Re: Call for Closure - HTTP response version

"Joel N. Weber II" <nemo@koa.iolani.honolulu.hi.us> wrote:
>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.

	But that was decided years ago when HTTP/1.0 was first born.
Clients should be testing for "HTTP/1.", not "HTTP/1.0", and until
someday there's a 2.x and it's an issue, retrying as HTTP/0.9.


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

	Clients may be (in fact, are) implementing HTTP/1.1 incrementally,
and thus may support some HTTP/1.1 features, but still be declaring
themselves as HTTP/1.0.  It most certainly is helpful for their
development to receive the HTTP/1.1 headers.  Such clients also may be
sending some of the HTTP/1.1 headers, if they're relevant to the
features they handle, and don't result in things they can't yet handle.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Tuesday, 31 December 1996 14:10:14 UTC