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

age calculations

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 20 Feb 96 13:49:28 PST
Message-Id: <9602202149.AA08023@acetes.pa.dec.com>
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
	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.

Received on Tuesday, 20 February 1996 22:07:32 UTC

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