Re: Server response version number

I do believe this has been discussed before, particularly around the
time of the LA IETF meeting (on the mailing list).  In any case, this
is both my personal recommendation as an implementor and the intention
of what is written in both HTTP specs regarding the HTTP-version.

The HTTP-version of a message represents the protocol capabilities
of the sender AND the gross-compatibility (major version number) of
the message being sent.  This allows a client to use a safe (HTTP/1.0)
subset of features in making a normal (HTTP/1.1) request, while at
the same time indicating to the recipient that it is capable of supporting
full HTTP/1.1 communication.  In other words, it provides a tentative
form of protocol negotiation on the HTTP scale.  We do this because it
allows each connection on a request/response chain to operate at its best
protocol level in spite of the limitations of some clients or servers
that are parts of the chain.

The HTTP-version provided by the server should be the highest minor
version supported by that server within the same major version as sent
by the client (i.e., a server today which is at least conditionally compliant
with HTTP/1.1 should always send HTTP/1.1 in its responses, even when it
is only using the features of HTTP/1.0).  This is required to work because
all HTTP/1.x protocols share a base level of compatibility (if they didn't,
they wouldn't be called HTTP/1.x).  Worries about some clients bombing on
receipt of "HTTP/1.1" in the Status-Line are pointless -- HTTP cannot be
extensible if it is always tied to the mistakes of the lowest common
denominator of client hacker; it is better to force those clients
to be upgraded than to hamstring the rest of the world forever.

The answer to the question "Why doesn't the spec require servers to always
send HTTP/1.1 or to always send the client's version?" is quite simple:
the specification only governs an implementation when it sends "HTTP/1.1".
If the server sends some other version, then it is obeying the requirements
of some other protocol, over which the HTTP/1.1 specification has no
relevance.  If the server decides to switch between the two at random,
then I would say that the server is randomly compliant with HTTP/1.1,
and the results in terms of robustness are equally random.  However, it
probably would not adversely affect the communication, since the really
important half of the HTTP-version decision is that the client always
send its best version.

I am willing to live (unhappily) with a server that switches from HTTP/1.1
to HTTP/1.0 when it is used as a proxy because it is unlikely that
any current browser will treat an origin server and a proxy server as the
"same server", because we will fix or remove that proxy relatively soon
(probably before any significant HTTP/1.1 browsers are deployed), and because
the likelihood that such a protocol downgrade will actually result in
communication problems on later requests is quite small.  I would be less
inclined to support a server which downgraded based on the client version,
since I see the server's version as a guarantee of good behavior, and that
guarantee is a good thing even when the client doesn't understand it.


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

Received on Monday, 21 October 1996 20:39:38 UTC