recursal/MDN huggingface dataset:
Sec-CH-UA-Platform
==================

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

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

 The **`Sec-CH-UA-Platform`** user agent client hint request header provides the platform or operating system on which the user agent is running.
 For example: "Windows" or "Android".

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


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

Syntax
------


```http
Sec-CH-UA-Platform: <platform>
```

### Directives

`<platform>`

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

Examples
--------

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

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


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

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

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

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

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

See also
--------

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

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

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

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


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

Syntax
------


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

Examples
--------


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

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

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

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

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

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

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

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


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

Syntax
------


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

Directives
----------

<host>

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

<port> Optional

TCP port number on which the server is listening.

Examples
--------


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

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

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

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

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

See also
--------

* `400`
* `<base>`
Keep-Alive
==========

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

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


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



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

Syntax
------


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

Directives
----------

`parameters`

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

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

Examples
--------

A response containing a `Keep-Alive` header:


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

(body)
```

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

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

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

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

See also
--------

* `Connection`
* Connection management in HTTP/1.x
Upgrade-Insecure-Requests
=========================

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

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

Syntax
------


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

Examples
--------

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


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


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


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

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

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

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

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

See also
--------

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

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

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

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

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

Syntax
------


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

Directives
----------

`language-tag`

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


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

Examples
--------

### Indicating the language a document is written in

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


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


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


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

### Indicating a target audience for a resource

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


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

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

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

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

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

See also
--------

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

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

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

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

Syntax
------


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

Directives
----------

<http-methods>

The comma-separated list of allowed HTTP request methods.

Examples
--------


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

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

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

See also
--------

* `405`
* `Server`
Link
====

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

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

Syntax
------


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


`<uri-reference>`

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

### Parameters

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

Examples
--------

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


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



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

### Encoding URLs

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


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



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

### Specifying multiple links

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


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

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

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

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

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

See also
--------

* `103 Early Hints`
* `<link>`
Cross-Origin-Resource-Policy
============================

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


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

Syntax
------


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

Examples
--------

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


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


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

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

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

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

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

See also
--------

* Cross-Origin Resource Policy (CORP) explainer
* Consider deploying Cross-Origin Resource Policy
* `Access-Control-Allow-Origin`
Sec-CH-UA-Full-Version
======================

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

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

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

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

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

Syntax
------


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

### Directives

`<version>`

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

Examples
--------

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


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


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


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

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

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

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

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

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

See also
--------

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

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

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

Syntax
------


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

Directives
----------

<delta-seconds>

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


Examples
--------

Cache results of a preflight request for 10 minutes:


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

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

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

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

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

See also
--------

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Methods`
Accept-CH-Lifetime
==================

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

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

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

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

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


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

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


Syntax
------


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

Examples
--------


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

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

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

See also
--------

* `Accept-CH`
* `Vary`
SourceMap
=========

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

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

Syntax
------


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

### Directives

<url>

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

Examples
--------


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

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

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

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

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

See also
--------

* Firefox Developer Tools: using a source map
Accept-Ranges
=============

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

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


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

Syntax
------


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

Directives
----------

`<range-unit>`

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


`none`

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


Examples
--------


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

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

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

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

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

See also
--------

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

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

The **`RTT`** Client hint request header field provides the approximate round trip time on the application layer, in milliseconds. The RTT hint, unlike transport layer RTT, includes server processing time.

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

The RTT value is rounded to the nearest 25 milliseconds to prevent fingerprinting. There are many other mechanisms an attacker might use to obtain similar round-trip information.

The hint allows a server to choose what information is sent based on the network responsiveness/latency. For example, it might choose to send fewer resources.

**Note:** The `Vary` header is used in responses to indicate that a different resource is sent for every different value of the header (see HTTP Caching Vary). Even if `RTT` is used to configure what resources are sent consider omitting it in the `Vary` header — it is likely to change often, which effectively makes the resource uncacheable.

Syntax
------


```http
RTT: <number>
```

Directives
----------

<number>

The approximate round trip time in milliseconds, rounded to the nearest 25 milliseconds.

Examples
--------

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


```http
Accept-CH: RTT
```


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


```http
RTT: 125
```

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

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

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

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

See also
--------

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