Defer WinHTTP HTTP/2 loopback connection closure until server disposal

[rzikm]

WinHTTP can discard buffered response data when the loopback server sends FIN before the client consumes it, causing error 12030. This affects more than cookie tests: the same failure signature also appeared in ClientCertificateTest.UseClientCertOnHttp2_OSSupportsIt_Success. Synchronizing individual tests leaves other paths exposed.

This change moves lifetime management into the shared HTTP/2 loopback infrastructure. In WinHTTP tests, connection disposal sends GOAWAY but retains the transport until the enclosing server is disposed, normally after both client and server callbacks complete. Retired connections do not prevent subsequent connections from being accepted. Automatic GOAWAY respects earlier last-stream boundaries, and cleanup tolerates the server closing a connection during asynchronous disposal.

The behavior is enabled by default only for WinHTTP tests. Explicit shutdown methods remain immediate, and tests requiring the original disposal behavior can set DeferConnectionClose = false. The HTTP/2 cookie tests quarantined under #126867 are re-enabled; no cookie-specific synchronization or product code changes are needed.

Validation

• WinHTTP functional suites: 1,749 tests on .NET 11 and 667 on .NET Framework, with zero failures and 41/28 existing skips respectively.
• WinHTTP unit tests: 173 passed.
• SocketsHttpHandler HTTP/2 protocol and cookie tests: 212 passed.
• Ten repetitions of the affected cookie, certificate, and lifetime tests: 800 passes, no failures or skips.
• Regression tests verify that responses remain readable after connection disposal and that physical closure during deferred disposal completes safely. Both regressions were checked against the corresponding unfixed behavior. These verify the lifetime contract, not a deterministic reproduction of native error 12030.

Fixes #133779
Fixes #130458
Fixes #126867

... and countless others that boil down to "Error 12030 calling WINHTTP_CALLBACK_STATUS_REQUEST_ERROR, 'The connection with the server was terminated abnormally'."

Note

This pull request description and changes were generated with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[Copilot]

🟡 Changes recommended

Two moderate concurrency and cleanup-safety issues remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

This PR defers WinHTTP HTTP/2 loopback connection closure until server disposal, preserving buffered responses and re-enabling affected cookie tests.

Changes:

• Adds deferred disposal, GOAWAY tracking, and cleanup regression tests.
• Re-enables WinHTTP HTTP/2 cookie tests.
• Updates shared loopback connection lifecycle handling.

File summaries

File	Summary
src/libraries/System.Net.Http.WinHttpHandler/tests/FunctionalTests/WinHttpHandlerTest.cs	Adds deferred-disposal regression tests.
src/libraries/System.Net.Http.WinHttpHandler/tests/FunctionalTests/PlatformHandlerTest.cs	Re-enables HTTP/2 cookie tests.
src/libraries/Common/tests/System/Net/Http/Http2LoopbackServer.cs	Manages retained connections and server cleanup. Moderate finding (1 vote): deferred-close state visibility is unsynchronized.
src/libraries/Common/tests/System/Net/Http/Http2LoopbackConnection.cs	Implements deferred GOAWAY and closure behavior. Moderate finding (2 votes): concurrent field cleanup can race active I/O and cause NullReferenceException.

Review details

Suppressed comments (1)

src/libraries/Common/tests/System/Net/Http/Http2LoopbackServer.cs:94

• IsCloseDeferred is read under the server's _connections lock, but _closeDeferred is written by Http2LoopbackConnection.DisposeAsync without that lock and is a plain bool. The lock therefore does not establish visibility between a completed deferred disposal and a concurrent EstablishConnectionAsync, so the new-connection path can still observe false and throw Connection already established. Synchronize this state transition (for example with matching Volatile.Read/Volatile.Write, or by using the server lock for both sides).

                if (!AllowMultipleConnections && _connections.Exists(c => !c.IsCloseDeferred))

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Lite

[rzikm]

/ba-g only known errors

[rzikm]

/backport to release/11.0

[github-actions]

Started backporting to release/11.0 (link to workflow run)