-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect name resolution errors in QuicConnection.ConnectAsync #89095
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
Thinking that The actual problem here, similarly to #89096 is that we can't detect Quic reproDnsEndPoint 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 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 Issue Detailshttps://github.com/dotnet/runtime/pull/88974/files#r1265843373 needs a follow-up:
|
Seems like dupe of #82404 |
Sorry, I forgot about that one. In case we want a simple fix for the |
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. |
Tentatively re-assigned myself. Will bring it up in todays meeting, and file a PR if we have consensus. (If no, let's close it as a dupe.) |
I think that should be ok. It is more work but we do it anyway and it possibly opens avenue to deal better with names that remove to multiple addresses. |
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
The text was updated successfully, but these errors were encountered: