W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: #184: HTTP/0.9

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 11 Aug 2009 12:29:12 -0700
Message-Id: <EEFF1D74-59F9-44B2-AD91-F38FD2D31425@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
On Aug 11, 2009, at 9:29 AM, William A. Rowe, Jr. wrote:

> Mark Nottingham wrote:
>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/184>
>>> p1 appendix B:
>>> It is worth noting that, at the time of composing this specification
>>> (1996), we would expect commercial HTTP/1.1 servers to:
>>>      recognize the format of the Request-Line for HTTP/0.9, 1.0,  
>>> and
>>> 1.1 requests;
>>>      understand any valid request in the format of HTTP/0.9,  
>>> 1.0, or
>>> 1.1;
>>>      respond appropriately with a message in the same major version
>>> used by the client.
>> This was discussed in Stockholm, and the feeling in the room was  
>> that we
>> should remove HTTP/0.9 from this text. Although it wasn't  
>> specifically
>> discussed, we'll also change the date.
>> Any further comments?
> The assumption that HTTP/0.9 should be understood shouldn't be removed
> until HTTP/1.2, I'd expect?  Surely there are many slim clients that
> rely on trivial http: requests, even today.

The support for 0.9 was based on an old design mantra that major  
would continue support for version - 1, but the fact is that responding
to a 0.9 request is completely unreliable due to host-based virtual
hosting.  The server ends up making wild guesses about the response,
which does nobody any good.

No slim client can rely on 0.9 because there is no host header
and therefore most sites would not be reachable in practice.

Today, the only significant occurrence of 0.9 is when Apache
responds to an invalid request (containing a CRLF in the middle
of a URI) with an assbackwards response.  I think we should
remove that support from Apache httpd.

> The date shouldn't be changed, but you are right that it makes little
> sense in 2616bis... what about
>   It is worth noting that, at the time RFC2616 was composed (1996),  
> we would
>   expect commercial HTTP/1.1 servers to:
> ...
> And that leaves the compatibility sentiment without suggesting it  
> applies
> to 2009, or adding new editorial comment about 0.9/1.0 support.

What are we trying to be compatible with?  The goal of the spec is to
define what is interoperable behavior for HTTP/1.1 -- that note was
just a hint to server developers regarding the different HTTP versions
found in the wild in 1995.  They don't exist now.

Received on Tuesday, 11 August 2009 19:29:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:51 UTC