Migration to IHttpClientFactory or allow devs to manage their own HttpClient?

[sm-cdecker]

As detailed in this Microsoft article they suggest you stop creating your own instances of the HttpClient class. Instead they want you to use IHttpClientFactory which handles the lifetime of the instance for you.

Are there any plans to change HttpService to use IHttpClientFactory? If not, is there a way I can pass in an instance of HttpClient myself so I can use my own instance of IHttpClientFactory?

[sm-cdecker]

I think if you make HttpService.GetHttpResponse() and HttpService.GetHttpResponseAsync(), it should enable people to use IHttpClientFactory

[hollabaq86]

👋 @sm-cdecker thanks for sharing this new article! Socket exhaustion was an issue in older versions of the SDKs, and the most current major version is using a static client by default as a result of that work. If Microsoft folks have released new recommendations, we'll definitely take that into consideration for future updates.

I don't have an ETA on when these changes would be made, or what we think is the best way to move forward with these recommendations. Any thoughts or feedback are welcome from the .NET community, just keep in mind that we have a balancing act in supporting whatever versions of .NET Framework and Core are still receiving security updates from core devs.

[hollabaq86]

for internal notekeeping, ticket 1616

[pikos-apikos]

I also like this idea, I would suggest you replace Configuration.WebProxy with Configuration.HttpClient

[caviyacht]

Is this ever going to be resolved? It's 2024 now and not being able to manage this ourselves is irritating.

[sm-cdecker]

FWIW I didn't even bother with this library. It was easier to just implement their GraphQL API and manage the client connections myself.
Though the graphQL stuff was a bit challenging to manage in C#.