Re: Dates vs. Deltas [was: An alternative to explicit revocation? ]

Daniel W. Connolly:
>
>Consider a client, an origin server, and three caching proxies
>in between. The server writes:
>
>        Cache: max-age=3600
>
>The first caching proxy sees that at 1pm, so it thinks the response is
>fresh until 2pm (note the book-keeping above and beyond the headers
>themselves). The second caching proxy requests this resource at
>1:15. Does the first proxy re-write the Cache: header? Yuk.

When I thought this through some time ago, I concluded that the
cleanest solution would be for the first caching proxy to add a header

 Cache-control: aged=900

(900 seconds = 15 minutes = 1:15pm - 1pm) to the response when serving
it to the second caching proxy.

A third proxy could in turn get response headers like
  Cache-control: max-age=3600
  Cache-control: aged=900
  Cache-control: aged=100
from the second proxy, so it can only serve the response to its own
clients for 3600-900-100=2600 seconds before a refresh has to be done.

>  What
>about latency?

The time spent by the first proxy doing the transaction with the
origin sever at 1am could also be accounted for in the aged= value it
sends at 1:15pm.

Proxies should only add aged= values to responses served from cache
memory, not to responses directly relayed from the origin server.  If
the proxy is just acting as a relay, the client that initiated the
request can determine the duration of the whole transaction itself.

As for the Dates vs. Deltas issue, I agree with Jeffrey Mogul that
caching should be based on deltas, never on absolute dates.  The date
in an Expires header should be treated as relative to the date in the
Date header of the same message, and a cache should calculate the
difference between these dates to get the lifetime of the response.

Caches are also present in user agents running on PCs with a modem,
and there is no way we can rely on the clocks in these PCs to be in
sync with anything.  Even if the PC system clock is set accurately,
it will usually be in local time, and not every PC OS will offer
conversion to GMT.

>Dan

Koen.

Received on Wednesday, 3 January 1996 22:04:02 UTC