HTTP प्रतिक्रिया में नो-कैश और नो-स्टोर दोनों का उपयोग क्यों किया जाना चाहिए?

Question

मुझे बताया गया है कि उपयोगकर्ता-जानकारी को लीक होने से रोकने के लिए, प्रतिक्रिया में केवल "नो-कैश" पर्याप्त नहीं है। "नो-स्टोर" भी आवश्यक है।

Cache-Control: no-cache, no-store

इस युक्ति को पढ़ने के बाद http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html , मुझे अभी भी यकीन नहीं है कि क्यों।

मेरी वर्तमान समझ यह है कि यह सिर्फ मध्यवर्ती कैश सर्वर के लिए है। भले ही "नो-कैश" प्रतिक्रिया में है, मध्यवर्ती कैश सर्वर अभी भी गैर-वाष्पशील भंडारण की सामग्री को बचा सकता है। मध्यवर्ती कैश सर्वर यह तय करेगा कि निम्नलिखित अनुरोध के लिए सहेजी गई सामग्री का उपयोग कर रहा है या नहीं। हालांकि, यदि "नो-स्टोर" प्रतिक्रिया में है, तो मध्यवर्ती कैश गंभीर सामग्री को संग्रहीत करने के लिए नहीं है। तो, यह सुरक्षित है।

क्या कोई और कारण है जो हमें "नो-कैश" और "नो-स्टोर" दोनों की आवश्यकता है?

Comments

no-cacheइसका मतलब यह नहीं है कि आप क्या सोचते हैं। असल में, इसका मतलब है "कृपया पुनर्जीवित करें"।

— एरवन लीग्रैंड

Answer 1

मुझे स्पष्ट करना चाहिए कि कैश काno-cache मतलब यह नहीं है । वास्तव में, इसका मतलब है कि आपके द्वारा अनुरोधित किसी भी कैश्ड प्रतिक्रिया का उपयोग करने से पहले "सर्वर के साथ अमान्य" हो सकता है।

must-revalidateदूसरी ओर, संसाधन को बासी समझे जाने पर केवल रिवाइंड करने की आवश्यकता होती है।

यदि सर्वर कहता है कि संसाधन अभी भी मान्य है, तो कैश अपने प्रतिनिधित्व के साथ प्रतिक्रिया दे सकता है, इस प्रकार सर्वर की आवश्यकता को पूरा करने के लिए पूरे संसाधन को फिर से भेजना है।

no-storeप्रभावी रूप से पूर्ण कैश निर्देश नहीं है और जो भी कैश के किसी भी रूप में प्रतिनिधित्व के भंडारण को रोकने का इरादा है।

मैं जो भी कहता हूं, लेकिन RFC 2616 HTTP कल्पना में इस पर ध्यान दें:

इतिहास बफ़र्स MAY अपने सामान्य ऑपरेशन के भाग के रूप में ऐसी प्रतिक्रियाओं को संग्रहीत करते हैं

लेकिन यह नए RFC 7234 HTTP कल्पना से संभावित रूप से no-storeमजबूत बनाने के प्रयास से छोड़ा गया है , देखें:

http://tools.ietf.org/html/rfc7234#section-5.2.1.5

Comments

अभी भी इस सवाल का जवाब नहीं: HTTP प्रतिक्रिया में नो-कैश और स्टोर दोनों का उपयोग क्यों किया जाना चाहिए? पर्याप्त नहीं है? Cache-Control: no-store

— फ्रैंकलिन यू

क्या ब्राउज़रों के बीच मतभेद हैं? क्योंकि Microsoft का यह आलेख docs.microsoft.com/en-us/iis/configuration/system.webServer/… भी उल्लेख नहीं करता है no-storeऔर वर्णन करता है no-cacheजैसे कि यह बिल्कुल भी कैशिंग नहीं करता है .... मैं भ्रमित हूँ!

— Roel

Alconja का जवाब सवाल का जवाब है, विशेष रूप से। जब मैंने उत्तर दिया तो मैंने केवल एक बहुत ही सामान्य miconception को स्पष्ट करने के लिए किया। कृपया अन्य उत्तर को वोट करें!

— ल्यूक पुप्लेट 12

