| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
I'm +1 on this. Can you fix the linting issue as well as your commit message?
Sorry, something went wrong.
I updated the commit message and changed the string from backticks to single quotes with escapes to pass linting. Thanks for the help! |
Sorry, something went wrong.
|
Can you also add a test? |
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
lgtm
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM with a nit about expanding the tests a bit more
Sorry, something went wrong.
There was a problem hiding this comment.
It probably does not matter as the header is sent by the server but this regex is vulnerable to ReDoS.
Sorry, something went wrong.
There was a problem hiding this comment.
FWIW the original is also vulnerable.
Sorry, something went wrong.
There was a problem hiding this comment.
I'm not questioning your point, I'm asking as I want to learn on this matter:
Sorry, something went wrong.
There was a problem hiding this comment.
- How do you know?
https://github.com/makenowjust-labs/recheck
- How can we fix it?
Usually it is possible to tweak the regex. I'm not sure if it is possible in this case. I did not spend time on it. The input is "trusted" so I think it does not worth the effort.
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks for reference.
I also think it's not worth the effort. Shall we just insert a comment for future knowledge?
Sorry, something went wrong.
There was a problem hiding this comment.
The input is "trusted" so I think it does not worth the effort.
I'd be concerned that we'd start leveraging this at a future time for something and expose it to end users. There should at least be a comment, IMO.
Sorry, something went wrong.
There was a problem hiding this comment.
(To be 100% clear: If we're certain that this is not something that will accept user input, yeah, we don't need to fix it. But let's add a comment explaining.)
Sorry, something went wrong.
There was a problem hiding this comment.
This regex (and the existing one) will fail to do the right thing if a quotation mark is backslash-escaped inside the string, right? (I only skimmed the spec so I apologize if I'm wrong!) Are we doing the whole "using a regexp when a parsing algorithm is what is needed" thing? (This is a question, but not a blocking objection or anything. The current regexp would have the same issue if this one has that issue.)
Sorry, something went wrong.
There was a problem hiding this comment.
You could have a for loop that loops backward from the string examining each character. That might actually be more performant than a regex.
It could also start from the beginning of the string, but yes, I think that it would be better.
Sorry, something went wrong.
There was a problem hiding this comment.
We can add a TODO comment and do this in a follow-up PR.
Sorry, something went wrong.
|
linting is failing |
Sorry, something went wrong.
Sorry, something went wrong.
|
@nodejs/build could you take a look? This seems an odd failure: https://ci.nodejs.org/job/node-test-commit/59852/console |
Sorry, something went wrong.
11:18:44 + git rev-parse origin/main
11:18:44 + REBASE_ONTO=96c720e98f4ea80103a9d240ae8072190a226729
11:18:44 + git rebase --committer-date-is-author-date 96c720e98f4ea80103a9d240ae8072190a226729
11:18:45 Rebasing (1/6)
Auto-merging lib/internal/validators.js
11:18:45 CONFLICT (content): Merge conflict in lib/internal/validators.js
11:18:45 error: could not apply 2e6e618a56b... http: fix validation of "Link" headerIt has failed to rebase this PR onto main (96c720e at the time). Possibly fe514bf has changed the file enough to confuse git? |
Sorry, something went wrong.
Updated regex for "Link" header validation to better match the specification in RFC 8288 section 3. Does not check for valid URI format but handles the rest of the header more permissively than before. Alternative to another outstanding PR that disables validation entirely. Fixes: #46453 Refs: https://www.rfc-editor.org/rfc/rfc8288.html#section-3 Refs: #46464
|
There was a new comma in validators.js in main. Rebased successfully. |
Sorry, something went wrong.
There was a problem hiding this comment.
lgtm
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Updated regex for "Link" header validation to better match the specification in RFC 8288 section 3. Does not check for valid URI format but handles the rest of the header more permissively than before. Alternative to another outstanding PR that disables validation entirely. Fixes: #46453 Refs: https://www.rfc-editor.org/rfc/rfc8288.html#section-3 Refs: #46464 PR-URL: #46466 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Paolo Insogna <paolo@cowtech.it> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Updated regex for "Link" header validation to better match the specification in RFC 8288 section 3. Does not check for valid URI format but handles the rest of the header more permissively than before. Alternative to another outstanding PR that disables validation entirely. Fixes: #46453 Refs: https://www.rfc-editor.org/rfc/rfc8288.html#section-3 Refs: #46464 PR-URL: #46466 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Paolo Insogna <paolo@cowtech.it> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
| Back | FazBrowse Home | New Git URL |
Updated regex for "Link" header validation to better match the
specification in RFC 8288 section 3. Does not check for valid URI
format but handles the rest of the header more permissively than
before. Alternative to another outstanding PR that disables validation
entirely.
Fixes: #46453
Refs: https://www.rfc-editor.org/rfc/rfc8288.html#section-3
Refs: #46464