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

सिद्धांत और इस्तेमाल

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

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

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

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

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

नियम बनाएं

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

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

यूआरएल फ़िल्टर से मिलते-जुलते वर्ण

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

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

नियम की प्राथमिकता

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

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

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

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

सिर्फ़ एक एक्सटेंशन में, प्राथमिकता तय करने के लिए नीचे दी गई प्रक्रिया का इस्तेमाल किया जाता है:

  1. डेवलपर की तय की गई सबसे ज़्यादा प्राथमिकता वाला नियम (दूसरे शब्दों में, "priority" फ़ील्ड) दिखाया जाता है.

  2. अगर डेवलपर की तय की गई प्राथमिकता वाले एक से ज़्यादा नियम हैं, तो "action" फ़ील्ड का इस्तेमाल करके नियमों को नीचे दिए गए क्रम में प्राथमिकता दी जाती है:

    1. allow
    2. allowAllRequests
    3. block
    4. upgradeScheme
    5. redirect

  3. अगर कार्रवाई का टाइप block या redirect नहीं है, तो मिलते-जुलते modifyHeaders नियमों का आकलन किया जाता है. ध्यान रखें कि अगर डेवलपर की तय की गई प्राथमिकता की प्राथमिकता वाला कोई नियम, allow और allowAllRequests के लिए तय प्राथमिकता से कम है, तो ऐसे नियमों को अनदेखा कर दिया जाता है.

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

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

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

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

  1. "action" फ़ील्ड का इस्तेमाल करके, नियमों को नीचे दिए गए क्रम में प्राथमिकता दी जाती है:

    1. block
    2. redirect या upgradeScheme
    3. allow या allowAllRequests

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

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

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

स्टैटिक नियम

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

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

सेशन के नियम

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

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

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

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

Chrome 121 और उसके बाद के वर्शन में, सुरक्षित डाइनैमिक नियमों के लिए ज़्यादा से ज़्यादा 30,000 नियम उपलब्ध हैं. इन्हें MAX_NUMBER_OF_DYNAMIC_RULES कहा जाता है. सुरक्षित नियमों को ऐसे नियमों के तौर पर बताया जाता है जिनके लिए block, allow, allowAllRequests या upgradeScheme कार्रवाई की जाती है. 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.

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

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

वेब ऐक्सेस करने लायक संसाधन

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

उदाहरण

कोड के उदाहरण

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

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

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

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

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

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

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

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

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

"प्राथमिकता" कुंजी

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

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

https://google.com पर जाना
इस यूआरएल पर दो नियम शामिल हैं: 1 और 4 आईडी वाले नियम. आईडी 1 वाला नियम लागू होता है, क्योंकि "redirect" कार्रवाइयों के मुकाबले "block" कार्रवाइयों को ज़्यादा प्राथमिकता मिलती है. बाकी नियम लागू नहीं होते, क्योंकि वे लंबे यूआरएल के लिए हैं.
https://google.com/1234 पर जाना
लंबे यूआरएल की वजह से, अब आईडी 2 वाला नियम, आईडी 1 और 4 वाले नियमों के साथ मेल खाता है. आईडी 2 वाला नियम लागू होता है, क्योंकि "allow" की प्राथमिकता "block" और "redirect" से ज़्यादा है.
https://google.com/12345 पर जाना
सभी चार नियम इस URL से मेल खाते हैं. आईडी 3 वाला नियम लागू होता है, क्योंकि डेवलपर की तय की गई प्राथमिकता, ग्रुप में सबसे ज़्यादा होती है.
[
  {
    "id": 1,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {"urlFilter": "google.com", "resourceTypes": ["main_frame"] }
  },
  {
    "id": 2,
    "priority": 1,
    "action": { "type": "allow" },
    "condition": { "urlFilter": "google.com/123", "resourceTypes": ["main_frame"] }
  },
  {
    "id": 3,
    "priority": 2,
    "action": { "type": "block" },
    "condition": { "urlFilter": "google.com/12345", "resourceTypes": ["main_frame"] }
  },
  {
    "id": 4,
    "priority": 1,
    "action": { "type": "redirect", "redirect": { "url": "https://example.com" } },
    "condition": { "urlFilter": "google.com", "resourceTypes": ["main_frame"] }
  },
]

रीडायरेक्ट

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

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

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

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

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

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

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

हेडर

इस उदाहरण में, मुख्य फ़्रेम और सब फ़्रेम, दोनों से सभी कुकी को हटाया गया है.

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

टाइप

DomainType

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

Enum

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

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

ExtensionActionOptions

Chrome 88+

प्रॉपर्टी

  • displayActionCountAsBadgeText

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

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

  • tabUpdate

    TabActionCountUpdate ज़रूरी नहीं

    Chrome 89+

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

GetDisabledRuleIdsOptions

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

प्रॉपर्टी

  • rulesetId

    स्ट्रिंग

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

GetRulesFilter

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

प्रॉपर्टी

  • ruleIds

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

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

HeaderOperation

Chrome 86+

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

Enum

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

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

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

IsRegexSupportedResult

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

प्रॉपर्टी

  • isSupported

    boolean

  • वजह

    UnsupportedRegexReason ज़रूरी नहीं

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

MatchedRule

प्रॉपर्टी

  • ruleId

    नंबर

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

  • rulesetId

    स्ट्रिंग

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

MatchedRuleInfo

प्रॉपर्टी

  • नियम

    MatchedRule

  • tabId

    नंबर

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

  • timeStamp

    नंबर

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

MatchedRuleInfoDebug

प्रॉपर्टी

  • CANNOT TRANSLATE

    RequestDetails

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

  • नियम

    MatchedRule

MatchedRulesFilter

प्रॉपर्टी

  • minTimeStamp

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

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

  • tabId

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

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

ModifyHeaderInfo

Chrome 86+

प्रॉपर्टी

  • हेडर

    स्ट्रिंग

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

  • कार्रवाई

    HeaderOperation

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

  • value

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

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

QueryKeyValue

प्रॉपर्टी

  • बटन

    स्ट्रिंग

  • replaceOnly

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

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

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

  • value

    स्ट्रिंग

QueryTransform

प्रॉपर्टी

  • addOrReplaceParams

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

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

  • removeParams

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

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

Redirect

प्रॉपर्टी

  • extensionPath

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

    एक्सटेंशन डायरेक्ट्री से मिलता-जुलता पाथ. '/' से शुरू होना चाहिए.

  • regexSubstitution

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

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

  • रूपांतरित करें

    URLTransform ज़रूरी नहीं

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

  • यूआरएल

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

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

RegexOptions

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

प्रॉपर्टी

  • isCaseSensitive

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

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

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

    स्ट्रिंग

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

  • requireCapturing

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

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

RequestDetails

प्रॉपर्टी

  • documentId

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

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

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

  • documentLifecycle

    DocumentLifecycle ज़रूरी नहीं

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

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

  • frameId

    नंबर

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

  • frameType

    FrameType ज़रूरी नहीं

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

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

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

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

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

  • method

    स्ट्रिंग

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

  • parentDocumentId

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

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

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

  • parentFrameId

    नंबर

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

  • requestId

    स्ट्रिंग

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

  • tabId

    नंबर

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

  • टाइप

    ResourceType

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

  • यूआरएल

    स्ट्रिंग

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

RequestMethod

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

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

Enum

"get"

"head"

"put"

ResourceType

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

Enum

"main_frame"

"sub_frame"

"object"

"xmlhttprequest"

"csp_report"

"websocket"

Rule

प्रॉपर्टी

  • किसी खास रूटीन से जुड़ी कार्रवाई

    RuleAction

    इस नियम के मेल खाने पर, कौनसी कार्रवाई की जानी चाहिए.

  • शर्त

    RuleCondition

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

  • id

    नंबर

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

  • प्राथमिकता

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

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

RuleAction

प्रॉपर्टी

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

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

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

  • requestHeaders

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

    Chrome 86+

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

  • responseHeaders

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

    Chrome 86+

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

  • टाइप

    RuleActionType

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

RuleActionType

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

Enum

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

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

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

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

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

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

RuleCondition