Answer 2

कुछ परिस्थितियों में, IE6 अभी भी फ़ाइलों को कैश करेगा जब भी Cache-Control: no-cacheप्रतिक्रिया हेडर में होती है।

W3C के राज्योंno-cache :

यदि नो-कैश निर्देश फ़ील्ड-नाम को निर्दिष्ट नहीं करता है, तो कैश को मूल सर्वर के साथ सफल पुन: सत्यापन के बिना बाद के अनुरोध को संतुष्ट करने के लिए प्रतिक्रिया का उपयोग नहीं करना चाहिए।

मेरे आवेदन में, यदि आप no-cacheशीर्ष लेख के साथ किसी पृष्ठ पर गए हैं , तो लॉग आउट किया है और फिर अपने ब्राउज़र में वापस मारा है, IE6 अभी भी कैश से पृष्ठ (सर्वर के लिए एक नया / मान्य अनुरोध के बिना) हड़प जाएगा। no-storeहेडर में जोड़ने से ऐसा करना बंद कर दिया। लेकिन अगर आप उनके शब्द पर W3C लेते हैं, तो वास्तव में इस व्यवहार को नियंत्रित करने का कोई तरीका नहीं है:

इतिहास बफ़र्स MAY अपने सामान्य ऑपरेशन के भाग के रूप में ऐसी प्रतिक्रियाओं को संग्रहीत करते हैं।

ब्राउज़र के इतिहास और सामान्य HTTP कैशिंग के बीच सामान्य अंतर कल्पना के एक विशिष्ट उप-भाग में वर्णित हैं ।

Comments

जब आप अपने ब्राउज़र में वापस आते हैं, तो IE6 पेज को कैश से नहीं पकड़ता है। यह इतिहास बफ़र से पृष्ठ को पकड़ता है।

— पचेरियर

Chrome 34 (2014) में, इसे अभी भी सेट करना आवश्यक है no-store। अन्यथा बैक बटन का उपयोग करने पर क्रोम कैश्ड / बफर डेटा दिखाएगा।

— caw

-1 क्योंकि पहला वाक्य गलत अर्थ निकालता है कि एक ब्राउज़र के लिए यह गलत है कि एक no-cacheहेडर के जवाब को कैश किया जाए । W3C उद्धरण तुरंत नीचे स्पष्ट करता है कि यह मामला नहीं है; इसके बजाय, no-cacheहेडर का अर्थ केवल यह है कि बाद के अनुरोधों की सेवा के लिए पुन: उपयोग करने से पहले प्रतिक्रिया को अमान्य कर दिया जाना चाहिए।

— मार्क अमेरी

युक्ति की रिकॉर्डिंग को RFC1616 से बढ़ाकर युक्ति के वर्तमान संस्करण में बदल दिया गया है ( tools.ietf.org/html/rfc7230 परिवार RFC का)। एक परिवार क्योंकि यह 6 RFC है। उन्होंने 2616 अप्रचलित किया।

— आर्किन बी।

Answer 3

से HTTP 1.1 विनिर्देश :

दुकान नहीं :

