-
Notifications
You must be signed in to change notification settings - Fork 184
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
http: lenient parsing flag #33
Conversation
Note: benchmarks show no performance degradation whatsoever, which is expected since the condition is triggered in the same place where an error would be triggered otherwise. |
Another note: I've upgraded the |
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.
Would the idea be to also address other points listed under https://github.com/creationix/http-parser-js/blob/master/tests/README.md using this flag, i.e. to extend the lenient mode to cover more technically invalid but real-world data?
The ones there that cover different content-length edge cases are too dangerous to implement here. They'll open up a way for a request smuggling. I think it might make sense to land it as it is now, and introduce more support depending on whether an issue will be filed in node.js repo or not. In each case we'll have to decide together whether such leniency would be safe to add. |
cc @bnoordhuis |
} else if (parser->flags & F_LENIENT) { | ||
parser->flags ^= F_LENIENT; | ||
} | ||
} |
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.
Shorter/branchless way of doing the same (not that it really matters but, you know, it looks neat):
parser->flags ^= F_LENIENT & parser->flags;
parser->flags ^= F_LENIENT * !!enabled;
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.
Good point. While we are here, am I right that &= ~F_LENIENT
would not work reliably here? (out of curiosity)
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.
It does actually but two statements with a common prefix is aesthetically pleasing to me. :-)
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.
Thanks!
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.
I decided to go with ~F_LENIENT
as it is less tricky and explicit.
d3ae731
to
60fb151
Compare
Introduce `llhttp_set_lenient` API method for enabling/disabling lenient parsing mode for header value. With lenient parsing on - no token check would be performed on the header value. This mode was originally introduced to http-parser in nodejs/http-parser@e2e467b9 in order to provide a fallback mode for less compliant clients/servers.
60fb151
to
7b58fae
Compare
Landed in 95321e2, thank you everyone! |
Introduce `llhttp_set_lenient` API method for enabling/disabling lenient parsing mode for header value. With lenient parsing on - no token check would be performed on the header value. This mode was originally introduced to http-parser in nodejs/http-parser@e2e467b9 in order to provide a fallback mode for less compliant clients/servers. PR-URL: #33 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
Introduce
llhttp_set_lenient
API method for enabling/disabling lenientparsing mode for header value. With lenient parsing on - no token check
would be performed on the header value.
This mode was originally introduced to http-parser in
nodejs/http-parser@e2e467b in
order to provide a fallback mode for less compliant clients/servers.
See: nodejs/node#30222 (comment)
cc @addaleax @nodejs/http