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.
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.
A core set of fields is standardized by the Internet Engineering Task Force (IETF) in RFC 9110 and 9111.
[8] Many field values may contain a quality (q) key-value pair separated by equals sign, specifying a weight to use in content negotiation.
[9] 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 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 some limits for practical and security reasons.
It just tells the browser and proxies to validate the cache content with the server before using it (this is done by using If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match attributes mentioned above).
The header field Cache-Control: no-store is intended to instruct a browser application to make a best effort not to write it to disk (i.e not to cache it).
Many user agents show different behavior in loading pages from the history store or cache depending on whether the protocol is HTTP or HTTPS.
While some user agents do pay attention to this field in responses,[78] the HTTP/1.1 RFC specifically warns against relying on this behavior.
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?