Making sure a web page is not cached, across all browsers

265 down vote favorite 228

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 cached, ever, by the web browser. This must work for at least the following browsers: Internet Explorer versions 6-8 Firefox versions 1.5 - 3.0 Safari version 3 Opera 9 Our requirement came from a security test. After logging out from our website you could press the back button and view cached pages. http caching https http-headers share|improve this question edited Jun 19 '13 at 20:21 informatik01 3,56331532 asked Sep 8 '08 at 12:08 Edward Wilde 5,05953448

add comment

19 Answers

active oldest votes

up vote 443 down vote accepted

The correct minimum set of headers that works across all mentioned browsers: Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0 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: response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1. response.setHeader("Pragma", "no-cache"); // HTTP 1.0. response.setDateHeader("Expires", 0); // Proxies. 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: 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: response.headers["Cache-Control"] = "no-cache, no-store, must-revalidate" // HTTP 1.1. response.headers["Pragma"] = "no-cache" // HTTP 1.0. response.headers["Expires"] = "0" // Proxies. Using Google 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 HTML: <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" /> The Cache-Control is per the HTTP 1.1 spec for clients (and implicitly required by some browsers next to Expires), the Pragma is per the HTTP 1.0 spec for clients and proxies and Expires is per the HTTP 1.1 spec for clients and proxies. Other Cache-Control parameters are irrelevant if the abovementioned three are specified. The Last-Modified header as included in most other answers here is only intersting if you actually want to cache the request, so you don't need to specify it at all. Note that when the page is served over HTTP and a header is present in both the HTTP response headers and the HTML meta tags, then the one specified in the response header will get precedence over the HTML meta tag. The HTML meta tag will only be used when the page is viewed from local disk file system. 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. To verify the one and other, you can see/debug them using Firebug Net panel. share|improve this answer edited Nov 19 '13 at 11:11 community wiki 14 revs, 6 users 73% BalusC

6 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. – Mike Ottum Jan 15 '10 at 2:26 6 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.. – BalusC Jan 15 '10 at 3:38 5 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. – haylem Oct 2 '12 at 22:46 1 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 Feb 12 '13 at 16:14 1 @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. – BalusC Feb 12 '13 at 16:18 show 27 more comments

No problem. We won't show you that ad again. Why didn't you like it?

• Uninteresting
• Misleading
• Offensive
• Repetitive

Oops! I didn't mean to do this.

up vote 39 down vote

(hey, everyone: please don't just mindlessly copy&paste all headers you can find) First of all, what you're trying to achieve should not be possible according to HTTP spec, because Back button history is not a cache: History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved. Back is supposed to go back in time (to the time when user was logged in), it does not navigate forward to previously opened URL. However, it is possible in practice, exactly due to "back after logout" panic. It works reliably in very specific circumstances: Page must be delivered over HTTPS. If you're not using HTTPS, then don't bother — it won't be reliable, and your page already has a bigger security problem. You must send Cache-Control: must-revalidate You never need any of: <meta> with cache headers — it doesn't work at all. Totally useless. post-check/pre-check — it's IE-only directive that only applies to cachable resources. Sending same header twice or in dozen parts. Some of the worst PHP snippets out there actually replace previous headers, resulting in only last one being sent. If you want, you could add: no-store if you're sending security-sensitive information. no-cache or max-age=0, which will make resource (URL) "stale" and require browsers to check with the server if there's a newer version (must-revalidate already implies this even stronger). Expires with date in the past for HTTP/1.0 clients (although real HTTP/1.0-only clients are probably non-existent these days). share|improve this answer edited May 22 '13 at 16:10 answered Mar 30 '11 at 23:08 porneL 38.2k1386131

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 ? – Raman Ghai May 22 '13 at 14:43 @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 May 22 '13 at 16:01 @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 – Pacerier Aug 25 '13 at 19:15 1 @Pacerier the relationship of no-cache with must-revalidate is true for cache, but back history is not a cache. Browsers special-case explicit must-revalidate to control history behavior. – porneL Aug 27 '13 at 17:29 @porneL, Hmm is there a supporting RFC that states that's the desired behavior? – Pacerier Aug 29 '13 at 3:35 show 1 more comment

up vote 13 down vote

As porneL 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: Cache-Control: no-store Cache-Control: no-cache (https only) Pragma: no-cache (https only) 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: Cache-Control: no-store <body onunload=""> in html Cache-Control: no-store (https only) In IE8 (v8.0.6001.18702IC) any one of these will work: Cache-Control: must-revalidate, max-age=0 Cache-Control: no-cache Cache-Control: no-store Cache-Control: must-revalidate Expires: 0 Cache-Control: must-revalidate Expires: Sat, 12 Oct 1991 05:00:00 GMT Pragma: no-cache (https only) 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: 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 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 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 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 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 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 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 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 Cache-Control: no-store Fail: Safari 5.1.7, Opera 12.15 Success: Chrome 28, FireFox 23, IE8 Cache-Control: no-store <body onunload=""> Fail: Opera 12.15 Success: Chrome 28, FireFox 23, IE8, Safari 5.1.7 Cache-Control: no-cache Fail: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15 Success: IE8 Vary: * Fail: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15 Success: none Pragma: no-cache Fail: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15 Success: none 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 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 Cache-Control: must-revalidate, max-age=0 Fail: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15 Success: IE8 Cache-Control: must-revalidate Expires: 0 Fail: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15 Success: IE8 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 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: 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 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 Vary: * Fail: Chrome 28, Safari 5.1.7, Opera 12.15 Success: FireFox 23, IE8 Pragma: no-cache Fail: Chrome 28, Safari 5.1.7, Opera 12.15 Success: FireFox 23, IE8 Cache-Control: no-cache Fail: Chrome 28, Safari 5.1.7, Opera 12.15 Success: FireFox 23, IE8 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 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 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 Cache-Control: must-revalidate Fail: Chrome 28, FireFox 23, IE8, Safari 5.1.7 Success: Opera 12.15 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 Cache-Control: must-revalidate, max-age=0 Fail: Chrome 28, FireFox 23, Safari 5.1.7 Success: IE8, Opera 12.15 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 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 Cache-Control: no-store Fail: Opera 12.15 Success: Chrome 28, FireFox 23, IE8, Safari 5.1.7 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 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 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 Cache-Control: must-revalidate Expires: 0 Fail: Chrome 28, FireFox 23, Safari 5.1.7, Success: IE8, Opera 12.15 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 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 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 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 Cache-Control: no-store, must-revalidate Fail: none Success: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15 share|improve this answer answered Aug 29 '13 at 16:50 Pacerier 13.5k1362142

add comment

up vote 11 down vote

After a bit of research we came up with the following list of headers that seemed to cover most browsers: Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-cache, private, must-revalidate, max-stale=0, post-check=0, pre-check=0 no-store Pragma: no-cache In ASP.NET we added these using the following snippet: 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 Found from: http://forums.asp.net/t/1013531.aspx share|improve this answer edited Sep 8 '08 at 13:55 answered Sep 8 '08 at 12:11 Edward Wilde 5,05953448

7 Answered your own question in three minutes. Congrats! That must be a stackoverflow.com record. – Stu Thompson Sep 8 '08 at 12:20 20 @bart: Even more troublesome yet is that the 26th of July in 1997 was a Saturday, not a Monday... – Cory Feb 13 '12 at 19:51 3 Cache-Control: no-cache and Cache-Control: private clash - you should never get both together: the former tells browsers and proxies not to cache at all, the latter tells proxies not to cache but lets browsers hold their own private copy. I'm not sure which setting the browser will follow, but it's unlikely to be consistent between browsers and versions. – Keith Oct 29 '12 at 11:48 1 @Edward, tested and doesn't work on Safari 5.1.7 and Opera – Pacerier Aug 29 '13 at 4:45 add comment

up vote 11 down vote

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. share|improve this answer edited Mar 17 '10 at 20:19 answered Jan 14 '10 at 23:35 Chris Vasselli 2,9851917

1 This works for IE8's back button!! AFter trying everything in every other suggestion, adding the "Vary: *" header is apparently the only thing that can force IE8 to reload the page when the user presses the back button. And this does work on HTTP/1.1 servers. – CoreDumpError Mar 22 '13 at 21:38 Combined with the headers suggested by BarlusC, plus a JS snippet that calls window.location.reload() when the onPageShow event triggers with the "persisted" attribute (needed for Safari), every browser I've tested successfully forces a reload from the server when the user uses the Back button. – CoreDumpError Mar 22 '13 at 21:46 @CoreDumpError, oh you should not assume JavaScript is enabled. – Pacerier Aug 25 '13 at 19:55 @Chris, just tested. It doesn't work on Safari 5.1.7 and Opera... – Pacerier Aug 29 '13 at 4:32 @Pacerier At the time I wrote the answer in 2010, this worked on what were then the latest versions of both Safari and Opera, with our server identifying itself as an HTTP 1.0 server. Unfortunately, I don't have any way to easily test this anymore, so I can't say anything definitive about the latest versions of these browsers. – Chris Vasselli Aug 31 '13 at 0:45 show 2 more comments

up vote 6 down vote

DISCLAIMER: I strongly suggest reading @BalusC's answer. After reading the following caching tutorial: http://www.mnot.net/cache_docs/ (I recommend you read it, too), I believe it to be correct. However, for historical reasons (and because I have tested it myself), I will include my original answer below: I tried the 'accepted' answer for PHP, which did not work for me. Then I did a little research, found a slight variant, tested it, and it worked. Here it is: 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'); That should work. The problem was that when setting the same part of the header twice, if the false is not sent as the second argument to the header function, header function will simply overwrite the previous header() call. So, when setting the Cache-Control, for example if one does not want to put all the arguments in one header() function call, he must do something like this: header('Cache-Control: this'); header('Cache-Control: and, this', false); See more complete documentation here. share|improve this answer edited Jan 25 '10 at 16:15 answered Sep 18 '08 at 10:36 Steven Oxley 2,53211741

