Headers

Every header field follows the same format:

A name, a colon, optional whitespace, and a value. The name is case-insensitive — Content-Type, content-type, and CONTENT-TYPE all mean the same thing. The value, however, is case-sensitive for most headers unless the specification for that header says otherwise.

Some values are simple tokens. Others carry parameters separated by semicolons, or lists of items separated by commas. The Accept header above says: "I prefer HTML, I can handle JSON almost as well, and in a pinch I will take anything." Those q values are quality weights — a number from 0 to 1 that ranks the client’s preference.

A message can contain any number of headers, and the same header name can appear more than once. When it does, the effect is the same as if the values were combined into a single comma-separated list. These two forms are equivalent:

Headers can appear in any order, with one exception: the Host header should appear first in an HTTP/1.1 request, because servers that support virtual hosting need it immediately.

HTTP defines dozens of standard headers. Remembering them all is unnecessary, but understanding how they are organized makes the list manageable. Headers fall into four broad categories based on their role in the message.

One of the most practical things headers do is make requests conditional. A conditional request says: "Only give me this resource if something has changed." This avoids transferring data the client already has, saving bandwidth and time.

The mechanism relies on validators — values that identify a specific version of a resource. HTTP supports two kinds:

Last-Modified dates. The server includes a Last-Modified header in the response, telling the client when the resource was last changed:

When the client requests the resource again, it includes the date in an If-Modified-Since header:

If the resource has not changed, the server responds with 304 Not Modified and no body — the client uses its cached copy. If it has changed, the server sends the full 200 OK response with the updated resource.

Entity tags. An ETag is an opaque identifier — often a hash — that the server assigns to a specific version of a resource:

The client echoes it back in an If-None-Match header:

If the ETag still matches, the server returns 304 Not Modified. ETags are more precise than dates because they change whenever the content changes, regardless of the clock. They also handle the edge case where a resource is modified, then reverted — the date changes but the content is the same. An ETag catches that.

Conditional requests are the foundation of efficient caching. Without them, every page view would require a full download even if nothing changed.

Caching is one of the most consequential behaviors that headers govern. The Cache-Control header tells every cache along the path — the browser, any proxy, any CDN — how to store, reuse, and validate responses. Getting caching right can make a site feel instant; getting it wrong can serve stale data or defeat the cache entirely.

Cache-Control carries one or more comma-separated directives:

This says: any cache may store the response (public), it is fresh for 86,400 seconds — one day (max-age), and after that the cache must check with the server before reusing it (must-revalidate).

The most important directives:

A static asset like a CSS file or an image that never changes can carry an aggressive cache policy:

This tells caches the resource is good for an entire year and will never change at that URL. The immutable directive prevents browsers from revalidating even when the user hits reload.

By contrast, a personalized dashboard page might use:

Only the browser may store it, and it must check with the server every time. This balances performance (the browser avoids a full download if the content has not changed) with correctness (the user always sees fresh data).

The Content-Type header deserves special attention because it affects how every participant in the chain interprets the body. Its value is a media type, optionally followed by parameters:

The media type text/html tells the receiver the body is an HTML document. The charset=utf-8 parameter specifies the character encoding. Without the charset, the receiver must guess — and guessing often goes wrong, producing garbled text.

Common Content-Type values you will encounter constantly:

When a client sends a POST request with a JSON body, it must set Content-Type so the server knows how to parse the payload:

If the client omits Content-Type, the server has no reliable way to determine whether the body is JSON, XML, form data, or something else. This is the most common cause of "400 Bad Request" errors in API work.

HTTP is stateless — the server remembers nothing about previous requests. But real applications need continuity: a shopping cart must persist across page views, a login must survive navigation. Cookies solve this by using two headers to graft state onto a stateless protocol.

The server creates a cookie by including a Set-Cookie header in the response:

The browser stores this cookie and returns it in a Cookie header on every subsequent request to the same site:

The server reads session_id and looks up the associated session — the user’s cart, their login state, their preferences. The protocol itself has not changed; it is still a standalone request and response. The cookie is simply a token that lets the server correlate requests.

The attributes on Set-Cookie control security and scope:

Cookies are the most widely used mechanism for session management on the web. They work because both sides cooperate: the server issues the token, the client returns it, and the protocol never needs to know what it means.

HTTP is designed to be extended. Any sender can introduce a new header name, and receivers that do not recognize it simply pass it through unchanged. This extensibility is one of the reasons HTTP has thrived for over three decades — new capabilities are added by defining new headers, not by changing the protocol.

Historically, custom headers used an X- prefix to signal that they were experimental or non-standard:

This convention was deprecated in 2012 (RFC 6648) because too many X- headers became permanent standards, and the prefix added confusion rather than clarity. Modern practice is to choose a descriptive name without the prefix and register it with IANA if it gains widespread use.

Custom headers are common in APIs. Rate-limiting headers tell clients how many requests they have left. Tracing headers like X-Request-ID correlate a single user action across multiple services. CDN headers report cache hit status. These all work because HTTP’s header mechanism is open-ended by design.

Putting it all together, here is an annotated exchange that uses many of the headers discussed in this section:

Nine request headers and eight response headers, and the entire interaction is self-describing. The client knows how to decompress and parse the body. The server knows the client is authenticated and prefers JSON. The browser knows how long to cache the result and which cookie to store. Every decision is made by reading headers — no out-of-band knowledge required.

This is the design insight that makes HTTP so durable. New requirements — compression, authentication, caching, rate limiting, content negotiation — are all layered on through headers rather than baked into the protocol’s core syntax. The message format has not changed since 1997, yet it handles workloads that its designers never imagined.