Skip to content

HttpClient difference 3.1 vs 5.0. Getting: connection was aborted  #52287

Closed

Description

@mikhail-tin

Hi there,

I have found strange behavior when moved from 3.1 to 5.0.
The same request in the same environment produces a different result.

Runtime: 3.1 - OK
Runtime 5.0.4 - Exception:
An error occurred while sending the request. -> Unable to read data from the transport connection -> An established connection was aborted by the software in your host machine.

Code:
program.cs

namespace WebApplication
{
    public class Program
    {
        public static void Main(string[] args) =>
            Host.CreateDefaultBuilder(args).ConfigureWebHostDefaults(wb => { wb.UseStartup<Startup>(); }).Build().Run();
    }

    public class Startup
    {
        public void ConfigureServices(IServiceCollection services){}

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            app.UseRouting();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapGet("/", async context =>
                {
                    try
                    {
                        var client = new HttpClient();
                        var resp = await client.GetAsync("https://demo.identityserver.io/.well-known/openid-configuration");
                        await context.Response.WriteAsync(Environment.Version.ToString() + ": " + resp.StatusCode);
                    }
                    catch (Exception ex)
                    {
                        await context.Response.WriteAsync(Environment.Version.ToString() + ": " + ex.Message);
                    }
                });
            });
        }
    }
}

WebApplication.csproj

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
	<!--<TargetFramework>netcoreapp3.1</TargetFramework>-->
  </PropertyGroup>
</Project>

What could be a reason of this behavior on the same machine(just flip TargetFramework)?
Also I have tried on another machine and both runtime works fine and no exception.

OS: Win 10

Thx!

Activity

  1. ghost added
    untriagedNew issue has not been triaged by the area owner
    on May 5, 2021
  2. wfurt commented on May 5, 2021

    @wfurt
    Member

    can you get packet captures with Wireshark? What is your OS?

  3. mikhail-tin commented on May 5, 2021

    @mikhail-tin
    Author

    can you get packet captures with Wireshark? What is your OS?

    No, I have no chance to download and install something.
    OS Name: Windows, OS Version: 10.0.19041, RID: win10-x64

  4. antonfirsov commented on May 5, 2021

    @antonfirsov
    Contributor

    @mikhail-tin is this a consistent or an intermittent error? AFAIK the only socket-level change between 3.1 and 5.0 is our switch to dual-mode sockets. Can you check if this ConnectCallback override changes anything: #44686 (comment) (Edit: fixed incorrect link.)

  5. karelz commented on May 5, 2021

    @karelz
    Member

    @mikhail-tin the code above creates HttpClient per request -- that is not a healthy practice, that may easily lead to other problems. Are you able to reproduce the same problem from a console app? (demonstrating 3.1 works and 5.0 does not)
    Same question as above -- is it 100% repro on first request, or is it intermittent?

  6. mikhail-tin commented on May 5, 2021

    @mikhail-tin
    Author

    It is 100% repro on first request . With CreateWorkaroundClient() no exception, it helps.

    public static 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:
                    // var socket = new Socket(SocketType.Stream, ProtocolType.Tcp);
    
                    var 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;
                    }
                }
            }

    Thx

  7. karelz commented on May 5, 2021

    @karelz
    Member

    OK, looks like another +1 on DualSockets causing problems ... what is your environment? Is it enterprise setup with some specific firewall? (just out of curiosity)

  8. mikhail-tin commented on May 5, 2021

    @mikhail-tin
    Author

    OK, looks like another +1 on DualSockets causing problems ... what is your environment? Is it enterprise setup with some specific firewall? (just out of curiosity)

    No, I have faced it on my machine for development( with firewall, antivirus and proxy).
    I assume we could close the issue as resolved. looks like the reason is firewall or something.

    Thx a lot.

  9. antonfirsov commented on May 5, 2021

    @antonfirsov
    Contributor

    with firewall, antivirus and proxy

    @mikhail-tin can you try disabling these one-by-one without the workaround code? That would be valuable info for us, I'd appreciate.

  10. mikhail-tin commented on May 5, 2021

    @mikhail-tin
    Author

    with firewall, antivirus and proxy

    @mikhail-tin can you try disabling these one-by-one without the workaround code? That would be valuable info for us, I'd appreciate.

    I can't do that due corp policies. No ways..

  11. karelz commented on May 5, 2021

    @karelz
    Member

    @mikhail-tin can you please at least tell us which firewall is used? ... we can then close the issue.

  12. mikhail-tin commented on May 5, 2021

    @mikhail-tin
    Author

    @karelz, Kaspersky Endpoint Security for Windows

  13. karelz commented on May 5, 2021

    @karelz
    Member

    Thanks!

    Closing as resolved.

  14. added this to the 6.0.0 milestone on May 20, 2021
  15. ghost locked as resolved and limited conversation to collaborators on Jun 19, 2021
  16. added a commit that references this issue on Jul 12, 2021
    067aa16
  17. removed
    untriagedNew issue has not been triaged by the area owner
    on Oct 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions