[Geoserver-devel] Returning proper HTTP error codes: epic failure?

GeoServer GeoServer Developer
1

Hi,
tried implement the OWS 2.0 policy of returning proper HTTP status
codes when a service exception is returned.

The patch attached to http://jira.codehaus.org/browse/GEOS-4255
has the basics of it:
- a new class to represent the ows error code and its correspondent
  status code
- changed service exception
- changed the wps module to use the new code class as an example
- made the service exception handlers set the status code
  (start the JVM with -DOWS10_HTTP_ERROR_CODES=true to have
   the codes set on WMS/WFS)

Now, what's wrong with it? Well, it basically makes debugging from
a browser impossible.
When a 500 or a 400 is set as the status code without also setting
the content type to html the browser just says that the web page is
not there, and does not offer to download the service exception
at all!
This basically means you have to use a non browser client,
such as "curl", to actually get the error message. Which is ridicolous.

In order to get anything to display HTTPServletResponse.sendError(code, message)
can be used, but at that point the container sets the content type to
html and builds a little web page around the message, disallowing
to use any other content type or... content.

I hope there is some workaround, otherwise this seemingly good
idea is going to turn into a tragedy (and one we won't be able
to avoid since OWS 2.0 will be the base for future specs...)

Suggestions, fixes to my eventually broken understanding,
moral support... all greatly appreciated...

Cheers
Andrea

--
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

2

moral support, at the very least :slight_smile:

I'll forward it on to the OGC as well - and see if I can get a
response. There is an emerging discussion on HTTP protocol and
browser-friendliness...

Rob

On Sat, Dec 11, 2010 at 6:18 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

Hi,
tried implement the OWS 2.0 policy of returning proper HTTP status
codes when a service exception is returned.

The patch attached to http://jira.codehaus.org/browse/GEOS-4255
has the basics of it:
- a new class to represent the ows error code and its correspondent
status code
- changed service exception
- changed the wps module to use the new code class as an example
- made the service exception handlers set the status code
(start the JVM with -DOWS10_HTTP_ERROR_CODES=true to have
the codes set on WMS/WFS)

Now, what's wrong with it? Well, it basically makes debugging from
a browser impossible.
When a 500 or a 400 is set as the status code without also setting
the content type to html the browser just says that the web page is
not there, and does not offer to download the service exception
at all!
This basically means you have to use a non browser client,
such as "curl", to actually get the error message. Which is ridicolous.

In order to get anything to display HTTPServletResponse.sendError(code, message)
can be used, but at that point the container sets the content type to
html and builds a little web page around the message, disallowing
to use any other content type or... content.

I hope there is some workaround, otherwise this seemingly good
idea is going to turn into a tragedy (and one we won't be able
to avoid since OWS 2.0 will be the base for future specs...)

Suggestions, fixes to my eventually broken understanding,
moral support... all greatly appreciated...

Cheers
Andrea

--
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

On Sat, Dec 11, 2010 at 12:00 AM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

moral support, at the very least :slight_smile:

I'll forward it on to the OGC as well - and see if I can get a
response. There is an emerging discussion on HTTP protocol and
browser-friendliness...

Yeah. So far I've tested with WMS 1.1 since it was the handy one to test
and it was late, want to check out with protocols that return text/xml as the
mime type for the error.

What I've seen so far is that 500 + html and image/png are showing up
the contents, so maybe 400 or 500 do show the result in the browser
if and only if the browser can handle them internally (which of course
does not work for the funky WMS 1.1 exception mime type).

It may also be browser dependent behavior... sigh

As for "emerging discussion on HTTP protocol and browser friendliness..."
ouch, how has that possibly been off the table until now? :-o

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

4

On Sat, Dec 11, 2010 at 8:53 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Sat, Dec 11, 2010 at 12:00 AM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

moral support, at the very least :slight_smile:

