Opened 19 years ago
Closed 18 years ago
#1262 closed defect (fixed)
SERVICE=WMS vendor specific on GetMap and GetFeatureInfo
Reported by: | Owned by: | mapserverbugs | |
---|---|---|---|
Priority: | high | Milestone: | 4.6 release |
Component: | Documentation - MapServer | Version: | unspecified |
Severity: | major | Keywords: | |
Cc: | jmckenna@…, bartvde@… |
Description
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.
Change History (18)
comment:2 by , 19 years ago
Milestone: | → 4.6 release |
---|
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.
comment:3 by , 19 years ago
Cc: | added |
---|
Daniel, I think this is a severe interoperability problem for which the fix ideally should be included in 4.4.2. Or not? Bart
comment:5 by , 19 years ago
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 ?
comment:6 by , 19 years ago
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.
comment:7 by , 19 years ago
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
comment:9 by , 19 years ago
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
comment:10 by , 19 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Fixed according to comment #5. Reassign to Jeff if he a note should be added.
comment:11 by , 19 years ago
Component: | WMS Server → MapServer Documentation |
---|
moving to documentation Component
comment:12 by , 19 years ago
Status: | new → assigned |
---|
comment:13 by , 19 years ago
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.
comment:16 by , 18 years ago
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.
comment:17 by , 18 years ago
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.
comment:18 by , 18 years ago
Cc: | added |
---|---|
Resolution: | → fixed |
Status: | new → closed |
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)
Note:
See TracTickets
for help on using tickets.