HTTP Headers Reference

The Accept request header tells the server which content types the client can handle. The server uses this to perform content negotiation and return the most appropriate format.

Multiple types can be listed with quality factors (q values) to indicate preference order. If omitted, the server may return any content type.

The Accept-Encoding header tells the server which compression algorithms the client supports. The server can then compress the response body accordingly, reducing transfer size.

Common values include gzip, deflate, br (Brotli), and identity (no encoding). The * wildcard means any encoding is accepted.

The Accept-Language header indicates which human languages the client prefers for the response. Servers use it to serve localised content when available.

Values use BCP 47 language tags (e.g. en-US, ru). Quality factors specify preference order; * matches any language not otherwise specified.

The Authorization header provides credentials for authenticating the client with the server. It is sent in response to a 401 Unauthorized challenge or proactively for known protected resources.

The most common scheme is Bearer (for OAuth 2.0 tokens) and Basic (Base64-encoded username:password). Never use Basic over unencrypted connections.

The Cookie header transmits stored HTTP cookies to the server. Browsers automatically include cookies that match the request's domain, path, and security requirements.

Cookies are set by the server via Set-Cookie and are commonly used for session management, personalisation, and tracking. For security, cookies should use the HttpOnly, Secure, and SameSite attributes.

The Host header is mandatory in HTTP/1.1 requests. It specifies the domain name (and optional port) of the server to which the request is sent, enabling virtual hosting on a single IP address.

In HTTP/2 and HTTP/3, the :authority pseudo-header replaces Host but serves the same purpose. A missing or invalid Host header results in a 400 Bad Request.

The If-Modified-Since header makes a GET or HEAD request conditional based on a timestamp. If the resource has not been modified since the given date, the server returns 304 Not Modified without a body.

It works alongside Last-Modified response header and is a simpler (but less precise) alternative to If-None-Match / ETag.

The If-None-Match header makes a GET or HEAD request conditional. The client sends the ETag value from a previous response; if the resource has not changed, the server returns 304 Not Modified instead of the full response body.

This is the primary mechanism for cache validation with ETags and reduces bandwidth by avoiding redundant data transfer.

The Origin header is sent with cross-origin requests (and same-origin POST requests). It tells the server where the request originated, allowing the server to decide whether to grant access via CORS.

Unlike Referer, Origin does not include the path. It is automatically set by the browser and cannot be overridden by JavaScript.

The Range header requests the server to send only a portion of a resource. This is used for resumable downloads, video streaming, and large file transfers.

If the server supports ranges, it responds with 206 Partial Content and the Content-Range header. If ranges are not supported or the range is invalid, it returns the full resource with 200 OK or 416 Range Not Satisfiable.

The Referer header (note the historical misspelling) indicates the URL of the resource from which the current request originated. It helps servers understand navigation flows and traffic sources.

Browsers control whether to send this header based on the Referrer-Policy header set on the referring page. It is omitted for direct navigation, bookmarks, and when downgrading from HTTPS to HTTP.

The User-Agent header contains a string that identifies the client software. Servers and analytics tools use it to detect browsers, bots, and client platforms.

The format is loosely standardised: it typically includes product tokens, version numbers, and comments. Bots and crawlers send their own identifying strings (e.g. Googlebot). The header can be spoofed, so it should never be used for access control.

Connection controls whether the connection stays open. HTTP/1.1 defaults to keep-alive for persistent connections.

Connection: close tells the client the server will close the connection after the response.

Not used in HTTP/2 and HTTP/3 — connection management is handled by the protocol.

The Content-Disposition header controls how the browser handles a response. With inline, the browser displays the content. With attachment, the browser triggers a file download, optionally using the provided filename.

It is also used in multipart form data to describe form fields. For security, always sanitise the filename to prevent path traversal attacks.

Content-Encoding indicates the compression algorithm applied to the response. The browser decompresses content before processing.

Common values: gzip (widely supported), br (Brotli, better compression), deflate (legacy). Selected based on Accept-Encoding.

Compression reduces transfer sizes by 60-80% for text resources. Enable both gzip and Brotli for optimal results.

Content-Length indicates the exact size of the response body in bytes, allowing the browser to determine when transfer is complete.

Enables efficient connection reuse. Without it, the server must use chunked transfer encoding or close the connection.

Automatically set by most servers for static files. Incorrect values cause incomplete responses.

Content-Type specifies the MIME type and character encoding of the response body. One of the most fundamental HTTP headers.

