Triage for dotnet/runtime#116688 by MihaZupan - SocketsHttpHandler should replace received new lines in headers with spaces

[MihuBot]

Triage for dotnet/runtime#116688.

dotnet/runtime#116688: SocketsHttpHandler should replace received new lines in headers with spaces by MihaZupan
[Tool] Searching for SocketsHttpHandler replace new lines headers, HTTP/2 HTTP/3 headers CR LF NUL, HttpClient response headers invalid characters, RFC9110 header field values, line folds new lines headers (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/runtime)
[Tool] Found 120 issues, 52 comments, 120 returned results (21127 ms)

Here are the most relevant related issues and pull requests to issue #116688 ("SocketsHttpHandler should replace received new lines in headers with spaces"):

---

1. PR #116323 (June 2025) - Fix various HTTP header parsing issues

• Summary: This PR by MihaZupan addresses several HTTP header parsing issues, including blocking new line characters in cookies, blocking escaped new lines in quoted strings, and improving host parsing. It also fixes percent decoding logic in Alt-Svc headers to block new line characters. The PR references improvements in header fuzzing and is directly related to the topic of handling invalid characters in headers.
• Relevance: Shows recent work on header validation, including new line handling, and is authored by the same person as the current issue.

---

2. Issue #29927 (June 2019) - Ignore invalid response header in HttpClient request

• Summary: Users report exceptions when HttpClient encounters non-standard or malformed response headers. The discussion includes community workarounds for removing or replacing invalid headers, and a detailed code sample for a custom stream wrapper that can replace or filter out invalid header characters before HttpClient processes them.
• Relevance: Demonstrates real-world impact of invalid header characters and community demand for more robust handling, including replacing or filtering new lines and other control characters.

---

3. Issue #67199 (March 2022) - HttpHeaders should not remove invalid values during validating access

• Summary: MihaZupan discusses how HttpHeaders currently removes header entries containing new lines or only whitespace during validation, which can cause side effects and inconsistencies. The proposal is to stop implicitly removing such entries, which would allow users to observe new-line characters if they were added without validation.
• Relevance: Directly discusses the handling of new-line characters in header values and the implications for validation and user observability.

---

4. Issue #63808 (January 2022) - SocketsHttpHandler does not preserve request header format

• Summary: Discusses how SocketsHttpHandler consolidates multi-line headers into a single comma-separated header, which can affect applications that require the original format. The discussion touches on how headers are parsed and reformatted, and the side effects of accessing headers through validated APIs.
• Relevance: While focused on formatting, it highlights the parsing and normalization process for headers, which is relevant to how new lines and other separators are handled.

---

5. Issue #38711 (July 2020) - API Proposal: Http header value Encoding selection

• Summary: MihaZupan proposes APIs to allow users to specify encoding for HTTP header values, noting that real-world services sometimes use non-ASCII or non-standard encodings. The proposal includes a warning about encodings that could introduce new line bytes, which could result in malformed requests.
• Relevance: Shows awareness of the risks of new line characters in header values and the need for robust handling, as well as the RFC's requirements.

---

6. PR #39468 (July 2020) - Implement Header encoding selectors on SocketsHttpHandler

• Summary: Implements the API proposal from #38711, allowing custom encoding selectors for headers. The PR notes the risk of encodings that could output new line bytes, and discusses how the implementation could guard against this.
• Relevance: Directly implements logic that could be extended to handle or replace new line characters in headers.

---

7. Issue #77001 (October 2022) - SocketsHttpHandler is inconsistent with header value trimming on HTTP/1.1

• Summary: MihaZupan points out that SocketsHttpHandler trims leading spaces and tabs inconsistently in HTTP/1.1 header values, referencing the relevant RFC. The issue is about whitespace handling, which is closely related to the handling of new lines and other control characters.
• Relevance: Shows ongoing attention to RFC compliance in header parsing and normalization.

---

8. Issue #28869 (March 2019) - Consider adding folded trailing header support

• Summary: Discusses support for folded headers (multi-line headers) in HTTP/1.1, noting that this is obsolete in newer RFCs and not present in HTTP/2. The discussion is about whether to support or reject such headers.
• Relevance: Provides context on the evolution of header folding and new line handling across HTTP versions.

---

9. Issue #116634 (June 2025) - SocketsHttpHandler should reject NUL in header values

• Summary: (Referenced in the new issue) This issue proposes that SocketsHttpHandler should reject NUL characters in header values, as required by RFC 9110. The discussion is about whether to reject or replace NUL characters, similar to the new line handling discussed in #116688.
• Relevance: Directly related, as it is referenced in the new issue and discusses the same section of RFC 9110.

---

Summary

• There is ongoing and recent work (see PR #116323 and issue #116634) to improve header validation in SocketsHttpHandler, including handling of new lines, NUL, and other control characters as required by RFC 9110.
• Multiple issues and PRs (notably by MihaZupan) discuss the challenges and requirements of handling invalid or dangerous characters in HTTP headers, both for HTTP/1.1 and HTTP/2/3.
• Community feedback and workarounds (see #29927) show that this is a real-world problem, and there is demand for robust, RFC-compliant handling.
• The new issue (#116688) is well-aligned with these ongoing efforts and is supported by both recent and historical discussions in the repository.

If you need more detail on any specific issue or PR, let me know!