Re: Call for Closure - HTTP response version

> There are two quite distinct pieces of information that in principle
> might be conveyed by a version header: 1) the capabilities of the
> server which are available for future transactions, and 2) the
> capabilities actually used in this transaction.

Note that #1 can not be determined by the client unless the server
tells it. #2 will be defined by the lower of the HTTP version numbers
used by the client and the server. The quickest way for the client and
server to determine the "best" set of capabilities they can use is to
tell each other the maximum that eacn can use. From previous
discussion here, the spec wsa written with that in mind. If you don't
do things that way, then the client/server have to guess about what's
going on.

My vote for what it should say:

	HTTP servers SHOULD send the minor number of the highest HTTP
	version they accept with the same major number as the request. 

Clearly, if it's dealing with a client or proxy that doesn't handle
HTTP version numbers higher than the number on the request, it should
send the number on the request. Hopefully, this situation will be
rare.

> A well designed 1.1 server will not simply send 1.1 transactions to
> 1.0 clients under the assumption that the client will ignore headers
> it does not understand.  Instead a good 1.1 server will attempt to
> simulate the 1.1 functionality to the extent possible.  It might,
> for example, replace ETag with a Last-Modified-Date or
> Cache-control: max-age with Expires.  In short, it will craft 1.0
> headers to do the best it can.

I suspect this behavior would have a negative impact on 1.1 clients
sitting behind a 1.0 proxy. Possibly it's the other way around; I
haven't given a lot of attention to the proxy side of things.

	<mike

Received on Tuesday, 14 January 1997 10:29:44 UTC