iOS/tvOS/MacCatalyst: some HttpClientHandler properties behave differently now

[rolfbjarne]

Description

I'm not sure if this is a bug or expected behavior now, but I'm filing this issue to track whatever it is.

This happens on iOS, tvOS or Mac Catalyst (not macOS).

1. The three Supports* properties all return false now, they used to return true. The corresponding supported properties throw PlatformNotSupportedException (which I guess is understandable if they're not supported).
2. Setting ServerCertificateValidationCallback throws a PNSE. This used to work.
3. CookieContainer returns null.

Regression?

Yes, it happened sometime between 6.0.100-preview.7.21330.1 and 6.0.100-rc.1.21369.3 (it's also a breaking change from legacy Xamarin).

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[rolfbjarne]

CC @steveisok @spouliot

[steveisok]

@rolfbjarne What we are doing with HttpClientHandler in iOS is mapping the properties that are implemented in NSUrlSessionHandler and the ones that aren't will throw PNSE. The reason why this is different in P7 is that the properties reflected what was supported in SocketsHttpHandler.

1. The three Supports* properties all return false now, they used to return true. The corresponding supported properties throw PlatformNotSupportedException (which I guess is understandable if they're not supported).

I don't think any of these features the three properties reference are supported by NSUrlSessionHandler. If that's not the case, please let me know.

2. Setting ServerCertificateValidationCallback throws a PNSE. This used to work.

Was the callback actually invoked from the handler?

3. CookieContainer returns null.

We're deferring to the native handler for any defaults. You'll need to initialize them in your handler.

[rolfbjarne]

OK, I think I was confused, and hopefully I've figured things out now.

In legacy Xamarin, we can select at build time which handler is the default for HttpClient (be it NSUrlSessionHandler, HttpClientHandler or CFNetworkHandler). So the build time option affects how "new HttpClient ()" behaves.

In .NET, we can select at build time which implementation HttpClientHandler should use (be it SocketsHttpHandler or NSUrlSessionHandler). So the build time option affects how "new HttpClientHandler ()" behaves (and thus indirectly how "new HttpClient ()" behaves as well).

In our tests we were doing "new HttpClientHandler ()", and assuming that that would get us a specific implementation. In .NET that's not true anymore, it depends on a build-time option.

The end result is that we'll have to update our tests, and afaik there's nothing to do here.

[rolfbjarne]

@steveisok

Reopening again, because I'm not sure I understand the rationale here:

@rolfbjarne What we are doing with HttpClientHandler in iOS is mapping the properties that are implemented in NSUrlSessionHandler and the ones that aren't will throw PNSE. The reason why this is different in P7 is that the properties reflected what was supported in SocketsHttpHandler.

This means that if you disable the native handler (set UseNativeHttpHandler=false), you'll use SocketsHttpHandler, except for the properties that aren't supported in NSUrlSessionHandler, which will throw PNSE.

Shouldn't those properties instead do whatever the underlying handler does, instead of assuming that if they aren't supported in NSUrlSessionHandler, they won't be supported in SocketsHttpHandler either?

[steveisok]

Good point. We thought to do PNSE mostly because NSUrlSessionHandler does not have most of the properties that you find in HttpClientHandler. If we stop throwing PNSE in runtime , what that means is NSUrlSessionHandler will need to add all of the HttpClientHandler properties. Otherwise, you'll get a rather uninformative reflection exception.