W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997


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>
Message-Id: <Pine.SUN.3.95.970810163638.27651F-100000@xochi.tezcat.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4147
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.)

Received on Sunday, 10 August 1997 15:18:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC