HTTP Headers: What They Are and How They Work

HTTP headers are name-value pairs that travel with every HTTP request and response. They control how content is cached, compressed, validated, and delivered between a client and server. That makes HTTP headers a practical concern for anyone monitoring web performance and availability.

Hypertext Transfer Protocol (HTTP) was first introduced by Tim Berners-Lee in 1991. The initial version, HTTP/0.9, moved data between a client and a server. HTTP defines the semantics of that exchange, and the wire format has changed across versions.

HTTP/1.1 and HTTP/2 run over TCP. HTTP/3 was standardized in 2022 in RFC 9114 and runs over QUIC, a transport that uses UDP to reduce latency on unreliable networks.

When a synthetic check inspects a response, HTTP headers are part of what it reads to confirm the response is correct and fresh.

This article explains how HTTP headers work and how teams use them during monitoring and troubleshooting.

What Is the Structure of an HTTP Message?

An HTTP message has three main parts: a start line, headers, and a body. HTTP headers appear between the start line and the body as name-value pairs separated by a colon.

• Start line, which carries the method, path, status code, and protocol version.
• Headers, defined as name-value pairs separated by a colon.
• Body, which holds the data sent or received with the message.

HTTP headers send additional parameters alongside the request or response. They define how each side should interpret the body, cache it, and validate it later. The sections below follow the semantic roles defined in RFC 9110.

Older material grouped HTTP headers as general, request, response, and entity headers. That four-part scheme is a simplified legacy convention from the now-obsolete RFC 2616, and “entity header” isn’t used anymore. RFC 9110 describes headers by role and semantics instead, which is the structure this article uses.

How Do HTTP Versions Carry Headers?

HTTP versions carry the same header semantics over different wire formats. HTTP/1.1 uses text lines, while HTTP/2 and HTTP/3 use binary framing, so a few version rules are worth keeping in mind.

• HTTP defines a set of semantics. The wire format differs by version.
• HTTP/1.1 uses a textual start line and colon-separated header lines. It can use Connection and Transfer-Encoding.
• HTTP/2 (RFC 9113) and HTTP/3 (RFC 9114) use binary framing and pseudo-headers such as :method, :path, and :status.
• Connection-specific fields such as Connection and Keep-Alive are prohibited in HTTP/2 and HTTP/3.
• Transfer-Encoding must not be used in HTTP/2 or HTTP/3, which use binary framing rather than a chunked transfer coding (HTTP/3 over QUIC streams).

Which HTTP Headers Control Requests and Responses?

Request and response control headers manage the connection and describe the client or the resource itself. Connection, User-Agent, and Allow are common examples.

Connection

The Connection header controls whether an HTTP/1.1 connection stays open after a message completes, which lets later requests reuse it. It’s a connection-specific field, so HTTP/2 and HTTP/3 prohibit it.

The following example is HTTP/1.1-specific:

Connection: keep-alive

The directives include:

• keep-alive: The connection stays open for later requests.
• close: The client or server closes the connection.

User-Agent

The User-Agent request header describes the client application, including software version, application type, and operating system. A common format looks like this:

User-Agent: Mozilla/<version> (<system-information>) <platform> (<platform-details>) <extensions>

Here is an example of a Firefox user agent string:

Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefoxversion

Allow

The Allow header lists the methods a resource supports. It often appears in the response to an OPTIONS request or with a 405 status. For example:

Allow: GET, POST, HEAD

Which HTTP Headers Matter for Caching and Validation?

Caching and validation headers decide whether a cache can store a response, how long it stays fresh, and how a client revalidates it. Cache-Control, ETag, If-Match, If-Modified-Since, Expires, and Vary are the main ones, and their rules come from RFC 9111.

Cache-Control

Cache-Control sets caching policy across the request and response cycle. Clients, proxies, and CDNs follow its directives when they store and reuse content. To cache a static file for a long period, you can use this format:

Cache-Control: public, max-age=31536000

• max-age: The maximum time, in seconds, that a resource stays fresh.
• max-stale: With an optional value, the client will accept a response that is stale by up to that many seconds.
• min-fresh: The client wants a response that stays fresh for at least the given seconds.
• no-cache: A stored response must be revalidated with the origin before reuse.
• no-store: Caches must not store the request or response.
• no-transform: Caches must not alter the content, such as recompressing an image.
• only-if-cached: The client wants a cached response and no origin fetch.
• must-revalidate: Once a stored response becomes stale, a cache must revalidate it before reuse.
• public: A shared cache may store the response even where it would not normally be cacheable.
• private: Only a private cache may store the response.
• proxy-revalidate: Applies to shared caches, which must revalidate a stale response.

A few directives fall outside the core caching standard and are called extension directives. The immutable directive is one example, and it indicates that the body won’t change, so the client doesn’t need to revalidate during the freshness window.

ETag

An ETag is an opaque validator for a specific representation of a resource, not a general-purpose unique identifier. A cache uses it to check whether a stored copy still matches the origin. The server sends it with other response headers:

ETag: “<etag_value>”

For example:

ETag: “51baf2f08d0b59d55196aba274562dcc”

An ETag differs from a Last-Modified date in precision. Last-Modified tracks change at one-second resolution, while an ETag can flag a change that happens within the same second or a change that doesn’t alter the timestamp.

If-Match

The If-Match request header makes a request conditional. The server returns the resource only if its current ETag matches one of the listed values. If-Match uses strong comparison, so the match must be byte for byte. For example:

If-Match: “67ab43”, “54ed21”, “7892dd”

If-Modified-Since

If-Modified-Since is another conditional request, used with GET or HEAD. The server returns the resource only if it changed after the given date. To request a resource modified after October 1, 2017, use this format:

If-Modified-Since: Sun, 1 Oct 2017 01:28:00 GMT

The date parameter follows this pattern:

If-Modified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT

Expires

The Expires header gives the date and time until which a response may be considered fresh. In the example below, the resource is considered fresh until October 21, 2015:

Expires: Wed, 21 Oct 2015 07:28:00 GMT

Vary

Vary lists the request header fields a cache uses to select among stored responses for the same URL. It is part of the cache key. For content that differs by client, a server might send:

Vary: User-Agent

Vary: User-Agent can fragment caches, because small user agent differences create many stored variants. Explicit content negotiation is often more reliable than varying on User-Agent, per MDN.

Which HTTP Headers Describe Content and Negotiation?

Content representation headers describe the payload and let the client and server agree on its encoding and size. Accept-Encoding, Content-Encoding, Content-Length, and Transfer-Encoding are the common ones.

Accept-Encoding

Accept-Encoding tells the server which content codings the client supports, with optional quality weights. For example:

Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5

Common values include:

• gzip: Compression based on the gzip format.
• deflate: Compression using the deflate algorithm.
• br: Compression using the Brotli algorithm.
• identity: No compression applied.
• *: Matches any coding not listed.
• ;q=: A quality weight that ranks preferences.

Content-Encoding

Content-Encoding lists the compression applied to the representation, such as gzip or br. It’s the normal way to compress a payload from origin to client. The header is sent like this:

Content-Encoding: gzip

Multiple codings can be listed in the order they were applied:

Content-Encoding: deflate, gzip

Content-Length

Content-Length gives the size of the message body in octets. The format is:

Content-Length: 3495

Transfer-Encoding

Transfer-Encoding describes a transfer coding applied for one hop of an HTTP/1.1 connection. It’s hop-by-hop and version-specific. Chunked is an HTTP/1.1 mechanism, and HTTP/2 and HTTP/3 must not use it. The common value is chunked, which the following HTTP/1.1-specific example uses:

Transfer-Encoding: chunked

Chunked encoding splits a body into chunks when the total length isn’t known in advance. Transfer-Encoding is separate from Content-Encoding. To compress a payload, use Content-Encoding, which describes the representation itself rather than a single hop.

