W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2006

Re: Behaviour of Date and Age Headers on Proxy Revalidate

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Tue, 24 Jan 2006 15:07:24 -0700
To: Boris Nikolaus <boris@cs.tu-berlin.de>
Cc: ietf-http-wg@w3.org
Message-Id: <1138140444.67293.48.camel@pail.measurement-factory.com>

On Mon, 2006-01-23 at 15:34 +0000, Boris Nikolaus wrote:

> RFC2616 states that
> 
>     the Age response-header field conveys the sender's estimate of the
>     amount of time since the response (or its revalidation) was
>     generated at the origin server
> 
> but that
>     
>     the Date general-header field represents the date and time at
>     which the message was originated,
> 
> leaving out the behaviour for a proxy after a revalidation for the
> Date header.

Pure proxies do not usually originate messages so the above definition
does not leave anything out, I think. The Date header is set by origin
servers. Proxies set Date only if it is missing from the original
message.

>   This leaves two possibilities:
> 
> a) The Date represents the time of the original message:
> 
>    This is the behaviour of squid 2.5, but looks very weird for
>    some objects to me:

I think (a) is the only possibility. There is nothing weird about the
Date and Age headers you observe if you notice the "or its revalidation"
clause in the Age definition.

>    What distracts me mostly is that "Date" + "Age" is not monotonic in
>    this case because I would like that "Date" + "Age" is an estimate
>    for the current time of the clock of the web server (apart from
>    network delays).

(Date + Age) is not a very meaningful expression in HTTP.
(Request_time - Age) is.

I agree that it may be counter-intuitive.

HTH,

Alex.
P.S. Please note that many proxies do not compute the Age value
correctly (i.e., according to the specs), and the algorithm in the specs
has its own known "inaccuracies".
Received on Tuesday, 24 January 2006 22:07:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:42 GMT