HTTP Headers Reference

Header Categories

HTTP headers are metadata sent with requests and responses. They're organized into categories based on their purpose:

Category	Purpose	Common Headers
Request	Client sends to server with the request	Host, Accept, User-Agent, Authorization
Response	Server sends back with the response	Content-Type, Content-Length, Location
Caching	Control how responses are cached	Cache-Control, ETag, Last-Modified
Security	Protect against attacks, control access	CORS headers, CSP, HSTS
Cookies	Manage client-side state	Cookie, Set-Cookie
Extension	Custom or vendor-specific headers	X-Request-ID, X-Forwarded-For

Request Request Headers

Headers sent by the client to provide information about the request, client capabilities, and preferences.

Header	Description	Example	RFC
Host	Target host and port (required in HTTP/1.1)	example.com:8080	9110 §7.2
Accept	Media types the client can process	text/html, application/json	9110 §12.5.1
Accept-Language	Preferred languages for response	en-US, en;q=0.9	9110 §12.5.4
Accept-Encoding	Compression algorithms supported	gzip, deflate, br	9110 §12.5.3
User-Agent	Client software identification	Mozilla/5.0 (Windows...)	9110 §10.1.5
Authorization	Authentication credentials	Bearer <token>	9110 §11.6.2
Content-Type	Media type of request body	application/json	9110 §8.3
Content-Length	Size of request body in bytes	1234	9110 §8.6
Referer	URL of referring page	https://example.com/page	9110 §10.1.3
Origin	Origin of the request (for CORS)	https://example.com	RFC 6454

Host

Specifies the host and port of the server. Required in HTTP/1.1+ to support virtual hosting (multiple domains on one IP).

Host: <host>[:<port>]

Accept

Tells the server which content types the client can understand. Uses quality values (q) to indicate preference.

Accept: <media-type>[;q=<quality>], ...

