URL: Add a way to set a default schema

[Geod24]

One very common need is to parse a user-provided struct into an URL.
It is currently quite tedious to do, as one of the requirement is to have a schema.
This make it slightly easier for the common and simple cases.

[s-ludwig]

This approach has a similar issue as #2308, where just a host name is accepted as a valid URL (which it isn't). In conjunction with the explicit default schema, it would make sense to accept "//host" as a protocol-relative URL, though, as that would allow to keep the current definition of URL as a non-relative URL.

Maybe it makes sense to add a parseFuzzyURL(str, default_schema, default_host, default_port) that allows interpreting URLs similar to a web browser. It could also allow relative paths with a base_path argument.

[Geod24]

@s-ludwig : I was looking at this again and got a bit puzzled.

You mentioned:

where just a host name is accepted as a valid URL (which it isn't).

What definition of URL are we using ? I assume this one ?

[s-ludwig]

In this case, I'd refer to RFC1738. For schemas that do not fall in that category, something like this would be valid, though: foo:bar.

[s-ludwig]

Yeah, but the one you mentioned would be what I'd associate with parseFuzzyURL (or whatever it would be called).

[Geod24]

But RFC1738 is obsolete (although there's probably a lot of overlap)... The RFC tracker doesn't make this very obvious, but AFAIK the "proper" RFC for would be RFC 3986. That's also the one mentioned in the above document.

[Geod24]

Note the goals section.

[s-ludwig]

But RFC1738 is obsolete (although there's probably a lot of overlap)... The RFC tracker doesn't make this very obvious, but AFAIK the "proper" RFC for would be RFC 3986. That's also the one mentioned in the above document.

I think this is slightly besides the point. RFC 3986 is a revision of the original generic URI definition (RFC 2396), which in turn generalizes RFC 1738. So it touches parts of RFC 1738, but the more specific parts that define the "Common Internet Scheme Syntax" are still relevant for the schemas that are modeled that way (e.g. http(s)), although there are changes to the gopher and telnet schemas mentioned (RFC 4266 and RFC 4248).

So in essence, the generic URL parser should only assume generic URL syntax, as defined by RFC 3986, but for known URL schemas, it should perform proper schema specific validation and extended parsing (host, port, user/password). So the basic parser to do what https://url.spec.whatwg.org/#urls describes as "valid", while parseFuzzyURL would be the whole thing ("output" in that table).