[✨ Triage] dotnet/runtime#117198 by amanasifkhalid - `SendAsync_RequestWithDangerousControlHeaderValue_ThrowsHttpReq ...

[MihuBot]

Triage for dotnet/runtime#117198.
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#117198: `SendAsync_RequestWithDangerousControlHeaderValue_ThrowsHttpRequestException` fails with QUIC protocol error by amanasifkhalid
[Tool] Searching for SendAsync_RequestWithDangerousControlHeaderValue_ThrowsHttpRequestException, QUIC protocol error, dangerous control header value HttpClient, QUIC HttpRequestException (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/runtime)
[Tool] Found 89 issues, 93 comments, 89 returned results (9674 ms)

Here are the most relevant related issues and discussions for triaging issue #117198 "SendAsync_RequestWithDangerousControlHeaderValue_ThrowsHttpRequestException fails with QUIC protocol error":

---

1. Issue #117161 (June 2025) - "SendAsync_OperationCanceledException_RecordsActivitiesWithCorrectErrorInfo test failed with 'Exception type was not an exact match'"

• Summary: This issue discusses failures in HTTP/3 tests, including SendAsync_RequestWithDangerousControlHeaderValue_ThrowsHttpRequestException, where the error message is "A QUIC protocol error was encountered." instead of the expected substring "ASCII". The test is failing because the assertion is looking for a specific error message substring that is not present when a QUIC protocol error occurs.
• Key Comment: The author of #117198, @amanasifkhalid, commented here:

  I'm seeing similar failures in SendAsync_RequestWithDangerousControlHeaderValue_ThrowsHttpRequestException ...
  Assert.Contains() Failure: Sub-string not found String: "A QUIC protocol error was encountered." Not found: "ASCII"
  Can we update the error message filter to capture "A QUIC protocol error was encountered", or should these be tracked separately?

• Relevance: This is a direct hit—your issue is already being discussed as a related symptom of a broader problem with error message matching in HTTP/3/QUIC tests.

---

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

• Summary: This PR tightened header value validation, especially for dangerous control characters (e.g., NUL, CR, LF) in HTTP headers, and added/updated tests for all handlers and header types. It specifically mentions that WinHTTP already refuses bad characters, and the error message was improved to "Request header must be valid Latin-1".
• Discussion: There is discussion about how different handlers (WinHTTP, SocketsHttpHandler, etc.) handle invalid header values, and how error messages are surfaced.
• Relevance: This PR is likely the source of the stricter validation that is now causing the test to fail with a QUIC protocol error, rather than the previously expected error message. It is highly relevant for understanding the root cause and the expected error message changes.

---

3. Issue #30430 (July 2019) - "HttpClient send with no-ascii header value throw exception"

• Summary: Discusses how HttpClient throws exceptions when sending headers with non-ASCII values, and the rationale for strict validation of outgoing headers.
• Key Comments:
  • "While HTTP 1.1 does allow non-ascii data in headers, later revisions recommend against it and we follow this recommendation."
  • "Writing out headers with non-ASCII is strictly not allowed."
• Relevance: Provides historical context for why strict header validation exists and why exceptions are thrown for invalid header values.

---

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

• Summary: Users request more lenient handling of invalid headers, but maintainers explain the importance of strict validation for outgoing requests.
• Key Comments:
  • "This follows the networking principle of 'Be flexible in what you receive and strict in what you send'."
• Relevance: Further context for the design philosophy behind strict header validation.

---

5. Issue #83932 (March 2023) - "Quic exception in the guts of making an http request"

• Summary: Discusses how QUIC-related exceptions can bubble up and cause failures in HttpClient requests, sometimes due to platform or configuration issues.
• Relevance: Shows that QUIC protocol errors can manifest in various ways, and that error handling/reporting for QUIC is a recurring theme.

---

6. Issue #72666 (July 2022) - "[QUIC] Surface transport error code in QuicException"

• Summary: Discusses how transport-level error codes from QUIC are surfaced in exceptions, and the need to improve error reporting for QUIC protocol errors.
• Key Comment:
  • "Triage: in the same bucket as other exception related issues, should be investigated and decided in 8.0."
• Relevance: Indicates ongoing work to improve how QUIC errors are reported and mapped to exceptions.

---

7. PR #88550 (July 2023) - "Added QuicException.TransportErrorCode"

• Summary: Implements surfacing of transport error codes in QuicException, improving diagnostics for QUIC protocol errors.
• Relevance: This change may affect how error messages are reported in tests like the one failing in your issue.

---

Conclusions and Recommendations

• Your issue is a symptom of stricter header validation (see PR #116634) and changes in how QUIC protocol errors are surfaced (see #72666, #88550).
• The test is failing because it expects a specific error message substring ("ASCII"), but now receives a generic QUIC protocol error message ("A QUIC protocol error was encountered.").
• This is already being discussed in #117161, where the suggestion is to update the error message filter to also match the new QUIC error message, or to track these failures separately.
• The root cause is a combination of stricter header validation and improved QUIC error reporting.

---

Action Items

• Consider updating the test's error message assertion to allow for the new QUIC protocol error message, as suggested in #117161.
• If the test is meant to specifically check for ASCII validation, you may want to distinguish between validation failures and protocol errors, or update the test to reflect the new expected behavior.
• Track ongoing work in the related issues and PRs for further changes to error reporting and validation.

---

References:

• Issue #117161
• PR #116634
• Issue #30430
• Issue #29927
• Issue #83932
• Issue #72666
• PR #88550

Let me know if you need a more detailed summary of any specific thread!