Proper reverse tunnel support?

[simple]

I want to bring this back from the dead because it's still very relevant and with the move to paid cloud subscription since is more important than ever. In a post I just made, the salient if salty point i think should be stressed (Hubitat over HTTPS/SSL using Apache - #52 by simple):

@simple

Really looking at what was in previous firmware compared to what you wrote, and what is now, just seems purposeful to force one to subscribe to the cloud service when everything is pretty much in place otherwise to work behind a reverse proxy.

The simple notion of "if local, write urls as relative and use the client request host/protocol" seems to be deliberately ignored/avoided especially with the immediate resistance (Proper reverse tunnel support? @patrick's response) and lack of fundamental understanding of how simple it can be makes the whole thing seem more purposeful to specifically stifle using your own "cloud"-y alternative considering that configuring HE in depth is already not a task for the average user to undertake since the UI is relatively clunky for a reactive style app.

So again to renew this request, it would be as simple as just not hardcoding the http://<LOCAL HOST> in static ref/links and setting the hubURL: window.location.host since it appears the HE is internally aware of whether the request is coming from within the LAN (subnet) or externally in order to decide how to treat it - though i'm assuming the https://cloud.hubitat.com/api/... cloud link is itself a proxy/wrapper and rewrites the static links to a respective CDN store.

The point here is KISS and occam's razor in assessing this feature request. It's not changing anything but removing a (now poor security practice) uri component and letting the browser fill in the blanks.