HTTP Headers Reference
HTTP fields carry representation metadata, authentication, caching rules, routing context, and policy. Field names are case-insensitive, but each field value has its own syntax and security requirements.
Representation and negotiation
| Header | Purpose |
|---|---|
| Content-Type | Describes the media type and parameters of the sent representation. |
| Content-Length | Declares representation length in bytes where framing uses it. |
| Content-Encoding | Lists representation codings such as gzip. |
| Accept | Lists response media types acceptable to the client. |
| Accept-Encoding | Lists response content codings the client can decode. |
| Content-Disposition | Suggests inline display or attachment handling and a filename. |
Content-Type: application/json describes the body being sent; Accept: application/json requests JSON in the response. Do not label form or text content as JSON. Use application/problem+json for a documented problem-details representation rather than returning an HTML error to an API client.
Authentication and cookies
Authorization carries credentials for the target resource, commonly a Bearer token. WWW-Authenticate accompanies authentication challenges. Set-Cookie creates or updates a cookie; the browser later sends matching values in Cookie. Protect session cookies with Secure, HttpOnly, an appropriate SameSite policy, narrow domain and path scope, and bounded lifetime. Never log these credential-bearing fields.
Caching and conditional requests
| Header | Use |
|---|---|
| Cache-Control | Defines caching directives such as no-store, no-cache, max-age, private, and immutable. |
| ETag | Provides an opaque validator for a selected representation. |
| Last-Modified | Provides a modification timestamp validator. |
| If-None-Match | Requests a representation only when the ETag differs; supports 304. |
| If-Match | Applies an operation only when the current ETag matches; helps prevent lost updates. |
| Vary | Names request fields that influence selection of a cached response. |
no-cache permits storage but requires validation before reuse; no-store asks caches not to store the response. Hash-named static assets can use a long max-age and immutable, while HTML normally needs revalidation so deployments propagate.
CORS fields
Browsers send Origin. A preflight also sends Access-Control-Request-Method and possibly Access-Control-Request-Headers. The server answers with the relevant Access-Control-Allow-Origin, methods, headers, and credentials policy. Credentialed requests cannot use a wildcard allowed origin. Add Vary: Origin when the policy response changes by origin.
Routing and proxy context
Host or the HTTP/2 authority identifies the target authority. Forwarded fields can describe the original client, host, and scheme across trusted proxies, but applications must trust them only from known infrastructure. An attacker-controlled forwarding header can corrupt redirect URLs, audit data, and security decisions. Prefer a standard Forwarded policy or one carefully documented platform convention.
Security and observability
Strict-Transport-Security instructs browsers to use HTTPS for a period after a secure visit. Content-Security-Policy restricts page resource and execution sources. X-Content-Type-Options: nosniff reduces content-type guessing. Request IDs and trace context help correlate services, but should not contain personal or credential data. Rate-limit field names vary by provider; treat their published contract as authoritative and handle Retry-After in either seconds or HTTP-date form.
Frequently Asked Questions
Are header names case-sensitive?
No. Each field value still has specific syntax.
How do Content-Type and Accept differ?
One describes sent content; the other requests response formats.
Should Authorization be logged?
No. Redact credentials and tokens everywhere.