Re: [hybi] WebSockets

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

On Mar 30, 2009, at 7:12 PM, Ian Hickson wrote:

> On Mon, 30 Mar 2009, Roy T. Fielding wrote:
>>
>> It would be nice to have a list of use cases for why anyone would  
>> want a
>> Web page (as opposed to an installed client or client extension) to
>> provide two-way communication,
>
> Some sample use cases:
>
>  * GMail's built-in IM client
>  * Collaborative editing as seen in tools like Google Apps
>  * Multiplayer games
>  * Pages that monitor services, e.g. a wifi router's status page,  
> showing
>    up-to-date information about signal:noise ratios, etc.
>
> Personally the reason I want a WebSocket-like mechanism is so that  
> I can
> make my Web-based model railway control panel quicker. Right now every
> time I click anything it has to do a round-trip TCP connection to  
> the Web
> server to tell it to tell the computer running the trains to  
> perform the
> action, whereas what I really want is for the Web page to just have a
> direct connection to that computer. This would also allow the train
> controlling computer to give immediate feedback instead of having to
> tunnel messages back through a long-lived CGI script returning drip- 
> fed
> <script> blocks to an <iframe> over a long-lived HTTP connection.

Thanks.  Perhaps we should start a wiki somewhere to list the use cases
and then a protocol comparison table to see what use cases are satisfied
by each protocol.

>> and also why that two-way communication must be tunneled over the Web
>> ports in a way that deliberately intends to fool security-enforcing
>> intermediaries into thinking it is HTTP.
>
> For my use case (the trains) I'm fine with not doing any tunneling,
> however it turns out that a lot of sites block all but port 80 and  
> port
> 443 and yet people still want to use their IM clients. Right now Web
> applications like GMail are tunneling through ports 80 and 443 by  
> abusing
> HTTP; I think it would be much better to have them Upgrade to another
> protocol and leave HTTP for REST-like purposes.

A lot of offices put locks on the door and only give keys to their
employees and trusted contractors.  That is inconvenient for a reason.

> Note that the way WebSocket is designed, there's no deliberate  
> fooling;
> it's a straight up HTTP Upgrade attempt.

Not quite.  You can't place constraints on specific ordering of bytes
within WebSocket and then claim it is HTTP, because HTTP allows (and
sometimes requires) intermediaries to change or reorder those same
bytes in specific situations.  I don't buy the argument regarding
ease of implementation because it simply isn't robust to parse a
line-delimited protocol as if it were a fixed structure, again because
of the presence of those intermediaries over which you have no control.
Upgrade was specifically designed for this purpose and can just as
easily be implemented with a standard HTTP/1.1 OPTIONS or CONNECT
request.

The good thing is that, by initiating the connection with an HTTP
request to the same-origin server by hostname, WebSocket doesn't
suffer quite as much from the shared-IP security holes that are
present in web-based software that uses raw sockets.  However, it
could still be used to trigger arbitrary requests by intercept
proxies that don't understand that the connection has been upgraded.
A more secure design would require the use of CONNECT and then
forcibly encode the stream such that it can't be misinterpreted.

Alternatively, just use a different port and let the organizations
decide whether they want to allow such connections through their
own firewalls.

....Roy