Skip to content
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

Open
wants to merge 21 commits into
base: dev
Choose a base branch
from
Open

Conversation

Janek91
Copy link
Contributor

@Janek91 Janek91 commented Sep 17, 2024

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.

tmenier and others added 21 commits April 25, 2022 17:23
Flurl 3.0.5 & Flurl.Http 3.2.3
Flurl 3.0.6 & Flurl.Http 3.2.4 prereleases
Flurl 3.0.6 & Flurl.Http 3.2.4
Flurl 3.0.7 & Flurl.Http 4.0.0-pre3
Flurl.Http.Newtonsoft take 2 (better test coverage)
release action failed without a "previous" release. attempting fix
@tmenier
Copy link
Owner

tmenier commented Sep 17, 2024

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?

@Janek91
Copy link
Contributor Author

Janek91 commented Sep 18, 2024

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.
I tried to use FlurlBuilder.AddMiddleware() to pass there MyDelegateHandler, but FlurlBuilder.Build() replaces its inner native handlers with default ones from DefaultFlurlClientFactory.CreateInnerHandler() - besides that, they're not the native ones - and currently, there is no way to replace that factory implementation, as I did in ver. 3.x - what pretty much did the work at that time.
I can make an example project to demonstrate that if you want.

@tmenier
Copy link
Owner

tmenier commented Sep 18, 2024

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: AddMiddleware, ConfigureInnerHandler, and UseSocketsHttpHandler. With those covering all real-world scenarios I could think of, I couldn't see a need to provide your own handler, and I'm still not seeing it in your description.

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.

@Janek91
Copy link
Contributor Author

Janek91 commented Sep 19, 2024

Sure, I understand. Will try that approach and return to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants