feat: add lenient flag for duplicate Content-Length - #879
Open
SUJP123 wants to merge 1 commit into
Open
Conversation
llhttp rejects a repeated `Content-Length` outright. RFC 9112 Section 6.3 lets a recipient either reject such a message or, when every value is identical, collapse them into one -- the latter arises when an upstream message processor combines or regenerates the header. This adds `llhttp_set_lenient_duplicate_content_length()`, off by default, alongside the existing lenient flags. With the flag set, the repeated header is routed to the general header-value path rather than erroring: `on_header_field` and `on_header_value` fire for every occurrence, and the body is framed with the first value. The parser deliberately does not compare the values. Doing so in the state machine would need a new property plus a custom native, since `isEqual` only compares a property to a constant, and callers that want this flag generally have the assembled header set already. The flag is documented accordingly: a caller enabling it MUST reject the message itself when the values differ. This is narrower than the two adjacent flags: LENIENT_CHUNKED_LENGTH and LENIENT_TRANSFER_ENCODING both permit what the spec forbids, whereas duplicate Content-Length with identical values is explicitly one of two conformant choices. Motivation: proxygen is migrating its HTTP/1.x codec from http_parser to llhttp. Its codec already accepts identical duplicates and rejects differing ones, and real-world traffic relies on that behaviour. It is an existing consumer of this mechanism, enabling lenient_chunked_length, optional_cr_before_lf and optional_lf_after_cr.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
注册 for free
to join this conversation on GitHub.
Already have an account?
登录 to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
llhttp rejects a repeated
Content-Lengthoutright. RFC 9112 Section 6.3 lets a recipient either reject such a message or, when every value is identical, collapse them into one -- the latter arises when an upstream message processor combines or regenerates the header.This adds
llhttp_set_lenient_duplicate_content_length(), off by default, alongside the existing lenient flags. With the flag set, the repeated header is routed to the general header-value path rather than erroring:on_header_fieldandon_header_valuefire for every occurrence, and the body is framed with the first value.The parser itself does not compare the values of the CL headers to ensure they match, as that is functionality expected by the caller. This flag just prevents those requests from being rejected.