add mode=ows functionality

[tomkralidis]

Propagated by #2512, OGC CITE tests require the SERVICE parameter to be passed. If not passed or invalid, an ExceptionReport is expected.

The problem here is that MapServer supports more than just OWS approaches from the CGI interface. So while not valid for OWS, it is valid for CGI MapServer.

Here is what everyone seemed to agree upon:

""" I agree with Daniel. Making 'mode=ows' a static part of the OnlineResource URL is probably the best way to be OGC-compliant with the least impact on your existing code base. --- Raj

On Feb 27, 2008, at 4:39 PM, Daniel Morissette wrote:

Norm, I think for the mode=ows vendor-specific parameter to work it needs to be included in the onlineresource of all services (i.e. in the GetCapabilities response), and then your question should really be: "Is there any problem with a server including a 'mode=ows' vendor-specific parameter in the onlineresource that it advertizes in GetCapabilities for all its services?" Since the onlineresource is the base URL string which is used as-is by the client to connect to the service then I can't imagine that there would be any problem with that, a server should be allowed to put anything in the onlineresource URL as long as it's a valid URL and nothing in the base URL conflicts with documented parameters of the relevant OGC spec. Daniel

"""

So we should add "ows" as a valid mode for the mode parameter.

Initial questions:

• incoming requests: when mode=ows (checking msObj->Mode), then msOWSDispatch checks for SERVICE accordingly
• configuration: how do we publish this through a mapfile? Do we set the ows_onlineresource with "mode=ows"? Or do we set WEB/METADATA/ows_pedantic, and this automagically populates the OnlineResource URL when publishing?

[dmorissette]

I'll take this one.

Note that what I propose to do is two things:

1- Add support for mode=ows. If set, then use of OWS services is enforced with all the checks that this implies. If that fails then an OWS exception is produced.

2- Add support for a MS_MODE environment variable that can be used to set the mode in a wrapper script. This would be the preferred way to setup a strictly compliant service.

Well a 3rd point is that MapServer will continue to make reasonable efforts to detect OWS requests if mode is not set. So in real life mode=ows will not be required... this new mode=ows is realy to trigger the strict enforcing of OWS specs when the SERVICE parameter is missing.

To answer Tom's questions, if one uses ows_onlineresource then they need to include mode=ows themselves (or set it through the MS_MODE env. var). I do not plan to revive RFC-35 as part of this.

[dmorissette]

FYI I am still working on this on and off. Handling the exception requirements of OWS Common is much more complicated than I thought, that and dealing with the the ms*Dispatch() functions which all trigger their own exceptions in various circumstances is a "fun" exercise.

For instance, OWS Common wants us to produce an exception if SERVICE and/or REQUEST are missing, but WMS 1.0.0 didn't have the SERVICE param, so we need to let msWMSDispatch() do its checks first before enforcing the OWS Common requirements. Then there are some specs that use XML POST encoding for the request, each of them in their own format, so we cannot only look for SERVICE and REQUEST in the HTTP GET KVP params at the beginning of msOWSDispatch(), we also need to worry about XML POST requests. What a mess!

[tomkralidis]

I would initially say process the older specs first, but then msOWSDispatch doesn't work that way (i.e. works by spec type, as opposed to version).

Let me know if you need any help or testing here.

[dmorissette]

I have committed a first pass at implementing mode=ows in r7549 However, the changes have little effect because the dispatch function for WFS currently produces an error if service is missing, which it should not... the checks on service need to be moved up to msOWSDispatch for the new mode to really work.

We'll also need a proper OWS Exception handler that's callable from msOWSDispatch().

Stay tuned...

[dmorissette]

To be continued in 5.4

[tomkralidis]

Dan: here's a first pass at all the WxS Server specs we support (or will support [WMS 1.3.0]). Let me know if I'm missing anything:

Spec	SERVICE	REQUEST	VERSION	XML POST	Does MapServer support XML POST?
WMS 1.0.0	non-existent	required	required (as WMTVER)	no	no
WMS 1.1.0	required for GetCapabilities, not specified for GetMap/GetFeatureInfo	required	optional for GetCapabilities, required for GetMap/GetFeatureInfo	no	no
WMS 1.1.1	required for GetCapabilities, not specified for GetMap/GetFeatureInfo	required	optional for GetCapabilities, required for GetMap/GetFeatureInfo	no	no
WMS 1.3.0	required for GetCapabilities, not specified for GetMap/GetFeatureInfo	required	optional for GetCapabilities, required for GetMap/GetFeatureInfo	optional	not yet
WFS 1.0.0	required for GetCapabilities, DescribeFeatureType, GetFeature	required	optional for GetCapabilities, required for DescribeFeatureType, GetFeature	yes	yes
WFS 1.1.0	optional for GetCapabilities, DescribeFeatureType, GetFeature	required	optional for GetCapabilities, DescribeFeatureType, GetFeature	yes	yes
WCS 1.0.0	required for GetCapabilities, DescribeCoverage, GetCoverage	required	optional for GetCapabilities, required for DescribeCoverage, GetCoverage	yes	no
WCS 1.1.0	required for GetCapabilities, DescribeCoverage, GetCoverage	required	optional for GetCapabilities, required for DescribeCoverage, GetCoverage	yes	no
SOS 1.0.0	required for GetCapabilities, DescribeSensor, GetObservation	required	optional for GetCapabilities, required for DescribeSensor, GetObservation	yes	yes

[tomkralidis]

P.S. it would be great if someone could verify these as well.

[nsavard]

Daniel, any update on this one?

[assefa]

It would simplify my life (and OCG CITE tests validation) if we could have a predefined modes such as WMS/WFS/SOS and force MapServer to work only in that mode. Is it something that could be useful?

[dmorissette]

I dunno. I would have thought that a mode=ows option should have been sufficient since OGC specs and the CITE engine should not contradict itself. However in practice there may be some cases where it is impossible for the same server to support two OWS specs at the same time and still pass CITE tests. If that's the case then perhaps we should call the option mode=ogccite? ;) ;)

[dmorissette]

Please forgive the useless answer above... some of the issues with the CITE tests kind of put me off and I have no intelligent answer to offer... sorry. Not sure what to suggest.

[assefa]

It is always a battle with some of the CITE tests and can be frustrating for sure :) I face some tests were there is no service (or invalid service), no/invalid version or no/invalid request (this cases are combined) and It is usually expecting an exception. Mode=ows is not for now sufficient to accommodate these tests and also Tom's table above, but I have not checked in detail if It can be by adding few more cases. My head hurts when I work on this so for now I am jumping to cite tests exposing real problems and will come back later and pollute again this bug :)

[assefa]

Couple of correction notes re the table above for WFS:

version:

• wfs 1.0 and 1.1.0 POST request: optional
• wfs 1.0 and 1.1.0 GET request: optional for getcapabilities and required for

describefeatute and getfeature

service

• wfs 1.0 and 1.1.0 GET: required and should be set to WFS
• wfs 1.0 POST: required
• wfs 1.1.1 POST: optional

I think adding mode=WFS/WMS/... seems to be the easiest way to handle things (at least from cite test perspective). I did few test by adding a mode=WFS and dealing with all the cases inside WFSDispatch and that seems to do the trick. Should I go ahead with this approach? Note that I will only do WFS for now.

Mode ows is still preserved as is.

[dmorissette]

I am also starting to think that mode=WFS/WMS/... will be the way to go given the incompatibilities between some of OGC's own specs.

So I say +1 to implement mode=wfs, and if that goes well we can do the others later.

[assefa]

added mode=wfs. Exceptions are returned now properly for WFS. r9942