Re: [whatwg/url] It's not immediately clear that "URL syntax" and "URL parser" conflict (#118)

> It doesn't even come close to describing Safari, or any utility that handles URLs outside of browsers. Not a single programming language changed its stdlib's URL parser according to the standard.

Safari supports more than 2 slashes, but not from the location bar. cURL does too. `rust-url` follows this Standard in its entirety.

> Today, you can not use the URL format given here to give a URL to the Google Chrome browser on Android, instead, to programmatically invoke it, it will only accept RFC-conform URLs.

And what happens if you do `window.location = "http://///////google.com/";`?

> Defining "URL" for the entire Internet in a new way requires a definition that also applies to URL parsing libraries in programming languages, that applies to cURL, wget, the Android Intent system, CLI invocations of browsers, and more.

Well cURL supports more than 2 slashes, and has other RFC deviations for the very reason that RFC don't actually reflect the real world.

> So either rename this, to make it clear you don't even care at all about the ecosystem outside of browsers — as suggested, Web Resource Locator would be one alternative to Uniform Resource Locator — but redefining the Uniform Resource Locator for the entirety of modern information technology requires discussion with more stakeholders (see the libcurl author higher up in this thread complaining), and it requires it to actually stay uniform. The very definition of a uniform resource locator is that there is only a single possible serialization, and only one way to parse it, and that this is standardized across all software.

The Web has a URL interface exposed to JavaScript that requires following this Standard. That ship sailed a long ago and this will never be renamed (that would break webcompat).

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

Received on Thursday, 19 October 2017 09:15:01 UTC