Manifest V2 एक्सटेंशन को 31 अगस्त, 2026 को Chrome Web Store से हटा दिया गया था. अपने एक्सटेंशन को Manifest V3 पर माइग्रेट करें, ताकि यह उपयोगकर्ताओं के लिए फिर से उपलब्ध हो सके.

Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

chrome.declarativeNetRequest

refresh date: 2026-09-25 robots: noindex

ब्यौरा

chrome.declarativeNetRequest एपीआई का इस्तेमाल, नेटवर्क के अनुरोधों को ब्लॉक करने या उनमें बदलाव करने के लिए किया जाता है. इसके लिए, डिक्लेरेटिव नियमों का इस्तेमाल किया जाता है. इससे एक्सटेंशन, नेटवर्क के अनुरोधों को इंटरसेप्ट किए बिना और उनके कॉन्टेंट को देखे बिना उनमें बदलाव कर सकते हैं. इससे उपयोगकर्ताओं को ज़्यादा निजता मिलती है.

अनुमतियां

declarativeNetRequest
declarativeNetRequestWithHostAccess

declarativeNetRequestFeedback
host_permissions

उपलब्धता

Chrome 84+

मेनिफ़ेस्ट

ऊपर बताई गई अनुमतियों के अलावा, कुछ खास तरह के रूलसेट, खास तौर पर स्टैटिक रूलसेट के लिए, "declarative_net_request" मेनिफ़ेस्ट पासकोड का एलान करना ज़रूरी है. यह एक डिक्शनरी होनी चाहिए, जिसमें "rule_resources" नाम का एक पासकोड हो. यह कुंजी एक कलेक्शन है, जिसमें Ruleset टाइप की डिक्शनरी शामिल हैं. जैसा कि यहां दिखाया गया है. (ध्यान दें कि 'Ruleset' नाम, मेनिफ़ेस्ट के JSON में नहीं दिखता, क्योंकि यह सिर्फ़ एक कलेक्शन है.) स्टैटिक रूलसेट के बारे में इस दस्तावेज़ में आगे बताया गया है.

{
  "name": "My extension",
  ...

  "declarative_net_request" : {
    "rule_resources" : [{
      "id": "ruleset_1",
      "enabled": true,
      "path": "rules_1.json"
    }, {
      "id": "ruleset_2",
      "enabled": false,
      "path": "rules_2.json"
    }]
  },
  "permissions": [
    "declarativeNetRequest",
    "declarativeNetRequestFeedback",
  ],
  "host_permissions": [
    "http://www.blogger.com/*",
    "http://*.google.com/*"
  ],
  ...
}

कॉन्सेप्ट और इस्तेमाल

इस एपीआई का इस्तेमाल करने के लिए, एक या इससे ज़्यादा नियमों के सेट तय करें. नियमों के सेट में नियमों का कलेक्शन होता है. एक नियम इनमें से कोई एक काम करता है:

नेटवर्क के अनुरोध को ब्लॉक करना.
स्कीमा को अपग्रेड करें (एचटीटीपी से एचटीटीपीएस पर).
ब्लॉक किए गए किसी भी नियम को नकारकर, किसी अनुरोध को ब्लॉक होने से रोकना.
नेटवर्क के अनुरोध को रीडायरेक्ट करना.
अनुरोध या रिस्पॉन्स हेडर में बदलाव करना.

नियमों के सेट तीन तरह के होते हैं. इन्हें मैनेज करने के तरीके भी थोड़े अलग होते हैं.

डाइनैमिक: ये ब्राउज़र सेशन और एक्सटेंशन अपग्रेड के दौरान बने रहते हैं. साथ ही, एक्सटेंशन के इस्तेमाल के दौरान, इन्हें JavaScript का इस्तेमाल करके मैनेज किया जाता है.
सेशन: ब्राउज़र बंद होने और एक्सटेंशन का नया वर्शन इंस्टॉल होने पर, यह डेटा मिटा दिया जाता है. एक्सटेंशन का इस्तेमाल करते समय, सेशन के नियमों को JavaScript का इस्तेमाल करके मैनेज किया जाता है.
स्थिर: कोई एक्सटेंशन इंस्टॉल या अपग्रेड किए जाने पर, उसे पैकेज, इंस्टॉल, और अपडेट किया जाता है. स्टैटिक नियमों को JSON फ़ॉर्मैट वाली नियम फ़ाइलों में सेव किया जाता है. साथ ही, इन्हें मेनिफ़ेस्ट फ़ाइल में शामिल किया जाता है.

अगले कुछ सेक्शन में, नियमों के सेट के टाइप के बारे में ज़्यादा जानकारी दी गई है.

डाइनैमिक और सेशन के स्कोप वाले रूलसेट

एक्सटेंशन का इस्तेमाल करते समय, डाइनैमिक और सेशन के नियमों के सेट को JavaScript का इस्तेमाल करके मैनेज किया जाता है.

डाइनैमिक नियम, ब्राउज़र सेशन और एक्सटेंशन अपग्रेड के दौरान बने रहते हैं.
ब्राउज़र बंद होने और एक्सटेंशन का नया वर्शन इंस्टॉल होने पर, सेशन के नियम हटा दिए जाते हैं.

इनमें से हर तरह का सिर्फ़ एक नियम सेट होता है. कोई एक्सटेंशन, updateDynamicRules() और updateSessionRules() को कॉल करके, डाइनैमिक तौर पर नियमों को जोड़ या हटा सकता है. हालांकि, इसके लिए ज़रूरी है कि नियमों की तय सीमाएं पार न हों. नियम की सीमाओं के बारे में जानने के लिए, नियम की सीमाएं लेख पढ़ें. कोड के उदाहरण में जाकर, इसका एक उदाहरण देखा जा सकता है.

स्टैटिक रूल्सैट

डाइनैमिक और सेशन नियमों के उलट, स्टैटिक नियमों को पैकेज, इंस्टॉल, और अपडेट तब किया जाता है, जब कोई एक्सटेंशन इंस्टॉल या अपग्रेड किया जाता है. इन्हें JSON फ़ॉर्मैट में नियम फ़ाइलों में सेव किया जाता है. इन्हें एक्सटेंशन को "declarative_net_request" और "rule_resources" कुंजियों का इस्तेमाल करके दिखाया जाता है. इसके बारे में ऊपर बताया गया है. साथ ही, एक या उससे ज़्यादा Ruleset डिक्शनरी का इस्तेमाल करके भी दिखाया जाता है. Ruleset डिक्शनरी में, नियम फ़ाइल का पाथ, फ़ाइल में मौजूद नियमों के सेट का आईडी, और नियमों के सेट के चालू या बंद होने की जानकारी होती है. आखिरी दो विकल्प तब ज़रूरी होते हैं, जब प्रोग्राम के हिसाब से नियमों के सेट को चालू या बंद किया जाता है.

{
  ...
  "declarative_net_request" : {
    "rule_resources" : [{
      "id": "ruleset_1",
      "enabled": true,
      "path": "rules_1.json"
    },
    ...
    ]
  }
  ...
}

नियमों की फ़ाइलों की जांच करने के लिए, अपने एक्सटेंशन को अनपैक करके लोड करें. अमान्य स्टैटिक नियमों से जुड़ी गड़बड़ियां और चेतावनियां, सिर्फ़ अनपैक किए गए एक्सटेंशन के लिए दिखती हैं. पैक किए गए एक्सटेंशन में मौजूद अमान्य स्टैटिक नियमों को अनदेखा कर दिया जाता है.

स्टैटिक नियमों और रूलसेट को चालू और बंद करना

रनटाइम के दौरान, अलग-अलग स्टैटिक नियमों और पूरे स्टैटिक नियम सेट को चालू या बंद किया जा सकता है.

चालू किए गए स्टैटिक नियमों और नियमों के सेट, ब्राउज़र के सभी सेशन में बने रहते हैं. एक्सटेंशन के अपडेट के दौरान, दोनों में से कोई भी नियम सेव नहीं रहता. इसका मतलब है कि अपडेट के बाद, सिर्फ़ वे नियम उपलब्ध होते हैं जिन्हें आपने अपनी नियम फ़ाइलों में सेव किया है.

परफ़ॉर्मेंस को बेहतर बनाए रखने के लिए, एक समय पर चालू किए जा सकने वाले नियमों और नियमों के सेट की संख्या पर भी सीमाएं लागू होती हैं. getAvailableStaticRuleCount() को कॉल करके, उन अतिरिक्त नियमों की संख्या देखें जिन्हें चालू किया जा सकता है. नियम की सीमाओं के बारे में जानने के लिए, नियम की सीमाएं लेख पढ़ें.

स्टैटिक नियमों को चालू या बंद करने के लिए, updateStaticRules() को कॉल करें. यह तरीका, UpdateStaticRulesOptions ऑब्जेक्ट लेता है. इसमें चालू या बंद किए जाने वाले नियमों के आईडी की कैटगरी होती हैं. आईडी को Ruleset डिक्शनरी की "id" कुंजी का इस्तेमाल करके तय किया जाता है.

स्टैटिक नियमों के सेट को चालू या बंद करने के लिए, updateEnabledRulesets() को कॉल करें. यह तरीका, UpdateRulesetOptions ऑब्जेक्ट लेता है. इसमें, चालू या बंद किए जाने वाले नियमों के सेट के आईडी की कैटगरी होती हैं. आईडी को Ruleset डिक्शनरी की "id" कुंजी का इस्तेमाल करके तय किया जाता है.

नियम बनाना

नियम चाहे किसी भी तरह का हो, उसमें चार फ़ील्ड होते हैं. इनके बारे में यहां बताया गया है. "id" और "priority" कुंजियों में कोई संख्या डाली जाती है. वहीं, "action" और "condition" कुंजियों में, ब्लॉक करने और रीडायरेक्ट करने की कई शर्तें डाली जा सकती हैं. यहां दिया गया नियम, "foo.com" से आने वाले सभी स्क्रिप्ट अनुरोधों को ब्लॉक करता है. ये अनुरोध, सबस्ट्रिंग के तौर पर "abc" वाले किसी भी यूआरएल के लिए होते हैं.

{
  "id" : 1,
  "priority": 1,
  "action" : { "type" : "block" },
  "condition" : {
    "urlFilter" : "abc",
    "initiatorDomains" : ["foo.com"],
    "resourceTypes" : ["script"]
  }
}

urlFilter से मैच होने वाले वर्ण

किसी नियम की "condition" कुंजी, किसी तय डोमेन के यूआरएल पर कार्रवाई करने के लिए "urlFilter" कुंजी की अनुमति देती है. पैटर्न मैचिंग टोकन का इस्तेमाल करके पैटर्न बनाए जाते हैं. यहां कुछ उदाहरण दिए गए हैं.

