Re: #300: Define non-final responses

On Sun, Jul 17, 2011 at 07:57:19PM -0700, Roy T. Fielding wrote:
> On Jul 17, 2011, at 2:48 PM, Willy Tarreau wrote:
> > Roy, this is not how I read RFC2616 :
> 
> Please read the section on Upgrade.

OK I found the point you mention :

  "the first action after changing the protocol MUST be a response to
   the initial HTTP request containing the Upgrade header field."

So this should be repeated in the 101 section, and we should probably
suggest that depending on the upgraded protocol, either the response
might be empty, or the server might need more info from the client in
order to respond.

One example is TLS : if we want the server to respond to the client,
it is necessary that the client can send a bit of information to the
server such as the session ID or a list of supported ciphers.

> > The term "immediately after the empty line which terminates the 101 response"
> > is pretty clear to me : HTTP ends after the 101 response, and immediately
> > after it, it is the next protocol. So there clearly is not any other HTTP
> > response after 101. It may not be how you designed it 12 years ago, but it
> > is how it's documented and how people have been using it. WebSocket is even
> > relying on this in the handshake.
> 
> If WebSocket relies on broken behavior, in spite of the many times that I have
> posted the correct handshake, then someone should fix WebSockets.

At that point it relies on *documented* HTTP behaviour. However there was a
discussion on using GET vs OPTIONS, and the rough consensus was that since
there was no perceivable benefit in switching to OPTIONS, it would remain
on GET unless some new element was brought in to change it. While I was more
in favor of using OPTIONS so that we can more easily get rid of the dumbest
transparent proxies, I really do not see any incompatibility with *documented*
requirements.

Willy

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