HTTP Expires header values "0" and "-1"

Question

What is the difference between Expires: 0 and Expires: -1 in the HTTP response header? RFC 2616 defines invalid date formats, especially including the value "0" as already expired. However, some servers (e.g. www.google.de) reply with Expires: -1.

Is there an advantage over using -1 over 0 or is this even required for some broken HTTP clients?

Answer 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.