recursal/MDN huggingface dataset:
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`
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`
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
================================

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()`
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`
Server-Timing
=============

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

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

Syntax
------

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

See also
--------

* `PerformanceServerTiming`
Sec-CH-UA-Mobile
================

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

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

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

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


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

Syntax
------


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

### Directives

`<boolean>`

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


Examples
--------

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

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


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


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


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

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

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

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

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

See also
--------

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

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

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

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

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

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


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

Syntax
------


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

Directives
----------

`<digest-algorithm>`

Digest algorithms are defined in Digest Headers.

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

`<digest-value>`

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


Examples
--------


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

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

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

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

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

See also
--------

* `Want-Digest`
* HTTP range requests
* `206 Partial Content`
Access-Control-Expose-Headers
=============================

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

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

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

Syntax
------


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

Directives
----------

<header-name>

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

`*` (wildcard)

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


Examples
--------

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


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


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


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


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


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


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

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

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

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

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

See also
--------

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Origin`
X-Content-Type-Options
======================

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

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

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

Site security testers usually expect this header to be set.

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



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

Syntax
------


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

Directives
----------

`nosniff`

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


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

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

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

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

### Browser specific notes

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

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

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

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

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

Syntax
------

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


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

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

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

See also
--------

* Network Error Logging (NEL) explainer