We've migrated infrastructure from Windows+Jetty+GeoServer 2.6 to Debian10+Tomcat+GeoServer 2.18.0

We had a client application that uses filtered features from WFS using cql_filter=Codigo IN (9999) (URL encoded as cql_filter=%20IN%20(9999) ) and obtains JSON feature format.

Unfortunately, with the new infrastructure, we cannot get the same code working as GeoServer 2.18.0 crashes with following log (debug):

2022-05-05 12:28:55,121 DEBUG [security.IncludeQueryStringAntPathRequestMatcher] - Matched Path: /xxxxx/wfs, QueryString: service=WFS&request=GetFeature&version=1.3.0&typename=xxxxxxxxxxxx&outputFormat=application/json&srsname=EPSG:4326&*cql_filter=Codigo%20IN%20(4536)*&time=1651746545231 with /**

2022-05-05 12:28:55,121 DEBUG [geoserver.filters] - Creating a new http session inside the web UI (normal behavior)
java.lang.Exception: Full stack trace for the session creation path
        at org.geoserver.filters.SessionDebugFilter$SessionDebugWrapper.getSession(SessionDebugFilter.java:92)
        at org.geoserver.filters.SessionDebugFilter$SessionDebugWrapper.getSession(SessionDebugFilter.java:66)
        at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:253)

and later in the same log's event:

2022-05-05 12:28:55,147 DEBUG [geoserver.requests] - Trying to create reader basing on existing charset information: `UTF-8`.
2022-05-05 12:28:55,147 ERROR [geoserver.ows] -
java.io.EOFException: input contained no data
        at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:3003)
        at org.xmlpull.mxp1.MXParser.more(MXParser.java:3046)
        at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1410)

To solve the issue, we went down the path to relaxed chars as follows as we initially though that GeoServer is not getting correct cql_filter string and we poked Tomcat's server.xml file:

relaxedQueryChars="()|[]|{}^\`"<>[]|{}^\`"<>= ""

relaxedPathChars="()|[]|{}^\`"<>[]|{}^\`"<>= ""

But still no positive result.

Any ideas?

  • 1
    version=1.3.0 is wrong for WFS
    – nmtoken
    May 5 at 13:18
  • neither of those errors relate to the CQL filter, please add the relevant part of the log file
    – Ian Turton
    May 6 at 7:36

1 Answer 1


We've finally found the issue and fixed it.

Client application code were requesting using http 1.1 POST verb, putting all query parameters in the URL, BUT NOT IN THE BODY OF THE POST REQUEST. This was working well while in an "academic environment such as Jetty" but when migrated to TOMCAT any queryparameters (such as CQLFilter and its parameters) should be placed into the BODY part of the request and it was not.

We changed the original code in this way and we found it working perfectly.

Other way of fixing it would have been to go ahead and change the verb to http 1.1 GET. With this all parameters are to be found withing the posted URL request.

Thank you to y'all anyway. Regards.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.