Re: #300: Define non-final responses

On Sun, Jul 17, 2011 at 07:51:45PM -0700, Roy T. Fielding wrote:
> On Jul 17, 2011, at 6:19 PM, Adrien de Croy wrote:
> 
> > For an intermediary, Upgrade + 101 needs to be handled like CONNECT + 200.
> 
> No.  Look, I don't know how any of you got the impression that Upgrade
> is a request to turn into a tunnel, but that simply is not the case.
> It cannot be implemented that way.  Please don't try.  You are not supposed
> to upgrade the connection if you don't know how to upgrade the connection.

Roy, the example in RFC2616 says "switching to a real-time, synchronous
protocol", which clearly suggests so. Once again, it is possible that people
have been using 101 for the wrong thing, but we should admit that the wording
used in the spec makes it obviously valid.

We can't write specs by playing with words and waiting for users to get
trapped. The spec was written in a way that unambiguously pretends to
upgrade to whatever protocol and which does not suggest at all that another
final HTTP response is coming, quite the opposite instead. Now we must admit
that it's being used how it has been understood.

Concerning the use of OPTIONS vs GET to establish a tunnel with the server,
it was mentionned nowhere either, and more precisely, nowhere it is said
that 101's semantics vary depending on the method. The earliest example of
OPTIONS we can find is in RFC2817.

At least if such specific semantics exist, we must now document them, and
it is even more urgent because WebSocket is close to be released, it's not
too late to adjust some things there.

Willy

Received on Monday, 18 July 2011 05:29:28 UTC