This article includes a list of references, related reading or external links, but its sources remain unclear because it lacks inline citations. Please improve this article by introducing more precise citations. (September 2010)

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (September 2010)

HTTP header fields are components of the message header of requests and responses in the Hypertext Transfer Protocol (HTTP). They define the operating parameters of an HTTP transaction.

The header fields are transmitted after the request or response line, the first line of a message. Header fields are colon-separated name-value pairs in clear-text string format, terminated by a carriage return (CR) and line feed (LF) character sequence. The end of the header fields is indicated by an empty field, resulting in the transmission of two consecutive CR-LF pairs. Long lines can be folded into multiple lines; continuation lines are indicated by presence of space (SP) or horizontal tab (HT) as first character on next line. ^[1] Few fields can also contain comments (i.e. in. User-Agent, Server, Via fields), which can be ignored by software.^[2]

A core set of fields is standardized by the Internet Engineering Task Force (IETF) in RFC 2616 and other updates and extension documents (e.g., RFC 4229), and must be implemented by all HTTP-compliant protocol implementations. Additional field names and permissible values may be defined by each application.

A permanent registry of headers^[3] and repository of provisional registrations^[4] is maintained by the IANA.

Many field values may contain a quality (q) key-value pair, specifying a weight to use in content negotiation.^[5]

There is no limits to size of each header field name or value, or number of headers in standard itself. However most servers, clients and proxy software impose some limits for practical and security reasons. For example Apache 2.3 server by default limits each header size to 8190 bytes, and there can be at most 100 headers in single request.^[6]

Requests[link]

Common non-standard request headers[link]

Non-standard header fields are conventionally marked by prefixing the field name with X- .^[10]

Responses[link]

Common non-standard response headers[link]

Non-standard header fields are conventionally marked by prefixing the field name with X- .

Effects of selected HTTP header fields[link]

Avoiding caching[link]

If a web server responds with Cache-Control: no-cache then a web browser or other caching system must not use the response to satisfy subsequent responses without first checking with the originating server. This header field is part of HTTP version 1.1, and is ignored by some caches and browsers. It may be simulated by setting the Expires HTTP version 1.0 header field value to a time earlier than the response time.

The request that a resource should not be cached is no guarantee that it will not be written to disk. In particular, the HTTP/1.1 definition draws a distinction between history stores and caches. If the user navigates back to a previous page a browser may still show you a page that has been stored on disk in the history store. This is correct behavior according to the specification. Many user agents show different behavior in loading pages from the history store or cache depending on whether the protocol is HTTP or HTTPS.

The header field Cache-Control: no-store is intended to instruct a browser application to make a best effort not to write it to disk.

The Pragma: no-cache header field is an HTTP/1.0 header intended for use in requests. It is a means for the browser to tell the server and any intermediate caches that it wants a fresh version of the resource, not for the server to tell the browser not to cache the resource. Some user agents do pay attention to this header in responses, but the HTTP/1.1 RFC specifically warns against relying on this behavior.

See also[link]

• HTTP ETag
• HTTP headers
• List of HTTP status codes

References[link]

External links[link]

• RFC 4229: HTTP Header Field Registrations. December 2005 (contains a more complete list of HTTP headers)
• RFC 2616: IETF HTTP/1.1 RFC
• RFC 2965: IETF HTTP State Management Mechanism RFC
• HTTP/1.1: Header Field Definitions
• HTTP/1.1 headers from a web server point of view
• HTTP Request Header Viewer
• HTTP Response Header Viewer - Retrieves the HTTP response headers of any domain.
• HTTP Header Viewer with Google App Engine
• Internet Explorer and Custom HTTP Headers - EricLaw's IEInternals - Site Home - MSDN Blogs
• crwlr.net - HTTP Header index
• HTTP Header with Privacyinfo - Display your HTTP request and response headers