Re: Still trying to make sense of HTTP caching model

  To get
> back to John's statement that "most Expires headers are set by server
> maintainers" ...  I don't know if this is true, but it should not be
> true.  Human server maintainers should set a value using one of the
> four approaches I listed, and, as Paul said, server software should
> compute the Expires: header sent with each response.


According to Jeffrey Mogul:
> 
> Then it's fairly easy to see how to resolve this.  Servers provide
> a way for admins to specify when a document expires.  This may be
> expressed in several different ways:
> 	(1) "The document expires on Dec 11 1995"
> or
> 	(2) "The document expires 10 days after it was created"
> OR
> 	(3) "Don't let anyone cache this after Dec 11 1995"
> or
> 	(4) "Don't let anyone cache this for more than 10 days"
> 
> I think a good server implementation ought to allow all four
> ways to describe expiration; although #1 and #2 are almost
> equivalent, the rest are quite different.  I couldn't think
> of any others, but there probably are some.
> 
> Now, assume we have document X that was created on Dec 1 1995,
> and on Dec 2, a client requests the document.  Here is what
> the server returns for each of the four cases above:
> 	(1) Xyzzy: Dec 11 1995
> 	(2) Xyzzy: Dec 11 1995
> 	(3) Xyzzy: Dec 11 1995
> 	(4) Xyzzy: Dec 12 1995
> 
> And if document X is requested on December 13:
> 	(1) Not found
> 	(2) Not found
> 	(3) Xyzzy: Dec 11 1995
> 	(4) Xyzzy: Dec 23 1995
> 
> Therefore, the Xyzzy mechanism in the HTTP specification is
> completely sufficient to implement all four styles of expiration.
> Note that it would NOT work for the admin to simply attach an
> Xyzzy value to the document, since this would not work for case
> 4, and would not distinguish between cases 1 and 3.  The server
> must compute the Xyzzy value to make this all work.
> 
> So now the remaining question is "should we add an Xyzzy: header to the
> HTTP spec?"  No way!  "Expires:" not only solves the problem already,
> it also is compatible with existing practice, more or less.

It seems to me that this is rather *incompatible* with existing 
practice.  Take the CERN server, for example.  It is widely used and
will continue to be for the foreseeable future.  To add an expiration
date to a document /path/foo the maintainer creates /path/.web/foo.meta
containing the line "Expires: <date>".  It is up to the maintainer
who creates it and it is attached, not computed.  I don't know of any
servers today which compute Expires, as opposed to attaching it.
As Jeff points out this makes the semantics  of Xyzzy impossible for
current servers.

It would be nice if we were starting with a clean slate and current
servers could be ignored, but I don't think that is the case.  Of
course, it would be possible to specify that HTTP/1.1 is a whole new
ball game and Expires in HTTP/1.1 must behave like Xyzzy, i.e. quite
differently from current practice.  But if HTTP/1.1 is starting from
scratch in this regard then I would argue for discarding Expires and
adding "Control-Cache: max-age=T".  No one seems to have disputed my
contention that it is 1) easier to implement at both ends and 2)
eliminates the problem of clock skew.  Also, I seem to recall substantial
discussion about max-age when it was added to the 1.1 proposal.  I
would be reluctant to junk it now.

I think that small T with slow connections is a non-problem.  The
proxy should use the time the header arrives as the base time from which to
measure T.  Of course, the proxy has to re-calculate T, when it sends
the document.  But at least it doesn't have to parse (multiple?) date
formats.


John Franks

Received on Thursday, 7 September 1995 12:58:06 UTC