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: Anyone likes OpenSSL-QUIC ?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Demi Marie Obenour <demiobenour_at_gmail.com>
Date: Wed, 1 Oct 2025 13:23:50 -0400
On 10/1/25 08:56, Daniel Stenberg via curl-library wrote:
> Hey,
>
> In curl we currently support three different QUIC backends, out of which only
> one has graduated into non-experimental (ngtcp2).
>
> We added support for OpenSSL's own QUIC stack back before they offered a
> "proper" QUIC API to allow users to do HTTP/3 even with vanilla OpenSSL, like
> users could with the OpenSSL forks. We call that the OpenSSL-QUIC backend.
>
> The OpenSSL-QUIC backend remains experimental in curl because it underperforms
> significanly speedwise compared to the alternatives. It does this while also
> using significantly more memory.
>
> As vanilla OpenSSL nowadays provides an API that allows curl to use ngtcp2,
> the need for curl to support OpenSSL-QUIC is questionable.
>
> Does anyone actually like or care for OpenSSL-QUIC support in curl?
Arch Linux once used it by default. Now that there is an alternative
that works with OpenSSL I think ngtcp2 is the right way to go.
I think OpenSSL should be focusing on fixing its performance problems
rather than on a QUIC implementation that nobody is interested in.
Personally, I think a Rust implementation would be better. Hopefully
the people behind https://memorysafety.org can fund someone to work
on stabilizing it and getting it used in distros.
Received on 2025-10-01
Date: Wed, 1 Oct 2025 13:23:50 -0400
On 10/1/25 08:56, Daniel Stenberg via curl-library wrote:
> Hey,
>
> In curl we currently support three different QUIC backends, out of which only
> one has graduated into non-experimental (ngtcp2).
>
> We added support for OpenSSL's own QUIC stack back before they offered a
> "proper" QUIC API to allow users to do HTTP/3 even with vanilla OpenSSL, like
> users could with the OpenSSL forks. We call that the OpenSSL-QUIC backend.
>
> The OpenSSL-QUIC backend remains experimental in curl because it underperforms
> significanly speedwise compared to the alternatives. It does this while also
> using significantly more memory.
>
> As vanilla OpenSSL nowadays provides an API that allows curl to use ngtcp2,
> the need for curl to support OpenSSL-QUIC is questionable.
>
> Does anyone actually like or care for OpenSSL-QUIC support in curl?
Arch Linux once used it by default. Now that there is an alternative
that works with OpenSSL I think ngtcp2 is the right way to go.
I think OpenSSL should be focusing on fixing its performance problems
rather than on a QUIC implementation that nobody is interested in.
Personally, I think a Rust implementation would be better. Hopefully
the people behind https://memorysafety.org can fund someone to work
on stabilizing it and getting it used in distros.
-- Sincerely, Demi Marie Obenour (she/her/hers)
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-keys attachment: OpenPGP public key
- application/pgp-signature attachment: OpenPGP digital signature