- From: Klaus Weide <kweide@tezcat.com>
- Date: Mon, 11 Aug 1997 12:50:22 -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:
> 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
> john@math.nwu.edu
Instead of
"features not compatible with the HTTP version with which they
are conditionally compliant",
that should be
"features compatible with a HTTP version with which they are
not conditionally compliant".
As for the (solely?) - Roy Fielding wrote on Saturday in
<9708090425.aa26104@paris.ics.uci.edu>:
> Unlike the server, a user agent cannot easily know in advance that a
> given server supports a given capability. If a future incarnation of
> this WG, or some fool programmer who believes that adding incompatible
> enhancements to the protocol can be done on their own outside the WG,
> manages to screw up the protocol such that it is unsafe for a client
> to send its own highest version on the first request, the fact that the
> server will respond with its highest minor version allows the client
> to start with a lower-version request and improve its later requests
> in safety.
Does that count?
Klaus
Received on Monday, 11 August 1997 10:51:29 UTC