Re: v11-03 COMMENT: 16.2.4 Age Calculations

	  apparent_age = max(0, now - date_value);
				^^^
	  corrected_received_age = max(apparent_age, age_value);
	  response_delay = now - request_time;
			   ^^^
	  corrected_initial_age = corrected_received_age + response_delay;
	  resident_time = now - response_time;
			  ^^^
	  current_age   = corrected_initial_age + resident_time;
    
    the first two `now' values denote the time of receipt of the response
    by the proxy.  The last `now' denotes the time at which the response
    is served by the proxy from its own cache memory.
    
    A fix is to replace the first two `now's by `response-time'.

You're right.  I had written these formulae with an expectation that
they would be computed "as soon as needed" (i.e., at different
values of 'now'), but since I failed to specify when each computation
is supposed to be done (and, in fact, that's not necessary to
specify), it makes sense to do that change.

      Note that a client can usually tell if a response is firsthand by
      comparing the Date to its local request-time, and hoping that the
      clocks are not badly skewed.
    
    This is misleading, there is a much easier way to know this, though it
    only works if there is a 1.1 cache in the chain:
    
      Note that a client can tell if a response is firsthand by
      checking if it contains an Age header.  Firsthand responses never
      contain an Age header.
    
    By the way, I can't find any clear reference to this important
    function of the Age header anywhere in the draft.  I'll post a
    separate note about this.

There's a logical error here.  While it is indeed true that

	if the response includes Age, then it is not firsthand

it is NOT true that

	if the response does not include Age, then it is firsthand

unless *the first* cache in the chain is an HTTP/1.1 (or higher) cache.

And since HTTP/1.0 caches do not implement the Via header, it's
probably not possible to reliably use the absence of an Age header
to decide if a response is definitely firsthand.

Of course, clock comparisons are also potentially flakey.  So I
guess the best we can do here is to say that a client can detect
non-firsthand responses in some cases, but not all cases, by looking
for an Age header or a large difference between Date and request_time.

    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.

    There are techniques that work much more reliably and efficiently.
    For example, the proxy could do a single HEAD request directly to the
    origin server, and use the Date header in the response to calculate a
    pessimistic value for the time difference between the origin server
    clock and its own clock.  Using this difference, the cache could make
    very good age corrections for subsequent responses from a 1.0 cache
    for resources on that origin server.

I'm reluctant to encourage this in the specification, both because
it gets us into the business of designing a clock synchronization
protocol (which is much harder than it might seem), and because
it encourages the use of extra messages (which is contrary to the
basic purpose of caching).

-Jeff

Received on Monday, 20 May 1996 17:15:23 UTC