Expires: meaning

What does Expires: really mean?

In the current protocol, we can express several concepts (pending the resolution of certain encoding issues):

  1. This response is "expired at birth"; you MUST NOT return it from a cached copy. (i.e., Expires: yesterday)
  2. This response never expires; you can always return it from a cached copy. (i.e., Expires: never)
  3. This response expires at a specific finite time in the future. (e.g., Expires: 1 January 1997)
The issue arises from the interpretation of (3): if the origin server says "Expires: 1 January 1997" does this mean "you are absolutely not allowed to return this response from your cache after 1 January 1997 without first validating it", or does it mean "sometime around 1 January 1997 it would be a good idea for you to consider validating this response with me"? People came up with scenarios where either interpretation could be useful, which lead to the proposal that we ought to have an explicit encoding in the protocol for which is meant.

My understanding of the consensus was that Expires: with a specific date will continue to mean "absolutely expires on that date", and that we may (or may not) introduce a new header (or Cache-control directive) that allows the origin server to give a more probabilistic interpretation. In the most elaborate proposal, the origin server could transmit an arbitrary probability distribution, but I think we agreed that something involving a mean and perhaps a maximum cutoff seemed more reasonable.

ACTION ITEM: Shel Kaphan was going to think about this some more, and to write something about it.

We discussed the problem that most servers do not send Expires: headers today, and in particular that there is a counter-incentive because some browsers do the wrong thing if the server sends Expires:. According to Shel,

The problem is that there is an unpleasant interaction with history buffers in some browsers. If you send Expires: now in a document, hoping that no further *new requests* for that document will result in it being delivered from a cache, some (many? most?) browsers will also interpret that to mean that if you revisit this document by using a history navigation command such as the BACK button, that the document must either be reloaded or the browser must give some kind of warning message such as "DATA MISSING". Both are bad, for different reasons. The general reason this is a problem is that it can be confusing and distracting to users.
Presumably, this can be solved in a pure-HTTP/1.1 environment by strict compliance with our recommendations about history buffers (see above), but we may continue to have trouble with certain older browsers.

We would like to see servers using explicit Expires: as much as possible, because we believe that this could increase the cache lifetimes for many resources (e.g., immutable ones) and could reduce the necessity for cache administrators to guess the proper heuristic tradeoffs.

DEFERRED ITEM: should Expires: be mandatory?

DEFERRED ITEM: When the Expires: header is not sent, should the rules determining what assumptions a cache can make about the expiration date depend on whether the origin server is HTTP/1.0 or HTTP/1.1?

http working group issues