Which HTTP Headers Handle Redirects and Partial Requests?

Redirect and partial-request headers move a client to another location or return part of a resource. Location, Range, and Accept-Ranges cover these cases.

Location

The Location header points to a URL. It appears with 3xx redirects and with 201 Created responses that report where a new resource lives. The format is:

Location: <url>

Range

The Range request header asks for part of a resource, such as a byte range or several ranges. For example:

Range: bytes=200-1000, 2000-6576

The general pattern is:

Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>

Accept-Ranges

Accept-Ranges is a response header that signals the server supports range requests, and it names the unit. For byte ranges:

Accept-Ranges: bytes

Which HTTP Headers Handle Security and Authentication?

Security and authentication headers tell the browser how to protect a session and handle content. Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, and cookie attributes are the common ones, and the definitions below follow MDN.

Strict-Transport-Security

Strict-Transport-Security (HSTS) tells the browser to use HTTPS for a domain for a set period. The max-age directive sets that period in seconds:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Content-Security-Policy

Content-Security-Policy (CSP) restricts which sources a page may load scripts, styles, and other resources from. It helps limit cross-site scripting by blocking unapproved origins.

X-Content-Type-Options

X-Content-Type-Options with the value nosniff stops the browser from guessing a response’s content type. That reduces some attacks based on MIME type confusion.

Cookie Attributes

Set-Cookie attributes control how a cookie behaves:

• Secure: The cookie is sent only over HTTPS.
• HttpOnly: Client-side JavaScript can’t read the cookie.
• SameSite: Limits when the cookie is sent on cross-site requests.

The presence of a security header doesn’t prove a safe configuration. A short HSTS max-age or a permissive CSP can still leave weaknesses, so teams check the values, not just the header names.

How Do You Use HTTP Headers to Troubleshoot a Stale CDN Response?

To troubleshoot a stale CDN response, you read the HTTP headers that govern caching and validation and compare them across regions and against the origin. Cache-Control, Age, ETag, and Vary show whether a cache is holding an old copy and why. These decisions show up in page load times and in the accuracy of what users receive.

Walking Through a Stale Bundle After a Deployment

Consider a CDN that keeps serving an old JavaScript bundle after a deployment. Some users get the new build, some get the old one, and errors appear only in certain regions. A team can work through it in steps:

1. Test the response from several regions to see where the old bundle still appears.
2. Check Cache-Control, Age, ETag, and Vary to confirm freshness and cache-key behavior.
3. Follow the redirect chain from the Location header to the final URL.
4. Compare the returned content version against the origin build.
5. Decide whether the fault lies in the application, the CDN, DNS or routing, or the delivery path.

An Age value that exceeds the response’s freshness lifetime can indicate that a cache is serving stale content. Compare Age with Cache-Control directives such as max-age, along with validators like ETag, to understand whether the cached response should still be considered fresh.

Origin-only checks can miss this. A healthy origin doesn’t prove that users get the correct response once DNS, routing, CDNs, and edge services shape the path.

Diagnostic Reference for Common HTTP Headers

Reading HTTP headers shows what a cache or origin claims to be doing. Confirming what users actually receive across the Internet path needs evidence from outside your own infrastructure.

Header Signals Speed Up Diagnosis

Header signals speed up diagnosis when you pair them with two viewpoints. Inside-out infrastructure visibility shows how your origin, applications, and cloud services behave.

Outside-in evidence shows what users experience once DNS, networks, CDNs, and edge services shape delivery. Teams need both to distinguish an origin problem from a CDN, DNS, routing, or regional delivery problem.

LogicMonitor Digital Experience adds outside-in data from locations across the Internet, alongside infrastructure monitoring. LogicMonitor processes more than two trillion metrics each day, so teams have more data to compare during troubleshooting.

Pairing header checks with synthetic monitoring, website monitoring, and uptime monitoring helps teams catch stale content, broken redirects, and slow responses before users report them.

FAQs