[✨ Triage] dotnet/runtime#130458 by MichalStrehovsky - [Test Failure] WinHTTP: System.Net.Http.Functional.Tests.Plat ...

[MihuBot]

Triage for dotnet/runtime#130458.
Repo filter: All networking issues.
MihuBot version: 9507a5.
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.

Tool logs

dotnet/runtime#130458: [Test Failure] WinHTTP: System.Net.Http.Functional.Tests.PlatformHandler_HttpClientHandler_Http2_Test.SendAsync_RequestWithLatin1HeaderValue_Succeeds by MichalStrehovsky
Extracted 5 search queries: WINHTTP_CALLBACK_STATUS_REQUEST_ERROR Error 12030 The connection with the server was terminated abnormally, PlatformHandler HttpClientHandler Http2 SendAsync failure with Latin1 header value (0x00A0), HttpRequestException: Error while copying content to a stream -> System.IO.IOException -> WinHttpException 12030, HTTP/2 on Windows WinHTTP handler connection terminated during request with non-ASCII header, System.Net.Http functional test failures for RequestWithLatin1HeaderValue
Found 25 candidate issues

• Issue #115112 (April 2025) - [WinHTTP] Validate header values for ASCII
  Summary: Proposed adding validation for header values passed to WinHTTP to match SocketsHttpHandler behavior (with explicit note that historical Latin‑1 bytes are allowed). The issue was fixed by PR #116634. Relevance: addresses how WinHTTP/PlatformHandler treats non‑ASCII / Latin‑1 header bytes; if your failing test is about sending Latin‑1 header values, this change is directly relevant (it was the work that normalized header validation behavior).

• PR #117756 (July 2025) - [HTTP] WinHTTP fix exception (merged)
  Summary: Removed the special‑case conversion that turned certain WinHTTP error codes (e.g. ERROR_INVALID_PARAMETER) into FormatException and instead always surfaces a WinHttpException (using the WinHttp error code). Tests were updated accordingly. Relevance: changed the exception semantics/tests around invalid header values — tests that previously asserted on a FormatException or a specific error message were updated to expect a WinHttpException. Also: reviewer comments called out that asserting on localized error message text is brittle and recommended asserting on HResult/error code instead. The current failing test is a PlatformHandler (WinHTTP) test for Latin‑1 headers; this PR shows the team intentionally changed how WinHTTP errors are surfaced, which may affect test expectations.

• Issue #30430 (July 2019) - HttpClient send with no-ascii header value throw exception
  Summary: Discussion of the policy that SocketsHttpHandler disallows sending headers with non‑ASCII characters (by design), while being lenient when receiving. The rationale is protocol/compatibility (no encoding defined beyond US‑ASCII), so sending non‑ASCII is rejected. Relevance: gives context for why handlers differ in behavior around non‑ASCII/Latin‑1 headers; the test under failure is exercising Latin‑1 behavior and this issue documents that handler behavior is a deliberate design decision.

• Issue #32482 (February 2020) - HttpClient not able to handle UTF8 Headers
  Summary: Discussion about receiving non‑ASCII header values in responses (e.g. cookies) and whether to accept UTF‑8/Latin‑1 in some headers. The team opted for conservative behavior but has made some targeted exceptions (e.g. Location). Relevance: background on historical and design choices around header encodings (helps reason whether a failing Latin‑1 header test is a behavior change or a flaky environment).

• Issue #69238 (May 2022) - Manual_CertificateOnlySentWhenValid_Success fails with WINHTTP_CALLBACK_STATUS_REQUEST_ERROR in rolling CI
  Summary: Long‑running flakiness in WinHTTP tests showing WINHTTP_CALLBACK_STATUS_REQUEST_ERROR (various error codes, often 12175). Investigation concluded many occurrences are environmental or TLS/certificate related; suggested capturing more WinHTTP diagnostic info and/or disabling flakey tests. Relevance: the current failure shows a WinHttpException with WINHTTP_CALLBACK_STATUS_REQUEST_ERROR (Error 12030 — connection terminated abnormally). Issue #69238 is a direct precedent for intermittent WINHTTP_CALLBACK_STATUS_REQUEST_ERROR failures in CI and contains triage suggestions (capture WinHTTP status codes/details, consider environment).