का उद्देश्य नो-स्टोरनिर्देश अनजाने रिलीज या संवेदनशील जानकारी के प्रतिधारण को रोकने के लिए है (उदाहरण के लिए, बैकअप टेप पर)। नो-स्टोर का निर्देश पूरे संदेश पर लागू होता है, और MAY को प्रतिक्रिया या अनुरोध में भेजा जाता है। यदि अनुरोध में भेजा जाता है, तो कैश को इस अनुरोध के किसी भी भाग या किसी भी प्रतिक्रिया को संग्रहीत नहीं करना चाहिए। यदि एक प्रतिक्रिया में भेजा जाता है, तो एक कैश को इस प्रतिक्रिया या अनुरोध के किसी भी हिस्से को स्टोर नहीं करना चाहिए जो इसे प्राप्त करता है। यह निर्देश गैर-साझा और साझा कैश दोनों पर लागू होता है। इस संदर्भ में "जरूरी नहीं संग्रह" का अर्थ है कि कैश को जानबूझकर गैर-वाष्पशील भंडारण में जानकारी को संग्रहीत नहीं करना चाहिए, और इसे अग्रेषित करने के बाद संभव के रूप में अस्थिर भंडारण से सूचना को हटाने के लिए सबसे अच्छा प्रयास करना होगा। जब यह निर्देश प्रतिक्रिया के साथ जुड़ा हो, तब भी उपयोगकर्ता कैशिंग सिस्टम के बाहर ऐसी प्रतिक्रिया को स्पष्ट रूप से संग्रहीत कर सकते हैं (उदाहरण के लिए, "सेव एज़" डायलॉग के साथ)। इतिहास बफ़र्स MAY अपने सामान्य ऑपरेशन के भाग के रूप में ऐसी प्रतिक्रियाओं को संग्रहीत करते हैं। इस निर्देश का उद्देश्य कुछ उपयोगकर्ताओं और सेवा लेखकों की उल्लिखित आवश्यकताओं को पूरा करना है, जो डेटा संरचनाओं को कैश करने के लिए अप्रत्याशित पहुंच के माध्यम से जानकारी के आकस्मिक रिलीज के बारे में चिंतित हैं। हालांकि इस निर्देश के उपयोग से कुछ मामलों में गोपनीयता में सुधार हो सकता है, हम चेतावनी देते हैं कि यह किसी भी तरह से गोपनीयता सुनिश्चित करने के लिए विश्वसनीय या पर्याप्त तंत्र नहीं है। विशेष रूप से, दुर्भावनापूर्ण या समझौता किए गए कैश इस निर्देश को पहचान नहीं सकते हैं या उनका पालन नहीं कर सकते हैं, और संचार नेटवर्क ईवेस्कॉपिंग के लिए असुरक्षित हो सकते हैं। इतिहास बफ़र्स MAY अपने सामान्य ऑपरेशन के भाग के रूप में ऐसी प्रतिक्रियाओं को संग्रहीत करते हैं। इस निर्देश का उद्देश्य कुछ उपयोगकर्ताओं और सेवा लेखकों की उल्लिखित आवश्यकताओं को पूरा करना है, जो डेटा संरचनाओं को कैश करने के लिए अप्रत्याशित पहुंच के माध्यम से जानकारी के आकस्मिक रिलीज के बारे में चिंतित हैं। हालांकि इस निर्देश के उपयोग से कुछ मामलों में गोपनीयता में सुधार हो सकता है, हम चेतावनी देते हैं कि यह किसी भी तरह से गोपनीयता सुनिश्चित करने के लिए विश्वसनीय या पर्याप्त तंत्र नहीं है। विशेष रूप से, दुर्भावनापूर्ण या समझौता किए गए कैश इस निर्देश को पहचान नहीं सकते हैं या उनका पालन नहीं कर सकते हैं, और संचार नेटवर्क ईवेस्कॉपिंग के लिए असुरक्षित हो सकते हैं। इतिहास बफ़र्स MAY अपने सामान्य ऑपरेशन के भाग के रूप में ऐसी प्रतिक्रियाओं को संग्रहीत करते हैं। इस निर्देश का उद्देश्य कुछ उपयोगकर्ताओं और सेवा लेखकों की उल्लिखित आवश्यकताओं को पूरा करना है, जो डेटा संरचनाओं को कैश करने के लिए अप्रत्याशित पहुंच के माध्यम से जानकारी के आकस्मिक रिलीज के बारे में चिंतित हैं। हालांकि इस निर्देश के उपयोग से कुछ मामलों में गोपनीयता में सुधार हो सकता है, हम चेतावनी देते हैं कि यह किसी भी तरह से गोपनीयता सुनिश्चित करने के लिए विश्वसनीय या पर्याप्त तंत्र नहीं है। विशेष रूप से, दुर्भावनापूर्ण या समझौता किए गए कैश इस निर्देश को पहचान नहीं सकते हैं या उनका पालन नहीं कर सकते हैं, और संचार नेटवर्क ईवेस्कॉपिंग के लिए असुरक्षित हो सकते हैं। हालांकि इस निर्देश के उपयोग से कुछ मामलों में गोपनीयता में सुधार हो सकता है, हम चेतावनी देते हैं कि यह किसी भी तरह से गोपनीयता सुनिश्चित करने के लिए विश्वसनीय या पर्याप्त तंत्र नहीं है। विशेष रूप से, दुर्भावनापूर्ण या समझौता किए गए कैश इस निर्देश को पहचान नहीं सकते हैं या उनका पालन नहीं कर सकते हैं, और संचार नेटवर्क ईवेस्कॉपिंग के लिए असुरक्षित हो सकते हैं। हालांकि इस निर्देश के उपयोग से कुछ मामलों में गोपनीयता में सुधार हो सकता है, हम चेतावनी देते हैं कि यह किसी भी तरह से गोपनीयता सुनिश्चित करने के लिए विश्वसनीय या पर्याप्त तंत्र नहीं है। विशेष रूप से, दुर्भावनापूर्ण या समझौता किए गए कैश इस निर्देश को पहचान नहीं सकते हैं या उनका पालन नहीं कर सकते हैं, और संचार नेटवर्क ईवेस्कॉपिंग के लिए असुरक्षित हो सकते हैं।

