पक्का करें कि आपके सेवा वर्कर को पता हो कि कुछ हिस्से का जवाब मांगे जाने पर क्या करना है.
कुछ एचटीटीपी अनुरोधों में 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));
});
हालांकि, यह कहना सही होगा कि ज़्यादातर डेवलपर को इसकी ज़रूरत के बारे में पता नहीं था. साथ ही, यह साफ़ तौर पर नहीं बताया गया था कि ऐसा क्यों ज़रूरी है. आखिरकार, यह पाबंदी इस वजह से थी कि ब्राउज़र को बुनियादी स्पेसिफ़िकेशन में हुए बदलावों के साथ अप-टू-डेट होना था. इन बदलावों की वजह से, इस सुविधा के लिए सहायता जोड़ी गई.
क्या ठीक किया गया है?
सही तरीके से काम करने वाले ब्राउज़र, fetch()
को event.request
पास करने पर 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 के दस्तावेज़ में मिल सकती है.
इस पोस्ट में हीरो इमेज, Unस्प्लैश पर नेटली रिया रिग्स ने पोस्ट की है.