You seem to have figured it out. You just don't agree with it.
> 2) It is flawed,
No it isn't.
> 3) It greatly complicates some kinds of proxy design, and
No it doesn't.
> 4) It has no discernible function.
Bullshit.
>We can probably live with these problems, but one price we will pay
>is that this aspect of the protocol will get rehashed at least every
>six months as new people wrestle with what ought to be a trivial part
>of the protocol.
The versioning semantics are central to the design of HTTP to support
future standard extensions to the protocol, including the extensions
from HTTP/1.0 to HTTP/1.1. It is this design that allows us to introduce
things like transfer encoding, 1xx responses, and PEP/Mandatory header
fields. The HTTP-version is the only field which is required NOT to be
forwarded blindly by any HTTP proxy, regardless of version. ALL of those
rules I listed yesterday depend on the minor protocol version indicating
the *capability* of the sender. 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.
The fact that some people seem incapable of understanding that should
not require the WG to endlessly cycle through the same discussion.
The fact that some people think all version numbers have the same purpose
is not an excuse to dismantle a working design. The fact that some
implementers choose not to read the specifications before attempting
to write an implementation does not justify changing the specification
to correspond to their bugs which will clearly never be able to
interoperate with future versions of the protocol.
>> > This is because hop-by-hop implies a
>> > 1.m proxy talking to a 1.m server can only ask for a response with
>> > EV == 1.m, even though it may acting on behalf of a 1.n client with
>> > n < m.
>>
>> Yes, that is the cost of progress. In order to take advantage of more
>> advanced protocol features, a proxy must make up for its weaker clients.
>> There is no way around it. In fact, that should be considered a valuable
>> feature by anyone who purchases a proxy.
>>
>
>But later you say the opposite:
>>
>> In general, there is no requirement that a client (including a proxy)
>> send a 1.1 request instead of 1.0. There can't be, since then the
>> client would be using the 1.0 protocol and not HTTP/1.1. Thus, the
>> concern you mention is unfounded.
How you can think that those two statements oppose one another is beyond
my understanding. The only difference between an HTTP/1.0 proxy and an
HTTP/1.1 proxy is that the latter declares its conformance with the 1.1
specification. Every feature of HTTP/1.1 is also an HTTP/1.0 feature.
Every header field defined in the HTTP/1.1 specification is also an
HTTP/1.0 header field. And yes, that also applies to Transfer-Encoding
(try it and see for yourself). Whereas an HTTP/1.1 server is required
not to send a Transfer-Encoding to an HTTP/1.0 client, an HTTP/1.0
server can do so at will. Granted, it would be stupid, but it wouldn't
make it any less stupid by adding an "entity version" to the message.
An HTTP entity is completely described by the entity-header fields that
are included with the entity. *Any* change to the protocol that requires
understanding of a particular aspect of the entity, which is not defined
by an existing version of the protocol, will also require incrementing
the minor protocol version. Adding an "entity version" would be no more
revealing to the recipient than allowing a mandatory header field to be
passed on to an old client.
>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.
>The reason that the version header comes up again and again is not
>that difficult to understand. What implementors NEED to know in
>processing a transaction is the *version of that entity*, i.e. the
>lowest version number such that a client or proxy of that version can
>handle this entity. The current version header gives only an upper
>bound estimate for this number. It is a non-trivial (and potentially
>error-prone) task to calculate this entity version. If versions 1.x
>with x > 1 come into being this problem will get harder.
You must be talking about some other protocol, since none of those
statements are true about HTTP/1.1.
>Apparently the original design intent was that the major version
>number would be the "entity version" and the minor number would
>indicate capability. This is manifestly no longer the case.
The major version number indicates the message format, which is the
case and has always been the case. Look at an HTTP/1.1 message (any
valid message) and point out the part which is not valid HTTP/1.0
other than the HTTP-version field.
>There is substantial evidence that new implementors *expect* the
>version header of a response to contain the entity version (which they
>need and which the origin server knows) rather than a statement of
>capability. When they discover this is not the case (either by
>reading the spec or when something breaks) they are annoyed by the
>extra work, seemingly gratuitously created for them, and they come
>here to complain. This is unlikely to change anytime soon.
So, what you are telling me is that we should stop all work on improving
HTTP because some implementers are untrained savages, apparently reared
by animals in a jungle, and unable to read the English language presented
quite clearly in three separate RFCs. Personally, I think implementers
who don't think they already know more about the protocol than the
protocol's designers will have the sense to actually read what has been
written on the subject and implement accordingly. If they do so, I can
guarantee they will interoperate with other compliant implementations.
If they don't, there will be no interoperability, and thus no reason to
have a standard or waste time discussing it in this WG.
...Roy T. Fielding
Department of Information & Computer Science (fielding@ics.uci.edu)
University of California, Irvine, CA 92697-3425 fax:+1(714)824-1715
http://www.ics.uci.edu/~fielding/