Accept - HTTP

Accept
======

The **`Accept`** request HTTP header indicates which content types, expressed as MIME types, the client is able to understand. The server uses content negotiation to select one of the proposals and informs the client of the choice with the `Content-Type` response header. Browsers set required values for this header based on the context of the request. For example, a browser uses different values in a request when fetching a CSS stylesheet, image, video, or a script.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |
| CORS-safelisted request header |
 yes, with the additional restriction that values can't contain a
 *CORS-unsafe request header byte*: 0x00-0x1F (except 0x09 (HT)),
 `"():<>?@[\]{}`, and 0x7F (DEL).
  |

Syntax
------

```http
Accept: <MIME\_type>/<MIME\_subtype>
Accept: <MIME\_type>/\*
Accept: \*/\*

// Multiple types, weighted with the quality value syntax:
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, \*/\*;q=0.8
```

Directives
----------

`<MIME_type>/<MIME_subtype>`

A single, precise MIME type, like `text/html`.

`<MIME_type>/*`

A MIME type, but without a subtype. `image/*` corresponds to `image/png`, `image/svg`, `image/gif`, and other image types.

`*/*`

Any MIME type

`;q=` (q-factor weighting)

A value used is placed in an order of preference expressed using a relative quality value called the *weight*.

Examples
--------

```http
Accept: text/html

Accept: image/\*

// General default
Accept: \*/\*

// Default for navigation requests
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, \*/\*;q=0.8
```

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

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

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

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

See also
--------

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


Location - HTTP

Location
========

 The **`Location`** response header indicates the URL to
 redirect a page to. It only provides a meaning when served with a
 `3xx` (redirection) or `201` (created) status response.

 In cases of redirection, the HTTP method used to make the new request to fetch the page
 pointed to by `Location` depends on the original method and the kind of
 redirection:

* `303` (See Other) responses always lead to the use of a
 `GET` method.
* `307` (Temporary Redirect) and
 `308` (Permanent Redirect) don't change the method used in the
 original request.
