W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: HTTP response version, still

From: Shel Kaphan <sjk@amazon.com>
Date: Sat, 21 Dec 1996 21:37:34 -0800 (PST)
Message-Id: <199612220537.VAA17258@anaconda.amazon.com>
To: Arnoud Galactus Engelfriet <galactus@htmlhelp.com>
Cc: www-talk@www10.w3.org, http-wg%cuckoo.hpl.hp.com@hplb.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 Saturday, 21 December 1996 21:48:26 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:19 EDT