Request scoped HttpClient lifetime issues with proxy and cookies

[dv00d00]

I have a feeling that the issue I am going to describe is touching several areas, and the way the need is formed in the title is probably due to the current active API surface of HttpClient + HttpClientHandler

Let's imagine I want to make an http request from my API to some 3rd party site. One call to my API produces n request for downstream 3rd party.

The whole communication scheme looks like this:

1. Http request to my API
2. Determine downstream and request details from incoming request.
3. Create an instance of HttpClient/Handler

• It should have its isolated cookie container (initialized on Handler)
• It should have randomly chosen web proxy [of N possible proxies] (initialized on Handler)

4. Make 3-5 requests to downstream using same proxy and cookie container.

The problem: how to pool http client handlers efficiently in this scenario is unclear to me.

The best I have come up with is

1. Register a named client per possible proxy
2. Create a request scoped delegating handler that will somehow access underlying Sockets handler and will call this awful cookie cleanup code

foreach (Cookie allCookie in socketsHttpHandler.CookieContainer.GetAllCookies())
            {
                allCookie.Expired = true;
            }

because there is no other way to reset a cookie collection on a used http client handler in a clear way I can find

Can anyone suggest a cleaner way to do this?
Why there is such a strict restriction in regards of changing properties on handler in the first place?
It feels like the set of options is just a specification on how to build underlying stack which will actually hit tcp socket

[LeaFrock]

Oh my dear Comrade 'Stalin', the similar question to yours has been raised by me since 2019. But it's still in discussion.

The related issue is #35992 & #77668 .