Comments

यदि आप पहले से ही अनुरोध को कैशिंग नहीं कर रहे हैं, तो क्या यह पहले से ही गैर-वाष्पशील मीडिया में प्रतिक्रिया के भंडारण को नहीं रोक पाएगा?

— लेसे मेजेस्टे

@ Lèsemajesté सबसे अधिक बार नहीं। no-cacheऔर max-age=0कहते हैं कि आइटम को बासी माना जाना है। इसका मतलब यह है कि इसे परोसा जाने से पहले इसे अमान्य कर दिया जाना चाहिए। इसका मतलब यह है कि एक कैश फ़ाइल को स्टोर कर सकता है और फिर एक सशर्त अनुरोध कर सकता है जिसके लिए सर्वर जवाब दे सकता है 304 NOT MODIFIED। यह स्पष्ट रूप से एक बहुत बड़ा लाभ है क्योंकि प्रतिक्रिया के शरीर को उत्पन्न करने और भेजने की आवश्यकता नहीं है। तो इसका फायदा उठाने के लिए कई (सबसे?) कैश प्रतिक्रियाएं जमा करेंगेno-cache ।

— केविन कॉक्स

Answer 4

यदि आप सभी कैशिंग को रोकना चाहते हैं (उदाहरण के लिए बैक बटन का उपयोग करते समय पुनः लोड करने के लिए बाध्य करें)

• IE के लिए नो-कैश

• फ़ायरफ़ॉक्स के लिए कोई दुकान नहीं

यहाँ इस बारे में मेरी जानकारी है:

http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/

Comments

इंटरनेट एक्सप्लोरर के लिए नो-स्टोर पर्याप्त क्यों नहीं होगा? आपका ब्लॉग पोस्ट नहीं समझाता।

— साइमन लीशेके

आप किस IE संस्करण के बारे में बात कर रहे हैं?

— पचेरियर

@Pacerier, संभवतया जो भी IE संस्करण उस समय सबसे नया था जब उसने टिप्पणी लिखी थी। विकिपीडिया के अनुसार यह IE7 था। एफएफ के लिए यह ऐसा दिखता है 3. बहुत से लोग अभी भी उपयोग नहीं करते हैं।

— ट्राइसिस

Answer 5

no-storeसामान्य स्थितियों में आवश्यक नहीं होना चाहिए, और गति और प्रयोज्य दोनों को नुकसान पहुंचा सकता है। इसका उपयोग उस उद्देश्य के लिए किया जाता है जहां HTTP प्रतिक्रिया में इतनी संवेदनशील जानकारी होती है कि इसे कभी भी डिस्क कैश पर नहीं लिखा जाना चाहिए, भले ही उपयोगकर्ता के लिए नकारात्मक प्रभाव पैदा हो।

यह काम किस प्रकार करता है:

• आम तौर पर, भले ही कोई उपयोगकर्ता एजेंट जैसे कि ब्राउज़र यह निर्धारित करता है कि प्रतिक्रिया को कैश नहीं किया जाना चाहिए, फिर भी यह उपयोगकर्ता एजेंट के आंतरिक कारणों के लिए डिस्क कैश में संग्रहीत कर सकता है। इस संस्करण का उपयोग "व्यू सोर्स", "बैक", "पेज इन्फो" जैसी सुविधाओं के लिए किया जा सकता है, और इसी तरह, जहां उपयोगकर्ता ने पृष्ठ को फिर से अनुरोध नहीं किया है, लेकिन ब्राउज़र इसे नया पृष्ठ दृश्य नहीं मानता है और यह उसी वर्जन की सेवा करने के लिए समझ में आता है जो उपयोगकर्ता वर्तमान में देख रहा है।

• उपयोग करने no-storeसे उस प्रतिक्रिया को संग्रहीत होने से रोका जा सकेगा, लेकिन इससे ब्राउज़र की "व्यू सोर्स", "बैक", "पेज इनफार्मेशन" की क्षमता प्रभावित हो सकती है और इसलिए सर्वर के लिए एक नया, अलग अनुरोध किए बिना, जो अवांछनीय है। दूसरे शब्दों में, उपयोगकर्ता स्रोत को देखने की कोशिश कर सकता है और यदि ब्राउज़र ने इसे मेमोरी में नहीं रखा है, तो उन्हें या तो यह बताया जाएगा कि यह संभव नहीं है, या यह सर्वर के लिए एक नया अनुरोध पैदा करेगा। इसलिए, no-storeकेवल तब उपयोग किया जाना चाहिए जब इन सुविधाओं के बाधित उपयोगकर्ता अनुभव ठीक से काम नहीं कर रहे हैं या जल्दी से कैश में संग्रहीत नहीं है, यह सुनिश्चित करने के महत्व से आगे निकल जाता है।

मेरी वर्तमान समझ यह है कि यह सिर्फ मध्यवर्ती कैश सर्वर के लिए है। भले ही "नो-कैश" प्रतिक्रिया में है, मध्यवर्ती कैश सर्वर अभी भी गैर-वाष्पशील भंडारण की सामग्री को बचा सकता है।

यह गलत है। HTTP 1.1 के साथ संगत इंटरमीडिएट कैश सर्वर उस सामग्री को कैश नहीं किया गया है, यह सुनिश्चित करते हुए निर्देशों no-cacheऔर must-revalidateनिर्देशों का पालन ​​करेगा । इन निर्देशों का उपयोग करना सुनिश्चित करेगा कि प्रतिक्रिया किसी भी मध्यवर्ती कैश द्वारा कैश नहीं की गई है, और बाद के सभी अनुरोधों को मूल सर्वर पर वापस भेजा जाता है।

यदि मध्यवर्ती कैश सर्वर HTTP 1.1 का समर्थन नहीं करता है, तो आपको Pragma: no-cacheसबसे अच्छा उपयोग करने और आशा करने की आवश्यकता होगी । ध्यान दें कि यदि यह HTTP 1.1 का समर्थन नहीं करता है, तो no-storeवैसे भी अप्रासंगिक है।

Comments

क्या मैं कुछ गलत समझ रहा हूं क्योंकि mnot.net/cache_docs/#CACHE-CONTROL आपको विरोधाभासी बता रहा है। यह कहता है कि no-cacheकैशिंग के सभी लाभों का त्याग किए बिना कठोर ताजगी बनाए रखता है, जिसका अर्थ है कि कैश संग्रहीत है और इसका उपयोग फिर से किया जाता है यदि सर्वर 304 नॉट संशोधित के साथ प्रतिक्रिया करता है।

— पेसियर

-1: नो-कैश का मतलब यह नहीं है कि सामग्री को कैश नहीं किया जा सकता है। 14.9.1 में कछुआ क्या कहता है, "यदि नो-कैश निर्देश क्षेत्र-नाम को निर्दिष्ट नहीं करता है, तो कैश कैश मूल सर्वर के साथ सफल पुनर्मूल्यांकन के बाद के अनुरोध को संतुष्ट करने के लिए प्रतिक्रिया का उपयोग नहीं करता है।" ( w3.org/Protocols/rfc2616/rfc2616-sec14.html#ecec14.9। ) जैसा कि क्रिस शिफलेट बताते हैं, यह "एक कैशिंग सिस्टम को कैश्ड कॉपी रखने से नहीं रोकता है। बस आवश्यकता है कि कैशिंग सिस्टम अपने कैश को पूर्व में अमान्य कर दे। इसे ग्राहक को वापस भेजने के लिए। " (HTTP डेवलपर की हैंडबुक, पृष्ठ 91)

— james.garriss

मुझे नहीं लगता कि मैंने इस जवाब में उन दोनों टिप्पणियों में से क्या लिखा है - मैंने बस इस बारे में बात नहीं की थी कि ब्राउज़र कैसे अमान्य होते हैं (जैसे कि अगर-संशोधित-चूंकि / अगर-कोई नहीं-मैच का उपयोग करते हुए) क्योंकि मैंने इसे नहीं देखा से मिलता जुलता। मैंने यह भी कवर करने का प्रयास नहीं किया कि नो-कैश क्या है, इसलिए मुझे यह समझने में कठिनाई हो रही है कि @ james.garriss द्वारा टिप्पणी मेरे जवाब से कैसे संबंधित है।

— थोमैसर्रक्ट

Answer 6

यदि कोई कैशिंग सिस्टम सही ढंग से नो-स्टोर को लागू करता है, तो आपको नो-कैश की आवश्यकता नहीं होगी। लेकिन सभी ऐसा नहीं करते। इसके अतिरिक्त, कुछ ब्राउज़र नो-कैश को लागू करते हैं जैसे यह कोई स्टोर नहीं था। इस प्रकार, जबकि कड़ाई की आवश्यकता नहीं है, यह शायद दोनों को शामिल करने के लिए सबसे सुरक्षित है।

Comments

“ लेकिन सभी ऐसा नहीं करते। “हमें अपने सहयोगी को समझाने के लिए एक ठोस उदाहरण की आवश्यकता है।

— फ्रैंकलिन यू

वह टिप्पणी 6 साल पहले की गई थी। आपको कैशिंग सर्वर के वर्तमान व्यवहार को देखने की आवश्यकता होगी कि वे क्या कर रहे हैं।

— james.garriss

Answer 7

ध्यान दें कि संस्करण 5 से 8 तक के इंटरनेट एक्सप्लोरर में https और सर्वर भेजने वाले Cache-Control: no-cacheया Pragma: no-cacheहेडर के माध्यम से सेव की गई फ़ाइल को डाउनलोड करने का प्रयास करते समय एक त्रुटि होगी ।

Http://support.microsoft.com/kb/812935/en-us देखें

का उपयोग Cache-Control: no-storeऔर Pragma: privateलगता है कि यह अभी भी काम करता है निकटतम चीज है।

Comments

जैसा कि संबंधित एसओ उत्तर में सुझाया गया है, आप Cache-Control: no-store, no-cache, must-revalidateइसे काम करने के लिए उस सटीक क्रम में सेट कर सकते हैं। हालाँकि, यह हमारे परिदृश्य में काम नहीं आया, लेकिन @bassim ने जो सुझाव दिया वह ऊपर किया। धन्यवाद!

— इरिक एच

Answer 8

क्रोम के लिए, नो-कैश का उपयोग री-विजिट पर पेज को फिर से लोड करने के लिए किया जाता है, लेकिन यह अभी भी कैश करता है यदि आप इतिहास में वापस जाते हैं (बैक बटन)। इतिहास-बैक के लिए पेज को पुनः लोड करने के लिए, नो-स्टोर का उपयोग करें। IE को सभी अवसरों में काम करने के लिए पुन: अमान्य होना चाहिए।

तो बस मैं हमेशा उपयोग सभी कीड़े और गलतफहमी से बचने के लिए सुनिश्चित हो

Cache-Control: no-store, no-cache, must-revalidate

अगर मैं यह सुनिश्चित करना चाहता हूं कि यह पुनः लोड हो।

Answer 9

मूल रूप से हमने कई साल पहले नो-कैश का उपयोग किया था और कुछ ब्राउज़रों के साथ बासी सामग्री के साथ कुछ समस्याओं में चला था ... दुर्भाग्य से बारीकियों को याद न करें।

हम तब से बस दुकान के उपयोग पर बस गए थे। तब से कभी भी पीछे मुड़कर नहीं देखा या किसी भी ब्राउज़र या बिचौलियों द्वारा बासी सामग्री के साथ कोई समस्या नहीं की।

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

Comments

मेरा मानना ​​है कि यह फ़ायरफ़ॉक्स है जो पसंद करते थे no-store।

— bvdb

Answer 10

बस चीजों को और भी बदतर बनाने के लिए, कुछ स्थितियों में, नो-कैश का उपयोग नहीं किया जा सकता है, लेकिन कोई भी स्टोर नहीं कर सकता है:

http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/

Answer 11

OWASP इस पर चर्चा करता है:

कैश-कंट्रोल निर्देशों के बीच क्या अंतर है: नो-कैश, और नो-स्टोर?

एक प्रतिक्रिया में नो-कैश निर्देश इंगित करता है कि प्रतिक्रिया का उपयोग बाद के अनुरोध की सेवा के लिए नहीं किया जाना चाहिए अर्थात कैश को ऐसी प्रतिक्रिया प्रदर्शित नहीं करनी चाहिए जिसमें हेडर में यह निर्देश सेट हो लेकिन सर्वर को अनुरोध को पूरा करने दें। नो-कैश निर्देश में कुछ फ़ील्ड नाम शामिल हो सकते हैं; जिस स्थिति में कैश को निर्दिष्ट फ़ील्ड नाम के अलावा प्रतिक्रिया दर्शाई जा सकती है जिसे सर्वर से सेवा दी जानी चाहिए। नो-स्टोर का निर्देश पूरे संदेश पर लागू होता है और इंगित करता है कि कैश को प्रतिक्रिया के किसी भी हिस्से या किसी भी अनुरोध को संग्रहीत नहीं करना चाहिए जो इसके लिए पूछा था।

क्या मैं इन निर्देशों के साथ पूरी तरह से सुरक्षित हूं?

नहीं, लेकिन आम तौर पर, दोनों कैश-कंट्रोल का उपयोग करें: नो-कैश, नो-स्टोर और प्रागमा: नो-कैश, एक्सपायर्स के अलावा: 0 (या एक पर्याप्त रूप से बैकडेटेड जीएमटी तिथि जैसे यूनिक्स अवधि)। गैर-HTML सामग्री प्रकार जैसे कि पीडीएफ, वर्ड डॉक्यूमेंट, एक्सेल स्प्रेडशीट, आदि अक्सर कैश हो जाते हैं, जब उपरोक्त कैश कंट्रोल निर्देश सेट किए जाते हैं (हालांकि यह संस्करण द्वारा बदलता है और पूर्व-चेक = 0, पोस्ट-चेक का अतिरिक्त उपयोग करना चाहिए) = 0, अधिकतम-आयु = 0, और s-maxage = 0 व्यवहार में कभी-कभी ब्राउज़र quirks और HTTP कार्यान्वयन के कारण कुछ मामलों में ब्राउज़र बंद होने पर फ़ाइल हटाने का परिणाम हो सकता है)। इसके अलावा, 'स्वतः पूर्ण' सुविधा किसी ब्राउज़र को एक प्रपत्र के इनपुट क्षेत्र में उपयोगकर्ता के प्रकार को कैश करने की अनुमति देती है। इसे जांचने के लिए, फॉर्म टैग या व्यक्तिगत इनपुट टैग में 'स्वतः पूर्ण = "बंद" विशेषता शामिल होनी चाहिए। तथापि,

स्रोत यहाँ ।

Comments

यह गलत है। no-cacheआप सर्वर के साथ सत्यापन के बिना इसका उपयोग नहीं कर सकते हैं । यदि आपकी कैश्ड कॉपी अभी भी अच्छी है, तो सर्वर एक 304 के साथ जवाब देगा और आप फिर अपनी कैश्ड कॉपी का उपयोग करेंगे। आपको एक संभावित बड़े नेटवर्क डाउनलोड को बचाता है। no-storeदूसरी ओर कहते हैं कि आपको डेटा को कैश करने की अनुमति नहीं है।

— गर्गॉयल