Opened 16 years ago
Last modified 15 years ago
#2512 new defect
A GetCapabilities issue to a SOS 1.0.0 server with no service parameter must trigger an OWS 1.0.0 exception
Reported by: | nsavard | Owned by: | tomkralidis |
---|---|---|---|
Priority: | normal | Milestone: | 6.0 release |
Component: | SOS Server | Version: | svn-trunk (development) |
Severity: | normal | Keywords: | OGC, CITE, TEAM, SOS 1.0.0 |
Cc: | sdlime, warmerdam, assefa, dmorissette |
Description
When a GetCapabilities request is sent to a SOS 1.0.0 server with no service parameter, the response must be an OWS 1.0.0 exception.
Actually a WFS 1.0.0 exception. The test try to validate against the schema found here:
http://schemas.opengis.net/ows/1.0.0/owsExceptionReport.xsd
The concerned test is: owsTests:ows-OWS.GetCapabilities-Exceptions.1 (s0003)
and the request is: http://dev1.lan.mapgears.com/manwe/cgi-bin/mssos100_ogc_cite?version=1.0.0&request=GetCapabilities
Change History (15)
comment:1 by , 16 years ago
Cc: | added |
---|
follow-up: 3 comment:2 by , 16 years ago
I don't see a workaround for this one. Why does SOS have this requirement on not other OWS specs?
Steve
follow-up: 4 comment:3 by , 16 years ago
Replying to sdlime:
I don't see a workaround for this one. Why does SOS have this requirement on not other OWS specs?
Steve
Steve: I agree.
Norm: does this type of assertion occur in CITE for WMS? I believe you have done tests which passed for WMS 1.1.1, so I'm wondering how this was dealt with there.
comment:4 by , 16 years ago
Replying to tomkralidis:
Replying to sdlime:
I don't see a workaround for this one. Why does SOS have this requirement on not other OWS specs?
Steve
Steve: I agree.
Norm: does this type of assertion occur in CITE for WMS? I believe you have done tests which passed for WMS 1.1.1, so I'm wondering how this was dealt with there.
Tom: I don't remember to have seen a test like that in any of the OWS before.
comment:5 by , 16 years ago
Can you ask CITE what we should do about this? Because we support more than OWS, we can't restrict in this manner.
comment:6 by , 16 years ago
Perhaps we could add a "mode=ows" vendor-specific CGI parameter that would force treating a given request as a OWS request, this mode param could be included in the onlineresource in the capabilities and unless I'm mistaken that would allow us too bypass the CGI and pass all those tests.
We could also add support for a MS_MODE environment variable that could be set inside a wrapper script or in Apache config to any of the valid mode values and could be used as an alternative to the mode=ows CGI param to force MapServer to act as a OWS. This would be used the same way we use MS_MAPFILE already today in WMS wrapper scripts, see http://mapserver.gis.umn.edu/docs/howto/wms_server/#more-about-the-online-resource-url
follow-up: 10 comment:7 by , 16 years ago
Daniel: good idea. Would there be more cases where we would need this other than CITE? Norm: can you check w/ CITE w.r.t. what their position is on service URLs submitted to CITE which support over and above the OGC standards (like MapServer)?
follow-up: 9 comment:8 by , 16 years ago
The CITE tests allow you to *require* a vendor specific parameter? I'm ok with the idea it just seems like a workaround for a silly requirement for SOS.
Steve
comment:9 by , 16 years ago
Replying to sdlime:
The CITE tests allow you to *require* a vendor specific parameter? I'm ok with the idea it just seems like a workaround for a silly requirement for SOS.
Steve
So long as it's part of the server base URL, it's fine. We'll see if we really need to do this before moving ahead.
comment:10 by , 16 years ago
Replying to tomkralidis:
Daniel: good idea. Would there be more cases where we would need this other than CITE? Norm: can you check w/ CITE w.r.t. what their position is on service URLs submitted to CITE which support over and above the OGC standards (like MapServer)?
I'll check.
comment:11 by , 16 years ago
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
"""
Daniel: should we open another ticket just for the implementation of this addition?
comment:12 by , 16 years ago
Yes, I think a separate ticket would be better, then the approach can be discussed in a single place and all tickets with related issues can refer to it in their 'fixed' comment.
comment:14 by , 16 years ago
Milestone: | 5.2 release → 5.4 release |
---|
comment:15 by , 15 years ago
Milestone: | 5.4 release → 6.0 release |
---|
This one is tough. If no SERVICE= is passed, that doesn't necessarily constitute an ExceptionReport, because MapServer offers up CGI mode as well.
CC'ing the other WxS folks on comments here.