- From: Shel Kaphan <sjk@amazon.com>
- Date: Wed, 3 Jan 1996 15:24:30 -0800
- To: "Daniel W. Connolly" <connolly@beach.w3.org>
- Cc: Jeffrey Mogul <mogul@pa.dec.com>, http-caching@pa.dec.com (http-caching mailing list)
As far as I can tell, it's possible to get the same effect using relative times as absolute times, though it's certainly far simpler to use the relative times. It's interesting to note that there is a now-deprecated format for the Expires header that consists of an integer -- the number of seconds till expiration. When using absolute times, each intermediate needs to adjust the expiration time to its own clock, and use the current time when generating Date headers. This is fairly clearly prohibited by the current 1.1 spec, but earlier 1.0 specs were not so clear what date the Date header corresponded to. (the origin server's date of sending, or the intermediate server's). So, if we stick with absolute dates, we need to adjust things so that each proxy can do its own crude deskewing using the received Date header vs. the local clock (which is actually pretty easy if you don't get carried away). We also need to define that Date means "time sent" according to the server that generates it, so the deskewing can happen at all (as Jeff points out). If we switch to a relative time for Expires, this is all much simpler to manage. The only reason I can think of not to is to try to make backwards compatibility with 1.0 servers work better. Whether this is relevant at all depends on what the common practice is for Date headers in 1.0. Are they the passed through as stamped by the origin-server? Or are they usually generated on the fly by each intermediate? --Shel
Received on Wednesday, 3 January 1996 23:42:43 UTC