Re: [hybi] Questions and comments on draft-hybi-thewebsocketprotocol-10

["Roy T. Fielding" <[e-mail]>]

On Jul 18, 2011, at 12:50 AM, Greg Wilkins wrote:
> On 18 July 2011 17:06, Mark Nottingham <[e-mail]> wrote:
>> 1) I missed the end of the handshake saga; can someone speak to why GET was chosen over, say, OPTIONS? Roy seems to have strong feelings about that (see recent discussion on HTTPbis).
> 
> I think we went with GET because Roy was not able to well communicate
> his concerns.   He's done a better job in the recent thread in
> httpbis, and I now understand that he is concerned about the
> outstanding semantic GET.   However I still don't understand why he
> thinks OPTION is any better, as it still is a request that requires a
> semantic response.   

OPTIONS is a request for the communication options on the connection
for the target resource.  It is not a request of the resource itself;
it is a meta-request to be processed by the handler of that resource.
It should be obvious why completing the WebSocket handshake is a valid
response to that request if the Upgrade succeeds.  In any case, see

  http://www.ietf.org/mail-archive/web/hybi/current/msg05743.html
  http://www.ietf.org/mail-archive/web/hybi/current/msg05750.html
  http://www.ietf.org/mail-archive/web/hybi/current/msg05751.html

to wonder at how I failed to communicate my concerns.

> In either case I think that websockets should be
> free to define an implicit response (eg 204 No Content) is represented
> by a successful handshake.

GET has specific semantics regarding the state of the resource that is
the target of this request.  If you want to use HTTP over the Web's
standard port, then you are subject to HTTP's definitions.  It is not
that difficult for WebSocket to correctly use GET, as Henrik Frystyk Nielsen
just explained on httpbis, if the target resource is meaningful and not
some generic entry point (like those stupid SOAP gateways).

There is no need for an implicit response of "no content" if the result
of making the WS request via HTTP has application-level semantics that
are equivalent to a response to GET after WS takes over the connection.
For example, if the request results in an asynchronous event feed (the
feed named by that URI), joins the user to a running game (named by
that URI), connects the client to the video stream corresponding
to the eyes of a mini robot (named by that URI), etc.  WebSockets
merely needs to state that the client's HTTP request remains
outstanding after the 101 is sent and the WebSockets application is
responsible for handling and responding to that request in accordance
with the semantics of the target resource.

If that's too much to ask, WebSockets is welcome to define its own
unique method, use OPTIONS (and let the framing be the response), or
use a different port and a different protocol for the handshake.

....Roy