HTTP/1.1 sends request headers as plain ASCII text on every single request. What changed in HTTP/2, and why was compressing header fields considered worth the extra complexity?

## What a header field costs A header field is a `name: value` pair sent ahead of the body, for example `Host: example.com` or `Cookie: session=8f3a...`. In HTTP/1.1 these travel as literal ASCII lines, once per request and once per response, with no compression at all. Two properties make that expensive at scale. **They are large.** A modern browser request carries `User-Agent` (often 100+ bytes), `Accept`, `Accept-Encoding`, `Accept-Language`, `Referer`, several `Sec-Fetch-*` fields, and cookies. Cookies are the worst offender: a site that sets a few analytics and session cookies can push 1-2 KB onto *every* request to that origin, including the request for a 300-byte icon. **They are nearly identical.** Between two requests on the same connection to the same origin, typically only the path changes. Everything else repeats verbatim. Sending the same 700 bytes 100 times is 70 KB of pure redundancy. ## Why HTTP/1.1 could not just gzip them Nothing in HTTP/1.1 defines header compression. `Content-Encoding` and `Transfer-Encoding` apply to the message body, and intermediaries — proxies, caches, load balancers — must be able to read and rewrite headers, so retrofitting a compressed header block into the existing text protocol was not feasible. HTTP/2 could do it because it redefined framing entirely: a HEADERS frame carries an opaque compressed header block fragment, and every endpoint on the connection is required to understand the new encoding. ## What HTTP/2 actually does Two separate changes, often conflated: 1. **Binary framing.** Header fields become a compact binary representation rather than CRLF-delimited text, and the request line and status line become pseudo-header fields (`:method`, `:scheme`, `:authority`, `:path`, `:status`). Parsing is length-prefixed instead of delimiter-scanning, which also removes a whole class of request-smuggling ambiguity. 2. **HPACK compression** (RFC 7541). Three mechanisms combine: a **static table** of 61 predefined entries covering the commonest name/value pairs, a **dynamic table** built up per connection as fields are sent, and **Huffman coding** of any string that still has to be sent literally. The result is that the first request on a connection pays roughly its literal (Huffman-coded) size, and subsequent requests pay a byte or two per unchanged field. Measured on real page loads, request header bytes typically drop by 80-90%. ## Why the win is uplink-shaped Downlink bandwidth is usually plentiful; uplink is not, especially on cellular. A browser opening a page fires many requests near-simultaneously. Under HTTP/1.1 that is N times 700 bytes upstream, which on a slow uplink with a small initial congestion window can take multiple round trips just to transmit the *requests*. Compressing them can remove a full round trip from time-to-first-byte on a resource-heavy page. This is exactly the regime HTTP/2 was designed for: many small requests to one origin. ## What it does not help If your traffic is a handful of large requests — a video download, a big file upload, one JSON API call per screen — header bytes are noise and HPACK saves you nothing measurable. Header compression is a per-request fixed-cost reduction, so its value scales with request count, not with bytes transferred. ## Where it shows up operationally Because the dynamic table is per-connection state on both peers, HPACK is not free for servers: an intermediary holding a million concurrent HTTP/2 connections holds a million pairs of tables. That is why the table size is negotiable and why proxies advertise conservative limits. HTTP/3 keeps the idea but replaces HPACK with QPACK, because HPACK's table updates assume a single strictly ordered byte stream and QUIC does not provide one across streams.