[✨ Triage] dotnet/runtime#116856 by MihaZupan - Content-Length headers with multiple values aren't sufficiently vali ...

[MihuBot]

Triage for dotnet/runtime#116856.
Repo filter: All networking issues.
MihuBot version: 1a6438.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

dotnet/runtime#116856: Content-Length headers with multiple values aren't sufficiently validated by MihaZupan
[Tool] Searching for Content-Length multiple values, Content-Length validation, Content-Length header parsing, StreamContent.Headers Content-Length, RFC9112 Content-Length (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/runtime)
[Tool] Found 31 issues, 16 comments, 31 returned results (5018 ms)
[Tool] Obtained 0 comments for issue #21929: [HttpListener] [Managed] HttpListener.GetContext should fail if Content-Length is specified twice with different values
[Tool] Obtained 2 comments for issue #116323: Fix various HTTP header parsing issues
[Tool] Obtained 16 comments for issue #102416: Content-Length header not always returned when enumerating HttpContentHeaders
[Tool] Obtained 9 comments for issue #62258: SocketsHttpHandler does not enforce request Content-Length correctness

Here are the most relevant related issues and discussions for triaging issue #116856, "Content-Length headers with multiple values aren't sufficiently validated":

---

1. Issue #21929 (May 2017) - "[HttpListener] [Managed] HttpListener.GetContext should fail if Content-Length is specified twice with different values"

• Summary: This issue reports that the managed implementation of HttpListener does not fail when a request contains two Content-Length headers with different values, whereas the Windows implementation does. The expectation is that the request should be rejected if the values differ, but accepted if they are the same.
• Relevance: This is directly related to the RFC requirement cited in #116856. It highlights a gap in validation for multiple Content-Length headers and aligns with the need for stricter validation as described in the new issue.
• Resolution: The issue was closed, but the discussion and test cases are relevant for understanding expected behavior.

---

2. PR #102416 (May 2024, merged) - "Content-Length header not always returned when enumerating HttpContentHeaders"

• Summary: This PR addresses when and how the Content-Length header is exposed via header enumeration. The discussion includes details about when validation occurs and how the header is computed or exposed.
• Relevant Comments:
  • MihaZupan notes that validation for conflicting headers (like Content-Length and Transfer-Encoding: chunked) is performed at the SocketsHttpHandler layer.
  • There is discussion about the correct timing and method for computing and exposing the Content-Length value, but not about validating multiple values for equality.
• Relevance: While this PR is more about header enumeration, it contains references to where header validation logic is implemented and may be useful for locating where to add or improve validation for multiple Content-Length values.

---

3. Issue #62258 (Dec 2021, closed) - "SocketsHttpHandler does not enforce request Content-Length correctness"

• Summary: This issue discusses the lack of enforcement that the number of bytes sent matches the Content-Length header. The discussion covers protocol violations and the need to throw exceptions when mismatches occur.
• Relevant Comments:
  • MihaZupan and others discuss the importance of strict validation for protocol compliance and security.
  • The conversation is focused on matching the actual content length to the header, not specifically on multiple header values, but it is part of the broader context of header correctness.
• Relevance: This issue and its resolution (see PR #62541 below) show the team's willingness to enforce stricter protocol compliance, which supports the motivation for #116856.

---

4. PR #62541 (Dec 2021, merged) - "Enforce HTTP request Content-Length correctness"

• Summary: This PR enforces that the number of bytes sent matches the Content-Length header, throwing exceptions when there is a mismatch. It is a direct fix for #62258.
• Relevant Comments:
  • MihaZupan explains the rationale for throwing exceptions and the types of exceptions used.
  • The PR does not address multiple Content-Length values, but it is part of the same area of protocol enforcement.
• Relevance: Shows recent work in enforcing Content-Length correctness, though not specifically about multiple values.

---

5. PR #116323 (June 2025, merged) - "Fix various HTTP header parsing issues"

• Summary: This PR fixes several header parsing issues, including stricter validation for certain headers (e.g., blocking new line characters in Cookie and Host headers).
• Relevant Comments:
  • There is a brief discussion about possibly centralizing header validation, including for null characters, but not specifically about Content-Length multi-value validation.
• Relevance: Indicates ongoing work to improve header validation, and the suggestion to centralize such logic could be relevant for implementing the fix for #116856.

---

Summary

• Directly related: Issue #21929 is the most directly related, as it discusses the exact scenario of multiple Content-Length headers with differing values and the need to reject such requests.
• Contextually related: PRs #102416, #62541, and #116323, and issue #62258, all show recent and ongoing work in the area of HTTP header validation and protocol compliance, though they do not specifically address the multi-value Content-Length scenario.
• No evidence of fix: There is no evidence that the specific scenario described in #116856 (multiple Content-Length values not being validated for equality) has been fully addressed in the current codebase.

---

Conclusion:
The issue raised in #116856 is valid and not a duplicate. There is clear precedent (see #21929) and RFC support for requiring stricter validation of multiple Content-Length headers. The related discussions and PRs show that the team is actively working on protocol compliance, but this specific gap remains. The issue should be triaged as a standards compliance bug, and the related issues/PRs above may provide useful context for implementation and testing.