Re: HTTP response version, again

Dave is right.

An individual HTTP message should be interpretable by the version
number in the request/response line.  Additionally, http 1.1 should
minimize the proxy traffic that does not use persistent connections.

The following suggestions achieve these aims.
.
To make proxies work right, one needs to record the version of
the client or the origin server in header.

	* HTTP-Version MUST be used by clients and servers to advertise
	their maximum protocol version. Too bad the server and client headers
	didn't include maximumhttp version.

	* The via header takes care of the proxy versions.

The following ensures that the most traffic will use 1.1 persistent connections
and caching features.


	* HTTP 1.1 proxies MUST upgrade 1.0 requests from clients when talking
	to 1.1 proxies or servers downstream. They also need to downgrade
	responses.

	* HTTP 1.1 MUST downgrade 1.1 requests from clients when talking to
	1.0 proxies or servers downstream and upgrade responses coming back.


One way to minimize work in proxies and prevent tampering with an http
message is to encapsulate it with the different protocol version. This
kind of tunnelling is needed for any digested, digitally-signed, or
encrypted message.

For present purposes, the last 1.1 proxy in the request chain would need to
unpack a tunnelled 1.0 message before delivering it to a 1.0 origin server.
Similarly, the last proxy in the respopnse chain would need to unpack
the response for the 1.0 client.

Once the old servers and clients are gone, the encapsulation facility
will be used for transmitting cryptographically checked messages.


At 4:11 PM -0800 1996-12-20, David W. Morris wrote:
>On Fri, 20 Dec 1996, Larry Masinter wrote:
>
>> Dave, what about:
>> 
>> # The protocol version in the response MAY be either HTTP/1.1 or
>> # HTTP/1.0. The headers in the response MUST be consistent with BOTH the
>> # protocol version of the response AND the protocol version in the
>> # request.
>> 
>> I don't know why we have to nail this down. "We MAY not always have to
>> MUST if we can MAY."
>
>And the content of the response MUST be compatible with the request
>version when the version is lower than the response version ...
>this I suppose is a side effect of TRANSFER-ENCODING: as a header
>not allowed by the above rule but is will surely break a 1.0 client
>if it is presumed to ignore unknown headers and is sent a content
>body with chunked encoding.
>
>I think that the real issue here is we are using a single value to
>accomplish two objectives:
>
>   a.  Label the level of the response
>   b.  Declare the capabilities of the server
>
>
>Perhaps the 'bug' fix is to add a way for the server to declare its
>capabilities ? And in the status, label the level of the response.
>
>Dave Morris

Received on Sunday, 22 December 1996 09:27:54 UTC