#823 closed defect (fixed)
[MapServer-WMS]Not returning a service exception when srs in GetMap is invalid for some layers
Reported by: | Owned by: | mapserverbugs | |
---|---|---|---|
Priority: | high | Milestone: | 4.4 release |
Component: | WMS Server | Version: | 4.3 |
Severity: | normal | Keywords: | VERIFIED |
Cc: |
Description
When the SRS parameter in a GetMap request contains a SRS that is valid for some, but not all of the layers being requested, then the server shall throw a Service Exception (code = "InvalidSRS"). (see wms/wmsops/getmap/params/srs/4) MapServer WMS needs to satisfy this part of the specification to comply. Actually MapServer is extracting the value of the "SRS" parameter. Then it verifies for each layer appearing in the "layers" parameter of the request, that the projection string is matching the one asked. If not the layer is reprojected. MapServer WMS should at least verify that the projection asked is corresponding to the one within map object. If not MapServer should look for a matching projection within each layer. If the projection asked is not found within a layer object, MapServer shall throw a service exception.
Change History (13)
comment:3 by , 20 years ago
Assuming information in bug description is correct and there is a map file that contains a map object within a specific projection and some layer objects within different projection than the map object (see mswms_ogc_cite_wms_srs map file). MapServer should not throw a service exception when a request is made with a srs parameter which value is corresponding to the projection in the map object or in one of the layers. I copied /path/to/cgi-bin/mswms_ogc_cite to /path/to/cgi-bin/mswms_ogc_cite_srs in which I modified the "MS_MAPFILE" value to point to /path/to/ogc_cite/map/ogc_cite_wms_srs.map and I changed the mapserver executable to "mapserv_assefa". I then copied "ogc_cite_wms.map" to "ogc_cite_wms_srs.map" in which I made the following modifications: advertized projection "EPSG:4326,4318,4319" BasicPolygons layer projection to epsg:4318 MapNeatline layer projection to epsg:4319 I then issued this URL request: http://server/cgi-bin/mswms_ogc_cite_srs?LaYeRs=OGC_CITE& VeRsIoN=1.1.1&ReQuEsT=GetMap&FoRmAt=image/gif&WiDtH=168& BbOx=-0.0042,-0.0024,0.0042,0.0024&HeIgHt=96&StYlEs=&SrS=EPSG:4326 The response to this request is "InvalidSRS".
comment:4 by , 20 years ago
The wms_srs should read "EPSG:4326 EPSG:4318 EPSG:4319" instead of "EPSG:4326,4318,4319". I have changed the demo map file and I get a map.
comment:6 by , 20 years ago
Fixed according to the bug description. I put the validation code under #ifdef OGC_STRICT_MODE. So when building for OGC tests, we need to activate that flag. I will update the windows makefile. Could someone do the same for the other platforms ?
comment:7 by , 20 years ago
Milestone: | → 4.4 release |
---|---|
Status: | new → assigned |
I'll add the -DOGC_STRING_MODEoption to the Unix configure script and Makefiles.
comment:8 by , 20 years ago
Assefa, can we change the compile flag to OWS_STRICT_MODE instead of OGC_STRICT_MODE? I think that would be more accurate since it would mean "OGC Web Services (OWS) Strict Mode".
comment:9 by , 20 years ago
Okay, I changed my mind again. I know I'm probably the one who suggested this strict mode flag, but now that I think about it again, if we have apps that would break because of that exception then we better fix them since they would break on other servers anyway. I mean it's a bad idea to let the server operate in non-strict mode (at least in this case) since that will allow us to build clients that will appear to work, but will fail with other servers that are strictly compliant. So I propose that we remove the Oxx_STRICT_FLAG, and leave this SRS cehck enabled at all times. What do you think Assefa?
comment:10 by , 20 years ago
My fear was that many of already setup wms clients would start breaking up when people upgrade to mapserver 4.4. On the other hand, if we aim mapserver 4.4 to be ogc compliant, It is the best time to intrduce that and people would understand the needs for this change. I think we should announce it specifically to the list. I was actually writing an e-mail to the list on this when I remebered that we decided to put a compiling flag, so It never went out. All this to say that I also think we should remove it.
comment:11 by , 20 years ago
Well,when I was working on this yesterday I realized that (1) that would probably not affect our client apps since it is MapServer that generates the GetMap requests, and MapServer already does the right thing (it won't request a SRS that's not supported for a given layer), and (2) *if* we or someone else happens to have any client app that doesn't handle SRS properly, then it would probably not work with WMS servers from other vendors anyway, so making them break now is just a good thing for interoperability anyway. I agree that a mail to mapserver-dev couldn't hurt, but I don't think that's as big an issue as I initially thought. So are you going to remove the #ifdef or should I do it? Also, a note about this new exception should be added to HISTORY.TXT
comment:12 by , 20 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I removed the ifdef and updated the History.txt. E-mail sent to mapserver-dev. Marking it as fixed.
comment:13 by , 20 years ago
Keywords: | VERIFIED added |
---|
Verified on Fedora Core 2. I check the "HISTORY.TXT" too.
Note:
See TracTickets
for help on using tickets.