[lewing]

Fixes several WasiHttpHandler (the wasi:http handler used by HttpClientHandler on WASI) behaviors that made failures hang or surface the wrong exception.

Request content failures hang until timeout. SendContent was started fire-and-forget, so if serializing the request content threw or was canceled, nothing observed it and the request waited for a response until HttpClient.Timeout (100s). The handler now watches the send task while polling for the response and fails the request with the content's exception.

Dispose hides the real exception. Stream.Dispose() called the WasiOutputStream.Close() override, which finished the outgoing body. After a content failure, that threw a WitException from OutgoingBody.Finish, which replaced the original exception. Completing the body is now an explicit Finish(), and disposing an unfinished stream aborts the body.

Pending-pollable disposal trap. Dropping a request or response stream while a read or write pollable (a child resource) was still registered trapped wasmtime with resource has children and killed the process. The streams now cancel their pending wait before dropping the stream.

Chunked / Content-Length. wasi:http forbids the Transfer-Encoding header, so TransferEncodingChunked = true failed header validation. It now omits the header (and Content-Length) and lets the host chunk the body, and chunked encoding without content throws InvalidOperationException like SocketsHttpHandler. For content with a known length, Content-Length is now computed and sent.

Exception types aligned with SocketsHttpHandler.

• Null or relative request URIs now throw InvalidOperationException, and non-http(s) schemes throw NotSupportedException; both used to throw ArgumentException.
• wasi:io stream errors while reading the response body now throw HttpIOException(HttpRequestError.ResponseEnded) instead of a raw WitException.
• CanRead is false after the response stream is disposed.

Validation

CoreCLR WASI, Release, wasmtime 49.0.1. Each run was done against a baseline build of the same main commit without these changes.

Run	Before (pass / fail / skip)	After (pass / fail / skip)
System.Net.Http.Functional.Tests innerloop	768 / 0 / 23 (791 run)	768 / 0 / 23 (791 run)
OuterLoop HttpClientHandler_RemoteServerTest, SocketsHttpHandler_PostScenarioTest, SocketsHttpHandler_ResponseStreamTest	35 / 338 / 3	37 / 336 / 3

• No test regressed from pass to fail.
• SendAsync_SendSameRequestMultipleTimesDirectlyOnHandler_Success now passes (2 cases) because Content-Length is sent.
• The remaining outerloop failures are pre-existing on WASI: MD5 is unavailable, TLS to the dev-cert echo server fails, and the handler has unsupported features.
• On main, the shared HttpClientHandlerTest bodies don't run against this handler on WASI. They're exercised by a follow-up WASI-only WasiHttpHandler test project, where the request-content-failure, cancellation and response-stream tests pass with these changes.

Note

This PR description and the 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.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[lewing]

I have a full test standup for this that needs to stack on the socketshttphandler/websocket pr that demonstrated the need for this.

[lewing]

#136684 has the test support for WasiHttpHandler