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

Jeff Posnick

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

बैकग्राउंड

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

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

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

• 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']
        };
    })
    );
});

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

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

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

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

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

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

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