http - कैश-कंट्रोल के बीच क्या अंतर है: अधिकतम आयु=0 और नो-कैश?




caching http-headers (6)

हेडर Cache-Control: max-age=0 तात्पर्य है कि सामग्री को तुरंत (और पुनः प्राप्त किया जाना चाहिए) माना जाता है, जो प्रभावी रूप से Cache-Control: no-cache जैसा ही होता है।


अंतर यह है कि नो-कैश (फ़ायरफ़ॉक्स पर नो-स्टोर) किसी भी प्रकार की कैशिंग को रोकता है। यह डिस्क पर लिखी सुरक्षित सामग्री वाले पृष्ठों को रोकने के लिए उपयोगी हो सकता है और उन पृष्ठों के लिए जिन्हें हमेशा अपडेट किया जाना चाहिए, भले ही उन्हें बैक बटन के साथ फिर से देखा जाए।

अधिकतम आयु = 0 इंगित करता है कि एक कैश प्रविष्टि पुरानी है और पुनः सत्यापन की आवश्यकता है, लेकिन कैशिंग को रोकता नहीं है। प्रायः ब्राउज़र केवल ब्राउज़र सत्र के दौरान संसाधनों को मान्य करते हैं, इसलिए जब तक साइट किसी नए सत्र में नहीं देखी जाती तब तक सामग्री अपडेट नहीं हो सकती है।

आमतौर पर, ब्राउज़र समाप्त होने वाली कैश प्रविष्टियों को नहीं हटाएंगे, जब तक कि ब्राउज़र कैश पूर्ण होने पर वे नई सामग्री के लिए स्थान पुनः प्राप्त कर रहे हों। नो-स्टोर का उपयोग करके, नो-कैश कैश एंट्री को स्पष्ट रूप से हटाया जा सकता है।


आईई 8 और फ़ायरफ़ॉक्स 3.5 के साथ मेरे हालिया परीक्षणों में, ऐसा लगता है कि दोनों आरएफसी-अनुरूप हैं। हालांकि, वे मूल सर्वर पर अपनी "मित्रता" में भिन्न होते हैं। आईई 8 max-age=0,must-revalidate रूप में समान अर्थशास्त्र के साथ no-cache प्रतिक्रियाओं का इलाज करता है max-age=0,must-revalidate । हालांकि, फ़ायरफ़ॉक्स 3.5 no-cache का इलाज no-cache के बराबर no-store करता है, जो प्रदर्शन और बैंडविड्थ उपयोग के लिए बेकार है।

डिफ़ॉल्ट रूप से स्क्विड कैश, फ़ायरफ़ॉक्स की तरह, no-cache हेडर के साथ कुछ भी स्टोर नहीं करता है।

मेरी सलाह गैर-संवेदनशील संसाधनों के लिए public,max-age=0 सेट करना होगा, जिसे आप प्रत्येक अनुरोध पर ताजगी के लिए जांचना चाहते हैं, लेकिन फिर भी कैशिंग के प्रदर्शन और बैंडविड्थ लाभों की अनुमति दें। प्रति उपयोगकर्ता वस्तुओं के लिए एक ही विचार के साथ, private,max-age=0

मैं पूरी तरह से no-cache के उपयोग से बचूंगा, क्योंकि ऐसा लगता है कि इसे कुछ ब्राउज़रों और लोकप्रिय कैशों द्वारा बिना किसी no-store के कार्यात्मक समकक्ष में बेस्टर्ड किया गया है।

इसके अतिरिक्त, अकामाई और लाइटलाइट का अनुकरण न करें। जबकि वे अनिवार्य रूप से बड़े पैमाने पर कैशिंग सरणी को अपने प्राथमिक व्यवसाय के रूप में चलाते हैं, और विशेषज्ञ होने चाहिए, वे वास्तव में अपने नेटवर्क से अधिक डेटा डाउनलोड करने में निहित रुचि रखते हैं। हो सकता है कि Google अनुकरण के लिए एक अच्छा विकल्प न हो। वे संसाधन के आधार पर यादृच्छिक रूप से max-age=0 या no-cache का उपयोग करते प्रतीत होते हैं।


