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: Brian Smith <brian@briansmith.org>
Date: Sun, 17 May 2009 18:56:14 -0500
To: "'Daniel Stenberg'" <daniel@haxx.se>, "'Jamie Lokier'" <jamie@shareable.org>
Cc: "'Geoffrey Sneddon'" <foolistbar@googlemail.com>, "'Brian Smith'" <brian@briansmith.org>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <001601c9d74b$10d40820$327c1860$@org>
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

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.

- Brian
Received on Sunday, 17 May 2009 23:56:55 UTC

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