Reading HTTP headers: request, response and what they control
How HTTP headers frame every request and response, why direction matters, and how caching, CORS and security headers change real behavior.
Headers are the metadata around every message
An HTTP exchange is more than a URL and a body. Before the body, both the client and the server send a block of headers, which are simple name and value lines that describe the message. A request carries headers like Host, Accept and User-Agent to say what is wanted and who is asking, while a response answers with headers like Content-Type, Content-Length and Server to describe what is coming back. Reading these lines is often the fastest way to understand why a page loaded, redirected or failed.
Why direction matters
Every header has a direction, and getting it wrong is a common source of confusion. Accept, Cookie and Authorization only make sense as request headers set by the client, whereas Set-Cookie, ETag and Location belong on the response. A handful, including Content-Type, Cache-Control and Connection, are legitimately used in both directions, which is why the reference marks them both. The Direction menu above exists so you can filter to just the side you are working on and avoid setting a response-only header on an outgoing request.
Caching and conditional requests
Caching headers decide whether a browser or proxy can reuse a response instead of fetching it again. Cache-Control sets the policy, Expires gives an absolute deadline, and ETag and Last-Modified act as validators. On the next visit the client sends If-None-Match or If-Modified-Since, and if nothing changed the server replies 304 Not Modified with no body, saving bandwidth. The Age and Vary headers round this out by reporting how long a shared cache has held an object and which request headers change which response is stored.
Security and cross-origin headers
A modern site leans on response headers to defend itself. Strict-Transport-Security forces future visits onto HTTPS, Content-Security-Policy restricts where scripts and images may load from to blunt cross-site scripting, and X-Frame-Options blocks framing to stop clickjacking. Cross-origin behavior is governed separately by the Access-Control family, which lets a server declare which other origins may read its responses. Copying a correct example from the table is a quick way to start from a known-good value before you tailor it to your own domain.