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.

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

Dot-related inconsistencies in url.absolute() #1129

Closed
nnposter opened this issue Feb 4, 2018 · 1 comment
Closed

Dot-related inconsistencies in url.absolute() #1129

nnposter opened this issue Feb 4, 2018 · 1 comment

Comments

@nnposter
Copy link

nnposter commented Feb 4, 2018

NSE function url.absolute() is not always returning results according to RFC 3986 when . or .. are involved.

  • One prominent category of cases is when .. exceeds the path depth
  • Terminal . and .. are treated differently when they are followed by / or not
  • Normalization does not happen if the second argument is already absolute
  • A few bugs

Here are the test suite results:

arg1      arg2      output    RFC
"a"       "."       "."       ""
"a"       "./"      ""        ""
".."      "b"       "b"       "b"
"../"     "b"       "../b"    "b"
"/"       ".."      ""        "/"
"/"       "../"     ""        "/"
"/../"    ".."      ".."      "/"
"/../"    "../"     "../"     "/"
"a/.."    "b"       "a/b"     "b"
"a/../"   "b"       "b"       "b"
"/a/.."   ""        "/a/"     "/"
""        "/a/.."   "/a/.."   "/"

I do have code that faithfully follows the RFC but the impact of this change is hard to gauge. In particular it could cause problems in contexts where the function is used to join two relative paths because the function would remove excessive .., possibly prematurely.

Please comment whether it is worth implementing this fix or whether we should add url.absolute2() for the correct behavior.

@cldrn
Copy link
Member

cldrn commented Feb 21, 2018

Hey,

I think we should stick to the RFC. There shouldn't be a lot of scripts affected by this and if they are, we can easily fix them and at the end we will be RFC compliant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants