[Geoserver-users] Exception with Filter 2.0

Jukka_Rahkonen · January 20, 2016, 12:53pm

Hi,

Can you reproduce the issue with the demo layer ”states”? If you can, please send the whole GET url for making testing convenient for the others.

Regards,

-Jukka Rahkonen-

···

Nhan Vo wrote:

Hi list,

I’m upgrading Geoserver from 2.3.5 to 2.8.1 and my client code cannot work anymore. Basically it sends a WFS Url request with a filter to Geoserver. The filter looks as follows:

<fes:Filter xmlns:fes=‘http://www.opengis.net/fes/2.0’ xmlns:gml=‘http://www.opengis.net/gml/3.2’>
<fes:PropertyIsLike matchCase=‘false’ wildCard=‘*’ singleChar=‘#’ escapeChar=‘!’>
fes:ValueReference…</fes:ValueReference>
fes:Literal…</fes:Literal>
</fes:PropertyIsLike>
</fes:Filter>

With version 2.8.1 I receive the exception message: XML document structures must start and end within the same entity

I have been able to get around this by replacing singleChar=‘#’ with singleChar=‘%’, but still cannot understand why the ‘#’ causes the problem. Also, ‘.’ and ‘_’ do not work either and I receive the same exception message. Only ‘%’ works.

Btw, Geoserver 2.3.5 was running with Java 6; when I updated to 2.8.1 I also updated to Java 8.

If someone could shed some light on this I’d appreciate it.

Best regards,
Nhan Vo

Nhan_Vo · January 20, 2016, 1:04pm

Hi,

Thanks for the response. This URL works:
http://192.168.0.102:8081/geoserver/wfs?VERSION=2.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=topp:states&FILTER=<fes:Filter%20xmlns:fes=‘http://www.opengis.net/fes/2.0’%20xmlns:gml=‘http://www.opengis.net/gml/3.2’><fes:PropertyIsLike%20matchCase=‘false’%20wildCard=‘*’%20singleChar='%'%20escapeChar='!'%3E%3Cfes:ValueReference%3Etopp:STATE_NAME%3C/fes:ValueReference%3E%3Cfes:Literal%3E*%3C/fes:Literal%3E%3C/fes:PropertyIsLike%3E%3C/fes:Filter%3E

This does not work:
http://192.168.0.102:8081/geoserver/wfs?VERSION=2.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=topp:states&FILTER=<fes:Filter%20xmlns:fes=‘http://www.opengis.net/fes/2.0’%20xmlns:gml=‘http://www.opengis.net/gml/3.2’><fes:PropertyIsLike%20matchCase=‘false’%20wildCard=‘*’%20singleChar=‘#’%20escapeChar=‘!’><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>*</fes:Literal></fes:PropertyIsLike></fes:Filter>

The only difference is /*singleChar='%'*/ and /*singleChar='#'*/.

Best regards,
Nhan Vo

On 1/20/2016 1:53 PM, Rahkonen Jukka (MML) wrote:

Hi,

Can you reproduce the issue with the demo layer ”states”? If you can, please send the whole GET url for making testing convenient for the others.

Regards,

-Jukka Rahkonen-

Nhan Vo wrote:

Hi list,

I'm upgrading Geoserver from 2.3.5 to 2.8.1 and my client code cannot work anymore. Basically it sends a WFS Url request with a filter to Geoserver. The filter looks as follows:

<fes:Filter xmlns:fes='http://www.opengis.net/fes/2.0’ xmlns:gml='http://www.opengis.net/gml/3.2’>
    <fes:PropertyIsLike matchCase='false' wildCard='*' singleChar='#' escapeChar='!'>
<fes:ValueReference>...</fes:ValueReference>
        <fes:Literal>...</fes:Literal>
    </fes:PropertyIsLike>
</fes:Filter>

With version 2.8.1 I receive the exception message:*XML document structures must start and end within the same entity*

I have been able to get around this by replacing */singleChar='#'/* with */singleChar='%'/*, but still cannot understand why the '#' causes the problem. Also, '.' and '_' do not work either and I receive the same exception message. Only '%' works.

Btw, Geoserver 2.3.5 was running with Java 6; when I updated to 2.8.1 I also updated to Java 8.

If someone could shed some light on this I'd appreciate it.

Best regards,
Nhan Vo

--

*Thanh-Trong-Nhan Vo*

smile consult GmbH
Vahrenwalder Straße 4
D-30165 Hannover

Tel:

0511/543617-46

Fax:

0511/543617-66

Mail:

nhanvo@anonymised.com <mailto:nhanvo@anonymised.com>

Internet:

http://www.smileconsult.de/>

Geschäftsführer: Frank Sellerhoff •Peter Milbradt •Christoph Lippert
USt-IdNr.: DE208857046 •Amtsgericht Hannover HRB 58707

Bart_van_den_Eijnde1 · January 20, 2016, 10:44pm

Nhan Vo,

neither singleChar="%" nor singleChar="#" work for me until I percent-encode them as singleChar="%25" or singleChar="%23" respectively. "%" is used for URL percent-encoding and "#" is the URL fragment separator and neither can be used unencoded in a URL. I am surprised that either worked for you before. Perhaps older Java or GeoServer was more permissive, or your client is encoding one but not the other? I think Java 8 may have added better unicode support in percent decoding; this may be the change.

Furthermore, matchCase is not permitted on PropertyIsLike. Including this attribute caused the rather unhelpful error message: "Attempted to construct illegal filter - I dont understand the tag: fes:ValueReference. HINT: tags are case-sensitive!"

Both of these URLs work for me against the current GeoServer master release configuration with Java 8:

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>*</fes:Literal></fes:PropertyIsLike></fes:Filter>

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%25"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>*</fes:Literal></fes:PropertyIsLike></fes:Filter>

Kind regards,
Ben.

On 21/01/16 02:04, Nhan Vo wrote:

Hi,

Thanks for the response. This URL works:
http://192.168.0.102:8081/geoserver/wfs?VERSION=2.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=topp:states&FILTER=<fes:Filter%20xmlns:fes=‘http://www.opengis.net/fes/2.0’%20xmlns:gml=‘http://www.opengis.net/gml/3.2’><fes:PropertyIsLike%20matchCase=‘false’%20wildCard=‘*’%20singleChar='%'%20escapeChar='!'%3E%3Cfes:ValueReference%3Etopp:STATE_NAME%3C/fes:ValueReference%3E%3Cfes:Literal%3E*%3C/fes:Literal%3E%3C/fes:PropertyIsLike%3E%3C/fes:Filter%3E

This does not work:
http://192.168.0.102:8081/geoserver/wfs?VERSION=2.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=topp:states&FILTER=<fes:Filter%20xmlns:fes=‘http://www.opengis.net/fes/2.0’%20xmlns:gml=‘http://www.opengis.net/gml/3.2’><fes:PropertyIsLike%20matchCase=‘false’%20wildCard=‘*’%20singleChar=‘#’%20escapeChar=‘!’><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>*</fes:Literal></fes:PropertyIsLike></fes:Filter>

The only difference is /*singleChar='%'*/ and /*singleChar='#'*/.

Best regards,
Nhan Vo

On 1/20/2016 1:53 PM, Rahkonen Jukka (MML) wrote:

Hi,

Can you reproduce the issue with the demo layer ”states”? If you can, please
send the whole GET url for making testing convenient for the others.

Regards,

-Jukka Rahkonen-

Nhan Vo wrote:

Hi list,

I'm upgrading Geoserver from 2.3.5 to 2.8.1 and my client code cannot work
anymore. Basically it sends a WFS Url request with a filter to Geoserver. The
filter looks as follows:

<fes:Filter xmlns:fes='http://www.opengis.net/fes/2.0’
xmlns:gml='http://www.opengis.net/gml/3.2’>
    <fes:PropertyIsLike matchCase='false' wildCard='*' singleChar='#'
escapeChar='!'>
<fes:ValueReference>...</fes:ValueReference>
        <fes:Literal>...</fes:Literal>
    </fes:PropertyIsLike>
</fes:Filter>

With version 2.8.1 I receive the exception message:*XML document structures
must start and end within the same entity*

I have been able to get around this by replacing */singleChar='#'/* with
*/singleChar='%'/*, but still cannot understand why the '#' causes the
problem. Also, '.' and '_' do not work either and I receive the same exception
message. Only '%' works.

Btw, Geoserver 2.3.5 was running with Java 6; when I updated to 2.8.1 I also
updated to Java 8.

If someone could shed some light on this I'd appreciate it.

Best regards,
Nhan Vo

--

*Thanh-Trong-Nhan Vo*

smile consult GmbH
Vahrenwalder Straße 4
D-30165 Hannover

Tel:

0511/543617-46

Fax:

0511/543617-66

Mail:

<mailto:nhanvo@anonymised.com>nhanvo@anonymised.com

Internet:

<http://www.smileconsult.de/>http://www.smileconsult.de

Geschäftsführer: Frank Sellerhoff •Peter Milbradt •Christoph Lippert
USt-IdNr.: DE208857046 •Amtsgericht Hannover HRB 58707

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

Nhan_Vo · January 21, 2016, 9:15am

Hi Ben,

Thanks for the helpful reply. The exception message was indeed misleading. A couple of points left, I hope you'd look into them:

1. How come matchCase was supported in version 2.3.5 but not anymore in 2.8.1? Personally I find it really useful. Is there a way to make a search with PropertyIsLike case-insensitive?

2. I had this problem already with version 2.3.5 and it seems to persist in version 2.8.1: When the search text contains a German letter with umlaut in upper-case (Ü, Ö, Ä), I got the exception "Attempted to construct illegal filter - I dont understand the tag: fes:ValueReference. HINT: tags are case-sensitive!". ü, ö, ä are however fine. As an added advantage with matchCase='false' I could get around this problem, but not anymore in 2.8.1. If possible could you shed some light on this?

Any hints or pointers are much appreciated!

Best regards,
Nhan Vo

On 1/20/2016 11:44 PM, Ben Caradoc-Davies wrote:

Nhan Vo,

neither singleChar="%" nor singleChar="#" work for me until I percent-encode them as singleChar="%25" or singleChar="%23" respectively. "%" is used for URL percent-encoding and "#" is the URL fragment separator and neither can be used unencoded in a URL. I am surprised that either worked for you before. Perhaps older Java or GeoServer was more permissive, or your client is encoding one but not the other? I think Java 8 may have added better unicode support in percent decoding; this may be the change.

Furthermore, matchCase is not permitted on PropertyIsLike. Including this attribute caused the rather unhelpful error message: "Attempted to construct illegal filter - I dont understand the tag: fes:ValueReference. HINT: tags are case-sensitive!"

Both of these URLs work for me against the current GeoServer master release configuration with Java 8:

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>*</fes:Literal></fes:PropertyIsLike></fes:Filter>

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%25"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>*</fes:Literal></fes:PropertyIsLike></fes:Filter>

Kind regards,
Ben.

On 21/01/16 02:04, Nhan Vo wrote:

Hi,

Thanks for the response. This URL works:
http://192.168.0.102:8081/geoserver/wfs?VERSION=2.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=topp:states&FILTER=<fes:Filter%20xmlns:fes=‘http://www.opengis.net/fes/2.0’%20xmlns:gml=‘http://www.opengis.net/gml/3.2’><fes:PropertyIsLike%20matchCase=‘false’%20wildCard=‘*’%20singleChar='%'%20escapeChar='!'%3E%3Cfes:ValueReference%3Etopp:STATE_NAME%3C/fes:ValueReference%3E%3Cfes:Literal%3E*%3C/fes:Literal%3E%3C/fes:PropertyIsLike%3E%3C/fes:Filter%3E

This does not work:
http://192.168.0.102:8081/geoserver/wfs?VERSION=2.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=topp:states&FILTER=<fes:Filter%20xmlns:fes=‘http://www.opengis.net/fes/2.0’%20xmlns:gml=‘http://www.opengis.net/gml/3.2’><fes:PropertyIsLike%20matchCase=‘false’%20wildCard=‘*’%20singleChar=‘#’%20escapeChar=‘!’><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>*</fes:Literal></fes:PropertyIsLike></fes:Filter>

The only difference is /*singleChar='%'*/ and /*singleChar='#'*/.

Best regards,
Nhan Vo

On 1/20/2016 1:53 PM, Rahkonen Jukka (MML) wrote:

Hi,

Can you reproduce the issue with the demo layer ”states”? If you can, please
send the whole GET url for making testing convenient for the others.

Regards,

-Jukka Rahkonen-

Nhan Vo wrote:

Hi list,

I'm upgrading Geoserver from 2.3.5 to 2.8.1 and my client code cannot work
anymore. Basically it sends a WFS Url request with a filter to Geoserver. The
filter looks as follows:

<fes:Filter xmlns:fes='http://www.opengis.net/fes/2.0’
xmlns:gml='http://www.opengis.net/gml/3.2’>
    <fes:PropertyIsLike matchCase='false' wildCard='*' singleChar='#'
escapeChar='!'>
<fes:ValueReference>...</fes:ValueReference>
        <fes:Literal>...</fes:Literal>
    </fes:PropertyIsLike>
</fes:Filter>

With version 2.8.1 I receive the exception message:*XML document structures
must start and end within the same entity*

