Comments Blog About Development Research Sites

Websocket servers with Chrome

Jun 11, 2010
A websocket is a spiffy new feature to be introduced with HTML5. Remember how I wrote about COMET a while ago? Well, forget all the hacks you used to need for it: with websockets you can create a lightweight persistent connection to any service.

This is great for chat applications, but even better for interactive games and dynamic sites where low latency and low bandwidth are essential. It should come as no surprise then that I have been looking into writing a WebSocket server in JAVA - based on some of my code for GaMED in fact.

After breaking my head on this for a day and a half, I finally discovered why Chrome would not connect to my WebSocket server: it uses an old draft of the websocket API! The latest "official" version is draft 76 (with an updated version to be found here). Chrome however apparently uses draft 75 and rejects the headers that confirm to an up-to-date specification.

What is worse, only the very latest versions of Chrome seem to give any useful status information, although these too are limited to "Unexpected response code:101" when in fact the WebSocket-Location field is the problem.

Long story short: try updating Chrome & downgrading your implementation if it should all work fine but for some reason doesn't :]

On a sidenote: the development release of Chrome does appear to use the latest specification, or something rather close to it. You can find it here.

Update, June 12th
On closer inspection, it appears Chrome development builds (currently testing 6.0.427.0) still do not confirm to specification - either that or my implementation calculates an incorrect response, which is unlikely since it appears to confirm with all available examples on the web. Might just be better to wait for a few more months for the specification (and implementations) to mature.

For those interested, my WebSocket testserver is up at ws://

Update, June 13th
Latest Safari release I could find (5.0) also appears to support WebSockets, but at draft 75. Again, not much help there.

Update, June 13th
Fancy that: turns out converting a byte array to a String and back again adds (invisible) bytes, and Chrome's implementation did correctly reject the handshake response - mind you, it would have helped if it actually threw an error in this case - I found out by using WireShark to manually analyse the raw TCP packets send over my NIC, one hell of a way to do debugging but oddly effective. Long story short: after calculating the hash, don't append it to a response string but directly send the bytes over the socket as they appear.

Expect a cleaned up source for a JAVA based WebSocket server up in a few days.

FragFrog out!

New comment

Your name: