W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Still trying to make sense of HTTP caching model

From: Shel Kaphan <sjk@amazon.com>
Date: Wed, 6 Sep 1995 07:51:14 -0700
Message-Id: <199509061451.HAA18738@bert.amazon.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

  According to Shel Kaphan:
  > Jeffrey Mogul writes:
  > 	...
  >  >    2.	Cache this object but always validate before using
  >  > 	   (i.e., "Expires: 1 January 1900")
  > I see. This actually gives a reasonable meaning to this construct.
  > This meaning seems better than simply "don't cache this", and works well with
  > GET if-<whatever>.  With plain GET it is equivalent to not caching.
  > 	...

  This usage encodes some very non-intuitive semantics in the Expires:
  heading.  If you want to tell the proxy to cache a document but always
  validate it then create a header or Pragma to do that.  Trying to
  encode this request in an otherwise meaningless variant of an existing
  header is a mistake.  This will inevitably lead to confusion because
  most people already think they know what Expires: means and they
  have a right to think that.

  John Franks

This was my first reaction too.  But here is why I changed my mind:

What happens when a cache holds a document that expires in a "normal"
way?  Before the expiration time, the cache is free to serve the
cached doc.  After the expiration time, the cache is required to issue
(at least) a conditional GET before serving the doc.  Repeating
myself, I think the spec is unclear what is supposed to happen if the
cache can't acquire an unexpired copy of the document then.

With this usage caches never have to do anything special because of
expiration dates when storing documents.  They only have to look when
serving them.  So the cache's behavior is completely uniform for
expiration dates in the past and the future.  One thing I *do* hate
about this is that "expires: <right now>" has problems because of
clock skew, but otherwise that would seem to make more sense
intuitively than "expires: yesterday".  

The point, as usual, is just that this needs to be resolved
unambiguously one way or another.  I'm pushing on it because there are
multiple interpretations floating around.

Received on Wednesday, 6 September 1995 07:58:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC