- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 20 Feb 96 14:00:58 PST
- To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
- Cc: http-caching@pa.dec.com
That is not surprising. What you are remembering is the discussion
over what the semantics of "Expires" should be. My opinion (and that
of several other server authors) is that it should return to how it
was originally specified, a.k.a.
Expires in HTTP means the same thing as the Expires on the top
on an Internet-Draft.
However, you should note that this does not have any actual effect
on the protocol, since both result in the same behavior by caches.
The difference is only in how the server provides the functionality
to the individual content providers, and when they should use it.
In any case, the existence of current practice will make them
redundant for some time.
Which is why it seems perfectly reasonable to make it clear in the
HTTP/1.1 spec that the proper behavior for a cache, once a cache entry
has reached its expiration date, is NOT to simply discard it, but
rather to revalidate it with the origin server before returning it in a
response.
The analogy to Internet-drafts is a false one, since there is no
useful mechanism to "refresh" an I-D, in large part because the
IETF's goal here is to force forward progress in the standards
process. In HTTP, our goal is improve the likelihood that a
request can be answered by a cache without a full retrieval, and
this argues in favor of keeping entries past their expiration date,
AS LONG AS they are not actually returned without being revalidated.
Note that there are two orthogonal issues to consider:
(1) Replacement policy (how a cache decides what to
store when it doesn't have room for everything)
(2) pseudo-security (analogous to "my bank-server
customer doesn't want stuff stored anywhere).
but these ought to be handled explicitly, not by making caching
less effective.
-Jeff
Received on Tuesday, 20 February 1996 22:30:12 UTC