Search notes:

HTTP Header

Some HTTP headers make sense only in HTTP requests, others only in HTTP responses and some can be used in requests and respones.
Some headers describe the body of a resource. These headers are referred to as entity headers.
A particular feature of HTTP headers is that they are (mostly) human readable.

Request headers

Some request(?) headers include:
Accept Indicates which content types (expressed as MIME types) the client understands. Accept belongs to the set of CORS-safelisted request headers. Values I often see include */* or image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8 etc.
Accept-Charset Specifies the client's character encoding. This header should not be and is not widely used anymore. Compare with Content-Type.
Accept-Encoding Specifies the encoding the client understands. Typically, the encoding is a compression algorithm. A list of offical content encodings is maintained by IANA (other encodings also seen include bzip and bzip2). The encoding that is chosen by the server is sent with the Content-Encoding header. The server might send the status code 406 (not acceptable) if it cannot server the document in the requested encoding.
Accept-Language Specifies a list of (natural) languages and locales, for example de-CH, en-US or en-US, en, de, en-gb;q=0.8, en;q=0.7 etc…. The chosen language/locale is reported back to the client using the Content-Language header. Accept-Language belongs to the set of CORS-safelisted request headers. Can be changed in Firefox under about:config -> intl.accept_languages. See also the PowerShell cmdLet noun winAcceptLanguageFromLanguageListOptOut and the value AcceptLanguage under the registry key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\International. If unable to serve the requested resource in one of the listed language, the server might send the status code 406 (not acceptable).
Accept-Ranges
Age
Allow
Authorization Used in response to response with status 401 (which includes the WWW-Authenticate header).
Cache-Control For example: max-age=0. This header is should be used instead of the deprecated Pragma header.
Clear-Site-Data
Connection The value of Connection can be set to keep-alive to specify that the connection between the client and the server should not be terminated when the transaction finishes (Compare with Keep-Alive header. Setting it to close terminates the connection. This header is not allowed in HTTP/2 and HTTP/3 (although Chrome and Firefox treats it gracefully in such a case). See also the Upgrade header for Connection: upgrade. Connection belongs to the set of «hop-by-hop headers».
Cookie Cookie sends the stored HTTP cookies associated with the server (which were sent by the server using a previous Set-Cookie response header or specified in JavaScript with document.cookie).
Date
DNT Do Not Track. Deprecated in favor of global privacy control. 1 (the typical value if this header is present), 0 or null. The value can be read in JavaScript from navigator.doNotTrack.
Expect
Expires
Forwarded
Host
Keep-Alive Keep-Alive is used in conjunction with Connection: keep-alive to set the timeout and max values (for example Keep-Alive: timeout=5, max=1000). This header is not allowed in HTTP/2 and HTTP/3. Keep-Aliave belongs to the set of «hop-by-hop headers».
If-Match Used together with ETag to detect mid-air edit collisions: When updating a resource, the client sends the ETag value it received from the server in the If-Match header. If the resource has changed in the mean time, the server responds with a 412 status («precodindition failed»).
If-Modified-Since
If-None-Match
If-Range
If-Unmodified-Since
Last-Modified
Location
Origin A version of Referer without revealing a path.
Pragma
Proxy-Authenticate Proxy-Authenticate <type> realm=<realm>. <type> is an authentication scheme. <realm> describes the protected «area». See also the WWW-Authenticate header and HTTP status 401, 403 and 407. Proxy-Authenticate belongs to the set of «hop-by-hop headers».
Proxy-Authorization Proxy-Authorization is typically when a server requests the credentials to authorize a user (status code 407). The syntax is Proxy-Authorization <type> <credentials>. <type> is an authentication scheme. <credentials> is the Base64 encoded form of username:secret. Proxy-Authorization belongs to the set of «hop-by-hop headers».
Range
Referer This is not a typo! Compare with the Origin header.
Referrer-Policy
Server
sec-ch-ua "Chromium";v="124", "Google Chrome";v="124", "Not-A.Brand";v="99" …
Sec-CH-UA-Bitness 32 or 64. See also navigator.userAgentData.getHighEntropyData('bitness')
Sec-CH-UA-Form-Factor Tablet VR … . See also navigator.userAgentData.getHighEntropyData('formFactor')
sec-ch-ua-mobile true, false. See also navigator.userAgentData.mobile
sec-ch-ua-platform Windows, Linux, Android … See also navigator.userAgentData.platform
Sec-Fetch-Dest
Sec-Fetch-Mode cors, navigate, no-cors, same-origin, websocket
Sec-Fetch-Site cross-site, same-site, same-origin or none
TE Specifies the transfer encodings a user agent is willing to accept (it would probably be more intuitive to call this header Accept-Transfer-Encoding). See also the Transfer-Encoding response header. TE belongs to the set of «hop-by-hop headers».
Trailers Trailers belongs to the set of «hop-by-hop headers».
Upgrade Used to change the protocol used in an already established connection (for example HTTP/1.1 -> HTTP/2 or HTTP -> HTTPS). Using Upgrade requires also Connection: upgrade to be sent with a request. This header can only be used in HTTP/1.1. Upgrade belongs to the set of «hop-by-hop headers».
Upgrade-Insecure-Requests
User-Agent Identifies the user agent
Warning
X-Real-IP Compare with X-Forwarded-For
X-Forwarded-For Compare with X-Real-IP
X-Forwarded-Proto https …

Client hints

The Sec-UA-CH-* headers are so called client hints.
Client hints can be divided in
  • Low entropy client hints (which don't give much information that can be used to create a fingerprinting for a user)
  • Critical client hints
Low entropy client hints include Save-Data, Sec-CH-UA, Sec-CH-UA-Mobile and Sec-CH-UA-Platform

Response headers

Some response headers include
Accept-CH Announces which client hints the web server understands. Alternatively, this list can also be sent with <meta http-equiv="Accept-CH" content="…" />.
Accept-Ranges For example bytes
Access-Control-Allow-Origin For example *
Access-Control-Request-Header This header can be used to respond to a preflight request to add more allowed headers (comma separated, or simply *) to the four CORS-safelisted request headers. A server must answer with this header if the request had an Access-Control-Request-Headers header.
Connection For example: Keep-Alive
Content-Security-Policy
Cross-Origin-Opener-Policy
Cross-Origin-Embedder-Policy
Date Sat, 22 Oct 2022 07:59:01 GMT
ETag ETag: "33B282594…", Etag: W/"1234". The value of the ETag response header line identifies the returned resource's version. This value is used by the user agent for caching the resources. Related are the If-Match, If-None-Match and the 304 and 412 status codes.
Keep-Alive
Last-Modified For example Sat, 19 May 2018 08:51:05 GMT
Location The URL to which a moved/redireced URL has moved (see HTTP status 301.
Origin-Trial Allow developers to try out new features and give feedback on it. See also active Chrome trials.
Retry-After The Retry-After can or should be sent along with HTTP status 503 (Service Unavailable), 429 (Too Many Requests) and 301 (Moved Permanently) and indicates how long the user agent should wait before making a follow-up request.
Server For example Apache or ngingx
Set-Cookie See also the Cookie request header.
Speculation-Rules See also the Speculation Rules Web API. Experimental.
Strict-Transport-Security Aka HSTS (HTTP Strict-Transport-Security) (or also simply STS?): Inform browser to always access the site using HTTPS. The required max-age directive specifies the number of seconds, after the reception of the STS header field, during which the UA regards the host (from whom the message was received) as a known HSTS host. See also 6797 HTTP Strict Transport Security (HSTS).
Transfer-Encoding See also the TE request header.
Vary For example Accept-Encoding
WWW-Authenticate WWW-Authenticate: <auth-scheme> …: Used for authentication. Must be included with in a response with status 401. After receiving a WWW-Authenticate header, a client will typically prompt the user for credentials and then re-request the resource with an additional Authorization header.
X-Content-Type-Options Sent to prevent MIME type sniffing by the browser (i. e. the browser must consider the MIME type (Content-Type) to be correct and follow it).
With PowerShell, a request's response headers can be inspected with 
(invoke-webRequest 'https://renenyffenegger.ch').headers
cURL will print the received response headers by specifying the command line option -i and dump them to the specified file with -D.

Request and response headers

Some headers, such as for example the so called representation headers, can be used in HTTP requests and responses.
Content-Encoding Specfies if and how content body was compressed. . See also the Accept-Encoding request header.
Content-Encoding For example: text/html; charset=utf-8 or simply text/html
Content-Length The size of the (potentially compressed) body, in bytes.
Content-Language See also the Accept-Language request header. Content-Language belongs to the set of CORS-safelisted request headers.
Content-Location
Content-Range
Content-Type Content-Type transmits (among others?) a MIME type. Often, Content-Type has a value like text/html; charset=utf-8 or multipart/form-data; boundary=MYCAREFULLYCHOSENBOUNDARY or text/plain. Content-Type belongs to the set of CORS-safelisted request headers. Compare with Accept-Charset
Via Added by proxies (both forward and reverse).

CORS-safelisted request headers

The four CORS-safelisted request headers are:
A HTTP request with no headers except these four does not necessitate a preflight request.
In an response to a preflight request, a server can safelist more headers by specifying them with the Access-Control-Allow-Headers header.

Forbidden headers

A forbidden header is a header over which a user agent has full control. Thus, they cannot be modified programmatically (for example with the JavaScript fetch API).
The list of forbidden headers is

Content-Disposition

The content should be rendered inline or downloaded.
Within a regular header: 
Content-Disposition: inline
Content-Disposition: attachment
Content-Disposition: attachment; filename="foo.mp3"
Within a multipart body: 
Content-Disposition: form-data
Content-Disposition: form-data; name="field-name"
Content-Disposition: form-data; name="field-name"; filename="foo.jpg"
This header might go hand in hand with Content-Transfer-Encoding: binary.

Proprietary headers (X-headers)

Historically, custom proprietary headers were prefixed with X-.
This convention was deprecated with RFC 6648 Deprecating the "X-" Prefix and Similar Constructs in Application Protocols.

TODO

HTTP request and response messages include an HTTP protocol version number. This version comes in a major.minor format.
To make this as clear as possible: The major version sent in a message MAY indicate the interpretation of other header fields. The minor version sent in a message MUST NOT indicate the interpretation of other header fields.

See also

HTTP
In order to get the response headers (and status line) only, the HEAD request method should be used.
Perl module HTTP::Headers.
For example, in wget, the header can be specified with the --header option (see Specifying the result language).
In the cURL command line tool (such as curl.exe), the -i command line option includes the response headers in the output.
The PHP function header()

Links

IANA maintains a registry of message headers (including a status such as standard, experimental, obsoleted)
A list of known HTTP headers is also found in the .NET class System.Net.HttpKnownHeaderNames (source file)
Wikipedia's List of HTTP header fields

Index