chrome.declarativeNetRequest

refresh date: 2026-09-25 robots: noindex

ब्यौरा

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

अनुमतियां

declarativeNetRequest
declarativeNetRequestWithHostAccess

declarativeNetRequestFeedback
host_permissions

उपलब्धता

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" कुंजी का इस्तेमाल करके तय किए जाते हैं.

स्टैटिक 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"]
  }
}

urlFilter से मेल खाने वाले वर्ण

किसी नियम की "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" मेनिफ़ेस्ट कुंजी के हिस्से के तौर पर ज़्यादा से ज़्यादा 50 स्टैटिक ruleset तय कर सकता है. हालांकि, इनमें से सिर्फ़ 10 ruleset एक बार में चालू किए जा सकते हैं. दूसरे को MAX_NUMBER_OF_ENABLED_STATIC_RULESETS कहा जाता है. इन सभी नियमों के सेट में, कम से कम 30,000 नियम होने की गारंटी है. इसे GUARANTEED_MINIMUM_STATIC_RULES कहा जाता है.

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

डाइनैमिक और सेशन के नियम

डाइनैमिक और सेशन के नियमों पर लागू होने वाली सीमाएं, स्टैटिक नियमों की तुलना में आसान होती हैं. दोनों की कुल संख्या 5,000 से ज़्यादा नहीं होनी चाहिए. इसे MAX_NUMBER_OF_DYNAMIC_AND_SESSION_RULES कहा जाता है.

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

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

उदाहरण

कोड के उदाहरण

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

यहां दिए गए उदाहरण में, 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" में मौजूद "scheme" कुंजी से पता चलता है कि सबडोमेन पर रीडायरेक्ट करने के लिए हमेशा "https" का इस्तेमाल किया जाएगा.

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

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

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

हेडर

यहां दिए गए उदाहरण में, मुख्य फ़्रेम और किसी भी सब-फ़्रेम से सभी कुकी हटा दी जाती हैं.

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

टाइप

DomainType

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

Enum

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

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

ExtensionActionOptions

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

प्रॉपर्टी

  • displayActionCountAsBadgeText

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

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

  • tabUpdate

    TabActionCountUpdate optional

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

    टैब के ऐक्शन की संख्या को कैसे अडजस्ट किया जाना चाहिए, इसकी जानकारी.

GetDisabledRuleIdsOptions

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

प्रॉपर्टी

  • rulesetId

    स्ट्रिंग

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

GetRulesFilter

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

प्रॉपर्टी

  • ruleIds

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

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

HeaderInfo

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

प्रॉपर्टी

  • excludedValues

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

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

  • हेडर

    स्ट्रिंग

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

  • वैल्यू

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

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

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

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

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

HeaderOperation

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

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

Enum

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

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

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

IsRegexSupportedResult

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

प्रॉपर्टी

  • isSupported

    बूलियन

  • वजह

    UnsupportedRegexReason 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 optional

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

  • tabId

    number optional

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

ModifyHeaderInfo

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

प्रॉपर्टी

  • हेडर

    स्ट्रिंग

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

  • कार्रवाई

    HeaderOperation

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

  • मान

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

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

QueryKeyValue

प्रॉपर्टी

  • बटन

    स्ट्रिंग

  • replaceOnly

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

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

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

  • मान

    स्ट्रिंग

QueryTransform

प्रॉपर्टी

  • addOrReplaceParams

    QueryKeyValue[] optional

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

  • removeParams

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

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

Redirect

प्रॉपर्टी

  • extensionPath

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

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

  • regexSubstitution

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

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

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

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

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

  • url

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

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

RegexOptions

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

