SERVICE=WMS vendor specific on GetMap and GetFeatureInfo

[doug@…]

A MapServer WMS service requires SERVICE=WMS on GetMap and GetFeatureInfo
requests if the WFS server is also enabled, but this isn't part of the 1.1.1 WMS
specification for these service types. It is required with GetCapabilities.
Since it is a vendor-specific requirement, and won't be added automatically by
compliant clients, it should be added to the auto generated OnlineResource hrefs
for GetMap and GetFeatureInfo.

Examples:

http://www2.dmsolutions.ca/cgi-bin/mswfs_gmap?SERVICE=WMS&REQUEST=GetCapabilities

... shows OnlineResource as:

<Get><OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://dev1.dmsolutions.ca:80/cgi-bin/mswfs_gmap?"/></Get>

... but a compliant request like this doesn't work:

http://www2.dmsolutions.ca/cgi-bin/mswfs_gmap?VERSION=1.1.1&REQUEST=getmap&layers=park,popplace&STYLES=&SRS=EPSG:4326&BBOX=-173.537,35.8775,-11.9603,83.8009&WIDTH=400&HEIGHT=300&FORMAT=image/png

... but this request does:

http://www2.dmsolutions.ca/cgi-bin/mswfs_gmap?SERVICE=WMS&VERSION=1.1.1&REQUEST=getmap&layers=park,popplace&STYLES=&SRS=EPSG:4326&BBOX=-173.537,35.8775,-11.9603,83.8009&WIDTH=400&HEIGHT=300&FORMAT=image/png

Workaround is to set the online resource in the metadata in your map file so
that it includes SERVICE=WMS. 

I believe that the default OnlineResource in the GetCapabilities response should
 include the SERVICE=WMS. Easy fix.

[doug@…]

The other option is to remove MapServer's requirement for SERVICE=WMS in 
GetMap and GetFeatureInfo altogether. These request types are obviously WMS, 
so there is no ambiguity, which is probably why the specification doesn't 
include them. 
 
-- Doug 

[dmorissette]

I prefer the second option (making the SERVICE=... parameter optional for the
cases where the spec says so). We should avoid vendor-specific exceptions as
much as possible.

[bartvde@…]

Daniel,

I think this is a severe interoperability problem for which the fix ideally
should be included in 4.4.2. Or not?

Bart

[assefa]

looking into this and bug 1302.

[assefa]

 Here is what the specs seems to say :

   - wms 1.1.1 :for WMS requests only getcapabilities requries (manadatory) 
the service parameter. All other do not need to have them.
   - wfs 1.0 : all requests need to have the service parameter and it is fixed 
to be WFS.

 Here is how mapserver works right now (I have tried it with current cvs 
version but should be the same with the 4.4.x releases) :

    - server side : the service parameter is not required for any wms or wfs 
requests 

 Here are the changes I am proposing to do :
   * verfiy that  the service parameter is set for getcapabilities request or 
send exception if it isn't set
   * make sure that other wms requests beside the getcapabilities do not 
require the service parameter
   * verfiy that the service parameter is set for all wfs requests 
  
  These changes tighten up things so previous working implemenations might 
break.

 Any comments before I do the changes ?   

  
 

[dmorissette]

Note to Doug: you suggested that the "SERVICE=WFS" should be automatically
included in the OnlineResource. We cannot do that, this would be illegal.

Doug wrote that MapServer "requires SERVICE=WMS on GetMap and GetFeatureInfo if
WFS is enabled", but Assefa came to the opposite conclusion. Who is right? Was
this fixed without us noticing?

other than that I agree with your proposed fixes Assefa.

[doug@…]

Daniel, 
 
I did not suggest that. I suggested that it could be added to WMS request 
online resource URLs for WMS GetMap and GetFeatureInfo requests. Since 
SERVICE= is not a defined parameter, it would be treated as a vendor specific 
thing and therefore would not be illegal. It would be illegal for a WFS 
request, but that's not what I suggested. 
 
In any case, the solutions suggested by Assefa would fix the problem better 
without requiring a vendor specific parameter. 
 
I haven't tested with a recent version, but it was absolutely the case before. 
It wasn't required unless the map supported both WMS and WFS server access. 
 
Doug  

[doug@…]

 
Try the links in my original message. The error is apparent. 

[assefa]

The link to the demo is using mapserver 4.2 version so It used to be like Doug 
descibed it. But the tests I have done are with recent versions 4.4 and 4.5. 
In any case I will make the changes according to comment #5

[assefa]

Fixed according to comment #5.

Reassign to Jeff if he a note should be added.

[jmckenna@…]

moving to documentation Component

[jmckenna@…]

i have some interesting results while testing these changes (with beta3):

- WFS getcapabilities request without SERVICE parameter does _NOT_ throw exception
- while WFS getfeature request without SERVICE parameter does throw exception

my understanding of this bug is that we now check all WFS requests for the
SERVICE parameter.

for example:

my internal wfs url without service:
http://127.0.0.1/cgi-bin/mapserv.exe?VERSION=1.0.0&REQUEST=getcapabilities

produces what looks like junk, "WMT_MS_Capabilities"? (but not an error):

****
<!-- end of DOCTYPE declaration -->
-
	<WMT_MS_Capabilities version="1.0.0">
-
	<!--
 MapServer version 4.6.0-beta3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP
OUTPUT=PDF OUTPUT=SWF OUTPUT=SVG SUPPORTS=PROJ SUPPORTS=FREETYPE
SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT
SUPPORTS=WCS_SERVER INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL
INPUT=SHAPEFILE DEBUG=MSDEBUG 
-->
-
	<Service>
<Name>GetMap</Name>
-
	<!--
 WARNING: Mandatory metadata '..._title' was missing in this context. 
-->
<Title>DEMO</Title>
<OnlineResource>http://127.0.0.1/cgi-bin/mapserv.exe?</OnlineResource>
</Service>
-
	<Capability>
-
	<Request>
-
	<Map>
-
	<Format>
<GIF/>
...
******

here is my internal WFS getfeature request without service:
http://127.0.0.1/cgi-bin/mapserv.exe?VERSION=1.0.0&REQUEST=getfeature&typename=park

returns what it should:

*****
	<ServiceExceptionReport xsi:schemaLocation="http://www.opengis.net/ogc
http://schemas.opengeospatial.net/wms/1.1.1/OGC-exception.xsd">
-
	<ServiceException>

msWFSDispatch(): WFS server error. Incomplete WFS request: SERVICE parameter missing
  
</ServiceException>
</ServiceExceptionReport>
******

i will update the docs anyway for the service requirement, but to me it looks
like we're not checking for it with wfs getcapabilities.

[jmckenna@…]

wms and wfs docs now mention this service requirement.

[jmckenna@…]

reassigning

[jmckenna@…]

Assefa please see my comment#12.  The docs were already updated, so if you are
ok with my comments at the beginning of comment#12 then we can call this fixed.

[assefa]

Jeff

 Here is what happens : when a request happens, it is passed through the wms,
wfs, wcs (in that order) until one of the services repspond to it.  
 In your case, the request is a valid request as a WMS (since wms 1.0.0 did not
need the service parameter). So you end up having a response. 
 (http://127.0.0.1/cgi-bin/mapserv.exe?VERSION=1.0.0&REQUEST=getcapabilities  )

 If the version was 1.1.0 for example, you would end up having an exception
thrown by the wms parsing code.

 Not sure if that is a bug or simply a side effect on how things are implemented.

I hope I ame sense.

 

[jmckenna@…]

thanks.  i've added a small note in the wms/wfs server docs about the order of
the requests.

(looking at the wcs server doc i think i will convert it to restructured text
and add some descriptions & examples, including the same note..opened bug#1604
for this)