- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 19 May 2009 15:24:18 +0200
- To: Brian Smith <brian@briansmith.org>
- CC: 'Daniel Stenberg' <daniel@haxx.se>, 'Jamie Lokier' <jamie@shareable.org>, 'Geoffrey Sneddon' <foolistbar@googlemail.com>, 'HTTP Working Group' <ietf-http-wg@w3.org>
Brian Smith wrote: > Daniel Stenberg wrote: >> It does beg the question: are implementations doing the comparisons >> case sensitively when parsing data in HTTP headers? I know libcurl >> certainly doesn't... >> >> And yeah, I wasn't aware of them being case sensitive either. > > The specification does say: > > Recipients of date values are encouraged to be robust in > accepting date values that may have been sent by non-HTTP > applications, as is sometimes the case when retrieving or posting > messages via proxies/gateways to SMTP or NNTP. > > SMTP and NNTP dates are not case sensitive, so it makes sense to parse these > in a case-insensitive manner. > > But, what does "are encouraged to" mean? Either it should be "are > RECOMMENDED to" (which means "SHOULD") or the statement should go. The > specification should not use non-RFC2119 language when making > recommendations. > > And, if it is to be "SHOULD", then the grammar should change to allow the > other cases (probably by adding an obs-rfc5322-date alternative that > references RFC 5322's date). Elsewhere in the document, the grammar reflects > what parsers SHOULD accept, and the prose further restricts what > implementations may generate. > ... I have opened a separate issue for this question (<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/165>). BR, Julian
Received on Tuesday, 19 May 2009 13:25:05 UTC