I think HTTP before HTTP/2 _is_ simple, but it limits its usefulness too, leading to pain when you want to do anything outside of what was included in the initial design.
But, I'd even argue the best version of HTTP is HTTP/1.0 + ability to specify Host: header (many web servers accept it when requesting via HTTP/1.0 even though it's been introduced in 1.1). The later extensions, including HTTP/1.1 are much harder to implement, thus limiting your implementation options and what you can do with it.
In terms of usefulness for the web (browsers) on the other hand HTTP/3 is the best, but it's far from simple and I doubt anyone would call it that too. Version 1.0 was really simple though, and that makes it beautiful
The author of https://http1mustdie.com/ says that the desync issues caused by pipelined HTTP requests combined with reverse proxies are so bad that we should stop using HTTP/1.1 for anything
Even the popular and battle-tested implementations disagree on how to interpret requests, which causes vulnerabilities when forwarding them to origin servers
It’s one thing to be hard in practice like IMAP where you get basically need to test again real world servers to see what they do and then build against that.
But tfa makes a good point about http having some odd complexities even on paper that we kinda take for granted.
I feel like I just wrote an LLM-level comment but I definitely clicked the article thinking it was just going to be about the first case.
The only other protocols I'm relatively familiar with are email and nntp protocols, mostly smtp and pop3. HTTP as a protocol is pretty similar at it's basic constructs. Compared to HTTP/2 or newer, it's insanely simple... IMAP and FTP, those are much more convoluted and difficult to get right even on a practical level.
HTTP is also pretty universal at this point with simple client and server libraries for pretty much every language or platform under the sun that could use them. You don't have to roll your own, unless you're rolling your own language, and even then, you can probably burrow an existing C implementation/library.
I think HTTP before HTTP/2 _is_ simple, but it limits its usefulness too, leading to pain when you want to do anything outside of what was included in the initial design.
But, I'd even argue the best version of HTTP is HTTP/1.0 + ability to specify Host: header (many web servers accept it when requesting via HTTP/1.0 even though it's been introduced in 1.1). The later extensions, including HTTP/1.1 are much harder to implement, thus limiting your implementation options and what you can do with it.
In terms of usefulness for the web (browsers) on the other hand HTTP/3 is the best, but it's far from simple and I doubt anyone would call it that too. Version 1.0 was really simple though, and that makes it beautiful
Parsers for HTTP/1.x are kind of a solved problem though, even in unsafe languages.
The danger is always when someone thinks they can do it themselves as a 30 minute side quest.
The author of https://http1mustdie.com/ says that the desync issues caused by pipelined HTTP requests combined with reverse proxies are so bad that we should stop using HTTP/1.1 for anything
Even the popular and battle-tested implementations disagree on how to interpret requests, which causes vulnerabilities when forwarding them to origin servers
Yeah. That research is pretty damning
The CDN and proxy operators are in a tight spot here also, since disabling connection reuse for upstream requests will likely crush performance.
It’s one thing to be hard in practice like IMAP where you get basically need to test again real world servers to see what they do and then build against that.
But tfa makes a good point about http having some odd complexities even on paper that we kinda take for granted.
I feel like I just wrote an LLM-level comment but I definitely clicked the article thinking it was just going to be about the first case.
The only other protocols I'm relatively familiar with are email and nntp protocols, mostly smtp and pop3. HTTP as a protocol is pretty similar at it's basic constructs. Compared to HTTP/2 or newer, it's insanely simple... IMAP and FTP, those are much more convoluted and difficult to get right even on a practical level.
HTTP is also pretty universal at this point with simple client and server libraries for pretty much every language or platform under the sun that could use them. You don't have to roll your own, unless you're rolling your own language, and even then, you can probably burrow an existing C implementation/library.
It looks simple from the outside. It's not the hot mess ftp is with having to manage multiple connections to do anything.