liminfoHTTP Header Reference
Free reference guide: HTTP Header Reference
About HTTP Header Reference
The HTTP Header Reference is a searchable quick-reference for the most important HTTP request and response headers used in modern web development. It organizes 28 headers into seven functional categories — Auth, Cache, Content, CORS, Security, Cookies, and Other — so web developers, backend engineers, and DevOps teams can immediately find the correct header name, syntax, and a real-world example without consulting RFC documents.
Backend developers use this reference to configure server responses correctly: setting Cache-Control with max-age and public/private directives, enabling conditional requests with ETag and If-None-Match, enforcing HTTPS with Strict-Transport-Security (HSTS), configuring CORS preflight with Access-Control-Allow-Origin and Access-Control-Max-Age, and setting secure cookies with HttpOnly, Secure, and SameSite attributes. Security engineers reference the CSP, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy headers for hardening web applications.
Content is organized to reflect the typical areas where developers look up headers: authentication flows (Bearer tokens, WWW-Authenticate challenges), HTTP caching strategies (ETags, conditional GETs, Expires), content negotiation (Accept, Content-Type, Content-Encoding with gzip/br), CORS configuration for cross-origin API calls, web security hardening, and cookie management. Each entry shows the header name, a concise description of its purpose, and a concrete example value.
Key Features
- Authentication headers: Authorization (Bearer, Basic), WWW-Authenticate challenges, Proxy-Authorization
- Cache headers: Cache-Control directives, ETag resource versioning, If-None-Match and If-Modified-Since conditional requests, Expires
- Content headers: Content-Type with charset, Content-Length, Content-Encoding (gzip), Accept and Accept-Encoding negotiation
- CORS headers: Access-Control-Allow-Origin, Allow-Methods, Allow-Headers, Max-Age for preflight caching
- Security headers: X-Frame-Options, Content-Security-Policy, Strict-Transport-Security (HSTS), X-Content-Type-Options, Referrer-Policy
- Cookie headers: Cookie request header, Set-Cookie with Path, HttpOnly, Secure, SameSite attributes
- Utility headers: User-Agent, Host, Location for redirects, X-Request-ID for distributed tracing
- Real example values for every header — copy-paste ready for Nginx, Express, Django, or any HTTP server
Frequently Asked Questions
What is the difference between Authorization and WWW-Authenticate headers?
Authorization is a request header sent by the client, carrying credentials such as a Bearer JWT token or Basic base64-encoded username:password. WWW-Authenticate is a response header sent by the server with a 401 Unauthorized status, telling the client what authentication scheme is required (e.g., Bearer realm="api"). The server challenges first; the client responds with Authorization on the next request.
How does HTTP caching with ETag and If-None-Match work?
The server sends an ETag header with a unique hash or version identifier for the resource. On subsequent requests the client sends If-None-Match: "hash". If the resource has not changed the server returns 304 Not Modified with no body, saving bandwidth. If it has changed the server returns 200 with the new ETag. Cache-Control: max-age controls how long the client uses the cached copy before revalidating.
What is Content-Security-Policy (CSP) and how do I configure it?
CSP is a security response header that restricts what resources the browser is allowed to load for a page. The directive default-src defines a fallback for all resource types. Use script-src to whitelist JavaScript sources, style-src for CSS, img-src for images, and connect-src for fetch/XHR targets. A strict starting policy is Content-Security-Policy: default-src 'self', which only allows same-origin resources. Use report-uri or report-to to receive violation reports.
What is HSTS and why is it important?
Strict-Transport-Security (HSTS) tells browsers to only connect to your site over HTTPS, even if the user types http://. The max-age directive sets how long (in seconds) to enforce this. includeSubDomains extends the policy to all subdomains. preload allows inclusion in browser preload lists, meaning the browser enforces HTTPS even on the very first visit. This prevents SSL stripping attacks and accidental HTTP connections.
How do CORS headers work for cross-origin API requests?
When a browser makes a cross-origin request, it first sends a preflight OPTIONS request. The server must respond with Access-Control-Allow-Origin (the allowed origin or *), Access-Control-Allow-Methods (GET, POST, etc.), and Access-Control-Allow-Headers (Content-Type, Authorization, etc.). Access-Control-Max-Age caches the preflight result so browsers do not send repeated OPTIONS requests. For credentialed requests (cookies), Access-Control-Allow-Credentials: true is required and Allow-Origin cannot be *.
What do the Set-Cookie attributes HttpOnly, Secure, and SameSite do?
HttpOnly prevents JavaScript (document.cookie) from accessing the cookie, protecting against XSS theft of session cookies. Secure restricts the cookie to HTTPS connections only. SameSite=Strict blocks the cookie from being sent in cross-site requests entirely (preventing CSRF). SameSite=Lax allows the cookie on top-level navigation (clicking a link) but not on embedded cross-site requests. Use all three attributes on authentication session cookies.
What is the difference between Cache-Control: no-cache and no-store?
no-cache does not mean "do not cache" — it means the client must revalidate with the server before using a cached copy (sending If-None-Match or If-Modified-Since). The response can still be cached locally. no-store means the response must never be stored anywhere — not in browser cache, not in CDN or proxy caches. Use no-store for sensitive data like bank account pages; use no-cache for pages that change frequently but can benefit from conditional GET revalidation.
What is Referrer-Policy and which value should I use?
Referrer-Policy controls how much information the Referer request header reveals about the origin page when navigating to another page. strict-origin-when-cross-origin (the modern browser default) sends the full URL for same-origin requests and only the origin for cross-origin requests, and nothing for HTTP-to-HTTPS downgrades. no-referrer sends no Referer at all (maximum privacy). same-origin sends the full URL only for same-origin requests. Use strict-origin-when-cross-origin as a sensible default for most sites.