Re: Call for Closure - HTTP response version

Roy T. Fielding wrote:
> 
> > 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.  
> 
> On the contrary, it will send both in the HTTP/1.1 response.  There is
> absolutely no reason for an HTTP/1.0 client not to implement Cache-Control
> and the functionality that uses Etag values.

I would agree with this entirely.  ETag is easier to handle than dates
since it is a straight string comparison.  Therefore a 1.0 client may
choose to recognise ETag (and send If-Match et al headers) to gain the
advantage of this newly defined feature without having to implement
other things which are required by HTTP/1.1 (such as chunked transfers
and the intermediate reponses to put/post)

However, if a client is 1.1 capable but sends a 1.0 "test the water"
request and the 1.1 server then decides to lie about its version number,
could (should?) the server send the header: "Upgrade: HTTP/1.1"

RFC2068 says that Upgrade should be used for advertising support for
incompatible protocols - but I don't see any reason why it couldn't be
used for advertising support for later minor version HTTP protocols. 

Is there a reason why it shouldn't use this mechanism?

-- 
Stewart Brodie, Electronics & Computer Science, Southampton University.
http://www.ecs.soton.ac.uk/~snb94r/      http://delenn.ecs.soton.ac.uk/