I have been able to get around this by replacing */singleChar='#'/* with
*/singleChar='%'/*, but still cannot understand why the '#' causes the
problem. Also, '.' and '_' do not work either and I receive the same exception
message. Only '%' works.

Btw, Geoserver 2.3.5 was running with Java 6; when I updated to 2.8.1 I also
updated to Java 8.

If someone could shed some light on this I'd appreciate it.

Best regards,
Nhan Vo

------------------------------------------------------------------------------

Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Bart_van_den_Eijnde1 · January 21, 2016, 12:23pm

Nhan Vo,

when you used PropertyIsLike/@matchCase="false" previously with GeoServer 2.3.5, did you use Filter 2.0 or Filter 1.1?

I looked a little deeper and matchCase="false" *should* be supported on PropertyIsLike in GeoServer WFS 1.1 because Niels kindly updated GeoTools to use the FES 1.1.3 schemas back in 2013 to add matchCase support:
http://osgeo-org.1560.x6.nabble.com/ogc-filter-1-1-doesn-t-support-matchCase-in-PropertyIsLike-td5079577.html
https://github.com/geotools/geotools/commit/4855cba310362f488d5686eda1fff17d7d02c714
http://schemas.opengis.net/filter/1.1.0/filter.xsd

I changed the GET request to use WFS 1.1 and can confirm that matchCase="false" works. The request matches "illino*" to "Illinois":
http://localhost:8080/geoserver/wfs?service=WFS&version=1.1.0&request=GetFeature&typename=topp:states&filter=<ogc:Filter%20xmlns:ogc="http://www.opengis.net/ogc"><ogc:PropertyIsLike%20matchCase="false"%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><ogc:PropertyName>topp:STATE_NAME</ogc:PropertyName><ogc:Literal>illino*</ogc:Literal></ogc:PropertyIsLike></ogc:Filter>

*But* if I look at even the latest schemas and standard for FES 2.0.2, there is no matchCase on PropertyIsLike:
http://schemas.opengis.net/filter/2.0/filter.xsd
http://docs.opengeospatial.org/is/09-026r2/09-026r2.html

I think this is a bug in the FES 2.0.2 schemas. I think GeoServer will need updated schemas to fix this for WFS 2.0 (and we can see that the XML parsing is horribly broken without this fix). We may need a change request (or an email to the standard maintainer):
http://www.opengeospatial.org/standards/cr

If I add a single line to the definition of PropertyIsLikeType in the copy of the FES 2.0 schemas in GeoTools gt-xsd-fes:
modules/extension/xsd/xsd-fes/src/main/resources/org/geotools/filter/v2_0/filter.xsd
<xsd:attribute name="matchCase" type="xsd:boolean" use="optional" default="true"/>

then suddenly matchCase="false" on PropertyIsLike starts working for WFS 2.0 in GeoServer, just as as for WFS 1.1:
http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20matchCase="false"%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>illino*</fes:Literal></fes:PropertyIsLike></fes:Filter>

GeoServer also supports a CQL_FILTER vendor parameter that has case insensitive "ilike" support:
http://docs.geoserver.org/latest/en/user/services/wfs/vendor.html#cql-filters
See the "strToLowerCase(STATE_NAME) like '%m%'" example in the tutorial:
http://docs.geoserver.org/latest/en/user/tutorials/cql/cql_tutorial.html
or the "ilike" predicate:
http://docs.geoserver.org/latest/en/user/filter/ecql_reference.html

As for letters outside ASCII ("Ü", "Ö", "Ä", "ü", "ö", "ä"), if you are using them in URLs such as encoded filters, are you percent-encoding these as required by RFC 3986?:
https://en.wikipedia.org/wiki/Percent-encoding
https://tools.ietf.org/html/rfc3986

$ python
Python 2.7.11 (default, Jan 11 2016, 21:04:40)
[GCC 5.3.1 20160101] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib
>>> for c in ("Ü", "Ö", "Ä", "ü", "ö", "ä"): print c, urllib.quote(c)
...
Ü %C3%9C
Ö %C3%96
Ä %C3%84
ü %C3%BC
ö %C3%B6
ä %C3%A4

Kind regards,
Ben.

On 21/01/16 22:15, Nhan Vo wrote:

Hi Ben,

Thanks for the helpful reply. The exception message was indeed
misleading. A couple of points left, I hope you'd look into them:

1. How come matchCase was supported in version 2.3.5 but not anymore in
2.8.1? Personally I find it really useful. Is there a way to make a
search with PropertyIsLike case-insensitive?

2. I had this problem already with version 2.3.5 and it seems to persist
in version 2.8.1: When the search text contains a German letter with
umlaut in upper-case (Ü, Ö, Ä), I got the exception "Attempted to
construct illegal filter - I dont understand the tag:
fes:ValueReference. HINT: tags are case-sensitive!". ü, ö, ä are
however fine. As an added advantage with matchCase='false' I could get
around this problem, but not anymore in 2.8.1. If possible could you
shed some light on this?

Any hints or pointers are much appreciated!

Best regards,
Nhan Vo

On 1/20/2016 11:44 PM, Ben Caradoc-Davies wrote:

Nhan Vo,

neither singleChar="%" nor singleChar="#" work for me until I
percent-encode them as singleChar="%25" or singleChar="%23"
respectively. "%" is used for URL percent-encoding and "#" is the URL
fragment separator and neither can be used unencoded in a URL. I am
surprised that either worked for you before. Perhaps older Java or
GeoServer was more permissive, or your client is encoding one but not
the other? I think Java 8 may have added better unicode support in
percent decoding; this may be the change.

Furthermore, matchCase is not permitted on PropertyIsLike. Including
this attribute caused the rather unhelpful error message: "Attempted
to construct illegal filter - I dont understand the tag:
fes:ValueReference. HINT: tags are case-sensitive!"

Both of these URLs work for me against the current GeoServer master
release configuration with Java 8:

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>*</fes:Literal></fes:PropertyIsLike></fes:Filter>

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%25"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>*</fes:Literal></fes:PropertyIsLike></fes:Filter>

Kind regards,
Ben.

On 21/01/16 02:04, Nhan Vo wrote:

Hi,

Thanks for the response. This URL works:
http://192.168.0.102:8081/geoserver/wfs?VERSION=2.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=topp:states&FILTER=<fes:Filter%20xmlns:fes=‘http://www.opengis.net/fes/2.0’%20xmlns:gml=‘http://www.opengis.net/gml/3.2’><fes:PropertyIsLike%20matchCase=‘false’%20wildCard=‘*’%20singleChar='%'%20escapeChar='!'%3E%3Cfes:ValueReference%3Etopp:STATE_NAME%3C/fes:ValueReference%3E%3Cfes:Literal%3E*%3C/fes:Literal%3E%3C/fes:PropertyIsLike%3E%3C/fes:Filter%3E

This does not work:
http://192.168.0.102:8081/geoserver/wfs?VERSION=2.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=topp:states&FILTER=<fes:Filter%20xmlns:fes=‘http://www.opengis.net/fes/2.0’%20xmlns:gml=‘http://www.opengis.net/gml/3.2’><fes:PropertyIsLike%20matchCase=‘false’%20wildCard=‘*’%20singleChar=‘#’%20escapeChar=‘!’><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>*</fes:Literal></fes:PropertyIsLike></fes:Filter>

The only difference is /*singleChar='%'*/ and /*singleChar='#'*/.

Best regards,
Nhan Vo

On 1/20/2016 1:53 PM, Rahkonen Jukka (MML) wrote:

Hi,

Can you reproduce the issue with the demo layer ”states”? If you
can, please
send the whole GET url for making testing convenient for the others.

Regards,

-Jukka Rahkonen-

Nhan Vo wrote:

Hi list,

I'm upgrading Geoserver from 2.3.5 to 2.8.1 and my client code
cannot work
anymore. Basically it sends a WFS Url request with a filter to
Geoserver. The
filter looks as follows:

<fes:Filter xmlns:fes='http://www.opengis.net/fes/2.0’
xmlns:gml='http://www.opengis.net/gml/3.2’>
    <fes:PropertyIsLike matchCase='false' wildCard='*' singleChar='#'
escapeChar='!'>
<fes:ValueReference>...</fes:ValueReference>
        <fes:Literal>...</fes:Literal>
    </fes:PropertyIsLike>
</fes:Filter>

With version 2.8.1 I receive the exception message:*XML document
structures
must start and end within the same entity*

I have been able to get around this by replacing */singleChar='#'/*
with
*/singleChar='%'/*, but still cannot understand why the '#' causes the
problem. Also, '.' and '_' do not work either and I receive the same
exception
message. Only '%' works.

Btw, Geoserver 2.3.5 was running with Java 6; when I updated to
2.8.1 I also
updated to Java 8.

If someone could shed some light on this I'd appreciate it.

Best regards,
Nhan Vo

------------------------------------------------------------------------------

Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

Nhan_Vo · January 21, 2016, 1:15pm

Hi Ben,

Thanks a lot for the detailed reply and the hints. I can confirm that in my case filter 2.0 was used with version 2.3.5. It is exactly like it is now and I have just removed matchCase to make it work in version 2.8.1 according to your explanation. Perhaps someone has modified the schema in the meantime to make it conform with Filter 2.0 spec?

Regarding the umlauts, I use URLEncoder.encode() to encode the filter part and it seems to properly percent-encode the letters.

Please try the following, which is the working example from you in your previous email in which I just replace the literal "*" with "ü*" and "Ü*":

This (with "ü*") works although returning 0 records:

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>ü*</fes:Literal></fes:PropertyIsLike></fes:Filter>

This (with "Ü*") breaks the XML parsing, and we receive the exception:

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>Ü*</fes:Literal></fes:PropertyIsLike></fes:Filter>

I've tried the 2 Urls above with Geoserver 2.8.1.

Best regards,
Nhan Vo

On 1/21/2016 1:23 PM, Ben Caradoc-Davies wrote:

Nhan Vo,

when you used PropertyIsLike/@matchCase="false" previously with GeoServer 2.3.5, did you use Filter 2.0 or Filter 1.1?

I looked a little deeper and matchCase="false" *should* be supported on PropertyIsLike in GeoServer WFS 1.1 because Niels kindly updated GeoTools to use the FES 1.1.3 schemas back in 2013 to add matchCase support:
http://osgeo-org.1560.x6.nabble.com/ogc-filter-1-1-doesn-t-support-matchCase-in-PropertyIsLike-td5079577.html

https://github.com/geotools/geotools/commit/4855cba310362f488d5686eda1fff17d7d02c714

http://schemas.opengis.net/filter/1.1.0/filter.xsd

I changed the GET request to use WFS 1.1 and can confirm that matchCase="false" works. The request matches "illino*" to "Illinois":
http://localhost:8080/geoserver/wfs?service=WFS&version=1.1.0&request=GetFeature&typename=topp:states&filter=<ogc:Filter%20xmlns:ogc="http://www.opengis.net/ogc"><ogc:PropertyIsLike%20matchCase="false"%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><ogc:PropertyName>topp:STATE_NAME</ogc:PropertyName><ogc:Literal>illino*</ogc:Literal></ogc:PropertyIsLike></ogc:Filter>

*But* if I look at even the latest schemas and standard for FES 2.0.2, there is no matchCase on PropertyIsLike:
http://schemas.opengis.net/filter/2.0/filter.xsd
http://docs.opengeospatial.org/is/09-026r2/09-026r2.html

I think this is a bug in the FES 2.0.2 schemas. I think GeoServer will need updated schemas to fix this for WFS 2.0 (and we can see that the XML parsing is horribly broken without this fix). We may need a change request (or an email to the standard maintainer):
http://www.opengeospatial.org/standards/cr

If I add a single line to the definition of PropertyIsLikeType in the copy of the FES 2.0 schemas in GeoTools gt-xsd-fes:
modules/extension/xsd/xsd-fes/src/main/resources/org/geotools/filter/v2_0/filter.xsd

<xsd:attribute name="matchCase" type="xsd:boolean" use="optional" default="true"/>

then suddenly matchCase="false" on PropertyIsLike starts working for WFS 2.0 in GeoServer, just as as for WFS 1.1:
http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20matchCase="false"%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>illino*</fes:Literal></fes:PropertyIsLike></fes:Filter>

GeoServer also supports a CQL_FILTER vendor parameter that has case insensitive "ilike" support:
http://docs.geoserver.org/latest/en/user/services/wfs/vendor.html#cql-filters

See the "strToLowerCase(STATE_NAME) like '%m%'" example in the tutorial:
http://docs.geoserver.org/latest/en/user/tutorials/cql/cql_tutorial.html
or the "ilike" predicate:
http://docs.geoserver.org/latest/en/user/filter/ecql_reference.html

As for letters outside ASCII ("Ü", "Ö", "Ä", "ü", "ö", "ä"), if you are using them in URLs such as encoded filters, are you percent-encoding these as required by RFC 3986?:
https://en.wikipedia.org/wiki/Percent-encoding
https://tools.ietf.org/html/rfc3986

$ python
Python 2.7.11 (default, Jan 11 2016, 21:04:40)
[GCC 5.3.1 20160101] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib
>>> for c in ("Ü", "Ö", "Ä", "ü", "ö", "ä"): print c, urllib.quote(c)
...
Ü %C3%9C
Ö %C3%96
Ä %C3%84
ü %C3%BC
ö %C3%B6
ä %C3%A4

Kind regards,
Ben.

On 21/01/16 22:15, Nhan Vo wrote:

Hi Ben,

Thanks for the helpful reply. The exception message was indeed
misleading. A couple of points left, I hope you'd look into them:

1. How come matchCase was supported in version 2.3.5 but not anymore in
2.8.1? Personally I find it really useful. Is there a way to make a
search with PropertyIsLike case-insensitive?

2. I had this problem already with version 2.3.5 and it seems to persist
in version 2.8.1: When the search text contains a German letter with
umlaut in upper-case (Ü, Ö, Ä), I got the exception "Attempted to
construct illegal filter - I dont understand the tag:
fes:ValueReference. HINT: tags are case-sensitive!". ü, ö, ä are
however fine. As an added advantage with matchCase='false' I could get
around this problem, but not anymore in 2.8.1. If possible could you
shed some light on this?

Any hints or pointers are much appreciated!

Best regards,
Nhan Vo

On 1/20/2016 11:44 PM, Ben Caradoc-Davies wrote:

Nhan Vo,

neither singleChar="%" nor singleChar="#" work for me until I
percent-encode them as singleChar="%25" or singleChar="%23"
respectively. "%" is used for URL percent-encoding and "#" is the URL
fragment separator and neither can be used unencoded in a URL. I am
surprised that either worked for you before. Perhaps older Java or
GeoServer was more permissive, or your client is encoding one but not
the other? I think Java 8 may have added better unicode support in
percent decoding; this may be the change.

Furthermore, matchCase is not permitted on PropertyIsLike. Including
this attribute caused the rather unhelpful error message: "Attempted
to construct illegal filter - I dont understand the tag:
fes:ValueReference. HINT: tags are case-sensitive!"

Both of these URLs work for me against the current GeoServer master
release configuration with Java 8:

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>*</fes:Literal></fes:PropertyIsLike></fes:Filter>

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%25"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>*</fes:Literal></fes:PropertyIsLike></fes:Filter>

Kind regards,
Ben.

On 21/01/16 02:04, Nhan Vo wrote:

Hi,

Thanks for the response. This URL works:
http://192.168.0.102:8081/geoserver/wfs?VERSION=2.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=topp:states&FILTER=<fes:Filter%20xmlns:fes=‘http://www.opengis.net/fes/2.0’%20xmlns:gml=‘http://www.opengis.net/gml/3.2’><fes:PropertyIsLike%20matchCase=‘false’%20wildCard=‘*’%20singleChar='%'%20escapeChar='!'%3E%3Cfes:ValueReference%3Etopp:STATE_NAME%3C/fes:ValueReference%3E%3Cfes:Literal%3E*%3C/fes:Literal%3E%3C/fes:PropertyIsLike%3E%3C/fes:Filter%3E

This does not work:
http://192.168.0.102:8081/geoserver/wfs?VERSION=2.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=topp:states&FILTER=<fes:Filter%20xmlns:fes=‘http://www.opengis.net/fes/2.0’%20xmlns:gml=‘http://www.opengis.net/gml/3.2’><fes:PropertyIsLike%20matchCase=‘false’%20wildCard=‘*’%20singleChar=‘#’%20escapeChar=‘!’><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>*</fes:Literal></fes:PropertyIsLike></fes:Filter>

The only difference is /*singleChar='%'*/ and /*singleChar='#'*/.

Best regards,
Nhan Vo

On 1/20/2016 1:53 PM, Rahkonen Jukka (MML) wrote:

Hi,

Can you reproduce the issue with the demo layer ”states”? If you
can, please
send the whole GET url for making testing convenient for the others.

Regards,

-Jukka Rahkonen-

Nhan Vo wrote:

Hi list,

I'm upgrading Geoserver from 2.3.5 to 2.8.1 and my client code
cannot work
anymore. Basically it sends a WFS Url request with a filter to
Geoserver. The
filter looks as follows:

<fes:Filter xmlns:fes='http://www.opengis.net/fes/2.0’
xmlns:gml='http://www.opengis.net/gml/3.2’>
    <fes:PropertyIsLike matchCase='false' wildCard='*' singleChar='#'
escapeChar='!'>
<fes:ValueReference>...</fes:ValueReference>
        <fes:Literal>...</fes:Literal>
    </fes:PropertyIsLike>
</fes:Filter>

With version 2.8.1 I receive the exception message:*XML document
structures
must start and end within the same entity*

I have been able to get around this by replacing */singleChar='#'/*
with
*/singleChar='%'/*, but still cannot understand why the '#' causes the
problem. Also, '.' and '_' do not work either and I receive the same
exception
message. Only '%' works.

Btw, Geoserver 2.3.5 was running with Java 6; when I updated to
2.8.1 I also
updated to Java 8.

If someone could shed some light on this I'd appreciate it.

Best regards,
Nhan Vo

------------------------------------------------------------------------------

Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Bart_van_den_Eijnde1 · January 21, 2016, 9:49pm

Nhan Vo,

I checked the GeoTools copy of the Filter 2.0 schema and it is unchanged since 2011. Perhaps the parser has changed and now ignores the invalid attribute? I do not know.

I tried both your URLs with GeoServer master and neither results in an exception. Both return numberMatched="0" and the logs contain:
filter = [ topp:STATE_NAME is like ü* ]
filter = [ topp:STATE_NAME is like Ü* ]
respectively.

What is the encoding used by your platform? I am using UTF-8. If you are not using UTF-8, perhaps GeoServer is making incorrect assumptions about encoding at some point while handling the filter?

Kind regards,
Ben.

On 22/01/16 02:15, Nhan Vo wrote:

Hi Ben,

Thanks a lot for the detailed reply and the hints. I can confirm that in
my case filter 2.0 was used with version 2.3.5. It is exactly like it is
now and I have just removed matchCase to make it work in version 2.8.1
according to your explanation. Perhaps someone has modified the schema
in the meantime to make it conform with Filter 2.0 spec?

Regarding the umlauts, I use URLEncoder.encode() to encode the filter
part and it seems to properly percent-encode the letters.

Please try the following, which is the working example from you in your
previous email in which I just replace the literal "*" with "ü*" and "Ü*":

This (with "ü*") works although returning 0 records:

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>ü*</fes:Literal></fes:PropertyIsLike></fes:Filter>

This (with "Ü*") breaks the XML parsing, and we receive the exception:

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>Ü*</fes:Literal></fes:PropertyIsLike></fes:Filter>

I've tried the 2 Urls above with Geoserver 2.8.1.

Best regards,
Nhan Vo

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

Nhan_Vo · January 22, 2016, 9:04am

Hi Ben,

Thanks again for the response. Under my Geoserver's Settings/Global/Character Set the value is UTF-8 but I still I had the parsing problem with "Ü". Then I restart my server adding -Dfile.encoding=UTF-8 to Java options the problem goes away. Perhaps somewhere in the code the Parser was constructed without explicitly specifying an encoding. I post the stack trace here just in case it could help locate the culprit.

Unable to parse filter: <fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike wildCard="*" singleChar="#" escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>�?*</fes:Literal></fes:PropertyIsLike></fes:Filter>
com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Ung�ltiges Byte 2 von 2-Byte-UTF-8-Sequenz.
     at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.invalidByte(UTF8Reader.java:701)
     at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(UTF8Reader.java:372)
     at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1790)
     at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.peekChar(XMLEntityScanner.java:503)
     at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2719)
     at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)
     at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:118)
     at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
     at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
     at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
     at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
     at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
     at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
     at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:327)
     at org.geotools.xml.Parser.parse(Parser.java:240)
     at org.geotools.xml.Parser.parse(Parser.java:170)
     at org.geoserver.wfs.kvp.FilterKvpParser.parse(FilterKvpParser.java:84)
     at org.geoserver.ows.util.KvpUtils.parse(KvpUtils.java:421)
     at org.geoserver.ows.Dispatcher.parseKVP(Dispatcher.java:1473)
     at org.geoserver.ows.Dispatcher.parseKVP(Dispatcher.java:1469)
     at org.geoserver.ows.Dispatcher.init(Dispatcher.java:326)
     at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:245)
     at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
     at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
     at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:923)
     at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:852)
     at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:882)
     at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:778)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter(ThreadLocalsCleanupFilter.java:28)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:75)
     at org.geoserver.wms.animate.AnimatorFilter.doFilter(AnimatorFilter.java:71)
     at org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:71)
     at org.geoserver.filters.SpringDelegatingFilter.doFilter(SpringDelegatingFilter.java:46)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.platform.AdvancedDispatchFilter.doFilter(AdvancedDispatchFilter.java:50)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:311)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69)
     at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:116)
     at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73)
     at org.geoserver.security.filter.GeoServerCompositeFilter.doFilter(GeoServerCompositeFilter.java:92)
     at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69)
     at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73)
     at org.geoserver.security.filter.GeoServerCompositeFilter.doFilter(GeoServerCompositeFilter.java:92)
     at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)
     at org.geoserver.security.filter.GeoServerAnonymousAuthenticationFilter.doFilter(GeoServerAnonymousAuthenticationFilter.java:54)
     at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69)
     at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:150)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73)
     at org.geoserver.security.filter.GeoServerCompositeFilter.doFilter(GeoServerCompositeFilter.java:92)
     at org.geoserver.security.filter.GeoServerBasicAuthenticationFilter.doFilter(GeoServerBasicAuthenticationFilter.java:83)
     at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69)
     at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
     at org.geoserver.security.filter.GeoServerSecurityContextPersistenceFilter$1.doFilter(GeoServerSecurityContextPersistenceFilter.java:53)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73)
     at org.geoserver.security.filter.GeoServerCompositeFilter.doFilter(GeoServerCompositeFilter.java:92)
     at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)
     at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:173)
     at org.geoserver.security.GeoServerSecurityFilterChainProxy.doFilter(GeoServerSecurityFilterChainProxy.java:135)
     at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
     at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:87)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:42)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.filters.SessionDebugFilter.doFilter(SessionDebugFilter.java:48)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.filters.FlushSafeFilter.doFilter(FlushSafeFilter.java:44)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
     at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)

org.geoserver.platform.ServiceException: org.xml.sax.SAXException: Attempted to construct illegal filter - I dont understand the tag: fes:ValueReference. HINT: tags are case-sensitive!
     at org.geoserver.wfs.kvp.FilterKvpParser.parseXMLFilterWithOldParser(FilterKvpParser.java:145)
     at org.geoserver.wfs.kvp.FilterKvpParser.parse(FilterKvpParser.java:96)
     at org.geoserver.ows.util.KvpUtils.parse(KvpUtils.java:421)
     at org.geoserver.ows.Dispatcher.parseKVP(Dispatcher.java:1473)
     at org.geoserver.ows.Dispatcher.parseKVP(Dispatcher.java:1469)
     at org.geoserver.ows.Dispatcher.init(Dispatcher.java:326)
     at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:245)
     at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
     at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
     at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:923)
     at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:852)
     at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:882)
     at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:778)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter(ThreadLocalsCleanupFilter.java:28)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:75)
     at org.geoserver.wms.animate.AnimatorFilter.doFilter(AnimatorFilter.java:71)
     at org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:71)
     at org.geoserver.filters.SpringDelegatingFilter.doFilter(SpringDelegatingFilter.java:46)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.platform.AdvancedDispatchFilter.doFilter(AdvancedDispatchFilter.java:50)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:311)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69)
     at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:116)
     at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73)
     at org.geoserver.security.filter.GeoServerCompositeFilter.doFilter(GeoServerCompositeFilter.java:92)
     at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69)
     at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73)
     at org.geoserver.security.filter.GeoServerCompositeFilter.doFilter(GeoServerCompositeFilter.java:92)
     at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)
     at org.geoserver.security.filter.GeoServerAnonymousAuthenticationFilter.doFilter(GeoServerAnonymousAuthenticationFilter.java:54)
     at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69)
     at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:150)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73)
     at org.geoserver.security.filter.GeoServerCompositeFilter.doFilter(GeoServerCompositeFilter.java:92)
     at org.geoserver.security.filter.GeoServerBasicAuthenticationFilter.doFilter(GeoServerBasicAuthenticationFilter.java:83)
     at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:69)
     at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
     at org.geoserver.security.filter.GeoServerSecurityContextPersistenceFilter$1.doFilter(GeoServerSecurityContextPersistenceFilter.java:53)
     at org.geoserver.security.filter.GeoServerCompositeFilter$NestedFilterChain.doFilter(GeoServerCompositeFilter.java:73)
     at org.geoserver.security.filter.GeoServerCompositeFilter.doFilter(GeoServerCompositeFilter.java:92)
     at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:323)
     at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:173)
     at org.geoserver.security.GeoServerSecurityFilterChainProxy.doFilter(GeoServerSecurityFilterChainProxy.java:135)
     at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
     at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:87)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:42)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.filters.SessionDebugFilter.doFilter(SessionDebugFilter.java:48)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.geoserver.filters.FlushSafeFilter.doFilter(FlushSafeFilter.java:44)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
     at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
     at java.lang.Thread.run(Thread.java:745)
Caused by: org.xml.sax.SAXException: Attempted to construct illegal filter - I dont understand the tag: fes:ValueReference. HINT: tags are case-sensitive!
     at org.geotools.filter.FilterFilter.startElement(FilterFilter.java:154)
     at org.geotools.gml.GMLFilterGeometry.startElement(GMLFilterGeometry.java:174)
     at org.geotools.gml.GMLFilterDocument.startElement(GMLFilterDocument.java:167)
     at org.xml.sax.helpers.ParserAdapter.startElement(ParserAdapter.java:622)
     at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:461)
     at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1364)
     at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2787)
     at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)
     at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
     at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
     at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
     at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
     at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
     at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
     at org.xml.sax.helpers.ParserAdapter.parse(ParserAdapter.java:430)
     at org.geoserver.wfs.kvp.FilterKvpParser.parseXMLFilterWithOldParser(FilterKvpParser.java:142)
     ... 86 more

Best regards,
Nhan Vo

On 1/21/2016 10:49 PM, Ben Caradoc-Davies wrote:

Nhan Vo,

I checked the GeoTools copy of the Filter 2.0 schema and it is unchanged since 2011. Perhaps the parser has changed and now ignores the invalid attribute? I do not know.

I tried both your URLs with GeoServer master and neither results in an exception. Both return numberMatched="0" and the logs contain:
filter = [ topp:STATE_NAME is like ü* ]
filter = [ topp:STATE_NAME is like Ü* ]
respectively.

What is the encoding used by your platform? I am using UTF-8. If you are not using UTF-8, perhaps GeoServer is making incorrect assumptions about encoding at some point while handling the filter?

Kind regards,
Ben.

On 22/01/16 02:15, Nhan Vo wrote:

Hi Ben,

Thanks a lot for the detailed reply and the hints. I can confirm that in
my case filter 2.0 was used with version 2.3.5. It is exactly like it is
now and I have just removed matchCase to make it work in version 2.8.1
according to your explanation. Perhaps someone has modified the schema
in the meantime to make it conform with Filter 2.0 spec?

Regarding the umlauts, I use URLEncoder.encode() to encode the filter
part and it seems to properly percent-encode the letters.

Please try the following, which is the working example from you in your
previous email in which I just replace the literal "*" with "ü*" and "Ü*":

This (with "ü*") works although returning 0 records:

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>ü*</fes:Literal></fes:PropertyIsLike></fes:Filter>

This (with "Ü*") breaks the XML parsing, and we receive the exception:

http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>Ü*</fes:Literal></fes:PropertyIsLike></fes:Filter>

I've tried the 2 Urls above with Geoserver 2.8.1.

Best regards,
Nhan Vo

--

*Thanh-Trong-Nhan Vo*

smile consult GmbH
Vahrenwalder Straße 4
D-30165 Hannover

Tel:

0511/543617-46

Fax:

0511/543617-66

Mail:

nhanvo@anonymised.com <mailto:nhanvo@anonymised.com>

Internet:

http://www.smileconsult.de/>

Geschäftsführer: Frank Sellerhoff •Peter Milbradt •Christoph Lippert
USt-IdNr.: DE208857046 •Amtsgericht Hannover HRB 58707

Bart_van_den_Eijnde1 · January 23, 2016, 1:26am

Nhan Vo,

I think you are not only correct but have located the culprit. I was able to reproduce the problem for both "ü*" and "Ü*" if I run GeoServer with -Dfile.encoding=ISO-8859-15 and try the two links you provided earlier. I have documented this failure and how to reproduce it in a Jira issue:
https://osgeo-org.atlassian.net/browse/GEOS-7385

I was so pleased by your detailed report that I wrote a unit test to demonstrate the failure and also a fix, which I have submitted in this pull request:
https://github.com/geoserver/geoserver/pull/1446

Note that, even with this fix, platforms using a non-UTF-8 default charset will not be able to support characters outside their charset in a WFS KVP Filter.

Kind regards,
Ben.

On 22/01/16 22:04, Nhan Vo wrote:

Hi Ben,

Thanks again for the response. Under my Geoserver's Settings/Global/Character
Set the value is UTF-8 but I still I had the parsing problem with "Ü". Then I
restart my server adding -Dfile.encoding=UTF-8 to Java options the problem goes
away. Perhaps somewhere in the code the Parser was constructed without
explicitly specifying an encoding. I post the stack trace here just in case it
could help locate the culprit.

Unable to parse filter: <fes:Filter
xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike wildCard="*"
singleChar="#"
escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>�?*</fes:Literal></fes:PropertyIsLike></fes:Filter>
com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException:
Ung�ltiges Byte 2 von 2-Byte-UTF-8-Sequenz. at

[...]

org.geoserver.wfs.kvp.FilterKvpParser.parse(FilterKvpParser.java:84)

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

Bart_van_den_Eijnde1 · January 23, 2016, 3:14am

Nhan Vo,

I have contacted the chair of the OGC WFS/FES standard technical committee, who has confirmed that the lack of matchCase on PropertyIsLike in the Filter 2.0.2 schemas and standard is a known issue. He is following up with OGC.

When the Filter 2.0 schemas are updated to include matchCase on PropertyIsLike, we just need to apply this change to the schemas in gt-xsd-fes and GeoServer will start permitting matchCase on PropertyIsLike.

We should also add test coverage for matchCase to gs-wfs Filter_2_0_0_KvpParserTest, once this new test is merged and matchCase is in the Filter 2.0 schemas. Test coverage will prevent any future regressions.

Kind regards,
Ben.

On 22/01/16 01:23, Ben Caradoc-Davies wrote:

I looked a little deeper and matchCase="false" *should* be supported on
PropertyIsLike in GeoServer WFS 1.1 because Niels kindly updated
GeoTools to use the FES 1.1.3 schemas back in 2013 to add matchCase support:
http://osgeo-org.1560.x6.nabble.com/ogc-filter-1-1-doesn-t-support-matchCase-in-PropertyIsLike-td5079577.html
https://github.com/geotools/geotools/commit/4855cba310362f488d5686eda1fff17d7d02c714
http://schemas.opengis.net/filter/1.1.0/filter.xsd

I changed the GET request to use WFS 1.1 and can confirm that
matchCase="false" works. The request matches "illino*" to "Illinois":
http://localhost:8080/geoserver/wfs?service=WFS&version=1.1.0&request=GetFeature&typename=topp:states&filter=<ogc:Filter%20xmlns:ogc="http://www.opengis.net/ogc"><ogc:PropertyIsLike%20matchCase="false"%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><ogc:PropertyName>topp:STATE_NAME</ogc:PropertyName><ogc:Literal>illino*</ogc:Literal></ogc:PropertyIsLike></ogc:Filter>

*But* if I look at even the latest schemas and standard for FES 2.0.2,
there is no matchCase on PropertyIsLike:
http://schemas.opengis.net/filter/2.0/filter.xsd
http://docs.opengeospatial.org/is/09-026r2/09-026r2.html

I think this is a bug in the FES 2.0.2 schemas. I think GeoServer will
need updated schemas to fix this for WFS 2.0 (and we can see that the
XML parsing is horribly broken without this fix). We may need a change
request (or an email to the standard maintainer):
http://www.opengeospatial.org/standards/cr

If I add a single line to the definition of PropertyIsLikeType in the
copy of the FES 2.0 schemas in GeoTools gt-xsd-fes:
modules/extension/xsd/xsd-fes/src/main/resources/org/geotools/filter/v2_0/filter.xsd
<xsd:attribute name="matchCase" type="xsd:boolean" use="optional"
default="true"/>

then suddenly matchCase="false" on PropertyIsLike starts working for WFS
2.0 in GeoServer, just as as for WFS 1.1:
http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20matchCase="false"%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>illino*</fes:Literal></fes:PropertyIsLike></fes:Filter>

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

Bart_van_den_Eijnde1 · January 26, 2016, 1:49am

I have implemented an even better solution so that platforms using a non-UTF-8 default charset *will* be able to support characters outside of this charset in a WFS KVP Filter:

[GEOS-7385] Do not re-encode Filter in default charset when parsing WFS KVP Filter
https://github.com/geoserver/geoserver/pull/1449
https://osgeo-org.atlassian.net/browse/GEOS-7385

Kind regards,
Ben.

On 23/01/16 14:26, Ben Caradoc-Davies wrote:

Nhan Vo,

I think you are not only correct but have located the culprit. I was
able to reproduce the problem for both "ü*" and "Ü*" if I run GeoServer
with -Dfile.encoding=ISO-8859-15 and try the two links you provided
earlier. I have documented this failure and how to reproduce it in a
Jira issue:
https://osgeo-org.atlassian.net/browse/GEOS-7385

I was so pleased by your detailed report that I wrote a unit test to
demonstrate the failure and also a fix, which I have submitted in this
pull request:
https://github.com/geoserver/geoserver/pull/1446

Note that, even with this fix, platforms using a non-UTF-8 default
charset will not be able to support characters outside their charset in
a WFS KVP Filter.

Kind regards,
Ben.

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

Bart_van_den_Eijnde1 · June 18, 2017, 4:16am

I have just heard back from the chair of the OGC WFS/FES technical committee. The Filter schemas and standard have now been updated to version 2.0.3, which includes matchCase on PropertyIsLike. I will patch our copy of this schema to include matchCase on PropertyIsLike. This will enable matchCase on PropertyIsLike in WFS 2.0 requests:
https://osgeo-org.atlassian.net/browse/GEOT-5343

Kind regards,
Ben.

On 23/01/16 16:14, Ben Caradoc-Davies wrote:

Nhan Vo,

I have contacted the chair of the OGC WFS/FES standard technical
committee, who has confirmed that the lack of matchCase on
PropertyIsLike in the Filter 2.0.2 schemas and standard is a known
issue. He is following up with OGC.

When the Filter 2.0 schemas are updated to include matchCase on
PropertyIsLike, we just need to apply this change to the schemas in
gt-xsd-fes and GeoServer will start permitting matchCase on PropertyIsLike.

We should also add test coverage for matchCase to gs-wfs
Filter_2_0_0_KvpParserTest, once this new test is merged and matchCase
is in the Filter 2.0 schemas. Test coverage will prevent any future
regressions.

Kind regards,
Ben.

On 22/01/16 01:23, Ben Caradoc-Davies wrote:

I looked a little deeper and matchCase="false" *should* be supported on
PropertyIsLike in GeoServer WFS 1.1 because Niels kindly updated
GeoTools to use the FES 1.1.3 schemas back in 2013 to add matchCase support:
http://osgeo-org.1560.x6.nabble.com/ogc-filter-1-1-doesn-t-support-matchCase-in-PropertyIsLike-td5079577.html
https://github.com/geotools/geotools/commit/4855cba310362f488d5686eda1fff17d7d02c714
http://schemas.opengis.net/filter/1.1.0/filter.xsd

I changed the GET request to use WFS 1.1 and can confirm that
matchCase="false" works. The request matches "illino*" to "Illinois":
http://localhost:8080/geoserver/wfs?service=WFS&version=1.1.0&request=GetFeature&typename=topp:states&filter=<ogc:Filter%20xmlns:ogc="http://www.opengis.net/ogc"><ogc:PropertyIsLike%20matchCase="false"%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><ogc:PropertyName>topp:STATE_NAME</ogc:PropertyName><ogc:Literal>illino*</ogc:Literal></ogc:PropertyIsLike></ogc:Filter>

*But* if I look at even the latest schemas and standard for FES 2.0.2,
there is no matchCase on PropertyIsLike:
http://schemas.opengis.net/filter/2.0/filter.xsd
http://docs.opengeospatial.org/is/09-026r2/09-026r2.html

I think this is a bug in the FES 2.0.2 schemas. I think GeoServer will
need updated schemas to fix this for WFS 2.0 (and we can see that the
XML parsing is horribly broken without this fix). We may need a change
request (or an email to the standard maintainer):
http://www.opengeospatial.org/standards/cr

If I add a single line to the definition of PropertyIsLikeType in the
copy of the FES 2.0 schemas in GeoTools gt-xsd-fes:
modules/extension/xsd/xsd-fes/src/main/resources/org/geotools/filter/v2_0/filter.xsd
<xsd:attribute name="matchCase" type="xsd:boolean" use="optional"
default="true"/>

then suddenly matchCase="false" on PropertyIsLike starts working for WFS
2.0 in GeoServer, just as as for WFS 1.1:
http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20matchCase="false"%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>illino*</fes:Literal></fes:PropertyIsLike></fes:Filter>

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

Bart_van_den_Eijnde1 · July 30, 2017, 9:47pm

I have applied this fix to master, stable, and maintenance. Support for matchCase on PropertyIsLike in WFS 2.0 requests will be included in GeoServer 2.12-beta, 2.11.2, and 2.10.5.

Kind regards,
Ben.

On 18/06/17 16:16, Ben Caradoc-Davies wrote:

I have just heard back from the chair of the OGC WFS/FES technical committee. The Filter schemas and standard have now been updated to version 2.0.3, which includes matchCase on PropertyIsLike. I will patch our copy of this schema to include matchCase on PropertyIsLike. This will enable matchCase on PropertyIsLike in WFS 2.0 requests:
https://osgeo-org.atlassian.net/browse/GEOT-5343

Kind regards,
Ben.

On 23/01/16 16:14, Ben Caradoc-Davies wrote:

Nhan Vo,

I have contacted the chair of the OGC WFS/FES standard technical
committee, who has confirmed that the lack of matchCase on
PropertyIsLike in the Filter 2.0.2 schemas and standard is a known
issue. He is following up with OGC.

When the Filter 2.0 schemas are updated to include matchCase on
PropertyIsLike, we just need to apply this change to the schemas in
gt-xsd-fes and GeoServer will start permitting matchCase on PropertyIsLike.

We should also add test coverage for matchCase to gs-wfs
Filter_2_0_0_KvpParserTest, once this new test is merged and matchCase
is in the Filter 2.0 schemas. Test coverage will prevent any future
regressions.

Kind regards,
Ben.

On 22/01/16 01:23, Ben Caradoc-Davies wrote:

I looked a little deeper and matchCase="false" *should* be supported on
PropertyIsLike in GeoServer WFS 1.1 because Niels kindly updated
GeoTools to use the FES 1.1.3 schemas back in 2013 to add matchCase support:
http://osgeo-org.1560.x6.nabble.com/ogc-filter-1-1-doesn-t-support-matchCase-in-PropertyIsLike-td5079577.html

https://github.com/geotools/geotools/commit/4855cba310362f488d5686eda1fff17d7d02c714

http://schemas.opengis.net/filter/1.1.0/filter.xsd

I changed the GET request to use WFS 1.1 and can confirm that
matchCase="false" works. The request matches "illino*" to "Illinois":
http://localhost:8080/geoserver/wfs?service=WFS&version=1.1.0&request=GetFeature&typename=topp:states&filter=<ogc:Filter%20xmlns:ogc="http://www.opengis.net/ogc"><ogc:PropertyIsLike%20matchCase="false"%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><ogc:PropertyName>topp:STATE_NAME</ogc:PropertyName><ogc:Literal>illino*</ogc:Literal></ogc:PropertyIsLike></ogc:Filter>

*But* if I look at even the latest schemas and standard for FES 2.0.2,
there is no matchCase on PropertyIsLike:
http://schemas.opengis.net/filter/2.0/filter.xsd
http://docs.opengeospatial.org/is/09-026r2/09-026r2.html

I think this is a bug in the FES 2.0.2 schemas. I think GeoServer will
need updated schemas to fix this for WFS 2.0 (and we can see that the
XML parsing is horribly broken without this fix). We may need a change
request (or an email to the standard maintainer):
http://www.opengeospatial.org/standards/cr

If I add a single line to the definition of PropertyIsLikeType in the
copy of the FES 2.0 schemas in GeoTools gt-xsd-fes:
modules/extension/xsd/xsd-fes/src/main/resources/org/geotools/filter/v2_0/filter.xsd

<xsd:attribute name="matchCase" type="xsd:boolean" use="optional"
default="true"/>

then suddenly matchCase="false" on PropertyIsLike starts working for WFS
2.0 in GeoServer, just as as for WFS 1.1:
http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&filter=<fes:Filter%20xmlns:fes="http://www.opengis.net/fes/2.0"><fes:PropertyIsLike%20matchCase="false"%20wildCard="*"%20singleChar="%23"%20escapeChar="!"><fes:ValueReference>topp:STATE_NAME</fes:ValueReference><fes:Literal>illino*</fes:Literal></fes:PropertyIsLike></fes:Filter>

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand