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/*"
  ],
  ...
}

नियम और रूलसेट

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

  • नेटवर्क अनुरोध को ब्लॉक करें.
  • स्कीमा को http से https में अपग्रेड करें.
  • किसी भी अनुरोध को ब्लॉक होने से रोकें. इसके लिए, ब्लॉक किए गए मिलते-जुलते नियमों को नज़रअंदाज़ करें.
  • नेटवर्क अनुरोध को रीडायरेक्ट करना.
  • अनुरोध या रिस्पॉन्स हेडर में बदलाव करें.

नियम सेट तीन तरह के होते हैं, जिन्हें अलग-अलग तरीकों से मैनेज किया जाता है.

डाइनैमिक
सभी ब्राउज़र सेशन और एक्सटेंशन अपग्रेड पर काम करता है. साथ ही, एक्सटेंशन के इस्तेमाल के दौरान उसे 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 बंद की जा सकती है.

स्टैटिक नियमसेट चालू या बंद करने के लिए, 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() पर कॉल करके, रनटाइम के दौरान यह नंबर ढूंढा जा सकता है. कोड के उदाहरण में जाकर, इसका उदाहरण देखा जा सकता है.

सेशन के नियम

किसी एक्सटेंशन में, ज़्यादा से ज़्यादा 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 किसी एक्सटेंशन में नियमों को कैसे प्राथमिकता देता है. इनकी समीक्षा करते समय, हो सकता है कि आप प्राथमिकता नियमों को एक अलग विंडो में खोलना चाहें.

"प्राथमिकता" बटन

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

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

https://google.com पर जाने के लिए नेविगेशन
इस यूआरएल में दो नियम हैं: आईडी 1 और 4 वाले नियम. आईडी 1 वाला नियम लागू होता है, क्योंकि "redirect" कार्रवाइयों के मुकाबले "block" कार्रवाइयों को ज़्यादा प्राथमिकता मिलती है. बाकी नियम लागू नहीं होते, क्योंकि वे लंबे यूआरएल के लिए होते हैं.
https://google.com/1234 पर नेविगेट करें
ज़्यादा लंबा यूआरएल होने की वजह से, अब आईडी 2 वाला नियम, आईडी 1 और 4 वाले नियमों के साथ-साथ मेल खाता है. आईडी 2 वाला नियम लागू होता है, क्योंकि "block" और "redirect" के मुकाबले "allow" की प्राथमिकता ज़्यादा है.
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"
नेटवर्क अनुरोध उस फ़्रेम का पहला पक्ष है जिसमें यह शुरू हुआ था.

"तीसरा पक्ष"
नेटवर्क अनुरोध जिस फ़्रेम से मिला है उसका तीसरा पक्ष है.

ExtensionActionOptions

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

प्रॉपर्टी

  • displayActionCountAsBadgeText

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

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

  • tabUpdate

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

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

    इस बारे में जानकारी कि टैब में की जाने वाली कार्रवाइयों की संख्या को कैसे अडजस्ट करना है.

GetDisabledRuleIdsOptions

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

प्रॉपर्टी

  • rulesetId

    स्ट्रिंग

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

GetRulesFilter

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

प्रॉपर्टी

  • ruleIds

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

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

HeaderInfo

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

प्रॉपर्टी

  • excludedValues

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

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

  • हेडर

    स्ट्रिंग

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

  • मान

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

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

    '*' : जितने चाहें उतने वर्णों से मेल खाता है.

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

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

HeaderOperation

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

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

Enum

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

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

"हटाएं"
खास हेडर के लिए सभी एंट्री हटा देता है.

IsRegexSupportedResult

Chrome 87+

प्रॉपर्टी

  • isSupported

    बूलियन

  • कारण

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

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

MatchedRule

प्रॉपर्टी

  • ruleId

    संख्या

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

  • rulesetId

    स्ट्रिंग

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

MatchedRuleInfo

प्रॉपर्टी

  • नियम

    MatchedRule

  • tabId

    संख्या

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

  • timeStamp

    संख्या

    नियम के मेल खाने का समय. टाइमस्टैंप, समय के लिए JavaScript के तौर-तरीकों के मुताबिक होंगे. जैसे, Epoch के बाद के मिलीसेकंड की संख्या.

MatchedRuleInfoDebug

प्रॉपर्टी

  • CANNOT TRANSLATE

    RequestDetails

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

  • नियम

    MatchedRule

MatchedRulesFilter

प्रॉपर्टी

  • minTimeStamp

    नंबर वैकल्पिक

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

  • tabId

    नंबर वैकल्पिक

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

ModifyHeaderInfo

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

प्रॉपर्टी

  • हेडर

    स्ट्रिंग

    हेडर का नाम, जिसमें बदलाव किया जाना है.

  • कार्रवाई

    HeaderOperation

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

  • value

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

    हेडर के लिए नई वैल्यू. append और set कार्रवाइयों के लिए बताया जाना चाहिए.

QueryKeyValue

प्रॉपर्टी

  • बटन

    स्ट्रिंग

  • replaceOnly

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

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

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

  • value

    स्ट्रिंग

QueryTransform

प्रॉपर्टी

  • addOrReplaceParams

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

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

  • removeParams

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

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

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 और उसके बाद वाले वर्शन

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

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

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

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

  • तरीका

    स्ट्रिंग

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

  • parentDocumentId

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

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

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

  • parentFrameId

    संख्या

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

  • requestId

    स्ट्रिंग

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

  • tabId

    संख्या

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

  • टाइप

    ResourceType

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

  • url

    स्ट्रिंग

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

RequestMethod

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

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

Enum

"कनेक्ट करें"

"मिटाएं"

"get"

"head"

"विकल्प"

"पैच"

"पोस्ट"

"पुट"

"अन्य"

ResourceType

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

Enum

"main_frame"

"sub_frame"

"स्टाइलशीट"

"script"

"इमेज"

"font"

"object"

"xmlhttprequest"

"पिंग"

"csp_report"

"मीडिया"

"websocket"

"वेबट्रांसपोर्ट"

"वेबबंडल"

"अन्य"

Rule

प्रॉपर्टी

  • ऐक्शन गेम

    RuleAction

    इस नियम के मेल खाने पर की जाने वाली कार्रवाई.

  • स्थिति

    RuleCondition

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

  • आईडी

    संख्या

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

  • प्राथमिकता

    नंबर वैकल्पिक

    नियम की प्राथमिकता. डिफ़ॉल्ट तौर पर, यह वैल्यू 1 पर सेट होती है. इसका मतलब है कि वैल्यू >= 1 होनी चाहिए.

RuleAction

प्रॉपर्टी

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

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

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

  • requestHeaders

    ModifyHeaderInfo[] वैकल्पिक

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

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

  • responseHeaders

    ModifyHeaderInfo[] वैकल्पिक

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

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

  • टाइप

    RuleActionType

    की जाने वाली कार्रवाई का टाइप.

RuleActionType

यह बताता है कि किसी RuleCondition का मिलान होने पर, किस तरह की कार्रवाई की जानी चाहिए.

Enum

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

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

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

"अपग्रेडScheme"
अगर अनुरोध http या ftp है, तो नेटवर्क अनुरोध यूआरएल की स्कीम को https में अपग्रेड करें.

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

"allowAllRequests"
फ़्रेम अनुरोध के साथ-साथ, फ़्रेम की हैरारकी में सभी अनुरोधों को अनुमति दें.

RuleCondition

प्रॉपर्टी

  • domainType

    DomainType ज़रूरी नहीं

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

  • डोमेन

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

    Chrome 101 के बाद से अब तक काम नहीं करता

    इसके बजाय, initiatorDomains का इस्तेमाल करें

    यह नियम सिर्फ़ domains की सूची से मिलने वाले नेटवर्क अनुरोधों का मिलान करेगा.

  • excludedDomains

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

    Chrome 101 के बाद से अब तक काम नहीं करता

    इसके बजाय, excludedInitiatorDomains का इस्तेमाल करें

    यह नियम, excludedDomains की सूची से मिलने वाले नेटवर्क अनुरोधों का मिलान नहीं करेगा.

  • excludedInitiatorDomains

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

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

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

    ध्यान दें:

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

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

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

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

    ध्यान दें:

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

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

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

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

  • excludedResourceTypes

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

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

  • excludedResponseHeaders

    HeaderInfo[] वैकल्पिक

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

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

  • excludedTabIds

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

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

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

  • initiatorDomains

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

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

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

    ध्यान दें:

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

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

    urlFilter या regexFilter (जो भी बताया गया हो) केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) है. डिफ़ॉल्ट रूप से गलत पर सेट होती है.

  • regexFilter

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

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

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

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

  • requestDomains

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

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

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

    ध्यान दें:

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

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

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

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

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

  • resourceTypes

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

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

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

  • responseHeaders

    HeaderInfo[] वैकल्पिक

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

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

  • tabIds

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

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

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

  • urlFilter

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

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

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

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

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

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

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

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

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

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

    ध्यान दें: urlFilter में सिर्फ़ ASCII वर्ण होने चाहिए. इसका मिलान ऐसे यूआरएल से किया जाता है जहां होस्ट को punycode फ़ॉर्मैट में एन्कोड किया जाता है (अंतरराष्ट्रीय डोमेन के मामले में) और बिना ASCII वाले दूसरे वर्ण, यूआरएल को utf-8 में एन्कोड करते हैं. उदाहरण के लिए, जब अनुरोध करने के लिए यूआरएल http://abc.टेरफ़ो?क्यू=एफ़एम है, तो 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 ज़रूरी नहीं

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

  • responseHeaders

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

    मंज़ूरी बाकी है

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

  • tabId

    नंबर वैकल्पिक

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

  • टाइप

    ResourceType

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

  • url

    स्ट्रिंग

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

UnsupportedRegexReason

Chrome 87+

किसी रेगुलर एक्सप्रेशन के काम न करने की वजह बताता है.

Enum

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

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

UpdateRuleOptions

Chrome 87+

प्रॉपर्टी

  • addRules

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

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

  • removeRuleIds

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

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

UpdateRulesetOptions

Chrome 87+

प्रॉपर्टी

  • disableRulesetIds

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

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

  • enableRulesetIds

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

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

UpdateStaticRulesOptions

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

प्रॉपर्टी

  • disableRuleIds

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

    Ruleset में नियमों के मुताबिक आईडी का सेट बंद किया जाना है.

  • enableRuleIds

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

    चालू करने के लिए, Ruleset के नियमों के हिसाब से आईडी का सेट.

  • rulesetId

    स्ट्रिंग

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

URLTransform

प्रॉपर्टी

  • फ़्रैगमेंट

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

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

  • होस्ट

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

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

  • पासवर्ड

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

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

  • पाथ

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

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

  • पोर्ट

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

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

  • क्वेरी

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

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

  • queryTransform

    QueryTransform ज़रूरी नहीं

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

  • स्कीम

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

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

  • उपयोगकर्ता नाम

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

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

प्रॉपर्टी

DYNAMIC_RULESET_ID

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

मान

"_डाइनैमिक"

GETMATCHEDRULES_QUOTA_INTERVAL

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

मान

10

GUARANTEED_MINIMUM_STATIC_RULES

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

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

मान

30,000

MAX_GETMATCHEDRULES_CALLS_PER_INTERVAL

GETMATCHEDRULES_QUOTA_INTERVAL के दौरान getMatchedRules को कितनी बार कॉल किया जा सकता है.

मान

20

MAX_NUMBER_OF_DYNAMIC_RULES

किसी एक्सटेंशन के ज़रिए जोड़े जा सकने वाले डाइनैमिक नियमों की ज़्यादा से ज़्यादा संख्या.

मान

30,000

MAX_NUMBER_OF_ENABLED_STATIC_RULESETS

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

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

मान

50

MAX_NUMBER_OF_REGEX_RULES

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

मान

1,000

MAX_NUMBER_OF_SESSION_RULES

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

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

मान

5,000

MAX_NUMBER_OF_STATIC_RULESETS

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

मान

100

MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES

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

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

मान

5,000

MAX_NUMBER_OF_UNSAFE_SESSION_RULES

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

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

मान

5,000

SESSION_RULESET_ID

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

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

मान

"_session"

तरीके

getAvailableStaticRuleCount()

प्रॉमिस Chrome 89 या इसके बाद के वर्शन पर 
chrome.declarativeNetRequest.getAvailableStaticRuleCount(
  callback?: function,
)

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

पैरामीटर

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    (count: number) => void

    • सोलर पैनलों की संख्या

      संख्या

रिटर्न

  • Promise<number>

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

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

getDisabledRuleIds()

प्रॉमिस Chrome 111 और उसके बाद वाले वर्शन के लिए 
chrome.declarativeNetRequest.getDisabledRuleIds(
  options: GetDisabledRuleIdsOptions,
  callback?: function,
)

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

पैरामीटर

  • विकल्प

    GetDisabledRuleIdsOptions

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

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    (disabledRuleIds: number[]) => void

    • disabledRuleIds

      नंबर[]

रिटर्न

  • प्रॉमिस<number[]>

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

getDynamicRules()

प्रॉमिस 
chrome.declarativeNetRequest.getDynamicRules(
  filter?: GetRulesFilter,
  callback?: function,
)

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

पैरामीटर

  • फ़िल्टर करें

    GetRulesFilter ज़रूरी नहीं

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

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

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    (rules: Rule[]) => void

रिटर्न

  • वादा<नियम[]>

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

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

getEnabledRulesets()

प्रॉमिस 
chrome.declarativeNetRequest.getEnabledRulesets(
  callback?: function,
)

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

पैरामीटर

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    (rulesetIds: string[]) => void

    • rulesetIds

      स्ट्रिंग[]

रिटर्न

  • Promise&lt;string[]&gt;

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

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

getMatchedRules()

प्रॉमिस 
chrome.declarativeNetRequest.getMatchedRules(
  filter?: MatchedRulesFilter,
  callback?: function,
)

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

पैरामीटर

  • फ़िल्टर करें

    MatchedRulesFilter ज़रूरी नहीं

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

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    (details: RulesMatchedDetails) => void

रिटर्न

  • Promise&lt;RulesMatchedDetails&gt;

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

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

getSessionRules()

प्रॉमिस Chrome 90 और उसके बाद वाले वर्शन के लिए 
chrome.declarativeNetRequest.getSessionRules(
  filter?: GetRulesFilter,
  callback?: function,
)

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

पैरामीटर

  • फ़िल्टर करें

    GetRulesFilter ज़रूरी नहीं

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

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

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    (rules: Rule[]) => void

रिटर्न

  • वादा<नियम[]>

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

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

isRegexSupported()

प्रॉमिस Chrome 87 और उसके बाद वाले वर्शन के लिए 
chrome.declarativeNetRequest.isRegexSupported(
  regexOptions: RegexOptions,
  callback?: function,
)

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

पैरामीटर

  • regexOptions

    RegexOptions

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

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    (result: IsRegexSupportedResult) => void

रिटर्न

  • Promise&lt;IsRegexSupportedResult&gt;

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

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

setExtensionActionOptions()

प्रॉमिस Chrome 88 और उसके बाद वाले वर्शन के लिए 
chrome.declarativeNetRequest.setExtensionActionOptions(
  options: ExtensionActionOptions,
  callback?: function,
)

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

पैरामीटर

  • विकल्प

    ExtensionActionOptions

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

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

    callback पैरामीटर ऐसा दिखता है: 

    () => void

रिटर्न

  • प्रॉमिस<void>

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

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

testMatchOutcome()

प्रॉमिस Chrome 103 और उसके बाद वाले वर्शन के लिए 
chrome.declarativeNetRequest.testMatchOutcome(
  request: TestMatchRequestDetails,
  callback?: function,
)

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

पैरामीटर

रिटर्न

  • Promise&lt;TestMatchOutcomeResult&gt;

    मेनिफ़ेस्ट 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

रिटर्न

  • प्रॉमिस<void>

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

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

updateEnabledRulesets()

प्रॉमिस 
chrome.declarativeNetRequest.updateEnabledRulesets(
  options: UpdateRulesetOptions,
  callback?: function,
)

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

पैरामीटर

  • विकल्प

    UpdateRulesetOptions

    Chrome 87+
  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    () => void

रिटर्न

  • प्रॉमिस<void>

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

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

updateSessionRules()

प्रॉमिस Chrome 90 और उसके बाद वाले वर्शन के लिए 
chrome.declarativeNetRequest.updateSessionRules(
  options: UpdateRuleOptions,
  callback?: function,
)

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

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

पैरामीटर

  • विकल्प

    UpdateRuleOptions

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    () => void

रिटर्न

  • प्रॉमिस<void>

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

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

updateStaticRules()

प्रॉमिस Chrome 111 और उसके बाद वाले वर्शन के लिए 
chrome.declarativeNetRequest.updateStaticRules(
  options: UpdateStaticRulesOptions,
  callback?: function,
)

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

पैरामीटर

  • विकल्प

    UpdateStaticRulesOptions

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    () => void

रिटर्न

  • प्रॉमिस<void>

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

इवेंट

onRuleMatchedDebug

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

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

पैरामीटर