Description
I'm not sure how much URI.js tries to be in sync with the Web API URL, but even after ac43ca8 , there's still a difference between URI.js and URL when it comes to slashes, e.g. when dealing with relative URLs that have a protocol (verified in Chrome 93.0.4577.82, Safari 14.1.2 and Firefox 92.0.1):
> URI.version
< '1.19.7'
> new URI("https:index.html", "https://github.com").toString()
< 'https://index.html/'
> new URL("https:index.html", "https://github.com").toString()
< 'https://github.com/index.html'This is caused by the newly introduced regex. It checks for zero or more slashes. Browsers seem to check for at least two slashes, if there's a base.
To complicate things, browsers behave differently when no base is given or when the protocols don't match. Then they rather seem to correct typical typos or lazy users (that's at least my assumption):
> new URI("https:index.html").toString()
< 'https://index.html/'
> new URL("https:index.html").toString()
< 'https://index.html/'I didn't check whether this is spec'ed somewhere for the URL Web API, but rather wanted to point out this suspicious aspect of the regex.
The good thing: as URI.js 1.19.6 threw an error for the above calls with a base, this issue shouldn't cause a regression for consumers.