Re: Call for Closure - HTTP response version

On Tue, 31 Dec 1996, Koen Holtman wrote:

> Dave Kristol:
> >
> >Let me make some assumptions.  They may be controversial, but I haven't
> >seen substantial contradictory evidence:
> >
> >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.
> 
> Ugh.  I don't know what twist in this thread caused you to make those
> assumptions, but they paint a completely wrong picture of the actual
> situation.

No, I don't think that's wrong. Dave's point 2) refers more to the
"HTTP/1.1" label than the headers, and point 1) is correct. There are
some headers that don't work with HTTP/1.0. I guess they *could* be
sent... but page 23 does say "A server MUST NOT send transfer-codings
to an HTTP/1.0 client," for example.

Now, the second point is not 100% true, as there are some clients that
do not function this way (AOL's recent proxy mishap is a good
example). If there were many clients that were misfunctional in this
manner, it would make sense for a server to send a response in the
version of the request, since the server's user would probably want it
to work.

On the flip side, it is not true either that 100% of HTTP/1.0 servers
will respond correctly to a HTTP/1.1 request. Again, this number is
very small. If it were not, it would make sense for a HTTP/1.1 client
to send HTTP/1.0 requests, and switch to HTTP/1.1 when it finds a
compatible server. In this scenario, it would be neccessary for
HTTP/1.1 servers to always use HTTP/1.1 in the response.

In a situation where there were many (say 10% or more) "broken"
(though they aren't really) clients and many broken servers, this
would be a real problem - we'd probably have to invent a header field
that says "I understand HTTP/1.1, but can't label the response as such
because otherwise I'd block out a whole lot of requests/responses."

Luckily, the current situation features few "broken" clients and few
broken servers. So we can (and possibly will) have all
HTTP/1.1-compliant programs always send HTTP/1.1, both clients and
servers.

The problem, as I see it, with not making a decision on this issue is
this: if a server decides to respond to HTTP/1.0 requests with
HTTP/1.0, and HTTP/1.1 requests with HTTP/1.1, and a browser decides
to issue HTTP/1.0 requests first, then use HTTP/1.1 if the server
supports it, on the assumption that the server will always return
HTTP/1.1 if it is compliant, these two devices will end up using
HTTP/1.0, even though they both support HTTP/1.1.

Now, we could certainly simply reccomend that all HTTP/1.1-compliant
browsers/proxies always send requests with HTTP/1.1, and servers can
either send HTTP/1.0 to HTTP/1.1 responses or HTTP/1.1 to HTTP/1.1
responses. This would seem to be the nearest we've come to a
consensus.

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

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