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: Network.framework and libcurl
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 31 Aug 2025 11:43:12 +0200 (CEST)
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.
Date: Sun, 31 Aug 2025 11:43:12 +0200 (CEST)
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.htmlReceived on 2025-08-31