To: new-httpd@hyperreal.com
Subject: Re: HTTP/1.1 
In-reply-to: Your message of "Thu, 25 Jul 1996 16:40:00 PDT."
             <Pine.SOL.3.93.960725163139.5571C-100000@acidik.organic.com>
Date: Thu, 25 Jul 1996 18:09:45 -0700
From: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>
Message-ID: <9607251809.aa20167@paris.ics.uci.edu>
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

>> Nope, don't commit that one -- we cannot change the server's HTTP version
>> until after we test the HTTP/1.1 features, which won't be finished until
>> the IESG approves the draft.  We don't need to change SERVER_PROTOCOL
>> until the last minute anyway.
> 
> Yes we do. We've been through this before - the server must behave
> differently when it's tagged as HTTP/1.1 then when it's tagged as
> HTTP/1.0.

No -- a server that calls itself HTTP/1.1 must behave as such-n-such.
A server that calls itself HTTP/1.0 can do anything it bloody well pleases.
Naturally, we try to limit ourselves to those things that work.

> Namely, if I send a request of:
> 
> GET / HTTP/1.1
> Host: hostname
> 
> A server tagged as HTTP/1.0 must not open a persistent connection, wheras
> a server tagged as HTTP/1.1 must. Rather an important distinction, IMO.

Neither is true.  The only requirements are that if the connection is made
persistent, then an HTTP/1.0 server must send Connection: keep-alive, and
if the connection is not persistent, an HTTP/1.1 server must send
Connection: close.  It is therefore safe, as an HTTP/1.0 server, to send
Connection: keep-alive on a persistent connection and
Connection: close on a non-persistent connection, regardless of the client's
version.  After it has been tested and we are an HTTP/1.1 server, we can
remove the option of sending Connection: keep-alive to an HTTP/1.1 client;
removing it is slightly more safe in the case of a broken proxy, but no such
broken proxy currently exists, and even if it did it would be better to
cause such a system to horribly crash now than to wait until more HTTP/1.1
systems get deployed.

Trust me -- there is nothing in HTTP/1.1 that can't be generated by an
HTTP/1.0 server.  If there was, I would not have allowed it in the protocol
since that defines the design contraints of HTTP/1.x.  The only thing
important is that all servers obey the 1.1 constraints on what can't be sent
to an HTTP/1.0 client.  Normal HTTP/1.1 clients will not "believe" the
1.1 features when coming from an HTTP/1.0 server, but there is no requirement
that we test with a normal HTTP/1.1 client.

>> Unknown -- it took them two months to approve HTTP/1.0 as informational
>> after the last comment was made.
> 
> Hmm. I assume the editors of the draft have indicated to the IESG that -06
> should be considered as a proposed standard? I'd assume so, but
> ftp://ds.internic.net/iesg/1protocol_actions.txt doesn't show anything
> about it.

Yes, they know.  The normal process is for the editors to produce a new
draft based on any comments received during the two-week last call, and that
new draft is "immediately" considered by the IESG, which in turn may ask
for additional changes before it is made an RFC.  Due to the length of
the draft, it will probably be another few weeks before the IESG is
willing to vote on it in one of their bi-weekly meetings.

In any case, we can't allow any software to be distributed that calls
itself HTTP/1.1 until the IESG approves it as a fixed reference.  Since
our own development tree and test servers are public, that means we
can't change SERVER_PROTOCOL in the cvs source until the last minute.
Note, however, that we may distribute Apache/1.2 before then, with all
the features implemented and tested according to draft 06, but without
the change to SERVER_PROTOCOL.

.....Roy