HTTP foundations

Start here when a browser, cache, crawler, or proxy is receiving a response that needs to be explained. The series covers representation and method semantics, caching, redirects, compression, and discovery.

A style request for /assets/site.css branches into schematic responses: 200 with CSS bytes declared text/css, or 404 with HTML bytes declared text/html. Nosniff is scoped to script and style destinations.

Content-Type should describe the bytes you actually send

A filename is only a hint; the response header is the browser-facing contract for the representation.

GET and HEAD use matched URL, request headers, and release. Both response cards show type, validator, coding, and length categories. Only GET has content and checksum evidence. HEAD length can be omitted; if provided it describes GET.

HEAD should describe the same representation as GET

HEAD is a metadata view of GET; status and representation headers should tell the same story.

Accept-Encoding selects identity or encoded representations. The two byte-distinct variants carry different schematic strong ETags, A and B. Vary: Accept-Encoding tells shared caches to match the negotiated request field.

Compression changes the selected HTTP representation

Test compressed and uncompressed requests separately so caches and validators describe the bytes actually served.

Inclusive byte offsets 0 through 15 select exactly 16 bytes from a complete representation of N bytes.

Range requests should prove which bytes were selected

A 206 response is useful only when its boundaries and total size describe the bytes that were returned.

A matrix distinguishes no-cache, which permits storage but requires validation before reuse, from no-store, which asks caches not to store the response.

Cache headers are a contract with two clocks

Separate browser freshness from origin validation, then verify the response headers that implement both.

A permanent 308 relocation links an old URI to a new URI while retaining POST on both sides.

Redirects and error codes should preserve the story

Check the method, Location header, and cache behavior before choosing a redirect or an error status.

Three separate roles: robots.txt gives cooperating crawler preferences, sitemap gives a URL inventory, and the server provides access authorization. Neither file controls access.

robots.txt and sitemaps answer different questions

robots.txt is a crawler-facing preference; a sitemap is a URL inventory; neither is an authorization layer.

GET and HEAD request no state change; PUT and DELETE are not safe even though their intended repeat effect is idempotent.

HTTP methods are a promise about side effects

Get the method boundary right once, and OPTIONS, HEAD, and idempotent writes stop being a surprise.