मेरे पास यही सवाल था, और मेरी खोजों में कुछ जानकारी मिली (आपका प्रश्न परिणामों में से एक के रूप में आया)। यहां मैंने जो निर्धारित किया है ...

Cache-Control हेडर के दो पक्ष हैं। एक तरफ वह जगह है जहां इसे वेब सर्वर (उर्फ। "मूल सर्वर") द्वारा भेजा जा सकता है। दूसरी तरफ यह है कि इसे ब्राउज़र द्वारा भेजा जा सकता है (उर्फ। "उपयोगकर्ता एजेंट")।

मूल सर्वर द्वारा भेजा गया जब

मेरा मानना ​​है कि max-age=0 बस कैश (और उपयोगकर्ता एजेंट) को बताता है कि प्रतिक्रिया प्राप्त होने से पुरानी है और इसलिए उन्हें कैश की गई प्रतिलिपि का उपयोग करने से पहले प्रतिक्रिया (जैसे। If-Not-Modified शीर्षलेख के साथ) को पुन: सत्यापित करना चाहिए , जबकि , no-cache उन्हें बताता है कि उन्हें कैश की गई प्रति का उपयोग करने से पहले पुन: सत्यापित करना होगा14.9.1 से कैशबल क्या है :

कोई कैश

... एक कैश मूल सर्वर के साथ सफल पुनर्मूल्यांकन के बिना बाद के अनुरोध को पूरा करने के लिए प्रतिक्रिया का उपयोग नहीं करना चाहिए। यह मूल सर्वर को उन कैशों द्वारा कैशिंग को रोकने की अनुमति देता है जिन्हें क्लाइंट अनुरोधों के लिए बाध्य प्रतिक्रियाएं वापस करने के लिए कॉन्फ़िगर किया गया है।

दूसरे शब्दों में, कैश कभी-कभी एक बाली प्रतिक्रिया का उपयोग करना चुन सकते हैं (हालांकि मुझे विश्वास है कि उन्हें एक Warning शीर्षलेख जोड़ना होगा), लेकिन no-cache कहता है कि उन्हें किसी भी प्रकार की प्रतिक्रिया का उपयोग करने की अनुमति नहीं है। हो सकता है कि आप एक पृष्ठ में बेसबॉल आंकड़े जेनरेट करते समय शॉल-रीवालिडेट व्यवहार चाहते हैं, लेकिन जब आप ई-कॉमर्स खरीद के जवाब उत्पन्न करते हैं तो आप जरूरी- वास्तविक व्यवहार चाहते हैं।

यद्यपि आप अपनी टिप्पणी में सही हैं, जब आप कहते हैं कि स्टोरेज को रोकने के लिए no-cache नहीं माना जाता है, तो वास्तव में no-cache का उपयोग करते समय यह एक और अंतर हो सकता है। मैं एक पृष्ठ पर आया, कैश कंट्रोल डायरेक्टिव्स डेमस्टिफाइड , जो कहता है (मैं इसकी शुद्धता के लिए झुकाव नहीं कर सकता):

अभ्यास में, आईई और फ़ायरफ़ॉक्स ने नो-कैश निर्देश का इलाज करना शुरू कर दिया है जैसे कि यह ब्राउज़र को निर्देश देता है कि पृष्ठ को कैश न करें। हमने एक साल पहले इस व्यवहार को देखना शुरू कर दिया था। हमें संदेह है कि इस परिवर्तन को कैशिंग को रोकने के लिए इस निर्देश के व्यापक (और गलत) उपयोग से प्रेरित किया गया था।

...

ध्यान दें कि देर से, "कैश-कंट्रोल: नो-कैश" ने "नो-स्टोर" निर्देश की तरह व्यवहार करना शुरू कर दिया है।

