क्रॉस-ऑरिजिन सर्विस वर्कर - फ़ॉरेन फ़ेच के साथ प्रयोग करना

जेफ़ पॉस्निक

Twitter GitHub होम पेज

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

बैकग्राउंड

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

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

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

• RESTful इंटरफ़ेस वाले एपीआई की सेवा देने वाली कंपनियां
• वेब फ़ॉन्ट देने वाली कंपनियां
• एनालिटिक्स कंपनी
• इमेज होस्टिंग की सेवा देने वाली कंपनियां
• सामान्य कॉन्टेंट डिलीवरी नेटवर्क

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

ज़रूरी शर्तें

ऑरिजिन ट्रायल टोकन

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

Origin-Trial: token_obtained_from_signup

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

किसी आधिकारिक ऑरिजिन ट्रायल टोकन के लिए रजिस्टर करने से पहले, विदेशी फ़ेच के साथ प्रयोग करने की सुविधा उपलब्ध कराने के लिए, chrome://flags/#enable-experimental-web-platform-features पर जाकर और "प्रयोग के तौर पर वेब प्लैटफ़ॉर्म की सुविधाएं" फ़्लैग को चालू करके, अपने स्थानीय कंप्यूटर के लिए Chrome की ज़रूरी शर्तों को बायपास किया जा सकता है. कृपया ध्यान दें कि आपको Chrome के हर उस इंस्टेंस में ऐसा करना होगा जिसे आपको अपने लोकल एक्सपेरिमेंट में इस्तेमाल करना है. हालांकि, ऑरिजिन ट्रायल टोकन के साथ यह सुविधा आपके सभी Chrome उपयोगकर्ताओं के लिए उपलब्ध रहेगी.

एचटीटीपीएस

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

फ़ॉरेन फ़ेच का इस्तेमाल करना

ऐसी ज़रूरी शर्तों के बारे में बात करते हैं, जो किसी विदेशी फ़ेच सर्विस वर्कर को शुरू करने और उसे चलाने के लिए ज़रूरी तकनीकी जानकारी के बारे में हैं.

अपने सर्विस वर्कर का रजिस्ट्रेशन करना

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

// You can't do this!
if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('service-worker.js');
}

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

यह समाधान एचटीटीपी हेडर के रूप में आता है. आपका सर्वर इसे किसी भी रिस्पॉन्स में शामिल कर सकता है:

Link: </service-worker.js>; rel="serviceworker"; scope="/"

आइए, उदाहरण के तौर पर दिए गए हेडर को इसके कॉम्पोनेंट में बांटते हैं. इनमें से हर एक को ; वर्ण से अलग किया गया है.

• </service-worker.js> ज़रूरी है और इसका इस्तेमाल आपकी सर्विस वर्कर फ़ाइल का पाथ बताने के लिए किया जाता है (/service-worker.js को अपनी स्क्रिप्ट के सही पाथ से बदलें). यह सीधे तौर पर scriptURL स्ट्रिंग से जुड़ा होता है, जिसे navigator.serviceWorker.register() को पहले पैरामीटर के तौर पर भेजा जाता है. वैल्यू को <> वर्णों में रखा जाना चाहिए (जैसा कि Link हेडर स्पेसिफ़िकेशन के मुताबिक ज़रूरी है). अगर दिया गया है, तो ऐब्सलूट यूआरएल के बजाय कोई रिलेटिव दिया गया है. ऐसे में, उसे रिस्पॉन्स की जगह के हिसाब से माना जाएगा.
• rel="serviceworker" भी ज़रूरी है. इसे अपनी पसंद के मुताबिक बनाने की ज़रूरत नहीं है.
• scope=/, स्कोप का एलान करना ज़रूरी नहीं है. यह options.scope स्ट्रिंग के बराबर है जिसे navigator.serviceWorker.register() में दूसरे पैरामीटर के तौर पर पास किया जा सकता है. इस्तेमाल के कई उदाहरणों के लिए, आपके पास डिफ़ॉल्ट स्कोप का इस्तेमाल करने का विकल्प होता है. इसलिए, अगर आपको इसकी ज़रूरत है, तो बेझिझक इसे छोड़ दें. Link हेडर रजिस्ट्रेशन पर भी वही पाबंदियां लागू होती हैं जो ज़्यादा से ज़्यादा अनुमति वाले दायरे में आती हैं. साथ ही, Service-Worker-Allowed हेडर की मदद से उन पाबंदियों में छूट देने की सुविधा भी लागू होती है.

"परंपरागत" सर्विस वर्कर रजिस्ट्रेशन की तरह ही, Link हेडर का इस्तेमाल करने से सर्विस वर्कर इंस्टॉल होगा. इसका इस्तेमाल, रजिस्टर किए गए स्कोप के हिसाब से किए जाने वाले अगले अनुरोध पर किया जाएगा. विशेष हेडर वाले जवाब के मुख्य भाग का इस्तेमाल ऐसे ही किया जाएगा. साथ ही, बाहरी सर्विस वर्कर के इंस्टॉलेशन को पूरा करने का इंतज़ार किए बिना ही, यह पेज पर तुरंत उपलब्ध हो जाएगा.

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

Link: </service-worker.js>; rel="serviceworker"
Origin-Trial: token_obtained_from_signup

ध्यान दें: सर्विस वर्कर विशेषता के सटीक पाठकों ने शायद <link rel="serviceworker"> DOM एलिमेंट के ज़रिए सर्विस वर्कर का रजिस्ट्रेशन करने के लिए, किसी दूसरे तरीके पर ध्यान दिया हो. फ़िलहाल, Chrome में <link> पर आधारित रजिस्ट्रेशन की सुविधा उसी ऑरिजिन ट्रायल से कंट्रोल की जा रही है जो Link हेडर के लिए दी गई है. इसलिए, यह सुविधा फ़िलहाल डिफ़ॉल्ट रूप से चालू नहीं की गई है. जब बात फ़ॉरेन फ़ेच रजिस्ट्रेशन के मामले में होती है, तो <link> पर आधारित रजिस्ट्रेशन की सीमाएं, JavaScript पर आधारित रजिस्ट्रेशन की तरह ही होती हैं. इसलिए, इस लेख में बताए गए मकसद के लिए, आपको Link हेडर का इस्तेमाल करना चाहिए.

रजिस्ट्रेशन डीबग किया जा रहा है

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

क्या सही रिस्पॉन्स हेडर भेजे जा रहे हैं?

विदेशी फ़ेच सर्विस वर्कर को रजिस्टर करने के लिए, आपको अपने डोमेन पर होस्ट किए गए संसाधन के जवाब पर एक लिंक हेडर सेट करना होगा. इसकी जानकारी इस पोस्ट में पहले दी गई है. ऑरिजिन ट्रायल की अवधि के दौरान, यह मानते हुए कि आपने chrome://flags/#enable-experimental-web-platform-features सेट नहीं किया है, आपको Origin-Trial रिस्पॉन्स हेडर भी सेट करना होगा. DevTools के नेटवर्क पैनल में मौजूद एंट्री देखकर, इस बात की पुष्टि की जा सकती है कि आपका वेब सर्वर उन हेडर को सेट कर रहा है:

क्या फ़ॉरेन फ़ेच सर्विस वर्कर सही तरीके से रजिस्टर किया गया है?

आप DevTools के ऐप्लिकेशन पैनल में सर्विस वर्कर की पूरी सूची देखकर, इसके दायरे के साथ-साथ, मौजूदा सर्विस वर्कर के रजिस्ट्रेशन की भी पुष्टि कर सकते हैं. "सभी दिखाएं" विकल्प चुनना न भूलें, क्योंकि डिफ़ॉल्ट रूप से आपको सिर्फ़ मौजूदा ऑरिजिन के लिए सर्विस वर्कर दिखेंगे.

इंस्टॉल इवेंट हैंडलर

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

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

self.addEventListener('install', event => {
    event.registerForeignFetch({
    scopes: [self.registration.scope], // or some sub-scope
    origins: ['*'] // or ['https://example.com']
    });
});

कॉन्फ़िगरेशन के दो विकल्प हैं, दोनों ज़रूरी हैं:

• scopes एक या उससे ज़्यादा स्ट्रिंग का कलेक्शन लेता है. इनमें से हर स्ट्रिंग, उन अनुरोधों का स्कोप दिखाती है जो foreignfetch इवेंट को ट्रिगर करेंगे. लेकिन इंतज़ार करें, आप सोच रहे होंगे, मैंने सर्विस वर्कर रजिस्ट्रेशन के दौरान पहले ही एक दायरा तय कर लिया है! यह सच है और यह कि पूरा दायरा अब भी काम का है. यहां बताया गया हर दायरा, सर्विस वर्कर के पूरे दायरे के बराबर या उसका सब-स्कोप होना चाहिए. यहां दिए गए अतिरिक्त दायरे से जुड़ी पाबंदियों की मदद से, सभी मकसद के लिए इस्तेमाल किए जाने वाले ऐसे सर्विस वर्कर डिप्लॉय किए जा सकते हैं जो पहले पक्ष के fetch इवेंट (आपकी अपनी साइट से किए गए अनुरोध के लिए) और तीसरे पक्ष के foreignfetch इवेंट (दूसरे डोमेन से किए गए अनुरोधों के लिए) दोनों को मैनेज कर सकें. साथ ही, यह साफ़ तौर पर बता सकते हैं कि आपके बड़े दायरे के किसी सबसेट को ही foreignfetch ट्रिगर करना चाहिए. व्यावहारिक रूप से, अगर आप किसी ऐसे सर्विस वर्कर को डिप्लॉय कर रहे हैं जो सिर्फ़ तीसरे पक्ष, foreignfetch इवेंट को मैनेज करने के लिए काम करता है, तो आपको ऐसे किसी एक एक्सप्लिसिट स्कोप का इस्तेमाल करना होगा जो आपके सर्विस वर्कर के पूरे स्कोप के बराबर है. ऊपर दिए गए उदाहरण में self.registration.scope वैल्यू का इस्तेमाल करके, ऐसा ही किया जाएगा.
• origins एक या उससे ज़्यादा स्ट्रिंग का कलेक्शन भी लेता है. इससे आपको अपने foreignfetch हैंडलर को सिर्फ़ कुछ खास डोमेन के अनुरोधों का जवाब देने के लिए सीमित किया जा सकता है. उदाहरण के लिए, अगर आपने साफ़ तौर पर 'https://example.com' को अनुमति दी है, तो https://example.com/path/to/page.html पर होस्ट किए गए पेज से किसी ऐसे संसाधन के लिए किया गया अनुरोध जो बाहरी फ़ेच वाले स्कोप से उपलब्ध कराया गया है, आपके लिए फ़ॉरेन फ़ेच हैंडलर को ट्रिगर करेगा. हालांकि, https://random-domain.com/path/to/page.html से किए गए अनुरोध, आपके हैंडलर को ट्रिगर नहीं करेंगे. अगर आपके पास रिमोट ऑरिजिन के सबसेट के लिए, सिर्फ़ फ़ॉरेन फ़ेच लॉजिक को ट्रिगर करने की कोई खास वजह न हो, तो कलेक्शन में सिर्फ़ '*' को एक वैल्यू के तौर पर ट्रिगर किया जा सकता है. साथ ही, सभी ऑरिजिन को अनुमति दी जाएगी.

फ़ॉरेनफ़ैच इवेंट हैंडलर

आपने तीसरे पक्ष के सर्विस वर्कर को इंस्टॉल कर लिया है और उसे registerForeignFetch() के ज़रिए कॉन्फ़िगर कर लिया गया है. इसलिए, अब यह आपके सर्वर से ऐसे क्रॉस-ऑरिजिन सबरिसॉर्स के अनुरोध देख पाएगा जो फ़ॉरेन फ़ेच के दायरे में आते हैं.

ध्यान दें: Chrome के मौजूदा तरीके को लागू करने में एक और पाबंदी है: सिर्फ़ सीओआरएस से सुरक्षित किए गए हेडर वाले GET, POST या HEAD अनुरोध ही विदेशी फ़ेच की ज़रूरी शर्तें पूरी करते हैं. यह पाबंदी, फ़ॉरेन फ़ेच की खास बातों का हिस्सा नहीं है. इसलिए, Chrome के आने वाले वर्शन में इसमें छूट दी जा सकती है.

पहले पक्ष के सर्विस वर्कर में, हर अनुरोध एक fetch इवेंट को ट्रिगर करता है जिसका जवाब आपके सर्विस वर्कर को दिया जाता है. हमारे तीसरे पक्ष के सर्विस वर्कर को, foreignfetch नाम के इवेंट को थोड़ा अलग हैंडल करने का मौका दिया जाता है. सैद्धान्तिक तौर पर, ये दो इवेंट काफ़ी हद तक मिलते-जुलते हैं. इनकी मदद से, आपको आने वाले अनुरोध की जांच करने का मौका मिलता है. साथ ही, यह विकल्प respondWith() की मदद से इसका जवाब देता है:

