[Bug] Error when hosting behind https reverse proxy

[RaphMad]

When hosting behind a reverse proxy using https, tiles cannot be loaded.

I was able to track it down to the magic_string_magic dummy host that is defined in https://github.com/headwaymaps/headway/blob/main/web/nginx.conf.template#L53.

It seems to only redirect accesses to http://magic_string_magic, but when the whole page is https, also this call will be https://magic_string_magic.

I was able to fix it by manually changing both occurrences of http://magic_string_magic to https://magic_string_magic (but of course this only works temporary until the container gets re-created).

I think a proper fix would be to have an ENV var defining whether the whole stack is hosted behind https and changing the entries in nginx.conf.template accordingly (could maybe even be dynamically parsed from HEADWAY_PUBLIC_URL).

[ellenhp]

Hey! Thanks for trying this out! My demo server is currently behind an nginx reverse proxy with HTTPS. https://maps.ellenhp.me/

It seems to only redirect accesses to http://magic_string_magic, but when the whole page is https, also this call will be https://magic_string_magic.

Is your (outer) nginx proxy terminating TLS and then making another HTTPS request out to headway, by any chance?

This is very strange, I'm going to go digging. By the way, there seems to be an issue with sprites and fonts at HEAD right now, my demo server is on 5713d71 which is working without issues.

[RaphMad]

I'm using traefik with the following annotations, rest is the very basic example compose file:

    labels:
      - traefik.enable=true
      - traefik.http.routers.headway.rule=Host(`headway.traefik.lan`)
      - traefik.http.routers.headway.entrypoints=https
      - traefik.http.routers.headway.tls=true
      - traefik.http.services.headway.loadbalancer.server.port=8080

(Don't get confused by https and tls=true, thats for talking to the proxy - the communication between traefik and headway then is plain http - I don't think the default headway nginx even exposes https)

[ellenhp]

It doesn't, but something is convincing the tileserver-gl-light container to think it should serve over https and I don't know what that could be. what Headway commit are you on?

[RaphMad]

Latest main (6ca45b3 as of now).

Also using Chromium: 102.0.5005.61 (Official Build) (64-bit) if that may be an influence, since the request to https://magic_string_magic is seen in the dev tools and originates from the browser.

[ellenhp]

Okay I think we need to set X-Forwarded-Proto in headway's nginx config. My current theory is that your (outer) reverse proxy is passing through some header indicating protocol that gets propagated all the way to the tileserver-gl-light container. The tileserver is dutifully constructing an https base URL, which means the substitution fails. My outer reverse proxy is stripping the headers when it reconstructs the request, so the protocol appears to be plain HTTP to the tileserver, and substitution succeeds.

I think a proper fix would be to have an ENV var defining whether the whole stack is hosted behind https and changing the entries in nginx.conf.template accordingly (could maybe even be dynamically parsed from HEADWAY_PUBLIC_URL).

I agree that the dummy host is janky but the proof of concept for headway was essentially built in 8 days so there's a bit of that. If you wanted to help with a proper fix for this instead of just a band-aid with the HTTP headers that would be wonderful. My only ask is that I would like to avoid adding redundant environment variables to .env if possible.

If you don't have bandwidth I'll get to this eventually! I've been working on #58 though so I haven't had time these last few days.

[ellenhp]

This should be fixed by #61. Closing for now but I would eventually like to replace the dummy host with something a bit less janky.