You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
HttpClient difference 3.1 vs 5.0. Getting: connection was aborted #52287
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.
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.
@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.)
@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?
It is 100% repro on first request . With CreateWorkaroundClient() no exception, it helps.
publicstaticHttpClientCreateWorkaroundClient(){SocketsHttpHandlerhandler=newSocketsHttpHandler{ConnectCallback=IPv4ConnectAsync};returnnewHttpClient(handler);staticasyncValueTask<Stream>IPv4ConnectAsync(SocketsHttpConnectionContextcontext,CancellationTokencancellationToken){// By default, we create dual-mode sockets:// var socket = new Socket(SocketType.Stream, ProtocolType.Tcp);varsocket=newSocket(AddressFamily.InterNetwork,SocketType.Stream,ProtocolType.Tcp);socket.NoDelay=true;try{awaitsocket.ConnectAsync(context.DnsEndPoint,cancellationToken).ConfigureAwait(false);returnnewNetworkStream(socket,ownsSocket:true);}catch{socket.Dispose();throw;}}}
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)
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.
Activity
wfurt commentedon May 5, 2021
can you get packet captures with Wireshark? What is your OS?
mikhail-tin commentedon May 5, 2021
No, I have no chance to download and install something.
OS Name: Windows, OS Version: 10.0.19041, RID: win10-x64
antonfirsov commentedon May 5, 2021
@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
ConnectCallbackoverride changes anything: #44686 (comment) (Edit: fixed incorrect link.)karelz commentedon May 5, 2021
@mikhail-tin the code above creates
HttpClientper 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?
mikhail-tin commentedon May 5, 2021
It is 100% repro on first request . With CreateWorkaroundClient() no exception, it helps.
Thx
karelz commentedon May 5, 2021
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)
mikhail-tin commentedon May 5, 2021
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.
antonfirsov commentedon May 5, 2021
@mikhail-tin can you try disabling these one-by-one without the workaround code? That would be valuable info for us, I'd appreciate.
mikhail-tin commentedon May 5, 2021
I can't do that due corp policies. No ways..
karelz commentedon May 5, 2021
@mikhail-tin can you please at least tell us which firewall is used? ... we can then close the issue.
mikhail-tin commentedon May 5, 2021
@karelz, Kaspersky Endpoint Security for Windows
karelz commentedon May 5, 2021
Thanks!
Closing as resolved.
Expose a global switch to disable IPV6 (#55012)