Air off, Mind on ~ / Javascript+Golang, Sci, Health… /

Socket.IO Behind Proxy or Firewall

Independently of what transport you are using (WebSocket or Comet or both), a connection can always be closed by a Proxy or Firewall, or an expected network outage can close your connection. Why is it a problem? It’s problematic when a disconnection happens as you may loose server side events if you don’t architect your application correctly.

  • long-polling: between reconnection, servers side events may happens and if they aren’t persisted, those events will never reach your client.
  • websocket: Websocket are new and most if not all firewall will close them after some X idle times. Again, all server sides events will be lost
  • http-streaming: Some proxy really don’t like the http-streaming technique, and will close it right away. Again, possibility to loose server sides events.
  • Unexpected network outage: the connection can also be closed by something between your browser and server.

Query string management is messed up

Socket.IO and firewall software

How HTML5 Web Sockets Interact With Proxy Servers

Websocket Interact with proxy

Using TLS/SSL is advised not only when you need to encrypt the traffic but also when you need to bypass proxy servers and firewalls, that otherwise will just block or not understand WebSockets connections. Diving into HTML5 with WebSockets and Perl

Socket.IO server configuring: match origin protocol


Reverse Proxy Web Sockets with Nginx and Socket.IO