Server-Timing - HTTP

Server-Timing
=============

The **`Server-Timing`** header communicates one or more metrics and descriptions for a given request-response cycle. It is used to surface any backend server timing metrics (e.g. database read/write, CPU time, file system access, etc.) in the developer tools in the user's browser or in the `PerformanceServerTiming` interface.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

The syntax of the `Server-Timing` header allows you to communicate metrics in different ways: server metric name only, metric with value, metric with value and description, and metric with description.

This header can contain one or more metrics, separated by commas. Each metric has a name, an optional duration, and an optional description. These components are separated by semi-colons.

 The duration component consists of the string `"dur"`, followed by `"="`, followed by the value, like `"dur=23.2"`.
 The description component consists of the string `"desc"`, followed by `"="`, followed by the value, like `"desc=DB lookup"`.

The specification advises that names and descriptions should be kept as short as possible (use abbreviations and omit optional values where possible) to minimize the HTTP overhead.

```http
// Single metric without value
Server-Timing: missedCache

// Single metric with value
Server-Timing: cpu;dur=2.4

// Single metric with description and value
Server-Timing: cache;desc="Cache Read";dur=23.2

// Two metrics with value
Server-Timing: db;dur=53, app;dur=47.2

// Server-Timing as trailer
Trailer: Server-Timing
--- response body ---
Server-Timing: total;dur=123.4
```

Privacy and security
--------------------

The `Server-Timing` header may expose potentially sensitive application and infrastructure information. Consider to control which metrics are returned when and to whom on the server side. For example, you could only show metrics to authenticated users and nothing to the public.

PerformanceServerTiming interface
---------------------------------

In addition to having `Server-Timing` header metrics appear in the developer tools of the browser, the `PerformanceServerTiming` interface enables tools to automatically collect and process metrics from JavaScript. This interface is restricted to the same origin, but you can use the `Timing-Allow-Origin` header to specify the domains that are allowed to access the server metrics. The interface is only available in secure contexts (HTTPS) in some browsers.

The components of the `Server-Timing` header map to the `PerformanceServerTiming` properties like this:

* `"name"` -> `PerformanceServerTiming.name`
* `"dur"` -> `PerformanceServerTiming.duration`
* `"desc"` -> `PerformanceServerTiming.description`
Specifications
--------------

| Specification |
| --- |
| Server Timing # the-server-timing-header-field |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `PerformanceServerTiming`


Sec-CH-UA-Mobile - HTTP

Sec-CH-UA-Mobile
================

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

**Secure context:** This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

 The **`Sec-CH-UA-Mobile`** user agent client hint request header indicates whether the browser is on a mobile device.
 It can also be used by a desktop browser to indicate a preference for a "mobile" user experience.

`Sec-CH-UA-Mobile` is a low entropy hint.
 Unless blocked by a user agent permission policy, it is sent by default, without the server opting in by sending `Accept-CH`.

|  |  |
| --- | --- |
| Header type | Request header,
 Client hint |
| Forbidden header name | yes |

Syntax
------

```http
Sec-CH-UA-Mobile: <boolean>
```

### Directives

`<boolean>`

`?1` indicates that the user-agent prefers a mobile experience (true).
 `?0` indicates that user-agent does not prefer a mobile experience (false).

Examples
--------

As `Sec-CH-UA-Mobile` is a low entropy hint it is typically sent in all requests.

A desktop browser would usually send requests with the following header:

```http
Sec-CH-UA-Mobile: ?0
```

A browser on a mobile device would usually send requests with the following header:

```http
Sec-CH-UA-Mobile: ?1
```

Specifications
--------------

| Specification |
| --- |
| User-Agent Client Hints # sec-ch-ua-mobile |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Client hints
* User-Agent Client Hints API
* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* `Accept-CH`
* HTTP Caching > Vary and `Vary`


Digest - HTTP

Digest
======

**Deprecated:** This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

The **`Digest`** response HTTP header provides a digest of the *selected representation* of the requested resource.

 Representations are different forms of a particular resource that might be returned from a request: for example, the same resource might be formatted in a particular media type such as XML or JSON, localized to a particular written language or geographical region, and/or compressed or otherwise encoded for transmission.
 The *selected representation* is the actual format of a resource that is returned following content negotiation, and can be determined from the response's Representation headers.

 The digest applies to the whole representation of a resource, not to a particular message.
 It can be used to verify that the representation data has not been modified during transmission.

**Note:** While a representation may be fully contained in the message body of a single response, it can also be sent using multiple messages in response to a range request, or omitted altogether in response to a `HEAD` request.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

```http
Digest: <digest-algorithm>=<digest-value>
Digest: <digest-algorithm>=<digest-value>,<digest-algorithm>=<digest-value>
```

Directives
----------

`<digest-algorithm>`

Digest algorithms are defined in Digest Headers.

* Permitted digest algorithms values include: `unixsum`, `unixcksum`, `crc32c`, `sha-256` and `sha-512`, `id-sha-256`, `id-sha-512`
* Deprecated algorithms values include: `md5`, `sha`, `adler32`.

`<digest-value>`

 The result of applying the digest algorithm to the resource representation and encoding the result.
 The choice of digest algorithm also determines the encoding to use: for example `SHA-256` uses base64 encoding.

Examples
--------

```http
Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=,unixsum=30637
```

Specifications
--------------

| Specification |
| --- |
| Digest Fields # section-3 |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Want-Digest`
* HTTP range requests
* `206 Partial Content`


Access-Control-Expose-Headers - HTTP

Access-Control-Expose-Headers
=============================

The **`Access-Control-Expose-Headers`** response header allows a server to indicate which response headers should be made available to scripts running in the browser, in response to a cross-origin request.

Only the CORS-safelisted response headers are exposed by default. For clients to be able to access other headers, the server must list them using the `Access-Control-Expose-Headers` header.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

```http
Access-Control-Expose-Headers: [<header-name>[, <header-name>]\*]
Access-Control-Expose-Headers: \*
```

Directives
----------

<header-name>

A list of zero or more comma-separated header names that clients are allowed to access from a response. These are *in addition* to the CORS-safelisted response headers.

`*` (wildcard)

 The value "`*`" only counts as a special wildcard value for requests without credentials (requests without HTTP cookies or HTTP authentication information).
 In requests with credentials, it is treated as the literal header name "`*`".

Examples
--------

The CORS-safelisted response headers are: `Cache-Control`, `Content-Language`, `Content-Length`, `Content-Type`, `Expires`, `Last-Modified`, `Pragma`. To expose a non-CORS-safelisted response header, you can specify:

```http
Access-Control-Expose-Headers: Content-Encoding
```

To additionally expose a custom header, like `Kuma-Revision`, you can specify multiple headers separated by a comma:

```http
Access-Control-Expose-Headers: Content-Encoding, Kuma-Revision
```

For requests without credentials, a server can also respond with a wildcard value:

```http
Access-Control-Expose-Headers: \*
```

A server can also respond with the `*` value for requests with credentials, but in this case it would refer to a header named `*`.

Specifications
--------------

| Specification |
| --- |
| Fetch Standard # http-access-control-expose-headers |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Origin`


X-Content-Type-Options - HTTP

X-Content-Type-Options
======================

 The **`X-Content-Type-Options`** response HTTP header is a
 marker used by the server to indicate that the MIME types advertised in the
 `Content-Type` headers should be followed and not be changed. The header allows you to avoid MIME type sniffing by saying that the MIME types are deliberately
 configured.

 This header was introduced by Microsoft in IE 8 as a way for webmasters to block
 content sniffing that was happening and could transform non-executable MIME types into
 executable MIME types. Since then, other browsers have introduced it, even if their MIME
 sniffing algorithms were less aggressive.

 Starting with Firefox 72, top-level
 documents also avoid MIME sniffing (if `Content-type` is provided). This can cause HTML web pages
 to be downloaded instead of being rendered when they are served with a MIME type other
 than `text/html`. Make sure to set both headers correctly.

Site security testers usually expect this header to be set.

**Note:** `X-Content-Type-Options` only apply
 request-blocking due to `nosniff`
 for request destinations of "`script`"
 and "`style`". However, it also
 enables Cross-Origin Read Blocking (CORB)
 protection for HTML, TXT, JSON and XML files (excluding SVG `image/svg+xml`).

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

```http
X-Content-Type-Options: nosniff
```

Directives
----------

`nosniff`

 Blocks a request if the request destination is of type
 `style` and the MIME type is not `text/css`,
 or of type `script` and the MIME type is not a JavaScript MIME type.

Specifications
--------------

| Specification |
| --- |
| Fetch Standard # x-content-type-options-header |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

### Browser specific notes

* Firefox 72 enables `X-Content-Type-Options: nosniff` for top-level
 documents
See also
--------

* `Content-Type`
* The original definition of X-Content-Type-Options by Microsoft.
* The Mozilla Observatory tool testing
 the configuration (including this header) of websites for safety and security
* Mitigating MIME Confusion Attacks in Firefox
* Cross-Origin Read Blocking (CORB)
* Google Docs CORB explainer


NEL - HTTP

NEL
===

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

The HTTP **`NEL`** response header is used to configure network request logging.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

| Specification |
| --- |
| Network Error Logging # nel-response-header |

```http
NEL: { "report\_to": "name\_of\_reporting\_group", "max\_age": 12345, "include\_subdomains": false, "success\_fraction": 0.0, "failure\_fraction": 1.0 }
```

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Network Error Logging (NEL) explainer


Sec-CH-UA-Bitness - HTTP

Sec-CH-UA-Bitness
=================

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

**Secure context:** This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

 The **`Sec-CH-UA-Bitness`** user agent client hint request header provides the "bitness" of the user-agent's underlying CPU architecture.
 This is the size in bits of an integer or memory address—typically 64 or 32 bits.

This might be used by a server, for example, to select and offer the correct binary format of an executable for a user to download.

|  |  |
| --- | --- |
| Header type | Request header,
 Client hint |
| Forbidden header name | yes |

Syntax
------

```http
Sec-CH-UA-Bitness: <bitness>
```

Directives
----------

`<bitness>`

A string indicating the underlying platform architecture bitness, such as: `"64"`, `"32"`.

Examples
--------

A server requests the `Sec-CH-UA-Bitness` header by including the `Accept-CH` in a *response* to any request from the client, using the name of the desired header as a token:

```http
HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Bitness
```

 The client may choose to provide the hint, and add the `Sec-CH-UA-Bitness` header to subsequent requests.
 For example, on a Windows based 64-bit computer, the client might add the header as shown:

```http
GET /GET /my/page HTTP/1.1
Host: example.site

Sec-CH-UA: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"
Sec-CH-UA-Bitness: "64"
```

Specifications
--------------

| Specification |
| --- |
| User-Agent Client Hints # sec-ch-ua-bitness |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Client hints
* User-Agent Client Hints API
* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* `Accept-CH`
* HTTP Caching > Vary and `Vary`


Expect - HTTP

Expect
======

 The **`Expect`** HTTP request header indicates expectations
 that need to be met by the server to handle the request successfully.

Upon `Expect: 100-continue`, the server responds with:

* `100` (Continue) if the information from the request header is insufficient to
 resolve the response and the client should proceed with sending the body.
* `417` (Expectation Failed) if the server cannot meet the expectation

 or any other status otherwise (e.g. a 4xx status for a client error, or a 2xx status if the
 request can be resolved successfully without further processing).

 For example, the server may reject a request if its `Content-Length` is
 too large.

 No common browsers send the `Expect` header, but some other clients such as
 cURL do so by default.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | yes |

Syntax
------

```http
Expect: 100-continue
```

Directives
----------

There is only one defined expectation:

`100-continue`

 Informs recipients that the client is about to send a (presumably large) message
 body in this request and wishes to receive a `100` (Continue) interim
 response.

Examples
--------

### Large message body

 A client sends a request with `Expect` header and waits for the server to respond
 before sending the message body.

```http
PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue
```

 The server checks the headers and generates the response.
 The server sends `100` (Continue), which instructs the client to send the message body.

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.expect |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `417 Expectation Failed`
* `100 Continue`


Access-Control-Request-Method - HTTP

Access-Control-Request-Method
=============================

 The **`Access-Control-Request-Method`** request header is used
 by browsers when issuing a preflight request, to let the server know
 which HTTP method will be used when the
 actual request is made. This header is necessary as the preflight request is always an
 `OPTIONS` and doesn't use the same method as the actual request.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | yes |

Syntax
------

```http
Access-Control-Request-Method: <method>
```

Directives
----------

<method>

 One of the HTTP request methods, for
 example `GET`, `POST`, or `DELETE`.

Examples
--------

```http
Access-Control-Request-Method: POST
```

Specifications
--------------

| Specification |
| --- |
| Fetch Standard # http-access-control-request-method |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Access-Control-Request-Headers`


Sec-CH-UA - HTTP

Sec-CH-UA
=========

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

**Secure context:** This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

The **`Sec-CH-UA`** user agent client hint request header provides the user-agent's branding and significant version information.

|  |  |
| --- | --- |
| Header type | Request header,
 Client hint |
| Forbidden header name | yes |

The **`Sec-CH-UA`** header provides the brand and significant version for each brand associated with the browser in a comma-separated list.

 A brand is a commercial name for the user agent like: Chromium, Opera, Google Chrome, Microsoft Edge, Firefox, and Safari.
 A user agent might have several associated brands.
 For example, Opera, Chrome, and Edge are all based on Chromium, and will provide both brands in the **`Sec-CH-UA`** header.

 The *significant version* is the "marketing" version identifier that is used to distinguish between major releases of the brand.
 For example a Chromium build with *full version number* "96.0.4664.45" has a significant version number of "96".

The header therefore allows the server to customize its response based on both shared brands and on particular customizations in their respective versions.

`Sec-CH-UA` is a low entropy hint.
 Unless blocked by a user agent permission policy, it is sent by default, without the server opting in by sending `Accept-CH`.

 The header may include "fake" brands in any position and with any name.
 This is a feature designed to prevent servers from rejecting unknown user agents outright, forcing user agents to lie about their brand identity.

**Note:** `Sec-CH-UA-Full-Version-List` is the same as **`Sec-CH-UA`**, but includes the full version number rather than the significant version number for each brand.

Syntax
------

 A comma separated list of brands in the user agent brand list, and their associated significant version number.
 The syntax for a single entry has the following format:

```http
Sec-CH-UA: "<brand>";v="<significant version>", ...
```

### Directives

`<brand>`

A brand associated with the user agent, like "Chromium", "Google Chrome", or an intentionally incorrect brand like `"Not A;Brand"`.

`<significant version>`

The "marketing" version number associated with distinguishable web-exposed features.

Examples
--------

`Sec-CH-UA` is a low entropy hint.
 Unless explicitly blocked by a user agent policy, it will be sent in all requests (without the server having to opt in by sending `Accept-CH`).

 Strings from Chromium, Chrome, Edge, and Opera desktop browsers are shown below.
 Note that they all share the "Chromium" brand, but have an additional brand indicating their origin.
 They also have an intentionally incorrect brand string, which may appear in any position and have different text.

```http
Sec-CH-UA: "(Not(A:Brand";v="8", "Chromium";v="98"
```

```http
Sec-CH-UA: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
```

```http
Sec-CH-UA: " Not A;Brand";v="99", "Chromium";v="96", "Microsoft Edge";v="96"
```

```http
Sec-CH-UA: "Opera";v="81", " Not;A Brand";v="99", "Chromium";v="95"
```

Specifications
--------------

| Specification |
| --- |
| User-Agent Client Hints # sec-ch-ua |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Client hints
* User-Agent Client Hints API
* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* `Accept-CH`
* HTTP Caching > Vary and `Vary`


Forwarded - HTTP

Forwarded
=========

The **`Forwarded`** request header contains information that may be added by reverse proxy servers (load balancers, CDNs, and so on) that would otherwise be altered or lost when proxy servers are involved in the path of the request.

 For example, if a client is connecting to a web server through an HTTP proxy (or load balancer), server logs will only contain the IP address, host address, and protocol of the proxy; this header can be used to identify the IP address, host, and protocol, of the original request.
 The header is optional and may be added to, modified, or removed, by any of the proxy servers on the path to the server.

 This header is used for debugging, statistics, and generating location-dependent content.
 By design, it exposes privacy sensitive information, such as the IP address of the client.
 Therefore, the user's privacy must be kept in mind when deploying this header.

The alternative and de-facto standard versions of this header are the `X-Forwarded-For`, `X-Forwarded-Host` and `X-Forwarded-Proto` headers.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

Syntax
------

 The syntax for the forwarding header from a single proxy is shown below.
 Directives are `key=value` pairs, separated by a semicolon.

```http
Forwarded: by=<identifier>;for=<identifier>;host=<host>;proto=<http|https>
```

 If there are multiple proxy servers between the client and server, they may each specify their own forwarding information.
 This can be done by adding a new `Forwarded` header to the end of the header block, or by appending the information to the end of the last `Forwarded` header in a comma-separated list.

Directives
----------

`by` Optional

 The interface where the request came in to the proxy server.
 The identifier can be:

* an obfuscated identifier (such as "hidden" or "secret").
 This should be treated as the default.
* an IP address (v4 or v6, optionally with a port, and ipv6 quoted and enclosed in square brackets)
* "unknown" when the preceding entity is not known (and you still want to indicate that forwarding of the request was made)

`for` Optional

 The client that initiated the request and subsequent proxies in a chain of proxies.
 The identifier has the same possible values as the `by` directive.

`host` Optional

The `Host` request header field as received by the proxy.

`proto` Optional

Indicates which protocol was used to make the request (typically "http" or "https").

Examples
--------

### Using the `Forwarded` header

```http
Forwarded: for="\_mdn"

# case insensitive
Forwarded: For="[2001:db8:cafe::17]:4711"

# separated by semicolon
Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43

# Values from multiple proxy servers can be appended using a comma
Forwarded: for=192.0.2.43, for=198.51.100.17
```

### Transitioning from `X-Forwarded-For` to `Forwarded`

 If your application, server, or proxy supports the standardized `Forwarded` header, the `X-Forwarded-For` header can be replaced.
 Note that an IPv6 address is quoted and enclosed in square brackets in `Forwarded` (unlike in the `X-Forwarded-For` header).

```http
X-Forwarded-For: 192.0.2.172
Forwarded: for=192.0.2.172

X-Forwarded-For: 192.0.2.43, 2001:db8:cafe::17
Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]"
```

Specifications
--------------

| Specification |
| --- |
| Forwarded HTTP Extension # section-4 |

See also
--------

* `X-Forwarded-For`
* `X-Forwarded-Host`
* `X-Forwarded-Proto`
* `Via` – provides information about the proxy itself, not about the client connecting to it.


Content-Security-Policy - HTTP

Content-Security-Policy
=======================

 The HTTP **`Content-Security-Policy`** response header allows
 website administrators to control resources the user agent is allowed to load for a
 given page. With a few exceptions, policies mostly involve specifying server origins and
 script endpoints. This helps guard against cross-site scripting attacks
 (Cross-site\_scripting).

For more information, see the introductory article on Content Security Policy (CSP).

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

```http
Content-Security-Policy: <policy-directive>; <policy-directive>
```

 where `<policy-directive>` consists of:
 `<directive> <value>` with no internal punctuation.

Directives
----------

### Fetch directives

Fetch directives control the locations from which certain resource types may be loaded.

`child-src`

 Defines the valid sources for web workers and nested browsing contexts loaded using elements such as
 `<frame>` and `<iframe>`.

**Warning:** Instead of **`child-src`**,
 if you want to regulate nested browsing contexts and workers,
 you should use the `frame-src` and `worker-src` directives, respectively.

`connect-src`

Restricts the URLs which can be loaded using script interfaces.

`default-src`

Serves as a fallback for the other fetch
 directives.

`font-src`

Specifies valid sources for fonts loaded using `@font-face`.

`frame-src`

 Specifies valid sources for nested browsing contexts loading using elements such as
 `<frame>` and `<iframe>`.

`img-src`

Specifies valid sources of images and favicons.

`manifest-src`

Specifies valid sources of application manifest files.

`media-src`

 Specifies valid sources for loading media using the `<audio>` ,
 `<video>` and `<track>` elements.

`object-src`

Specifies valid sources for the `<object>` and `<embed>` elements.

**Note:** Elements controlled by `object-src` are perhaps
 coincidentally considered legacy HTML elements and are not receiving new standardized
 features (such as the security attributes `sandbox` or `allow`
 for `<iframe>`). Therefore it is **recommended** to
 restrict this fetch-directive (e.g., explicitly set `object-src 'none'` if
 possible).

`prefetch-src`
Deprecated

Non-standard

Specifies valid sources to be prefetched or prerendered.

`script-src`

Specifies valid sources for JavaScript and WebAssembly resources.

`script-src-elem`

Specifies valid sources for JavaScript `<script>` elements.

`script-src-attr`

Specifies valid sources for JavaScript inline event handlers.

`style-src`

Specifies valid sources for stylesheets.

`style-src-elem`

 Specifies valid sources for stylesheets `<style>` elements and
 `<link>` elements with `rel="stylesheet"`.

`style-src-attr`

Specifies valid sources for inline styles applied to individual DOM elements.

`worker-src`

 Specifies valid sources for `Worker`, `SharedWorker`, or
 `ServiceWorker` scripts.

### Document directives

 Document directives govern the properties of a document or worker environment to which a policy
 applies.

`base-uri`

 Restricts the URLs which can be used in a document's `<base>`
 element.

`sandbox`

 Enables a sandbox for the requested resource similar to the
 `<iframe>` `sandbox` attribute.

### Navigation directives

 Navigation directives govern to which locations a user can navigate or submit a form,
 for example.

`form-action`

 Restricts the URLs which can be used as the target of a form submissions from a
 given context.

`frame-ancestors`

 Specifies valid parents that may embed a page using `<frame>`,
 `<iframe>`, `<object>`, or `<embed>`.

### Reporting directives

 Reporting directives control the reporting process of CSP violations. See also the
 `Content-Security-Policy-Report-Only` header.

`report-uri`
Deprecated

 Instructs the user agent to report attempts to violate the Content Security Policy.
 These violation reports consist of JSON documents sent via an HTTP
 `POST` request to the specified URI.

**Warning:** Though the `report-to` directive is intended
 to replace the deprecated **`report-uri`** directive,
 `report-to` is not supported in most browsers yet.
 So for compatibility with current browsers
 while also adding forward compatibility when browsers get `report-to` support,
 you can specify both **`report-uri`** and `report-to`:

```http
Content-Security-Policy: …; report-uri https://endpoint.example.com; report-to groupname
```

 In browsers that support `report-to`,
 the **`report-uri`** directive will be ignored.

`report-to`

Fires a `SecurityPolicyViolationEvent`.

### Other directives

`require-trusted-types-for`
Experimental

Enforces Trusted Types at the DOM XSS injection sinks.

`trusted-types`
Experimental

 Used to specify an allowlist of Trusted Types
 policies. Trusted Types allows applications to lock down DOM XSS injection sinks to
 only accept non-spoofable, typed values in place of strings.

`upgrade-insecure-requests`

 Instructs user agents to treat all of a site's insecure URLs (those served over
 HTTP) as though they have been replaced with secure URLs (those served over HTTPS).
 This directive is intended for websites with large numbers of insecure legacy URLs
 that need to be rewritten.

### Deprecated directives

`block-all-mixed-content`
Deprecated

Prevents loading any assets using HTTP when the page is loaded using HTTPS.

`plugin-types`
Deprecated

Non-standard

 Restricts the set of plugins that can be embedded into a document by limiting the
 types of resources which can be loaded.

`referrer`
Deprecated

Non-standard

 Used to specify information in the Referer (sic) header for links away
 from a page. Use the `Referrer-Policy` header instead.

Values
------

 An overview of the allowed values are listed below.
 For detailed reference see CSP Source Values and the documentation for individual directives.

### Keyword values

`'none'`

Won't allow loading of any resources.

`'self'`

Only allow resources from the current origin.

`'strict-dynamic'`

The trust granted to a script in the page due to an accompanying nonce or hash is extended to the scripts it loads.

`'report-sample'`

Require a sample of the violating code to be included in the violation report.

`'inline-speculation-rules'`

Allows the inclusion of speculation rules in scripts (see also `<script type="speculationrules">`).

### Unsafe keyword values

`'unsafe-inline'`

Allow use of inline resources.

`'unsafe-eval'`

Allow use of dynamic code evaluation such as `eval`, `setTimeout()`, and `window.execScript`
Non-standard
.

`'unsafe-hashes'`

Allows enabling specific inline event handlers.

`'wasm-unsafe-eval'`

 Allows the loading and execution of WebAssembly modules without the need to also allow unsafe JavaScript execution via `'unsafe-eval'`.
 The single quotes are required.

### Hosts values

* Host
    + Only allow loading of resources from a specific host, with optional scheme, port, and path. For example, `example.com`, `*.example.com`, `https://*.example.com:12/path/to/file.js`.
    + Path parts in the CSP that end in `/` match any path they are a prefix of. For example, `example.com/api/` will match URLs like `example.com/api/users/new`.
    + Other path parts in the CSP are matched exactly; for example, `example.com/file.js` will match `http://example.com/file.js` and `https://example.com/file.js`, but not `https://example.com/file.js/file2.js`.
* Scheme
    + Only allow loading of resources over a specific scheme, should always end with "`:`". For example, `https:`, `http:`, `data:`, etc.
### Other values

`'nonce-*'`

A cryptographic nonce (only used once) to allow scripts. The server must generate a unique nonce value each time it transmits a policy. It is critical to provide a nonce that cannot be guessed as bypassing a resource's policy is otherwise trivial. This is used in conjunction with the script tag nonce attribute. For example, `nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV`.

`'sha*-*'`

sha256, sha384, or sha512. Followed by a dash and then the sha\* value. For example, `sha256-jzgBGA4UWFFmpOBq0JpdsySukE1FrEN5bUpoK8Z29fY=`.

CSP in workers
--------------

Workers are in general *not* governed
 by the content security policy of the document (or parent worker) that created them. To
 specify a content security policy for the worker, set a
 `Content-Security-Policy` response header for the request which requested the
 worker script itself.

 The exception to this is if the worker script's origin is a globally unique identifier
 (for example, if its URL has a scheme of data or blob). In this case, the worker does
 inherit the content security policy of the document or worker that created it.

Multiple content security policies
----------------------------------

 The CSP mechanism allows multiple policies being specified for a resource, including
 via the `Content-Security-Policy` header, the
 `Content-Security-Policy-Report-Only` header and a
 `<meta>` element.

 You can use the `Content-Security-Policy` header more than once, as in the
 example below. Pay special attention to the `connect-src` directive here. Even
 though the second policy would allow the connection, the first policy contains
 `connect-src 'none'`. Adding additional policies *can only further
restrict* the capabilities of the protected resource, which means that there will
 be no connection allowed and, as the strictest policy, `connect-src 'none'`
 is enforced.

```http
Content-Security-Policy: default-src 'self' http://example.com;
 connect-src 'none';
Content-Security-Policy: connect-src http://example.com/;
 script-src http://example.com/
```

Examples
--------

 Example: Disable unsafe inline/eval, only allow loading of resources (images, fonts,
 scripts, etc.) over https:

### Using the HTTP header

```http
Content-Security-Policy: default-src https:
```

### Using the HTML meta element

```html
<meta http-equiv="Content-Security-Policy" content="default-src https:" />
```

 Example: Pre-existing site that uses too much inline code to fix but wants to ensure
 resources are loaded only over HTTPS and to disable plugins:

```http
Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'
```

 Example: Do not implement the above policy yet; instead just report violations that
 would have occurred:

```http
Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
```

See Mozilla Web Security Guidelines for more examples.

Specifications
--------------

| Specification |
| --- |
| Content Security Policy Level 3 # csp-header |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Content-Security-Policy-Report-Only`
* Learn about: Content Security Policy
* Content Security in WebExtensions
* Adopting a strict policy
* CSP Evaluator - Evaluate your
 Content Security Policy


Pragma - HTTP

Pragma
======

**Deprecated:** This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

 The **`Pragma`** HTTP/1.0 general header is an
 implementation-specific header that may have various effects along the request-response
 chain. This header serves for backwards compatibility with the HTTP/1.0 caches that do not have a
 `Cache-Control` HTTP/1.1 header.

**Note:** `Pragma` is not specified for HTTP responses and is
 therefore not a reliable replacement for the general HTTP/1.1
 `Cache-Control` header, although its behavior is the same as
 `Cache-Control: no-cache` if the `Cache-Control` header field
 is omitted in a request. Use `Pragma` only for backwards compatibility with
 HTTP/1.0 clients.

|  |  |
| --- | --- |
| Header type | Request header,
 Response header (response behavior is not
 specified and thus implementation-specific).
  |
| Forbidden header name | no |
| CORS-safelisted response header | yes |

Syntax
------

```http
Pragma: no-cache
```

Directives
----------

no-cache

 Same as `Cache-Control: no-cache`. Forces caches to submit the request
 to the origin server for validation before a cached copy is released.

Examples
--------

```http
Pragma: no-cache
```

Specifications
--------------

| Specification |
| --- |
| HTTP Caching # field.pragma |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Cache-Control`
* `Expires`


Critical-CH - HTTP

Critical-CH
===========

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

**Secure context:** This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

The **`Critical-CH`** client hint response header is used along with `Accept-CH` to specify that accepted client hints are also critical client hints.

User agents receiving a response with `Critical-CH` must check if the indicated critical headers were sent in the original request. If not, the user agent will retry the request along with the critical headers rather than render the page. This approach ensures that client preferences set using critical client hints are always used, even if not included in the first request, or following server configuration changes.

Each header listed in the `Critical-CH` header should also be present in the `Accept-CH` and `Vary` headers.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

```http
Critical-CH: <ch-list>
```

### Directives

`<ch-list>`

A list of one or more comma-delimited client hint headers that the server considers to be critical client hints.

Examples
--------

The client makes an initial request to the server:

```http
GET / HTTP/1.1
Host: example.com
```

The server responds, telling the client via `Accept-CH` that it accepts `Sec-CH-Prefers-Reduced-Motion`. In this example `Critical-CH` is also used, indicating that `Sec-CH-Prefers-Reduced-Motion` is considered a critical client hint.

```http
HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Sec-CH-Prefers-Reduced-Motion
Vary: Sec-CH-Prefers-Reduced-Motion
Critical-CH: Sec-CH-Prefers-Reduced-Motion
```

**Note:** We've also specified `Sec-CH-Prefers-Reduced-Motion` in the `Vary` header to indicate that responses should be separately cached based on the value of this header (even if the URL stays the same).
 Each header listed in the `Critical-CH` header should also be present in the `Accept-CH` and `Vary` headers.

The client automatically retries the request (due to `Critical-CH` being specified above), telling the server via `Sec-CH-Prefers-Reduced-Motion` that it has a user preference for reduced-motion animations:

```http
GET / HTTP/1.1
Host: example.com
Sec-CH-Prefers-Reduced-Motion: "reduce"
```

The client will include the header in subsequent requests in the current session unless the `Accept-CH` changes in responses to indicate that it is no longer supported by the server.

Specifications
--------------

| Specification |
| --- |
| Client Hint Reliability # name-the-critical-ch-response-he |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Client hints
* User-Agent Client Hints API
* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* `Accept-CH`
* HTTP Caching > Vary and `Vary`


Upgrade - HTTP

Upgrade
=======

The HTTP 1.1 (only) `Upgrade` header can be used to upgrade an already established client/server connection to a different protocol (over the same transport protocol). For example, it can be used by a client to upgrade a connection from HTTP 1.1 to HTTP 2.0, or an HTTP or HTTPS connection into a WebSocket.

**Warning:** HTTP/2 explicitly disallows the use of this mechanism/header; it is specific to HTTP/1.1.

|  |  |
| --- | --- |
| Header type | Request header,
 Response header |
| Forbidden header name | yes |

Overview
--------

The `Upgrade` header field may be used by clients to invite a server to switch to one (or more) of the listed protocols, in descending preference order.

For example, the client might send a `GET` request as shown, listing the preferred protocols to switch to (in this case "example/1" and "foo/2"):

```http
GET /index.html HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: example/1, foo/2
```

**Note:** `Connection: upgrade` must be set whenever `Upgrade` is sent.

The server can choose to ignore the request, for any reason, in which case it should just respond as though the `Upgrade` header had not been sent (for example, with a `200 OK`).

If the server decides to upgrade the connection, it must:

1. Send back a `101 Switching Protocols` response status with an `Upgrade` header that specifies the protocol(s) being switched to. For example:

```http
HTTP/1.1 101 Switching Protocols
Upgrade: foo/2
Connection: Upgrade
```

2. Send a response to the original request *using the new protocol* (the server may only switch to a protocol with which it can complete the original request).

A server may also send the header as part of a `426` `Upgrade Required` response, to indicate that the server won't perform the request using the current protocol, but might do so if the protocol is changed. The client can then request a protocol change using the process above.

More detail and examples are provided in the topic Protocol upgrade mechanism.

Syntax
------

```http
Connection: upgrade
Upgrade: protocol\_name[/protocol\_version]
```

Notes:

* The `Connection` header with type `upgrade` must *always* be sent with the `Upgrade` header (as shown above).
* Protocols are listed, comma-separated, in order of descending preference. Protocol version is optional. For example:

```http
Connection: upgrade
Upgrade: a\_protocol/1, example, another\_protocol/2.2
```

Directives
----------

any comma-separated list protocol names (each with optional protocol version)

One or more protocol names with optional version ("/" separated). The protocols are listed in order of descending preference.

Examples
--------

```http
Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
```

```http
Connection: Upgrade
Upgrade: websocket
```

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.upgrade |
| HTTP Semantics # status.426 |
| HTTP/2 # informational-responses |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Protocol upgrade mechanism
* `101` `Switching Protocol`
* `426` `Upgrade Required`
* `Connection`


Content-Range - HTTP

Content-Range
=============

 The **`Content-Range`** response HTTP header indicates where in
 a full body message a partial message belongs.

|  |  |
| --- | --- |
| Header type | Response header,
 Payload header |
| Forbidden header name | no |
| CORS-safelisted
 response-header | no |

Syntax
------

```http
Content-Range: <unit> <range-start>-<range-end>/<size>
Content-Range: <unit> <range-start>-<range-end>/\*
Content-Range: <unit> \*/<size>
```

Directives
----------

<unit>

The unit in which ranges are specified. This is usually `bytes`.

<range-start>

An integer in the given unit indicating the start position (zero-indexed & inclusive) of the request range.

<range-end>

An integer in the given unit indicating the end position (zero-indexed & inclusive) of the requested range.

<size>

The total length of the document (or `'*'` if unknown).

Examples
--------

```http
Content-Range: bytes 200-1000/67589
```

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.content-range |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `If-Range`
* `Range`
* `Content-Type`
* `206` `Partial Content`
* `416` `Range Not Satisfiable`


Expect-CT - HTTP

Expect-CT
=========

**Deprecated:** This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

The `Expect-CT` header lets sites opt in to reporting and/or enforcement of Certificate Transparency requirements. Certificate Transparency (CT) aims to prevent the use of misissued certificates for that site from going unnoticed.

Only Google Chrome and other Chromium-based browsers implemented `Expect-CT`, and Chromium has deprecated the header from version 107, because Chromium now enforces CT by default. See the Chrome Platform Status update.

CT requirements can be satisfied via any one of the following mechanisms:

* X.509v3 certificate extension to allow embedding of signed certificate timestamps issued by individual logs. Most TLS certificates issued by publicly-trusted CAs and used online contain embedded CT.
* A TLS extension of type `signed_certificate_timestamp` sent during the handshake
* Supporting OCSP stapling (that is, the `status_request` TLS extension) and providing a `SignedCertificateTimestampList`

**Note:** When a site enables the `Expect-CT` header, they are requesting that the browser check that any certificate for that site appears in **public CT logs**.

**Note:** Browsers **ignore** the `Expect-CT` header over HTTP; the header only has effect on HTTPS connections.

**Note:** The `Expect-CT` is mostly obsolete since June 2021. Since May 2018, all new TLS certificates are expected to support SCTs by default. Certificates issued before March 2018 were allowed to have a lifetime of 39 months, so they had expired in June 2021. Chromium plans to deprecate `Expect-CT` header and to eventually remove it.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | yes |

Syntax
------

```http
Expect-CT: report-uri="<uri>",
 enforce,
 max-age=<age>
```

Directives
----------

`max-age`

The number of seconds after reception of the `Expect-CT` header field during which the user agent should regard the host of the received message as a known `Expect-CT` host.

If a cache receives a value greater than it can represent, or if any of its subsequent calculations overflows, the cache will consider this value to be either 2,147,483,648 (2^31) or the greatest positive integer it can represent.

`report-uri="<uri>"` Optional

The URI where the user agent should report `Expect-CT` failures.

When present with the `enforce` directive, the configuration is referred to as an "enforce-and-report" configuration, signalling to the user agent both that compliance to the Certificate Transparency policy should be enforced *and* that violations should be reported.

`enforce` Optional

Signals to the user agent that compliance with the Certificate Transparency policy should be enforced (rather than only reporting compliance) and that the user agent should refuse future connections that violate its Certificate Transparency policy.

When both the `enforce` directive and the `report-uri` directive are present, the configuration is referred to as an "enforce-and-report" configuration, signalling to the user agent both that compliance to the Certificate Transparency policy should be enforced and that violations should be reported.

Example
-------

The following example specifies enforcement of Certificate Transparency for 24 hours and reports violations to `foo.example.com`.

```http
Expect-CT: max-age=86400, enforce, report-uri="https://foo.example.com/report"
```

Notes
-----

Root CAs manually added to the trust store override and suppress `Expect-CT` reports/enforcement.

Browsers will not remember an `Expect-CT` policy, unless the site has 'proven' it can serve a certificate satisfying the certificate transparency requirements. Browsers implement their own trust model regarding which CT logs are considered trusted for the certificate to have been logged to.

Builds of Chrome are designed to stop enforcing the `Expect-CT` policy 10 weeks after the installation's build date.

Specifications
--------------

| Specification |
| --- |
| Expect-CT Extension for HTTP # section-2.1 |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


Last-Modified - HTTP

Last-Modified
=============

 The **`Last-Modified`** response HTTP header contains a date
 and time when the origin server believes the resource was last modified. It is used
 as a validator to determine if the resource is the same as the previously stored one. Less accurate
 than an `ETag` header, it is a fallback mechanism. Conditional requests
 containing `If-Modified-Since` or `If-Unmodified-Since`
 headers make use of this field.

`Last-Modified` is also used by crawlers to adjust crawl frequency, by browsers in heuristic caching, and by content management systems (CMS) to display the time the content was last modified.

|  |  |
| --- | --- |
| Header type | Representation header |
| Forbidden header name | no |
| CORS-safelisted response header | yes |

Syntax
------

```http
Last-Modified: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

Directives
----------

<day-name>

One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).

<day>

2 digit day number, e.g. "04" or "23".

<month>

 One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov",
 "Dec" (case sensitive).

<year>

4 digit year number, e.g. "1990" or "2016".

<hour>

2 digit hour number, e.g. "09" or "23".

<minute>

2 digit minute number, e.g. "04" or "59".

<second>

2 digit second number, e.g. "04" or "59".

`GMT`

Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.

Examples
--------

```http
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
```

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.last-modified |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `If-Modified-Since`
* `If-Unmodified-Since`
* `Etag`


If-None-Match - HTTP

If-None-Match
=============

The **`If-None-Match`** HTTP request header makes the request conditional. For `GET` and `HEAD` methods, the server will return the requested resource, with a `200` status, only if it doesn't have an `ETag` matching the given ones. For other methods, the request will be processed only if the eventually existing resource's `ETag` doesn't match any of the values listed.

When the condition fails for `GET` and `HEAD` methods, then the server must return HTTP status code 304 (Not Modified). For methods that apply server-side changes, the status code 412 (Precondition Failed) is used. Note that the server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

The comparison with the stored `ETag` uses the *weak comparison algorithm*, meaning two files are considered identical if the content is equivalent — they don't have to be identical byte by byte. For example, two pages that differ by their creation date in the footer would still be considered identical.

When used in combination with `If-Modified-Since`, **`If-None-Match`** has precedence (if the server supports it).

There are two common use cases:

* For `GET` and `HEAD` methods, to update a cached entity that has an associated `ETag`.
* For other methods, and in particular for `PUT`, `If-None-Match` used with the `*` value can be used to save a file not known to exist, guaranteeing that another upload didn't happen before, losing the data of the previous put; this problem is a variation of the lost update problem.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

Syntax
------

```http
If-None-Match: "<etag\_value>"
If-None-Match: "<etag\_value>", "<etag\_value>", …
If-None-Match: \*
```

Directives
----------

<etag\_value>

Entity tags uniquely representing the requested resources. They are a string of ASCII characters placed between double quotes (Like `"675af34563dc-tr34"`) and may be prefixed by `W/` to indicate that the weak comparison algorithm should be used (this is useless with `If-None-Match` as it only uses that algorithm).

`*`

The asterisk is a special value representing any resource. They are only useful when uploading a resource, usually with `PUT`, to check if another resource with the identity has already been uploaded before.

Examples
--------

```http
If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

If-None-Match: W/"67ab43", "54ed21", "7892dd"

If-None-Match: \*
```

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.if-none-match |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `ETag`
* `If-Unmodified-Since`
* `If-Modified-Since`
* `If-Match`
* `304 Not Modified`
* `412 Precondition Failed`


Sec-CH-Prefers-Reduced-Motion - HTTP

Sec-CH-Prefers-Reduced-Motion
=============================

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

**Secure context:** This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

The **`Sec-CH-Prefers-Reduced-Motion`** user agent client hint request header indicates the user agent's preference for animations to be displayed with reduced motion.

If a server signals to a client via the `Accept-CH` header that it accepts `Sec-CH-Prefers-Reduced-Motion`, the client can then respond with this header to indicate the user's preference for reduced motion. The server can send the client appropriately adapted content, for example, JavaScript or CSS, to reduce the motion of any animations presented on subsequent rendered content. This could include reducing the speed or amplitude of movement to reduce discomfort for those with vestibular motion disorders.

This header is modeled on the `prefers-reduced-motion` media query.

|  |  |
| --- | --- |
| Header type | Request header,
 Client hint |
| Forbidden header name | yes |

Syntax
------

```http
Sec-CH-Prefers-Reduced-Motion: <preference>
```

### Directives

`<preference>`

The user agent's preference for reduced-motion animations. This is often taken from the underlying operating system's setting. The value of this directive can be either `no-preference` or `reduce`.

Examples
--------

The client makes an initial request to the server:

```http
GET / HTTP/1.1
Host: example.com
```

The server responds, telling the client via `Accept-CH` that it accepts `Sec-CH-Prefers-Reduced-Motion`. In this example `Critical-CH` is also used, indicating that `Sec-CH-Prefers-Reduced-Motion` is considered a critical client hint.

```http
HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Sec-CH-Prefers-Reduced-Motion
Vary: Sec-CH-Prefers-Reduced-Motion
Critical-CH: Sec-CH-Prefers-Reduced-Motion
```

**Note:** We've also specified `Sec-CH-Prefers-Reduced-Motion` in the `Vary` header to indicate to the browser that the served content will differ based on this header value, even if the URL stays the same, so the browser shouldn't just use an existing cached response and instead should cache this response separately. Each header listed in the `Critical-CH` header should also be present in the `Accept-CH` and `Vary` headers.

The client automatically retries the request (due to `Critical-CH` being specified above), telling the server via `Sec-CH-Prefers-Reduced-Motion` that it has a user preference for reduced-motion animations:

```http
GET / HTTP/1.1
Host: example.com
Sec-CH-Prefers-Reduced-Motion: "reduce"
```

The client will include the header in subsequent requests in the current session unless the `Accept-CH` changes in responses to indicate that it is no longer supported by the server.

Specifications
--------------

| Specification |
| --- |
| User Preference Media Features Client Hints Headers # sec-ch-prefers-reduced-motion |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Client hints
* `prefers-reduced-motion` CSS Media Query
* User-Agent Client Hints API
* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* `Accept-CH`
* HTTP Caching > Vary and `Vary`


Timing-Allow-Origin - HTTP

Timing-Allow-Origin
===================

The **`Timing-Allow-Origin`** response header specifies origins that are allowed to see values of attributes retrieved via features of the Resource Timing API, which would otherwise be reported as zero due to cross-origin restrictions.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

```http
Timing-Allow-Origin: \*
Timing-Allow-Origin: <origin>[, <origin>]\*
```

Directives
----------

`*`

The server may specify "\*" as a wildcard, thereby allowing any origin to see timing resources.

<origin>

Specifies a URI that may see the timing resources. You can specify multiple origins, separated by commas.

Examples
--------

To allow any resource to see timing resources:

```http
Timing-Allow-Origin: \*
```

To allow `https://developer.mozilla.org` to see timing resources, you can specify:

```http
Timing-Allow-Origin: https://developer.mozilla.org
```

Specifications
--------------

| Specification |
| --- |
| Resource Timing # sec-timing-allow-origin |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Resource Timing API
* `Vary`


Cookie - HTTP

Cookie
======

The **`Cookie`** HTTP request header contains stored HTTP cookies associated with the server (i.e. previously sent by the server with the `Set-Cookie` header or set in JavaScript using `Document.cookie`).

The `Cookie` header is optional and may be omitted if, for example, the browser's privacy settings block cookies.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | yes |

Syntax
------

```http
Cookie: <cookie-list>
Cookie: name=value
Cookie: name=value; name2=value2; name3=value3
```

Directives
----------

<cookie-list>

A list of name-value pairs in the form of `<cookie-name>=<cookie-value>`. Pairs in the list are separated by a semicolon and a space (`'; '`).

Examples
--------

```http
Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; \_gat=1
```

Specifications
--------------

| Specification |
| --- |
| HTTP State Management Mechanism # cookie |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Set-Cookie`
* `Document.cookie`


Alt-Svc - HTTP

Alt-Svc
=======

The `Alt-Svc` HTTP header allows a server to indicate that another network location (the "alternative service") can be treated as authoritative for that origin when making future requests.

Doing so allows new protocol versions to be advertised without affecting in-flight requests, and can also help servers manage traffic. Using an alternative service is not visible to the end user; it does not change the URL or the origin of the request, and does not introduce extra round trips.

Syntax
------

```http
Alt-Svc: clear
Alt-Svc: <protocol-id>=<alt-authority>; ma=<max-age>
Alt-Svc: <protocol-id>=<alt-authority>; ma=<max-age>; persist=1
```

`clear`

The special value `clear` indicates that the origin requests all alternative services for that origin to be invalidated.

`<protocol-id>`

The ALPN protocol identifier. Examples include `h2` for HTTP/2 and `h3-25` for draft 25 of the HTTP/3 protocol.

`<alt-authority>`

The quoted string specifying the alternative authority which consists of an optional host override, a colon, and a mandatory port number.

`ma=<max-age>` Optional

 The number of seconds for which the alternative service is considered fresh.
 If omitted, it defaults to 24 hours.
 Alternative service entries can be cached for up to *<max-age>* seconds, minus the age of the response (from the `Age` header).
 Once the cached entry expires, the client can no longer use this alternative service for new connections.

`persist=1` Optional

 Usually cached alternative service entries are cleared on network configuration changes.
 Use of the `persist=1` parameter requests that the entry not be deleted by such changes.

 Multiple entries can be specified in a single `Alt-Svc` header using comma as separator.
 In that case, early entries are considered more preferable.

Example
-------

```http
Alt-Svc: h2=":443"; ma=2592000;
Alt-Svc: h2=":443"; ma=2592000; persist=1
Alt-Svc: h2="alt.example.com:443", h2=":443"
Alt-Svc: h3-25=":443"; ma=3600, h2=":443"; ma=3600
```

Specifications
--------------

| Specification |
| --- |
| HTTP Alternative Services # alt-svc |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Alternative Services (article about `Alt-Svc` by HTTP Working Group chair Mark Nottingham)


Content-Length - HTTP

Content-Length
==============

The **`Content-Length`** header indicates the size of the message body, in bytes, sent to the recipient.

|  |  |
| --- | --- |
| Header type | Request header,
 Response header,
 Payload header |
| Forbidden header name | yes |
| CORS-safelisted response header | yes |

Syntax
------

```http
Content-Length: <length>
```

Directives
----------

<length>

The length in decimal number of octets.

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.content-length |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Transfer-Encoding`


Origin - HTTP

Origin
======

 The **`Origin`** request header indicates the origin (scheme, hostname, and port) that *caused* the request.
 For example, if a user agent needs to request resources included in a page, or fetched by scripts that it executes, then the origin of the page may be included in the request.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | yes |

Syntax
------

```http
Origin: null
Origin: <scheme>://<hostname>
Origin: <scheme>://<hostname>:<port>
```

Directives
----------

`null`

The origin is "privacy sensitive", or is an *opaque origin* as defined by the HTML specification (specific cases are listed in the description section).

`<scheme>`

 The protocol that is used.
 Usually, it is the HTTP protocol or its secured version, HTTPS.

`<hostname>`

The domain name or the IP address of the origin server.

`<port>` Optional

 Port number on which the server is listening.
 If no port is given, the default port for the requested service is implied (e.g., "80" for an HTTP URL) .

Description
-----------

 The `Origin` header is similar to the `Referer` header, but does not disclose the path, and may be `null`.
 It is used to provide the "security context" for the origin request, except in cases where the origin information would be sensitive or unnecessary.

Broadly speaking, user agents add the `Origin` request header to:

* cross origin requests.
* same-origin requests except for `GET` or `HEAD` requests (i.e. they are added to same-origin `POST`, `OPTIONS`, `PUT`, `PATCH`, and `DELETE` requests).

There are some exceptions to the above rules; for example, if a cross-origin `GET` or `HEAD` request is made in no-cors mode, the `Origin` header will not be added.

The `Origin` header value may be `null` in a number of cases, including (non-exhaustively):

* Origins whose scheme is not one of `http`, `https`, `ftp`, `ws`, `wss`, or `gopher` (including `blob`, `file` and `data`).
* Cross-origin images and media data, including that in `<img>`, `<video>` and `<audio>` elements.
* Documents created programmatically using `createDocument()`, generated from a `data:` URL, or that do not have a creator browsing context.
* Redirects across origins.
* iframes with a sandbox attribute that doesn't contain the value `allow-same-origin`.
* Responses that are network errors.
* `Referrer-Policy` set to `no-referrer` for non-`cors` request modes (e.g. simple form posts).

**Note:** There is a more detailed listing of cases that may return `null` on Stack Overflow: When do browsers send the Origin header? When do browsers set the origin to null?

Examples
--------

```http
Origin: https://developer.mozilla.org
```

```http
Origin: http://developer.mozilla.org:80
```

Specifications
--------------

| Specification |
| --- |
| The Web Origin Concept # section-7 |
| Fetch Standard # origin-header |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Host`
* `Referer`
* Same-origin policy
* When do browsers send the Origin header? When do browsers set the origin to null? (Stack Overflow)


Vary - HTTP

Vary
====

The **`Vary`** HTTP response header describes the parts of the request message aside from the method and URL that influenced the content of the response it occurs in. Most often, this is used to create a cache key when content negotiation is in use.

The same `Vary` header value should be used on all responses for a given URL, including `304` `Not Modified` responses and the "default" response.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

```http
Vary: \*
Vary: <header-name>, <header-name>, ...
```

Directives
----------

\*

Indicates that factors other than request headers influenced the generation of this response. Implies that the response is uncacheable.

<header-name>

A comma-separated list of request header names that could have influenced the generation of this response.

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.vary |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

### Compatibility notes

* Vary with care – Vary header problems in IE6-9
See also
--------

* Understanding The Vary Header - Smashing Magazine
* Best Practices for Using the Vary Header – fastly.com
* Content negotiation


Sec-WebSocket-Accept - HTTP

Sec-WebSocket-Accept
====================

 The **Sec-WebSocket-Accept** header is used in the websocket opening
 handshake. It would appear in the response headers. That is, this is header is sent from
 server to client to inform that server is willing to initiate a websocket connection.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

```http
Sec-WebSocket-Accept: <hashed key>
```

Directives
----------

<hashed key>

 The server takes the value of the Sec-WebSocket-Key sent in the handshake request,
 appends `258EAFA5-E914-47DA-95CA-C5AB0DC85B11`, takes SHA-1 of the new
 value, and is then base64
 encoded.

Examples
--------

```http
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
```

Specifications
--------------

#### No specification found

No specification data found for `http.headers.Sec-WebSocket-Accept`.
Check for problems with this page or contribute a missing `spec_url` to mdn/browser-compat-data. Also make sure the specification is included in w3c/browser-specs.

See also
--------

* `Sec-WebSocket-Key`
Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


ETag - HTTP

ETag
====

 The **`ETag`** (or **entity tag**) HTTP response header is an identifier for a
 specific version of a resource. It lets caches be more efficient and save bandwidth, as
 a web server does not need to resend a full response if the content was not changed.
 Additionally, etags help to prevent simultaneous updates of a resource from overwriting
 each other ("mid-air collisions").

 If the resource at a given URL changes, a new `Etag` value *must* be
 generated. A comparison of them can determine whether two representations of a resource
 are the same.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

```http
ETag: W/"<etag\_value>"
ETag: "<etag\_value>"
```

Directives
----------

`W/` Optional

`'W/'` (case-sensitive) indicates that a weak validator
 is used. Weak etags are easy to generate, but are far less useful for comparisons.
 Strong validators are ideal for comparisons but can be very difficult to generate
 efficiently. Weak `ETag` values of two representations of the same
 resources might be semantically equivalent, but not byte-for-byte identical. This
 means weak etags prevent caching when byte range requests are used,
 but strong etags mean range requests can still be cached.

"<etag\_value>"

 Entity tag that uniquely represents the requested resource. It is a string of ASCII
 characters placed between double quotes, like `"675af34563dc-tr34"`. The
 method by which `ETag` values are generated is not specified. Typically, the ETag value
 is a hash of the content, a hash of the last modification timestamp, or just a revision number.
 For example, a wiki engine can use a hexadecimal hash of the documentation article content.

Examples
--------

```http
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"
```

### Avoiding mid-air collisions

 With the help of the `ETag` and the `If-Match` headers, you
 can detect mid-air edit collisions.

 For example, when editing a wiki, the current wiki content may be hashed
 and put into an `Etag` header in the response:

```http
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

 When saving changes to a wiki page (posting data), the `POST` request
 will contain the `If-Match` header containing the `ETag`
 values to check freshness against.

```http
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

 If the hashes don't match, it means that the document has been edited in-between and a
 `412` `Precondition Failed` error is thrown.

### Caching of unchanged resources

 Another typical use of the `ETag` header is to cache resources that are
 unchanged. If a user visits a given URL again (that has an `ETag` set), and
 it is *stale* (too old to be considered usable), the client will send the value
 of its `ETag` along in an `If-None-Match` header field:

```http
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

 The server compares the client's `ETag` (sent with
 `If-None-Match`) with the `ETag` for its current version of the
 resource, and if both values match (that is, the resource has not changed), the server
 sends back a `304` `Not Modified` status, without a body,
 which tells the client that the cached version of the response is still good to use
 (*fresh*).

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.etag |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `If-Match`
* `If-None-Match`
* `304 Not Modified`
* `Precondition Failed`
* W3C Note: Editing the Web – Detecting the Lost Update Problem Using Unreserved Checkout


Transfer-Encoding - HTTP

Transfer-Encoding
=================

The **`Transfer-Encoding`** header specifies the form of encoding used to safely transfer the payload body to the user.

**Note:** HTTP/2 disallows all uses of the Transfer-Encoding header other than the HTTP/2 specific: `"trailers"`. HTTP 2 provides its own more efficient mechanisms for data streaming than chunked transfer and forbids the use of the header. Usage of the header in HTTP/2 may likely result in a specific `protocol error` as HTTP/2 Protocol prohibits the use.

`Transfer-Encoding` is a hop-by-hop header, that is applied to a message between two nodes, not to a resource itself.
 Each segment of a multi-node connection can use different `Transfer-Encoding` values.
 If you want to compress data over the whole connection, use the end-to-end `Content-Encoding` header instead.

When present on a response to a `HEAD` request that has no body, it indicates the value that would have applied to the corresponding `GET` message.

|  |  |
| --- | --- |
| Header type | Request header, Response header, Payload header |
| Forbidden header name | yes |

Syntax
------

```http
Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip

// Several values can be listed, separated by a comma
Transfer-Encoding: gzip, chunked
```

Directives
----------

`chunked`

 Data is sent in a series of chunks. The `Content-Length` header is omitted in this case and at the beginning of each chunk you need to add the length of the current chunk in hexadecimal format, followed by '`\r\n`' and then the chunk itself, followed by another '`\r\n`'.
 The terminating chunk is a regular chunk, with the exception that its length is zero.
 It is followed by the trailer, which consists of a (possibly empty) sequence of header fields.

`compress`

 A format using the Lempel-Ziv-Welch (LZW) algorithm.
 The value name was taken from the UNIX *compress* program, which implemented this algorithm.
 Like the compress program, which has disappeared from most UNIX distributions, this content-encoding is used by almost no browsers today, partly because of a patent issue (which expired in 2003).

`deflate`

Using the zlib structure (defined in RFC 1950), with the *deflate* compression algorithm (defined in RFC 1951).

`gzip`

 A format using the Lempel-Ziv coding (LZ77), with a 32-bit CRC.
 This is originally the format of the UNIX *gzip* program.
 The HTTP/1.1 standard also recommends that the servers supporting this content-encoding should recognize `x-gzip` as an alias, for compatibility purposes.

Examples
--------

### Chunked encoding

 Chunked encoding is useful when larger amounts of data are sent to the client and the total size of the response may not be known until the request has been fully processed.
 For example, when generating a large HTML table resulting from a database query or when transmitting large images.
A chunked response looks like this:

```http
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
11\r\n
Developer Network\r\n
0\r\n
\r\n
```

Specifications
--------------

| Specification |
| --- |
| HTTP/1.1 # field.transfer-encoding |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Accept-Encoding`
* `Content-Encoding`
* `Content-Length`
* Header fields that regulate the use of trailers: `TE` (requests) and `Trailer` (responses).
* Chunked transfer encoding


Sec-Fetch-Mode - HTTP

Sec-Fetch-Mode
==============

The **`Sec-Fetch-Mode`** fetch metadata request header indicates the mode of the request.

Broadly speaking, this allows a server to distinguish between: requests originating from a user navigating between HTML pages, and requests to load images and other resources. For example, this header would contain `navigate` for top level navigation requests, while `no-cors` is used for loading an image.

|  |  |
| --- | --- |
| Header type | Fetch Metadata Request Header |
| Forbidden header name | yes (prefix `Sec-`) |
| CORS-safelisted request header | no |

Syntax
------

```http
Sec-Fetch-Mode: cors
Sec-Fetch-Mode: navigate
Sec-Fetch-Mode: no-cors
Sec-Fetch-Mode: same-origin
Sec-Fetch-Mode: websocket
```

Servers should ignore this header if it contains any other value.

Directives
----------

**Note:** These directives correspond to the values in `Request.mode`.

`cors`

The request is a CORS protocol request.

`navigate`

The request is initiated by navigation between HTML documents.

`no-cors`

The request is a no-cors request (see `Request.mode`).

`same-origin`

The request is made from the same origin as the resource that is being requested.

`websocket`

The request is being made to establish a WebSocket connection.

Examples
--------

If a user clicks on a page link to another page on the same origin, the resulting request would have the following headers (note that the mode is `navigate`):

```http
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
```

A cross-site request generated by an `<img>` element would result in a request with the following HTTP request headers (note that the mode is `no-cors`):

```http
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site
```

Specifications
--------------

| Specification |
| --- |
| Fetch Metadata Request Headers # sec-fetch-mode-header |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Related headers
    + `Sec-Fetch-Dest`
    + `Sec-Fetch-Site`
    + `Sec-Fetch-User`
* Protect your resources from web attacks with Fetch Metadata (web.dev)
* Fetch Metadata Request Headers playground (secmetadata.appspot.com)


Accept-Language - HTTP

Accept-Language
===============

 The **`Accept-Language`** request HTTP header indicates the natural language and locale that the client prefers.
 The server uses content negotiation to select one of the proposals and informs the client of the choice with the `Content-Language` response header. Browsers set required values for this header according to their active user interface language. Users rarely change it, and such changes are not recommended because they may lead to fingerprinting.

This header serves as a hint when the server cannot determine the target content language otherwise (for example, use a specific URL that depends on an explicit user decision). The server should never override an explicit user language choice. The content of `Accept-Language` is often out of a user's control (when traveling, for instance). A user may also want to visit a page in a language different from the user interface language.

The server possibly can send back a `406` (Not Acceptable) error code when unable to serve content in a matching language. However, such a behavior is rarely implemented for a better user experience, and servers often ignore the `Accept-Language` header in such cases.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |
| CORS-safelisted request header |
 yes, with the additional restriction that values can only be
 `0-9`, `A-Z`, `a-z`, space or
 `*,-.;=`.
  |

Syntax
------

```http
Accept-Language: <language>
Accept-Language: \*

// Multiple types, weighted with the quality value syntax:
Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, \*;q=0.5
```

Directives
----------

`<language>`

 A language tag (which is sometimes referred to as a "locale identifier"). This
 consists of a 2-3 letter base language tag that indicates a language, optionally
 followed by additional subtags separated by `'-'`. The most common extra
 information is the country or region variant (like `'en-US'` or
 `'fr-CA'`) or the type of alphabet to use (like `'sr-Latn'`).
 Other variants, like the type of orthography (`'de-DE-1996'`), are usually
 not used in the context of this header.

`*`

Any language; `'*'` is used as a wildcard.

`;q=` (q-factor weighting)

 Any value placed in an order of preference expressed using a relative
 quality value called *weight*.

Examples
--------

```http
Accept-Language: de
```

```http
Accept-Language: de-CH
```

```http
Accept-Language: en-US,en;q=0.5
```

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.accept-language |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* HTTP content negotiation
* A header with the result of the content negotiation:
 `Content-Language`
* Other similar headers: `TE`, `Accept-Encoding`, `Accept`


Trailer - HTTP

Trailer
=======

 The **Trailer** response header allows the sender to include additional
 fields at the end of chunked messages in order to supply metadata that might be
 dynamically generated while the message body is sent, such as a message integrity check,
 digital signature, or post-processing status.

**Note:** The `TE` request header needs to be set to "trailers" to allow
 trailer fields.

|  |  |
| --- | --- |
| Header type | Request header,
 Response header,
 Payload header |
| Forbidden header name | yes |

Syntax
------

```http
Trailer: header-names
```

Directives
----------

`header-names`

 HTTP header fields which will be present in the trailer part of chunked messages.
 These header fields are **disallowed**:

* message framing headers (e.g., `Transfer-Encoding` and
 `Content-Length`),
* routing headers (e.g., `Host`),
* request modifiers (e.g., controls and conditionals, like
 `Cache-Control`, `Max-Forwards`, or
 `TE`),
* authentication headers (e.g., `Authorization` or
 `Set-Cookie`),
* or `Content-Encoding`, `Content-Type`,
 `Content-Range`, and `Trailer` itself.

Examples
--------

### Chunked transfer encoding using a trailing header

 In this example, the `Expires` header is used at the end of the chunked
 message and serves as a trailing header.

```http
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
Trailer: Expires

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
Expires: Wed, 21 Oct 2015 07:28:00 GMT\r\n
\r\n
```

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.trailer |
| HTTP/1.1 # chunked.trailer.section |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Transfer-Encoding`
* `TE`
* Chunked transfer encoding


Sec-CH-UA-Arch - HTTP

Sec-CH-UA-Arch
==============

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

**Secure context:** This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

The **`Sec-CH-UA-Arch`** user agent client hint request header provides the user-agent's underlying CPU architecture, such as ARM or x86.

This might be used by a server, for example, to select and offer the correct binary format of an executable for a user to download.

|  |  |
| --- | --- |
| Header type | Request header,
 Client hint |
| Forbidden header name | yes |

Syntax
------

```http
Sec-CH-UA-Arch: <arch>
```

### Directives

`<arch>`

A string indicating the underlying platform architecture, such as: `"x86"`, `"ARM"`, `"[arm64-v8a, armeabi-v7a, armeabi]"`.

Examples
--------

A server requests the `Sec-CH-UA-Arch` header by including the `Accept-CH` in a response to some request from the client, using the name of the desired header as a token:

```http
HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch
```

 The client may choose to provide the hint, and add the `Sec-CH-UA-Arch` header to subsequent requests.
 For example, on a Windows X86 based computer, the client might add the header as shown:

```http
GET /GET /my/page HTTP/1.1
Host: example.site

Sec-CH-UA: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"
Sec-CH-UA-Arch: "x86"
```

Note above that the low entropy headers are added to the request even though not specified in the server response.

Specifications
--------------

| Specification |
| --- |
| User-Agent Client Hints # sec-ch-ua-arch |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Client hints
* User-Agent Client Hints API
* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* `Accept-CH`
* HTTP Caching > Vary and `Vary`


Referer - HTTP

Referer
=======

 The **`Referer`** HTTP request header contains the absolute or partial address from which a resource has been requested.
 The `Referer` header allows a server to identify referring pages that people are visiting from or where requested resources are being used.
 This data can be used for analytics, logging, optimized caching, and more.

 When you click a link, the **`Referer`** contains the address of the page that includes the link.
 When you make resource requests to another domain, the **`Referer`** contains the address of the page that uses the requested resource.

 The `Referer` header can contain an *origin*, *path*, and *querystring*, and may not contain URL fragments (i.e. `#section`) or `username:password` information.
 The request's *referrer policy* defines the data that can be included. See `Referrer-Policy` for more information and examples.

**Note:** The header name "referer" is actually a misspelling of the word "referrer".
 See HTTP referer on Wikipedia for more details.

**Warning:** This header may have undesirable consequences for user security and privacy.
 See Referer header: privacy and security concerns for more information and mitigation hints.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | yes |

Syntax
------

```http
Referer: <url>
```

Directives
----------

<url>

 An absolute or partial address of the web page that makes the request.
 URL fragments (i.e. `#section`) and userinfo (i.e. `username:password` in `https\://username:password\@example.com/foo/bar/`) are not included.
 Origin, path, and querystring may be included, depending on the referrer policy.

Examples
--------

```http
Referer: https://developer.mozilla.org/en-US/docs/Web/JavaScript
Referer: https://example.com/page?q=123
Referer: https://example.com/
```

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.referer |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* HTTP referer on Wikipedia
* Fetch: `Request.referrerPolicy`
* The obsolete `Content-Security-Policy` `referrer`
Deprecated
 directive.
* Same-origin policy
* Tighter Control Over Your Referrers – Mozilla Security Blog


Sec-CH-Prefers-Color-Scheme - HTTP

Sec-CH-Prefers-Color-Scheme
===========================

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

**Secure context:** This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

The **`Sec-CH-Prefers-Color-Scheme`** user preference media feature client hint request header provides the user's preference for light or dark color themes. A user indicates their preference through an operating system setting (for example, light or dark mode) or a user agent setting.

If a server signals to a client via the `Accept-CH` header that it accepts `Sec-CH-Prefers-Color-Scheme`, the client can then respond with this header to indicate the user's preference for a specific color scheme. The server can send the client appropriately adapted content including images or CSS to display a light or dark mode for subsequent rendered content.

This header is modeled on the `prefers-color-scheme` media query.

|  |  |
| --- | --- |
| Header type | Request header,
 Client hint |
| Forbidden header name | yes |

Usage notes
-----------

The **`Sec-CH-Prefers-Color-Scheme`** header allows sites to obtain user color scheme preference at request time; they could then choose to provide the relevant CSS for the user's preference inline, for performance reasons. If the server inlines the CSS, it might want to include a `Vary` response header specifying `Sec-CH-Prefers-Color-Scheme`, to indicate that the response is tailored for a particular color scheme.

If performance is not a critical consideration in this context, you could instead handle the user's color scheme preference using the `prefers-color-scheme` media query, and/or the `Window.matchMedia()` API.

`Sec-CH-Prefers-Color-Scheme` is a high entropy hint so the site needs to opt into receiving it by sending an appropriate `Accept-CH` response header. A user agent may intentionally omit the `Sec-CH-Prefers-Color-Scheme` header to preserve user privacy since the user's preference could, in theory, be used for fingerprinting.

Syntax
------

```http
Sec-CH-Prefers-Color-Scheme: <preference>
```

### Directives

`<preference>`

 A string indicating the user agent's preference for dark or light content: `"light"` or `"dark"`.
 The value may originate from a corresponding setting in the underlying operating system.

Examples
--------

The client makes an initial request to the server:

```http
GET / HTTP/1.1
Host: example.com
```

The server responds, telling the client via `Accept-CH` that it accepts `Sec-CH-Prefers-Color-Scheme`. In this example `Critical-CH` is also used, indicating that `Sec-CH-Prefers-Color-Scheme` is considered a critical client hint.

```http
HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Sec-CH-Prefers-Color-Scheme
Vary: Sec-CH-Prefers-Color-Scheme
Critical-CH: Sec-CH-Prefers-Color-Scheme
```

**Note:** We've also specified `Sec-CH-Prefers-Color-Scheme` in the `Vary` header to indicate that responses should be separately cached based on the value of this header (even if the URL stays the same).
 Each header listed in the `Critical-CH` header should also be present in the `Accept-CH` and `Vary` headers.

The client automatically retries the request (due to `Critical-CH` being specified above), telling the server via `Sec-CH-Prefers-Color-Scheme` that it has a user preference for dark content:

```http
GET / HTTP/1.1
Host: example.com
Sec-CH-Prefers-Color-Scheme: "dark"
```

The client will include the header in subsequent requests in the current session, unless the `Accept-CH` changes in responses to indicate that it is no longer supported by the server.

Specifications
--------------

| Specification |
| --- |
| User Preference Media Features Client Hints Headers # sec-ch-prefers-color-scheme |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Client hints
* `prefers-color-scheme` CSS Media Query
* User-Agent Client Hints API
* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* `Accept-CH`
* HTTP Caching > Varying responses and `Vary`


Cross-Origin-Opener-Policy - HTTP

Cross-Origin-Opener-Policy
==========================

The HTTP **`Cross-Origin-Opener-Policy`** (COOP) response header allows you to ensure a top-level document does not share a browsing context group with cross-origin documents.

COOP will process-isolate your document and potential attackers can't access your global object if they were to open it in a popup, preventing a set of cross-origin attacks dubbed XS-Leaks.

If a cross-origin document with COOP is opened in a new window, the opening document will not have a reference to it, and the `window.opener` property of the new window will be `null`. This allows you to have more control over references to a window than `rel=noopener`, which only affects outgoing navigations.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

Syntax
------

```http
Cross-Origin-Opener-Policy: unsafe-none
Cross-Origin-Opener-Policy: same-origin-allow-popups
Cross-Origin-Opener-Policy: same-origin
```

### Directives

`unsafe-none`

This is the default value. Allows the document to be added to its opener's browsing context group unless the opener itself has a COOP of `same-origin` or `same-origin-allow-popups`.

`same-origin-allow-popups`

Retains references to newly opened windows or tabs that either don't set COOP or that opt out of isolation by setting a COOP of `unsafe-none`.

`same-origin`

Isolates the browsing context exclusively to same-origin documents. Cross-origin documents are not loaded in the same browsing context.

Examples
--------

### Certain features depend on cross-origin isolation

Certain features like `SharedArrayBuffer` objects or `Performance.now()` with unthrottled timers are only available if your document has a COOP header with the value `same-origin` set.

```http
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
```

See also the `Cross-Origin-Embedder-Policy` header which you'll need to set to `require-corp` or `credentialless` as well.

To check if cross-origin isolation has been successful, you can test against the `crossOriginIsolated` property available to window and worker contexts:

```js
const myWorker = new Worker("worker.js");

if (crossOriginIsolated) {
  const buffer = new SharedArrayBuffer(16);
  myWorker.postMessage(buffer);
} else {
  const buffer = new ArrayBuffer(16);
  myWorker.postMessage(buffer);
}
```

Specifications
--------------

| Specification |
| --- |
| HTML Standard # the-coop-headers |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Cross-Origin-Embedder-Policy`


If-Match - HTTP

If-Match
========

The **`If-Match`** HTTP request header makes a request conditional.

 A server will only return requested resources for `GET` and `HEAD` methods, or upload resource for `PUT` and other non-safe methods, if the resource matches one of the listed `ETag` values.
 If the conditional does not match then the `412` (Precondition Failed) response is returned.

 The comparison with the stored `ETag` uses the *strong comparison algorithm*, meaning two files are considered identical byte by byte only.
 If a listed `ETag` has the `W/` prefix indicating a weak entity tag, this comparison algorithm will never match it.

There are two common use cases:

* For `GET` and `HEAD` methods, used in combination with a `Range` header, it can guarantee that the new ranges requested
 come from the same resource as the previous one.
* For other methods, and in particular for `PUT`, `If-Match` can be used to prevent the lost update problem.
 It can check if the modification of a resource that the user wants to upload will not override another change that has been done since the original resource was fetched.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

Syntax
------

```http
If-Match: <etag\_value>
If-Match: <etag\_value>, <etag\_value>, …
```

Directives
----------

`<etag_value>`

 Entity tags uniquely representing the requested resources.
 They are a string of ASCII characters placed between double quotes (like `"675af34563dc-tr34"`).
 They may be prefixed by `W/` to indicate that they are "weak", i.e. that they represent the resource semantically but not byte-by-byte.
 However, in an **`If-Match`** header, weak entity tags will never match.

`*`

 The asterisk is a special value representing any resource.
 Note that this must match as `false` if the origin server does not have a current representation for the target resource.

Examples
--------

```http
If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

If-Match: "67ab43", "54ed21", "7892dd"

If-Match: \*
```

Specifications
--------------

| Specification |
| --- |
| HTTP Semantics # field.if-match |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `ETag`
* `If-Unmodified-Since`
* `If-Modified-Since`
* `If-None-Match`
* `412 Precondition Failed`
* `416 Range Not Satisfiable`