Click here to Skip to main content
15,117,095 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
The questions is if the content is disposed properly in all scenarios?

FYI, httpClient is an instance injected using DI and AddHttpClient() in Startup.cs, the project is a regular REST API .NET 5.

I always use the 3th approach since HttpClient instance is supposed to dispose HttpContent when HttpClient is disposed.
But what about the other ways? Just out of curiosity how it works underneath.
Might 2nd scenario cause memory leaks?
Or maybe the 1st approach and use of using is not needed here since parent's disposal (httpclient) takes care of everything implicitly, anyway?

What do you think?

What I have tried:

1.
var json = JsonConvert.SerializeObject(myObj);
using var httpContent = new StringContent(json);
var response = await _httpClient.PostAsync("path", httpContent);


2.
var json = JsonConvert.SerializeObject(myObj);
var httpContent = new StringContent(json); //no using on StringContent
var response = await _httpClient.PostAsync("path", httpContent);


3.
var json = JsonConvert.SerializeObject(myObj);
var response = await _httpClient.PostAsync("path", new StringContent(json)); //one-liner
Posted
Updated 21-Sep-21 1:02am
v2
Comments
Richard Deeming 21-Sep-21 7:07am
   
Don't forget that HttpResponseMessage also implements IDisposable, so you should probably be disposing of that too.
using var response = await _httpClient.PostAsync(...);

IIRC, if you don't dispose of it, cacheable responses won't be cached. That shouldn't be an issue for POST requests, but it might bite you if you're expecting GET requests to be cached.
Member 14637786 21-Sep-21 7:40am
   
No, not really, I believe. HttpClientFactory in Core (or 5, whatever we call it) which is used simply as HttpClient injected through DI is managed by DI container which manages lifetimes of services. HttpClient is a bit of an exception since the practice is to keep it alive and shared between threads as long as possible. Using on var response seems like redundant code to me. Let's wait for other opinions.
Richard Deeming 21-Sep-21 7:48am
   
As I said, if you don't dispose of the response, cacheable responses will never be cached. And since you're worried about memory leaks, you really ought to be disposing everything you can when you've finished with it.

If you're using IHttpClientFactory, which is the recommended way to inject HttpClient instances via DI, you should be disposing of the HttpClient instance as well. It's the underlying HttpMessageHandler instance which needs to be cached, and the client factory library takes care of that for you.

Use IHttpClientFactory to implement resilient HTTP requests | Microsoft Docs[^]
Member 14637786 21-Sep-21 8:04am
   
The provided MSDN tells nothing to prove your theory?
When HttpClient instance is created using IHttpClientFactory, Dispose(bool disposing) method has _disposeHandler variable set to false, therefore "using" is redundant code which does nothing even if it calls Dispose method. I am not debating here IF it's worse or the same because I believe it simply doesn't matter but if it makes any profitable difference which I am closer to think it does not. I have found several articles that confirms it so far.
Chris Copeland 21-Sep-21 10:29am
   
I think this might be that troll user again.

"I am not debating here IF it's worse or the same because I believe it simply doesn't matter but if it makes any profitable difference which I am closer to think it does not. I have found several articles that confirms it so far."

If you've found several articles (and therefore done your homework already) why are you asking questions here? Are you purposefully just trying to catch people out and call them out?
Richard Deeming 21-Sep-21 11:33am
   
I don't think so. This account's been around for nearly two years, and hasn't posted any abusive comments. :)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900