- From: Shel Kaphan <sjk@amazon.com>
- Date: Sat, 21 Dec 1996 21:37:34 -0800 (PST)
- To: galactus@htmlhelp.com (Arnoud "Galactus" Engelfriet)
- Cc: www-talk@www10.w3.org, http-wg@cuckoo@hpl.hp.com
Arnoud Engelfriet writes: > > Wouldn't it be better to *only* give 1.1 responses if the *request* was > also done in HTTP/1.1? > > Galactus > The question seems to boil down to what the significance of the version number in the header is. Since it should be possible for (most) HTTP 1.1 headers to exist without harm in a message labelled HTTP/1.0, then it matters very little what version is in the label, so long as the other headers are interpreted independently of the (minor) version number in the label. A 1.1 server can't use aspects of the protocol in its communication with a 1.0 client that cannot be understood in 1.0, such as chunked transfer encoding. However, a 1.1 server should be allowed to add such headers to the response as should not confuse a 1.0 client. So, one important function of the version number in a _request_ is to limit the response to that part of the protocol which is at least backward compatible with the request, according to our rules of engagement (that unknown headers be ignored (clients) and passed through (proxies)). The version number in the request identifies the capabilities the client wishes to expose, but since that client may be a proxy, and may be a proxy for another client with a higher version number, it would be nice if the version number of the proxy did not limit a server to responses without anything in them pertinent to higher versions than that of the immediately adjacent client. (The protocol version number in a message is a point-to-point aspect of the procotol, not end-to-end). In other words, it would be nice if a 1.1 client could get a message with 1.1 headers (and semantics) even if speaking to the server through a 1.0 proxy. The question then becomes, how should a message from a 1.1 server to a 1.0 client be labelled? We know that it may have backward compatible 1.1-level headers in it, but is that enough reason to label the entire message as 1.1? Intuitively it makes sense, but on the other hand, a 1.0 proxy as in the above example would return 1.1 headers if they were given it by a 1.1 server, and the 1.0 proxy would be unlikely to identify its responses as HTTP/1.1. My conclusion is that the version number in the response doesn't matter much. The important point is elsewhere: HTTP 1.1 servers have to provide backward compatible responses when they receive requests labelled HTTP 1.0. However, they should not be restricted from adding headers only defined within HTTP 1.1 in those responses. Similarly, HTTP 1.1 clients that do not know the version of a server should give backward compatible requests, or be prepared for anomolous results. Since there _are_ some aspects of HTTP 1.1 that are incompatible with 1.0 (chunked transfer encoding for example) it is important to clarify which aspects of 1.1 are backward compatible and which are not. It is unfortunate that there seems to be some software around that won't work simply due to the version number in the response header. --Shel
Received on Sunday, 22 December 1996 00:37:46 UTC