Permissions-Policy - HTTP

Permissions-Policy
==================

The HTTP **`Permissions-Policy`** header provides a mechanism to allow and deny the use of browser features in a document or within any `<iframe>` elements in the document.

For more information, see the main Permissions Policy article.

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

Syntax
------

```http
Permissions-Policy: <directive>=<allowlist>
```

`<directive>`

The Permissions Policy directive to apply the `allowlist` to. See Directives below for a list of the permitted directive names.

`<allowlist>`

An allowlist is a list of origins that takes one or more of the following values contained in parentheses, separated by spaces:

* `*`: The feature will be allowed in this document, and all nested browsing contexts (`<iframe>`s) regardless of their origin.
* `()` (empty allowlist): The feature is disabled in top-level and nested browsing contexts. The equivalent for `<iframe>` `allow` attributes is `'none'`.
* `self`: The feature will be allowed in this document, and in all nested browsing contexts (`<iframe>`s) in the same origin only. The feature is not allowed in cross-origin documents in nested browsing contexts. `self` can be considered shorthand for `https://your-site.example.com`. The equivalent for `<iframe>` `allow` attributes is `self`.
* `src`: The feature will be allowed in this `<iframe>`, as long as the document loaded into it comes from the same origin as the URL in its src attribute. This value is only used in the `<iframe>` `allow` attribute, and is the *default* `allowlist` value in `<iframe>`s.
* `"<origin>"`: The feature is allowed for specific origins (for example, `"https://a.example.com"`). Origins should be separated by spaces. Note that origins in `<iframe>` allow attributes are not quoted.

The values `*` and `()` may only be used on their own, while `self` and `src` may be used in combination with one or more origins.

**Note:** Directives have a default allowlist, which is always one of `*`, `self`, or `none` for the `Permissions-Policy` HTTP header, and governs the default behavior if they are not explicitly listed in a policy. These are specified on the individual directive reference pages. For `<iframe>` `allow` attributes , the default behavior is always `src`.

Where supported, you can include wildcards in Permissions Policy origins. This means that instead of having to explicitly specify several different subdomains in an allowlist, you can specify them all in a single origin with a wildcard.

So instead of

```http
("https://example.com" "https://a.example.com" "https://b.example.com" "https://c.example.com")
```

You can specify

```http
("https://example.com" "https://*.example.com")
```

**Note:** `"https://*.example.com"` does not match `"https://example.com"`.

Directives
----------

`accelerometer`
Experimental

Controls whether the current document is allowed to gather information about the acceleration of the device through the `Accelerometer` interface.

`ambient-light-sensor`
Experimental

Controls whether the current document is allowed to gather information about the amount of light in the environment around the device through the `AmbientLightSensor` interface.

`autoplay`
Experimental

Controls whether the current document is allowed to autoplay media requested through the `HTMLMediaElement` interface. When this policy is disabled and there were no user gestures, the `Promise` returned by `HTMLMediaElement.play()` will reject with a `NotAllowedError` `DOMException`. The autoplay attribute on `<audio>` and `<video>` elements will be ignored.

`battery`
Experimental

Controls whether the use of the Battery Status API is allowed. When this policy is disabled, the `Promise` returned by `Navigator.getBattery()` will reject with a `NotAllowedError` `DOMException`.

`camera`

Controls whether the current document is allowed to use video input devices. When this policy is disabled, the `Promise` returned by `getUserMedia()` will reject with a `NotAllowedError` `DOMException`.

`display-capture`

Controls whether or not the current document is permitted to use the `getDisplayMedia()` method to capture screen contents. When this policy is disabled, the promise returned by `getDisplayMedia()` will reject with a `NotAllowedError` `DOMException` if permission is not obtained to capture the display's contents.

`document-domain`
Experimental

Controls whether the current document is allowed to set `document.domain`. When this policy is disabled, attempting to set `document.domain` will fail and cause a `SecurityError` `DOMException` to be thrown.

`encrypted-media`
Experimental

Controls whether the current document is allowed to use the Encrypted Media Extensions API (EME). When this policy is disabled, the `Promise` returned by `Navigator.requestMediaKeySystemAccess()` will reject with a `SecurityError` `DOMException`.

`execution-while-not-rendered`
Experimental

Controls whether tasks should execute in frames while they're not being rendered (e.g. if an iframe is `hidden` or has `display: none` set).

`execution-while-out-of-viewport`
Experimental

Controls whether tasks should execute in frames while they're outside of the visible viewport.

`fullscreen`

Controls whether the current document is allowed to use `Element.requestFullscreen()`. When this policy is disabled, the returned `Promise` rejects with a `TypeError`.

`gamepad`
Experimental

 Controls whether the current document is allowed to use the Gamepad API.
 When this policy is disabled, calls to `Navigator.getGamepads()` will throw a `SecurityError` `DOMException`, and the `gamepadconnected` and `gamepaddisconnected` events will not fire.

`geolocation`

Controls whether the current document is allowed to use the `Geolocation` Interface. When this policy is disabled, calls to `getCurrentPosition()` and `watchPosition()` will cause those functions' callbacks to be invoked with a `GeolocationPositionError` code of `PERMISSION_DENIED`.

`gyroscope`
Experimental

Controls whether the current document is allowed to gather information about the orientation of the device through the `Gyroscope` interface.

`hid`
Experimental

Controls whether the current document is allowed to use the WebHID API to connect to uncommon or exotic human interface devices such as alternative keyboards or gamepads.

`identity-credentials-get`
Experimental

Controls whether the current document is allowed to use the Federated Credential Management API (FedCM), and more specifically the `navigator.credentials.get()` method with an `identity` option. Where this policy forbids use of the API, the `Promise` returned by the `get()` call will reject with a `NotAllowedError` `DOMException`.

`idle-detection`
Experimental

Controls whether the current document is allowed to use the Idle Detection API to detect when users are interacting with their devices, for example to report "available"/"away" status in chat applications.

`local-fonts`
Experimental

Controls whether the current document is allowed to gather data on the user's locally-installed fonts via the `Window.queryLocalFonts()` method (see also the Local Font Access API).

`magnetometer`
Experimental

Controls whether the current document is allowed to gather information about the orientation of the device through the `Magnetometer` interface.

`microphone`

Controls whether the current document is allowed to use audio input devices. When this policy is disabled, the `Promise` returned by `MediaDevices.getUserMedia()` will reject with a `NotAllowedError` `DOMException`.

`midi`
Experimental

Controls whether the current document is allowed to use the Web MIDI API. When this policy is disabled, the `Promise` returned by `Navigator.requestMIDIAccess()` will reject with a `SecurityError` `DOMException`.

`otp-credentials`
Experimental

Controls whether the current document is allowed to use the WebOTP API to request a one-time password (OTP) from a specially-formatted SMS message sent by the app's server, i.e., via `navigator.credentials.get({otp: ..., ...})`.

`payment`
Experimental

Controls whether the current document is allowed to use the Payment Request API. When this policy is enabled, the `PaymentRequest()` constructor will throw a `SecurityError` `DOMException`.

`picture-in-picture`
Experimental

Controls whether the current document is allowed to play a video in a Picture-in-Picture mode via the corresponding API.

`publickey-credentials-create`
Experimental

Controls whether the current document is allowed to use the Web Authentication API to create new asymmetric key credentials, i.e., via `navigator.credentials.create({publicKey: ..., ...})`.

`publickey-credentials-get`

Controls whether the current document is allowed to use the Web Authentication API to retrieve already stored public-key credentials, i.e., via `navigator.credentials.get({publicKey: ..., ...})`.

`screen-wake-lock`
Experimental

Controls whether the current document is allowed to use Screen Wake Lock API to indicate that device should not turn off or dim the screen.

`serial`
Experimental

Controls whether the current document is allowed to use the Web Serial API to communicate with serial devices, either directly connected via a serial port, or via USB or Bluetooth devices emulating a serial port.

`speaker-selection`
Experimental

Controls whether the current document is allowed to use the Audio Output Devices API to list and select speakers.

`storage-access`
Experimental

Controls whether a document loaded in a third-party context (i.e. embedded in an `<iframe>`) is allowed to use the Storage Access API to request access to unpartitioned cookies.

`usb`
Experimental

Controls whether the current document is allowed to use the WebUSB API.

`web-share`

Controls whether or not the current document is allowed to use the `Navigator.share()` of Web Share API to share text, links, images, and other content to arbitrary destinations of user's choice, e.g. mobile apps.

`window-management`
Experimental

Controls whether or not the current document is allowed to use the Window Management API to manage windows on multiple displays.

`xr-spatial-tracking`
Experimental

Controls whether or not the current document is allowed to use the WebXR Device API to interact with a WebXR session.

Examples
--------

### Basic usage

#### Permissions-Policy header

To allow all origins access to geolocation, you would do this:

```http
Permissions-Policy: geolocation=\*
```

Or to allow access to a subset of origins, you'd do this:

```http
Permissions-Policy: geolocation=(self "https://a.example.com" "https://b.example.com")
```

Several features can be controlled at the same time by sending the header with a comma-separated list of policies, or by sending a separate header for each policy.

For example, the following are equivalent:

```http
Permissions-Policy: picture-in-picture=(), geolocation=(self https://example.com), camera=\*

Permissions-Policy: picture-in-picture=()
Permissions-Policy: geolocation=(self https://example.com)
Permissions-Policy: camera=\*
```

#### iframes

For an `<iframe>` to have a feature enabled its allowed origin must also be in the allowlist for the parent page. Because of this inheritance behavior, it is a good idea to specify the widest acceptable support for a feature in the HTTP header, and then specify the subset of support you need in each `<iframe>`.

To allow all origins access to geolocation, you would do this:

```html
<iframe src="https://example.com" allow="geolocation \*"></iframe>
```

To apply a policy to the current origin and others, you'd do this:

```html
<iframe
 src="https://example.com"
 allow="geolocation 'self' https://a.example.com https://b.example.com"></iframe>
```

This is important: By default, if an `<iframe>` navigates to another origin, the policy is not applied to the origin that the `<iframe>` navigates to. By listing the origin that the `<iframe>` navigates to in the `allow` attribute, the Permissions Policy that was applied to the original `<iframe>` will be applied to the origin the `<iframe>` navigates to.

Several features can be controlled at the same time by including a semi-colon-separated list of policy directives inside the `allow` attribute.

```html
<iframe
 src="https://example.com"
 allow="geolocation 'self' https://a.example.com https://b.example.com; fullscreen 'none'"></iframe>
```

It is worth giving the `src` value a special mention. We mentioned above that using this allowlist value will mean that the associated feature will be allowed in this `<iframe>`, as long as the document loaded into it comes from the same origin as the URL in its src attribute. This value is the *default* `allowlist` value for features listed in `allow`, so the following are equivalent:

```html
<iframe src="https://example.com" allow="geolocation 'src'">
  <iframe src="https://example.com" allow="geolocation"></iframe
></iframe>
```

### Denying access to powerful features

SecureCorp Inc. wants to disable Microphone (for example `MediaDevices.getUserMedia()`) and `Geolocation` APIs in its application. It can do so using the following response header:

```http
Permissions-Policy: microphone=(), geolocation=()
```

By specifying `()` for the origin list, the specified features will be disabled for all browsing contexts (this includes all `<iframe>`s), regardless of their origin.

### Combining HTTP header and `<iframe>` policies

For example, let's say that we wanted to enable geolocation usage on our own origin, and in embedded content coming from our trusted ad network. We could set up the page-wide Permissions Policy like this:

```http
Permissions-Policy: geolocation=(self https://trusted-ad-network.com)
```

Over in our ad `<iframe>`s, we could set access to the `https://trusted-ad-network.com` origin like this:

```html
<iframe src="https://trusted-ad-network.com" allow="geolocation"></iframe>
```

If a different origin ended up getting loaded into `<iframe>`, it would not have access to geolocation:

```html
<iframe src="https://rogue-origin-example.com" allow="geolocation"></iframe>
```

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

| Specification |
| --- |
| Permissions Policy # permissions-policy-http-header-field |

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

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

See also
--------

* Permissions Policy
* `Document.featurePolicy` and `FeaturePolicy`
* `Content-Security-Policy`
* `Referrer-Policy`


Connection - HTTP

Connection
==========

 The **`Connection`** general header controls whether the
 network connection stays open after the current transaction finishes. If the value sent
 is `keep-alive`, the connection is persistent and not closed, allowing for
 subsequent requests to the same server to be done.

**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
 spec requirements and does not load any response that contains them.

 All hop-by-hop headers used by the message - including standard hop-by-hop headers (`Keep-Alive`,
 `Transfer-Encoding`, `TE`, `Connection`,
 `Trailer`, `Upgrade`,
 `Proxy-Authorization` and `Proxy-Authenticate`) - must be listed in the `Connection`
 header, so that the first proxy knows it has to consume them and not forward them
 further.

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

Syntax
------

```http
Connection: keep-alive
Connection: close
```

Directives
----------

`close`

 Indicates that either the client or the server would like to close the connection.
 This is the default on HTTP/1.0 requests.

any comma-separated list of HTTP headers [Usually `keep-alive` only]

 Indicates that the client would like to keep the connection open. Keeping a connection open
 is the default on HTTP/1.1 requests. The list of headers are the
 name of the header to be removed by the first non-transparent proxy or cache
 in-between: these headers define the connection between the emitter and the first
 entity, not the destination node.

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

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

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

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


WWW-Authenticate - HTTP

WWW-Authenticate
================

The HTTP **`WWW-Authenticate`** response header defines the HTTP authentication methods ("challenges") that might be used to gain access to a specific resource.

**Note:** This header is part of the General HTTP authentication framework, which can be used with a number of authentication schemes.
 Each "challenge" lists a scheme supported by the server and additional parameters that are defined for that scheme type.

 A server using HTTP authentication will respond with a `401` `Unauthorized` response to a request for a protected resource.
 This response must include at least one `WWW-Authenticate` header and at least one challenge, to indicate what authentication schemes can be used to access the resource (and any additional data that each particular scheme needs).

 Multiple challenges are allowed in one `WWW-Authenticate` header, and multiple `WWW-Authenticate` headers are allowed in one response.
 A server may also include the `WWW-Authenticate` header in other response messages to indicate that supplying credentials might affect the response.

 After receiving the `WWW-Authenticate` header, a client will typically prompt the user for credentials, and then re-request the resource.
 This new request uses the `Authorization` header to supply the credentials to the server, encoded appropriately for the selected "challenge" authentication method.
 The client is expected to select the most secure of the challenges it understands (note that in some cases the "most secure" method is debatable).

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

Syntax
------

 At least one challenge must be specified.
 Multiple challenges may be specified, comma-separated, in a single header, or in individual headers:

```http
// Challenges specified in single header
WWW-Authenticate: challenge1, ..., challengeN

// Challenges specified in multiple headers
WWW-Authenticate: challenge1
...
WWW-Authenticate: challengeN
```

 A single challenge has the following format. Note that the scheme token (`<auth-scheme>`) is mandatory.
 The presence of `realm`, `token68` and any other parameters depends on the definition of the selected scheme.

```http
// Possible challenge formats (scheme dependent)
WWW-Authenticate: <auth-scheme>
WWW-Authenticate: <auth-scheme> realm=<realm>
WWW-Authenticate: <auth-scheme> token68
WWW-Authenticate: <auth-scheme> auth-param1=token1, ..., auth-paramN=auth-paramN-token
WWW-Authenticate: <auth-scheme> realm=<realm> token68
WWW-Authenticate: <auth-scheme> realm=<realm> token68 auth-param1=auth-param1-token , ..., auth-paramN=auth-paramN-token
WWW-Authenticate: <auth-scheme> realm=<realm> auth-param1=auth-param1-token, ..., auth-paramN=auth-paramN-token
WWW-Authenticate: <auth-scheme> token68 auth-param1=auth-param1-token, ..., auth-paramN=auth-paramN-token
```

For example, Basic authentication requires `realm` and allows for optional use of `charset` key, but does not support `token68`.

```http
WWW-Authenticate: Basic realm=<realm>
WWW-Authenticate: Basic realm=<realm>, charset="UTF-8"
```

Directives
----------

`<auth-scheme>`

The Authentication scheme. Some of the more common types are (case-insensitive): `Basic`, `Digest`, `Negotiate` and `AWS4-HMAC-SHA256`.

**Note:** For more information/options see HTTP Authentication > Authentication schemes

**realm=**<realm> Optional

 A string describing a protected area.
 A realm allows a server to partition up the areas it protects (if supported by a scheme that allows such partitioning).
 Some clients show this value to the user to inform them about which particular credentials are required — though most browsers stopped doing so to counter phishing.
 The only reliably supported character set for this value is `us-ascii`.
 If no realm is specified, clients often display a formatted hostname instead.

`<token68>` Optional

 A token that may be useful for some schemes. The token allows the 66 unreserved URI characters plus a few others.
 According to the specification, it can hold a base64, base64url, base32, or base16 (hex) encoding, with or without padding, but excluding whitespace.

 Other than `<auth-scheme>` and the key `realm`, authorization parameters are specific to each authentication scheme.
 Generally you will need to check the relevant specifications for these (keys for a small subset of schemes are listed below).

### Basic

`<realm>`

 As above.
 Note that the realm is mandatory for basic authentication.

`charset="UTF-8"` Optional

 Tells the client the server's preferred encoding scheme when submitting a username and password.
 The only allowed value is the case-insensitive string "UTF-8".
 This does not relate to the encoding of the realm string.

### Digest

`<realm>` Optional

 String indicating which username/password to use.
 Minimally should include the host name, but might indicate the users or group that have access.

`domain` Optional

 A quoted, space-separated list of URI prefixes that define all the locations where the authentication information may be used.
 If this key is not specified then the authentication information may be used anywhere on the web root.

`nonce`

 A server-specified quoted string that the server can use to control the lifetime in which particular credentials will be considered valid.
 This must be uniquely generated each time a 401 response is made, and may be regenerated more often (for example, allowing a digest to be used only once).
 The specification contains advice on possible algorithms for generating this value.
 The nonce value is opaque to the client.

`opaque`

 A server-specified quoted string that should be returned unchanged in the `Authorization`.
 This is opaque to the client. The server is recommended to include Base64 or hexadecimal data.

`stale` Optional

 A case-insensitive flag indicating that the previous request from the client was rejected because the `nonce` used is too old (stale).
 If this is `true` the request can be re-tried using the same username/password encrypted using the new `nonce`.
 If it is any other value then the username/password are invalid and must be re-requested from the user.

`algorithm` Optional

 Algorithm used to produce the digest.
 Valid non-session values are: `"MD5"` (default if not specified), `"SHA-256"`, `"SHA-512"`.
 Valid session values are: `"MD5-sess"`, `"SHA-256-sess"`, `"SHA-512-sess"`.

`qop`

Quoted string indicating the quality of protection supported by the server. This must be supplied, and unrecognized options must be ignored.

* `"auth"`: Authentication
* `"auth-int"`: Authentication with integrity protection

`charset="UTF-8"` Optional

 Tells the client the server's preferred encoding scheme when submitting a username and password.
 The only allowed value is the case-insensitive string "UTF-8".

`userhash` Optional

A server may specify `"true"` to indicate that it supports username hashing (default is `"false"`)

### HTTP Origin-Bound Authentication (HOBA)

`<challenge>`

 A set of pairs in the format of '<len>:<value>' concatenated together to be given to a client.
 The challenge is made of up a nonce, algorithm, origin, realm, key identifier, and the challenge.

`<max-age>`

The number of seconds from the time the HTTP response is emitted for which responses to this challenge can be accepted.

`realm` Optional

As above in the directives section.

Examples
--------

### Basic authentication

A server that only supports basic authentication might have a `WWW-Authenticate` response header which looks like this:

```http
WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"
```

 A user-agent receiving this header would first prompt the user for their username and password, and then re-request the resource: this time including the (encoded) credentials in the `Authorization` header.
 The `Authorization` header might look like this:

```http
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

For `"Basic"` authentication the credentials are constructed by first combining the username and the password with a colon (`aladdin:opensesame`), and then by encoding the resulting string in `base64` (`YWxhZGRpbjpvcGVuc2VzYW1l`).

**Note:** See also HTTP authentication for examples on how to configure Apache or Nginx servers to password protect your site with HTTP basic authentication.

### Digest authentication with SHA-256 and MD5

**Note:** This example is taken from RFC 7616 "HTTP Digest Access Authentication" (other examples in the specification show the use of `SHA-512`, `charset`, and `userhash`).

 The client attempts to access a document at URI "http://www.example.org/dir/index.html" that is protected via digest authentication.
 The username for this document is "Mufasa" and the password is "Circle of Life" (note the single space between each of the words).

 The first time the client requests the document, no `Authorization` header field is sent.
 Here the server responds with an HTTP 401 message that includes a challenge for each digest algorithm it supports, in its order of preference (`SHA256` and then `MD5`)

```http
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
 realm="http-auth@example.org",
 qop="auth, auth-int",
 algorithm=SHA-256,
 nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
 opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
WWW-Authenticate: Digest
 realm="http-auth@example.org",
 qop="auth, auth-int",
 algorithm=MD5,
 nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
 opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
```

 The client prompts the user for their username and password, and then responds with a new request that encodes the credentials in the `Authorization` header field.
 If the client chose the MD5 digest the `Authorization` header field might look as shown below:

```http
Authorization: Digest username="Mufasa",
 realm="http-auth@example.org",
 uri="/dir/index.html",
 algorithm=MD5,
 nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
 nc=00000001,
 cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
 qop=auth,
 response="8ca523f5e9506fed4657c9700eebdbec",
 opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
```

If the client chose the SHA-256 digest the `Authorization` header field might look as shown below:

```http
Authorization: Digest username="Mufasa",
 realm="http-auth@example.org",
 uri="/dir/index.html",
 algorithm=SHA-256,
 nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
 nc=00000001,
 cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
 qop=auth,
 response="753927fa0e85d155564e2e272a28d1802ca10daf449
 6794697cf8db5856cb6c1",
 opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
```

### HOBA Authentication

A server that supports HOBA authentication might have a `WWW-Authenticate` response header which looks like this:

```http
WWW-Authenticate: HOBA max-age="180", challenge="16:MTEyMzEyMzEyMw==1:028:https://www.example.com:80800:3:MTI48:NjgxNDdjOTctNDYxYi00MzEwLWJlOWItNGM3MDcyMzdhYjUz"
```

The to-be-signed blob challenge is made from these parts: www.example.com using port 8080, the nonce is '1123123123', the algorithm for signing is RSA-SHA256, the key identifier is 123, and finally the challenge is '68147c97-461b-4310-be9b-4c707237ab53'.

A client would receive this header, extract the challenge, sign it with their private key that corresponds to key identifier 123 in our example using RSA-SHA256, and then send the result in the `Authorization` header as a dot-separated key id, challenge, nonce, and signature.

```http
Authorization: 123.16:MTEyMzEyMzEyMw==1:028:https://www.example.com:80800:3:MTI48:NjgxNDdjOTctNDYxYi00MzEwLWJlOWItNGM3MDcyMzdhYjUz.1123123123.<signature-of-challenge>
```

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

| Specification |
| --- |
| HTTP Semantics # field.www-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`
* `Proxy-Authenticate`
* `401`, `403`, `407`


Large-Allocation - HTTP

Large-Allocation
================

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

 The non-standard **`Large-Allocation`** response header tells the browser that the page being loaded is going to want to perform a large allocation.
 It's not implemented in current versions of any browser, but is harmless to send to any browser.

WebAssembly or asm.js applications can use large
 contiguous blocks of allocated memory. For complex games, for example, these allocations
 can be quite large, sometimes as large as 1GB. The `Large-Allocation` tells
 the browser that the web content in the to-be-loaded page is going to want to perform a
 large contiguous memory allocation and the browser can react to this header by starting
 a dedicated process for the to-be-loaded document, for example.

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

Syntax
------

```http
Large-Allocation: 0
Large-Allocation: <megabytes>
```

Directives
----------

`0`

 0 is a special value which represents uncertainty as to what the size of the
 allocation is.

`<megabytes>`

The expected size of the allocation to be performed, in megabytes.

Examples
--------

```http
Large-Allocation: 0
Large-Allocation: 500
```

Troubleshooting errors
----------------------

 The `Large-Allocation` header throws warnings or error messages when used
 incorrectly. You'll encounter them in the web console.

This page was loaded in a new process due to a `Large-Allocation` header.

 This message means that the browser saw the `Large-Allocation` header,
 and was able to reload the page into a new process which should have more available
 contiguous memory.

A `Large-Allocation` header was ignored due to the load being triggered
 by a non-GET request.

 When a `POST` request is used to load a document, that load cannot
 currently be redirected into a new process. This error is displayed when loading a
 document with a `Large-Allocation` header with a non-GET HTTP method. This
 could be caused due to the document being loaded by a form submission, for example.

A `Large-Allocation` header was ignored due to the presence of windows
 which have a reference to this browsing context through the frame hierarchy or
 `window.opener`.

 This error means that the document was not loaded at the top level of an
 user-opened or noopener-opened tab or window. It can occur in these situations:

* The document with the `Large-Allocation` header was loaded in an
 `<iframe>`. Firefox cannot move an iframe into a new process
 currently, so the document must load in the current process.
* The document with the `Large-Allocation` header was loaded in a
 window which was opened by `window.open()`,
 `<a target="_blank">` or other similar methods without
 `rel="noopener"` or the `"noopener"` feature being set.
 These windows must remain in the same process as their opener, as they can
 communicate, meaning that we cannot allow them to switch processes.
* The document with the `Large-Allocation header` has opened another
 window with `window.open()`, `<a target="_blank">`
 or other similar methods without `rel="noopener"` or the
 `"noopener"` feature being set. This is for the same reason as above,
 namely that they can communicate and thus we cannot allow them to switch
 processes.

