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: Wed, 25 Jan 2006 09:36:30 -0700
To: Boris Nikolaus <boris@cs.tu-berlin.de>
Cc: ietf-http-wg@w3.org
Message-Id: <1138206990.91687.43.camel@pail.measurement-factory.com>

On Wed, 2006-01-25 at 12:32 +0100, Boris Nikolaus wrote:
> On Tue, Jan 24, 2006 at 03:07:24PM -0700, Alex Rousskov wrote:
> > On Mon, 2006-01-23 at 15:34 +0000, Boris Nikolaus wrote:
> > > a) The Date represents the time of the original message:
> > I think (a) is the only possibility.
> I just found a section in RFC2616 which would result in (b) being
> correct:
>     10.3.5 304 Not Modified
>     [...]
>     The response MUST include the following header fields:
>     - Date, unless the omission is required by section 14.18.1
>     - [...]
>     - Expires, Cache-Control, and/or Vary, if the field-value might
>       differ from that sent in any previous response for the same
>       variant
>     [...]
>     If a cache uses a received 304 response to update a cache entry,
>     the cache MUST update the entry to reflect any new field values
>     given in the response.
> According to the last sentence, all the above mentioned headers
> have to be updated in the cache (including the Date header), so (b)
> should be the correct behaviour (which makes most sense to me).

If the cache updates the cache entry (whatever that means), then the
cache needs to update the Date header as well. However, if the cache
does not update the entry, then it is not required to update Date. In
the latter case, the Age value returned by the cache with subsequent
responses must keep increasing but the Date value will remain the same.

Note that the cache may, in some cases, forward the original 304 back to
the client without modifying it and then switch to generation of its own
304 responses for subsequent responses. And/or you may be talking to
different caches at different times.  This may create Date/Age sequences
that are not as monotonic/predictable as you prefer.

Looking back, I think I gave you a misleading/incorrect answer last
time, confused by the offered choices and an example of a non-HTTP/1.1
compliant cache. I apologize! The server sets Date for each response.
The Date is always the date when the message was generated. However,
there are several messages to consider when we are talking about cache

With respect to the cached entity, the cache has two choices:

 (b) Update Date (and, hence, reset Age)
 (c) Preserve Date (and, hence, increment Age)

With respect to the request that caused revalidation (assuming it was an
IMS request), the cache probably has two choices:

 (i) generate a 304 response based on the cached entity (updated or not)
 (ii) forward the original 304 response

When you combine the above choices, add non-predictability of proxy
routes, and add cooperative proxy meshes into the mix, you get
non-monotonic behavior of Date/Age combinations. Add non-compliant
proxies into the mix (many of which do not even bother to set or update
the Age header!), and you get semi-random Date/Age values.

I hope this answer clarifies the situation better than my original

Received on Wednesday, 25 January 2006 16:38:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:27 UTC