HTTP

HTTP is the protocol that moves data between clients and servers on the web. Every API call, page load, and image fetch goes over it. The networks post covered the full request flow top to bottom — this goes deeper on HTTP itself.

Request Structure

METHOD /path HTTP/version
Header-Name: value
Another-Header: value

Body (optional)

A real GET request:

GET /api/users/42 HTTP/2
Host: api.example.com
Authorization: Bearer eyJhbGci...
Accept: application/json
Accept-Encoding: gzip, br
User-Agent: Mozilla/5.0

A POST with a body:

POST /api/users HTTP/2
Host: api.example.com
Content-Type: application/json
Content-Length: 42

{"name": "Alice", "email": "alice@example.com"}

Response Structure

HTTP/version STATUS_CODE Reason Phrase
Header-Name: value

Body

HTTP/2 200 OK
Content-Type: application/json
Content-Length: 87
Cache-Control: max-age=3600
ETag: "abc123"

{"id": 42, "name": "Alice", "email": "alice@example.com"}

Methods

Idempotent means calling it multiple times has the same effect as calling it once. PUT replacing a user with the same data is a no-op on the second call. POST creating a user twice creates two users.

Status Codes

The ones you'll actually see:

301 vs 302: browsers follow both, but only cache 301s. 302 vs 307: both are temporary, but 302 allows browsers to change POST to GET on the redirect; 307 doesn't.

Headers

Request Headers

Response Headers

Caching

Good caching makes everything faster. Cache-Control is how you tell caches what to do.

Cache-Control Directives

no-cache doesn't mean don't cache — it means always check if the cached version is still fresh. For truly no caching, use no-store.

ETags and Conditional Requests

ETags are fingerprints. Server sends one with the response; browser stores it. Next request, browser sends If-None-Match: "etag-value". If the resource hasn't changed, server returns 304 Not Modified with no body. Browser uses its cached copy. Saves bandwidth, same end result.

Same idea with Last-Modified / If-Modified-Since using timestamps instead of hashes.

Vary

Vary: Accept-Encoding tells caches to store separate versions for each encoding. Without it, a CDN might serve a gzip'd response to a client that requested plain text.

Cookies

Set by the server with Set-Cookie, sent by the browser on every matching request.

Set-Cookie: session=abc123; Path=/; Domain=example.com; Expires=Fri, 01 Jan 2027 00:00:00 GMT; Secure; HttpOnly; SameSite=Strict

HttpOnly + Secure + SameSite=Strict is the baseline for anything sensitive.

CORS

Browsers block JavaScript from reading cross-origin responses unless the server explicitly allows it. This is CORS (Cross-Origin Resource Sharing).

Same origin = same scheme + host + port. https://api.example.com and https://example.com are different origins.

For simple requests (GET/POST with basic content types), the browser just adds an Origin header and checks the response:

Response: Access-Control-Allow-Origin: https://yourapp.com

For non-simple requests (DELETE, custom headers, application/json bodies), the browser sends a preflight OPTIONS request first:

OPTIONS /api/data HTTP/2
Origin: https://yourapp.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: Authorization

Server responds with what it allows:

Access-Control-Allow-Origin: https://yourapp.com
Access-Control-Allow-Methods: GET, POST, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 86400

If the server doesn't respond with the right headers, the browser blocks the request — the network request still happens, the browser just won't give JavaScript the response.

Access-Control-Allow-Credentials: true allows cookies and auth headers on cross-origin requests. Can't be combined with Access-Control-Allow-Origin: *.

Compression

Servers compress response bodies; clients say what they support in Accept-Encoding.

Server adds Content-Encoding: gzip to indicate the body is compressed. Client decompresses transparently. Typical compression saves 60–80% on HTML/JSON/CSS.

HTTP Versions

HTTP/1.1 introduced keep-alive connections. Browsers work around its per-connection limitations by opening 6–8 parallel connections per origin.

HTTP/2 multiplexes multiple requests over one connection — no need for multiple connections or domain sharding. Binary protocol, so no more text parsing. Header compression with HPACK cuts overhead significantly.

HTTP/3 moves to QUIC, which runs over UDP. TLS 1.3 is baked in. Losing a packet in HTTP/2 stalls all streams on the TCP connection — HTTP/3 only stalls the one stream that lost the packet.

Check what version a site is running:

curl -I --http2 https://example.com
curl -I --http3 https://example.com