इस पेज का अनुवाद Cloud Translation API से किया गया है.

chrome.declarativeNetRequest

ब्यौरा

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

अनुमतियां

declarativeNetRequest
declarativeNetRequestWithHostAccess

"declarativeNetRequest" और "declarativeNetRequestWithHostAccess" अनुमतियां एक ही सुविधाएं देती हैं. इन दोनों में अंतर यह है कि अनुमतियों का अनुरोध कब किया जाता है या उन्हें कब मंज़ूरी दी जाती है.

"declarativeNetRequest": , इंस्टॉल के समय अनुमति से जुड़ी चेतावनी ट्रिगर करता है. हालांकि, यह allow, allowAllRequests, और block नियमों का ऐक्सेस अपने-आप देता है. होस्ट से पूरा ऐक्सेस पाने का अनुरोध करने से बचने के लिए, जब भी हो सके तब इस सुविधा का इस्तेमाल करें.
"declarativeNetRequestFeedback": अनपैक किए गए एक्सटेंशन के लिए, डीबग करने की सुविधाएं चालू करता है. खास तौर पर, getMatchedRules() और onRuleMatchedDebug के लिए.
"declarativeNetRequestWithHostAccess": इंस्टॉल के समय अनुमति से जुड़ी चेतावनी नहीं दिखाई जाती. हालांकि, होस्ट पर कोई कार्रवाई करने से पहले, आपको होस्ट से अनुमतियों का अनुरोध करना होगा. यह तब सही होता है, जब आपको किसी ऐसे एक्सटेंशन में, एलान वाले नेट अनुरोध के नियमों का इस्तेमाल करना हो जिसमें पहले से ही होस्ट की अनुमतियां हों. ऐसा करने पर, आपको अतिरिक्त चेतावनियां नहीं मिलेंगी.

उपलब्धता

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" कुंजी का इस्तेमाल करके तय किए जाते हैं. बंद किए गए स्टैटिक नियमों की संख्या 5,000 से ज़्यादा नहीं होनी चाहिए.

स्टैटिक rulesets को चालू या बंद करने के लिए, 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"]
  }
}

यूआरएल मैच करना

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

यूआरएल फ़िल्टर का सिंटैक्स

नियम की "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://a.example.company	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

रेगुलर एक्सप्रेशन

कंडीशन में रेगुलर एक्सप्रेशन का इस्तेमाल भी किया जा सकता है. "regexFilter" बटन देखें. इन शर्तों पर लागू होने वाली सीमाओं के बारे में जानने के लिए, रेगुलर एक्सप्रेशन का इस्तेमाल करने वाले नियम देखें.

यूआरएल से जुड़ी अच्छी शर्तें लिखना

नियम लिखते समय, इस बात का ध्यान रखें कि वे पूरे डोमेन से हमेशा मैच करते हों. ऐसा न करने पर, आपका नियम अनचाहे मामलों में मैच कर सकता है. उदाहरण के लिए, पैटर्न मैचिंग सिंटैक्स का इस्तेमाल करते समय:

google.com, https://example.com/?param=google.com से गलत तरीके से मैच करता है
||google.com, https://google.company से गलत तरीके से मैच करता है
https://www.google.com, https://example.com/?param=https://www.google.com से गलत तरीके से मैच करता है

इनका इस्तेमाल करें:

||google.com/, जो सभी पाथ और सभी सबडोमेन से मैच करता है.
|https://www.google.com/, जो सभी पाथ से मेल खाता है और किसी भी सबडोमेन से नहीं.

इसी तरह, रेगुलर एक्सप्रेशन को ऐंकर करने के लिए, ^ और / वर्णों का इस्तेमाल करें. उदाहरण के लिए, ^https:\/\/www\.google\.com\/, https://www.google.com पर मौजूद किसी भी पाथ से मेल खाता है.

नियम का आकलन

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

अनुरोध करने से पहले

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

हर एक्सटेंशन के लिए, ब्राउज़र मैच होने वाले नियमों की सूची तय करता है. modifyHeaders कार्रवाई वाले नियमों को यहां शामिल नहीं किया गया है, क्योंकि उन्हें बाद में मैनेज किया जाएगा. इसके अलावा, responseHeaders शर्त वाले नियमों पर बाद में विचार किया जाएगा (जब रिस्पॉन्स हेडर उपलब्ध होंगे). इन्हें शामिल नहीं किया गया है.

