Buy commercial curl support. 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 Daniel himself.
Re: Weird behavior when using DoH with the multi interface
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 4 Jun 2024 17:35:34 +0200 (CEST)
On Tue, 4 Jun 2024, Timothe Litt via curl-library wrote:
> The application has no control over how many DNS transactions it takes to
> resolve, e.g. a redirect/cname chain. So picking a limit would require
> guesswork.
Correct. As a user you also cannot really know how many connections those DNS
transactions will need or create.
Still: the application has decided that it wants libcurl to limit the number
of concurrent connections and presumably such an applications do that for a
reason. So I don't think it is totally unreasonable for libcurl to then
actually try to adhere to that limit, even when DoH is used.
> An alternate approach would be to not count the DOH connections at all - or
> keep a separate cache and/or quota for them. You probably don't want a
> long-lived libcurl user to keep DOH connections forever, or to cache very
> large numbers. So a separate limit seems like the right approach.
Sure, but I am not a fan of inventing new complicated schemes if the much
simpler approach works good enough...
Date: Tue, 4 Jun 2024 17:35:34 +0200 (CEST)
On Tue, 4 Jun 2024, Timothe Litt via curl-library wrote:
> The application has no control over how many DNS transactions it takes to
> resolve, e.g. a redirect/cname chain. So picking a limit would require
> guesswork.
Correct. As a user you also cannot really know how many connections those DNS
transactions will need or create.
Still: the application has decided that it wants libcurl to limit the number
of concurrent connections and presumably such an applications do that for a
reason. So I don't think it is totally unreasonable for libcurl to then
actually try to adhere to that limit, even when DoH is used.
> An alternate approach would be to not count the DOH connections at all - or
> keep a separate cache and/or quota for them. You probably don't want a
> long-lived libcurl user to keep DOH connections forever, or to cache very
> large numbers. So a separate limit seems like the right approach.
Sure, but I am not a fan of inventing new complicated schemes if the much
simpler approach works good enough...
-- / 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/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-06-04