chrome.declarativeNetRequest

ब्यौरा

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

अनुमतियां

declarativeNetRequest
declarativeNetRequestWithHostAccess

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

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

उपलब्धता

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

मेनिफ़ेस्ट

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

{
  "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 के हिसाब से क्रम में लगाने के बाद, Chrome उन नियमों को हटा सकता है जो allow या allowAllRequests से मिलते-जुलते हैं. ऐसा "अनुरोध से पहले" सेक्शन में बताए गए चरणों के हिसाब से होता है. इसके बाद, Chrome किसी एक्सटेंशन की ओर से किए गए अनुरोध को ब्लॉक कर सकता है या उसे रीडायरेक्ट कर सकता है.

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

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

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

सुरक्षा के नियम

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

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

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

स्टैटिक नियम

स्टैटिक नियम वे होते हैं जो मेनिफ़ेस्ट फ़ाइल में बताए गए नियम वाली फ़ाइलों में तय किए जाते हैं. कोई एक्सटेंशन, "rule_resources" मेनिफ़ेस्ट कुंजी के हिस्से के तौर पर ज़्यादा से ज़्यादा 100 स्टैटिक ruleset तय कर सकता है. हालांकि, इनमें से सिर्फ़ 50 ruleset एक बार में चालू किए जा सकते हैं. बाद वाले को 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. यह अनुमति वाली सूची, केस-सेंसिटिव (बग 449152902) होती है.

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

उदाहरण

कोड के उदाहरण

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

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

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

{
  "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[] optional

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

HeaderInfo

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

प्रॉपर्टी

excludedValues

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

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

स्ट्रिंग

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

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

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

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

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

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

HeaderOperation

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

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

Enum

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

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

"remove"
इससे तय किए गए हेडर की सभी एंट्री हट जाती हैं.

IsRegexSupportedResult

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

प्रॉपर्टी

isSupported

बूलियन
वजह

UnsupportedRegexReason optional

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

MatchedRule

प्रॉपर्टी

ruleId

संख्या

मेल खाने वाले नियम का आईडी.
rulesetId

स्ट्रिंग

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

MatchedRuleInfo

प्रॉपर्टी

नियम

MatchedRule
tabId

संख्या

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

संख्या

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

MatchedRuleInfoDebug

प्रॉपर्टी

CANNOT TRANSLATE

RequestDetails

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

MatchedRule

MatchedRulesFilter

प्रॉपर्टी

minTimeStamp

number ज़रूरी नहीं

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

number ज़रूरी नहीं

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

ModifyHeaderInfo

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

प्रॉपर्टी

हेडर

स्ट्रिंग

बदलाव किए जाने वाले हेडर का नाम.
कार्रवाई

HeaderOperation

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

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

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

QueryKeyValue

प्रॉपर्टी

बटन

स्ट्रिंग
replaceOnly

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

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

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

स्ट्रिंग

QueryTransform

प्रॉपर्टी

addOrReplaceParams

QueryKeyValue[] optional

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

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

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

Redirect

प्रॉपर्टी

extensionPath

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

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

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

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

URLTransform optional

यूआरएल में किए जाने वाले ट्रांसफ़ॉर्मेशन.
url

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

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

RegexOptions

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

प्रॉपर्टी

isCaseSensitive

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

regex में दिए गए टेक्स्ट में बड़े और छोटे अक्षरों का अंतर मायने रखता है या नहीं. यह डिफ़ॉल्ट रूप से 'सही' पर सेट होती है.
रेगुलर एक्सप्रेशन

स्ट्रिंग

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

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

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

RequestDetails

प्रॉपर्टी

documentId

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

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

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

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

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

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

संख्या

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

FrameType optional

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

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

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

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

स्ट्रिंग

यह एक स्टैंडर्ड एचटीटीपी मेथड है.
parentDocumentId

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

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

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

संख्या

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

स्ट्रिंग

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

संख्या

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

ResourceType

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

स्ट्रिंग

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

RequestMethod

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

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

Enum

"connect"

"delete"

"get"

"head"

"options"

"patch"

"post"

"put"

"other"

ResourceType

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

Enum

"main_frame"

"sub_frame"

"stylesheet"

"script"

"image"

"font"

"object"

"xmlhttprequest"

"ping"

"csp_report"

"media"

"websocket"

"webtransport"

"webbundle"

"other"

Rule

प्रॉपर्टी

ऐक्शन गेम

RuleAction

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

RuleCondition

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

संख्या

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

number ज़रूरी नहीं

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

RuleAction

प्रॉपर्टी

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

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

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

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

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

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

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

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

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

RuleActionType

कार्रवाई किस तरह की है.

RuleActionType

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

Enum

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

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

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

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

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

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

RuleCondition

प्रॉपर्टी

domainType

DomainType optional

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

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[] optional

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

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

ResourceType[] optional

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

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

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

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

number[] optional

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RequestMethod[] optional

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

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

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

ResourceType[] optional

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

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

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

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

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

number[] optional

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RuleConditionKeys

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

Enum

"urlFilter"

"regexFilter"

"isUrlFilterCaseSensitive"

"initiatorDomains"

"excludedInitiatorDomains"

"requestDomains"

"excludedRequestDomains"

"topDomains"

"excludedTopDomains"

"domains"

"excludedDomains"

"resourceTypes"

"excludedResourceTypes"

"requestMethods"

"excludedRequestMethods"

"domainType"

"tabIds"

"excludedTabIds"

"responseHeaders"

"excludedResponseHeaders"

Ruleset

प्रॉपर्टी

चालू किया गया

बूलियन

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

स्ट्रिंग

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

स्ट्रिंग

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

RulesMatchedDetails

प्रॉपर्टी

rulesMatchedInfo

MatchedRuleInfo[]

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

TabActionCountUpdate

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

प्रॉपर्टी

अधिक

संख्या

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

संख्या

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

TestMatchOutcomeResult

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

प्रॉपर्टी

matchedRules

MatchedRule[]

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

TestMatchRequestDetails

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

प्रॉपर्टी

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

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

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

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

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

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

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

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

number ज़रूरी नहीं

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

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

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

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

ResourceType

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

स्ट्रिंग

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

UnsupportedRegexReason

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

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

Enum

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

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

UpdateRuleOptions

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

प्रॉपर्टी

addRules

Rule[] optional

जोड़ने के लिए नियम.
removeRuleIds

number[] optional

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

UpdateRulesetOptions

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

प्रॉपर्टी

disableRulesetIds

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

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

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

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

UpdateStaticRulesOptions

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

प्रॉपर्टी

disableRuleIds

number[] optional

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

number[] optional

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

स्ट्रिंग

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

URLTransform

प्रॉपर्टी

फ़्रैगमेंट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

प्रॉपर्टी

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()

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

chrome.declarativeNetRequest.getAvailableStaticRuleCount(): Promise<number>

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

रिटर्न

Promise<number>

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

getDisabledRuleIds()

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

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

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

पैरामीटर

विकल्प

GetDisabledRuleIdsOptions

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

रिटर्न

Promise<number[]>

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

getDynamicRules()

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

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

पैरामीटर

फ़िल्टर करें

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

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

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

रिटर्न

Promise<Rule[]>

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

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

getEnabledRulesets()

chrome.declarativeNetRequest.getEnabledRulesets(): Promise<string[]>

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

रिटर्न

Promise<string[]>

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

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

getMatchedRules()

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

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

पैरामीटर

फ़िल्टर करें

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

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

रिटर्न

Promise<RulesMatchedDetails>

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

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

getSessionRules()

Chrome 90+

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

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

पैरामीटर

फ़िल्टर करें

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

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

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

रिटर्न

Promise<Rule[]>

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

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

isRegexSupported()

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

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

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

पैरामीटर

regexOptions

RegexOptions

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

रिटर्न

Promise<IsRegexSupportedResult>

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

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

setExtensionActionOptions()

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

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

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

पैरामीटर

विकल्प

ExtensionActionOptions

रिटर्न

Promise<void>

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

testMatchOutcome()

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

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

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

पैरामीटर

CANNOT TRANSLATE

TestMatchRequestDetails

रिटर्न

Promise<TestMatchOutcomeResult>

यह प्रॉमिस, मैच किए गए नियमों की जानकारी के साथ पूरा होता है.

updateDynamicRules()

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

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

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

पैरामीटर

विकल्प

UpdateRuleOptions

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

रिटर्न

Promise<void>

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

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

updateEnabledRulesets()

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

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

पैरामीटर

विकल्प

UpdateRulesetOptions

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

रिटर्न

Promise<void>

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

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

updateSessionRules()

Chrome 90+

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

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

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

पैरामीटर

विकल्प

UpdateRuleOptions

रिटर्न

Promise<void>

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

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

updateStaticRules()

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

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

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

पैरामीटर

विकल्प

UpdateStaticRulesOptions

रिटर्न

Promise<void>

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

इवेंट

onRuleMatchedDebug

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

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

पैरामीटर

कॉलबैक

फ़ंक्शन

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