On Tue, 14 Dec 2021, Dmitry Karpov wrote:
But the question remains whether libcurl should always rely on a default DNS
timeout set by c-ares, whatever it is, instead of explicitly setting the
"curl" one?
We also don't set any timeouts for the stock name resolver functions but rely
on their internally used timeouts. I don't think curl has better or more
information than the resolver library so I don't think we can make a better
decision.
How do other common getaddrinfo implementations handle (timeouts for)
non-responding name reservers? It seems like behavior we should be able to
mimick.
The concern is that different c-ares versions may have different default
timeouts which can create inconsistent behavior
Yes, but that's more of a feature than a bug. When c-ares fixes problems in
later versions it is a good thing that curl can work with them. "inconsistent
behavior" goes both ways.
makes tight coupling libcurl with c-ares default timeout.
Yes, but now we're back in "old code" territory and that old way of using
c-ares had more problem than just that timer dependency so I suggest you move
away from that. The "new code" path sets no timeout at all but relies on
c-ares' default.
options.timeout = DEFAULT_DNS_TIMEOUT;
This simple change will make libcurl DNS timeout consistent regardless if
the default timeout changes in c-ares.
If we can't improve c-ares to do this better then I think this is a change to
consider, yes. I want us to first explore fixing this in the resolver code.
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
