Re: Still trying to make sense of HTTP caching model

John Franks writes:

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

[ Devil's advocate mode ON ]

1.  If you want behavior like the CERN server, where you can just put
a header in a file that just needs to be prepended, it is clearly
harder to use a relative-time format.  In fact, it can't be done
without some computation based on an absolute time, if you want
something to "expire" at a specific time. Parsing dates is
something all clients have to know how do anyhow. Arithmetic on
time_t's is not exactly rocket science.

2.  It replaces clock skew with a delay computation problem, as Jeff said.
Jeff's algorithm for deskewing the clock is easy. Also, same argument
about parsing dates as above.

 > I think that small T with slow connections is a non-problem.

For present applications, right...

  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.

So it's not only harder at both ends, it's harder in the middle too!

  But at least it doesn't have to parse (multiple?) date
 > formats.

I don't know where you get the idea that you could write an HTTP
client or server that didn't understand how to parse multiple date formats.
There are other headers that send dates too.

[ Devil's advocate mode OFF ]

Received on Thursday, 7 September 1995 14:05:21 UTC