W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2008

[whatwg] Simplified WebSockets

From: Shannon <shannon@arc.net.au>
Date: Mon, 13 Oct 2008 15:32:17 +1100
Message-ID: <48F2CF51.4070807@arc.net.au>
I have written an implementation of a websocket client and server for 
testing my proposed protocol. Testing in the real world has provided me 
some good information on what works and what doesn't, particularly in 
regards to relaying through public anonymous proxies. Those wishing to 
experiment with variations of the protocol or with particular services 
may find these scripts useful.

http://www.warriorhut.org/whatwg/

The scripts connect to each other with a lightweight HTTP handshake then 
asynchronously send a user-defined amount of data. The purpose is to see 
how common HTTP proxies handle asynchronous connections (with client and 
server sending simultaneously). These scripts are not an implementation 
of the current draft spec, but an alternative proposal I raised earlier 
due to what I see as major design flaws in the draft spec.

It should be noted that the spec outlined does not use the onmessage 
interface proposed in the WHATWG draft spec, but rather a more standard 
read() and write() as implemented by most other languages (ie, 
websocket.read(512) returns up to 512 bytes of buffered data from the 
socket). This will make porting traditional client code from other 
languages much easier.

The underlying design principles behind this proposal are:

* Don't send author defined data (except for host) to any service that 
has not yet identified itself as a websocket.
* Do not frame, encode or restrict any data sent after the websocket 
upgrade. It should be possible at this point for any type of server to 
take over the connection transparently.
* Do not require any headers not absolutely essential to creating a 
connection. Let the client and server handle cookies, origin or 
authentication as the author chooses.
* Do not hardcode port numbers, this is not really as secure or useful 
as the spec authors seem to believe (port 81 is quite commonly used as a 
webmail port for example).

I have not addressed TLS as this is difficult to program. In theory 
though it should only require Upgrade: TLS in place of, or prior to, the 
Upgrade: Websocket header.

Shannon
Received on Sunday, 12 October 2008 21:32:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:06 UTC