`urlFilter`	मैच	मिलान नहीं होता है
`"abc"`	https://abcd.com https://example.com/abcd	https://ab.com
`"abc*d"`	https://abcd.com https://example.com/abcxyzd	https://abc.com
`"\|\|a.example.com"`	https://a.example.com/ https://b.a.example.com/xyz	https://example.com/
`"\|https*"`	https://example.com	http://example.com/ http://https.com
`"example*^123\|"`	https://example.com/123 http://abc.com/example?123	https://example.com/1234 https://abc.com/example0123

नियमों को प्राथमिकता देना

वेब पेजों से भेजे गए अनुरोधों से नियम ट्रिगर होते हैं. अगर एक से ज़्यादा नियम किसी अनुरोध से मैच करते हैं, तो नियमों को प्राथमिकता के हिसाब से क्रम में लगाना होगा. इस सेक्शन में बताया गया है कि उन्हें प्राथमिकता कैसे दी जाती है. प्राथमिकता दो चरणों में तय होती है.

किसी एक्सटेंशन में मौजूद नियमों के लिए प्राथमिकता तय की जाती है.
अगर एक से ज़्यादा एक्सटेंशन किसी अनुरोध पर कोई नियम लागू कर सकते हैं, तो किसी अनुरोध से मैच करने वाले सभी एक्सटेंशन के लिए प्राथमिकता तय की जाती है.

मैच करने के इस तरीके के बारे में सोचें: कोई एक्सटेंशन जिस नियम को प्राथमिकता देता है उसे अन्य एक्सटेंशन के नियमों के मुकाबले प्राथमिकता दी जाएगी.

सावधानी:एक ही कार्रवाई और प्राथमिकता वाले ऐसे नियम लिखने से बचें जिन्हें किसी खास क्रम में चलाना ज़रूरी हो. एक जैसी कार्रवाई और प्राथमिकता वाले नियम (उदाहरण के लिए, प्राथमिकता 1 वाले रीडायरेक्ट नियम) किसी भी क्रम में लागू किए जाते हैं. यह क्रम तय नहीं होता है और यह रन या ब्राउज़र के वर्शन के बीच बदल सकता है. भले ही, ये नियम कई तरह के नियमों के सेट (उदाहरण के लिए, स्टैटिक नियम और सेशन नियम) के बीच फैले हों. यह सभी ब्राउज़र पर लागू होता है.

किसी एक्सटेंशन में नियम की प्राथमिकता तय करना

किसी एक एक्सटेंशन में, प्राथमिकता तय करने के लिए इस प्रोसेस का इस्तेमाल किया जाता है:

डेवलपर की तय की गई सबसे ज़्यादा प्राथमिकता वाला नियम (दूसरे शब्दों में, "priority" फ़ील्ड) दिखाया जाता है.
अगर डेवलपर की तय की गई सबसे ज़्यादा प्राथमिकता वाले एक से ज़्यादा नियम हैं, तो "action" फ़ील्ड का इस्तेमाल करके नियमों को प्राथमिकता दी जाती है. इसके लिए, यह क्रम अपनाया जाता है:
1. allow
2. allowAllRequests
3. block
4. upgradeScheme
5. redirect
अगर कार्रवाई का टाइप block या redirect नहीं है, तो मैच करने वाले किसी भी modifyHeaders नियम का आकलन किया जाता है. ध्यान रखें कि अगर डेवलपर ने किसी नियम के लिए, allow और allowAllRequests के लिए तय की गई प्राथमिकता से कम प्राथमिकता सेट की है, तो ऐसे नियमों को अनदेखा कर दिया जाता है.
अगर एक से ज़्यादा नियम एक ही हेडर में बदलाव करते हैं, तो बदलाव का फ़ैसला, डेवलपर के तय किए गए "priority" फ़ील्ड और तय की गई कार्रवाइयों के आधार पर लिया जाता है.
- अगर कोई नियम किसी हेडर में जुड़ता है, तो कम प्राथमिकता वाले नियम सिर्फ़ उस हेडर में जुड़ सकते हैं. सेट करने और हटाने की कार्रवाइयों की अनुमति नहीं है.
- अगर कोई नियम हेडर सेट करता है, तो कम प्राथमिकता वाले नियम सिर्फ़ उस हेडर में जोड़े जा सकते हैं. इसके अलावा, कोई और बदलाव करने की अनुमति नहीं है.
- अगर कोई नियम किसी हेडर को हटाता है, तो कम प्राथमिकता वाले नियम उस हेडर में और बदलाव नहीं कर सकते.

एक्सटेंशन के बीच नियमों की प्राथमिकता तय करना

अगर सिर्फ़ एक एक्सटेंशन में ऐसा नियम है जो किसी अनुरोध से मैच करता है, तो वह नियम लागू हो जाता है. हालांकि, अगर किसी अनुरोध से एक से ज़्यादा एक्सटेंशन मैच करते हैं, तो यह प्रोसेस इस्तेमाल की जाती है:

नियमों को "action" फ़ील्ड का इस्तेमाल करके, इस क्रम में प्राथमिकता दी जाती है:
1. block
2. redirect या upgradeScheme
3. allow या allowAllRequests
अगर एक से ज़्यादा नियम मैच होते हैं, तो सबसे हाल ही में इंस्टॉल किए गए एक्सटेंशन को प्राथमिकता दी जाती है.

नियम की सीमाएं

ब्राउज़र में नियमों को लोड करने और उनका आकलन करने में परफ़ॉर्मेंस ओवरहेड होता है. इसलिए, एपीआई का इस्तेमाल करते समय कुछ सीमाएं लागू होती हैं. सीमाएं इस बात पर निर्भर करती हैं कि किस तरह के नियम का इस्तेमाल किया जा रहा है.

स्टैटिक नियम

स्टैटिक नियम वे होते हैं जो मेनिफ़ेस्ट फ़ाइल में बताई गई नियम फ़ाइलों में दिए जाते हैं. कोई एक्सटेंशन, "rule_resources" मेनिफ़ेस्ट कुंजी के हिस्से के तौर पर, ज़्यादा से ज़्यादा 50 स्टैटिक नियम सेट तय कर सकता है. हालांकि, इनमें से सिर्फ़ 10 नियम सेट एक बार में चालू किए जा सकते हैं. बाद वाले को MAX_NUMBER_OF_ENABLED_STATIC_RULESETS कहा जाता है. इन नियमों के सेट में, कम से कम 30,000 नियमों की गारंटी दी जाती है. इसे GUARANTEED_MINIMUM_STATIC_RULES कहते हैं.

इसके बाद, उपलब्ध नियमों की संख्या इस बात पर निर्भर करती है कि उपयोगकर्ता के ब्राउज़र पर इंस्टॉल किए गए सभी एक्सटेंशन ने कितने नियम चालू किए हैं. रनटाइम के दौरान, getAvailableStaticRuleCount() को कॉल करके यह नंबर पता किया जा सकता है. कोड के उदाहरण में जाकर, इसका एक उदाहरण देखा जा सकता है.

डाइनैमिक और सेशन के नियम

डाइनैमिक और सेशन के नियमों पर लागू होने वाली सीमाएं, स्टैटिक नियमों की तुलना में आसान होती हैं. दोनों की कुल संख्या 5,000 से ज़्यादा नहीं हो सकती. इसे MAX_NUMBER_OF_DYNAMIC_AND_SESSION_RULES कहते हैं.

रेगुलर एक्सप्रेशन का इस्तेमाल करने वाले नियम

सभी तरह के नियमों में रेगुलर एक्सप्रेशन का इस्तेमाल किया जा सकता है. हालांकि, हर तरह के रेगुलर एक्सप्रेशन वाले नियमों की कुल संख्या 1,000 से ज़्यादा नहीं हो सकती. इसे MAX_NUMBER_OF_REGEX_RULES कहा जाता है.

इसके अलावा, कंपाइल होने के बाद हर नियम का साइज़ 2 केबी से कम होना चाहिए. यह नियम की जटिलता से काफ़ी हद तक मेल खाता है. अगर आपने इस सीमा से ज़्यादा बड़ा नियम लोड करने की कोशिश की, तो आपको यहां दी गई चेतावनी दिखेगी और नियम को अनदेखा कर दिया जाएगा.

rules_1.json: Rule with id 1 specified a more complex regex than allowed
as part of the "regexFilter" key.

सर्विस वर्कर के साथ इंटरैक्शन

declarativeNetRequest सिर्फ़ उन अनुरोधों पर लागू होता है जो नेटवर्क स्टैक तक पहुंचते हैं. इसमें एचटीटीपी कैश मेमोरी से मिले रिस्पॉन्स शामिल हैं. हालांकि, इसमें ऐसे रिस्पॉन्स शामिल नहीं हो सकते जो सर्विस वर्कर के onfetch हैंडलर से गुज़रते हैं. declarativeNetRequest, सर्विस वर्कर से जनरेट किए गए या CacheStorage से वापस लाए गए रिस्पॉन्स पर असर नहीं डालेगा. हालांकि, यह सर्विस वर्कर में fetch() को किए गए कॉल पर असर डालेगा.

वेब पर ऐक्सेस किए जा सकने वाले संसाधन

declarativeNetRequest नियम, किसी सार्वजनिक संसाधन के अनुरोध को ऐसे संसाधन पर रीडायरेक्ट नहीं कर सकता जिसे वेब पर ऐक्सेस नहीं किया जा सकता. ऐसा करने पर, गड़बड़ी का मैसेज दिखता है. यह तब भी लागू होता है, जब वेब से ऐक्सेस किए जा सकने वाले संसाधन का मालिकाना हक, रीडायरेक्ट करने वाले एक्सटेंशन के पास हो. declarativeNetRequest के लिए संसाधनों का एलान करने के लिए, मेनिफ़ेस्ट के "web_accessible_resources" कलेक्शन का इस्तेमाल करें.

उदाहरण

कोड के उदाहरण

डाइनैमिक नियमों को अपडेट करना

यहां दिए गए उदाहरण में, updateDynamicRules() को कॉल करने का तरीका बताया गया है. updateSessionRules() के लिए भी यही तरीका है.

// Get arrays containing new and old rules
const newRules = await getNewRules();
const oldRules = await chrome.declarativeNetRequest.getDynamicRules();
const oldRuleIds = oldRules.map(rule => rule.id);

// Use the arrays to update the dynamic rules
await chrome.declarativeNetRequest.updateDynamicRules({
  removeRuleIds: oldRuleIds,
  addRules: newRules
});

स्टैटिक नियमों के सेट अपडेट करना

यहां दिए गए उदाहरण में, नियम के सेट को चालू और बंद करने का तरीका बताया गया है. इसमें, उपलब्ध और चालू किए गए स्टैटिक नियम के सेट की ज़्यादा से ज़्यादा संख्या को ध्यान में रखा गया है. ऐसा तब किया जाता है, जब आपको तय सीमा से ज़्यादा स्टैटिक नियमों की ज़रूरत हो. इसके लिए, आपके कुछ नियम सेट इंस्टॉल होने चाहिए और कुछ नियम सेट बंद होने चाहिए. इसके लिए, मेनिफ़ेस्ट फ़ाइल में "Enabled" को false पर सेट करें.

async function updateStaticRules(enableRulesetIds, disableCandidateIds) {
  // Create the options structure for the call to updateEnabledRulesets()
  let options = { enableRulesetIds: enableRulesetIds }
  // Get the number of enabled static rules
  const enabledStaticCount = await chrome.declarativeNetRequest.getEnabledRulesets();
  // Compare rule counts to determine if anything needs to be disabled so that
  // new rules can be enabled
  const proposedCount = enableRulesetIds.length;
  if (enabledStaticCount + proposedCount > chrome.declarativeNetRequest.MAX_NUMBER_OF_ENABLED_STATIC_RULESETS) {
    options.disableRulesetIds = disableCandidateIds
  }
  // Update the enabled static rules
  await chrome.declarativeNetRequest.updateEnabledRulesets(options);
}

नियम के उदाहरण

यहां दिए गए उदाहरणों से पता चलता है कि Chrome, किसी एक्सटेंशन में नियमों को कैसे प्राथमिकता देता है. समीक्षा करते समय, हो सकता है कि आप प्राथमिकता के नियमों को किसी अलग विंडो में खोलना चाहें.

"priority" कुंजी

इन उदाहरणों के लिए, *://*.example.com/* को होस्ट करने की अनुमति की ज़रूरत होती है.

किसी यूआरएल की प्राथमिकता तय करने के लिए, (डेवलपर की तय की गई) "priority" कुंजी, "action" कुंजी, और "urlFilter" कुंजी देखें. ये उदाहरण, इनके नीचे दिखाई गई उदाहरण के तौर पर दी गई नियम फ़ाइल से जुड़े हैं.

https://google.com पर नेविगेट करना: इस यूआरएल पर दो नियम लागू होते हैं: आईडी 1 और 4 वाले नियम. आईडी 1 वाला नियम लागू होता है, क्योंकि "block" कार्रवाइयों की प्राथमिकता "redirect" कार्रवाइयों से ज़्यादा है. बाकी नियम लागू नहीं होते, क्योंकि वे लंबे यूआरएल के लिए हैं.
https://google.com/1234 पर नेविगेट करना: यूआरएल लंबा होने की वजह से, आईडी 2 वाला नियम अब आईडी 1 और 4 वाले नियमों के साथ-साथ मैच होता है. आईडी 2 वाला नियम लागू होता है, क्योंकि "allow" की प्राथमिकता "block" और "redirect" से ज़्यादा है.
https://google.com/12345 पर नेविगेट करना: इस यूआरएल से चारों नियम मैच होते हैं. आईडी 3 वाला नियम लागू होता है, क्योंकि डेवलपर ने इसे ग्रुप में सबसे ज़्यादा प्राथमिकता दी है.

[
  {
    "id": 1,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {"urlFilter": "google.com", "resourceTypes": ["main_frame"] }
  },
  {
    "id": 2,
    "priority": 1,
    "action": { "type": "allow" },
    "condition": { "urlFilter": "google.com/123", "resourceTypes": ["main_frame"] }
  },
  {
    "id": 3,
    "priority": 2,
    "action": { "type": "block" },
    "condition": { "urlFilter": "google.com/12345", "resourceTypes": ["main_frame"] }
  },
  {
    "id": 4,
    "priority": 1,
    "action": { "type": "redirect", "redirect": { "url": "https://example.com" } },
    "condition": { "urlFilter": "google.com", "resourceTypes": ["main_frame"] }
  },
]

रीडायरेक्ट

यहां दिए गए उदाहरण में, *://*.example.com/* के लिए होस्ट की अनुमति ज़रूरी है.

यहां दिए गए उदाहरण में, example.com से किसी अनुरोध को एक्सटेंशन के अंदर मौजूद पेज पर रीडायरेक्ट करने का तरीका बताया गया है. एक्सटेंशन पाथ /a.jpg, chrome-extension://EXTENSION_ID/a.jpg पर ले जाता है. यहां EXTENSION_ID आपके एक्सटेंशन का आईडी है. इसके लिए, मेनिफ़ेस्ट में /a.jpg को वेब पर ऐक्सेस किए जा सकने वाले संसाधन के तौर पर एलान करना चाहिए.

{
  "id": 1,
  "priority": 1,
  "action": { "type": "redirect", "redirect": { "extensionPath": "/a.jpg" } },
  "condition": {
    "urlFilter": "https://www.example.com",
    "resourceTypes": ["main_frame"]
  }
}

यहां example.com के सबडोमेन पर रीडायरेक्ट करने के लिए, "transform" कुंजी का इस्तेमाल किया गया है. यह example.com से किसी भी स्कीम के साथ किए गए अनुरोधों को रोकने के लिए, डोमेन नेम ऐंकर ("||") का इस्तेमाल करता है. "transform" में मौजूद "scheme" कुंजी से पता चलता है कि सबडोमेन पर रीडायरेक्ट करने के लिए, हमेशा "https" का इस्तेमाल किया जाएगा.

{
  "id": 1,
  "priority": 1,
  "action": {
    "type": "redirect",
    "redirect": {
      "transform": { "scheme": "https", "host": "new.example.com" }
    }
  },
  "condition": {
    "urlFilter": "||example.com",
    "resourceTypes": ["main_frame"]
  }
}

यहां दिए गए उदाहरण में, https://www.abc.xyz.com/path से https://abc.xyz.com/path पर रीडायरेक्ट करने के लिए रेगुलर एक्सप्रेशन का इस्तेमाल किया गया है. "regexFilter" कुंजी में, ध्यान दें कि पीरियड को कैसे एस्केप किया गया है और कैप्चर करने वाला ग्रुप "abc" या "def" में से किसी एक को चुनता है. "regexSubstitution" कुंजी, "\1" का इस्तेमाल करके रेगुलर एक्सप्रेशन के पहले मैच की जानकारी देती है. इस मामले में, "abc" को रीडायरेक्ट किए गए यूआरएल से कैप्चर किया जाता है और बदले गए यूआरएल में डाला जाता है.

{
  "id": 1,
  "priority": 1,
  "action": {
    "type": "redirect",
    "redirect": {
      "regexSubstitution": "https://\\1.xyz.com/"
    }
  },
  "condition": {
    "regexFilter": "^https://www\\.(abc|def)\\.xyz\\.com/",
    "resourceTypes": [
      "main_frame"
    ]
  }
}

हेडर

यहां दिए गए उदाहरण में, मुख्य फ़्रेम और किसी भी सब-फ़्रेम से सभी कुकी हटाई गई हैं.

{
  "id": 1,
  "priority": 1,
  "action": {
    "type": "modifyHeaders",
    "requestHeaders": [{ "header": "cookie", "operation": "remove" }]
  },
  "condition": { "resourceTypes": ["main_frame", "sub_frame"] }
}

टाइप

DomainType

इससे पता चलता है कि अनुरोध, उस फ़्रेम के लिए पहले पक्ष का है या तीसरे पक्ष का है जिसमें इसे शुरू किया गया था. किसी अनुरोध को पहले पक्ष का अनुरोध तब कहा जाता है, जब उसका डोमेन (eTLD+1) वही हो जो उस फ़्रेम का है जिसमें अनुरोध किया गया था.

Enum

"firstParty"
नेटवर्क का अनुरोध, उस फ़्रेम का पहला पक्ष है जिसमें इसे शुरू किया गया था.

"thirdParty"
नेटवर्क का अनुरोध, उस फ़्रेम के लिए तीसरे पक्ष का है जिसमें इसे शुरू किया गया था.

ExtensionActionOptions

Chrome 88 या इसके बाद का वर्शन

प्रॉपर्टी

displayActionCountAsBadgeText

बूलियन ज़रूरी नहीं

क्या किसी पेज के लिए, कार्रवाई की संख्या को एक्सटेंशन के बैज टेक्स्ट के तौर पर अपने-आप दिखाना है. यह प्राथमिकता सभी सेशन में बनी रहती है.
tabUpdate

TabActionCountUpdate ज़रूरी नहीं

Chrome 89 या इसके बाद का वर्शन

टैब की कार्रवाई की संख्या को अडजस्ट करने के तरीके की जानकारी.

GetDisabledRuleIdsOptions

Chrome 111+

प्रॉपर्टी

rulesetId

स्ट्रिंग

स्टैटिक Ruleset से जुड़ा आईडी.

GetRulesFilter

Chrome 111+

प्रॉपर्टी

ruleIds

number[] ज़रूरी नहीं

अगर आईडी की जानकारी दी गई है, तो सिर्फ़ मेल खाने वाले आईडी वाले नियम शामिल किए जाते हैं.

HeaderInfo

Chrome 128+

प्रॉपर्टी

excludedValues

string[] ज़रूरी नहीं

अगर यह शर्त तय की गई है, तो हेडर मौजूद होने पर भी यह शर्त मैच नहीं होती. हालांकि, ऐसा तब होता है, जब हेडर की वैल्यू में इस सूची का कम से कम एक एलिमेंट शामिल हो. यह values के जैसे ही मैच पैटर्न सिंटैक्स का इस्तेमाल करता है.
हेडर

स्ट्रिंग

हेडर का नाम. यह शर्त, नाम से सिर्फ़ तब मैच करती है, जब values और excludedValues, दोनों की वैल्यू न दी गई हो.
वैल्यू

string[] ज़रूरी नहीं

अगर यह शर्त तय की गई है, तो यह तब मैच करती है, जब हेडर की वैल्यू इस सूची में मौजूद कम से कम एक पैटर्न से मैच करती हो. यह केस-इनसेंसिटिव हेडर वैल्यू मैचिंग के साथ-साथ, इन कंस्ट्रक्ट के साथ काम करता है:

'*' : यह किसी भी संख्या में वर्णों से मैच करता है.

'?' : शून्य या एक वर्ण से मेल खाता है.

'*' और '?' को बैकस्लैश के साथ एस्केप किया जा सकता है. जैसे, '\*' और '\?'

HeaderOperation

Chrome 86 या इसके बाद का वर्शन

इसमें "modifyHeaders" नियम के लिए संभावित कार्रवाइयों के बारे में बताया गया है.

Enum

"append"
यह तय किए गए हेडर के लिए नई एंट्री जोड़ता है. किसी अनुरोध के हेडर में बदलाव करते समय, यह कार्रवाई सिर्फ़ चुनिंदा हेडर के लिए की जा सकती है.

"set"
यह दिए गए हेडर के लिए नई वैल्यू सेट करता है. साथ ही, उसी नाम वाले किसी भी मौजूदा हेडर को हटा देता है.

"remove"
यह हेडर की सभी एंट्री हटा देता है.

IsRegexSupportedResult

Chrome 87+

प्रॉपर्टी

isSupported

बूलियन
reason

UnsupportedRegexReason ज़रूरी नहीं है

इससे पता चलता है कि रेगुलर एक्सप्रेशन क्यों काम नहीं करता. यह सिर्फ़ तब उपलब्ध होता है, जब isSupported की वैल्यू 'गलत है' पर सेट हो.

MatchedRule

प्रॉपर्टी

ruleId

संख्या

मिलते-जुलते नियम का आईडी.
rulesetId

स्ट्रिंग

उस Ruleset का आईडी जिससे यह नियम जुड़ा है. डाइनैमिक नियमों के सेट से मिलने वाले नियम के लिए, यह DYNAMIC_RULESET_ID के बराबर होगा.

MatchedRuleInfo

प्रॉपर्टी

नियम

MatchedRule
tabId

संख्या

अगर टैब अब भी चालू है, तो उस टैब का tabId जिससे अनुरोध किया गया था. Else -1.
timeStamp

संख्या

नियम के मैच होने का समय. टाइमस्टैंप, समय के लिए JavaScript कन्वेंशन के मुताबिक होंगे. इसका मतलब है कि टाइमस्टैंप, इपॉक के बाद से मिलीसेकंड की संख्या के हिसाब से होंगे.

MatchedRuleInfoDebug

प्रॉपर्टी

CANNOT TRANSLATE

RequestDetails

उस अनुरोध के बारे में जानकारी जिसके लिए नियम मैच हुआ.
नियम

MatchedRule

MatchedRulesFilter

प्रॉपर्टी

minTimeStamp

number ज़रूरी नहीं

अगर यह पैरामीटर दिया गया है, तो दिए गए टाइमस्टैंप के बाद के नियमों से ही मैच किया जाएगा.
tabId

number ज़रूरी नहीं

अगर तय किया गया है, तो सिर्फ़ दिए गए टैब के नियमों से मैच करता है. अगर इसे -1 पर सेट किया जाता है, तो यह उन नियमों से मैच करता है जो किसी भी चालू टैब से जुड़े नहीं हैं.

ModifyHeaderInfo

Chrome 86 या इसके बाद का वर्शन

प्रॉपर्टी

हेडर

स्ट्रिंग

उस हेडर का नाम जिसमें बदलाव करना है.
कार्रवाई

HeaderOperation

हेडर पर की जाने वाली कार्रवाई.
मान

string ज़रूरी नहीं

हेडर की नई वैल्यू. append और set कार्रवाइयों के लिए, यह जानकारी देना ज़रूरी है.

QueryKeyValue

प्रॉपर्टी

बटन

स्ट्रिंग
replaceOnly

बूलियन ज़रूरी नहीं

Chrome 94 या इसके बाद का वर्शन

अगर सही है, तो क्वेरी कुंजी को सिर्फ़ तब बदला जाता है, जब वह पहले से मौजूद हो. अगर ऐसा नहीं है, तो कुंजी मौजूद न होने पर उसे भी जोड़ दिया जाता है. डिफ़ॉल्ट तौर पर, यह 'गलत' पर सेट होती है.
मान

स्ट्रिंग

QueryTransform

प्रॉपर्टी

addOrReplaceParams

QueryKeyValue[] ज़रूरी नहीं

जोड़े जाने वाले या बदले जाने वाले क्वेरी की-वैल्यू पेयर की सूची.
removeParams

string[] ज़रूरी नहीं

हटाए जाने वाली क्वेरी कुंजियों की सूची.

Redirect

प्रॉपर्टी

extensionPath

string ज़रूरी नहीं

एक्सटेंशन डायरेक्ट्री के हिसाब से पाथ. '/' से शुरू होना चाहिए.
regexSubstitution

string ज़रूरी नहीं

regexFilter तय करने वाले नियमों के लिए, सबस्टिट्यूशन पैटर्न. यूआरएल में regexFilter के पहले मैच को इस पैटर्न से बदल दिया जाएगा. regexSubstitution में, बैकस्लैश से शुरू होने वाले अंकों (\1 से \9) का इस्तेमाल करके, उनसे जुड़े कैप्चर ग्रुप डाले जा सकते हैं. \0, मैच होने वाले पूरे टेक्स्ट के बारे में बताता है.
रूपांतरित करें

URLTransform ज़रूरी नहीं

यूआरएल में किए जाने वाले बदलाव.
url

string ज़रूरी नहीं

रीडायरेक्ट यूआरएल. JavaScript यूआरएल पर रीडायरेक्ट करने की अनुमति नहीं है.

RegexOptions

Chrome 87+

प्रॉपर्टी

isCaseSensitive

बूलियन ज़रूरी नहीं

क्या तय किया गया regex केस-सेंसिटिव है. डिफ़ॉल्ट रूप से, यह true पर सेट रहता है.
रेगुलर एक्सप्रेशन

स्ट्रिंग

जांच करने के लिए रेगुलर एक्सप्रेशन.
requireCapturing

बूलियन ज़रूरी नहीं

क्या बताए गए regex को कैप्चर करना ज़रूरी है. कैप्चर करने की ज़रूरत सिर्फ़ उन रीडायरेक्ट नियमों के लिए होती है जिनमें regexSubstition कार्रवाई के बारे में बताया गया हो. डिफ़ॉल्ट रूप से, यह 'गलत' पर सेट होती है.

RequestDetails

प्रॉपर्टी

documentId

string ज़रूरी नहीं

Chrome 106+

फ़्रेम के दस्तावेज़ के लिए यूनीक आइडेंटिफ़ायर, अगर यह अनुरोध किसी फ़्रेम के लिए है.
documentLifecycle

DocumentLifecycle ज़रूरी नहीं

Chrome 106+

फ़्रेम के दस्तावेज़ की लाइफ़साइकल, अगर यह अनुरोध किसी फ़्रेम के लिए है.
frameId

संख्या

वैल्यू 0 से पता चलता है कि अनुरोध मुख्य फ़्रेम में किया गया है. वहीं, पॉज़िटिव वैल्यू से उस सबफ़्रेम के आईडी का पता चलता है जिसमें अनुरोध किया गया है. अगर किसी (सब-)फ़्रेम का दस्तावेज़ लोड किया जाता है (type, main_frame या sub_frame है), तो frameId इस फ़्रेम का आईडी दिखाता है, न कि बाहरी फ़्रेम का आईडी. फ़्रेम आईडी, किसी टैब में यूनीक होते हैं.
frameType

FrameType ज़रूरी नहीं है

Chrome 106+

अगर यह अनुरोध किसी फ़्रेम के लिए है, तो फ़्रेम का टाइप.
शुरू करने वाला

string ज़रूरी नहीं

वह ऑरिजिन जहां से अनुरोध किया गया था. रीडायरेक्ट करने से इसमें कोई बदलाव नहीं होता. अगर यह एक ओपेक ऑरिजिन है, तो 'null' स्ट्रिंग का इस्तेमाल किया जाएगा.
तरीका

स्ट्रिंग

एचटीटीपी का स्टैंडर्ड तरीका.
parentDocumentId

string ज़रूरी नहीं

Chrome 106+

फ़्रेम के पैरंट दस्तावेज़ का यूनीक आइडेंटिफ़ायर. यह तब होता है, जब यह अनुरोध किसी फ़्रेम के लिए हो और उसका कोई पैरंट हो.
parentFrameId

संख्या

अनुरोध भेजने वाले फ़्रेम को रैप करने वाले फ़्रेम का आईडी. अगर कोई पैरंट फ़्रेम मौजूद नहीं है, तो इसे -1 पर सेट करें.
requestId

स्ट्रिंग

अनुरोध का आईडी. अनुरोध आईडी, ब्राउज़र के किसी सेशन के लिए यूनीक होते हैं.
tabId

संख्या

उस टैब का आईडी जिसमें अनुरोध किया गया है. अगर अनुरोध किसी टैब से जुड़ा नहीं है, तो इसे -1 पर सेट करें.
टाइप

ResourceType

अनुरोध का संसाधन टाइप.
url

स्ट्रिंग

अनुरोध का यूआरएल.

RequestMethod

Chrome 91+

इससे नेटवर्क के अनुरोध के एचटीटीपी अनुरोध के तरीके के बारे में पता चलता है.

Enum

"connect"

"मिटाएं"

"get"

"head"

"options"

"patch"

"post"

"put"

"other"

ResourceType

इससे नेटवर्क के अनुरोध के संसाधन टाइप के बारे में पता चलता है.

Enum

"main_frame"

"sub_frame"

"stylesheet"

"script"

"image"

"font"

"object"

"xmlhttprequest"

"ping"

"csp_report"

"media"

"websocket"

"webtransport"

"webbundle"

"other"

Rule

प्रॉपर्टी

ऐक्शन गेम

RuleAction

इस नियम के मैच होने पर की जाने वाली कार्रवाई.
शर्त

RuleCondition

वह शर्त जिसके तहत यह नियम ट्रिगर होता है.
आईडी

संख्या

एक ऐसा आईडी जो किसी नियम की खास तौर पर पहचान करता है. यह ज़रूरी है और इसकी वैल्यू 1 से ज़्यादा या इसके बराबर होनी चाहिए.
प्राथमिकता

number ज़रूरी नहीं

नियम की प्राथमिकता. डिफ़ॉल्ट वैल्यू 1 होती है. अगर इसकी वैल्यू दी गई है, तो वह 1 से ज़्यादा या उसके बराबर होनी चाहिए.

RuleAction

प्रॉपर्टी

रीडायरेक्ट करो

रीडायरेक्ट ज़रूरी नहीं

इससे पता चलता है कि रीडायरेक्ट कैसे किया जाना चाहिए. यह सिर्फ़ रीडायरेक्ट करने के नियमों के लिए मान्य है.
requestHeaders

ModifyHeaderInfo[] ज़रूरी नहीं

Chrome 86 या इसके बाद का वर्शन

अनुरोध के लिए, अनुरोध के हेडर में बदलाव करना. यह सिर्फ़ तब मान्य होता है, जब RuleActionType "modifyHeaders" हो.
responseHeaders

ModifyHeaderInfo[] ज़रूरी नहीं

Chrome 86 या इसके बाद का वर्शन

अनुरोध के लिए, रिस्पॉन्स हेडर में बदलाव करना. यह सिर्फ़ तब मान्य होता है, जब RuleActionType "modifyHeaders" हो.
टाइप

RuleActionType

कार्रवाई का टाइप.

RuleActionType

इससे पता चलता है कि RuleCondition मैच होने पर किस तरह की कार्रवाई करनी है.

Enum

"block"
नेटवर्क के अनुरोध को ब्लॉक करें.

"redirect"
नेटवर्क के अनुरोध को रीडायरेक्ट करें.

"allow"
नेटवर्क के अनुरोध को अनुमति दें. अगर अनुरोध, अनुमति देने वाले किसी नियम से मैच करता है, तो उसे नहीं रोका जाएगा.

"upgradeScheme"
अगर नेटवर्क अनुरोध का यूआरएल एचटीटीपी या एफ़टीपी है, तो उसे एचटीटीपीएस में अपग्रेड करें.

"modifyHeaders"
नेटवर्क के अनुरोध से, अनुरोध/रिस्पॉन्स हेडर में बदलाव करें.

"allowAllRequests"
फ़्रेम की हैरारकी में मौजूद सभी अनुरोधों को अनुमति दें. इसमें फ़्रेम का अनुरोध भी शामिल है.

RuleCondition

प्रॉपर्टी

domainType

DomainType ज़रूरी नहीं है

इससे पता चलता है कि नेटवर्क का अनुरोध, उस डोमेन के लिए पहले पक्ष का है या तीसरे पक्ष का जिससे वह शुरू हुआ है. अगर इसे शामिल नहीं किया जाता है, तो सभी अनुरोध स्वीकार कर लिए जाते हैं.
डोमेन

string[] ज़रूरी नहीं

Chrome 101 के बाद से इस्तेमाल नहीं किया जा रहा है

इसके बजाय, initiatorDomains का इस्तेमाल करें
यह नियम, सिर्फ़ domains की सूची से जनरेट होने वाले नेटवर्क के अनुरोधों से मैच करेगा.
excludedDomains

string[] ज़रूरी नहीं

Chrome 101 के बाद से इस्तेमाल नहीं किया जा रहा है

इसके बजाय, excludedInitiatorDomains का इस्तेमाल करें
यह नियम, excludedDomains की सूची से आने वाले नेटवर्क के अनुरोधों से मैच नहीं होगा.
excludedInitiatorDomains

string[] ज़रूरी नहीं

Chrome 101+

यह नियम, excludedInitiatorDomains की सूची से आने वाले नेटवर्क के अनुरोधों से मैच नहीं होगा. अगर सूची खाली है या उसे शामिल नहीं किया गया है, तो किसी भी डोमेन को बाहर नहीं रखा जाता. इसे initiatorDomains के ऊपर प्राथमिकता दी जाती है.

ध्यान दें:
- "a.example.com" जैसे सब-डोमेन भी इस्तेमाल किए जा सकते हैं.
- एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
- अंतरराष्ट्रीय डोमेन के लिए, प्यूनीकोड एन्कोडिंग का इस्तेमाल करें.
- यह अनुरोध करने वाले से मैच करता है, न कि अनुरोध के यूआरएल से.
- सूची में शामिल डोमेन के सब-डोमेन भी शामिल नहीं किए जाते.
excludedRequestDomains

string[] ज़रूरी नहीं

Chrome 101+

अगर डोमेन, excludedRequestDomains की सूची में मौजूद किसी डोमेन से मैच करता है, तो नियम नेटवर्क के अनुरोधों से मैच नहीं करेगा. अगर सूची खाली है या उसे शामिल नहीं किया गया है, तो किसी भी डोमेन को बाहर नहीं रखा जाता. इसे requestDomains के ऊपर प्राथमिकता दी जाती है.

ध्यान दें:
- "a.example.com" जैसे सब-डोमेन भी इस्तेमाल किए जा सकते हैं.
- एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
- अंतरराष्ट्रीय डोमेन के लिए, प्यूनीकोड एन्कोडिंग का इस्तेमाल करें.
- सूची में शामिल डोमेन के सब-डोमेन भी शामिल नहीं किए जाते.
excludedRequestMethods

RequestMethod[] ज़रूरी नहीं है

Chrome 91+

अनुरोध के उन तरीकों की सूची जो नियम से मैच नहीं करेंगे. requestMethods और excludedRequestMethods में से सिर्फ़ एक की जानकारी दी जानी चाहिए. अगर इनमें से कोई भी तरीका नहीं बताया गया है, तो अनुरोध के सभी तरीके मैच किए जाते हैं.
excludedResourceTypes

ResourceType[] ज़रूरी नहीं है

उन रिसॉर्स टाइप की सूची जिनसे नियम मैच नहीं होगा. resourceTypes और excludedResourceTypes में से सिर्फ़ एक की जानकारी दी जानी चाहिए. अगर इनमें से कोई भी वैल्यू तय नहीं की गई है, तो "main_frame" को छोड़कर, सभी तरह के रिसॉर्स ब्लॉक कर दिए जाते हैं.
excludedResponseHeaders

HeaderInfo[] optional

Chrome 128+

अगर अनुरोध, इस सूची में मौजूद किसी भी रिस्पॉन्स हेडर की शर्त से मैच करता है, तो नियम मैच नहीं होता. हालांकि, ऐसा तब होता है, जब शर्त तय की गई हो. अगर excludedResponseHeaders और responseHeaders, दोनों प्रॉपर्टी की वैल्यू दी गई हैं, तो excludedResponseHeaders प्रॉपर्टी को प्राथमिकता दी जाती है.
excludedTabIds

number[] ज़रूरी नहीं

Chrome 92+

tabs.Tab.id की सूची, जिससे नियम मैच नहीं होना चाहिए. tabs.TAB_ID_NONE का आईडी, उन अनुरोधों को बाहर रखता है जो किसी टैब से नहीं आते. यह सुविधा सिर्फ़ सेशन के स्कोप वाले नियमों के लिए उपलब्ध है.
excludedTopDomains

string[] ज़रूरी नहीं

Chrome 145 या इसके बाद का वर्शन

अगर टॉप-लेवल फ़्रेम का डोमेन, excludedTopDomains की सूची में मौजूद किसी डोमेन से मैच करता है, तो नियम नेटवर्क के अनुरोधों से मैच नहीं करेगा. अगर सूची खाली है या उसे शामिल नहीं किया गया है, तो किसी भी डोमेन को बाहर नहीं रखा जाता. इसे topDomains के ऊपर प्राथमिकता दी जाती है.

ध्यान दें:
- "a.example.com" जैसे सब-डोमेन भी इस्तेमाल किए जा सकते हैं.
- एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
- अंतरराष्ट्रीय डोमेन के लिए, प्यूनीकोड एन्कोडिंग का इस्तेमाल करें.
- सूची में शामिल डोमेन के सब-डोमेन भी शामिल नहीं किए जाते.
- ऐसे अनुरोधों के लिए जिनका कोई टॉप-लेवल फ़्रेम नहीं है, जैसे कि ServiceWorker से शुरू किए गए अनुरोध, अनुरोध शुरू करने वाले के डोमेन को ही टॉप-लेवल फ़्रेम माना जाता है.
initiatorDomains

string[] ज़रूरी नहीं

Chrome 101+

यह नियम, सिर्फ़ initiatorDomains की सूची से जनरेट होने वाले नेटवर्क के अनुरोधों से मैच करेगा. अगर सूची को शामिल नहीं किया जाता है, तो नियम सभी डोमेन से आने वाले अनुरोधों पर लागू होता है. खाली सूची की अनुमति नहीं है.

ध्यान दें:
- "a.example.com" जैसे सब-डोमेन भी इस्तेमाल किए जा सकते हैं.
- एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
- अंतरराष्ट्रीय डोमेन के लिए, प्यूनीकोड एन्कोडिंग का इस्तेमाल करें.
- यह अनुरोध करने वाले से मैच करता है, न कि अनुरोध के यूआरएल से.
- सूची में शामिल डोमेन के सब-डोमेन भी मैच किए जाते हैं.
isUrlFilterCaseSensitive

बूलियन ज़रूरी नहीं

urlFilter या regexFilter (जो भी तय किया गया हो) केस-सेंसिटिव है या नहीं. डिफ़ॉल्ट रूप से, यह false पर सेट होती है.
regexFilter

string ज़रूरी नहीं

नेटवर्क के अनुरोध वाले यूआरएल से मैच करने के लिए रेगुलर एक्सप्रेशन. यह RE2 सिंटैक्स का पालन करता है.

ध्यान दें: urlFilter या regexFilter में से सिर्फ़ एक की जानकारी दी जा सकती है.

ध्यान दें: regexFilter में सिर्फ़ ASCII वर्ण होने चाहिए. इसे उस यूआरएल से मैच किया जाता है जिसमें होस्ट को punycode फ़ॉर्मैट (अंतरराष्ट्रीय डोमेन के मामले में) में कोड में बदला गया हो. साथ ही, अन्य सभी गैर-ASCII वर्णों को utf-8 में यूआरएल कोड में बदला गया हो.
requestDomains

string[] ज़रूरी नहीं

Chrome 101+

यह नियम, नेटवर्क के अनुरोधों से सिर्फ़ तब मैच होगा, जब डोमेन, requestDomains की सूची में मौजूद किसी डोमेन से मैच होगा. अगर सूची को शामिल नहीं किया जाता है, तो नियम सभी डोमेन से आने वाले अनुरोधों पर लागू होता है. खाली सूची की अनुमति नहीं है.

ध्यान दें:
- "a.example.com" जैसे सब-डोमेन भी इस्तेमाल किए जा सकते हैं.
- एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
- अंतरराष्ट्रीय डोमेन के लिए, प्यूनीकोड एन्कोडिंग का इस्तेमाल करें.
- सूची में शामिल डोमेन के सब-डोमेन भी मैच किए जाते हैं.
requestMethods

RequestMethod[] ज़रूरी नहीं है

Chrome 91+

एचटीटीपी अनुरोध के उन तरीकों की सूची जिनसे नियम मैच हो सकता है. खाली सूची की अनुमति नहीं है.

ध्यान दें: requestMethods नियम की शर्त तय करने पर, एचटीटीपी(एस) के अलावा अन्य अनुरोध भी शामिल नहीं किए जाएंगे. हालांकि, excludedRequestMethods तय करने पर ऐसा नहीं होगा.
resourceTypes

ResourceType[] ज़रूरी नहीं है

उन संसाधन टाइप की सूची जिनसे नियम मैच हो सकता है. खाली सूची की अनुमति नहीं है.

ध्यान दें: यह allowAllRequests नियमों के लिए तय किया जाना चाहिए. इसमें सिर्फ़ sub_frame और main_frame रिसॉर्स टाइप शामिल हो सकते हैं.
responseHeaders

HeaderInfo[] optional

Chrome 128+

अगर अनुरोध, इस सूची में मौजूद रिस्पॉन्स हेडर की किसी शर्त से मैच करता है, तो नियम मैच होता है. हालांकि, ऐसा तब होता है, जब शर्त बताई गई हो.
tabIds

number[] ज़रूरी नहीं

Chrome 92+

tabs.Tab.id की सूची, जिससे नियम मैच होना चाहिए. tabs.TAB_ID_NONE का आईडी, उन अनुरोधों से मैच करता है जो किसी टैब से नहीं आते. खाली सूची की अनुमति नहीं है. यह सुविधा सिर्फ़ सेशन के स्कोप वाले नियमों के लिए उपलब्ध है.
topDomains

string[] ज़रूरी नहीं

Chrome 145 या इसके बाद का वर्शन

यह नियम, नेटवर्क के अनुरोधों से सिर्फ़ तब मैच होगा, जब उससे जुड़े टॉप-लेवल फ़्रेम का डोमेन, topDomains की सूची में मौजूद किसी डोमेन से मैच होगा. अगर सूची को शामिल नहीं किया जाता है, तो नियम को सभी टॉप-लेवल फ़्रेम डोमेन से जुड़े अनुरोधों पर लागू किया जाता है. खाली सूची की अनुमति नहीं है.

ध्यान दें:
- "a.example.com" जैसे सब-डोमेन भी इस्तेमाल किए जा सकते हैं.
- एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
- अंतरराष्ट्रीय डोमेन के लिए, प्यूनीकोड एन्कोडिंग का इस्तेमाल करें.
- सूची में शामिल डोमेन के सब-डोमेन भी मैच किए जाते हैं.
- ऐसे अनुरोधों के लिए जिनका कोई टॉप-लेवल फ़्रेम नहीं है, जैसे कि ServiceWorker से शुरू किए गए अनुरोध, अनुरोध शुरू करने वाले के डोमेन को ही टॉप-लेवल फ़्रेम माना जाता है.
urlFilter

string ज़रूरी नहीं

वह पैटर्न जो नेटवर्क अनुरोध के यूआरएल से मैच करता है. इस्तेमाल किए जा सकने वाले कंस्ट्रक्ट:

'*' : वाइल्डकार्ड: यह किसी भी संख्या में वर्णों से मैच करता है.

'|' : बायां/दायां ऐंकर: अगर पैटर्न के किसी भी सिरे पर इस्तेमाल किया जाता है, तो यह यूआरएल की शुरुआत/आखिर के बारे में बताता है.

'||' : डोमेन नेम ऐंकर: अगर इसका इस्तेमाल पैटर्न की शुरुआत में किया जाता है, तो इससे यूआरएल के (सब-)डोमेन की शुरुआत का पता चलता है.

'^' : सेपरेटर वर्ण: यह किसी अक्षर, अंक या इनमें से किसी एक को छोड़कर, किसी भी चीज़ से मैच करता है: _, -, . या %. यह यूआरएल के आखिरी हिस्से से भी मैच करता है.

इसलिए, urlFilter में ये हिस्से शामिल होते हैं: (ज़रूरत के हिसाब से लेफ्ट/डोमेन नेम ऐंकर) + पैटर्न + (ज़रूरत के हिसाब से राइट ऐंकर).

अगर इसे शामिल नहीं किया जाता है, तो सभी यूआरएल मैच किए जाते हैं. खाली स्ट्रिंग की अनुमति नहीं है.

||* से शुरू होने वाले पैटर्न का इस्तेमाल नहीं किया जा सकता. इसके बजाय, * का इस्तेमाल करें.

ध्यान दें: urlFilter या regexFilter में से सिर्फ़ एक की जानकारी दी जा सकती है.

ध्यान दें: urlFilter में सिर्फ़ ASCII वर्ण होने चाहिए. इसे उस यूआरएल से मैच किया जाता है जिसमें होस्ट को punycode फ़ॉर्मैट (अंतरराष्ट्रीय डोमेन के मामले में) में कोड में बदला गया हो. साथ ही, अन्य सभी गैर-ASCII वर्णों को utf-8 में यूआरएल कोड में बदला गया हो. उदाहरण के लिए, अगर अनुरोध का यूआरएल http://abc.рф?q=ф है, तो urlFilter को http://abc.xn--p1ai/?q=%D1%84 यूआरएल से मैच किया जाएगा.

RuleConditionKeys

Chrome 145 या इसके बाद का वर्शन

Enum

"urlFilter"

"regexFilter"

"isUrlFilterCaseSensitive"

"initiatorDomains"

"excludedInitiatorDomains"

"requestDomains"

"excludedRequestDomains"

"topDomains"

"excludedTopDomains"

"domains"

"excludedDomains"

"resourceTypes"

"excludedResourceTypes"

"requestMethods"

"excludedRequestMethods"

"domainType"

"tabIds"

"excludedTabIds"

"responseHeaders"

"excludedResponseHeaders"

Ruleset

प्रॉपर्टी

चालू किया गया

बूलियन

क्या नियमों का सेट डिफ़ॉल्ट रूप से चालू है.
आईडी

स्ट्रिंग

एक ऐसी स्ट्रिंग जो खाली न हो और जिससे नियमों के सेट की खास तौर पर पहचान की जा सके. '_' से शुरू होने वाले आईडी, अंदरूनी इस्तेमाल के लिए रिज़र्व होते हैं.
पाथ

स्ट्रिंग

एक्सटेंशन डायरेक्ट्री के हिसाब से, JSON नियमों के सेट का पाथ.

RulesMatchedDetails

प्रॉपर्टी

rulesMatchedInfo

MatchedRuleInfo[]

दिए गए फ़िल्टर से मैच करने वाले नियम.

TabActionCountUpdate

Chrome 89 या इसके बाद का वर्शन

प्रॉपर्टी

अधिक

संख्या

टैब की कार्रवाई की संख्या में बढ़ोतरी की वैल्यू. नेगेटिव वैल्यू से, संख्या कम हो जाएगी.
tabId

संख्या

वह टैब जिसके लिए कार्रवाई की संख्या अपडेट करनी है.

TestMatchOutcomeResult

Chrome 103 या इसके बाद का वर्शन

प्रॉपर्टी

matchedRules

MatchedRule[]

काल्पनिक अनुरोध से मेल खाने वाले नियम (अगर कोई हो).

TestMatchRequestDetails

Chrome 103 या इसके बाद का वर्शन

प्रॉपर्टी

शुरू करने वाला

string ज़रूरी नहीं

अनुमानित अनुरोध के लिए, अनुरोध शुरू करने वाले का यूआरएल (अगर कोई है).
तरीका

RequestMethod ज़रूरी नहीं है

काल्पनिक अनुरोध का स्टैंडर्ड एचटीटीपी तरीका. एचटीटीपी अनुरोधों के लिए, यह डिफ़ॉल्ट रूप से "get" पर सेट होता है. साथ ही, एचटीटीपी के अलावा अन्य अनुरोधों के लिए इसे अनदेखा कर दिया जाता है.
responseHeaders

object ज़रूरी नहीं

Chrome 129 या इसके बाद का वर्शन

अगर अनुरोध को भेजने से पहले ब्लॉक या रीडायरेक्ट नहीं किया जाता है, तो काल्पनिक जवाब से मिले हेडर. इसे एक ऑब्जेक्ट के तौर पर दिखाया जाता है, जो हेडर के नाम को स्ट्रिंग वैल्यू की सूची से मैप करता है. अगर यह तय नहीं किया गया है, तो काल्पनिक रिस्पॉन्स में खाली रिस्पॉन्स हेडर दिखेंगे. ये हेडर, उन नियमों से मैच हो सकते हैं जो हेडर मौजूद न होने पर मैच होते हैं. उदा. {"content-type": ["text/html; charset=utf-8", "multipart/form-data"]}
tabId

number ज़रूरी नहीं

उस टैब का आईडी जिसमें काल्पनिक अनुरोध किया जाता है. इसका किसी असली टैब आईडी से मेल खाना ज़रूरी नहीं है. डिफ़ॉल्ट वैल्यू -1 होती है. इसका मतलब है कि अनुरोध किसी टैब से जुड़ा नहीं है.
topUrl

string ज़रूरी नहीं

Chrome 145 या इसके बाद का वर्शन

अनुरोध के लिए, उससे जुड़ा टॉप-लेवल फ़्रेम यूआरएल (अगर कोई है).
टाइप

ResourceType

काल्पनिक अनुरोध का संसाधन टाइप.
url

स्ट्रिंग

काल्पनिक अनुरोध का यूआरएल.

UnsupportedRegexReason

Chrome 87+

इससे पता चलता है कि कोई रेगुलर एक्सप्रेशन क्यों काम नहीं करता.

Enum

"syntaxError"
रेगुलर एक्सप्रेशन का सिंटैक्स गलत है या इसमें ऐसी सुविधाओं का इस्तेमाल किया गया है जो RE2 सिंटैक्स में उपलब्ध नहीं हैं.

"memoryLimitExceeded"
रेगुलर एक्सप्रेशन, मेमोरी की सीमा से ज़्यादा है.

UpdateRuleOptions

Chrome 87+

प्रॉपर्टी

addRules

नियम[] ज़रूरी नहीं

जोड़े जाने वाले नियम.
removeRuleIds

number[] ज़रूरी नहीं

हटाए जाने वाले नियमों के आईडी. अमान्य आईडी को अनदेखा कर दिया जाएगा.

UpdateRulesetOptions

Chrome 87+

प्रॉपर्टी

disableRulesetIds

string[] ज़रूरी नहीं

स्टैटिक Ruleset से जुड़े आईडी का सेट, जिसे बंद किया जाना चाहिए.
enableRulesetIds

string[] ज़रूरी नहीं

स्टैटिक Ruleset से जुड़े आईडी का सेट, जिसे चालू किया जाना चाहिए.

UpdateStaticRulesOptions

Chrome 111+

प्रॉपर्टी

disableRuleIds

number[] ज़रूरी नहीं

Ruleset में मौजूद नियमों के आईडी का सेट, जिन्हें बंद करना है.
enableRuleIds

number[] ज़रूरी नहीं

चालू करने के लिए, Ruleset में मौजूद नियमों से जुड़े आईडी का सेट.
rulesetId

स्ट्रिंग

स्टैटिक Ruleset से जुड़ा आईडी.

URLTransform

प्रॉपर्टी

फ़्रैगमेंट

string ज़रूरी नहीं

अनुरोध के लिए नया फ़्रैगमेंट. यह फ़ील्ड खाली होना चाहिए. ऐसा होने पर, मौजूदा फ़्रैगमेंट को हटा दिया जाता है. इसके अलावा, यह फ़ील्ड '#' से शुरू होना चाहिए.
होस्ट

string ज़रूरी नहीं

अनुरोध के लिए नया होस्ट.
पासवर्ड

string ज़रूरी नहीं

अनुरोध के लिए नया पासवर्ड.
पाथ

string ज़रूरी नहीं

अनुरोध के लिए नया पाथ. अगर यह फ़ील्ड खाली है, तो मौजूदा पाथ हटा दिया जाता है.
पोर्ट

string ज़रूरी नहीं

अनुरोध के लिए नया पोर्ट. अगर यह फ़ील्ड खाली है, तो मौजूदा पोर्ट को हटा दिया जाता है.
क्वेरी

string ज़रूरी नहीं

अनुरोध के लिए नई क्वेरी. यह खाली होना चाहिए. ऐसा होने पर, मौजूदा क्वेरी मिटा दी जाती है. इसके अलावा, यह '?' से शुरू होना चाहिए.
queryTransform

QueryTransform ज़रूरी नहीं

क्वेरी के की-वैल्यू पेयर जोड़ें, हटाएं या बदलें.
स्कीम

string ज़रूरी नहीं

अनुरोध के लिए नई स्कीम. "http", "https", "ftp", और "chrome-extension" वैल्यू का इस्तेमाल किया जा सकता है.
उपयोगकर्ता नाम

string ज़रूरी नहीं

अनुरोध के लिए नया उपयोगकर्ता नाम.

प्रॉपर्टी

DYNAMIC_RULESET_ID

एक्सटेंशन से जोड़े गए डाइनैमिक नियमों के लिए Ruleset ID.

वैल्यू

"_dynamic"

GETMATCHEDRULES_QUOTA_INTERVAL

वह समयावधि जिसमें MAX_GETMATCHEDRULES_CALLS_PER_INTERVAL getMatchedRules कॉल किए जा सकते हैं. इसे मिनट में बताया जाता है. इसके बाद किए जाने वाले कॉल तुरंत फ़ेल हो जाएंगे और runtime.lastError सेट हो जाएगा. ध्यान दें: उपयोगकर्ता के जेस्चर से जुड़े getMatchedRules कॉल, कोटे से बाहर होते हैं.

वैल्यू

GUARANTEED_MINIMUM_STATIC_RULES

Chrome 89 या इसके बाद का वर्शन

किसी एक्सटेंशन के लिए, चालू किए गए स्टैटिक रूलसेट में स्टैटिक नियमों की कम से कम संख्या. इस सीमा से ज़्यादा नियम, ग्लोबल स्टैटिक नियम की सीमा में गिने जाएंगे.

वैल्यू

30000

MAX_GETMATCHEDRULES_CALLS_PER_INTERVAL

GETMATCHEDRULES_QUOTA_INTERVAL की अवधि में, getMatchedRules को कितनी बार कॉल किया जा सकता है.

वैल्यू

MAX_NUMBER_OF_DYNAMIC_RULES

ज़्यादा से ज़्यादा डाइनैमिक नियम, जो कोई एक्सटेंशन जोड़ सकता है.

वैल्यू

30000

MAX_NUMBER_OF_ENABLED_STATIC_RULESETS

Chrome 94 या इसके बाद का वर्शन

स्टैटिक Rulesets की वह ज़्यादा से ज़्यादा संख्या जिसे कोई एक्सटेंशन एक बार में चालू कर सकता है.

वैल्यू

MAX_NUMBER_OF_REGEX_RULES

रेगुलर एक्सप्रेशन के नियमों की वह ज़्यादा से ज़्यादा संख्या जो कोई एक्सटेंशन जोड़ सकता है. इस सीमा का आकलन, डाइनैमिक नियमों के सेट और नियम के रिसॉर्स फ़ाइल में बताए गए नियमों के लिए अलग-अलग किया जाता है.

वैल्यू

1000

MAX_NUMBER_OF_SESSION_RULES

Chrome 120 या इसके बाद का वर्शन

सेशन के स्कोप वाले नियमों की वह संख्या जो कोई एक्सटेंशन जोड़ सकता है.

वैल्यू

5000

MAX_NUMBER_OF_STATIC_RULESETS

"rule_resources" मेनिफ़ेस्ट कुंजी के हिस्से के तौर पर, कोई एक्सटेंशन ज़्यादा से ज़्यादा कितने स्टैटिक Rulesets तय कर सकता है.

वैल्यू

100

MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES

Chrome 120 या इसके बाद का वर्शन

कोई एक्सटेंशन, "असुरक्षित" डाइनैमिक नियमों को ज़्यादा से ज़्यादा कितनी बार जोड़ सकता है.

वैल्यू

5000

MAX_NUMBER_OF_UNSAFE_SESSION_RULES

Chrome 120 या इसके बाद का वर्शन

सेशन के स्कोप वाले "असुरक्षित" नियमों की वह संख्या जो कोई एक्सटेंशन जोड़ सकता है.

वैल्यू

5000

SESSION_RULESET_ID

Chrome 90+

एक्सटेंशन से जोड़े गए सेशन के स्कोप वाले नियमों के लिए, नियमों के सेट का आईडी.

वैल्यू

"_session"

तरीके

getAvailableStaticRuleCount()

Promise Chrome 89 और इसके बाद के वर्शन

chrome.declarativeNetRequest.getAvailableStaticRuleCount(
  callback?: function,
): Promise<number>

यह फ़ंक्शन, स्टैटिक नियमों की वह संख्या दिखाता है जिन्हें कोई एक्सटेंशन, ग्लोबल स्टैटिक नियम की सीमा तक पहुंचने से पहले चालू कर सकता है.

पैरामीटर

कॉलबैक

function ज़रूरी नहीं

callback पैरामीटर कुछ ऐसा दिखता है:
```
(count: number) => void
```
- सोलर पैनलों की संख्या
  
  संख्या

रिटर्न

Promise<number>

Chrome 91+

प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म के लिए, कॉलबैक का इस्तेमाल करना ज़रूरी है.

getDisabledRuleIds()

Promise Chrome 111+

chrome.declarativeNetRequest.getDisabledRuleIds(
  options: GetDisabledRuleIdsOptions,
  callback?: function,
): Promise<number[]>

यह फ़ंक्शन, दिए गए Ruleset में मौजूद उन स्टैटिक नियमों की सूची दिखाता है जो फ़िलहाल बंद हैं.

पैरामीटर

विकल्प

GetDisabledRuleIdsOptions

इससे क्वेरी के लिए नियमों के सेट के बारे में पता चलता है.
कॉलबैक

function ज़रूरी नहीं

callback पैरामीटर कुछ ऐसा दिखता है:
```
(disabledRuleIds: number[]) => void
```
- disabledRuleIds
  
  number[]

रिटर्न

Promise<number[]>

प्रॉमिस, जो उस नियम सेट में बंद किए गए नियमों से जुड़े आईडी की सूची के साथ रिज़ॉल्व होता है.

प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म के लिए, कॉलबैक का इस्तेमाल करना ज़रूरी है.

getDynamicRules()

वादा

chrome.declarativeNetRequest.getDynamicRules(
  filter?: GetRulesFilter,
  callback?: function,
): Promise<Rule[]>

यह एक्सटेंशन के लिए, डाइनैमिक नियमों का मौजूदा सेट दिखाता है. कॉलर, filter की जानकारी देकर, फ़ेच किए गए नियमों की सूची को फ़िल्टर कर सकते हैं.

पैरामीटर

फ़िल्टर

GetRulesFilter ज़रूरी नहीं

Chrome 111+

फ़ेच किए गए नियमों की सूची को फ़िल्टर करने के लिए कोई ऑब्जेक्ट.
कॉलबैक

function ज़रूरी नहीं

callback पैरामीटर कुछ ऐसा दिखता है:
```
(rules: Rule[]) => void
```
- नियम
  
  नियम[]

रिटर्न

Promise<Rule[]>

Chrome 91+

प्रॉमिस, जो डाइनैमिक नियमों के सेट के साथ रिज़ॉल्व होता है. सिस्टम में कुछ समय के लिए होने वाली गड़बड़ियों की वजह से, Promise को अस्वीकार किया जा सकता है.

प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म के लिए, कॉलबैक का इस्तेमाल करना ज़रूरी है.

getEnabledRulesets()

वादा

chrome.declarativeNetRequest.getEnabledRulesets(
  callback?: function,
): Promise<string[]>

यह चालू किए गए स्टैटिक रूलसेट के मौजूदा सेट के लिए आईडी दिखाता है.

पैरामीटर

कॉलबैक

function ज़रूरी नहीं

callback पैरामीटर कुछ ऐसा दिखता है:
```
(rulesetIds: string[]) => void
```
- rulesetIds
  
  string[]

रिटर्न

Promise<string[]>

Chrome 91+

प्रॉमिस, जो आईडी की सूची के साथ रिज़ॉल्व होता है. इसमें हर आईडी, चालू किए गए स्टैटिक Ruleset से जुड़ा होता है.

प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म के लिए, कॉलबैक का इस्तेमाल करना ज़रूरी है.

getMatchedRules()

वादा

chrome.declarativeNetRequest.getMatchedRules(
  filter?: MatchedRulesFilter,
  callback?: function,
): Promise<RulesMatchedDetails>

यह एक्सटेंशन के लिए मैच होने वाले सभी नियम दिखाता है. कॉलर, filter की जानकारी देकर, मैच होने वाले नियमों की सूची को फ़िल्टर कर सकते हैं. यह तरीका सिर्फ़ उन एक्सटेंशन के लिए उपलब्ध है जिनके पास "declarativeNetRequestFeedback" की अनुमति है या जिनके पास filter में बताए गए tabId के लिए "activeTab" की अनुमति है. ध्यान दें: ऐसे नियम जो किसी चालू दस्तावेज़ से जुड़े नहीं हैं और पांच मिनट से ज़्यादा समय पहले मैच हुए थे, वे नहीं दिखाए जाएंगे.

पैरामीटर

फ़िल्टर

MatchedRulesFilter ज़रूरी नहीं

यह एक ऑब्जेक्ट है, जिसका इस्तेमाल मिलते-जुलते नियमों की सूची को फ़िल्टर करने के लिए किया जाता है.
कॉलबैक

function ज़रूरी नहीं

callback पैरामीटर कुछ ऐसा दिखता है:
```
(details: RulesMatchedDetails) => void
```
- विवरण
  
  RulesMatchedDetails

रिटर्न

Promise<RulesMatchedDetails>

Chrome 91+

यह प्रॉमिस, मैच होने वाले नियमों की सूची फ़ेच होने के बाद रिज़ॉल्व हो जाता है. कोई गड़बड़ी होने पर, Promise को अस्वीकार कर दिया जाएगा. ऐसा कई वजहों से हो सकता है. जैसे, ज़रूरी अनुमतियां न होना या कोटा खत्म हो जाना.

प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म के लिए, कॉलबैक का इस्तेमाल करना ज़रूरी है.

getSessionRules()

Promise Chrome 90 और इसके बाद के वर्शन

chrome.declarativeNetRequest.getSessionRules(
  filter?: GetRulesFilter,
  callback?: function,
): Promise<Rule[]>

यह एक्सटेंशन के लिए, सेशन के स्कोप वाले नियमों का मौजूदा सेट दिखाता है. कॉलर, filter की जानकारी देकर, फ़ेच किए गए नियमों की सूची को फ़िल्टर कर सकते हैं.

पैरामीटर

फ़िल्टर

GetRulesFilter ज़रूरी नहीं

Chrome 111+

फ़ेच किए गए नियमों की सूची को फ़िल्टर करने के लिए कोई ऑब्जेक्ट.
कॉलबैक

function ज़रूरी नहीं

callback पैरामीटर कुछ ऐसा दिखता है:
```
(rules: Rule[]) => void
```
- नियम
  
  नियम[]

रिटर्न

Promise<Rule[]>

Chrome 91+

प्रॉमिस, जो सेशन के स्कोप वाले नियमों के सेट के साथ रिज़ॉल्व होता है.

प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म के लिए, कॉलबैक का इस्तेमाल करना ज़रूरी है.

isRegexSupported()

Promise Chrome 87 और इसके बाद के वर्शन

chrome.declarativeNetRequest.isRegexSupported(
  regexOptions: RegexOptions,
  callback?: function,
): Promise<IsRegexSupportedResult>

यह जांच करता है कि दिया गया रेगुलर एक्सप्रेशन, regexFilter नियम की शर्त के तौर पर काम करेगा या नहीं.

पैरामीटर

regexOptions

RegexOptions

जांच करने के लिए रेगुलर एक्सप्रेशन.
कॉलबैक

function ज़रूरी नहीं

callback पैरामीटर कुछ ऐसा दिखता है:
```
(result: IsRegexSupportedResult) => void
```
- नतीजा
  
  IsRegexSupportedResult

रिटर्न

Promise<IsRegexSupportedResult>

Chrome 91+

प्रॉमिस, जो जानकारी के साथ रिज़ॉल्व होता है. इसमें यह शामिल होता है कि रेगुलर एक्सप्रेशन काम करता है या नहीं. अगर काम नहीं करता है, तो इसकी वजह क्या है.

प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म के लिए, कॉलबैक का इस्तेमाल करना ज़रूरी है.

setExtensionActionOptions()

Promise Chrome 88 और इसके बाद के वर्शन

chrome.declarativeNetRequest.setExtensionActionOptions(
  options: ExtensionActionOptions,
  callback?: function,
): Promise<void>

यह नीति कॉन्फ़िगर करती है कि टैब के लिए ऐक्शन की संख्या को एक्सटेंशन ऐक्शन के बैज टेक्स्ट के तौर पर दिखाया जाना चाहिए या नहीं. साथ ही, यह ऐक्शन की संख्या को बढ़ाने का तरीका भी बताती है.

पैरामीटर

विकल्प

ExtensionActionOptions
कॉलबैक

function ज़रूरी नहीं

Chrome 89 या इसके बाद का वर्शन

callback पैरामीटर कुछ ऐसा दिखता है:
```
() => void
```

रिटर्न

वादा<शून्य>

Chrome 91+

प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म के लिए, कॉलबैक का इस्तेमाल करना ज़रूरी है.

testMatchOutcome()

Promise Chrome 103+

chrome.declarativeNetRequest.testMatchOutcome(
  request: TestMatchRequestDetails,
  callback?: function,
): Promise<TestMatchOutcomeResult>

यह जांच करता है कि क्या एक्सटेंशन का कोई declarativeNetRequest नियम, किसी काल्पनिक अनुरोध से मेल खाएगा. ध्यान दें: यह सुविधा सिर्फ़ अनपैक किए गए एक्सटेंशन के लिए उपलब्ध है, क्योंकि इसका इस्तेमाल सिर्फ़ एक्सटेंशन डेवलप करने के दौरान किया जाता है.

पैरामीटर

CANNOT TRANSLATE

TestMatchRequestDetails
कॉलबैक

function ज़रूरी नहीं

callback पैरामीटर कुछ ऐसा दिखता है:
```
(result: TestMatchOutcomeResult) => void
```
- नतीजा
  
  TestMatchOutcomeResult

रिटर्न

Promise<TestMatchOutcomeResult>

यह प्रॉमिस, मैच होने वाले नियमों की जानकारी के साथ रिज़ॉल्व होता है.

प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म के लिए, कॉलबैक का इस्तेमाल करना ज़रूरी है.

updateDynamicRules()

वादा

chrome.declarativeNetRequest.updateDynamicRules(
  options: UpdateRuleOptions,
  callback?: function,
): Promise<void>

यह एक्सटेंशन के लिए, डाइनैमिक नियमों के मौजूदा सेट में बदलाव करता है. options.removeRuleIds में दिए गए आईडी वाले नियम पहले हटाए जाते हैं. इसके बाद, options.addRules में दिए गए नियम जोड़े जाते हैं. ध्यान दें:

यह अपडेट, एक ही ऐटॉमिक ऑपरेशन के तौर पर होता है: या तो तय किए गए सभी नियम जोड़ दिए जाते हैं और हटा दिए जाते हैं या फिर गड़बड़ी का मैसेज दिखता है.
ये नियम, ब्राउज़र सेशन और एक्सटेंशन के अपडेट के दौरान भी लागू रहते हैं.
एक्सटेंशन पैकेज के हिस्से के तौर पर तय किए गए स्टैटिक नियमों को इस फ़ंक्शन का इस्तेमाल करके नहीं हटाया जा सकता.
MAX_NUMBER_OF_DYNAMIC_RULES, डाइनैमिक नियमों की वह संख्या है जो कोई एक्सटेंशन जोड़ सकता है. असुरक्षित नियमों की संख्या MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES से ज़्यादा नहीं होनी चाहिए.

पैरामीटर

विकल्प

UpdateRuleOptions

Chrome 87+
कॉलबैक

function ज़रूरी नहीं

callback पैरामीटर कुछ ऐसा दिखता है:
```
() => void
```

रिटर्न

वादा<शून्य>

Chrome 91+

अपडेट पूरा होने के बाद, प्रॉमिस रिज़ॉल्व हो जाता है. कोई गड़बड़ी होने पर, प्रॉमिस को अस्वीकार कर दिया जाएगा और नियम के सेट में कोई बदलाव नहीं किया जाएगा. ऐसा कई वजहों से हो सकता है. जैसे, नियम का फ़ॉर्मैट अमान्य होना, नियम का आईडी डुप्लीकेट होना, नियम की संख्या की सीमा पार होना, सिस्टम से जुड़ी गड़बड़ियां वगैरह.

प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म के लिए, कॉलबैक का इस्तेमाल करना ज़रूरी है.

updateEnabledRulesets()

वादा

chrome.declarativeNetRequest.updateEnabledRulesets(
  options: UpdateRulesetOptions,
  callback?: function,
): Promise<void>

यह एक्सटेंशन के लिए, चालू किए गए स्टैटिक रूलसेट के सेट को अपडेट करता है. options.disableRulesetIds में मौजूद आईडी वाले नियमों के सेट पहले हटाए जाते हैं. इसके बाद, options.enableRulesetIds में मौजूद नियमों के सेट जोड़े जाते हैं. ध्यान दें कि चालू किए गए स्टैटिक रूलसेट का सेट, सभी सेशन में बना रहता है.हालांकि, एक्सटेंशन के अपडेट के दौरान ऐसा नहीं होता. इसका मतलब है कि rule_resources मेनिफ़ेस्ट कुंजी, एक्सटेंशन के हर अपडेट पर चालू किए गए स्टैटिक रूलसेट का सेट तय करेगी.

पैरामीटर

विकल्प

UpdateRulesetOptions

Chrome 87+
कॉलबैक

function ज़रूरी नहीं

callback पैरामीटर कुछ ऐसा दिखता है:
```
() => void
```

रिटर्न

वादा<शून्य>

Chrome 91+

अपडेट पूरा होने के बाद, प्रॉमिस रिज़ॉल्व हो जाता है. कोई गड़बड़ी होने पर, प्रॉमिस को अस्वीकार कर दिया जाएगा. साथ ही, चालू किए गए नियमों के सेट में कोई बदलाव नहीं किया जाएगा. ऐसा कई वजहों से हो सकता है. जैसे, अमान्य नियम सेट आईडी, नियमों की तय सीमा से ज़्यादा नियम होना या सिस्टम में गड़बड़ियां होना.

प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म के लिए, कॉलबैक का इस्तेमाल करना ज़रूरी है.

updateSessionRules()

Promise Chrome 90 और इसके बाद के वर्शन

chrome.declarativeNetRequest.updateSessionRules(
  options: UpdateRuleOptions,
  callback?: function,
): Promise<void>

यह एक्सटेंशन के लिए, सेशन के स्कोप वाले नियमों के मौजूदा सेट में बदलाव करता है. options.removeRuleIds में दिए गए आईडी वाले नियम पहले हटाए जाते हैं. इसके बाद, options.addRules में दिए गए नियम जोड़े जाते हैं. ध्यान दें:

यह अपडेट, एक ही ऐटॉमिक ऑपरेशन के तौर पर होता है: या तो तय किए गए सभी नियम जोड़ दिए जाते हैं और हटा दिए जाते हैं या फिर गड़बड़ी का मैसेज दिखता है.
ये नियम, सेशन के दौरान सेव नहीं रहते और मेमोरी में सेव होते हैं.
MAX_NUMBER_OF_SESSION_RULES, सेशन के नियमों की वह संख्या है जो कोई एक्सटेंशन ज़्यादा से ज़्यादा जोड़ सकता है.

पैरामीटर

विकल्प

UpdateRuleOptions
कॉलबैक

function ज़रूरी नहीं

callback पैरामीटर कुछ ऐसा दिखता है:
```
() => void
```

रिटर्न

वादा<शून्य>

Chrome 91+

अपडेट पूरा होने के बाद, प्रॉमिस रिज़ॉल्व हो जाता है. कोई गड़बड़ी होने पर, प्रॉमिस को अस्वीकार कर दिया जाएगा और नियम के सेट में कोई बदलाव नहीं किया जाएगा. ऐसा कई वजहों से हो सकता है. जैसे, नियम का फ़ॉर्मैट अमान्य होना, नियम का आईडी डुप्लीकेट होना, नियमों की संख्या तय सीमा से ज़्यादा होना वगैरह.

प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म के लिए, कॉलबैक का इस्तेमाल करना ज़रूरी है.

updateStaticRules()

Promise Chrome 111+

chrome.declarativeNetRequest.updateStaticRules(
  options: UpdateStaticRulesOptions,
  callback?: function,
): Promise<void>

Ruleset में अलग-अलग स्टैटिक नियमों को बंद और चालू करता है. बंद किए गए Ruleset के नियमों में किए गए बदलाव, अगली बार चालू होने पर लागू होंगे.

पैरामीटर

विकल्प

UpdateStaticRulesOptions
कॉलबैक

function ज़रूरी नहीं

callback पैरामीटर कुछ ऐसा दिखता है:
```
() => void
```

रिटर्न

वादा<शून्य>

अपडेट पूरा होने पर रिज़ॉल्व होने वाला प्रॉमिस. अगर कोई गड़बड़ी होती है, तो प्रॉमिस को अस्वीकार कर दिया जाएगा. साथ ही, चालू किए गए स्टैटिक नियमों में कोई बदलाव नहीं किया जाएगा.

प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म के लिए, कॉलबैक का इस्तेमाल करना ज़रूरी है.

इवेंट

onRuleMatchedDebug

chrome.declarativeNetRequest.onRuleMatchedDebug.addListener(
  callback: function,
)

यह तब ट्रिगर होता है, जब कोई नियम किसी अनुरोध से मैच होता है. यह सिर्फ़ उन अनपैक किए गए एक्सटेंशन के लिए उपलब्ध है जिनके पास "declarativeNetRequestFeedback" की अनुमति है. ऐसा इसलिए, क्योंकि इसका इस्तेमाल सिर्फ़ डीबग करने के लिए किया जाता है.

पैरामीटर

कॉलबैक

फ़ंक्शन

callback पैरामीटर कुछ ऐसा दिखता है:
```
(info: MatchedRuleInfoDebug) => void
```
- जानकारी
  
  MatchedRuleInfoDebug