Subject: Meaning of invalid but well-formed dates

From: Geoffrey Sneddon <[email-masked]>
Date: Sun, 3 May 2009 16:09:26 +0100

Hi,

"Wed, 32 March 2009 00:00:00 GMT" matches HTTP-date, and as far as I  
can tell is completely valid to produce and send. However, what it  
actually means is completely undefined.

Equally, "Mon, 03 May 2009 00:00:00 GMT" matches HTTP-date, but the  
wkday and and date1 disagree. This too is valid, but what it means is  
undefined.

Actually, I can't find anything that even defines what "Sun, 03 May  
2009 00:00:00 GMT" a valid and logically correct date means.

--
Geoffrey Sneddon
<http://gsnedders.com/>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 May 2009 19:30:24 +0200

Geoffrey Sneddon wrote:
> Hi,
> 
> "Wed, 32 March 2009 00:00:00 GMT" matches HTTP-date, and as far as I can 
> tell is completely valid to produce and send. However, what it actually 
> means is completely undefined.

Nope. It may be valid according to the ABNF grammar, but that doesn't 
make March, 32 a valid date.

> wkday and and date1 disagree. This too is valid, but what it means is 

See above.

> Actually, I can't find anything that even defines what "Sun, 03 May 2009 
> 00:00:00 GMT" a valid and logically correct date means.

I think it's totally obvious what it means. The day is "03", the month 
is "May", and the year is "2009". What am I missing here?

Maybe you could clarify what you're looking for? Do you have any 
evidence of implementations interpreting valid dates incorrectly?

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Sun, 3 May 2009 15:10:06 -0500

> actually means is completely undefined.

Everything is clearly specified, but you need to navigate a circuitous route
to find the definitions. HTTP-date time is defined in terms of RFC 1123's
date construct. RFC 1123's date construct is just RFC 822's date-time
extended to support four-digit years. RFC 822 already restricted date-time
constructs to semantically valid dates. RFC 2822 obsoleted RFC 822 and RFC
5322 obsoleted 2822. RFC 5322 clearly specifies the meaning of each
component of the date-time construct, including four-digit years.

The HTTP spec. shouldn't be referencing RFC 1123 anymore. RFC 1123's date
construct isn't really the same as what HTTP calls rfc1123-date so the name
is misleading; "date-time" could be a better name. If the components of
HTTP-date were renamed to match the names in RFC 5233 then the specification
could then say:

   The semantics of <date-time>, <day-name>, <day>,
   <month-name>, <year>, and <time-of-day> are the
   same as the semantics of the RFC 5322 constructs
   with the corresponding name.

Also, the statement "[...]; it MUST be sent in rfc1123-date format" should
be removed from section 8.3 (Date), because section 3.2.1 already says:

   [Implementations] MUST only generate the RFC 1123 format for
   representing HTTP-date values in header fields.

It is straightforward to replace the other RFC 1123 references with RFC 5322
references.

- Brian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 04 May 2009 09:04:23 +0200

> date construct. RFC 1123's date construct is just RFC 822's date-time

Actually, it's not. At least it's not intended to. The reference to RFC 
1123 is to explain where it comes from, and is informative.

>    with the corresponding name.

That sounds like a good idea.

> be removed from section 8.3 (Date), because section 3.2.1 already says:

As a matter of fact, 8.3 already refers to RFC5322 for semantics. 
Probably that should just be moved up to Section 3.2.1.

Also, the duplication was introduced in RFC 2616 (it's not present in 
<http://tools.ietf.org/html/rfc2068#section-14.19>).

> It is straightforward to replace the other RFC 1123 references with RFC 5322

Best regards, Julian

---

From: Geoffrey Sneddon <[email-masked]>
Date: Mon, 4 May 2009 16:21:11 +0100

On 3 May 2009, at 18:30, Julian Reschke wrote:

> Geoffrey Sneddon wrote:
>> Hi,
>> "Wed, 32 March 2009 00:00:00 GMT" matches HTTP-date, and as far as  
>> I can tell is completely valid to produce and send. However, what  
>> it actually means is completely undefined.
>
> Nope. It may be valid according to the ABNF grammar, but that  
> doesn't make March, 32 a valid date.

What makes it invalid in the spec?

--
Geoffrey Sneddon
<http://gsnedders.com/>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 May 2009 17:44:47 +0200

Brian Smith wrote:
> ...

I have opened <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/163>, 
tracking this.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 May 2009 14:29:55 +0200

> I have opened <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/163>, 

I produced a proposed change that rearranges the ABNF, renames some of 
the productions for consistency with RFC5322, and refers to RFC5322 for 
their semantics -- see 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/163/163.diff> 
and below:

-- snip --
3.2.  Date/Time Formats

3.2.1.  Full Date

    HTTP applications have historically allowed three different formats
    for the representation of date/time stamps:

      Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
      Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
      Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

    The first format is preferred as an Internet standard and represents
    a fixed-length subset of that defined by [RFC1123].  The other
    formats are described here only for compatibility with obsolete
    implementations.  HTTP/1.1 clients and servers that parse the date
    value MUST accept all three formats (for compatibility with
    HTTP/1.0), though they MUST only generate the RFC 1123 format for
    representing HTTP-date values in header fields.  See Appendix A for
    further information.

       Note: 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.

    All HTTP date/time stamps MUST be represented in Greenwich Mean Time
    (GMT), without exception.  For the purposes of HTTP, GMT is exactly
    equal to UTC (Coordinated Universal Time).  This is indicated in the
    first two formats by the inclusion of "GMT" as the three-letter
    abbreviation for time zone, and MUST be assumed when reading the
    asctime format.  HTTP-date is case sensitive and MUST NOT include
    additional whitespace beyond that specifically included as SP in the
    grammar.

      HTTP-date    = rfc1123-date / obs-date

      rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT

      day-name     = s-Mon / s-Tue / s-Wed
                   / s-Thu / s-Fri / s-Sat / s-Sun

      s-Mon = %x4D.6F.6E ; "Mon", case-sensitive
      s-Tue = %x54.75.65 ; "Tue", case-sensitive
      s-Wed = %x57.65.64 ; "Wed", case-sensitive
      s-Thu = %x54.68.75 ; "Thu", case-sensitive
      s-Fri = %x46.72.69 ; "Fri", case-sensitive
      s-Sat = %x53.61.74 ; "Sat", case-sensitive
      s-Sun = %x53.75.6E ; "Sun", case-sensitive

      date1        = day SP month SP year
                   ; e.g., 02 Jun 1982

      day          = 2DIGIT
      month        = s-Jan / s-Feb / s-Mar / s-Apr
                   / s-May / s-Jun / s-Jul / s-Aug
                   / s-Sep / s-Oct / s-Nov / s-Dec
      year         = 4DIGIT

      s-Jan = %x4A.61.6E ; "Jan", case-sensitive
      s-Feb = %x46.65.62 ; "Feb", case-sensitive
      s-Mar = %x4D.61.72 ; "Mar", case-sensitive
      s-Apr = %x41.70.72 ; "Apr", case-sensitive
      s-May = %x4D.61.79 ; "May", case-sensitive
      s-Jun = %x4A.75.6E ; "Jun", case-sensitive
      s-Jul = %x4A.75.6C ; "Jul", case-sensitive
      s-Aug = %x41.75.67 ; "Aug", case-sensitive
      s-Sep = %x53.65.70 ; "Sep", case-sensitive
      s-Oct = %x4F.63.74 ; "Oct", case-sensitive
      s-Nov = %x4E.6F.76 ; "Nov", case-sensitive
      s-Dec = %x44.65.63 ; "Dec", case-sensitive

      GMT   = %x47.4D.54 ; "GMT", case-sensitive

      time-of-day  = hour ":" minute ":" second
                     ; 00:00:00 - 23:59:59

      hour         = 2DIGIT
      minute       = 2DIGIT
      second       = 2DIGIT

    The semantics of day-name, day, month, year, and time-of-day are the
    same as those defined in the RFC 5322 constructs with the
    corresponding name ([RFC5322], Section 3.3).

      obs-date     = rfc850-date / asctime-date
      rfc850-date  = day-name-l "," SP date2 SP time-of-day SP GMT
      asctime-date = day-name SP date3 SP time-of-day SP 4DIGIT

      date2        = 2DIGIT "-" month "-" 2DIGIT
                     ; day-month-year (e.g., 02-Jun-82)
      date3        = month SP ( 2DIGIT / ( SP 1DIGIT ))
                     ; month day (e.g., Jun  2)
      day-name-l   = l-Mon / l-Tue / l-Wed
                   / l-Thu / l-Fri / l-Sat / l-Sun

      l-Mon = %x4D.6F.6E.64.61.79          ; "Monday", case-sensitive
      l-Tue = %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
      l-Wed = %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
      l-Thu = %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
      l-Fri = %x46.72.69.64.61.79          ; "Friday", case-sensitive
      l-Sat = %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
      l-Sun = %x53.75.6E.64.61.79          ; "Sunday", case-sensitive

    Note: HTTP requirements for the date/time stamp format apply only to
    their usage within the protocol stream.  Clients and servers are not
    required to use these formats for user presentation, request logging,
    etc.
-- snip --

While at it, we probably should also drop the surplus subsection 3.2.1 
and move all of this into 3.2 (this is a left-over from partitioning RFC 
2616).

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 8 May 2009 12:08:11 -0500

Julian Reschke wrote:
> 3.2.  Date/Time Formats
>     The first format is preferred as an Internet standard and
>     represents a fixed-length subset of that defined by
>     [RFC1123].

I still think it is misleading to refer to RFC1123 here when HTTP doesn't
use the syntax or the semantics of RFC1123. Besides, the specification
doesn't have to justify why the that syntax is preferred. The next paragraph
already states that implementations MUST use it. I'd just delete that
paragraph.

I don't get why s-Mon, s-Jan, l-Mon, etc. are named productions (instead of
unnamed alternatives like in RFC 5023), but that is not new to this change.

