W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Re: age calculations

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
Message-Id: <9602201451.aa12248@paris.ics.uci.edu>
>     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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC