- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 19 May 2009 15:43:10 +0200
- 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