Reverse Proxy Compatibility about architecture

[michaelarnauts]

This can quite easily be fixed by using (sub)domain names that point at your home address. Ngnix can route requests to hass based on a specific domain. Even it is a dynamic address, this is possible. This also plays nicely with https what won't work good with just an IP.

[balloob]

Ah that's a good point too Pascal. Okay, case closed. Subdomains is the solution if people want to run multiple things on a server, Home Assistant doesn't have to know about it.

[OttoWinter]

So what you're really asking here is the ability to change the relative URL root of the Home Assistant installation to allow urls like 192.168.178.42/homeassistant/states instead of the "forced" 192.168.178.42/states? I'm not sure how was that would be since Frontend would probably also need to know this at compile time.

(Btw, you can have multiple IPs point to the same computer in your network; for example have 192.168.178.2 point to Home Assistant and 192.168.178.3 to everything else)

[balloob]

A pull request to add this to the frontend is welcome. Here are some constraints:

• It should not make current startup slower because it's doing extra requests or things like that
• it should be backwards compatible

[balloob]

There you go, problem solved, case closed…

[pvizeli]

That is a problem of reverse proxy and not our software.

@balloob we should not change or make our URL schema dynamic. Otherwise it is hard for things like hass.io to interact with home-assistant.

[fanthos]

To make the web UI reverse proxy compatible with appname, we don't have to make the URL dynamic. Seems that make the front-end works with relative URL will resolve the issue. /api/* mapped to /appname/api/* for front-end page, and nginx will forward it to /api/*.