RE: Call for Closure - HTTP response version

Sorry for the inconvenience of broadcast...


PLEASE!!!!!  I have tried EVERYTHING to get off this maillist!  I will 
soon bounce all messages to me.  Maybe that will get the list server's 

Thank-you, Pat

From:  Roy T. Fielding[SMTP:fielding@liege.ICS.UCI.EDU]
Sent:  Monday, January 13, 1997 7:20 PM
Subject:  Re: Call for Closure - HTTP response version

Alexei wrote:
> On the flip side, it is not true either that 100% of HTTP/1.0 
> will respond correctly to a HTTP/1.1 request. Again, this number is
> very small. If it were not, it would make sense for a HTTP/1.1 
> to send HTTP/1.0 requests, and switch to HTTP/1.1 when it finds a
> compatible server. In this scenario, it would be neccessary for
> HTTP/1.1 servers to always use HTTP/1.1 in the response.

Exactly.  Although this is not so evident from the changes we included 
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 
on a given server.  This allows a client to deal with the situation 
even though the protocol designers intended the protocols to be 
something about them or the existing applications makes them 
That robustness would be broken if the server simply mimicked the 

The Upgrade header field provides a similar purpose for incompatible
protocols, but its operation is quite different.

The HTTP-Version is not a "single field", so arguments suggesting 
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.  Were it not for that fact, there 
be no reason to have a separate major and minor version.  Personally,
I cannot conceive of any other interpretation of what is in the RFC, 
I know that is what I intended when I wrote it two years ago, so I 
understand the need for this debate unless people want to change the
intended design of HTTP/1.x.  If so, I think it is incumbent on those
people to prove that the change is necessary and not simply 
with what you would expect".  It is easier to change expectations 
it is to change HTTP/1.x.

 ...Roy T. Fielding
    Department of Information & Computer Science 
    University of California, Irvine, CA 92697-3425 

Received on Tuesday, 14 January 1997 11:23:05 UTC