Hacker News Reader

Comment by josefx | Hacker News Reader

Ah, the QUIC drama. When everyone adopted quic before the protocol was even fully specified.

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.

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.

Yet here we are in 2025, with OpenSSL still lacking a QUIC server API and RFC9000 approaching its fourth birthday.

They pretty much told everyone that a proper integration for OpenSSL would take years. The server API seems to be in an early review state and slowly progressing.

https://github.com/openssl/openssl/tree/feature/quic-server

As the blog post mentions, the main question is not why a including a QUIC implementation in OpenSSL will take years (that’s reasonable), it’s why the only way to do QUIC using OpenSSL is to use their implementation of the whole thing. The way QUIC hooks into TLS is admittedly a little bit peculiar, but it’s in no way impossible to separate the layers. The OpenSSL devs just decided they don’t want to.

Reply on news.ycombinator.com