Runtime: Remove CurlHandler fallback from HttpClientHandler

[stephentoub]

SocketsHttpHandler has progressed to the point where we shouldn't need the fallback behind HttpClientHandler, and having it significantly increases the size of System.Net.Http.dll on Unix, while also requiring System.Net.Http.Native.so/dylib, and impacting distribution with libcurl. We should remove the fallback and all associated code, and if any additional and impactful gaps are discovered, fix them in SocketsHttpHandler.

[eiriktsarpalis]

I'd be happy to take this on. Is it an immediate priority?

[stephentoub]

Thanks. No immediate rush. It'd be good to do it earlier rather than later in the .NET 5 cycle, though.

[scalablecory]

It has been useful in the past to ask people to disable SocketsHttpHandler to check behavior against one of these long-term "stable" platforms. What do you think of instead moving these classes to a NuGet package?

[davidsh]

What do you think of instead moving these classes to a NuGet package?

CurlHandler isn't even a public API in .NET Core. So, we would have to make it one via API review etc.

I think we should still remove it entirely from .NET Core as per this issue. But I think it might also be useful to move all of this code (managed and native helper library) to another repo and have a separate NuGet package. That could be a community supported thing perhaps. But I'm not sure it would still be under the http://github.com/dotnet ownership.

The key point here in this issue is to move this out of .NET Core since we don't want to support it anymore and we don't want the costs of having it in the binaries, repo.

[stephentoub]

I'm also not sure how long-term or stable CurlHandler is :smile: Certainly curl / libcurl themselves are, but we have a non-trivial amount of code layered on top that attempts to provide behavior akin to .NET Framework on top of libcurl, and so testing behavior via CurlHandler isn't always a good indication of what curl itself does... in general I personally found that just using curl from the command-line or writing a little C app that directly used libcurl's APIs was a better indication of how it behaved without all of our gunk on top of it.

[scalablecory]

That's reasonable :)

[karelz]

Triage: We would like to have it sooner rather than later. Testing adjustment will require some thought.

Good for ramp up - @aik-jahoda @ManickaP @alnikola

[ManickaP]

Switches turning on CurlHandler: SocketsHttpHandler

[tmds]

@stephentoub are there known things in .NET Core 3 that only work with the libcurl handler?

[stephentoub]

Not to my knowledge. If there are any found and they're important, we should augment SocketsHttpHandler accordingly.