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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 19 May 2009 15:24:18 +0200
Message-ID: <4A12B302.4030001@gmx.de>
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

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