More suitable HTTP status codes for service exceptions

[cklein05]

Hi there,

All types of exception reports currently are returned with a HTTP status code of 404 Not Found. Actually, that's not ideal, since in case of an error ("Oh, I'm getting no map images...!"), most people will likely issue some test requests in a web browser. Since most modern browsers just do not show the response for a 404, you need Wireshark (or similar) to actually read the service exception.

You could either constantly use status code 200 OK for all responses (that's what GeoServer does, for example) or try using the codes recommended by OGC's 'Web Services Common Standard', which basically are 400 Bad Request and 501 Not Implemented.

For the latter solution, obviously there is more work to be done. You could probably pass the HTTP status code as a (new) last parameter to OGCException and use it in the handler accordingly. If you actually go that far, you could also add support for the 'locator' attribute for version 1.3.0 exception reports (also with an additional argument to ctor of OGCException).

At least for the self.debug == true case, in which you switch to the HTML handler, returning 200 OK would be helpful; the same seems to be true for IN_IMAGE and BLANK handlers. So, using different status codes for different exceptions, actually only applies to XML and - maybe - HTML formats.

Although not that familiar with Python (coming form Java, C++, VB etc.), I could likely implement these changes if you like (and one or two more, see upcoming issues). I need to use OGCServer in a production environment (Apache httpd, mod_wsgi etc.), but I'm really not a fan of creating my personal local branches.

However, I've read Dane Springmeyer's post "Inventory and evaluate merge of refactoring done for haiti instance", so I'm not quite sure whether the latest version is the one to implement these changes on. Maybe you should first clean up the code? Oh, the ticket is from 2010... As far as I've seen, the Haiti stuff is still there... Are still movong on with this?

Thanks in advance for any helpful reply,
Carsten

[manelclos]

Hi Carsten,

I started squashing bugs some weeks ago, and the 404 response was one of those. We were returning 200 for all responses, so my code was also caching bad responses. I started using 400 in my tests, but ended looking at what others do, and TileCache was using 404 with good results. Changing it to 400 is an easy change if we are sure it is an improvement. ArcGIS WMS server will return 200 text/xml, and you already mentioned geoserver.

I'm able to see the 404 response body in Chrome. And you can always use Chrome developer tools or Firefox's Firebug to inspect the response.

For the debug case, you wan't more information when there is an error, but using 200 will complicate things if you are caching results. Let's see if with a 400 code things get better.

About Springmeyer's post, I haven't got time to go over the needed refactoring. We basically need to provide a new config file to support more WMS features like groups of layers (usable as meta layers), title, and other features that were removed from Mapnik's XML because they were too WMS oriented.

Any coding and help is appreciated! Please open different issues for different problems so we can test and discuss them.

Thanks!