Re: HTTP version number

> So under the current scheme, with 1.0 software in the request chain
> undetectable, even if 95% of the software is 1.1, the service author
> _will still have to guess_ which protocol elements can be safely used
> in a response, as the response may go to some ancient 1.0 client.

No.  All 1.1 elements which are not specific to the nearest-neighbor
in the communication chain are already safe to be used in a response
to any 1.0 client.  We cannot introduce unsafe elements to the
protocol until we are willing to change the version to 2.0, which,
as I said before, cannot be done until we have deployed the
immediate infrastructure present in 1.1.

> The current scheme uses the version numbers in requests and responses
> to indicate capabilities of the immediate connections in the chain.
> Yet, AFAIK, all the proposed 1.1 mechanisms that act on immediate
> connections, like persistent connections, have their own headers to
> signal capabilities, so they won't need the version numbers in the
> first lines of the requests and responses.

We cannot send a 1xx Informational message to a 1.0 client and there is
nothing other than the HTTP-version number to indicate that.  In any
case, the version rules are meant to be generic and not restricted to
the scope of changes currently on the table for 1.1.

> I propose use of the version number in the request-line to indicate
> the _minimal_ protocol version used in the request chain.

No, that is not acceptable to me.  It prevents forward progress and
efficient introduction of protocol-upgrading proxies solely for the
purpose of introducing incompatible changes to the protocol without changing
the major version number.


 ...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 Saturday, 16 March 1996 00:37:04 UTC