Testing a socket.io application in the PROD environment for the first time, we found that while the xhr-polling transport (Ajax long polling) works, the websocket transport does not.
Looking at the data transmitted using Fiddler, I can see that the
UPGRADEhappens and- the first message from the server (5 bytes gross) arrive at the client.
- The client then sends a couple of messages to the server, which normally result in server->client messages
But those server->client messages never arrive (I'm not even sure if the client->server messages arrive on the server side). Eventually (after about 6 seconds), Fiddler reports a
Read from Server failed...
and a new connection gets established, as unsuccessful as the first one.
Our setup looks something like this:
Internet -> Firewall -> BIG-IP 3600 (terminates SSL) -> Node.js server
I'd think the firewall could not be the culprit, as all it sees is an SSL encrypted stream of data, and with a the non-websocket transport it does works. I also tried the match origin protocol option in socket.io, without success.
Unfortunately I cannot freely play in that environment, so I tried to replicate the issue in my DEV environment, without success. I created a software SSL proxy (using node.js's http-proxy), which should work similar to BIG-IP. But going through that SSL proxy with websockets works just fine.
Could this a be an issue with the BIG-IP? Configuration? What else could it be?
Best Answer
As of December of 2012, BIG-IP doesn't support SSL offload of WebSocket traffic. Because the requests look like HTTP, they're processed by an HTTP engine that doesn't understand when the direction of flow changes for a WebSocket connection. Don't use SSL offload with WebSocket connections until it's officially supported.