> Yes, we like being able to see protocols in the clear since it makes debugging and tracing easier. But text based protocols are also more error prone and open up for much more parsing and parsing problems.
> If you really can't take a binary protocol, then you couldn't handle TLS and compression in HTTP 1.x either and its been there and used for a very long time.
First, you can have the best of both worlds of fixed-sized frames and human readability: make sure each HTTP keyword has a finite, short length. ASCII abbreviations are an acceptable means to this end. This would also eliminate a lot of the implementation difficulties and performance penalties of writing and using a parser.
Second, TLS and compression are not integrated into HTTP/1.1, meaning that people who want to be able to read an HTTP stream on the wire can do so by disabling these features. It's disingenuous to claim that people don't care about human readability just because these extensions exist.
Why not just have the wire sniffer decode the frames before presenting them. If you're interested in what's going on at the HTTP level, you aren't reading packetwise IP packet dumps, because it's hard to make sense of anything and everything is all mixed together; you're looking at abstracted, higher-level flows, where it's just taken for granted that you have a set of linear TCP streams.
HTTP2 is a(n SCTPish) transport-layer protocol squished in underneath an application-layer protocol. Use tools that abstract away the transport-layer protocol.
Or, just, y'know, disable HTTP2? It's an "optional feature" as much as TLS and compression are. Everything that speaks HTTP2 also speaks HTTP1.1, just like everything that speaks compressed/encrypted HTTP also speaks uncompressed/unencrypted HTTP.
It is never a good idea to assume that a can opener[1] will always be available. While your decoder - an extra tool - may be available in "many" cases, there will always be a sizable minority of cases where it isn't. As the performance benefits of fixed-width fields are orthogonal to the fields being ASCII-vs-binary.
> SCTP / "transport-layer protocol"
So we move yet another step down the path of obsoleting TCP port numbers by adding another layer of indirection[2]. Re-implementing ports by tunneling everything over HTTP{,2} was a bad idea when it started over a decade ago, and it's still the wrong way to solve the problem.
The real problem is that flow control needs to happen at the pair-of-machines level. If we had that, opening 1000 "stream" connections to a server would be exactly the same as opening a single 1000-channel SCTP connection.
> Why not just have the wire sniffer decode the frames before presenting them.
Certainly possible, but why make our lives harder by implementing HTTP/2 such that it requires a decoder to read in the first place? If the number of bytes sent remains the same, why not make the fields as self-documenting as possible?
> Everything that speaks HTTP2 also speaks HTTP1.1
No, they have fundamentally different wire formats. This statement isn't even true for HTTP/1.1 and HTTP/1.0, which both have the same wire formats and share many fields but have different interpretations for some of them.
>Certainly possible, but why make our lives harder
I cannot imagine anyone that has written a compliant HTTP parser, or attempted to make a fast HTTP implementation thinking the new framing is harder.
As the article mentions, yeah, it would be nice to be able to look through raw captures. But overall, it's simply too much of a massive downside. It wastes space and burns CPU for nearly zero benefit.
Text protocols make developers start treating them like text than protocols, so you end up with a nightmare of things that look ok to humans but introduce compatibility or security issues when parsing. Even getting line endings right is a pain.
I don't mean that everything that speaks HTTP2 speaks HTTP1.1 definitionally; I mean that, literally, every web browser and web server currently coded to speak HTTP2 is also coded, by duplication of effort, to speak HTTP1.1, and nothing offers an "HTTP2-only" mode of operation so far (nor, I doubt, will anything any time soon.)
> Yes, we like being able to see protocols in the clear since it makes debugging and tracing easier. But text based protocols are also more error prone and open up for much more parsing and parsing problems.
> If you really can't take a binary protocol, then you couldn't handle TLS and compression in HTTP 1.x either and its been there and used for a very long time.
First, you can have the best of both worlds of fixed-sized frames and human readability: make sure each HTTP keyword has a finite, short length. ASCII abbreviations are an acceptable means to this end. This would also eliminate a lot of the implementation difficulties and performance penalties of writing and using a parser.
Second, TLS and compression are not integrated into HTTP/1.1, meaning that people who want to be able to read an HTTP stream on the wire can do so by disabling these features. It's disingenuous to claim that people don't care about human readability just because these extensions exist.