[whatwg] Web Sockets

[Ian Hickson]

On Tue, 22 Jul 2008, Frode Børli wrote:
>
> 1. Allow pure TCPSocket using this method: var s = new
> TCPSocket("/tcpsocket.xml");
> 
> The tcpsocket.xml-file must have a structure similar to this:
> 
> <websocket>
>   <host>hostname/ip-address</host>
>   <port>portnumber</port>
>   <allow-origin>*</allow-origin>
> </websocket>
> 
> [...] port: any port

We can't do this, because it would allow cross-site scripting on shared 
hosts. (The server running on one port is not necessarily from the same 
user as the server running on another.)


> - Easy to adopt today on existing servers and can easily utilize for 
> example existing IRC-servers etc without modifications.

I don't know that it's that easy. We'd need to provide APIs for poking 
bytes, separate from poking text, and probably would need to provide an 
API to decide the encoding of each output string, etc. Reading would be 
even more complicated, since we'd have no framing, so you'd have to 
provide an arbitrary byte array, and then a bunch of methods for 
converting those to strings.

That sounds like far more complexity than I want to specify in HTML5.


> - Enables cross site usage (script on www.example.com can connect to 
> Yahoo by downloading www.yahoo.com/websocket.xml)

The current feature allows that too.


> - Requires access to place files on the targeted server - so it is not 
> possible by simple cross site scripting attacks.

Same with WebSockets.


> - A simple perl script can dynamically generate the xml-file above.

WebSockets do this without even the XML file. :-)


> - Allows connection to SMTP servers only if the server owner intends to 
> allow it.

Not necessarily, as noted above, since shared hosts means that different 
ports are owned by different people, even at the same IP.


> 2. WebSockets should use previous work from RFC 2817 
> (http://www.ietf.org/rfc/rfc2817.txt). Web servers such as Apache must 
> then be extended to support websockets, but it should be very easy for a 
> developer to start using websockets. It would not require an extra 
> application listening on a separate port, and it would by definition 
> work in a virtual hosting environment.

I'm not sure which part of RFC 2817 you intended to refer to. If you mean 
the TLS upgrade specifically, then we can't use that since 2817 doesn't 
provide a way to explicitly require a TLS connection from the page that 
creates the connection. Much better to have two separate protocol schemes 
and have one always require encryption.

Note that browsers don't use RFC 2817. It's not clear that servers would 
actually benefit from it either.


> Since the request is to an ordinary URL, the webserver will direct the 
> request to a file or script in the web root for the virtual host and 
> this script can decide to send an 426 Upgrade Required response, or it 
> can send 401 Unauthorised if the client sent the wrong Origin headers.

That doubles the number of HTTP roundtrips, which seems unnecessary.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'