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.