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:
<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>
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.
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);
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
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.
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);
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
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.