This page would be loaded in a new process due to a `Large-Allocation`
 header, however `Large-Allocation` process creation is disabled on
 non-Win32 platforms.

 Firefox currently only supports the `Large-Allocation` header in our
 32-bit Windows builds, as memory fragmentation is not an issue in 64-bit builds. If
 you are running a non-win32 version of Firefox, this error will appear. This check can
 be disabled with the `dom.largeAllocation.forceEnable` boolean preference in about:config.

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

 Not part of any current specifications. An explainer of the ideas behind this header
 can be found in this document.

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

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

See also
--------

* WebAssembly


Sec-Fetch-User - HTTP

Sec-Fetch-User
==============

The **`Sec-Fetch-User`** fetch metadata request header is only sent for requests initiated by user activation, and its value will always be `?1`.

A server can use this header to identify whether a navigation request from a document, iframe, etc., was originated by the user.

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

Syntax
------

```http
Sec-Fetch-User: ?1
```

Directives
----------

The value will always be `?1`. When a request is triggered by something other than a user activation, the spec requires browsers to omit the header completely.

Examples
--------

If a user clicks on a page link to another page on the same origin, the resulting request would have the following headers:

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

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

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

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

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

See also
--------

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


Sec-CH-UA-Full-Version-List - HTTP

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

**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-Full-Version-List`** user agent client hint request header provides the user-agent's branding and full version information.

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

The **`Sec-CH-UA-Full-Version-List`** header provides the brand and full version information for each brand associated with the browser, in a comma-separated list.

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

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

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

**Note:** This is similar to `Sec-CH-UA`, but includes the full version number instead of the significant version number for each brand.

Syntax
------

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

```http
Sec-CH-UA-Full-Version-List: "<brand>";v="<full version>", ...
```

### Directives

`<brand>`

 A brand associated with the user agent, like "Chromium", "Google Chrome".
 This may be an intentionally incorrect brand like `" Not A;Brand"` or `"(Not(A:Brand"` (the actual value is expected change over time and be unpredictable).

`<full version>`

A full version number, such as 98.0.4750.0.

Examples
--------

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

The client may choose to provide the hint, and add the `Sec-CH-UA-Full-Version-List` header to subsequent requests, as shown below:

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

Sec-CH-UA: " Not A;Brand";v="99", "Chromium";v="98", "Google Chrome";v="98"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Full-Version-List: " Not A;Brand";v="99.0.0.0", "Chromium";v="98.0.4750.0", "Google Chrome";v="98.0.4750.0"
Sec-CH-UA-Platform: "Linux"
```

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

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

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`


If-Unmodified-Since - HTTP

If-Unmodified-Since
===================

 The HyperText Transfer Protocol (HTTP) **`If-Unmodified-Since`** request header makes the
 request for the resource conditional: the server will send the requested resource or accept it in
 the case of a `POST` or another non-safe method only if the resource has not been modified after the date specified by this HTTP header. If the resource has been modified
 after the specified date, the response will be a `412 Precondition Failed` error.

The **`If-Unmodified-Since`** HTTP header is commonly used in the following situations:

* In conjunction with non-safe methods, like `POST`,
 this header can be used to implement an optimistic concurrency control, as is done by some wikis: editions are rejected if the
 stored document has been modified since the original was retrieved.
* In conjunction with a range request using the `Range` header, this header can
 be used to ensure that the new fragment requested comes from an unmodified document.

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

Syntax
------

```http
If-Unmodified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

Directives
----------

<day-name>

A 3-letter description of the day of the week. One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).

<day>

A 2-digit day number of the month. Examples: "04", "23".

<month>

A 3-letter description of the month. One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (case-sensitive).

<year>

A 4-digit year number. Examples: "1990", "2016".

<hour>

A 2-digit hour number based on a 24-hour system. Examples: "09", "23".

<minute>

A 2-digit minute number. Examples: "04", "59".

<second>

A 2-digit second number. Examples: "04", "59".

`GMT`

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

Examples
--------

```http
If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT
```

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

| Specification |
| --- |
| HTTP Semantics # field.if-unmodified-since |

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

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

See also
--------

* `Last-Modified`
* `If-Modified-Since`
* `If-Match`
* `If-None-Match`
* `Range`
* `412 Precondition Failed`


Range - HTTP

Range
=====

 The **`Range`** HTTP request header indicates the parts of a resource that the server should return.
 Several parts can be requested at the same time in one `Range` header, and the server may send back these ranges in a multipart document.
 If the server sends back ranges, it uses the `206 Partial Content` status code for the response.
 If the ranges are invalid, the server returns the `416 Range Not Satisfiable` error.

 A server that doesn't support range requests may ignore the `Range` header and return the whole resource with a `200` status code.
 Ignoring the `Range` header is equivalent to `Accept-Ranges: none`, so the `Accept-Ranges` response header is rarely used for this purpose.

 Currently only `bytes` units are registered which are *offsets* (zero-indexed & inclusive).
 If the requested data has a content coding applied, each byte range represents the encoded sequence of bytes, not the bytes that would be obtained after decoding.

The header is a CORS-safelisted request header when the directive specifies a single byte range.

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

Syntax
------

```http
Range: <unit>=<range-start>-
Range: <unit>=<range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>, <range-start>-<range-end>
Range: <unit>=-<suffix-length>
```

Directives
----------

<unit>

The unit in which ranges are specified.

<range-start>

An integer in the given unit indicating the start position of the request range.

<range-end>

 An integer in the given unit indicating the end position of the requested range.
 This value is optional and, if omitted, the end of the resource is used as the end of the range.

<suffix-length>

An integer indicating the number of units at the end of the resource to return.

Examples
--------

 The following examples show how to make requests using the `Range` header for CORS-safelisted requests, and for requesting multiple ranges.
 Other examples can be found in the HTTP range requests guide.

### Single byte ranges and CORS-safelisted requests

 The `Range` header is a CORS-safelisted request header when the value is a single byte range.
 This means that it can be used in cross-origin requests without triggering a preflight request, which is useful for requesting media and resuming downloads.

The following example requests the first 500 bytes of a resource:

```http
Range: bytes=0-499
```

To request the second 500 bytes:

```http
Range: bytes=500-999
```

Omitting the end position requests all remaining units of the resource, so the last 100 bytes of a resource with a length of 1000 bytes can be requested using:

```http
Range: bytes=900-
```

Alternatively, if it's unknown how large a resource is, the last `n` bytes can be requested using a suffix range of `-n`:

```http
Range: bytes=-100
```

### Requesting multiple ranges

 Given a resource with a length of 10000 bytes, the following example requests three separate ranges; `200`-`999` (800 bytes), `2000`-`2499` (500 bytes), and finally `9500-`.
 The ranges-specifier value `9500-` omits an end position which indicates that all bytes from 9500 onward are part of the third range (500 bytes).

```http
Range: bytes=200-999, 2000-2499, 9500-
```

 This example requests the first 500 and last 500 bytes of the file.
 The request may be rejected by the server if these ranges overlap (if the requested resource was less than 1000 bytes long, for instance).

```http
Range: bytes=0-499, -499
```

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

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

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

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

See also
--------

* `If-Range`
* `Content-Range`
* `Content-Type`
* `Accept-Ranges`
* `206 Partial Content`
* `416 Range Not Satisfiable`
* HTTP range requests guide
* CORS-safelisted request header


Retry-After - HTTP

Retry-After
===========

 The **`Retry-After`** response HTTP header indicates how long
 the user agent should wait before making a follow-up request. There are three main cases
 this header is used:

* When sent with a `503` (Service Unavailable) response, this indicates
 how long the service is expected to be unavailable.
* When sent with a `429` (Too Many Requests) response, this indicates
 how long to wait before making a new request.
* When sent with a redirect response, such as `301` (Moved Permanently),
 this indicates the minimum time that the user agent is asked to wait before issuing
 the redirected request.

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

Syntax
------

```http
Retry-After: <http-date>
Retry-After: <delay-seconds>
```

Directives
----------

<http-date>

 A date after which to retry. See the `Date` header for more details
 on the HTTP date format.

<delay-seconds>

 A non-negative decimal integer indicating the seconds to delay after the response is
 received.

Examples
--------

### Dealing with scheduled downtime

 Support for the `Retry-After` header on both clients and servers is still
 inconsistent. However, some crawlers and spiders, like the Googlebot, honor the
 `Retry-After` header. It is useful to send it along with a
 `503` (Service Unavailable) response, so that search engines will keep
 indexing your site when the downtime is over.

```http
Retry-After: Wed, 21 Oct 2015 07:28:00 GMT
Retry-After: 120
```

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

| Specification |
| --- |
| HTTP Semantics # field.retry-after |

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

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

See also
--------