इसके बाद, Chrome हर अनुरोध के लिए हर एक्सटेंशन के लिए ज़्यादा से ज़्यादा एक उम्मीदवार चुनता है. Chrome, मिलते-जुलते सभी नियमों को प्राथमिकता के हिसाब से क्रम में लगाकर, मैच होने वाला नियम ढूंढता है. एक ही प्राथमिकता वाले नियमों को कार्रवाई के हिसाब से क्रम में लगाया जाता है (allow या allowAllRequests > block > upgradeScheme > redirect).

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

अगर एक से ज़्यादा एक्सटेंशन इस अनुरोध को ब्लॉक या रीडायरेक्ट करना चाहते हैं, तो एक ही कार्रवाई चुनी जाती है. Chrome, नियमों को block > redirect या upgradeScheme > allow या allowAllRequests के क्रम में क्रम से लगाकर ऐसा करता है. अगर दो नियम एक जैसे हैं, तो Chrome हाल ही में इंस्टॉल किए गए एक्सटेंशन से नियम चुनता है.

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

अनुरोध हेडर भेजे जाने से पहले

Chrome, सर्वर को अनुरोध हेडर भेजने से पहले, हेडर को मैच करने वाले modifyHeaders नियमों के आधार पर अपडेट करता है.

Chrome, किसी एक एक्सटेंशन में, मैच होने वाले सभी modifyHeaders नियमों को ढूंढकर, बदलावों की सूची बनाता है. पहले की तरह ही, सिर्फ़ उन नियमों को शामिल किया जाता है जिनकी प्राथमिकता, मैच करने वाले किसी भी allow या allowAllRequests नियम से ज़्यादा हो.

Chrome, इन नियमों को इस क्रम में लागू करता है कि हाल ही में इंस्टॉल किए गए एक्सटेंशन के नियमों का आकलन, पुराने एक्सटेंशन के नियमों से पहले किया जाए. इसके अलावा, किसी एक्सटेंशन के ज़्यादा प्राथमिकता वाले नियम, उसी एक्सटेंशन के कम प्राथमिकता वाले नियमों से पहले हमेशा लागू होते हैं. खास तौर पर, सभी एक्सटेंशन के लिए:

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

जवाब मिलने के बाद

रिस्पॉन्स हेडर मिलने के बाद, Chrome responseHeaders शर्त वाले नियमों का आकलन करता है.

इन नियमों को action और priority के हिसाब से क्रम में लगाने और मैच करने वाले allow या allowAllRequests नियम की वजह से, अमान्य हो चुके नियमों को हटाने के बाद (यह "अनुरोध करने से पहले" में दिए गए चरणों की तरह ही होता है), Chrome किसी एक्सटेंशन की ओर से अनुरोध को ब्लॉक या रीडायरेक्ट कर सकता है.

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

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

अगर अनुरोध को ब्लॉक या रीडायरेक्ट नहीं किया जाता है, तो Chrome कोई भी modifyHeaders नियम लागू करता है. जवाब के हेडर में बदलाव करने का तरीका, "अनुरोध के हेडर भेजे जाने से पहले" में बताए गए तरीके से मिलता-जुलता है. अनुरोध के हेडर में बदलाव करने से कोई फ़र्क़ नहीं पड़ता, क्योंकि अनुरोध पहले ही कर दिया गया है.

सुरक्षित नियम

सुरक्षित नियमों को ऐसे नियमों के तौर पर परिभाषित किया जाता है जिनमें block, allow, allowAllRequests या upgradeScheme की कार्रवाई होती है. ये नियम, डाइनैमिक नियमों के कोटा के हिसाब से तय किए जाते हैं.

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

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

स्टैटिक नियम

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

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

ध्यान दें: Chrome 128 से, अगर कोई उपयोगकर्ता chrome://extensions के ज़रिए किसी एक्सटेंशन को बंद करता है, तो एक्सटेंशन के स्टैटिक नियमों को ग्लोबल स्टैटिक नियम की सीमा में नहीं गिना जाएगा. इससे, अन्य एक्सटेंशन के लिए स्टैटिक नियम का कोटा खाली हो सकता है. हालांकि, इसका यह भी मतलब है कि जब एक्सटेंशन फिर से चालू हो जाएगा, तो हो सकता है कि उसके लिए पहले के मुकाबले कम स्टैटिक नियम उपलब्ध हों.

सेशन के नियम

किसी एक्सटेंशन में ज़्यादा से ज़्यादा 5,000 सेशन नियम हो सकते हैं. इसे MAX_NUMBER_OF_SESSION_RULES के तौर पर दिखाया जाता है.

Chrome 120 से पहले, डाइनैमिक और सेशन नियमों की कुल संख्या 5,000 थी.

डाइनैमिक नियम

किसी एक्सटेंशन में कम से कम 5,000 डाइनैमिक नियम हो सकते हैं. इसे MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES के तौर पर दिखाया जाता है.

Chrome 121 से, सुरक्षित डाइनैमिक नियमों के लिए,30,000 नियमों की ज़्यादा सीमा उपलब्ध है. इन्हें MAX_NUMBER_OF_DYNAMIC_RULES के तौर पर दिखाया जाता है. 5,000 की सीमा के अंदर जोड़े गए असुरक्षित नियम भी इस सीमा में गिने जाएंगे.

Chrome 120 से पहले, डाइनैमिक और सेशन के नियमों की कुल संख्या 5,000 थी.

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

सभी तरह के नियमों में रेगुलर एक्सप्रेशन का इस्तेमाल किया जा सकता है. हालांकि, हर तरह के रेगुलर एक्सप्रेशन नियमों की कुल संख्या 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" कलेक्शन का इस्तेमाल करें.

हेडर में बदलाव करना

जोड़ने की सुविधा सिर्फ़ इन हेडर के लिए काम करती है: accept, accept-encoding, accept-language, access-control-request-headers, cache-control, connection, content-language, cookie, forwarded, if-match, if-none-match, keep-alive, range, te, trailer, transfer-encoding, upgrade, user-agent, via, want-digest, x-forwarded-for.

उदाहरण

कोड के उदाहरण

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

यहां दिए गए उदाहरण में, 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

बूलियन
वजह

UnsupportedRegexReason ज़रूरी नहीं

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

MatchedRule

प्रॉपर्टी

ruleId

संख्या

मैच करने वाले नियम का आईडी.
rulesetId

स्ट्रिंग

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

MatchedRuleInfo

प्रॉपर्टी

नियम

MatchedRule
tabId

संख्या

उस टैब का tabId जिससे अनुरोध शुरू हुआ था. हालांकि, यह ज़रूरी है कि वह टैब अब भी चालू हो. इसके अलावा, -1.
timeStamp

संख्या

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

MatchedRuleInfoDebug

प्रॉपर्टी

CANNOT TRANSLATE

RequestDetails

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

MatchedRule

MatchedRulesFilter

प्रॉपर्टी

minTimeStamp

number ज़रूरी नहीं

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

number ज़रूरी नहीं

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

ModifyHeaderInfo

Chrome 86 और उसके बाद के वर्शन

प्रॉपर्टी

हेडर

स्ट्रिंग

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

HeaderOperation

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

स्ट्रिंग ज़रूरी नहीं

हेडर की नई वैल्यू. append और set ऑपरेशन के लिए, यह तय होना चाहिए.

QueryKeyValue

प्रॉपर्टी

बटन

स्ट्रिंग
replaceOnly

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

Chrome 94 और उसके बाद के वर्शन

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

स्ट्रिंग

QueryTransform

प्रॉपर्टी

addOrReplaceParams

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

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

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

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

Redirect

प्रॉपर्टी

extensionPath

स्ट्रिंग ज़रूरी नहीं

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

स्ट्रिंग ज़रूरी नहीं

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

URLTransform ज़रूरी नहीं

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

स्ट्रिंग ज़रूरी नहीं

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

RegexOptions

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

प्रॉपर्टी

isCaseSensitive

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

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

स्ट्रिंग

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

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

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

RequestDetails

प्रॉपर्टी

documentId

स्ट्रिंग ज़रूरी नहीं

Chrome 106 और उसके बाद के वर्शन

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

DocumentLifecycle ज़रूरी नहीं

Chrome 106 और उसके बाद के वर्शन

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

संख्या

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

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

Chrome 106 और उसके बाद के वर्शन

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

