Re: HTTPS RR side of things

Timothe Litt via curl-library <[email protected]> Thu, 20 Feb 2025 11:00:24 -0500
Newsgroups	gmane.comp.web.curl.library
Message-ID	<[email protected]>
On 20-Feb-25 09:34, Niall O'Reilly via curl-library wrote:
>
> On 21 Jan 2025, at 16:50, Daniel Stenberg wrote:
>
>     Bluergh. Unfortunately I am away on vacation over both this
>     Hackathon and the Netnod meeting, which is a little annoying since
>     I live in Stockholm so it would otherwise have been easy to sync up.
>
> That's really unfortunate, but can't be helped.
>
>     Anyway, let's see how far we can take curl's HTTPS RR and ECH
>     support before this!
>
> I've been busy with other work, so have only been able to look very 
> occasionally
> at what's happening with that activity, so can't usefully comment.
>
> In the meantime, I've had confirmation of my place at the two meetings in
> Stockholm. I won't know for a while whether a Hackathon team will form
> around my proposed project. Nevertheless, I would like to describe it here
> so that I can take draw severally on your wisdom.
>
> Although what I proposed to the organizers overlaps with current work on
> libcurl to support and use data from any (available) HTTPS RR, I am aiming
> for something which can be useful for any application or library.
>
> Here it is.
>
>     Possible name: getBETTERinfo
>
>     Goal: design data structure and related APIs for making HTTPS/SVCB
>     data, as well as what getaddrinfo() provides, available, as simply
>     as possible, to an application.
>
>     Things to take into account (first three are already handled by
>     getaddrinfo):
>
>       * RFC3493 (addrinfo)
>       * RFC3484 (address selection policy -- ip6addrctl.conf (BSD),
>         gai.conf(GNU))
>       * nsswitch
>       * application pragmatics
>       * RFC9460 (HTTPS/SVCB RRs)
>       * Happy Eyeballs v3 draft
>         (https://datatracker.ietf.org/doc/html/draft-pauly-v6ops-happy-eyeballs-v3-02)
>
> /Niall
>
>
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.  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.    Whether such controls belong in the API, a file 
(ip6addrctl.conf/gao/conf, both and/or something else requires some thought.

FWIW.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
OpenPGP_signature.asc (application/pgp-signature, 495 B)