SocketsHttpHandler: Timeout from ConnectTimeout should use timeout exception pattern #47484
Comments
dotnet-issue-labeler
bot
added
area-System.Net
untriaged
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsDescriptionInconsistent behavior of Socket class on different platforms doesn't allow to use a new timeout handling mechanism in .NET 5.0 as described in this blog post. Here is the repro code: static async Task Main()
{
using var client = new HttpClient(new SocketsHttpHandler { ConnectTimeout = TimeSpan.FromMilliseconds(100) }, true)
{
BaseAddress = new Uri("http://localhost:3262")
};
using var cts = new CancellationTokenSource();
cts.CancelAfter(200);
var response = await client.SendAsync(new HttpRequestMessage { Method = HttpMethod.Get }, cts.Token);
Console.WriteLine(response);
}Assume that nothing is hosted on Exception type is Now let's try to launch this code on Linux: Exception type is ConfigurationChecked on .NET 5.0.102 Regression?N/A Other informationRelated: #34474
|
|
UPD: The same behavior observed when real address is used instead of |
|
From the trace it seems like there is nothing listening on the port. Socket error would be propagated up if it happens before timeout. You can use Wireshark and look at what is happening at the network. |
Correct, but why the exception is different on various platforms? |
|
From my point of view, such behavior increases complexity of code for handling errors produced by try
{
await client.SendAsync(...);
}
catch (HttpRequestException e)
{
// handle HTTP-related exceptions such as unexpected error code
// OR
// handle refused connection on Linux
}
catch (OperationCanceledException e) when (!token.IsCancellationRequested)
{
// handle refused connection on Windows
}
catch (OperationCanceledException e) when (e.InnerException is TimeoutException)
{
// handle timeout on all platforms
} |
|
It depends on system you are connecting to. I get something very similar exception even on Windows if you connect to Linux host with closed port: The difference is that in some cases you get RST (or ICMP unreachable) and in some cases it just times out of there is no response. So the inconsistence is on the server, not on the client IMHO. |
|
In both cases I tried to connect to the same Linux host in my home network. I think it's valid to expect the same behavior on various platforms. But the exception type depends on client platform, not server.
In this case it would be great to see |
|
If you make the BTW, the |
|
@ManickaP , I tried to omit custom cancellation token but result is the same. Increasing connection timeout doesn't change the picture, exception still different on various platforms. Also, I checked I'm trying to say that the pattern catch (OperationCanceledException e) when (!token.IsCancellationRequested)cannot be fully replaced with catch (OperationCanceledException e) when (e.InnerException is TimeoutException)Moreover, this replacement is unreliable and dangerous. Another main concern that exception type varies depends on the platform. |
|
Triage: The Linux behavior is by design -- Socket fails on Linux, reporting inability early. On Windows (and also on Linux) we should have It should be fairly straightforward to do - use same pattern we have for the implemented |
karelz
added
bug
help wanted
I met this problem too, and I've done this before I saw this issue. My tests failed on GitHub(ubuntu) env but pass in Windows with HttpRequestException in .net 5.0. And, yes, as it is a frequency component that it should be the same pattern (exception) in the different platforms or it makes ppl confused. |
geoffkizer
changed the title
ghost
added
the
in-pr
ghost
removed
the
in-pr
ghost
locked as resolved and limited conversation to collaborators
Description
Inconsistent behavior of Socket class on different platforms doesn't allow to use a new timeout handling mechanism in .NET 5.0 as described in this blog post.
Here is the repro code:
Assume that nothing is hosted on
http://localhost:3262address. On Windows, I have the following exception:Exception type is
TaskCanceledExceptionwithInnerExceptionequals to null instead ofTimeoutExceptionas described in the blog post.Now let's try to launch this code on Linux:
Exception type is
HttpRequestExceptionwithInnerExceptionequals toSocketException.Configuration
Checked on .NET 5.0.102
Linux Ubuntu 20.04.1 LTS x86_64
Windows 10 Enterprise x86_64
Regression?
N/A
Other information
Related: #34474
The text was updated successfully, but these errors were encountered: