Native handlers support
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.
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. 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.
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.
Sure, I understand. Will try that approach and return to you.