views:

877

answers:

3

I'm extremely excited about html5's websockets spec but I have a concern.

These days everyone is operating off of some network, with routers (wired/wireless) that have built in firewalls, windows has a built in firewall too.

With that in mind when the server attempts to connect back to the browser that started the websocket handshake will it fail for the vast majority of users? (most people have no idea how to set up port forwarding on their routers)

Or is my thinking incorrect and it will go through fine?

+2  A: 

I'm not an expert (so please check to confirm) but I beleive there will be an UPGRADE mechanism where a regular HTTP connection can be made, then upgraded to a WebSocket, so no existing firewall rules interfere unless they are doing aggressive application level packet inspection. Connections are still initiated by the browser.

Mark Renouf
I believe you're right, the whole protocol is effectively an extension of HTTP so all the traffic goes over port 80
teepark
Any firewall that does statefull packet inspection will drop WebSocket traffic. After the upgrade - it's not HTTP anymore.
Brian Dilley
+2  A: 

HTML 5 WebSockets don't require port forwarding. Connections continue to be established from the client, but the client and server swap roles once the connection is established (TCP is a symmetric protocol after establishment). WebSockets also punch through proxies by using the same CONNECT model that HTTPS uses today.

Marcelo Cantos
+1  A: 

Since firewalls typically simply enforce the rules for inbound traffic rejection and outbound traffic routing (usually through the proxy server), there usually are no specific WebSocket traffic-related firewall concerns.

Proxy servers (and to some extent, certain load balancing routers as well) are a different matter though (See http://stackoverflow.com/questions/2201317/why-dont-current-websocket-client-implementations-support-proxies/2291377#2291377)

Peter Lubbers