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>]
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 |
| Manage client-side state | Cookie, Set-Cookie | |
| Extension | Custom or vendor-specific headers | X-Request-ID, X-Forwarded-For |
The following sections document commonly used HTTP headers. Each header includes syntax, allowed values, and practical examples.
Request Request Headers
Headers sent by the client to provide information about the request, client capabilities, and preferences.
| Header | Description | Example |
|---|---|---|
| Host | Target host and port (required in HTTP/1.1) | example.com:8080 |
| Accept | Media types the client can process | text/html, application/json |
| Accept-Language | Preferred languages for response | en-US, en;q=0.9 |
| Accept-Encoding | Compression algorithms supported | gzip, deflate, br |
| User-Agent | Client software identification | Mozilla/5.0 (Windows...) |
| Authorization | Authentication credentials | Bearer <token> |
| Content-Type | Media type of request body | application/json |
| Content-Length | Size of request body in bytes | 1234 |
| Origin | Origin of the request (for CORS) | https://example.com |
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 |
|---|---|---|
| Content-Type | Media type of the response body | text/html; charset=utf-8 |
| Content-Length | Size of response body in bytes | 3495 |
| Content-Encoding | Compression applied to the body | gzip |
| Location | URL for redirects or new resource | https://example.com/new |
| Server | Server software identification | nginx/1.24.0 |
| WWW-Authenticate | Authentication method required (with 401) | Bearer realm="api" |
| Retry-After | When to retry (with 429/503) | 120 |
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 |
|---|---|---|
| Cache-Control | Caching directives for request/response | max-age=3600, public |
| ETag | Unique identifier for resource version | "33a64df5" |
| Last-Modified | Date resource was last changed | Wed, 27 Nov 2024 10:00:00 GMT |
| If-None-Match | Conditional request using ETag | "33a64df5" |
| If-Modified-Since | Conditional request using date | Wed, 27 Nov 2024 10:00:00 GMT |
| Vary | Headers that affect cached response | Accept-Encoding, Accept-Language |
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)
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 |
|---|---|---|
| Access-Control-Allow-Origin | Origins allowed to access resource (CORS) | https://example.com |
| Access-Control-Allow-Methods | HTTP methods allowed (CORS preflight) | GET, POST, PUT |
| Content-Security-Policy | Restrict resources page can load | default-src 'self' |
| Strict-Transport-Security | Force HTTPS connections (HSTS) | max-age=31536000; includeSubDomains |
| X-Content-Type-Options | Prevent MIME type sniffing | nosniff |
| X-Frame-Options | Control iframe embedding | DENY |
| Referrer-Policy | Control Referer header sent | strict-origin-when-cross-origin |
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
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
Cookie Headers
Headers for managing cookies—small pieces of data stored on the client to maintain state across requests.
| Header | Direction | Description |
|---|---|---|
| Cookie | Request | Sends stored cookies to server |
| Set-Cookie | Response | Sets cookie on client |
Set-Cookie
Sets a cookie with optional attributes for security and scope. Modern best practices require Secure, HttpOnly, and SameSite attributes.
Set-Cookie: <name>=<value>[; <attribute>=<value>]...
- Expires=<date>
- Absolute expiration date
- Max-Age=<seconds>
- Relative expiration (preferred over Expires)
- Domain=<domain>
- Domain scope (includes subdomains)
- Path=<path>
- URL path scope
- Secure
- Only send over HTTPS
- HttpOnly
- Not accessible via JavaScript (prevents XSS theft)
- SameSite=Strict|Lax|None
- Cross-site request restrictions (CSRF protection)
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-Forwarded-For | Original client IP (when behind proxy) | Proxies, load balancers, CDNs |
| X-Forwarded-Proto | Original protocol (http/https) | SSL termination at proxy |
| 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.
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