Consists of a media type (e.g., text/html, application/json) and optionally a charset parameter.

Incorrect Content-Type can cause rendering issues and security vulnerabilities. Always set it explicitly with X-Content-Type-Options: nosniff.

Date represents when the message was originated, in HTTP-date format (RFC 7231).

Automatically set by most servers. Important for caching — validators use it to calculate response age.

Clock synchronization via NTP is recommended for accurate timestamps.

ETag (Entity Tag) provides a unique identifier for a resource version. Browsers send it back via If-None-Match for 304 Not Modified responses.

Can be strong (exact match) or weak (prefixed with W/). Strong ETags required for byte-range requests.

More precise than Last-Modified. Most servers generate ETags automatically.

Last-Modified indicates when the resource was last changed. Browsers send it via If-Modified-Since for 304 responses.

Works well for static files but has second-level precision limitations.

For more precise validation, use ETag in addition to Last-Modified.

Location indicates the redirect URL. Used with 3xx status codes (301, 302, 307) and 201 Created responses.

The value can be absolute or relative. For redirects, the browser navigates automatically.

Important for SEO: 301 redirects pass link equity, 302 do not. Use absolute URLs for maximum compatibility.

The Retry-After header is sent with 429 Too Many Requests, 503 Service Unavailable, or 301/302 redirect responses. It indicates how long the client should wait before retrying.

The value can be a delay in seconds or an absolute HTTP date. Clients should respect this header to avoid hammering the server and to implement proper backoff behaviour.

Server identifies the software used by the origin server. Common values: nginx, Apache, cloudflare.

Can expose details that help attackers find known vulnerabilities. Best practice: remove or set to a generic value.

In nginx: server_tokens off;. In Apache: ServerTokens Prod.

Set-Cookie sends cookies to the browser. Enables session management, preferences, and tracking.

Key attributes: Secure (HTTPS only), HttpOnly (no JS access), SameSite (Strict/Lax/None), Path, Domain, Max-Age.

For security: always use Secure; HttpOnly; SameSite=Lax for session cookies. Never store sensitive data directly.

Transfer-Encoding specifies how the payload is encoded for transfer. Most common value: chunked.

Chunked encoding sends data in parts, useful for dynamically generated content where total length is unknown.

Not used in HTTP/2 — the protocol has its own framing mechanism.

The WWW-Authenticate response header is sent alongside a 401 Unauthorized status. It defines the authentication scheme(s) that can be used to gain access, such as Basic, Digest, or Bearer.

The client then includes matching credentials in subsequent requests using the Authorization header.

The Content-Security-Policy (CSP) header is one of the most powerful security mechanisms available to web developers. It defines an allowlist of content sources that the browser should trust, effectively mitigating cross-site scripting (XSS) and other code injection attacks.

CSP works by specifying directives that control resource loading: default-src sets the fallback policy, script-src controls JavaScript sources, style-src manages CSS, and img-src handles images. Each directive can specify origins, keywords like \'self\' or \'unsafe-inline\', and nonce/hash-based whitelisting.

Implementing CSP correctly requires careful planning. Start with Content-Security-Policy-Report-Only to monitor violations without blocking, then gradually tighten the policy.

Cross-Origin-Opener-Policy (COOP) controls whether a top-level document shares a browsing context with cross-origin documents. Defense against Spectre-type side-channel attacks.

Values: unsafe-none (default), same-origin-allow-popups, same-origin (full isolation).

Often used with Cross-Origin-Embedder-Policy (COEP) to achieve cross-origin isolation, enabling SharedArrayBuffer and high-resolution timers.

Cross-Origin-Resource-Policy (CORP) tells the browser which origins can include the resource. Prevents cross-origin data leaks.

Values: same-site, same-origin, cross-origin.

Important for resources with sensitive data — without it, any website could embed your resources and extract information via side-channel attacks.

Permissions-Policy (formerly Feature-Policy) controls which browser features and APIs are available. Prevents third-party scripts from abusing camera, microphone, geolocation, or payment APIs.

Each feature can be: * (allow all), self (same origin), specific origins, or () (disable).

Important for sites with third-party content — restricting permissions limits potential damage from compromised scripts.

The Referrer-Policy header controls what referrer information is sent in the Referer header. Important for privacy and security.

Common values: no-referrer, same-origin, strict-origin-when-cross-origin, no-referrer-when-downgrade.

Recommended: strict-origin-when-cross-origin — prevents leaking URL paths to third-party sites while keeping analytics data.

The Strict-Transport-Security (HSTS) header tells browsers to only communicate with the server using HTTPS. Once received, the browser will automatically convert all HTTP requests to HTTPS for the specified duration.

The max-age directive specifies how long (in seconds) to enforce HTTPS. includeSubDomains extends this to all subdomains. preload allows inclusion in browser HSTS preload lists.

HSTS prevents man-in-the-middle attacks, SSL stripping, and cookie hijacking. Use at least 1 year (31536000 seconds) for production.

The X-Content-Type-Options header with nosniff prevents the browser from guessing the MIME type. The browser will strictly follow the Content-Type declared by the server.

Without this header, browsers may examine content to determine the type, which attackers can exploit by uploading files with misleading extensions.

This header is simple to implement, has no compatibility issues, and is recommended by OWASP. Set it on every response.

The X-Frame-Options header controls whether a browser can render a page in <frame>, <iframe>, <embed>, or <object>. Key defense against clickjacking.

Values: DENY (no framing), SAMEORIGIN (same-origin only), ALLOW-FROM uri (deprecated).

The modern replacement is frame-ancestors in Content-Security-Policy. For maximum compatibility, use both headers.

X-XSS-Protection enabled the XSS filter in older browsers. Values: 0 (disable), 1 (enable), 1; mode=block (block page on detection).

Recommended modern value is 0 — the filter itself can introduce vulnerabilities.

Deprecated. Modern browsers removed the XSS auditor. Use Content-Security-Policy instead.

Age indicates the time in seconds a response has been in a cache since the origin server generated it. Typically added by CDNs.

Combined with Cache-Control: max-age, clients can calculate remaining freshness lifetime.

Useful for debugging caching. If Age is always 0, the cache may not be working.

Cache-Control is the primary mechanism for controlling HTTP caching. Specifies directives for browser and CDN/proxy caches.

Key directives: max-age=N, no-cache (must revalidate), no-store (never cache), public, private, must-revalidate, immutable.

Best practice: long max-age with versioned URLs for static assets, short max-age or no-cache for HTML.

Expires specifies an absolute date after which the response is stale. Original HTTP/1.0 caching mechanism.

When both Cache-Control: max-age and Expires are present, Cache-Control takes precedence.

Limitation: requires synchronized clocks. Cache-Control: max-age (relative time) is preferred.

Pragma is a legacy HTTP/1.0 cache control mechanism. Only standard value: no-cache.

Exists for backward compatibility. In modern HTTP/1.1+ use Cache-Control instead.

For old HTTP/1.0 clients, include both Pragma: no-cache and Cache-Control: no-cache.

Vary tells caches which request headers affect the response. Different header values need separate cached versions.

Common values: Accept-Encoding, Accept-Language, Cookie.

Careful with Vary: Cookie or Vary: * — these effectively disable CDN caching.

The Access-Control-Allow-Credentials response header tells browsers whether the response to a cross-origin request with credentials (cookies, HTTP auth, client-side certificates) can be exposed to JavaScript.

When set to true, the Access-Control-Allow-Origin header must specify an explicit origin (not *), otherwise the browser will block the response.

Access-Control-Allow-Headers indicates which headers can be included in cross-origin requests.

Simple headers (Accept, Accept-Language, Content-Language, simple Content-Type) are always allowed. Custom headers like Authorization need explicit permission.

* allows any headers but does not work with credentials.

Access-Control-Allow-Methods is used in CORS preflight responses to indicate allowed HTTP methods for cross-origin access.

Common values: GET, POST, PUT, DELETE, PATCH, OPTIONS. Preflight is sent for non-simple methods or custom headers.

Only list methods your API supports. Extra methods expand the attack surface.

Access-Control-Allow-Origin is the most important CORS header. Tells the browser which origins can access the response.

Value: specific origin (e.g., https://example.com) or * (any origin). * cannot be used with credentials.

For security, avoid * on sensitive endpoints. Validate the Origin header against an allowlist. Always include Vary: Origin when dynamic.

The Access-Control-Max-Age header indicates how many seconds the browser can cache the result of a CORS preflight request. During this period, the browser does not need to send another preflight for the same resource.

Setting a reasonable value (e.g. 3600 seconds) reduces unnecessary preflight requests and improves performance for API-heavy applications. Some browsers have a maximum limit they enforce regardless of this value.