Re: Network.framework and libcurl

On Thu, 28 Aug 2025, Demi Marie Obenour wrote:

> To me, most of libcurl's functionality is in the higher levels of the stack: 
> the many protocols it supports, the HTTP redirect handling, the stable ABI 
> and API, and things like that.

In order to support the existing API, libcurl needs to control its engine. If 
we outsource all of DNS, TCP/QUIC connection and TLS/QUIC handshake to a black 
box we can't control, a huge amount of options can no longer work and a lot of 
behavior is going to be controlled by what Apple decides their magic functions 
should do.

In some cases that can be a good thing as then we could benefit from magic 
super powers Apple can do because they own the whole stack, but it would also 
prevent us from doing much of the magic we think benefits curl users. Like 
DoH, using c-ares, our happy eyeballs, our DNS cache, our resolve/connect-to 
tricks, h1/h2/h3 connection racing, HTTPS-RR records, ECH handling, unix 
domain sockets, several proxy setups etc. It might also cause 
blocking/non-blocking problems or challenges to do a massive amount of 
parallel transfers correctly - because of all the threads and blocking calls.

I might also be wrong and then someone can prove that with code and test 
cases. I rather not speak in terms of absolutes as what is "allowed" and "not 
allowed" but rather that it always depends on the exact specific details in 
every case, and until we have a proposal in front of us I rather use general 
terms.

-- 

  / daniel.haxx.se || https://rock-solid.curl.dev
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html