Hacker News Reader

Comment by derefr | Hacker News Reader

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.

View on HN

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.

[1] http://en.wikipedia.org/wiki/Assume_a_can_opener

[2] See RFC 1925, Section 2, rule 11a. ( https://tools.ietf.org/html/rfc1925 )

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.)

Reply on news.ycombinator.com