- From: Shannon <shannon@arc.net.au>
- Date: Mon, 13 Oct 2008 15:32:17 +1100
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