हम सभी ब्राउज़रों में वेब पेज कैशिंग को कैसे नियंत्रित करते हैं?


1552

हमारी जांच ने हमें दिखाया है कि सभी ब्राउज़र समान तरीके से HTTP कैश निर्देशों का सम्मान नहीं करते हैं।

सुरक्षा कारणों से हम नहीं चाहते हैं कि हमारे एप्लिकेशन के कुछ पृष्ठ वेब ब्राउज़र द्वारा कभी भी कैश किए जाएं । यह कम से कम निम्नलिखित ब्राउज़रों के लिए काम करना चाहिए:

  • इंटरनेट एक्सप्लोरर 6+
  • फ़ायरफ़ॉक्स 1.5+
  • सफारी 3+
  • ओपेरा 9+
  • क्रोम

हमारी आवश्यकता एक सुरक्षा परीक्षण से आई थी। हमारी वेबसाइट से लॉग आउट करने के बाद आप बैक बटन दबा सकते हैं और कैश्ड पेज देख सकते हैं।


बस आईपैड सफारी के लिए, [यह] [१] मदद करता है? [1]: stackoverflow.com/questions/24524248/...
बख्शी

सबसे सरल उपयोग कर रहा है: अधिकतम आयु = 10। यह सही नहीं है क्योंकि पेज को 10 सेकंड के लिए कैश किया जाएगा। लेकिन यह कम से कम "हेडर स्पेगेटी" समाधान है। इसके अलावा, यह कभी-कभी डायनेमिक वेबसाइटों पर एक बड़ा प्रदर्शन को बढ़ावा देता है जो रिवर्स प्रॉक्सी का उपयोग करते हैं। (आपकी धीमी php स्क्रिप्ट को हर 10 सेकंड में एक बार कॉल किया जाएगा और फिर रिवर्स प्रॉक्सी द्वारा कैश किया जाएगा। 10 सेकंड के बाद एक बार प्रति आगंतुक एक बार की तुलना में बेहतर है)
हैलो वर्ल्ड


3
उस महान प्रश्न के लिए धन्यवाद। जिज्ञासा के लिए ऐसी स्थिति क्या हो सकती है जो आपको कुछ डेटा भेजती है जबकि रिसीवर नहीं चाहता कि इसे "सुरक्षा कारणों" से बचाया जाए । आपने उन्हें पहले ही भेज दिया!
अकाउंटेंट एनई

1
@Accountant: अपने परिदृश्य में, उपयोगकर्ता ने लॉग आउट किया था। कौन गारंटी दे सकता है कि उपयोगकर्ता-एजेंट पर अगला मानव उपयोगकर्ता वह व्यक्ति होगा जो अभी लॉग आउट हुआ है?
फेबिन हदादी

जवाबों:


2578

परिचय

हेडर का सही न्यूनतम सेट जो सभी उल्लेखित क्लाइंट (और समीप) में काम करता है:

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

Cache-Controlप्रति ग्राहकों और प्रॉक्सी (और परोक्ष करने के लिए अगले कुछ ग्राहकों के लिए आवश्यक के लिए HTTP 1.1 कल्पना है Expires)। Pragmaप्रति प्रागैतिहासिक ग्राहकों के लिए HTTP 1.0 कल्पना है। ExpiresHTTP 1.0 और ग्राहकों और प्रॉक्सी के लिए 1.1 चश्मा प्रति है। HTTP 1.1 में, पहले Cache-Controlसे अधिक समय लगता है Expires, इसलिए यह केवल HTTP 1.0 प्रॉक्सी के लिए ही है।

यदि आप केवल HTTPS से अधिक पृष्ठों की सेवा करते समय IE6 और इसके टूटे हुए कैशिंग के बारे में परवाह नहीं करते हैं no-store, तो आप छोड़ सकते हैं Cache-Control: no-cache

Cache-Control: no-store, must-revalidate
Pragma: no-cache
Expires: 0

यदि आप IE6 और HTTP 1.0 क्लाइंट (HTTP 1.1 1997 में पेश किए गए थे) के बारे में परवाह नहीं करते हैं, तो आप छोड़ सकते हैं Pragma

Cache-Control: no-store, must-revalidate
Expires: 0

यदि आप HTTP 1.0 के बारे में परवाह नहीं करते हैं, तो आप छोड़ सकते हैं Expires

Cache-Control: no-store, must-revalidate

दूसरी ओर, यदि सर्वर में एक ऑटो Dateहैडर शामिल है , तो आप सैद्धांतिक रूप से Cache-Controlभी चूक सकते हैं और Expiresकेवल इस पर भरोसा कर सकते हैं ।

Date: Wed, 24 Aug 2016 18:32:02 GMT
Expires: 0

लेकिन यह विफल हो सकता है जैसे कि एंड-यूज़र ऑपरेटिंग सिस्टम की तारीख में हेरफेर करता है और क्लाइंट सॉफ्टवेयर उस पर भरोसा कर रहा है।

अन्य Cache-Controlपैरामीटर जैसे कि max-ageअप्रासंगिक हैं यदि उपरोक्त Cache-Controlपैरामीटर निर्दिष्ट हैं। Last-Modifiedशीर्ष लेख यहाँ अधिकांश अन्य जवाब में शामिल के रूप में है ही दिलचस्प यदि आप वास्तव में चाहते हैं ताकि आप सभी पर यह निर्दिष्ट करने की आवश्यकता नहीं है, अनुरोध कैश करने के लिए।

इसे कैसे सेट करें?

PHP का उपयोग करना:

header("Cache-Control: no-cache, no-store, must-revalidate"); // HTTP 1.1.
header("Pragma: no-cache"); // HTTP 1.0.
header("Expires: 0"); // Proxies.

जावा सर्वलेट, या Node.js का उपयोग करना:

response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setHeader("Expires", "0"); // Proxies.

ASP.NET-MVC का उपयोग करना

Response.Cache.SetCacheability(HttpCacheability.NoCache);  // HTTP 1.1.
Response.Cache.AppendCacheExtension("no-store, must-revalidate");
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0.
Response.AppendHeader("Expires", "0"); // Proxies.

ASP.NET वेब API का उपयोग करना:

// `response` is an instance of System.Net.Http.HttpResponseMessage
response.Headers.CacheControl = new CacheControlHeaderValue
{
    NoCache = true,
    NoStore = true,
    MustRevalidate = true
};
response.Headers.Pragma.ParseAdd("no-cache");
// We can't use `response.Content.Headers.Expires` directly
// since it allows only `DateTimeOffset?` values.
response.Content?.Headers.TryAddWithoutValidation("Expires", 0.ToString()); 

ASP.NET का उपयोग करना:

Response.AppendHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0.
Response.AppendHeader("Expires", "0"); // Proxies.

ASP.NET Core v3 का उपयोग करना

// using Microsoft.Net.Http.Headers
Response.Headers[HeaderNames.CacheControl] = "no-cache, no-store, must-revalidate";
Response.Headers[HeaderNames.Expires] = "0";
Response.Headers[HeaderNames.Pragma] = "no-cache";

ASP का उपयोग करना:

Response.addHeader "Cache-Control", "no-cache, no-store, must-revalidate" ' HTTP 1.1.
Response.addHeader "Pragma", "no-cache" ' HTTP 1.0.
Response.addHeader "Expires", "0" ' Proxies.

