Re: [whatwg/url] feat: handle Windows file paths with backslashes in URL parsing (PR #874)

shannonbooth left a comment (whatwg/url#874)

I have had an initial attempt at implementing this. I'm having quite a bit of trouble trying to match up this merge request with the tests at https://github.com/web-platform-tests/wpt/pull/53459. I will need to come back to it to understand the intent a bit better since there seem to be a few different causes of mismatches (one of them, for example, is percent encoding of certain characters, but I haven't narrowed that down yet).

I did draw some initial feedback though, which I will drop here:

- On the WPT side, the tests need to be updated to account for the unfortunate reality of `origin` being implementation defined for file scheme URLs.
- Currently, setting the `"file"` scheme is redundant since if we go into `file` state that will set the scheme for us. But this might be redundant with Anne's comment.
- It is unclear to me what should happen to `pointer` if we manipulate `remaining`. Should it be at the beginning of remaining prefixed by `///`? This impacts, for example, whether `D:\\foo\\bar.exe` should still have `D:` in the parsed URL.
- Is it intended that 4 slashes are prepended to `remaining`? `remaining` includes a `\` which is transformed to `/`, so `remaining` then ends up having four leading `/`'s?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/pull/874#issuecomment-3076523175
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/pull/874/c3076523175@github.com>