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.html

Reply via email to