Flurl: PlatformNotSupportedException in Uno Platform app

Created on 14 Aug 2020  路  6Comments  路  Source: tmenier/Flurl

I just started an Uno Platform project using this library. I tested it on Android and UWP, it works just as expected. But on WASM, it completely breaks. Attempting to make a GET request to https://icanhazdadjoke.com/api with Accept: application/json fails with the following exception:

Flurl.Http.FlurlHttpException: Call failed. Property AutomaticDecompression is not supported. GET https://icanhazdadjoke.com ---> System.PlatformNotSupportedException: Property AutomaticDecompression is not supported.

This project is compatible with .NET Standard, UWP, and Xamarin, (and even works on the Android head) why doesn't this work on the WASM head?

3.0 bug

All 6 comments

Fixed with #480, but only for 3.0 which is still in prerelease. I think you have 2 options here:

  1. Upgrade to the latest prerelease. I've been telling people to consider these as stable and production-ready as any other release, but with caveat that there could be more breaking changes before the final release. You can learn more about 3.0 here.

  2. Create and register a custom factory. Something like this:

c# public class WasmHttpClientFactory : DefaultHttpClientFactory { public override HttpMessageHandler CreateMessageHandler() { var handler = base.CreateMessageHandler() as HttpClientHandler; httpClientHandler.AutomaticDecompression = DecompressionMethods.None; return handler; } }

Since you're just starting a new project, I'd really encourage you to take a look at 3.0. The final release isn't far off and it's where everything new is going. 2.x is "done".

I updated to 3.0.0-pre4, and now I get the following error:

Flurl.Http.FlurlHttpException: Call failed. Property UseCookies is not supported. GET https://icanhazdadjoke.com ---> System.PlatformNotSupportedException: Property UseCookies is not supported.

I suspect there will be more properties that don't work

Thanks for reporting. WASM-based platforms have been challenging to say the least. They technically implement .NET Standard but throw runtime exceptions for the parts they don't actually support, which keeps library devs like me guessing. :)

You can still get un-blocked with a custom factory that defines CreateMessageHandler, but just don't call the base implementation. In fact, it would be great if you could start with the default implementation and tweak/remove lines until you confirm it's working. That would help me ensure that the permanent fix will work.

Is there an ETA for when the changes from https://github.com/tmenier/Flurl/commit/fb92cee1b2dc7d17909c99658bc387a5c2ad2e66 appear on NuGet (at least as a prerelease)?

Hopefully this week. Getting very close.

Was this page helpful?
0 / 5 - 0 ratings