- From: Karl <notifications@github.com>
- Date: Fri, 04 Feb 2022 01:12:21 -0800
- To: whatwg/url <url@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/url/issues/531/1029786172@github.com>
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