एक तरफ, ऐसा लगता है कि Cache-Control: max-age=0, must-revalidate होना मूल रूप से Cache-Control: no-cache जैसा ही होना चाहिए। तो हो सकता है कि यह no-cache वास्तविक व्यवहार को प्राप्त करने का एक तरीका है, जबकि no-cache के स्पष्ट माइग्रेशन से बचने के लिए no-store (यानी कोई कैशिंग नहीं है)?

जब उपयोगकर्ता एजेंट द्वारा भेजा गया

मेरा मानना ​​है कि शाहकालपेश का जवाब उपयोगकर्ता एजेंट पक्ष पर लागू होता है। आप 13.2.6 एकाधिक प्रतिक्रियाओं को असंबद्ध भी देख सकते हैं।

यदि कोई उपयोगकर्ता एजेंट Cache-Control: max-age=0 साथ अनुरोध भेजता है Cache-Control: max-age=0 (उर्फ। "अंत-से-अंत पुनर्मूल्यांकन"), तो प्रत्येक कैश जिस तरह से इसके कैश प्रविष्टि को पुन: सत्यापित करेगा (उदाहरण के लिए। If-Not-Modified शीर्षलेख) मूल सर्वर के लिए सभी तरह से। यदि उत्तर 304 (संशोधित नहीं है) है, तो कैश्ड इकाई का उपयोग किया जा सकता है।

दूसरी तरफ, Cache-Control: no-cache साथ एक अनुरोध भेजना Cache-Control: no-cache (उर्फ। "एंड-टू-एंड रीलोड") पुन: वैध नहीं होता है और सर्वर प्रतिक्रिया देते समय कैश की गई प्रति का उपयोग नहीं करना चाहिए


मैं शायद ही एक कैशिंग विशेषज्ञ हूं, लेकिन मार्क नॉटिंघम है। यहां उनके कैशिंग दस्तावेज़ हैं । संदर्भ खंड में उनके पास उत्कृष्ट लिंक भी हैं।

उन दस्तावेज़ों के पढ़ने के आधार पर, ऐसा लगता है कि max-age=0 कैश को "उसी समय" में आने वाले अनुरोधों के लिए कैश प्रतिक्रिया भेजने की अनुमति दे सकता है, जहां "एक ही समय" का मतलब है कि वे एकसाथ नज़दीक हैं, वे एक साथ दिखते हैं कैश, लेकिन no-cache नहीं होगा।


वैसे, यह ध्यान देने योग्य है कि कुछ मोबाइल डिवाइस, विशेष रूप से आईफोन / आईपैड जैसे ऐप्पल उत्पाद पूरी तरह से हेड-कैश, नो-स्टोर, एक्सपियर: 0, या जो कुछ भी आप उन्हें फिर से उपयोग नहीं करने के लिए मजबूर करने के लिए मजबूर करने की कोशिश कर सकते हैं, फॉर्म पेज

इससे हमें सिरदर्द का कोई अंत नहीं हुआ है क्योंकि हम किसी उपयोगकर्ता के आईपैड के मुद्दे को प्राप्त करने का प्रयास करते हैं, एक पृष्ठ पर सोए जाने वाले पेज पर सोते हुए, 3 की चरण 2 कहें, और फिर डिवाइस पूरी तरह से स्टोर / कैश निर्देश, और जहां तक ​​मैं कह सकता हूं, बस अपने अंतिम राज्य से पृष्ठ का वर्चुअल स्नैपशॉट लेता है, यानी, इसे स्पष्ट रूप से जो बताया गया था उसे अनदेखा कर रहा है, और न केवल उस पृष्ठ को लेना जिसे संग्रहीत नहीं किया जाना चाहिए , और वास्तव में इसे फिर से जांच किए बिना संग्रहीत किया जाता है, जो अन्य चीजों के साथ सभी प्रकार के अजीब सत्र मुद्दों की ओर जाता है।

मैं इसे जोड़ने के मामले में बस इसे जोड़ रहा हूं और यह नहीं समझ सकता कि उन्हें विशेष रूप से आईफ़ोन और आईपैड के साथ सत्र त्रुटियां क्यों मिल रही हैं, जो इस क्षेत्र में सबसे खराब अपराधी हैं।