The semantics of the obsolete date formats are not defined. How is a server
supposed to interpret a 2-digit year? 

>                      ; day-month-year (e.g., 02-Jun-82)

Might as well use "day" and "year":

        asctime-date = day-name SP date3 SP time-of-day SP year
        date2        = day "-" month "-" 2DIGIT
                       ; day-month-year (e.g., 02-Jun-82)

> required to use these formats for user presentation, request logging,

Might as well delete this while you are at it. It is strange to single out
that this one part of the HTTP syntax doesn't have to be used outside of the
protocol, when that is generally true for all parts of the syntax.

> and move all of this into 3.2 (this is a left-over from partitioning
> RFC 2616).

+1.

- Brian

---

From: Geoffrey Sneddon <[email-masked]>
Date: Fri, 8 May 2009 18:25:08 +0100

> unnamed alternatives like in RFC 5023), but that is not new to this  

Case sensitivity. Plain strings in ABNF are case insensitive.

--
Geoffrey Sneddon
<http://gsnedders.com/>

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 8 May 2009 12:32:59 -0500

> Case sensitivity. Plain strings in ABNF are case insensitive.

I meant, why not write them like this:

  day-name = %x4D.6F.6E  ; "Mon", case-sensitive
           / %x54.75.65  ; "Tue", case-sensitive
           / %x57.65.64  ; "Wed", case-sensitive
           / %x54.68.75  ; "Thu", case-sensitive
           / %x46.72.69  ; "Fri", case-sensitive
           / %x53.61.74  ; "Sat", case-sensitive
           / %x53.75.6E  ; "Sun", case-sensitive

It's not really a big deal, but I think this way is clearer.

- Brian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 May 2009 19:48:40 +0200

> It's not really a big deal, but I think this way is clearer.

I was going to agree, but then realized that we would loose clarity in 
the collected ABNF (which doesn't contain the comments).

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 May 2009 20:06:01 +0200

> already states that implementations MUST use it. I'd just delete that

I think it's useful to understand why HTTP/1.1 happens to use this format.

> unnamed alternatives like in RFC 5023), but that is not new to this change.

For readability; our version is case-sensitive, so we can't use string 
constants in the ABNF.

> supposed to interpret a 2-digit year? 

Good question. Do you have an answer? Can we mandate the rules in 
<http://tools.ietf.org/html/rfc5322#section-4.3>?

> Might as well use "day" and "year":

We can re-use "day", but not "year" (because it's 4DIGIT).

> protocol, when that is generally true for all parts of the syntax.

I think I agree, but I'd like to avoid taking out stuff without more review.

>> and move all of this into 3.2 (this is a left-over from partitioning

Will do that when the patch gets applied. In the meantime I have 
re-arranged stuff a bit more so that it's more clear what belongs to 
which format, and which ones are preferred/obsolete; and also moved the 
other note to the end of the paragraph. See 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/163/163.diff> 
and full text below:

-- snip --
3.2.  Date/Time Formats

3.2.1.  Full Date

    Preferred format:

      day          = 2DIGIT

      hour         = 2DIGIT
      minute       = 2DIGIT
      second       = 2DIGIT

    Obsolete formats:

       Note: HTTP requirements for the date/time stamp format apply only
       to their usage within the protocol stream.  Clients and servers
       are not required to use these formats for user presentation,
       request logging, etc.
-- snip --

Best regards, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 8 May 2009 13:13:33 -0500

Julian Reschke wrote:
> Brian Smith wrote:
> > The semantics of the obsolete date formats are not defined. How is a
> > server supposed to interpret a 2-digit year?
> 

I don't have an answer. RFC 5322's rules are just as good as any, I suppose.

> We can re-use "day", but not "year" (because it's 4DIGIT).

I meant, use <day> for <date2> and <year> for <asctime-date>.

- Brian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 May 2009 20:17:37 +0200

> I don't have an answer. RFC 5322's rules are just as good as any, I suppose.

Yes, but we can't just impose a rule because we like it, unless we are 
sure it's what's actually implemented.

> I meant, use <day> for <date2> and <year> for <asctime-date>.

Ack. (see my new patch)

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 May 2009 12:45:26 +0200

> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/163/163.diff> 

I have applied the proposed change with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/580> (and also got 
rid of subsection 3.2.1).

The ticket stays open, in case we find out how to defined the semantics 
for RFC850 dates, or decide on other related changes.

BR, Julian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 11 May 2009 10:51:24 +0900

Sorry to be late with this comment.

> the collected ABNF (which doesn't contain the comments).

That seems to be backward. Wouldn't the comments be helpful in the 
collected ABNF, too?

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 May 2009 09:13:29 +0200

> That seems to be backward. Wouldn't the comments be helpful in the 

The collected ABNF is produced by an ABNF parser (Bill Fenner's), by 
serializing the rule objects it generates. Thus, it doesn't have the 
comments anymore.

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 11 May 2009 06:51:08 -0500

> serializing the rule objects it generates. Thus, it doesn't have the

If the readability of the collected ABNF were a goal, then the comments
would be included, and the #rule extensions would be preserved.

Having the collected ABNF split into multiple parts defeats the purpose of
having a collected ABNF. Given the availability of Bill Fenner's tool, and
the fact that the appendicies are generated from that tool, I don't see why
the collected ABNF appendices need to be included anymore. A single,
plain-text (no IETF boilerplate like headers/footers) file that gathers all
the productions from all documents (including all parts of HTTPbis, RFC3986,
etc.) would be a much more useful deliverable.

In the event that Appendix D differs materially from the grammar in the rest
of the document, which part of the document takes precedence? Is Appendix D
non-normative? It looks like all the appendices are non-normative except
maybe the glossary.

- Brian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 May 2009 13:57:58 +0200

> would be included, and the #rule extensions would be preserved.

If we used the #rule, it wouldn't be an ABNF conforming to RFC5234 anymore.

> etc.) would be a much more useful deliverable.

I have no problem in working on generating and publishing it 
unofficially, but I'm not sure how to make it part of the official spec. 
Any proposal for that?

> non-normative? It looks like all the appendices are non-normative except

Everything in an RFC is normative unless stated otherwise (as far as I 
can tell).

The ABNF appendix is auto-generated, thus I don't see how it can get out 
of sync with the rest of the spec except by us, the editors, screwing up.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 17 May 2009 13:56:48 +0200

> serializing the rule objects it generates. Thus, it doesn't have the 

In the meantime I noticed that BAP (Bill Fenner's ABNF Parser) can 
automatically generate comments for printable byte sequences; with that 
feature turned on the generated ABNF is readable enough without the 
extra productions.

See <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/582>. The 
section now reads:

-- snip --
3.2.  Date/Time Formats: Full Date

    Preferred format:

      day          = 2DIGIT
      month        = %x4A.61.6E ; "Jan", case-sensitive
                   / %x46.65.62 ; "Feb", case-sensitive
                   / %x4D.61.72 ; "Mar", case-sensitive
                   / %x41.70.72 ; "Apr", case-sensitive
                   / %x4D.61.79 ; "May", case-sensitive
                   / %x4A.75.6E ; "Jun", case-sensitive
                   / %x4A.75.6C ; "Jul", case-sensitive
                   / %x41.75.67 ; "Aug", case-sensitive
                   / %x53.65.70 ; "Sep", case-sensitive
                   / %x4F.63.74 ; "Oct", case-sensitive
                   / %x4E.6F.76 ; "Nov", case-sensitive
                   / %x44.65.63 ; "Dec", case-sensitive
      year         = 4DIGIT

      hour         = 2DIGIT
      minute       = 2DIGIT
      second       = 2DIGIT

    Obsolete formats:

      day-name-l   = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
             / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
             / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
             / %x46.72.69.64.61.79 ; "Friday", case-sensitive
             / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
             / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive

BR, Julian

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 17 May 2009 19:08:41 +0100

> Case sensitivity. Plain strings in ABNF are case insensitive.

Oh.  I didn't realise date strings in HTTP were case sensitive.  I
just thought they were always generated that way for maximum
compatibility and convention, in the same way that we capitalise HTTP
header names according to convention.

-- Jamie

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 17 May 2009 23:11:00 +0200 (CEST)

On Sun, 17 May 2009, Jamie Lokier wrote:

> Oh.  I didn't realise date strings in HTTP were case sensitive.  I just 
> thought they were always generated that way for maximum compatibility and 
> convention, in the same way that we capitalise HTTP header names according 
> to convention.

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.

-- 

  / daniel.haxx.se

---

From: "Brian Smith" <[email-masked]>
Date: Sun, 17 May 2009 18:56:14 -0500

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...
> 

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.

- Brian

---

From: "Brian Smith" <[email-masked]>
Date: Sun, 17 May 2009 21:38:41 -0500

>                    / %x53.75.6E ; "Sun", case-sensitive

I think that does make the grammar more readable.

>     The semantics of day-name, day, month, year, and time-of-day are
>     the same as those defined in the RFC 5322 constructs with the

This wording is a little off. Try:

      The semantics of day-name, day, month, year, and time-of-day are
      the same as semantics of the RFC 5322 constructs with the
      corresponding name ([RFC5322], Section 3.3).

Note that this change resolves the issue for rfc1123-date but not for the
obsolete forms. 

- Brian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 May 2009 13:59:48 +0200

>       corresponding name ([RFC5322], Section 3.3).

That doesn't sound better to me, but that may be caused by me not being 
a native English speaker.

> Note that this change resolves the issue for rfc1123-date but not for the

Yes, I already pointed that out. Do you have a proposal how to get there 
(which would to consider existing implementations)?

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 18 May 2009 11:21:58 -0500

> a native English speaker.

"...defined in the RFC 5322 constructs..." means the definition is inside
the construct. I thnk you meant "...defined in RFC 5322 for the
constructs...".

> > Note that this change resolves the issue for rfc1123-date but not for
> > the obsolete forms.
> 
> Yes, I already pointed that out. Do you have a proposal how to get
> there (which would to consider existing implementations)?

The only instances of this problem are one-digit days in asctime-date (just
prepend a zero to get a day), day-name-l (just drop all characters after the
first three to get a day-name), and two-digit years. I doubt there is an
interpretation of two-digit years commonly accepted by all implementations.
Probably the most common implementation is to either ignore dates using
rfc850-date format and/or return (400) errors when rfc850-date is
encountered. That is what all my implementations do. Accordingly, I don't
think support for rfc850-date should be a MUST- or even SHOULD- level
requirement.

Regards,
Brian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 May 2009 19:00:23 +0200

> the construct. I thnk you meant "...defined in RFC 5322 for the

Indeed. Fixed.

> think support for rfc850-date should be a MUST- or even SHOULD- level

Yes, the 2-digit dates are a can of worms. This is a mess, we do both 
say "MUST accept", but then do not say what it means.

That being said, changing a normative requirement from RFC2616, even if 
it's underspecified, is something we shouldn't do lightly.

BR, Julian

---

From: Dan Winship <[email-masked]>
Date: Mon, 18 May 2009 15:28:45 -0400

> say "MUST accept", but then do not say what it means.

And we *can't* just assert a meaning arbitrarily, since we also forbid
implementations to send them, and so by definition, if you receive an
rfc850-date, then you've received it from an implementation that doesn't
obey our rules...

> it's underspecified, is something we shouldn't do lightly.

Has anyone even seen an rfc850-date in the wild recently?

Anyway, if you really want to nail their semantics down, RFC 2616 and
1945 (HTTP/1.0) both say that the Date header has "the same semantics as
orig-date in RFC 822", and RFC 822 says that "If included, day-of-week
must be the day implied by the date specification." Since HTTP's
rfc850-date syntax requires the day of week to be present, then if we
just say implementations SHOULD assume all rfc850-dates refer to years
between 1900 and 2299, then they are no longer ambiguous, merely
annoying. "Monday, 18-May-09 19:16:46 GMT" is today, and "Tuesday,
18-May-09 19:16:46 GMT" was 100 years ago.

-- Dan

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 18 May 2009 15:38:10 -0500

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.
> 

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. 

- Brian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 May 2009 15:24:18 +0200

> implementations may generate.

I have opened a separate issue for this question 
(<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/165>).

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 May 2009 15:43:10 +0200

> should be moved up to section 3.2 with the rest of date syntax and

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

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 19 May 2009 15:01:50 +0100

> -> 50 years from when? Does the semantics of the message depend on when 

One could just assume that systems with such long time ranges simply
won't transmit RFC-850 dates _over HTTP_.  Then the "wraparound"
comparison works: similar to the 32-bit wraparound sequence comparison
used by TCP and many other systems.

For archived email and news, of course 2-digit years will continue to
mean the same for a long time into the future, and should not be used
for new messages.

It would be tidy to be consistent with email and news interpretation
of 2-digit years, whatever it is, which presumably doesn't depend on
when you look at it.

But since we never expect to see 2-digit years in HTTP, and if there
are any implementations which do, they can be expected to disappear,
either interpretation should be fine.

... Unless there is some attack on HTTP possible by taking advantage
of a message's time being interpreted differently on different agents
that it passes through.  Proxies don't rewrite the date header into
standard form - do they?

-- Jamie

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 19 May 2009 09:31:27 -0500

Jamie Lokier wrote:
> > 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?

I think the algorithm is:

* If the Date header field isn't present, synthesize a Date header from the
current time as you usually would. 
* Add the century from the Date header to the two-digit year.
* If the resultant year is 50 years or more in the future (relative to the
Date header), keep subtracting 100 from it until it appears to be in the
past (subtracting 100 once will be sufficient if the Date header isn't
invalidly far in the future).

I don't know why only "clients and caches" should do this and not origin
servers. That doesn't make sense to me.

> that it passes through.  Proxies don't rewrite the date header into

They are required to rewrite dates into rfc1123 format, because they are
forbidden from sending dates in the obsolete formats. My implementations do
not do that, but I don't know about others. 

- Brian

---

From: David Morris <[email-masked]>
Date: Tue, 19 May 2009 07:35:22 -0700 (PDT)

On Tue, 19 May 2009, Julian Reschke wrote:

> -> 50 years from when? Does the semantics of the message depend on when you 
> look at it?

50 years from now ... sure ... the problem with 2 digit years is well 
known and has been for more than 15 years. So this is simply a bad data 
fix up which has essentially no risk of a bad outcome. In the case where 
the recipient knows of a bad potential outcome for the wrong 
interpretation, such a date should be rejected ... (I don't feel a need to
say this in the spec).

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 25 May 2009 16:38:32 +0900

>> make March, 32 a valid date.

In another IETF WG, we used to use such kinds of dates to meet our 
deadlines. Let's say we had a deadline of March 2009 for one of our 
drafts. If we didn't make it by March 31st, we would just continue 
counting days and make it by March 45th or March 64th or whatever :-).