प्रॉपर्टी

  • domainType

    DomainType ज़रूरी नहीं

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

  • डोमेन

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

    Chrome 101 के बाद से अब सेवा में नहीं है

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

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

  • excludedDomains

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

    Chrome 101 के बाद से अब सेवा में नहीं है

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

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

  • excludedInitiatorDomains

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

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

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

    ध्यान दें:

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

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

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

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

    ध्यान दें:

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

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

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

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

  • excludedResourceTypes

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

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

  • excludedTabIds

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

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

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

  • initiatorDomains

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

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

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

    ध्यान दें:

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

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

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

  • regexFilter

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

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

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

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

  • requestDomains

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

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

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

    ध्यान दें:

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

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

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

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

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

  • resourceTypes

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

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

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

  • tabIds

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

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

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

  • urlFilter

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

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

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

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

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

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

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

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

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

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

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

Ruleset

प्रॉपर्टी

  • चालू किया गया

    boolean

    क्या रूलसेट डिफ़ॉल्ट रूप से चालू है.

  • id

    स्ट्रिंग

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

  • पाथ

    स्ट्रिंग

    एक्सटेंशन डायरेक्ट्री के संबंध में JSON रूलसेट का पाथ.

RulesMatchedDetails

प्रॉपर्टी

  • rulesMatchedInfo

    MatchedRuleInfo[]

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

TabActionCountUpdate

Chrome 89+

प्रॉपर्टी

  • अधिक

    नंबर

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

  • tabId

    नंबर

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

TestMatchOutcomeResult

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

प्रॉपर्टी

  • matchedRules

    MatchedRule[]

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

TestMatchRequestDetails

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

प्रॉपर्टी

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

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

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

  • method

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

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

  • tabId

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

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

  • टाइप

    ResourceType

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

  • यूआरएल

    स्ट्रिंग

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

UnsupportedRegexReason

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

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

Enum

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

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

UpdateRuleOptions

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

प्रॉपर्टी

  • addRules

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

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

  • removeRuleIds

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

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

UpdateRulesetOptions

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

प्रॉपर्टी

  • disableRulesetIds

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

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

  • enableRulesetIds

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

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

UpdateStaticRulesOptions

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

प्रॉपर्टी

  • disableRuleIds

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

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

  • enableRuleIds

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

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

  • rulesetId

    स्ट्रिंग

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

URLTransform

प्रॉपर्टी

  • फ़्रैगमेंट

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

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

  • होस्ट

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

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

  • पासवर्ड

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

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

  • पाथ

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

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

  • पोर्ट

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

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

  • query

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

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

  • queryTransform

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

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

  • स्कीम

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

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

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

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

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

प्रॉपर्टी

DYNAMIC_RULESET_ID

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

वैल्यू

GETMATCHEDRULES_QUOTA_INTERVAL

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

वैल्यू

10

GUARANTEED_MINIMUM_STATIC_RULES

Chrome 89+

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

वैल्यू

30,000

MAX_GETMATCHEDRULES_CALLS_PER_INTERVAL

GETMATCHEDRULES_QUOTA_INTERVAL की अवधि के दौरान getMatchedRules को कॉल किए जाने की संख्या.

वैल्यू

20

MAX_NUMBER_OF_DYNAMIC_RULES

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

वैल्यू

30,000

MAX_NUMBER_OF_ENABLED_STATIC_RULESETS

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

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

वैल्यू

50

MAX_NUMBER_OF_REGEX_RULES

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

वैल्यू

1,000

MAX_NUMBER_OF_SESSION_RULES

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

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

वैल्यू

5,000

MAX_NUMBER_OF_STATIC_RULESETS

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

वैल्यू

100

MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES

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

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

वैल्यू

5,000

MAX_NUMBER_OF_UNSAFE_SESSION_RULES

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

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

वैल्यू

5,000

SESSION_RULESET_ID

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

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

वैल्यू

"_session"

तरीके

getAvailableStaticRuleCount()

प्रॉमिस Chrome 89+ 
chrome.declarativeNetRequest.getAvailableStaticRuleCount(
  callback?: function,
)

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

पैरामीटर

  • कॉलबैक

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

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

    (count: number)=>void

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

      नंबर

रिटर्न

  • वादा<number>

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

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

getDisabledRuleIds()

प्रॉमिस Chrome 111+ 
chrome.declarativeNetRequest.getDisabledRuleIds(
  options: GetDisabledRuleIdsOptions,
  callback?: function,
)

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

पैरामीटर

  • विकल्प

    GetDisabledRuleIdsOptions

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

  • कॉलबैक

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

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

    (disabledRuleIds: number[])=>void

    • disabledRuleIds

      नंबर[]

रिटर्न

  • वादा करें<number[]>

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

getDynamicRules()

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

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

पैरामीटर

  • फ़िल्‍टर

    GetRulesFilter ज़रूरी नहीं

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

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

  • कॉलबैक

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

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

    (rules: Rule[])=>void

रिटर्न

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

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

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

getEnabledRulesets()

वादा 
chrome.declarativeNetRequest.getEnabledRulesets(
  callback?: function,
)

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

पैरामीटर

  • कॉलबैक

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

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

    (rulesetIds: string[])=>void

    • rulesetIds

      स्ट्रिंग[]

रिटर्न

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

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

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

getMatchedRules()

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

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

पैरामीटर

  • फ़िल्‍टर

    MatchedRulesFilter ज़रूरी नहीं

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

  • कॉलबैक

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

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

    (details: RulesMatchedDetails)=>void

रिटर्न

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

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

getSessionRules()

प्रॉमिस Chrome 90+ 
chrome.declarativeNetRequest.getSessionRules(
  filter?: GetRulesFilter,
  callback?: function,
)

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

पैरामीटर

  • फ़िल्‍टर

    GetRulesFilter ज़रूरी नहीं

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

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

  • कॉलबैक

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

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

    (rules: Rule[])=>void

रिटर्न

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

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

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

isRegexSupported()

प्रॉमिस Chrome 87+ 
chrome.declarativeNetRequest.isRegexSupported(
  regexOptions: RegexOptions,
  callback?: function,
)

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

पैरामीटर

  • regexOptions

    RegexOptions

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

  • कॉलबैक

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

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

    (result: IsRegexSupportedResult)=>void

रिटर्न

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

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

setExtensionActionOptions()

प्रॉमिस Chrome 88+ 
chrome.declarativeNetRequest.setExtensionActionOptions(
  options: ExtensionActionOptions,
  callback?: function,
)

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

पैरामीटर

  • विकल्प

    ExtensionActionOptions

  • कॉलबैक

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

    Chrome 89+

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

    ()=>void

रिटर्न

  • Promise<void>

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

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

testMatchOutcome()

प्रॉमिस Chrome 103+ 
chrome.declarativeNetRequest.testMatchOutcome(
  request: TestMatchRequestDetails,
  callback?: function,
)

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

पैरामीटर

रिटर्न

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

updateDynamicRules()

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

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

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

पैरामीटर

  • विकल्प

    UpdateRuleOptions

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

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

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

    ()=>void

रिटर्न

  • Promise<void>

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

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

updateEnabledRulesets()

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

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

पैरामीटर

  • विकल्प

    UpdateRulesetOptions

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

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

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

    ()=>void

रिटर्न

  • Promise<void>

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

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

updateSessionRules()

प्रॉमिस Chrome 90+ 
chrome.declarativeNetRequest.updateSessionRules(
  options: UpdateRuleOptions,
  callback?: function,
)

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

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

पैरामीटर

  • विकल्प

    UpdateRuleOptions

  • कॉलबैक

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

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

    ()=>void

रिटर्न

  • Promise<void>

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

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

updateStaticRules()

प्रॉमिस Chrome 111+ 
chrome.declarativeNetRequest.updateStaticRules(
  options: UpdateStaticRulesOptions,
  callback?: function,
)

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

पैरामीटर

  • विकल्प

    UpdateStaticRulesOptions

  • कॉलबैक

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

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

    ()=>void

रिटर्न

  • Promise<void>

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

इवेंट

onRuleMatchedDebug

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

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

पैरामीटर