I am involved with a geoserver (2.25.2, Ubuntu 22.04, Corretto 11) instance that occasionally receives WFS requests with syntactically broken CQL.
The response in such a case nicely explains what is wrong, like this:
<?xml version="1.0" ?>
<ServiceExceptionReport ...>
<ServiceException>
Could not parse CQL filter list.
Encountered "<EOF>" at line 1, column 4.
Was expecting one of:
...
Parsing : crap.
</ServiceException>
</ServiceExceptionReport>
for a request to /geoserver/wfs/wfs?...&CQL_FILTER=crap&... (obviously simplifying the real requests here).
However, I was kind of surprised that the response code is 200, and I wonder if this is expected behavior. To me, it would seem like a clear 400 (“malformed syntax” in RFC 7231 hits the nail on the head).
In the server logs, I can see where the ServiceException is thrown:
ERROR [geoserver.ows] -
org.geoserver.platform.ServiceException: Could not parse CQL filter list.
at org.geoserver.ows.kvp.CQLFilterKvpParser.parse(CQLFilterKvpParser.java:32)
at org.geoserver.ows.util.KvpUtils.parse(KvpUtils.java:438)
at org.geoserver.ows.Dispatcher.parseKVP(Dispatcher.java:1533)
at org.geoserver.ows.Dispatcher.parseKVP(Dispatcher.java:1529)
at org.geoserver.ows.Dispatcher.init(Dispatcher.java:320)
at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:239)
...
Looking at the code from the stacktrace, the Dispatcher class seems to have a mechanism for transforming exceptions of type HttpErrorCodeException into an HttpServletResponse with the corresponding error code. However, ServiceException is not a subclass of HttpErrorCodeException. (In fact, I failed to find any subclasses of it at all.)
Classic OGC services are more SOAP like than REST like and won’t return a
suitable HTTP error status, it’s up to you to check the response mime type
and verify if it’s a service exception or a feature payload.
I am involved with a geoserver (2.25.2, Ubuntu 22.04, Corretto 11)
instance that occasionally receives WFS requests with syntactically broken
CQL.
The response in such a case nicely explains what is wrong, like this:
<?xml version="1.0" ?>
<ServiceExceptionReport …>
Could not parse CQL filter list.
Encountered "<EOF>" at line 1, column 4.
Was expecting one of:
…
Parsing : crap.
for a request to /geoserver/wfs/wfs?..&CQL_FILTER=crap&… (obviously
simplifying the real requests here).
However, I was kind of surprised that the response code is 200, and I
wonder if this is expected behavior. To me, it would seem like a clear 400
(“malformed syntax” in RFC 7231 hits the nail on the head).
In the server logs, I can see where the ServiceException is thrown:
ERROR [geoserver.ows] -
org.geoserver.platform.ServiceException: Could not parse CQL filter list.
at org.geoserver.ows.kvp.CQLFilterKvpParser.parse(CQLFilterKvpParser.java:32)
at org.geoserver.ows.util.KvpUtils.parse(KvpUtils.java:438)
at org.geoserver.ows.Dispatcher.parseKVP(Dispatcher.java:1533)
at org.geoserver.ows.Dispatcher.parseKVP(Dispatcher.java:1529)
at org.geoserver.ows.Dispatcher.init(Dispatcher.java:320)
at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:239)
…
Looking at the code from the stacktrace, the Dispatcher class seems to
have a mechanism for transforming exceptions of type
HttpErrorCodeException into an HttpServletResponse with the corresponding
error code. However, ServiceException is not a subclass of
HttpErrorCodeException. (In fact, I failed to find any subclasses of it
at all.)