Re: HTTP version number

> General comments on section 3.1:
> 
> 1) Is there any rationale for the rules in Section 3.1?  

Yes.  The rules exist to assist deployment of multiple protocol revisions
and to prevent the HTTP protocol designers from forgetting that deployment
of the protocol is an important aspect of its design.

They do so by making it easy to differentiate between compatible changes
to the protocol and incompatible changes.  Compatible changes are easy
to deploy and communication of the differences can be achieved within
the protocol stream.  Incompatible changes are difficult to deploy because
they require some determination of acceptance of the protocol before
the protocol stream can commence.

The Upgrade header field reduces the difficulty of deploying incompatible
changes by allowing the client to advertize its willingness for a better
protocol while communicating in an older protocol stream.  However, we
need a 1.1 standard in order to use Upgrade.

> 2) I'm not sure that I really like the weak requirements for
> translation by proxies that are in the draft spec now: these
> requirements will basically shift the burden of making things
> interoperable from proxy authors to httpd and CGI authors, and there
> are a lot more CGI authors than proxy authors.

CGI authors will have to do better than they do now in order to be
HTTP compliant.  That would be true for HTTP/1.0 as well, since many
CGI scripts are non-compliant with anything HTTP.  How the server is
implemented is not our concern -- what we care about is the interface
on the HTTP side, and that needs to be HTTP compliant regardless of
who or what is responsible for generating the message.

> 3) With proxies being allowed to upgrade and downgrade the minor
> version number, it seems that the server, it it gets a 1.1 request,
> will not be able to find out if there are any 1.0 applications in the
> request chain.

Yes.  We have talked about adding that information to Forwarded, but
we also need to come up with a more compact encoding for that header.
In any case, the recipient doesn't need to know about 1.0 applications
in the request chain if there are no incompatible changes in the
request chain applying to more than just the immediate connection.

> 4) So the server has to make things interoperable, but it does not
> even know the capabilities (versions) of the software it is serving
> to!  So, for example, if the server uses a 1.1 Cache-Control header,
> it must always include a 1.0 Expires header.

Yes.  There is no way to avoid it without requiring a major protocol
change, and thus a major version number change.

> 5) Wouldn't things be easier if we did a major version number change
> and defined HTTP/2.0 instead of HTTP/1.1?

No, that only shifts the burden from the protocol designers to the
implementors and deployment.  We should not make a major protocol
change when we can solve 95% of our problems with a minor change,
particularly since that minor change includes the primary deployment
mechanism for future major changes.

We can, quite easily, change what we are calling HTTP/1.2 + PEP + "cookies
done right" into the label "HTTP/2.0".  However, we need the most important
issues in front of us (Host, Caching, Persistent Connections) to be easily
deployed.  That means we must have an HTTP/1.1 proposed standard before
making any incompatible changes.

> 6) In summary, I suspect that the version rules will need to be
> seriously reviewed.

I would hope that the entire document gets "seriously reviewed".
However, changing the version rules would be a mistake, since it would
only make it easier on the protocol designers and make it harder to
deploy implementations.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Sunday, 10 March 1996 22:59:18 UTC