HTTP/2 frame headers are amazing because they contain both a 24-bit and a 31-bit number, which no programming language I know of can read from a stream innately. 😂

I think we're at a point in network infrastructure where we don't need to shave individual bits or bytes from protocols.


The 24-bit number is unusual but the 31-bit cracks me up primarily because the 1-bit field preceding it has no purpose. They could've just made it a 32-bit number.

@ioquatix I know how to do it. :-) It's more that, in most languages, reading 32-bit numbers from binary streams, strings, or byte arrays isn't just *less complicated* than manual bit shifting — it's downright trivial.

I feel like the protocol designers didn't take ease of implementation into account. Because of TLS, adding one byte to the plaintext incurs no additional bytes over the wire probably 99.9% of the time. Seems like a pointless optimization.

@jgaskins I wasn't suggesting you didn't know how to do it, just showing you that I did it so my thoughts on the matter weren't completely abstract.

Regarding the design of the protocol, there are a ton of weird issues. Another one is simply how chatty the protocol is - in my implementation's micro-benchmarks, it's about 5x slower than optimal HTTP/1.1 comparing like for like persistent connections.

The way HPACK works is also pretty awesome...

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!