Hi Jonathan,
version negotiation is indeed something that is not tested by OGC automated
tests, actually some fail
solid if you have multiple versions available at all (not because of our
negotiation issues, it's just that
for example WCS 1.0 tests expect to never find a higher version, like it's
not possible, because there
was not a newer one when they were written).
So, not surprised if there are misbehaviors. Checking them in detail is
rather a drag since one has to satisfy
all OWS specs at the same time (which I hope were consistent but... uh).
Thinking about the code, I believe there are partial bits of negotiation
logic spread around here and there,
when imho it should all be in the OWS dispatcher, where all the services
and their versions are visible.
Been like that for ages, I don't see it getting fixed anytime soon (e.g,,
so far nobody has been bothered to the point of
spending their spare time, or sponsoring development, on it).
Cheers
Andrea
On Sat, Mar 31, 2018 at 8:34 PM, Jonathan Moules <
jonathan-li...@lightpear.com> wrote:
> Hi Andrea, List,
>
> So I'm giving acceptversions a try and have come across quite a number of
> issues. I don't think they're my mistakes, but please do correct me if they
> are.
> These are all against a 2.12.0 deployment
>
> A) WCS AcceptVersions only accepts version 2.0.0 or 2.0.1
> ?request=getCapabilities&service=WCS&acceptversions=1.1.1
>
> What I expect is a WCS 1.1.1 spec. What I get is a WCS 2.0 exception:
>
> <ows:Exception exceptionCode="NoApplicableCode">
> <ows:ExceptionText>
> java.io.IOExceptionjava.lang.IllegalArgumentException: Not a
> GetCapabilitiesType: net.opengis.wcs20.impl.GetCapabilitiesTypeImpl@7416780e
> (updateSequence: null, baseUrl: http://inspire.misoportal.com:
> 80/geoserver/) (service: WCS) Not a GetCapabilitiesType:
> net.opengis.wcs20.impl.GetCapabilitiesTypeImpl@7416780e (updateSequence:
> null, baseUrl: http://inspire.misoportal.com:80/geoserver/) (service:
> WCS) []
> </ows:ExceptionText>
>
> For all my tests it produces an exception if 2.0.0 or 2.0.1 isn't
> somewhere in the acceptVersions parameter.
>
>
> B) If the request is changed to 1.0.0, the request becomes:
> ?request=getCapabilities&service=WCS&AcceptVersions=1.0.0,0.8.3
> (That's copied-and-pasted the example from the OWSCS spec itself)
> The Exception is 2.0
>
> <ows:Exception exceptionCode="VersionNegotiationFailed">
> <ows:ExceptionText>Could not find any matching version
> []</ows:ExceptionText>
> </ows:Exception>
>
> Which seems like it's mis-representing me, I didn't required "version []",
> I requested 1.0.0
>
>
> C) Behaviour changes again if I throw back in the "version" parameter. The
> spec says it should be ignored if acceptversions is there. It turns out the
> AcceptVersions and version must match or you get an exception:
>
> This request:
> ?request=getCapabilities&service=WCS&acceptversions=1.
> 0.0,2.0.0&version=1.1.1
>
> brings back a WCS 1.1.0 exception:
> <ows:Exception exceptionCode="VersionNegotiationFailed">
> <ows:ExceptionText>
> Could not find any matching version [1.0.0, 2.0.0] in supported list:
> [1.0.0, 2.0.0]
> </ows:ExceptionText>
>
> But these two work as expected
> request=getCapabilities&service=WCS&acceptversions=1.
> 0.0,2.0.0&version=2.0.0
> request=getCapabilities&service=WCS&acceptversions=1.
> 0.0,2.0.0&version=1.0.0
>
> -----
> WMS doesn't do acceptVersions as best I can see in the specs and correctly
> ignores that parameter.
>
> -----
> WFS seems better than WCS. I'm not sure what to expect for this response -
> I'm using AcceptVersions which is a WFS 2.0.0 to request a 1.1.0 page
> (which didn't support it). I suspect I should get the 1.1.0 response, but
> the response is the 2.0.0 spec:
> ?request=getCapabilities&service=WFS&acceptversions=1.1.0,2.0.0,1.0.0 -
> returns the 2.0.0 spec
>
> That said, GeoServer still ignores the acceptversions in this request and
> returns a 1.1.0 spec because that's what "version" is asking for - the spec
> says it should be 2.0.0
> ?request=getCapabilities&service=WFS&acceptversions=2.0.0&version=1.1.0
>
> If these seem valid I'll update the ticket or create new a one if desired.
> For my own purposes I think it's safest if I switch back to just "version"
> and don't include "AcceptVersions " at all.
>
> Cheers,
> Jonathan
>
> p.s. - the Above is non-exhaustive manual testing. Some good unit-tests
> across all services may get more.
>
>
>
>
> On 2018-03-30 19:27, Jonathan Moules wrote:
>
> Hi Andrea,
> Ok, I was getting quite confused there for a bit, but I've figured out
> what's going on now. The WCS specs build on another specification - "OGC
> Web Services Common Specification" - and *that* is the place they talk
> about version negotiation. I had assumed because it wasn't specified it
> just built on the previous version (that being 1.0.0). And you are (of
> course) correct, they have indeed replaced Version with AcceptVersions.
> Thanks for the correction!
>
> > WCS 1.0 is probably based on 1.0, WCS 1.1 still probably based on OWS
> 1.0 but not sure, WCS 2.0 I believe is based on OWS 2.0
>
> If you're curious, WCS 1.0 doesn't seem to be based on any - probably why
> it declares that stuff explicitly. WCS 1.1 is OWSC 1.0, WCS 1.1.1 and 1.1.2
> are OWSC 1.1.1, and of course WCS 2 is OWSC 2. "Fun fun" indeed! :-)
>
> > it's not part of the OGC specifications. As such, it's free to behave as
> it pleases when you use it.
>
> It's probably me again, but the OWSC subclause D.11 (both version 1.1 and
> 2.0, (it's subclause C.11 in 1.0)) does seem to cover these scenarios and
> does have provision for what to do if "version" is set. This seems to be
> the pertinent part:
>
> """
> A server may also optionally implement the old-style version negotiation
> mechanism so
> that old clients that send GetCapabilities requests containing a “version”
> parameter can
> be served. If both a “version” and an AcceptVersions parameter exist in a
> GetCapabilities
> request, the server shall ignore the “version” parameter.
>
> a) The old-style version negotiation process using the GetCapabilities
> operation is as
> follows: The client initially makes a GetCapabilities operation request
> identifying the
> latest version it supports, and then the server responds to
> GetCapabilities operation
> requests:
> 1) If no version number is specified in the request, the server shall
> respond with the
> highest version it supports.
> 2) If the version number specified in the request is supported by the
> server, the
> server shall respond with that version.
> 3) If the version number specified in the request is lower than the lowest
> version
> supported by the server, the server shall respond with the lowest version
> that it
> supports.
> 4) If the version number specified in the request is higher than the
> lowest version
> supported by the server, the server shall respond with the highest version
> it
> supports that is lower than the requested version.
> """
>
> So while it's optional, it does seem to be specified what to do if the
> option is implemented. If I'm reading this right, this scenario falls under
> item (4).
>
> But yes, this was mostly just a curious aside before I got drawn into the
> exciting world of OGC standards!
>
> Thanks again!
> Jonathan
>
> On 2018-03-30 18:26, Andrea Aime wrote:
>
> Hi Jonathan,
> as said above, using "version" in GetCapabilities is a GeoServer vendor
> extension, it's not part of the OGC specifications.
> As such, it's free to behave as it pleases when you use it.
>
> The version negotiation protocol is described in the various OWS
> documents, each version of a protocol
> is based on a different version of OWS, e.g., WCS 1.0 is probably based on
> 1.0, WCS 1.1 still probably
> based on OWS 1.0 but not sure, WCS 2.0 I believe is based on OWS 2.0 (fun
> fun):
> http://www.opengeospatial.org/standards/common
>
> Go look for "GetCapabilities request KVP encoding" or something similar to
> find the requested behavior
>
> Cheers
> Andrea
>
>
> On Fri, Mar 30, 2018 at 7:20 PM, Jonathan Moules <
> <jonathan-li...@lightpear.com>jonathan-li...@lightpear.com> wrote:
>
>> Hi Andrea,
>> Interesting, I'd not come across AcceptBersions before. A quick search
>> through the WCS specs (Ctrl-F) indicates it first appears in 1.1.0, then
>> the 1.1.1, and 1.1.2, and finally a single reference in 2.0.1. However none
>> of them actually seem to explain it (they're either UML or XML examples),
>> though I can guess what it does.
>>
>> I've opened a ticket for it (8670).
>>
>> (Incidentally, it's my first ticket using this new portal and I have to
>> say - it's a real chore. Absurdly slow page loads, lots of login/redirect
>> problems across two browsers, and once logged in it's non-obvious how to
>> create a ticket.
>> Also, I there was a big friendly "ACCESS DENIED" which may be as a result
>> of the link I followed to get there - it's repeatable for me if I use the
>> link from here to login -
>> https://osgeo-org.atlassian.net/projects/GEOS/summary
>> - the sign-up link there has the word "admin" in the URL, so I wonder if
>> you're trying to get people to log in to the admin account by accident?)
>>
>> Thanks,
>> Jonathan
>>
>>
>> On 2018-03-30 17:33, Andrea Aime wrote:
>>
>> Hi Jonathan,
>> there migth well be some issue in version negotiation, but the parameter
>> to be used normally
>> is acceptVersions, not version (version works for any other call but
>> GetCapabiltiies, GeoServer still uses it
>> in case there is an exact match). That might play a role too.
>>
>> Cheers
>> Andrea
>>
>>
>> On Fri, Mar 30, 2018 at 5:52 PM, Jonathan Moules <
>> <jonathan-li...@lightpear.com>jonathan-li...@lightpear.com> wrote:
>>
>>> Hi List,
>>> I have a version negotiation question for WCS.
>>>
>>> I'm making GetCapabilities requests to various public boxes for WCS
>>> version 1.1.2, and GeoServer doesn't seem to support this particular
>>> version. GeoServer seems to go from 1.1.1, then straight to 2.0.1; I guess
>>> that's what got funded.
>>>
>>> The odd thing is in this scenario, GeoServer is returning the 2.0.1
>>> GetCap. I would have expected the 1.1.1 GetCapabilities.
>>> The only WCS spec I can see that discusses version negotiation is
>>> the WCS 1.0.0 spec. Section 6.2.4 says:
>>>
>>> " If no version number is specified in the request, the server must
>>> respond with the highest version it understands and label the response
>>> accordingly."
>>>
>>> Ok, but I *did* specify a version number. My query is something like:
>>> http://example.com/geoserver/ows?request=GetCapabilities&se
>>> rvice=WCS&version=1.1.2
>>>
>>> So these are the negotiation rules in the spec:
>>> "a) If the server implements the requested version number, the
>>> server must send that version.
>>>
>>> b) If a version unknown to the server is requested, the server must
>>> send the highest version it knows that is less than the requested version.
>>>
>>> c) If the client request is for a version lower than any of those
>>> known to the server, then the server must send the lowest version it knows.
>>> [snip]"
>>>
>>> So my question is, which of these rules is triggering? To my mind it
>>> should be rule (b) - I'm requesting an unknown number, so the server should
>>> be returning the highest version that's *less* than it, so 1.1.1.
>>> Am I misreading the spec/situation or is this a bug in GeoServer's
>>> negotiating?
>>> Cheers,
>>> Jonathan
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! <http://sdm.link/slashdot>
>>> http://sdm.link/slashdot
>>> _______________________________________________
>>> Geoserver-users mailing list
>>>
>>> Please make sure you read the following two resources before posting to
>>> this list:
>>> - Earning your support instead of buying it, but Ian Turton:
>>> http://www.ianturton.com/talks/foss4g.html#/
>>> - The GeoServer user list posting guidelines:
>>> http://geoserver.org/comm/userlist-guidelines.html
>>>
>>> If you want to request a feature or an improvement, also see this:
>>> <https://github.com/geoserver/g>https://github.com/geoserver/g
>>> eoserver/wiki/Successfully-requesting-and-integrating-new-fe
>>> atures-and-improvements-in-GeoServer
>>>
>>>
>>> Geoserver-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>
>>
>>
>>
>> --
>>
>> Regards,
>>
>> Andrea Aime
>>
>> == 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
>> <https://maps.google.com/?q=Via+di+Montramito+3/A+%0D%0A+55054+%C2%A0Massarosa&entry=gmail&source=g>
>> 55054
>> Massarosa
>> <https://maps.google.com/?q=Via+di+Montramito+3/A+%0D%0A+55054+%C2%A0Massarosa&entry=gmail&source=g>
>> (LU) phone: +39 0584 962313 <+39%200584%20962313> fax: +39 0584 1660272
>> <+39%200584%20166%200272> mob: +39 339 8844549 <+39%20339%20884%204549>
>> 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
>> c ompleteness of sent mes sages 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.
>>
>> --
>
> Regards,
>
> Andrea Aime
>
> == 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
> <https://maps.google.com/?q=Via+di+Montramito+3/A+%0D%0A+55054+%C2%A0Massarosa&entry=gmail&source=g>
> 55054
> Massarosa
> <https://maps.google.com/?q=Via+di+Montramito+3/A+%0D%0A+55054+%C2%A0Massarosa&entry=gmail&source=g>
> (LU) phone: +39 0584 962313 <+39%200584%20962313> fax: +39 0584 1660272
> <+39%200584%20166%200272> mob: +39 339 8844549 <+39%20339%20884%204549>
> 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 f inalità 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 int e nded 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.
>
>
--
Regards,
Andrea Aime
==
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.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
Please make sure you read the following two resources before posting to this
list:
- Earning your support instead of buying it, but Ian Turton:
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines:
http://geoserver.org/comm/userlist-guidelines.html
If you want to request a feature or an improvement, also see this:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