* `301` (Moved Permanently) and `302` (Found) don't
 change the method most of the time, though older user-agents may (so you basically
 don't know).

All responses with one of these status codes send a `Location` header.

In cases of resource creation, it indicates the URL to the newly created resource.

`Location` and `Content-Location` are different.
 `Location` indicates the target of a redirection or the URL of a newly
 created resource. `Content-Location` indicates the direct URL to
 use to access the resource when content negotiation happened,
 without the need of further content negotiation. `Location` is a header
 associated with the response, while `Content-Location` is associated
 with the entity returned.

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

Syntax
------

```http
Location: <url>
```

Directives
----------

<url>

A relative (to the request URL) or absolute URL.

Examples
--------

```http
Location: /index.html
```

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

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

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

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

See also
--------

* `Content-Location`
* Status of responses including a `Location` header: `201`,
 `301`, `302`, `303`,
 `307`, `308`.


Sec-Fetch-Site - HTTP

Sec-Fetch-Site
==============

The **`Sec-Fetch-Site`** fetch metadata request header indicates the relationship between a request initiator's origin and the origin of the requested resource.

In other words, this header tells a server whether a request for a resource is coming from the same origin, the same site, a different site, or is a "user initiated" request. The server can then use this information to decide if the request should be allowed.

Same-origin requests would usually be allowed by default, but what happens for requests from other origins may further depend on what resource is being requested, or information in other Fetch metadata request headers. By default, requests that are not accepted should be rejected with a `403` response code.

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

Syntax
------

```http
Sec-Fetch-Site: cross-site
Sec-Fetch-Site: same-origin
Sec-Fetch-Site: same-site
Sec-Fetch-Site: none
```

Directives
----------

`cross-site`

The request initiator and the server hosting the resource have a different site (i.e. a request by "potentially-evil.com" for a resource at "example.com").

`same-origin`

The request initiator and the server hosting the resource have the same origin (same scheme, host and port).

`same-site`

The request initiator and the server hosting the resource have the same scheme, domain and/or subdomain, but not necessarily the same port.

`none`

This request is a user-originated operation. For example: entering a URL into the address bar, opening a bookmark, or dragging-and-dropping a file into the browser window.

Examples
--------

 A fetch request to `https://mysite.example/foo.json` originating from a web page on `https://mysite.example` (with the same port) is a same-origin request.
 The browser will generate the `Sec-Fetch-Site: same-origin` header as shown below, and the server will typically allow the request:

```http
GET /foo.json
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
```

A fetch request to the same URL from another site, for example `potentially-evil.com`, causes the browser to generate a different header (e.g. `Sec-Fetch-Site: cross-site`), which the server can choose to accept or reject:

```http
GET /foo.json
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
```

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

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

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

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

See also
--------

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


Content-DPR - HTTP

Content-DPR
===========

**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.

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

**Non-standard:** This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

The **`Content-DPR`** response header is used to confirm the *image* device to pixel ratio in requests where the screen `DPR` client hint was used to select an image resource.

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

If the `DPR` client hint is used to select an image the server must specify `Content-DPR` in the response. If the value in `Content-DPR` is different from the `DPR` value in the request (i.e. image DPR is not the same as screen DPR) then the client must use the `Content-DPR` for determining intrinsic image size and scaling the image.

If the `Content-DPR` header appears more than once in a message the last occurrence is used.

**Note:**

* `Content-DPR` was removed from the client hints specification in draft-ietf-httpbis-client-hints-07. The Responsive Image Client Hints spec proposes to replace this header by specifying intrinsic resolution/dimensions in EXIF metadata.

Syntax
------

```http
Content-DPR: <number>
```

Directives
----------

`<number>`

 The image device pixel ratio, calculated according to the following formula:
 Content-DPR = *Selected image resource size* / (*Width* / *DPR*)

Examples
--------

See the `DPR` header example.

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

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

See also
--------

* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* Device client hints
    + `Device-Memory`
    + `DPR`
    + `Viewport-Width`
    + `Width`
* `Accept-CH`
* HTTP Caching > Vary and `Vary`


Want-Digest - HTTP

Want-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 **`Want-Digest`** HTTP header is primarily used in a request, to ask the server to provide a digest of the requested resource using the `Digest` response header.

 The header contains identifiers for one or more digest algorithms that the sender wishes the server to use to create the digest.
 The request may use quality values to indicate its preference/order for particular digest algorithms.

If `Want-Digest` does not include any digest algorithms that the server supports, the server may respond with:

* a digest calculated using a different digest algorithm, or
* a `400 Bad Request` error, and include another `Want-Digest` header with that response, listing the algorithms that it does support.

See the page for the `Digest` header for more information.

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

Syntax
------

```http
Want-Digest: <digest-algorithm>

// Multiple algorithms, weighted with the quality value syntax:
Want-Digest: <digest-algorithm><q-value>,<digest-algorithm><q-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`.

<q-value>

 The quality value to apply to that
 option.

Examples
--------

```http
Want-Digest: sha-256
Want-Digest: SHA-512;q=0.3, sha-256;q=1, md5;q=0
```

### Basic operation

 The sender provides a list of digests which it is prepared to accept, and the server
 uses one of them:

Request:

```http
GET /item
Want-Digest: sha-256;q=0.3, sha;q=1
```

Response:

```http
HTTP/1.1 200 Ok
Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
```

### Unsupported digests

The server does not support any of the requested digest algorithms, so uses a different algorithm:

Request:

```http
GET /item
Want-Digest: sha;q=1
```

Response:

```http
HTTP/1.1 200 Ok
Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
```

 The server does not support any of the requested digest algorithms.
 In this case it responds with a 400 error and includes another `Want-Digest` header, listing the algorithms that it does support:

Request:

```http
GET /item
Want-Digest: sha;q=1
```

Response:

```http
HTTP/1.1 400 Bad Request
Want-Digest: sha-256, sha-512
```

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

| Specification |
| --- |
| Digest Fields # section-4 |

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

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

See also
--------

* `Digest`


Proxy-Authenticate - HTTP

Proxy-Authenticate
==================

 The HTTP **`Proxy-Authenticate`** response header defines the
 authentication method that should be used to gain access to a resource behind a
 proxy server. It authenticates the request to the proxy server, allowing
 it to transmit the request further.

 The `Proxy-Authenticate` header is sent along with a `407`
`Proxy Authentication Required`.

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

Syntax
------

```http
Proxy-Authenticate: <type> realm=<realm>
```

Directives
----------

<type>

Authentication type. A common type is "Basic".
 IANA maintains a list of authentication schemes.

realm=<realm>

 A description of the protected area, the realm. If no realm is specified, clients
 often display a formatted host name instead.

Examples
--------

```http
Proxy-Authenticate: Basic

Proxy-Authenticate: Basic realm="Access to the internal site"
```

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

| Specification |
| --- |
| HTTP Semantics # field.proxy-authenticate |

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

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

See also
--------

* HTTP authentication
* `Authorization`
* `Proxy-Authorization`
* `WWW-Authenticate`
* `401`, `403`, `407`


Server - HTTP

Server
======

 The **`Server`** header describes the
 software used by the origin server that handled the request — that is, the server that
 generated the response.

**Warning:** Avoid overly-detailed `Server` values, as they can reveal information that
 may make it (slightly) easier for attackers to exploit known security holes.

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

Syntax
------

```http
Server: <product>
```

Directives
----------

<product>

 A name of the software or the product that handled the request. Usually in a format
 similar to `User-Agent`.

 How much detail to include is an interesting balance to strike; exposing the OS version
 is probably a bad idea, as mentioned in the earlier warning about overly-detailed
 values. However, exposed Apache versions helped browsers to work around a bug of the
 versions with `Content-Encoding` and
 `Range` in combination.

Examples
--------

```http
Server: Apache/2.4.1 (Unix)
```

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

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

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

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

See also
--------

* `Allow`


X-DNS-Prefetch-Control - HTTP

X-DNS-Prefetch-Control
======================

**Non-standard:** This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

 The **`X-DNS-Prefetch-Control`** HTTP response header controls
 DNS prefetching, a feature by which browsers proactively perform domain name resolution
 on both links that the user may choose to follow as well as URLs for items referenced by
 the document, including images, CSS, JavaScript, and so forth.

 This prefetching is performed in the background, so that the DNS is
 likely to have been resolved by the time the referenced items are needed. This reduces
 latency when the user clicks a link.

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

Syntax
------

```http
X-DNS-Prefetch-Control: on
X-DNS-Prefetch-Control: off
```

### Directives

on

 Enables DNS prefetching. This is what browsers do, if they support the feature, when
 this header is not present

off

 Disables DNS prefetching. This is useful if you don't control the link on the pages,
 or know that you don't want to leak information to these domains.

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

 DNS requests are very small in terms of bandwidth, but latency can be quite high,
 especially on mobile networks. By speculatively prefetching DNS results, latency can be
 reduced significantly at certain times, such as when the user clicks the link. In some
 cases, latency can be reduced by a second.

 The implementation of this prefetching in some browsers allows domain name resolution
 to occur in parallel with (instead of in serial with) the fetching of actual page
 content. By doing this, the high-latency domain name resolution process doesn't cause
 any delay while fetching content.

 Page load times – especially on mobile networks – can be measurably improved in this
 way. If the domain names for images can be resolved in advance of the images being
 requested, pages that load many images can see an improvement of 5% or more in the time
 of loading images.

### Configuring prefetching in the browser

 In general, you don't need to do anything to manage prefetching. However, the user may
 wish to disable prefetching. On Firefox, this can be done by setting the
 `network.dns.disablePrefetch` preference to `true`.

 Also, by default, prefetching of embedded link hostnames is not performed on documents
 loaded over HTTPS. On Firefox, this can be changed by setting the
 `network.dns.disablePrefetchFromHTTPS` preference to `false`.

Examples
--------

### Turning on and off prefetching

 You can either send the `X-DNS-Prefetch-Control` header server-side, or from
 individual documents, using the `http-equiv` attribute on
 the `<meta>` element, like this:

```html
<meta http-equiv="x-dns-prefetch-control" content="off" />
```

You can reverse this setting by setting `content` to "`on`".

### Forcing lookup of specific hostnames

 You can force the lookup of specific hostnames without providing specific anchors using
 that hostname by using the `rel` attribute on the `<link>` element with a link type of `dns-prefetch`:

```html
<link rel="dns-prefetch" href="https://www.mozilla.org" />
```

In this example, the domain name `www.mozilla.org` will be pre-resolved.

 Similarly, the link element can be used to resolve hostnames without providing a
 complete URL, but only, by preceding the hostname with two slashes:

```html
<link rel="dns-prefetch" href="//www.mozilla.org" />
```

 Forced prefetching of hostnames might be useful, for example, on the homepage of a site
 to force pre-resolution of domain names that are referenced frequently throughout the
 site even though they are not used on the home page itself. This will improve the
 overall performance of site even though the performance of the home page may not be
 affected.

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

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

See also
--------

* DNS Prefetching for Firefox (blog post)
* Google Chrome handles DNS prefetching control


Width - HTTP

Width
=====

**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.

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

**Non-standard:** This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

The **`Width`** device client hint request header field indicates the desired resource width in physical pixels — the intrinsic size of an image. The provided pixel value is a number rounded to the smallest following integer (i.e. ceiling value).

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

The hint is particularly useful because it allows the client to request a resource that is optimal for both the screen and the layout: taking into account both the density-corrected width of the screen and the image's extrinsic size within the layout.

If the desired resource width is not known at the time of the request or the resource does not have a display width, the `Width` header field can be omitted.

If the `Width` header appears more than once in a message the last occurrence is used.

**Note:**

* Client Hints are accessible only on secure origins (via TLS).
* A server has to opt in to receive the `Width` header from the client, by sending the `Accept-CH` response header.
* Servers that opt in to the `Width` client hint will typically also specify it in the `Vary` header. This informs caches that the server may send different responses based on the header value in a request.
* `Width` was removed from the client hints specification in draft-ietf-httpbis-client-hints-07. The proposed replacement is `Sec-CH-Width` (Responsive Image Client Hints).

Syntax
------

```http
Width: <number>
```

Directives
----------

<number>

The width of the resource in physical pixels, rounded up to the nearest integer.

Examples
--------

The server first needs to opt in to receive the `Width` header by sending the response headers `Accept-CH` containing `Width`.

```http
Accept-CH: Width
```

Then on subsequent requests the client might send `Width` header back:

```http
Width: 1920
```

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

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

See also
--------

* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* Device client hints
    + `Content-DPR`
    + `Device-Memory`
    + `DPR`
    + `Viewport-Width`
* `Accept-CH`
* HTTP Caching > Vary and `Vary`


ECT - HTTP

ECT
===

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

The **`ECT`** Client hint request header field indicates the effective connection type: `slow-2g`, `2g`, `3g`, `4g`.

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

The value represents the "network profile" that best matches the connection's latency and bandwidth, rather than the actual mechanisms used for transferring the data. For example, `2g` might be used to represent a slow Wi-Fi connection with high latency and low bandwidth, while `4g` might be used to represent a fast fibre-based broadband network.

The hint allows a server to choose what information is sent based on the broad characteristics of the network. For example, a server might choose to send smaller versions of images and other resources on less capable connections. The value might also be used as a starting point for determining what information is sent, which is further refined using information in `RTT` and `Downlink` hints.

**Note:** A server that specifies `ECT` in `Accept-CH` may also specify it in `Vary` to indicate that responses should be cached for different ECT values.

Syntax
------

```http
ECT: <value>
```

Directives
----------

<value>

A value indicating effective connection type. This is one of: `slow-2g`, `2g`, `3g`, or `4g`.

Examples
--------

A server first needs to opt in to receive the `ECT` header by sending the `Accept-CH` response header containing `ECT`.

```http
Accept-CH: ECT
```

Then on subsequent requests the client might send an `ECT` header back:

```http
ECT: 2g
```

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

| Specification |
| --- |
| Network Information API # ect-request-header-field |

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

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

See also
--------

* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* Network client hints
    + `Downlink`
    + `RTT`
    + `Save-Data`
* `Accept-CH`
* HTTP Caching > Vary and `Vary`
* `NetworkInformation.effectiveType`


Proxy-Authorization - HTTP

Proxy-Authorization
===================

 The HTTP **`Proxy-Authorization`** request header contains the
 credentials to authenticate a user agent to a proxy server, usually after the server has
 responded with a `407` `Proxy Authentication Required` status
 and the `Proxy-Authenticate` header.

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

Syntax
------

```http
Proxy-Authorization: <type> <credentials>
```

Directives
----------

<type>

Authentication type. A common type is "Basic".
 See also the IANA registry of Authentication schemes.

<credentials>

The credentials are constructed like this:

* The username and the password are combined with a colon
 (`aladdin:opensesame`).
* The resulting string is base64
 encoded (`YWxhZGRpbjpvcGVuc2VzYW1l`).

**Note:** Base64 encoding does not mean encryption or hashing! This
 method is as secure as sending the credentials in clear text (base64 is a
 reversible encoding). It is preferable to use HTTPS in conjunction with Basic
 Authentication.

Examples
--------

```http
Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

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

| Specification |
| --- |
| HTTP Semantics # field.proxy-authorization |

See also
--------

* HTTP authentication
* `Proxy-Authenticate`
* `WWW-Authenticate`
* `Authorization`
* `401`, `403`, `407`


Viewport-Width - HTTP

Viewport-Width
==============

**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.

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

**Non-standard:** This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

The **`Viewport-Width`** device client hint request header provides the client's layout viewport width in CSS pixels. The value is rounded up to the smallest following integer (i.e. ceiling value).

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

The hint can be used with other screen-specific hints to deliver images optimized for a specific screen size, or to omit resources that are not needed for a particular screen width.

If the `Viewport-Width` header appears more than once in a message the last occurrence is used.

**Note:**

* Client Hints are accessible only on secure origins (via TLS).
* A server has to opt in to receive the `Viewport-Width` header from the client, by sending the `Accept-CH` response header.
* Servers that opt in to the `Viewport-Width` client hint will typically also specify it in the `Vary` header. This informs caches that the server may send different responses based on the header value in a request.
* `Viewport-Width` was removed from the original client hints specification in draft-ietf-httpbis-client-hints-07. The proposed replacement is `Sec-CH-Viewport-Width` (Responsive Image Client Hints).

Syntax
------

```http
Viewport-Width: <number>
```

Directives
----------

<number>

The width of the user's viewport in CSS pixels, rounded up to the nearest integer.

Examples
--------

A server must first opt in to receive the `Viewport-Width` header by sending the response header `Accept-CH` containing the directive `Viewport-Width`.

```http
Accept-CH: Viewport-Width
```

Then on subsequent requests the client might send `Viewport-Width` header back:

```http
Viewport-Width: 320
```

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

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

See also
--------

* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* Device client hints
    + `Content-DPR`
    + `Device-Memory`
    + `DPR`
    + `Width`
* `Accept-CH`
* HTTP Caching > Vary and `Vary`


Sec-CH-UA-Platform - HTTP

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

**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-Platform`** user agent client hint request header provides the platform or operating system on which the user agent is running.
 For example: "Windows" or "Android".

`Sec-CH-UA-Platform` 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-Platform: <platform>
```

### Directives

`<platform>`

One of the following strings: `"Android"`, `"Chrome OS"`, `"Chromium OS"`, `"iOS"`, `"Linux"`, `"macOS"`, `"Windows"`, or `"Unknown"`.

Examples
--------

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

A browser running on a macOS computer might add the following header to all requests.

```http
Sec-CH-UA-Platform: "macOS"
```

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

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

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`


Accept-Encoding - HTTP

Accept-Encoding
===============

The **`Accept-Encoding`** request HTTP header indicates the content encoding (usually a compression algorithm) that the client can understand. The server uses content negotiation to select one of the proposals and informs the client of that choice with the `Content-Encoding` response header.

Even if both the client and the server support the same compression algorithms, the server may choose not to compress the body of a response if the `identity` value is also acceptable. Two common cases lead to this:

* The data to be sent is already compressed, therefore a second compression will not reduce the transmitted data size. This is true for pre-compressed image formats (JPEG, for instance);
* The server is overloaded and cannot allocate computing resources to perform the compression. For example, Microsoft recommends not to compress if a server uses more than 80% of its computational power.

As long as the `identity;q=0` or `*;q=0` directives do not explicitly forbid the `identity` value that means no encoding, the server must never return a `406` `Not Acceptable` error.

**Note:**

* An IANA registry maintains a complete list of official content encodings.
* Two other content encodings, namely `bzip` and `bzip2`, are sometimes used, These non-standard encodings implement the algorithm that these two UNIX programs use. Note that `bzip` was discontinued due to patent licensing issues.

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

Syntax
------

```http
Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: \*

// Multiple algorithms, weighted with the quality value syntax:
Accept-Encoding: deflate, gzip;q=1.0, \*;q=0.5
```

Directives
----------

`gzip`

A compression format that uses the Lempel-Ziv coding (LZ77) with a 32-bit CRC.

`compress`

A compression format that uses the Lempel-Ziv-Welch (LZW) algorithm.

`deflate`

A compression format that uses the zlib structure with the *deflate* compression algorithm.

`br`

A compression format that uses the Brotli algorithm.

`identity`

Indicates the identity function (that is, without modification or compression). This value is always considered as acceptable, even if omitted.

`*`

Matches any content encoding not already listed in the header. This is the default value if the header is not present. This directive does not suggest that any algorithm is supported but indicates that no preference is expressed.

`;q=` (qvalues weighting)

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

Examples
--------

```http
Accept-Encoding: gzip

Accept-Encoding: gzip, compress, br

Accept-Encoding: br;q=1.0, gzip;q=0.8, \*;q=0.1
```

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

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

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-Encoding`
* Other similar headers: `TE`, `Accept`, `Accept-Language`


Access-Control-Allow-Headers - HTTP

Access-Control-Allow-Headers
============================

The **`Access-Control-Allow-Headers`** response header is used in response to a preflight request which includes the `Access-Control-Request-Headers` to indicate which HTTP headers can be used during the actual request.

This header is required if the request has an `Access-Control-Request-Headers` header.

**Note:** CORS-safelisted request headers are always allowed and usually aren't listed in `Access-Control-Allow-Headers` (unless there is a need to circumvent the safelist additional restrictions).

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

Syntax
------

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

Directives
----------

`<header-name>`

The name of a supported request header. The header may list any number of headers, separated by commas.

`*` (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 "`*`" without special semantics. Note that the `Authorization` header can't be wildcarded and always needs to be listed explicitly.

Examples
--------

### A custom header

Here's an example of what an `Access-Control-Allow-Headers` header might look like. It indicates that a custom header named `X-Custom-Header` is supported by CORS requests to the server (in addition to the CORS-safelisted request headers).

```http
Access-Control-Allow-Headers: X-Custom-Header
```

### Multiple headers

This example shows `Access-Control-Allow-Headers` when it specifies support for multiple headers.

```http
Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests
```

### Bypassing additional restrictions

Although CORS-safelisted request headers are always allowed and don't usually need to be listed in `Access-Control-Allow-Headers`, listing them anyway will circumvent the additional restrictions that apply.

```http
Access-Control-Allow-Headers: Accept
```

### Example preflight request

Let's look at an example of a preflight request involving `Access-Control-Allow-Headers`.

#### Request

First, the request. The preflight request is an `OPTIONS` request that includes some combination of the three preflight request headers: `Access-Control-Request-Method`, `Access-Control-Request-Headers`, and `Origin`.

The preflight request below tells the server that we want to send a CORS `GET` request with the headers listed in `Access-Control-Request-Headers` (`Content-Type` and `x-requested-with`).

```http
OPTIONS /resource/foo
Access-Control-Request-Method: GET
Access-Control-Request-Headers: Content-Type, x-requested-with
Origin: https://foo.bar.org
```

#### Response

If the CORS request indicated by the preflight request is authorized, the server will respond to the preflight request with a message that indicates the allowed origin, methods, and headers. Below we see that `Access-Control-Allow-Headers` includes the headers that were requested.

```http
HTTP/1.1 200 OK
Content-Length: 0
Connection: keep-alive
Access-Control-Allow-Origin: https://foo.bar.org
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Allow-Headers: Content-Type, x-requested-with
Access-Control-Max-Age: 86400
```

If the requested method isn't supported, the server will respond with an error.

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

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

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

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

See also
--------

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers`
* `Access-Control-Allow-Methods`
* `Access-Control-Request-Headers`


Early-Data - HTTP

Early-Data
==========

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

 The **`Early-Data`** header is set by
 an intermediary to indicate that the request has been conveyed in TLS early data,
 and also indicates that the intermediary understands the `425 (Too Early)` status code.

 The `Early-Data` header is **not** set by the originator of the
 request (i.e., a browser).

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

Syntax
------

```http
Early-Data: 1
```

Examples
--------

```http
GET /resource HTTP/1.0
Host: example.com
Early-Data: 1
```

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

| Specification |
| --- |
| Using Early Data in HTTP # header |

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

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


Cache-Control - HTTP

Cache-Control
=============

The **`Cache-Control`** HTTP header field holds *directives* (instructions) — in both requests and responses — that control caching in browsers and shared caches (e.g. Proxies, CDNs).

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

Syntax
------

Cache directives follow these rules:

* Caching directives are case-insensitive. However, lowercase is recommended because some implementations do not recognize uppercase directives.
* Multiple directives are permitted and must be comma-separated (e.g., `Cache-control: max-age=180, public`).
* Some directives have an optional argument. When an argument is provided, it is separated from the directive name by an equals symbol (`=`). Typically, arguments for the directives are integers and are therefore not enclosed in quote characters (e.g., `Cache-control: max-age=12`).
### Cache directives

The following table lists the standard `Cache-Control` directives:

| Request | Response |
| --- | --- |
| `max-age` | `max-age` |
| `max-stale` | - |
| `min-fresh` | - |
| - | `s-maxage` |
| `no-cache` | `no-cache` |
| `no-store` | `no-store` |
| `no-transform` | `no-transform` |
| `only-if-cached` | - |
| - | `must-revalidate` |
| - | `proxy-revalidate` |
| - | `must-understand` |
| - | `private` |
| - | `public` |
| - | `immutable` |
| - | `stale-while-revalidate` |
| `stale-if-error` | `stale-if-error` |

Note: Check the compatibility table for their support; user agents that don't recognize them should ignore them.

Vocabulary
----------

This section defines the terms used in this document, some of which are from the specification.

`(HTTP) cache`

Implementation that holds requests and responses for reusing in subsequent requests. It can be either a shared cache or a private cache.

`Shared cache`

Cache that exists between the origin server and clients (e.g. Proxy, CDN). It stores a single response and reuses it with multiple users — so developers should avoid storing personalized contents to be cached in the shared cache.

`Private cache`

Cache that exists in the client. It is also called *local cache* or *browser cache*. It can store and reuse personalized content for a single user.

`Store response`

Store a response in caches when the response is cacheable. However, the cached response is not always reused as-is. (Usually, "cache" means storing a response.)

`Reuse response`

Reuse cached responses for subsequent requests.

`Revalidate response`

Ask the origin server whether or not the stored response is still fresh. Usually, the revalidation is done through a conditional request.

`Fresh response`

Indicates that the response is fresh. This usually means the response can be reused for subsequent requests, depending on request directives.

`Stale response`

Indicates that the response is a stale response. This usually means the response can't be reused as-is. Cache storage isn't required to remove stale responses immediately because revalidation could change the response from being stale to being fresh again.

`Age`

The time since a response was generated. It is a criterion for whether a response is fresh or stale.

Directives
----------

This section lists directives that affect caching — both response directives and request directives.

### Response Directives

#### `max-age`

The `max-age=N` response directive indicates that the response remains fresh until *N* seconds after the response is generated.

```http
Cache-Control: max-age=604800
```

Indicates that caches can store this response and reuse it for subsequent requests while it's fresh.

 Note that `max-age` is not the elapsed time since the response was received; it is the elapsed time since the response was generated on the origin server.
 So if the other cache(s) — on the network route taken by the response — store the response for 100 seconds (indicated using the `Age` response header field), the browser cache would deduct 100 seconds from its freshness lifetime.

```http
Cache-Control: max-age=604800
Age: 100
```

#### `s-maxage`

 The `s-maxage` response directive indicates how long the response remains fresh in a shared cache.
 The `s-maxage` directive is ignored by private caches, and overrides the value specified by the `max-age` directive or the `Expires` header for shared caches, if they are present.

```http
Cache-Control: s-maxage=604800
```

#### `no-cache`

The `no-cache` response directive indicates that the response can be stored in caches, but the response must be validated with the origin server before each reuse, even when the cache is disconnected from the origin server.

```http
Cache-Control: no-cache
```

If you want caches to always check for content updates while reusing stored content, `no-cache` is the directive to use. It does this by requiring caches to revalidate each request with the origin server.

Note that `no-cache` does not mean "don't cache". `no-cache` allows caches to store a response but requires them to revalidate it before reuse. If the sense of "don't cache" that you want is actually "don't store", then `no-store` is the directive to use.

#### `must-revalidate`

The `must-revalidate` response directive indicates that the response can be stored in caches and can be reused while fresh. If the response becomes stale, it must be validated with the origin server before reuse.

Typically, `must-revalidate` is used with `max-age`.

```http
Cache-Control: max-age=604800, must-revalidate
```

HTTP allows caches to reuse stale responses when they are disconnected from the origin server. `must-revalidate` is a way to prevent this from happening - either the stored response is revalidated with the origin server or a 504 (Gateway Timeout) response is generated.

#### `proxy-revalidate`

The `proxy-revalidate` response directive is the equivalent of `must-revalidate`, but specifically for shared caches only.

#### `no-store`

The `no-store` response directive indicates that any caches of any kind (private or shared) should not store this response.

```http
Cache-Control: no-store
```

#### `private`

The `private` response directive indicates that the response can be stored only in a private cache (e.g. local caches in browsers).

```http
Cache-Control: private
```

You should add the `private` directive for user-personalized content, especially for responses received after login and for sessions managed via cookies.

If you forget to add `private` to a response with personalized content, then that response can be stored in a shared cache and end up being reused for multiple users, which can cause personal information to leak.

#### `public`

The `public` response directive indicates that the response can be stored in a shared cache. Responses for requests with `Authorization` header fields must not be stored in a shared cache; however, the `public` directive will cause such responses to be stored in a shared cache.

```http
Cache-Control: public
```

In general, when pages are under Basic Auth or Digest Auth, the browser sends requests with the `Authorization` header. This means that the response is access-controlled for restricted users (who have accounts), and it's fundamentally not shared-cacheable, even if it has `max-age`.

You can use the `public` directive to unlock that restriction.

```http
Cache-Control: public, max-age=604800
```

Note that `s-maxage` or `must-revalidate` also unlock that restriction.

If a request doesn't have an `Authorization` header, or you are already using `s-maxage` or `must-revalidate` in the response, then you don't need to use `public`.

#### `must-understand`

The `must-understand` response directive indicates that a cache should store the response only if it understands the requirements for caching based on status code.

`must-understand` should be coupled with `no-store` for fallback behavior.

```http
Cache-Control: must-understand, no-store
```

If a cache doesn't support `must-understand`, it will be ignored. If `no-store` is also present, the response isn't stored.

If a cache supports `must-understand`, it stores the response with an understanding of cache requirements based on its status code.

#### `no-transform`

Some intermediaries transform content for various reasons. For example, some convert images to reduce transfer size. In some cases, this is undesirable for the content provider.

`no-transform` indicates that any intermediary (regardless of whether it implements a cache) shouldn't transform the response contents.

#### `immutable`

The `immutable` response directive indicates that the response will not be updated while it's fresh.

```http
Cache-Control: public, max-age=604800, immutable
```

A modern best practice for static resources is to include version/hashes in their URLs, while never modifying the resources — but instead, when necessary, *updating* the resources with newer versions that have new version-numbers/hashes, so that their URLs are different. That's called the **cache-busting** pattern.

```html
<script src=https://example.com/react.0.0.0.js></script>
```

 When a user reloads the browser, the browser will send conditional requests for validating to the origin server. But it's not necessary to revalidate those kinds of static resources even when a user reloads the browser, because they're never modified.
 `immutable` tells a cache that the response is immutable while it's fresh and avoids those kinds of unnecessary conditional requests to the server.

When you use a cache-busting pattern for resources and apply them to a long `max-age`, you can also add `immutable` to avoid revalidation.

#### `stale-while-revalidate`

The `stale-while-revalidate` response directive indicates that the cache could reuse a stale response while it revalidates it to a cache.

```http
Cache-Control: max-age=604800, stale-while-revalidate=86400
```

 In the example above, the response is fresh for 7 days (604800s).
 After 7 days it becomes stale, but the cache is allowed to reuse it for any requests that are made in the following day (86400s), provided that they revalidate the response in the background.

Revalidation will make the cache be fresh again, so it appears to clients that it was always fresh during that period — effectively hiding the latency penalty of revalidation from them.

If no request happened during that period, the cache became stale and the next request will revalidate normally.

#### `stale-if-error`

The `stale-if-error` response directive indicates that the cache can reuse a stale response when an upstream server generates an error, or when the error is generated locally. Here, an error is considered any response with a status code of 500, 502, 503, or 504.

```http
Cache-Control: max-age=604800, stale-if-error=86400
```

In the example above, the response is fresh for 7 days (604800s). Afterwards, it becomes stale, but can be used for an extra 1 day (86400s) when an error is encountered.

After the stale-if-error period passes, the client will receive any error generated.

### Request Directives

#### `no-cache`

The `no-cache` request directive asks caches to validate the response with the origin server before reuse.

```http
Cache-Control: no-cache
```

`no-cache` allows clients to request the most up-to-date response even if the cache has a fresh response.

Browsers usually add `no-cache` to requests when users are **force reloading** a page.

#### `no-store`

The `no-store` request directive allows a client to request that caches refrain from storing the request and corresponding response — even if the origin server's response could be stored.

```http
Cache-Control: no-store
```

#### `max-age`

The `max-age=N` request directive indicates that the client allows a stored response that is generated on the origin server within *N* seconds — where *N* may be any non-negative integer (including `0`).

```http
Cache-Control: max-age=10800
```

In the case above, if the response with `Cache-Control: max-age=10800` was generated more than 3 hours ago (calculated from `max-age` and the `Age` header), the cache couldn't reuse that response.

Many browsers use this directive for **reloading**, as explained below.

```http
Cache-Control: max-age=0
```

`max-age=0` is a workaround for `no-cache`, because many old (HTTP/1.0) cache implementations don't support `no-cache`. Recently browsers are still using `max-age=0` in "reloading" — for backward compatibility — and alternatively using `no-cache` to cause a "force reloading".

If the `max-age` value isn't non-negative (for example, `-1`) or isn't an integer (for example, `3599.99`), then the caching behavior is undefined. However, the Calculating Freshness Lifetime section of the HTTP specification states:

>
> Caches are encouraged to consider responses that have invalid freshness information to be stale.
>
>
>

In other words, for any `max-age` value that isn't an integer or isn't non-negative, the caching behavior that's encouraged is to treat the value as if it were `0`.

#### `max-stale`

The `max-stale=N` request directive indicates that the client allows a stored response that is stale within *N* seconds.

```http
Cache-Control: max-stale=3600
```

In the case above, if the response with `Cache-Control: max-age=604800` was generated more than 3 hours ago (calculated from `max-age` and the `Age` header), the cache couldn't reuse that response.

Clients can use this header when the origin server is down or too slow and can accept cached responses from caches even if they are a bit old.

Note that the major browsers do not support requests with `max-stale`.

#### `min-fresh`

The `min-fresh=N` request directive indicates that the client allows a stored response that is fresh for at least *N* seconds.

```http
Cache-Control: min-fresh=600
```

In the case above, if the response with `Cache-Control: max-age=3600` was stored in caches 51 minutes ago, the cache couldn't reuse that response.

Clients can use this header when the user requires the response to not only be fresh, but also requires that it won't be updated for a period of time.

Note that the major browsers do not support requests with `min-fresh`.

#### `no-transform`

Same meaning that `no-transform` has for a response, but for a request instead.

#### `only-if-cached`

The client indicates that an already-cached response should be returned. If a cache has a stored response, even a stale one, it will be returned. If no cached response is available, a 504 Gateway Timeout response will be returned.

Use Cases
---------

### Preventing storing

If you don't want a response stored in caches, use the `no-store` directive.

```http
Cache-Control: no-store
```

Note that `no-cache` means "it can be stored but don't reuse before validating" — so it's not for preventing a response from being stored.

```http
Cache-Control: no-cache
```

In theory, if directives are conflicted, the most restrictive directive should be honored. So the example below is basically meaningless because `private`, `no-cache`, `max-age=0` and `must-revalidate` conflict with `no-store`.

```http
# conflicted
Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate

# equivalent to
Cache-Control: no-store
```

### Caching static assets with "cache busting"

When you build static assets with versioning/hashing mechanisms, adding a version/hash to the filename or query string is a good way to manage caching.

For example:

```html
<!-- index.html -->
<script src="/assets/react.min.js"></script>
<img src="/assets/hero.png" width="900" height="400" />
```

The React library version will change when you update the library, and `hero.png` will also change when you edit the picture. So those are hard to store in a cache with `max-age`.

In such a case, you could address the caching needs by using a specific, numbered version of the library, and including the hash of the picture in its URL.

```html
<!-- index.html -->
<script src="/assets/react.0.0.0min.js"></script>
<img src="/assets/hero.png?hash=deadbeef" width="900" height="400" />
```

You can add a long `max-age` value and `immutable` because the content will never change.

```http
# /assets/*
Cache-Control: max-age=31536000, immutable
```

When you update the library or edit the picture, new content should have a new URL, and caches aren't reused. That is called the "cache busting" pattern.

Use a `no-cache` to make sure that the HTML response itself is not cached. `no-cache` could cause revalidation, and the client will correctly receive a new version of the HTML response and static assets.

```http
# /index.html
Cache-Control: no-cache
```

Note: If `index.html` is controlled under Basic Authentication or Digest Authentication, files under `/assets` are not stored in the shared cache. If `/assets/` files are suitable for storing in a shared cache, you also need one of `public`, `s-maxage` or `must-revalidate`.

### Up-to-date contents always

For content that's generated dynamically, or that's static but updated often, you want a user to always receive the most up-to-date version.

If you don't add a `Cache-Control` header because the response is not intended to be cached, that could cause an unexpected result. Cache storage is allowed to cache it heuristically — so if you have any requirements on caching, you should always indicate them explicitly, in the `Cache-Control` header.

Adding `no-cache` to the response causes revalidation to the server, so you can serve a fresh response every time — or if the client already has a new one, just respond `304 Not Modified`.

```http
Cache-Control: no-cache
```

Most HTTP/1.0 caches don't support `no-cache` directives, so historically `max-age=0` was used as a workaround. But only `max-age=0` could cause a stale response to be reused when caches disconnected from the origin server. `must-revalidate` addresses that. That's why the example below is equivalent to `no-cache`.

```http
Cache-Control: max-age=0, must-revalidate
```

But for now, you can simply use `no-cache` instead.

### Clearing an already-stored cache

Unfortunately, there are no cache directives for clearing already-stored responses from caches.

Imagine that clients/caches store a fresh response for a path, with no request flight to the server. There is nothing a server could do to that path.

Alternatively, `Clear-Site-Data` can clear a browser cache for a site. But be careful: that clears every stored response for a site — and only in browsers, not for a shared cache.

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

| Specification |
| --- |
| HTTP Caching # field.cache-control |
| HTTP Immutable Responses # the-immutable-cache-control-extension |

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

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

See also
--------

* HTTP caching
* Caching Tutorial for Web Authors and Webmasters
* Caching best practices & max-age gotchas
* Cache-Control for Civilians
* RFC 9111 – HTTP Caching
* RFC 5861 – HTTP Cache-Control Extensions for Stale Content
* RFC 8246 – HTTP Immutable Responses


Content-Security-Policy-Report-Only - HTTP

Content-Security-Policy-Report-Only
===================================

The HTTP **`Content-Security-Policy-Report-Only`** response header allows web developers to experiment with policies by monitoring (but not enforcing) their effects. These violation reports consist of JSON documents sent via an HTTP `POST` request to the specified URI.

For more information, see also this article on Content Security Policy (CSP).

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |
| This header is not supported inside a `<meta>` element. |

Syntax
------

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

Directives
----------

The directives of the `Content-Security-Policy` header can also be applied to `Content-Security-Policy-Report-Only`, except for the `sandbox` directive, which is ignored when used with `Content-Security-Policy-Report-Only`.

The CSP `report-to` directive should be used with this header, otherwise this header will be an expensive no-op machine.

Examples
--------

This header reports violations that would have occurred. You can use this to iteratively work on your content security policy. You observe how your site behaves, watching for violation reports, then choose the desired policy enforced by the `Content-Security-Policy` header.

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

If you still want to receive reporting, but also want to enforce a policy, use the `Content-Security-Policy` header with the `report-to` directive.

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

Violation report syntax
-----------------------

The report JSON object is sent with an `application/csp-report` `Content-Type` and contains the following data:

`blocked-uri`

The URI of the resource that was blocked from loading by the Content Security Policy. If the blocked URI is from a different origin than the document-uri, then the blocked URI is truncated to contain just the scheme, host, and port.

`disposition`

Either `"enforce"` or `"report"` depending on whether the `Content-Security-Policy` header or the `Content-Security-Policy-Report-Only` header is used.

`document-uri`

The URI of the document in which the violation occurred.

`effective-directive`

The directive whose enforcement caused the violation.

`original-policy`

The original policy as specified by the `Content-Security-Policy-Report-Only` HTTP header.

`referrer`

The referrer of the document in which the violation occurred.

`script-sample`

The first 40 characters of the inline script, event handler, or style that caused the violation.

`status-code`

The HTTP status code of the resource on which the global object was instantiated.

`violated-directive`
Deprecated

The directive whose enforcement caused the violation. The `violated-directive` is a historic name for the `effective-directive` field and contains the same value.

Sample violation report
-----------------------

Let's consider a page located at `http://example.com/signup.html`. It uses the following policy, disallowing everything but stylesheets from `cdn.example.com`.

```http
Content-Security-Policy-Report-Only: default-src 'none'; style-src cdn.example.com; report-to /\_/csp-reports
```

The HTML of `signup.html` looks like this:

```html
<!doctype html>
<html lang="en-US">
  <head>
    <meta charset="UTF-8" />
    <title>Sign Up</title>
    <link rel="stylesheet" href="css/style.css" />
  </head>
  <body>
    Page content
  </body>
</html>
```

 Can you spot the violation? Stylesheets are only allowed to be loaded from `cdn.example.com`, yet the website tries to load one from its own origin (`http://example.com`).
 A browser capable of reporting CSP violations will send the following report as an HTTP `POST` request to `http://example.com/_/csp-reports`, when the document is visited:

```json
{
  "csp-report": {
    "blocked-uri": "http://example.com/css/style.css",
    "disposition": "report",
    "document-uri": "http://example.com/signup.html",
    "effective-directive": "style-src-elem",
    "original-policy": "default-src 'none'; style-src cdn.example.com; report-to /\_/csp-reports",
    "referrer": "",
    "status-code": 200,
    "violated-directive": "style-src-elem"
  }
}
```

The report includes the full path to the violating resource in `blocked-uri` which may not always the case. For example, when the `signup.html` would attempt to load CSS from `http://anothercdn.example.com/stylesheet.css`, the browser would *not* include the full path but only the origin (`http://anothercdn.example.com`). This is done to prevent leaking sensitive information about cross-origin resources.

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

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

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

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

See also
--------

* `Content-Security-Policy`
* CSP `report-to` directive
* CSP `report-uri` directive
Deprecated


Host - HTTP

Host
====

 The **`Host`** request header specifies the host and port
 number of the server to which the request is being sent.

 If no port is included, the default port for the service requested is implied (e.g.,
 `443` for an HTTPS URL, and `80` for an HTTP URL).

 A `Host` header field must be sent in all HTTP/1.1 request messages. A
 `400` (Bad Request) status code may be sent to any HTTP/1.1 request
 message that lacks or contains more than one `Host` header field.

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

Syntax
------

```http
Host: <host>:<port>
```

Directives
----------

<host>

the domain name of the server (for virtual hosting).

<port> Optional

TCP port number on which the server is listening.

Examples
--------

```http
Host: developer.mozilla.org
```

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

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

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

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

See also
--------

* `400`
* `<base>`


Keep-Alive - HTTP

Keep-Alive
==========

The **`Keep-Alive`** general header allows the sender to hint about how the connection may be used to set a timeout and a maximum amount of requests.

**Note:** Set the `Connection` header to "keep-alive" for this header to have any effect.

**Warning:** Connection-specific header fields such as
 `Connection` and `Keep-Alive` are prohibited
 in HTTP/2 and
 HTTP/3. Chrome and
 Firefox ignore them in HTTP/2 responses, but Safari conforms to the HTTP/2
 specification requirements and does not load any response that contains them.

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

Syntax
------

```http
Keep-Alive: parameters
```

Directives
----------

`parameters`

A comma-separated list of parameters, each consisting of an identifier and a value separated by the equal sign (`'='`). The following identifiers are possible:

* `timeout`: An integer that is the time in seconds that the host will allow an idle connection to remain open before it is closed. A connection is idle if no data is sent or received by a host. A host may keep an idle connection open for longer than `timeout` seconds, but the host should attempt to retain a connection for at least `timeout` seconds.
* `max`: An integer that is the maximum number of requests that can be sent on this connection before closing it. Unless `0`, this value is ignored for non-pipelined connections as another request will be sent in the next response. An HTTP pipeline can use it to limit the pipelining.

Examples
--------

A response containing a `Keep-Alive` header:

```http
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Thu, 11 Aug 2016 15:23:13 GMT
Keep-Alive: timeout=5, max=1000
Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT
Server: Apache

(body)
```

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

| Specification |
| --- |
| HTTP/1.1 # compatibility.with.http.1.0.persistent.connections |

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

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

See also
--------

* `Connection`
* Connection management in HTTP/1.x


Referrer-Policy - HTTP

Referrer-Policy
===============

The **`Referrer-Policy`** HTTP header controls how much referrer information (sent with the `Referer` header) should be included with requests. Aside from the HTTP header, you can set this policy in HTML.

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

Syntax
------

```http
Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url
```

**Note:** The original header name `Referer` is a misspelling of the word "referrer". The `Referrer-Policy` header does not share this misspelling.

Directives
----------

`no-referrer`

The `Referer` header will be omitted: sent requests do not include any referrer information.

`no-referrer-when-downgrade`

Send the origin, path, and querystring in `Referer` when the protocol security level stays the same or improves (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS). Don't send the `Referer` header for requests to less secure destinations (HTTPS→HTTP, HTTPS→file).

`origin`

 Send only the origin in the `Referer` header.
 For example, a document at `https://example.com/page.html` will send the referrer `https://example.com/`.

`origin-when-cross-origin`

When performing a same-origin request to the same protocol level (HTTP→HTTP, HTTPS→HTTPS), send the origin, path, and query string. Send only the origin for cross origin requests and requests to less secure destinations (HTTPS→HTTP).

`same-origin`

Send the origin, path, and query string for same-origin requests. Don't send the `Referer` header for cross-origin requests.

`strict-origin`

Send only the origin when the protocol security level stays the same (HTTPS→HTTPS). Don't send the `Referer` header to less secure destinations (HTTPS→HTTP).

`strict-origin-when-cross-origin` (default)

Send the origin, path, and querystring when performing a same-origin request. For cross-origin requests send the origin (only) when the protocol security level stays same (HTTPS→HTTPS). Don't send the `Referer` header to less secure destinations (HTTPS→HTTP).

**Note:** This is the default policy if no policy is specified, or if the provided value is invalid (see spec revision November 2020). Previously the default was `no-referrer-when-downgrade`.

`unsafe-url`

Send the origin, path, and query string when performing any request, regardless of security.

**Warning:** This policy will leak potentially-private information from HTTPS resource URLs to insecure origins. Carefully consider the impact of this setting.

Integration with HTML
---------------------

You can also set referrer policies inside HTML. For example, you can set the referrer policy for the entire document with a `<meta>` element with a name of `referrer`:

```html
<meta name="referrer" content="origin" />
```

You can specify the `referrerpolicy` attribute on `<a>`, `<area>`, `<img>`, `<iframe>`, `<script>`, or `<link>` elements to set referrer policies for individual requests:

```html
<a href="http://example.com" referrerpolicy="origin">…</a>
```

Alternatively, you can set a `noreferrer` link relation on an `a`, `area`, or `link` elements:

```html
<a href="http://example.com" rel="noreferrer">…</a>
```

**Warning:** As seen above, the `noreferrer` link relation is written without a dash. When you specify the referrer policy for the entire document with a `<meta>` element, it should be written *with* a dash: `<meta name="referrer" content="no-referrer">`.

Integration with CSS
--------------------

CSS can fetch resources referenced from stylesheets. These resources follow a referrer policy as well:

* External CSS stylesheets use the default policy (`strict-origin-when-cross-origin`), unless it's overwritten by a `Referrer-Policy` HTTP header on the CSS stylesheet's response.
* For `<style>` elements or `style` attributes, the owner document's referrer policy is used.
Examples
--------

### `no-referrer`

| From document | Navigation to | Referrer used |
| --- | --- | --- |
| `https://example.com/page` | *anywhere* | *(no referrer)* |

### `no-referrer-when-downgrade`

| From document | Navigation to | Referrer used |
| --- | --- | --- |
| `https://example.com/page` | `https://example.com/otherpage` | `https://example.com/page` |
| `https://example.com/page` | `https://mozilla.org` | `https://example.com/page` |
| `https://example.com/page` | **http**://example.com | *(no referrer)* |

### `origin`

| From document | Navigation to | Referrer used |
| --- | --- | --- |
| `https://example.com/page` | *anywhere* | `https://example.com/` |

### `origin-when-cross-origin`

| From document | Navigation to | Referrer used |
| --- | --- | --- |
| `https://example.com/page` | `https://example.com/otherpage` | `https://example.com/page` |
| `https://example.com/page` | `https://mozilla.org` | `https://example.com/` |
| `https://example.com/page` | **http**://example.com/page | `https://example.com/` |

### `same-origin`

| From document | Navigation to | Referrer used |
| --- | --- | --- |
| `https://example.com/page` | `https://example.com/otherpage` | `https://example.com/page` |
| `https://example.com/page` | `https://mozilla.org` | *(no referrer)* |

### `strict-origin`

| From document | Navigation to | Referrer used |
| --- | --- | --- |
| `https://example.com/page` | `https://mozilla.org` | `https://example.com/` |
| `https://example.com/page` | **http**://example.com | *(no referrer)* |
| **http**://example.com/page | *anywhere* | `http://example.com/` |

### `strict-origin-when-cross-origin`

| From document | Navigation to | Referrer used |
| --- | --- | --- |
| `https://example.com/page` | `https://example.com/otherpage` | `https://example.com/page` |
| `https://example.com/page` | `https://mozilla.org` | `https://example.com/` |
| `https://example.com/page` | **http**://example.com | *(no referrer)* |

### `unsafe-url`

| From document | Navigation to | Referrer used |
| --- | --- | --- |
| `https://example.com/page?q=123` | *anywhere* | `https://example.com/page?q=123` |

### Specify a fallback policy

If you want to specify a fallback policy in case the desired policy hasn't got wide enough browser support, use a comma-separated list with the desired policy specified last:

```http
Referrer-Policy: no-referrer, strict-origin-when-cross-origin
```

In the above scenario, `no-referrer` is used only if the browser does not support the `strict-origin-when-cross-origin` policy.

**Note:** Specifying multiple values is only supported in the `Referrer-Policy` HTTP header, and not in the `referrerpolicy` attribute.

Browser-specific preferences/settings
-------------------------------------

### Firefox preferences

You can configure the *default* referrer policy in Firefox preferences. The preference names are version specific:

* Firefox version 59 and later: `network.http.referer.defaultPolicy` (and `network.http.referer.defaultPolicy.pbmode` for private networks)
* Firefox versions 53 to 58: `network.http.referer.userControlPolicy`

All of these settings take the same set of values: `0 = no-referrer`, `1 = same-origin`, `2 = strict-origin-when-cross-origin`, `3 = no-referrer-when-downgrade`.

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

| Specification |
| --- |
| Referrer Policy # referrer-policy-header |

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

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

See also
--------

* Web security > Referer header: privacy and security concerns
* HTTP referer on Wikipedia
* When using Fetch: `Request.referrerPolicy`
* The obsolete `Content-Security-Policy`'s `referrer`
Deprecated
 directive.
* Same-origin policy
* Tighter Control Over Your Referrers – Mozilla Security Blog


Upgrade-Insecure-Requests - HTTP

Upgrade-Insecure-Requests
=========================

The HTTP **`Upgrade-Insecure-Requests`** request header sends a signal to the server expressing the client's preference for an encrypted and authenticated response, and that it can successfully handle the `upgrade-insecure-requests` CSP directive.

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

Syntax
------

```http
Upgrade-Insecure-Requests: 1
```

Examples
--------

A client's request signals to the server that it supports the upgrade mechanisms of `upgrade-insecure-requests`:

```http
GET / HTTP/1.1
Host: example.com
Upgrade-Insecure-Requests: 1
```

The server can now redirect to a secure version of the site. A `Vary` header can be used so that the site isn't served by caches to clients that don't support the upgrade mechanism.

```http
Location: https://example.com/
Vary: Upgrade-Insecure-Requests
```

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

| Specification |
| --- |
| Upgrade Insecure Requests # preference |

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

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

See also
--------

* `Content-Security-Policy`
* CSP `upgrade-insecure-requests` directive


Content-Language - HTTP

Content-Language
================

The **`Content-Language`** representation header is used to **describe the language(s) intended for the audience**, so users can differentiate it according to their own preferred language.

For example, if "`Content-Language: de-DE`" is set, it says that the document is intended for German language speakers (however, it doesn't indicate the document is written in German. For example, it might be written in English as part of a language course for German speakers. If you want to indicate which language the document is written in, use the `lang` attribute instead).

If no `Content-Language` is specified, the default is that the content is intended for all language audiences. Multiple language tags are also possible, as well as applying the `Content-Language` header to various media types and not only to textual documents.

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

Syntax
------

```http
Content-Language: de-DE
Content-Language: en-US
Content-Language: de-DE, en-CA
```

Directives
----------

`language-tag`

Multiple language tags are separated by a comma. Each language tag is a sequence of one or more case-insensitive subtags, each separated by a hyphen character ("`-`", `%x2D`). In most cases, a language tag consists of a primary language subtag that identifies a broad family of related languages (e.g., "`en`" = English) and is optionally followed by a series of subtags that refine or narrow that language's range (e.g., "`en-CA`" = the variety of English as communicated in Canada).

**Note:** Language tags are formally defined in BCP 47, which rely on the ISO 639 standard (quite often the ISO 639-1 code list) for language codes to be used.

Examples
--------

### Indicating the language a document is written in

The global `lang` attribute is used on HTML elements to indicate the language of an entire HTML document or parts of it.

```html
<html lang="de">
  …
</html>
```

Do **not** use this meta element like this for stating a document language:

```html
<!-- ⚠ This is bad practice -->
<meta http-equiv="content-language" content="de" />
```

### Indicating a target audience for a resource

The `Content-Language` header is used to specify the **page's intended audience** and can indicate that this is more than one language.

```http
Content-Language: de, en
```

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

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

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

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

See also
--------

* `Accept-Language`
* HTTP headers, meta elements and language information
* HTML `lang` attribute


Origin-Agent-Cluster - HTTP

Origin-Agent-Cluster
====================

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

The **`Origin-Agent-Cluster`** HTTP response header is used to request that the associated `Document` should be placed in an *origin-keyed agent cluster*. This means that operating system resources (for example, the operating system process) used to evaluate the document should be shared only with other documents from the same origin.

The effect of this is that a resource-intensive document will be less likely to degrade the performance of documents from other origins.

Modern web browsers have a multiprocess architecture in which pages from different origins can run in different operating system processes. This is important for performance, because it means that a resource-intensive page will not have as much of an impact on other pages that the user has open.

However, browsers can't as a general rule run same-site, cross-origin pages in different processes, because of certain DOM APIs that depend on same-site, cross-origin communication. For example, by default, pages from the following two origins will share the same operating system resources:
```

https://apples.example.org
https://oranges.example.org
```

By setting the `Origin-Agent-Cluster` header, a page can request that the browser allocate dedicated resources to this origin that are not shared with any other origins.

The browser is not required to honor the request. If it does, the `Window.originAgentCluster` property returns `true`, and the window is not able to do the following things, which all depend on same-site, cross-origin communication:

* Use `Document.domain`.
* Send `WebAssembly.Module` objects to other same-site cross-origin pages using `postMessage()`.
* Send `SharedArrayBuffer` or `WebAssembly.Memory` objects to other same-site cross-origin pages.

Origin-keyed agent clusters should not be viewed as a security feature: browsers may ignore the request for various reasons, or choose to implement it in a way that does not provide memory protection (for example, using separate threads instead of separate processes). Instead, this feature is a hint that the user experience would be improved if this origin were allocated dedicated resources.

For example, suppose your site includes a page from one origin that embeds a same-site, cross-origin iframe which runs a resource-intensive game. By setting `Origin-Agent-Cluster` on the document in the iframe, you can prevent the game from affecting the performance of the main page.

The browser will ensure that all pages from a given origin are either origin-keyed or they are not. This means that:

* If the first page from an origin does not set the header, then no other pages from that origin will be origin-keyed, even if those other pages do set the header.
* If the first page from an origin sets the header and is made origin-keyed, then all other pages from that origin will be origin-keyed whether they ask for it or not.

To avoid this kind of unpredictable situation, you should set this header for all pages from a given origin, or none of them.

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

Syntax
------

```http
Origin-Agent-Cluster: <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
--------

```http
Origin-Agent-Cluster: ?1
```

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

| Specification |
| --- |
| HTML Standard # origin-agent-cluster |

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

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

See also
--------

* `Window.originAgentCluster`
* Requesting performance isolation with the Origin-Agent-Cluster header on web.dev


Allow - HTTP

Allow
=====

The **`Allow`** header lists the set of methods supported by a resource.

This header must be sent if the server responds with a `405` `Method Not Allowed` status code to indicate which request methods can be used. An empty `Allow` header indicates that the resource allows no request methods, which might occur temporarily for a given resource, for example.

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

Syntax
------

```http
Allow: <http-methods>
```

Directives
----------

<http-methods>

The comma-separated list of allowed HTTP request methods.

Examples
--------

```http
Allow: GET, POST, HEAD
```

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

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

See also
--------

* `405`
* `Server`


Link - HTTP

Link
====

The HTTP **`Link`** entity-header field provides a means for serializing one or more links in HTTP headers. It is semantically equivalent to the HTML `<link>` element.

**Note:** Some browsers do not support the "icon" relation via HTTP (FF#1185705). Use HTML `<link rel="icon">` instead.

Syntax
------

```http
Link: <uri-reference>; param1=value1; param2="value2"
```

`<uri-reference>`

The URI reference, must be enclosed between `<` and `>` and URL encoded.

### Parameters

The link header contains parameters, which are separated with `;` and are equivalent to attributes of the `<link>` element.

Examples
--------

The URI (absolute or relative) must be enclosed between `<` and `>`:

```http
Link: <https://example.com>; rel="preconnect"
```

```http
Link: https://bad.example; rel="preconnect"
```

### Encoding URLs

The URI (absolute or relative) must encode char codes greater than 255:

```http
Link: <https://example.com/%E8%8B%97%E6%9D%A1>; rel="preconnect"
```

```http
Link: <https://example.com/苗条>; rel="preconnect"
```

### Specifying multiple links

You can specify multiple links separated by commas, for example:

```http
Link: <https://one.example.com>; rel="preconnect", <https://two.example.com>; rel="preconnect", <https://three.example.com>; rel="preconnect"
```

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

| Specification |
| --- |
| Web Linking # header |

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

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

See also
--------

* `103 Early Hints`
* `<link>`


Cross-Origin-Resource-Policy - HTTP

Cross-Origin-Resource-Policy
============================

 The HTTP **`Cross-Origin-Resource-Policy`** response header
 conveys a desire that the browser blocks no-cors cross-origin/cross-site requests to the
 given resource.

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

Syntax
------

```http
Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin
```

Examples
--------

 The response header below will cause compatible user agents to disallow cross-origin
 no-cors requests:

```http
Cross-Origin-Resource-Policy: same-origin
```

For more examples, see https://resourcepolicy.fyi/.

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

| Specification |
| --- |
| Fetch Standard # cross-origin-resource-policy-header |

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

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

See also
--------

* Cross-Origin Resource Policy (CORP) explainer
* Consider deploying Cross-Origin Resource Policy
* `Access-Control-Allow-Origin`


Clear-Site-Data - HTTP

Clear-Site-Data
===============

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

The **`Clear-Site-Data`** header clears browsing data (cookies, storage, cache) associated with the requesting website. It allows web developers to have more control over the data stored by a client browser for their origins.

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

Syntax
------

The `Clear-Site-Data` header accepts one or more directives. If all types of data should be cleared, the wildcard directive (`"*"`) can be used.

```http
// Single directive
Clear-Site-Data: "cache"

// Multiple directives (comma separated)
Clear-Site-Data: "cache", "cookies"

// Wild card
Clear-Site-Data: "\*"
```

Directives
----------

**Note:** All directives must comply with the quoted-string grammar. A directive that does not include the double quotes is invalid.

`"cache"`
Experimental

Indicates that the server wishes to remove locally cached data (the browser cache, see HTTP caching) for the origin of the response URL. Depending on the browser, this might also clear out things like pre-rendered pages, script caches, WebGL shader caches, or address bar suggestions.

`"clientHints"`
Experimental

Indicates that the server wishes to remove all client hints (requested via `Accept-CH`) stored for the origin of the response URL.

**Note:** In browsers that support the `"clientHints"` data type, client hints are also cleared when the `"cache"`, `"cookies"`, or `"*"` types are specified. `"clientHints"` is therefore only needed when none of those other types are specified.

`"cookies"`

Indicates that the server wishes to remove all cookies for the origin of the response URL. HTTP authentication credentials are also cleared out. This affects the entire registered domain, including subdomains. So `https://example.com` as well as `https://stage.example.com`, will have cookies cleared.

`"storage"`

Indicates that the server wishes to remove all DOM storage for the origin of the response URL. This includes storage mechanisms such as:

* localStorage (executes `localStorage.clear`),
* sessionStorage (executes `sessionStorage.clear`),
* IndexedDB (for each database execute `IDBFactory.deleteDatabase`),
* Service worker registrations (for each service worker registration, execute `ServiceWorkerRegistration.unregister`),
* Web SQL databases (deprecated),
* FileSystem API data,
* Plugin data (Flash via `NPP_ClearSiteData`).

`"executionContexts"`
Experimental

Indicates that the server wishes to reload all browsing contexts for the origin of the response (`Location.reload`).

`"*"` (wildcard)

Indicates that the server wishes to clear all types of data for the origin of the response. If more data types are added in future versions of this header, they will also be covered by it.

Examples
--------

### Sign out of a website

If a user signs out of your website or service, you might want to remove locally stored data. To do this, add the `Clear-Site-Data` header to the page that confirms the logging out from the site has been accomplished successfully (`https://example.com/logout`, for example):

```http
Clear-Site-Data: "cache", "cookies", "storage", "executionContexts"
```

### Clearing cookies

If this header is delivered with the response at `https://example.com/clear-cookies`, all cookies on the same domain `https://example.com` and any subdomains (like `https://stage.example.com`, etc.), will be cleared out.

```http
Clear-Site-Data: "cookies"
```

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

| Specification |
| --- |
| Clear Site Data # header |

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

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

See also
--------

* `Cache-Control`


Sec-CH-UA-Full-Version - HTTP

Sec-CH-UA-Full-Version
======================

**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.

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

**Note:** This is being replaced by the `Sec-CH-UA-Full-Version-List`.

The **`Sec-CH-UA-Full-Version`** user agent client hint request header provides the user-agent's full version string.

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

Syntax
------

```http
Sec-CH-UA-Full-Version: <version>
```

### Directives

`<version>`

A string containing the full version number, like "96.0.4664.93".

Examples
--------

A server requests the `Sec-CH-UA-Full-Version` 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-Full-Version
```

 The client may choose to provide the hint, and add the `Sec-CH-UA-Full-Version` header to subsequent requests.
 For example, 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-Full-Version: "96.0.4664.110"
Sec-CH-UA-Platform: "Windows"
```

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

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

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`


Access-Control-Max-Age - HTTP

Access-Control-Max-Age
======================

The **`Access-Control-Max-Age`** response header indicates how long the results of a preflight request (that is the information contained in the `Access-Control-Allow-Methods` and `Access-Control-Allow-Headers` headers) can be cached.

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

Syntax
------

```http
Access-Control-Max-Age: <delta-seconds>
```

Directives
----------

<delta-seconds>

 Maximum number of seconds the results can be cached, as an unsigned non-negative integer.
 Firefox caps this at 24 hours (86400 seconds).
 Chromium (prior to v76) caps at 10 minutes (600 seconds).
 Chromium (starting in v76) caps at 2 hours (7200 seconds).
 The default value is 5 seconds.

Examples
--------

Cache results of a preflight request for 10 minutes:

```http
Access-Control-Max-Age: 600
```

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

| Specification |
| --- |
| Fetch Standard # http-access-control-max-age |

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-Methods`


Accept-CH-Lifetime - HTTP

Accept-CH-Lifetime
==================

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

**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.

**Non-standard:** This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

**Warning:** The header was removed from the specification in draft 8.

 The **`Accept-CH-Lifetime`** header is set by the server to
 specify the persistence of the client hint headers it specified using `Accept-CH`, that the client should
 include in subsequent requests.

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

**Note:** Client Hints are accessible only on secure origins (via TLS).
 `Accept-CH` and `Accept-CH-Lifetime` headers should be persisted for all secure requests
 to ensure Client Hints are sent reliably.

Syntax
------

```http
Accept-CH-Lifetime: <age>
```

Examples
--------

```http
Accept-CH: Viewport-Width
Accept-CH-Lifetime: 86400
```

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

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

See also
--------

* `Accept-CH`
* `Vary`


SourceMap - HTTP

SourceMap
=========

The **`SourceMap`** HTTP response header links generated code to a source map, enabling the browser to reconstruct the original source and present the reconstructed original in the debugger.

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

Syntax
------

```http
SourceMap: <url>
X-SourceMap: <url> (deprecated)
```

### Directives

<url>

A relative (to the request URL) or absolute URL pointing to a source map file.

Examples
--------

```http
SourceMap: /path/to/file.js.map
```

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

| Specification |
| --- |
| Source Map # linking-generated-code |

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

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

See also
--------

* Firefox Developer Tools: using a source map


Accept-Ranges - HTTP

Accept-Ranges
=============

 The **`Accept-Ranges`** HTTP response header is a marker used
 by the server to advertise its support for partial requests from the client for file downloads. The value of this field
 indicates the unit that can be used to define a range.

 In the presence of an `Accept-Ranges` header, the browser may try to
 *resume* an interrupted download instead of trying to restart the download.

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

Syntax
------

```http
Accept-Ranges: <range-unit>
Accept-Ranges: none
```

Directives
----------

`<range-unit>`

 Defines the range unit that the server supports. Though `bytes` is the only
 range unit formally defined by RFC 7233, additional range units may be
 registered in the HTTP Range Unit Registry.

`none`

 Indicates that no range unit is supported. This makes the header equivalent of its own absence
 and is therefore, rarely used. Although in some browsers, like IE9, this setting is used to
 disable or remove the pause buttons in the download manager.

Examples
--------

```http
Accept-Ranges: bytes
```

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

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

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

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

See also
--------

* `If-Range`
* `Range`
* IANA HTTP Range Unit Registry