स्ट्रिंग ज़रूरी नहीं

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

स्ट्रिंग

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

स्ट्रिंग ज़रूरी नहीं

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

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

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

"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[] ज़रूरी नहीं है

Chrome 128+

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

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

Chrome 92 और उसके बाद के वर्शन

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

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

Chrome 101 और उसके बाद के वर्शन

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

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

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

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

स्ट्रिंग ज़रूरी नहीं

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

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

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

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

Chrome 101 और उसके बाद के वर्शन

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

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

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

Chrome 91 और उसके बाद के वर्शन

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

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

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

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

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

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

Chrome 128+

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

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

Chrome 92 और उसके बाद के वर्शन

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

स्ट्रिंग ज़रूरी नहीं

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

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

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

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

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

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

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

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

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

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

Ruleset

प्रॉपर्टी

चालू किया गया

बूलियन

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

स्ट्रिंग

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

स्ट्रिंग

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

RulesMatchedDetails

प्रॉपर्टी

rulesMatchedInfo

MatchedRuleInfo[]

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

TabActionCountUpdate

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

प्रॉपर्टी

अधिक

संख्या

टैब के ऐक्शन की संख्या में यह संख्या जोड़ें. नेगेटिव वैल्यू से गिनती कम हो जाएगी.
tabId

संख्या

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

TestMatchOutcomeResult

Chrome 103 और उसके बाद के वर्शन

प्रॉपर्टी

matchedRules

MatchedRule[]

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

TestMatchRequestDetails

Chrome 103 और उसके बाद के वर्शन

प्रॉपर्टी

शुरुआत करने वाला

स्ट्रिंग ज़रूरी नहीं

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

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

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

ऑब्जेक्ट ज़रूरी नहीं है

Chrome 129 और उसके बाद के वर्शन

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

number ज़रूरी नहीं

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

ResourceType

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

स्ट्रिंग

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

UnsupportedRegexReason

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

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

Enum

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

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

UpdateRuleOptions

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

प्रॉपर्टी

addRules

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

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

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

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

UpdateRulesetOptions

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

प्रॉपर्टी

disableRulesetIds

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

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

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

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

UpdateStaticRulesOptions

Chrome 111 और उसके बाद के वर्शन

प्रॉपर्टी

disableRuleIds

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

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

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

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

स्ट्रिंग

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

URLTransform

प्रॉपर्टी

फ़्रैगमेंट

स्ट्रिंग ज़रूरी नहीं

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

स्ट्रिंग ज़रूरी नहीं

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

स्ट्रिंग ज़रूरी नहीं

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

स्ट्रिंग ज़रूरी नहीं

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

स्ट्रिंग ज़रूरी नहीं

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

स्ट्रिंग ज़रूरी नहीं

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

QueryTransform ज़रूरी नहीं

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

स्ट्रिंग ज़रूरी नहीं

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

स्ट्रिंग ज़रूरी नहीं

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

प्रॉपर्टी

DYNAMIC_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,
)

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

पैरामीटर

कॉलबैक

फ़ंक्शन ज़रूरी नहीं

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

रिटर्न

Promise<number>

Chrome 91 और उसके बाद के वर्शन

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

getDisabledRuleIds()

Promise Chrome 111 और उसके बाद के वर्शन के लिए

chrome.declarativeNetRequest.getDisabledRuleIds(
  options: GetDisabledRuleIdsOptions,
  callback?: function,
)

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

पैरामीटर

विकल्प

GetDisabledRuleIdsOptions

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

फ़ंक्शन ज़रूरी नहीं

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

रिटर्न

Promise<number[]>

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

getDynamicRules()

वादा करना

chrome.declarativeNetRequest.getDynamicRules(
  filter?: GetRulesFilter,
  callback?: function,
)

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

पैरामीटर

फ़िल्टर करें

GetRulesFilter ज़रूरी नहीं

Chrome 111 और उसके बाद के वर्शन

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

फ़ंक्शन ज़रूरी नहीं

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

रिटर्न

Promise<Rule[]>

Chrome 91 और उसके बाद के वर्शन

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

getEnabledRulesets()

वादा करना

chrome.declarativeNetRequest.getEnabledRulesets(
  callback?: function,
)

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

पैरामीटर

कॉलबैक

