-
-
Notifications
You must be signed in to change notification settings - Fork 391
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IFlurlClientFactory to use string instead of Url key #610
Comments
I might consider something like this for a future major version, but for now I don't think it can be done without breaking some contracts. For example, I'm not sure how the static In the mean time, keep in mind the only time |
Thank you for your answer. The alternative solution you're talking about is more or less what I ended up doing and it worked for my use case! |
I was working with |
@CesarD I'm not certain I'm following the question, but it might help to look at the differences between |
@tmenier It would be nice to use a URL + some kind of custom key. I my case I have the same url and endpoints, but different headers and certificate files. So I created static foreach (var (headerKey, certificateFilePath) in CertificateFiles)
{
var certificate = new X509Certificate2(certificateFilePath, certificatePassword);
var flurlClient = new FlurlClient(Foo.Url)
.Configure(settings => settings.HttpClientFactory = new ApiHttpClientFactory(certificate));
Clients.TryAdd(headerKey, flurlClient);
} |
At long last I'm dusting off this issue and actually attempting to solve it. 😄 The idea to just use any arbitrary string as a key doesn't really address how Flurl then decides what key to use to look up a client. The current interface allows you to customize how this question is answered: "Given this URL, what client should I use?" What if we change the question to: "Given this HTTP request, what client should I use?" The request contains the URL, but also other information such as headers that might be useful. My plan for 4.0 is to change the current |
I did some experimenting per the above ideas and didn't like where things were going. It occurred to me that something along the lines of named clients is really all that's being asked for here (correct me if that's wrong). I'll consider something like this - I'd like to move Flurl closer to a model like IHttpClientFactory anyway since most people are familiar with it. |
Hi, Thanks for working on this issue, I think you're onto something. I feel like the example you shared is a good way to solve this, I am already using named options in other places of the applications so this would indeed be a familiar solution. |
Closing in favor of #770. Flurl is getting a BIG overhaul in this area and I encourage you weigh in there with any thoughts you may have. |
Hello,
I have been inheriting from
FlurlClientFactoryBase
for a while now, I have multiple clients returned by the factory depending on multipleBaseUrl
, each client uses its own user/password and way of authenticating.But, I am now facing a new challenge. I need to use two different couple user/password for the same client, everything else is going to be the same. So I was just thinking of creating two different clients, one configured for each couple user/password
APIClientUser1
andAPIClientUser2
. But since they share the sameBaseUrl
I can't really base my caching strategy on theBaseUrl
anymore. I wanted to use a simple string as a key or even a comboBaseUrl/Username
but it looks like the factory only wants the get method like thisGet(Url url)
Do you think that would make sense as a feature to be able to just put whatever you want as a key? Not necessarily based on the
BaseUrl
for your request? I would rather ask even if I realize I might need to create my own factory right now.Thank you!
The text was updated successfully, but these errors were encountered: