Using SocketsHttpHandler and NSUrlSessionHandler in the same net8.0-ios project causes incorrect 401 runtime errors for NTLM authorized HTTP requests

[rolfbjarne]

From @JeroenBer on Fri, 15 Mar 2024 15:17:31 GMT

We ported our Xamarin iOS application to .NET 8 (net8.0-ios). We use SocketsHttpHandler and NSUrlSessionHandler in the same project. We use SocketsHttpHandler for NTLM requests and NSUrlSessionHandler for other requests.

Ntlm SocketsHttpHandler can do HTTP requests with NTLM authorization. But if you also use NSUrlSessionHandler and once you hit a 401 in NSUrlSessionHandler it seems this has the nasty side effect that NTLM authorization in SocketsHttpHandler is broken.

Steps to Reproduce

1. Do a NTLM authorized HTTP Requests with SocketsHttpHandler (Succes)
2. Do a NSUrlSessionHandler request which returns a 401
3. Do the same request as in step 1 and now it will also start failing with a 401. This is not correct, it should still work.

Expected Behavior

SocketHttpHandler requests should not be influenced by NSUrlSessionHandler requests

Actual Behavior

401 on NSUrlSessionHandler causes NTLM to fail on SocketHttpHandler

Environment

Environment is Microsoft.iOS.Sdk/17.2.8022

Example Project (If Possible)

1. Clone project https://github.com/JeroenBer/TestHttpClientHandlers
2. Run "HttpMessageHandlerTests.iOS" project in Debug mode
3. Click on button "NTLM Test"
4. This will run the code in NtlmTest.cs

You can see this code unexpectedly fails now:

    public static async Task<string> RunTest()
    {
        await SocketsHttpRequest();
        await SocketsHttpRequest();
        await SocketsHttpRequest();

        // force a 401 request with NSUrlSessionHandler
        await NsUrlSessionHandler401Request();
        
        // This http request now unexpectedly fails!!!
        await SocketsHttpRequest();
        return "OK";
    }

Copied from original issue xamarin/xamarin-macios#20311

[rolfbjarne]

From @rolfbjarne on Mon, 18 Mar 2024 10:07:54 GMT

I can reproduce.

This seems to be an issue in SocketsHttpHandler; nothing NSUrlSessionHandler does should affect how SocketsHttpHandler works, so I'm moving to dotnet/runtime (where the implementation of SocketsHttpHandler lives).

[wfurt]

I'm wondering if this is related to #97966. Maybe not crashing (without GC.Collect) but the macOS GASSI mangles memory. Adding @filipnavara for more thoughts.

[filipnavara]

We can test what happens with the Managed NTLM switch (or run on .NET 9 preview) to avoid the GSSAPI code paths that corrupt memory. Otherwise I don't have many ideas, NSUrlSessionHandler doesn't even use GSSAPI (at least for NTLM; don't remember about Kerberos/Negotiate).

[wfurt]

We can test what happens with the Managed NTLM switch (or run on .NET 9 preview) to avoid the GSSAPI code paths

is that something you can try @rolfbjarne since you already have repro?

[filipnavara]

is that something you can try @rolfbjarne since you already have repro?

Just to save some time. It means adding this to the .csproj file:

<ItemGroup>
  <RuntimeHostConfigurationOption Include="System.Net.Security.UseManagedNtlm" Value="true" />
</ItemGroup>

[rolfbjarne]

is that something you can try @rolfbjarne since you already have repro?

Just to save some time. It means adding this to the .csproj file:

<ItemGroup>
  <RuntimeHostConfigurationOption Include="System.Net.Security.UseManagedNtlm" Value="true" />
</ItemGroup>

Yes, that seems to work.

[antonfirsov]

@rolfbjarne can we close this as duplicate of #97966, or is there something else we could do?

[rolfbjarne]

@rolfbjarne can we close this as duplicate of #97966, or is there something else we could do?

CC @JeroenBer (the original reporter)

[dotnet-policy-service]

This issue has been marked needs-author-action and may be missing some important information.

[dotnet-policy-service]

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.