- From: Alexei Kosut <akosut@nueva.pvt.k12.ca.us>
- Date: Tue, 31 Dec 1996 14:06:40 -0800 (PST)
- To: Koen Holtman <koen@win.tue.nl>
- Cc: Dave Kristol <dmk@research.bell-labs.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, www-talk@www10.w3.org
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 17:08:25 UTC