Question bank — HTTP - 2 — multiplexing, header compression (HPACK), server push

False. It removes application-layer HOL (streams no longer wait for each other in HTTP), but the single TCP connection still delivers bytes in order, so one lost packet stalls all streams — transport-layer HOL. HTTP-3-and-QUIC fixes that.

False. Semantics are identical to HTTP-1.1; only the wire format (binary framing instead of text) changed. A 200 OK still means the same thing.

False. HTTP/1.1 needed ~6 connections to fake parallelism; HTTP/2 wants one connection so it has a single warmed-up congestion window and pays one TCP+TLS handshake instead of six.

False. Gzip mixes attacker-controlled and secret bytes, and its output length leaks secrets (CRIME-and-BREACH-attacks). HPACK uses a static/dynamic index table plus a fixed Huffman-Coding table, avoiding that adaptive context-mixing.

False. Clients use odd IDs, servers use even IDs, so the two ID spaces never collide on the same connection.

False. If the server pushes a resource the browser already cached, it wastes bandwidth and steals congestion window from the real HTML. Mis-tuned push often hurt, which is why Chrome dropped it.

False. The 24-bit Length field allows up to $2^{24}-1$ bytes, but the default maximum is $2^{14}=16384$ so no single frame monopolizes the link.

False. The dynamic table is per-connection; encoder and decoder each maintain their own copy that evolves as headers are seen on that one connection.

False. HPACK uses a fixed, spec-defined Huffman code optimized for typical HTTP header characters. Being static is part of what makes it CRIME-resistant, unlike adaptive coding.

False. It is the same 7-bit continuation idea used in Varint-encoding and many binary protocols — small numbers fit inline, big ones spill into continuation bytes whose high bit means "more follow".

Wrong frame and stream. The server first sends a PUSH_PROMISE on the client's stream to reserve a new even stream ID, then delivers HEADERS+DATA for the pushed resource on that new stream.

Wrong pattern. A single leading 1 bit marks a fully indexed representation. The 01 prefix marks literal with incremental indexing (a new header to remember).

The top bit is a reserved (R) bit, not a chooser. Odd/even is just the parity of the 31-bit ID value itself — clients pick odd, servers pick even.

Wrong. $10<2^5-1=31$, so it fits directly in the 5 bits as 0b01010. You only emit $31$ first when the value overflows the prefix.

A message (one request or response) is one HEADERS frame plus zero or more DATA frames, all sharing the same Stream ID. It is generally several frames.

The danger isn't which algorithm but length-based leakage when secret and attacker-influenced data are compressed together; HPACK's design (indexing over a static table) is the real fix, not compressing separately.

So many messages can be interleaved on one connection — labeled chunks (by Stream ID) let a slow response yield the wire to ready ones, killing application-layer HOL blocking.

To stop any single frame from monopolizing the shared connection; small frames keep interleaving fair so no one stream starves the others.

The most common headers (:method GET, :status 200, etc.) are known in advance, so they can be sent as a single index byte from the very first request — no learning phase needed.

Because compressing a secret (cookie) together with attacker-chosen text made the compressed length depend on how well the guess matched the secret, leaking it byte by byte. See CRIME-and-BREACH-attacks.

One connection means one properly-warmed TCP congestion window that grows and stays large, instead of six tiny cold windows each restarting from slow-start.

Push blindly resends resources the browser may already have cached and competes for bandwidth; 103 Early Hints + <link rel=preload> lets the browser decide what to fetch, avoiding waste.

All ten streams stall until TCP retransmits that packet, because TCP guarantees in-order byte delivery — this transport-level HOL is precisely what HTTP-3-and-QUIC removes.

It uses a literal without indexing (or never-indexed) representation — sent Huffman-encoded but not added to the dynamic table, so it doesn't waste table space or risk it being indexed.

Entries are evicted oldest-first to stay under the negotiated size limit; evicting an entry simply means the next occurrence of that header must be sent as a literal again.

The client can send RST_STREAM on the pushed (even) stream to cancel it — but bandwidth already spent on frames in flight is wasted, one reason push fell out of favor.

No. The rule is if I < 2^N - 1 fits inline; $I=2^N-1$ triggers the overflow path: store $2^N-1$ in the prefix, then $0$ in a single continuation byte.