Detect name resolution errors in QuicConnection.ConnectAsync

[antonfirsov]

Edit: see #89095 (comment).

---

https://github.com/dotnet/runtime/pull/88974/files#r1265843373 needs a follow-up:
https://github.com/antonfirsov/runtime/blob/b54e8c72cb63de3549ae4bff268d88daa628404c/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/ConnectHelper.cs#L146

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

Issue Details

---

https://github.com/dotnet/runtime/pull/88974/files#r1265843373 needs a follow-up:

https://github.com/antonfirsov/runtime/blob/b54e8c72cb63de3549ae4bff268d88daa628404c/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/ConnectHelper.cs#L146

Author:	antonfirsov
Assignees:	antonfirsov
Labels:	area-System.Net.Http
Milestone:	8.0.0

[antonfirsov]

Thinking that QuicException.TransportErrorCode would help identifying relevant error cases was a wrong assumption.

The actual problem here, similarly to #89096 is that we can't detect NameResolutionError. If QuicClientConnectionOptions.ClientAuthenticationOptions.TargetHost is different than the actual host, FinishConnectAsync will resolve the addresses, and in case it fails a SocketException(SocketError.HostNotFound) will correctly surface to the user. But this is not the case with HTTP/3 logic where we have host == QuicClientConnectionOptions.ClientAuthenticationOptions.TargetHost. In this case we leave the leave the name resolution to msquic, which will fail with the mysterious error code -2147013895 (0x80072af9) on Windows and QUIC_STATUS_INVALID_PARAMETER on Linux.

Quic repro

DnsEndPoint endPoint = new DnsEndPoint("BadHost", 443);

await Assert.ThrowsAsync<SocketException>(async () => await QuicConnection.ConnectAsync(new QuicClientConnectionOptions()
{
    MaxInboundBidirectionalStreams = 0,
    MaxInboundUnidirectionalStreams = 5,
    IdleTimeout = TimeSpan.FromMinutes(1),
    DefaultStreamErrorCode = 0x10c,
    DefaultCloseErrorCode = 0x100,
    RemoteEndPoint = endPoint,
    ClientAuthenticationOptions = new SslClientAuthenticationOptions()
    {
        TargetHost = "BadHost",
        EnabledSslProtocols = SslProtocols.Tls13,
        ApplicationProtocols = new Collections.Generic.List<SslApplicationProtocol> { SslApplicationProtocol.Http3 }
    }
}));

A robust fix would be to do the name resolution in S.N.Quic code, running a multi-connect attempt similar to Socket.'s DnsConnectAsync. Since there is no multi-connect in msquic anyways (microsoft/msquic#1181), it might be good enough to also take the first resolved address for the host == TargetHost case.

cc @karelz @ManickaP @CarnaViire, not sure how critical is this for 8.0, you may want to punt this.

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

Issue Details

---

https://github.com/dotnet/runtime/pull/88974/files#r1265843373 needs a follow-up:

https://github.com/antonfirsov/runtime/blob/b54e8c72cb63de3549ae4bff268d88daa628404c/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/ConnectHelper.cs#L146

Author:	antonfirsov
Assignees:	antonfirsov
Labels:	area-System.Net.Http, area-System.Net.Quic
Milestone:	8.0.0

[ManickaP]

Seems like dupe of #82404

[antonfirsov]

Sorry, I forgot about that one. In case we want a simple fix for the HttpRequestError problem, I wonder if we can get rid of the host.Equals(options.ClientAuthenticationOptions.TargetHost) special-casing, always resolving the name & setting a QUIC_PARAM_CONN_REMOTE_ADDRESS to the first address? Or do we expect problematic side-effects from doing so? If we are unwilling to do such a change for 8.0, let's close this issue as a dupe of #82404.

[ManickaP]

Yeah, I think we could do that, i.e. remove that part of the condition and do name resolution ourselves. I see no problem with that. @wfurt, just checking if you see any potential issues with that? If not, Anton go ahead.