पक्का करें कि आपके सेवा वर्कर को पता हो कि कुछ हिस्से का जवाब मांगे जाने पर क्या करना है.
कुछ एचटीटीपी अनुरोधों में Range: हेडर होता है. इससे पता चलता है कि पूरे रिसॉर्स में से सिर्फ़ एक हिस्सा दिखाया जाना चाहिए. आम तौर पर, इनका इस्तेमाल ऑडियो या वीडियो कॉन्टेंट को स्ट्रीम करने के लिए किया जाता है. इससे, रीमोट फ़ाइल का पूरा अनुरोध करने के बजाय, मीडिया के छोटे हिस्सों को मांग पर लोड किया जा सकता है.
सर्विस वर्कर, JavaScript कोड होता है. यह आपके वेब ऐप्लिकेशन और नेटवर्क के बीच काम करता है. यह नेटवर्क से बाहर भेजे जाने वाले अनुरोधों को रोक सकता है और उनके लिए जवाब जनरेट कर सकता है.
पहले, रेंज रिक्वेस्ट और सर्विस वर्कर एक साथ काम नहीं करते थे. अपने सेवा वर्कर में खराब नतीजों से बचने के लिए, खास कदम उठाने ज़रूरी हैं. हालांकि, अब इस स्थिति में बदलाव हो रहा है. सही तरीके से काम करने वाले ब्राउज़र में, सर्विस वर्कर के ज़रिए भेजे जाने पर, रेंज रिक्वेस्ट "बस काम करेगा".
समस्या क्या है?
यहां दिए गए fetch इवेंट लिसनर वाले सेवा वर्कर पर विचार करें. यह हर आने वाले अनुरोध को स्वीकार करता है और उसे नेटवर्क पर भेजता है:
self.addEventListener('fetch', (event) => {
// The Range: header will not pass through in
// browsers that behave incorrectly.
event.respondWith(fetch(event.request));
});
गलत तरीके से काम करने वाले ब्राउज़र में, अगर event.request में Range: हेडर शामिल किया गया है, तो उस हेडर को चुपचाप हटा दिया जाएगा. रिमोट सर्वर को मिले अनुरोध में Range: बिल्कुल शामिल नहीं होगा. इससे ज़रूरी नहीं है कि कुछ भी "बंद" हो जाए, क्योंकि सर्वर को तकनीकी तौर पर 200 स्टेटस कोड के साथ पूरा रिस्पॉन्स बॉडी दिखाने की अनुमति है. भले ही, मूल अनुरोध में Range: हेडर मौजूद हो. हालांकि, इससे ब्राउज़र के हिसाब से ज़रूरत से ज़्यादा डेटा ट्रांसफ़र होगा.
जिन डेवलपर को इस गड़बड़ी के बारे में पता था वे Range: हेडर की मौजूदगी की साफ़ तौर पर जांच करके, इस गड़बड़ी से बच सकते थे. अगर हेडर मौजूद होता, तो वे event.respondWith() को कॉल नहीं करते. ऐसा करने से, सेवा वर्कर, रिस्पॉन्स जनरेशन की प्रोसेस से खुद को हटा देता है. इसके बजाय, ब्राउज़र के डिफ़ॉल्ट नेटवर्किंग लॉजिक का इस्तेमाल किया जाता है. यह लॉजिक, रेंज अनुरोधों को सेव करने का तरीका जानता है.
self.addEventListener('fetch', (event) => {
// Return without calling event.respondWith()
// if this is a range request.
if (event.request.headers.has('range')) {
return;
}
event.respondWith(fetch(event.request));
});
हालांकि, यह कहना सही होगा कि ज़्यादातर डेवलपर को इसकी ज़रूरत के बारे में पता नहीं था. साथ ही, यह साफ़ तौर पर नहीं बताया गया था कि ऐसा क्यों ज़रूरी है. आखिरकार, यह पाबंदी इस वजह से थी कि ब्राउज़र को इस सुविधा के लिए, बुनियादी स्पेसिफ़िकेशन में हुए बदलावों के साथ अप-टू-डेट होना पड़ा.
क्या ठीक किया गया है?
सही तरीके से काम करने वाले ब्राउज़र, event.request को fetch() को पास करते समय Range: हेडर को सुरक्षित रखते हैं. इसका मतलब है कि मेरे शुरुआती उदाहरण में मौजूद सेवा वर्कर कोड, रिमोट सर्वर को Range: हेडर देखने की अनुमति देगा. हालांकि, ऐसा तब ही होगा, जब इसे ब्राउज़र ने सेट किया हो:
self.addEventListener('fetch', (event) => {
// The Range: header will pass through in browsers
// that behave correctly.
event.respondWith(fetch(event.request));
});
अब सर्वर को रेंज के अनुरोध को सही तरीके से मैनेज करने का मौका मिलता है. साथ ही, 206 स्टेटस कोड के साथ कुछ हिस्से का जवाब दिया जा सकता है.
कौनसे ब्राउज़र सही तरीके से काम करते हैं?
Safari के नए वर्शन में, सही तरीके से काम करने वाली सुविधाएं हैं. Chrome और Edge के 87 वर्शन से भी यह सुविधा सही तरीके से काम करती है.
अक्टूबर 2020 तक, Firefox ने इस समस्या को ठीक नहीं किया है. इसलिए, प्रोडक्शन में अपने सेवा वर्कर के कोड को डिप्लॉय करते समय, आपको अब भी इस बात का ध्यान रखना पड़ सकता है.
वेब प्लैटफ़ॉर्म टेस्ट डैशबोर्ड की "नेटवर्क अनुरोध में रेंज हेडर शामिल करें" लाइन की जांच करके, यह पुष्टि की जा सकती है कि किसी ब्राउज़र ने इस समस्या को ठीक किया है या नहीं.
कैश मेमोरी से रेंज के अनुरोधों को दिखाने के बारे में क्या जानकारी है?
सेवा वर्कर, नेटवर्क को अनुरोध भेजने के अलावा और भी बहुत कुछ कर सकते हैं. ऑडियो और वीडियो फ़ाइलों जैसे रिसॉर्स को लोकल कैश मेमोरी में जोड़ना, इसका एक सामान्य इस्तेमाल है. इसके बाद, कोई सेवा वर्कर उस कैश मेमोरी से अनुरोधों को पूरा कर सकता है. इसके लिए, उसे नेटवर्क का इस्तेमाल नहीं करना पड़ता.
Firefox के साथ-साथ सभी ब्राउज़र, fetch हैंडलर में मौजूद अनुरोध की जांच कर सकते हैं. साथ ही, Range: हेडर की मौजूदगी की जांच कर सकते हैं. इसके बाद, कैश मेमोरी से मिले 206 रिस्पॉन्स की मदद से, स्थानीय तौर पर अनुरोध को पूरा कर सकते हैं. हालांकि, Range: हेडर को सही तरीके से पार्स करने और कैश मेमोरी में सेव किए गए पूरे रिस्पॉन्स का सिर्फ़ सही सेगमेंट दिखाने के लिए, सेवा वर्कर कोड बनाना आसान नहीं है.
हालांकि, जिन डेवलपर को मदद चाहिए वे Workbox का इस्तेमाल कर सकते हैं. यह लाइब्रेरी का एक सेट है, जो सर्विस वर्कर के सामान्य इस्तेमाल के उदाहरणों को आसान बनाता है. workbox-range-request module, कैश मेमोरी से सीधे तौर पर कुछ जवाब दिखाने के लिए, ज़रूरी सभी लॉजिक लागू करता है. इस इस्तेमाल के उदाहरण के लिए पूरी जानकारी, Workbox के दस्तावेज़ में मिल सकती है.
इस पोस्ट की हीरो इमेज, Unsplash पर Natalie Rhea Riggs की है.