W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: Call for Closure - HTTP response version

From: John Franks <john@math.nwu.edu>
Date: Tue, 14 Jan 1997 08:55:02 -0600 (CST)
To: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>
Cc: cuckoo.hpl.hp.com@http-wg.uucp, www-talk@www10.w3.org
Message-Id: <Pine.SUN.3.95.970114082158.17107A-100000@hopf.math.nwu.edu>
On Mon, 13 Jan 1997, Roy T. Fielding wrote:
> 
> Although this is not so evident from the changes we included in
> HTTP/1.1 vs 1.0, the versioning design was intended to allow any 1.b
> client to "test the waters" with a 1.a request before using a 1.b request
> on a given server.  This allows a client to deal with the situation where,
> even though the protocol designers intended the protocols to be compatible,
> something about them or the existing applications makes them incompatible.
> That robustness would be broken if the server simply mimicked the request
> version.
> 

This only confuses me more.  Is there anything in the spec which
suggests this asymmetry in HTTP version for client and server?
Are you really suggesting that an HTTP/1.1 server must always give
the 1.1 version header to "advertise its capabilities", but that a
client might normally lie on its first transaction to "test the 
waters"?   Presumably if the client finds it is talking to a 1.0
server it will continue to lie about its capabilities.

As I read the spec, whatever the client can do with the version
header the server can also do.  This makes the scenario you suggest
quite problematic.  If a 1.1 client "tests the water" with a 
1.0 version header and a 1.1 server sends a 1.0 version number to
1.0 clients then when that client and server communicate they will 
never make use of 1.1 features.

> 
> The HTTP-Version is not a "single field", so arguments suggesting that
> there be a separate field for "capability" are groundless.  The major
> version defines the message format and the minor version defines the
> capability within that format.
>

There are two quite distinct pieces of information that in principle
might be conveyed by a version header: 1) the capabilities of the
server which are available for future transactions, and 2) the
capabilities actually used in this transaction.  Blurring the
distinction between the two is the cause of all the difficulty with
the version header in the current spec.  The spec can say the header
reflects 1) or it reflects 2), but it should not say there is no
difference between the two, or the differences are irrelevant.

A well designed 1.1 server will not simply send 1.1 transactions to
1.0 clients under the assumption that the client will ignore headers
it does not understand.  Instead a good 1.1 server will attempt to
simulate the 1.1 functionality to the extent possible.  It might,
for example, replace ETag with a Last-Modified-Date or 
Cache-control: max-age with Expires.  In short, it will craft 1.0
headers to do the best it can.  

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu
Received on Tuesday, 14 January 1997 11:20:15 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:26 EDT