How to enable WebSocket on Firefox

As you might know, WebSocket Draft-76 version is disabled in Firefox 4 and 5 due to security issues while it’s being supported in Chrome 12 and Safari 5. However, you can still enable WebSocket in Firefox 4 and 5 by opening about:config and setting the network.websocket.enabled and network.websocket.override-security-block preferences to true. Here’s more information and description on this: https://developer.mozilla.org/en/WebSockets

WebSocket.close is broken in Chrome?

According to the WebSocket Draft-76 spec, Wocket.close is supposed to do the following:

To close the connection cleanly, a frame consisting of just a 0xFF
byte followed by a 0x00 byte is sent from one peer to ask that the
other peer close the connection.

But, after a few tests, I don’t think that Chrome is doing anything when closed is called. I’m curious if I’m doing something wrong or if it’s a known bug.

WebSocket handshake and Content-Length

I was running some tests with Chrome against a WebSocket enabled server, and Chrome would close the connection during the WebSocket handshake with no errors or indication as what happened. After much debugging, and Googling, turns out that this is due to the missing “Content-Length” header missing in the draft-76 of WebSocket protocol. It’s also explained in WebSocket Wikipedia entry:

Unfortunately, a recent update to the draft (version 76) broke compatibility with reverse-proxies and gateways because the 8 bytes of data the client must send after the headers is not advertised in a Content-Length header, so the intermediates won’t forward that data until the handshake completes. And since the handshake needs those 8 bytes to complete, the handshake never completes and deadlocks. In current state of affairs, it’s not advisable to modify such intermediate components to support this non-standard HTTP behaviour because doing so would render the components vulnerable to HTTP smuggling attacks, since an attacker would just have to pretend trying to upgrade to the WebSocket protocol in a request to be able to send more data than the target plain HTTP server can parse, possibly bypassing some mandatory security filtering. It is not known if this recent breakage will be worked around in a new draft or not.