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: HTTPS RR side of things
- 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: Mon, 24 Mar 2025 12:33:37 +0000
On 21 Feb 2025, at 17:09, Niall O'Reilly wrote:
> On 20 Feb 2025, at 16:00, Timothe Litt via curl-library
> made a number of insightful comments, which I really appreciate; he
> wrote:
>
>> You might consider extending getaddrinfo instead of creating yet
>> another API and (likely) library.
>>
>> It has the 'hints's argument & ai.flags... and extending the addrinfo
>> struct in a backward-compatible manner seems possible. A heavier
>> initial lift to get acceptance, but could be better in the long
>> run.
>
> My initial idea was to develop something which could supersede
> getaddrinfo()
> in the same way that this superseded gethostby*(), which would need
> similar
> heavy lifting to get acceptance.
>
> I prefer your suggestion, and your assessment that a
> backward-compatible extension
> seems possible.
>
> I wonder whether the diplomacy/politics/marketing necessary for an
> update to POSIX
> (or just glibc) can be completed in my lifetime.
This last consideration was decisive in negotiating the formation of a
project
team at the Hackathon.
We decided instead on a "wrapping" approach, like the current definition
of `struct Curl_dns_entry` in *lib/hostip.h*, but with a pointer to a
(chain of)
type-agnostic object(s), rather than to a single type-specific object
representing
data extracted from the RDATA of an HTTPS RR.
A team was formed around a merger of two projects, the other of which
needed data
from the TLSA RR (RFC6698) instead of the HTTPS RR. Having contrasting
requirements
helped us find an architecture flexible enough to accommodate possible
future
use-cases.
We still have to finish writing up our project; for anyone who is
interested,
the material can be found at https://github.com/DNS-Hackathon/LHB
The approach we used seems to offer the possibility of using RDATA from
the MX RR
"under the hood" in libcurl, instead of needing to identify the target
host for
a **mailto:** URL using an option.
/Niall
Date: Mon, 24 Mar 2025 12:33:37 +0000
On 21 Feb 2025, at 17:09, Niall O'Reilly wrote:
> On 20 Feb 2025, at 16:00, Timothe Litt via curl-library
> made a number of insightful comments, which I really appreciate; he
> wrote:
>
>> You might consider extending getaddrinfo instead of creating yet
>> another API and (likely) library.
>>
>> It has the 'hints's argument & ai.flags... and extending the addrinfo
>> struct in a backward-compatible manner seems possible. A heavier
>> initial lift to get acceptance, but could be better in the long
>> run.
>
> My initial idea was to develop something which could supersede
> getaddrinfo()
> in the same way that this superseded gethostby*(), which would need
> similar
> heavy lifting to get acceptance.
>
> I prefer your suggestion, and your assessment that a
> backward-compatible extension
> seems possible.
>
> I wonder whether the diplomacy/politics/marketing necessary for an
> update to POSIX
> (or just glibc) can be completed in my lifetime.
This last consideration was decisive in negotiating the formation of a
project
team at the Hackathon.
We decided instead on a "wrapping" approach, like the current definition
of `struct Curl_dns_entry` in *lib/hostip.h*, but with a pointer to a
(chain of)
type-agnostic object(s), rather than to a single type-specific object
representing
data extracted from the RDATA of an HTTPS RR.
A team was formed around a merger of two projects, the other of which
needed data
from the TLSA RR (RFC6698) instead of the HTTPS RR. Having contrasting
requirements
helped us find an architecture flexible enough to accommodate possible
future
use-cases.
We still have to finish writing up our project; for anyone who is
interested,
the material can be found at https://github.com/DNS-Hackathon/LHB
The approach we used seems to offer the possibility of using RDATA from
the MX RR
"under the hood" in libcurl, instead of needing to identify the target
host for
a **mailto:** URL using an option.
/Niall
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-03-24