Re: Call for Closure - HTTP response version

> This only confuses me more.  Is there anything in the spec which
> suggests this asymmetry in HTTP version for client and server?
> Are you really suggesting that an HTTP/1.1 server must always give
> the 1.1 version header to "advertise its capabilities", but that a
> client might normally lie on its first transaction to "test the 
> waters"?   Presumably if the client finds it is talking to a 1.0
> server it will continue to lie about its capabilities.

There is asymmetry -- only the client can send the request,
and thus initiate communication.  There is no asymmetry in terms of the
versioning requirements, since both sides SHOULD send the highest
minor version supported.  The above is not intended to be a "normal"
procedure.  Nevertheless, it works if and only if the server does not
mimick the client version.

> As I read the spec, whatever the client can do with the version
> header the server can also do.  This makes the scenario you suggest
> quite problematic.  If a 1.1 client "tests the water" with a 
> 1.0 version header and a 1.1 server sends a 1.0 version number to
> 1.0 clients then when that client and server communicate they will 
> never make use of 1.1 features.

Correct, which is why it says "SHOULD" instead of "MAY".

> 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.  Blurring the
> distinction between the two is the cause of all the difficulty with
> the version header in the current spec.  The spec can say the header
> reflects 1) or it reflects 2), but it should not say there is no
> difference between the two, or the differences are irrelevant.

The capabilities used in the transaction are not defined by any
version number.  All HTTP/1.1 header fields are valid HTTP/1.0 header
fields, and thus HTTP/1.0 capabilities.  There is no mechanism for tracking
individual extensions because attempting to do so would increase the
bytes sent to an unacceptable degree.  The only thing that matters is
whether or not the recipient will understand a particular extension,
which is what you get in the minor version number to the extent that
the specification requires such understanding.  Whether or not the message
contains extensions that were first well-defined in HTTP/1.1 is simply
not relevant to understanding the content of the message.

> 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.  

On the contrary, it will send both in the HTTP/1.1 response.  There is
absolutely no reason for an HTTP/1.0 client not to implement Cache-Control
and the functionality that uses Etag values.

 ......Roy

Received on Wednesday, 15 January 1997 04:19:49 UTC