[Geoserver-devel] Omitting service=wfs from a KVP WFS 2.0 request has unpredictable results

I was doing some testing with WFS GetFeature requests, and ran into some rather startling behaviour.

First of all, omitting the “service=wfs” parameter from a KVP-encoded request generally works just fine, as long as you are using the WFS virtual service endpoint. However, sometimes it doesn’t. All testing is done with a GeoServer 2.10.2 installation with no extensions:

With service=wfs:

http://localhost:8080/geoserver/wfs?service=wfs&request=GetFeature&typenames=sf:roads&version=2.0.0

returns all property values for all features in sf:roads

http://localhost:8080/geoserver/wfs?service=wfs&request=GetFeature&typenames=sf:roads&version=2.0.0&propertyname=

returns all property values for all features in sf:roads

http://localhost:8080/geoserver/wfs?service=wfs&request=GetFeature&typenames=sf:roads&version=2.0.0&propertyname=*

returns all property values for all features in sf:roads

http://localhost:8080/geoserver/wfs?service=wfs&request=GetFeature&typenames=sf:roads&version=2.0.0&propertyname=cat

returns all values for cat property for all features in sf:roads

http://localhost:8080/geoserver/wfs?service=wfs&request=GetFeature&typenames=sf:roads&version=2.0.0&propertyname=cat,label

returns all values for cat and label properties for all features in sf:roads

Without service=wfs:

http://localhost:8080/geoserver/wfs?request=GetFeature&typenames=sf:roads&version=2.0.0

returns all property values for all features in sf:roads

http://localhost:8080/geoserver/wfs?request=GetFeature&typenames=sf:roads&version=2.0.0&propertyname=

<ows:Exception exceptionCode=“NoApplicableCode”>
ows:ExceptionTextjava.lang.NullPointerException</ows:ExceptionText>
</ows:Exception>

http://localhost:8080/geoserver/wfs?request=GetFeature&typenames=sf:roads&version=2.0.0&propertyname=*

<ows:Exception exceptionCode=“NoApplicableCode”>
ows:ExceptionTextjava.lang.NullPointerException</ows:ExceptionText>
</ows:Exception>

http://localhost:8080/geoserver/wfs?request=GetFeature&typenames=sf:roads&version=2.0.0&propertyname=cat

<ows:Exception exceptionCode=“NoApplicableCode”>
ows:ExceptionText
java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Collection java.lang.String cannot be cast to java.util.Collection
</ows:ExceptionText>
</ows:Exception>

http://localhost:8080/geoserver/wfs?request=GetFeature&typenames=sf:roads&version=2.0.0&propertyname=cat,label

<ows:Exception exceptionCode=“NoApplicableCode”>
ows:ExceptionText
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 Index: 0, Size: 0
</ows:ExceptionText>
</ows:Exception>

Given that all of the above is not actually valid according to the WFS 2.0 specification (the propertyname parameter is not part of the 2.0 spec), this is slightly less problematic. However since we still provide this functionality, some amount of consistency would be good.
Given the errors observed when service=wfs is omitted, it might be best to explicitly throw an error instead when service is not included in the KVP.

Does anyone else have any insight here?

Torben

On Fri, Mar 17, 2017 at 12:23 AM, Torben Barsballe <
tbarsballe@anonymised.com> wrote:

Given that all of the above is not actually valid according to the WFS 2.0
specification (the propertyname parameter is not part of the 2.0 spec),
this is slightly less problematic. However since we still provide this
functionality, some amount of consistency would be good.
Given the errors observed when service=wfs is omitted, it might be best to
explicitly throw an error instead when service is not included in the KVP.

We've been down this road already with the version number, also required,
not mandated by GeoServer in its default configuration, and causing
occasional failures
in kvp parsing when omitted.

I did not check, but I'd guess that service omission might be the same.
Mandating it out of the box is a no go for simple backwards compatibility
issues,
and also because it is going to break existing endpoints like the wms
reflector, kml reflector and animator which normally miss both service and
version
(incidentally, I'm also building the
sort-of-rest-but-not-quite-and-more-kvp-like OpenSearch service on the same
premise as the reflectors,
that the service and method can be put in the path and version is not
required).

I've been down this road in the past for "version", what I found out is
that the kvp parsing should have clear service and version before the
kvpparsers are called, right
now it's a mixed bag, kvp parser get what's in the kvp, if it's available,
and then some code later figures out service and version if they were
missing... but
at that point the dispatcher might have used the wrong kvp parsers.
I did prepare a pull request in my spare time to address this, but Justin
requested me to run the cite tests offline and I never had time (or to be
fair, the inclination
to do so on a weekend);

https://github.com/geoserver/geoserver/pull/574

My take: if you want to try and resurrect that patch, align it with today's
GeoServer, and make it built, I'd say go ahead and commit it on master,
and we'll see what the ares CITE jobs think of it. Our CITE compliance is
in quite some disarray anyways, it's not going to be a big deal if
master is not compliant with our outdated version of the tests for a night
or two imho

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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

Thanks for the link to the PR Andrea (and the explanation of what is going on here). I’ll try and make some time to get that working with the current geoserver.

Torben

···

On Fri, Mar 17, 2017 at 12:30 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Mar 17, 2017 at 12:23 AM, Torben Barsballe <tbarsballe@anonymised.com> wrote:

Given that all of the above is not actually valid according to the WFS 2.0 specification (the propertyname parameter is not part of the 2.0 spec), this is slightly less problematic. However since we still provide this functionality, some amount of consistency would be good.

Given the errors observed when service=wfs is omitted, it might be best to explicitly throw an error instead when service is not included in the KVP.

We’ve been down this road already with the version number, also required, not mandated by GeoServer in its default configuration, and causing occasional failures
in kvp parsing when omitted.

I did not check, but I’d guess that service omission might be the same. Mandating it out of the box is a no go for simple backwards compatibility issues,
and also because it is going to break existing endpoints like the wms reflector, kml reflector and animator which normally miss both service and version
(incidentally, I’m also building the sort-of-rest-but-not-quite-and-more-kvp-like OpenSearch service on the same premise as the reflectors,
that the service and method can be put in the path and version is not required).

I’ve been down this road in the past for “version”, what I found out is that the kvp parsing should have clear service and version before the kvpparsers are called, right
now it’s a mixed bag, kvp parser get what’s in the kvp, if it’s available, and then some code later figures out service and version if they were missing… but
at that point the dispatcher might have used the wrong kvp parsers.
I did prepare a pull request in my spare time to address this, but Justin requested me to run the cite tests offline and I never had time (or to be fair, the inclination
to do so on a weekend);

https://github.com/geoserver/geoserver/pull/574

My take: if you want to try and resurrect that patch, align it with today’s GeoServer, and make it built, I’d say go ahead and commit it on master,
and we’ll see what the ares CITE jobs think of it. Our CITE compliance is in quite some disarray anyways, it’s not going to be a big deal if
master is not compliant with our outdated version of the tests for a night or two imho

Cheers
Andrea

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.