मैंने इस मुद्दे के साथ काफी व्यापक डीबगर परीक्षण किया है, और यह मेरा निष्कर्ष है, डिवाइस इन निर्देशों को पूरी तरह से अनदेखा करते हैं।

यहां तक ​​कि नियमित उपयोग में भी, मैंने पाया है कि कुछ मोबाइल भी कहने के माध्यम से नए संस्करणों की जांच करने में असफल हो जाते हैं, समाप्त हो जाते हैं: 0 फिर अंतिम संशोधित तिथियों की जांच करने के लिए यह निर्धारित करने के लिए कि क्या यह एक नया होना चाहिए।

यह बस ऐसा नहीं होता है, इसलिए मुझे जो करना पड़ा था, वह सीएसएस / जेएस फ़ाइलों को क्वेरी स्ट्रिंग जोड़ना था, जिन्हें मुझे अद्यतनों को मजबूर करने के लिए जरूरी था, जो बेवकूफ मोबाइल उपकरणों को यह सोचने में मदद करता है कि यह एक फ़ाइल है, जैसे: मेरा सीएसएस / जेएस अपडेट के लिए .css? v = 1, फिर v = 2। यह काफी हद तक काम करता है।

उपयोगकर्ता ब्राउज़र, वैसे भी, यदि 2016 तक, उनके डिफ़ॉल्ट पर छोड़ दिया गया है, जैसा कि मैं लगातार खोजता हूं (हम अपनी साइट पर बहुत सारे बदलाव और अपडेट करते हैं) भी ऐसी फाइलों पर अंतिम संशोधित तिथियों की जांच करने में विफल रहते हैं, लेकिन क्वेरी स्ट्रिंग विधि उस समस्या को हल करता है। यह कुछ ऐसा है जो मैंने ग्राहकों और कार्यालय के लोगों के साथ देखा है जो अपने ब्राउज़र पर बुनियादी सामान्य उपयोगकर्ता डिफ़ॉल्ट का उपयोग करते हैं, और सीएसएस / जेएस आदि के साथ मुद्दों को कैशिंग करने की कोई जागरूकता नहीं है, लगभग हमेशा नए सीएसएस / जेएस को बदलने पर असफल हो जाते हैं, जिसका मतलब है कि उनके ब्राउज़र के लिए डिफ़ॉल्ट, ज्यादातर एमएसआईई / फ़ायरफ़ॉक्स, जो कुछ करने के लिए कहा जाता है, वह नहीं कर रहे हैं, वे परिवर्तनों को अनदेखा करते हैं और अंतिम संशोधित तिथियों को अनदेखा करते हैं और मान्य नहीं होते हैं, यहां तक ​​कि समाप्ति के साथ भी: 0 सेट स्पष्ट रूप से।

यह बहुत अच्छी तकनीकी जानकारी के साथ एक अच्छा धागा था, लेकिन यह भी ध्यान रखना महत्वपूर्ण है कि इस सामान के लिए समर्थन कितना बुरा है विशेष रूप से मोबाइल उपकरणों में। प्रत्येक कुछ महीनों में मुझे उनके द्वारा प्राप्त किए गए हेडर कमांड का पालन करने में विफलता के विरुद्ध सुरक्षा की अधिक परतें जोड़नी होंगी, या उन आदेशों को सही तरीके से हस्तक्षेप करना होगा।


अधिकतम उम्र = 0

यह रीफ्रेश पर क्लिक करने के बराबर है, जिसका अर्थ है, मुझे नवीनतम प्रतिलिपि दें जब तक कि मेरे पास पहले से ही नवीनतम प्रतिलिपि न हो।

कोई कैश

रीफ्रेश पर क्लिक करते समय यह शिफ्ट धारण कर रहा है, जिसका अर्थ है, सबकुछ फिर से करें, इससे कोई फर्क नहीं पड़ता।





http-headers