10 This is full of myths. pre-check and post-check are IE-only, relevant only for cached responses, and 0 value is a no-op. max-stale is proxy request header, not server response header. Expires accepts only single value. More than one will cause this header to be ignored. – porneL Oct 19 '08 at 18:19 1 @porneL, will you be submitting a competing answer that deals with these myths correctly? – Oddthinking Nov 28 '08 at 1:56 4 Holy headers batman! – Chad Grant May 1 '09 at 8:39 @Oddthinking, looks like stackoverflow.com/questions/49547/… is a competing answer. – Mike Ottum Jan 14 '10 at 23:55 @Steven, just tested. It doesn't work on Safari 5.1.7 and Opera... – Pacerier Aug 29 '13 at 4:34 show 1 more comment

up vote 6 down vote	There's a bug in IE6 Content with "Content-Encoding: gzip" is always cached even if you use "Cache-Control: no-cache". http://support.microsoft.com/kb/321722 You can disable gzip compression for IE6 users (check the user agent for "MSIE 6") share|improve this answer edited Jul 1 '13 at 10:20 answered Jun 13 '13 at 15:23 Edson Medina 2,290923
	add comment

up vote 5 down vote

These directives does not mitigate any security risk. They are really intended to force UA's to refresh volatile information, not keep UA's from being retaining information. See this similar question. At the very least, there is no guarantee that any routers, proxies, etc. will not ignore the caching directives as well. On a more positive note, policies regarding physical access to computers, software installation, and the like will put you miles ahead of most firms in terms of security. If the consumers of this information are members of the public, the only thing you can really do is help them understand that once the information hits their machine, that machine is their responsibility, not yours. share|improve this answer edited Sep 19 '08 at 3:23 answered Sep 19 '08 at 3:08 Dustman 1,61041934

add comment

up vote 5 down vote

The PHP documentation for the header function has a rather complete example (contributed by a third party): 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); share|improve this answer edited Apr 13 '12 at 18:27 Community♦ 1 answered Sep 8 '08 at 12:19 Cd-MaN 7,43132139

11 This is obviously wrong. Second calls to header() for Expires, Cache-control and Pragma completely overwrite previously set values. – porneL Oct 19 '08 at 18:22 @porneL: No the do not overwrite previously set values as he pass false as a 2nd parameter, telling to not override previous values. – Julien Palard Feb 14 '13 at 10:52 @JulienPalard the answer has been edited after I made my comment. It still doesn't make much sense. – porneL Feb 15 '13 at 10:31 add comment

up vote 4 down vote

The use of the pragma header in the response is a wives tale. RFC2616 only defines it as a request header http://www.mnot.net/cache_docs/#PRAGMA share|improve this answer answered Sep 17 '08 at 14:18 Dave Cheney 1,934815

2 This is a good example of why you need to go beyond the specs. If the specs were always crystal clear, there wouldn't be much point for sites like StackOverflow. From Microsoft For purposes of backward compatibility with HTTP 1.0 servers, Internet Explorer supports a special usage of the HTTP Pragma: no-cache header. If the client communicates with the server over a secure connection (https://) and the server returns a Pragma: no-cache header with the response, Internet Explorer does not cache the response. – michaelok Jul 10 '12 at 18:42 add comment

up vote 4 down vote	If you're facing download problems with IE6-IE8 over SSL and cache:no-cache header (and similar values) with MS Office files you can use cache:private,no-store header and return file on POST request. It works. share|improve this answer answered Sep 21 '12 at 9:02 Albert 411
	add comment

up vote 4 down vote	in my case i fix the problem in chrome with this <form id="form1" runat="server" autocomplete="off"> where i need to clear the content of a previus form data when the users click button back for security reasons share|improve this answer answered Jun 19 '13 at 17:28 user2321638 412
	My mozilla 19.x browser issue also got resolved by the code snippet. autocomplete="off". Thank you. – Satya Nov 22 '13 at 7:33 add comment

up vote 3 down vote	The RFC for HTTP 1.1 says the proper method is to add an HTTP Header for: Cache-Control: no-cache Older browsers may ignore this if they are not properly compliant to HTTP 1.1. For those you can try the header: Pragma: no-cache This is also supposed to work for HTTP 1.1 browsers. share|improve this answer answered Sep 8 '08 at 12:14 Chris Dail 10.3k63046
	The spec indicates that the response must not be reused without revalidation. It is the Cache-Control:no-store which is the official method to indicate that the response not even be stored in a cache in the first place. – AnthonyWJones Sep 19 '08 at 18:14 add comment

up vote 3 down vote	Setting the modified http header to some date in 1995 usually does the trick. Here's an example: Expires: Wed, 15 Nov 1995 04:58:08 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Cache-Control: no-cache, must-revalidate share|improve this answer edited Nov 19 '08 at 8:23 answered Sep 8 '08 at 12:10 Anders Sandvig 7,634104364
	2 voted down cos 1995 is not in 1950 :-) – Simon_Weaver Nov 19 '08 at 1:33 @Anders, just tested. It doesn't work on Safari 5.1.7 and Opera... – Pacerier Aug 29 '13 at 4:41 add comment

up vote 3 down vote

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></configuration> 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(); }); share|improve this answer edited Nov 21 '13 at 19:05 answered Jun 15 '12 at 2:40 Joseph Connolly 485

add comment

up vote 2 down vote	I've had best and most consistent results across all browsers by setting Pragma: no-cache share|improve this answer answered Sep 17 '08 at 12:32 petr k. 4,62622544
	add comment

up vote 2 down vote	In addition to the headers consider serving your page via https. Many browsers will not cache https by default. share|improve this answer answered Nov 19 '08 at 8:31 Harry 1,67221520
	add comment

up vote 2 down vote

The headers in the answer provided by BalusC does not prevent Safari 5 (and possibly older versions as well) from displaying content from the browser cache when using the browser's back button. A way to prevent this is to add an empty onunload event handler attribute to the body tag: <body onunload=""> This hack apparently breaks the back-forward cache in Safari: Cross-browser onload event and the Back button share|improve this answer answered Apr 23 '11 at 21:24 Tobias 412

Cool, I've tested it and this actually works on Safari (5.1.7) but not Opera. – Pacerier Aug 29 '13 at 4:59 add comment

up vote 2 down vote

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