Add this to the docker-compose.yml file or CSS will always be broken for any FQDN

[HVR88]

Regardless of any MUSICBRAINZ_WEB_SERVER_* settings, the static resource URL should never be built with variables. The ultimate fix is to remove the building of that path using variables.

But for the quick fix, adding this to docker-compose.yml addresses the issue from user-config space without changing the underlying docker files.

  - STATIC_RESOURCES_LOCATION=/static/build

Now you can set the host or port to anything you want, with or without reverse proxy and css will be served from the correct relative path that all other resources are served from.

[mwiencek]

Normally it should be fine if you set MUSICBRAINZ_WEB_SERVER_HOST to your FQDN. (The README sounds like it's saying that MUSICBRAINZ_WEB_SERVER_HOST is a listen address, but it's not.)

But you're right that musicbrainz-docker is "broken" here if you're publishing anything but ports 80 or 443 on the host:

sub WEB_SERVER {
    $ENV{MUSICBRAINZ_WEB_SERVER_PORT} == 80 ||
    $ENV{MUSICBRAINZ_WEB_SERVER_PORT} == 443
        ? "$ENV{MUSICBRAINZ_WEB_SERVER_HOST}"
        : "$ENV{MUSICBRAINZ_WEB_SERVER_HOST}:$ENV{MUSICBRAINZ_WEB_SERVER_PORT}"
}

I put "broken" in quotes because it's at least documented in the README:

If `MUSICBRAINZ_WEB_SERVER_PORT` set to `80` (http), then the
port number will not appear in the base URL of the web server.

If set to `443` (https), then the port number will not appear either,
but the a separate reverse proxy is required to handle https correctly.

We should probably allow configuring WEB_SERVER directly, and only use the above code if that's unset. Using STATIC_RESOURCES_LOCATION=/static/build does work fine for getting CSS/JavaScript to work, at least, but there may be other places WEB_SERVER is used internally that we'd want to ensure correctly point to the public facing server.

[pvanderlinden]

This might be good to document, as it is confusing. Setting MUSICBRAINZ_WEB_SERVER_PORT to 443 also changes the port forwarding, which also gives an error (the reverse proxy is running here).

Luckily that can be solved with another docker compose override file (set HOST to your FQDN and PORT to 443). This assumes you have a network nginx with the reverse proxy running.

services:
  musicbrainz:
    ports: !reset []
    networks:
      default: {}
      nginx: {}
networks:
  nginx:
    external: true

[HVR88]

Normally it should be fine if you set MUSICBRAINZ_WEB_SERVER_HOST to your FQDN.

But it's not. :(

But you're right that musicbrainz-docker is "broken" here if you're publishing anything but ports 80 or 443 on the host:

IMO, it's really broken with ALL CAPS, as in BROKEN. Not in quotes. There's no way around it without my suggestion. Tthe container comes set up to use 5000 by default, and the current behaviour always breaks css.

It also makes no sense to put the container on port 80 or 443 because it's set up only for bridge networking. The only time it even remotely makes any sense is when running on a dedicated host. I run it like that without 80/443, but I can probably count on one hand how many other people are likely to. Even then, just leave it obscured and use a reverse proxy. But besides any of that, again, the container defaults to port 5000 by default.

Luckily that can be solved with another docker compose override file (set HOST to your FQDN and PORT to 443). This assumes you have a network nginx with the reverse proxy running.

Please don't do that. Always use a reverse proxy outside of the container to forward to its default port or some other arbitrary port. "That is the way."

I just set up my own deployment stack with the workaround in place and no manual config steps needed to bring everything up.
https://github.com/HVR88/musicbrainz_stack-DEV

[pvanderlinden]

I actually use a reverse proxy. What I am doing:
MUSICBRAINZ_WEB_SERVER_PORT=443
MUSICBRAINZ_WEB_SERVER_HOST=fqdn...

Then with the compose override I posted above:

• don't publish the server port on the server container
• add the nginx docker network
• let nginx reverse proxy the server with the default port 5000 and (docker) hostname musicbrainz.

The site works perfectly and is not reachable without the reverse proxy.

[HVR88]

We're kind of getting out into the weeds here. My OP was to make the point that static resources should be relative and not take any kind of parameter in front of them.

But....

You can actually skip settings on the container when using nginx for reverse proxy. So long as you include "STATIC_RESOURCES_LOCATION=/static/build" to prevent the issues I mentioned up top.

Just forward your FQDN to container IP and PORT, force SSL and give it a cert. And for sanity's sake...

proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $remote_addr;