रूबी ऑन रेल्स, या पायथन / फ्लास्क का उपयोग करना:

headers["Cache-Control"] = "no-cache, no-store, must-revalidate" # HTTP 1.1.
headers["Pragma"] = "no-cache" # HTTP 1.0.
headers["Expires"] = "0" # Proxies.

पायथन / Django का उपयोग करना:

response["Cache-Control"] = "no-cache, no-store, must-revalidate" # HTTP 1.1.
response["Pragma"] = "no-cache" # HTTP 1.0.
response["Expires"] = "0" # Proxies.

पायथन / पिरामिड का उपयोग करना:

request.response.headerlist.extend(
    (
        ('Cache-Control', 'no-cache, no-store, must-revalidate'),
        ('Pragma', 'no-cache'),
        ('Expires', '0')
    )
)

उपयोग करना:

responseWriter.Header().Set("Cache-Control", "no-cache, no-store, must-revalidate") // HTTP 1.1.
responseWriter.Header().Set("Pragma", "no-cache") // HTTP 1.0.
responseWriter.Header().Set("Expires", "0") // Proxies.

अपाचे .htaccessफ़ाइल का उपयोग करना :

<IfModule mod_headers.c>
    Header set Cache-Control "no-cache, no-store, must-revalidate"
    Header set Pragma "no-cache"
    Header set Expires 0
</IfModule>

HTML4 का उपयोग करना:

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="0">

HTML मेटा टैग बनाम HTTP प्रतिक्रिया हेडर

यह जानना महत्वपूर्ण है कि जब एचटीएमएल पेज को HTTP कनेक्शन पर परोसा जाता है, और एचटीटीपी प्रतिक्रिया हेडर और एचटीएमएल टैग दोनों में एक हेडर मौजूद होता है <meta http-equiv>, तो एचटीटीपी प्रतिक्रिया हेडर में निर्दिष्ट एचटीएमएल मेटा टैग पर पूर्ववर्तीता प्राप्त होगी। HTML मेटा टैग का उपयोग केवल तब किया जाएगा जब पृष्ठ को file://URL के माध्यम से स्थानीय डिस्क फ़ाइल सिस्टम से देखा जाए । W3 HTML कल्पना अध्याय 5.2.2 भी देखें । इस बात का ध्यान रखें जब आप उन्हें प्रोग्रामेटिक रूप से निर्दिष्ट नहीं करते हैं क्योंकि वेबसर्वर अर्थात् कुछ डिफ़ॉल्ट मान शामिल कर सकते हैं।

आम तौर पर, आप शुरुआत से भ्रम से बचने और हार्ड HTTP प्रतिक्रिया हेडर पर भरोसा करने के लिए HTML मेटा टैग को बेहतर नहीं कहेंगे। इसके अलावा, विशेष रूप से वे <meta http-equiv>टैग HTML5 में अमान्य हैं । केवल http-equivमें सूचीबद्ध मानों एचटीएमएल 5 विनिर्देश की अनुमति है।

वास्तविक HTTP प्रतिक्रिया हेडर का सत्यापन

एक और दूसरे को सत्यापित करने के लिए, आप उन्हें वेब ट्रैवर्स डेवलपर के टूलसेट के HTTP ट्रैफिक मॉनिटर में देख / डिबग कर सकते हैं। Chrome / Firefox23 + / IE9 + में F12 दबाकर, और फिर "नेटवर्क" या "नेट" टैब पैनल खोलकर, और फिर HTTP अनुरोध और प्रतिक्रिया के बारे में सभी विवरणों को उजागर करने के लिए HTTP के अनुरोध पर क्लिक करके प्राप्त कर सकते हैं। नीचे स्क्रीनशॉट क्रोम से है:

Chrome डेवलपर टूलसेट HTTP ट्रैफ़िक मॉनिटर, stackoverflow.com पर HTTP प्रतिक्रिया हेडर दिखा रहा है

मैं उन हेडर को फ़ाइल डाउनलोड पर भी सेट करना चाहता हूं

सबसे पहले, यह सवाल और जवाब "वेब पेज" (HTML पेज) पर लक्षित होता है, न कि "फाइल डाउनलोड" (पीडीएफ, ज़िप, एक्सेल आदि) पर। बेहतर होगा कि आप उन्हें कैश्ड करें और यूआरआई पथ में कहीं न कहीं कुछ फ़ाइल संस्करण पहचानकर्ता का उपयोग करें या एक परिवर्तित फ़ाइल पर एक रीडाउट को मजबूर करने के लिए क्वेरिस्ट्रिंग करें। फ़ाइल डाउनलोड पर उन नो-कैश हेडर को वैसे भी लागू करते हैं, तो HTTP के बजाय HTTPS पर फ़ाइल डाउनलोड की सेवा करते समय IE7 / 8 बग से सावधान रहें। विस्तार के लिए, देखें IE foo.jsf डाउनलोड नहीं कर सकता है। IE इस इंटरनेट साइट को खोलने में सक्षम नहीं था। अनुरोधित साइट या तो अनुपलब्ध है या नहीं मिल सकती है


16
यह पूरा होता नहीं दिख रहा है। मैंने IE 8 पर इस समाधान की कोशिश की और पाया कि जब आप बैक बटन दबाते हैं तो ब्राउज़र एक कैश्ड संस्करण को लोड करेगा।
माइक ओटम

16
संभवतः आपकी परीक्षण पद्धति गलत थी। हो सकता है कि पेज पहले से कैश में था? हो सकता है हेडर गलत थे / ओवररिडेन? शायद आप गलत अनुरोध देख रहे थे? आदि ..
बालुस

8
वास्तव में, मैं पुष्टि करता हूं कि यह दृष्टिकोण अधूरा है और IE8 के साथ समस्याओं का कारण बनता है, या कम से कम कुछ परिस्थितियों में। विशेष रूप से, IE8 का उपयोग करते हुए SSL पर संसाधन लाने के लिए, IE8 संसाधन को दूसरी बार लाने के लिए मना कर देगा (या तो पहले, या पहले प्रयास के बाद, उपयोग किए गए हेडर के आधार पर)। उदाहरण के लिए, EricLaw का ब्लॉग देखें ।
२०:४६ बजे हेयरस्टाइल

21
मैं जोड़ना चाहूंगा कि यह अनिवार्य रूप से बैंक ऑफ अमेरिका करता है। यदि आप उनकी प्रतिक्रिया हेडर देखते हैं और अनुवाद करते हैं कि एस्पक्स में, वे कर रहे हैं: Response.AppendHeader ("कैश-कंट्रोल", "नो-कैश, नो-स्टोर, मस्ट-रिवाइंडलेट"); प्रतिक्रिया ।AppendHeader ("समाप्ति", "थू, 01 दिसंबर 1994 16:00:00 GMT"); मैं समझती हूं, अगर यह उनके लिए काफी अच्छा है, तो यह मेरे लिए काफी अच्छा है।
जॉन

8
@ जॉन: यह हेडर समाप्त हो जाता है HTTP 1.0 विनिर्देश में उदाहरण मूल्य है । यह काम करता है, लेकिन यह वास्तव में उस टाइमस्टैम्प को लेने के लिए कुछ हास्यास्पद है।
बालूसी

244

(हे, सब लोग: कृपया ध्यान से कॉपी और पेस्ट न करें सभी हेडर आप पा सकते हैं)

सबसे पहले, बैक बटन का इतिहास कैश नहीं है :

ताजगी का मॉडल (धारा ४.२) आवश्यक रूप से इतिहास तंत्र पर लागू नहीं होता है। यही है, एक इतिहास तंत्र पिछले प्रतिनिधित्व को प्रदर्शित कर सकता है भले ही वह समाप्त हो गया हो।

पुराने HTTP कल्पना में शब्द और भी मजबूत था, स्पष्ट रूप से ब्राउज़र को बैक बटन इतिहास के लिए कैश निर्देशों की अवहेलना करना।

वापस वापस (समय के लिए जब उपयोगकर्ता समय में जाने के लिए माना जाता है किया गया था में लॉग इन)। यह पहले से खोले गए URL पर आगे नहीं बढ़ता है।

हालांकि, व्यवहार में, कैश बहुत विशिष्ट परिस्थितियों में बैक बटन को प्रभावित कर सकता है:

  • पृष्ठ को HTTPS पर वितरित किया जाना चाहिए , अन्यथा यह कैश-बस्टिंग विश्वसनीय नहीं होगा। इसके अलावा, यदि आप HTTPS का उपयोग नहीं कर रहे हैं, तो आपका पृष्ठ कई अन्य तरीकों से चोरी करने के लिए असुरक्षित है।
  • आपको भेजना होगा Cache-Control: no-store, must-revalidate(कुछ ब्राउज़र अवलोकन करते हैं no-storeऔर कुछ अवलोकन करते हैं must-revalidate)

आपको कभी भी किसी की आवश्यकता नहीं है:

  • <meta>कैश हेडर के साथ - यह बिल्कुल काम नहीं करता है। पूरी तरह से बेकार।
  • post-check/ pre-check- यह IE- केवल निर्देश है जो केवल कछुआ संसाधनों पर लागू होता है ।
  • एक ही हैडर को दो बार या दर्जन भागों में भेजना। कुछ PHP स्निपेट वास्तव में पिछले हेडर को प्रतिस्थापित करते हैं, जिसके परिणामस्वरूप केवल अंतिम एक भेजा जाता है।

यदि आप चाहें, तो आप जोड़ सकते हैं:

  • no-cacheया max-age=0, जो संसाधन (URL) को "बासी" बना देगा और यदि कोई नया संस्करण है (तो no-storeयह पहले से भी अधिक मजबूत है) सर्वर के साथ जाँच करने के लिए ब्राउज़र की आवश्यकता होती है ।
  • ExpiresHTTP / 1.0 क्लाइंट के लिए अतीत में एक तारीख के साथ (हालांकि असली HTTP / 1.0-केवल क्लाइंट इन दिनों पूरी तरह से गैर-मौजूद हैं)।

बोनस: नया एचटीटीपी कैशिंग आरएफसी


1
क्या लोडिंग समय के संदर्भ में वेबसाइट के प्रदर्शन पर इसका कोई दुष्प्रभाव होगा? नो-स्टोर, नो-कैश, प्रदर्शन को फिर से कैसे प्रभावित करना चाहिए?
रमन घई

@RamanGhai कैश को अक्षम करना आमतौर पर प्रदर्शन को नुकसान पहुंचाता है (और आपके द्वारा अक्षम कैशिंग के सभी 3 विकल्प)। यह CDN और ISP परदे के पीछे (जैसे आमतौर पर मोबाइल ऑपरेटरों द्वारा उपयोग किया जाता है) अप्रभावी बना सकता है। यह एक नए उपयोगकर्ता (प्रॉक्सी के मुद्दे से अलग) द्वारा पहले लोड को चोट नहीं पहुंचाता है, लेकिन बाद में नेविगेशन बहुत धीमा हो सकता है।
कोर्नेल

@porneL आप कहते हैं कि हमें भेजना होगा Cache-Control: must-revalidate। पहले Cache-Control: no-cacheसे no-cacheही तात्पर्य क्यों नहीं भेजा गया must-revalidate? w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
पचेरियर

3
@Pacerier के रिश्ते no-cacheके साथ must-revalidateकैश के लिए सही है, लेकिन वापस इतिहास एक कैश नहीं है। इतिहास के व्यवहार को नियंत्रित करने के लिए ब्राउजर विशेष-मामला स्पष्ट must-revalidateहै
कोर्नेल

@ चोंच, हम्म एक सहायक आरएफसी है जो बताता है कि वांछित व्यवहार है?
पचेरियर

103

जैसा कि @Kornel ने कहा, आप जो चाहते हैं वह कैश को निष्क्रिय करने के लिए नहीं है, बल्कि इतिहास बफर को निष्क्रिय करने के लिए है। इतिहास बफ़र को अक्षम करने के लिए विभिन्न ब्राउज़रों के अपने सूक्ष्म तरीके हैं।

Chrome (v28.0.1500.95 m) में हम केवल यही कर सकते हैं Cache-Control: no-store

FireFox (v23.0.1) में इनमें से कोई भी काम करेगा:

  1. Cache-Control: no-store

  2. Cache-Control: no-cache (केवल https)

  3. Pragma: no-cache (केवल https)

  4. Vary: * (केवल https)

Opera (v12.15) में हम केवल इसे Cache-Control: must-revalidate(केवल https ) कर सकते हैं ।

सफारी में (v5.1.7, 7534.57.2) इनमें से कोई भी काम करेगा:

  1. Cache-Control: no-store
    <body onunload=""> html में

  2. Cache-Control: no-store (केवल https)

IE8 में (v8.0.6001.18702IC) इनमें से कोई भी काम करेगा:

  1. Cache-Control: must-revalidate, max-age=0

  2. Cache-Control: no-cache

  3. Cache-Control: no-store

  4. Cache-Control: must-revalidate
    Expires: 0

  5. Cache-Control: must-revalidate
    Expires: Sat, 12 Oct 1991 05:00:00 GMT

  6. Pragma: no-cache (केवल https)

  7. Vary: * (केवल https)

उपरोक्त संयोजन हमें यह समाधान देता है जो Chrome 28, FireFox 23, IE8, Safari 5.1.7 और Opera 12.15: Cache-Control: no-store, must-revalidate (केवल https) के लिए काम करता है।

ध्यान दें कि https की आवश्यकता है क्योंकि ओपेरा सादे http पृष्ठों के लिए इतिहास बफर को निष्क्रिय नहीं करेगा। अगर आपको वास्तव में https नहीं मिल रहा है और आप ओपेरा को नजरअंदाज करने के लिए तैयार हैं, तो सबसे अच्छा आप यह कर सकते हैं:

Cache-Control: no-store
<body onunload="">

नीचे मेरे परीक्षणों के कच्चे लॉग दिखाए गए हैं:

एचटीटीपी:

  1. Cache-Control: private, no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    असफलता: ओपेरा 12.15
    सफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7

  2. Cache-Control: private, no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    <body onunload="">
    असफलता: ओपेरा 12.15
    सफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7

  3. Cache-Control: private, no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    असफलता: सफारी 5.1.7, ओपेरा 12.15
    सफलता: क्रोम 28, फायरफॉक्स 23, IE8

  4. Cache-Control: private, no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    असफलता: सफारी 5.1.7, ओपेरा 12.15
    सफलता: क्रोम 28, फायरफॉक्स 23, IE8

  5. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7, ओपेरा 12.15
    सफलता: IE8

  6. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    <body onunload="">
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7, ओपेरा 12.15
    सफलता: IE8

  7. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7, ओपेरा 12.15
    सफलता: IE8

  8. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    <body onunload="">
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7, ओपेरा 12.15
    सफलता: IE8

  9. Cache-Control: no-store
    असफलता: सफारी 5.1.7, ओपेरा 12.15
    सफलता: क्रोम 28, फायरफॉक्स 23, IE8

  10. Cache-Control: no-store
    <body onunload="">
    असफलता: ओपेरा 12.15
    सफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7

  11. Cache-Control: no-cache
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7, ओपेरा 12.15
    सफलता: IE8

  12. Vary: *
    असफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7, ओपेरा 12.15
    सफलता: कोई नहीं

  13. Pragma: no-cache
    असफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7, ओपेरा 12.15
    सफलता: कोई नहीं

  14. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    <body onunload="">
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7, ओपेरा 12.15
    सफलता: IE8

  15. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7, ओपेरा 12.15
    सफलता: IE8

  16. Cache-Control: must-revalidate, max-age=0
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7, ओपेरा 12.15
    सफलता: IE8

  17. Cache-Control: must-revalidate
    Expires: 0
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7, ओपेरा 12.15
    सफलता: IE8

  18. Cache-Control: must-revalidate
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7, ओपेरा 12.15
    सफलता: IE8

  19. Cache-Control: private, must-revalidate, proxy-revalidate, s-maxage=0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    असफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7, ओपेरा 12.15
    सफलता: कोई नहीं

HTTPS:

  1. Cache-Control: private, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    <body onunload="">
    असफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7, ओपेरा 12.15
    सफलता: कोई नहीं

  2. Cache-Control: private, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    <body onunload="">
    असफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7, ओपेरा 12.15
    सफलता: कोई नहीं

  3. Vary: *
    असफलता: क्रोम 28, सफारी 5.1.7, ओपेरा 12.15
    सफलता: फायरफॉक्स 23, IE8

  4. Pragma: no-cache
    असफलता: क्रोम 28, सफारी 5.1.7, ओपेरा 12.15
    सफलता: फायरफॉक्स 23, IE8

  5. Cache-Control: no-cache
    असफलता: क्रोम 28, सफारी 5.1.7, ओपेरा 12.15
    सफलता: फायरफॉक्स 23, IE8

  6. Cache-Control: private, no-cache, max-age=0, proxy-revalidate, s-maxage=0
    असफलता: क्रोम 28, सफारी 5.1.7, ओपेरा 12.15
    सफलता: फायरफॉक्स 23, IE8

  7. Cache-Control: private, no-cache, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    असफलता: क्रोम 28, सफारी 5.1.7, ओपेरा 12.15
    सफलता: फायरफॉक्स 23, IE8

  8. Cache-Control: private, no-cache, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    असफलता: क्रोम 28, सफारी 5.1.7, ओपेरा 12.15
    सफलता: फायरफॉक्स 23, IE8

  9. Cache-Control: must-revalidate
    असफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7
    सफलता: ओपेरा 12.15

  10. Cache-Control: private, must-revalidate, proxy-revalidate, s-maxage=0
    <body onunload="">
    असफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7
    सफलता: ओपेरा 12.15

  11. Cache-Control: must-revalidate, max-age=0
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7
    सफलता: IE8, ओपेरा 12.15

  12. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    <body onunload="">
    असफलता: क्रोम 28, सफारी 5.1.7
    सफलता: फायरफॉक्स 23, IE8, ओपेरा 12.15

  13. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    असफलता: क्रोम 28, सफारी 5.1.7
    सफलता: फायरफॉक्स 23, IE8, ओपेरा 12.15

  14. Cache-Control: no-store
    असफलता: ओपेरा 12.15
    सफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7

  15. Cache-Control: private, no-cache, no-store, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    असफलता: ओपेरा 12.15
    सफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7

  16. Cache-Control: private, no-cache, no-store, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    <body onunload="">
    असफलता: ओपेरा 12.15
    सफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7

  17. Cache-Control: private, no-cache
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    असफलता: क्रोम 28, सफारी 5.1.7, ओपेरा 12.15
    सफलता: फायरफॉक्स 23, IE8

  18. Cache-Control: must-revalidate
    Expires: 0
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7,
    सफलता: IE8, ओपेरा 12.15

  19. Cache-Control: must-revalidate
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7,
    सफलता: IE8, ओपेरा 12.15

  20. Cache-Control: private, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    <body onunload="">
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7,
    सफलता: IE8, ओपेरा 12.15

  21. Cache-Control: private, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    <body onunload="">
    असफलता: क्रोम 28, फायरफॉक्स 23, सफारी 5.1.7,
    सफलता: IE8, ओपेरा 12.15

  22. Cache-Control: private, must-revalidate
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    असफलता: क्रोम 28, सफारी 5.1.7
    सफलता: फायरफॉक्स 23, IE8, ओपेरा 12.15

  23. Cache-Control: no-store, must-revalidate
    असफलता: कोई भी
    सफलता: क्रोम 28, फायरफॉक्स 23, IE8, सफारी 5.1.7, ओपेरा 12.15


3
मुझे पता है कि यह कुछ साल पहले पोस्ट किया गया था, लेकिन यह एक दिलचस्प पढ़ा गया था। कुछ महीनों से यह समस्या मुझे पागल कर रही है, शरीर वास्तव में कैश कंट्रोल से निपटने के बारे में जानता है। मैंने कुछ लोगों को इस्तेमाल करते हुए देखा है <body onunload="">लेकिन यह वास्तविक समस्या के आसपास एक तरह से अधिक लगता है। मैंने .htaccess का उपयोग करने की कोशिश की है और इस तरह हेडर को संशोधित किया है, अगर मैं HTTPS का उपयोग करता हूँ तो क्या यह उस तरह से काम करना चाहिए? यह मुख्य रूप से सफारी है जहाँ समस्या सबसे अधिक है।
जॉर्डन

4
@ जोर्डन, ऊपर दिए गए लॉग्स में अगर आपके पास HTTPS है तो ऐड Cache-Control: no-storeकरना ट्रिक करेगा। <body onunload="">केवल तभी आवश्यक है जब आपके पास HTTPS न हो।
पचेरियर

37

मैंने web.config मार्ग को उपयोगी पाया (इसे उत्तर में जोड़ने की कोशिश की, लेकिन ऐसा लगता नहीं है कि यहाँ पोस्टिंग स्वीकार की गई है)

<configuration>
<system.webServer>
    <httpProtocol>
        <customHeaders>
            <add name="Cache-Control" value="no-cache, no-store, must-revalidate" />
            <!-- HTTP 1.1. -->
            <add name="Pragma" value="no-cache" />
            <!-- HTTP 1.0. -->
            <add name="Expires" value="0" />
            <!-- Proxies. -->
        </customHeaders>
    </httpProtocol>
</system.webServer>

और यहाँ एक्सप्रेस / नोड है। ऐसा करने का तरीका:

app.use(function(req, res, next) {
    res.setHeader('Cache-Control', 'no-cache, no-store, must-revalidate');
    res.setHeader('Pragma', 'no-cache');
    res.setHeader('Expires', '0');
    next();
});

Web.config के लिए मैं केवल उन लिपियों के लिए कस्टम हेडर लागू करने के लिए थोड़ा संशोधित करूंगा, जिन्हें हम जानते हैं कि वे गतिशील रूप से लोड किए गए हैं / रिक्जेक्शंस का उपयोग कर रहे हैं। आपकी स्क्रिप्ट को क्लाइंट फ़ोल्डर में पाया जाता है: <लोकेशन पाथ = "क्लाइंट"> ..... </ लोकेशन>
इब्राहिम बेन सलाह

कौन क्या सोच रहा है, इसके web.confलिए: यह ASP.NETवेब एप्लिकेशन के लिए मुख्य सेटिंग्स और कॉन्फ़िगरेशन फ़ाइल है । यह एक XML दस्तावेज है जो रूट डायरेक्टरी में रहता है। ( विकि )।
एक और

27

मैंने पाया कि इस पृष्ठ के सभी उत्तरों में अभी भी समस्याएं थीं। विशेष रूप से, मैंने देखा कि उनमें से कोई भी IE8 को पृष्ठ के कैश्ड संस्करण का उपयोग करने से नहीं रोकेगा जब आपने बैक बटन दबाकर इसे एक्सेस किया था।

बहुत शोध और परीक्षण के बाद, मैंने पाया कि केवल दो हेडर जो मुझे वास्तव में चाहिए थे:

कैश-कंट्रोल: नो-स्टोर
वैरी: *

वैरी हैडर की व्याख्या के लिए, http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.6 देखें

IE6-8, FF1.5-3.5, Chrome 2-3, Safari 4, और ओपेरा 9-10 पर, इन हेडर के कारण पृष्ठ से सर्वर से अनुरोध किया जाता है जब आप पृष्ठ के लिंक पर क्लिक करते हैं, या URL डालते हैं सीधे एड्रेस बार में। यह सभी ब्राउज़रों का लगभग 99% जन '10 'के रूप में उपयोग करता है।

IE6, और ओपेरा 9-10 पर, बैक बटन को हिट करने के बावजूद कैश्ड संस्करण लोड किया गया। मेरे द्वारा परीक्षण किए गए अन्य सभी ब्राउज़रों पर, उन्होंने सर्वर से एक ताज़ा संस्करण प्राप्त किया। अब तक, मुझे हेडर का कोई सेट नहीं मिला है, जो उन ब्राउज़रों का कारण बने पृष्ठों के कैश्ड संस्करणों को वापस नहीं करेगा, जब आप बैक बटन दबाते हैं।

अपडेट: इस उत्तर को लिखने के बाद, मुझे महसूस हुआ कि हमारा वेब सर्वर HTTP 1.0 सर्वर के रूप में अपनी पहचान बना रहा है। मैंने जिन हेडरों को सूचीबद्ध किया है, वे ब्राउज़रों द्वारा कैश नहीं किए जाने के लिए HTTP 1.0 सर्वर से प्रतिक्रियाओं के लिए सही हैं। HTTP 1.1 सर्वर के लिए, BalusC के उत्तर को देखें


4
यह IE8 के बैक बटन के लिए काम करता है !! "वैरी: *" हेडर को जोड़ते हुए हर दूसरे सुझाव में हर चीज की कोशिश कर रहा है, जाहिर तौर पर हेडर केवल एक चीज है जो IE8 पेज को फिर से लोड करने के लिए मजबूर कर सकता है जब उपयोगकर्ता बैक बटन दबाता है। और यह HTTP / 1.1 सर्वर पर काम करता है।
coredumperror

BarlusC द्वारा सुझाए गए हेडर के साथ संयुक्त, प्लस एक जेएस स्निपेट जो window.location.reload () को कॉल करता है जब onPageShow ईवेंट "सस्पेंडेड" विशेषता (सफारी के लिए आवश्यक) के साथ चालू होता है, मैंने जो परीक्षण किया है , वह हर ब्राउज़र को लोड से पुनः लोड होने पर मजबूर करता है। सर्वर जब उपयोगकर्ता बैक बटन का उपयोग करता है।
coredumperror

1
@CoreDumpError, ओह आपको यह नहीं समझना चाहिए कि जावास्क्रिप्ट सक्षम है।
पचेरियर

@Pacerier जिस समय मैंने 2010 में उत्तर लिखा था, उस समय सफारी और ओपेरा दोनों के नवीनतम संस्करणों पर काम किया था, जिसमें हमारे सर्वर ने खुद को HTTP 1.0 सर्वर के रूप में पहचाना था। दुर्भाग्य से, मेरे पास अब इसे आसानी से जांचने का कोई तरीका नहीं है, इसलिए मैं इन ब्राउज़रों के नवीनतम संस्करणों के बारे में कुछ भी निश्चित नहीं कह सकता।
क्रिस वासेली

आपके द्वारा परीक्षण किए गए ब्राउज़र संस्करण क्या थे?
पेसियर

21

कुछ शोध के बाद हम शीर्ष लेखों की सूची के साथ आए जो कि अधिकांश ब्राउज़रों को कवर करने के लिए लगता था:

ASP.NET में हमने निम्नलिखित स्निपेट का उपयोग करके इन्हें जोड़ा है:

Response.ClearHeaders(); 
Response.AppendHeader("Cache-Control", "no-cache"); //HTTP 1.1
Response.AppendHeader("Cache-Control", "private"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "no-store"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "must-revalidate"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "max-stale=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "post-check=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "pre-check=0"); // HTTP 1.1 
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0 
Response.AppendHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT"); // HTTP 1.0 

से मिला: http://forums.asp.net/t/1013531.aspx


35
@ बर्ट: इससे भी ज्यादा तकलीफदेह बात यह है कि 1997 में 26 जुलाई का दिन शनिवार का था, सोमवार का नहीं ...
C12

5
Cache-Control: no-cacheऔर Cache-Control: privateटकराव - आप दोनों को कभी भी एक साथ नहीं मिलना चाहिए: पूर्व ब्राउज़रों को बताता है और प्रॉक्सी को कैश नहीं करने के लिए कहता है। मुझे यकीन नहीं है कि कौन सा सेटिंग ब्राउज़र का पालन करेगा, लेकिन यह ब्राउज़र और संस्करणों के बीच संगत होने की संभावना नहीं है।
कीथ

प्री-चेक और पोस्ट-चेक का उपयोग न करें। blogs.msdn.com/b/ieinternals/archive/2009/07/20/…
EricLaw

यह मेरे लिए काम नहीं कर रहा था - asp.net 4.5 कोड का उपयोग करते हुए, लेकिन आवश्यक परिणाम नहीं देता है। मुझे इसका अनुसरण करना था: stackoverflow.com/questions/22443932/…
एंडी

8

प्रतिक्रिया में प्रागमा हेडर का उपयोग एक पत्नियों की कहानी है। RFC2616 केवल इसे एक अनुरोध शीर्ष लेख के रूप में परिभाषित करता है

http://www.mnot.net/cache_docs/#PRAGMA


4
यह एक अच्छा उदाहरण है कि आपको ऐनक से परे जाने की आवश्यकता क्यों है। यदि चश्मा हमेशा क्रिस्टल स्पष्ट होते हैं, तो StackOverflow जैसी साइटों के लिए बहुत अधिक बिंदु नहीं होगा। Microsoft से HTTP 1.0 सर्वर के साथ पिछड़े संगतता के प्रयोजनों के लिए, इंटरनेट एक्सप्लोरर HTTP प्राग्म के विशेष उपयोग का समर्थन करता है: नो-कैश हेडर। यदि क्लाइंट एक सुरक्षित कनेक्शन (https: //) से अधिक सर्वर से संपर्क करता है और सर्वर एक प्रज्ञा देता है: प्रतिक्रिया के साथ नो-कैश हेडर, इंटरनेट एक्सप्लोरर प्रतिक्रिया को कैश नहीं करता है।
माइकल जूल

@michaelok: आपका संदर्भ मान्य है, लेकिन बड़े बिंदु को याद करता है- एक उचित कैश-कंट्रोल / एक्सपायर सेट करें और आपको प्रज्ञा की आवश्यकता नहीं है।
12

8

अस्वीकरण: मैं दृढ़ता से @ BalusC के उत्तर को पढ़ने का सुझाव देता हूं। निम्नलिखित कैशिंग ट्यूटोरियल पढ़ने के बाद: http://www.mnot.net/cache_docs/ (मैं आपको इसे पढ़ने की सलाह देता हूं, भी), मेरा मानना ​​है कि यह सही है। हालाँकि, ऐतिहासिक कारणों से (और क्योंकि मैंने खुद इसका परीक्षण किया है), मैं नीचे अपना मूल उत्तर शामिल करूंगा:


मैंने PHP के लिए 'स्वीकृत' उत्तर की कोशिश की, जो मेरे काम नहीं आया। फिर मैंने थोड़ा शोध किया, एक मामूली रूपांतर पाया, इसका परीक्षण किया, और यह काम किया। यह रहा:

header('Cache-Control: no-store, private, no-cache, must-revalidate');     // HTTP/1.1
header('Cache-Control: pre-check=0, post-check=0, max-age=0, max-stale = 0', false);  // HTTP/1.1
header('Pragma: public');
header('Expires: Sat, 26 Jul 1997 05:00:00 GMT');                  // Date in the past  
header('Expires: 0', false); 
header('Last-Modified: '.gmdate('D, d M Y H:i:s') . ' GMT');
header ('Pragma: no-cache');

वह काम करना चाहिए। समस्या यह थी कि हेडर के एक ही हिस्से को दो बार सेट करते समय, यदि falseहेडर फ़ंक्शन के दूसरे तर्क के रूप में नहीं भेजा जाता है, तो हेडर फ़ंक्शन पिछले header()कॉल को अधिलेखित कर देगा । इसलिए, Cache-Controlउदाहरण के लिए, यदि कोई एक header()फ़ंक्शन कॉल में सभी तर्क नहीं देना चाहता है , तो उसे कुछ ऐसा करना चाहिए:

header('Cache-Control: this');
header('Cache-Control: and, this', false);

अधिक पूर्ण प्रलेखन यहाँ देखें ।


14
यह मिथकों से भरा है। प्री-चेक और पोस्ट-चेक आईई-ओनली हैं, जो केवल कैश्ड प्रतिक्रियाओं के लिए प्रासंगिक हैं, और 0 मूल्य एक नो-ऑप है। अधिकतम-बासी प्रॉक्सी अनुरोध हेडर है, सर्वर प्रतिक्रिया हेडर नहीं। समय सीमा समाप्त केवल एकल मान स्वीकार करता है। एक से अधिक इस हेडर को अनदेखा करने का कारण होगा।
कोर्नेल

1
@porneL, क्या आप एक प्रतिस्पर्धी उत्तर प्रस्तुत कर रहे हैं जो इन मिथकों से सही तरीके से निपटता है?
1

@Oddthinking, ऐसा दिखता है जैसे stackoverflow.com/questions/49547/… एक प्रतिस्पर्धी उत्तर है।
माइक ओटम

@Pacerier हाँ, जैसा कि मैंने अस्वीकरण में कहा है, BalusC के उत्तर का उपयोग करें।
स्टीवन ऑक्सले

8

ASP.NET कोर के लिए, एक साधारण मिडलवेयर क्लास बनाएँ:

public class NoCacheMiddleware
{
    private readonly RequestDelegate m_next;

    public NoCacheMiddleware( RequestDelegate next )
    {
        m_next = next;
    }

    public async Task Invoke( HttpContext httpContext )
    {
        httpContext.Response.OnStarting( ( state ) =>
        {
            // ref: http://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers
            httpContext.Response.Headers.Append( "Cache-Control", "no-cache, no-store, must-revalidate" );
            httpContext.Response.Headers.Append( "Pragma", "no-cache" );
            httpContext.Response.Headers.Append( "Expires", "0" );
            return Task.FromResult( 0 );
        }, null );

        await m_next.Invoke( httpContext );
    }
}

फिर इसे पंजीकृत करें Startup.cs

app.UseMiddleware<NoCacheMiddleware>();

सुनिश्चित करें कि आप इसे कहीं और जोड़ दें

app.UseStaticFiles();

मैं Microsoft.Net.Http.Headers.eaderNames से लगातार स्ट्रिंग शाब्दिक "कैश-कंट्रोल", "प्रागमा" और "एक्सपायर" के बजाय कॉन्स्टेंट का उपयोग करने का सुझाव दूंगा।
विक्टर शारोवतोव

7

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

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


7

IE6 में एक बग है

यदि आप "कैश-कंट्रोल: नो-कैश" का उपयोग करते हैं तो भी "कंटेंट-एनकोडिंग: गज़िप" की सामग्री हमेशा कैश की जाती है।

http://support.microsoft.com/kb/321722

आप IE6 उपयोगकर्ताओं के लिए gzip संपीड़न को अक्षम कर सकते हैं ("MSIE 6" के लिए उपयोगकर्ता एजेंट की जाँच करें)


6

HTTP 1.1 के लिए RFC का कहना है कि उचित विधि के लिए एक HTTP हैडर जोड़ना है:

कैश-कंट्रोल: नो-कैश

पुराने ब्राउज़र इसे अनदेखा कर सकते हैं यदि वे HTTP 1.1 के लिए ठीक से अनुपालन नहीं कर रहे हैं। उन लोगों के लिए आप शीर्ष लेख आज़मा सकते हैं:

प्रज्ञा: नो-कैश

यह HTTP 1.1 ब्राउज़रों के लिए भी काम करने वाला है।


1
युक्ति इंगित करती है कि प्रतिक्रिया का पुन: उपयोग नहीं किया जाना चाहिए। यह कैश-कंट्रोल है: नो-स्टोर जो यह इंगित करने के लिए आधिकारिक विधि है कि प्रतिक्रिया को पहले से कैश में संग्रहीत नहीं किया जाना चाहिए।
एंथनीवजोन

6

1995 में कुछ तारीखों में संशोधित http हेडर सेट करना आमतौर पर ट्रिक है।

यहाँ एक उदाहरण है:

अवसान: बुध, 15 नवंबर 1995 04:58:08 GMT
अंतिम-संशोधित: बुध, 15 नवंबर 1995 04:58:08 GMT
कैश-कंट्रोल: नो-कैश, री-रिवाइंड करना चाहिए

1
एक लंबे समय से पहले लास्ट-मॉडिफाइड सेट करने का कैशिंग पर कोई प्रभाव नहीं पड़ता है, कैश्ड रिस्पांस देने के अलावा अन्य का उपयोग हेयुरिस्टिक रिवीलेशन के कारण लंबे समय तक किया जाता है।
12

6

हैडर समारोह के लिए पीएचपी प्रलेखन एक नहीं बल्कि पूर्ण उदाहरण (एक तीसरी पार्टी के योगदान) होते हैं:

    header('Pragma: public');
    header("Expires: Sat, 26 Jul 1997 05:00:00 GMT");                  // Date in the past   
    header('Last-Modified: '.gmdate('D, d M Y H:i:s') . ' GMT');
    header('Cache-Control: no-store, no-cache, must-revalidate');     // HTTP/1.1
    header('Cache-Control: pre-check=0, post-check=0, max-age=0', false);    // HTTP/1.1
    header ("Pragma: no-cache");
    header("Expires: 0", false);

11
यह स्पष्ट रूप से गलत है। समाप्ति, कैश-नियंत्रण और प्राग्मा के लिए हेडर () के लिए दूसरा कॉल पहले से निर्धारित मूल्यों को पूरी तरह से अधिलेखित करता है।
कोर्नेल

1
@porneL: नहीं, पहले से निर्धारित मानों को अधिलेखित न करें क्योंकि वह पिछले मानों को ओवरराइड नहीं करने के लिए कहकर एक दूसरे पैरामीटर के रूप में गलत है।
जुलिएन पैलार्ड

1
मेरी टिप्पणी के बाद @JulienPalard को संपादित किया गया है। यह अभी भी बहुत मतलब नहीं है।
कोर्नेल

यदि आप IE में काम करना चाहते हैं, तो एकाधिक कैश-कंट्रोल हेडर को 9 पर न भेजें। कभी भी प्री-चेक या पोस्ट-चेक न भेजें। blogs.msdn.com/b/ieinternals/archive/2009/07/20/…
EricLaw

6

यदि आप एसएसएल और कैश पर IE6-IE8 के साथ डाउनलोड समस्याओं का सामना कर रहे हैं: एमएस ऑफिस फ़ाइलों के साथ नो-कैश हेडर (और इसी तरह के मूल्य) आप कैश का उपयोग कर सकते हैं: निजी, नो-स्टोर हेडर और पीओएसटी अनुरोध पर रिटर्न फाइल। यह काम करता हैं।


6

मेरे मामले में मैं इस के साथ क्रोम में समस्या को ठीक

<form id="form1" runat="server" autocomplete="off">

जब मुझे उपयोगकर्ताओं को सुरक्षा कारणों से वापस क्लिक करने पर प्रीवियस फॉर्म डेटा की सामग्री को साफ़ करने की आवश्यकता होती है


मेरा मोज़िला 19.x ब्राउज़र समस्या भी कोड स्निपेट द्वारा हल हो गई। स्वत: पूर्ण = "बंद"। धन्यवाद।
सत्या

5

स्वीकृत उत्तर IIS7 + के लिए काम नहीं करता है, कैश हेडर के बारे में बड़ी संख्या में प्रश्न II7 में नहीं भेजे जा रहे हैं:

और इसी तरह

स्वीकृत उत्तर सही है जिसमें हेडर सेट होना चाहिए, लेकिन इसमें नहीं कि उन्हें कैसे सेट किया जाना चाहिए। यह तरीका IIS7 के साथ काम करता है:

Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.AppendCacheExtension("no-store, must-revalidate");
Response.AppendHeader("Pragma", "no-cache");
Response.AppendHeader("Expires", "-1");

पहली पंक्ति सेट Cache-controlहोती है no-cache, और दूसरी पंक्ति अन्य विशेषताओं को जोड़ती हैno-store, must-revalidate


यह मेरे लिए काम करता है:Response.Cache.SetAllowResponseInBrowserHistory(false); Response.Cache.SetCacheability(HttpCacheability.NoCache); Response.Cache.SetNoStore(); Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches);
Vilx-

