- From: Daniel W. Connolly <connolly@beach.w3.org>
- Date: Wed, 03 Jan 1996 01:14:49 -0500
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-caching@pa.dec.com (http-caching mailing list)
In message <9601030037.AA29004@acetes.pa.dec.com>, Jeffrey Mogul writes: > > Date parsing: Just Say No! > >Actually, I spent part of the weekend mulling this over, and I >think the use of absolute expiration dates (as opposed to "seconds >remaining") is a mistake. (1) I disagree, and (2) that's not what I was talking about. I was talking about the zillions of date formats: Tue, 02 Jan 1996 ... as opposed to nice sortable ISO format: 19960102163724Z. But you raise an interesting point. >Consider the problem of dealing with clock skew. I'd rather not. I'd rather (1) have as few mechanisms as possible depend on global synchronization (e.g. compare IMS dates for equality _only_, and never order) (2) in the few cases where we need global synchronization, just count on everybody having good clocks, and live with the resulting level of reliability. >Think about how you would handle this case: > > The origin server has a correct clock. On Monday, > it generates a response which is cachable until Friday. ew... I hate the term "cachable." I much prefer "fresh." But anyway... > The first cache has a clock that is a day slow If their clock is off by a day, then stale HTTP pages are the least of their worries. They're Seriously Broken. Trying to deal with their brokennes is just going to complicate things to the point where the net reliability will suffer, I predict. >One have the caches rewrite the expiration dates, or include >more mechanisms for clock-deskewing. But it seems much simpler >and safer to express expiration as a number of seconds remaining, >which works as long as the inaccuracy in clock rates is reasonably >small. Exactly what do you mean by "works"? How exactly does it "work"? With global clocks, the test for fressness is: Given t1, the fresh-until date given in the Cache: header of the response, and t2, the local current time, is t2 < t1? I'd like to use a simple lexicographic test on ISO format dates, though I suppose integral seconds will do. ISO dates are convenient if, for example, you only want to be precise to the month: Cache: fresh-until=199605 What exactly is the test for freshness using deltas, and what are the input parameters? Does the number of parameters increase with the number of parties involved in an HTTP transaction? I'm playing devil's advocate (read: I'm too lazy to think it through myself.) Consider a client, an origin server, and three caching proxies in between. The server writes: Cache: max-age=3600 The first caching proxy sees that at 1pm, so it thinks the response is fresh until 2pm (note the book-keeping above and beyond the headers themselves). The second caching proxy requests this resource at 1:15. Does the first proxy re-write the Cache: header? Yuk. What about latency? Dan
Received on Wednesday, 3 January 1996 06:26:48 UTC