Error for unsupported services is confusing (bug 2025)

[Frank Warmerdam]

Daniel Morissette wrote:
> Kralidis,Tom [Burlington] wrote:
>>>
>>> Perhaps the best compromise would be to add a test at the end of
>>> msOWSDispatch() to return a meaningful error message if a known 
>>> service name was requested but the request was not handled by any of 
>>> the dispatch functions (i.e. likely because the specified service was 
>>> not compiled in). If service contained any other value (not a 
>>> recognized service name) then msOWSDispatch() would return normally 
>>> and let the traditional CGI code kick in.
>>>
>>
>> But, if service == not a recognized service name, shouldn't an OGC
>> exception be returned in lieu of CGI mode kicking in?  The fact that
>> service=foo was passed (IMHO) would mean that the client is in an OGC
>> mode of some sort.
>>
> 
> That's also an option and if the keyword was OWSSERVICE or something 
> OGC-specific I would have no problem with that, but since SERVICE is a 
> very generic keyword I'm not sure if it's okay to assume that any 
> request with SERVICE in it is an OWS request. At a minimum we'd need to 
> document in the mapserv CGI docs that mapserv CGI templates cannot 
> contain form fields called SERVICE as this would conflict with the OWS 
> support in MapServer.

Folks,

My original thought was closer to Tom's, but I'm also quite cautious in
some things, so I think I'll still with Daniel's approach of only issuing
an error on known OGC SERVICE=value combinations instead of any unrecognised
SERVICE value.

Are there any OGC services that I should treat similarly beyond WMS, WFS,
WCS, and SOS?

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org