Allow changing the path/subfolder of the application

[schlenger]

Issue: This refers to example [1] specified below. When the application is available with an appended path, the path needs to be configured somehow.

1. Usually, the full request path is handed to the application, in [1] this would be e.g. soundworks/controller but the application itself is only handling paths without the leading (subfolder) path such as controller. There is a workaround by removing the prefixes via the nginx config. This leads to a working application (without working websockets). However, this is also not specifiable (if this is a word) in the configuration: If I don't set a specific path for the sockets (default is socket) in the configuration of soundworks, then the request for the socket will be send on wss://example.com/socket, which is obviously not available. If I add the full path soundworks/socket, the request will be handled and upgrade by the webserver (http->ws), but in the scope of the scenario in 1), this request will also be stripped: This is due to the fact, that the websockets requests are forwarded correctly by the webserver e.g. wss://example.com/soundworks/socket, the corresponding request in the application will be /socket. This is not matching the expected schema and opened sockets which are running on /soundworks/socket.

2. Without dropping the prefixes, the requests like example.com/soundworks/controller will be internally forwarded by ngnix to 127.0.0.1:8000 with the path soundworks/controller, which return obviously a 404 because only /player and /controller are specified by default.

Workaround for 1): I solved this by modifying the soundworks/core code. What I did is hardcoding the socket path instead of using the full path from the configuration (which would be /soundworks/socket). To modification are made here: https://github.com/collective-soundworks/soundworks/blob/master/src/server/Sockets.js#L37

What would be useful: It would be useful to specify a subfolder/request path of the application manually in the configuration. This would help to overcome the modifications and configuration issues named above. The application handling/routing internally could then work without that overhead.

[1] Example:

• Main domain (nginx): example.com
• Server path where the application is available example.com/soundworks
• The soundworks application is running at 127.0.0.1:8000
• in ngix: The request paths /soundsworks are configured to be internally redirected to 127.0.0.1:8000

[b-ma]

As mentioned in #32 there is cleaner workaround that does not imply to change the core, by adding another nginx location configuration.

Let's keep that open, but it implies two important aspects:

• handle the problem properly without making a breaking change
• make sure it works with apache too

[b-ma]

Hi,

The issue has been fixed in e9312e9, and released in @soundworks/core#3.0.4

So, there is a new config option subpath that replaces both assetsDomain and websockets.path options.
We thus have a more simple configuration file and a more consistent behavior regarding to rewriting rules.

With a soundworks config file (e.g. config/env/whatever.json) such as:

{
  type: 'production',
  port: 8001,
  subpath: 'my-app',
  useHttps: false,
}

We can thus have an nginx config such as:

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

location /my-app {
    rewrite ^/my-app/?(.*)$ /$1 break;
    proxy_pass http://127.0.0.1:8001;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
}

Existing applications and nginx config should still work as expected without modifications.

I also updated the template to get rid of all references to assetsDomain, you can have a look to the changes here: collective-soundworks/soundworks-template@fffa4a2, but again this is not mandatory as everything has been aliased to keep the backward compatibility.

Cheers,

[b-ma]

Also added a documentation page there https://collective-soundworks.github.io/misc/online-deployment.html