Petacope_AcceptVersions in WCS requests

[Bang Pham Huu]

From OGC document ​https://portal.opengeospatial.org/files/09-148r1, WCS request in XML should have a request like this

GetCapabilities
Requirement 3 /req/post-xml/getCapabilities-request-structure:
A GetCapabilities request using POST/XML shall consist of an XML document of type
wcs:GetCapabilities.
Example The following is a minimum GetCapabilities request encoded in XML:
<?xml version="1.0" encoding="UTF-8"?>
<GetCapabilities
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:ows="http://www.opengis.net/ows/1.1"
 xmlns:wcs="http://www.opengis.net/wcs/2.0"
 xsi:schemaLocation=
 "http://schemas.opengis.net/wcs/2.0 ../wcsAll.xsd"
 service="WCS">
 <ows:AcceptVersions>
     <ows:Version>2.0.0</ows:Version>
 </ows:AcceptVersions>
</GetCapabilities>

It was fixed in WCS XML Parser to accept this format, but with KVP Request it uses the request like this

service=WCS&version=2.0.1&request=GetCapabilities

As Petascope only supports WCS version 2.0.1.

However, with some checks with WCS implementation provider

MapServer: ​http://mapserver.org/de/ogc/wcs_server.html#wcs-2-0

# GetCapabilities
http://www.yourserver.com/wcs?SERVICE=WCS&ACCEPTVERSIONS=1.0.0,2.0.1
  &REQUEST=GetCapabilities
http://www.yourserver.com/wcs?SERVICE=WCS&REQUEST=GetCapabilities

and an INSPIRE guidance technical document
​http://inspire.ec.europa.eu/file/1635/download?token=7m3PXp4a

http://myserver.ac.uk/some/folders/ows?
 service=WCS&
 request=GetCapabilities&
 AcceptVersions=2.0.1, 2.0.0&

it shows that version in KVP request should be change to AcceptVersions (even Petascope only supports WCS 2.0.1) in system test, examples,…but keep the version as backward support.

[Bang Pham Huu]

This problem could be solved quickly but I'd need your agreements first.

[Dimitar Misev]

@pbaumann @vmerticariu - can we get your input on this?

[Vlad Merticariu]

We could add an acceptVersions parameter in the KVP requests and treat it as we treat version right now.

I don't think that we can remove version completely as this is the parameter currently used by the clients.

[Peter Baumann]

several issues:

• in rasdaman, VERSION seems mandatory in GetCap, and this breaks the standard
• you indicate clients use this; this would also be in violation of the standard
• ACCEPTVERSIONS needs to support the appropriate mechanics as per OWS Common

IMHO VERSION needs to be removed completely.
What clients use VERSION, actually?

[Dimitar Misev]

Replying to pbaumann:

IMHO VERSION needs to be removed completely.

It should be made optional, removing (I assume you mean throwing an exception when not VERSION is specified) would break a lot of existing clients.

[Peter Baumann]

which one, for example?

[Dimitar Misev]

earthlook demos, raswct, user's own demos.. it might be hard to go through everything and make sure it's fixed.

Perhaps as a first step we could print a warning in the logs: "Using VERSION in a GetCapabilities request is invalid".

[Peter Baumann]

So likely we are talking about our own clients - these should be updated as well to reflect the standard.
I cannot imagine that other tools would be non-conformant in the same way, so this should be safe.

What about:

• we retain VERSION as undocumented feature
• fix our clients
• communicate that VERSION is deprecated
• phase it out in the "near future"
• having a notice in the log is a good idea IMO.

Anyway, currently standards-conformant clients break so we need a fix asap.

[Dimitar Misev]

Replying to pbaumann:

Anyway, currently standards-conformant clients break so we need a fix asap.

It's already fixed, standards-conformant clients will work fine now.

[Bang Pham Huu]

The warning is logged in petascope, wcs client also sends AcceptVersions by default in the newly accepted patch today, so I close this ticket here.

[Peter Baumann]

good work!