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


From: John Franks <john@math.nwu.edu>
Date: Sun, 10 Aug 1997 10:20:56 -0500 (CDT)
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Cc: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <Pine.SUN.3.96.970810095022.6346C-100000@hopf.math.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4140
On Sat, 9 Aug 1997, Roy T. Fielding wrote:

> >It is specious to say that a 1.1 proxy can send a 1.0 version number
> >because then it becomes a 1.0 proxy.  What is really happening is that
> >the proxy is lying in its version header because that is the only way
> >it can request the response it wants from the server.  This is one
> >example of a flaw in the version header design: a proxy may sometimes
> >need to lie about its capabilities in order to get the response it
> >wants.
> What flaw?  The proxy is lying because it doesn't want the capabilities
> required of an HTTP/1.1 proxy.  If it had those capabilities, it wouldn't
> need to lie, nor is there any reason for a fully-capable proxy to lie.
> As I explained before, those requirements exist for the *benefit* of
> proxies.

One concrete example:

A 1.1 proxy cannot request an unchunked
response from a 1.1 server without violating RFC 2145.  So far I
have seen two responses to this, 1) It's a feature not a bug, and
2) Become a 1.0 proxy and send a 1.0 request.

Neither of these is a reasonable answer.  There are many valid reasons
a 1.1 server might sometimes want a 1.0 response (e.g. to reduce
de-chunking overhead if the response is only going to be passed to a
1.0 client).  Answer 2) is a clear violation of RFC 2145.  The current
spec is flawed because an implementor is required either to forgo some
proxy funcitionality or to lie and violate RFC 2145.

This problem will be exacerbated as we add additional transfer encodings
and move to versions 1.x, with x > 1.

> Without these versioning semantics, the
> entire HTTP design collapses and we will never be able to improve HTTP,
> not even with a major version change, except via an external indicator
> on the URL scheme or DNS to indicate a new protocol can be used.

Can you back this statement up?  Suppose the semantics were that the
request version header indicated the desired response version
(usually, but not always the highest version the requestor is capable
of) and the response version header indicated the version of the
response (usually the minimum of the request version and the
responder's capability).  Can you give some concrete examples of
how "the entire HTTP design collapses" with this semantics?

John Franks 	Dept of Math. Northwestern University
Received on Sunday, 10 August 1997 08:22:29 UTC

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