HTTP Request
Method + URL + headers + body
Your request is framed as HTTP. HTTP/1.1 sends plaintext headers; HTTP/2 uses binary frames with HPACK compression; HTTP/3 runs HTTP/2 semantics over QUIC.
How It Works
HTTP is the application protocol that powers the web. At its core, it's a request-response protocol: the client sends a method (GET, POST, PUT, DELETE), a URL, headers (metadata about the request), and optionally a body. The server responds with a status code (200, 404, 500), response headers, and a body. HTTP is stateless — each request is independent, with cookies providing continuity.
The protocol has evolved significantly across versions. HTTP/1.1 (1997) sends plaintext headers and allows persistent connections but suffers from head-of-line blocking — only one request can be in flight per connection. HTTP/2 (2015) introduces binary framing, multiplexing (many requests on one connection), header compression (HPACK), and server push. HTTP/3 (2022) moves to QUIC transport, eliminating TCP head-of-line blocking. The semantics (methods, headers, status codes) are the same across all versions — it's the framing that changed.
The Signal Flow
Key Concepts
GET (read), POST (create), PUT (replace), PATCH (update), DELETE (remove), HEAD (metadata only), OPTIONS (capabilities). Methods have semantics: GET is safe and idempotent; POST is neither.
Key-value metadata on every request and response. Host identifies the target server. Authorization carries credentials. Content-Type declares the body format. Cache-Control manages caching. There are ~80 standard headers.
HTTP/2+ can send many requests simultaneously over one connection. Each gets a stream ID. No more opening 6 parallel TCP connections to load a page — one connection handles everything.
Cache-Control headers tell browsers and CDNs what to cache and for how long. ETag/If-None-Match enable conditional requests — 'send the full response only if it changed.' Proper caching eliminates most redundant network requests.
Deep Dive
HTTP/1.1 → 2 → 3: the evolution
HTTP/1.1's plaintext format is human-readable but wasteful — headers are repeated verbatim on every request, and only one request can be in flight per connection. HTTP/2 fixed this with binary framing and multiplexing, reducing page load times by 10–40%. But HTTP/2 over TCP still has head-of-line blocking at the transport layer. HTTP/3 solves this by running over QUIC (UDP), where each stream is independent. The web is gradually moving to HTTP/3 — as of 2024, ~30% of web traffic uses it.
Header compression
HTTP/2's HPACK maintains a dynamic table of recently-used header key-value pairs, shared between client and server. Repeated headers (like Cookie, User-Agent, Accept) are sent as tiny index references instead of full strings. First request: 800 bytes of headers. Subsequent requests to the same server: 20–30 bytes. HTTP/3's QPACK adapts this for QUIC's out-of-order delivery.
Related Specs
Must-know specifications from the HTTP layer.
This is the core contract of every web API, browser request, and server response. You can't design or debug HTTP without knowing this.
Correct caching is the difference between a fast app and an expensive, slow one. Mis-configured cache headers cause stale data bugs and unnecessary origin load.
HTTP/1.1 is still the baseline. Load balancers, proxies, and debugging tools often present HTTP in this format. Understanding the wire format is essential.