Normalize repeated carriage returns in headers - #13595
Open
RajaMuhammadAwais wants to merge 1 commit into
Open
Conversation
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Fix HTTP header serialization so malformed header line endings containing repeated carriage-return (
CR) bytes are not forwarded unchanged to the next hop.This addresses issue #12195, where ATS was observed forwarding header lines such as
Extra-CRs: \r\r\r\r\nwith the extra carriage returns preserved.Problem
ATS intentionally preserves the original input buffer for some valid
CRLF-terminated fields as a serialization fast path. The parser already trims trailing whitespace, line-feed, and carriage-return characters from the parsed field value, but it could still mark a line with repeated carriage returns as safe for raw-line preservation merely because it ended inCRLF.As a result, the normalized field representation and the serialized wire representation could differ: the parsed value was normalized, while the original malformed line—including the extra
CRbytes—could be forwarded downstream.This is undesirable for HTTP intermediaries because downstream components should not receive malformed line endings that ATS has already parsed and normalized.
Implementation
The parser now disables raw input-line preservation when either of the following is true:
CRLFsequence; orCRLFis itself a carriage return, indicating repeated carriage returns at the line ending.When raw preservation is disabled, ATS serializes the parsed field using its normal canonical format, producing a single
CRLFterminator. The existing fast path for correctly formed header lines remains unchanged.Regression Test
Added a header unit test that:
Extra-CRs: \r\r\r\r\n.Extra-CRs: \r\nform.Validation
The following checks were completed locally:
test_proxy_hdrssuite passed: 53 test cases and 436,882 assertions.git diff --checkpassed.Scope and Compatibility
This change is limited to serialization of header fields whose raw line ending contains repeated carriage returns. Properly formed
CRLFheader lines retain the existing behavior. No public API, configuration setting, or wire format for valid HTTP headers is changed.Related Issue
Fixes #12195