- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Tue, 20 Feb 1996 14:50:59 -0800
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-caching@pa.dec.com
> In order to know if a cached entry is fresh, a cache needs to > know if its age exceeds its freshness lifetime. The latter can be > reliably calculated as Expires: - Date:, or from Cache-control: > max-age=NNN (which takes priority). > > An entry's age can be calculated in two independent ways: > now - Date: > if the clocks are reasonably well synchronized > Sum of "time resident in cache" for all caches involved, > using the Age: header > if all of the caches support Age: > > Given that we have two independent ways to compute the age, > we can combine these as > age = max(now - Date:, Age:) > and as long as we have either synchronized clocks or all-HTTP/1.1 > paths, one gets a reliable (conservative) result. The purpose > of the Age: header is to pass this value along to the next > recipient cache. > > Note that this correction can be applied at each HTTP/1.1 cache > along the path, so that if there is an HTTP/1.0 cache in the path, > the correct age is computed as long as the receiving cache's clock > is in sync. We don't need end-to-end clock synchronization > (although it is good to have), and there is no explicit clock > synchronization step. That seems to be correct, but I don't find it very clear. I think that this particular part of the protocol is procedural in nature, and thus would lend itself better to a procedural description. Of course, you may have done that as well, in which case you can ignore this message. ......Roy
Received on Tuesday, 20 February 1996 23:10:32 UTC