-
-
Notifications
You must be signed in to change notification settings - Fork 387
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
Native handlers support #839
base: dev
Are you sure you want to change the base?
Conversation
Flurl 3.0.5 & Flurl.Http 3.2.3
Flurl 3.0.6 & Flurl.Http 3.2.4 prereleases
Flurl.Http 3.2.4-pre2
Flurl 3.0.6 & Flurl.Http 3.2.4
Flurl.Http 4.0.0-pre1
Flurl.Http 4.0-pre2
Flurl 3.0.7 & Flurl.Http 4.0.0-pre3
4.0.0-pre4
Flurl.Http 4.0-pre5
Flurl.Http 4.0-pre6
Flurl.Http.Newtonsoft
Flurl.Http.Newtonsoft take 2 (better test coverage)
release action failed without a "previous" release. attempting fix
release action fix
Flurl.Http 4.0.0-pre7
Newtonsoft package updates
4.0 here we go!
4.0 official, take 2
sponsorship
Flurl.Http 4.0.2
To my knowledge there's no need for this. Flurl should just work on Xamarin/MAUI platforms because the HttpClient picks the platform-specific handler by default. What am I missing? |
I know that my case can be a bit custom, because additionally, to provide API calls retry feature I wrap these native handlers - configured with certpinning and so on - in MyDelegateHandler - inheriting from DelegateHandler, which executes Polly retry policy. |
Removing the ability to provide your own inner handler was an intentional design decision in 4.0. Flurl needs to tweak some things on that handler, such as disabling cookies and auto-redirects, which caused a lot of people headaches if they neglected to do the same on their provided handlers. This capability was replaced by a few new features: That said, if you really think you need to do this, you could leverage the FlurlClient constructor that takes an existing HttpClient. With that you can provide a new HttpClient that uses whatever handler you want. But without a valid use case, I'd rather not provide a more "first-class" way of directly supplying an inner handler, or I worry people will get into trouble with it like in 3.x. |
Sure, I understand. Will try that approach and return to you. |
Hi,
Since ver. 4 there is no longer way to pass custom HttmMessageHandler like the native ones from Xamarin or MAUI. I've created the possibility to do so. It's working now, but I'm open to modify it the way Flurl further progress is designed.