The QUIC API OpenSSL will not provide (2021)
7 comments
·January 21, 2025matthberg
spiffyk
While they have done stuff with QUIC, this more recent blog from Daniel [1] seems to indicate the situation is still not quite ideal.
[1]: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...
badmintonbaseba
Just recently apt listchanges informed me that "curl" (the binary) switched to gnuTLS to support HTTP3 (libcurl remained on openSSL for compatibility). So I assume this is still not fully resolved.
josefx
Ah, the QUIC drama. When everyone adopted quic before the protocol was even fully specified.
spiffyk
Now that is not really fair. For an RFC to be accepted as standard, it needs to have functioning implementations. The code and the specifications come hand-in-hand.
Ayesh
The same happened when TLS 1.3Bwasnarpundnthe corner. Several draft version with different implementations that browsers shipped before the RFC was finalized. OpenSSL wasn't as late as QUIC to implement TLS 1.3 though.
These are selective improvements, and where every millisecond counts, I don't think see anything negative about implementations want to get ahead of the game.
I think Caddy browser gained a significant market share because it supports HTTP/3 by default, while Apache (that uses OpenSSL) lags behind.
BitPirate
Yet here we are in 2025, with OpenSSL still lacking a QUIC server API and RFC9000 approaching its fourth birthday.
Note this is a blog post from 2021, which should be added to the title. The information included is out of date by several years now.
OpenSSL has done stuff with QUIC since then, a cursory search turned up this README in their main repo on using QUIC and OpenSSL: https://github.com/openssl/openssl/blob/master/README-QUIC.m...