relative URLs

[stevenvachon]

Now that a native URL parser is finally being standardized and implemented, why would we leave out relative URLs? They are URLs:

//domain.com/root/path/to/someting.html?var=value#hash
/root/path/to/someting.html?var=value#hash
path/to/someting.html?var=value#hash

Due to the decisions made, another parser will be necessary -- that is silly.

[jasnell]

The key challenge with relative URLs is that the rules for handling them can vary significant based on what they are relative to. For instance d:/foo/bar means something very different when it is relative to http://example.org/ than file://d:/foo/baz. Given the ambiguity, requiring at least some kind of base is preferred (in my opinion at least)

[stevenvachon]

Interesting. Something for me to think about.

[stevenvachon]

I think it's fine, actually, that we don't parse relative URLs. The only downside is backwards-compatibility with Node's url.parse(). I'm writing specurl—which builds on whatwg-url—in an attempt to replace Node's url, even if only in user land. Let me know if you have any thoughts/ideas.

[jasnell]

OK. One thing to keep in mind is that we are currently looking at adding
WHATWG URL parsing to core currently as an experimental new feature. There
is an open pr but I don't have the link immediately handy.

On Saturday, August 6, 2016, Steven Vachon notifications@github.com wrote:

I think it's fine, actually, that we don't parse relative URLs. The only
downside is backwards-compatibility with Node's url.parse(). I'm writing
specurl https://github.com/stevenvachon/specurl—which builds on
whatwg-url https://npmjs.com/whatwg-url—in an attempt to replace Node's
url, even if only in user land. Let me know if you have any
thoughts/ideas.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#136 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAa2eeuR7wXXfyyIyyeziDJF8u88HjjUks5qdL5RgaJpZM4JeG7c
.

[stevenvachon]

Awesome! I didn't know that.

[annevk]

Yeah, the main reason relative URLs cannot be turned into an object, is because it makes little sense to do so without a base URL. I still think that design makes sense. Given your comment above I'm going to close this. Hope that's okay.

[stevenvachon]

@jasnell I cannot find that PR.
@annevk sure, makes sense.

[nex3]

I'd like to push for some notion of a "relative URL" as a first-class object, at least in the spec terminology if not in the API. I'm working on defining a file format that includes a construct for referring to documents from other documents, naturally using URLs.

The thing is, I want to define some behavior around this construct that's independent of the base URL, but still uses URL notions like the path. The spec as it stands provides me no way of saying "this is a relative URL, and the path must contain at least one element that's an identifier" or whatever.

To put this more generally: tools often process documents at build time, in a context-free manner, where the base URL is not known. They may even process documents that may be used in multiple contexts with different base URLs. I believe this is why humans tend to gravitate towards referring to "relative URLs" as objects in and of themselves, and there's value in the spec matching this intuition in some way. Right now, it provides no way to even talk about a URL unless you have all the context of how the document that contains it will be used.

One possibility would be for the spec to include a definition of "relative URL" that explicitly includes an initial "ambiguous segment" and forbids certain operations if that segment is non-empty.

[annevk]

@nex3 it might be good to open a new issue as discussions in closed issues tend to get lost or forgotten about. Having said that, does https://url.spec.whatwg.org/#relative-url-with-fragment-string not help here somewhat? It seems the URL Standard does offer you to place restrictions on what can be produced. And since the parser only takes a string, it would only makes sense to have objects here if we also did something with them, I think.