Re: [whatwg/url] Support relative URLs (#531)

I agree that APIs to manipulate relative references are important.

I'm not a big fan of combining that with the existing API for absolute URLs. A lot of legacy libraries went that way, and it ends up having all kinds of problems - from poor performance to non-obvious semantics. For example, in a strongly-typed language, you can have a function which accepts a parameter of type `URL`; but if that single URL type supports both absolute URLs and relative references, pretty much anything (including `"foo"`) counts as a URL, which is generally not what developers expect (at least for the sorts of applications in my domain, perhaps expectations on the web are different). I think the use-cases are distinct enough that they warrant a separate API.

Also, if we're just talking about APIs for e.g. server use-cases (routing and such), I'm not sure it's obvious that we need all of the quirky web-compatibility behaviour that the relative-string parser does, treating back-slashes like forward-slashes and such. For a lot of these use-cases, you have better control over the inputs and can do perfectly fine with only a sanitised subset of that behaviour.

One thing that's worth noting though: currently you don't _only_ need the scheme to know how to interpret a URL. For example, in this case, a correct interpretation also requires you to know the base URL's path:

```
// "C|" is not interpreted as a drive letter if the base path has a drive letter
(input: "/a/../C|/Windows", base: "file:///D:/Music")  --> "file:///D:/C|/Windows"

// Same input string, but base doesn't have a drive letter.
// Now "C|" is considered a drive letter.
(input: "/a/../C|/Windows", base: "file:///Dx/Music")  --> "file:///C:/Windows"
```

(This is #574, and hopefully fixable)

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

Message ID: <whatwg/url/issues/531/1029786172@github.com>

Received on Friday, 4 February 2022 09:12:34 UTC