HTTP

01The message format

HTTP is a request–response protocol, like a waiter taking an order and bringing a dish. A request has a start line (method, path, version), headers (key: value pairs) and an optional body. A response has a status line (version, code, reason), headers and an optional body. HTTP is stateless: each request stands alone, and state such as a login is carried with cookies or tokens. In HTTP/2 and HTTP/3 the same messages are sent as binary frames, but the meaning is identical, so the text form below is still the best way to think about them.

1POST /api/orders HTTP/1.1
2Host: api.example.com
3Content-Type: application/json
4Authorization: Bearer <token>
5Content-Length: 39
6 
7{"productId": 42, "quantity": 2}
8 
9HTTP/1.1 201 Created
10Location: /api/orders/1001
11Content-Type: application/json
12 
13{"id": 1001, "status": "pending"}

02Methods and their promises

GET reads a resource and must not change anything. HEAD is GET without a body, useful for checks. POST creates something or triggers an action. PUT replaces a resource completely, PATCH changes part of it, DELETE removes it. OPTIONS asks what is allowed and is used by CORS preflights. Two properties matter. Safe methods (GET, HEAD, OPTIONS) do not change state, so crawlers and prefetchers can call them freely. Idempotent methods (GET, HEAD, PUT, DELETE, OPTIONS) give the same result if repeated, so clients can retry them after a timeout. POST and PATCH are not idempotent by default; retrying a POST can create two orders unless the server uses an idempotency key.

• Never change data on GET: a link preview or prefetch could trigger it.
• Retry automatically only idempotent requests.
• Use 405 Method Not Allowed with an Allow header for unsupported methods.

03Status code families

The first digit tells the story. 1xx informational (103 Early Hints lets a server send preload hints before the real response). 2xx success: 200 OK, 201 Created, 204 No Content. 3xx redirection: 301 and 308 permanent, 302 and 307 temporary (307 and 308 keep the method and body), 304 Not Modified for caching. 4xx client errors: 400 Bad Request, 401 Unauthorized (not authenticated), 403 Forbidden (authenticated but not allowed), 404 Not Found, 405, 409 Conflict, 410 Gone, 413 Payload Too Large, 415 Unsupported Media Type, 422 Unprocessable Content (validation), 429 Too Many Requests. 5xx server errors: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout. Correct codes let clients, caches, monitoring and search engines behave correctly without reading the body.

04Headers and cookies

Headers carry metadata. Request: Host, Accept, Accept-Language, Authorization, Content-Type, User-Agent, Cookie. Response: Content-Type, Content-Length, Location, Set-Cookie, Cache-Control and security headers such as Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff and Referrer-Policy. Cookies are small values the server asks the browser to store and send back on every request to that site. Flags decide how safe they are. Secure: only sent over HTTPS. HttpOnly: JavaScript cannot read it, which limits damage from XSS. SameSite=Lax (the browser default) blocks sending on most cross-site requests, Strict blocks all, None allows cross-site but requires Secure. Path, Domain and Max-Age control scope and lifetime. A __Host- prefix forces Secure, Path=/ and no Domain.

1HTTP/1.1 200 OK
2Set-Cookie: __Host-session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=7200
3Strict-Transport-Security: max-age=31536000; includeSubDomains
4X-Content-Type-Options: nosniff
5Referrer-Policy: strict-origin-when-cross-origin
6Content-Security-Policy: default-src 'self'; img-src 'self' data:

05Caching: Cache-Control, ETag, 304

Caching avoids work. Cache-Control tells browsers and CDNs what to do: max-age=31536000, immutable for versioned assets like app.3f9a1c.js; no-cache for HTML that may be stored but must be revalidated each time; no-store for sensitive data that must never be stored; private for responses meant only for one user's browser; s-maxage for shared caches such as CDNs; stale-while-revalidate to serve a slightly old copy while refreshing in the background. Validators make revalidation cheap: the server sends an ETag (a fingerprint) or Last-Modified, the browser later sends If-None-Match or If-Modified-Since, and if nothing changed the server replies 304 Not Modified with no body. Vary tells caches which request headers change the response, such as Accept-Encoding.

1GET /app.css HTTP/1.1
2Host: example.com
3If-None-Match: "a1b2c3"
4 
5HTTP/1.1 304 Not Modified
6ETag: "a1b2c3"
7Cache-Control: no-cache

06CORS without the confusion

Browsers enforce the same-origin policy: a page on https://app.example.com cannot read responses from https://api.example.com unless the API allows it. CORS (Cross-Origin Resource Sharing) is how the server grants that permission with response headers. Simple requests just need Access-Control-Allow-Origin. Requests with JSON bodies, custom headers like Authorization, or methods like PUT and DELETE trigger a preflight: the browser first sends OPTIONS asking whether the real request is allowed. If cookies are involved, the server must return the exact origin (not *) and Access-Control-Allow-Credentials: true. CORS is enforced only by browsers; it does not protect your API from curl or other servers, so you still need authentication.

1OPTIONS /api/orders HTTP/1.1
2Origin: https://app.example.com
3Access-Control-Request-Method: POST
4Access-Control-Request-Headers: content-type, authorization
5 
6HTTP/1.1 204 No Content
7Access-Control-Allow-Origin: https://app.example.com
8Access-Control-Allow-Methods: GET, POST, PATCH, DELETE
9Access-Control-Allow-Headers: content-type, authorization
10Access-Control-Allow-Credentials: true
11Access-Control-Max-Age: 600
12Vary: Origin

07Inspecting HTTP in practice

The browser's Network tab shows every request with headers, timing, cookies and the response. Right-click a request and choose Copy as cURL to reproduce it in a terminal. curl -v prints the full exchange; -I fetches only headers. For APIs, tools like Postman, Insomnia or HTTPie help, but plain curl in a runbook is the most portable. When debugging, compare a working and a failing request side by side: usually one header, cookie or status code explains the difference. Remember to remove tokens and cookies before sharing a copied request with anyone.

1curl -sI https://example.com/                      # headers only
2curl -v https://api.example.com/health             # full exchange
3curl -s -X POST https://api.example.com/orders \
4  -H "Content-Type: application/json" \
5  -H "Authorization: Bearer $TOKEN" \
6  -d '{"productId":42,"quantity":2}' -w "\n%{http_code}\n"

08Message framing and request smuggling

In HTTP/1.1 the receiver must know where a body ends. Content-Length gives the size in bytes; Transfer-Encoding: chunked sends the body in pieces, each with its own length, ending with a zero-size chunk. If a request carries both, or a malformed version of one, a front proxy and a back-end server may disagree about where the request ends. An attacker can then hide a second request inside the first body, which the back end treats as the start of the next user's request. This is HTTP request smuggling, and it can bypass security rules or poison caches. Defences: keep proxies and servers updated, reject requests with both headers or invalid framing, prefer HTTP/2 end to end where possible, and avoid hand-written proxies. HTTP/2 and HTTP/3 have their own framing, but downgrading to HTTP/1.1 at a proxy reintroduces the risk.

09Conditional requests for safe concurrent updates

Two admins open the same product, both edit it, and the second save silently overwrites the first: the lost update problem. HTTP solves it with validators. The GET response includes an ETag (a version fingerprint). The client sends the change with If-Match set to that ETag. If the resource changed in the meantime, the server refuses with 412 Precondition Failed and the client reloads and merges. If-None-Match: * on a PUT means create only if it does not exist, which prevents accidental overwrites. Servers can require preconditions on writes with 428 Precondition Required. Internally, this maps neatly onto a version column or updated_at check in a single UPDATE ... WHERE version = ? statement, so the check and the write are atomic.

1GET /api/products/42 HTTP/1.1
2 
3HTTP/1.1 200 OK
4ETag: "v7"
5 
6PATCH /api/products/42 HTTP/1.1
7If-Match: "v7"
8Content-Type: application/json
9 
10{"price": 4900}
11 
12HTTP/1.1 412 Precondition Failed      # someone saved v8 first

10Content negotiation, Vary and range requests

One URL can have several representations. The client states preferences with Accept, Accept-Language and Accept-Encoding, and the server picks one, ideally answering 406 when nothing fits. Any header that changes the response must be listed in Vary, or a cache may serve a Brotli body to a client that only accepts gzip, or a Russian page to an English visitor. Vary also splits the cache: Vary: User-Agent or Vary: Cookie can make caching nearly useless, so prefer separate URLs for languages and keep Vary to Accept-Encoding where possible. Range requests let a client ask for part of a file with Range: bytes=0-1023; the server answers 206 Partial Content and advertises support with Accept-Ranges: bytes. Video players and download managers depend on this for seeking and resuming.

1curl -s -o /dev/null -D - -H "Range: bytes=0-1023" https://example.com/video.mp4
2# HTTP/2 206
3# content-range: bytes 0-1023/48213004
4# accept-ranges: bytes

11Cookies across sites, subdomains and frames

Site and origin are different ideas. An origin is scheme + host + port; a site is the registrable domain, so app.example.com and api.example.com are different origins but the same site. SameSite rules use sites, which is why a SameSite=Lax cookie is still sent between your subdomains. Cross-site, Lax cookies go only with top-level GET navigations, never with fetch or form POSTs from another site. Cookies set with a Domain attribute are shared with every subdomain, including ones run by a third-party service, so keep session cookies host-only. Third-party contexts are restricted: Safari and Firefox block third-party cookies by default, and Partitioned cookies (CHIPS) let an embedded widget keep state separately per top-level site. Browsers also limit cookie size, about 4 KB each, and every cookie is sent on every request, so large cookies cost bandwidth.

1Set-Cookie: __Host-sid=8f2c...; Path=/; Secure; HttpOnly; SameSite=Lax
2Set-Cookie: widget_state=abc; Path=/; Secure; SameSite=None; Partitioned