#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 )
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 , 8 years ago
Description: | modified (diff) |
---|
comment:2 by , 8 years ago
comment:4 by , 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.
follow-up: 6 comment:5 by , 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?
comment:6 by , 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.
comment:8 by , 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".
follow-up: 10 comment:9 by , 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.
comment:10 by , 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 , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
This problem could be solved quickly but I'd need your agreements first.