chrome.declarativeNetRequest (original) (raw)

सीधे मुख्य कॉन्टेंट पर जाएं

ब्यौरा

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

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

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

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

डाइनैमिक

ये ब्राउज़र सेशन और एक्सटेंशन अपग्रेड के दौरान बने रहते हैं. साथ ही, एक्सटेंशन का इस्तेमाल करते समय इन्हें 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.comhttps://example.com/abcd https://ab.com
"abc*d" https://abcd.comhttps://example.com/abcxyzd https://abc.com
"| a.example.com" https://a.example.com/https://b.a.example.com/xyzhttps://a.example.company
"|https*" https://example.com http://example.com/http://https.com
"example*^123|" https://example.com/123http://abc.com/example?123 https://example.com/1234https://abc.com/example0123

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

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

यूआरएल के लिए अच्छी शर्तें लिखना

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

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

इसी तरह, रेगुलर एक्सप्रेशन को ऐंकर करने के लिए ^ और / वर्णों का इस्तेमाल करें. उदाहरण के लिए, ^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() को कॉल करके, रनटाइम के दौरान इस नंबर का पता लगाया जा सकता है. कोड के उदाहरण में जाकर, इसका उदाहरण देखा जा सकता है.

सेशन के नियम

किसी एक्सटेंशन में ज़्यादा से ज़्यादा 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) उस फ़्रेम के डोमेन (eTLD+1) से मेल खाता हो जिसमें अनुरोध किया गया था.

Enum

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

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

ExtensionActionOptions

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

प्रॉपर्टी

GetDisabledRuleIdsOptions

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

प्रॉपर्टी

GetRulesFilter

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

प्रॉपर्टी

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

प्रॉपर्टी

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

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

Enum

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

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

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

IsRegexSupportedResult

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

प्रॉपर्टी

MatchedRule

प्रॉपर्टी

MatchedRuleInfo

प्रॉपर्टी

MatchedRuleInfoDebug

प्रॉपर्टी

MatchedRulesFilter

प्रॉपर्टी

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

प्रॉपर्टी

QueryKeyValue

प्रॉपर्टी

QueryTransform

प्रॉपर्टी

Redirect

प्रॉपर्टी

RegexOptions

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

प्रॉपर्टी

RequestDetails

प्रॉपर्टी

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

प्रॉपर्टी

RuleActionType

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

Enum

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

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

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

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

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

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

RuleCondition

प्रॉपर्टी

RuleConditionKeys

Enum

"urlFilter"

"regexFilter"

"isUrlFilterCaseSensitive"

"initiatorDomains"

"excludedInitiatorDomains"

"requestDomains"

"excludedRequestDomains"

"topDomains"

"excludedTopDomains"

"domains"

"excludedDomains"

"resourceTypes"

"excludedResourceTypes"

"requestMethods"

"excludedRequestMethods"

"domainType"

"tabIds"

"excludedTabIds"

"responseHeaders"

"excludedResponseHeaders"

Ruleset

प्रॉपर्टी

RulesMatchedDetails

प्रॉपर्टी

TabActionCountUpdate

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

प्रॉपर्टी

TestMatchOutcomeResult

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

प्रॉपर्टी

TestMatchRequestDetails

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

प्रॉपर्टी

UnsupportedRegexReason

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

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

Enum

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

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

UpdateRuleOptions

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

प्रॉपर्टी

UpdateRulesetOptions

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

प्रॉपर्टी

UpdateStaticRulesOptions

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

प्रॉपर्टी

URLTransform

प्रॉपर्टी

प्रॉपर्टी

DYNAMIC_RULESET_ID

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

GETMATCHEDRULES_QUOTA_INTERVAL

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

GUARANTEED_MINIMUM_STATIC_RULES

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

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

MAX_GETMATCHEDRULES_CALLS_PER_INTERVAL

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

MAX_NUMBER_OF_DYNAMIC_RULES

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

MAX_NUMBER_OF_ENABLED_STATIC_RULESETS

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

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

MAX_NUMBER_OF_REGEX_RULES

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

MAX_NUMBER_OF_SESSION_RULES

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

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

MAX_NUMBER_OF_STATIC_RULESETS

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

MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES

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

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

MAX_NUMBER_OF_UNSAFE_SESSION_RULES

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

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

SESSION_RULESET_ID

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

तरीके

getAvailableStaticRuleCount()

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

chrome.declarativeNetRequest.getAvailableStaticRuleCount(): Promise

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

रिटर्न

getDisabledRuleIds()

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

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

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

पैरामीटर

रिटर्न

getDynamicRules()

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

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

पैरामीटर

रिटर्न

getEnabledRulesets()

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

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

रिटर्न

getMatchedRules()

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

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

पैरामीटर

रिटर्न

getSessionRules()

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

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

पैरामीटर

रिटर्न

isRegexSupported()

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

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

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

पैरामीटर

रिटर्न

setExtensionActionOptions()

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

chrome.declarativeNetRequest.setExtensionActionOptions(
  options: ExtensionActionOptions,
): Promise

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

पैरामीटर

रिटर्न

testMatchOutcome()

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

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

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

पैरामीटर

रिटर्न

updateDynamicRules()

chrome.declarativeNetRequest.updateDynamicRules(
  options: UpdateRuleOptions,
): Promise

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

पैरामीटर

रिटर्न

updateEnabledRulesets()

chrome.declarativeNetRequest.updateEnabledRulesets(
  options: UpdateRulesetOptions,
): Promise

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

पैरामीटर

रिटर्न

updateSessionRules()

chrome.declarativeNetRequest.updateSessionRules(
  options: UpdateRuleOptions,
): Promise

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

पैरामीटर

रिटर्न

updateStaticRules()

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

chrome.declarativeNetRequest.updateStaticRules(
  options: UpdateStaticRulesOptions,
): Promise

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

पैरामीटर

रिटर्न

इवेंट

onRuleMatchedDebug

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

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

पैरामीटर

जब तक कुछ अलग से न बताया जाए, तब तक इस पेज की सामग्री को Creative Commons Attribution 4.0 License के तहत और कोड के नमूनों को Apache 2.0 License के तहत लाइसेंस मिला है. ज़्यादा जानकारी के लिए, Google Developers साइट नीतियां देखें. Oracle और/या इससे जुड़ी हुई कंपनियों का, Java एक रजिस्टर किया हुआ ट्रेडमार्क है.

आखिरी बार 2025-12-12 (UTC) को अपडेट किया गया.