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

> If I'm reading this right it sounds like @annevk justification for not wanting to make changes to the API is because it's not a problem in browsers, and who cares about Node.

That's really not fair. The WG has been proactive about reaching out to Node.js on changes that impact URL.

A lot of this issue is based on a few fundamental misunderstandings about how the URL parser works. Let's g back to the original example in this issue:

```
new URL('./page.html', 'https://site.com/help/');  // OK
new URL('./page.html', '/help/'); // Error
```

The original post has the statement: "That requirement is painful because determining which absolute URL to use as a base can be difficult or impossible in many circumstances."

To be certain, it's not that the URL parser really needs to know an absolute URL to function, it needs to know what the protocol component of the URL is in order to make sense of the input; and needs to know what it is normalizing the relative path against.

For instance, specifically in that second example, should the input be treated as an opaque path or hierarchical? Should it be interpreted as "special" or not? There are quite a few places in the parsing algorithm where that distinction is important.

That said, I do think there's a reasonable potential path forward. If we could add the option of passing an object as the second argument to `new URL` then we could do something like `new URL('/foo', { protocol: 'http:' })` -- that is, pass in a *URL Record* as the second argument -- to provide the missing detail -- then I think we could address the core need here with minimal changes to the API.

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

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