chrome.webRequest

ब्यौरा

ट्रैफ़िक पर नज़र रखने और उसका विश्लेषण करने के साथ-साथ, फ़्लाइट के दौरान अनुरोधों को रोकने, ब्लॉक करने या उनमें बदलाव करने के लिए, chrome.webRequest API का इस्तेमाल करें.

अनुमतियां

webRequest

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

{
  "name": "My extension",
  ...
  "permissions": [
    "webRequest"
  ],
  "host_permissions": [
    "*://*.google.com/*"
  ],
  ...
}

webRequestBlocking

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

webRequestAuthProvider

onAuthRequired तरीके का इस्तेमाल करने के लिए ज़रूरी है. पुष्टि करने की प्रोसेस मैनेज करना देखें.

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

अनुरोधों का लाइफ़ साइकल

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

पूरे होने वाले अनुरोधों के इवेंट लाइफ़ साइकल की जानकारी यहां दी गई है. इसके बाद, इवेंट की परिभाषाएं दी गई हैं:

webrequest API के हिसाब से, वेब अनुरोध की लाइफ़ साइकल

onBeforeRequest (वैकल्पिक रूप से सिंक्रोनस)
जब कोई अनुरोध किया जाता है, तब ट्रिगर होता है. यह इवेंट, टीसीपी कनेक्शन से पहले भेजा जाता है और इसका इस्तेमाल अनुरोधों को रद्द या रीडायरेक्ट करने के लिए किया जा सकता है.
onBeforeSendHeaders (वैकल्पिक रूप से सिंक्रोनस)
यह तब ट्रिगर होता है, जब कोई अनुरोध होने वाला हो और शुरुआती हेडर तैयार हों. इवेंट का मकसद एक्सटेंशन को अनुरोध के हेडर जोड़ने, उनमें बदलाव करने, और उन्हें मिटाने की अनुमति देना है (*). onBeforeSendHeaders इवेंट सभी सदस्यों को पास किया गया है. इसलिए, अलग-अलग सदस्य अनुरोध में बदलाव करने की कोशिश कर सकते हैं. इसे मैनेज करने का तरीका जानने के लिए, लागू करने से जुड़ी जानकारी सेक्शन देखें. इस इवेंट का इस्तेमाल अनुरोध रद्द करने के लिए किया जा सकता है.
onSendHeaders
सभी एक्सटेंशन के अनुरोध के हेडर में बदलाव करने के बाद ही ट्रिगर होने लगता है. यह आखिरी (*) वर्शन के बारे में बताता है. नेटवर्क को हेडर भेजने से पहले इवेंट ट्रिगर होता है. यह इवेंट जानकारी देने के मकसद से बनाया गया है. साथ ही, इसे एसिंक्रोनस तरीके से हैंडल किया जाता है. यह अनुरोध में बदलाव करने या उसे रद्द करने की अनुमति नहीं देता.
onHeadersReceived (वैकल्पिक रूप से सिंक्रोनस)
हर बार एचटीटीपी(एस) रिस्पॉन्स हेडर मिलने पर ट्रिगर होता है. रीडायरेक्ट और पुष्टि करने के अनुरोधों की वजह से, ऐसा हर अनुरोध के लिए कई बार हो सकता है. इस इवेंट का मकसद एक्सटेंशन को रिस्पॉन्स हेडर जोड़ने, उनमें बदलाव करने, और मिटाने की अनुमति देना है, जैसे कि इनकमिंग कॉन्टेंट-टाइप हेडर. इस इवेंट के ट्रिगर होने से पहले, कैश मेमोरी में सेव किए गए डायरेक्टिव प्रोसेस किए जाते हैं. इसलिए, कैश कंट्रोल जैसे हेडर में बदलाव करने से ब्राउज़र के कैश पर कोई असर नहीं होता. इसकी मदद से, अनुरोध को रद्द किया जा सकता है या उसे रीडायरेक्ट भी किया जा सकता है.
onAuthRequired (वैकल्पिक रूप से सिंक्रोनस)
जब किसी अनुरोध के लिए उपयोगकर्ता की पुष्टि करने की ज़रूरत होती है, तब यह सेवा चालू हो जाती है. पुष्टि करने के क्रेडेंशियल देने के लिए, इस इवेंट को साथ में मैनेज किया जा सकता है. ध्यान दें कि एक्सटेंशन से अमान्य क्रेडेंशियल मिल सकते हैं. ध्यान रखें कि बार-बार अमान्य क्रेडेंशियल देकर इनफ़ाइनाइट लूप न डाला जाए. इसका इस्तेमाल, अनुरोध को रद्द करने के लिए भी किया जा सकता है.
onBeforeRedirect
यह तब ट्रिगर होता है, जब कोई रीडायरेक्ट शुरू होने वाला होता है. रीडायरेक्ट, एचटीटीपी रिस्पॉन्स कोड या एक्सटेंशन से ट्रिगर हो सकता है. इस इवेंट में, जानकारी दी जाती है. साथ ही, इसे एसिंक्रोनस तरीके से मैनेज किया जाता है. यह आपको अनुरोध में बदलाव करने या उसे रद्द करने की अनुमति नहीं देता.
onResponseStarted
रिस्पॉन्स बॉडी का पहला बाइट मिलने पर चालू हो जाता है. एचटीटीपी अनुरोधों के लिए, इसका मतलब है कि स्टेटस लाइन और रिस्पॉन्स हेडर उपलब्ध हैं. यह इवेंट जानकारी देता है और इसे एसिंक्रोनस तरीके से मैनेज किया जाता है. यह अनुरोध में बदलाव करने या उसे रद्द करने की अनुमति नहीं देता.
onCompleted
अनुरोध पूरा हो जाने पर चालू हो जाता है.
onErrorOccurred
अनुरोध को प्रोसेस नहीं किए जा सकने पर चालू होता है.

वेब अनुरोध एपीआई इस बात की गारंटी देता है कि हर अनुरोध के लिए, onCompleted या onErrorOccurred को फ़ाइनल इवेंट के तौर पर ट्रिगर किया जाएगा. हालांकि, इस अपवाद का एक अपवाद है: अगर किसी अनुरोध को data:// यूआरएल पर रीडायरेक्ट किया जाता है, तो onBeforeRedirect आखिरी इवेंट है.

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

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

  • अनुमति
  • कैश-कंट्रोल
  • कनेक्शन
  • Content-Length
  • होस्ट
  • अगर-बदलाव करने की तारीख से
  • अगर कोई मैच नहीं है
  • अगर-रेंज
  • पार्शियल-डेटा
  • प्रग्मा
  • प्रॉक्सी-ऑथराइज़ेशन
  • प्रॉक्सी-कनेक्शन
  • ट्रांसफ़र-कोड में बदलने का तरीका

Chrome 79 से, अनुरोध के हेडर में बदलाव करने से, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) की जांच पर असर पड़ता है. अगर क्रॉस-ऑरिजिन अनुरोधों के बदले गए हेडर, ज़रूरी शर्तों को पूरा नहीं करते हैं, तो सर्वर से यह पूछने के लिए एक सीओआरएस प्रीफ़्लाइट भेजा जाएगा कि क्या ऐसे हेडर स्वीकार किए जा सकते हैं. अगर आपको सीओआरएस प्रोटोकॉल का उल्लंघन करने के लिए, हेडर में बदलाव करना है, तो आपको opt_extraInfoSpec में 'extraHeaders' के बारे में बताना होगा. वहीं दूसरी ओर, रिस्पॉन्स हेडर में बदलाव करने से सीओआरएस जांच में धोखा नहीं मिलता. अगर आपको सीओआरएस प्रोटोकॉल से धोखाधड़ी करनी है, तो आपको रिस्पॉन्स में बदलाव के लिए, 'extraHeaders' को भी तय करना होगा.

Chrome 79 और इसके बाद के वर्शन में वेब का अनुरोध करने वाला एपीआई, डिफ़ॉल्ट रूप से सीओआरएस प्रीफ़्लाइट के अनुरोधों और रिस्पॉन्स को नहीं रोकता. किसी अनुरोध यूआरएल के लिए, सीओआरएस प्रीफ़्लाइट उस एक्सटेंशन को दिखता है जो opt_extraInfoSpec में अनुरोध वाले यूआरएल के लिए, 'extraHeaders' वाला कोई श्रोता हो सकता है. onBeforeRequest, Chrome 79 से 'extraHeaders' का इस्तेमाल भी कर सकता है.

Chrome 79 की शुरुआत से, नीचे दिया गया अनुरोध का हेडर नहीं दिया गया है और इसे opt_extraInfoSpec में 'extraHeaders' तय किए बिना बदला या हटाया नहीं जा सकता:

  • शुरुआत की जगह

अगर आपको क्रॉस ऑरिजिन रीड ब्लॉकिंग (सीओआरबी) से पहले जवाबों में बदलाव करना है, तो आपको opt_extraInfoSpec में 'extraHeaders' की जानकारी देनी होगी. ऐसा Chrome 72 और उसके बाद के वर्शन में किया जा रहा है.

Chrome 72 और उसके बाद के वर्शन में, नीचे दिए गए अनुरोध के हेडर नहीं दिए गए हैं और opt_extraInfoSpec में 'extraHeaders' तय किए बिना, इनमें बदलाव नहीं किया जा सकता या उन्हें हटाया नहीं जा सकता:

  • भाषा स्वीकार करें
  • कोड में बदलने का तरीका स्वीकार करें
  • रेफ़रर
  • कुकी

Chrome 72 और फिर Set-Cookie रिस्पॉन्स हेडर नहीं दिया गया है. साथ ही, opt_extraInfoSpec में 'extraHeaders' तय किए बिना, इसे बदला या हटाया नहीं जा सकता.

Chrome 89 और उसके बाद के वर्शन में, opt_extraInfoSpec में 'extraHeaders' तय किए बिना, X-Frame-Options रिस्पॉन्स हेडर में असरदार तरीके से बदलाव नहीं किया जा सकता या उसे हटाया नहीं जा सकता.

webRequest API, एक्सटेंशन को दी गई होस्ट अनुमतियों के आधार पर सिर्फ़ उन अनुरोधों को दिखाता है जिन्हें देखने की अनुमति एक्सटेंशन के पास है. इसके अलावा, सिर्फ़ इन स्कीम को ऐक्सेस किया जा सकता है: http://, https://, ftp://, file://, ws:// (Chrome 58 के बाद से), wss:// (Chrome 58 के बाद से), urn: (Chrome 91 के बाद से) या chrome-extension://. इसके अलावा, ऊपर दी गई स्कीम में से किसी एक का इस्तेमाल करके, यूआरएल वाले कुछ अनुरोध भी छिपा दिए जाते हैं. इनमें chrome-extension://other_extension_id शामिल है, जहां other_extension_id, अनुरोध को मैनेज करने वाले एक्सटेंशन का आईडी नहीं है. साथ ही, https://www.google.com/chrome और ब्राउज़र की मुख्य सुविधाओं के काम करने के लिए, अन्य संवेदनशील अनुरोध शामिल हैं. साथ ही, डेडलॉक को रोकने के लिए, आपके एक्सटेंशन के सिंक्रोनस XMLHttpRequests, इवेंट हैंडलर को ब्लॉक करने से छिपे हुए हैं. ध्यान दें कि काम करने वाली कुछ स्कीम से जुड़े प्रोटोकॉल की वजह से, उपलब्ध इवेंट का सेट सीमित हो सकता है. उदाहरण के लिए, इस फ़ाइल: स्कीम के लिए, सिर्फ़ onBeforeRequest, onResponseStarted, onCompleted, और onErrorOccurred को भेजा जा सकता है.

Chrome 58 और उसके बाद के वर्शन में, webRequest API WebSocket हैंडशेक अनुरोध को इंटरसेप्ट करने की सुविधा देता है. हैंडशेक, एचटीटीपी अपग्रेड करने के अनुरोध की मदद से किया जाता है. इसलिए, इसका फ़्लो, एचटीटीपी पर आधारित webRequest मॉडल में फ़िट हो जाता है. ध्यान दें कि एपीआई इंटरसेप्ट नहीं करता:

  • एक स्थापित WebSocket कनेक्शन पर भेजे गए व्यक्तिगत मैसेज.
  • WebSocket कनेक्शन बंद हो रहा है.

WebSocket अनुरोधों के लिए, रीडायरेक्ट काम नहीं करते.

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

Chrome 96 और इसके बाद के वर्शन में, webRequest API एचटीटीपी/3 हैंडशेक अनुरोध पर WebTransport को रोकने की सुविधा देता है. हैंडशेक, एचटीटीपी से कनेक्ट करने के अनुरोध की मदद से किया जाता है. इसलिए, इसका फ़्लो, एचटीटीपी पर आधारित webRequest मॉडल में फ़िट हो जाता है. ध्यान दें:

  • सेशन शुरू होने के बाद, एक्सटेंशन, webRequest API की मदद से सेशन की निगरानी नहीं कर सकते या उसमें रुकावट नहीं डाल सकते.
  • onBeforeSendHeaders में एचटीटीपी अनुरोध के हेडर में बदलाव नहीं किया जाता.
  • WebTransport में, एचटीटीपी/3 पर रीडायरेक्ट और पुष्टि करने की सुविधा काम नहीं करती.

अनुरोध के आईडी

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

इवेंट लिसनर को रजिस्टर करना

वेब अनुरोध के लिए इवेंट लिसनर को रजिस्टर करने के लिए, आपको सामान्य addListener() फ़ंक्शन के वैरिएशन का इस्तेमाल करना होगा. कॉलबैक फ़ंक्शन के बारे में बताने के अलावा, आपको फ़िल्टर आर्ग्युमेंट के बारे में बताना होगा. साथ ही, आपके पास अतिरिक्त जानकारी वाला एक आर्ग्युमेंट इस्तेमाल करने का विकल्प भी होता है.

वेब अनुरोध एपीआई के addListener() के लिए दिए गए तीन तर्कों की ये परिभाषाएं हैं:

var callback = function(details) {...};
var filter = {...};
var opt_extraInfoSpec = [...];

onBeforeRequest इवेंट को सुनने का एक उदाहरण यहां दिया गया है:

chrome.webRequest.onBeforeRequest.addListener(
    callback, filter, opt_extraInfoSpec);

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

अगर विकल्प के तौर पर दिए गए opt_extraInfoSpec कलेक्शन में 'blocking' स्ट्रिंग है (सिर्फ़ खास इवेंट के लिए इस्तेमाल किया जा सकता है), तो कॉलबैक फ़ंक्शन को सिंक्रोनस तरीके से हैंडल किया जाता है. इसका मतलब है कि अनुरोध को तब तक ब्लॉक किया जाता है, जब तक कॉलबैक फ़ंक्शन वापस नहीं दिखता. इस मामले में, कॉलबैक, webRequest.BlockingResponse को लौटा सकता है, जो अनुरोध का अगला लाइफ़ साइकल तय करता है. कॉन्टेक्स्ट के हिसाब से, यह रिस्पॉन्स, अनुरोध (onBeforeRequest) को रद्द या रीडायरेक्ट करने, अनुरोध को रद्द करने या हेडर (onBeforeSendHeaders, onHeadersReceived) में बदलाव करने, और अनुरोध को रद्द करने या पुष्टि करने के क्रेडेंशियल (onAuthRequired) देने की अनुमति देता है.

अगर विकल्प के तौर पर दिए गए opt_extraInfoSpec कलेक्शन में, 'asyncBlocking' स्ट्रिंग शामिल है (सिर्फ़ onAuthRequired के लिए अनुमति है), तो एक्सटेंशन webRequest.BlockingResponse को एसिंक्रोनस तरीके से जनरेट कर सकता है.

webRequest.RequestFilter filter, अलग-अलग डाइमेंशन में ट्रिगर किए जाने वाले इवेंट के अनुरोधों को सीमित करने की अनुमति देता है:

यूआरएल
यूआरएल पैटर्न, जैसे कि *://www.google.com/foo*bar.
टाइप
अनुरोध किस तरह का है, जैसे कि main_frame (ऐसा दस्तावेज़ जो किसी टॉप-लेवल फ़्रेम के लिए लोड किया जाता है), sub_frame (वह दस्तावेज़ जिसे किसी एम्बेड किए गए फ़्रेम के लिए लोड किया जाता है), और image (किसी वेबसाइट पर मौजूद इमेज). webRequest.RequestFilter देखें.
टैब ID
एक टैब के लिए आइडेंटिफ़ायर.
विंडो आईडी
विंडो के लिए आइडेंटिफ़ायर.

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

पुष्टि करने की प्रोसेस को मैनेज करना

एचटीटीपी की पुष्टि करने के अनुरोधों को मैनेज करने के लिए, अपनी मेनिफ़ेस्ट फ़ाइल में "webRequestAuthProvider" की अनुमति जोड़ें:

{
  "permissions": [
    "webRequest",
    "webRequestAuthProvider"
  ]
}

ध्यान दें कि नीति से इंस्टॉल किए गए किसी ऐसे एक्सटेंशन के लिए इस अनुमति की ज़रूरत नहीं होती जिसके पास "webRequestBlocking" की अनुमति हो.

सिंक्रोनस रूप से क्रेडेंशियल देने के लिए:

chrome.webRequest.onAuthRequired.addListener((details) => {
    return {
      authCredentials: {
        username: 'guest',
        password: 'guest'
      }
    };
  },
  { urls: ['https://httpbin.org/basic-auth/guest/guest'] },
  ['blocking']
);

एसिंक्रोनस तरीके से क्रेडेंशियल देने के लिए:

chrome.webRequest.onAuthRequired.addListener((details, callback) => {
    callback({
      authCredentials: {
        username: 'guest',
        password: 'guest'
      }
    });
  },
  { urls: ['https://httpbin.org/basic-auth/guest/guest'] },
  ['asyncBlocking']
);

क्रियान्वयन विवरण

वेब अनुरोध एपीआई का इस्तेमाल करने वाले एक्सटेंशन को डेवलप करते समय, लागू करने से जुड़ी कई जानकारी को समझना ज़रूरी हो सकता है:

web_accessible_resources

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

समस्या का समाधान

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

कैश मेमोरी में सेव करना

Chrome दो कैश मेमोरी का इस्तेमाल करता है—डिस्क पर मौजूद कैश मेमोरी और बहुत तेज़ मेमोरी में कैश मेमोरी. इन-मेमोरी कैश मेमोरी में सेव किया गया डेटा, रेंडर करने की प्रोसेस के लाइफ़टाइम से जुड़ा होता है. यह करीब-करीब किसी टैब से जुड़ा होता है. इन-मेमोरी कैश मेमोरी से जवाब दिए जाने वाले अनुरोध, वेब अनुरोध एपीआई पर नहीं दिखते. अगर कोई अनुरोध हैंडलर अपने व्यवहार में बदलाव करता है (उदाहरण के लिए, ऐसा व्यवहार जिसके हिसाब से अनुरोधों को ब्लॉक किया गया है), तो हो सकता है कि पेज को सामान्य रूप से रीफ़्रेश करने से यह बदलाव काम न करे. यह पक्का करने के लिए कि काम करने का तरीका बदलाव हो, handlerBehaviorChanged() को कॉल करें, ताकि इन-मेमोरी कैश मेमोरी को फ़्लश किया जा सके. हालांकि, यह अक्सर न करें. कैश मेमोरी को मिटाना बहुत महंगा काम है. इवेंट लिसनर को रजिस्टर या रजिस्टर करने के बाद, आपको handlerBehaviorChanged() को कॉल करने की ज़रूरत नहीं है.

टाइमस्टैंप वाले हिस्सों में

इस बात की गारंटी है कि वेब अनुरोध इवेंट की timestamp प्रॉपर्टी, अंदरूनी एक जैसी रहेगी. एक इवेंट की तुलना दूसरे इवेंट से करने से आपको उनके बीच सही ऑफ़सेट मिलेगा, लेकिन उनकी तुलना एक्सटेंशन के मौजूदा समय से (उदाहरण के लिए, (new Date()).getTime() के ज़रिए) करने से अनचाहे नतीजे मिल सकते हैं.

गड़बड़ी ठीक करना

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

उदाहरण

इस उदाहरण में, www.evil.com के सभी अनुरोधों को ब्लॉक करने का तरीका बताया गया है:

chrome.webRequest.onBeforeRequest.addListener(
  function(details) {
    return {cancel: details.url.indexOf("://www.evil.com/") != -1};
  },
  {urls: ["<all_urls>"]},
  ["blocking"]
);

यह फ़ंक्शन ब्लॉक करने वाले इवेंट हैंडलर का इस्तेमाल करता है. इसलिए, इसके लिए मेनिफ़ेस्ट फ़ाइल में "webRequest" के साथ-साथ "webRequestBlocking" की अनुमति की ज़रूरत होती है.

इस उदाहरण में, इसी लक्ष्य को और बेहतर तरीके से हासिल किया गया है. इसकी वजह यह है कि जिन अनुरोधों को www.evil.com के लिए टारगेट नहीं किया गया है उन्हें एक्सटेंशन में भेजना ज़रूरी नहीं है:

chrome.webRequest.onBeforeRequest.addListener(
  function(details) { return {cancel: true}; },
  {urls: ["*://www.evil.com/*"]},
  ["blocking"]
);

यहां दिए गए उदाहरण में, सभी अनुरोधों से उपयोगकर्ता-एजेंट हेडर को मिटाने का तरीका बताया गया है:

chrome.webRequest.onBeforeSendHeaders.addListener(
  function(details) {
    for (var i = 0; i < details.requestHeaders.length; ++i) {
      if (details.requestHeaders[i].name === 'User-Agent') {
        details.requestHeaders.splice(i, 1);
        break;
      }
    }
    return {requestHeaders: details.requestHeaders};
  },
  {urls: ["<all_urls>"]},
  ["blocking", "requestHeaders"]
);

chrome.webRequest एपीआई को इस्तेमाल करने के लिए, chrome-extension-सैंपल डेटा स्टोर करने की जगह से webRequest सैंपल इंस्टॉल करें.

टाइप

BlockingResponse

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

प्रॉपर्टी

  • authCredentials

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

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

    • पासवर्ड

      स्ट्रिंग

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

      स्ट्रिंग

  • अभी नहीं

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

    अगर अनुरोध सही है, तो अनुरोध रद्द कर दिया गया है. यह अनुरोध को भेजे जाने से रोकता है. इसका इस्तेमाल, onbeforeRequest, onBeforeSendHeaders, onHeadersReceived, और onAuthAllowed इवेंट के जवाब के रूप में किया जा सकता है.

  • redirectUrl

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

    इसका इस्तेमाल सिर्फ़ onBeforeRequest और onHeadersReceived इवेंट के रिस्पॉन्स के तौर पर किया जाता है. अगर यह नीति सेट की जाती है, तो मूल अनुरोध को भेजने/पूरा होने से रोक दिया जाता है और उसके बजाय, दिए गए यूआरएल पर रीडायरेक्ट कर दिया जाता है. data: जैसी बिना एचटीटीपी स्कीम पर रीडायरेक्ट करने की अनुमति है. रीडायरेक्ट कार्रवाई से शुरू किए गए रीडायरेक्ट, रीडायरेक्ट के लिए अनुरोध के मूल तरीके का इस्तेमाल करते हैं. हालांकि, इसमें एक अपवाद है: अगर रीडायरेक्ट onHeadersReceived स्टेज पर शुरू किया गया है, तो GET तरीके का इस्तेमाल करके रीडायरेक्ट जारी किया जाएगा. ws:// और wss:// स्कीम वाले यूआरएल से किए जाने वाले रीडायरेक्ट को अनदेखा किया जाता है.

  • requestHeaders

    HttpHeaders ज़रूरी नहीं

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

  • responseHeaders

    HttpHeaders ज़रूरी नहीं

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

FormDataItem

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

इसमें फ़ॉर्म डेटा में दिया गया डेटा शामिल होता है. यूआरएल कोड में बदले गए फ़ॉर्म के लिए, अगर डेटा utf-8 स्ट्रिंग है, तो इसे स्ट्रिंग के तौर पर सेव किया जाता है. अगर ऐसा नहीं है, तो इसे arrayBuffer के तौर पर सेव किया जाता है. फ़ॉर्म-डेटा के लिए, यह arrayBuffer है. अगर फ़ाइल का नाम, फ़ॉर्म-डेटा की मदद से अपलोड किया जाता है, तो यह फ़ाइल नाम वाली स्ट्रिंग होती है.

Enum

ArrayBuffer

स्ट्रिंग

HttpHeaders

एचटीटीपी हेडर का कलेक्शन. हर हेडर को एक डिक्शनरी के तौर पर दिखाया जाता है. इसमें name बटन और value या binaryValue बटन होते हैं.

टाइप

ऑब्जेक्ट[]

प्रॉपर्टी

  • binaryValue

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

    एचटीटीपी हेडर का मान, अगर इसे UTF-8 से नहीं दिखाया जा सकता, जिसे अलग-अलग बाइट वैल्यू (0..255) के तौर पर स्टोर किया जाता है.

  • नाम

    स्ट्रिंग

    एचटीटीपी हेडर का नाम.

  • value

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

    एचटीटीपी हेडर की वैल्यू, अगर उसे UTF-8 से दिखाया जा सकता है.

IgnoredActionType

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

Enum

"request_headers"

"response_headers"

OnAuthRequiredOptions

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

Enum

"responseHeaders"
से यह पता चलता है कि रिस्पॉन्स हेडर को इवेंट में शामिल किया जाना चाहिए.

"ब्लॉक करना"
यह बताता है कि अनुरोध को तब तक ब्लॉक किया गया है, जब तक कॉलबैक फ़ंक्शन वापस नहीं आता.

"asyncsync"
यह बताता है कि कॉलबैक फ़ंक्शन को एसिंक्रोनस तरीके से मैनेज किया जाता है.

"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.

OnBeforeRedirectOptions

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

Enum

"responseHeaders"
से यह पता चलता है कि रिस्पॉन्स हेडर को इवेंट में शामिल किया जाना चाहिए.

"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.

OnBeforeRequestOptions

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

Enum

"ब्लॉक करना"
यह बताता है कि अनुरोध को तब तक ब्लॉक किया गया है, जब तक कॉलबैक फ़ंक्शन वापस नहीं आता.

"requestBody"
यह बताता है कि अनुरोध के मुख्य हिस्से को इवेंट में शामिल किया जाना चाहिए.

"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.

OnBeforeSendHeadersOptions

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

Enum

"requestHeaders"
यह बताता है कि अनुरोध का हेडर, इवेंट में शामिल किया जाना चाहिए.

"ब्लॉक करना"
यह बताता है कि अनुरोध को तब तक ब्लॉक किया गया है, जब तक कॉलबैक फ़ंक्शन वापस नहीं आता.

"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.

OnCompletedOptions

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

Enum

"responseHeaders"
से यह पता चलता है कि रिस्पॉन्स हेडर को इवेंट में शामिल किया जाना चाहिए.

"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.

OnErrorOccurredOptions

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

वैल्यू

"extraHeaders"

OnHeadersReceivedOptions

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

Enum

"ब्लॉक करना"
यह बताता है कि अनुरोध को तब तक ब्लॉक किया गया है, जब तक कॉलबैक फ़ंक्शन वापस नहीं आता.

"responseHeaders"
से यह पता चलता है कि रिस्पॉन्स हेडर को इवेंट में शामिल किया जाना चाहिए.

"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.

OnResponseStartedOptions

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

Enum

"responseHeaders"
से यह पता चलता है कि रिस्पॉन्स हेडर को इवेंट में शामिल किया जाना चाहिए.

"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.

OnSendHeadersOptions

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

Enum

"requestHeaders"
यह बताता है कि अनुरोध का हेडर, इवेंट में शामिल किया जाना चाहिए.

"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.

RequestFilter

webRequest इवेंट पर लागू करने के लिए फ़िल्टर के बारे में बताने वाला ऑब्जेक्ट.

प्रॉपर्टी

  • tabId

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

  • प्रकार

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

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

  • urls

    स्ट्रिंग[]

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

  • windowId

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

ResourceType

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

Enum

"main_frame"
संसाधन को मुख्य फ़्रेम के तौर पर बताता है.

"sub_frame"
संसाधन को एक सब फ़्रेम के तौर पर बताता है.

"स्टाइलशीट"
संसाधन को स्टाइलशीट के तौर पर बताता है.

"script"
संसाधन को स्क्रिप्ट के तौर पर बताता है.

"image"
संसाधन को इमेज के तौर पर बताता है.

"font"
संसाधन को फ़ॉन्ट के रूप में बताता है.

"object"
संसाधन को ऑब्जेक्ट के तौर पर बताता है.

"xmlhttprequest"
यह संसाधन को XMLHttpRequest के रूप में बताता है.

"ping"
संसाधन को पिंग के तौर पर बताता है.

"csp_report"
यह संसाधन किसी कॉन्टेंट की सुरक्षा नीति (सीएसपी) की रिपोर्ट के तौर पर बताता है.

"media"
संसाधन को मीडिया ऑब्जेक्ट के तौर पर बताता है.

"websocket"
संसाधन को WebSocket के तौर पर बताता है.

"वेबबंडल"
संसाधन को वेबबंडल के रूप में बताता है.

"other"
संसाधन को ऐसे टाइप के तौर पर बताता है जो सूची में शामिल टाइप में शामिल नहीं है.

UploadData

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

प्रॉपर्टी

  • बाइट

    कोई ज़रूरी नहीं

    डेटा की कॉपी के साथ ArrayBuffer.

  • फ़ाइल

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

    फ़ाइल का पाथ और नाम वाली स्ट्रिंग.

प्रॉपर्टी

MAX_HANDLER_BEHAVIOR_CHANGED_CALLS_PER_10_MINUTES

किसी लगातार 10 मिनट के अंतराल में, handlerBehaviorChanged को ज़्यादा से ज़्यादा बार कॉल किए जाने की संख्या. handlerBehaviorChanged एक महंगा फ़ंक्शन कॉल है, जिसे बार-बार कॉल नहीं किया जाना चाहिए.

वैल्यू

20

तरीके

handlerBehaviorChanged()

वादा 
chrome.webRequest.handlerBehaviorChanged(
  callback?: function,
)

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

पैरामीटर

  • कॉलबैक

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

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

    ()=>void

रिटर्न

  • Promise<void>

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

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

इवेंट

onActionIgnored

Chrome 70 और इसके बाद के वर्शन 
chrome.webRequest.onActionIgnored.addListener(
  callback: function,
)

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

पैरामीटर

  • कॉलबैक

    फ़ंक्शन

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

    (details: object)=>void

    • विवरण

      ऑब्जेक्ट

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

        IgnoredActionType

        प्रस्तावित कार्रवाई जिसे अनदेखा किया गया था.

      • requestId

        स्ट्रिंग

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

onAuthRequired

chrome.webRequest.onAuthRequired.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnAuthRequiredOptions[],
)

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

पैरामीटर

  • कॉलबैक

    फ़ंक्शन

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

    (details: object,asyncCallback?: function)=>BlockingResponse|undefined

    • विवरण

      ऑब्जेक्ट

      • चैलेंजर

        ऑब्जेक्ट

        पुष्टि करने का अनुरोध करने वाला सर्वर.

        • होस्ट

          स्ट्रिंग

        • पोर्ट

          नंबर

      • documentId

        स्ट्रिंग

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

        अनुरोध करने वाले दस्तावेज़ का यूयूआईडी.

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

        दस्तावेज़ की लाइफ़साइकल.

      • frameId

        नंबर

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

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

        जिस फ़्रेम में अनुरोध किया गया.

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

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

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

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

      • isProxy

        boolean

        प्रॉक्सी-Authenticate के लिए सही, WWW-Authenticate के लिए गलत.

      • method

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        नंबर

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

      • रेल्म

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

        सर्वर की ओर से उपलब्ध कराया गया पुष्टि करने का क्षेत्र, अगर कोई हो.

      • requestId

        स्ट्रिंग

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

      • responseHeaders

        HttpHeaders ज़रूरी नहीं

        इस रिस्पॉन्स के साथ मिले एचटीटीपी रिस्पॉन्स हेडर.

      • स्कीम

        स्ट्रिंग

        पुष्टि करने की स्कीम, जैसे कि बेसिक या डाइजेस्ट.

      • statusCode

        नंबर

        Chrome 43+

        सर्वर से मिला स्टैंडर्ड एचटीटीपी स्टेटस कोड.

      • statusLine

        स्ट्रिंग

        रिस्पॉन्स की एचटीटीपी स्टेटस लाइन या एचटीटीपी/0.9 रिस्पॉन्स के लिए 'HTTP/0.9 200 OK' स्ट्रिंग या अगर कोई हेडर न हो, तो खाली स्ट्रिंग.

      • tabId

        नंबर

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

      • timeStamp

        नंबर

        इस सिग्नल के ट्रिगर होने का समय, यानी epoch के बाद से मिलीसेकंड में.

      • टाइप

        ResourceType

        अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.

      • यूआरएल

        स्ट्रिंग

    • asyncCallback

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

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

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

      (response: BlockingResponse)=>void

    • returns

      BlockingResponse|तय नहीं है

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

  • फ़िल्‍टर

    RequestFilter

  • extraInfoSpec

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

onBeforeRedirect

chrome.webRequest.onBeforeRedirect.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnBeforeRedirectOptions[],
)

तब ट्रिगर होता है, जब सर्वर से शुरू किया गया रीडायरेक्ट होने वाला होता है.

पैरामीटर

  • कॉलबैक

    फ़ंक्शन

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

    (details: object)=>void

    • विवरण

      ऑब्जेक्ट

      • documentId

        स्ट्रिंग

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

        अनुरोध करने वाले दस्तावेज़ का यूयूआईडी.

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

        दस्तावेज़ की लाइफ़साइकल.

      • frameId

        नंबर

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

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

        जिस फ़्रेम में अनुरोध किया गया.

      • fromCache

        boolean

        इससे पता चलता है कि यह रिस्पॉन्स, डिस्क की कैश मेमोरी से फ़ेच किया गया था या नहीं.

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

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

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

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

      • ip

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

        सर्वर का वह आईपी पता जिस पर अनुरोध भेजा गया. ध्यान दें कि यह एक लिटरल आईपीवी6 पता हो सकता है.

      • method

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        नंबर

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

      • redirectUrl

        स्ट्रिंग

        नया यूआरएल.

      • requestId

        स्ट्रिंग

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

      • responseHeaders

        HttpHeaders ज़रूरी नहीं

        इस रीडायरेक्ट के साथ मिले एचटीटीपी रिस्पॉन्स हेडर.

      • statusCode

        नंबर

        सर्वर से मिला स्टैंडर्ड एचटीटीपी स्टेटस कोड.

      • statusLine

        स्ट्रिंग

        रिस्पॉन्स की एचटीटीपी स्टेटस लाइन या एचटीटीपी/0.9 रिस्पॉन्स के लिए 'HTTP/0.9 200 OK' स्ट्रिंग या अगर कोई हेडर न हो, तो खाली स्ट्रिंग.

      • tabId

        नंबर

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

      • timeStamp

        नंबर

        इस सिग्नल के ट्रिगर होने का समय, यानी epoch के बाद से मिलीसेकंड में.

      • टाइप

        ResourceType

        अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.

      • यूआरएल

        स्ट्रिंग

  • फ़िल्‍टर

    RequestFilter

  • extraInfoSpec

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

onBeforeRequest

chrome.webRequest.onBeforeRequest.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnBeforeRequestOptions[],
)

तब सक्रिय होता है, जब कोई अनुरोध आने वाला होता है.

पैरामीटर

  • कॉलबैक

    फ़ंक्शन

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

    (details: object)=>BlockingResponse|undefined

    • विवरण

      ऑब्जेक्ट

      • documentId

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

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

        अनुरोध करने वाले दस्तावेज़ का यूयूआईडी.

      • documentLifecycle

        extensionTypes.DocumentLifecycle ज़रूरी नहीं

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

        दस्तावेज़ की लाइफ़साइकल.

      • frameId

        नंबर

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

      • frameType

        extensionTypes.FrameType ज़रूरी नहीं

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

        जिस फ़्रेम में अनुरोध किया गया.

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

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

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

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

      • method

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        नंबर

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

      • requestBody

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

        इसमें एचटीटीपी अनुरोध का मुख्य डेटा शामिल होता है. यह सिर्फ़ तब दिया जाता है, जब extraInfospec में 'requestBody' शामिल हो.

        • गड़बड़ी

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

          अनुरोध के मुख्य हिस्से का डेटा हासिल करते समय दिखने वाली गड़बड़ियां.

        • formData

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

          अगर अनुरोध का तरीका POST है और मुख्य हिस्सा UTF8 में एन्कोड किए गए की-वैल्यू पेयर का एक क्रम है, जो मल्टीपार्ट/फ़ॉर्म-डेटा या ऐप्लिकेशन/x-www-form-urlencoded के रूप में एन्कोड किए गए हैं, तो यह शब्दकोश मौजूद होता है और हर कुंजी के लिए उस कुंजी के सभी वैल्यू की सूची शामिल होती है. अगर डेटा किसी दूसरे तरह के मीडिया का है या अगर वह गलत है, तो शब्दकोश मौजूद नहीं है. उदाहरण के लिए, इस डिक्शनरी की वैल्यू {'key': ['value1', 'value2']} है.

        • रॉ

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

          अगर अनुरोध का तरीका PUT या POST है और मुख्य हिस्से को formData में पहले से पार्स नहीं किया गया है, तो पार्स न किए गए अनुरोध के मुख्य हिस्से को इस अरे में शामिल किया जाता है.

      • requestId

        स्ट्रिंग

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

      • tabId

        नंबर

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

      • timeStamp

        नंबर

        इस सिग्नल के ट्रिगर होने का समय, यानी epoch के बाद से मिलीसेकंड में.

      • टाइप

        ResourceType

        अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.

      • यूआरएल

        स्ट्रिंग

    • returns

      BlockingResponse|तय नहीं है

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

  • फ़िल्‍टर

    RequestFilter

  • extraInfoSpec

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

onBeforeSendHeaders

chrome.webRequest.onBeforeSendHeaders.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnBeforeSendHeadersOptions[],
)

अनुरोध के हेडर उपलब्ध होने पर, एचटीटीपी अनुरोध भेजने से पहले सक्रिय किया जाता है. सर्वर से टीसीपी कनेक्शन बनाए जाने के बाद, लेकिन कोई एचटीटीपी डेटा भेजे जाने से पहले ऐसा हो सकता है.

पैरामीटर

  • कॉलबैक

    फ़ंक्शन

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

    (details: object)=>BlockingResponse|undefined

    • विवरण

      ऑब्जेक्ट

      • documentId

        स्ट्रिंग

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

        अनुरोध करने वाले दस्तावेज़ का यूयूआईडी.

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

        दस्तावेज़ की लाइफ़साइकल.

      • frameId

        नंबर

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

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

        जिस फ़्रेम में अनुरोध किया गया.

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

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

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

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

      • method

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        नंबर

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

      • requestHeaders

        HttpHeaders ज़रूरी नहीं

        इस अनुरोध के साथ भेजे जाने वाले एचटीटीपी अनुरोध के हेडर.

      • requestId

        स्ट्रिंग

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

      • tabId

        नंबर

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

      • timeStamp

        नंबर

        इस सिग्नल के ट्रिगर होने का समय, यानी epoch के बाद से मिलीसेकंड में.

      • टाइप

        ResourceType

        अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.

      • यूआरएल

        स्ट्रिंग

    • returns

      BlockingResponse|तय नहीं है

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

  • फ़िल्‍टर

    RequestFilter

  • extraInfoSpec

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

onCompleted

chrome.webRequest.onCompleted.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnCompletedOptions[],
)

अनुरोध पूरा होने पर सक्रिय होता है.

पैरामीटर

  • कॉलबैक

    फ़ंक्शन

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

    (details: object)=>void

    • विवरण

      ऑब्जेक्ट

      • documentId

        स्ट्रिंग

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

        अनुरोध करने वाले दस्तावेज़ का यूयूआईडी.

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

        दस्तावेज़ की लाइफ़साइकल.

      • frameId

        नंबर

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

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

        जिस फ़्रेम में अनुरोध किया गया.

      • fromCache

        boolean

        इससे पता चलता है कि यह रिस्पॉन्स, डिस्क की कैश मेमोरी से फ़ेच किया गया था या नहीं.

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

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

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

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

      • ip

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

        सर्वर का वह आईपी पता जिस पर अनुरोध भेजा गया. ध्यान दें कि यह एक लिटरल आईपीवी6 पता हो सकता है.

      • method

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        नंबर

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

      • requestId

        स्ट्रिंग

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

      • responseHeaders

        HttpHeaders ज़रूरी नहीं

        इस रिस्पॉन्स के साथ मिले एचटीटीपी रिस्पॉन्स हेडर.

      • statusCode

        नंबर

        सर्वर से मिला स्टैंडर्ड एचटीटीपी स्टेटस कोड.

      • statusLine

        स्ट्रिंग

        रिस्पॉन्स की एचटीटीपी स्टेटस लाइन या एचटीटीपी/0.9 रिस्पॉन्स के लिए 'HTTP/0.9 200 OK' स्ट्रिंग या अगर कोई हेडर न हो, तो खाली स्ट्रिंग.

      • tabId

        नंबर

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

      • timeStamp

        नंबर

        इस सिग्नल के ट्रिगर होने का समय, यानी epoch के बाद से मिलीसेकंड में.

      • टाइप

        ResourceType

        अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.

      • यूआरएल

        स्ट्रिंग

  • फ़िल्‍टर

    RequestFilter

  • extraInfoSpec

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

onErrorOccurred

chrome.webRequest.onErrorOccurred.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnErrorOccurredOptions[],
)

कोई गड़बड़ी होने पर सक्रिय होता है.

पैरामीटर

  • कॉलबैक

    फ़ंक्शन

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

    (details: object)=>void

    • विवरण

      ऑब्जेक्ट

      • documentId

        स्ट्रिंग

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

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

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

        दस्तावेज़ की लाइफ़साइकल.

      • गड़बड़ी

        स्ट्रिंग

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

      • frameId

        नंबर

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

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

        जिस फ़्रेम में अनुरोध किया गया.

      • fromCache

        boolean

        इससे पता चलता है कि यह रिस्पॉन्स, डिस्क की कैश मेमोरी से फ़ेच किया गया था या नहीं.

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

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

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

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

      • ip

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

        सर्वर का वह आईपी पता जिस पर अनुरोध भेजा गया. ध्यान दें कि यह एक लिटरल आईपीवी6 पता हो सकता है.

      • method

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        नंबर

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

      • requestId

        स्ट्रिंग

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

      • tabId

        नंबर

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

      • timeStamp

        नंबर

        इस सिग्नल के ट्रिगर होने का समय, यानी epoch के बाद से मिलीसेकंड में.

      • टाइप

        ResourceType

        अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.

      • यूआरएल

        स्ट्रिंग

  • फ़िल्‍टर

    RequestFilter

  • extraInfoSpec

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

onHeadersReceived

chrome.webRequest.onHeadersReceived.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnHeadersReceivedOptions[],
)

अनुरोध के एचटीटीपी रिस्पॉन्स हेडर मिलने पर सक्रिय होता है.

पैरामीटर

  • कॉलबैक

    फ़ंक्शन

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

    (details: object)=>BlockingResponse|undefined

    • विवरण

      ऑब्जेक्ट

      • documentId

        स्ट्रिंग

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

        अनुरोध करने वाले दस्तावेज़ का यूयूआईडी.

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

        दस्तावेज़ की लाइफ़साइकल.

      • frameId

        नंबर

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

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

        जिस फ़्रेम में अनुरोध किया गया.

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

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

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

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

      • method

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        नंबर

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

      • requestId

        स्ट्रिंग

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

      • responseHeaders

        HttpHeaders ज़रूरी नहीं

        इस रिस्पॉन्स के साथ मिले एचटीटीपी रिस्पॉन्स हेडर.

      • statusCode

        नंबर

        Chrome 43+

        सर्वर से मिला स्टैंडर्ड एचटीटीपी स्टेटस कोड.

      • statusLine

        स्ट्रिंग

        रिस्पॉन्स की एचटीटीपी स्टेटस लाइन या एचटीटीपी/0.9 रिस्पॉन्स के लिए 'एचटीटीपी/0.9 200 OK' स्ट्रिंग. जैसे, ऐसे रिस्पॉन्स जिनके लिए स्टेटस लाइन उपलब्ध नहीं है.

      • tabId

        नंबर

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

      • timeStamp

        नंबर

        इस सिग्नल के ट्रिगर होने का समय, यानी epoch के बाद से मिलीसेकंड में.

      • टाइप

        ResourceType

        अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.

      • यूआरएल

        स्ट्रिंग

    • returns

      BlockingResponse|तय नहीं है

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

  • फ़िल्‍टर

    RequestFilter

  • extraInfoSpec

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

onResponseStarted

chrome.webRequest.onResponseStarted.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnResponseStartedOptions[],
)

रिस्पॉन्स के मुख्य हिस्से का पहला बाइट मिलने पर सक्रिय होता है. एचटीटीपी अनुरोधों के लिए, इसका मतलब है कि स्टेटस लाइन और रिस्पॉन्स हेडर उपलब्ध हैं.

पैरामीटर

  • कॉलबैक

    फ़ंक्शन

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

    (details: object)=>void

    • विवरण

      ऑब्जेक्ट

      • documentId

        स्ट्रिंग

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

        अनुरोध करने वाले दस्तावेज़ का यूयूआईडी.

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

        दस्तावेज़ की लाइफ़साइकल.

      • frameId

        नंबर

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

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

        जिस फ़्रेम में अनुरोध किया गया.

      • fromCache

        boolean

        इससे पता चलता है कि यह रिस्पॉन्स, डिस्क की कैश मेमोरी से फ़ेच किया गया था या नहीं.

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

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

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

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

      • ip

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

        सर्वर का वह आईपी पता जिस पर अनुरोध भेजा गया. ध्यान दें कि यह एक लिटरल आईपीवी6 पता हो सकता है.

      • method

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        नंबर

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

      • requestId

        स्ट्रिंग

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

      • responseHeaders

        HttpHeaders ज़रूरी नहीं

        इस रिस्पॉन्स के साथ मिले एचटीटीपी रिस्पॉन्स हेडर.

      • statusCode

        नंबर

        सर्वर से मिला स्टैंडर्ड एचटीटीपी स्टेटस कोड.

      • statusLine

        स्ट्रिंग

        रिस्पॉन्स की एचटीटीपी स्टेटस लाइन या एचटीटीपी/0.9 रिस्पॉन्स के लिए 'HTTP/0.9 200 OK' स्ट्रिंग या अगर कोई हेडर न हो, तो खाली स्ट्रिंग.

      • tabId

        नंबर

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

      • timeStamp

        नंबर

        इस सिग्नल के ट्रिगर होने का समय, यानी epoch के बाद से मिलीसेकंड में.

      • टाइप

        ResourceType

        अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.

      • यूआरएल

        स्ट्रिंग

  • फ़िल्‍टर

    RequestFilter

  • extraInfoSpec

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

onSendHeaders

chrome.webRequest.onSendHeaders.addListener(
  callback: function,
  filter: RequestFilter,
  extraInfoSpec?: OnSendHeadersOptions[],
)

यह डेटा, सर्वर पर अनुरोध भेजे जाने से ठीक पहले सक्रिय होता है (पिछले onBeforeSendHeaders कॉलबैक में बदलाव, onSendHeaders के चालू होने के समय तक दिखने लगते हैं).

पैरामीटर

  • कॉलबैक

    फ़ंक्शन

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

    (details: object)=>void

    • विवरण

      ऑब्जेक्ट

      • documentId

        स्ट्रिंग

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

        अनुरोध करने वाले दस्तावेज़ का यूयूआईडी.

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

        दस्तावेज़ की लाइफ़साइकल.

      • frameId

        नंबर

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

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

        जिस फ़्रेम में अनुरोध किया गया.

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

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

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

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

      • method

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        नंबर

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

      • requestHeaders

        HttpHeaders ज़रूरी नहीं

        इस अनुरोध के साथ भेजे गए एचटीटीपी अनुरोध के हेडर.

      • requestId

        स्ट्रिंग

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

      • tabId

        नंबर

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

      • timeStamp

        नंबर

        इस सिग्नल के ट्रिगर होने का समय, यानी epoch के बाद से मिलीसेकंड में.

      • टाइप

        ResourceType

        अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.

      • यूआरएल

        स्ट्रिंग

  • फ़िल्‍टर

    RequestFilter

  • extraInfoSpec

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