HTTP header

Request headers describe the client and what it wants: `Host` names the site, `User-Agent` identifies the client, `Accept` lists acceptable formats, `Accept-Encoding` advertises which compression the client understands, `Cookie` returns previously stored state.

Response headers describe the answer and instruct the client: `Content-Type` states what the body is, `Cache-Control` states how long it may be reused, `Set-Cookie` stores state, `Location` points elsewhere on a redirect.

A third group instructs the browser about security rather than content — `Content-Security-Policy`, `Strict-Transport-Security`, `X-Content-Type-Options` — and these are only meaningful in a response.

Names are case-insensitive. HTTP/2 and HTTP/3 transmit them lowercase, which is why tooling output sometimes differs from documentation that writes them capitalised.

The application sets some directly, in code, per response. This is where content type and dynamic caching decisions usually live.

The web server sets others by configuration, applied across whole path patterns. Static asset caching is almost always set here.

A CDN or reverse proxy in front may add, rewrite or strip headers. This is the most common source of surprise: a header the application sends correctly can be removed before it reaches the browser, and a header the application never set can appear.

The order of that chain decides who wins. When a header appears twice with different values, what the browser does depends on the header, and the result is rarely what anyone intended.

Nothing on the page changes. A site with no caching headers renders identically to one that is perfectly cached; it is simply slower for returning visitors, which no screenshot shows.

Security headers are the same: a missing `X-Content-Type-Options` has no visible effect until the day a file is served with the wrong type and the browser guesses.

Header problems also tend to be environment-specific. A configuration applied at the CDN is absent when testing against the origin directly, and present in production only.

This is precisely why headers are checked mechanically rather than reviewed by eye — there is nothing to see.

`curl -I https://example.com` sends a HEAD request and prints the response headers. `curl -sSD - -o /dev/null https://example.com` does the same with a real GET, which occasionally differs.

Add `-L` to follow redirects and print the headers of every hop, which is how you see where in a chain a header is lost.

In a browser, the Network panel shows both request and response headers for every request, including the ones added by the browser itself.

Compare the origin against the public hostname when a CDN is involved. Two different answers to the same question identify exactly which layer sets the header.