How do we control web page caching, across all browsers?

disable browser cache using javascript
cache-control best practices
cache-control example
browser caching
how browser cache works
multiple cache-control headers
cache-control: max-age=0
angular cache-control

Our investigations have shown us that not all browsers respect the HTTP cache directives in a uniform manner.

For security reasons we do not want certain pages in our application to be cached, ever, by the web browser. This must work for at least the following browsers:

  • Internet Explorer 6+
  • Firefox 1.5+
  • Safari 3+
  • Opera 9+
  • Chrome

Our requirement came from a security test. After logging out from our website you could press the back button and view cached pages.

Introduction

The correct minimum set of headers that works across all mentioned clients (and proxies):

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

The Cache-Control is per the HTTP 1.1 spec for clients and proxies (and implicitly required by some clients next to Expires). The Pragma is per the HTTP 1.0 spec for prehistoric clients. The Expires is per the HTTP 1.0 and 1.1 specs for clients and proxies. In HTTP 1.1, the Cache-Control takes precedence over Expires, so it's after all for HTTP 1.0 proxies only.

If you don't care about IE6 and its broken caching when serving pages over HTTPS with only no-store, then you could omit Cache-Control: no-cache.

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

If you don't care about IE6 nor HTTP 1.0 clients (HTTP 1.1 was introduced 1997), then you could omit Pragma.

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

If you don't care about HTTP 1.0 proxies either, then you could omit Expires.

Cache-Control: no-store, must-revalidate

On the other hand, if the server auto-includes a valid Date header, then you could theoretically omit Cache-Control too and rely on Expires only.

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

But that may fail if e.g. the end-user manipulates the operating system date and the client software is relying on it.

Other Cache-Control parameters such as max-age are irrelevant if the abovementioned Cache-Control parameters are specified. The Last-Modified header as included in most other answers here is only interesting if you actually want to cache the request, so you don't need to specify it at all.

How to set it?

Using PHP:

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

Using Java Servlet, or 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.

Using 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.

Using ASP.NET Web 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()); 

Using 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.

Using 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";

Using 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.

Using Ruby on Rails, or Python/Flask:

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

Using Python/Django:

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

Using Python/Pyramid:

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

Using Go:

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.

Using Apache .htaccess file:

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

Using 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 meta tags vs HTTP response headers

Important to know is that when an HTML page is served over an HTTP connection, and a header is present in both the HTTP response headers and the HTML <meta http-equiv> tags, then the one specified in the HTTP response header will get precedence over the HTML meta tag. The HTML meta tag will only be used when the page is viewed from a local disk file system via a file:// URL. See also W3 HTML spec chapter 5.2.2. Take care with this when you don't specify them programmatically because the webserver can namely include some default values.

Generally, you'd better just not specify the HTML meta tags to avoid confusion by starters and rely on hard HTTP response headers. Moreover, specifically those <meta http-equiv> tags are invalid in HTML5. Only the http-equiv values listed in HTML5 specification are allowed.

Verifying the actual HTTP response headers

To verify the one and other, you can see/debug them in HTTP traffic monitor of webbrowser's developer toolset. You can get there by pressing F12 in Chrome/Firefox23+/IE9+, and then opening the "Network" or "Net" tab panel, and then clicking the HTTP request of interest to uncover all detail about the HTTP request and response. The below screenshot is from Chrome:

I want to set those headers on file downloads too

First of all, this question and answer are targeted on "web pages" (HTML pages), not "file downloads" (PDF, zip, Excel, etc). You'd better have them cached and make use of some file version identifier somewhere in URI path or querystring to force a redownload on a changed file. When applying those no-cache headers on file downloads anyway, then beware of the IE7/8 bug when serving a file download over HTTPS instead of HTTP. For detail, see IE cannot download foo.jsf. IE was not able to open this internet site. The requested site is either unavailable or cannot be found.

Cache-Control, The browser's HTTP Cache is your first line of defense. of cached responses, but it's effective, it's supported in all browsers, HTML, and the browser automatically takes care of HTTP caching for you, without extra effort. Cache-Control is for browsers and proxies using the HTTP/1.1 protocol. Pragma is for old browsers using the HTTP/1.0 protocol. Expires is for browsers and proxies, although in HTTP/1.1 Cache-Control takes precedence over Expires . You can set the response headers for a page served over a HTTP connection. Classic ASP

Appendix: Cache-Control examples, Covers the how's and why's of Web caching for people who publish on the Web. by a few browser caches, not proxy caches (which almost never read the HTML in The Expires HTTP header is a basic means of controlling caches; it tells all  Proceed to disable the cache by checking the Disable cache checkbox and hitting Reload. In this case, you see that the Status Code is 200 without any indication that it used the cache. The browser requested the resource from the web server, and the web server responded by serving back a fresh copy.

As @Kornel stated, what you want is not to deactivate the cache, but to deactivate the history buffer. Different browsers have their own subtle ways to disable the history buffer.

In Chrome (v28.0.1500.95 m) we can do this only by Cache-Control: no-store.

In FireFox (v23.0.1) any one of these will work:

  1. Cache-Control: no-store

  2. Cache-Control: no-cache (https only)

  3. Pragma: no-cache (https only)

  4. Vary: * (https only)

In Opera (v12.15) we only can do this by Cache-Control: must-revalidate (https only).

In Safari (v5.1.7, 7534.57.2) any one of these will work:

  1. Cache-Control: no-store <body onunload=""> in html

  2. Cache-Control: no-store (https only)

In IE8 (v8.0.6001.18702IC) any one of these will work:

  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 only)

  7. Vary: * (https only)

Combining the above gives us this solution which works for Chrome 28, FireFox 23, IE8, Safari 5.1.7, and Opera 12.15: Cache-Control: no-store, must-revalidate (https only)

Note that https is needed because Opera wouldn't deactivate history buffer for plain http pages. If you really can't get https and you are prepared to ignore Opera, the best you can do is this:

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

Below shows the raw logs of my tests:

HTTP:

  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=""> Fail: Opera 12.15 Success: Chrome 28, FireFox 23, IE8, Safari 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=""> Fail: Opera 12.15 Success: Chrome 28, FireFox 23, IE8, Safari 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: * Fail: Safari 5.1.7, Opera 12.15 Success: Chrome 28, FireFox 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: * Fail: Safari 5.1.7, Opera 12.15 Success: Chrome 28, FireFox 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=""> Fail: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15 Success: 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=""> Fail: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15 Success: 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=""> Fail: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15 Success: 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=""> Fail: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15 Success: IE8

  9. Cache-Control: no-store Fail: Safari 5.1.7, Opera 12.15 Success: Chrome 28, FireFox 23, IE8

  10. Cache-Control: no-store <body onunload=""> Fail: Opera 12.15 Success: Chrome 28, FireFox 23, IE8, Safari 5.1.7

  11. Cache-Control: no-cache Fail: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15 Success: IE8

  12. Vary: * Fail: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15 Success: none

  13. Pragma: no-cache Fail: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15 Success: none

  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=""> Fail: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15 Success: 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=""> Fail: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15 Success: IE8

  16. Cache-Control: must-revalidate, max-age=0 Fail: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15 Success: IE8

  17. Cache-Control: must-revalidate Expires: 0 Fail: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15 Success: IE8

  18. Cache-Control: must-revalidate Expires: Sat, 12 Oct 1991 05:00:00 GMT Fail: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15 Success: IE8

  19. Cache-Control: private, must-revalidate, proxy-revalidate, s-maxage=0 Pragma: no-cache Vary: * <body onunload=""> Fail: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15 Success: none

HTTPS:

  1. Cache-Control: private, max-age=0, proxy-revalidate, s-maxage=0 Expires: 0 <body onunload=""> Fail: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15 Success: none

  2. Cache-Control: private, max-age=0, proxy-revalidate, s-maxage=0 Expires: Sat, 12 Oct 1991 05:00:00 GMT <body onunload=""> Fail: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15 Success: none

  3. Vary: * Fail: Chrome 28, Safari 5.1.7, Opera 12.15 Success: FireFox 23, IE8

  4. Pragma: no-cache Fail: Chrome 28, Safari 5.1.7, Opera 12.15 Success: FireFox 23, IE8

  5. Cache-Control: no-cache Fail: Chrome 28, Safari 5.1.7, Opera 12.15 Success: FireFox 23, IE8

  6. Cache-Control: private, no-cache, max-age=0, proxy-revalidate, s-maxage=0 Fail: Chrome 28, Safari 5.1.7, Opera 12.15 Success: FireFox 23, IE8

  7. Cache-Control: private, no-cache, max-age=0, proxy-revalidate, s-maxage=0 Expires: 0 Pragma: no-cache Vary: * Fail: Chrome 28, Safari 5.1.7, Opera 12.15 Success: FireFox 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: * Fail: Chrome 28, Safari 5.1.7, Opera 12.15 Success: FireFox 23, IE8

  9. Cache-Control: must-revalidate Fail: Chrome 28, FireFox 23, IE8, Safari 5.1.7 Success: Opera 12.15

  10. Cache-Control: private, must-revalidate, proxy-revalidate, s-maxage=0 <body onunload=""> Fail: Chrome 28, FireFox 23, IE8, Safari 5.1.7 Success: Opera 12.15

  11. Cache-Control: must-revalidate, max-age=0 Fail: Chrome 28, FireFox 23, Safari 5.1.7 Success: IE8, Opera 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=""> Fail: Chrome 28, Safari 5.1.7 Success: FireFox 23, IE8, Opera 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=""> Fail: Chrome 28, Safari 5.1.7 Success: FireFox 23, IE8, Opera 12.15

  14. Cache-Control: no-store Fail: Opera 12.15 Success: Chrome 28, FireFox 23, IE8, Safari 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=""> Fail: Opera 12.15 Success: Chrome 28, FireFox 23, IE8, Safari 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=""> Fail: Opera 12.15 Success: Chrome 28, FireFox 23, IE8, Safari 5.1.7

  17. Cache-Control: private, no-cache Expires: Sat, 12 Oct 1991 05:00:00 GMT Pragma: no-cache Vary: * Fail: Chrome 28, Safari 5.1.7, Opera 12.15 Success: FireFox 23, IE8

  18. Cache-Control: must-revalidate Expires: 0 Fail: Chrome 28, FireFox 23, Safari 5.1.7, Success: IE8, Opera 12.15

  19. Cache-Control: must-revalidate Expires: Sat, 12 Oct 1991 05:00:00 GMT Fail: Chrome 28, FireFox 23, Safari 5.1.7, Success: IE8, Opera 12.15

  20. Cache-Control: private, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0 Expires: 0 <body onunload=""> Fail: Chrome 28, FireFox 23, Safari 5.1.7, Success: IE8, Opera 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=""> Fail: Chrome 28, FireFox 23, Safari 5.1.7, Success: IE8, Opera 12.15

  22. Cache-Control: private, must-revalidate Expires: Sat, 12 Oct 1991 05:00:00 GMT Pragma: no-cache Vary: * Fail: Chrome 28, Safari 5.1.7 Success: FireFox 23, IE8, Opera 12.15

  23. Cache-Control: no-store, must-revalidate Fail: none Success: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15

Caching Tutorial for Web Authors and Webmasters, How can I prevent Web browsers from caching my pages? When you change a page on your site, the change  Almost every web server has some cache settings in header responses by default, but it isn’t clear what we get if there are no cache policies. Without cache control settings, the browser goes to

I found the web.config route useful (tried to add it to the answer but doesn't seem to have been accepted so posting here)

<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>

And here is the express / node.js way of doing the same:

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();
});

Preventing Browser Caching, Cache-control is an HTTP header used to specify browser caching policies in both For example, a web page response marked as private can be cached by a​  Overview. Caching is a useful yet surprisingly complex feature of web browsers. In this article, we’ll explain the how the browser uses its cache to load pages faster, which factors determine

I found that all of the answers on this page still had problems. In particular, I noticed that none of them would stop IE8 from using a cached version of the page when you accessed it by hitting the back button.

After much research and testing, I found that the only two headers I really needed were:

Cache-Control: no-store Vary: *

For an explanation of the Vary header, check out http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.6

On IE6-8, FF1.5-3.5, Chrome 2-3, Safari 4, and Opera 9-10, these headers caused the page to be requested from the server when you click on a link to the page, or put the URL directly in the address bar. That covers about 99% of all browsers in use as of Jan '10.

On IE6, and Opera 9-10, hitting the back button still caused the cached version to be loaded. On all other browsers I tested, they did fetch a fresh version from the server. So far, I haven't found any set of headers that will cause those browsers to not return cached versions of pages when you hit the back button.

Update: After writing this answer, I realized that our web server is identifying itself as an HTTP 1.0 server. The headers I've listed are the correct ones in order for responses from an HTTP 1.0 server to not be cached by browsers. For an HTTP 1.1 server, look at BalusC's answer.

What is Cache-Control and How HTTP Cache Headers Work, When a user visits a web page, the contents of that page can be stored in the browser's cache so from their local cache, or whether they want the content cached at all. The inclusion of just an Expires header with no Cache-Control header  In addition to configuring general cache settings, there are additional settings to configure that control whether SSL content is cached. When this option is enabled any SSL content is not stored to disk this includes the static images and includes forcing the browser to request the content on every visit to the page.

Caching Behavior of Web Browsers, When someone visits a website, everything the site needs to display and The next time the browser hits that page, it can look in the cache for Two main types of cache headers, cache-control and expires, define the  How to Force Refresh a Single Page Before you go straight to clearing your entire browser cache, one trick you can try is something called a “force refresh”. Normally, when you refresh a page, your browser still serves up the cached version of the page, rather than downloading all of the assets again.

HTTP Caching | Web Fundamentals, The minimum set of HTML headers to disable browser caching that works across the most important browsers: Cache-Control, Pragma,  By using a browser caching mechanism you tell the browser of your visitor to copy and store your web files for later use. When your visitor re-visits your website these copies can be used without the visitor having to re-download the files.

Disable browser caching with meta HTML tags, Most browsers and intermediate proxies today respect this expiration However, the page remains in the disk cache ("Temporary Internet Files") and is prevents all caching of a particular Web resource when the no-cache  I found that Chrome responds better to Cache-Control: no-cache (100% conditional requests afterwards). "no-store" sometimes loaded from cache without even attempting a conditional request. Firefox responds better to "no-store" but still sometimes loads from cache if you reload immediately afterwords.

Comments
  • Just for ipad Safari, Does [this][1] help? [1]: stackoverflow.com/questions/24524248/…
  • The simplest is using: max-age=10 . This is not perfect because the page will be cached for 10 seconds. But it's the least "header spaghetti" solution out there. Also, this sometimes provides a big performance boost on dynamic websites who use reverse proxies. (Your slow php script will be called once every 10 seconds and will then be cached by the reverse proxy. once per 10 seconds is way better than once per visitor)
  • Also see securityevaluators.com/knowledge/case_studies/caching
  • Thank you for that great question . For curiosity what might be the situation that makes you send some data while don't want the receiver to save it for "security reasons" . you sent them already!
  • @Accountant: in his scenario, the user had logged out. Who can guarantee that the next human user on that User-Agent will be the person who just logged out?
  • This does not appear to be complete. I tried this solution on IE 8 and found that the browser will load a cached version when you hit the back button.
  • Likely your testing methodology was wrong. Maybe the page was already in the cache? Maybe the headers were incorrect/overriden? Maybe you were looking at the wrong request? Etc..
  • Actually, I confirm that this approach is incomplete and causes issues with IE8, or at least in some circumstances. Specifically, when using IE8 to fetch a resource over SSL, IE8 will refuse to fetch the resource a second time (either at all, or after a first try, depending on headers used). See EricLaw's blog, for instance.
  • I'd like to add that this is essentially what Bank of America does. If you look at their response headers and translate that into aspx, they're doing: Response.AppendHeader("Cache-Control", "no-cache, no-store, must-revalidate"); Response.AppendHeader("Expires", "Thu, 01 Dec 1994 16:00:00 GMT"); I figure, if it's good enough for them, it's good enough for me.
  • @John: That expires header is exactly the example value in HTTP 1.0 specification. It works, but it's somewhat ridiculous to take exactly that timestamp.
  • will this have any side-effect on the performance of the website in terms of loading time ? how no-store , no-cache , must-revalidate affect performance ?
  • @RamanGhai Disabling cache generally hurts performance (and all 3 options you've mentioned disable caching). It may make CDNs and ISP proxies (e.g. commonly used by mobile operators) ineffective. It doesn't hurt first load by a new user (aside from the proxy issue), but then subsequent navigation may be a lot slower.
  • @porneL you state that we must send Cache-Control: must-revalidate. Why not send Cache-Control: no-cache since no-cache already implies must-revalidate? w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1