I'll forward it on to the OGC as well - and see if I can get a
response. There is an emerging discussion on HTTP protocol and
browser-friendliness...

Made a bit more tests, the results are really not looking good.
The pastures are green for those that use a browser worthy of thy name
and recent OGC service versions, but for everyone else an unusable
debugging experience is there waiting for us to enable http error codes
in responses.

My last hope is that I may have did something stupid in how I set the
http status.
Currently I just use HTTPServletResponse.setStatus(int) and then
write out the service exception.
The only alternative I see would be to use
HTTPServletResponse.sendError(int, message), but by javadoc
that sets the content type to html and builds a small html page
around the error message.
Anyways, if anyone has ideas the patch is here:
http://jira.codehaus.org/browse/GEOS-4255

It's probably time to start thinking about workarounds here, since
all IE versions I tried fail to deliver any meaningful error back.
Ideas:
- set a custom header like ogcHttpStatus instead? That would
  break OWS 2.0 compliance, but at the same not sure what
  service out there is using OWS 2.0.
  WCS 2.0 and WFS 2.0 maybe? Not sure
  This work around should still make monitoring statistics software
  life easier
- the above plus browser detection: if the client is a known to be
  broken one (that is, IE) set the status to 200 nevertheless.
  At least the well behaved part of the internet can have proper
  status codes with the newer OGC services

Opinions?

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

5

Hi all,

I don’t know how relevant it is to the discussion but IE definitely has specialized handing for non 200 responses and there are various ways to overcome the browser’s “friendly” error pages. Take a look at http://support.microsoft.com/kb/294807. It is somewhat kludgy but we have always made sure that our error pages were large enough that IE would use them instead of substituting their own friendly pages. I wouldn’t be too surprised if other browser vendors took similar approaches.

Eli

On Sat, Dec 11, 2010 at 7:18 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sat, Dec 11, 2010 at 8:53 AM, Andrea Aime

<andrea.aime@anonymised.com> wrote:

On Sat, Dec 11, 2010 at 12:00 AM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

moral support, at the very least :slight_smile:

I’ll forward it on to the OGC as well - and see if I can get a
response. There is an emerging discussion on HTTP protocol and
browser-friendliness…

Made a bit more tests, the results are really not looking good.
The pastures are green for those that use a browser worthy of thy name
and recent OGC service versions, but for everyone else an unusable
debugging experience is there waiting for us to enable http error codes
in responses.

My last hope is that I may have did something stupid in how I set the
http status.
Currently I just use HTTPServletResponse.setStatus(int) and then
write out the service exception.
The only alternative I see would be to use
HTTPServletResponse.sendError(int, message), but by javadoc
that sets the content type to html and builds a small html page
around the error message.
Anyways, if anyone has ideas the patch is here:

http://jira.codehaus.org/browse/GEOS-4255

It’s probably time to start thinking about workarounds here, since
all IE versions I tried fail to deliver any meaningful error back.
Ideas:

  • set a custom header like ogcHttpStatus instead? That would
    break OWS 2.0 compliance, but at the same not sure what
    service out there is using OWS 2.0.
    WCS 2.0 and WFS 2.0 maybe? Not sure
    This work around should still make monitoring statistics software
    life easier
  • the above plus browser detection: if the client is a known to be
    broken one (that is, IE) set the status to 200 nevertheless.
    At least the well behaved part of the internet can have proper
    status codes with the newer OGC services

Opinions?

Cheers
Andrea

Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

***************************************************
The information contained in this e-mail message 
is intended only for the use of the recipient(s) 
named above and may contain information that is 
privileged, confidential, and/or proprietary. 
If you are not the intended recipient, you may not
review, copy or distribute this message. If you have
received this communication in error, please notify 
the sender immediately by e-mail, and delete the original message.
***************************************************
6

The following from that URL looks like a nice and non invasive way of
working around that for IE if you change "ISAPI filter" by "Servlet
filter":

