Should 'C%3A' or 'C%7C' be interpreted as 'C:' and 'C|'?

[jasnell]

Given the examples new URL('file:///C%3A/a/b/c') and new URL('file:///C%7C/a/b/c'), the parsed pathnames do not unescape the %3A (:) and %7C (|). Technically speaking, those should be considered valid Windows drive letters. Currently neither the Node.js, Firefox, or Chrome impls decode the %-encoded : and | characters.

[domenic]

Technically speaking, those should be considered valid Windows drive letters.

What does "should" mean here? Who says they should be considered valid Windows drive letters?

[jasnell]

Should in the same sense that /%2e/ is interpreted as a valid single dot segment and /%2e%2e/ is interpreted as a valid double dot segment, etc. It's a bit inconsistent to pct-decode in some cases while not in others.

[jasnell]

For instance,

> var m = new url.URL('file:///c%3a/%2e/a/%2e%2e/b')
undefined
> m
URL {
  href: file:///c%3a/b
  protocol: file:
  pathname: /c%3a/b
}

[domenic]

I believe the consensus of recent work was that %2e is special (and is only decoded in special cases, itself). See #87

[jasnell]

Indeed, but windows drive letters are also already special cased in the URL parsing algorithm and anyone processing the URL appropriately (by decoding any pct-encoded characters prior to using it) can end up with rather unexpected results if they are not being careful.

> var m = new url.URL('file://c%3a/%2e/a/%2e%2e/b')
undefined
> m
URL {
  href: file://c:/b
  protocol: file:
  hostname: c:
  pathname: /b
}

> var m = new url.URL('file:///c%3a/%2e/a/%2e%2e/b')
undefined
> m
URL {
  href: file://c:/b
  protocol: file:
  pathname: /c%3a/b
}

I believe it at least warrants some additional consideration.

[annevk]

Does Edge do this or something? If nobody does this, I'm not sure why we would. The drive letter system is already complicated enough.

[jasnell]

I was kind of hoping it didn't but I just checked and the results are fairly surprising...

Edge does nothing with %7C. It ignores it the same as Firefox, Chrome and Node.js

It does, however, decode %3A, with different results based on how it appears:

file:///c%3a/a/b/c

{
   href: "file:///c:/a/b/c",
   pathname: "/c:/a/b/c",
   protocol: "file:",
}

Note the decoded : in the pathname

However,

file://c%3a/a/b/c

Results in an error being thrown with the message "A security problem occurred"

The security error implies that the %3a is being decoded by Edge because the equivalent file://c%7c/a/b/c has zero problems.

[annevk]

I'm not sure that's worth emulating then. The only thing that would sway this for me personally is data showing such URLs are out there and content relies on them working.

[jasnell]

Understood! And to be certain, I'm not trying to argue that this should be handled. It's just an edge case that happened to come up while I was putting the parser through some of it's paces and I realized it wasn't covered. At the very least, knowing that it's explicitly out of scope means I don't have to write code to account for it ;-). Will close this for now and we can revisit it again later if necessary

[annevk]

Let me leave this open to make sure we add tests to web-platform-tests.

[annevk]

Test created, would appreciate review.