List of HTTP header fields
HTTP |
---|
![]() |
Request methods |
Header fields |
Response status codes |
Security access control methods |
Security vulnerabilities |
HTTP header fields are a list of strings sent and received by both the client program and server on every HTTP request and response. These headers are usually invisible to the end-user and are only processed or logged by the server and client applications. They define how information sent/received through the connection are encoded (as in Content-Encoding), the session verification and identification of the client (as in browser cookies, IP address, user-agent) or their anonymity thereof (VPN or proxy masking, user-agent spoofing), how the server should handle data (as in Do-Not-Track or Global Privacy Control), the age (the time it has resided in a shared cache) of the document being downloaded, amongst others.
General format
In HTTP version 1.x, header fields are transmitted after the request line (in case of a request HTTP message) or the response line (in case of a response HTTP message), which is the first line of a message. Header fields are colon-separated key-value pairs in clear-text string format, terminated by a carriage return (CR) and line feed (LF) character sequence. The end of the header section is indicated by an empty field line, resulting in the transmission of two consecutive CR-LF pairs. In the past, long lines could be folded into multiple lines; continuation lines are indicated by the presence of a space (SP) or horizontal IETF|date=|access-|first2=H. }}</ref> (HTTP/2) or QPACK (HTTP/3), which both provide efficient header compression. The request or response line from HTTP/1 has also been replaced by several pseudo-header fields, each beginning with a colon (:
).
Field names
A core set of fields is standardized by the Internet Engineering Task Force (IETF) in RFC 9110 and 9111. The Field Names, Header Fields and Repository of Provisional Registrations are maintained by the IANA. Additional field names and permissible values may be defined by each application.
Header field names are case-insensitive.[1] This is in contrast to HTTP method names (GET, POST, etc.), which are case-sensitive.[2]
HTTP/2 makes some restrictions on specific header fields (see below).
Non-standard header fields were conventionally marked by prefixing the field name with X-
but this convention was deprecated in June 2012 because of the inconveniences it caused when non-standard fields became standard.[3] An earlier restriction on use of Downgraded-
was lifted in March 2013.[4]
Field values
A few fields can contain comments (i.e. in User-Agent, Server, Via fields), which can be ignored by software.[5]
Many field values may contain a quality (q) key-value pair separated by equals sign, specifying a weight to use in content negotiation.[6] 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
Size limits
The standard imposes no limits to the size of each header field name or value, or to the number of fields. However, most servers, clients, and proxy software impose |title=core - Apache HTTP Server |publisher=Httpd.apache.org |access-date=2012-03-13}}</ref>
Request fields
Standard request fields
Name | Description |
Common non-standard request fields
Response fieldsStandard response fields
Common non-standard response fields
Effects of selected fieldsAvoiding cachingIf a web server responds with The header field 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 See alsoReferences
As of this edit, this article uses content from "What is the X-REQUEST-ID http header?", authored by Stefan Kögl at Stack Exchange, which is licensed in a way that permits reuse under the Creative Commons Attribution-ShareAlike 3.0 Unported License, but not under the GFDL. All relevant terms must be followed.
As of this edit, this article uses content from "Why does ASP.NET framework add the 'X-Powered-By:ASP.NET' HTTP Header in responses?", authored by Adrian Grigore at Stack Exchange, which is licensed in a way that permits reuse under the Creative Commons Attribution-ShareAlike 3.0 Unported License, but not under the GFDL. All relevant terms must be followed.
External links
|
---|