Re: Call for Closure - HTTP response version
- Alexei Kosut:
>?? I think it refers to headers.
>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
>> 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
>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.Actually, Dave's point 2) is correct too, but it fails to mention that
1.0 clients will *also* understand responses which include all kinds
of headers *not* defined by HTTP/1.0.
>There areA transfer encoding is an encoding of the message body, it is not a
>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.
header. Even AOL's proxy did not break on the presence of a HTTP/1.1
header. It broke on the the presence of the HTTP/1.1 version number.
- David W. Morris:
>Another choice is to stop overloading a single value for twoI see no such overloading in the HTTP/1.1 spec. The spec is clear on
> 1. Declaring the servers capabilities
> 2. Labeling the level of the response
the fact that the minor version number in the response does 1 (but
only for this particular request!), not 2.
Now, there *might* be a good reason to add a header which does 2. A
header which says `this response is compatible with both 1.0 clients
and 1.1 clients' might be useful for a 1.1 caching proxy. We'll find
out when someone actually starts trying to build such a proxy.
- David W. Morris:
>If a 1.0 proxy forwards a request and gets back a 1.1 response, it is
>A data point ...
>I have just observed that the CERN 3.0 proxy forwards the response
>status from the server to the client.
> client sent HTTP/1.0
> client gets back HTTP/1.1 in what would clearly seem to be a non-1.1
> proxy context.
allowed to switch to tunnel behavior and forward the exact response to
the client, 1.1 version number included. So what you have seen need
not be a bug in the CERN 3.0 proxy, it may be the CERN 3.0 proxy
switching to tunnel behavior.
On the other hand, if you are sure you are getting the 1.1 response
from CERN proxy cache memory, without the origin server being
contacted, then there _is_ a bug in the CERN 3.0 proxy. Does the Date
header change in subsequent responses?