[Geoserver-devel] Proper HTTP codes in service exceptions: progress and updated patch

GeoServer GeoServer Developer
1

Hi,
so following up the discussion of last week I added a filter that makes
sure responses with a code other than 200 are at least 513 bytes long.
That also required changing the gzip filter not to compress the output
in that case.

Then modified the service exception handlers all non problematic services
(WFS, WCS 1.1, WPS) to set the http status code, and made WPS
use the new set of excpeption codes

Still have to migrate WFS and WMS, but it's mostly search and replace.

For WMS 1.0 and WCS 1.0 I simply did not set the status code.
What I did for all exceptions though was to set a couple of headers,
owsStatusCode and owsExceptionCode, that always contain the
http status code we'd like to use in a perfect world, and also the
ows exception code (just for completeness)

A monitoring software can look at those headers for the time being
to decide whether the request failed or not

About having a request param to force the status code to be 200,
I think it's not necessary as the only services that show problems
with the 400/500 codes are simply not using them

Hum... which makes me realize, I would actually have to make sure
WMS 1.3 sets the status code properly, as in that case the mime
type is just text/xml.

Anyways, opinions? Am I heading in the right direction?

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

Sounds great to me. Having these there makes the services make sense to a wider (non-ogc) audience, which I think is where the next step of GeoServer growth will come from. And as long as it doesn’t affect current things it’s great, which it sounds like you’ve gone through extra work to make sure of.

On Fri, Dec 17, 2010 at 11:15 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
so following up the discussion of last week I added a filter that makes
sure responses with a code other than 200 are at least 513 bytes long.
That also required changing the gzip filter not to compress the output
in that case.

Then modified the service exception handlers all non problematic services
(WFS, WCS 1.1, WPS) to set the http status code, and made WPS
use the new set of excpeption codes

Still have to migrate WFS and WMS, but it’s mostly search and replace.

For WMS 1.0 and WCS 1.0 I simply did not set the status code.
What I did for all exceptions though was to set a couple of headers,
owsStatusCode and owsExceptionCode, that always contain the
http status code we’d like to use in a perfect world, and also the
ows exception code (just for completeness)

A monitoring software can look at those headers for the time being
to decide whether the request failed or not

About having a request param to force the status code to be 200,
I think it’s not necessary as the only services that show problems
with the 400/500 codes are simply not using them

Hum… which makes me realize, I would actually have to make sure
WMS 1.3 sets the status code properly, as in that case the mime
type is just text/xml.

Anyways, opinions? Am I heading in the right direction?

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

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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

On Tue, Dec 21, 2010 at 3:49 AM, Chris Holmes <cholmes@anonymised.com.> wrote:

Sounds great to me. Having these there makes the services make sense to a wider (non-ogc) audience, which I think is where the next step of GeoServer growth will come from. And as long as it doesn’t affect current things it’s great, which it sounds like you’ve gone through extra work to make sure of.

So today I went a bit further, switched WFS and partially WCS and run tests.
Surprise surpise… the CITE engine is not ready!
Both WFS 1.0 and WCS 1.1 tests fail because the cite engine stops the moment
it sees the HTTP response code being 400 or 500 (could not run WFS 1.1 hmm…)

I could understand WFS 1.0. But WCS 1.1 is based on OWS 1.1, which demands
the check of the return codes in its abstract test suite.

I guess it’s time to take a decision here:

  • do we drop the ball since not the cite tests break
  • do we create a property to control the usage of proper http status codes and
    have it disabled by default (so that cite tests can run unaffected)?

I guess the day OGC gets its act togheter and start demanding in CITE tests
what they write on paper we’ll write service exception handlers that do use
the proper http codes by default (which I guess will happen for newer services).

I would go for the second, allowing the admin to choose for which services
to enable the http codes. As far as I can see they do work and make sense
in WFS 1.0, WFS 1.1, WMS 1.3, WCS 1.1 and WPS 1.0

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