W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: Issue 163, was: Meaning of invalid but well-formed dates

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 19 May 2009 15:43:10 +0200
Message-ID: <4A12B76E.8060304@gmx.de>
To: Brian Smith <brian@briansmith.org>
CC: 'Dan Winship' <dan.winship@gmail.com>, 'HTTP Working Group' <ietf-http-wg@w3.org>
Brian Smith wrote:
> Dan Winship wrote:
>> Julian Reschke wrote:
>>> That being said, changing a normative requirement from RFC2616, even
>>> if it's underspecified, is something we shouldn't do lightly.
>> Has anyone even seen an rfc850-date in the wild recently?
> No, and I think the MUST-level requirement should be reduced to SHOULD for
> that reason. It is analogous to the situation with line folding.
> I just found that the semantics of two-digit dates are defined already in
> Part 1, Appendix A, which used to be RFC 2616 Section 19.3. That statement
> should be moved up to section 3.2 with the rest of date syntax and
> semantics. 

Good catch, but what a mess:

     * HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date 
which appears to be more than 50 years in the future is in fact in the 
past (this helps solve the "year 2000" problem).

-> 50 years from when? Does the semantics of the message depend on when 
you look at it?

     * If an HTTP header incorrectly carries a date value with a time 
zone other than GMT, it MUST be converted into GMT using the most 
conservative possible conversion.

-> What exactly is the "most conservative conversion"?

It would be extremely useful to find out how deployed code handles these 
cases; either there is common handling (in which case we should specify 
it), or there isn't (in which case we could remove requirements).

BR, Julian
Received on Tuesday, 19 May 2009 13:43:52 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC