4 ms·
> 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 th
by jude- 12y ago
> 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.
- derefr 12y agoI 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.)
- MichaelGG 12y ago>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.