Scope of disposal and cancelation

[breyed]

Does disposing a HttpClient object dispose any HttpResponseMessage objects (and their HttpContent objects) that it has created? Does HttpClient.CancelPendingRequests cancel HttpContent.ReadAsStringAsync on objects it has created? Does a cancellation token passed to HttpClient.SendAsync apply to HttpContent.ReadAsStringAsync?

In general, the scoping rules regarding disposal and cancelation need to be better documented. It would appear that there is at least some interconnection; otherwise, one would expect the async methods in HttpContent to take a cancellation token. But the docs don't say what the rules are.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 7ef78901-be85-0439-819b-39a792a34672
• Version Independent ID: 5505e40d-6767-b131-4b42-0b92634b6fa4
• Content: HttpMessageInvoker.Dispose Method (System.Net.Http)
• Content Source: xml/System.Net.Http/HttpMessageInvoker.xml
• Product: .net
• GitHub Login: @dotnet-bot
• Microsoft Alias: dotnetcontent

[breyed]

A related question regards the scope of HttpClient.Timeout: When it says that "the same timeout will apply for all requests using this HttpClient instance," does that apply only to calls like HttpClient.SendAsync, or also follow-up calls like HttpContent.ReadAsStringAsync?

[mairaw]

@davidsh can you help with this feedback? Any improvements we should do to those API docs?

[Trolldemorted]

Any chance we can get the question whether ReadAsStringAsync is cancelled when the HttpClient is disposed soon?

[davidsh]

A related question regards the scope of HttpClient.Timeout: When it says that "the same timeout will apply for all requests using this HttpClient instance," does that apply only to calls like HttpClient.SendAsync, or also follow-up calls like HttpContent.ReadAsStringAsync?

Does a cancellation token passed to HttpClient.SendAsync apply to HttpContent.ReadAsStringAsync?

HttpClient.Timeout only affects the HttpClient operations like GetAsync(), SendAsync(). It doesn't affect any subsequent operations that might be performed on the returned HttpResponseMessage. So, it doesn't affect HttpContent.ReadAs*Async operations.

The cancellation token passed to HttpClient methods like SendAsync() doesn't apply to other methods like HttpContent.ReadAs*Async. Those methods currently don't take any cancellation token parameters. But we are adding new APIs to HttpContent that will have a cancellation token argument. That work is planned for .NET 5.

[davidsh]

otherwise, one would expect the async methods in HttpContent to take a cancellation token.

See: https://github.com/dotnet/corefx/issues/32615

[davidsh]

Any chance we can get the question whether ReadAsStringAsync is cancelled when the HttpClient is disposed soon?

Disposing the HttpClient shouldn't affect a current HttpContent.ReadAs*Async operation.

[Trolldemorted]

Disposing the HttpClient shouldn't affect a current HttpContent.ReadAs*Async operation.

Is there any way to convince a HttpContent.ReadAs*Async operation to stop within the near future, or can they literally be stuck for ages if a content is big and a server is slow?

[davidsh]

Is there any way to convince a HttpContent.ReadAs*Async operation to stop within the near future, or can they literally be stuck for ages if a content is big and a server is slow?

Why are you calling HttpContent.ReadAs*Async() directly? When you call HttpClient.SendAsync() for example, the default behavior is to read all the response body and buffer it into memory. You can change that behavior by using HttpCompletionOptions enum and passing that into .SendAsync().

So, if you call HttpClient.SendAsync() with the default buffering behavior, you will have the benefit of "timeouts" either via the HttpClient.Timeout property or passing in a cancellation token into HttpClient.SendAsync().

[breyed]

@davidsh HttpCompletionOption.ResponseHeadersRead is there for a reason. It and HttpContent.ReadAs*Async() are needed any time that client benefits from access to partial data. Examples include progressive rendering or JPG images, web pages, or multi-part MIME messages. I have an application in which the server can send a an initial control message if it knows that a dependency will provide a delayed response; the client uses the control message to give the user a quick heads up that the system's OK but there may be a delay. In all these cases, if the user deletes the server connection, the transfer should be terminated.

[Trolldemorted]

Why are you calling HttpContent.ReadAs*Async() directly? When you call HttpClient.SendAsync() for example, the default behavior is to read all the response body and buffer it into memory. You can change that behavior by using HttpCompletionOptions enum and passing that into .SendAsync().

I do call HttpClient.SendAsync(), but how can I get the response if not with response.Content.ReadAsStringAsync()?

Since I don't specify HttpCompletionOptions, can I be certain that ReadAsStringAsync will never asynchronously await because everything has been received already, and thus passing a cancellation token to the SendAsync call is completely sufficient for my use-case?

For breyed's usecase, would you recommend using the HttpContent's Stream's ReadAsync family?