Open bdbusch opened 1 year ago
If you want to serve on a different port like that, I think you could provide the "--public_url --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
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
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.
TL;DR:
--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