List of HTTP header fields
HTTP header fields (often inaccurate HTTP headers ) are part of the Hypertext Transfer Protocol (HTTP) - protocol header and transmit the key for transferring files over HTTP parameters and arguments z. B. Desired language or character set and often information about the client. “HTTP header” is often used synonymously, but has ambiguity between a single field in the header block and the entire header block. The term "header" is used here for the entirety of the header fields and the term "header field" according to RFC 2616 is used for a single line in the header .
The individual fields in the header are always transmitted after the request line (e.g. GET /index.html HTTP/1.1
) or the response line (if successful HTTP/1.1 200 OK
). The lines of the header themselves are key-value pairs, separated by colons (e.g. Content-type: text/html
). The names are firmly specified by various standards . The end of the line is marked by the character combination <CR><LF>
( carriage return , line feed ), the end of the header is indicated by a blank line, which is the <CR><LF><CR><LF>
same as the transmission of .
Most of the header fields are standardized by the IETF's RFCs , e.g. B. the "core" in RFC 2616 and extensions in RFC 4229 . The standards set out in these specifications must be present in all HTTP implementations. In addition, manufacturers or projects can add additional extensions to their software (for which there is no guarantee that they will be correctly "understood" by all implementations). Depending on the product, the individual user or administrator can also define their own header fields.
Since security-critical information such as the web server used including the version may be visible in the HTTP response header (e.g. Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
), it is recommended that this information be hidden.
The permanent and provisional header fields can be viewed at the Internet Assigned Numbers Authority (IANA).
Request header fields
The request fields appear in the header of the request from an HTTP client (e.g. browser ) to a web server . They include e.g. B. Information about the requested resource and the MIME types accepted by the client .
For precise research, reading RFC 2616 , Chapter 14 (p. 62ff) is recommended (chapter number in the second column of the table).
Name of the field | Chapter in RFC 2616 | description | example |
---|---|---|---|
Accept | 14.1 | What types of content the client can process. If the server is unable to provide a type of content that the client will accept, it can either 406 Not acceptable send the HTTP status code or use any type of content to encode the requested information. If the Accept field is missing, this means that the client accepts all content types. In this example, if the server can send the content of the requested resource to the client both as HTML and as an image in GIF format, the Accept header of the request results in HTML being selected as the content type of the response. |
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
|
Accept charset | 14.2 | Which character sets the client can display and thus want to receive. The appropriate file is found using content negotiation (e.g. with Apache mod_negotiation ). |
Accept-Charset: utf-8
|
Accept-Encoding | 14.3 | Which compressed formats the client supports. A suitably compressed file is delivered via content negotiation. |
Accept-Encoding: gzip,deflate
|
Accept-Language | 14.4 | Which languages the client accepts. If the server is set up appropriately and the language versions are available, the appropriate file is delivered via content negotiation. |
Accept-Language: en-US
|
Authorization | 14.8 | Authentication data for HTTP authentication methods |
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
|
Cache control | 14.9 | Is used to define options that must be followed by all caching mechanisms along the request / response chain. |
Cache-Control: no-cache
|
Connection | 14.10 | What type of connection the client prefers. |
Connection: close
|
Cookie | an HTTP cookie, previously from the server Set-Cookie has been set |
Cookie: $Version=1; Skin=new;
|
|
Content-Length | 14.13 | Length of the body in bytes |
Content-Length: 348
|
Content-MD5 | 14.15 | A Base64 encoded MD5 checksum of the body |
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
|
Content-Type | 14.17 | MIME type of the body (used here for POST and PUT operations) |
Content-Type: application/x-www-form-urlencoded
|
Date | 14.18 | Date and time when the request was sent |
Date: Tue, 15 Nov 1994 08:12:31 GMT
|
Expect | 14.20 | Shows what behavior the client expects from the server. If the server does not understand this header or cannot fulfill the behavior, it must 417 Expectation Failed send the code . The client sends in Expect: 100-continue when it only sends the header but not the body of a (very large) request and then expects the HTTP status code 100 Continue as confirmation in order to be able to send a possibly very large request. The purpose is to make sure that the server will accept the (very large) request. |
Expect: 100-continue
|
Forwarded | RFC 7239 | Serves to identify the forwarding reverse proxy (load balancer), the originally requesting client, the originally used protocol and the originally requested host and port, as a reverse proxy (load balancer) changes this information depending on the function. |
Forwarded: by="10.0.0.1"; for="192.168.0.1:4711"; proto=http; host="www.example.com:8080"
|
From | 14.22 | E-mail address of the user who made the request (uncommon today). RFC 2616 says that the may From: not be sent without the express permission of the user. |
From: user@example.com
|
Host | 14.23 | Domain name of the server, mandatory since HTTP / 1.1 and required for name-based hosts . If this header is missing, the server must 400 Bad Request respond with the definition . |
Host: en.wikipedia.org
|
If match | 14.24 | Only take action if the code sent matches the code on the server. |
If-Match: "737060cd8c284d8af7ad3082f209582d"
|
If-Modified-Since | 14.25 | Allows the server 304 Not Modified to send the status code if nothing has changed since the specified time. |
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
|
If-none-match | 14.26 | If the content is unchanged (verified by ETags), this allows the server to send the status code 304 Not Modified as a response, see HTTP ETag
|
If-None-Match: "737060cd8c284d8af7ad3082f209582d"
|
If range | 14.27 | If the client has a part of a file from the server in the cache that has not changed on the server, only send the remaining part; otherwise send the whole file. |
If-Range: "737060cd8c284d8af7ad3082f209582d"
|
If-Unmodified-Since | 14.28 | Send the page only if it has not been changed since the specified time. If the page was changed, the server sends the status code 412 Precondition Failed ; if the page is unchanged, the response does not differ from a normal response and the client receives a 2xx status code ( Success ). |
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
|
Max forwards | 14.31 | Limits the number of possible forwardings through proxies or gateways. The field contains the remaining number of redirects, so each proxy must update (decrement) this number |
Max-Forwards: 10
|
Pragma | 14.32 | The Pragma field contains options that may only be understood by some implementations and apply to all links in the question-and-answer chain. |
Pragma: no-cache
|
Proxy authorization | 14.34 | In the field Proxy-Authorization authorization data can be embedded with authorization compulsory for proxies. |
Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
|
Range | 14.35 | Contains an area specification for the area that the client requests from the server (in this example only bytes 500-999) |
Range: bytes=500-999
|
Referer [sic] | 14.36 | The Referer field contains the URI of the referring page. If you click on a link on the main page of the German-language Wikipedia, the browser sends a header field to the server of the accessed page, as in the example. (The word "Referer" is misspelled both in the RFC and in most implementations; the correct word would be "Referrer" (from to refer, referred, referred )) |
Referer: https://de.wikipedia.org/wiki/Wikipedia:Hauptseite
|
TE | 14.39 | Which formats the client can accept are possible here, for example. B. gzip or deflate . “Trailers” indicates that the client accepts and evaluates the “Trailer” field in the individual pieces in the “Chunked” encoding mode. (See chapters 3.6, 3.6.1, 14.39, 14.40 in RFC 2616 ) |
TE: trailers, deflate
|
Transfer encoding | 14.41 | The transformations that were applied to safely transport the content to the server. The following methods are currently defined: chunked (split), compress (compressed), deflate (compressed), gzip (compressed), identity. |
Transfer-Encoding: chunked
|
Upgrade | 14.42 | Suggestion to the server to use a different protocol |
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
|
User agent | 14.43 | The client's user agent string . It contains information about the client, so that z. E.g. a server-side script can deliver content adapted to different browsers (e.g. for download pages that should offer different links for Mac OS than for Microsoft Windows ) |
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
|
Via | 14.45 | Gives the server information about proxies in the transmission path. |
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
|
Warning | 14.46 | General warnings about handling the body or the body itself. |
Warning: 199 Miscellaneous warning
|
Response header fields
Header field | Chapter in RFC 2616 | description | example |
---|---|---|---|
Accept ranges | 14.5 | Which units for Range data the server accepts. |
Accept-Ranges: bytes
|
Age | 14.6 | How long the object was in the proxy cache (in sec). |
Age: 12
|
Allow | 14.7 | Allowed actions for a specific resource. Must u. a. to be 405 Method Not Allowed sent with a . |
Allow: GET, HEAD
|
Cache control | 14.9 | Informs all caching mechanisms along the retrieval chain (e.g. proxies) whether and how long the object can be stored (in sec). |
Cache-Control: max-age=3600
|
Connection | 14.10 | preferred connection types |
Connection: close
|
Content encoding | 11/14 | Coding the content |
Content-Encoding: gzip
|
Content language | 14.12 | The language in which the file is available (only useful with content negotiation). Is sent if the server either recognizes and delivers a language using content negotiation or if the server recognizes a language based on the extension. |
Content-Language: de
|
Content-Length | 14.13 | Length of the body in bytes |
Content-Length: 348
|
Content location | 14.14 | Alternative name / location for the requested item. If, for example, “foo.html” is requested via CN, and the server sends Accept-language back the German version, which is actually under foo.html.de, based on the field, Content-Location the name of the original file is written in the. |
Content-Location: /foo.html.de
|
Content-MD5 | 14.15 | The Base64- encoded MD5 checksum of the body |
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
|
Content disposition | 19.5.1 1) | With this non-standardized field, which is classified as dangerous, the server can generate download windows for certain MIME types and suggest a file name. |
Content-Disposition: attachment; filename=fname.ext
|
Content range | 14.16 | Which area of the overall body the sent content covers. |
Content-Range: bytes 21010-47021/47022
|
Content Security Policy | W3C CSP 1.0 | Security concept to ward off cross-site scripting (XSS) and similar attacks. |
Content-Security-Policy: default-src https://cdn.example.net; frame-src 'none'; object-src 'none'
|
Content-Type | 14.17 | The MIME type of the requested file. It cannot be overwritten with a charset specification in the HTML header. |
Content-Type: text/html; charset=utf-8
|
Date | 14.18 | Time of sending |
Date: Tue, 15 Nov 1994 08:12:31 GMT
|
ETag | 14.19 | A specific version of a file, often implemented as a message digest . |
ETag: "737060cd8c284d8af7ad3082f209582d"
|
Expires | 14.21 | When the file can be considered out of date. |
Expires: Thu, 01 Dec 1994 16:00:00 GMT
|
Last modified | 14.29 | Time of the last change to the file (as RFC 2822 ). |
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
|
link | RFC 5988 Section 5 | Used to notify the client of "related" files or resources, e.g. B. an RSS feed, a favicon , copyright licenses, etc. This header field is equivalent to the <link /> field in (X) HTML. |
Link: </feed>; rel="alternate"
|
Location | 14.30 | Often used to forward clients (with a 3xx code). |
Location: https://www.w3.org/People.html
|
P3P | - | This field is used to create a P3P privacy policy as follows inform: P3P:CP="your_compact_policy" . P3P did not really catch on, but is used by some browsers and websites to e.g. B. Enforce or review cookie policy. |
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
|
Pragma | 14.32 | Implementation-specific options that can influence several stations in the request-response chain. |
Pragma: no-cache
|
Proxy authenticate | 14.33 | Instruction as to whether and how the client has to authenticate itself with the proxy. |
Proxy-Authenticate: Basic
|
Refresh | Proprietary | Refresh is used to redirect or refresh the page after a certain number of seconds. This header field is proprietary and comes from Netscape, but is supported by most browsers. |
Refresh: 5; url=https://www.w3.org/People.html
|
Retry after | 14.37 | If a resource is temporarily unavailable, the server uses this field to inform the client when it is worth trying again. |
Retry-After: 120
|
server | 14.38 | Server ID (as is User-Agent for the client, is Server for the server software). |
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
|
Set cookie | - | A cookie |
Set-Cookie: UserID=FooBar; Max-Age=3600; Version=1
|
Trailer | 14.40 | The trailer field contains the names of the header fields that are contained in the trailer of the response (with chunked encoding ). A message in chunked encoding is divided into the header (header), the body (body) and the trailer, whereby the body can be divided into parts (chunks) for reasons of efficiency. The trailer can then (depending on the value of the TE field of the request) contain header information, the precalculation of which runs counter to the increase in efficiency. |
Trailer: Max-Forwards
|
Transfer encoding | 14.41 | The method used to safely get the content to the user. The following methods are currently defined: chunked (split), compress (compressed), deflate (compressed), gzip (compressed), identity. |
Transfer-Encoding: chunked
|
Vary | 14.44 | Shows downstream proxies how they should handle future requests based on the header fields, i.e. whether the cached response can be used or a new request should be made. |
Vary: *
|
Via | 14.45 | Informs the client which proxies the response was sent through. |
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
|
Warning | 14.46 | A general warning about body problems. |
Warning: 199 Miscellaneous warning
|
WWW Authenticate | 14.47 | Defines the authentication method to be used to download a specific file (more precisely defined in RFC 2617 ). |
WWW-Authenticate: Basic
|
1) Not in the official HTTP / 1.1 standard, as (Section 15.5) a number of security concerns were raised. Content-disposition
is described in more detail in RFC 2183 .
General, non-standardized fields
Request fields
Non-standardized headers often have an ' X-
' at the beginning. With RFC 6648 the prefix is X-
considered obsolete.
Field name | description | example |
---|---|---|
X-Requested-With | Often used at Ajax . |
X-Requested-With: XMLHttpRequest
|
X-Do-Not-Track | Instructs a website to turn off user tracking . Until now, this field has been ignored by the vast majority of servers. However, this could change in the future. See also the 'DNT' field. |
X-Do-Not-Track: 1
|
DNT or Dnt | Tells a website not to track the user. This field is Mozilla's version of the X-Do-Not-Track field, but it is also supported by Safari 5, Internet Explorer 9 and Google Chrome (the latter uses the variant Dnt ). On March 7, 2011, a draft was submitted to the IETF. |
DNT: 1
|
X-Forwarded-For | a de facto standard for identifying the original IP address of a client connecting to a web server through an HTTP proxy or load balancer . |
X-Forwarded-For: client1, proxy1, proxy2
|
X-Forwarded Proto | a de facto standard for identifying the original protocol of an HTTP request, as a reverse proxy (load balancer) communicates with a web server over HTTP. |
X-Forwarded-Proto: https
|
Answer fields
Field name | description | example |
---|---|---|
X-frame options | Clickjacking -protection: "DENY" - no rendering in a frame; "SAMEORIGIN" - Only then no rendering if the origin is wrong. |
X-Frame-Options: DENY
|
X-XSS protection | Cross-Site Scripting (XSS) Filters |
X-XSS-Protection: 1; mode=block
|
X-Content-Type-Options | The only defined value "nosniff" prohibits Internet Explorer from using MIME sniffing to determine and use a content type other than the declared one. |
X-Content-Type-Options: nosniff
|
X-Powered-By | Specifies on which technology (ASP.NET, PHP, JBoss u. A.) The web application is based (version details are often found in X-Runtime , X-Version or X-AspNet-Version ) |
X-Powered-By: PHP/5.3.8
|
X-UA Compatible | Recommends the recommended rendering engine (often a backward compatible mode) to display the content. Also used to activate the Chrome Frame in Internet Explorer. |
X-UA-Compatible: IE=EmulateIE7 X-UA-Compatible: IE=edge X-UA-Compatible: Chrome=1
|
X-Robots-Tag | Defines for web crawlers which content can be indexed. |
X-Robots-Tag: noarchive X-Robots-Tag: unavailable_after: 25 Jun 2010 15:00:00 PST X-Robots-Tag: googlebot: nofollow
|
Referrer Policy | Checks whether the browser should transmit the referrer to the target website. |
Referrer-Policy: no-referrer
|
See also
Individual evidence
- ↑ Instructions for defining your own header fields with Apache2 ( memento of the original from April 2, 2015 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
-
↑ Documentation of the directive
header
- ↑ Ubuntu: "Hide" Apache information. In: Johann.gr. December 23, 2015, accessed June 20, 2016 .
- ↑ How to hide Nginx version | Nginx Tips. In: ScaleScale.com. Retrieved June 20, 2016 (American English).
- ↑ Permanent Message Header Field Names ( English ) iana.org. July 11, 2019. Retrieved July 18, 2019.
- ↑ Provisional Message Header Field Names ( English ) iana.org. Retrieved July 18, 2019.
- ↑ Hypertext Transfer Protocol - HTTP / 1.1 ( English ) ietf.org. Retrieved July 18, 2019.
- ↑ RFC 2616, Section 10.4.7 .
- ↑ RFC 5988 section 5 (PDF; 36 kB)
- ↑ W3C P3P Work Suspended
- ↑ docs.djangoproject.com ( Memento of the original from October 5, 2011 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
- ↑ hackademix.net
- ↑ blog.sidstamm.com
- ↑ blogs.msdn.com
- ↑ IETF Do Not Track: A Universal Third-Party Web Tracking Opt Out
- ↑ Amos Jeffries: SquidFaq / ConfiguringSquid - Squid Web Proxy Wiki . July 2, 2010. Retrieved September 10, 2009.
- ^ Dave Steinberg: How do I adjust my SSL site to work with GeekISP's loadbalancer? . April 10, 2007. Retrieved September 30, 2010.
- ↑ blogs.msdn.com
- ↑ Eric Lawrence: IE8 Security Part IV: The XSS Filter . July 2, 2008. Retrieved September 30, 2010.
- ↑ Eric Lawrence: IE8 Security Part VI: Beta 2 Update . September 3, 2008. Retrieved September 28, 2010.
- ↑ Why does ASP.NET framework add the 'X-Powered-By: ASP.NET' HTTP Header in responses? - Stack overflow . Retrieved September 30, 2010.
- ↑ Define Document Compatibility: Specify Document Compatibility Mode . April 1, 2011. Retrieved January 24, 2012.
- ↑ developers.google.com from September 18, 2013.
- ↑ Scott Helme: A new security header: Referrer Policy. Retrieved October 11, 2018 .