Re: Call for Closure - HTTP response version

On Tue, 31 Dec 1996, Dave Kristol wrote:

> 1) The HTTP/1.1 draft is clear about which HTTP/1.1 headers cannot be
> sent to HTTP/1.0 clients.
> 2) If an HTTP/1.1 server sends a response labeled as HTTP/1.1, but with
> only HTTP/1.0-compatible headers, HTTP/1.0 clients will understand it.
> (There are a few known exceptions.)

The way GNU E-scape is written right now, it will send an HTTP/1.0 request.
If the first line it gets back contains HTTP/1.0, it treats the response
as an HTTP/1.0 response.  Otherwise, it assumes that it's talking to
an HTTP/0.9 server, and retries the request as HTTP/0.9

I will change it to react correctly to HTTP/1.x responses if that's
what is decided is the correct answer.  I haven't even made a prerelease
available to others yet, so there's plenty of time for the decission
to be made.

> I have stated several times my preference:  responses must be labeled
> with the same version as the request.
> Proponents of the other view assert that my approach will slow
> deployment of HTTP/1.1.  I don't see why.  Henryk and I have both asked
> for a direct response to the question, Why can't clients just send
> HTTP/1.1 requests when they're HTTP/1.1 capable?  An HTTP/1.1 server
> will respond in kind, and both will reap the benefits of the newer
> protocol.  An HTTP/1.0 server will respond as HTTP/1.0, and both will
> use that.  Having a server send an HTTP/1.1 response to a user agent or
> proxy that isn't HTTP/1.1 capable does nothing that I can see to speed
> HTTP/1.1 deployment or interoperation.

Sending HTTP/1.1 responses to HTTP/1.0 requests might speed deployment,
because it might hurt interoperation, and it will be nessisary to
upgrade browsers to keep them interoperable.

There's no reason I see that it's nessisary to send HTTP/1.1 headers
in response to HTTP/1.0 requests.

<>                    <>
"...For I have not come to call the righteous, but sinners."  -- Mathew 9:13

Received on Tuesday, 31 December 1996 12:51:17 UTC