Assets should be served from the container

[XanderVertegaal]

On the server, requests for /assets/ are redirected/proxied to htdocs/assets. This is not correct for our Docker Compose setup: assets should be served from the container instead.

The proxy seems to be set up using an Apache alias in cookiecutter.json in the deployment repo. However, even after removing this and restarting Apache, the server will still look for assets in htdocs/assets.

We are not using many assets now, so we can work around this problem by manually copying them to htdocs/assets. However, for future deployments using Docker Compose networks, this is something we should fix.

[jgonggrijp]

The proxy seems to be set up using an Apache alias in cookiecutter.json in the deployment repo. However, even after removing this and restarting Apache, the server will still look for assets in htdocs/assets.

This is likely rather due to a lack of configuration than a surplus. The default behavior for Apache on all backoffice servers is to attempt to serve everything as a static file from htdocs.

[XanderVertegaal]

Ah, interesting! In that case I am still a bit confused about the Apache aliases in cookiecutter.json, which do seem to explicitly proxy calls to /static/ and /assets/. Or are these aliases causing the default behaviour you are describing?

    "apache": {
        "aliases": [{
                "/static/": "{{ cookiecutter._vhost.static }}/"
            },
            {
                "/assets/": "{{ cookiecutter._vhost.static }}/assets/"
            }
        ]
    },

[jgonggrijp]

When you visit a URL, for example

https://some.domain/some/path

Apache looks for a virtual host (vhost) that is allowed to respond to requests to that domain. This is something that backoffice configures for us. Apache then consults the configuration of that vhost in order to determine how to handle the request to /some/path within that vhost. By default, it tries to do that by resolving the path relative to the htdocs folder. In other words, it translates the above request URL to the following path on the local file system:

$WEBROOT/htdocs/some/path

The static alias overrides this behavior by routing https://some.domain/static/bla to $WEBROOT/htdocs/bla instead of $WEBROOT/htdocs/static/bla.

Side note: an alias is not a proxy because it does not defer the request to another server. It is just a way for Apache to map request paths to file paths.

At the surface, the assets alias does not change anything, because https://some.domain/assets/bla is still routed to $WEBROOT/htdocs/assets/bla. However, we normally need that alias because we proxy everything under / to a Gunicorn server. My impression is that the latter override is missing or incomplete in your case, which means that the behavior occurs whether you specify the alias or not.

[bbonf]

As far as I can tell the problem was caused by the ProxyPass {{ key }} ! line in the apache conf (the important bit is the ! which means, don't pass these requests to the proxied server)

Given that, commit https://github.com/UUDigitalHumanitieslab/deployment/commit/415d2ad46dd82355084502a3c3540ae0440bf855 should have solved the issue. However, at least on the test server there was another .conf file left from a previous deployment attempt from the branch parseport-docker-test, that still had the ProxyPass /assets ! line. Since both files were read by apache, the changes had no effect.

Just to be sure I also removed the entry for /static because we really do want to forward everything to the containerized nginx.