प्रॉपर्टी

  • isCaseSensitive

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

    इससे पता चलता है कि क्या regex केस-सेंसिटिव है. डिफ़ॉल्ट रूप से, यह सही पर सेट होता है.

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

    स्ट्रिंग

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

  • requireCapturing

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

    इससे पता चलता है कि क्या बताई गई 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

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

  • id

    संख्या

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

  • प्राथमिकता

    number optional

    नियम की प्राथमिकता. डिफ़ॉल्ट वैल्यू 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 ज़रूरी नहीं है

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

  • डोमेन

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

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

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

  • excludedTabIds

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

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

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

  • excludedTopDomains

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

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

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

    ध्यान दें:

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

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

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

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

    ध्यान दें:

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

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

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

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

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

  • tabIds

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

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

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

  • topDomains

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

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

    यह नियम सिर्फ़ तब नेटवर्क अनुरोधों से मैच करेगा, जब इससे जुड़े टॉप-लेवल फ़्रेम का डोमेन, 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

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

Enum

"urlFilter"

"regexFilter"

"isUrlFilterCaseSensitive"

"initiatorDomains"

"excludedInitiatorDomains"

"requestDomains"

"excludedRequestDomains"

"topDomains"

"excludedTopDomains"

"domains"

"excludedDomains"

"resourceTypes"

"excludedResourceTypes"

"requestMethods"

"excludedRequestMethods"

"domainType"

"tabIds"

"excludedTabIds"

"responseHeaders"

"excludedResponseHeaders"

Ruleset

प्रॉपर्टी

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

    बूलियन

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

  • id

    स्ट्रिंग

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

  • पाथ

    स्ट्रिंग

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

RulesMatchedDetails

प्रॉपर्टी

  • rulesMatchedInfo

    MatchedRuleInfo[]

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

TabActionCountUpdate

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

प्रॉपर्टी

  • अधिक

    संख्या

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

  • tabId

    संख्या

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

TestMatchOutcomeResult

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

प्रॉपर्टी

  • matchedRules

    MatchedRule[]

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

TestMatchRequestDetails

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

प्रॉपर्टी

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

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

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

  • तरीका

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

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

  • responseHeaders

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

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

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

  • tabId

    number optional

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

  • topUrl

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

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

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

  • टाइप

    ResourceType

    यह प्रॉपर्टी, काल्पनिक अनुरोध के संसाधन का टाइप दिखाती है.

  • url

    स्ट्रिंग

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

UnsupportedRegexReason

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

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

Enum

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

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

UpdateRuleOptions

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

प्रॉपर्टी

  • addRules

    Rule[] optional

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

  • removeRuleIds

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

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

UpdateRulesetOptions

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

प्रॉपर्टी

  • disableRulesetIds

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

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

  • enableRulesetIds

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

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

UpdateStaticRulesOptions

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

प्रॉपर्टी

  • disableRuleIds

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

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

  • enableRuleIds

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

    चालू करने के लिए, 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 कॉल, कोटे से बाहर रखे जाते हैं.

वैल्यू

10

GUARANTEED_MINIMUM_STATIC_RULES

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

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

वैल्यू

30000

MAX_GETMATCHEDRULES_CALLS_PER_INTERVAL

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

वैल्यू

20

MAX_NUMBER_OF_DYNAMIC_RULES

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

वैल्यू

30000

MAX_NUMBER_OF_ENABLED_STATIC_RULESETS

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

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

वैल्यू

50

MAX_NUMBER_OF_REGEX_RULES

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

वैल्यू

1000

MAX_NUMBER_OF_SESSION_RULES

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

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

वैल्यू

5000

MAX_NUMBER_OF_STATIC_RULESETS

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

वैल्यू

100

MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES

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

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

वैल्यू

5000

MAX_NUMBER_OF_UNSAFE_SESSION_RULES

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

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

वैल्यू

5000

SESSION_RULESET_ID

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

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

वैल्यू

"_session"

तरीके

getAvailableStaticRuleCount()

Promise Chrome 89 या इसके बाद का वर्शन 
chrome.declarativeNetRequest.getAvailableStaticRuleCount(
  callback?: function,
): Promise<number>

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

पैरामीटर

  • कॉलबैक

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

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

    (count: number) => void

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

      संख्या

रिटर्न

  • Promise<number>

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

    प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

getDisabledRuleIds()

Promise Chrome 111 या इसके बाद के वर्शन 
chrome.declarativeNetRequest.getDisabledRuleIds(
  options: GetDisabledRuleIdsOptions,
  callback?: function,
): Promise<number[]>

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

पैरामीटर

  • विकल्प

    GetDisabledRuleIdsOptions

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

  • कॉलबैक

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

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

    (disabledRuleIds: number[]) => void

    • disabledRuleIds

      number[]

रिटर्न

  • Promise<number[]>

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

    प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

getDynamicRules()

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

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

पैरामीटर

  • फ़िल्टर

    GetRulesFilter ज़रूरी नहीं

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

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

  • कॉलबैक

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

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

    (rules: Rule[]) => void

    • नियम

      Rule[]

रिटर्न

  • Promise<Rule[]>

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

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

    प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

getEnabledRulesets()

Promise 
chrome.declarativeNetRequest.getEnabledRulesets(
  callback?: function,
): Promise<string[]>

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

पैरामीटर

  • कॉलबैक

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

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

    (rulesetIds: string[]) => void

    • rulesetIds

      string[]

रिटर्न

  • Promise<string[]>

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

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

    प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

getMatchedRules()

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

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

पैरामीटर

  • फ़िल्टर

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

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

  • कॉलबैक

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

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

    (details: RulesMatchedDetails) => void

रिटर्न

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

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

    प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

getSessionRules()

Promise Chrome 90+ 
chrome.declarativeNetRequest.getSessionRules(
  filter?: GetRulesFilter,
  callback?: function,
): Promise<Rule[]>

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

पैरामीटर

  • फ़िल्टर

    GetRulesFilter ज़रूरी नहीं

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

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

  • कॉलबैक

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

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

    (rules: Rule[]) => void

    • नियम

      Rule[]

रिटर्न

  • Promise<Rule[]>

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

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

    प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

isRegexSupported()

Promise Chrome 87 या इसके बाद के वर्शन 
chrome.declarativeNetRequest.isRegexSupported(
  regexOptions: RegexOptions,
  callback?: function,
): Promise<IsRegexSupportedResult>

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

पैरामीटर

  • regexOptions

    RegexOptions

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

  • कॉलबैक

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

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

    (result: IsRegexSupportedResult) => void

रिटर्न

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

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

    प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

setExtensionActionOptions()

Promise Chrome 88 या इसके बाद के वर्शन 
chrome.declarativeNetRequest.setExtensionActionOptions(
  options: ExtensionActionOptions,
  callback?: function,
): Promise<void>

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

पैरामीटर

  • विकल्प

    ExtensionActionOptions

  • कॉलबैक

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

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

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

    () => void

रिटर्न

  • Promise<void>

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

    प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

testMatchOutcome()

Promise Chrome 103 और इसके बाद के वर्शन 
chrome.declarativeNetRequest.testMatchOutcome(
  request: TestMatchRequestDetails,
  callback?: function,
): Promise<TestMatchOutcomeResult>

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

पैरामीटर

रिटर्न

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

    प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

updateDynamicRules()

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

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

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

पैरामीटर

  • विकल्प

    UpdateRuleOptions

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

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

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

    () => void

रिटर्न

  • Promise<void>

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

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

    प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

updateEnabledRulesets()

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

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

पैरामीटर

  • विकल्प

    UpdateRulesetOptions

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

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

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

    () => void

रिटर्न

  • Promise<void>

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

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

    प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

updateSessionRules()

Promise Chrome 90+ 
chrome.declarativeNetRequest.updateSessionRules(
  options: UpdateRuleOptions,
  callback?: function,
): Promise<void>

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

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

पैरामीटर

  • विकल्प

    UpdateRuleOptions

  • कॉलबैक

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

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

    () => void

रिटर्न

  • Promise<void>

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

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

    प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

updateStaticRules()

Promise Chrome 111 या इसके बाद के वर्शन 
chrome.declarativeNetRequest.updateStaticRules(
  options: UpdateStaticRulesOptions,
  callback?: function,
): Promise<void>

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

पैरामीटर

  • विकल्प

    UpdateStaticRulesOptions

  • कॉलबैक

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

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

    () => void

रिटर्न

  • Promise<void>

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

    प्रॉमिस सिर्फ़ Manifest V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

इवेंट

onRuleMatchedDebug

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

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

पैरामीटर