HttpClient is not always a good alternative

HttpClient may be a great option for many scenarios but in a large multi-tenant application that communicates with many 3rd party API's it isn't really an option. I have tried to use it instead of WebRequest but ran into problems.

Using{ HttpClient } blocks caused our production servers to run out of ports quite fast. Turned out that it is not supposed to be disposed... But in that case it is not usable, we need to set the headers and have separate cookies for each and every customer connecting to different 3rd party API's in multiple threads.

I hope this is not an arm twister in order to promote micro service architecture with queues in stead of fast in-process synchronous communication. It's good for fallback when something goes down but immediate processing is much more user-friendly when possible.

If something gets deprecated there better first be a good replacement. Can't the flaws be fixed instead of deprecated?

---
#### Document Details

⚠ *Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.*

* ID: 2cef6c88-811c-4651-4e8f-87365a799dda
* Version Independent ID: 3d53a1d2-c6bf-7698-02ed-759679547f2b
* Content: [Breaking change: WebRequest, WebClient, and ServicePoint are obsolete - .NET](https://docs.microsoft.com/en-us/dotnet/core/compatibility/networking/6.0/webrequest-deprecated#feedback)
* Content Source: [docs/core/compatibility/networking/6.0/webrequest-deprecated.md](https://github.com/dotnet/docs/blob/main/docs/core/compatibility/networking/6.0/webrequest-deprecated.md)
* Product: **dotnet-fundamentals**
* GitHub Login: @gewarren
* Microsoft Alias: **gewarren**