- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 20 Feb 96 13:49:28 PST
- To: http-caching@pa.dec.com
After some private exchanges with Paul Leach, who was confused by some of the stuff in my draft regarding Age:, I tried to write down a concise description of how Age: Expires: Date: Cache-control: max-age=NNN all fit together. Paul didn't seem to object (although this may simply be because he didn't get my mail, the Microsoft mail gateway is very lossy) so I'm hoping that this meets with general consenus. 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. -Jeff
Received on Tuesday, 20 February 1996 22:07:32 UTC