>
One can create HTTP/1 server in just a few lines of code.One can create a non-conforming server in a few lines of code. The actual protocol has a horrendous number of corner cases and weirdness. E.g., determining a message body's size depends on whether content-length is sent, is it chunked, was the request a HEAD request, etc. There's also header folding (whereby a header can be split over multiple lines) though one has the out that the standard allows that to be optional (you can respond w/ 400). Trailers (additional headers after the body) and continuations (allows the client to request a potentially large upload, and the server can reject it prior to the client transmitting the body). Actually parsing headers beyond just a KV mapping, that is, trying to work with any of the actual data in a header is fraught with error: many of them can be specified multiple times, and can thus be in multiple occurrences of the header, or all in a single header but separated by commas, or some mix of the two. (Except cookie headers, those are special.) Some also allow a comma to appear in the value itself, meaning a parser that first splits on comma and then parses the resulting parts is broken.
These text protocols, while "simple" in the sense that a human can generally look at the on-the-wire data and parse with their eyeballs, require complex FSMs to parse correctly. (Complex, relative to an equivalent binary protocol with binary-encoded length-prefixed data or even a text protocol that didn't accommodate every random slightly different way of doing it.) Now, HTTP/2 also adds a lot of functionality above and beyond what HTTP/1 has, so that certainly eats up some of the gains in parsing simplicity (and I think it would be fair to say that the outcome is overall more complex).
I'd much rather have a binary protocol and good tooling. (And that's much more feasible with today's browser's devtools. I would not want to attempt this with the lame excuse for tooling IE 6 had back in the 90s.)
MIME's header encoding of non-ASCII characters is another abomination that I'd toss in this bucket. E.g.,
Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
=?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=
(Yes, that's a valid email Subject line.) HTTP supported this at one time, though nowadays the standard has mostly deprecated this:
Historically, HTTP has allowed field content with text in the
ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
through use of [RFC2047] encoding. In practice, most HTTP header
field values use only a subset of the US-ASCII charset [USASCII].
Newly defined header fields SHOULD limit their field values to
US-ASCII octets. A recipient SHOULD treat other octets in field
content (obs-text) as opaque data.