-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
perf: improve URL parsing performance #9694
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
} | ||
} | ||
|
||
const match = url.match(urlRegex); |
Check failure
Code scanning / CodeQL
Polynomial regular expression used on uncontrolled data
1dcba82
to
67676d6
Compare
size-limit report 📦
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The goal here is not so much performance as bundle size. Since we are not running this in any perf critical path I would prefer the smaller size.
67676d6
to
07f0572
Compare
@mitsuhiko The current implementation is prone to bugs. Regexp approach is wrong and results in bugs. For example currently we don't handle |
urlInstance: URL; | ||
}>; | ||
|
||
const urlRegex = /^(([^:/?#]+):)?(\/\/([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?$/; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there an external reference to the source of this regexp that would make sense to add here? I'm asking because these look daunting (at least to me), but I find that they can usually be a good way to educate, for example maybe by linking to the standard that this is supposed to support.
@anonrig I think we could use |
Follow up for #9676.
Without introducing any breaking changes, this is what I came up with that is in par with current regexp parsing. I'm not quite happy with it, but I think it's better than the current approach.
cc @AbhiPrasad