कैश-कंट्रोल हेडर: सार्वजनिक और व्यक्तिगत प्रतिक्रियाओं के लिए समझ
यह दस्तावेज़ Cache-Control HTTP हेडर ‘नो-स्टोर’, ‘नो-कैश’ और ‘प्राइवेट’ की व्याख्या करता है, जो सार्वजनिक और व्यक्तिगत प्रतिक्रियाओं के लिए कैशिंग व्यवहार को नियंत्रित करने में उनके अंतरों को बताता है, साथ ही ब्राउज़र निदान और सामान्य गलतियों पर भी प्रकाश डालता है।
इस पृष्ठ पर
संक्षिप्त उत्तर
कैश-कंट्रोल हेडर वेब ब्राउज़रों और मध्यवर्ती कैश (जैसे सीडीएन) द्वारा वेब संसाधनों को कैसे प्रबंधित करते हैं, यह प्रबंधित करने के लिए महत्वपूर्ण हैं। ये हेडर कैश को बताते हैं कि प्रतिक्रियाओं को संग्रहीत करना, मान्य करना या संग्रहीत करने से रोकना है या नहीं। आइए तीन प्रमुख निर्देशों को तोड़ते हैं: ‘नो-स्टोर’, ‘नो-कैश’ और ‘प्राइवेट’। ‘नो-स्टोर’ सबसे सख्त है। यह *किसी भी* कैशिंग को रोकता है, जिसमें निजी कैश भी शामिल हैं। यह अत्यधिक संवेदनशील डेटा या एक-बार के लिए प्रतिक्रियाओं के लिए आवश्यक है। उदाहरण: Cache-Control: no-store। ‘नो-कैश’ कैशिंग की अनुमति देता है लेकिन *हमेशा* मूल सर्वर के साथ प्रतिक्रिया को मान्य करने की आवश्यकता है इससे पहले कि इसका उपयोग किया जाए। यह सुनिश्चित करता है कि ब्राउज़र नवीनतम संस्करण प्राप्त करे, भले ही कैश में एक पुरानी प्रति हो। उदाहरण: Cache-Control: no-cache। ‘प्राइवेट’ केवल निजी कैश को संग्रहीत करने तक सीमित करता है - ब्राउज़र के स्थानीय कैश जैसे विशिष्ट उपयोगकर्ता से जुड़े कैश। यह साझा कैश को अन्य उपयोगकर्ताओं को व्यक्तिगत सामग्री परोसने से रोकता है। उदाहरण: Cache-Control: private। जब व्यक्तिगत प्रतिक्रियाओं से निपटते हैं, तो ‘प्राइवेट’ महत्वपूर्ण है। एक उपयोगकर्ता की वेबसाइट में लॉग इन करने पर विचार करें; उनकी प्रतिक्रिया को केवल उनके ब्राउज़र में संग्रहीत किया जाना चाहिए, साझा सीडीएन में नहीं। यदि प्रतिक्रिया में व्यक्तिगत डेटा होता है, तो ‘प्राइवेट’ का उपयोग जानकारी लीक को रोकने के लिए आवश्यक है। MDN दस्तावेज़ इंगित करता है कि ‘नो-कैश’ का मतलब “कैश न करें” नहीं है। इसका मतलब है “पुन: उपयोग करने से पहले मान्य करें”। ‘नो-कैश’ निर्देश गारंटी नहीं देता है कि इतिहास नेविगेशन के लिए पुन: सत्यापन। इसके अतिरिक्त, ‘मैक्स-एज’ निर्देश बताता है कि प्रतिक्रिया को कितने समय तक ताज़ा माना जाता है। 0 का मान इंगित करता है कि प्रतिक्रिया को हमेशा मान्य किया जाना चाहिए। ‘इम्म्यूटेबल’ निर्देश कैशिंग को रोकता है, भले ही मैक्स-एज सेट हो, यह सुनिश्चित करता है कि ब्राउज़र हमेशा संसाधन के नवीनतम संस्करण का अनुरोध करे। जब ब्राउज़र के अनुरोध हेडर का निरीक्षण किया जाता है, तो आप कैशिंग व्यवहार को प्रभावित करने वाले Cache-Control निर्देशों को देखेंगे। उदाहरण के लिए, एक सार्वजनिक संपत्ति के लिए अनुरोध में Cache-Control: public max-age=3600 हो सकता है, जो इसे एक घंटे के लिए कैश करने की अनुमति देता है। एक निजी प्रोफ़ाइल के लिए अनुरोध में Cache-Control: private no-cache हो सकता है, यह सुनिश्चित करता है कि केवल उपयोगकर्ता के ब्राउज़र को इसे संग्रहीत करने की अनुमति है और पुन: उपयोग करने से पहले सत्यापन की आवश्यकता है। ब्राउज़र निदान यह प्रकट कर सकते हैं कि प्रतिक्रिया कैश की जा रही है या नहीं और Cache-Control हेडर कैसे हैं। डेवलपर टूल जैसे ब्राउज़र के उपकरण नेटवर्क अनुरोधों की निगरानी और Cache-Control हेडर की जांच करने की अनुमति देते हैं। सामान्य गलतियों में ‘प्राइवेट’ सेट करना शामिल है जो व्यक्तिगत प्रतिक्रियाओं के लिए नहीं है, जिससे संभावित डेटा लीक हो सकता है। एक अन्य गलती केवल ‘नो-स्टोर’ पर भरोसा करना है जब एक अधिक सूक्ष्म दृष्टिकोण की आवश्यकता होती है - कभी-कभी, सत्यापन के साथ कैशिंग की अनुमति देना बेहतर होता है। निर्णय मानदंड डेटा की संवेदनशीलता और वांछित कैशिंग व्यवहार पर आधारित होना चाहिए। अंत में, याद रखें कि Cache-Control एक प्राधिकरण सीमा नहीं है; ‘नो-कैश’ का मतलब “कोई भंडारण नहीं” नहीं है। दायरे की सीमा विशिष्ट हेडर द्वारा निर्धारित की जाती है और ब्राउज़र और मध्यवर्ती कैश द्वारा लागू कैशिंग नीतियों द्वारा।
भंडारण से अलग करना पुन: उपयोग से
कैशिंग वेब प्रदर्शन को बेहतर बनाने की एक मौलिक तकनीक है, लेकिन यह डेटा संवेदनशीलता के साथ इसकी बातचीत को समझने के लिए महत्वपूर्ण है। मूल अवधारणा भंडारण की एक प्रतिक्रिया और पुन: उपयोग किए गए प्रतिक्रिया के बीच अंतर करना है। एक कैश एक प्रतिक्रिया संग्रहीत कर सकता है, लेकिन इसे पुन: उपयोग करने से पहले उसे मान्य करना चाहिए। ‘नो-स्टोर’ दोनों को संग्रहीत करने और पुन: उपयोग करने से रोकता है, यह सुनिश्चित करता है कि प्रतिक्रिया कभी भी क्लाइंट के ब्राउज़र से बाहर न निकले। ‘नो-कैश’ भंडारण की अनुमति देता है लेकिन पुन: उपयोग करने से पहले मान्य करने की आवश्यकता है, यह सुनिश्चित करता है कि ब्राउज़र हमेशा नवीनतम संस्करण प्राप्त करे। ‘प्राइवेट’ निजी कैश को संग्रहीत करने तक सीमित करता है, साझा कैश को अन्य उपयोगकर्ताओं को व्यक्तिगत सामग्री परोसने से रोकता है।
एक परिदृश्य पर विचार करें जहां एक उपयोगकर्ता लॉग इन करता है। उनकी व्यक्तिगत प्रोफ़ाइल डेटा वाली प्रतिक्रिया को निजी माना जाना चाहिए। ‘प्राइवेट’ के बिना, एक साझा कैश इस डेटा को अन्य उपयोगकर्ताओं को परोस सकता है, जिससे उनकी गोपनीयता खतरे में पड़ सकती है। MDN दस्तावेज़ पर जोर देता है कि ‘नो-कैश’ का मतलब “कैश न करें” नहीं है। इसका मतलब है “पुन: उपयोग करने से पहले मान्य करें।”
नो-स्टोर को समझें
Cache-Control: no-store निर्देश सबसे प्रतिबंधात्मक है। यह निर्देश सभी कैशों - निजी और साझा दोनों - को *प्रतिक्रिया को बिल्कुल भी संग्रहीत करने के लिए नहीं* बताता है। यह विकल्प अत्यधिक संवेदनशील डेटा, एक-बार के लिए प्रतिक्रियाओं या ऐसी सामग्री के लिए उपयुक्त है जिसे कभी भी पुन: उपयोग नहीं किया जाना चाहिए। यह प्रभावी रूप से निर्दिष्ट संसाधन के लिए कैशिंग को अक्षम करता है।
उदाहरण: Cache-Control: no-store किसी भी कैश को प्रतिक्रिया संग्रहीत करने से रोकेगा, चाहे वह ब्राउज़र कैश हो या सीडीएन कैश। यह संवेदनशील जानकारी के अनधिकृत पहुंच को रोकने के लिए महत्वपूर्ण है।
नो-कैश को समझें
Cache-Control: no-cache निर्देश कैशिंग की अनुमति देता है लेकिन *हमेशा* मूल सर्वर के साथ प्रतिक्रिया को मान्य करने की आवश्यकता है इससे पहले कि इसका उपयोग किया जाए। यह सुनिश्चित करता है कि ब्राउज़र हमेशा संसाधन के नवीनतम संस्करण प्राप्त करे, भले ही कैश में एक पुरानी प्रति हो। यह प्रदर्शन और डेटा ताज़ेपन के बीच एक संतुलन है।
यह निर्देश का मतलब “कैश न करें” नहीं है; इसका मतलब है “पुन: उपयोग करने से पहले मान्य करें”। ब्राउज़र हमेशा सर्वर से यह सत्यापित करने के लिए एक अनुरोध करेगा कि कैश की गई प्रति अभी भी मान्य है। यह गतिशील सामग्री जैसे कि प्रतिक्रियाशील सामग्री के लिए उपयोगी है।
प्राइवेट को समझें
Cache-Control: private निर्देश निजी कैश तक संग्रहीत करने को सीमित करता है - ब्राउज़र के स्थानीय कैश जैसे विशिष्ट उपयोगकर्ता से जुड़े कैश। यह साझा कैश को अन्य उपयोगकर्ताओं को व्यक्तिगत सामग्री परोसने से रोकता है। यह उपयोगकर्ता गोपनीयता की सुरक्षा के लिए आवश्यक है।
जब प्रतिक्रिया में व्यक्तिगत डेटा होता है, तो ‘प्राइवेट’ का उपयोग करना महत्वपूर्ण है। इसके बिना, एक साझा कैश समान प्रतिक्रिया को कई उपयोगकर्ताओं को परोस सकता है, संभावित रूप से उनके व्यक्तिगत जानकारी को उजागर कर सकता है। MDN दस्तावेज़ नोट करता है कि ‘प्राइवेट’ व्यक्तिगत प्रतिक्रियाओं के लिए विशेष रूप से महत्वपूर्ण है जो लॉग इन करने के बाद प्राप्त होती हैं।
तीन प्रतिक्रिया नीतियों की तुलना
यहाँ तीन निर्देशों के बीच मुख्य अंतरों का सारांश तालिका दी गई है:
एक ब्राउज़र अनुरोध का निरीक्षण
अपने ब्राउज़र के डेवलपर टूल का उपयोग करके (आमतौर पर F12 दबाकर पहुँचा जाता है), आप नेटवर्क अनुरोधों के Cache-Control हेडर का निरीक्षण कर सकते हैं। नेटवर्क पैनल में 'हेडर' टैब देखें। यह ब्राउज़र द्वारा भेजे जा रहे सटीक हेडर को दिखाएगा, जिसमें Cache-Control निर्देश शामिल हैं।
उदाहरण के लिए, यदि आप एक व्यक्तिगत प्रोफ़ाइल वाले पृष्ठ को देख रहे हैं, तो आपको अनुरोध हेडर में Cache-Control: निजी no-cache दिखाई देना चाहिए। यह दर्शाता है कि ब्राउज़र को प्रतिक्रिया को केवल अपने स्थानीय कैश में संग्रहीत करने और पुन: उपयोग करने से पहले सर्वर के साथ मान्य करने के लिए कहता है।
व्यक्तिगत प्रतिक्रियाओं को संभालना
व्यक्तिगत प्रतिक्रियाएँ - उन प्रतिक्रियाएँ जिनमें उपयोगकर्ता-विशिष्ट डेटा शामिल होता है जैसे लॉगिन जानकारी, प्राथमिकताएँ, या शॉपिंग कार्ट सामग्री - Cache-Control हेडर पर सावधानीपूर्वक विचार करने की आवश्यकता होती है। हमेशा Cache-Control: निजी का उपयोग करें ताकि साझा कैश अन्य उपयोगकर्ताओं को इस डेटा को परोसने से न रोकें।
ऐसा करने में विफल रहने से गंभीर गोपनीयता उल्लंघन और सुरक्षा कमजोरियाँ हो सकती हैं। MDN दस्तावेज़ स्पष्ट रूप से 'निजी' का उपयोग करने की अनुशंसा करता है उपयोगकर्ता-व्यक्तिगत सामग्री के लिए।
निष्कासन और विरासत सीमाओं को पहचानना
भले ही 'no-cache' का उपयोग किया गया हो, फिर भी ब्राउज़र का इतिहास कैश (bfcache) अभी भी बिना पुन: मान्यकरण के एक कैश की गई प्रतिक्रिया परोस सकता है। यह एक विरासत व्यवहार है जिसे पिछली सत्रों को पुनर्स्थापित करने के लिए डिज़ाइन किया गया है, और यह Cache-Control हेडर द्वारा नियंत्रित नहीं होता है।
इसके अतिरिक्त, पुराने HTTP/1.0 कैश 'no-cache' निर्देश का पूरी तरह से समर्थन नहीं कर सकते हैं, जिससे पुरानी प्रतिक्रियाओं का पुन: उपयोग हो सकता है। इस समस्या को हल करने के लिए 'max-age=0, must-revalidate' का उपयोग करना एक समाधान हो सकता है, लेकिन 'no-cache' का उपयोग करना सर्वोत्तम अभ्यास है जब भी संभव हो।
क्या जाँचें
- कैश व्यवहार अनुरोध/प्रतिक्रिया और मध्यवर्ती पर निर्भर करता है।
- कैश-कंट्रोल एक प्राधिकरण सीमा नहीं है; नो-कैश का मतलब कोई भंडारण नहीं है।
- ‘प्राइवेट’ निर्देश साझा कैशिंग को रोकता है जो व्यक्तिगत सामग्री को संग्रहीत करता है।
- 'नो-स्टोर' निर्देश सभी कैशिंग को रोकता है।
- 'नो-कैश' निर्देश पुन: उपयोग करने से पहले सत्यापन की आवश्यकता है।
- ब्राउज़र डेवलपर टूल का उपयोग Cache-Control हेडर का निरीक्षण करने के लिए किया जा सकता है।
- निजी और साझा कैश के बीच अंतर को समझना महत्वपूर्ण है।
- विरासत कैशिंग व्यवहार (bfcache) Cache-Control निर्देशों को बायपास कर सकता है।
- HTTP/1.0 कैश ‘नो-कैश’ को पूरी तरह से समर्थन नहीं कर सकते हैं।
उपयोग की सीमाएँ
ये हेडर कैशिंग व्यवहार को नियंत्रित करने का एक तंत्र प्रदान करते हैं, लेकिन वे पूरी तरह से कैशिंग या जानकारी लीक से सुरक्षा की गारंटी नहीं देते हैं। ब्राउज़र कार्यान्वयन और मध्यवर्ती कैश अलग-अलग व्यवहार कर सकते हैं, और उपयोगकर्ता कैशिंग सेटिंग्स को ओवरराइड कर सकते हैं। इसके अतिरिक्त, ‘नो-कैश’ निर्देश भंडारण को रोकता नहीं है। दायरे की सीमा विशिष्ट हेडर द्वारा निर्धारित की जाती है और ब्राउज़र और मध्यवर्ती कैश द्वारा लागू कैशिंग नीतियों द्वारा।