HTTP foundations

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

A file representation passing through a media-type label before reaching a browser.

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 requests aligned to the same response metadata while only GET carries a body.

HEAD should describe the same representation as GET

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

A long byte sequence with one bounded segment selected for a partial response.

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.

Cache headers are a contract with two clocks

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

A large HTTP representation compressed into a smaller transfer.

Compression changes the selected HTTP representation

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

An old URI permanently redirected to a new URI with status 308.

Redirects and error codes should preserve the story

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

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.