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.

Follow

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
Mastodon

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!