Re: HTTP date format: RFC 850 or RFC 1036
"Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
To: Tony Sanders <sanders@bsdi.com>
Cc: www-talk@www0.cern.ch, Tim Berners-Lee <timbl@www0.cern.ch>
Subject: Re: HTTP date format: RFC 850 or RFC 1036
In-reply-to: Your message of "Wed, 15 Dec 1993 19:30:39 CST."
<199312160130.TAA09527@austin.BSDI.COM>
Date: Wed, 15 Dec 1993 20:19:15 -0800
From: "Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
Message-id: <9312152019.aa00974@paris.ics.uci.edu>
Content-Length: 3148
>> The date format MUST be RFC822 compliant (as is the new RFC1036) and
>> can be seen in every Date: field generated by NNTP and mail.
> Is that so... Hmmm... a quick sample (from comp.mail.headers!) reveals no
> less than six (6) different Date formats in current use:
> Date: 1 Dec 1993 15:40:28 -0000
> Date: 15 Dec 1993 18:00:37 GMT
> Date: 4 Dec 93 23:53:10 GMT
> Date: Tue, 14 Dec 1993 21:29:02 GMT
> Date: Wed, 8 Dec 93 07:51:39 GMT
> Date: Mon, 06 Dec 93 22:05:22 +1000 (AEST)
> And this is from a sample size of only 7 messages!
>
> In other groups I found some really amazing stuff:
> Date: Monday 13 April, 1992 09:30:00 PDT
> Date: Monday, March 3, 12:59:00 CDT
> Date: Monday May 24 23:01:34.34 CDT 1993
> Date: Thu, 2 Dec 1993 12:53:49
> Date: Wed, 15 Dec 1993 13:36:54 UNDEFINED
> I have just as many email examples also. So much for "MUST" and "every".
Of the 603 mail messages and 197 news posts I have stored, every single
date header is RFC822 compliant with the exception that roughly half use
a four digit year (which I prefer) instead of two. The fact that there
exists non-compliant servers out there does not justify making HTTP servers
non-compliant.
> Now, do you have any valid arguments for *why* we should break hundreds
> of HTTP servers? It is VERY VERY important that HTTP software agree on
> the date format, and that it not change weekly. This isn't so with News
> and Mail (as is obvious by the lack of a real standard in those cases).
Break? The output format of the date makes no difference to the HTTP
server -- only to the clients (like the one I'm building). As for a change,
the NCSA httpd server just changed its date format to supposedly be RFC822
(see the announcement) and the fact that it is not should be pointed out.
Here is the one line change required to make NCSA httpd_1.0 compliant with
RFC822 and RFC1036 with the exception of the four-digit year:
----------------------------------------------------------------------
% diff -c save/util.c util.c
*** save/util.c Wed Dec 15 19:43:30 1993
--- util.c Wed Dec 15 19:44:28 1993
***************
*** 24,30 ****
t = gmtime(&sec);
/* check return code? */
! strftime(ts,MAX_STRING_LEN,"%A, %d-%h-%y %T GMT",t);
return ts;
}
--- 24,30 ----
t = gmtime(&sec);
/* check return code? */
! strftime(ts,MAX_STRING_LEN,"%a, %d %h %Y %T GMT",t);
return ts;
}
----------------------------------------------------------------------
>
> Clearly having a full year (instead of just two digits) is not optimial
> but neither is it a major problem (not until 2070 or so anyway).
>
> If we do end up changing then this is clearly the best format:
> Date: Tue, 04 Dec 1993 21:29:02 GMT
Which is what the above change does. I would be surprised if other
servers were any harder to change. What is important is that we don't
have a special date format for every protocol, resulting in a nightmare
for gateways and clients.
....Roy Fielding ICS Grad Student, University of California, Irvine USA
(fielding@ics.uci.edu)