मान लें कि पुस्तकालय की वेबसाइट पर आज के खुलने का समय बदला गया, लेकिन कुछ पाठकों को अब भी पुराना समय दिख रहा है। पहले यह अलग करना होगा कि सर्वर का मूल डेटा नहीं बदला, ब्राउज़र ने सहेजी प्रतिक्रिया दोबारा इस्तेमाल की, या बीच के सर्वर ने पुराना संस्करण दिया। कई बार पृष्ठ रीफ़्रेश करना अपने आप नहीं बताता कि किस चरण में समस्या है।
HTTP कैश प्राप्त प्रतिक्रियाएँ सहेजता है और उपयुक्त शर्तों पर उनका दोबारा उपयोग करता है। यह लेख सार्वजनिक कार्य-समय की काल्पनिक सारणी से Cache-Control के संग्रह और सत्यापन निर्देशों को ETag तथा 304 प्रतिक्रियाओं से जोड़ता है। नीचे के आदान-प्रदान समझाने के लिए संक्षिप्त किए गए हैं; वे वास्तविक पुस्तकालय या किसी विशेष सर्वर के माप नहीं हैं। उद्देश्य सभी कैश हटाने का नुस्खा देना नहीं, बल्कि यह समझाना है कि कौन-सी प्रतिक्रिया कब दोबारा इस्तेमाल की जा सके।
1. सहेजना, जाँचकर उपयोग करना और साझा करना अलग प्रश्न हैं
कैश नीति पढ़ते समय तीन प्रश्न अलग लिखें: क्या प्रतिक्रिया सहेज सकते हैं, क्या सहेजी प्रति को अगले अनुरोध में तुरंत इस्तेमाल कर सकते हैं, और क्या कई उपयोगकर्ताओं के बीच साझा कर सकते हैं? सहेजने की अनुमति हमेशा दोबारा उपयोग की अनुमति नहीं है; अद्यतन स्थिति जाँचना भी दूसरों से साझा करना उचित नहीं बना देता। HTTP कैश मानक RFC 9111 इन शर्तों को अलग निर्देशों से परिभाषित करता है। यहाँ ऐसे प्रतिक्रिया निर्देशों की चर्चा है जिनमें फ़ील्ड नाम अलग आर्ग्युमेंट के रूप में नहीं दिए गए हैं।
| निर्णय का प्रश्न | संबंधित प्रतिक्रिया निर्देश | अलग समझने वाला अर्थ |
|---|---|---|
| क्या प्रतिक्रिया सहेजना मना है? | no-store | बाद में उपयोग के लिए संग्रह निषिद्ध करने का निर्देश |
| क्या दोबारा उपयोग से पहले जाँच चाहिए? | no-cache | संग्रह हो सकता है, पर दोबारा उपयोग से पहले सफल सत्यापन आवश्यक है |
| क्या कई उपयोगकर्ता साझा कर सकते हैं? | private | साझा कैश में संग्रह रोकता है; निजी कैश में संग्रह को पूरी तरह निषिद्ध नहीं करता |
मसलन, सार्वजनिक समय-सारणी एक ही पते पर अक्सर बदलती हो तो सहेजी प्रति उपलब्ध होने पर भी उपयोग से पहले जाँच की जरूरत पर विचार कर सकते हैं। व्यक्तिगत पृष्ठों की साझा करने की शर्तें शुरू से ही सार्वजनिक सारणी से अलग हैं। private साझा कैश का निर्देश है; वह लॉगिन और अधिकार-जाँच का विकल्प नहीं है। अलग उद्देश्यों वाली सेटिंग को एक वाक्य में मिला देने से गति सुधारते समय सूचना का प्राप्तकर्ता गलत तय हो सकता है।
नीति की तालिका में निर्देश के साथ कारण भी रखें। लिखें कि सारणी सार्वजनिक सूचना है जिसकी बदलाव-जाँच चाहिए, लोगो स्थिर सामग्री की फ़ाइल है, या उसी पते से व्यक्तिगत जानकारी दी जाती है। यह हर वेबसाइट पर लगाने वाला तैयार कॉन्फ़िगरेशन नहीं, वास्तविक प्रतिक्रियाओं को वर्गीकृत करने का आरंभ है। यह भी अलग करें कि नियम ब्राउज़र, CDN या किस अन्य संग्रह पर लागू होता है।
2. no-cache और no-store को केवल नाम से न चुनें
no-cache नाम को संग्रह निषेध समझ लेना आसान है, लेकिन प्रतिक्रिया में इसका अर्थ सहेजी प्रति के दोबारा उपयोग से पहले सत्यापन है। सर्वर बदलाव न होने की पुष्टि करे तो सहेजा मुख्य भाग फिर इस्तेमाल किया जा सकता है। इसके विपरीत no-store इस प्रतिक्रिया को सहेजने से मना करता है। क्या रखना है और अगले अनुरोध में क्या जाँचना है, दोनों अलग हैं; इसलिए इन दो सेटिंग का व्यवहार समान न मानें।
कैश में fresh उस स्थिति का नाम है जिसमें नीति अतिरिक्त सत्यापन के बिना दोबारा उपयोग की अनुमति देती है। यह गारंटी नहीं कि इस बीच संचालक ने सामग्री नहीं बदली। max-age से उपयोग की अवधि तय हो तो उसके भीतर मूल सामग्री बदलने पर भी पहले सहेजी प्रतिक्रिया चुनी जा सकती है। पहले स्वीकार्य अद्यतन विलंब तय करें, फिर जरूरत को निर्देश से जोड़ें। किसी मनमानी लंबी संग्रह अवधि को प्रदर्शन सुधार का सार्वभौमिक उत्तर मानकर उसकी नकल न करें।
MDN का HTTP कैश मार्गदर्शन बताता है कि नई प्रतिक्रिया में no-store जोड़ने से उसी URL की पहले सहेजी पुरानी प्रतिक्रिया नहीं मिटती। पुरानी प्रति अभी उपयोग योग्य हो और नई प्रतिक्रिया माँगी ही न जाए तो नया हेडर भी नहीं पहुँच सकता। no-store को सारे कैश मिटाने का आदेश या गोपनीयता की पर्याप्त शर्त न मानें; मौजूदा प्रतिक्रियाओं का जीवनकाल और प्रबंधित कैश की अद्यतन प्रक्रिया भी जाँचें।
3. ETag और 304 से दोबारा आने पर होने वाला आदान-प्रदान समझें
मान लें कि काल्पनिक सारणी का पता /hours.json शुरू में 18:00 बजे बंद होने की सूचना देता है। नीचे HTTP/1.1 का व्याख्यात्मक रूप है जिसमें केवल जरूरी हिस्से रखे गए हैं; वास्तविक प्रतिक्रिया के अन्य हेडर छोड़े गए हैं। hours-v1 इस उदाहरण में सर्वर द्वारा चुने निरूपण का पहचानकर्ता है, समय निकालने का सूत्र या वास्तविक फ़ाइल हैश नहीं।
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "hours-v1"
{"closes":"18:00"}ब्राउज़र ने प्रतिक्रिया सहेजी हो तो अगली बार ETag का मान सशर्त अनुरोध के If-None-Match में भेज सकता है। सर्वर को लगे कि शर्त चुने गए वर्तमान निरूपण से मेल खाती है और बदलाव नहीं हुआ तो वह 304 Not Modified देता है। अगला ब्लॉक अनुरोध और उसके उत्तर को क्रम से लिखा हुआ संक्षिप्त रिकॉर्ड है। यह 304 के बाद समय-सारणी का JSON मुख्य भाग दोबारा भेजने का उदाहरण नहीं है।
GET /hours.json HTTP/1.1
Host: library.example
If-None-Match: "hours-v1"
HTTP/1.1 304 Not Modified
Cache-Control: no-cache
ETag: "hours-v1"MDN की ETag व्याख्या के अनुसार इस स्थिति में क्लाइंट सहेजा मुख्य भाग इस्तेमाल करता है। 304 में नया मुख्य भाग नहीं होता, पर अनुरोध और सत्यापन के लिए संचार फिर भी होता है। संचालक ने बंद होने का समय 19:00 किया हो और सर्वर का निरूपण भी बदला हो तो पुरानी शर्त पर नए मुख्य भाग और नए पहचानकर्ता वाली 200 प्रतिक्रिया की अपेक्षा की जा सकती है। no-cache लगाने का अर्थ हर बार 304 मिलना या डेटाबेस क्वेरी समाप्त हो जाना नहीं है।
अकेले स्थिति कोड के बजाय सामग्री और पहचानकर्ता का मेल जाँचें। सामग्री बदल गई हो पर सर्वर पुराना ETag रखे तो सत्यापन गलत निष्कर्ष दे सकता है। उलटे सामग्री समान रहे पर पहचानकर्ता लगातार बदले तो मुख्य भाग अधिक बार भेजा जा सकता है। निर्माण पद्धति और चुने गए निरूपण का संबंध सर्वर पर जाँचना होगा; ETag दिखना मात्र सही कार्यान्वयन का प्रमाण नहीं है।
4. बदलते दस्तावेज़ और नए नाम वाले संसाधन को अलग रखें
एक ही URL पर बदलने वाले समय-सारणी जैसे दस्तावेज़ और सामग्री बदलने पर नया फ़ाइल नाम पाने वाले लोगो या स्क्रिप्ट की अद्यतन रणनीति अलग हो सकती है। मसलन logo.a1.png से logo.b2.png होने वाले डिज़ाइन में नया दस्तावेज़ नए पते की ओर संकेत करे। नाम में पहचानकर्ता जोड़कर फिर पुरानी फ़ाइल की सामग्री बदल देना, सामग्री और पते को साथ प्रबंधित करने का नियम तोड़ता है।
केवल नई फ़ाइल अपलोड करने से आगंतुक नया पता नहीं माँगता। उसके प्राप्त HTML में पुराने लोगो का पता हो तो पुराना संसाधन फिर इस्तेमाल हो सकता है। इसलिए संसाधन की कैश सेटिंग के साथ उसे संदर्भित करने वाले दस्तावेज़ का अद्यतन मार्ग भी देखें। दोनों की संग्रह अवधि समान करने के बजाय यह समझा सकें कि प्रत्येक कितनी देर बाद बदल सकता है।
परिनियोजन के दौरान पुराने और नए दस्तावेज़ थोड़ी देर साथ उपयोग हो सकते हैं। नया संसाधन तैयार होने से पहले नया दस्तावेज़ प्रकाशित करना या पुराना संसाधन जल्दी मिटा देना अलग विफलताएँ पैदा कर सकता है। इस काल्पनिक मामले में नए दस्तावेज़ की संदर्भित फ़ाइलों का मौजूद होना और पुराने दस्तावेज़ की फ़ाइलों तक पहुँच, दोनों जाँच सकते हैं। फ़ाइल का नाम बदलना कैश डिज़ाइन का साधन है; यह परिनियोजन क्रम और वापसी की हर समस्या अपने आप नहीं हल करता।
5. Network पैनल में एक समय पर एक परिकल्पना जाँचें
प्रत्यक्ष जाँच में पहले कैश की अनुमति वाली स्थिति का आधार रिकॉर्ड बनाएं। सटीक URL और क्वेरी, स्क्रीन पर सारणी का संस्करण, प्रतिक्रिया की स्थिति, अनुरोध का If-None-Match तथा प्रतिक्रिया के Cache-Control और ETag को साथ देखें। अनुरोध और प्रतिक्रिया के एक नाम वाले हेडर भी अलग पक्षों की शर्तें बताते हैं; लिखें कि कौन-सा पढ़ रहे हैं। Chrome DevTools Network दस्तावेज़ Headers में इन्हें अलग देखने का तरीका बताता है।
| काल्पनिक जाँच की स्थिति | साथ देखने वाले रिकॉर्ड | जल्दबाजी में न निकालें ऐसा निष्कर्ष |
|---|---|---|
| वही समय-सारणी फिर माँगना | सशर्त अनुरोध, स्थिति, स्क्रीन का समय | 304 आया, इसलिए कोई संचार नहीं हुआ |
| मूल समय बदलकर अनुरोध करना | नया मुख्य भाग, ETag, वास्तविक URL | सफल संग्रह का संकेत आया, इसलिए सभी को अद्यतन दिखा |
| ब्राउज़र कैश बंद करके अनुरोध | पहली बार डाउनलोड करने और सामान्य दोबारा आने का अंतर | यही सामान्य दोबारा भेंट की गति है |
| पीछे बटन से लौटना | नया अनुरोध हुआ या नहीं और बहाल स्क्रीन | स्क्रीन दिखी, इसलिए नया HTTP सत्यापन जरूर हुआ |
इसके बाद ब्राउज़र कैश निष्क्रिय करने को अलग स्थिति में आजमाएं। Chrome की Disable cache सेटिंग DevTools खुले रहने तक लागू होती है, इसलिए उपकरण की खुली स्थिति और सेटिंग दोनों दर्ज करें। पहली बार डाउनलोड को देखने में यह उपयोगी है, पर सामान्य दोबारा भेंट में सहेजी प्रति कैसे चलती है, उसकी जाँच के समान नहीं। सेटिंग सक्रिय होने का रिकॉर्ड न हो तो हर बार नए सिरे से डाउनलोड होते देखकर गलत समझ सकते हैं कि कैश काम नहीं कर रहा। प्रयोग की स्थितियाँ रखें ताकि कैश की अनुमति वाली स्थिति में लौटकर तुलना कर सकें।
एक साथ कई संशोधन और अनुरोध न करने से कारण पहचानना सरल होता है। पहले सामग्री बदले बिना दोबारा भेंट देखें, फिर समय की एक प्रविष्टि बदलकर प्रतिक्रिया का अंतर देखें। दस्तावेज़ URL, सर्वर सेटिंग और फ़ाइल नाम साथ बदलें तो किस बदलाव ने परिणाम दिया, तय करना कठिन है। अपेक्षित 200 या 304 न मिले तो और सेटिंग जोड़ने से पहले वास्तविक अनुरोध तथा प्रतिक्रिया फिर पढ़ें।
6. अन्य संग्रह मार्ग और पूरा होने के मानदंड भी देखें
ब्राउज़र का HTTP कैश निष्क्रिय करने से सर्वर के आगे का CDN या अनुप्रयोग के दूसरे संग्रह मार्ग गायब हो गए, ऐसा न मानें। अलग जाँचें कि service worker अनुरोध सँभाल रहा है या नहीं, बीच का सर्वर कौन-सी प्रतिक्रिया चुनता है और अनुप्रयोग पहले मिले डेटा को स्क्रीन पर रखता है या नहीं। एक URL दिखने का अर्थ सभी परतों का एक प्रति इस्तेमाल करना नहीं है।
पीछे बटन को भी नए HTTP अनुरोध से अलग जाँचें। ब्राउज़र पिछले सत्र की स्क्रीन बहाल करे तो no-cache के बावजूद अपेक्षित सत्यापन अनुरोध नहीं दिख सकता। इसे तुरंत सर्वर द्वारा हेडर अनदेखा करने का प्रमाण मानने से गलत कारण पकड़ सकते हैं। नए नेविगेशन, रीफ़्रेश और पीछे लौटने में वास्तविक अनुरोध हुआ या नहीं, अलग दर्ज करना विभिन्न घटनाओं को एक समस्या मानने से बचाता है।
सारणी के उदाहरण का पूरा होने का माप केवल कैश हिट दर नहीं है। सामग्री न बदलने पर सहेजी प्रति का सही इस्तेमाल, बदलाव के बाद स्वीकार्य समय में नई सूचना का दिखना और सही उपयोगकर्ता समूह के साथ प्रतिक्रिया साझा होना जाँचें। बदलाव का समय, निरीक्षण का समय, स्थितियाँ और वास्तविक मुख्य भाग दर्ज हों तो कोई दूसरा वही स्थिति दोहरा सकता है। गति के अंक सुधरें पर गलत कार्य-समय लंबे समय दिखे तो मूल जरूरत पूरी नहीं हुई।
वास्तविक सेवा में लागू करते समय प्रतिक्रिया प्रकारों की नीति को अद्यतन और वापसी की प्रक्रिया के साथ जाँचें। सार्वजनिक दस्तावेज़ के कैश निर्देश व्यक्तिगत प्रतिक्रिया में नकल न करें; सफल सत्यापन को पहुँच-अधिकार जाँच पूरी होना न समझें। हेडर संग्रह और दोबारा उपयोग के नियम पहुँचाने का माध्यम हैं। क्या सहेजा गया और किन जाँचों से होकर वर्तमान स्क्रीन तक पहुँचा, यह समझा सकें तो पुराने पृष्ठ की समस्या अधिक सही पहचान सकते हैं।