url rewriting in utils.js doesn't honor the --port used to launch the program making proxying the port impossible

[bdbusch]

TL;DR:

• setup nginx to listen on 9444 and set the right headers for proxied-for
• start the app with --port 9444 (not default 8080)
• you get the initial /styles.json properly but the URLs _embedded _within__ do not include the --port, making subsequent fetches fail (as they're now going to 443, which is in use by other software not in my control on my deployed systems).

Details: Awesome tool! But, if you use an nginx proxy to provide SSL (needed if the client app is using HTTPS and hitting this unsecured HTTP endpoint - forbidden by modern browsers (dreaded mixed-content)) and need it to be on a different port than 443 (very commonly in use by other apps not in your control) - your src/utils.js::getUrlObject() does not account for the --port provided on the command line.

initial request for /styles.json (proxied through nginx, and setting the required proxied-for headers)

https://host.com:9444/styles.json

returns urls like

https://host.com/yada.json

I had to patch your code to add the port -- if you just set the urlObject.port to the 'program.opts' --port flag, it would make the subsequent URLs you send use the same port that the app is listening on.

I tried to fork the repo and wanted to add access to this program.opts (from main.js - to get to the port used in the app) but was unable to satisfy the binary dependencies on windows and test.

There absolutely might be a configuration I missed, but this function seems to not address the port issue. Or some trick in nginx.

To me, a PR would look like

urlObject.port = program.opts.port || req.headers.port || req.{some parsing of original url?} VR Brian

[acalcutt]

If you want to serve on a different port like that, I think you could provide the "--public_url " option with the url and desired port. --public_url https://host.com:9444/

https://maptiler-tileserver.readthedocs.io/en/latest/usage.html -u|--public_url <url> Enable exposing the server on subpaths, not necessarily the root of the domain

[acalcutt]

Comment on windows support. we did just get windows binaries in Maplibre-Native v5.2.0 which was release last week , however in testing we have found a sharp/canvas incompatibility in windows. I have gotten tileserver-gl to work in windows by downgrading sharp to 0.30.7

[nowkarol]

Hi! Maybe it should be another issue, I am not sure.

I think you could provide the "--public_url " option with the url and desired port.

This probably is possible but would require different configurations for testing enviroments. I wanted to use X-Forwarded-Host header to make it dynamic (proxy would copy original Host header there) but there is issue with port.

My proxy works on different port than tileserver (31011 for example), despite setting X-Forwarded-Host to value with port (example-original-host.com:80) created links use port from Host created in proxy and its result in example-original-host.com:31011. It would be nice to not strip port from X-Forwarded-Host. I know it is not rfc specified header so people have similar problems with it's implementation in different places.

It could be backward compatible change when port will be taken from Host (as now is) if not passed in X-Forwarded-Host (with exception of cases when someone passes invalid port and rely on overwriting it by port from Host)

@bdbusch I found simple but hacky way to solve this in nginx - overwrite Host header passed to tileserver proxy_set_header "Host" "$host"; It wont work if another proxy listens on this port and uses Host to decide where finally should request arrive but that's rarely the case.