List of HTTP header fields

This article or section needs to be revised. Details should be given on the talk page. Please help to improve it , and then remove this flag.

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 acceptablesend 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-Cookiehas 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 Failedsend the code . The client sends in Expect: 100-continuewhen 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: [e-mail]
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 Requestrespond 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 Modifiedto 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 Modifiedas 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-Authorizationauthorization 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 Rangedata 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 Allowedsent 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-languageback the German version, which is actually under foo.html.de, based on the field, Content-Locationthe 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-Disposition: inline; filename="picture name.png"
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-Agentfor the client, is Serverfor 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

¹⁾ Not in the official HTTP / 1.1 standard, as (Section 15.5) a number of security concerns were raised. Content-dispositionis 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-Trackfield, 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-Versionor 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

• Hypertext Transfer Protocol (HTTP)
• HTTP status code
• HTTP cookie
• HTTP ETag

Individual evidence

1. ↑ 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. 
2. ↑ Documentation of the directiveheader
3. ↑ Ubuntu: "Hide" Apache information. In: Johann.gr. December 23, 2015, accessed June 20, 2016 . 
4. ↑ How to hide Nginx version | Nginx Tips. In: ScaleScale.com. Retrieved June 20, 2016 (American English). 
5. ↑ Permanent Message Header Field Names ( English ) iana.org. July 11, 2019. Retrieved July 18, 2019.
6. ↑ Provisional Message Header Field Names ( English ) iana.org. Retrieved July 18, 2019.
7. ↑ Hypertext Transfer Protocol - HTTP / 1.1 ( English ) ietf.org. Retrieved July 18, 2019.
8. ↑ RFC 2616, Section 10.4.7 .
9. ↑ RFC 5988 section 5 (PDF; 36 kB)
10. ↑ W3C P3P Work Suspended
11. ↑ 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. 
12. ↑ hackademix.net
13. ↑ blog.sidstamm.com
14. ↑ blogs.msdn.com
15. ↑ IETF Do Not Track: A Universal Third-Party Web Tracking Opt Out
16. ↑ Amos Jeffries: SquidFaq / ConfiguringSquid - Squid Web Proxy Wiki . July 2, 2010. Retrieved September 10, 2009.
17. ^ Dave Steinberg: How do I adjust my SSL site to work with GeekISP's loadbalancer? . April 10, 2007. Retrieved September 30, 2010.
18. ↑ blogs.msdn.com
19. ↑ Eric Lawrence: IE8 Security Part IV: The XSS Filter . July 2, 2008. Retrieved September 30, 2010.
20. ↑ Eric Lawrence: IE8 Security Part VI: Beta 2 Update . September 3, 2008. Retrieved September 28, 2010.
21. ↑ Why does ASP.NET framework add the 'X-Powered-By: ASP.NET' HTTP Header in responses? - Stack overflow . Retrieved September 30, 2010.
22. ↑ Define Document Compatibility: Specify Document Compatibility Mode . April 1, 2011. Retrieved January 24, 2012.
23. ↑ developers.google.com from September 18, 2013.
24. ↑ Scott Helme: A new security header: Referrer Policy. Retrieved October 11, 2018 .