HTTP Expires header values “0” and “-1”

The problem is in how invalid Expires header processed by Internet Explorer (especially older versions).
IE uses Trident layout engine and WinINET API to process HTTP requests. As you may know Expires could be specified in HTTP header

Expires: 0

or in meta tag

<meta http-equiv="Expires" content="0">

In second case, Expires became part of the response content (not header content), so it will be processed by Trident and then propagated to WinINET:

If WinINET downloads a response with an invalid Expires header (e.g.
one that doesn’t contain a valid HTTPDATE value) and no other caching
directives, it will mark the document as having expired one hour ago.
Trident, however, has no such logic. If you specify an invalid time,
Trident grabs the current timestamp and uses that as the expiration.
Trident will also use the current timestamp if it encounters the
Pragma: no-cache directive. If the user tries to re-navigate to the
current document during same exact second that the HTTP/404 was
processed, the incorrectly-updated expiration of the existing cache
entry will result in it being treated as fresh for that request. If
the user hit the Refresh button or F5, the cache would be bypassed and
the 404 page would be shown.

In other words Expires: 0 not always leads to immediate resource expiration, therefore should be avoided and Expires: [some valid date in the past] should be used instead.

Leave a Comment