If you end up doing a lot of work on mapserver and tilecache behind corporate proxy servers, you’re likely to hit a couple of snags, when the proxy thinks you’re trying to do something evil, when really all you want to do is seed a tilecache or look at an external WMS server. Fortunately there are a couple of useful workarounds, which I record here for my own sanity as much as anything else!
Mapserver has some great documentation on how to use proxy authentication when requesting data from an external web server, but unfortunately if you’re still on Mapserver 5.6.x, and on windows, you are likely to find that some of the directives don’t work. When you test your mapserver layer in a browser, you get a blank screen, and the following error message in your logs:
HTTP request error. CURLOPT_PROXYAUTH not supported. Requires Curl 7.10.7 and up
Needless to say, the later versions of mapserver (5.6.6) are using Curl versions greater than 7.10.7 so we’ll ignore that part of the message and concentrate on the CURLOPT_PROXYAUTH part. A quick google will inform you that this must be explicitly compiled into mapserver, and as far as I can tell, none of pre-compiled windows binaries for 5.6.x have been compiled with this option.
Enter cntlm, which is designed to stand between your application and your corporate proxy server, providing proxy authentication on the fly. To use it with mapserver, install the latest binaries and follow the configuration hints on the home page. The basic process is to run cntlm from a command line to establish the type of authentication that your proxy server uses, then fill in the supplied cntlm.ini file with the appropriate values for your configuration. If you don’t know these, you can easily find them by opening firefox or similar and looking at preferences->advanced->network->settings. You’ll need the URL of the proxy, the port, and the type.
Then, assuming that cntlm is installed on the same server as mapserver, your map file needs only the following layer metadata parameters (in addition to anything else you have defined):
wms_proxy_port: specified in cntlm.ini (default is 3128)
wms_proxy_type: http or socks5 etc
With luck, once you have cntlm configured correctly, your external WMS layer should display just fine!
If when seeding your tilecache you receive “bad gateway” errors, or inexplicably corrupted tiles, it’s possible that the tilecache_seed.py script is also being blocked by the proxy server on your network. Somewhat counter-intuitively (at least it seems that way at first), this can be easily circumvented by switching off the proxy settings in Internet Explorer on the machine you’re running the script on (and switching back on once the script completes successfully). Note that it has to be Internet Explorer- you’ll need another approach if that’s not installed.
The reason for this is that tilecache_seed.py uses the python module urllib2, which uses ProxyHandler to handle proxies (who would have guessed). This will attempt to autodetect proxy settings, and one of the options it checks is in Internet Explorer (I guess this equates to a registry setting somewhere but we don’t go digging in the registry without our vaccinations up to date and all our affairs in order, do we?). A longer term solution might be to extend the tilecache_seed.py script to explicitly set up a ProxyHandler with no proxies defined, as in this example.