RE: Call for Closure - HTTP response version

Sorry for the inconvenience of broadcast...

UNSUBSCRIBE www-talk@www10.w3.org

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 
attention!

Thank-you, Pat

----------
From:  Roy T. Fielding[SMTP:fielding@liege.ICS.UCI.EDU]
Sent:  Monday, January 13, 1997 7:20 PM
To:  http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com; www-talk@www10.w3.org
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 
servers
> 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 
client
> 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 
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.

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 
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.  Were it not for that fact, there 
would
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, 
and
I know that is what I intended when I wrote it two years ago, so I 
don't
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 
"consistent
with what you would expect".  It is easier to change expectations 
than
it is to change HTTP/1.x.

 ...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 Tuesday, 14 January 1997 11:23:05 UTC