Issue with changing the subdirectory and socket path accordingly

[schlenger]

I've wanted to deploy the current state in production - when changing the IP in the config to 0.0.0.0 in config/env/default.json (to e.g. put an apache server before the application itself), it seems like the application is ignoring the config parameter.

Any suggestions or ideas?

Edit(s): This is actually working now: It seems like this is more a simple logging issue since the server is also reachable via 0.0.0.0 but only prints the network interface adapter adresses.

However, there is still the issue named underneath with the subdirectories (this is optional) and another one with the websockets: I deployed a test project here and I can not figure out why the websockets are not opened correctly. The current configuration is:

 // websockets configuration
  "websockets": {
    "path": "paraspace/socket",
    "url": "",
    "pingInterval": 5000
  },

[schlenger]

It would be interesting to change the "subdirectory" in which the process is running as well.

Edit: In my case I want to run the application in <ip>/soundsworks/ which is not working currently, since the webserver calls want to call the soundworks application with /soundsworks/ as path even when this actual corresponds to the / parameter.

[b-ma]

The IP config entry does not change anything server side, it's only made for node.js clients as written in the comments: https://github.com/collective-soundworks/soundworks-template/blob/907ecdf893aece77554ff8639a40026f611928eb/config/env/default.json#L15

To achieve what you want, from what I understand having a nginx or apache proxy, you need to set the 3 configuration options (port, assetsDomain and websockets.path) the application such as:

  // config/env/prod.json
  port: 8001, // or whatever port...

  // domain
  assetsDomain: '/paraspace/',

  // websockets configuration
  websockets: {
    path: 'paraspace/socket',
    url: '',
    pingInterval: 5000
  },

Then, assuming the node server is listening the 8001 port, you need to configure your proxy so that requests to paraspace are redirected to the 8001 port. In both case (nginx or apache) you will also need to configure the websocket tunnelling.

To launch and orchestrate your applications, you can use a dedicated tool such as pm2 (https://pm2.keymetrics.io/) which works really well.

(I guess that's another documentation page I need to write :), I will start an issue to list all these)

[b-ma]

33

[schlenger]

Okay thanks.

After some investigation it seems like there is issue with the final binding of the web sockets, probably caused by the nginx configuration.

However, it is weird that I have running another, quite plain, node application on the same server with the same configuration which is also configured with websockets (socketio) and which is working quite well.

Current approach: As in the example https://shining.uber.space/paraspace/ named above, the path on which the client wants to connect seems valid. Is there any chance to log the websocket url opened by the server? I've digged deeper into the soundworks core yesterday and haven't found something that seems really helpful. Any further ideas on how to investigate this issue?

The error message can be found in the logs:

WebSocket connection to 'wss://shining.uber.space/paraspace/socket?binary=0&clientType=player&key=3991080189674012' failed: init @ Socket.js?b9ea:102

Maybe this affects more than only this test environment, but I can't say for sure where it fails concretely. If you've interested in (re)creating the same scenario https://uberspace.de/de/ offers free webservers for the first month after setup. You can basically just deploy the soundworks-template and expose it via their web backend s.

[b-ma]

Ok I think I found the problem, there is an inconsistency between how the socket and how regular files are handled with rewriting rules.

The socket path should not be rewritten as the regular files, therefore this lead to the following configuration

• project located in my-app subfolder
• server listening on 8001 port

Apache

RewriteCond %{REQUEST_URI}  ^/my-app/socket       [NC]
RewriteRule /(.*)           ws://127.0.0.1:8001/$1 [P,L]
<Location "/my-app">
  ProxyPass "http://127.0.0.1:8001"
</Location>

Nginx (tested locally)

events {
    # configuration of connection processing
}

http {
  map $http_upgrade $connection_upgrade {
     default upgrade;
     '' close;
  }

  server {
    listen 80;

    location / {
      root /path/to/nginx;
    }

    # rewrite rule for regular files
    location /my-app/ {
      rewrite ^/my-app(.*)$ $1 break;
      proxy_pass http://localhost:8001;
    }

    # special location for the websocket without rewrite rule
    location /my-app/socket {
      rewrite_log  on;

      proxy_pass http://localhost:8001;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;
    }
  }
}

This should be made more consistent inside the @soundworks/core but this would probably be a breaking change, and at least it seems to work both with apache and nginx, so let's hope documenting the problem is enough for now.

Hope this helps, let me know if it works on your side.

[schlenger]

Haha, I wrote a more precise issue here exactly at the same time: https://github.com/collective-soundworks/soundworks/issues/35

I think we can close this one and maybe also one of the others - I'll check this.