Reparsing problem with non-special URL and double-dot path component

[zealousidealroll]

When the URL a:/a/..//a is parsed, the resulting URL object has no hostname, and has the path //a

c = 'a'
state = scheme start state
buffer = ""
pointer = 0

---

c = ':'
state = scheme state
buffer = "a"
pointer = 1

---

scheme = "a"
buffer = ""
state = path or authority state
pointer = 2

---

pointer = 3
c = 'a'
state = path state
pointer = 2

---

state = path state
pointer = 3
c = 'a'
buffer = "a"

---

state = path state
pointer = 4
c = '/'
path = [ "a" ]
buffer = ""

---

state = path state
pointer = 5
c = '.'
path = [ "a" ]
buffer = "."

---

state = path state
pointer = 6
c = '.'
path = [ "a" ]
buffer = ".."

---

state = path state
pointer = 7
c = '/'
path = [""]
buffer = ""

---

state = path state
pointer = 8
c = '/'
path = ["", ""]
buffer = ""

---

state = path state
pointer = 9
c = 'a'
path = ["", ""]
buffer = "a"

---

state = path state
pointer = 10
c = EOF
path = ["", "", "a"]
buffer = ""

When the resulting URL is serialized, it gets serialized as a://a, which, if it gets reparsed, gets an empty path and a hostname a.

Found while trying to find a spec-compliant resolution for servo/rust-url#459

This isn't a problem for special URLs, which always have a host.

[GPHemsley]

What should the correct behavior be?

I'm thinking this should serialize to a:///a? (I haven't tested whether that reparses correctly.)

[zealousidealroll]

According to https://quuz.org/url/liveview.html#a:///a , a:///a and a:/a parse to the same thing (a URL with protocol a: and path /a) so I would think that it ought to get serialized to a:////a where it'll get the //a path (consistent with its original parse).

Though I'm not sure if the "empty host" that a:////a gets and the "null host" that a:/a/..//a are actually the same thing.

[zealousidealroll]

Looking at other implementations:

• Firefox leaves the path empty (which seems very wrong)
• Edge thinks a: is a drive letter
  • If I change the scheme to am:, it changes the path to /.//a, basically adding a disambiguating . to the front.

[annevk]

For https://jsdom.github.io/whatwg-url/#url=YTovYS8uLi8vYQ==&base=YWJvdXQ6Ymxhbms= Safari behaves per spec (and has a reparsing issue), Firefox seems to fail to parse the URL, and Chrome gives /a/..//a as path, which is weird, but basically means they don't have relative URL handling for this scheme.

I guess when we decide to use relative URL handling we should really set the host to a non-null value.

[domenic]

Firefox seems to fail to parse the URL

Interesting aside: I don't think it fails to parse. As far as I can tell it's parsing it as having protocol a: but some kind of hidden "scheme data" of /a/..//a. Parsing failure always results in a protocol of just :.

Weirder and weirder, new URL("a:/a/..//ab") in Firefox has a pathname of /a/..//a. It's only <a> elements that have the hidden "scheme data".

[annevk]

If I'm reading https://tools.ietf.org/html/rfc3986#section-5.2.2 correctly that has this problem as well. It forbids a scheme followed by an absolute path from taking the form scheme://path as that's ambiguous as it repeatedly points out (elsewhere in the document), but then scheme:/doesnotmatter/..//path is fine and would also yield this state.

https://tools.ietf.org/html/rfc3986#section-5.3 does not account for it either.

I suggested changing the host above, but upon re-reading this issue I rather like what Edge did here as it is isolated to serialization and preserves intent better.

[annevk]

@valenting @achristensen07 this is worth fixing, right? It's only for non-special schemes, but it seems those should be free of idempotency issues too.

[annevk]

@valenting @achristensen07 ping.

[valenting]

@valenting @achristensen07 this is worth fixing, right? It's only for non-special schemes, but it seems those should be free of idempotency issues too.

I think it makes sense that non-special URLs should also be idempotent. 👍