Aside: I should say that what follows is not what we normally do in our real applications – we usually use ASP.Net .ashx handlers to relay requests through the root of our web sites, which also helps to avoid cross-domain problems with GetFeatureInfo responses and WFS, but that’s another story! This post is in reaction to Dennis’s request for help, and because I wanted to check this approach is viable.

I’ve posted before on how to use URL Rewrite to give GeoServer a friendly URL on IIS, and we’re going to use the same technique here, so first ensure you have the necessaries installed.

You should also already have a working WMS/WFS – we created this one in the previous post:

http://mapservertest.esdm.co.uk/scripts/mapserv.exe?map=D:\Websites\mapservertest\map\mapfiletest.map

which was fine, but a) the URL reveals some information about the structures on the web server, and b) the URL is a bit ugly.

So decide what address you want for your MapServer service (remembering this will be specific right down to the map file). I’m using “mapservertestwrapper.esdm.co.uk” which I have pointed at the web server in question.

Create a new web site in IIS with this URL as a host header (you’ll first need to create an empty “physical” folder for the site to point at – add a readme.config file explaining what it’s for).

Now open URL Rewrite and create a reverse proxy inbound rule, entering the real service address as the forwarding address:

OK now we should be able to see our MapServer on the new URL. However, when we visit http://mapservertestwrapper.esdm.co.uk/ we get this feedback in the browser:

msLoadMap(): Regular expression error. MS_DEFAULT_MAPFILE_PATTERN validation failed. msEvalRegex(): Regular expression error. String failed expression test.

The fix is to re-edit the inbound rule, and remove the final “/” in the “rewrite URL”, going from:

http://mapservertest.esdm.co.uk/scripts/mapserv.exe?map=D:\Websites\mapservertest\map\mapfiletest.map/{R:1}

to:

http://mapservertest.esdm.co.uk/scripts/mapserv.exe?map=D:\Websites\mapservertest\map\mapfiletest.map{R:1}

Now we should get sensible MapServer feedback in the browser (conditioned by a template specified in the map file).

Now let’s see if we can do a GetCapabilities request… turns out our URL has to be this:

http://mapservertestwrapper.esdm.co.uk/?service=wms&version=1.3.0&request=getcapabilities

Yes it works, but a) that’s a slightly odd URL with “/?”, and b) the response contains the original service addresses, again revealing information about our server.

To fix a), we go back and edit our inbound rule again, and change the “pattern” from “(.*)” to “map1(.*)” (without the quotes of course). Now our service URL becomes:

http://mapservertestwrapper.esdm.co.uk/map1?service=wms&version=1.3.0&request=getcapabilities

Ah yes that’s much nicer, and now of course we see we can manage lots of .map files within one web site simply by setting up in inbound rule for each, with an appropriate pattern and target.

To fix b) we can edit the metadata in the .map file to set this:

"wms_onlineresource"    "http://mapservertestwrapper.esdm.co.uk/map1"

This works fine, returning this within the GetCapabilities:

<OnlineResource xlink:href="http://mapservertestwrapper.esdm.co.uk/map1?" xmlns:xlink="http://www.w3.org/1999/xlink"/>

And I can confirm this creates a working map in QGIS, with map requests like this visible in Fiddler:

http://mapservertestwrapper.esdm.co.uk/map1?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&BBOX=52801.44371538766426966,3347.3560407145996578,657116.82161524775438011,428145.51874091033823788&CRS=EPSG:27700&WIDTH=1020&HEIGHT=717&LAYERS=grid&STYLES=&FORMAT=image/png&DPI=96&MAP_RESOLUTION=96&FORMAT_OPTIONS=dpi:96&TRANSPARENT=TRUE

And a quick test shows that info clicking (GetFeatureInfo) and legends work too:

e.g. http://mapservertestwrapper.esdm.co.uk/map1?version=1.3.0&service=WMS&request=GetLegendGraphic&sld_version=1.1.0&layer=grid&format=image/png&STYLE=default

gives this:

There you go Dennis, we have working OGC services from MapServer with nice clean URLs, a simple architecture for adding new services with their own map files, and no leaking of details about our directory structures.

Footnote…

I’m not completely keen on the last bit, having to change the wms_onlineresource, as this means the original service is now broken (depending on whether the mapping client makes us of this, which QGIS likes to). Another way should be  to create an outbound URL Rewrite rule to rewrite any references to the original URL with the new one. However, after a bit of pfaffing with this, I’m pretty sure there’s a bug in URL Rewrite that means outbound rewriting doesn’t work for attributes containing colons, and ours is “xlink:href”. Incidentally setting up the outbound rules for custom tags is a bit of an adventure through the UI, and there is a bit of escaping to do for the backslashes and question mark in the URL (highlighted below) as URL Rewrite is doing regular expressions so you might as well get down and dirty in the web.config located in the “dummy” folder we created for the new web site we created earlier. So this is my outbound rule that doesn’t work, but should when someone fixes the bug!

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule2" stopProcessing="true">
                    <match url="map1(.*)" />
                    <action type="Rewrite" url="http://mapservertest.esdm.co.uk/scripts/mapserv.exe?map=D:\Websites\mapservertest\map\mapfiletest.map{R:1}" />
                </rule>
            </rules>
            <outboundRules>
                <rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsXML" enabled="true">
                    <match filterByTags="CustomTags" customTags="OGC GetCapabilities" pattern="^http(s)?://mapservertest.esdm.co.uk/scripts/mapserv.exe\?map=D:\\Websites\\mapservertest\\map\\mapfiletest.map(.*)" />
                    <action type="Rewrite" value="http{R:1}://mapservertestwrapper.esdm.co.uk/map1{R:2}" />
                </rule>
                <preConditions>
                    <preCondition name="ResponseIsHtml1">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    </preCondition>
                    <preCondition name="ResponseIsXML">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/xml" />
                    </preCondition>
                </preConditions>
                <customTags>
                    <tags name="OGC GetCapabilities">
                        <tag name="OnlineResource" attribute="xlink:href" />       
                    </tags>
                </customTags>
            </outboundRules>
        </rewrite>
    </system.webServer>
</configuration>

The red bit is the bit affected by the bug I think, unless someone can point out how this should be escaped/expressed to make it work?

java.lang.RuntimeException: java.io.IOException java.io.IOException null Invalid column name 'VALI, ROW_NUMBER() OVER (ORDER BY CURRENT_TIMESTAMP) AS _GT_ROW_NUMBER DFROM'.

I eventually discovered that the cause is having a field name containing the string "FROM". Specifically, I had

...t3.VALID_FROM AS VALIDFROM , t3.VALID_TO AS VALIDTO,...

This suggests some pretty sloppy SQL parsing in GeoServer, and for the moment I've resolved this by changing my alias to VALID_STARTDATE.

1. the WMS request should include this on the KVP URL: &tiled=true
2. the client should construct its tile requests so that they match the server tiles – this is not the place for elaboration, but essentially this means getting the origin and tile size correct
3. the GeoServer must have “Enable direct integration with GeoServer WMS” switched on.

The setting in #3 is found under Tile Caching > Caching Defaults in the main GeoServer menu. Set it once, and forget it. Or so I thought.

How do we know if the WMS is using its cache? Insect the http requests in Fiddler (or similar) and check the headers of the responses.

If the WMS is using its cache you will see lines in the headers like this

geowebcache-cache-result: HIT

along with various other geowebcache-… values

If it knows it has a cache, but something is wrong with the WMS requests (item #2 above), you might see headers like this:

geowebcache-miss-reason: request does not align to grid(s) 'OSGB27700'
geowebcache-cache-result: MISS

And if the WMS is unaware it even has a cache of tiles at all, you will see nothing about geowebcache at all in the headers. And of course, poor WMS performance may give you a clue something is not working as you hoped.

Well I had set everything up lovely and my cache was working well, giving super fast performance of my Ordnance Survey mapping once the initial requests had populated the cache for an area.

But the very next day… performance was rubbish, and on inspecting the http headers, it turned out the WMS had forgotten about its cache.

In the GeoServer admin interface, the “Enable direct integration with GeoServer WMS” was now set to false. Grrr – I wondered how I could stupidly have switched that off again. Ah well, switch it on again and move on.

A few hours later… same again. This time I started suspecting colleagues, but there was no evidence, or motive, yet…

A couple more times, and I realised it was reverting after any re-start of GeoServer. I had been restarting every now and then, to make sure changed wrapper log settings etc. stuck, but it turned out this had been un-sticking my essential cache setting.

The solution turned out to be to edit the gwc-gs.xml file, found in the GeoServer data directory, and set this:

  <directWMSIntegrationEnabled>true</directWMSIntegrationEnabled>

In my data dir, there was a gwc-gs.xml.tmp file, and I can only assume GeoServer had always failed to update the main XML file for some reason, used the .tmp version for the duration of the session, then reverted to the main one upon a re-start.

Now my cached WMS layers run nice and fast, and GeoServer doesn’t forget the setting.

• Add new class
• Use new class

New class

   // A control class for capturing click events...

   OpenLayers.Control.Click = OpenLayers.Class(OpenLayers.Control, {
       defaultHandlerOptions: {
           'single': true,
           'double': true,
           'pixelTolerance': 0,
           'stopSingle': false,
           'stopDouble': false
       },
       handleRightClicks: true,
       initialize: function (options) {
           this.handlerOptions = OpenLayers.Util.extend(
             {}, this.defaultHandlerOptions
           );
           OpenLayers.Control.prototype.initialize.apply(
             this, arguments
            );
           this.handler = new OpenLayers.Handler.Click(
             this, this.eventMethods, this.handlerOptions
           );
       },
       CLASS_NAME: "OpenLayers.Control.Click" 
   });

Use it

    // Add an instance of the Click control that listens to various click events:

    var oClick = new OpenLayers.Control.Click({ eventMethods: {
        'rightclick': function (e) {
            //the infotool has already been added to the map so lets use it!  No need to fuff about and do the request ourselves is there?
            infoTool.request(e.xy);
        }
    }
    });
    map.addControl(oClick);
    oClick.activate();

Our HTTP inspection tool of choice is of course Fiddler, however if you open this while using QGIS to connect to a web service, you see… nothing. So you need to tell QGIS to pass requests through a proxy, using Host = localhost and Port 8888 as shown below:

QGIS menu Settings > Options > Network:

Requests now start appearing in Fiddler.

However, there’s a small gotcha… once set into this mode, requests fail entirely if Fiddler is not running.  A WMS will simply fail to draw, and connecting to a WMS server gives this error:

Could not understand the response. The wms provider said:

Download of capabilities failed: Connection refused

This cost me half an hour this morning, having forgotten that I had set QGIS into this mode a few days ago, grrr.  Here we are after I’d remembered the solution, showing a WMS of archaeological sites recorded by the National Trust, in Snowdonia, Wales.