Very cool! And congrats for reaching version 1.0.0!<p>Other nice HTTP/3 libraries include H2O: <a href="https://h2o.examp1e.net" rel="nofollow noreferrer">https://h2o.examp1e.net</a> as well as Facebook/Meta ProxyGen: <a href="https://github.com/facebook/proxygen">https://github.com/facebook/proxygen</a>
Funny, I saw this on HN while I was taking a break from testing Caddy, which has HTTP/3 support, and is even enabled by default. I suppose it's based on Go's implementation.<p>I'm using Apache at the moment and it's working great. HTTP/3 isn't even in the horizon for Apache, and it is the reason why I'm trying out Caddy/Nginx/OpenLitepseed in the first place.<p>Would nghttp3 eventually bring HTTP/3 to Apache?
How does it compare to <a href="https://github.com/cloudflare/quiche">https://github.com/cloudflare/quiche</a>?
How about using a memory-safe HTTP/3 implementation which is also callable from C or any other language? <a href="https://github.com/cloudflare/quiche">https://github.com/cloudflare/quiche</a>
It's going to be sad when the browser oligarchs deprecate HTTP/1.1. The last web protocol that humans could understand. But, perhaps it will force people to go back to the drawing board and develop new protocols that aren't dependent on web browser tech. Maybe the state of the art will finally advance past this networked document reader.
After looking around for ~5 minutes I still can't find out if this HTTP/3 lib will allow establishment of an HTTP/3 connection with a self signed cert. Or if it will allow non-encrypted connections. Does anyone know?<p>Given the lack of any function names addressing TLS/CAs/encryption/etc I'm going to assume it's like all the other HTTP/3 implementations and fails to fully implement the spec. It's funny. Everyone defends MS/Google's HTTP/3 based on QUIC by saying the lack of ability to use plain text or self signed certs is the fault of the HTTP/3 implementations. But all the HTTP/3 lib implementations say it's the fault of QUIC.