Re: HTTP/1.1

["Roy T. Fielding" <fi...@liege.ICS.UCI.EDU>]

> I've just uploaded a revised HTTP/1.1 patch to
> /httpd/incoming/http11a.patch. It fixes a number of the problems with the
> first one.
> 
> I agree; it's a large patch, and there are sure to be problems, but I
> think it's better to commit it all as is, and fix the problems, then to
> keep revising the patch. (all the pieces fit together, so it'd be hard to
> split it up into seperate patches, as well).

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.

> Anyone else think this is the right approach?

Yes -- everything except the change to SERVER_PROTOCOL can be applied
and tested as an HTTP/1.0 server.

Skimming it, the one code problem I see is the fixed boundary for
byte ranges -- that won't work because the server may be sending
a file which was once generated by a prior byterange output (e.g., an
example from the documentation or prior test cases or somebody's bug report).
At least part of the boundary (preferably most of it) must be pseudo-random.

> Re HTTP/1.1, though, I've a question; mainly for Roy, but if anyone else
> knows the answer, that'd be nice: What is the status of HTTP/1.1? The last
> call period on draft -05 came and went a few weeks ago. I never saw a new
> last call on draft -06, will there be one, or will the IESG just approve
> -06 directly? If so, is there a likely date when this might happen? I'd
> perfer to avoid the HTML 3.0 fiasco by not releasing Apache 1.2 until
> after HTTP/1.1 is at least a proposed standard. I'd be nice to have an
> approximate date on this.

Unknown -- it took them two months to approve HTTP/1.0 as informational
after the last comment was made.

....Roy

Re: HTTP/1.1

[Alexei Kosut <ak...@organic.com>]

On Thu, 25 Jul 1996, Roy T. Fielding wrote:

> > I agree; it's a large patch, and there are sure to be problems, but I
> > think it's better to commit it all as is, and fix the problems, then to
> > keep revising the patch. (all the pieces fit together, so it'd be hard to
> > split it up into seperate patches, as well).
> 
> 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.

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.

> Skimming it, the one code problem I see is the fixed boundary for
> byte ranges -- that won't work because the server may be sending
> a file which was once generated by a prior byterange output (e.g., an
> example from the documentation or prior test cases or somebody's bug report).
> At least part of the boundary (preferably most of it) must be pseudo-random.

Hmm. Hadn't thought of that. Narf. Anyone know a good boundary-generating
routine?

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

-- Alexei Kosut <ak...@organic.com>            The Apache HTTP Server 
   http://www.nueva.pvt.k12.ca.us/~akosut/      http://www.apache.org/