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

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? 

>       asctime-date = day-name SP date3 SP time-of-day SP 4DIGIT
>       date2        = 2DIGIT "-" month "-" 2DIGIT
>                      ; 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)

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

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.

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

+1.

- Brian

Received on Friday, 8 May 2009 17:08:51 UTC