Code:
use actix_web::client::Client;
#[actix_rt::main]
async fn main() {
let client = Client::default();
// Create request builder and send request
let response = client
.get("https://www.rust-lang.org") // <--- notice the "s" in "https://..."
.header("User-Agent", "Actix-web")
.send()
.await; // <- Send http request
println!("Response: {:?}", response);
}
When toml is:
[dependencies]
actix-rt = "1.1.1"
actix-web = { version = "3.0.0-alpha.3", features=["rustls"] }
rustls = "0.17.0"
Error is
2020-05-15T13:42:33.392505900+03:00 DEBUG trust_dns_resolver::async_resolver::background - trust-dns resolver running
2020-05-15T13:42:33.398505100+03:00 DEBUG trust_dns_proto::xfer::dns_handle - querying: www.rust-lang.org A
2020-05-15T13:42:33.399506400+03:00 DEBUG trust_dns_resolver::name_server::name_server - reconnecting: NameServerConfig { socket_addr: V6([fec0:0:0:ffff::1]:53), protocol: Udp, tls_dns_name: None }
2020-05-15T13:42:33.399506400+03:00 DEBUG trust_dns_resolver::name_server::name_server - reconnecting: NameServerConfig { socket_addr: V6([fec0:0:0:ffff::2]:53), protocol: Udp, tls_dns_name: None }
2020-05-15T13:42:33.399506400+03:00 DEBUG trust_dns_resolver::name_server::connection_provider - connecting: Udp { socket_addr: V6([fec0:0:0:ffff::1]:53), timeout: 5s }
2020-05-15T13:42:33.400506700+03:00 DEBUG trust_dns_proto::xfer - enqueueing message: [Query { name: Name { is_fqdn: false, labels: [www, rust-lang, org] }, query_type: A, query_class: IN }]
2020-05-15T13:42:33.400506700+03:00 DEBUG trust_dns_resolver::name_server::connection_provider - connecting: Udp { socket_addr: V6([fec0:0:0:ffff::2]:53), timeout: 5s }
2020-05-15T13:42:33.400506700+03:00 DEBUG trust_dns_proto::xfer - enqueueing message: [Query { name: Name { is_fqdn: false, labels: [www, rust-lang, org] }, query_type: A, query_class: IN }]
2020-05-15T13:42:33.400506700+03:00 DEBUG trust_dns_proto::xfer::dns_exchange - connection established: UDP([fec0:0:0:ffff::1]:53)
2020-05-15T13:42:33.400506700+03:00 DEBUG trust_dns_proto::xfer::dns_exchange - sending message via: UDP([fec0:0:0:ffff::1]:53)
2020-05-15T13:42:33.400506700+03:00 DEBUG trust_dns_proto::xfer::dns_exchange - all handles closed, shutting down: UDP([fec0:0:0:ffff::1]:53)
2020-05-15T13:42:33.400506700+03:00 DEBUG trust_dns_proto::xfer::dns_exchange - io_stream is done, shutting down
2020-05-15T13:42:33.400506700+03:00 DEBUG trust_dns_proto::xfer::dns_exchange - connection established: UDP([fec0:0:0:ffff::2]:53)
2020-05-15T13:42:33.400506700+03:00 DEBUG trust_dns_proto::xfer::dns_exchange - sending message via: UDP([fec0:0:0:ffff::2]:53)
2020-05-15T13:42:33.400506700+03:00 DEBUG trust_dns_proto::xfer::dns_exchange - all handles closed, shutting down: UDP([fec0:0:0:ffff::2]:53)
2020-05-15T13:42:33.400506700+03:00 DEBUG trust_dns_proto::xfer::dns_exchange - io_stream is done, shutting down
2020-05-15T13:42:33.400506700+03:00 DEBUG trust_dns_proto::udp::udp_stream - created socket successfully
2020-05-15T13:42:33.401506100+03:00 DEBUG trust_dns_proto::udp::udp_stream - created socket successfully
[src\clients.rs:28] response = Err(
Connect(
Timeout,
),
)
When toml is:
[dependencies]
actix-rt = "1.1.1"
actix-web = { version = "3.0.0-alpha.3", features=["openssl"] }
rustls = "0.17.0"
Error is
[src\clients.rs:28] response = Err(
Connect(
Io(
Custom {
kind: Other,
error: "the handshake failed: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl\\statem\\statem_clnt.c:1915:: unable to get local issuer certificate",
},
),
),
)
Windows 10 x64 2004
rustc -V): rustc 1.43.1 (8d69840ab 2020-05-04)This works for me with rustls on msvc toolchain on Windows.
May be relevant: When I tried to use wss in https://github.com/actix/actix-web/pull/1654 and https in https://github.com/actix/actix-web/pull/1656, Windows CI pipelines had failed with the similar error.
I don't have access to Windows to any help in digging into this would be amazing.
I'll try to reproduce it locally.
Woah, that was a tough session of looking for a needle in a haystack.
But finally I found it, and the perpetrator is the trust-dns-resolver.
For some reason, on windows DNS lookup takes way too long. There is a relevant (but not exact) issue there: https://github.com/bluejekyll/trust-dns/issues/1057
Once I increased client timeout, request was executed successfully.
Client::build().timeout(std::time::Duration::from_secs(100)).finish();
So, regarding the issue, I see the following possible outcomes:
Not sure which one is preferable, but unfortunately I'm neither have a good networking knowledge nor using Windows for development, so I don't think I can help with the first two options.
I'm pretty sure that I see no problem with DNS resolving on windows in, say, reqwest or applications. So the culprit must be in the code somewhere
@Pzixel As I said, the issue is with trust-dns-resolver. I tried the example from linked issue, but replaced hn with "google.com".
At least on my machine (Win 10) it was really slow. The logs in the OP are also showing that timeout occurs right after trust-dns-related lines.
I understand this, as well as I see that reqwest manage to resolve the same domain name somehow
On reqwest, trust-dns-resolver is an optional resolver. By default it uses hyper's getaddrinfo resolver.
Ok I've subscried to that issue, I think the way forward for us now is to double the default timeout (maybe targetting windows specifically?) and figure out a longer term solution.
If getaddrinfo can get DNS without issue then it's now windows problem, but rather trust-dns one. Increasing timeout doesn't look like a solution to me. I would be really surprised by 100 sec lookup
@popzxc would you like to create an issue in https://github.com/bluejekyll/trust-dns ? I didn't play around it so i don't have a MRE using their API
@Pzixel Sure, I'll try to do it today or tomorrow.
@Pzixel I'm not sure what happened, but after the most recent Windows update I'm unable to reproduce the issue at all.
awc::Client works even with 1 second timeout, both on 2.0, 3.0-alpha and 3.0 versions. trustdns code seems to work fine as well.
Could you please try to apply the latest Windows update and then reproduce the issue?
Hmm, it does work indeed.

That's unexpected. So probably there is not problem to be fixed. We can workaround older windows versions at best.
Most helpful comment
Hmm, it does work indeed.
That's unexpected. So probably there is not problem to be fixed. We can workaround older windows versions at best.