Quick reference to HTTP headers

This document lists all the message headers defined in the HTTP/1.1 protocol, with short descriptions. In the list, the name of the header is a link to its definition in the protocol itself. Note that some of the headers are also used in Internet E-mail and in Usenet; see Quick reference to Internet message headers.

The kind of the header is indicated as follows:

Accept [Request]

Specifies which Internet media types are acceptable for the response and to assign preferences to them.

Accept-Charset [Request]

Specifies which character encodings (confusingly called "charsets") are acceptable for the response and to assign preferences to them.

Accept-Encoding [Request]

Specifies which data format tranformations, confusingly called content (en)codings, such as compression mechanisms, are acceptable for the response and to assign preferences to them.

Accept-Language [Request]

Specifies which natural languages are acceptable for the response and to assign preferences to them. Useful for language negotation.

Accept-Ranges [Response]

Indicates the server's acceptance of range requests for a resource.

Age [Response]

Gives the sender's estimate of the amount of time since the response (or its revalidation) was generated at the origin server.

Allow [Entity]

Lists the set of methods supported by the resource identified by the Request-URI. The purpose is to inform the recipient of valid methods associated with the resource.

Authorization [Request]

Consists of credentials containing the authentication information of the client for the realm of the resource being requested

Cache-Control [General]

Specifies directives that must be obeyed by all caching mechanisms along the request/response chain.

Connection [General]

Specifies options that are desired for the particular connection and must not be communicated by proxies over further connections.

Content-Encoding [Entity]

Used as a modifier to the media-type, to indicate what additional data format transformations such as compression have been applied to the entity-body.

Content-Language [Entity]

Specifies the natural language(s) of the intended audience for the enclosed entity. But according to RFC 3282, specifies the language(s) of the entity.

Content-Length [Entity]

Indicates the size (in octets) of the entity-body that is sent or that would have been sent if it has reen requested.

Content-Location [Entity]

Supplies the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI.

Content-MD5 [Entity]

An MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body.

Content-Range [Entity]

Sent with a partial entity-body to specify where in the full entity-body the partial body should be applied.

Content-Type [Entity]

Specifies the Internet media type of the entity-body that is sent or would have been sent if requested. Often includes a charset parameter specifying the character encoding.

Date [General]

Date and time at which the message was originated.

ETag [Response]

Provides the current value of the entity tag for the requested variant, for caching purposes.

Expect [Request]

Indicates that particular server behaviors are required by the client.

Expires [Entity]

Gives the date/time after which the response is considered stale, for caching purposes.

From [Request]

The Internet e-mail address for the human user who controls the requesting browser or other client.

Host [Request]

Specifies the Internet host and port number of the resource being requested. Obligatory in all HTTP/1.1 requests.

If-Match [Request]

Used with a method to make it conditional: a client that has previously obtained entities can verify that one of those entities is current by including a list of their associated entity tags in the If-Match header field.

If-Modified-Since [Request]

Used with a method to make it conditional: if the requested variant has not been modified since the time specified in this field, the server will not return the entity but information about this fact.

If-None-Match [Request]

Used with a method to make it conditional: a client that has previously obtained entities can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field.

If-Range [Request]

Used together with Range to say: "if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity".

If-Unmodified-Since [Request]

Used with a method to make it conditional: if the requested variant has been modified since the time specified in this field, the server will not perform the requested operation but information about this fact.

Last-Modified [Entity]

Indicates the date and time at which the origin server believes the variant was last modified.

Location [Response]

Redirects the recipient to a location other than the Request-URI for completion of the request or identification of a new resource.

Max-Forwards [Request]

Provides a mechanism with the TRACE and OPTIONS methods to limit the number of proxies or gateways that can forward the request to the next inbound server.

Pragma [General]

Used to include implementation-specific directives that might (optionally) apply to any recipient along the request/response chain.

Proxy-Authenticate [Response]

Included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI.

Proxy-Authorization [Request]

Used by a client to identify itself (or its user) to a proxy which requires authentication.

Range [Request]

Restricts the request to some part(s), specified as range(s) of octets, in the resource.

Referer [Request]

Used by a client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained.

Retry-After [Response]

Indicates how long the service is expected to be unavailable to the requesting client.

Server [Response]

Contains information about the software used by the origin server to handle the request.

TE [Request]

Indicates what extension transfer-codings the client is willing to accept in the response and whether or not it is willing to accept trailer fields in a chunked transfer-coding.

Trailer [General]

Indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer-coding.

Transfer-Encoding [General]

Indicates what (if any) type of transformation has been applied to the message body in order to safely transfer it between the sender and the recipient. This differs from the Content-Encoding in that the transfer-coding is a property of the message, not of the entity.

Upgrade [General]

Used by a client to specify what additional communication protocols it supports and would like to use if the server finds it appropriate to switch protocols. The server uses the Upgrade header to indicate which protocol(s) are being switched.

User-Agent [Request]

Contains information about the user agent (client) originating the request

Vary [Response]

Indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation.

Via [General]

Used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses.

Warning [General]

Carries additional information about the status or transformation of a message which might not be reflected in the message.

WWW-Authenticate [Response]

Used in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.

There might be other headers in use as well, but with no authoritative definition.

You could use e.g. Tipjar's tester to see what headers your browser actually sends. It displays a collection of "environment variables", and those beginning with HTTP_ derive from HTTP headers, as per CGI rules; e.g., HTTP_ACCEPT corresponds to the Accept header. And you could use e.g. Delorie's HTTP Viewer to see what headers a Web server actually sends, in response to a simple request.