chrome.webRequest

ब्यौरा

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

अनुमतियां

webRequest

मेनिफ़ेस्ट

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

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

Chrome 108 से, "webRequest" और "webRequestAuthProvider" अनुमतियों का इस्तेमाल करके, onAuthRequired इवेंट के लिए क्रेडेंशियल एसिंक्रोनस तरीके से दिए जा सकते हैं.

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

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

यहां इवेंट के लाइफ़ साइकल के बारे में बताया गया है. इसके बाद, इवेंट की परिभाषाएं दी गई हैं:

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

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

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

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

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

  • अनुमति देना
  • Cache-Control
  • कनेक्शन
  • Content-Length
  • होस्ट
  • If-Modified-Since
  • If-None-Match
  • If-Range
  • Partial-Data
  • Pragma
  • Proxy-Authorization
  • Proxy-Connection
  • Transfer-Encoding

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

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

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

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

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

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

  • Accept-Language
  • Accept-Encoding
  • रेफ़रर
  • कुकी

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, HTTP/3 पर WebTransport के हैंडशेक अनुरोध को इंटरसेप्ट करने की सुविधा देता है. हैंडशेक, एचटीटीपी कनेक्ट अनुरोध के ज़रिए किया जाता है. इसलिए, इसका फ़्लो एचटीटीपी पर आधारित webRequest मॉडल के मुताबिक होता है. ध्यान दें कि:

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

कॉन्सेप्ट

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

अनुरोध आईडी

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

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

वेब अनुरोध के लिए इवेंट लिसनर रजिस्टर करने के लिए, सामान्य 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 देखें.
टैब आईडी
यह किसी टैब का आइडेंटिफ़ायर होता है.
विंडो आईडी
यह किसी विंडो का आइडेंटिफ़ायर होता है.

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

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

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

web_accessible_resources

जब कोई एक्सटेंशन, webRequest API का इस्तेमाल करके किसी सार्वजनिक संसाधन के अनुरोध को ऐसे संसाधन पर रीडायरेक्ट करता है जिसे वेब से ऐक्सेस नहीं किया जा सकता, तो उसे ब्लॉक कर दिया जाता है. इससे गड़बड़ी होती है. ऊपर दी गई जानकारी तब भी लागू होती है, जब वेब पर ऐक्सेस नहीं की जा सकने वाली संसाधन फ़ाइल का मालिकाना हक, रीडायरेक्ट करने वाले एक्सटेंशन के पास हो. declarativeWebRequest एपीआई के साथ इस्तेमाल किए जाने वाले संसाधनों के बारे में बताने के लिए, मेनिफ़ेस्ट फ़ाइल में "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"]
);

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

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 API को आज़माने के लिए, chrome-extension-samples रिपॉज़िटरी से webRequest का सैंपल इंस्टॉल करें.

टाइप

BlockingResponse

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

प्रॉपर्टी

  • authCredentials

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

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

    • पासवर्ड

      स्ट्रिंग

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

      स्ट्रिंग

  • अभी नहीं

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

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

  • redirectUrl

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

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

  • requestHeaders

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

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

  • responseHeaders

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

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

FormDataItem

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

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

Enum

ArrayBuffer

स्ट्रिंग

HttpHeaders

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

टाइप

object[]

प्रॉपर्टी

  • binaryValue

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

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

  • नाम

    स्ट्रिंग

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

  • मान

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

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

IgnoredActionType

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

Enum

"redirect"

"request_headers"

"response_headers"

"auth_credentials"

OnAuthRequiredOptions

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

Enum

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

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

"asyncBlocking"
इससे पता चलता है कि कॉलबैक फ़ंक्शन को एसिंक्रोनस तरीके से हैंडल किया जाता है.

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

OnBeforeRedirectOptions

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

Enum

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

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

OnBeforeRequestOptions

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

Enum

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

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

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

OnBeforeSendHeadersOptions

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

Enum

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

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

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

OnCompletedOptions

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

Enum

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

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

OnErrorOccurredOptions

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

मान

"extraHeaders"

OnHeadersReceivedOptions

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

Enum

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

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

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

OnResponseStartedOptions

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

Enum

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

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

OnSendHeadersOptions

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

Enum

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

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

RequestFilter

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

प्रॉपर्टी

  • tabId

    number ज़रूरी नहीं

  • प्रकार

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

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

  • यूआरएल

    string[]

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

  • windowId

    number ज़रूरी नहीं

ResourceType

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

Enum

"main_frame"
इस विकल्प से, संसाधन को मुख्य फ़्रेम के तौर पर सेट किया जाता है.

"sub_frame"
इस पैरामीटर की वैल्यू से पता चलता है कि संसाधन एक सब फ़्रेम है.

"stylesheet"
यह रिसॉर्स को स्टाइलशीट के तौर पर तय करता है.

"script"
इस विकल्प का इस्तेमाल करके, रिसोर्स को स्क्रिप्ट के तौर पर तय किया जाता है.

"image"
इससे रिसोर्स को इमेज के तौर पर तय किया जाता है.

"font"
इससे संसाधन को फ़ॉन्ट के तौर पर तय किया जाता है.

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

"xmlhttprequest"
इस संसाधन को XMLHttpRequest के तौर पर तय करता है.

"ping"
इस विकल्प का इस्तेमाल करके, संसाधन को पिंग के तौर पर तय किया जाता है.

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

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

"websocket"
इस विकल्प से, संसाधन को WebSocket के तौर पर तय किया जाता है.

"webbundle"
इससे संसाधन को WebBundle के तौर पर तय किया जाता है.

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

UploadData

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

प्रॉपर्टी

  • बाइट

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

    डेटा की कॉपी वाला ArrayBuffer.

  • फ़ाइल

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

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

प्रॉपर्टी

MAX_HANDLER_BEHAVIOR_CHANGED_CALLS_PER_10_MINUTES

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

मान

20

तरीके

handlerBehaviorChanged()

प्रॉमिस 
chrome.webRequest.handlerBehaviorChanged(
  callback?: function,
): Promise<void>

जब 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 और इसके बाद के वर्शन

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

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

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

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

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

      • isProxy

        बूलियन

        Proxy-Authenticate के लिए सही और WWW-Authenticate के लिए गलत.

      • तरीका

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        संख्या

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

      • रेल्म

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

        अगर सर्वर ने पुष्टि करने का कोई दायरा तय किया है, तो यह कुकी उस दायरे की जानकारी देती है.

      • requestId

        स्ट्रिंग

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

      • responseHeaders

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

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

      • स्कीम

        स्ट्रिंग

        पुष्टि करने की स्कीम, जैसे कि Basic या Digest.

      • statusCode

        संख्या

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

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

      • statusLine

        स्ट्रिंग

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

      • tabId

        संख्या

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

      • timeStamp

        संख्या

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

      • टाइप

        ResourceType

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

      • url

        स्ट्रिंग

    • asyncCallback

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

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

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

      (response: BlockingResponse) => void

    • returns

      BlockingResponse | undefined

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

  • फ़िल्टर करें

    RequestFilter

  • extraInfoSpec

    OnAuthRequiredOptions[] optional

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

        बूलियन

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

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

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

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

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

      • ip

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

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

      • तरीका

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        संख्या

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

      • redirectUrl

        स्ट्रिंग

        नया यूआरएल.

      • requestId

        स्ट्रिंग

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

      • responseHeaders

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

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

      • statusCode

        संख्या

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

      • statusLine

        स्ट्रिंग

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

      • tabId

        संख्या

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

      • timeStamp

        संख्या

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

      • टाइप

        ResourceType

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

      • url

        स्ट्रिंग

  • फ़िल्टर करें

    RequestFilter

  • extraInfoSpec

    OnBeforeRedirectOptions[] optional

onBeforeRequest

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

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

पैरामीटर

  • कॉलबैक

    फ़ंक्शन

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

    (details: object) => BlockingResponse | undefined

    • विवरण

      ऑब्जेक्ट

      • documentId

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

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

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

      • documentLifecycle

        extensionTypes.DocumentLifecycle optional

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

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

      • frameId

        संख्या

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

      • frameType

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

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

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

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

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

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

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

      • तरीका

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        संख्या

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

      • requestBody

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

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

        • गड़बड़ी

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

          अनुरोध के मुख्य हिस्से का डेटा पाने में गड़बड़ियां.

        • formData

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

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

        • रॉ

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

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

      • requestId

        स्ट्रिंग

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

      • tabId

        संख्या

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

      • timeStamp

        संख्या

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

      • टाइप

        ResourceType

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

      • url

        स्ट्रिंग

    • returns

      BlockingResponse | undefined

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

  • फ़िल्टर करें

    RequestFilter

  • extraInfoSpec

    OnBeforeRequestOptions[] optional

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 और इसके बाद के वर्शन

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

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

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

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

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

      • तरीका

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        संख्या

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

      • requestHeaders

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

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

      • requestId

        स्ट्रिंग

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

      • tabId

        संख्या

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

      • timeStamp

        संख्या

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

      • टाइप

        ResourceType

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

      • url

        स्ट्रिंग

    • returns

      BlockingResponse | undefined

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

  • फ़िल्टर करें

    RequestFilter

  • extraInfoSpec

    OnBeforeSendHeadersOptions[] optional

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

        बूलियन

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

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

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

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

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

      • ip

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

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

      • तरीका

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        संख्या

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

      • requestId

        स्ट्रिंग

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

      • responseHeaders

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

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

      • statusCode

        संख्या

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

      • statusLine

        स्ट्रिंग

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

      • tabId

        संख्या

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

      • timeStamp

        संख्या

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

      • टाइप

        ResourceType

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

      • url

        स्ट्रिंग

  • फ़िल्टर करें

    RequestFilter

  • extraInfoSpec

    OnCompletedOptions[] optional

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

        बूलियन

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

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

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

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

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

      • ip

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

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

      • तरीका

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        संख्या

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

      • requestId

        स्ट्रिंग

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

      • tabId

        संख्या

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

      • timeStamp

        संख्या

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

      • टाइप

        ResourceType

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

      • url

        स्ट्रिंग

  • फ़िल्टर करें

    RequestFilter

  • extraInfoSpec

    OnErrorOccurredOptions[] optional

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 और इसके बाद के वर्शन

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

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

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

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

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

      • तरीका

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        संख्या

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

      • requestId

        स्ट्रिंग

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

      • responseHeaders

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

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

      • statusCode

        संख्या

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

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

      • statusLine

        स्ट्रिंग

        जवाब की एचटीटीपी स्टेटस लाइन या एचटीटीपी/0.9 जवाबों के लिए 'HTTP/0.9 200 OK' स्ट्रिंग (यानी कि ऐसे जवाब जिनमें स्टेटस लाइन नहीं होती).

      • tabId

        संख्या

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

      • timeStamp

        संख्या

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

      • टाइप

        ResourceType

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

      • url

        स्ट्रिंग

    • returns

      BlockingResponse | undefined

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

  • फ़िल्टर करें

    RequestFilter

  • extraInfoSpec

    OnHeadersReceivedOptions[] optional

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

        बूलियन

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

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

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

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

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

      • ip

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

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

      • तरीका

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        संख्या

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

      • requestId

        स्ट्रिंग

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

      • responseHeaders

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

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

      • statusCode

        संख्या

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

      • statusLine

        स्ट्रिंग

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

      • tabId

        संख्या

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

      • timeStamp

        संख्या

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

      • टाइप

        ResourceType

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

      • url

        स्ट्रिंग

  • फ़िल्टर करें

    RequestFilter

  • extraInfoSpec

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

onSendHeaders

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

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

पैरामीटर

  • कॉलबैक

    फ़ंक्शन

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

    (details: object) => void

    • विवरण

      ऑब्जेक्ट

      • documentId

        स्ट्रिंग

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

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

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

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

      • frameId

        संख्या

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

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

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

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

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

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

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

      • तरीका

        स्ट्रिंग

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

      • parentDocumentId

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

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

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

      • parentFrameId

        संख्या

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

      • requestHeaders

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

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

      • requestId

        स्ट्रिंग

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

      • tabId

        संख्या

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

      • timeStamp

        संख्या

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

      • टाइप

        ResourceType

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

      • url

        स्ट्रिंग

  • फ़िल्टर करें

    RequestFilter

  • extraInfoSpec

    OnSendHeadersOptions[] optional