self.addEventListener('foreignfetch', event => {
    // Assume that requestLogic() is a custom function that takes
    // a Request and returns a Promise which resolves with a Response.
    event.respondWith(
    requestLogic(event.request).then(response => {
        return {
        response: response,
        // Omit to origin to return an opaque response.
        // With this set, the client will receive a CORS response.
        origin: event.origin,
        // Omit headers unless you need additional header filtering.
        // With this set, only Content-Type will be exposed.
        headers: ['Content-Type']
        };
    })
    );
});

सैद्धांतिक समानताओं के बावजूद, respondWith() को ForeignFetchEvent पर कॉल करने के व्यवहार में कुछ अंतर होते हैं. respondWith() के लिए सिर्फ़ Response (या Response से रिज़ॉल्व होने वाला Promise) देने के बजाय, आपको FetchEvent के साथ करने वाला कोई Promise पास करना होगा, जो ForeignFetchEvent के respondWith() के लिए खास प्रॉपर्टी वाले ऑब्जेक्ट से रिज़ॉल्व होता है:

• response ज़रूरी है. साथ ही, इसे Response ऑब्जेक्ट पर सेट करना ज़रूरी है, जिसे अनुरोध करने वाले क्लाइंट को दिखाया जाएगा. अगर आप मान्य Response के अलावा कोई और जानकारी देते हैं, तो क्लाइंट का अनुरोध नेटवर्क की गड़बड़ी के साथ खत्म कर दिया जाएगा. fetch इवेंट हैंडलर में respondWith() को कॉल करने के उलट, आपको यहां Response देना ज़रूरी है, न कि ऐसा Promise जो Response के साथ रिज़ॉल्व होता हो! प्रॉमिस चेन के ज़रिए अपना रिस्पॉन्स बनाया जा सकता है और उस चेन को foreignfetch के respondWith() के पैरामीटर के तौर पर पास किया जा सकता है. हालांकि, चेन को ऐसे ऑब्जेक्ट के साथ रिज़ॉल्व करना होगा जिसमें response प्रॉपर्टी, Response ऑब्जेक्ट पर सेट हो. इसका डेमो, ऊपर दिए गए कोड सैंपल में देखा जा सकता है.
• origin इस्तेमाल करना ज़रूरी नहीं है. इसका इस्तेमाल यह तय करने के लिए किया जाता है कि मिलने वाला रिस्पॉन्स ओपेक है या नहीं. अगर आपने इसे छोड़ दिया, तो जवाब ओपेक होगा. साथ ही, क्लाइंट को जवाब के मुख्य हिस्से और हेडर का सीमित ऐक्सेस मिलेगा. अगर अनुरोध mode: 'cors' का इस्तेमाल करके किया गया था, तो ओपेक रिस्पॉन्स न मिलने पर, उसे गड़बड़ी माना जाएगा. हालांकि, अगर रिमोट क्लाइंट के ऑरिजिन के बराबर कोई स्ट्रिंग वैल्यू तय की जाती है (जिसे event.origin से हासिल किया जा सकता है), तो इसका मतलब है कि क्लाइंट को सीओआरएस की सुविधा वाले रिस्पॉन्स देने के लिए साफ़ तौर पर ऑप्ट-इन किया जा रहा है.
• headers भी ज़रूरी नहीं है. यह सिर्फ़ तब काम आता है, जब origin के बारे में जानकारी दी जा रही हो और सीओआरएस रिस्पॉन्स दिया जा रहा हो. डिफ़ॉल्ट रूप से, आपके जवाब में सिर्फ़ सीओआरएस से सुरक्षित की गई सूची में शामिल रिस्पॉन्स हेडर सूची के हेडर शामिल किए जाएंगे. अगर आपको मिलने वाली वैल्यू को और फ़िल्टर करना है, तो हेडर एक या उससे ज़्यादा हेडर नामों की सूची बनाते हैं. यह रिस्पॉन्स में उन हेडर का इस्तेमाल, अनुमति वाली सूची के तौर पर करता है जिन्हें रिस्पॉन्स में दिखाना है. इसकी मदद से, सीओआरएस में ऑप्ट-इन किया जा सकता है. साथ ही, संभावित संवेदनशील रिस्पॉन्स हेडर, रिमोट क्लाइंट को सीधे तौर पर नहीं दिख पाएंगे.

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

self.addEventListener('foreignfetch', event => {
    // The new Request will have credentials omitted by default.
    const noCredentialsRequest = new Request(event.request.url);
    event.respondWith(
    // Replace with your own request logic as appropriate.
    fetch(noCredentialsRequest)
        .catch(() => caches.match(noCredentialsRequest))
        .then(response => ({response}))
    );
});

क्लाइंट के लिए ध्यान रखने वाली बातें

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

ऐसे क्लाइंट जिनके पास पहले पक्ष के सर्विस वर्कर हैं

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

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

पहले पक्ष के सर्विस वर्कर में, क्रॉस-ऑरिजिन रिसॉर्स पाने के लिए fetch() का इस्तेमाल करने से, सही फ़ॉरेन फ़ेच सर्विस वर्कर ट्रिगर हो जाएगा. इसका मतलब है कि नीचे दिए गए कोड से आपके foreignfetch हैंडलर का फ़ायदा मिल सकता है:

// Inside a client's first-party service-worker.js:
self.addEventListener('fetch', event => {
    // If event.request is under your foreign fetch service worker's
    // scope, this will trigger your foreignfetch handler.
    event.respondWith(fetch(event.request));
});

इसी तरह, अगर पहले-पक्ष के फ़ेच हैंडलर मौजूद हैं, लेकिन वे आपके क्रॉस-ऑरिजिन रिसॉर्स के अनुरोधों को हैंडल करते समय, event.respondWith() को कॉल नहीं करते हैं, तो अनुरोध आपके foreignfetch हैंडलर को अपने-आप "मिल जाएगा":

// Inside a client's first-party service-worker.js:
self.addEventListener('fetch', event => {
    if (event.request.mode === 'same-origin') {
    event.respondWith(localRequestLogic(event.request));
    }

    // Since event.respondWith() isn't called for cross-origin requests,
    // any foreignfetch handlers scoped to the request will get a chance
    // to provide a response.
});

अगर पहले पक्ष का fetch हैंडलर event.respondWith() को कॉल करता है, लेकिन आपके बाहरी फ़ेच स्कोप के तहत किसी संसाधन का अनुरोध करने के लिए fetch() का इस्तेमाल नहीं करता है, तो आपके फ़ॉरेन फ़ेच सर्विस वर्कर को अनुरोध हैंडल करने का मौका नहीं मिलेगा.

ऐसे क्लाइंट जिनके पास अपना सर्विस वर्कर नहीं है

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

इन सभी बातों को एक साथ दिखाना: जहां क्लाइंट कोई जवाब ढूंढते हैं

ऊपर दी गई जानकारी को ध्यान में रखते हुए, हम सोर्स की हैरारकी इकट्ठा कर सकते हैं. क्लाइंट, इसका इस्तेमाल किसी क्रॉस-ऑरिजिन अनुरोध का जवाब देने के लिए करेगा.

1. पहले पक्ष के सर्विस वर्कर का fetch हैंडलर (अगर मौजूद हो)
2. तीसरे पक्ष के सर्विस वर्कर का foreignfetch हैंडलर (अगर मौजूद हो और सिर्फ़ क्रॉस-ऑरिजिन अनुरोधों के लिए)
3. ब्राउज़र की एचटीटीपी कैश मेमोरी (अगर कोई नया जवाब मौजूद है)
4. नेटवर्क

ब्राउज़र ऊपर से शुरू होता है और सर्विस वर्कर के लागू होने के आधार पर, सूची में तब तक नीचे चलता रहेगा, जब तक उसे रिस्पॉन्स के लिए कोई सोर्स नहीं मिल जाता.

ज़्यादा जानें

• फ़ॉरेन फ़ेच करने के बारे में जानकारी
• सैंपल कोड और लाइव डेमो
• सर्विस वर्कर से जुड़ी समस्या को ट्रैक करने वाला टूल

अप-टू-डेट रहें

हम डेवलपर से मिले सुझावों पर ध्यान दे रहे हैं. इसलिए, Chrome में विदेशी फ़ेच ऑरिजिन ट्रायल को लागू करने की प्रोसेस में बदलाव हो सकता है. हम इनलाइन बदलावों के ज़रिए इस पोस्ट को अप-टू-डेट रखेंगे और नीचे दिए गए खास बदलावों पर ध्यान देंगे. हम @chromiumdev Twitter खाते के ज़रिए भी बड़े बदलावों के बारे में जानकारी शेयर करेंगे.