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)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
