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.
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:
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.
To complete BalusC -> ANSWER If you are using perl you can use CGI to add HTTP headers.
Using Perl:
Using apache httpd.conf
Note: When I tried to use the html META, browsers ignored them and cached the page.
In addition to the headers consider serving your page via https. Many browsers will not cache https by default.
After a bit of research we came up with the following list of headers that seemed to cover most browsers:
In ASP.NET we added these using the following snippet:
Found from: http://forums.asp.net/t/1013531.aspx
in my case i fix the problem in chrome with this
where i need to clear the content of a previus form data when the users click button back for security reasons
Introduction
The correct minimum set of headers that works across all mentioned clients (and proxies):
The
Cache-Control
is per the HTTP 1.1 spec for clients and proxies (and implicitly required by some clients next toExpires
). ThePragma
is per the HTTP 1.0 spec for prehistoric clients. TheExpires
is per the HTTP 1.0 and 1.1 specs for clients and proxies. In HTTP 1.1, theCache-Control
takes precedence overExpires
, 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 omitCache-Control: no-cache
.If you don't care about IE6 nor HTTP 1.0 clients (HTTP 1.1 was introduced 1997), then you could omit
Pragma
.If you don't care about HTTP 1.0 proxies either, then you could omit
Expires
.On the other hand, if the server auto-includes a valid
Date
header, then you could theoretically omitCache-Control
too and rely onExpires
only.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 asmax-age
are irrelevant if the abovementionedCache-Control
parameters are specified. TheLast-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:
Using Java Servlet, or Node.js:
Using ASP.NET-MVC
Using ASP.NET Web API:
Using ASP.NET:
Using ASP:
Using Ruby on Rails, or Python/Flask:
Using Python/Django:
Using Python/Pyramid:
Using Go:
Using Apache
.htaccess
file:Using HTML4:
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 afile://
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 thehttp-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.