Re: [whatwg/url] Base URL Windows drive sometimes favoured over input string drive (#574)

Yes, this is unpleasant. I remember two testcases in WPT that are related. (see below). 

These are 'congruence bugs', in the mathematical sense. They are not exactly reparsing bugs according to the spec, but they are very similar. 

You'd want to prevent components that 'look like drive letters' from 'becoming drive letters' when normalizing.  
This is similar to what was done in #505 for hosts (there, path components would 'turn into a host'). You can resolve this by percent encoding (part of) the first component upon serialization, if it would otherwise turn into a drive letter. Or otherwise, prefix `./` as in #505. 

For implementations and the spec, It's useful to store the drive as a property on the (internal) URL record to avoid branching on the content of the first path component. 

Related tests:
```
{
  "input": "file:///./Y:",
  "base": "about:blank",
  "href": "file:///Y:",
  "protocol": "file:",
  "username": "",
  "password": "",
  "host": "",
  "hostname": "",
  "port": "",
  "pathname": "/Y:",
  "search": "",
  "hash": ""
}
```

```
{
  "input": "file:///./y:",
  "base": "about:blank",
  "href": "file:///y:",
  "protocol": "file:",
  "username": "",
  "password": "",
  "host": "",
  "hostname": "",
  "port": "",
  "pathname": "/y:",
  "search": "",
  "hash": ""
}
```


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