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.
Re: HTTPS records
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Niall O'Reilly via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 07 Dec 2022 20:59:29 +0000
On 6 Dec 2022, at 7:33, Daniel Stenberg wrote:
> I think we could just extend the current logic and add the scheme to
> the mix. It's not like many users are going to first use one scheme
> and then switch to another to the same host name and port number
> (within the DNS cache timeout period) and get upset if we don't cache
> the address for that.
If I get time before someone else does, that looks like a place for me
to start.
> Another thing that we might want to ponder is TTL for DNS cache
> entries, as currently we have a 60 second default but when we talk to
> the DNS "properly" we actually get the exact TTL for entries and could
> then potentially have a different TTL for some of the data for a
> cached entry.
Since libcurl's DNS cache is downstream of some full-function resolver
cache,
using 60 seconds as default is probably not harmful. On the other hand,
using
the exact cache seems somehow more correct.
I've thought a little about what should be the TTL that libcurl's cache
uses
when it contains data drawn from multiple RRsets (even if just A and
AAAA).
I think the safe think to do is to use the minimum value across all
retrieved
RRsets, so that each set of related data in cache has a consistent
lifetime.
€0,02
Niall
Date: Wed, 07 Dec 2022 20:59:29 +0000
On 6 Dec 2022, at 7:33, Daniel Stenberg wrote:
> I think we could just extend the current logic and add the scheme to
> the mix. It's not like many users are going to first use one scheme
> and then switch to another to the same host name and port number
> (within the DNS cache timeout period) and get upset if we don't cache
> the address for that.
If I get time before someone else does, that looks like a place for me
to start.
> Another thing that we might want to ponder is TTL for DNS cache
> entries, as currently we have a 60 second default but when we talk to
> the DNS "properly" we actually get the exact TTL for entries and could
> then potentially have a different TTL for some of the data for a
> cached entry.
Since libcurl's DNS cache is downstream of some full-function resolver
cache,
using 60 seconds as default is probably not harmful. On the other hand,
using
the exact cache seems somehow more correct.
I've thought a little about what should be the TTL that libcurl's cache
uses
when it contains data drawn from multiple RRsets (even if just A and
AAAA).
I think the safe think to do is to use the minimum value across all
retrieved
RRsets, so that each set of related data in cache has a consistent
lifetime.
€0,02
Niall
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-12-07