On Sun, 10 Aug 1997, Klaus Weide wrote:

> On Sun, 10 Aug 1997, John Franks wrote:
> > 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.

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

I stand corrected.  There does exist at least a hypothetical example
where the "capability semantics" of the version header can be of use.
The functionality seems very limited given the problems it has caused
and the existence of an OPTIONS header which might be better suited for
the purpose, but at least this semantics is not intrinsically  useless.

Perhaps it would be helpful to have a sentence in the specification
saying "The capability semantics of the response version header is
intended (solely?) for the benefit of clients which wish to implement
certain features not compatible with the HTTP version with which they
are conditionally compliant."  Had I been aware of this I would not
have claimed it had no discernible use.

John Franks 	Dept of Math. Northwestern University

Received on Sunday, 10 August 1997 16:05:11 UTC