This article lists standard and notable non-standard HTTP header fields.
A core set of fields is standardized by the Internet Engineering Task Force (IETF) in . The Field Names, Header Fields and Repository of Provisional Registrations are maintained by the IANA. Additional fields may be defined by a web application.
In the past, non-standard header field names were prefixed with X- but this convention was deprecated in June 2012 because of the inconveniences it caused when non-standard fields became standard. An earlier restriction on use of Downgraded- was lifted in March 2013.
A few field values can contain comments (i.e. in User-Agent, Server, Via fields), which can be ignored by software.
Many field values may contain a quality (q) key-value pair separated by equals sign, specifying a weight to use in content negotiation. For example, a browser may indicate that it accepts information in German or English, with German as preferred by setting the q value for de higher than that of en, as follows:
Accept-Language: de; q=1.0, en; q=0.5
Request fields This section lists header fields used in a request.
Standard request fields
A-IM
[RFC 3229, permanent] Acceptable instance-manipulations for the request.
For example: A-IM: feed
Accept
[RFC 9110, permanent] Media type(s) that is/are acceptable for the response. See Content negotiation.
For example: Accept: text/html
Accept-Charset
[RFC 9110, permanent] Character sets that are acceptable.
For example: Accept-Charset: utf-8
Accept-Datetime
[RFC 7089, provisional] Acceptable version in time.
For example: Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT
Accept-Encoding
[RFC 9110, permanent] List of acceptable encodings. See HTTP compression.
For example: Accept-Encoding: gzip, deflate
Accept-Language
[RFC 9110, permanent] List of acceptable human languages for response. See Content negotiation.
For example: Accept-Language: en-US
Access-Control-Request-Method, Access-Control-Request-Headers
[permanent] Initiates a request for cross-origin resource sharing with Origin (below).
For example: Access-Control-Request-Method: GET
Authorization
[RFC 9110, permanent] Authentication credentials for HTTP authentication.
For example: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control
[RFC 9111, permanent] Used to specify directives that must be obeyed by all caching mechanisms along the request-response chain. Per HTTP/1.1, the no-cache value allows the browser to tell the server and intermediate caches that it wants a fresh version of the resource. In HTTP/1.0, the Pragma: no-cache header field has the same purpose.
The behavior of no-cache in a response is not specified yet some user agents support it. HTTP/1.1 specifically warns against relying on this behavior.
For example: Cache-Control: no-cache
Connection
[RFC 9110, permanent] Control options for the current connection and list of hop-by-hop request fields. Must not be used with HTTP/2.
For example: Connection: keep-alive Connection: Upgrade
Content-Digest [RFC 9530, Digest Fields] Content-Digest header enables verification of message content integrity by computing a digest over the literal bytes transmitted in the HTTP message. This digest reflects the content after applying transformations like Content-Encoding, matching exactly what travels across the network.
Content-Encoding
[RFC 9110, permanent] The type of encoding used on the data. See HTTP compression.
For example: Content-Encoding: gzip
Content-Length
[RFC 9110, permanent] The length of the request body in octets (8-bit bytes).
For example: Content-Length: 348
Content-MD5
[RFC 1544, 1864, 4021, obsolete] A Base64-encoded binary MD5 sum of the content of the request body.
For example: Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Type
[RFC 9110, permanent] The Media type of the body of the request (used with POST and PUT requests).
For example: Content-Type: application/x-www-form-urlencoded
Cookie
[RFC 2965, 6265, permanent] An HTTP cookie previously sent by the server with Set-Cookie (below).
For example: Cookie: $Version=1; Skin=new;
Date
[RFC 9110, permanent] The date and time at which the message was originated (in "HTTP-date" format as defined by RFC 9110: HTTP Semantics, section 5.6.7 "Date/Time Formats").
For example: Date: Tue, 15 Nov 1994 08:12:31 GMT
Expect
[RFC 9110, permanent] Indicates that particular server behaviors are required by the client.
For example: Expect: 100-continue
Forwarded
[RFC 7239, permanent] Disclose original information of a client connecting to a web server through an HTTP proxy.
For example: Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43 Forwarded: for=192.0.2.43, for=198.51.100.17
From
[RFC 9110, permanent] The email address of the user making the request.
For example: From: [email protected]
Host
[RFC 9110, 9113, permanent] The domain name of the server (for virtual hosting), and the TCP port number on which the server is listening. The port number may be omitted if the port is the standard port for the service requested. Mandatory since HTTP/1.1. If the request is generated directly in HTTP/2, it should not be used.
For example: Host: en.wikipedia.org:8080 Host: en.wikipedia.org
HTTP2-Settings
[RFC 7540, 9113, obsolete] A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly one HTTP2-Settings header field. The HTTP2-Settings header field is a connection-specific header field that includes parameters that govern the HTTP/2 connection, provided in anticipation of the server accepting the request to upgrade.
For example: HTTP2-Settings: token64
If-Match
[RFC 9110, permanent] Only perform the action if the client supplied entity matches the same entity on the server. This is mainly for methods like PUT to only update a resource if it has not been modified since the user last updated it.
For example: If-Match: "737060cd8c284d8af7ad3082f209582d"
If-Modified-Since
[RFC 9110, permanent] Allows a 304 Not Modified to be returned if content is unchanged.
For example: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match
[RFC 9110, permanent] Allows a 304 Not Modified to be returned if content is unchanged, see HTTP ETag.
For example: If-None-Match: "737060cd8c284d8af7ad3082f209582d"
If-Range
[RFC 9110, permanent] If the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity.
For example: If-Range: "737060cd8c284d8af7ad3082f209582d"
If-Unmodified-Since
[RFC 9110, permanent] Only send the response if the entity has not been modified since a specific time.
For example: If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Max-Forwards
[RFC 9110, permanent] Limit the number of times the message can be forwarded through proxies or gateways.
For example: Max-Forwards: 10
Origin
[RFC 6454, permanent] Initiates a request for cross-origin resource sharing (asks server for Access-Control-* response fields).
For example: Origin: http://www.example-social-network.com
Pragma
[RFC 9111, outdated] Implementation-specific fields that may have various effects anywhere along the request-response chain.
For example: Pragma: no-cache
Prefer
[RFC 7240, permanent] Allows client to request that certain behaviors be employed by a server while processing a request.
For example: Prefer: return=representation
Proxy-Authorization
[RFC 9110, permanent] Authorization credentials for connecting to a proxy.
For example: Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range
[RFC 9110, permanent] Request only part of an entity. Bytes are numbered from 0. See Byte serving.
For example: Range: bytes=500-999
Referer
[RFC 9110, permanent] The address of the previous web page from which a link to the currently requested page was followed.
Although the intended term is actually spelled "referrer", the misspelling is in the RFC as well as in most implementations, and is therefore considered correct terminology.
For example: Referer: http://en.wikipedia.org/wiki/Main_Page
TE
[RFC 9110, permanent] The transfer encodings the user agent is willing to accept: the same values as for the response header field Transfer-Encoding can be used, plus the "trailers" value (related to the "chunked" transfer method) to notify the server it expects to receive additional fields in the trailer after the last, zero-sized, chunk. Only trailers is supported in HTTP/2.
For example: TE: trailers, deflate
Trailer
[RFC 9110, permanent] The Trailer general field value indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer coding.
For example: Trailer: Max-Forwards
Transfer-Encoding
[RFC 9110, permanent] The form of encoding used to safely transfer the entity to the user. Currently defined methods are: chunked, compress, deflate, gzip, identity. Must not be used with HTTP/2.
For example: Transfer-Encoding: chunked
User-Agent
[RFC 9110, permanent] The user agent string of the user agent.
For example: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0
Upgrade
[RFC 9110, permanent] Ask the server to upgrade to another protocol. Must not be used in HTTP/2.
For example: Upgrade: h2c, HTTPS/1.3, IRC/6.9, RTA/x11, websocket
Via
[RFC 9110, permanent] Informs the server of proxies through which the request was sent.
For example: Via: 1.0 fred, 1.1 example.com (Apache/1.1)
Warning
[RFC 7234, 9111, obsolete] A warning about a possible problem with the entity body. Since this header is often neither sent by servers nor acknowledged by clients, this header and its codes were obsoleted by the HTTP Working Group in 2022 with .
The following caching related warning codes were specified under RFC 7234.
110 Response is Stale The response provided by a cache is stale (the content's age exceeds a maximum age set by a Cache-Control header or heuristically chosen lifetime).
111 Revalidation Failed The cache was unable to validate the response, due to an inability to reach the origin server.
112 Disconnected Operation The cache is intentionally disconnected from the rest of the network.
113 Heuristic Expiration The cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 hours.
199 Miscellaneous Warning Arbitrary, non-specific warning. The warning text may be logged or presented to the user.
214 Transformation Applied Added by a proxy if it applies any transformation to the representation, such as changing the content encoding, media type or the like.
299 Miscellaneous Persistent Warning Same as 199, but indicating a persistent warning.
For example: Warning: 199 Miscellaneous warning
Common non-standard request fields
Upgrade-Insecure-Requests Tells a server which (presumably in the middle of a HTTP -> HTTPS migration) hosts mixed content that the client would prefer redirection to HTTPS and can handle Content-Security-Policy: upgrade-insecure-requests
For example: Upgrade-Insecure-Requests: 1
X-Requested-With Mainly used to identify Ajax requests (most JavaScript frameworks send this field with value of XMLHttpRequest); this also identifies Android apps using WebView.
For example: X-Requested-With: XMLHttpRequest
DNT
Requests a web application to disable their tracking of a user. This is Mozilla's version of the X-Do-Not-Track header field (since Firefox 4.0 Beta 11). Safari and IE9 also have support for this field. On March 7, 2011, a draft proposal was submitted to IETF.IETF Do Not Track: A Universal Third-Party Web Tracking Opt Out March 7, 2011 The W3C Tracking Protection Working Group is producing a specification.W3C Tracking Preference Expression (DNT), January 26, 2012
For example:
DNT: 1 (Do Not Track Enabled)
DNT: 0 (Do Not Track Disabled)
X-Forwarded-For