You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
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):
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):
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):
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.
The text was updated successfully, but these errors were encountered: