पक्का करें कि आपके सर्विस वर्कर को पता है कि आंशिक जवाब का अनुरोध किए जाने पर क्या करना है.
कुछ एचटीटीपी अनुरोधों में एक 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));
});
हालांकि, यह कहना सुरक्षित है कि ज़्यादातर डेवलपर को ऐसा करने की ज़रूरत के बारे में पता नहीं था. साथ ही, यह साफ़ तौर पर नहीं बताया गया था कि क्यों का इस्तेमाल करना ज़रूरी है. आखिरकार, यह पाबंदी इसलिए आई, क्योंकि ब्राउज़र को बुनियादी जानकारी में हुए बदलावों को पूरा करना ज़रूरी था. इससे, इस फ़ंक्शन के लिए सहायता जोड़ी गई.
क्या ठीक किया गया है?
सही तरीके से काम करने वाले ब्राउज़र, Range: हेडर को तब सुरक्षित रखते हैं, जब event.request को fetch() पर भेजा जाता है. इसका मतलब है कि मेरे शुरुआती उदाहरण में दिया गया सर्विस वर्कर कोड, रिमोट सर्वर को Range: हेडर देखने की अनुमति देगा, अगर ब्राउज़र ने इसे सेट किया हो:
self.addEventListener('fetch', (event) => {
// The Range: header will pass through in browsers
// that behave correctly.
event.respondWith(fetch(event.request));
});
अब सर्वर को रेंज के अनुरोध को ठीक से मैनेज करने और 206 स्टेटस कोड के साथ आंशिक जवाब देने का मौका मिलता है.
कौनसे ब्राउज़र ठीक से काम करते हैं?
Safari के हाल ही के वर्शन में सही फ़ंक्शन हैं. वर्शन 87 से शुरू होने वाले Chrome और Edge भी ठीक से काम करते हैं.
अक्टूबर 2020 तक, Firefox में इस गड़बड़ी को ठीक नहीं किया गया है. इसलिए, हो सकता है कि प्रोडक्शन में अपने सर्विस वर्कर के कोड को डिप्लॉय करते समय, आपको अब भी इसका ध्यान रखना पड़े.
वेब प्लैटफ़ॉर्म टेस्ट डैशबोर्ड की "नेटवर्क अनुरोध में रेंज हेडर शामिल करें" पंक्ति को चुनकर, यह पुष्टि की जा सकती है कि दिए गए ब्राउज़र ने इस व्यवहार को ठीक किया है या नहीं.
कैश मेमोरी से सेवा की रेंज के लिए किए गए अनुरोधों का क्या होगा?
सर्विस वर्कर, नेटवर्क के पास किसी अनुरोध को भेजने के अलावा बहुत कुछ कर सकते हैं. इसका एक सामान्य उदाहरण ऑडियो और वीडियो फ़ाइलों जैसे संसाधनों को किसी लोकल कैश में जोड़ना है. इसके बाद, सर्विस वर्कर नेटवर्क को पूरी तरह से बायपास करते हुए, उस कैश मेमोरी के अनुरोधों को पूरा कर सकता है.
Firefox के साथ-साथ सभी ब्राउज़र पर, fetch हैंडलर के अंदर किए गए अनुरोध की जांच की जा सकती है. साथ ही, यह जांच की जा सकती है कि Range: हेडर मौजूद है या नहीं. इसके बाद, इन ब्राउज़र पर कैश से मिलने वाले 206 रिस्पॉन्स की मदद से, अनुरोध को स्थानीय तौर पर पूरा किया जा सकता है. Range: हेडर को ठीक से पार्स करने और कैश मेमोरी में सेव किए गए पूरे रिस्पॉन्स के सही सेगमेंट को लौटाने के लिए सर्विस वर्कर कोड आसान नहीं होता.
अच्छी बात यह है कि जिन डेवलपर को कुछ मदद चाहिए वे वर्कबॉक्स इस्तेमाल कर सकते हैं. यह लाइब्रेरी का एक सेट है, जो सर्विस वर्कर के सामान्य इस्तेमाल को आसान बना देता है. workbox-range-request module, आंशिक जवाब देने के लिए ज़रूरी सभी लॉजिक को सीधे कैश से लागू करता है. इस इस्तेमाल के उदाहरण की पूरी रेसिपी वर्कबॉक्स दस्तावेज़ में देखी जा सकती है.
इस पोस्ट पर हीरो इमेज, Unsplash पर नैटली रिया रिग्स की है.