Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Name resolution timeout not respected, Curl_resolver_kill() hangs.
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Woody via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 15 Nov 2021 16:39:33 +0100
Hello, I looked for similar problems in the archive and found something
related to timeout and name resolution, but nothing seems to represent a
solution.
I am working on Windows 10 and for my test I installed and activated the M$
loopback adapter, then I deactivated the true network card.
I am using curl 7.78.0. I downloaded and compiled curl.exe from the official
repository with the following parameters:
Protocols: dict http https smb smbs
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL HSTS TrackMemory UnixSockets alt-svc
I tried also with a reduced set of Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL.
I prepared a script which does a "echo %TIME%" before and after calling
"curl -v --connect-timeout 1 --trace-time http://...".
This is the output I get:
-------------------------------------------------------------
14:47:42,47
14:47:43.552035 * Resolving timed out after 1005 milliseconds
14:47:54.584128 * Closing connection 0
curl: (28) Resolving timed out after 1005 milliseconds
14:47:54,53
-------------------------------------------------------------
It takes one second to give the timeout error, but it waits then 11 seconds
to return control.
I debugged into the curl-library and I discovered that when
multi_handle_timeout() detects a timeout, it calls the Curl_resolver_kill().
The Curl_resolver_kill() awaits then 11 seconds for Curl_thread_join().
I noticed even that the multi_handle_timeout() does not set "data->result"
to the current "status".
Perhaps this could be useful for subsequent calls to be informed that an
error occurred.
So I was expecting a timeout event after 1 second, but it took 12 seconds to
have the prompt again.
If there were to wait one second from the resolver and one second to the
connection to close (because I set "--connect-timeout 1"), I would have
understood it, but not 1+11 seconds.
Did I do something wrong or is there somekind of bug?
Thank you.
Date: Mon, 15 Nov 2021 16:39:33 +0100
Hello, I looked for similar problems in the archive and found something
related to timeout and name resolution, but nothing seems to represent a
solution.
I am working on Windows 10 and for my test I installed and activated the M$
loopback adapter, then I deactivated the true network card.
I am using curl 7.78.0. I downloaded and compiled curl.exe from the official
repository with the following parameters:
Protocols: dict http https smb smbs
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL HSTS TrackMemory UnixSockets alt-svc
I tried also with a reduced set of Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL.
I prepared a script which does a "echo %TIME%" before and after calling
"curl -v --connect-timeout 1 --trace-time http://...".
This is the output I get:
-------------------------------------------------------------
14:47:42,47
14:47:43.552035 * Resolving timed out after 1005 milliseconds
14:47:54.584128 * Closing connection 0
curl: (28) Resolving timed out after 1005 milliseconds
14:47:54,53
-------------------------------------------------------------
It takes one second to give the timeout error, but it waits then 11 seconds
to return control.
I debugged into the curl-library and I discovered that when
multi_handle_timeout() detects a timeout, it calls the Curl_resolver_kill().
The Curl_resolver_kill() awaits then 11 seconds for Curl_thread_join().
I noticed even that the multi_handle_timeout() does not set "data->result"
to the current "status".
Perhaps this could be useful for subsequent calls to be informed that an
error occurred.
So I was expecting a timeout event after 1 second, but it took 12 seconds to
have the prompt again.
If there were to wait one second from the resolver and one second to the
connection to close (because I set "--connect-timeout 1"), I would have
understood it, but not 1+11 seconds.
Did I do something wrong or is there somekind of bug?
Thank you.
-- Best regards. Woody from WiBu Systems AG. -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-11-15