From my understanding, WebSockets has been designed to traverse firewalls and proxies. Indeed, after an handshake between the client and the server, the communication protocol will change from HTTP to WS but it will still communicate on the port used to establish the handshake. (See websocket.org).
In other words, if a client can do an HTTP request on a given port, he will also be able to do WS on the same port.
However, according to XSockets configuration documentation, the port used for WS communications isn't the same as the HTTP port. Unlike a regular WS connection, a NAT on the firewall seems to be required to allow communication between the XSockets server and the client.
Is there a way to configure an XSockets server to re-use the HTTP port used for the handshake (port 80) without creating conflicts with the existing web applications hosted on the same web server (IIS)?
You are right. But, the application listening on the web port, should be able of understanding WebSocket protocol in order to do the handshake, and that is not the case of IIS < 8.
If you want to have your WebSocket running on the same port than your web application, you need IIS 8 (included in Windows >= 8 and >= 2012).
As far as I know XSocket allows you to use IIS8 as hosting environment: http://xsockets.net/docs/hosting#using-iis8
But if you have IIS < 8 , then it is not possible. It is not a XSocket limitation, it is a IIS limitation.
Related
I have ExspressJS app run with Socket.io, due to firewall issues with higher port for SIO i want to switch that both will work on port 80.
Found this small article and on my dev machine it's look working good.
My question is, is it really goo to do that? is it a good practice? if not why?
Please advise.
It makes absolute sense to run socket.io and your web server on the same port.
The webSocket protocol (which socket.io is based on) is specifically designed for this to be the primary way that socket.io is used for a bunch of reasons including same-origin permissions and client and server firewall routing of port 80.
In case you didn't realize it, every socket.io connection starts with an HTTP request to a specific route and then once the initial handshake between client and server has been confirmed, then the protocol is "upgraded" from HTTP to webSocket. Because all socket.io connections connect in on a very specific route, all other HTTP connections can easily be separated out and be treated by your web server as regular web requests.
In these instances, what happens? Does communication fall back to HTTP? I'm assuming that communication will either fail, or fallback, depending on the setup of the ssl-enabled destination server.
Example Case:
A plugin that is installed on Server A (which may or may not have SSL), communicates with an API that functions over HTTPS on Server B.
I think your question is not clear enough. Do you mean, with "a server without SSL", that
The server system has no kind of SSL software installed. In this case of course no SSL requests can be done from the server.
Or that the web server itself is only available by HTTP and not HTTPS, but there is a script on it which needs to access other hosts by HTTPS. In this case it can do these requests if the required software is installed on the server and if the target host is available by HTTPS and if no firewalls blocks the connections etc. Configuration of the web server itself has nothing to do what kind of requests programs on the web server can do.
I have a website behind cloudflare. I need to enable websockets over SSL without turning off cloudflare support. I have a PRO plan and hence won't get the new websocket support. I am using Nginx to proxy a SSL connection to a web socket running on a node server. Now, I read somewhere that cloudflare could work with approved ports would support websockets. Hence, I'm using 8443 for the Nginx port and another port for the node server. Using wscat it returns a 200 error.
$ wscat -c wss://xyz.com:8443
error: Error: unexpected server response (200)
I know that the websocket is expecting a 101 code. However, if I visit https://xyz.com:8443, I can see the page displayed by the node server telling me proxy is working. Also, once I turn off cloudflare support, the websocket starts working. Any clues to get this working. I know I can create a subdomain but I'd prefer running the websocket behind cloudflare.
If you're trying to access this through CloudFlare's network you'd need to explicitly have web sockets enabled on your domain before they will work -- regardless of the port. As in, even if the port can pass through our network, that won't automatically mean that web sockets will be enabled or accessible on your domain.
You can try contacting our support team to request an exception to see if they can enable it for your domain, but typically this is still only available at the business and enterprise levels.
Disclaimer: I work at CloudFlare.
A websocket server that is not hosted in port 80, will be invisible from Internet Browsers?
I cannot use port 80 (it's being used by IIS) neither 443 nor 8080.
Does websockets hosted on custom ports will have firewall issues?
The only way is to use IIS8 as to share the same port (80)?
(I'm using IIS7 with SuperWebSocket library)
Websockets that are accessed from browsers, should not be deployed in custom ports?
Thanks in advance.
To get to the heart of your question, I've had most success with realizing that my Web Server and Web Socket Server can both be on port 80, but different hosts ( origins ). As long as the Web Socket Server can handle CORS requests from your Web Page origin, it seems this is a way that avoids firewall problems and leads towards the architecture of having static content froma Web Server and dynamic from a WebSocket server.
So the story is:
serve page from web.server.com:80 (that's the origin)
in application space on that web page open a WebSocket to websocket.server.com:80/serviceName
(makes a cross-origin request that needs be be allowed by websocket.server.com, which might whitelist web.server.com)
happily serve dynamic content and static content separately.
Some more specific answers to some of your questions:
A WebSocket server that is not hosted in port 80, will be invisible from Internet Browsers?
No. Your application in the browser can open a WebSocket to other ports if that is desirable,
subject to CORS constraints. Oftentimes it is advantageous to keep the WebSockets on port 80, so that intermediaries and edge gateways don't have to change firewall rules.
I cannot use port 80 (it's being used by IIS) neither 443 nor 8080.
Does WebSockets hosted on custom ports will have firewall issues?
Most likely, unless you are in control of the firewall and can open up other ports.
If you have control over the firewall then there is no issue with running a websocket server on a custom port. You just need to open up the port to allow incoming traffic to that port.
The problem is not really firewalls per se but rather other types of filtering, proxying, load balancing, etc that happens before the traffic reaches your server. However, unless you have specific requirements that you didn't mention then there should be no issue with simply allowing traffic on that port.
If you WebSocket server is configured to limit connections to specific origins (CORS) then you will need to allow the origin to make connections. The origin is the address of the web server that will be serving up the web page that will make the WebSocket request. The default is usually either wide open or limited to the address of the websocket server itself.
According to here:
Warning: The server may listen on any port it chooses, but if it
chooses any port other than 80 or 443, it may have problems with
firewalls and/or proxies. Connections on port 443 tend to succeed more
often but of course, that requires a secure connection (TLS/SSL).
Also, note that most browsers (notably Firefox 8+) do not allow
connections to insecure WebSocket servers from secure pages.
I was trying to sniff HTTP packets though wireshark on my localhost, when i tried working on a web2py instance at my localhost no http connections found. While digging deeper into it i found it is not creating `any connections in the application layer. well then how does it communicate with browsers without http? (I have heard of web2py as a very secure framework, now this thing is creating more curiosity in me)
Are you sure it's not an HTTP connection on port 8000 (which is the IANA registered port for irdmi)? If you use wireshark, you can choose to decode as HTTP when the port isn't the standard port for the protocol.