Returning proper HTTP error codes: epic failure?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Returning proper HTTP error codes: epic failure?

geowolf
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: Returning proper HTTP error codes: epic failure?

Rob Atkinson
moral support, at the very least :-)

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
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: Returning proper HTTP error codes: epic failure?

geowolf
On Sat, Dec 11, 2010 at 12:00 AM, Rob Atkinson <[hidden email]> wrote:
> moral support, at the very least :-)
>
> 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

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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: Returning proper HTTP error codes: epic failure?

geowolf
On Sat, Dec 11, 2010 at 8:53 AM, Andrea Aime
<[hidden email]> wrote:
> On Sat, Dec 11, 2010 at 12:00 AM, Rob Atkinson <[hidden email]> wrote:
>> moral support, at the very least :-)
>>
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: Returning proper HTTP error codes: epic failure?

emiller
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 <[hidden email]> wrote:
On Sat, Dec 11, 2010 at 8:53 AM, Andrea Aime
<[hidden email]> wrote:
> On Sat, Dec 11, 2010 at 12:00 AM, Rob Atkinson <[hidden email]> wrote:
>> moral support, at the very least :-)
>>
>> 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:
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: Returning proper HTTP error codes: epic failure?

Gabriel Roldan
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
> <[hidden email]> wrote:
>         On Sat, Dec 11, 2010 at 8:53 AM, Andrea Aime
>         <[hidden email]> wrote:
>        
>         > On Sat, Dec 11, 2010 at 12:00 AM, Rob Atkinson
>         <[hidden email]> wrote:
>         >> moral support, at the very least :-)
>         >>
>         >> 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
>         [hidden email]
>         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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
[hidden email]
Expert service straight from the developers


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: Returning proper HTTP error codes: epic failure?

geowolf
On Sat, Dec 11, 2010 at 4:50 PM, Gabriel Roldán <[hidden email]> 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

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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: Returning proper HTTP error codes: epic failure?

geowolf
On Sat, Dec 11, 2010 at 6:18 PM, Andrea Aime
<[hidden email]> wrote:

> On Sat, Dec 11, 2010 at 4:50 PM, Gabriel Roldán <[hidden email]> 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

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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: Returning proper HTTP error codes: epic failure?

emiller
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>"

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 <[hidden email]> wrote:
On Sat, Dec 11, 2010 at 6:18 PM, Andrea Aime
<[hidden email]> wrote:
> On Sat, Dec 11, 2010 at 4:50 PM, Gabriel Roldán <[hidden email]> 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.
***************************************************


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: Returning proper HTTP error codes: epic failure?

geowolf
On Sat, Dec 11, 2010 at 9:48 PM, Eli Miller <[hidden email]> 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 :-(

> 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

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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: Returning proper HTTP error codes: epic failure?

Rob Atkinson
In reply to this post by Rob Atkinson
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 :-) (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 <[hidden email]> wrote:

> moral support, at the very least :-)
>
> 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
> <[hidden email]> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Reply | Threaded
Open this post in threaded view
|

Re: Returning proper HTTP error codes: epic failure?

Justin Deoliveira
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 <[hidden email]> 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 :-) (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 <[hidden email]> wrote:
> moral support, at the very least :-)
>
> 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
> <[hidden email]> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



--
Justin Deoliveira
Enterprise support for open source geospatial.


------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Geoserver-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel