Fix HTTP streaming Abort() not canceling response reception and add unit tests

[Copilot]

Fixes the issue where calling Abort() on HTTP-based WCF channels doesn't cancel in-progress stream reads after HttpClient.SendAsync returns. The abort signal now properly propagates to the response body reader.

Problem

HTTP-based transports don't abort an in-progress request if the reply has already started. After HttpClient.SendAsync returns an HttpResponseMessage, calling Abort() on the WCF channel doesn't propagate to the code receiving the response body, causing stream reads to hang until timeout.

Solution

The fix follows the exact same pattern already used for the send phase in SendRequestAsync:

Modified HttpResponseMessageHelper:

• Changed to accept CancellationTokenSource httpSendCts parameter instead of CancellationToken
• Added s_cancelCts static callback (same pattern as in HttpChannelFactory)
• In ParseIncomingResponse, registers the timeout token callback using timeoutToken.UnsafeRegister(s_cancelCts, _httpSendCts)
• This allows the timeout token to cancel _httpSendCts
• All stream reading operations use _httpSendCts.Token
• Updated all stream reading operations:
  • GetStreamAsync()
  • ReadChunkedBufferedMessageAsync()
  • ReadBufferedMessageAsync()
  • DecodeBufferedMessageAsync()

Modified HttpClientChannelAsyncRequest.ReceiveReplyAsync():

• Now passes _httpSendCts (the CancellationTokenSource) to HttpResponseMessageHelper constructor
• When Abort() is called, _httpSendCts is cancelled via the existing Cleanup() method
• When timeout expires, the registered callback also cancels _httpSendCts
• Both abort and timeout can now cancel ongoing stream read operations

Pattern used (matching SendRequestAsync):

var timeoutToken = await timeoutHelper.GetCancellationTokenAsync();
using (timeoutToken.UnsafeRegister(s_cancelCts, _httpSendCts))
{
    // All stream operations use _httpSendCts.Token
    // Both timeout and abort can cancel _httpSendCts
}

No linked CancellationTokenSource is created, avoiding resource management issues.

Test Implementation

• Created: HttpStreamingAbortTests.4.1.0.cs with sync and async variants
• Approach: Uses CustomBinding with TransferMode.StreamedResponse, reads partial data (1KB from 500KB stream), calls Abort(), then attempts continued reading
• Validation: If abort works, throws CommunicationObjectAbortedException, IOException, CommunicationException, or OperationCanceledException. If broken, hangs until ReceiveTimeout expires.

// Start streaming response
responseStream = serviceProxy.GetStreamFromString(largeData);
byte[] buffer = new byte[1024];
int bytesRead = responseStream.Read(buffer, 0, buffer.Length);

// Abort while receiving
((ICommunicationObject)serviceProxy).Abort();

// Should throw exception, not hang
responseStream.Read(buffer, 0, buffer.Length); 

Tests use existing CustomTextEncoderStreamed endpoint. Both synchronous and async patterns covered.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>HTTP based transports don't abort an in progress request if the reply has already started</issue_title>
<issue_description>If you are using an Http based binding, and you call Abort() on the client channel proxy after the call to HttpClient.SendAsync has returned an HttpResponseMessage, it doesn't propagate aborting of the WCF channel to the code that's receiving the response body. This means if the response body is being read, and something happens where the server stops responding, calling Abort() on the channel doesn't cancel the ReadAsync call on the response stream.

Relying on the binding SendTimeout or the channel OperationTimeout still works as we create a CancellationToken based on the remaining time left in the operation and that will be honored.

Calling Abort() while the request is being sent does get honored as the cancellation token we create for timing out calling HttpClient.SendAsync isn't directly passed, but instead a callback is registered against it which cancels the request wide CancellationTokenSource, the CancellationToken for which is then passed to the SendAsync call. That code looks similar to this:

var timeoutToken = await _timeoutHelper.GetCancellationTokenAsync();

using (timeoutToken.UnsafeRegister(s_cancelCts, _httpSendCts))
{
    _httpResponseMessage = await _httpClient.SendAsync(httpRequestMessage, HttpCompletionOption.ResponseHeadersRead, _httpSendCts.Token);
}

The callback s_cancelCts will cancel _httpSendCts. The CancellationTokenSource _httpSendCts gets cancelled when Abort is called on the request, so this pattern enables cancelling the call when the timeout hits, or when Abort() is manually called. This code is in System.ServiceModel.Channels.HttpChannelFactory<TChannel>.HttpClientRequestChannel.HttpClientChannelAsyncRequest which is in the file src\System.ServiceModel.Http\src\System\ServiceModel\Channels\HttpChannelFactory.cs

In the ReceiveReplyAsync method, a timeoutHelper is being created and passed along to a helper class/method HttpResponseMessageHelper.ParseIncomingResponse. This needs to be checked/validated, but I believe we could use the same registering of the callback with the CancellationToken from the TimeoutHelper, and pass _httpSendCts.Token to HttpResponseMessageHelper.ParseIncomingResponse instead. The potential things which could cause a problem are if the remaining or original timeout need to be retrieved from the TimeoutHelper in a transitive call inside ParseIncomingResponse, e.g. for formatting a string used in an exception message.</issue_description>

<agent_instructions>Write a unit test to validate the fix. We might already have a test service endpoint which purposefully delays the response to test for these types of scenarios. The test service would need to be using either TransferMode.StreamedResponse or TransferMode.Streamed and would return a Stream for the operation which has a delay in completing the response. That way we can be sure the client is in the receiving code when calling Abort(). Set up the test so that if Abort() doesn't work, the client call will have a TimeoutException thrown, but if the Abort() does work, a different exception gets thrown. I'm not sure which exception that would be, but I think it would be CommunicationObjectAbortedException.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes HTTP based transports don't abort an in progress request if the reply has already started #5885

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[mconnew]

@copilot, you didn't make any changes to address the problem described in the issue. You only wrote the test that was described in the additional instructions.

[Copilot]

@copilot, you didn't make any changes to address the problem described in the issue. You only wrote the test that was described in the additional instructions.

You're absolutely right - I misunderstood the original instructions. I only created the unit test but didn't implement the actual fix for the issue. I'm now implementing the fix to propagate Abort() to the response stream reading operations.

[mconnew]

@copilot, don't create a linked cancellation token source. Do something more like this:

var timeoutToken = await _timeoutHelper.GetCancellationTokenAsync();

using (timeoutToken.UnsafeRegister(s_cancelCts, _httpSendCts))
{
    _httpResponseMessage = await _httpClient.SendAsync(httpRequestMessage, HttpCompletionOption.ResponseHeadersRead, _httpSendCts.Token);
}

There's no need to create a linked token as we have a callback which will cancel _httpSendCts which can be registered against a new CancellationToken.

[Copilot]

@copilot, don't create a linked cancellation token source. Do something more like this:

var timeoutToken = await _timeoutHelper.GetCancellationTokenAsync();

...

Refactored to use the UnsafeRegister pattern as suggested. Changed HttpResponseMessageHelper to accept CancellationTokenSource instead of CancellationToken, and register the timeout token callback in ParseIncomingResponse using timeoutToken.UnsafeRegister(s_cancelCts, _httpSendCts). This matches the pattern in SendRequestAsync and avoids creating a linked CancellationTokenSource. (commit a19fad8)