Closed tomkralidis closed 9 years ago
Hi @tomkralidis, I noticed this when testing the 1.13. I'm checking the spex to see how we can work around this. Any ideas?
@lorebiga perhaps, for this specific test case, look for either an OWS 1.0.0 OR 2.0.0 ExceptionReport
?
Yes. I was also thinking that perhaps we may wildcard the namespace...
@lorebiga any status on this one? In current state pycsw fails until this is fixed in CITE.
@tomkralidis, I think this is a bug, as the CSW 2.0.2 specs say (§7.3.2): "If the list does not contain any version numbers that the server supports, the server shall return an Exception with exceptionCode="VersionNegotiationFailed". To ensure backward compatibility, clients shall also be prepared to accept an unknown response and treat this situation as an indication that version negotiation has failed."
I'm generalizing the test accordingly.
@tomkralidis can you confirm the fix is ok? If so, I'll release this as beta.
@lorebiga thanks for the update. FYI pycsw returns an Exception with exceptionCode="VersionNegotiationFailed"
, but via an OWS 2 ExceptionReport
, not an OWS 1 ExceptionReport
.
IHMO this test is best off simply scanning for //exceptionCode
with value VersionNegotiationFailed
independent of the OWS version of the response. Thoughts?
I thought about that, but it would imply assessing the response correctness against the CSW 3.0 specification, which is out of scope in the CSW 2.0.2 ETS.
So I'd rather congregate the CSW 3.0 with the other "unknown responses" (which are however legitimate).
Plus, in case of a strict CSW 2.0.2 response, the ExceptionReport must have a version of 1.2.0, which wouldn't be tested in your approach, if I understand it correctly.
@lorebiga how can, in this case, pycsw pass this test, then? pycsw is emitting 'latest version first' design pattern, as discussed in #8
Suggested approach:
//@exceptionCode==VersionNegotiationFailed
//@locator==acceptversions
(case insensitive)This covers this test case whether the endpoint supports versions > 2.0.2 or not.
I think it should pass the test now, as its response is legitimate. I'm running the test agains pycsw and I get: "Cannot find the declaration of element 'ows20:ExceptionReport'."
The failure I'm getting from CITE is:
test: csw:csw-2.0.2-GetCapabilities-tc1.3
session: 2e35d718-e170-4fba-9e2d-43e9d5cd68b9/d68e6533_1/d68e6403_1/d68e427_1
Assertion: The response to a GetCapabilities request containing an ACCEPTVERSIONS parameter that does not contain any version numbers that the server supports must include an Exception with exceptionCode="VersionNegotiationFailed". Note: to ensure backward compatibility, clients must also be prepared to accept an unknown response and treat this situation as an indication that version negotiation has failed, as expected (e.g., a CSW 3.0 would return a OWS 2.0 Exception).
Message
FAILURE: Missing response entity.
Test result: Failed
Submitted request:
Method=
GETURL=
http://demo.pycsw.org/cite/cswParameters:
SERVICE=
CSWREQUEST=
GetCapabilitiesACCEPTVERSIONS=
2006.10.29
Request body: empty.
Note: testing http://demo.pycsw.org/cite/csw from CITE master via mvn test
I'm testing against this endpoint, which I found in the sut.properties: http://demo.pycsw.org/cite/csw?service=CSW&version=2.0.2&request=GetCapabilities
@lorebiga same here.
The test was still validating against the OWS 1.0, now it should work, please confirm.
Confirmed, works. Thanks @lorebiga!
Good, validation is spread all over the scripts, I had forgotten a call some lines up (CTL is a PITA :-) Thank you for reporting and for your cooperation! I'm rolling this out in the new beta, should be out end of month.
@lorebiga: given 60b469486a9e0c6dfd1a0d1ece29a30163399e93, pycsw fails against
csw-2.0.2-GetCapabilities-tc1.3
.Request: http://demo.pycsw.org/cite/csw?SERVICE=CSW&REQUEST=GetCapabilities&ACCEPTVERSIONS=2006.10.29
The problem is pycsw returns a CSW3-based
ExceptionReport
.Given #8, the nature of this test case and the 'highest version first' design pattern of OWS, can we update this test case to cover accordingly?