relativeTo issue with empty folder

[fxOne]

I have an issue with generating an relative url where the current browsers url contains an empty folder:

history.pushState(null,'test','/a//c/d') // browser path: example.com/a//c/d
var uri = new URI('http://example.com/a').relativeTo(new URI()) // uri = "../../a"
history.pushState(null,'test2',uri.toString()) // browser path: example.com/a/a

The problem is that normalizePath convert '/a//c/d' to '/a/c/d'. Maybe you can find a solution for me?

[rodneyrehm]

All clients I know translate /{2,} to /, meaning /// gets normalized to /. I've always considered a//b the result of a bad join operation (e.g. "a/" + "/" + "b").

I have not found anything in RFC 3986 that mandates this behavior. In fact I have not found any mention of // in the path segment aside from section 3.3 saying:

If a URI does not contain an authority component, then the path cannot begin with two slash characters ("//").

Here's a good summary on the behavior of // in paths in Linux. It is also the way Python normalizes paths. Exactly the behavior URI.js show.

---

Maybe we should talk about the semantics of your a//b/c thing. What's the reason you're using // in there?

[fxOne]

Well you are right, currently i have the // because of a bug in an other place of our routing and we are trying to remove it, which should also solve the problem. Also you are right that // should not be used and looks wired.

So far I tested the code i posted in Chrome and was surprised to get example.com/a/a as a result instead of the expected example.com/a.

So far i noticed the also google used the // as you can see here: http://static.googleusercontent.com/media/www.google.com/en//webmasters/docs/search-engine-optimization-starter-guide.pdf If you remove in the link the // it wont work.

[rodneyrehm]

Does that mean we can close this issue now?

[fxOne]

Feel free to close this ticket, as I found the solution for me to use absolute URIs,which works for our project. But I would say that relativeTo does not work correct at least in Chrome as you can see in my example.

[rodneyrehm]

using the url resolution of URL in Chrome I can see the following happening, suggesting that URI.js may indeed be a bit overzealous in normalizing paths:

var url = new URL('../../d', 'https://google.com/a//b/c');
ulr.pathname === '/a/d'

where URI.js behaves as follows:

var url = new URI('../../d', 'https://google.com/a/b/c');
url.pathname() === '/d'

---

Simply removing the /-deduplication in .normalizePath() breaks existing tests. I'm not sure how to go about this properly and will leave it open for discussion