This website serves as a reference site for information related to the HTTP protocol, specificaly looking at information that is not covered by the RFC specifications and some of the other official website documentation. This site concentrates on the elements of the subject matter not directly addressed by the official specification. It attempts to address practical aspects of the subject that are not covered by official specifications including how headers should be implemented in particular webservers, what security risks come with headers how to test and debug headers. The site tries to help novice users and experts alike by clearly explaining what the header does, how it should be used what the ramifications of usage are. Some headers are benign, some helpful and some should be treated with care. We take particular care to frame our information with reference to the implications of header use related to SEO (Search Engine Optimisation) rather than just regurgitating the official documentation .
http-headers.com is designed to serve as a reference site, allowing you to find header information by their type, request and response. We also have a Help Centre that allows you to validate header information in the real world by allowing you to create headers to put into your website and by making requests for pages on your site to ensure they are correct. Headers are broadly classified as request and response headers.
Request headers are generated by the Client (your Browser or other software capable of asking for a web page) when asking for a page from your webserver. Request headers are used by the webserver to understand more about what your browser is asking for and how it might expect the response. For example, if your browser is capable of processing a compressed response then it might include "Accept-Encoding: gzip, deflate" which tells the webserver that the client can decode compressed content. This convention extends to all and any resources that require intelligence to process include media payload formats for audio, images and video.
Conversely, Response headers are generated by the webserver for the Client in response to every resource request it receives. These headers are used by the Client in a variety of ways including processing the content of the response, caching the resource and security, to name but a few. For example, the response header "Content-type: text/html" tells the Client that the resource is a page of HTML and that it should be processed accordingly.
We haven't launched this section yet, please stay tuned.
HTTP Headers, both request and response, are passed between Server and Client as plain text records (delimited by a carriage return) prepended to the request or response payload. By way of example, let's have a look at the interchange between Client and Server. For the purposes of this example, the ␍ indicates a Carriage Return/New Line character sequence.
① GET /index.html HTTP/1.1␍
② Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8␍
③ Accept-Encoding: gzip, deflate, br␍
④ Accept-Language: en-GB,en;q=0.9,en-US;q=0.8␍
⑤ Cache-Control: no-cache␍
⑥ Connection: keep-alive␍
⑦ DNT: 1␍
⑧ Host: http-headers.com␍
⑨ Pragma: no-cache␍
⑩ Referer: http://http-headers.com/␍
⑪ Upgrade-Insecure-Requests: 1␍
⑫ User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36␍
⑬ ␍
The two notworthy lines in the request are lines 1 and 13. Line 1 tells the server what resource is required and line 13, which is essentially empty, tells the server that we have finished sending headers and we are ready to receive the response.
① HTTP/1.0 200 OK␍
② Server: Apache/2.4.23 (Unix) OpenSSL/1.0.1e-fips mod_bwlimited/1.4␍
③ Date: Mon, 08 Oct 2018 10:32:46 GMT␍
④ Content-type: text/html␍
⑤ Content-Length: 5913␍
⑥ Last-Modified: Wed, 25 Jul 2018 10:29:47 GMT␍
⑦ ␍
⑧ <html>...
Line 1 conveys the status of the request to the Client, in this case that the resource was successfully found and will be returned to the Client. The other line of particular interest is line 7. As per line 13 in the Send example, this line tells the Client that all the headers have been sent and that the resource content is about to follow... as indicated in line 8.