Re: #29: correcting corrected_initial_age

On 09.03.2010 10:22, Mark Nottingham wrote:
> Agreed. Julian, since you did the patch, could you update?
 > ...

OK - it appears we want to do multiple things here:

1) clarify input fields (absence of Age header, "local time"), and

2) change the actual calculation (issue 29).

Thus I've decided to do this in two steps. For 1) I just committed 
changes <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/778> abd 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/778>, with the 
resulting text being:

-- snip --
2.3.2.  Calculating Age

    HTTP/1.1 uses the Age response-header to convey the estimated age of
    the response message when obtained from a cache.  The Age field value
    is the cache's estimate of the amount of time since the response was
    generated or validated by the origin server.  In essence, the Age
    value is the sum of the time that the response has been resident in
    each of the caches along the path from the origin server, plus the
    amount of time it has been in transit along network paths.

    The following data is used for the age calculation:

    age_value

       The term "age_value" denotes the value of the Age header, in a
       form appropriate for arithmetic operation; or 0, if not available.

    date_value

       HTTP/1.1 requires origin servers to send a Date header, if
       possible, with every response, giving the time at which the
       response was generated (see Section 9.3 of [Part1]).  The term
       "date_value" denotes the value of the Date header, in a form
       appropriate for arithmetic operations.  See Section 9.3.1 of
       [Part1] for requirements regarding responses without a Date
       response header.[[TODO-checkref: correct reference? --jre]]

    now

       The term "now" means "the current value of the clock at the host
       performing the calculation".  Hosts that use HTTP, but especially
       hosts running origin servers and caches, SHOULD use NTP
       ([RFC1305]) or some similar protocol to synchronize their clocks
       to a globally accurate time standard.

    request_time

       The current value of the clock at the host at the time the request
       resulting in the stored response was made.

    response_time

       The current value of the clock at the host at the time the
       response was received.

    A response's age can be calculated in two entirely independent ways:

    1.  now minus date_value, if the local clock is reasonably well
        synchronized to the origin server's clock.  If the result is
        negative, the result is replaced by zero.

    2.  age_value, if all of the caches along the response path implement
        HTTP/1.1.

    These are combined as

      corrected_received_age = max(now - date_value, age_value)

    When an Age value is received, it MUST be interpreted relative to the
    time the request was initiated, not the time that the response was
    received.

      corrected_initial_age = corrected_received_age
                              + (now - request_time)

    where "request_time" is the time (according to the local clock) when
    the request that elicited this response was sent.

    The current_age of a stored response can then be calculated by adding
    the amount of time (in seconds) since the stored response was last
    validated by the origin server to the corrected_initial_age.

    With these definitions, the current_age can be calculated as per:

      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;
-- snip --

Before I go on with the actual change for issue 29, I'd like to collect 
some feedback on the rearranged text, defining the data for the age 
calculation.

Also - Mark - is...:

"See Section 9.3.1 of [Part1] for requirements regarding responses 
without a Date response header."

this the reference you had in mind for absent Date headers?

Best regards, Julian

Received on Tuesday, 9 March 2010 13:20:13 UTC