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: Fri, 21 Feb 2025 17:09:18 +0000
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.
> Prototype can be separate, of course.
> Also consider control of which of the extensions to enable on a given call. There can be weird behaviors. E.g. Happy Eyeballs is generally a good thing. But my IPv6 block is a Hurricane Electric tunnel, which */some /*CDNs blacklist ("all tunnels are bad", "Some HE tunnels are bad, so block em all"). There are wondrous race conditions that mean pages, or portions of pages randomly get 403 (or other errors) some of the time.
Such operational detail is very valuable. This complexity is to be compounded
with what might ensue from a cascade of orthogonal HTTPS RRs (eg. one for QUIC,
with specific target host, address hints, and ECH configuration; another for H2,
with another set of service parameters), not necessarily all compatible with all
the entries in the chain of struct addrinfo.
> Whether such controls belong in the API, a file (ip6addrctl.conf/gao/conf, both and/or something else requires some thought.
Definitely.
> FWIW.
Worth a great deal to me. Yours are just the kind of comments I was hoping for.
Thanks.
/Niall
Date: Fri, 21 Feb 2025 17:09:18 +0000
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.
> Prototype can be separate, of course.
> Also consider control of which of the extensions to enable on a given call. There can be weird behaviors. E.g. Happy Eyeballs is generally a good thing. But my IPv6 block is a Hurricane Electric tunnel, which */some /*CDNs blacklist ("all tunnels are bad", "Some HE tunnels are bad, so block em all"). There are wondrous race conditions that mean pages, or portions of pages randomly get 403 (or other errors) some of the time.
Such operational detail is very valuable. This complexity is to be compounded
with what might ensue from a cascade of orthogonal HTTPS RRs (eg. one for QUIC,
with specific target host, address hints, and ECH configuration; another for H2,
with another set of service parameters), not necessarily all compatible with all
the entries in the chain of struct addrinfo.
> Whether such controls belong in the API, a file (ip6addrctl.conf/gao/conf, both and/or something else requires some thought.
Definitely.
> FWIW.
Worth a great deal to me. Yours are just the kind of comments I was hoping for.
Thanks.
/Niall
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-02-21