Re: Date header handling

"Nottingham, Mark (Australia)" <mark_nottingham@exchange.au.ml.com> writes

    14.18 says that the Date header "represents the date and time at
    which the message was originated, having the same semantics as
    orig-date in RFC 822.  [...] The HTTP-date sent in a Date header
    SHOULD NOT represent a date and time subsequent to the generation
    of the message."

    Is the term 'message' used here as it is defined in 1.3? The
    reference to 822 seems to indicate it is bound to the entity
    generation date, not the message generation date.

    Also to support this,
    * 13.5.1 implies that Date is a end-to-end header, and SHOULD NOT
    be changed by a cache (although it isn't specifically forbidden in
    13.5.2).
    * 13.2.3 calculates entity age based on the Date header; if Date
    were modified after entity generation, this would be invalid.

Ouch.  The text from 14.18 probably should have said "end-to-end
message", since it does seem to be ambiguous (although one might
believe that the word "originated" implies "origin server",
this is clearly open to misinterpretation).

There is also text in 13.2.3 saying:

   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 14.18). We use the term "date_value" to denote
   the value of the Date header, in a form appropriate for arithmetic
   operations.

I think the lack of clarity may reflect the assumption that
all responses carry a Date from the origin server, and so
we just assumed that proxies wouldn't be adding them except
when specifically required by 14.18.

    I've noticed that some Web caches will change the response's Date
    header to reflect the time that they generate the message. Based on
    the above, this seems to be incorrect. Others will use the original
    Date, but not update the header upon validation (as in 13.5.3).

    Is this correct? What's the proper behaviour here?

It's hard to define "proper behaviour" for HTTP/1.0 caches,
since the HTTP/1.1 spec doesn't formally apply to them, and
the HTTP/1.0 spec wasn't very detailed in this area.  HTTP/1.1
compliant proxies, based on 13.5.1, SHOULD NOT modify Date
headers (i.e., not without a very good reason, and I can't
think of any right now).  And 13.5.3 clearly says that
HTTP/1.1-compliant proxies MUST update the Date of a stored
cache entry upon validation.

So if the "some Web caches" you refer to are claiming to
be HTTP/1.1 implementations, these are in violation of
the spec.  Otherwise, we're stuck with the history of HTTP/1.0.

-Jeff

Received on Monday, 19 July 1999 13:07:21 UTC