geoserver-cloud icon indicating copy to clipboard operation
geoserver-cloud copied to clipboard

CQL filter: could not parse CQL filter list.

Open woutergd opened this issue 2 years ago • 7 comments

When requesting a layer through a reverse proxy from the geoserver, the WMS or WFS cant be loaded when a combined set of parameters (e.g. with an AND or OR-statement) is used. This occurs when HTML encoded characters are applied, e.g. %20 for a space. When this is removed, or it is directly requested on the geoserver itself, it works sometimes. I get it always when used on WFS, sometimes on WMS.

For instance, with an url parameter like the following: &CQL_FILTER=(categorie=5%20OR%20categorie=4)

The exact error we receive is the following: Could not parse CQL filter list. Lexical error at line 1, column 13. Encountered: "%" (37), after : "" Parsing : (categorie=5%20OR%20categorie=4).

This request is no problem with a regular geoserver. It seems like that the gateway is not correctly passing the %-signs, or applying additional escape characters causing this issue so that the services thinks it is receiving a % in the CQL filter.

woutergd avatar May 18 '22 13:05 woutergd

I think it's also happening with the rest service requests when getting a style (.sld) for instance.

giancastro avatar Jun 17 '22 10:06 giancastro

I think it's also happening with the rest service requests when getting a style (.sld) for instance.

@giancastro Don't you mean issue #212 that is occurring? We experienced on our side no issues with retrieving SLD through the rest api, when we apply the correct content type (just passing .sld) is not enough with this version of Geoserver at the moment.

woutergd avatar Jun 17 '22 18:06 woutergd

@woutergd, does any style have a space between the name? for instance, My Style. I Had problem retrieving the style in these cases.

giancastro avatar Jun 20 '22 11:06 giancastro

@giancastro I just verified it on the server that is running on our side the latest geoserver Snapshot-version (of today), but that works fine to me with a space in the name, eithjer with a %20 or without a %20 as dash in the url

The url I used is the following: http://:9090/rest/workspaces/mapgear/styles/test%20style.sld, and added the header "Accept: application/vnd.ogc.sld+xml" (so I get the SLD instead of the HTML). Even without the header added, I just get the HTML page of the style back from the API.

Did you also get the same error as shown in my initial post (the lexical error)?

woutergd avatar Jun 20 '22 11:06 woutergd

@woutergd , I got a not found error, but I'll try to figure out what's happening on my side.

giancastro avatar Jun 20 '22 11:06 giancastro

@groldan is there any update on this issue, can I help you explain the issue a bit more?

woutergd avatar Jul 13 '22 07:07 woutergd

I have been trying to pinpoint this issue. It was happening when the url contained a CQL_FILTER parameter like &CQL_FILTER=ogc_fid=1 OR ogc_fid=2. When this was added in the url, it was converted into &CQL_FILTER=ogc_fid=1%20OR%20ogc_fid=2 (so, with proper html encoding). It seemed however that both the WMS and WFS services got in the end the % character, indicating some html encoding issue within the gateway and not in the WMS or WFS services itself.

I have been searching for a solution for this, and found out that it was related due to an open issue in Spring Boot Gateway around double Html encoding (see https://github.com/spring-cloud/spring-cloud-gateway/issues/2065). What was happening that when %20 was passed into the gateway within just a query parameter, it was encoded again and passing the %-characters into the CQL filter.

Based on a solution that was provided into the issue of Spring Cloud Gateway, I have created a PR to resolve this issue, see: #281

woutergd avatar Oct 14 '22 15:10 woutergd

Fixed by #281

groldan avatar Dec 26 '22 12:12 groldan