Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#1508 closed defect (fixed)

Petacope_AcceptVersions in WCS requests

Reported by: Bang Pham Huu Owned by: Bang Pham Huu
Priority: major Milestone: 9.4
Component: petascope Version: development
Keywords: WCS AcceptVersions, version Cc: Peter Baumann, Dimitar Misev, Vlad Merticariu
Complexity: Medium

Description (last modified by 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.

Change History (12)

comment:1 by Bang Pham Huu, 8 years ago

Description: modified (diff)

comment:2 by Bang Pham Huu, 8 years ago

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

comment:3 by Dimitar Misev, 8 years ago

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

comment:4 by Vlad Merticariu, 8 years ago

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.

comment:5 by Peter Baumann, 7 years ago

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?

in reply to:  5 comment:6 by Dimitar Misev, 7 years ago

Replying to pbaumann:

IMHO VERSION needs to be removed completely.

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

Last edited 7 years ago by Dimitar Misev (previous) (diff)

comment:7 by Peter Baumann, 7 years ago

which one, for example?

comment:8 by Dimitar Misev, 7 years ago

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".

comment:9 by Peter Baumann, 7 years ago

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.

in reply to:  9 comment:10 by Dimitar Misev, 7 years ago

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.

comment:11 by Bang Pham Huu, 7 years ago

Resolution: fixed
Status: newclosed

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.

comment:12 by Peter Baumann, 7 years ago

good work!

Note: See TracTickets for help on using tickets.