Error for unsupported services is confusing (bug 2025)

[Frank Warmerdam]

Frank Warmerdam wrote:
> 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?

Folks,

OK, this turned out to be messier than I expected due to issues with
putting out error messages at different levels of the code.  My summary
of the changes made is:

"""
It turns out that the functions msWMSDispatch(), msWFSDispatch() and
so forth are always compiled in even if the service is not available, and
these functions issue an appropriate error in that case.

So I modified msOWSDispatch() to actually call them unconditionally.

However, for mapserv.c to know whether it was supposed to report the error
to stdout I had to modify all the OWS services exception methods to
clear the error stack after issuing exceptions.  An error still left
on the stack after msOWSDispatch() returns gets reported by mapserv.c
now.

This is a sort of risky change!  We never used to require the exceptions
functions to clear the error stack, so I am worried there could be
some sort of surprising side effect.  I'm not quite sure what though.


Files affected: mapserv.c, mapows.c, mapwfs.c, mapwms.c, mapwcs.c, mapogcsos.c

Changes only in development head ... way to risky to backport.
"""

Please keep this change in mind if encountering error OWS error reporting
issues in dev-head.

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