HTTP Response
Status + headers + body
The server responds with a status code, headers (Cache-Control, Set-Cookie, Content-Type), and body. The response travels back through HTTP framing, TLS encryption, and TCP/QUIC transport.
How It Works
The HTTP response mirrors the request structure: a status line (HTTP/2 200 OK), response headers, and a body. Status codes are grouped by class: 2xx success, 3xx redirection, 4xx client error, 5xx server error. The response headers carry critical metadata — Cache-Control tells the browser how long to cache; Set-Cookie establishes or updates cookies; Content-Type declares what the body is; Content-Encoding indicates compression.
Before the response body is sent, it's typically compressed. Brotli (br) achieves 15–25% better compression than gzip for HTML/CSS/JS, but both are universally supported. The compressed body is then encrypted by TLS, framed by HTTP/2 or HTTP/3, and sent back through the same TCP/QUIC connection. For large responses, the server may stream the body in chunks using Transfer-Encoding: chunked or HTTP/2 DATA frames, allowing the browser to start processing before the full response arrives.
The Signal Flow
Key Concepts
200 OK, 201 Created, 301 Moved Permanently, 304 Not Modified, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests, 500 Internal Server Error, 503 Service Unavailable — each tells the client exactly what happened.
The header that controls caching: max-age=3600 (cache for 1 hour), no-cache (validate before using), no-store (never cache), immutable (never changes — cache forever). Proper caching eliminates 50–90% of repeat requests.
A compression algorithm designed for the web, achieving 15–25% better ratios than gzip on typical web content. Named after a Swiss pastry. Supported by all modern browsers via Accept-Encoding: br.
The server can send the response body in chunks without knowing the total size upfront. The browser processes each chunk as it arrives — this is how server-sent events, streaming HTML, and large file downloads work.
Deep Dive
The caching hierarchy
HTTP caching operates at multiple layers: browser memory cache (fastest, gone on tab close), browser disk cache (persists across sessions), shared CDN/proxy cache (serves many users), and origin server cache (Redis, Varnish). Cache-Control directives propagate through all layers. A resource with 'Cache-Control: public, max-age=31536000, immutable' is cached everywhere for a year and never revalidated — perfect for fingerprinted static assets (app.abc123.js).
Security headers on the response
The response carries security policy headers that protect the user. Strict-Transport-Security forces HTTPS for future visits. X-Content-Type-Options: nosniff prevents MIME type confusion. X-Frame-Options prevents clickjacking by blocking iframe embedding. Content-Security-Policy restricts script sources, preventing XSS. Permissions-Policy controls which browser APIs (camera, geolocation, microphone) the page can use. These headers are your server's instructions to the browser's security enforcement engine.
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.