Subject: #184: HTTP/0.9

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Aug 2009 05:27:38 +1000

<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?

--
Mark Nottingham     http://www.mnot.net/

---

From: David Morris <[email-masked]>
Date: Mon, 10 Aug 2009 12:38:59 -0700 (PDT)

Agree ... surely time to remove HTTP/0.9 from the specification. If we 
could get away with it, I'd require 0.9 requests be rejected as not 
supported.

A historical note and reference to an older RFC might be appropriate as it 
might help a newbie understand some part of server code they have 
inherited, etc.

Dave Morris

On Tue, 11 Aug 2009, Mark Nottingham wrote:

>> 	• recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1 
>> requests;
>> 	• 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?
>
> --

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Aug 2009 21:47:45 +0200

Mark Nottingham wrote:
 > ...

+1

In particular, we do *not* expect today's servers to understand 0.9 
requests, and respond to them. Right? RIGHT?

So, the replacement text would be:

"It is worth noting that, at the time of composing this specification, 
we would expect commercial HTTP/1.1 servers to:

     • recognize the format of the Request-Line for HTTP/1.0 and 1.1 
requests;
     • understand any valid request in the format of HTTP/1.0 or 1.1;
     • respond appropriately with a message in the same major version 
used by the client."

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Aug 2009 22:06:15 +0200

>     • respond appropriately with a message in the same major version 

Note that there's another mention of 0.9 in the subsequent paragraph... 
Proposed change: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/184/184.diff>

Full text:

-- snip --
    It is beyond the scope of a protocol specification to mandate
    compliance with previous versions.  HTTP/1.1 was deliberately
    designed, however, to make supporting previous versions easy.  It is
    worth noting that, at the time of composing this specification, we
    would expect commercial HTTP/1.1 servers to:

    o  recognize the format of the Request-Line for HTTP/1.0 and 1.1
       requests;

    o  understand any valid request in the format of HTTP1.0 and 1.1;

    o  respond appropriately with a message in the same major version
       used by the client.

    And we would expect HTTP/1.1 clients to:

    o  recognize the format of the Status-Line for HTTP/1.0 and 1.1
       responses;

    o  understand any valid response in the format of HTTP/1.0 or 1.1.

    For most implementations of HTTP/1.0, each connection is established
    by the client prior to the request and closed by the server after
    sending the response.  Some implementations implement the Keep-Alive
    version of persistent connections described in Section 19.7.1 of
    [RFC2068].
-- snip --

BR, Julian

---

From: Dan Winship <[email-masked]>
Date: Mon, 10 Aug 2009 16:24:05 -0400

>    would expect commercial HTTP/1.1 servers to:

Why "commercial" here, but not in the client text below? Maybe
"general-purpose HTTP/1.1 servers"?

>    o  understand any valid request in the format of HTTP1.0 and 1.1;

with the removal of 0.9, there's no need to call out the Request-Line
for special treatment. The second bullet point covers it. (Except that
you're missing a "/" in "HTTP1.0".) Likewise for Status-Line in the
client text.

>    o  respond appropriately with a message in the same major version

Maybe we should absorb some of the text from RFC 2145 (Use and
Interpretation of HTTP Version Numbers) here too?

-- Dan

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Aug 2009 22:34:37 +0200

> "general-purpose HTTP/1.1 servers"?

Sounds good to me.

> you're missing a "/" in "HTTP1.0".) Likewise for Status-Line in the

Right. New proposed change: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/184/184.2.diff>, 
changing the text to:

-- snip --
    would expect general-purpose HTTP/1.1 servers to:

    o  understand any valid request in the format of HTTP/1.0 and 1.1;

> Interpretation of HTTP Version Numbers) here too?

I assume this would repeat text from earlier sections; but it's too late 
over here (== I'm too lazy too...) to check...

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 11 Aug 2009 00:29:43 +0200

> requests, and respond to them. Right? RIGHT?

Right. But I still expect clients to handle HTTP/0.9 responses, even if
not required by any specifications old or new, but that does not need to
be covered here.

However, I would use slightly different wording for the server
requirements. What you proposed kind of implies that servers need to
understand the HTTP/1.0 specifications as well which is not the case.
The HTTP/1.1 specifications do contain all the needed requirements for
how a HTTP/1.1 server should respond to HTTP/1.0 requests. No need to
mention HTTP/1.0 as if it was a different format from HTTP/1.1. And the
same is also true for HTTP/1.1 clients receiving an HTTP/1.0 response.

Sorry, no explicit wording suggestion at this time. Too late in the
night.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Aug 2009 19:11:54 +0200

William A. Rowe, Jr. wrote:
> ...
> 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.

Really?

What's the situation for today's servers, such as recent httpds, IIS, 
Tomcat..,?

> 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:
> 
> ...

s/we would expect/we did expect/

In which case the reader will ask: "and as of 2009?"

> And that leaves the compatibility sentiment without suggesting it applies
> to 2009, or adding new editorial comment about 0.9/1.0 support.
> 
> WDYT?

It appears you're trying to avoid the question what we expect as of 
*2009*, and that's really what the reader would want to know (me thinks).

BR, Julian

---

From: Dan Winship <[email-masked]>
Date: Tue, 11 Aug 2009 14:20:55 -0400

> rely on trivial http: requests, even today.

HTTP/0.9 is not useful for programmatic stuff, because you don't get
back a status code, so you can't easily know whether the thing you got
back is the thing you were looking for, or an error message.

Trivial clients use HTTP/1.0 (plus the Host header), which is reasonably
simple to implement if you're only doing something trivial. (HTTP/1.1 is
complicated even for trivial requests, because there's no way to prevent
the server from using chunked encoding in the response, or sending an
unsolicited "100 Continue", etc.)

-- Dan

---

From: Geoffrey Sneddon <[email-masked]>
Date: Tue, 11 Aug 2009 21:27:04 +0200

On 11 Aug 2009, at 19:11, Julian Reschke wrote:

> What's the situation for today's servers, such as recent httpds,  
> IIS, Tomcat..,?

They all support HTTP/0.9. Clients have to support HTTP/0.9 for web  
compatibility (or at least those that care about web compatibility  
do), primarily due to broken CGI scripts.

--
Geoffrey Sneddon

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Aug 2009 21:52:04 +0200

Geoffrey Sneddon wrote:
> compatibility (or at least those that care about web compatibility do), 
> primarily due to broken CGI scripts.

I just tried IIS 5.1, and it responds with an HTTP/1.1 message.

It really seems we're making up requirements here.

BR, Julian

---

From: David Morris <[email-masked]>
Date: Tue, 11 Aug 2009 13:27:36 -0700 (PDT)

FWIW ... IIS 6.0 seems to provide the correct response for an HTTP/0.9 
request.
a. Responds after first CR/LF
b. Has no header/status in the response

Which doesn't change my mind ... 0.9 needs to leave the room.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 11 Aug 2009 12:29:12 -0700

> rely on trivial http: requests, even today.

The support for 0.9 was based on an old design mantra that major  
versions
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.

> 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.

....Roy

---

From: "William A. Rowe, Jr." <[email-masked]>
Date: Tue, 11 Aug 2009 12:29:19 -0400

...

WDYT?

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 11 Aug 2009 21:45:09 +0100

> What's the situation for today's servers, such as recent httpds, IIS, 

Apache 2.3.4 responds with a body and no headers, as expected for
HTTP/0.9.  When given a URL as opposed to a path, it uses the host
from the URL to select a virtual domain.

-- Jamie

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Aug 2009 17:18:25 +0200

> not required by any specifications old or new, but that does not need to

Why would a client be expected to handle 0.9 response when it doesn't 
send a 0.9 request?

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 13 Aug 2009 19:12:32 +0200

> Why would a client be expected to handle 0.9 response when it doesn't 

Because there is still some dumb devices out there responding with
HTTP/0.9. Eventually they will die, but server rotation is a bit slower
than client rotation.

But as I said it's not really something the HTTP/1.1 specifications need
to go into. It's entirely up to client vendors to judge if they need to
support HTTP/0.9 or not, or if just HTTP/1.x is sufficient as per the
HTTP/1.1 specifications + HTTP/1.0 keep-alive (which is not in 1.0
specifications, in fact all of the HTTP/1.0 specifications is best
ignored today). Most will be just fine with tha 1.1 specifications.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 24 Aug 2009 15:06:21 +1000

Julian, after re-reading the subsequent discussion, it looks to me  
like this patch is what we want to do.

Cheers,

On 11/08/2009, at 6:34 AM, Julian Reschke wrote:

> Right. New proposed change: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/184/184.2.diff 
> >, changing the text to:
>
> -- snip --
> I assume this would repeat text from earlier sections; but it's too  
> late over here (== I'm too lazy too...) to check...
>
> BR, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Aug 2009 09:40:33 +0200

Mark Nottingham wrote:
> Julian, after re-reading the subsequent discussion, it looks to me like 
> this patch is what we want to do.
> ...

Applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/685>.

BR, Julian