Opened 14 years ago

Last modified 12 years ago

#2531 assigned defect

add mode=ows functionality

Reported by: tomkralidis Owned by: dmorissette
Priority: normal Milestone: 6.0 release
Component: MapServer CGI Version: svn-trunk (development)
Severity: normal Keywords:
Cc: warmerdam, assefa, sdlime, dmorissette, bartvde@…

Description

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?

Change History (16)

comment:1 by dmorissette, 14 years ago

Owner: changed from sdlime to 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.

comment:2 by dmorissette, 14 years ago

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!

comment:3 by tomkralidis, 14 years ago

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.

comment:4 by dmorissette, 14 years ago

Status: newassigned

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...

comment:5 by dmorissette, 14 years ago

Milestone: 5.2 release5.4 release

To be continued in 5.4

comment:6 by tomkralidis, 13 years ago

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:

SpecSERVICEREQUESTVERSIONXML POSTDoes MapServer support XML POST?
WMS 1.0.0non-existentrequiredrequired (as WMTVER)nono
WMS 1.1.0required for GetCapabilities, not specified for GetMap/GetFeatureInforequiredoptional for GetCapabilities, required for GetMap/GetFeatureInfonono
WMS 1.1.1required for GetCapabilities, not specified for GetMap/GetFeatureInforequiredoptional for GetCapabilities, required for GetMap/GetFeatureInfonono
WMS 1.3.0required for GetCapabilities, not specified for GetMap/GetFeatureInforequiredoptional for GetCapabilities, required for GetMap/GetFeatureInfooptionalnot yet
WFS 1.0.0required for GetCapabilities, DescribeFeatureType, GetFeaturerequiredoptional for GetCapabilities, required for DescribeFeatureType, GetFeatureyesyes
WFS 1.1.0optional for GetCapabilities, DescribeFeatureType, GetFeaturerequiredoptional for GetCapabilities, DescribeFeatureType, GetFeatureyesyes
WCS 1.0.0required for GetCapabilities, DescribeCoverage, GetCoveragerequiredoptional for GetCapabilities, required for DescribeCoverage, GetCoverageyesno
WCS 1.1.0required for GetCapabilities, DescribeCoverage, GetCoveragerequiredoptional for GetCapabilities, required for DescribeCoverage, GetCoverageyesno
SOS 1.0.0required for GetCapabilities, DescribeSensor, GetObservationrequiredoptional for GetCapabilities, required for DescribeSensor, GetObservationyesyes

comment:7 by tomkralidis, 13 years ago

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

comment:8 by dmorissette, 13 years ago

Milestone: 5.4 release6.0 release

comment:9 by nsavard, 13 years ago

Daniel, any update on this one?

comment:10 by assefa, 12 years ago

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?

comment:11 by dmorissette, 12 years ago

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? ;) ;)

comment:12 by dmorissette, 12 years ago

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.

comment:13 by assefa, 12 years ago

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 :)

comment:14 by assefa, 12 years ago

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.

comment:15 by dmorissette, 12 years ago

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.

comment:16 by assefa, 12 years ago

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

Note: See TracTickets for help on using tickets.