HTTP/1.1 must die: the desync endgame

Re:HTTP/1.1 must die: the desync endgame by spenczar5 on Friday August 15, 2025 @02:14PM (#44915680)

I dont know, arguing that http/2 is safer overall is a... bold claim. It is sufficiently complex that there is no standard implementation in the Python standard library, and even third party library support is all over the place. requests doesn't support it; httpx has experimental, partial, pre-1.0 support. Python http/2 servers are virtually unavailable at all. And it's not just Python - I remember battling memory leaks, catastrophic deadlocks, and more in the grpc-go implementation of http/2, in its early days.

HTTP 1.1 connection reuse is indeed more subtle than it first appears. But http/2 is so hard to get right.

[ Parent | on HN ]

Re:HTTP/1.1 must die: the desync endgame by Bender on Friday August 15, 2025 @04:14PM (#44916835)

Speaking of http/2 [1] - August 14, 2025

The underlying vulnerability, tracked as CVE-2025-8671, has been found to impact projects and organizations such as AMPHP, Apache Tomcat, the Eclipse Foundation, F5, Fastly, gRPC, Mozilla, Netty, Suse Linux, Varnish Software, Wind River, and Zephyr Project.

[1] - https://www.securityweek.com/madeyoureset-http2-vulnerabilit...

[ Parent | on HN ]

Re:HTTP/1.1 must die: the desync endgame by yencabulator on Monday August 18, 2025 @03:53PM (#44944609)

Protocol smuggling is a lot more severe than DoS.

[ Parent | on HN ]

Re:HTTP/1.1 must die: the desync endgame by ameliaquining on Friday August 15, 2025 @03:13PM (#44916359)

These sound to me like they are mostly problems with protocol maturity rather than with its fundamental design. If hypothetically the whole world decided to move to HTTP/2, there'd be bumps in the road, but eventually at steady state there'd be a number of battle-tested implementations available with the defect rates you'd expect of mature widely used open-source protocol implementations. And programming language standard libraries, etc., would include bindings to them.

[ Parent | on HN ]

Re:HTTP/1.1 must die: the desync endgame by jcdentonn on Friday August 15, 2025 @02:26PM (#44915845)

Not sure about servers, but we had http/2 clients in java for a very long time.

[ Parent | on HN ]

Re:HTTP/1.1 must die: the desync endgame by jiehong on Friday August 15, 2025 @02:48PM (#44916107)

nghttp2 is a C lib that can be used for serving as a server in many cases. Rust has the http2 crate.

Perhaps it isn’t that easy, but it could be put in common and used a bit everywhere.

[ Parent | on HN ]

Re:HTTP/1.1 must die: the desync endgame by cyberax on Friday August 15, 2025 @02:34PM (#44915941)

An HTTP/2 client is pretty easy to implement. Built-in framing automatically improves a lot of complexity, and if you don't need multiple streams, you can simplify the overall state machine.

Perhaps something like "HTTP/2-Lite" profile is in order? A minimal profile with just 1 connection, no compression, and so on.

[ Parent | on HN ]

Re:HTTP/1.1 must die: the desync endgame by spenczar5 on Friday August 15, 2025 @02:37PM (#44915982)

Isn't the original post about servers? A minimal client doesn't help with server security.

I would endorse your idea, though, speaking more broadly! That does sound useful.

[ Parent | on HN ]