Expiration and the Expires Header
It is highly recommended that all Web servers use a scheme for the expiration of all Web pages. It is bad practice for a Web server not to supply expiration information via the HTTP Expires response header for every resource returned to requesting clients. Most browsers and intermediate proxies today respect this expiration information and use it to increase the efficiency of communications over the network.
The Expires header should always be used to specify the most reasonable time when a particular file on the server needs to be updated by the client. When pages are updated regularly, the next period for update is the most efficient response. Take, for example, a daily news page on the Internet that is updated every day at 5 A.M. The Web server for this news page should return an Expires header with a value for 5 A.M. the next day. When this is done, the browser does not need to contact the Web server again until the page has actually changed.
Pages that are not expected to change should be marked with an expiration date of approximately one year.
In many cases, Web servers have one or more volatile pages on a server that contain information, which is subject to change immediately. These pages should be so marked by the server with a value of "-1" for the Expires header. On future requests by the user, Internet Explorer usually contacts the Web server for updates to that page via a conditional If-Modified-Since request. However, the page remains in the disk cache ("Temporary Internet Files") and is used in appropriate situations without contacting the remote Web server, such as when the BACK and FORWARD buttons are used to access the navigation history or when the browser is in offline mode.
The Cache-Control Header
Certain pages, however, are so volatile or sensitive that they require no disk caching. To this end, Internet Explorer supports the HTTP 1.1 Cache-Control header, which prevents all caching of a particular Web resource when the no-cache value is specified by an HTTP 1.1 server.
Because pages that are kept out of the cache are not accessible until the browser can re-contact the Web server, servers should use the Cache-Control header sparingly. In most cases, the use of "Expires: -1" is preferred.
The Pragma: No-Cache Header
Unfortunately, legacy HTTP 1.0 servers cannot use the Cache-Control header. 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.
Note, however, that the Pragma: no-cache header was not intended for this. According to the HTTP 1.0 and 1.1 specifications, this header is defined in the context of a request only, not a response, and is actually intended for proxy servers that may prevent certain important requests from reaching the destination Web server. For future applications, the Cache-Control header is the proper means for controlling caching.
HTTP-EQUIV META Tags
HTML pages allow for a special HTTP-EQUIV form of the META tag that specifies particular HTTP headers from within the HTML document. Here is a short example HTML page that uses both Pragma: no-cache and Expires: -1:
<HTML><HEAD><META HTTP-EQUIV="Pragma" CONTENT="no-cache"><META HTTP-EQUIV="Expires" CONTENT="-1"></HEAD><BODY></BODY></HTML>
Pragma: no-cache prevents caching only when used over a secure connection. A Pragma: no-cache META tag is treated identically to Expires: -1 if used in a non-secure page. The page will be cached but marked as immediately expired.
Cache-Control META HTTP-EQUIV tags are ignored and have no effect in Internet Explorer versions 4 or 5. To use Cache-Control this header must be specified using HTTP headers as described in the Cache-Control section above.
Note that the use of standard HTTP headers are much preferred over META tags. META tags typically must appear at the top of the HTML HEAD section. And there is at least one known problem with the Pragma HTTP-EQUIV META tag. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
"Pragma: No-cache" tag may not prevent page from being cached
Server Options for Caching
When the Cache-Control header needs to be used on non-ASP pages, it may be necessary to use options in the server configuration to add this header automatically. Refer to your server documentation for the process of adding HTTP headers to server responses for a particular directory. For example, in IIS 4, follow these steps:
- Invoke the Internet Services Manager.
- Using the computer and services tree, open the Default Web Server (or web server in question) and find the directory containing the content that needs the Cache-Control header.
- Bring up the Properties dialog for that directory.
- Choose the HTTP Headers tab.
- Click the Add button in the Custom HTTP Headers group and add "Cache-Control" for the header name and "no-cache" for the header value.
Remember that it is not a good idea to use this header globally across the entire Web server. Restrict its use purely to content that absolutely must not be cached on the client.Problem ChecklistIf you've applied the techniques in this article and you are still having problems with caching and Internet Explorer, please review this handy checklist step by step before contacting Microsoft for technical support assistance:
- Are you using the Cache-Control header with the ASP "Response.CacheControl" property or through a returned HTTP header? This is the only way to truly prevent caching in Internet Explorer.
- Are you using Internet Explorer 4.01 Service Pack 2 or higher? There is no way to completely prevent caching in earlier versions of the browser.
- Have you double-checked that your web server has HTTP 1.1 turned on and is returning HTTP 1.1 responses to Internet Explorer? Cache-Control headers are invalid in HTTP 1.0 responses.
- If you're using CGI/ISAPI/Servlets on the server side, are you following the HTTP 1.1 specification exactly, particularly in respect to CRLF termination of HTTP headers? In the interest of performance, Internet Explorer is typically unforgiving of responses that violate the HTTP 1.1 specification. This usually results in ignored headers or reports of unexpected server errors.
- Are the HTTP headers spelled correctly?