"Method 3
Use an ISAPI filter that forces the content length of all HTTP 500
responses to be larger than 512 bytes, effectively padding all 500
responses so that they are large enough to override the "friendly" error
setting in Internet Explorer 5.x and 6.x...."

On Sat, 2010-12-11 at 09:59 -0500, Eli Miller wrote:

Hi all,

I don't know how relevant it is to the discussion but IE definitely
has specialized handing for non 200 responses and there are various
ways to overcome the browser's "friendly" error pages. Take a look at
http://support.microsoft.com/kb/294807. It is somewhat kludgy but we
have always made sure that our error pages were large enough that IE
would use them instead of substituting their own friendly pages. I
wouldn't be too surprised if other browser vendors took similar
approaches.

Eli

On Sat, Dec 11, 2010 at 7:18 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
        On Sat, Dec 11, 2010 at 8:53 AM, Andrea Aime
        <andrea.aime@anonymised.com> wrote:
        
        > On Sat, Dec 11, 2010 at 12:00 AM, Rob Atkinson
        <robatkinson101@anonymised.com> wrote:
        >> moral support, at the very least :slight_smile:
        >>
        >> I'll forward it on to the OGC as well - and see if I can
        get a
        >> response. There is an emerging discussion on HTTP protocol
        and
        >> browser-friendliness...
        
        Made a bit more tests, the results are really not looking
        good.
        The pastures are green for those that use a browser worthy of
        thy name
        and recent OGC service versions, but for everyone else an
        unusable
        debugging experience is there waiting for us to enable http
        error codes
        in responses.
        
        My last hope is that I may have did something stupid in how I
        set the
        http status.
        Currently I just use HTTPServletResponse.setStatus(int) and
        then
        write out the service exception.
        The only alternative I see would be to use
        HTTPServletResponse.sendError(int, message), but by javadoc
        that sets the content type to html and builds a small html
        page
        around the error message.
        Anyways, if anyone has ideas the patch is here:
        http://jira.codehaus.org/browse/GEOS-4255
        
        It's probably time to start thinking about workarounds here,
        since
        all IE versions I tried fail to deliver any meaningful error
        back.
        Ideas:
        - set a custom header like ogcHttpStatus instead? That would
         break OWS 2.0 compliance, but at the same not sure what
         service out there is using OWS 2.0.
         WCS 2.0 and WFS 2.0 maybe? Not sure
         This work around should still make monitoring statistics
        software
         life easier
        - the above plus browser detection: if the client is a known
        to be
         broken one (that is, IE) set the status to 200 nevertheless.
         At least the well behaved part of the internet can have
        proper
         status codes with the newer OGC services
        
        Opinions?
        
        Cheers
        Andrea
        
        -----------------------------------------------------
        Ing. Andrea Aime
        Senior Software Engineer
        
        GeoSolutions S.A.S.
        Via Poggio alle Viti 1187
        55054 Massarosa (LU)
        Italy
        
        phone: +39 0584962313
        fax: +39 0584962313
        
        http://www.geo-solutions.it
        http://geo-solutions.blogspot.com/
        http://www.linkedin.com/in/andreaaime
        http://twitter.com/geowolf
        
        -----------------------------------------------------
        
        ------------------------------------------------------------------------------
        Oracle to DB2 Conversion Guide: Learn learn about native
        support for PL/SQL,
        new data types, scalar functions, improved concurrency,
        built-in packages,
        OCI, SQL*Plus, data movement tools, best practices and more.
        http://p.sf.net/sfu/oracle-sfdev2dev
        _______________________________________________
        Geoserver-devel mailing list
        Geoserver-devel@lists.sourceforge.net
        https://lists.sourceforge.net/lists/listinfo/geoserver-devel
        
***************************************************
The information contained in this e-mail message
is intended only for the use of the recipient(s)
named above and may contain information that is
privileged, confidential, and/or proprietary.
If you are not the intended recipient, you may not
review, copy or distribute this message. If you have
received this communication in error, please notify
the sender immediately by e-mail, and delete the original message.
***************************************************
------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

7

On Sat, Dec 11, 2010 at 4:50 PM, Gabriel Roldán <groldan@anonymised.com> wrote:

The following from that URL looks like a nice and non invasive way of
working around that for IE if you change "ISAPI filter" by "Servlet
filter":

"Method 3
Use an ISAPI filter that forces the content length of all HTTP 500
responses to be larger than 512 bytes, effectively padding all 500
responses so that they are large enough to override the "friendly" error
setting in Internet Explorer 5.x and 6.x...."

Yep, tried it just for WFS exceptions so far and it works.
Spot on, thanks a lot Eli!

Now, making it work is going to be a bit trickier in that we have to disable
the gzip compression filter when the status code is anything other than 200,
and to do so we'll have to wrap the HTTPServletResponse since
status only has a setter.
But yeah, seems quite doable.

I'll let you know what happens when we try out the odd mime types
that WCS 1.0 and WMS 1.1 have.

Cheers
Andrea
-
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

8

On Sat, Dec 11, 2010 at 6:18 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Sat, Dec 11, 2010 at 4:50 PM, Gabriel Roldán <groldan@anonymised.com> wrote:

The following from that URL looks like a nice and non invasive way of
working around that for IE if you change "ISAPI filter" by "Servlet
filter":

"Method 3
Use an ISAPI filter that forces the content length of all HTTP 500
responses to be larger than 512 bytes, effectively padding all 500
responses so that they are large enough to override the "friendly" error
setting in Internet Explorer 5.x and 6.x...."

Yep, tried it just for WFS exceptions so far and it works.
Spot on, thanks a lot Eli!

Now, making it work is going to be a bit trickier in that we have to disable
the gzip compression filter when the status code is anything other than 200,
and to do so we'll have to wrap the HTTPServletResponse since
status only has a setter.
But yeah, seems quite doable.

I'll let you know what happens when we try out the odd mime types
that WCS 1.0 and WMS 1.1 have.

So I've tried by appending 1024 empty spaces to the response and temporarily
disabling the compression filter.
All resposes that use "text/xml" or "application/xml" as the content
type are properly
displayed by IE, even poor old IE 6.
However when the content type is "application/vnd.ogc.se_xml" no luck, padding
or not no browser seems to be able to open the thing and just reports the
400 error in its own custom page.

I looked around for some generic hint to tell the browser that thing is really
just xml, but without any luck.

If no other way is found to make WMS 1.1 and WCS 1.0 to pop the
file open dialog with the "application/vnd.ogc.se_xml" I guess a working
plan would be:
- set the http status code on ows 1.1 and subsequent
- don't even provide an option with ows 1.0 ones

I'm wondering if we should set some extra http headers so that monitoring
tools can get to know the http code we wished to set, but we couldn't,
in a unifor manner. Something like:
  OWS-Status-Code: 400
  OWS-Exception-Code: InvalidParameterValue

Any Nagios expert around here? Can it be made to use those custom
headers to evaluate the return status?
What about other common monitoring tools?

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

9

Hi Andrea,

It’s a bit of a shot in the dark but adding the content disposition header might force a download:

Content-Disposition: filename=“”

If that doesn’t do the trick you can always add a text editor (or maybe even the browser) as the handler for application/vnd.ogc.se_xml in your browser configuration.

With regards to Nagios and other monitoring software, if you need to go with “inconsistent” HTTP status codes you might consider making the status code behavior dependent on user agent.

Eli

On Sat, Dec 11, 2010 at 1:28 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sat, Dec 11, 2010 at 6:18 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Sat, Dec 11, 2010 at 4:50 PM, Gabriel Roldán <groldan@anonymised.com> wrote:

The following from that URL looks like a nice and non invasive way of
working around that for IE if you change “ISAPI filter” by “Servlet
filter”:

“Method 3
Use an ISAPI filter that forces the content length of all HTTP 500
responses to be larger than 512 bytes, effectively padding all 500
responses so that they are large enough to override the “friendly” error
setting in Internet Explorer 5.x and 6.x…”

Yep, tried it just for WFS exceptions so far and it works.
Spot on, thanks a lot Eli!

Now, making it work is going to be a bit trickier in that we have to disable
the gzip compression filter when the status code is anything other than 200,
and to do so we’ll have to wrap the HTTPServletResponse since
status only has a setter.
But yeah, seems quite doable.

I’ll let you know what happens when we try out the odd mime types
that WCS 1.0 and WMS 1.1 have.

So I’ve tried by appending 1024 empty spaces to the response and temporarily
disabling the compression filter.
All resposes that use “text/xml” or “application/xml” as the content
type are properly
displayed by IE, even poor old IE 6.
However when the content type is “application/vnd.ogc.se_xml” no luck, padding
or not no browser seems to be able to open the thing and just reports the
400 error in its own custom page.

I looked around for some generic hint to tell the browser that thing is really
just xml, but without any luck.

If no other way is found to make WMS 1.1 and WCS 1.0 to pop the
file open dialog with the “application/vnd.ogc.se_xml” I guess a working
plan would be:

  • set the http status code on ows 1.1 and subsequent
  • don’t even provide an option with ows 1.0 ones

I’m wondering if we should set some extra http headers so that monitoring
tools can get to know the http code we wished to set, but we couldn’t,
in a unifor manner. Something like:
OWS-Status-Code: 400
OWS-Exception-Code: InvalidParameterValue

Any Nagios expert around here? Can it be made to use those custom
headers to evaluate the return status?
What about other common monitoring tools?

Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

***************************************************
The information contained in this e-mail message 
is intended only for the use of the recipient(s) 
named above and may contain information that is 
privileged, confidential, and/or proprietary. 
If you are not the intended recipient, you may not
review, copy or distribute this message. If you have
received this communication in error, please notify 
the sender immediately by e-mail, and delete the original message.
***************************************************
10

On Sat, Dec 11, 2010 at 9:48 PM, Eli Miller <emiller@anonymised.com> wrote:

Hi Andrea,

It's a bit of a shot in the dark but adding the content disposition header
might force a download:

Content-Disposition: filename="<filename-to-save-as>"

Yep, was my first thought as well, unfortunately it did not work :frowning:

If that doesn't do the trick you can always add a text editor (or maybe even
the browser) as the handler for application/vnd.ogc.se_xml in your browser
configuration.

Yeah, thought about it

With regards to Nagios and other monitoring software, if you need to go with
"inconsistent" HTTP status codes you might consider making the status code
behavior dependent on user agent.

Thought about this as well, not sure I like the idea for a couple of reasons:
- it makes the code more complex
- it does not significantly improves the result, as unfortunately IE still has
  a very significant share of users, so monitoring software wise it would
  account for 70% of the calls anyways (don't know about your general case,
  what I normally is is that desktop software is used quite rarely to access
  OGC services compared to the common web based front ends people put
  in front of them for easy consultation).

Adding a custom header seemed like a better solution, no need to care
about the client, but it would work only if the common monitoring software
can make any use of it

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

11

I have some feedback from those in the know at OGC...

OWS is not a RESTful interface, so its not really bound by these
considerations. A RESTful version of OWS is something that is under
consderation - with active debate about it. In a way, these findings
seem to settle the argument about whether OWS can be considered
RESTful :slight_smile: (and the answer is of course no!)

good luck with the workarounds - its really working around I.E's
behaviour, which is frustrating on many levels.

Rob

On Sat, Dec 11, 2010 at 10:00 AM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

moral support, at the very least :slight_smile:

I'll forward it on to the OGC as well - and see if I can get a
response. There is an emerging discussion on HTTP protocol and
browser-friendliness...

Rob

On Sat, Dec 11, 2010 at 6:18 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

Hi,
tried implement the OWS 2.0 policy of returning proper HTTP status
codes when a service exception is returned.

The patch attached to http://jira.codehaus.org/browse/GEOS-4255
has the basics of it:
- a new class to represent the ows error code and its correspondent
status code
- changed service exception
- changed the wps module to use the new code class as an example
- made the service exception handlers set the status code
(start the JVM with -DOWS10_HTTP_ERROR_CODES=true to have
the codes set on WMS/WFS)

Now, what's wrong with it? Well, it basically makes debugging from
a browser impossible.
When a 500 or a 400 is set as the status code without also setting
the content type to html the browser just says that the web page is
not there, and does not offer to download the service exception
at all!
This basically means you have to use a non browser client,
such as "curl", to actually get the error message. Which is ridicolous.

In order to get anything to display HTTPServletResponse.sendError(code, message)
can be used, but at that point the container sets the content type to
html and builds a little web page around the message, disallowing
to use any other content type or... content.

I hope there is some workaround, otherwise this seemingly good
idea is going to turn into a tragedy (and one we won't be able
to avoid since OWS 2.0 will be the base for future specs...)

Suggestions, fixes to my eventually broken understanding,
moral support... all greatly appreciated...

Cheers
Andrea

--
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

12

Sorry for chiming in late on this one. Perhaps the work has already moved along but thought I would throw in my two cents.

In terms of the patch I think it looks good.

In terms of not being able to get back exception reports in the browser I agree that is quite a pain. Not sure what the best solution is. What about allowing one to turn off the USE_HTTP_ERROR_CODES flag directly as an additional request parameter. It would least give developers and users trying to gather a bug report a relatively easy way to get the exception in the browser.

2c.

-Justin

On Sun, Dec 12, 2010 at 10:45 PM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

I have some feedback from those in the know at OGC…

OWS is not a RESTful interface, so its not really bound by these
considerations. A RESTful version of OWS is something that is under
consderation - with active debate about it. In a way, these findings
seem to settle the argument about whether OWS can be considered
RESTful :slight_smile: (and the answer is of course no!)

good luck with the workarounds - its really working around I.E’s
behaviour, which is frustrating on many levels.

Rob

On Sat, Dec 11, 2010 at 10:00 AM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

moral support, at the very least :slight_smile:

I’ll forward it on to the OGC as well - and see if I can get a
response. There is an emerging discussion on HTTP protocol and
browser-friendliness…

Rob

On Sat, Dec 11, 2010 at 6:18 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

Hi,
tried implement the OWS 2.0 policy of returning proper HTTP status
codes when a service exception is returned.

The patch attached to http://jira.codehaus.org/browse/GEOS-4255
has the basics of it:

  • a new class to represent the ows error code and its correspondent
    status code
  • changed service exception
  • changed the wps module to use the new code class as an example
  • made the service exception handlers set the status code
    (start the JVM with -DOWS10_HTTP_ERROR_CODES=true to have
    the codes set on WMS/WFS)

Now, what’s wrong with it? Well, it basically makes debugging from
a browser impossible.
When a 500 or a 400 is set as the status code without also setting
the content type to html the browser just says that the web page is
not there, and does not offer to download the service exception
at all!
This basically means you have to use a non browser client,
such as “curl”, to actually get the error message. Which is ridicolous.

In order to get anything to display HTTPServletResponse.sendError(code, message)
can be used, but at that point the container sets the content type to
html and builds a little web page around the message, disallowing
to use any other content type or… content.

I hope there is some workaround, otherwise this seemingly good
idea is going to turn into a tragedy (and one we won’t be able
to avoid since OWS 2.0 will be the base for future specs…)

Suggestions, fixes to my eventually broken understanding,
moral support… all greatly appreciated…

Cheers
Andrea

–

Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.