CODEWITHSUNDEEP
htmlwebsocket
dlchambers
dlchambers

Reputation: 3752

WebSocket won't connect to anything other than 127.0.0.1 / localhost

I have a testapp consisting of an HTML5/WebSocket client and an HTTP/WS server. Both servers are in C#; the HTTP server is my own simple thing and the WS server is also homebrew based on concepts from http://nugget.codeplex.com/. HTTP server is listening on 0.0.0.0:5959 and WS server on 0.0.0.0:5960 (accept connections from any client, but on different ports).

My index.html includes some JavaScript that opens a WebSocket to 'ws://'+document.location.hostname+':5960/' (that is, to the same IP address that the webpage came from, but on port 5960). The WS server sends sample data every 100ms. All in all, it's a pretty straightforward demo. I'm using Chrome 12.0 on Windows7.

I've found that the HTTP server works from any client, either a browser on my machine pointed to 127.0.0.1:5959 or localhost:5959, AND it works when any machine (mine or a remote machine... "remote" being a different PC on my desk :) hits my server machine's work-internal 10-net address 10.122.0.159:5959. Everything works as expected in HTTP land.

However, the WebSocket only works on 127.0.0.1 and localhost; remote machines can successfully fetch HTML from 10.122.0.159:5959 but the WebSocket will NOT connect to 10.122.0.159:5960. In fact, when I point my local browser to it's own 10-net address (10.122.0.159:5959) I get the same result - HTML loads but WebSocket does not connect.

Any ideas as to why this might be happening? Does CORS require that the WS be using the same port as the HTTP request originated from? If so, is there a special exception to the rule for 127.0.0.1?

Many thanks,
-Dave

Update
It seems to be caused by a proxy server blocking ws:// requests. Our company employs a proxy server for content filtering and all the usual stuff, and our browsers are configured to use it.
Chrome uses IE's proxy settings, and IE's default settings are for localhost to not use a proxy server. When I check the box to have local connections also use the proxy server, my ws:// requests to localhost get blocked. Conversely, when I uncheck the "use proxy server" box my server does rx the WS request. Similarly with the remote machine, if I turn off the proxy on the remote machine my server does rx the ws:// request.
So it's a proxy thing, not a CORS or socket thing, and now I'm off to explore proxy settings with our IT folks.

Upvotes: 3

Views: 13117

Answers (2)

dlchambers
dlchambers

Reputation: 3752

It is/was indeed a proxy thing.
Rather than asking our IT folks to make changes (good luck with that, eh?) I simply turned off proxy for 10.122.0.159 ([Howto for IE/Chrome][1]). I briefly experimented with turning it off for the ws:// protocol but couldn't get it to work, so for now just opening that one IP address does the trick.

Upvotes: 1

kanaka
kanaka

Reputation: 73217

There is no WebSocket limitation on cross-origin except what is governed by the CORS security in the handshake.

It sounds like something is wrong with your WebSocket server and it is only listening on localhost for connections. I would add some debug output to the OnClientConnect routine in Nugget (WebSocketServer.cs) so you can see when socket connections happen. If you really think it isn't a problem with the server then I would suggest using wireshark and comparing the localhost connection to the remote connection.

Also, if you are using the SilverLight WebSocket prototype (README) in IE 9, then you are restricted to ports 4502-4534 for WebSocket connections. It's possible that for localhost this restriction is lifted.

Upvotes: 2

Related Questions