> Well that's a good reason. I'm persuaded. Now maybe you can persuade
> the spec writers. I note that the current HTTP spec at
> <http://info.cern.ch/hypertext/WWW/Protocols/HTTP/Object_Headers.html>
> is quite explicit: the Date header is optional. And until the HTTP spec is
> changed maybe "broken" is a little strong as an adjective to describe
> servers which don't supply a Date header.
Well, I generally try to be a bit more forceful than the existing HTTP spec.
The source of all these problems/misunderstandings is that the HTTP spec
was never finished -- when the WWW took off, the specs got left behind
(along with most of the documentation at CERN).
I am willing to volunteer my time toward rewriting/finishing the HTTP/1.0
specification such that it reflects current practice. However, I don't
want to step on anybody's toes in the process. Does everybody/anybody
think that I should do this? One nice thing is that it would allow us
to start talking about HTTP/1.1 as a separate entity.
> While we're on the topic of servers complying with the HTTP/1.0 spec
> let me raise another issue. The document cited above is quite
> explicit in saying that the status line (i.e. the first line) of the
> server response must end with CR/LF and not just LF. Presumably the
> same is true for other response headers; it is explicitly stated for
> all request headers. Anyway NCSA httpd terminates header lines with
> only LF. I haven't checked other servers. Does anyone care? Does it
> make any difference.
It may make a difference if people have mistakenly assumed that the lines
are always LF terminated (or always CR/LF terminated) in applications
which interact with those servers. It is definitely broken and should be
fixed, though it's not an emergency. One question is -- who will change it?
Is anybody working on the NCSA server now that Rob is at MCom?
......Roy Fielding ICS Grad Student, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>