Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Advice requested for a failing WCS 2.0.1 test #137

Closed
robinhoutmeyers opened this issue May 23, 2024 · 5 comments · Fixed by #138
Closed

Advice requested for a failing WCS 2.0.1 test #137

robinhoutmeyers opened this issue May 23, 2024 · 5 comments · Fixed by #138
Assignees
@dstenger
Labels
bug
Milestone
1.21

Comments

@robinhoutmeyers
Copy link

I am testing our LuciadFusion WCS 2.0.1 implemention against the WCS 2.0 Conformance Test Suite, but there is one failing issue for which it is not clear to me why it is failing.

The test that fails is Test wcs2:get-kvp-core-req30

The test details include the following:

Method: get
URL: https://demo.luciad.com:443/LuciadFusionPlatform2024/ogc/wcs/compliance_test?&service=WCS&VERSION=2.0.1&request=GetCoverage&coverageid=US_Relief&format=image/tiff;subtype="geotiff"&mediatype=multipart/related&subset=dimension_bogus(-168.1,-60.099999999999994)
Error in call to extension function {public org.w3c.dom.NodeList com.occamlab.te.TECore.request(org.w3c.dom.Document,java.lang.String) throws java.lang.Throwable}: Exception in extension function java.lang.RuntimeException: Parser {http://www.occamlab.com/te/parsers}XMLValidatingParser threw an exception.
Result: Failed

At first sight, https://demo.luciad.com:443/LuciadFusionPlatform2024/ogc/wcs/compliance_test?&service=WCS&VERSION=2.0.1&request=GetCoverage&coverageid=US_Relief&format=image/tiff;subtype="geotiff"&mediatype=multipart/related&subset=dimension_bogus(-168.1,-60.099999999999994) returns the expected result.

Do you have any idea what could be the cause of this issue?
@dstenger
Copy link
Contributor

Thank you for reporting.
Indeed, the XMLValidatingParser seems to not be able to parse the response.
We will do further investigation.

@dstenger dstenger transferred this issue from opengeospatial/cite May 23, 2024
@dstenger
Copy link
Contributor

I moved this issue to the ets-wcs20 tracker as it is related to that test suite.

@bpross-52n
Copy link
Contributor

@robinhoutmeyers Imho the failures are caused by value of the format parameter. The test suite send this as is, i.e. not url encoded. The quotation marks seem to cause the problem.
This is the resulting response I captured during my investigations:

<!doctype html><html lang="en"><head><title>HTTP Status 400 – Bad Request</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 400 – Bad Request</h1><hr class="line" /><p><b>Type</b> Exception Report</p><p><b>Message</b> Invalid character found in the request target [&#47;LuciadFusionPlatform&#47;ogc&#47;wcs&#47;compliance_test?service=WCS&amp;request=GetCoverage&amp;version=1.1.1&amp;identifier=Bogus&amp;BoundingBox=-168.1,13.0,-60.099999999999994,75.0,EPSG:4326&amp;Format=image&#47;tiff;subtype=&quot;geotiff&quot;]. The valid characters are defined in RFC 7230 and RFC 3986</p><p><b>Description</b> The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).</p><p><b>Exception</b></p><pre>java.lang.IllegalArgumentException: Invalid character found in the request target [&#47;LuciadFusionPlatform&#47;ogc&#47;wcs&#47;compliance_test?service=WCS&amp;request=GetCoverage&amp;version=1.1.1&amp;identifier=Bogus&amp;BoundingBox=-168.1,13.0,-60.099999999999994,75.0,EPSG:4326&amp;Format=image&#47;tiff;subtype=&quot;geotiff&quot;]. The valid characters are defined in RFC 7230 and RFC 3986
	org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:490)
	org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:269)
	org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
	org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:888)
	org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1684)
	org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	java.lang.Thread.run(Thread.java:750)
</pre><p><b>Note</b> The full stack trace of the root cause is available in the server logs.</p><hr class="line" /><h3>Apache Tomcat/9.0.43 (Debian)</h3></body></html>

The XMLValidatingParser cannot properly handle this response.
When sending the request using a browser (or even a tool like Postman), the quotation marks seem to be url encoded behind the scenes and the correct ExceptionReport is displayed.
I will have to investigate a bit more to find out whether this has to be fixed in the test suite.

The service you mentioned seems to be offline, btw. But I did some tests with the following service https://demo.luciad.com:443/LuciadFusionPlatform/ogc/wcs/compliance_test and the WCS 1.1 test suite, where a similar issue seems to be present.

@dstenger
Copy link
Contributor

Decision during CITE meeting 2024-07-18:

  • Test suite shall encode double quotation marks in requests.

@bpross-52n bpross-52n mentioned this issue Jul 25, 2024
Merged
@dstenger dstenger assigned dstenger and unassigned bpross-52n Jul 25, 2024
@dstenger dstenger added this to CITE Aug 1, 2024
@dstenger dstenger moved this to To verify in CITE Aug 1, 2024
dstenger added a commit that referenced this issue Aug 30, 2024
@dstenger
Merge pull request #138 from opengeospatial/issue#137
291db57 
Closes #137
@github-project-automation github-project-automation bot moved this from To verify to Done in CITE Aug 30, 2024
@dstenger dstenger added the bug label Aug 30, 2024
@dstenger dstenger mentioned this issue Aug 30, 2024
Open
@dstenger
Copy link
Contributor

New issue was created for WCS 1.1 test suite: opengeospatial/ets-wcs11#79

@dstenger dstenger added this to the 1.21 milestone Aug 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dstenger dstenger

Labels
bug
Projects
CITE
Status: Done
Milestone
1.21
Development

Successfully merging a pull request may close this issue.

Closes #137 opengeospatial/ets-wcs20
3 participants
@dstenger @bpross-52n @robinhoutmeyers