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, JulianReceived 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