Re: Issue: case-sensitive date format

Roy Fielding writes:

    Dean Gaudet has pointed out to me that Section 3.3.1 needs to include
    a sentence to the effect of
    
       HTTP-date is case sensitive and does not allow additional LWS
       beyond that specifically included as SP in the grammar.
    
    since "literal" defaults to case-insensitive.
    
I would phrase it as:
       HTTP-date is case sensitive and does not allow additional LWS
       beyond that specifically included as SP in the grammar.
       HTTP/1.1 implementations that generate HTTP-date values MUST use
       the correct case and LWS.  However, HTTP/1.1 clients and servers
       that parse HTTP-date value SHOULD accept values with extra LWS
       and without regard to case.

I went back to the 500K-message proxy trace I made about 14 months
ago, and went looking for what the then-existing HTTP implementations
actually send.

I started by looking for all header lines containing the string "GMT",
and took these lines apart into the individual tokens.  In this
group, I didn't find any lower-case month or day-of-the-week names,
although that doesn't prove that no implementations send "GMT"
dates with improper case; this survey only covers about 22K servers
and 7K clients.

I then looked for Date, Expires, and If-Modified-Since headers
(using a case-insensitive match for header names), and concentrated
on the ones that were not in GMT.  Here I found some interesting
oddities:
	Expires: {ts '1996-12-06 11:44:58'}
	Expires: 01-Jan-70
	Expires: Now
	Date: FRIDAY, 12/06/96 13:29:11 EST
	Date:Friday, 06-Dec-1996
	Date:         1996/08/26
	Date: Thu, 05 Dec 1996 18:08:25 +0000
	Date: March 1979
	Date: February 26, 1979
It's possible that some of these are actually from the bodies
of messages (sometimes my header-parser gets confused by interrupted
retrievals).  However, it does appear that at least one implementation
is sending RFC-850 style dates with non-standard case:
	Date: FRIDAY, 06-DEC-96 4:48:43 CST
Whether or not this should be rejected outright because of the "CST"
is another question.

(All of the If-Modified-Since headers in my trace seem to include
"GMT", although many are in RFC-850 format.)

Bottom line: there aren't many examples of implementations that
send otherwise legal dates but in the "wrong" case.  However,
it seems reasonable to suggest that implementations not choke
on these.

By the way, I found a few other date-related oddities in HTTP
headers:
	Satday, 30-Nov-96 19:59:25 GMT
	miercoles, 14-ago-96 08:20:33 GMT
	viernes, 06-dic-96 00:38:02 GMT

I can't imagine a date-parser that would really care that "Saturday" is
spelled "Satday" (instead of just ignoring the day-of-the-week
entirely).  On the other hand, trying to get a parser to understand the
month-names in all possible different languages is probably
impossible.  (I wonder if there is any three-letter string that
abbreviates two different month-names in two different lanuages?)

-Jeff

Received on Friday, 30 January 1998 13:50:49 UTC