[✨ Triage] dotnet/runtime#117391 by MihaZupan - WinHttpHandler reports the wrong error message for large headers

[MihuBot]

Triage for dotnet/runtime#117391.
Repo filter: All networking issues.
MihuBot version: 4431de.
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#117391: WinHttpHandler reports the wrong error message for large headers by MihaZupan
[Tool] Searching for WinHttpHandler large headers, WinHttpHandler ERROR_INVALID_PARAMETER, WinHttpHandler header size limit, WinHttpHandler specialized exception, WinHttpHandler non-Latin-1 header (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/runtime)
[Tool] Found 46 issues, 75 comments, 46 returned results (5520 ms)

Here are the most relevant related issues and discussions for triaging issue #117391 ("WinHttpHandler reports the wrong error message for large headers"):

---

1. Issue #115112 (April 2025, closed June 2025) - "[WinHTTP] Validate header values for ASCII"

• Summary: This issue discusses the lack of validation for header values in WinHttpHandler, which were being passed to WinHTTP.dll without checks. The proposal was to validate headers for ASCII, matching SocketsHttpHandler, but the discussion (including @stephentoub and @ManickaP) clarified that Latin-1 should be allowed for historical reasons, except for dangerous control characters.
• Resolution: Fixed by PR #116634, which improved error reporting for invalid headers and clarified that WinHTTP already refuses bad characters, so the managed code just improves the error message.
• Relevance: Directly related to header validation and error reporting in WinHttpHandler, including the distinction between ASCII, Latin-1, and error messages for invalid headers.

---

2. PR #116634 (June 2025, merged) - "[HTTP] Stricter header value validation"

• Summary: Implements stricter validation for header values, forbidding CR, LF, and NUL, and aligns error messages with the actual cause (e.g., "Request header must be valid Latin-1"). Discussion between @MihaZupan and @ManickaP clarified that WinHTTP sends characters as-is and does not silently corrupt non-ASCII/Latin-1 values.
• Relevance: This PR directly addresses error reporting for invalid headers and improves the specificity of exceptions thrown, which is the core of issue #117391.

---

3. PR #116256 (June 2025, closed) - "[WinHTTP] Validate header values for ASCII"

• Summary: An earlier attempt to restrict headers to ASCII, but closed in favor of PR #116335 after discussion clarified that Latin-1 should be allowed. The discussion also covers exception messages and the correct validation approach.
• Relevance: Shows the evolution of thinking about header validation and error reporting in WinHttpHandler.

---

4. PR #116335 (June 2025, closed) - "[WinHTTP] Validate header values for Latin1"

• Summary: Replaces the previous PR to allow Latin-1 (not just ASCII) in header values, with discussion about handling CRLF and line folding. @MihaZupan notes that header validation should rely on the header collection on modern .NET, and only check for values <= 255.
• Relevance: Directly related to the error handling and validation logic in WinHttpHandler for header values.

---

5. Issue #37024 (May 2020, closed August 2020) - "HTTP header encoding"

• Summary: Discusses ambiguity in HTTP spec regarding header encoding (ASCII, Latin-1, UTF-8), and the need for control over encoding in .NET APIs. Includes a detailed test matrix showing how .NET Framework and .NET Core handle various header byte values.
• Relevance: Provides background on how .NET handles header encoding and the resulting error messages or data corruption, which is relevant to the confusion over error reporting in WinHttpHandler.

---

6. Issue #18670 (September 2016, closed January 2020) - "WinHttpHandler could query individual headers instead of double buffering them in the managed address space"

• Summary: Discusses memory usage and header extraction in WinHttpHandler, with a comment noting that SocketsHttpHandler does not have the same problem.
• Relevance: While not directly about error messages, it is related to header handling in WinHttpHandler.

---

7. Issue #18362 (August 2016, closed January 2020) - ""WinHttpException: The parameter is incorrect" when server return 401"

• Summary: Reports "The parameter is incorrect" error from WinHttpHandler in certain authentication scenarios, with a stack trace showing the error bubbling up as a WinHttpException.
• Relevance: Shows that WinHttpHandler can surface generic error messages (like "The parameter is incorrect") in multiple scenarios, not just header encoding, supporting the claim in #117391 that ERROR_INVALID_PARAMETER is not specific to non-Latin-1.

---

8. Issue #17005 (April 2016, closed January 2020) - "WinHttp buffer supplied to the function was too small error should not be exposed"

• Summary: Discusses how low-level WinHTTP errors (like buffer too small) are surfaced as exceptions in .NET, and whether these should be mapped to more meaningful exceptions.
• Relevance: Related to the general theme of WinHttpHandler surfacing low-level or misleading error messages.

---

Summary

• Recent work (2025) has focused on improving header validation and error reporting in WinHttpHandler, moving from ASCII-only to Latin-1, and clarifying exception messages.
• There is consensus that WinHttpHandler can throw generic errors like ERROR_INVALID_PARAMETER for multiple reasons, not just non-Latin-1 headers, which matches the concern in #117391.
• The proposed fix in #117391 (not throwing a specialized exception for ERROR_INVALID_PARAMETER) is consistent with the direction of recent changes, which aim to make error messages more accurate and less misleading.

If you are triaging #117391, you should reference the recent header validation work (issues/PRs #115112, #116634, #116256, #116335) and note that the error message for large headers is indeed misleading, as ERROR_INVALID_PARAMETER is not unique to non-Latin-1. The suggestion to avoid a specialized exception is well-supported by recent discussions and fixes.

Let me know if you need a more detailed summary of any specific discussion or PR!