Subject: Date format glitch

From: Daniel Stenberg <[email-masked]>
Date: Sun, 10 Oct 2010 23:08:13 +0200 (CEST)

Hi friends,

In RFC2616 section 3.3.1 it says that "HTTP applications have historically 
allowed three different formats" and one of them is the RFC822/RFC1123 format.

It then goes on to say that RFC822 was updated by RFC1123 and that "clients 
and servers that parse the date value MUST accept all three formats". RFC1123 
basically only changed the year field to be 4-digit instead of 2-digit.

However - and here's my question/thoughts - the follwing BNF syntax 
description of the rfc1123 time in RFC2616 is incorrect by my reading of it. 
RFC822 has the seconds part of the time triplet (HH:MM:SS) optional. RFC822
defines it as:

  hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]

This "flaw" is in httpbis as well and while I don't think it ever causes any 
particular problem anywhere, it just popped to my attention as I believed my 
parser that parses HTTP dates were RFC822 compliant when in fact it wasn't... 
(It was used to parse RFC822 date strings in a totally unrelated context when 
this was reported.)

It might be worth to note this. Or not. I just wanted to mention this.

-- 

  / daniel.haxx.se

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Oct 2010 14:42:34 +0200

On 10.10.2010 23:08, Daniel Stenberg wrote:
> Hi friends,
>
> In RFC2616 section 3.3.1 it says that "HTTP applications have
> historically allowed three different formats" and one of them is the
> RFC822/RFC1123 format.
>
> It then goes on to say that RFC822 was updated by RFC1123 and that
> "clients and servers that parse the date value MUST accept all three
> formats". RFC1123 basically only changed the year field to be 4-digit
> instead of 2-digit.
>
> description of the rfc1123 time in RFC2616 is incorrect by my reading of
> it. RFC822 has the seconds part of the time triplet (HH:MM:SS) optional.
> RFC822
> defines it as:
>
> This "flaw" is in httpbis as well and while I don't think it ever causes
> any particular problem anywhere, it just popped to my attention as I
> believed my parser that parses HTTP dates were RFC822 compliant when in
> fact it wasn't... (It was used to parse RFC822 date strings in a totally
> unrelated context when this was reported.)
>

Ah, spec archeology :-)

The thing called "rfc1123-date" isn't really the format defined by RFC 
1123. See:

"However, the preferred format is a fixed-length subset of that defined 
by [RFC1123]:" -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-11.html#rfc.section.6.1>

Do we need to expand this sentence?

Best regards, Julian

PS: I think we discussed renaming the format some time ago, but 
concluded it would just increase the confusion we already see.

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 11 Oct 2010 14:50:42 +0200 (CEST)

On Mon, 11 Oct 2010, Julian Reschke wrote:

> The thing called "rfc1123-date" isn't really the format defined by RFC 1123. 
> See:
>
> "However, the preferred format is a fixed-length subset of that defined by 
> [RFC1123]:" --

Ah right. I read that sentense but wasn't sure how to interpret that, but no I 
see.

> Do we need to expand this sentence?

It would've helped me when I looked for clarifications on this, so if that is 
any guidance... But I'll admit I haven't looked into this much deeper so I 
don't know what other details in the format that isn't strictly adhering to 
RFC822/RFC1123, so I can't really suggest any particular wording at this 
point.

-- 

  / daniel.haxx.se

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Oct 2010 15:07:49 +0200

On 11.10.2010 14:50, Daniel Stenberg wrote:
> ...
> It would've helped me when I looked for clarifications on this, so if
> that is any guidance... But I'll admit I haven't looked into this much
> deeper so I don't know what other details in the format that isn't
> strictly adhering to RFC822/RFC1123, so I can't really suggest any
> particular wording at this point.
 > ...

OK, I added a short comment to the rfc1123-date ABNF (see 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1028>).

Best regards, Julian