Following best-practices for HttpClient

[samcic]

In the latest version of this library, creating a StripeClient with the minimal constructor creates a new SystemNetHttpClient, which in turn creates a new HttpClient.

In some cases, multiple StripeClients need to be created in an application (e.g. when dealing with multiple Stripe accounts, each with a different API key).

The "best practices" for HttpClient instances are mentioned by Microsoft as follows:

HttpClient is intended to be instantiated once and reused throughout the life of an application.

My questions:

• Why isn't SystemNetHttpClient using a static, application-wide HttpClient instance?
• When passing a custom SystemNetHttpClient instance to StripeClient, is there any danger in using a static, application-wide HttpClient instance?

[clement911]

Or another option might be to use the new HttpClientFactory:

https://docs.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/use-httpclientfactory-to-implement-resilient-http-requests

[ob-stripe]

Hi @samcic, thanks for the report. It seems like when we (I) refactored the HTTP layer of stripe-dotnet in v27.0.0, I mistakenly made it non-static. This was an oversight, but should be easy to fix. In the meantime, you can manually pass a static instance that you created yourself to SystemNetHttpClient to prevent it from creating a new instance.

@clement911 While HttpClientFactory is great, stripe-dotnet still needs to support .NET Framework 4.5 for the foreseeable future, so unfortunately it is not available to us. Thanks for the suggestion though!

[samcic]

Thanks @ob-stripe , we'll update our integration to manually pass a static instance to SystemNetHttpClient as you suggested.

[ob-stripe]

This is fixed in v34.20.1. SystemNetHttpClient instances will now use a shared static instance of HttpClient when no client is passed to the constructor.

[clement911]

Great!
It's really amazing to see how responsive you are to fixing issue 👏 👏 .

[ob-stripe]

Thanks for the kind words :)

[Simonl9l]

While HttpClientFactory is great, stripe-dotnet still needs to support .NET Framework 4.5 for the foreseeable future, so unfortunately it is not available to us. Thanks for the suggestion though!

Just to say .Net 5 is just around the corner...no more .Net Framework to support...would be good to have native HttpClientFactory support...

[Simonl9l]

@ob-stripe Just following on this ? What are Stripe's plans for native Support with HttpClientFactory for DotNet 5.0?

[ob-stripe]

@Simonl9l The next major version of stripe-dotnet will drop support for .NET Framework 4.5, so in theory we should now be able to use HttpClientFactory. That said, I no longer actively work on stripe-dotnet myself -- cc @richardm-stripe to put this on your radar.

[Simonl9l]

@ob-stripe thanks just saw this...been a while, @ransford-stripe any word?

[dancooktoptal]

Hi, any news on .NET Core support, ideally 3.1 (LTS)?

[Simonl9l]

@richardm-stripe (or have you moved on too @ob-stripe) its been another 18 months... not is .Net Framework 4.5 deprecated yet such that HttpClientFactory can be supported...? .Net 6 (rolling on .net 7) obvs now being the suggested target...