HTTP Fundamentals

Each client-initiated HTTP exchange has one request and one final response. Some exchanges also include interim 1xx responses before the final answer; HTTP/2 briefly added server push, but browser support has largely been removed.

The server does not retain any client context between requests. Two requests from the same browser look identical to the server unless the client explicitly sends identifying information (a cookie, a token).

HTTP/1.1 messages are human-readable ASCII text — you can literally telnet into a server and type a raw HTTP request. HTTP/2 and HTTP/3 moved to binary framing for efficiency, but the conceptual model (method, headers, body) stayed the same.

HTTP doesn't handle its own reliability or ordering — it delegates that to TCP (HTTP/1.1, HTTP/2) or QUIC (HTTP/3). This is why understanding TCP's handshake and congestion behavior matters for understanding HTTP performance.

Declares the intent: GET (read, safe, no side effects), POST (create / submit, has side effects), PUT (replace a resource), PATCH (partially update), DELETE (remove), HEAD (like GET but headers-only), OPTIONS (ask what's allowed — used for CORS preflight).

Scheme (http/https) + host (api.example.com) + path (/users/42) + optional query string (?sort=name). The Host header (not the URL line itself) is what actually tells the server which domain the request is for — critical for shared hosting where one IP serves many domains.

Key-value metadata: Content-Type, Authorization, Accept, User-Agent, Cookie, Cache-Control. Headers are how almost every HTTP feature beyond the basic request/response is implemented — content negotiation, auth, caching, and CORS are all just headers.

Optional payload — JSON, form data, a file upload. GET requests conventionally have no body (though technically allowed, most servers/proxies ignore it). POST/PUT/PATCH typically carry a body.

Rarely seen directly. 100 Continue tells a client it can proceed with sending a large body.

200 OK (standard success), 201 Created (a POST created a resource), 204 No Content (success, nothing to return).

301 Moved Permanently (cached by browsers — use for permanent URL changes), 302 Found / 307 Temporary Redirect (not cached the same way), 304 Not Modified (cache validation — no body sent).

400 Bad Request (malformed input), 401 Unauthorized (missing/invalid auth), 403 Forbidden (authenticated but not allowed), 404 Not Found, 429 Too Many Requests (rate limited).

500 Internal Server Error (unhandled exception), 502 Bad Gateway (upstream server failed), 503 Service Unavailable (overloaded/maintenance), 504 Gateway Timeout.

Blocks JavaScript (document.cookie) from reading the cookie — mitigates cookie theft via XSS.

The cookie is only sent over HTTPS connections — never leaks over plaintext HTTP.

Controls whether the cookie is sent on cross-site requests. Strict blocks it entirely cross-site; Lax allows it on top-level navigation; None (requires Secure) allows it everywhere — used for third-party embeds.

Tells the browser it can reuse the response for N seconds without asking the server at all — a full cache hit, zero network round trips.

Once max-age expires, the browser can revalidate: send the cached ETag in an If-None-Match header. If the content hasn't changed, the server replies 304 Not Modified with no body — cheap for both sides.

A coarser alternative to ETag — based on a timestamp instead of a content hash. Less precise (second-level granularity) but simpler to generate.

One request per connection at a time (unless pipelining, which was never reliably deployed). Browsers work around this by opening ~6 parallel TCP connections per host — still limited, and each connection pays its own TCP + TLS handshake cost.

Introduces multiplexing — many requests share a single TCP connection as interleaved binary frames. This removes the HTTP/1.1 request queueing problem on a connection, adds header compression (HPACK), and standardized server push, though server push is now effectively retired in browsers and many deployments.

Replaces TCP with QUIC, a transport built on UDP. Each stream is independent at the transport level, so a single lost packet only stalls its own stream — eliminating TCP-level head-of-line blocking, which matters most on lossy mobile networks. QUIC also folds the transport and TLS handshake into fewer round trips.

Sits in front of application servers, terminating TLS, handling compression, and forwarding requests — nginx and Envoy are common examples.

Distributes incoming requests across multiple healthy backend instances using a strategy like round-robin or least-connections, and removes unhealthy instances via health checks.

Adding more app server instances (rather than a bigger single machine) to handle more traffic — cheaper, more resilient, and what load balancers are designed to enable.