• Issue #33509 (March 2020) - Error 12175 calling WINHTTP_CALLBACK_STATUS_REQUEST_ERROR, "A security error occurred"
  Summary: Another recurring case of WINHTTP secure‑failure (12175) in server environments; triage concluded that these are most often TLS/certificate/environment issues and requested repros or switching to SocketsHttpHandler for comparison. Relevance: further precedent that WINHTTP secure/TLS errors surface as WINHTTP_CALLBACK_STATUS_REQUEST_ERROR and may be environmental rather than a test/assertion bug.

• Issue #95155 (November 2023) - [6.0] Error 12175 calling WINHTTP_CALLBACK_STATUS_REQUEST_ERROR (Known Build Error)
  Summary: Recorded as a Known Build Error for 6.0 branch; similar symptom (12175) in CI runs. Low hit counts and eventually closed. Relevance: more evidence that WINHTTP request error codes (esp. secure/TLS ones) repeatedly show up in CI and are often triaged as infra/environmental.

• Issue #121913 (November 2025) - Broken error handling in WinHttpHandler
  Summary: Found unobserved exception risk in WinHttpHandler where a task that sends request body is awaited in a finally block without proper chaining/observation; can lead to unobserved exceptions being raised by finalizer thread. The issue attracted interest and suggestions to accept PRs to fix. Relevance: explains some WinHTTP error / crash patterns where request body send errors bubble in unexpected ways; while not the same symptom, it’s relevant to diagnosing WinHTTP request/send path robustness.

• Issue #30639 (August 2019) - HTTP2: Header corruption issue in SocketsHttpHandler
  Summary: HPACK integer encoding bug in SocketsHttpHandler caused header corruption over HTTP/2; was diagnosed and fixed. Relevance: shows that HTTP/2 header handling bugs (HPACK/encoding) can cause tests about headers to fail. The current failing test is an HTTP/2 PlatformHandler test; however, the above bug was in SocketsHttpHandler, not WinHTTP — still worth keeping in mind when debugging HTTP/2 header test failures.

Notes & actionable takeaways for triage of this new failure (#130458)

• The failure you posted shows a WinHttpException: "Error 12030 ... The connection with the server was terminated abnormally." That pattern is commonly seen in flaky WinHTTP CI runs and often points to transient networking/TLS/certificate or server‑side termination — see #69238, #33509, #95155 for precedent. Before assuming a code regression, check for environmental flakiness (re-run, capture Helix logs/WinHTTP traces).
• If the intent of the test is to assert behavior around Latin‑1 header handling, check the historical handler behavior and the fixes/PRs: header validation work (#115112 → fixed by #116634) and the exception‑surfacing change in PR #117756 (WinHTTP now surfaces WinHttpException rather than special‑casing FormatException). Tests that rely on specific localized error messages are brittle — prefer asserting on HResult/error code or WinHttpException type instead (this was recommended in the PR review comments).
• To diagnose further: capture WinHTTP diagnostics (netsh trace, or enable WinHTTP logging) and include lpvStatusInformation where available (see comments in issues such as #33509 and #69238). Also try running the same test with SocketsHttpHandler (if possible) to see whether the failure is specific to the WinHTTP/PlatformHandler path.
• If CI shows this is a transient infra/TLS issue across multiple runs, consider marking the test as known flaky / disabling on the affected queue while investigating (this was the path taken for other recurring WINHTTP_CALLBACK_STATUS_REQUEST_ERROR flakes in CI).

If you want, I can:

• pull the specific Helix/console log for this build and cross‑check whether it resembles previous WINHTTP_CALLBACK_STATUS_REQUEST_ERROR flakes, or
• list the exact commits (PRs) that changed header validation/exception behavior so we can review expected test assertions.