2. HTTP Headers

Headers are name/value pairs that appear in both request and response messages. They are usually displayed with a colon separating the name of the header from its value. For example, this header value in a request message:

user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/154.0.0.0 Safari/537.36

provides a header called user-agent whose value is Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/154.0.0.0 Safari/537.36. The purpose of this particular header is to supply the web server with information about the type of browser making the request. The standard HTTP headers are defined in RFC 9110 (HTTP Semantics) and the other specifications listed in the IANA HTTP Field Name Registry.

Web applications can also define their own custom headers. These were traditionally given an X- prefix to show that they were non-standard (e.g. x-powered-by in the response shown below), but this convention was deprecated by RFC 6648 because many X- headers later became widely used standards. New custom headers should simply be given a descriptive name.

Header names are not case sensitive. With HTTP/1.1 they are often written with capital letters, e.g. User-Agent, but HTTP/2 and HTTP/3 require them to be sent in lower case. These versions also replace the HTTP/1.1 request and status lines with pseudo-headers whose names start with a colon, such as :method, :path and :status. This site uses HTTP/2, so the examples in the HTTP Gallery show headers in lower case, as you will see them in HttpWatch.

2.1 Request Headers

HTTP clients use headers in the request message to identify themselves and control how content is returned. This site uses HTTP/2, so header names are in lower case. Here are the request headers that Chrome sent with the request in Example 2 (the exact values depend on your browser and its settings):

:authority: www.httpwatch.com
:method: GET
:path: /httpgallery/headers/time/?0.12755670088014281
:scheme: https
accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
accept-encoding: gzip, deflate, br, zstd
accept-language: en-GB,en-US;q=0.9,en;q=0.8
cookie: _ga=GA1.1.123456789.1781623674; _ga_EZJNXG1Z1J=GS2.1.s1791888846$o35$g1$t1791888867$j39$l0$h0
priority: i
referer: https://www.httpwatch.com/httpgallery/headers/
sec-ch-ua: "Chromium";v="154", "Google Chrome";v="154", "Not A(Brand";v="99"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
sec-fetch-dest: image
sec-fetch-mode: no-cors
sec-fetch-site: same-origin
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/154.0.0.0 Safari/537.36

Each of these headers is described below.

:authority: www.httpwatch.com
:method: GET
:path: /httpgallery/headers/time/?0.12755670088014281
:scheme: https

These pseudo-headers, which start with a colon, replace the request line and host header used by HTTP/1.1. They give the host name, the method, the path of the requested resource and the scheme (https). Supplying the host name with every request allows many web sites to be hosted on a single IP address. The random number in the query string is added by the script in Example 2 so that each request has a different URL.

accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8

The content types that the browser can handle for an image. Types without a q value have the highest preference, so the browser prefers image formats such as AVIF, WebP and SVG. The final */*;q=0.8 means it will accept any type of content with a lower preference.

accept-encoding: gzip, deflate, br, zstd

The browser can handle content compressed with gzip, deflate, Brotli or Zstandard (See 8. Compression).

accept-language: en-GB,en-US;q=0.9,en;q=0.8

The languages the user prefers, in order. British English is preferred, followed by American English and then any other form of English.

cookie: _ga=GA1.1.123456789.1781623674; _ga_EZJNXG1Z1J=GS2.1.s1791888846$o35$g1$t1791888867$j39$l0$h0

The cookies the browser holds for this site (See 4. Cookies). In this case they were set by the Google Analytics script on the page. The browser sends matching cookies with every request, including requests for images, so large cookies increase the size of every request.

priority: i

A hint to the server about how important this response is compared with the others the browser is waiting for, defined in RFC 9218. i (incremental) means that the image can be displayed as it arrives, so it can share the connection with other responses. Requests for more important resources, such as the page itself, also include an urgency value from u=0 (most urgent) to u=7; when it is omitted, as here, the default urgency of 3 applies.

referer: https://www.httpwatch.com/httpgallery/headers/

The page that caused the request; in this case the page containing the image. (The header name has been misspelt since the earliest versions of HTTP.) To protect privacy, browsers normally send only the origin, e.g. https://www.httpwatch.com/, when a request goes to a different site, and sites can control this with the referrer-policy header.

sec-ch-ua: "Chromium";v="154", "Google Chrome";v="154", "Not A(Brand";v="99"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"

These User-Agent Client Hints give the browser's brand names and major version, whether it is running on a mobile device (?0 means false) and the operating system. The odd-looking "Not A(Brand" entry is deliberate: its name changes between Chrome versions to make sure servers do not rely on an exact list of brands. Sites that need more detail, such as the full browser version, can ask for extra hints by returning an accept-ch response header.

sec-fetch-dest: image
sec-fetch-mode: no-cors
sec-fetch-site: same-origin

These Fetch Metadata headers describe how the request was made: the content will be used as an image, it was made by an <img> element rather than a script that could read the response, and it came from a page on the same site. Servers can use them to reject unexpected cross-site requests.

user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/154.0.0.0 Safari/537.36

This identifies the browser as Google Chrome 154 running on 64-bit Windows. To make it harder to track users, Chrome and Edge now report a simplified value: the minor version numbers are always zero and both Windows 10 and Windows 11 appear as Windows NT 10.0. The Mozilla, AppleWebKit and Safari parts are kept so that older sites that check for those names still work.

You may notice that there is no connection header. It is only used with HTTP/1.1, where connection: keep-alive asks the server to keep the TCP connection open for further requests. HTTP/2 connections are always persistent, and connection-specific headers like this are not allowed.

2.2 Response Headers

HTTP servers use headers in the response message to specify how content is being returned and how it should be handled. Your browser will have received headers like these with the image in Example 2:

:status: 200
cache-control: no-cache, no-store
content-length: 2478
content-type: image/png
date: Tue, 13 Oct 2026 10:54:49 GMT
expires: -1
pragma: no-cache
server: Microsoft-IIS/10.0
x-powered-by: ASP.NET

:status: 200

With HTTP/2 the status code is sent as a pseudo-header in place of the HTTP/1.1 status line, and there is no reason phrase such as OK. (See 3. Status Codes)

cache-control: no-cache, no-store

This header controls whether the resource may be stored by the browser or any intermediate caches. The value no-store prevents the image from being cached at all, so that a new copy is always downloaded. (See 5. Caching for more information.)

content-length: 2478

The length in bytes of the resource (i.e. the PNG image) that follows the headers.

content-type: image/png

The content is in PNG format. Browsers use this header, rather than the file extension in the URL, to decide how to handle the content.

date: Tue, 13 Oct 2026 10:54:49 GMT

The date and time on the web server when the response was generated. HTTP dates are always given in GMT (i.e. UTC).

expires: -1

The expires header specifies when the content should be considered to be out of date. -1 is not a valid date, and caches treat invalid values as a time in the past, so the content has already expired. This header is only needed for very old caches because cache-control takes priority.

pragma: no-cache

A legacy header from HTTP/1.0 that some sites still send to prevent caching by very old proxies that do not support cache-control.

server: Microsoft-IIS/10.0
x-powered-by: ASP.NET

The software that handled the request. This site is an ASP.NET Core application hosted in Microsoft IIS 10, which adds both headers. If the same application is run on its own using the Kestrel web server built into ASP.NET Core, e.g. on a developer's computer, the response contains server: Kestrel and no x-powered-by header. Many sites remove these headers, or reduce the detail they contain, to avoid advertising the software and versions they use.