Paul via MapServer-users: > Thanx for the suggestions Kaido, Seth, Steve. Updating the mapfile at > deployment indeed is a better option then the querystring approach, let me > verify what scripting options (sed?) i have on our docker image.
If you omit setting the ows_onlineresource (just try to commend it out) in the .map-file, mapserver will dynamically use the path (e.g. domain) it was reached by. Thus you can have the same mapfile on dev, test, qa or production and they will have individual domains. If you reach the server-instance, it will use the server-name (and port) rather than the proxied domain, but then it will be easier to problem shoot individual server instances using plain gis-tools that utilize metadata such as ows_onlineresource. We tested this some years ago, and have the following expereience using a reverse proxy in front of a mapserver cluster: http -> http ows_onlineresource will use http://whatever.domain.reached.by.frontend.com/path/to/mapservice https -> https will use https://whatever.domain.reached.by.frontend.com/path/to/mapservice https -> http (ssl-offloading) will unfortunately use http://blablabla, even if we set forward proto and forwarded port on the proxy-end. It would be nice if mapserver could use an ssl-offloading proxy, be it haproxy, nginx or something else. So, the ows_onlineresource-problem was solved for us by having a fail-over frontend holding the domains, and different mapserver-clusters for load balancing and fail-over - we just had to live with configuring certificates also for the backend servers for the different environments (domains). -- Kind regards Bjørn Ove Grøtan _______________________________________________ MapServer-users mailing list MapServer-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapserver-users