Make IE cache the resources but always revalidate

I’ve eventually figured it out. Here is an explanation and a tested solution.

The following site confirms my observation: http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/

It says that IE does not locally store pages with the ‘no-cache’ directive and hence always sends an unconditional request.

There’s also a MS support article – https://support.microsoft.com/help/234067/ – which confirms this:

“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…”

This behavior is not entirely wrong — but it is not what RFC 2616 (sec. 14.9.1) intended. About ‘no-cache’ it says “… a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server.” So the response CAN be cached but MUST revalidate it. The major browsers, except for IE, do cache the response and revalidate it. To prevent storing the request, there’s the ‘no-store’ Cache-Control directive.

In summary, IE treats ‘no-cache’ as ‘no-store’.

And here’s the solution to enable conditional requests for IE and the other browsers in a consistent way:

Don’t use no-cache, but instead set the Expires header to the past (or -1, which has the same effect). IE, as well as the other major browsers, will then send conditional requests. (Note, you should also be aware of the IE Vary header bug, which prevents caching.)

These are the critical header fields:

Last-Modified: Wed, 16 Feb 2011 13:52:26 GMT
Expires: -1
Cache-Control: must-revalidate, private
  • Last-Modified (or ETag) is needed as a validator
  • Expires -1 tells that the resource is stale and must be revalidated
  • Cache-Control must not include no-cache or no-store

Leave a Comment