HTTP Header Fields
HTTP - Header Fields
Section titled “HTTP - Header Fields”HTTP header fields are components of the header section of request and response messages. They define the operating parameters of an HTTP transaction. Header names are case-insensitive. Headers are colon-separated name-value pairs.
Headers can be conceptually grouped (though newer RFCs like RFC 7230-7231 and RFC 9110 refine these categories):
- Message Metadata Headers (formerly General Headers): Apply to the message as a whole, such as
DateorConnection. - Request Headers: Contain more information about the resource to be fetched or about the client itself, such as
User-Agent,Accept, orHost. - Response Headers: Hold additional information about the response, like its location, or about the server itself, such as
Server,Allow, orSet-Cookie. - Representation Data Headers (formerly Entity Headers): Contain information about the body of the resource, like its content type (
Content-Type) or encoding (Content-Encoding).
General Headers / Message Metadata Headers
Section titled “General Headers / Message Metadata Headers”Cache-Control
Section titled “Cache-Control”Specifies directives for caching mechanisms in both requests and responses. It is a comma-separated list of directives.
Syntax: `Cache-Control: directive1, directive2, ...`Common directives:
- Request:
no-cache(revalidate with server),no-store(don’t store),max-age=seconds,max-stale[=seconds],min-fresh=seconds. - Response:
public(can be cached by any cache),private(intended for a single user),no-cache(revalidate before use),no-store,must-revalidate,proxy-revalidate,max-age=seconds,s-maxage=seconds(for shared caches),immutable,stale-while-revalidate=seconds,stale-if-error=seconds.
Example: `Cache-Control: no-cache, max-age=0, must-revalidate`Connection
Section titled “Connection”Controls whether the network connection stays open after the current transaction finishes. Also used for hop-by-hop headers.
Syntax: `Connection: "close" | "keep-alive" | header-name`Connection: close signals that the connection will be closed after this request/response. HTTP/1.1 defaults to keep-alive. HTTP/2 and HTTP/3 manage connections differently (multiplexing over a single connection) and generally don’t use this header for connection management itself.
The date and time at which the message was originated, in RFC 1123 (IMF-fixdate) format (GMT/UTC).
Example: `Date: Tue, 22 Feb 2022 10:00:00 GMT`Pragma
Section titled “Pragma”An HTTP/1.0 header for backward compatibility, primarily Pragma: no-cache. Its behavior is not reliably specified. For caching, Cache-Control is preferred.
Trailer
Section titled “Trailer”Allows the sender to include additional fields in a trailer, appended after the final chunk of a message encoded with chunked transfer-coding. The Trailer header lists the names of the header fields present in the trailer.
Example: `Trailer: ETag, X-Checksum` (sent in main headers if `Transfer-Encoding: chunked` is used)Transfer-Encoding
Section titled “Transfer-Encoding”Specifies the form of encoding used to safely transfer the payload body to the user. chunked is a common value for HTTP/1.1 when the content length is not known in advance. This is a hop-by-hop header. HTTP/2 and HTTP/3 do not use this mechanism for chunking data.
Example: `Transfer-Encoding: chunked`Upgrade
Section titled “Upgrade”Allows the client to specify other communication protocols it would like to use if the server supports them (e.g., upgrading from HTTP/1.1 to HTTP/2, or to WebSockets). Requires a 101 Switching Protocols response if successful.
Example: `Upgrade: h2c, websocket` (h2c for HTTP/2 over cleartext)Added by proxies (both forward and reverse) to indicate intermediate protocols and recipients between the user agent and the origin server, or between the origin server and the client. Used for message tracking and loop detection.
Example: `Via: 1.1 example-proxy.com (Squid/3.5.27), 1.0 internal-gw`Warning (Deprecated)
Section titled “Warning (Deprecated)”Carried additional information about the status or transformation of a message. This header is now obsolete (RFC 7234).
Client Request Headers
Section titled “Client Request Headers”Accept
Section titled “Accept”Informs the server about the types of media (MIME types) the client can process, often with quality factors (q-values).
Example: `Accept: application/json, text/plain;q=0.9, */*;q=0.8`Accept-Charset
Section titled “Accept-Charset”Indicates which character sets are acceptable for the response. Less common now due to UTF-8’s prevalence.
Example: `Accept-Charset: utf-8, iso-8859-1;q=0.5`Accept-Encoding
Section titled “Accept-Encoding”Restricts the content encodings (compressions) that are acceptable in the response.
Example: `Accept-Encoding: gzip, deflate, br`Accept-Language
Section titled “Accept-Language”Restricts the set of natural languages that are preferred as a response.
Example: `Accept-Language: en-US,en;q=0.9,fr;q=0.8`Authorization
Section titled “Authorization”Contains credentials for authenticating the client with the server.
Examples: `Authorization: Basic dXNlcjpwYXNzd29yZA==` (Base64 encoded username:password)`Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...` (Bearer token, e.g., JWT)Cookie
Section titled “Cookie”Contains HTTP cookies previously sent by the server with Set-Cookie.
Syntax: `Cookie: name1=value1; name2=value2`Expect
Section titled “Expect”Indicates expectations that need to be met by the server for the request to be processed successfully. The only common expectation is 100-continue, which asks the server to acknowledge if it’s okay to send the request body.
Example: `Expect: 100-continue`From (Rarely used)
Section titled “From (Rarely used)”Contains an Internet email address for the human user who controls the requesting user agent. Rarely used due to privacy concerns.
Specifies the domain name of the server (for virtual hosting), and optionally the TCP port number. Mandatory for HTTP/1.1.
Example: `Host: www.example.com` or `Host: api.example.com:8080`If-Match / If-None-Match / If-Modified-Since / If-Unmodified-Since / If-Range
Section titled “If-Match / If-None-Match / If-Modified-Since / If-Unmodified-Since / If-Range”These are conditional request headers. They make the request method conditional based on resource metadata (like ETag or Last-Modified date). Used for cache validation, optimistic concurrency control, or resuming downloads.
Examples:`If-None-Match: "xyzzy"` (GET if ETag is different)`If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT` (GET if modified since this date)Max-Forwards
Section titled “Max-Forwards”Used with TRACE and OPTIONS to limit the number of proxies or gateways that can forward the request.
Proxy-Authorization
Section titled “Proxy-Authorization”Allows the client to identify itself (or its user) to a proxy which requires authentication.
Requests only part of an entity. Bytes are numbered from 0. Used for resuming interrupted downloads or fetching parts of a large file.
Example: `Range: bytes=0-499` (first 500 bytes)`Range: bytes=500-` (from byte 500 to end)Referer (Misspelled in spec, should be ‘Referrer’)
Section titled “Referer (Misspelled in spec, should be ‘Referrer’)”The address of the previous web page from which a link to the currently requested page was followed. Referrer-Policy header can control this.
Specifies the transfer encodings the user agent is willing to accept. Typically used for trailers in chunked encoding.
Example: `TE: trailers, deflate`User-Agent
Section titled “User-Agent”Contains a characteristic string that allows the network protocol peers to identify the application type, operating system, software vendor or software version of the requesting software user agent.
Example: `User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36`Server Response Headers
Section titled “Server Response Headers”Accept-Ranges
Section titled “Accept-Ranges”Indicates if the server supports range requests for a resource, and if so, what unit (e.g., bytes).
Example: `Accept-Ranges: bytes` or `Accept-Ranges: none`The age the object has been in a proxy cache in seconds.
An identifier for a specific version of a resource. Allows caches to be more efficient and saves bandwidth, as a web server does not need to resend a full response if the content has not changed (If-None-Match).
Example: `ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"` (strong ETag)`ETag: W/"0815"` (weak ETag)Location
Section titled “Location”Used in redirection (3xx responses) to specify the new URL, or in 201 Created responses to specify the URL of the newly created resource.
Proxy-Authenticate
Section titled “Proxy-Authenticate”Must be included as part of a 407 (Proxy Authentication Required) response, defining the authentication method the proxy requires.
Retry-After
Section titled “Retry-After”Can be used with a 503 (Service Unavailable) or 429 (Too Many Requests) response to indicate how long the service is expected to be unavailable or how long to wait before retrying.
Example: `Retry-After: 120` (seconds) or `Retry-After: Fri, 31 Dec 2022 23:59:59 GMT`Server
Section titled “Server”Contains information about the software used by the origin server. Can be suppressed for security reasons (information disclosure).
Example: `Server: nginx/1.21.6`Set-Cookie
Section titled “Set-Cookie”Sends cookies from the server to the user agent. The user agent saves the cookie and sends it back on subsequent requests to the same server.
Syntax: `Set-Cookie: NAME=VALUE; [Expires=date;] [Max-Age=seconds;] [Domain=domain;] [Path=path;] [Secure;] [HttpOnly;] [SameSite=Strict|Lax|None]`Multiple cookies require multiple `Set-Cookie` headers.Example: `Set-Cookie: session_id=abc123xyz; Path=/; Secure; HttpOnly; SameSite=Lax`Strict-Transport-Security (HSTS)
Section titled “Strict-Transport-Security (HSTS)”Instructs user agents (browsers) to only access the site using HTTPS. Helps prevent protocol downgrade attacks and cookie hijacking.
Example: `Strict-Transport-Security: max-age=31536000; includeSubDomains`Determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server. It lists the request headers that influenced the generation of this response.
Example: `Vary: Accept-Encoding, User-Agent`WWW-Authenticate
Section titled “WWW-Authenticate”Must be included in 401 (Unauthorized) response messages. Defines the authentication method(s) that should be used to access the resource.
Example: `WWW-Authenticate: Basic realm="Restricted Area"``WWW-Authenticate: Bearer realm="example", error="invalid_token", error_description="The access token expired"`Representation Data Headers (formerly Entity Headers)
Section titled “Representation Data Headers (formerly Entity Headers)”Lists the set of HTTP methods supported by a resource. Often sent with 405 (Method Not Allowed) responses.
Example: `Allow: GET, HEAD, PUT, OPTIONS`Content-Encoding
Section titled “Content-Encoding”Specifies the encoding transformations (e.g., compression) that have been applied to the entity-body.
Example: `Content-Encoding: gzip` or `Content-Encoding: br`Content-Language
Section titled “Content-Language”Describes the natural language(s) of the intended audience for the enclosed entity.
Example: `Content-Language: en-US, fr-CA`Content-Length
Section titled “Content-Length”Indicates the size of the entity-body, in decimal number of octets (bytes).
Example: `Content-Length: 3495`Content-Location (Less common)
Section titled “Content-Location (Less common)”Indicates an alternate location for the returned data (sometimes used when content negotiation has occurred).
Content-MD5 (Deprecated)
Section titled “Content-MD5 (Deprecated)”A Base64-encoded binary MD5 digest of the entity-body for checking message integrity. Largely deprecated in favor of Digest or relying on TLS for integrity.
Content-Range
Section titled “Content-Range”Sent with a partial entity-body (206 Partial Content status) to specify where in the full entity-body the partial body should be applied.
Example: `Content-Range: bytes 21010-47021/47022` (bytes 21010-47021 of a total 47022)Content-Type
Section titled “Content-Type”Indicates the media type (MIME type) of the entity-body sent to the recipient.
Example: `Content-Type: application/json; charset=utf-8``Content-Type: image/png`Content-Security-Policy (CSP)
Section titled “Content-Security-Policy (CSP)”A powerful security header that helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks by allowing web administrators to control the resources the user agent is allowed to load.
Example: `Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com`Expires (Legacy)
Section titled “Expires (Legacy)”Gives the date/time after which the response is considered stale. Cache-Control: max-age is preferred for HTTP/1.1 and newer.
Last-Modified
Section titled “Last-Modified”The date and time at which the origin server believes the resource was last modified. Used as a validator for caching.
Example: `Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT`