Detect Geoserver errors returned as 200 and don't cache them

[kring]

Geoserver has a bad habit of returning errors using HTTP status code 200. This causes our proxy to put long-expiration cache headers on the response, and then Varnish and end-user browsers cache these errors for a long time. This impedes our ability to fix such problems.

The proxy should detect Geoserver errors and set them to no-cache. We should also consider whether it makes sense to shift to a more sensible error code.

[stevage]

We should also consider whether it makes sense to shift to a more sensible error code.

You mean, detect the error (inspecting the XML for an error message), and then returning a 400, 404 or 500 or something? I like that idea a lot.

[kring]

Geoserver returns errors as a particular MIME type, so it should be pretty easy to detect.

[meh9]

As I have previously said, I've started writing a Servlet Filter to do just this, to be put in front of Geoserver, and that other Geoserver installations could also use.

If you want to put the fix in terriajs-server I guess that's fine, but that only solves our problem, and not anybody else's, since this is really a Geoserver problem.

Another approach would be to have a little Varnish snippet that does the same thing and just write a blog post about it or something.

[kring]

I've started writing a Servlet Filter to do just this

That's cool, and will probably be useful to lots of folks! However, it doesn't necessarily solve our problem, because we have to convince everyone A) that it's a good idea to return actual errors codes, even though the Geoserver maintainers don't think it is, B) to install the filter.

So I think we need to address this in our proxy anyway.

[kring]

I think a totally legit approach is:

• Change the proxy so it doesn't add cache headers to error responses, but don't change the error code.
• Write a servlet filter to change the error code, and encourage people to use it.

[stevage]

Just pointing out the obvious: if there are Geoservers with CORS enabled, we'll still have to proxy them.

[kring]

if there are Geoservers with CORS enabled, we'll still have to proxy them.

Why? Only if we want to cache them, right?

[stevage]

well, if we want the benefit of proper error codes in TerriaJS, that is.

[kring]

Oh, I see what you mean. Well I don't think they actually provide that much benefit in TerriaJS. It's easy to check for the errors without looking at the HTTP status code. The important thing is that errors not get cached for two weeks.

[meh9]

The important thing is that errors not get cached for two weeks.

Yeah, to be clear, I am in favour of any and all solutions that will solve this problem - I've just encountered it again where I ended up testing a new layer in prod which had an error and now I'm screwed. >:(

[vfonsecaz]

still no updates on this issue?

I'm having troubles with mapfishprint, because sometimes the getlegendgraphic response returns 200 (on service exception) and breaks the printing job

mapfish/mapfish-print#861

[kring]

@vfonsecaz we haven't done anything with this yet, but I'm not sure it would help you in the context of mapfish-print anyway. We're talking about modifying the server used with TerriaJS to avoid caching WMS errors. But mapfish is probably talking to those servers directly, rather than going through our proxy, so it needs a different solution.

[vfonsecaz]

yes, I understand! thanks

[ianturton]

You guys do realise that this is the expected behaviour of any conforming WMS server. Also that if the client sets the error type to EXCEPTIONS=application/vnd.ogc.se_inimage you won't see them.

[kring]

Yes @ianturton, returning an error document with a 200 status code is both expected behavior for a conforming WMS server, and unexpected behavior for a well-behaved service on the web. IMO the WMS spec made a poor choice here (a product of its time), but that ship has sailed. Anyway, the end result is that caches (Varnish in our case) end up caching tempory WMS errors for an extended period of time because they look like successful responses, and so this issue is about how to work around that. This is not as much of an issue as it used to be because we've tended to remove Varnish from most of our recent deployments.