* Google Webmaster blog: How to deal with planned site downtime
* `503` (Service Unavailable)
* `301` (Moved Permanently)


From - HTTP

From
====

 The **`From`** request header contains an Internet email
 address for a human user who controls the requesting user agent.

 If you are running a robotic user agent (e.g. a crawler), the `From` header
 must be sent, so you can be contacted if problems occur on servers, such as if the
 robot is sending excessive, unwanted, or invalid requests.

**Warning:** You must not use the `From` header for access control or authentication.

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

Syntax
------

```http
From: <email>
```

Directives
----------

<email>

A machine-usable email address.

Examples
--------

```http
From: webmaster@example.org
```

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

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

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

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

See also
--------

* `Host`


Sec-CH-Prefers-Reduced-Transparency - HTTP

Sec-CH-Prefers-Reduced-Transparency
===================================

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

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

The **`Sec-CH-Prefers-Reduced-Transparency`** user agent client hint request header indicates the user agent's preference for reduced transparency.

If a server signals to a client via the `Accept-CH` header that it accepts `Sec-CH-Prefers-Reduced-Transparency`, the client can then respond with this header to indicate the user's preference for reduced transparency. The server can send the client appropriately adapted content — for example, CSS or images — to reduce the transparency of the content.

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

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

Syntax
------

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

### Directives

`<preference>`

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

Examples
--------

The client makes an initial request to the server:

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

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

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

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

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

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

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

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

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

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`


Set-Cookie - HTTP

Set-Cookie
==========

 The **`Set-Cookie`** HTTP response header is used to send a cookie from the server to the user agent, so that the user agent can send it back to the server later.
 To send multiple cookies, multiple **`Set-Cookie`** headers should be sent in the same response.

**Warning:** Browsers block frontend JavaScript code from accessing the `Set-Cookie` header, as required by the Fetch spec, which defines `Set-Cookie` as a forbidden response-header name that must be filtered out from any response exposed to frontend code.

For more information, see the guide on Using HTTP cookies.

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

Syntax
------

```http
Set-Cookie: <cookie-name>=<cookie-value>
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<number>
Set-Cookie: <cookie-name>=<cookie-value>; Partitioned
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
Set-Cookie: <cookie-name>=<cookie-value>; Secure

Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None; Secure

// Multiple attributes are also possible, for example:
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly
```

Attributes
----------

`<cookie-name>=<cookie-value>`

 Defines the cookie name and its value.
 A cookie definition begins with a name-value pair.

A `<cookie-name>` can contain any US-ASCII characters except for: control characters (ASCII characters 0 up to 31 and ASCII character 127) or separator characters (space, tab and the characters: `( ) < > @ , ; : \ " / [ ] ? = { }`)

A `<cookie-value>` can optionally be wrapped in double quotes and include any US-ASCII character excluding control characters (ASCII characters 0 up to 31 and ASCII character 127), Whitespace, double quotes, commas, semicolons, and backslashes.

**Encoding**: Many implementations perform URL encoding on cookie values.
 However, this is not required by the RFC specification.
 The URL encoding does help to satisfy the requirements of the characters allowed for `<cookie-value>`.

**Note:** Some `<cookie-name>` have a specific semantic:

**`__Secure-` prefix**: Cookies with names starting with `__Secure-` (dash is part of the prefix)
 must be set with the `secure` flag from a secure page (HTTPS).

**`__Host-` prefix**: Cookies with names starting with `__Host-` must be set with the `secure` flag, must be from a secure page (HTTPS), must not have a domain specified (and therefore, are not sent to subdomains), and the path must be `/`.

`Domain=<domain-value>` Optional

Defines the host to which the cookie will be sent.

Only the current domain can be set as the value, or a domain of a higher order, unless it is a public suffix. Setting the domain will make the cookie available to it, as well as to all its subdomains.

If omitted, this attribute defaults to the host of the current document URL, not including subdomains.

Contrary to earlier specifications, leading dots in domain names (`.example.com`) are ignored.

Multiple host/domain values are *not* allowed, but if a domain *is* specified, then subdomains are always included.

`Expires=<date>` Optional

 Indicates the maximum lifetime of the cookie as an HTTP-date timestamp.
 See `Date` for the required formatting.

 If unspecified, the cookie becomes a **session cookie**.
 A session finishes when the client shuts down, after which
 the session cookie is removed.

**Warning:** Many web browsers have a *session restore* feature that will save all tabs and restore them the next time the browser is used. Session cookies will also be restored, as if the browser was never closed.

When an `Expires` date is set, the deadline is relative to the *client* the cookie is being set on, not the server.

`HttpOnly` Optional

 Forbids JavaScript from accessing the cookie, for example, through the `Document.cookie` property.
 Note that a cookie that has been created with `HttpOnly` will still be sent with JavaScript-initiated requests, for example, when calling `XMLHttpRequest.send()` or `fetch()`.
 This mitigates attacks against cross-site scripting (XSS).

`Max-Age=<number>` Optional

Indicates the number of seconds until the cookie expires. A zero or negative number will expire the cookie immediately. If both `Expires` and `Max-Age` are set, `Max-Age` has precedence.

`Partitioned` Optional
Experimental

Indicates that the cookie should be stored using partitioned storage. See Cookies Having Independent Partitioned State (CHIPS) for more details.

`Path=<path-value>` Optional

Indicates the path that *must* exist in the requested URL for the browser to send the `Cookie` header.

The forward slash (`/`) character is interpreted as a directory separator, and subdirectories are matched as well. For example, for `Path=/docs`,

* the request paths `/docs`, `/docs/`, `/docs/Web/`, and `/docs/Web/HTTP` will all match.
* the request paths `/`, `/docsets`, `/fr/docs` will not match.

`SameSite=<samesite-value>` Optional

 Controls whether or not a cookie is sent with cross-site requests,
 providing some protection against cross-site request forgery attacks (CSRF).

The possible attribute values are:

`Strict`

 Means that the browser sends the cookie only for same-site requests, that is, requests originating from the same site that set the cookie.
 If a request originates from a different domain or scheme (even with the same domain), no cookies with the `SameSite=Strict` attribute are sent.

`Lax`

 Means that the cookie is not sent on cross-site requests, such as on requests to load images or frames, but is sent when a user is navigating to the origin site from an external site (for example, when following a link).
 This is the default behavior if the `SameSite` attribute is not specified.

`None`

 Means that the browser sends the cookie with both cross-site and same-site requests.
 The `Secure` attribute must also be set when setting this value, like so `SameSite=None; Secure`. If `Secure` is missing an error will be logged:

```

Cookie "myCookie" rejected because it has the "SameSite=None" attribute but is missing the "secure" attribute.

This Set-Cookie was blocked because it had the "SameSite=None" attribute but did not have the "Secure" attribute, which is required in order to use "SameSite=None".
```

**Note:** A `Secure` cookie is only sent to the server with an encrypted request over the HTTPS protocol. Note that insecure sites (`http:`) can't set cookies with the `Secure` directive, and therefore can't use `SameSite=None`.

`Secure` Optional

Indicates that the cookie is sent to the server only when a request is made with the `https:` scheme (except on localhost), and therefore, is more resistant to man-in-the-middle attacks.

**Note:** Do not assume that `Secure` prevents all access to sensitive information in cookies (session keys, login details, etc.). Cookies with this attribute can still be read/modified either with access to the client's hard disk or from JavaScript if the `HttpOnly` cookie attribute is not set.

Insecure sites (`http:`) cannot set cookies with the `Secure` attribute (since Chrome 52 and Firefox 52). The `https:` requirements are ignored when the `Secure` attribute is set by localhost (since Chrome 89 and Firefox 75).

Examples
--------

### Session cookie

**Session cookies** are removed when the client shuts down. Cookies are session cookies if they do not specify the `Expires` or `Max-Age` attribute.

```http
Set-Cookie: sessionId=38afes7a8
```

### Permanent cookie

**Permanent cookies** are removed at a specific date (`Expires`) or after a specific length of time (`Max-Age`) and not when the client is closed.

```http
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT
```

```http
Set-Cookie: id=a3fWa; Max-Age=2592000
```

### Invalid domains

A cookie for a domain that does not include the server that set it should be rejected by the user agent.

The following cookie will be rejected if set by a server hosted on `originalcompany.com`:

```http
Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk
```

A cookie for a subdomain of the serving domain will be rejected.

The following cookie will be rejected if set by a server hosted on `example.com`:

```http
Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com
```

### Cookie prefixes

Cookie names prefixed with `__Secure-` or `__Host-` can be used only if they are set with the `secure` attribute from a secure (HTTPS) origin.

In addition, cookies with the `__Host-` prefix must have a path of `/` (meaning any path at the host) and must not have a `Domain` attribute.

**Warning:** For clients that don't implement cookie prefixes, you cannot count on these additional assurances, and prefixed cookies will always be accepted.

```http
// Both accepted when from a secure origin (HTTPS)
Set-Cookie: \_\_Secure-ID=123; Secure; Domain=example.com
Set-Cookie: \_\_Host-ID=123; Secure; Path=/

// Rejected due to missing Secure attribute
Set-Cookie: \_\_Secure-id=1

// Rejected due to the missing Path=/ attribute
Set-Cookie: \_\_Host-id=1; Secure

// Rejected due to setting a Domain
Set-Cookie: \_\_Host-id=1; Secure; Path=/; Domain=example.com
```

### Partitioned cookie

```http
Set-Cookie: \_\_Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;
```

**Note:** Partitioned cookies must be set with `Secure`. In addition, it is recommended to use the `__Host` prefix when setting partitioned cookies to make them bound to the hostname and not the registrable domain.

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

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

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

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

### Compatibility notes

* Starting with Chrome 52 and Firefox 52, insecure sites (`http:`) can't set cookies with the `Secure` attribute anymore.
See also
--------

* HTTP cookies
* `Cookie`
* `Document.cookie`
* Samesite cookies explained (web.dev blog)


Max-Forwards - HTTP

Max-Forwards
============

The **`Max-Forwards`** request HTTP header is used with the `TRACE` method to limit the number of nodes (usually proxies) that request goes through. Its value is an integer value indicating the *maximum amount* of nodes it must visit. At each node, the value is decremented and the `TRACE` request is forwarded to the next node, until the destination is reached, or the received value of `Max-Forwards` is zero. The request is then sent back, except for some headers, as the body of a `200 OK` response.

If the `Max-Forwards` header is not present in a `TRACE` request, a node will assume that there is no maximum number of forwards.

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

Syntax
------

```http
Max-Forwards: <integer>
```

Examples
--------

```http
Max-Forwards: 0
Max-Forwards: 10
```

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

| Specification |
| --- |
| HTTP Semantics # field.max-forwards |

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

This feature is neither targeted at, nor implemented in, browsers.

See also
--------

* The HTTP `TRACE` method


Sec-GPC - HTTP

Sec-GPC
=======

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

**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 **`Sec-GPC`** (**G**lobal **P**rivacy **C**ontrol) request header indicates whether the user consents to a website or service selling or sharing their personal information with third parties.

 The specification does not define how the user can withdraw or grant consent for website.
 Where possible the mechanism will be indicated in the browser compatibility section below.

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

Syntax
------

```http
Sec-GPC: 1
```

Directives
----------

The `Sec-GPC` is header is sent with a value of `1` if the user has indicated that they prefer their information not be shared with, or sold to, third parties.

Otherwise, the header is not sent, which indicates that either the user has not made a decision or the user is okay with their information being shared with or sold to third parties.

Examples
--------

### Reading Global Privacy Control status from JavaScript

The user's GPC preference can also be read from JavaScript using the `Navigator.globalPrivacyControl` or `WorkerNavigator.globalPrivacyControl` property:

```js
navigator.globalPrivacyControl; // "false" or "true"
```

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

| Specification |
| --- |
| Global Privacy Control (GPC)  |

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

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

See also
--------

* `Navigator.globalPrivacyControl`
* `DNT` header
* `Tk` header
* globalprivacycontrol.org
* Global Privacy Control Spec
* Do Not Track on Wikipedia


Content-Disposition - HTTP

Content-Disposition
===================

In a regular HTTP response, the **`Content-Disposition`** response header is a header indicating if the content is expected to be displayed *inline* in the browser, that is, as a Web page or as part of a Web page, or as an *attachment*, that is downloaded and saved locally.

In a `multipart/form-data` body, the HTTP **`Content-Disposition`** general header is a header that must be used on each subpart of a multipart body to give information about the field it applies to. The subpart is delimited by the *boundary* defined in the `Content-Type` header. Used on the body itself, `Content-Disposition` has no effect.

The `Content-Disposition` header is defined in the larger context of MIME messages for email, but only a subset of the possible parameters apply to HTTP forms and `POST` requests. Only the value `form-data`, as well as the optional directive `name` and `filename`, can be used in the HTTP context.

|  |  |
| --- | --- |
| Header type | Response header (for the main body),Request header,
 Response header (for a subpart of a multipart
 body)
  |
| Forbidden header name | no |

Syntax
------

### As a response header for the main body

The first parameter in the HTTP context is either `inline` (default value, indicating it can be displayed inside the Web page, or as the Web page) or `attachment` (indicating it should be downloaded; most browsers presenting a 'Save as' dialog, prefilled with the value of the `filename` parameters if present).

```http
Content-Disposition: inline
Content-Disposition: attachment
Content-Disposition: attachment; filename="filename.jpg"
```

**Note:** Chrome, and Firefox 82 and later, prioritize the HTML <a> element's `download` attribute over the `Content-Disposition: inline` parameter (for same-origin URLs). Earlier Firefox versions prioritize the header and will display the content inline.

### As a header for a multipart body

A `multipart/form-data` body requires a `Content-Disposition` header to provide information for each subpart of the form (e.g. for every form field and any files that are part of field data). The first directive is always `form-data`, and the header *must* also include a `name` parameter to identify the relevant field. Additional directives are case-insensitive and have arguments that use quoted-string syntax after the `'='` sign. Multiple parameters are separated by a semicolon (`';'`).

```http
Content-Disposition: form-data; name="fieldName"
Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"
```

### Directives

`name`

 Is followed by a string
 containing the name of the HTML field in the form
 that the content of this subpart refers to.
 When dealing with multiple files in the same field
 (for example, the `multiple` attribute of an `<input type="file">` element),
 there can be several subparts with the same name.

 A `name` with a value of `'_charset_'` indicates
 that the part is not an HTML field,
 but the default charset to use for parts without explicit charset information.

`filename`

Is followed by a string containing the original name of the file transmitted. The filename is always optional and must not be used blindly by the application: path information should be stripped, and conversion to the server file system rules should be done. This parameter provides mostly indicative information. When used in combination with `Content-Disposition: attachment`, it is used as the default filename for an eventual "Save As" dialog presented to the user.

`filename*`

The parameters `filename` and `filename*` differ only in that `filename*` uses the encoding defined in RFC 5987. When both `filename` and `filename*` are present in a single header field value, `filename*` is preferred over `filename` when both are understood.

**Warning:** The string following `filename` should always be put into quotes; but, for compatibility reasons, many browsers try to parse unquoted names that contain spaces.

Examples
--------

A response triggering the "Save As" dialog:

```http
200 OK
Content-Type: text/html; charset=utf-8
Content-Disposition: attachment; filename="cool.html"
Content-Length: 21

<HTML>Save me!</HTML>
```

This simple HTML file will be saved as a regular download rather than displayed in the browser. Most browsers will propose to save it under the `cool.html` filename (by default).

An example of an HTML form posted using the `multipart/form-data` format that makes use of the `Content-Disposition` header:

```http
POST /test.html HTTP/1.1
Host: example.org
Content-Type: multipart/form-data;boundary="boundary"

--boundary
Content-Disposition: form-data; name="field1"

value1
--boundary
Content-Disposition: form-data; name="field2"; filename="example.txt"

value2
--boundary--
```

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

| Specification |
| --- |
| Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) # header.field.definition |
| Returning Values from Forms: multipart/form-data # section-4.2 |

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

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

### Compatibility notes

* Firefox 5 handles the `Content-Disposition` HTTP response header more effectively if both the `filename` and `filename*` parameters are provided; it looks through all provided names, using the `filename*` parameter if one is available, even if a `filename` parameter is included first. Previously, the first matching parameter would be used, thereby preventing a more appropriate name from being used. See Firefox bug 588781.
* Firefox 82 (and later) and Chrome prioritize the HTML <a> element's `download` attribute over the `Content-Disposition: inline` parameter (for same-origin URLs). Earlier Firefox versions prioritize the header and will display the content inline.
See also
--------

* HTML Forms
* The `Content-Type` defining the boundary of the multipart body.
* The `FormData` interface used to prepare form data for use in the `fetch()` or `XMLHttpRequest` APIs.


DNT - HTTP

DNT
===

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

 The **`DNT`** (**D**o **N**ot
 **T**rack) request header indicates the user's tracking preference. It lets
 users indicate whether they would prefer privacy rather than personalized content.

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

Syntax
------

```http
DNT: 0
DNT: 1
DNT: null
```

Directives
----------

0

The user prefers to allow tracking on the target site.

1

The user prefers not to be tracked on the target site.

null

The user has not specified a preference about tracking.

Examples
--------

### Reading Do Not Track status from JavaScript

 The user's DNT preference can also be read from JavaScript using the
 `Navigator.doNotTrack` property:

```js
navigator.doNotTrack; // "0", "1" or null
```

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

#### No specification found

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

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

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

See also
--------

* `Navigator.doNotTrack`
* `Tk` header
* Do Not Track on Wikipedia
* What Does the "Track" in "Do Not Track" Mean? – EFF
* DNT on Electronic Frontier Foundation
* DNT browser settings help:
    + Firefox
    + Chrome


Age - HTTP

Age
===

The **`Age`** header contains the time in seconds the object was in a proxy cache.

 The `Age` header is usually close to zero. If it is `Age: 0`, it was probably fetched from the origin server; otherwise, it was usually calculated as
 a difference between the proxy's current date and the `Date` general header included in the HTTP response.

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

Syntax
------

```http
Age: <delta-seconds>
```

Directives
----------

<delta-seconds>

A non-negative integer that is time in seconds the object was in a proxy cache.

Examples
--------

```http
Age: 24
```

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

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

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

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

See also
--------

* `Cache-Control`
* `Expires`


Accept-Charset - HTTP

Accept-Charset
==============

**Warning:** Do not use this header. Browsers omit this header and servers should ignore it.

The **`Accept-Charset`** request HTTP header was a header that advertised a client's supported character encodings. It is no longer widely used.

UTF-8 is well-supported and the overwhelmingly preferred choice for character encoding. To guarantee better privacy through less configuration-based entropy, all browsers omit the `Accept-Charset` header.

Today, `Accept-Charset` is most notable for being one of several forbidden header names.

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

See also
--------

* HTTP content negotiation
* Accept-Charset is no more
* Header with the result of the content negotiation: `Content-Type`
* Other similar headers: `TE`, `Accept-Encoding`, `Accept-Language`, `Accept`


Content-Location - HTTP

Content-Location
================

 The **`Content-Location`** header indicates an alternate
 location for the returned data. The principal use is to indicate the URL of a resource
 transmitted as the result of content negotiation.

`Location` and `Content-Location` are different.
 `Location` indicates the URL of a redirect, while
 `Content-Location` indicates the direct URL to use to access the resource,
 without further content negotiation in the future. `Location` is a header
 associated with the response, while `Content-Location` is associated with the
 data returned. This distinction may seem abstract without examples.

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

Syntax
------

```http
Content-Location: <url>
```

Directives
----------

<url>

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

Examples
--------

### Requesting data from a server in different formats

 Let's say a site's API can return data in JSON, XML, or
 CSV formats. If the URL for a particular document
 is at `https://example.com/documents/foo`, the site could return different
 URLs for `Content-Location` depending on the request's
 `Accept` header:

| Request header | Response header |
| --- | --- |
| `Accept: application/json, text/json` | `Content-Location: /documents/foo.json` |
| `Accept: application/xml, text/xml` | `Content-Location: /documents/foo.xml` |
| `Accept: text/plain, text/*` | `Content-Location: /documents/foo.txt` |

 These URLs are examples — the site could serve the different filetypes with any URL
 patterns it wishes, such as a query string parameter: `/documents/foo?format=json`,
 `/documents/foo?format=xml`, and so on.

 Then the client could remember that the JSON version is available at that particular
 URL, skipping content negotiation the next time it requests that document.

 The server could also consider other content negotiation headers, such
 as `Accept-Language`.

### Pointing to a new document (HTTP 201 Created)

Say you're creating a new blog post through a site's API:

```http
POST /new/post
Host: example.com
Content-Type: text/markdown

# My first blog post!

I made this through `example.com`'s API. I hope it worked.
```

The site returns the published post in the response body. The server specifies *where* the new post is with the `Content-Location` header, indicating that this location refers to the content (the body) of this response:

```http
HTTP/1.1 201 Created
Content-Type: text/markdown
Content-Location: /my-first-blog-post

# My first blog post

I made this through `example.com`'s API. I hope it worked.
```

### Indicating the URL of a transaction's result

 Say you have a
 `<form>` for sending
 money to another user of a site.

```html
<form action="/send-payment" method="post">
  <p>
    <label
 >Who do you want to send the money to?
      <input type="text" name="recipient" />
    </label>
  </p>

  <p>
    <label
 >How much?
      <input type="number" name="amount" />
    </label>
  </p>

  <button type="submit">Send Money</button>
</form>
```

 When the form is submitted, the site generates a receipt for the transaction. The
 server could use `Content-Location` to indicate that receipt's URL for future
 access.

```http
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Location: /my-receipts/38

<!doctype html>
(Lots of HTML…)

<p>You sent $38.00 to ExampleUser.</p>

(Lots more HTML…)
```

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

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

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

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

See also
--------

* `Location`


DPR - HTTP

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 **`DPR`** device client hint request header provides the client device pixel ratio. This ratio is the number of physical device pixels corresponding to every CSS pixel.

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

The hint is useful when selecting image sources that best correspond to a screen's pixel density. This is similar to the role played by `x` descriptors in the `<img>` `srcset` attribute to allow user agents to select a preferred image.

If a server uses the `DPR` hint to choose which resource is sent in a response, the response must include the `Content-DPR` header. The client must use the value in `Content-DPR` for layout if it differs from the value in the request's `DPR` header.

If the `DPR` 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 `DPR` header from the client, by sending the `Accept-CH` response header.
* Servers that opt in to the `DPR` 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.
* `DPR` was removed from the client hints specification in draft-ietf-httpbis-client-hints-07. The proposed replacement is `Sec-CH-DPR` (Responsive Image Client Hints).

Syntax
------

```http
DPR: <number>
```

Directives
----------

`<number>`

The client device pixel ratio.

Examples
--------

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

```http
Accept-CH: DPR
```

Then on subsequent requests the client might send `DPR` header to the server:

```http
DPR: 2.0
```

If a request with the `DPR` header (as shown above) is for an image resource, then the server response must include the `Content-DPR` header:

```http
Content-DPR: 2.0
```

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`
    + `Viewport-Width`
    + `Width`
* `Accept-CH`
* HTTP Caching > Vary and `Vary`


Cross-Origin-Embedder-Policy - HTTP

Cross-Origin-Embedder-Policy
============================

 The HTTP **`Cross-Origin-Embedder-Policy`** (COEP) response header configures
 embedding cross-origin resources into the document.

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

Syntax
------

```http
Cross-Origin-Embedder-Policy: unsafe-none | require-corp | credentialless
```

### Directives

`unsafe-none`

This is the default value. Allows the document to fetch cross-origin resources without giving explicit permission through the CORS protocol or the `Cross-Origin-Resource-Policy` header.

`require-corp`

 A document can only load resources from the same origin, or resources explicitly marked as loadable from another origin.
 If a cross origin resource supports CORS, the `crossorigin` attribute or the `Cross-Origin-Resource-Policy` header must be used to load it without being blocked by COEP.

`credentialless`

no-cors cross-origin requests are sent without credentials. In particular, it means Cookies are omitted from the request, and ignored from the response. The responses are allowed **without** an explicit permission via the `Cross-Origin-Resource-Policy` header. Navigate responses behave similarly as the `require-corp` mode: They require `Cross-Origin-Resource-Policy` response header.

Examples
--------

### Certain features depend on cross-origin isolation

You can only access certain features like `SharedArrayBuffer` objects or `Performance.now()` with unthrottled timers, if your document has a COEP header with a value of `require-corp` or `credentialless` set.

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

See also the `Cross-Origin-Opener-Policy` header which you'll need to set as well.

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

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

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

### Avoiding COEP blockage with CORS

If you enable COEP using `require-corp` and have a cross origin resource that needs to be loaded, it needs to support CORS and you need to explicitly mark the resource as loadable from another origin to avoid blockage from COEP. For example, you can use the `crossorigin` attribute for this image from a third-party site:

```html
<img src="https://thirdparty.com/img.png" crossorigin />
```

If CORS is not supported for some images, a COEP value of `credentialless` can be used as an alternative to load the image without any explicit opt-in from the cross-origin server, at the cost of requesting it without cookies.

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

| Specification |
| --- |
| HTML Standard # coep |

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

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

See also
--------

* `Cross-Origin-Opener-Policy`


Content-Type - HTTP

Content-Type
============

The **`Content-Type`** representation header is used to indicate the original media type of the resource (prior to any content encoding applied for sending).

In responses, a `Content-Type` header provides the client with the actual content type of the returned content. This header's value may be ignored, for example when browsers perform MIME sniffing; set the `X-Content-Type-Options` header value to `nosniff` to prevent this behavior.

In requests, (such as `POST` or `PUT`), the client tells the server what type of data is actually sent.

|  |  |
| --- | --- |
| 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't contain a
 *CORS-unsafe request header byte*: 0x00-0x1F (except 0x09 (HT)),
 `"():<>?@[\]{}`, and 0x7F (DEL).It also needs to
 have a MIME type of its parsed value (ignoring parameters) of either
 `application/x-www-form-urlencoded`,
 `multipart/form-data`, or `text/plain`.
  |

Syntax
------

```http
Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something
```

Directives
----------

`media-type`

The MIME type of the resource or the data.

charset

The character encoding standard. Case insensitive, lowercase is preferred.

boundary

For multipart entities the `boundary` directive is required. The directive consists of 1 to 70 characters from a set of characters (and not ending with white space) known to be very robust through email gateways. It is used to encapsulate the boundaries of the multiple parts of the message. Often, the header boundary is prepended with two dashes and the final boundary has two dashes appended at the end.

Examples
--------

### `Content-Type` in HTML forms

In a `POST` request, resulting from an HTML form submission, the `Content-Type` of the request is specified by the `enctype` attribute on the `<form>` element.

```html
<form action="/" method="post" enctype="multipart/form-data">
  <input type="text" name="description" value="some text" />
  <input type="file" name="myFile" />
  <button type="submit">Submit</button>
</form>
```

The request looks something like this (less interesting headers are omitted here):

```http
POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575

-----------------------------974767299852498929531610575
Content-Disposition: form-data; name="description"

some text
-----------------------------974767299852498929531610575
Content-Disposition: form-data; name="myFile"; filename="foo.txt"
Content-Type: text/plain

(content of the uploaded file foo.txt)
-----------------------------974767299852498929531610575--
```

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

| Specification |
| --- |
| HTTP Semantics # status.206 |
| HTTP Semantics # field.content-type |

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

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

See also
--------

* `Accept`
* `Content-Disposition`
* `206` Partial Content
* `X-Content-Type-Options`


Accept-CH - HTTP

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

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

 The **`Accept-CH`** header may be set by a server to specify
 which client hints headers a 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: <comma separated list of client hint headers>
```

Examples
--------

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

**Note:** Remember to vary the response
 based on the accepted client hints.

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

| Specification |
| --- |
| HTTP Client Hints # section-3.1 |

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

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

See also
--------

* `Vary`


Access-Control-Allow-Credentials - HTTP

Access-Control-Allow-Credentials
================================

The **`Access-Control-Allow-Credentials`** response header tells browsers whether the server allows cross-origin HTTP requests to include credentials.

Credentials are cookies, TLS client certificates, or authentication headers containing a username and password. By default, these credentials are not sent in cross-origin requests, and doing so can make a site vulnerable to CSRF attacks.

A client can ask that credentials should be included in cross-site requests in one of two ways:

* Using `fetch()`, by setting the `credentials` option in the `Request()` constructor to `"include"`.
* Using `XMLHttpRequest`, by setting the `XMLHttpRequest.withCredentials` property to `true`.

If the client has asked for credentials to be included:

* If the request is preflighted, then the preflight request does not include credentials. If the server's response to the preflight request sets the `Access-Control-Allow-Credentials` header to `true`, then the real request will include credentials: otherwise, the browser reports a network error.
* If the request is not preflighted, then the request will include credentials, and if the server's response does not set the `Access-Control-Allow-Credentials` header to `true`, the browser reports a network error.

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

Syntax
------

```http
Access-Control-Allow-Credentials: true
```

Directives
----------

`true`

 The only valid value for this header is `true` (case-sensitive). If you
 don't need credentials, omit this header entirely (rather than setting its value to
 `false`).

Examples
--------

Allow credentials:

```http
Access-Control-Allow-Credentials: true
```

Using `fetch()` with credentials:

```js
fetch(url, {
  credentials: "include",
});
```

Using `XMLHttpRequest` with credentials:

```js
const xhr = new XMLHttpRequest();
xhr.open("GET", "http://example.com/", true);
xhr.withCredentials = true;
xhr.send(null);
```

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

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

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

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

See also
--------

* `XMLHttpRequest.withCredentials`
* `Request()`


User-Agent - HTTP

User-Agent
==========

The **User-Agent** request header is a characteristic string that lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting user agent.

**Warning:** Please read Browser detection using the user agent for why serving different Web pages or services to different browsers is usually a bad idea.

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

Syntax
------

```http
User-Agent: <product> / <product-version> <comment>
```

Common format for web browsers:

```http
User-Agent: Mozilla/5.0 (<system-information>) <platform> (<platform-details>) <extensions>
```

### Directives

<product>

A product identifier — its name or development codename.

<product-version>

Version number of the product.

<comment>

Zero or more comments containing more details. For example, sub-product information.

Firefox UA string
-----------------

For more on Firefox- and Gecko-based user agent strings, see the Firefox user agent string reference. The UA string of Firefox is broken down into 4 components:
```

Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefoxversion
```

1. `Mozilla/5.0` is the general token that says that the browser is Mozilla-compatible. For historical reasons, almost every browser today sends it.
2. ***platform*** describes the native platform that the browser is running on (Windows, Mac, Linux, Android, etc.) and if it is a mobile phone. Firefox OS phones say `Mobile` — the web is the platform. Note that ***platform*** can consist of multiple "`;`"-separated tokens. See below for further details and examples.
3. **rv:*geckoversion*** indicates the release version of Gecko (such as "*17.0*"). In recent browsers, ***geckoversion*** is the same as ***firefoxversion***.
4. ***Gecko/geckotrail*** indicates that the browser is based on Gecko. (On the desktop, ***geckotrail*** is always the fixed string `20100101`.)
5. ***Firefox/firefoxversion*** indicates that the browser is Firefox and provides the version (such as "*17.0"*).
### Examples
```

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Mozilla/5.0 (Macintosh; Intel Mac OS X x.y; rv:42.0) Gecko/20100101 Firefox/42.0
```

Chrome UA string
----------------

The Chrome (or Chromium/Blink-based engines) user agent string is similar to Firefox's. For compatibility, it adds strings like `KHTML, like Gecko` and `Safari`.

### Examples
```

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
```

Opera UA string
---------------

The Opera browser is also based on the Blink engine, which is why it almost looks the same as the Chrome UA string, but adds `"OPR/<version>"`.

### Examples
```

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 OPR/38.0.2220.41
```

Older, Presto-based Opera releases used:
```

Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.15 Version/10.00
Opera/9.60 (Windows NT 6.0; U; en) Presto/2.1.1
```

Microsoft Edge UA string
------------------------

The Edge browser is also based on the Blink engine. It adds `"Edg/<version>"`.

### Examples
```

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 Edg/91.0.864.59
```

Safari UA string
----------------

In this example, the user agent string is mobile Safari's version. It contains the word `"Mobile"`.

### Examples
```

Mozilla/5.0 (iPhone; CPU iPhone OS 13_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Mobile/15E148 Safari/604.1
```

Crawler and bot UA strings
--------------------------

### Examples
```

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
```

```
Mozilla/5.0 (compatible; YandexAccessibilityBot/3.0; +http://yandex.com/bots)
```

Library and net tool UA strings
-------------------------------

### Examples
```

curl/7.64.1
```

```
PostmanRuntime/7.26.5
```

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

| Specification |
| --- |
| HTTP Semantics # field.user-agent |

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

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

See also
--------

* User-Agent detection, history and checklist
* Firefox user agent string reference
* Browser detection using the user agent
* Client hints


Tk - HTTP

Tk
==

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

 The **`Tk`** response header indicates the tracking status that
 applied to the corresponding request.

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

Syntax
------

```http
Tk: ! (under construction)
Tk: ? (dynamic)
Tk: G (gateway or multiple parties)
Tk: N (not tracking)
Tk: T (tracking)
Tk: C (tracking with consent)
Tk: P (potential consent)
Tk: D (disregarding DNT)
Tk: U (updated)
```

### Directives

!

 Under construction. The origin server is currently testing its communication of
 tracking status.

?

Dynamic. The origin server needs more information to determine tracking status.

G

 Gateway or multiple parties. The server is acting as a gateway to an exchange
 involving multiple parties.

N

Not tracking.

T

Tracking.

C

 Tracking with consent. The origin server believes it has received prior consent for
 tracking this user, user agent, or device.

P

 Potential consent. The origin server does not know, in real-time, whether it has
 received prior consent for tracking this user, user agent, or device, but promises not
 to use or share any `DNT:1` data until such consent has been determined,
 and further promises to delete or permanently de-identify within 48 hours any
 `DNT:1` data received for which such consent has not been received.

D

 Disregarding DNT. The origin server is unable or unwilling to respect a tracking
 preference received from the requesting user agent.

U

 Updated. The request resulted in a potential change to the tracking status
 applicable to this user, user agent, or device.

Examples
--------

A `Tk` header for a resource that claims not to be tracking would look like:

```http
Tk: N
```

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

#### No specification found

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

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

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

See also
--------

* `DNT` header
* `Navigator.doNotTrack`