[10.2][hdrs] obs-fold continuation silently dropped when CRLF lands on an input-buffer boundary

Branch: 10.2.x (10.2.1, commit 31f1f2f3b) · Severity: medium · category: logic-bug
Location: src/proxy/hdrs/MIME.cc:2383 (MIMEScanner::get)

What's wrong

MIMEScanner::get() only detects an obs-fold (line-folding) continuation when the preceding LF and the next line's leading whitespace arrive in the same get() call. In the post-loop CONT cleanup, when state == AFTER and more input is not yet available (non-eof), it returns OK for the field instead of waiting — so whether an obs-folded header is joined or split depends on TCP segmentation, i.e. non-deterministic parsing that can differ from the origin/other proxies (a request-smuggling-adjacent differential).

Suggested fix

Return CONT while in AFTER state at a buffer boundary (non-eof) so the scanner waits for the next byte before deciding, or reject obs-fold outright (RFC 7230 permits rejecting it with 400).

Why tracked, not yet a PR

This is a change to the incremental header-scanner state machine; the correct behavior interacts with streaming/segmentation and must be validated with the end-to-end autest suite (and ideally fuzzing), which isn't available in the audit environment. Filing for a maintainer.

From an automated multi-lens audit of the 10.2.x branch. Full report on branch claude/codebase-audit-review-9nw7vz (CODEBASE_AUDIT_10.2.md).

Start in the 10.2.x branch at src/proxy/hdrs/MIME.cc:2383, in MIMEScanner::get, and trace the AFTER-state cleanup at an input-buffer boundary. Compare returning CONT with rejecting obs-fold, then validate the chosen behavior across streaming and TCP segmentation using the end-to-end autest suite and, if available, fuzzing. Done means folded headers are handled consistently or rejected rather than silently split or dropped.