Closed jmacura closed 1 year ago
In this case, I'd say that the status code is incorrect eg. such a response should be handled differently on Layman.
In this case, I'd say that the status code is incorrect eg. such a response should be handled differently on Layman.
Might be. @fzadrazil mentioned that the exception was thrown directly by Geoserver, perhaps Layman only resent it.
I think 200 is probably ok in this case. It is not HTTP error that would require different status code. But it is right, that Layman just resends this message. Anyway, I will discuss with Layman guys.
Ok, so it is definitely GeoServer error, Layman acts only as a proxy in this case. Althought it is most likely not valid by the HTTP specs to return status 200, it is how GeoServer treats errors and HSLayers should adapt. WMS spec is not clear in this, it only describes how the ExceptionReport should look like and suggests the server "may return other status codes" in some cases. Layman can modify the status code in the future to make it valid, but I suppose it will be the same issue even for non-Layman WFS layers (at least those published via GS).
Cannot find a non-editable layer now to replicate. Will change code to disable layer synchronization icon.
Layer synchronization state fixed in f1014bb
Bug
Describe the bug When Layman (geoserver?) returns 200 OK, but the body contains Exception, it is not treated as such. E.g. when drawing into a layer which cannot be actually used for drawing (Postgres direct connection layer).
To Reproduce Steps to reproduce the behavior:
Expected behavior The error message shall be propagated to the user and any code waiting to success shall finish (like layer synchronizing)
Screenshots
Additional context This is an example exception response from Layman: