SSL Web Socket proxy bug

#1
Hello,

This is my first post here, and unfortunately a bug report. I recently had to rebuild a large project and I decided to switch from NGINX to LSWS on all the web servers in the cluster. Part of this move was also using LSWS Web Socket proxy since it looked so promising.

However, it seems that if the browser does not send: "Upgrade Request" there will be no connection, at all.

This is specified in the LSWS panel:

Specifies the URI(s) that will use this WebSocket backend. Traffic to this URI will only be forwarded to the WebSocket backend when it contains a WebSocket upgrade request.

Traffic without this upgrade request will automatically be forwarded to the Context that this URI belongs to. If no Context exists for this URI, LSWS will treat this traffic as though it is accessing a static context with the location $DOC_ROOT/URI.


However... this is were it gets interesting, notice the line: Traffic without this upgrade request will automatically be forwarded to the Context that this URI belongs to.

This is not the case, because it doesn't work. Like at all, I tried all sorts of combinations and it simply does not work. Nothing to see in debug logs either, weirdly.

I would imagine the config should be like following:

1. I have your "main" web socket on "/"
2. I have a Context setup as Web Server Proxy on "/"

The result should be that traffic without the upgrade request to go the Web Server Proxy on the same path. But as I mentioned, that does not happen.

So I tried another approach...

1. Setup web socket proxy on "/main"
2. Setup normal web proxy on "/fallback"

And the result is the same... if the browser is old and does not send upgrade request, you just don't connect. This is crucial to me to fix, because I simply cannot have people not connecting to the server. I would like like to mention that I am using SSL, and without SSL is not an option.

Please advise on how should I make this part work:

Traffic without this upgrade request will automatically be forwarded to the Context that this URI belongs to.

So that I can still forward people to the web socket app server.

Your help is much appreciated.
 
#3
May I know if this is a OpenLiteSpeed or LiteSpeed Web Server? Were you trying to use a secure WebSocket backend?
Thank you for replying, this is OpenLiteSpeed 1.6.20 (I can't go Enterprise on so many servers yet with this massive issue, the company won't approve it).

Regarding your question, no; the backend does not specifically listen with SSL. I`m using Ratchet as backend, but without SSL and quite simple:

PHP:
$wsServer = new WsServer($chatServer);
$http = new HttpServer($wsServer);
$server = IoServer::factory($http, $port, $ip);
The site itself has SSL, and the subdomain for the web socket proxy has SSL as well.

Here is the VHOST configuration:

Code:
docRoot                   $VH_ROOT/html
vhDomain                  wss.gra1.broadcastcentre.com
enableGzip                1
enableBr                  1
enableIpGeo               1

errorlog $VH_ROOT/logs/ws_error.log {
  useServer               0
  logLevel                INFO
  rollingSize             100M
}

accesslog $VH_ROOT/logs/ws_access.log {
  useServer               0
  logHeaders              7
  rollingSize             100M
  compressArchive         1
}

extprocessor fallback {
  type                    proxy
  address                 https://127.0.0.1:9911
  maxConns                2000
  pcKeepAliveTimeout      -1
  initTimeout             5
  retryTimeout            5
  respBuffer              0
}

extprocessor test {
  type                    servlet
  address                 127.0.0.1:9911
  maxConns                2000
  pcKeepAliveTimeout      -1
  initTimeout             5
  retryTimeout            5
  respBuffer              0
}

context /test {
  type                    proxy
  handler                 fallback

  accessControl  {
    allow                 ALL
  }
  addDefaultCharset       off
  enableIpGeo             1
}

vhssl  {
  keyFile                 /etc/letsencrypt/live/wss.gra1.broadcastcentre.com/privkey.pem
  certFile                /etc/letsencrypt/live/wss.gra1.broadcastcentre.com/fullchain.pem
  certChain               1
  renegProtection         1
  sslSessionCache         1
  sslSessionTickets       1
  enableSpdy              15
  enableQuic              1
}

websocket /main {
  address                 10.4.76.225:9911
}
Feel free to connect to this WS server if you'd like to: wss.gra1.broadcastcentre.com

Thanks again for the support.
 
#5
Thank you for clarification. LSWS normaly refers to "LiteSpeed Enterprise Web Server" while "OLS" means OpenLiteSpeed. That's why we could like to clarify when you writing "LSWS", you means to write "OLS".

For OLS websocket proxy setup, you can refer to https://openlitespeed.org/kb/setting-up-websocket-proxies-on-openlitespeed/.

Does your websocket backend tested ok on ws://10.4.76.225:9911? also OLS only proxy to ws: , cannot be wss://
My bad... I`m using LSWS on other projects/servers so I am used to saying LSWS. The proxy is already setup and working, please see the config file...

10.4.76.225 is private IP as you can see...
 
#6
What I am trying to explain in simpler words is that people can only connect to the web socket if the browser sends the upgrade request, and openlitespeed should send requests without the upgrade request to the context the uri belongs to (as the docs say), but it doesn't...

As I said in my initial post, I have tested and tried to setup a web proxy on context to the web socket backend, with the hope that openlitespeed will send requests without the upgrade request there, but it does not.

The end result being... if you have a browser that does not send upgrade request, you don't connect. No status code returned, nothing.
 
#8
Is there really no solution for this? I have tested with many users and a very high percentage will simply not connect to the web socket due to the upgrade request missing :(
 
#9
I made tests on a separate project using LSWS Enterprise and there is the same problem. Maybe you can actually give some attention to this issue...
 
Top