कंपनी का ब्यौरा
ट्रैफ़िक पर नज़र रखने और उसका विश्लेषण करने के साथ-साथ, फ़्लाइट के दौरान अनुरोधों को रोकने, ब्लॉक करने या उनमें बदलाव करने के लिए, chrome.webRequest
API का इस्तेमाल करें.
अनुमतियां
webRequest
मेनिफ़ेस्ट
वेब अनुरोध एपीआई का इस्तेमाल करने के लिए, आपको एक्सटेंशन मेनिफ़ेस्ट में "webRequest"
अनुमति के बारे में जानकारी देनी होगी. साथ ही, आपको होस्ट की ज़रूरी अनुमतियों के बारे में भी बताना होगा. किसी सब-रिसॉर्स के अनुरोध को रोकने के लिए, एक्सटेंशन के पास अनुरोध किए गए यूआरएल और उसे शुरू करने वाले यूआरएल, दोनों का ऐक्सेस होना चाहिए. उदाहरण के लिए:
{
"name": "My extension",
...
"permissions": [
"webRequest"
],
"host_permissions": [
"*://*.google.com/*"
],
...
}
Chrome 108 से, "webRequest"
और "webRequestAuthProvider"
अनुमतियों का इस्तेमाल करने पर, आपके पास onAuthRequired
इवेंट के लिए एसिंक्रोनस तरीके से क्रेडेंशियल देने का विकल्प है.
अनुरोधों का लाइफ़ साइकल
वेब अनुरोध एपीआई, इवेंट के ऐसे सेट के बारे में बताता है जो वेब अनुरोध की लाइफ़ साइकल के हिसाब से होता है. इन इवेंट का इस्तेमाल, ट्रैफ़िक पर नज़र रखने और उसका विश्लेषण करने के लिए किया जा सकता है. कुछ सिंक्रोनस इवेंट आपको अनुरोध को रोकने, ब्लॉक करने या उसमें बदलाव करने की सुविधा देते हैं.
पूरे होने वाले अनुरोधों के इवेंट लाइफ़ साइकल की जानकारी यहां दी गई है. इसके बाद, इवेंट की परिभाषाएं दी गई हैं:
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
में स्ट्रिंग तय की जा सकती है. अगर साफ़ तौर पर अनुरोध किया गया हो, तो ही अनुरोध के डेटा के बारे में ज़्यादा जानकारी देने के लिए इसका इस्तेमाल किया जाता है.
क्रियान्वयन विवरण
वेब अनुरोध एपीआई का इस्तेमाल करने वाले एक्सटेंशन को डेवलप करते समय, लागू करने से जुड़ी कई जानकारी को समझना ज़रूरी हो सकता है:
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
इसमें फ़ॉर्म डेटा में दिया गया डेटा शामिल होता है. यूआरएल कोड में बदले गए फ़ॉर्म के लिए, अगर डेटा utf-8 स्ट्रिंग है, तो इसे स्ट्रिंग के तौर पर सेव किया जाता है. अगर ऐसा नहीं है, तो इसे arrayBuffer के तौर पर सेव किया जाता है. फ़ॉर्म-डेटा के लिए, यह arrayBuffer है. अगर फ़ाइल का नाम, फ़ॉर्म-डेटा की मदद से अपलोड किया जाता है, तो यह फ़ाइल नाम वाली स्ट्रिंग होती है.
Enum
ArrayBuffer
स्ट्रिंग
HttpHeaders
एचटीटीपी हेडर का कलेक्शन. हर हेडर को एक डिक्शनरी के तौर पर दिखाया जाता है. इसमें name
बटन और value
या binaryValue
बटन होते हैं.
टाइप
ऑब्जेक्ट[]
प्रॉपर्टी
-
binaryValue
नंबर[] ज़रूरी नहीं
एचटीटीपी हेडर का मान, अगर इसे UTF-8 से नहीं दिखाया जा सकता, जिसे अलग-अलग बाइट वैल्यू (0..255) के तौर पर स्टोर किया जाता है.
-
नाम
स्ट्रिंग
एचटीटीपी हेडर का नाम.
-
value
स्ट्रिंग ज़रूरी नहीं
एचटीटीपी हेडर की वैल्यू, अगर उसे UTF-8 से दिखाया जा सकता है.
IgnoredActionType
Enum
"request_headers"
"response_headers"
OnAuthRequiredOptions
Enum
"responseHeaders"
से यह पता चलता है कि रिस्पॉन्स हेडर को इवेंट में शामिल किया जाना चाहिए.
"ब्लॉक करना"
यह बताता है कि अनुरोध को तब तक ब्लॉक किया गया है, जब तक कॉलबैक फ़ंक्शन वापस नहीं आता.
"asyncsync"
यह बताता है कि कॉलबैक फ़ंक्शन को एसिंक्रोनस तरीके से मैनेज किया जाता है.
"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.
OnBeforeRedirectOptions
Enum
"responseHeaders"
से यह पता चलता है कि रिस्पॉन्स हेडर को इवेंट में शामिल किया जाना चाहिए.
"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.
OnBeforeRequestOptions
Enum
"ब्लॉक करना"
यह बताता है कि अनुरोध को तब तक ब्लॉक किया गया है, जब तक कॉलबैक फ़ंक्शन वापस नहीं आता.
"requestBody"
यह बताता है कि अनुरोध के मुख्य हिस्से को इवेंट में शामिल किया जाना चाहिए.
"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.
OnBeforeSendHeadersOptions
Enum
"requestHeaders"
यह बताता है कि अनुरोध का हेडर, इवेंट में शामिल किया जाना चाहिए.
"ब्लॉक करना"
यह बताता है कि अनुरोध को तब तक ब्लॉक किया गया है, जब तक कॉलबैक फ़ंक्शन वापस नहीं आता.
"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.
OnCompletedOptions
Enum
"responseHeaders"
से यह पता चलता है कि रिस्पॉन्स हेडर को इवेंट में शामिल किया जाना चाहिए.
"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.
OnErrorOccurredOptions
वैल्यू
"extraHeaders"
OnHeadersReceivedOptions
Enum
"ब्लॉक करना"
यह बताता है कि अनुरोध को तब तक ब्लॉक किया गया है, जब तक कॉलबैक फ़ंक्शन वापस नहीं आता.
"responseHeaders"
से यह पता चलता है कि रिस्पॉन्स हेडर को इवेंट में शामिल किया जाना चाहिए.
"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.
OnResponseStartedOptions
Enum
"responseHeaders"
से यह पता चलता है कि रिस्पॉन्स हेडर को इवेंट में शामिल किया जाना चाहिए.
"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.
OnSendHeadersOptions
Enum
"requestHeaders"
यह बताता है कि अनुरोध का हेडर, इवेंट में शामिल किया जाना चाहिए.
"extraHeaders"
इससे पता चलता है कि हेडर, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) का उल्लंघन कर सकते हैं.
RequestFilter
webRequest इवेंट पर लागू करने के लिए फ़िल्टर के बारे में बताने वाला ऑब्जेक्ट.
प्रॉपर्टी
-
tabId
नंबर ज़रूरी नहीं
-
प्रकार
ResourceType[] ज़रूरी नहीं
अनुरोध टाइप की सूची. ऐसे अनुरोध जो किसी भी टाइप से मेल नहीं खाते, उन्हें फ़िल्टर करके बाहर कर दिया जाएगा.
-
urls
स्ट्रिंग[]
यूआरएल या यूआरएल पैटर्न की सूची. ऐसे अनुरोध जो किसी भी यूआरएल से मेल नहीं खाते, उन्हें फ़िल्टर करके बाहर कर दिया जाएगा.
-
windowId
नंबर ज़रूरी नहीं
ResourceType
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.webRequest.onActionIgnored.addListener(
callback: function,
)
यह तब ट्रिगर होता है, जब एक्सटेंशन के ज़रिए, नेटवर्क अनुरोध में किए जाने वाले बदलाव को अनदेखा किया जाता है. अन्य एक्सटेंशन के साथ विरोध होने पर ऐसा होता है.
पैरामीटर
-
कॉलबैक
function
callback
पैरामीटर ऐसा दिखता है:(details: object) => void
-
जानकारी
ऑब्जेक्ट
-
ऐक्शन गेम
प्रस्तावित कार्रवाई जिसे अनदेखा किया गया था.
-
requestId
स्ट्रिंग
अनुरोध का आईडी. ब्राउज़र सेशन में अनुरोध का आईडी यूनीक होता है. नतीजे के तौर पर, इनका इस्तेमाल एक ही अनुरोध के अलग-अलग इवेंट को जोड़ने के लिए किया जा सकता है.
-
-
onAuthRequired
chrome.webRequest.onAuthRequired.addListener(
callback: function,
filter: RequestFilter,
extraInfoSpec?: OnAuthRequiredOptions[],
)
पुष्टि करने में कोई गड़बड़ी मिलने पर ट्रिगर होता है. लिसनर के पास तीन विकल्प होते हैं: वह पुष्टि करने के क्रेडेंशियल दे सकता है, वह अनुरोध को रद्द कर सकता है और गड़बड़ी वाला पेज दिखा सकता है. इसके अलावा, वह चैलेंज पर कोई कार्रवाई नहीं कर सकता है. अगर गलत उपयोगकर्ता क्रेडेंशियल दिए गए हैं, तो एक ही अनुरोध के लिए इस नंबर को एक से ज़्यादा बार कॉल किया जा सकता है. ध्यान दें, extraInfoSpec
पैरामीटर में 'blocking'
या 'asyncBlocking'
मोड में से सिर्फ़ एक के बारे में बताया जाना चाहिए.
पैरामीटर
-
कॉलबैक
function
callback
पैरामीटर ऐसा दिखता है:(details: object, asyncCallback?: function) => BlockingResponse | undefined
-
जानकारी
ऑब्जेक्ट
-
चैलेंजर
ऑब्जेक्ट
पुष्टि करने का अनुरोध करने वाला सर्वर.
-
होस्ट
स्ट्रिंग
-
पोर्ट
नंबर
-
-
documentId
स्ट्रिंग
Chrome 106 और इसके बाद के वर्शनअनुरोध करने वाले दस्तावेज़ का यूयूआईडी.
-
documentLifecycleChrome 106 और इसके बाद के वर्शन
दस्तावेज़ की लाइफ़साइकल.
-
frameId
नंबर
वैल्यू 0 बताती है कि अनुरोध मुख्य फ़्रेम में किया गया है. पॉज़िटिव वैल्यू, उस सबफ़्रेम के आईडी को दिखाती है जिसमें अनुरोध किया गया है. अगर किसी (सब-)फ़्रेम का दस्तावेज़ लोड किया गया है (
type
का साइज़main_frame
याsub_frame
है), तोframeId
इस फ़्रेम के आईडी को दिखाता है, न कि आउटर फ़्रेम का आईडी. फ़्रेम आईडी, टैब में यूनीक होते हैं. -
frameTypeChrome 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 के बाद से मिलीसेकंड में.
-
टाइप
अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.
-
यूआरएल
स्ट्रिंग
-
-
asyncCallback
फ़ंक्शन ज़रूरी नहीं
Chrome 58 और इसके बाद के वर्शनasyncCallback
पैरामीटर ऐसा दिखता है:(response: BlockingResponse) => void
-
जवाब
-
-
returns
BlockingResponse | इसके बारे में जानकारी नहीं है
अगर "extraInfoSpecification" पैरामीटर में "ब्लॉक करें" के बारे में बताया गया है, तो इवेंट लिसनर को इस तरह का ऑब्जेक्ट दिखाना चाहिए.
-
-
फ़िल्टर
-
extraInfoSpec
OnAuthRequiredOptions[] ज़रूरी नहीं है
onBeforeRedirect
chrome.webRequest.onBeforeRedirect.addListener(
callback: function,
filter: RequestFilter,
extraInfoSpec?: OnBeforeRedirectOptions[],
)
तब ट्रिगर होता है, जब सर्वर से शुरू किया गया रीडायरेक्ट होने वाला होता है.
पैरामीटर
-
कॉलबैक
function
callback
पैरामीटर ऐसा दिखता है:(details: object) => void
-
जानकारी
ऑब्जेक्ट
-
documentId
स्ट्रिंग
Chrome 106 और इसके बाद के वर्शनअनुरोध करने वाले दस्तावेज़ का यूयूआईडी.
-
documentLifecycleChrome 106 और इसके बाद के वर्शन
दस्तावेज़ की लाइफ़साइकल.
-
frameId
नंबर
वैल्यू 0 बताती है कि अनुरोध मुख्य फ़्रेम में किया गया है. पॉज़िटिव वैल्यू, उस सबफ़्रेम के आईडी को दिखाती है जिसमें अनुरोध किया गया है. अगर किसी (सब-)फ़्रेम का दस्तावेज़ लोड किया गया है (
type
का साइज़main_frame
याsub_frame
है), तोframeId
इस फ़्रेम के आईडी को दिखाता है, न कि आउटर फ़्रेम का आईडी. फ़्रेम आईडी, टैब में यूनीक होते हैं. -
frameTypeChrome 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 के बाद से मिलीसेकंड में.
-
टाइप
अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.
-
यूआरएल
स्ट्रिंग
-
-
-
फ़िल्टर
-
extraInfoSpec
OnBeforeRedirectOptions[] ज़रूरी नहीं है
onBeforeRequest
chrome.webRequest.onBeforeRequest.addListener(
callback: function,
filter: RequestFilter,
extraInfoSpec?: OnBeforeRequestOptions[],
)
तब सक्रिय होता है, जब कोई अनुरोध आने वाला होता है.
पैरामीटर
-
कॉलबैक
function
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 के बाद से मिलीसेकंड में.
-
टाइप
अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.
-
यूआरएल
स्ट्रिंग
-
-
returns
BlockingResponse | इसके बारे में जानकारी नहीं है
अगर "extraInfoSpecification" पैरामीटर में "ब्लॉक करें" के बारे में बताया गया है, तो इवेंट लिसनर को इस तरह का ऑब्जेक्ट दिखाना चाहिए.
-
-
फ़िल्टर
-
extraInfoSpec
OnBeforeRequestOptions[] ज़रूरी नहीं है
onBeforeSendHeaders
chrome.webRequest.onBeforeSendHeaders.addListener(
callback: function,
filter: RequestFilter,
extraInfoSpec?: OnBeforeSendHeadersOptions[],
)
अनुरोध के हेडर उपलब्ध होने पर, एचटीटीपी अनुरोध भेजने से पहले सक्रिय किया जाता है. सर्वर से टीसीपी कनेक्शन बनाए जाने के बाद, लेकिन कोई एचटीटीपी डेटा भेजे जाने से पहले ऐसा हो सकता है.
पैरामीटर
-
कॉलबैक
function
callback
पैरामीटर ऐसा दिखता है:(details: object) => BlockingResponse | undefined
-
जानकारी
ऑब्जेक्ट
-
documentId
स्ट्रिंग
Chrome 106 और इसके बाद के वर्शनअनुरोध करने वाले दस्तावेज़ का यूयूआईडी.
-
documentLifecycleChrome 106 और इसके बाद के वर्शन
दस्तावेज़ की लाइफ़साइकल.
-
frameId
नंबर
वैल्यू 0 बताती है कि अनुरोध मुख्य फ़्रेम में किया गया है. पॉज़िटिव वैल्यू, उस सबफ़्रेम के आईडी को दिखाती है जिसमें अनुरोध किया गया है. अगर किसी (सब-)फ़्रेम का दस्तावेज़ लोड किया गया है (
type
का साइज़main_frame
याsub_frame
है), तोframeId
इस फ़्रेम के आईडी को दिखाता है, न कि आउटर फ़्रेम का आईडी. फ़्रेम आईडी, टैब में यूनीक होते हैं. -
frameTypeChrome 106 और इसके बाद के वर्शन
जिस फ़्रेम में अनुरोध किया गया.
-
शुरू करने वाला
स्ट्रिंग ज़रूरी नहीं
Chrome 63 और इसके बाद के वर्शनवह ऑरिजिन जहां से अनुरोध किया गया था. इसमें रीडायरेक्ट से कोई बदलाव नहीं होता. अगर यह ओपेक ऑरिजिन है, तो 'null' स्ट्रिंग का इस्तेमाल किया जाएगा.
-
method
स्ट्रिंग
एचटीटीपी का स्टैंडर्ड तरीका.
-
parentDocumentId
स्ट्रिंग ज़रूरी नहीं
Chrome 106 और इसके बाद के वर्शनउस पैरंट दस्तावेज़ का यूयूआईडी जिसके पास यह फ़्रेम है. अगर कोई पैरंट न हो, तो यह सेट नहीं होता है.
-
parentFrameId
नंबर
अनुरोध भेजने वाले फ़्रेम को रैप करने वाले फ़्रेम का आईडी. अगर कोई पैरंट फ़्रेम मौजूद नहीं है, तो -1 पर सेट करें.
-
requestHeaders
HttpHeaders ज़रूरी नहीं
इस अनुरोध के साथ भेजे जाने वाले एचटीटीपी अनुरोध के हेडर.
-
requestId
स्ट्रिंग
अनुरोध का आईडी. ब्राउज़र सेशन में अनुरोध का आईडी यूनीक होता है. नतीजे के तौर पर, इनका इस्तेमाल एक ही अनुरोध के अलग-अलग इवेंट को जोड़ने के लिए किया जा सकता है.
-
tabId
नंबर
उस टैब का आईडी जिसमें अनुरोध किया जाता है. अगर अनुरोध किसी टैब से नहीं जुड़ा है, तो -1 पर सेट करें.
-
timeStamp
नंबर
इस सिग्नल के ट्रिगर होने का समय, यानी epoch के बाद से मिलीसेकंड में.
-
टाइप
अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.
-
यूआरएल
स्ट्रिंग
-
-
returns
BlockingResponse | इसके बारे में जानकारी नहीं है
अगर "extraInfoSpecification" पैरामीटर में "ब्लॉक करें" के बारे में बताया गया है, तो इवेंट लिसनर को इस तरह का ऑब्जेक्ट दिखाना चाहिए.
-
-
फ़िल्टर
-
extraInfoSpec
OnBeforeSendHeadersOptions[] ज़रूरी नहीं
onCompleted
chrome.webRequest.onCompleted.addListener(
callback: function,
filter: RequestFilter,
extraInfoSpec?: OnCompletedOptions[],
)
अनुरोध पूरा होने पर सक्रिय होता है.
पैरामीटर
-
कॉलबैक
function
callback
पैरामीटर ऐसा दिखता है:(details: object) => void
-
जानकारी
ऑब्जेक्ट
-
documentId
स्ट्रिंग
Chrome 106 और इसके बाद के वर्शनअनुरोध करने वाले दस्तावेज़ का यूयूआईडी.
-
documentLifecycleChrome 106 और इसके बाद के वर्शन
दस्तावेज़ की लाइफ़साइकल.
-
frameId
नंबर
वैल्यू 0 बताती है कि अनुरोध मुख्य फ़्रेम में किया गया है. पॉज़िटिव वैल्यू, उस सबफ़्रेम के आईडी को दिखाती है जिसमें अनुरोध किया गया है. अगर किसी (सब-)फ़्रेम का दस्तावेज़ लोड किया गया है (
type
का साइज़main_frame
याsub_frame
है), तोframeId
इस फ़्रेम के आईडी को दिखाता है, न कि आउटर फ़्रेम का आईडी. फ़्रेम आईडी, टैब में यूनीक होते हैं. -
frameTypeChrome 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 के बाद से मिलीसेकंड में.
-
टाइप
अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.
-
यूआरएल
स्ट्रिंग
-
-
-
फ़िल्टर
-
extraInfoSpec
OnCompletedOptions[] ज़रूरी नहीं
onErrorOccurred
chrome.webRequest.onErrorOccurred.addListener(
callback: function,
filter: RequestFilter,
extraInfoSpec?: OnErrorOccurredOptions[],
)
कोई गड़बड़ी होने पर सक्रिय होता है.
पैरामीटर
-
कॉलबैक
function
callback
पैरामीटर ऐसा दिखता है:(details: object) => void
-
जानकारी
ऑब्जेक्ट
-
documentId
स्ट्रिंग
Chrome 106 और इसके बाद के वर्शनअनुरोध करने वाले दस्तावेज़ का यूयूआईडी. अगर अनुरोध किसी फ़्रेम के नेविगेशन के लिए किया गया है, तो यह वैल्यू मौजूद नहीं होती है.
-
documentLifecycleChrome 106 और इसके बाद के वर्शन
दस्तावेज़ की लाइफ़साइकल.
-
गड़बड़ी
स्ट्रिंग
गड़बड़ी की जानकारी. इस बात की कोई गारंटी नहीं है कि यह स्ट्रिंग, रिलीज़ के बीच पुराने सिस्टम के साथ काम करती नहीं है. आपको इसकी सामग्री के आधार पर पार्स और कार्रवाई नहीं करनी चाहिए.
-
frameId
नंबर
वैल्यू 0 बताती है कि अनुरोध मुख्य फ़्रेम में किया गया है. पॉज़िटिव वैल्यू, उस सबफ़्रेम के आईडी को दिखाती है जिसमें अनुरोध किया गया है. अगर किसी (सब-)फ़्रेम का दस्तावेज़ लोड किया गया है (
type
का साइज़main_frame
याsub_frame
है), तोframeId
इस फ़्रेम के आईडी को दिखाता है, न कि आउटर फ़्रेम का आईडी. फ़्रेम आईडी, टैब में यूनीक होते हैं. -
frameTypeChrome 106 और इसके बाद के वर्शन
जिस फ़्रेम में अनुरोध किया गया.
-
fromCache
boolean
इससे पता चलता है कि यह रिस्पॉन्स, डिस्क की कैश मेमोरी से फ़ेच किया गया था या नहीं.
-
शुरू करने वाला
स्ट्रिंग ज़रूरी नहीं
Chrome 63 और इसके बाद के वर्शनवह ऑरिजिन जहां से अनुरोध किया गया था. इसमें रीडायरेक्ट से कोई बदलाव नहीं होता. अगर यह ओपेक ऑरिजिन है, तो 'null' स्ट्रिंग का इस्तेमाल किया जाएगा.
-
ip
स्ट्रिंग ज़रूरी नहीं
सर्वर का वह आईपी पता जिस पर अनुरोध भेजा गया. ध्यान दें कि यह एक लिटरल आईपीवी6 पता हो सकता है.
-
method
स्ट्रिंग
एचटीटीपी का स्टैंडर्ड तरीका.
-
parentDocumentId
स्ट्रिंग ज़रूरी नहीं
Chrome 106 और इसके बाद के वर्शनउस पैरंट दस्तावेज़ का यूयूआईडी जिसके पास यह फ़्रेम है. अगर कोई पैरंट न हो, तो यह सेट नहीं होता है.
-
parentFrameId
नंबर
अनुरोध भेजने वाले फ़्रेम को रैप करने वाले फ़्रेम का आईडी. अगर कोई पैरंट फ़्रेम मौजूद नहीं है, तो -1 पर सेट करें.
-
requestId
स्ट्रिंग
अनुरोध का आईडी. ब्राउज़र सेशन में अनुरोध का आईडी यूनीक होता है. नतीजे के तौर पर, इनका इस्तेमाल एक ही अनुरोध के अलग-अलग इवेंट को जोड़ने के लिए किया जा सकता है.
-
tabId
नंबर
उस टैब का आईडी जिसमें अनुरोध किया जाता है. अगर अनुरोध किसी टैब से नहीं जुड़ा है, तो -1 पर सेट करें.
-
timeStamp
नंबर
इस सिग्नल के ट्रिगर होने का समय, यानी epoch के बाद से मिलीसेकंड में.
-
टाइप
अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.
-
यूआरएल
स्ट्रिंग
-
-
-
फ़िल्टर
-
extraInfoSpec
OnErrorOccurredOptions[] ज़रूरी नहीं
onHeadersReceived
chrome.webRequest.onHeadersReceived.addListener(
callback: function,
filter: RequestFilter,
extraInfoSpec?: OnHeadersReceivedOptions[],
)
अनुरोध के एचटीटीपी रिस्पॉन्स हेडर मिलने पर सक्रिय होता है.
पैरामीटर
-
कॉलबैक
function
callback
पैरामीटर ऐसा दिखता है:(details: object) => BlockingResponse | undefined
-
जानकारी
ऑब्जेक्ट
-
documentId
स्ट्रिंग
Chrome 106 और इसके बाद के वर्शनअनुरोध करने वाले दस्तावेज़ का यूयूआईडी.
-
documentLifecycleChrome 106 और इसके बाद के वर्शन
दस्तावेज़ की लाइफ़साइकल.
-
frameId
नंबर
वैल्यू 0 बताती है कि अनुरोध मुख्य फ़्रेम में किया गया है. पॉज़िटिव वैल्यू, उस सबफ़्रेम के आईडी को दिखाती है जिसमें अनुरोध किया गया है. अगर किसी (सब-)फ़्रेम का दस्तावेज़ लोड किया गया है (
type
का साइज़main_frame
याsub_frame
है), तोframeId
इस फ़्रेम के आईडी को दिखाता है, न कि आउटर फ़्रेम का आईडी. फ़्रेम आईडी, टैब में यूनीक होते हैं. -
frameTypeChrome 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 के बाद से मिलीसेकंड में.
-
टाइप
अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.
-
यूआरएल
स्ट्रिंग
-
-
returns
BlockingResponse | इसके बारे में जानकारी नहीं है
अगर "extraInfoSpecification" पैरामीटर में "ब्लॉक करें" के बारे में बताया गया है, तो इवेंट लिसनर को इस तरह का ऑब्जेक्ट दिखाना चाहिए.
-
-
फ़िल्टर
-
extraInfoSpec
OnHeadersReceivedOptions[] ज़रूरी नहीं
onResponseStarted
chrome.webRequest.onResponseStarted.addListener(
callback: function,
filter: RequestFilter,
extraInfoSpec?: OnResponseStartedOptions[],
)
रिस्पॉन्स के मुख्य हिस्से का पहला बाइट मिलने पर सक्रिय होता है. एचटीटीपी अनुरोधों के लिए, इसका मतलब है कि स्टेटस लाइन और रिस्पॉन्स हेडर उपलब्ध हैं.
पैरामीटर
-
कॉलबैक
function
callback
पैरामीटर ऐसा दिखता है:(details: object) => void
-
जानकारी
ऑब्जेक्ट
-
documentId
स्ट्रिंग
Chrome 106 और इसके बाद के वर्शनअनुरोध करने वाले दस्तावेज़ का यूयूआईडी.
-
documentLifecycleChrome 106 और इसके बाद के वर्शन
दस्तावेज़ की लाइफ़साइकल.
-
frameId
नंबर
वैल्यू 0 बताती है कि अनुरोध मुख्य फ़्रेम में किया गया है. पॉज़िटिव वैल्यू, उस सबफ़्रेम के आईडी को दिखाती है जिसमें अनुरोध किया गया है. अगर किसी (सब-)फ़्रेम का दस्तावेज़ लोड किया गया है (
type
का साइज़main_frame
याsub_frame
है), तोframeId
इस फ़्रेम के आईडी को दिखाता है, न कि आउटर फ़्रेम का आईडी. फ़्रेम आईडी, टैब में यूनीक होते हैं. -
frameTypeChrome 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 के बाद से मिलीसेकंड में.
-
टाइप
अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.
-
यूआरएल
स्ट्रिंग
-
-
-
फ़िल्टर
-
extraInfoSpec
OnResponseStartedOptions[] ज़रूरी नहीं
onSendHeaders
chrome.webRequest.onSendHeaders.addListener(
callback: function,
filter: RequestFilter,
extraInfoSpec?: OnSendHeadersOptions[],
)
यह डेटा, सर्वर पर अनुरोध भेजे जाने से ठीक पहले सक्रिय होता है (पिछले onBeforeSendHeaders कॉलबैक में बदलाव, onSendHeaders के चालू होने के समय तक दिखने लगते हैं).
पैरामीटर
-
कॉलबैक
function
callback
पैरामीटर ऐसा दिखता है:(details: object) => void
-
जानकारी
ऑब्जेक्ट
-
documentId
स्ट्रिंग
Chrome 106 और इसके बाद के वर्शनअनुरोध करने वाले दस्तावेज़ का यूयूआईडी.
-
documentLifecycleChrome 106 और इसके बाद के वर्शन
दस्तावेज़ की लाइफ़साइकल.
-
frameId
नंबर
वैल्यू 0 बताती है कि अनुरोध मुख्य फ़्रेम में किया गया है. पॉज़िटिव वैल्यू, उस सबफ़्रेम के आईडी को दिखाती है जिसमें अनुरोध किया गया है. अगर किसी (सब-)फ़्रेम का दस्तावेज़ लोड किया गया है (
type
का साइज़main_frame
याsub_frame
है), तोframeId
इस फ़्रेम के आईडी को दिखाता है, न कि आउटर फ़्रेम का आईडी. फ़्रेम आईडी, टैब में यूनीक होते हैं. -
frameTypeChrome 106 और इसके बाद के वर्शन
जिस फ़्रेम में अनुरोध किया गया.
-
शुरू करने वाला
स्ट्रिंग ज़रूरी नहीं
Chrome 63 और इसके बाद के वर्शनवह ऑरिजिन जहां से अनुरोध किया गया था. इसमें रीडायरेक्ट से कोई बदलाव नहीं होता. अगर यह ओपेक ऑरिजिन है, तो 'null' स्ट्रिंग का इस्तेमाल किया जाएगा.
-
method
स्ट्रिंग
एचटीटीपी का स्टैंडर्ड तरीका.
-
parentDocumentId
स्ट्रिंग ज़रूरी नहीं
Chrome 106 और इसके बाद के वर्शनउस पैरंट दस्तावेज़ का यूयूआईडी जिसके पास यह फ़्रेम है. अगर कोई पैरंट न हो, तो यह सेट नहीं होता है.
-
parentFrameId
नंबर
अनुरोध भेजने वाले फ़्रेम को रैप करने वाले फ़्रेम का आईडी. अगर कोई पैरंट फ़्रेम मौजूद नहीं है, तो -1 पर सेट करें.
-
requestHeaders
HttpHeaders ज़रूरी नहीं
इस अनुरोध के साथ भेजे गए एचटीटीपी अनुरोध के हेडर.
-
requestId
स्ट्रिंग
अनुरोध का आईडी. ब्राउज़र सेशन में अनुरोध का आईडी यूनीक होता है. नतीजे के तौर पर, इनका इस्तेमाल एक ही अनुरोध के अलग-अलग इवेंट को जोड़ने के लिए किया जा सकता है.
-
tabId
नंबर
उस टैब का आईडी जिसमें अनुरोध किया जाता है. अगर अनुरोध किसी टैब से नहीं जुड़ा है, तो -1 पर सेट करें.
-
timeStamp
नंबर
इस सिग्नल के ट्रिगर होने का समय, यानी epoch के बाद से मिलीसेकंड में.
-
टाइप
अनुरोध किए गए संसाधन का इस्तेमाल कैसे किया जाएगा.
-
यूआरएल
स्ट्रिंग
-
-
-
फ़िल्टर
-
extraInfoSpec
OnSendHeadersOptions[] ज़रूरी नहीं