Home Assistant isn't served correctly for base_url with a path

[davidjb]

Home Assistant release with the issue:

0.87.1

Last working Home Assistant release (if known): N/A, first version installed

Operating environment (Hass.io/Docker/Windows/etc.):

FreeBSD 11.2, Python 3.7, Nginx front-end

Component/platform:

https://www.home-assistant.io/components/http/#base_url (but possibly other components)

Description of problem:
Setting a http base_url setting with a path present (eg https://home.example.com/homeassistant) doesn't affect the resources served by the frontend (at least). Hitting the URL, which is reverse-proxied from Nginx, sees the HTML load, but the resources on the page are all absolute URLs fixed to the root of the domain eg:

    <link rel='preload' href='/frontend_latest/core-441324a2.js' as='script'/>
    <link rel='preload' href='/static/fonts/roboto/Roboto-Regular.ttf' as='font' crossorigin />
    <link rel='preload' href='/static/fonts/roboto/Roboto-Medium.ttf' as='font' crossorigin />
    <meta charset="utf-8">
<link rel='manifest' href='/manifest.json' crossorigin="use-credentials">
<link rel='icon' href='/static/icons/favicon.ico'>

So, these URLs produce 404s because Nginx is serving with the prefix /homeassistant/…. I've not yet looked into how other parts of Home Assistant behave with a base_url with a path as I'm stuck at this point but I suspect the hosting and HTML of the frontend won't be the only issue.

In short, the aim is to host Home Assistant behind an Nginx reverse proxy alongside several other applications on the same hostname, following config from the Nginx proxy docs which hosts at the root of a domain. Serving Home Assistant from a subdirectory on the same hostname removes the need for setting up a separate hostname, DNS entry, SSL certificate etc, and Home Assistant can co-exist beside other apps on the same hostname like https://home.example.com/files/, https://home.example.com/netdata/, and so on.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

http:
  base_url: https://home.example.com/homeassistant
  use_x_forwarded_for: true
  trusted_proxies: 192.168.0.123

Traceback (if applicable): N/A

Additional information:

In other applications, configuring hosting on a path can be done in a variety of ways, either by always using relative URLs, using absolute URLs (eg prefixed with the full base_url or adding just the path component to the beginning hrefs), or configuring a <base> tag and leaving URLs as they are.

For note, my Nginx configuration looks like this:

        location /homeassistant {
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass http://hass;

            # Rewrite is currently required because HA is serving from the root of the host
            # If `base_url` eventually affected the path from which resources were
            # served from this wouldn't be required.
            rewrite ^/homeassistant/(.*)$ /$1 break; 
        }

[awarecan]

Base url with path is not supported.

[davidjb]

@awarecan Okay, is it an issue that's been considered in the past? If Home Assistant's code base could be adapted to support this, I could look at contributing code to fix the issue -- suggestions on where to start with a PR?

[awarecan]

I think url rewrite is the right way to resolve it. Why do no you want to use it?

[davidjb]

Unfortunately, URL rewriting (eg the rewrite directive in Nginx) isn't sufficient to re-host an application with hard-coded URLs in the HTML/JS/CSS. With URL rewriting, you can redirect requests to different paths, but you can't change the content of a page or its resources. So, in the example above, the browser is still going to keep trying to access /frontend_latest/core-441324a2.js (which 404s) instead of /homeassistant/frontend_latest/core-441324a2.js (which would load).

In this example path, in order to inject a path prefix into that HTML code, one would have to use streaming regex replacement in the body of a HTTP response which whilst technically possible for some limited use cases like HTML, is a hack because you're patching source code on the fly. In some cases like minified JavaScript source code, this type of replacement is impossible.

[andrewsayre]

I would agree rewrite isn’t feasible for this. Even if you could catch all the content in transit, there are components that rely on knowing the path exposed to the internet. For example, the SmartThings component validates digitally signed messages and path is one of the signed attributes.

This would not be an issue/fix, but an enhancement. Open an architectural issue before starting a PR to get alignment with the core team.

[cgarwood]

I prefer using subdomains for everything running through a reverse proxy for this reason, I've run into a lot of applications don't support base paths like that.

Like @andrewsayre said, this would be best as an issue on the home-assistant/architecture repo, or as a post on the community forums.

[davidjb]

Righto - I'll open an issue over on the other repo. In the meantime, I've opened a PR for the docs explaining that paths aren't (currently) valid as part of the base_url.

[davidjb]

home-assistant/architecture#156

[idreamerhx]

2021-07-13 12:24:09 WARNING (MainThread) [homeassistant.components.http] The 'base_url' option is deprecated, please remove it from your configuration

hass behind revert proxy (nginx) need requests uri relative, and also this is a better practice develop web app

[frenck]

@idreamerhx base_url has been replaced with the external & internal URL core configuration. It has not been removed. Please note, you are responding on a 2-year-old issue, things changed a lot. I don't recommend digging up issues that old.

However, it seems like you are looking for a way to host Home Assistant behind a reverse proxy in a subpath. This is (and never was) supported, nor are we going to implement support for it. More information can be found in the linked architecture issue above.

Locking this issue to prevent confusion.

../Frenck