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

Jeff Posnick

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

बैकग्राउंड

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

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

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

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

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

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

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

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

Origin-Trial: token_obtained_from_signup

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

आधिकारिक ऑरिजिन ट्रायल टोकन के लिए रजिस्टर करने से पहले, फ़ॉरेन फ़ेच की सुविधा को आज़माने के लिए, अपने लोकल कंप्यूटर पर Chrome में chrome://flags/#enable-experimental-web-platform-features पर जाकर, "वेब प्लैटफ़ॉर्म की एक्सपेरिमेंटल सुविधाएं" फ़्लैग को चालू करें. कृपया ध्यान दें कि आपको 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"> डीओएम एलिमेंट की मदद से, सेवा वर्कर को रजिस्टर करने का एक और तरीका दिखाया जा सकता है. फ़िलहाल, 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 से किए गए अनुरोध, आपके हैंडलर को ट्रिगर नहीं करेंगे. अगर आपके पास किसी खास वजह से, सिर्फ़ रिमोट ऑरिजिन के सबसेट के लिए, फ़ॉरेन फ़ेच लॉजिक को ट्रिगर करने की ज़रूरत नहीं है, तो ऐरे में सिर्फ़ '*' को वैल्यू के तौर पर सेट किया जा सकता है. ऐसा करने पर, सभी ऑरिजिन को अनुमति दी जाएगी.

foreignfetch इवेंट हैंडलर

तीसरे पक्ष का सर्विस वर्कर इंस्टॉल करने और 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 देना ज़रूरी है, न कि Promise, जो Response के साथ रिज़ॉल्व होता है! प्रॉमिस चेन की मदद से अपना रिस्पॉन्स बनाया जा सकता है और उस चेन को 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 ट्विटर खाते के ज़रिए भी, बड़े बदलावों के बारे में जानकारी शेयर करेंगे.