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

[Greg Wilkins <[e-mail]>]

On 19 July 2011 14:49, Roy T. Fielding <[e-mail]> wrote:
> On Jul 18, 2011, at 12:50 AM, Greg Wilkins wrote:
>> I think we went with GET because Roy was not able to well communicate
>> his concerns.
> [...]
>  In any case, see [...] to wonder at how I failed to communicate my concerns.

Roy,
I didn't mean to imply that you didn't try to communicate your
concerns, nor that you were to blame for the failure of that attempt.
It may well be that I/we were not listening correctly.


> If you want to use HTTP over the Web's
> standard port, then you are subject to HTTP's definitions.

and that is something I fully agree with and have advocated long and
hard for in this WG.


> 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).

I believe that websocket usage will be just the same as other
webapplication usage in this regard.  Some will correctly reference
specific resources, while others will not.  I don't think the spec can
mandate against bad URI space design.


> 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.

Ok I think I'm getting you more now.   It is not that you want
WebSockets to give an immediate semantic final response to the GET
request, rather you don't want websocket to consider the 101 to be
that final response because it is by definition a non final response.
So you say that this could be resolved by the spec making it clear
that the event stream accesses by the ws handshake is semantically the
response to the handshake GET?

regards