On Wed, 7 Dec 2022, Mellergård, Daniel wrote:
But at the same time CURLAUTH_ANY* is a bit loosely defined ("libcurl will
automatically select the one it finds most secure"). I don't know if there
are RFC:s that require a new negotiation with the host for each new request?
The RFCs only
> Am 08.12.2022 um 23:28 schrieb Daniel Stenberg via curl-library
> :
>
> On Thu, 8 Dec 2022, Daniel Stenberg via curl-library wrote:
>
>> Sure. That should be fairly even even! The "struct ares_addrinfo" contains
>> TTL data.
>
> Oops, I meant to say "fairly easy even".
We require at
On Thu, 8 Dec 2022, Daniel Stenberg via curl-library wrote:
Sure. That should be fairly even even! The "struct ares_addrinfo" contains
TTL data.
Oops, I meant to say "fairly easy even".
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes,
On Thu, 8 Dec 2022, Dmitry Karpov via curl-library wrote:
It is kind of pity that we are tightly bound to limitations of getaddrinfo()
and can't use features from libraries that provide TTL, like c-ares.
I totally agree.
Correct me if I'm wrong, but both c-ares and getaddrinfo()-specific
> Sure, just a little complicated.
> A primary reason the default name resolving in libcurl is still done with
> getaddrinfo() and not with a third party library like c-ares is that it is
> mighty hard to replicate its functionality. And getaddrinfo() does not return
> TTL.
> If we want to
On Thu, 8 Dec 2022, Daniel F via curl-library wrote:
You can also try to use res_query, which returns TTL as well. It is part of
4.3BSD standard, so should be available on may *nix systems.
Yes but...
That limitation is enough for me to argue that it isn't terribly interesting,
and then add
