HN user
HTTP/3 was designed for unstable connections, such as cellphone and satellite networks.
Satellite networks are not a good example. Regular HTTP/1.1, paired with a PEP, outperforms HTTP/3 by an order of magnitude.
The issue you linked to is an excellent example of why everyone and their dog is becoming a CNA these days. It's the only way to keep CVE spam at bay. The system has been broken by the gamification of CVEs and is in desperate need of reform.
Isn't the QUIC transport the default since v0.6.0? Compared to TCP, it's much better suited for satellite communications.
Anything that involves high latency and/or packet loss. And in general: testing servers.
The question is also a bit odd, to be honest. There's no need to look for a beneficial use case to add support for the next iteration of the HTTP protocol.
You could try to force QUIC which should handle latency a bit better. The priority of TCP/QUIC will be configurable with the upcoming v1.23.5 release:
That would be great! I've only had a quick look at the docs, but the API seems reasonable:
https://docs.joinmastodon.org/methods/apps/oauth/ https://docs.joinmastodon.org/methods/statuses/
OT but i wish they'd add Mastodon support.
There is quic-go[1] but i don't think that it's sufficiently optimized[2-4] to be used for this kind of workload. caddy will use it to provide HTTP/3 by default[5] in the upcoming 2.6.0 release.
[1] https://github.com/lucas-clemente/quic-go [2]: https://github.com/lucas-clemente/quic-go/issues/2877 [3]: https://github.com/lucas-clemente/quic-go/issues/2607 [4]: https://github.com/lucas-clemente/quic-go/issues/341 [5]: https://github.com/caddyserver/caddy/pull/4707
I have also been struggling lately with prepared statements and obscure query planning decisions. The developers of the mssql JDBC driver seem to be determined to force the use of prepexec in their driver, which causes high execution times for typical ORM-generated queries: