HttpClient on .net core3.0 and 5.0 with different responses

[jchhh912]

Hi there,
I see a few cases of the same error as mine in Issues, and I thought I should do something to give you more information to make changes to this issue.

Next I used the same code on two computers, using the company network and 4G network to test The following two links

PC [001]

OS Name: Windows, OS Version: 10.0.19042, RID: win10-x64
Macafee Version:

Pulse Secure Version:

PC[002] =>Restore factory mode

OS Name: Windows, OS Version: 10.0.18362, RID: win10-x64

Link1:https://sfapi-sbox.sf-express.com/std/service

Link2:https://demo.identityserver.io/.well-known/openid-configuration

1.Using the company network

PC [001]	link1	Link2
.netcore 3.1	OK	OK
.netcore 5.0	Exception	OK
Exception：A connection attempt failed because the connected party did not properly respond after a period of time,or established connection failed because connected host has failed to respond.

PC [002]	link1	Link2
.netcore 3.1	OK	OK
.netcore 5.0	OK	OK

2.Using the 4G network

PC [001]	link1	Link2
.netcore 3.1	OK	OK
.netcore 5.0	Exception	OK

PC [002]	link1	Link2
.netcore 3.1	OK	OK
.netcore 5.0	OK	OK

[dotnet-issue-labeler]

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.

[jchhh912]

Testing code:

using System;
using System.Net.Http;

namespace Demo.SDK5._0
{
    class Program
    { 
        static void Main(string[] args)
        {
            var client = new HttpClient();
            //var resp = client.GetAsync("https://sfapi-sbox.sf-express.com/std/service").Result;
            var resp = client.GetAsync("https://demo.identityserver.io/.well-known/openid-configuration").Result;
            Console.WriteLine(resp.Content.ReadAsStringAsync().Result);
            Console.ReadKey();
        }
    }
}

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Hi there,
I see a few cases of the same error as mine in Issues, and I thought I should do something to give you more information to make changes to this issue.

Next I used the same code on two computers, using the company network and 4G network to test The following two links

PC [001]

OS Name: Windows, OS Version: 10.0.19042, RID: win10-x64
Macafee Version:

Pulse Secure Version:

PC[002] =>Restore factory mode

OS Name: Windows, OS Version: 10.0.18362, RID: win10-x64

Link1:https://sfapi-sbox.sf-express.com/std/service

Link2:https://demo.identityserver.io/.well-known/openid-configuration

1.Using the company network

PC [001]	link1	Link2
.netcore 3.1	OK	OK
.netcore 5.0	Exception	OK
Exception：A connection attempt failed because the connected party did not properly respond after a period of time,or established connection failed because connected host has failed to respond.

PC [002]	link1	Link2
.netcore 3.1	OK	OK
.netcore 5.0	OK	OK

2.Using the 4G network

PC [001]	link1	Link2
.netcore 3.1	OK	OK
.netcore 5.0	Exception	OK

PC [002]	link1	Link2
.netcore 3.1	OK	OK
.netcore 5.0	OK	OK

Author:	jchhh912
Assignees:	-
Labels:	area-System.Net.Http, untriaged
Milestone:	-

[karelz]

@jchhh912 will you get the same exception if you use packet capture tool like Wireshark?

[karelz]

Triage: @antonfirsov thinks it may be IPv6 differences -- there is workaround he is going to post here.

[antonfirsov]

@jchhh912 this might be caused by issues with IPV6 and/or dual-stack socket support in your corpnet or the McAffee proxy. Since .NET 5.0, HttpClient is using dual-stack sockets by default. Can you check if the following workaround helps:

public HttpClient CreateWorkaroundClient()
{
    SocketsHttpHandler handler = new SocketsHttpHandler
    {
        ConnectCallback = IPv4ConnectAsync
    };
    return new HttpClient(handler);

    static async ValueTask<Stream> IPv4ConnectAsync(SocketsHttpConnectionContext context, CancellationToken cancellationToken)
    {
        // By default, we create dual-mode sockets:
        // Socket socket = new Socket(SocketType.Stream, ProtocolType.Tcp);

        Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
        socket.NoDelay = true;

        try
        {
            await socket.ConnectAsync(context.DnsEndPoint, cancellationToken).ConfigureAwait(false);
            return new NetworkStream(socket, ownsSocket: true);
        }
        catch
        {
            socket.Dispose();
            throw;
        }
    }
}

This overrides SocketsHttpHandler.ConnectCallback to enforce IPV4.

[jchhh912]

@jchhh912 this might be caused by issues with IPV6 and/or dual-stack socket support in your corpnet or the McAffee proxy. Since .NET 5.0, is using dual-stack sockets by default. Can you check if the following workaround helps:HttpClient

public HttpClient CreateWorkaroundClient()
{
    SocketsHttpHandler handler = new SocketsHttpHandler
    {
        ConnectCallback = IPv4ConnectAsync
    };
    return new HttpClient(handler);

    static async ValueTask<Stream> IPv4ConnectAsync(SocketsHttpConnectionContext context, CancellationToken cancellationToken)
    {
        // By default, we create dual-mode sockets:
        // Socket socket = new Socket(SocketType.Stream, ProtocolType.Tcp);

        Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
        socket.NoDelay = true;

        try
        {
            await socket.ConnectAsync(context.DnsEndPoint, cancellationToken).ConfigureAwait(false);
            return new NetworkStream(socket, ownsSocket: true);
        }
        catch
        {
            socket.Dispose();
            throw;
        }
    }
}

This overrides to enforce IPV4.SocketsHttpHandler.ConnectCallback

Thanks, this is useful and I was wondering if this would be fixed in 6.0?

[jchhh912]

@jchhh912 will you get the same exception if you use packet capture tool like Wireshark?

I'm sorry, but I can't use Wireshark due to my company's IT policy, but if there is another suitable method, I'd be happy to provide you with information.

[antonfirsov]

@jchhh912 I'm not familiar with the McAfee software mentioned, I don't know what does the log in the screenshot mean.

For us the most important question here is if the workaround code in #54807 (comment) changes anything while keeping your company software turned on.

[jchhh912]

@antonfirsov Yes, my application works fine after using it, but do I need to come back and change my code if my .net core version continues to be upgraded later？

[karelz]

We plan to implement this in .NET 6: #47583 ... as a workaround and escape route for environments where IPv6 does not work properly (like yours - likely caused by MacAfee SW).
If you need solution on .NET 5 or before .NET 6 ships, you should use the code workaround mentioned above.
Closing as resolved.

[antonfirsov]

@jchhh912 .NET uses IPv6 dual-stack sockets very extensively, switching to them in HttpClient was a natural step, we don't plan to revert it.

In our experience, IPv6 works 99.9% of the time, when not, it's typically a problem with IPv6 support within your IT infrastructure. We recommend to raise an issue against your IT department. If they can't resolve it for some reason, #47583 will provide an easy workaround (disabling IPv6 globally within your .NET app).