[
https://issues.apache.org/jira/browse/CXF-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640505#comment-13640505
]
Stian Soiland-Reyes commented on CXF-4919:
------------------------------------------
https://java.net/jira/browse/JAX_RS_SPEC-398 was for some reason was deleted,
on request I posted it again.
content below (for records):
{quote}
Note: This issue was previously posted as JAX_RS_SPEC-398 which somehow
disappeared. I was requested to post it again - see
In the documentation
https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/core/UriInfo.html#relativize(java.net.URI)
The example is misleading (and wrong):
{quote}
Examples (for base URI http://host:port/app/root/):
Request URI: http://host:port/app/root/a/b/c
Supplied URI: a/b/c/d/e
Returned URI: d/e
{quote}
But this would be an invalid example, as trying to resolve the returned URI
shows:
{code}
java.net.URI.create("http://host:port/app/root/a/b/c";).resolve("d/e")
http://host:port/app/root/a/b/d/e
{code}
This is simply because a / is missing at the end of the request URI - it would
be very strange for someone requesting /app/root/a/b/c to interpret that as
/app/root/a/b/c/. Replace "c" with "index.html" to understand in a web sense,
it's reference to d.png should not resolve to index.html/d.png.
The above misleading example has already led to confusions in the
implementation in CXF - see https://issues.apache.org/jira/browse/CXF-4919 --
in my suggested patch I have deliberately changed the original test to not
check for the specified behaviour in JAX-RS javadocs as I believe it is wrong.
The documentation could probably be rewritten to use a .html resource to be
more understandable out of the box. I would also change the confusing (and
HTTP-wise invalid) ":port" - as this is an example no need to be generic ;)
For instance:
{quote}
Base URI: http://example.com:8080/app/root/
Request URI: http://example.com:8080/app/root/a/b/c/resource.html
Supplied URI: a/b/c/d/e.txt
Returned URI: d/e.txt
{quote}
Or a very simpler fix would be to just add the missing / in the request URI:
{quote}
Examples (for base URI http://host:port/app/root/):
Request URI: http://host:port/app/root/a/b/c/
Supplied URI: a/b/c/d/e
Returned URI: d/e
{quote}
.. although that would still lead open to the same confusions for request URIs
not ending in /.
{quote}
> UriInfo.relativize (and HttpUtils.relativize) broken
> ----------------------------------------------------
>
> Key: CXF-4919
> URL: https://issues.apache.org/jira/browse/CXF-4919
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.7.3
> Reporter: Stian Soiland-Reyes
>
> None of these tests pass:
> {code}
>
> @Test
> public void testRelativize() throws Exception {
> URI ab = URI.create("http://example.com/a/b/";);
> URI abcd = URI.create("http://example.com/a/b/c/d";);
> assertEquals(URI.create(""), HttpUtils.relativize(ab, ab));
> assertEquals(URI.create("c/d"), HttpUtils.relativize(ab, abcd));
> assertEquals(URI.create("../"), HttpUtils.relativize(abcd, ab));
> assertEquals(URI.create(""), HttpUtils.relativize(abcd, abcd));
> URI abcd2 = URI.create("http://example.com/a/b/c/d2";);
> assertEquals(URI.create("d2"), HttpUtils.relativize(abcd, abcd2));
> URI ab2cd = URI.create("http://example.com/a/b2/c/d";);
> assertEquals(URI.create("../../b2/c/d"), HttpUtils.relativize(abcd,
> ab2cd));
> }
> {code}
> This affects LinkBuilder.buildRelativize() and UriInfo.relativize()
> The algorithm is basically working by counting elements common by position -
> this would also fail hard when there are common elements later - but with a
> different ancestor.
> Javadoc for UriInfo.relativize() also has some testcases that should work.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
