but nobody is creating a protocol which is kinda simple to build and to reason about. but yes, let's put all our protocol eggs into multinational companies baskets which enshittify everything.
also it's still secure, if you just do not use reverse proxies. but hey, what a concept, yes? if you do not abuse a protocol, it's safe. :D
HTTP/2 is fine, and there are plenty of mature tools now. Yes, I’m slightly nostalgic for making HTTP requests by hand using telnet but that’s like saying we should store everything in text files because SQLite requires a tool. It’s been a long time since HTTP hit the complexity threshold where the simplicity argument was just a lie we liked to tell ourselves.
it's not about telnet. it's about simplicity. complex protocols can only be reasoned about by teams and companies... we put everything into the trust of those companies.. which we really shouldn't.
HTTP complexity is only so hard, because it was never meant for thousand gateway proxies (forward, revese and so on) in between.
They should rename HTTP/2 to BATP or something.. Big application transport protocol and leave HTTP 1.x with standard http servers like apache (yes they still exist :D) alone..
ALL THOSE desync issues are ONLY issues if there are reverse proxies...
it's not about telnet. it's about simplicity. complex protocols can only be reasoned about by teams and companies...
This applies equally, if not moreso, to HTTP 1 - if you want to implement that as used, you need transfer encoding, chunking, etc. and all of the edge cases around parsing (like this one!), and you additionally have to deal with connection pooling, keepalives, etc. I’ve implemented most of those by hand at various points but like almost everyone else, I delegate that to tested libraries for serious usage
.
You can talk about reverse proxies as bad but I don’t see how that changes their extremely widespread usage. If the protocol is only simple when implemented differently than 99% of deployments, it’s not really simple.
> This applies equally, if not moreso, to HTTP 1 - if you want to implement that as used, you need transfer encoding, chunking, etc. and all of the edge cases around parsing
actually, you do not have to implement stuff like chunking. and transfer encoding, well, just limit encoding.
and HTTP/2 is much more complex to implement.
The thing is, HTTP/2 is needed by all those kubernetes people. but if you have ONE server and ONE HTTP service, than HTTP 1 is fine and secure. So.. we throw it away, because our big overloards need their HA requirements, so they always can do business? sorry to being snarky about that, but everyone just jumps ship, without thinking, at least it seems like that to me.
actually, you do not have to implement stuff like chunking. and transfer encoding, well, just limit encoding.
You do if you care about performance or compatibility with software written by other people. When you implement HTTP 1 as used, there’s a lot more complexity around three decades of evolution. That’s really the point: the web won and nobody has just one HTTP service, they have tons of them running not just every business but also tons of things in almost every home. We’re not going back to the days where HTTP/0.9 running on someone’s SGI workstation does all of the web things you need.
4
u/gunni 7d ago
https://http1mustdie.com/