text/html: HTML documents
application/json: JSON data
*/*: Any content type
q=0.9: Quality value (0-1) indicating preference

Authorization

Contains credentials for authenticating the client with the server. Multiple schemes are supported.

Authorization: <type> <credentials>

Basic <base64>: Base64-encoded username:password (use only over HTTPS)
Bearer <token>: OAuth 2.0 / JWT token
Digest ...: Challenge-response authentication

Response Response Headers

Headers sent by the server to provide information about the response and additional instructions for the client.

Header	Description	Example	RFC
Content-Type	Media type of the response body	text/html; charset=utf-8	9110 §8.3
Content-Length	Size of response body in bytes	3495	9110 §8.6
Content-Encoding	Compression applied to the body	gzip	9110 §8.4
Location	URL for redirects or new resource	https://example.com/new	9110 §10.2.2
Server	Server software identification	nginx/1.24.0	9110 §10.2.4
Date	Date/time the response was generated	Wed, 27 Nov 2024 12:00:00 GMT	9110 §6.6.1
WWW-Authenticate	Authentication method required (with 401)	Bearer realm="api"	9110 §11.6.1
Retry-After	When to retry (with 429/503)	120	9110 §10.2.3

Content-Type

Indicates the media type of the response body. Essential for the client to know how to interpret the data.

Content-Type: <media-type>[; charset=<charset>]

text/html; charset=utf-8: HTML document with UTF-8 encoding
application/json: JSON data (UTF-8 is default)
application/octet-stream: Binary data (triggers download)
multipart/form-data: Form data with file uploads

Location

Used with 3xx redirects to specify the new URL, or with 201 Created to provide the URL of the new resource.

Location: <url>

Caching Caching Headers

Headers that control how responses are cached by browsers and intermediary proxies. Proper caching dramatically improves performance.

Header	Description	Example	RFC
Cache-Control	Caching directives for request/response	max-age=3600, public	9111 §5.2
ETag	Unique identifier for resource version	"33a64df5"	9110 §8.8.3
Last-Modified	Date resource was last changed	Wed, 27 Nov 2024 10:00:00 GMT	9110 §8.8.2
If-None-Match	Conditional request using ETag	"33a64df5"	9110 §13.1.2
If-Modified-Since	Conditional request using date	Wed, 27 Nov 2024 10:00:00 GMT	9110 §13.1.3
Expires	Date/time after which response is stale	Thu, 28 Nov 2024 12:00:00 GMT	9111 §5.3
Vary	Headers that affect cached response	Accept-Encoding, Accept-Language	9110 §12.5.5
Age	Time in seconds since cached	3600	9111 §5.1

Cache-Control

The primary header for controlling caching behavior. Supports many directives that can be combined.

Cache-Control: <directive>[, <directive>, ...]

max-age=<seconds>: Maximum time to cache (in seconds)
no-cache: Must revalidate before using cached copy
no-store: Never cache (sensitive data)
public: Can be cached by shared caches (CDNs)
private: Only browser can cache (not CDNs)
immutable: Resource will never change (for versioned assets)
stale-while-revalidate=<seconds>: Serve stale while fetching fresh copy

ETag & Conditional Requests

ETags enable efficient cache validation. The server returns an ETag with the response; the client sends it back with If-None-Match to check if the resource changed.

ETag: "<etag-value>" If-None-Match: "<etag-value>"

Security Security Headers

Headers that protect against common web vulnerabilities. These should be set on all production websites.

Header	Description	Example	Spec
Access-Control-Allow-Origin	Origins allowed to access resource (CORS)	https://example.com	Fetch
Access-Control-Allow-Methods	HTTP methods allowed (CORS preflight)	GET, POST, PUT	Fetch
Access-Control-Allow-Headers	Request headers allowed (CORS preflight)	Content-Type, Authorization	Fetch
Content-Security-Policy	Restrict resources page can load	default-src 'self'	CSP Level 3
Strict-Transport-Security	Force HTTPS connections (HSTS)	max-age=31536000; includeSubDomains	RFC 6797
X-Content-Type-Options	Prevent MIME type sniffing	nosniff	Fetch
X-Frame-Options	Control iframe embedding	DENY	RFC 7034
Referrer-Policy	Control Referer header sent	strict-origin-when-cross-origin	W3C
Permissions-Policy	Control browser features (camera, mic)	geolocation=(self)	W3C

CORS Headers

Cross-Origin Resource Sharing headers control which origins can access your API. Without proper CORS headers, browsers block cross-origin requests.

Access-Control-Allow-Origin: <origin> | * Access-Control-Allow-Methods: <method>, ... Access-Control-Allow-Headers: <header>, ... Access-Control-Allow-Credentials: true Access-Control-Max-Age: <seconds>

Content-Security-Policy

Defines approved sources for content, protecting against XSS and data injection attacks. One of the most important security headers.

Content-Security-Policy: <directive> <source>; ...

default-src 'self': Allow resources only from same origin
script-src 'self' 'unsafe-inline': Script sources (avoid unsafe-inline if possible)
style-src 'self' 'unsafe-inline': Stylesheet sources
img-src 'self' data: https:: Image sources
connect-src 'self' https://api.example.com: Allowed fetch/XHR destinations
frame-ancestors 'none': Prevent embedding in frames (replaces X-Frame-Options)

Strict-Transport-Security (HSTS)

Tells browsers to only connect via HTTPS. Prevents downgrade attacks and cookie hijacking.

Strict-Transport-Security: max-age=<seconds>[; includeSubDomains][; preload]

max-age=31536000: Enforce HTTPS for 1 year
includeSubDomains: Apply to all subdomains
preload: Request inclusion in browser preload list

Cookies Cookie Headers

Headers for managing cookies—small pieces of data stored on the client to maintain state across requests.

Header	Direction	Description	RFC
Cookie	Request	Sends stored cookies to server	6265 §5.4
Set-Cookie	Response	Sets cookie on client	6265 §5.2

Extension Extension Headers

Custom headers used by applications, proxies, and services. While the X- prefix is deprecated for new headers, many are still widely used.

Extension headers are not part of the HTTP standard but are commonly used in practice. The X- prefix was historically used to mark experimental headers, but RFC 6648 deprecated this practice in 2012. However, many established X- headers remain in widespread use.

Header	Description	Typical Use
X-Request-ID	Unique identifier for request tracing	Debugging, distributed tracing, log correlation
X-Correlation-ID	ID linking related requests across services	Microservices, event chains
X-Forwarded-For	Original client IP (when behind proxy)	Proxies, load balancers, CDNs
X-Forwarded-Proto	Original protocol (http/https)	SSL termination at proxy
X-Forwarded-Host	Original Host header value	Reverse proxies
X-Real-IP	Client's real IP (nginx convention)	nginx reverse proxy
X-Powered-By	Technology stack identification	Often removed for security
X-RateLimit-Limit	Maximum requests allowed	API rate limiting
X-RateLimit-Remaining	Requests remaining in window	API rate limiting
X-RateLimit-Reset	When rate limit resets (Unix timestamp)	API rate limiting

Forwarded (Standard Replacement)

The standardized replacement for X-Forwarded-* headers, defined in RFC 7239. Combines forwarding information into a single header.

Forwarded: by=<identifier>;for=<identifier>;host=<host>;proto=<proto>

Rate Limiting Headers

While not standardized, these headers are widely used by APIs to communicate rate limit status. A draft standard (RateLimit Headers) is in progress.

X-RateLimit-Limit: <max-requests> X-RateLimit-Remaining: <remaining> X-RateLimit-Reset: <unix-timestamp>

Creating Custom Headers

When you need application-specific headers, follow these guidelines:

Don't use X- prefix: Deprecated per RFC 6648; use descriptive names
Use your organization prefix: e.g., Acme-Request-Priority
Be consistent: Use same casing and naming conventions
Document thoroughly: Include in API documentation
Consider standardization: If broadly useful, propose as IETF draft