Runtime: HttpClient design and multiple proxies

[ghost]

Hi,

Many articles I have read recommend to only use one instance of HttpClient in an application but I am not sure how to use this class in the following scenario:

• Server App (ASP.NET Core)
• Heavy usage of HttpClient for outgoing requests (Http dependencies)
• A different proxy has to be used for each outgoing request (round robin proxy with thousands of entries)

Should I have one instance of HttpClient per proxy that will be used (meaning thousands of HttpClient-s allocated)? Or is it better in this scenario to use a different HttpClient instance for each request?

Thanks!

[stephentoub]

A different proxy has to be used for each outgoing request

Can you just create your own IWebProxy that handles round-robining which proxy it gives back, and set that as the Proxy on the HttpClientHandler?

[ghost]

Looks great, I will give it a try, thanks!

[ghost]

Is there a way with this approach to find out which proxy address has been used for a particular http request? The only context I have in GetProxy is the destination Uri, it can be subclassed but I am not a huge fan of this approach.

[stephentoub]

Is there a way with this approach to find out which proxy address has been used for a particular http request?

I don't understand the question. You would create your own IWebProxy implementation, and its GetProxy would be handed the Uri of the destination and it would decide what proxy Uri to hand back. It's in your implementation's control.

The only context I have

What other context are you looking for? Do you mean you want the history of what proxy Uri has been used for what destination Uri? That information is not tracked / stored by HttpClient, but your object can do so to whatever extent it wants.

[ghost]

I would like to know from an HttpResponseMessage which proxy Uri has been used by HttpClient to handle that request. I can track the Destination Uri => Proxy Uri relationship in my object and then use the response RequestMessage.RequestUri property but it will only work if the Uri object passed to GetProxy is the one in the RequestUri property.

[karelz]

@lkfr is there any reason for you to believe it is not the same value / same object?

[ghost]

No and it looks like it is the same object but I have no guarantee it will always work like this. In the future a different Uri object might be allocated internally by HttpClient for some reason and handed to GetProxy.

[stephentoub]

I can track the Destination Uri => Proxy Uri relationship in my object and then use the response RequestMessage.RequestUri property but it will only work if the Uri object passed to GetProxy is the one in the RequestUri property.

Why does it require object identity? Uri provides equality support via overriding Equals, GetHashCode, providing an operator== method, etc.

[ghost]

Requests with the same destination Uri value will not go through the same proxy so I need a way to distinguish them apart.

[stephentoub]

Requests with the same destination Uri value will not go through the same proxy so I need a way to distinguish them apart.

And you're trying to distinguish them by the actual Uri's object identity? Even if the implementation guaranteed that the object identity of the Uri passed in wasn't perturbed, how is that going to work when you don't own that object, e.g. in the case of a redirect?

Regardless, this interface isn't going to change. At this point I think this is more of a design question for your app and it'd be best to try a site like stackoverflow or elsewhere to discuss your implementation. I don't believe there's anything actionable here for corefx.

[ghost]

Which is why I thought it might be useful to be able to get more context in the IWebProxy implementation instead of just a Uri (like for instance an application-defined value passed upfront in the call to HttpClient). Nevermind ...

[karelz]

Seems to be answered.