Just yesterday I had a post about the dot in the beginning of relative URLs. Today I have a small addition to that: Two dot path segments in an URL/URI.
It’s some more detailed thing related to the history and the specs of relative links. As with the dots, on first sight you’re pretty sure you can not do it wrong but then, well, it actually can happen 😉 .
A problem with two-dotted-segments in a path is that those can be differently interpreted based on the RFC that was taken to implement such functions. That means: Older libraries / tools might do work in some other way then newer might do. The difference is between RFC 1808 and RFC 3986. The latter supersedes the previous one. But: there is a simple way to get both compatible, so it actually is no problem to get both relative path resolving algorithms working well together.
First for the differences shown in a simple comparison scenario:
Base: "http://a/b/c/d;p?q" RFC 1808: "../../../g" = "http://a/../g" "../../../../g" = "http://a/../../g" RFC 3986: "../../../g" = "http://a/g" "../../../../g" = "http://a/g"
As you can see RFC 1808 does preserve unused double dot segments whereas RFC 3986 just removes them. So the only thing you need to take care about is, that double dot segments always do count a maximum of steps up the directory tree and do not contain additional double dot segments which wouldn’t make sense path-wise spoken.
The smell here would be to identify those relative links which would render differently compared between RFC 1808 and 3986.