Re: HTTP response version, again

> I think that AOL's decision is silly, but they _are_ allowed to let
> their 1.0 clients do silly things when getting a 1.1 response.  The
> 1.0 spec is a `best current practice' spec, so you can call your
> clients 1.0 even if they disagree with some of it.  It would make AOL
> clients `inferior current practice', but they are allowed to be.

Please stop spreading this nonsense.  There is only one definition
of HTTP/1.0 and that is found in RFC 1945.  Whether or not it is a
standard is simply irrelevant.  Any application which fails to
implement HTTP/1.0 as specified in RFC 1945 is not implementing
HTTP/1.0, period.  That is the difference between a "bug" and a "feature"
for any protocol, regardless of its status in the IETF.

AOL's problem is that their proxy does not correctly implement HTTP/1.0.
That isn't too surprising -- many applications don't.  Their problems
won't go away until they do implement HTTP/1.x correctly.  This situation
has absolutely nothing to do with HTTP/1.1 aside from the singular fact
that it was one or more features of an HTTP/1.1 response that triggered
this particular bug in AOL's proxy.  I could easily trigger the same
bug with a valid HTTP/1.0 response.

It is very important that implementers understand the source of their
problems.  We didn't spend 18 months writing and reviewing RFC 1945
just because it seemed like a good idea at the time.  We needed a
protocol definition that was not subject to the variance of every
single hacker under the sun.

On a related subject, the reason why HTTP/1.1 does not say when a
server should send an HTTP/1.0 response is because then it would
be an HTTP/1.0 server and not subject to the draft-07 specification.
There are some things better left for writers of books.

Cheers,

 ...Roy T. Fielding    (still on vacation, and enjoying it)
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Sunday, 22 December 1996 03:23:20 UTC