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
