Re: HTTP response version, again

On Sat, 21 Dec 1996 S.N.Brodie@ecs.soton.ac.uk wrote:

> I agree with Brian here.  Case 2 is the preferable solution.  For a
> start it's the only easy way I can see of allowing my (HTTP/1.1
> compliant) browser can establish persistent connections with 1.1 proxies
> without requiring an extra request just to test it out.  I am not willing
> to rely on some of the more obscure methods (such as OPTIONS) not being
> implemented in a 1.0 proxy either.

Not true ... your browser would send the HTTP/1.1 request and a 1.1 server
would respond in kind in either case. A 1.0 server would be in error to
return 1.1 in the status response with a 1.0 response (which was all it
could generate).  In terms of pipelining being used before the server
responds with HTTP/1.1, while that is currently allowed by the spec.,
I am not convinced that it won't seriously confuse some existing 1.0
servers to receive data following the initial request so be wary and if
you try it let us and test with a wide variety of servers, let us know
what happens.

> My browser keeps a list of sites recently visited and their HTTP version
> precisely so it can avoid confusing them.

What will it do in the future when an HTTP/1.2 site declares itself?

> 
> I read the message that the AOL proxy has been issuing that blames the
> remote site for the failure (in Apache Week).  It would seem that their
> proxy does not implement HTTP/1.0 correctly if it does not accept a
> response in the same major version (which is all servers have to provide)

Perhaps they don't implement the non-standard HTTP/1.0 RFC 'correctly'
which may not have even existed when they implemented...

Until this discussion started, my interpretation was that n HTTP/1.0
request should always receive HTTP/1.0 in the status line.

Dave Morris

Received on Saturday, 21 December 1996 12:14:57 UTC