Fixed isURL regex to take account file urls. #20435
Conversation
Added unit test to validate isURL when parsing file URLs.
SergioEstevao
added
[Type] Bug
|
Size Change: +846 B (0%) Total Size: 866 kB
ℹ️ View Unchanged
|
packages/url/src/is-url.native.js
Outdated
| @@ -1,4 +1,4 @@ | |||
| const URL_REGEXP = /((([A-Za-z]{3,9}:(?:\/\/)?)(?:[\-;:&=\+\$,\w]+@)?[A-Za-z0-9\.\-]+|(?:www\.|[\-;:&=\+\$,\w]+@)[A-Za-z0-9\.\-]+)(?::\d{2,5})?((?:\/[\+~%\/\.\w\-_]*)?\??(?:[\-\+=&;%@\.\w_]*)#?(?:[\.\!\/\\\w]*))?)/i; | |||
| const URL_REGEXP = /((([A-Za-z]{3,9}:(?:\/\/?\/)?)(?:[\-;:&=\+\$,\w]+@)?[A-Za-z0-9\.\-]+|(?:www\.|[\-;:&=\+\$,\w]+@)[A-Za-z0-9\.\-]+)(?::\d{2,5})?((?:\/[\+~%\/\.\w\-_]*)?\??(?:[\-\+=&;%@\.\w_]*)#?(?:[\.\!\/\\\w]*))?)/i; | |||
There was a problem hiding this comment.
In wondering whether the proposed revisions are in-fact technically valid, it eventually clicked with me that the extra slash is meant to represent the path name (e.g. file: is the protocol, then //, then /foo constituting a root-relative path). So in looking at how this is implemented, I wonder if this is something where we should be accounting for this as part of the pattern matching for the path, and not strictly as an optional extra slash following the //. The pattern is a bit unwieldy to untangle, so it's not immediately clear to me where this change would need to occur.
It's also a bit awkward that it's the second of three slashes which is made to be optional. Though I expect it works just the same.
| const URL_REGEXP = /((([A-Za-z]{3,9}:(?:\/\/?\/)?)(?:[\-;:&=\+\$,\w]+@)?[A-Za-z0-9\.\-]+|(?:www\.|[\-;:&=\+\$,\w]+@)[A-Za-z0-9\.\-]+)(?::\d{2,5})?((?:\/[\+~%\/\.\w\-_]*)?\??(?:[\-\+=&;%@\.\w_]*)#?(?:[\.\!\/\\\w]*))?)/i; | |
| const URL_REGEXP = /((([A-Za-z]{3,9}:(?:\/\/\/?)?)(?:[\-;:&=\+\$,\w]+@)?[A-Za-z0-9\.\-]+|(?:www\.|[\-;:&=\+\$,\w]+@)[A-Za-z0-9\.\-]+)(?::\d{2,5})?((?:\/[\+~%\/\.\w\-_]*)?\??(?:[\-\+=&;%@\.\w_]*)#?(?:[\.\!\/\\\w]*))?)/i; |
Noting that the // is technically considered optional based on this pattern, I wonder if the following should be considered valid, as omitting the optional //, but still root-relative:
file:/foo
In the browser, this is considered valid, and evaluates the same as file:///foo:
new URL( 'file:/ok' ).pathname
// "/ok"Under this proposed implementation, I expect that would not be supported.
There was a problem hiding this comment.
Possibly related contrary information for the above-given example:
- If url’s scheme is "file", then:
- If remaining does not start with "//", validation error.
There was a problem hiding this comment.
Noting that the // is technically considered optional based on this pattern, I wonder if the following should be considered valid, as omitting the optional //, but still root-relative:
At least based on relevant specification, it is optional:
If c is U+002F (/), then set state to authority state.
Otherwise, set state to path state, and decrease pointer by one.
https://url.spec.whatwg.org/#path-or-authority-state
The diagram here is a little easier to interpret, though technically not the specification we adhere to:
https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Generic_syntax
If the extra slash we're accounting for is relevant for the path, then the pattern should match it separately from the optional authority //.
Edit: Oof, this gets really confusing, when you consider that http: is a "special scheme", and thus it would be subject to special authority slashes state, and omitting // would be deemed invalid.
There was a problem hiding this comment.
@aduth I did some changes to support the case you mention, have a look to see if you agree.
There was a problem hiding this comment.
@SergioEstevao I'm not seeing any changes. Did you push them? GitHub was having an outage incident this morning, so possible that it was missed?
There was a problem hiding this comment.
My previous comments were admittedly a bit of a winding brain dump. In short, it's not clear to me if we should consider file:/foo as "valid". It's tolerated by the URL constructor and thus would return true in the browser, so there's an argument in favor of consistency. But as I note in #20435 (comment), the specification is fairly clear that a double-slash should be required to be considered valid.
There was a problem hiding this comment.
Did you come up with this regular expression or find it somewhere? I was trying to decipher it yesterday, and it felt to me like there's some redundancies around www., and user/pass matching. It made it hard for me to figure out how best to change it, but ultimately it felt like the problem is in-part because there's an expectation that one or more characters exist before the pathname can start (which is what the changes here are proposing is an incorrect assumption).
Notably, the occurrences of: [A-Za-z0-9\.\-]+
There was a problem hiding this comment.
I've updated the expression that @etoledom used. I think he used the one for Javascript defined here: https://urlregex.com/
I'm tempted to replace it by the one defined for HTML 5:
^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
There was a problem hiding this comment.
I'm tempted to replace it by the one defined for HTML 5:
^(([^:/?#]+):)?(//([^/?#]))?([^?#])(?([^#]))?(#(.))?
I've tried this and it's no good, I think the current version of the commit is the best one that matches all the situations.
|
The example of
Action steps:
|
|
I'm interested to see your commit at 7ddfe49, because I was wondering about this yesterday as well, given that we have test cases which include a substring of a valid URL, but that we assert to yield I assumed that it was the additional conditions we apply on the matched results that accounted for this: Thus, I wonder: If we're changing the regular expression to check that the given string starts and ends as a URL pattern, is it now enough to just |
@aduth Good point I updated the code to use the simplified condition. |
There was a problem hiding this comment.
Based on tests and assessment of spec-conformance at #20435 (comment), I think this looks fine. 👍
Description
I updated the isURL regex for RN to take account file urls.
Added unit test to validate isURL when parsing file URLs.
How has this been tested?
Using unit tests
Screenshots
Types of changes
Checklist: