- From: Koen Holtman <koen@win.tue.nl>
- Date: Wed, 22 May 1996 23:32:03 +0200 (MET DST)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, mogul@pa.dec.com
Jeffrey Mogul: > [Koen Holtman:] > > I dare to predict that most 1.1 caches will in many cases use not use > the correction > > corrected_received_age = max(now - date_value, age_value) > > but will use > > corrected_received_age = age_value > > instead because the max( ) correction would often, because of clock > skew, needlessly decrease the freshness lifetime left without there > being any need for this from a general correctness standpoint. > >"Needless" is a slippery concept here. Decreasing the freshness >lifetime can never turn a semantically transparent response into >a non-transparent one, but failing to decrease the freshness lifetime >can do so. If one views the server's specified expiration time >as an upper bound on the allowable freshness (rather than a lower >bound, which makes little sense) then the protocol design has to >be conservative here. My argument is that one can do better than corrected_received_age = max(now - date_value, age_value) so the spec should not _require_ this particular correction, as it does now. > There are techniques that work much more reliably and efficiently. > For example, the proxy could do a single HEAD request directly to the [....] >I'm reluctant to encourage this in the specification, Me too. You are correct that the spec should not discuss such things. What I suggest is that some words are put in the spec that would allow cache authors to implement something better than corrected_received_age = max(now - date_value, age_value) without this making the cache non-conforming. For example, below the 16.2.4 text apparent_age = max(0, response_time - date_value); corrected_received_age = max(apparent_age, age_value); response_delay = response_time - request_time; corrected_initial_age = corrected_received_age + response_delay; resident_time = now - response_time; current_age = corrected_initial_age + resident_time; When a cache sends a response, it must add to the corrected_initial_age the amount of time that the response was resident locally. It must then transmit this total age, using the Age header, to the next recipient cache. the following text could be added: If detailed information about clock skew is available, a cache MAY calculate apparent_age using a different formulae than the one above. However, use of a different formulae MUST NOT increase the probability that clock skew and intermediate HTTP/1.0 caches cause the freshness requirements of the origin server to be violated. >-Jeff Koen.
Received on Wednesday, 22 May 1996 14:38:57 UTC