4

मैंने प्राग्मा: नो-कैश की स्थापना करके सभी ब्राउज़रों में सर्वश्रेष्ठ और सबसे सुसंगत परिणाम प्राप्त किए हैं


4

BalusC द्वारा दिए गए उत्तर में हेडर सफारी 5 (और संभवतः पुराने संस्करणों के साथ) को ब्राउज़र के बैक बटन का उपयोग करते समय ब्राउज़र कैश से सामग्री प्रदर्शित करने से नहीं रोकता है। इसे रोकने का एक तरीका यह है कि शरीर के टैग पर एक खाली ऑनलोड लोड हैंडलर विशेषता को जोड़ा जाए:

<body onunload=""> 

यह हैक जाहिर तौर पर सफारी में बैक-फॉरवर्ड कैश को तोड़ता है: क्या बैक बटन पर क्लिक करने पर क्रॉस-ब्राउज़र ऑनलोड घटना होती है?


कूल, मैंने इसका परीक्षण किया है और यह वास्तव में सफारी (5.1.7) पर काम करता है, लेकिन ओपेरा नहीं।
पचेरियर

4

इसके अलावा, केवल अच्छे उपाय के लिए, सुनिश्चित करें कि आप ExpiresDefaultअपनी .htaccessफ़ाइल में रीसेट कर सकते हैं यदि आप कैशिंग को सक्षम करने के लिए उपयोग कर रहे हैं।

ExpiresDefault "access plus 0 seconds"

बाद में, आप उन ExpiresByTypeफ़ाइलों के लिए विशिष्ट मान सेट करने के लिए उपयोग कर सकते हैं जिन्हें आप कैश करना चाहते हैं:

ExpiresByType image/x-icon "access plus 3 month"

यह भी काम आ सकता है अगर आपकी डायनामिक फाइल्स जैसे php, आदि को ब्राउज़र द्वारा कैश किया जा रहा है, और आप इसका पता नहीं लगा सकते हैं। जाँच करें ExpiresDefault


3

शीर्षकों के अलावा, https के माध्यम से अपने पृष्ठ की सेवा करने पर विचार करें । कई ब्राउज़र डिफ़ॉल्ट रूप से https को कैश नहीं करेंगे।


3
//In .net MVC
[OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")]
public ActionResult FareListInfo(long id)
{
}

// In .net webform
<%@ OutputCache NoStore="true" Duration="0" VaryByParam="*" %>

2

BalusC -> ANSWER को पूरा करने के लिए यदि आप पर्ल का उपयोग कर रहे हैं तो आप HTTP हेडर जोड़ने के लिए CGI का उपयोग कर सकते हैं।

पर्ल का उपयोग करना:

Use CGI;    
sub set_new_query() {
        binmode STDOUT, ":utf8";
        die if defined $query;
        $query = CGI->new();
        print $query->header(
                        -expires       => 'Sat, 26 Jul 1997 05:00:00 GMT',
                        -Pragma        => 'no-cache',
                        -Cache_Control => join(', ', qw(
                                            private
                                            no-cache
                                            no-store
                                            must-revalidate
                                            max-age=0
                                            pre-check=0
                                            post-check=0 
                                           ))
        );
    }

Apache httpd.conf का उपयोग करना

<FilesMatch "\.(html|htm|js|css|pl)$">
FileETag None
<ifModule mod_headers.c>
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
</ifModule>

नोट: जब मैंने html मेटा का उपयोग करने का प्रयास किया, तो ब्राउज़र ने उन्हें अनदेखा कर दिया और पृष्ठ को कैश कर दिया।


0

मैं केवल यह बताना चाहता हूं कि अगर कोई केवल गतिशील सामग्री को कैशिंग से रोकना चाहता है, तो उन अतिरिक्त हेडर को जोड़कर प्रोग्रामेटिक रूप से बनाया जाना चाहिए।

मैंने नो-कैश हेडर को जोड़ने के लिए अपनी परियोजना की कॉन्फ़िगरेशन फ़ाइल को संपादित किया, लेकिन यह भी स्थिर कैशिंग स्थिर सामग्री को अक्षम कर दिया, जो आमतौर पर वांछनीय नहीं है। कोड में प्रतिक्रिया हेडर को संशोधित करने का आश्वासन दिया गया है कि चित्र और शैली की फाइलें कैश की जाएंगी।

यह काफी स्पष्ट है, फिर भी ध्यान देने योग्य है।

और एक और सावधानी। HttpResponse वर्ग से ClearHeaders पद्धति का उपयोग करके सावधान रहें। यदि आप लापरवाही से इसका उपयोग करते हैं तो यह आपको कुछ चोट दे सकता है। जैसे इसने मुझे दिया।

ActionFilterAttribute घटना पर पुनर्निर्देशन के बाद सभी हेडर साफ़ करने के परिणाम TempData संग्रहण में सभी सत्र डेटा और डेटा खो रहे हैं। यह एक एक्शन से रीडायरेक्ट करने के लिए सुरक्षित है या रीडायरेक्शन होने पर हेडर को साफ़ न करें।

दूसरे विचार पर मैं ClearHeaders पद्धति का उपयोग करने के लिए सभी को हतोत्साहित करता हूं। हेडर को अलग से निकालना बेहतर है। और कैश-कंट्रोल हेडर को ठीक से सेट करने के लिए मैं इस कोड का उपयोग कर रहा हूं:

filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
filterContext.HttpContext.Response.Cache.AppendCacheExtension("no-store, must-revalidate");

0

मुझे <head><meta>तत्वों से कोई मतलब नहीं था । HTTP कैश संबंधित मापदंडों को सीधे (HTML डॉक के बाहर) जोड़ना मेरे लिए वास्तव में काम करता है।

Web.py web.headerकॉल का उपयोग करके पायथन में नमूना कोड निम्नानुसार है। मैंने अपने व्यक्तिगत अप्रासंगिक उपयोगिता कोड को उद्देश्यपूर्ण रूप से कम कर दिया है।

    आयात वेब
    आयात sys
    व्यक्तिगत-आयात आयात करें

    myname = "main.py"

    urls = (
        '/', 'main_class'
    )

    मुख्य = web.application (urls, ग्लोबल्स ())

    रेंडर = web.template.render ("टेम्पलेट /", आधार = "लेआउट", कैश = गलत)

    वर्ग main_class (ऑब्जेक्ट):
        डीईटी प्राप्त करें (स्व):
            web.header ("कैश-कंट्रोल", "नो-कैश, नो-स्टोर, मस्ट-रिवाइल्ड")
            web.header ("प्राग्मा", "नो-कैश")
            web.header ("समाप्ति", "0")
            लौटाना ।.main_form ()

        POST को ख़त्म करें (स्व):
            संदेश = "पोस्ट किया गया:"
            फ़ॉर्म = web.input (फ़ंक्शन = कोई नहीं)
            web.header ("कैश-कंट्रोल", "नो-कैश, नो-स्टोर, मस्ट-रिवाइल्ड")
            web.header ("प्राग्मा", "नो-कैश")
            web.header ("समाप्ति", "0")
            वापसी रेंडर .index_laid_out (ग्रीटिंग = msg + form.function)

    अगर __name__ == "__main__":
        nargs = len (sys.argv)
        # सुनिश्चित करें कि अजगर कार्यक्रम के नाम के बाद पर्याप्त तर्क हैं
        अगर नरगिस! = 2:
            LOG-AND-DIE ("% s: कमांड लाइन एरर, नार्स =% s, 2 होना चाहिए", myname; नर्ग्स)
        # सुनिश्चित करें कि टीसीपी पोर्ट संख्या संख्यात्मक है
        प्रयत्न:
            tcp_port = int (sys.argv [1])
        ई के रूप में अपवाद को छोड़कर:
            LOG-AND-DIE ("% s: tcp_port = int (% s) विफल (पूर्णांक नहीं)", myname, sys.argv [1])
        # सब ठीक हैं!
        JUST-LOG ("% s: पोर्ट% d पर चल रहा है", myname, tcp_port)
        web.httpserver.runsimple (main.wsgifunc) (, ("लोकलहोस्ट", tcp_port))
        main.run ()


क्या यह वर्षों से साइट पर मौजूद उत्तरों में पहले से ही कई बार कवर नहीं किया गया है?
मार्टिन टूरनोइज

मेटा निर्देश इंटरनेट एक्सप्लोरर और एज 18 और उससे पहले के संस्करणों में काम करता है। आधुनिक ब्राउज़र उनका समर्थन नहीं करते हैं। crbug.com/2763
एरिकलॉ

0

कैशिंग पर केस स्टडी के लिए यह लिंक देखें:

http://securityevaluators.com/knowledge/case_studies/caching/

सारांश, लेख के अनुसार, केवल Cache-Control: no-storeक्रोम, फ़ायरफ़ॉक्स और IE पर काम करता है। IE अन्य नियंत्रणों को स्वीकार करता है, लेकिन क्रोम और फ़ायरफ़ॉक्स नहीं करते हैं। लिंक कैशिंग और अवधारणा के दस्तावेजीकरण के इतिहास के साथ एक अच्छा पढ़ा पूरा है।


0

यकीन नहीं होता अगर मेरा उत्तर सरल और बेवकूफ लगता है, और शायद यह आपको पहले से ही लंबे समय से पहले से ही पता है, लेकिन चूंकि किसी ने ब्राउज़र बैक बटन का उपयोग करने से रोकने के लिए अपने ऐतिहासिक पृष्ठों को देखना आपके लक्ष्यों में से एक है, तो आप उपयोग कर सकते हैं:

window.location.replace("https://www.example.com/page-not-to-be-viewed-in-browser-history-back-button.html");

बेशक, यह पूरी साइट पर लागू होने के लिए संभव नहीं है, लेकिन कम से कम कुछ महत्वपूर्ण पृष्ठों के लिए, आप ऐसा कर सकते हैं। उम्मीद है की यह मदद करेगा।


-1

आप IIS में कैशिंग पूरे ऐप के बजाय सेट व्यक्तिगत फ़ाइल के लिए स्थान ब्लॉक का उपयोग कर सकते हैं

 <location path="index.html">
    <system.webServer>
      <httpProtocol>
        <customHeaders>
          <add name="Cache-Control" value="no-cache" />
        </customHeaders>
      </httpProtocol>
    </system.webServer>
  </location>
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.