फ़ंक्शन ज़रूरी नहीं

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

रिटर्न

Promise<string[]>

Chrome 91 और उसके बाद के वर्शन

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

getMatchedRules()

वादा करना

chrome.declarativeNetRequest.getMatchedRules(
  filter?: MatchedRulesFilter,
  callback?: function,
)

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

पैरामीटर

फ़िल्टर करें

MatchedRulesFilter ज़रूरी नहीं

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

फ़ंक्शन ज़रूरी नहीं

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

रिटर्न

Promise<RulesMatchedDetails>

Chrome 91 और उसके बाद के वर्शन

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

getSessionRules()

Promise Chrome 90+

chrome.declarativeNetRequest.getSessionRules(
  filter?: GetRulesFilter,
  callback?: function,
)

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

पैरामीटर

फ़िल्टर करें

GetRulesFilter ज़रूरी नहीं

Chrome 111 और उसके बाद के वर्शन

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

फ़ंक्शन ज़रूरी नहीं

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

रिटर्न

Promise<Rule[]>

Chrome 91 और उसके बाद के वर्शन

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

isRegexSupported()

Promise Chrome 87 और उसके बाद के वर्शन के लिए

chrome.declarativeNetRequest.isRegexSupported(
  regexOptions: RegexOptions,
  callback?: function,
)

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

पैरामीटर

regexOptions

RegexOptions

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

फ़ंक्शन ज़रूरी नहीं

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

रिटर्न

Promise<IsRegexSupportedResult>

Chrome 91 और उसके बाद के वर्शन

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

setExtensionActionOptions()

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

chrome.declarativeNetRequest.setExtensionActionOptions(
  options: ExtensionActionOptions,
  callback?: function,
)

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

पैरामीटर

विकल्प

ExtensionActionOptions
कॉलबैक

फ़ंक्शन ज़रूरी नहीं

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

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

रिटर्न

Promise<void>

Chrome 91 और उसके बाद के वर्शन

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

testMatchOutcome()

Promise Chrome 103 और उसके बाद के वर्शन के लिए

chrome.declarativeNetRequest.testMatchOutcome(
  request: TestMatchRequestDetails,
  callback?: function,
)

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

पैरामीटर

CANNOT TRANSLATE

TestMatchRequestDetails
कॉलबैक

फ़ंक्शन ज़रूरी नहीं

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

रिटर्न

Promise<TestMatchOutcomeResult>

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

updateDynamicRules()

वादा करना

chrome.declarativeNetRequest.updateDynamicRules(
  options: UpdateRuleOptions,
  callback?: function,
)

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

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

पैरामीटर

विकल्प

UpdateRuleOptions

Chrome 87 और उसके बाद के वर्शन
कॉलबैक

फ़ंक्शन ज़रूरी नहीं

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

रिटर्न

Promise<void>

Chrome 91 और उसके बाद के वर्शन

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

updateEnabledRulesets()

वादा करना

chrome.declarativeNetRequest.updateEnabledRulesets(
  options: UpdateRulesetOptions,
  callback?: function,
)

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

पैरामीटर

विकल्प

UpdateRulesetOptions

Chrome 87 और उसके बाद के वर्शन
कॉलबैक

फ़ंक्शन ज़रूरी नहीं

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

रिटर्न

Promise<void>

Chrome 91 और उसके बाद के वर्शन

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

updateSessionRules()

Promise Chrome 90+

chrome.declarativeNetRequest.updateSessionRules(
  options: UpdateRuleOptions,
  callback?: function,
)

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

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

पैरामीटर

विकल्प

UpdateRuleOptions
कॉलबैक

फ़ंक्शन ज़रूरी नहीं

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

रिटर्न

Promise<void>

Chrome 91 और उसके बाद के वर्शन

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

updateStaticRules()

Promise Chrome 111 और उसके बाद के वर्शन के लिए

chrome.declarativeNetRequest.updateStaticRules(
  options: UpdateStaticRulesOptions,
  callback?: function,
)

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

पैरामीटर

विकल्प

UpdateStaticRulesOptions
कॉलबैक

फ़ंक्शन ज़रूरी नहीं

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

रिटर्न

Promise<void>

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

इवेंट

onRuleMatchedDebug

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

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

पैरामीटर

कॉलबैक

फ़ंक्शन

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