Ticket Navigation

Ticket #2531 (assigned defect)

Opened 6 months ago

Last modified 2 months ago

add mode=ows functionality

Reported by:	tomkralidis	Assigned to:	dmorissette (accepted)
Priority:	normal	Milestone:	5.4 release
Component:	MapServer CGI	Version:	svn-trunk (development)
Severity:	normal	Keywords:
Cc:	warmerdam,assefa,sdlime,dmorissette,bartvde@osgis.nl

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

02/28/08 13:21:22 changed by dmorissette

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.

03/26/08 17:09:12 changed by 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!

Download in other formats: