[Question] HttpClientHandler, SocketsHttpHandler for a .NET Core 3.1 app

[dgkanatsios]

We have a .NET Core 3.1 app that we're using HttpClient to connect to a web server. The HttpClient instance is constructed via a HttpClientHandler instance we are creating.

From what I understand reading this, in >=2.1 the HttpClientHandler was rewritten to use SocketsHttpHandler.
Still, this page seems to recommend SocketsHttpHandler.

Can you clarify on what's the optimal solution? FWIW, we don't need the older HTTP stacks.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

[stephentoub]

From what I understand reading this, in >=2.1 the HttpClientHandler was rewritten to use SocketsHttpHandler.

Correct.

Still, this page seems to recommend SocketsHttpHandler.

In 3.1, there are actually two implementations behind HttpClientHandler: SocketsHttpHandler, and then as a fallback an OS-specific handler. That page is really just saying that SocketsHttpHandler is the default implementation, but you can opt-out to the fallback if necessary.

Can you clarify on what's the optimal solution? FWIW, we don't need the older HTTP stacks.

Using HttpClientHandler is totally fine, using SocketsHttpHandler as an implementation. If you want access to additional knobs and configuration exposed via properties on SocketsHttpHandler, you can construct it directly.

[dgkanatsios]

thanks @stephentoub for the ultra fast response!