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

mertcanaltin 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 [web-platform-tests/wpt#53459](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?

Good catch on the 4 slashes issue! You're right - if remaining starts with \ (which becomes / after replacement), then prepending /// gives us ////. We should probably check if remaining starts with / after the backslash replacement and adjust accordingly.

For the pointer question, I think it should point to the beginning of the path part (after the /// prefix) to maintain correct parsing position.

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

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

Received on Thursday, 17 July 2025 17:27:56 UTC