- 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>
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 john@math.nwu.edu
Received on Sunday, 10 August 1997 08:22:29 UTC