- 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