HTTP

401 means authentication is missing or invalid — the server asks "who are you?" and must send a WWW-Authenticate header. 403 means the identity is known (or irrelevant) and the request is still refused; retrying with credentials will not help.

GET requests a representation of a resource — retrieval only, parameters in the URL, no intended side effects. POST asks the target resource to process the enclosed representation according to its own semantics — creating, submitting, or triggering work, with data in the body.

HEAD asks for exactly what GET would return, minus the response body. The status line and headers must match the GET response, so Content-Length states the size of the body that GET would have sent, even though HEAD sends zero bytes.

Both send the client to the URL in the Location header. 301 Moved Permanently says the resource has a new home — clients and caches may store it indefinitely and search engines transfer ranking. 302 Found says it is temporary — keep using the original URL, and do not cache by default.

Safe means the method is read-only: the client asks for nothing to change. Idempotent means sending the identical request many times leaves the server in the same state as sending it once. GET, HEAD, OPTIONS, TRACE are safe (and therefore idempotent); PUT and DELETE are idempotent but not safe; POST and PATCH are neither by definition.

Host names the target site, so one IP and port can serve many domains (name-based virtual hosting). Every HTTP/1.1 request must carry exactly one Host; a missing or duplicated Host must be answered with 400 Bad Request.

Content-Length states the body size in octets, so the receiver reads exactly that many bytes and stops. If it is absent, HTTP/1.1 can use Transfer-Encoding: chunked, where each chunk announces its own size and a zero-size chunk ends the body.

Each chunk is its size in hexadecimal, CRLF, that many octets, CRLF. A chunk of size 0 ends the body. After the terminal chunk, optional trailer fields may appear (metadata such as a checksum computed only after streaming), then a final empty line.

Forwarded is the standard single header carrying for, proto, host and by parameters; X-Forwarded-For and X-Forwarded-Proto are the de-facto split equivalents. All are client-spoofable, so trust only entries appended by proxies you control: count hops from the rightmost end, never take the leftmost value blindly.

That pattern means the request is rejected during header parsing, before the app runs. Cookies and token claims accumulate until the header section passes the server's ~8 KB cap, giving 400/431 or a reset. Measure header size at the edge, reproduce with curl, then shrink cookies and tokens.

no-store means never write this to any cache. no-cache means you may store it but must check with the origin before every reuse. must-revalidate means you may serve it freely while fresh, but once it expires you must revalidate rather than serve it stale. Use no-store for secrets, no-cache for always-current data, must-revalidate when stale answers are unacceptable.

A stored response is fresh while its age is below its freshness lifetime; it can be reused with no network trip. Once age exceeds that lifetime it is stale — which does not mean deleted. The cache normally revalidates with the origin, and a successful check makes the copy usable again with a reset clock.

That is the lost update problem: the second PUT was computed from stale data and overwrote the first. HTTP prevents it with a conditional write - the client echoes the ETag it read in an If-Match header, and the server answers 412 Precondition Failed on mismatch.

A private cache serves one user - the browser's own store. A shared cache serves many - a CDN, proxy or gateway. Cache-Control: private forbids shared caches from storing the response; public explicitly permits storing even responses that would otherwise be ineligible, such as authenticated ones.

The server sends an ETag identifying the representation. On the next request the client sends If-None-Match with that value; if it still matches, the server replies 304 Not Modified with headers but no body, and the client reuses its stored copy. Only the round trip is spent, not the payload.

HTTP/1.1 handles one request-response exchange at a time per connection, so the second and third wait for the first to finish. A slow first response stalls the queue behind it; that is head-of-line blocking.

HTTP/1.1 leaves the TCP connection open after a response so the next request reuses it instead of paying for a new handshake. Connection: close announces this is the last message on that connection; the sender closes it once the message ends.

The client sends headers only and waits before sending the body. The server either replies 100 Continue, telling it to send the body, or answers with a final status such as 401 or 413, letting the client skip the upload entirely.

A new HTTPS connection costs a DNS lookup, a TCP three-way handshake (1 RTT), and a TLS handshake (1 RTT with TLS 1.3, 2 with TLS 1.2), plus asymmetric-crypto CPU on both ends and a cold TCP congestion window. Reuse skips all of it.

Most request headers are re-sent to the new URL, and the body is re-sent only when the redirect preserves the method. Host is recomputed. Credentials are the exception: clients drop Authorization (and proxy credentials) on a cross-origin redirect so a redirect cannot leak your token to another host.

HTTP/2 chops every message into binary frames, each tagged with a stream ID. Frames from many streams interleave on one connection, so requests and responses overlap. HTTP/1.1 finished one message per connection at a time, so browsers opened about six connections per host.

QUIC is a reliable, multiplexed transport implemented on top of UDP, with TLS 1.3 built into the protocol rather than layered above it. UDP was chosen because it passes through existing networks and lets the transport live in user space, so it can evolve without OS or middlebox changes.

HPACK encodes each field as an index or a literal. A 61-entry static table covers common fields; a per-connection dynamic table (FIFO, byte-bounded) holds fields already seen, so repeats become one index byte. Literal strings are Huffman-coded. Both peers must keep tables in sync.

TCP delivers one ordered byte stream, so the kernel holds back every byte after the lost segment — all nine other responses stall for a retransmission round trip even though their data arrived. QUIC tracks loss per packet and delivers each stream independently, so only streams with data in the lost packet wait.

HTTP/2 is chosen by ALPN inside the TLS handshake: the client offers h2 and http/1.1, the server picks one, at no extra round trip. HTTP/3 cannot be negotiated that way because it needs a QUIC connection first, so the server advertises it with an Alt-Svc response header or a DNS HTTPS record.

Accept is a request header listing the media types a client can handle, such as application/json or text/html. The server picks one representation of the resource from that list and names its choice in the response Content-Type header.

The client sends Accept-Encoding listing codings it can decode, such as gzip, br, zstd. The server may compress the body with one of them and must say which in Content-Encoding. The client decompresses before parsing. Uncompressed is called identity.

q is a relative preference weight from 0 to 1 (three decimals max). Omitted means q=1, the strongest preference; q=0 means unacceptable. So in that header application/json (q=1) is preferred over text/html (0.8). Header order carries no priority.

406 is about the response: the server cannot produce any representation matching the request's Accept headers. 415 is about the request body: the server cannot process the Content-Type (or Content-Encoding) the client sent. Response side versus request side.

The server routes a body by its declared Content-Type, not by sniffing the bytes. With no Content-Type or the wrong one, there is no parser to hand it to, so it returns 415 — ideally with an Accept-Post header naming the media types it accepts.

With no Max-Age or Expires it is a session cookie: held in memory and dropped when the browsing session ends. With Max-Age=3600 it is persistent: written to disk and sent for one hour, surviving browser restarts.

Set-Cookie goes server to client, one header per cookie, carrying name=value plus attributes. Cookie goes client to server as a single header listing only the matching name=value pairs separated by '; '. Attributes such as Path, Expires and HttpOnly are never sent back.

No Domain means host-only: sent only to the exact host that set it. Domain=example.com means sent to example.com and every subdomain of it. Counter-intuitively, omitting Domain is the narrower, safer scope.

Secure tells the browser to send the cookie only over HTTPS, protecting it from network eavesdroppers. HttpOnly hides it from JavaScript's document.cookie, so cross-site scripting cannot read and exfiltrate it. Session cookies should carry both.

Max-Age wins when both are present. To delete, resend Set-Cookie with the same name and the same Domain and Path, plus Max-Age=0 (or an Expires date in the past). If the scoping attributes do not match, you create a second cookie instead of removing the first.

The client sends Authorization: Basic <base64 of userid:password>, recomputed on every request. Base64 is reversible encoding, not encryption or hashing — anyone who captures the header decodes the password instantly, so only TLS provides confidentiality.

Send Authorization: Bearer <token> on each request, over TLS. 'Bearer' means possession alone proves authorization: the request carries no proof of who is holding it, so whoever copies the token can use it exactly like the legitimate client.

The server refuses with 401 and a WWW-Authenticate header naming an authentication scheme, usually plus a realm. The client gets credentials for that scheme and retries the same request with an Authorization header. HTTP is stateless, so the header repeats on every later request.

Basic transmits the reusable password itself, base64-encoded, on every single request. Without TLS any observer — network tap, proxy, log — reads and replays it forever. TLS is the only thing supplying confidentiality; the scheme supplies none.

invalid_token goes with 401: the token is expired, revoked or malformed, so a fresh token may work — clients refresh and retry. insufficient_scope goes with 403: the token is valid but lacks the required privilege, so retrying with the same token is pointless.