- From: Klaus Weide <kweide@tezcat.com>
- Date: Sun, 10 Aug 1997 17:16:59 -0500 (CDT)
- To: John Franks <john@math.nwu.edu>
- Cc: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
On Sun, 10 Aug 1997, John Franks wrote:
> When the version number is really representing the "capability of the
> server" and is not equal to the version of the response, I have yet to
> see a concrete example of how it might be used, if neither client nor
> server is buggy and RFC 2145 is complied with.
>
> I would like to hear of a SINGLE hypothetical or real example of how
> the response version header can be used when it is really representing
> "capability of the sender", that is, when the minor version number of
> the response is strictly greater than the minor version number of the
> request (so the response is of a version lower than the server is
> capable). Such an example should assume any clients, servers and
> proxies involved are not buggy and are unconditionally compliant with
> RFC 2145.
Assume a client which is compliant with protocol version 1.N, and which
additionally implements some (but not all) features of protocol version
1.M where M > N. Assume further that the client wants to use a feature F
of 1.M which requires that the next-hop server is (at least) 1.M. The
client cannot send HTTP/1.M in a request since it is not compliant with
1.M. But once it has received a HTTP/1.M response from a server, it
will know that it can use F in communicating with that server.
A more concrete example, for N=0 and M=1:
A client implements HTTP/1.0 and in addition can do chunked *en*coding
according to HTTP 1.1. In order to upload something with
"Transfer-Encoding: chunked", it first has to know that the server
will understand it, and the only currently defined way how the client can
know this is through a HTTP/1.1 response.
Such an "enhanced 1.0" client will never *receive* chunked content from
a 1.1 server, but I believe that is an orthogonal issue. A 1.1 server is
required to to able to receive and decode "chunked", whether the client
is 1.0 or 1.1. (As it happens, for this example a client would have to
either violate the wording in RFC 1945 about content-length in requests or
send a meaningless content-length and violate a RFC 2068 requirement, but
there may be better examples where no such violation occurs.)
Klaus
Received on Sunday, 10 August 1997 15:18:00 UTC