Uri.resolve and Uri.resolveUri return incorrect results for ".." when the base URI is relative

[nex3]

Currently, Uri.parse(".").resolve("../foo").path returns "foo". This is incorrect; . refers to the current path, so anything resolved relative to it should return itself. This means that the example above should return "../foo".

[nex3]

Upon further inspection, this goes beyond just .. Any single-component relative URI will ignore any number of leading ../ components in resolve() and resolveUri()

[lrhn]

The problem is that the resolution algorithm in RFC 3986 is only specified to work for an "absolute" base URI, and for that case, you can't go "above the root", so initial ".." are discarded. (It's not really absolute in the sense that the path needs to start with "/", but nevertheless it acts that way).

We conflate URI (always has a scheme and is considered "complete") and URI-reference (may not have a scheme and is considered to be relative to a base URI) into one class, so we can't easily make the distinction that you can only resolve a URI reference against a base URI.

So, resolving against a relative URI is really unspecified, but I agree that it would be great if it did something useful instead of this.

How about: If the receiver Uri of resolveUri has no scheme (so we are in unspecified territory) and a non-empty relative path (implies that there is also no authority, and it's really just a path), then we allow path merging to result in leading ".." segments. That means that Uri.parse("foo/bar").resolve("../../../baz") would give the path "../baz". If you do Uri.parse("file:foo/bar").resolve("../../../baz") then you still get "file:/baz" as the specification requires.

[floitschG]

Let's do that.

[lrhn]

Another problem is that we don't path-normalize the URI from the beginning, and I think we should do that too.
The effect is that if you start with scheme://auth/foo/.. and resolve bar against it, you get scheme://auth/foo/bar. The merge-path algorithm in RFC 3986 makes you drop the last segment of the original path before merging, and it doesn't check if that happens to be "..".

[floitschG]

Agreed. This is something that could drip users. So let's fix it.

[sethladd]

@floitschG should we do this for 1.12 ?

[lrhn]

Thanks for asking :)
This was fixed in 848f6c9 which is part of 1.12.

[sethladd]

Cool, thanks for the update!