[Geoserver-devel] Exception handlers and WMS exceptions reported in application/vnd.ogc.se_inimage format

Andrea_Aime3 · May 23, 2008, 4:43pm

Hi,
I'm looking around to see how it would be possible to
support the application/vnd.ogc.se_inimage format for
WMS error reporting.

The interest stems out of the new preview (which I still
haven't commited) and the ability to specify filters in it.
Basically, if you specify a wrong filter, you get back a
blank image with no indication of what was wrong with
the parameters.

Now, the current dispatcher has pluggable exception handlers,
(ServiceExceptionHandler) that answer to the following request:
public abstract void handleServiceException(ServiceException exception, Service service, HttpServletRequest request, HttpServletResponse response);

Applying this to a GetMap request is possible, but not exactly
trivial. The main issue is that in order to build the exception
as an image, I would need to get widht/height and image format...
and this would require parsing. So, can I use the parsing
that the dispatcher already does??? Eh, only sometimes.

I mean, if the exception occurred in the map building, yes,
but that's hardly the case, exceptions often occur in parsing
the request
So, if the request is a GET request, the exception handler would
have to reparse the three params above, hoping the problem was
not there, and if it was a POST request... well in that case
I'd need to reload the xml again in a dom and use xpath to
access the three params needed (that is, an approach that
disregards whatever else may be broken).

Ouch, this is getting complex, but seems doable... besides a bit:
is the exception handler able to get to the XML of a POST once
the dispatcher has already tried to parse it? I have the
impression that would not be possible? If so, I guess I'll
have to give up the GetMap POST request (which is not very
common) and support application/vnd.ogc.se_inimage only in get ones...

Cheers
Andrea

Justin_Deoliveira · May 23, 2008, 5:49pm

Yeah... tough issue. I think we might be able to get around part of this by instead of passing in the request object to the exception handler... passing in the Dispatchers internal Request object, which has the following information:

* HttpServletRequest/Response
* Raw kvp + parsed kvp
* a reader for the body content

Getting the xml in a post is tricky... the requst input stream is buffered, and marked at 2048 bytes. So that up to that can be ready by the dispatcher and then reset for the service processing the request.

So i guess the exception handler could get at the request if the service has not read it already...

Andrea Aime wrote:

Hi,
I'm looking around to see how it would be possible to
support the application/vnd.ogc.se_inimage format for
WMS error reporting.

The interest stems out of the new preview (which I still
haven't commited) and the ability to specify filters in it.
Basically, if you specify a wrong filter, you get back a
blank image with no indication of what was wrong with
the parameters.

Now, the current dispatcher has pluggable exception handlers,
(ServiceExceptionHandler) that answer to the following request:
public abstract void handleServiceException(ServiceException exception, Service service, HttpServletRequest request, HttpServletResponse response);

Applying this to a GetMap request is possible, but not exactly
trivial. The main issue is that in order to build the exception
as an image, I would need to get widht/height and image format...
and this would require parsing. So, can I use the parsing
that the dispatcher already does??? Eh, only sometimes.

I mean, if the exception occurred in the map building, yes,
but that's hardly the case, exceptions often occur in parsing
the request
So, if the request is a GET request, the exception handler would
have to reparse the three params above, hoping the problem was
not there, and if it was a POST request... well in that case
I'd need to reload the xml again in a dom and use xpath to
access the three params needed (that is, an approach that
disregards whatever else may be broken).

Ouch, this is getting complex, but seems doable... besides a bit:
is the exception handler able to get to the XML of a POST once
the dispatcher has already tried to parse it? I have the
impression that would not be possible? If so, I guess I'll
have to give up the GetMap POST request (which is not very
common) and support application/vnd.ogc.se_inimage only in get ones...

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,4836f45e263435219720167!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Andrea_Aime3 · May 23, 2008, 6:05pm

Justin Deoliveira ha scritto:

Yeah... tough issue. I think we might be able to get around part of this by instead of passing in the request object to the exception handler... passing in the Dispatchers internal Request object, which has the following information:

* HttpServletRequest/Response
* Raw kvp + parsed kvp
* a reader for the body content

Getting the xml in a post is tricky... the requst input stream is buffered, and marked at 2048 bytes. So that up to that can be ready by the dispatcher and then reset for the service processing the request.

Friday, almost evening... my head is spinning

Anyways, looks like a good idea, but the Request objects should become
public. If we do that, the same object could also hold the Operation,
that is, accumulate information as it goes, and leave the exception
handlers figure out what they prefer to use.

Yet, is the parsed kvp set if an exception occurs
right during kvp parsing? Even in that case there is no guarantee
I'd get the widht/height/format in parsed format, I'd have to resort
using the kvp parsers manually anyways.... so I would have no
much use Operation or the parsed kvp, thought the raw kvp can be handy.

So i guess the exception handler could get at the request if the service has not read it already...

Yeah, this one too seems useful. So ok, exposing Request seems like
a good path. So, we move it to its own class? And then add getters and setters for all the fields it has?

Cheers
Andrea

Justin_Deoliveira · May 23, 2008, 6:16pm

Friday, almost evening... my head is spinning

Right, you are thinking way to hard for a Friday :).

Anyways, looks like a good idea, but the Request objects should become
public. If we do that, the same object could also hold the Operation,
that is, accumulate information as it goes, and leave the exception
handlers figure out what they prefer to use.

+1

Yet, is the parsed kvp set if an exception occurs
right during kvp parsing? Even in that case there is no guarantee
I'd get the widht/height/format in parsed format, I'd have to resort
using the kvp parsers manually anyways.... so I would have no
much use Operation or the parsed kvp, thought the raw kvp can be handy.

Nope, teh complete parsing of kvp will always happen. Any exceptions that occur are caught, and set on the request object. So you can be sure the kvp's were parsed... but the one you are interested in could have been in err. So I guess some checks will need to be done. But in the normal case things like width and height and format will be fine.

So i guess the exception handler could get at the request if the service has not read it already...

Yeah, this one too seems useful. So ok, exposing Request seems like
a good path. So, we move it to its own class? And then add getters and setters for all the fields it has?

Sounds good to me.

Cheers
Andrea

!DSPAM:4007,48370762304278362916074!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com