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

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

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

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

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

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

Syntax
------


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

Directives
----------

`<bitness>`

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

Examples
--------

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


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


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


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

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

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

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

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

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

See also
--------

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

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

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

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

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

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

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


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

Syntax
------


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

Directives
----------

There is only one defined expectation:

`100-continue`

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


Examples
--------

### Large message body

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


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


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

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

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

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

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

See also
--------

* `417 Expectation Failed`
* `100 Continue`
Access-Control-Request-Method
=============================

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


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

Syntax
------


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

Directives
----------

<method>

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


Examples
--------


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

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

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

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

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

See also
--------

* `Access-Control-Request-Headers`
Pragma
======

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

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


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



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

Syntax
------


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

Directives
----------

no-cache

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


Examples
--------


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

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

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

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

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

See also
--------

* `Cache-Control`
* `Expires`
Critical-CH
===========

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

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

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

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

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

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

Syntax
------


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

### Directives

`<ch-list>`

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

Examples
--------

The client makes an initial request to the server:


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


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


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


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


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


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


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

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

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

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

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

See also
--------

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

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


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

Syntax
------


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

Directives
----------

<unit>

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

<range-start>

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

<range-end>

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

<size>

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

Examples
--------


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

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

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

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

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

See also
--------

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

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

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

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

Syntax
------


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

Directives
----------

<day-name>

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

<day>

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

<month>

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


<year>

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

<hour>

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

<minute>

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

<second>

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

`GMT`

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

Examples
--------


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

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

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

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

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

See also
--------

* `If-Modified-Since`
* `If-Unmodified-Since`
* `Etag`
If-None-Match
=============

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

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

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

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

There are two common use cases:

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

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

Syntax
------


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

Directives
----------

<etag\_value>

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

`*`

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

Examples
--------


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

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

If-None-Match: \*
```

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

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

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

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

See also
--------

* `ETag`
* `If-Unmodified-Since`
* `If-Modified-Since`
* `If-Match`
* `304 Not Modified`
* `412 Precondition Failed`
Timing-Allow-Origin
===================

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

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

Syntax
------


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

Directives
----------

`*`

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

<origin>

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

Examples
--------

To allow any resource to see timing resources:


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


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


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

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

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

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

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

See also
--------

* Resource Timing API
* `Vary`
Cookie
======

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

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

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

Syntax
------


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

Directives
----------

<cookie-list>

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

Examples
--------


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

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

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

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

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

See also
--------

* `Set-Cookie`
* `Document.cookie`
Alt-Svc
=======

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

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

Syntax
------


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


`clear`

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

`<protocol-id>`

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

`<alt-authority>`

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

`ma=<max-age>` Optional

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


`persist=1` Optional

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



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

Example
-------


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

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

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

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

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

See also
--------

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

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

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

Syntax
------


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

Directives
----------

<length>

The length in decimal number of octets.

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

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

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

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

See also
--------

* `Transfer-Encoding`