recursal/MDN huggingface dataset:
Accept-Post
===========

The **`Accept-Post`** response HTTP header advertises which media types are accepted by the server for HTTP post requests.

**`Accept-Post`** in response to any method means that `POST` is allowed on the requested resource (any document/media format in the header further indicates that the document format is allowed).

For example, a server receiving a `POST` request with an unsupported media type could reply with `415` `Unsupported Media Type` and an **`Accept-Post`** header referencing one or more supported media types.

**Note:** An IANA registry maintains a complete list of official content encodings.


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

Syntax
------


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


**Note:** The `Accept-Post` header specifies a media range in the same way as `Accept`, except that it has no notion of preference (i.e., no `q` arguments). This is because `Accept-Post` is a response header while `Accept` is a request header.

Directives
----------

None.

Examples
--------


```http
Accept-Post: application/example, text/example
Accept-Post: image/webp
Accept-Post: \*/\*
```

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

| Specification |
| --- |
| Linked Data Platform # header-accept-post |

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

Browser compatibility is not relevant for this header (header is sent by server, and the specification does not define client behavior).

See also
--------

* Http method `POST`
* HTTP Semantic and context RFC 7231, section 4.3.3: POST
Downlink
========

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

The **`Downlink`** Client hint request header field provides the approximate bandwidth of the client's connection to the server, in Mbps.

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

The `Downlink` value is given in Mbps and rounded to the nearest 25 kilobits per second to prevent fingerprinting. There are many other mechanisms an attacker might use to obtain similar information.

The hint allows a server to choose what information is sent based on the network bandwidth. For example, a server might choose to send smaller versions of images and other resources on low bandwidth networks.

**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 `Downlink` 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
Downlink: <number>
```

Directives
----------

<number>

The downlink rate in Mbps, rounded to the nearest 25 kilobits.

Examples
--------

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


```http
Accept-CH: Downlink
```


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


```http
Downlink: 1.7
```

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

| Specification |
| --- |
| Network Information API # downlink-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
    + `RTT`
    + `ECT`
    + `Save-Data`
* `Accept-CH`
* HTTP Caching > Vary and `Vary`
* `NetworkInformation.effectiveType`
Content-Encoding
================

 The **`Content-Encoding`** representation header lists any encodings that have been applied to the representation (message payload), and in what order.
 This lets the recipient know how to decode the representation in order to obtain the original payload format.
 Content encoding is mainly used to compress the message data without losing information about the origin media type.

Note that the original media/content type is specified in the `Content-Type` header, and that the `Content-Encoding` applies to the representation, or "coded form", of the data. If the original media is encoded in some way (e.g. a zip file) then this information would not be included in the `Content-Encoding` header.

Servers are encouraged to compress data as much as possible, and should use content encoding where appropriate. Compressing a compressed media type such as a zip or jpeg may not be appropriate, as this can make the payload larger.

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

Syntax
------


```http
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: br

// Multiple, in the order in which they were applied
Content-Encoding: deflate, gzip
```

Directives
----------

`gzip`

 A format using the Lempel-Ziv coding
 (LZ77), with a 32-bit CRC. This is the original format of the UNIX *gzip*
 program. The HTTP/1.1 standard also recommends that the servers supporting this
 content-encoding should recognize `x-gzip` as an alias, for compatibility
 purposes.


`compress`

 A format using the Lempel-Ziv-Welch (LZW) algorithm. The
 value name was taken from the UNIX *compress* program, which implemented this
 algorithm. Like the compress program, which has disappeared from most UNIX
 distributions, this content-encoding is not used by many browsers today, partly
 because of a patent issue (it expired in 2003).


`deflate`

 Using the zlib
 structure (defined in RFC 1950) with the deflate compression
 algorithm (defined in RFC 1951).


`br` 
Non-standard

A format using the Brotli algorithm.

Examples
--------

### Compressing with gzip

 On the client side, you can advertise a list of compression schemes that will be sent
 along in an HTTP request. The `Accept-Encoding` header is used for
 negotiating content encoding.


```http
Accept-Encoding: gzip, deflate
```


 The server responds with the scheme used, indicated by the
 `Content-Encoding` response header.


```http
Content-Encoding: gzip
```


 Note that the server is not obligated to use any compression method. Compression highly
 depends on server settings and used server modules.

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

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

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

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

See also
--------

* `Accept-Encoding`
* `Transfer-Encoding`
If-Modified-Since
=================

 The **`If-Modified-Since`** request HTTP header makes the
 request conditional: the server sends back the requested resource, with a
 `200` status, only if it has been last modified after the given date. If
 the resource has not been modified since, the response is a `304`
 without any body; the `Last-Modified` response header of a previous
 request contains the date of last modification. Unlike
 `If-Unmodified-Since`, `If-Modified-Since` can only be used
 with a `GET` or `HEAD`.

 When used in combination with `If-None-Match`, it is ignored, unless
 the server doesn't support `If-None-Match`.

 The most common use case is to update a cached entity that has no associated
 `ETag`.


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

Syntax
------


```http
If-Modified-Since: <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
If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
```

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

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

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

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

See also
--------

* `ETag`
* `If-Unmodified-since`
* `If-Match`
* `If-None-Match`
* `304 Not Modified`
Sec-CH-UA-Model
===============

**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-Model`** user agent client hint request header indicates the device model on which the browser is running.

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

Syntax
------


```http
Sec-CH-UA-Model: <device-version>
```

### Directives

`<device-version>`

A string containing the device version. For example "Pixel 3".

Examples
--------

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


 The client may choose to provide the hint, and add the `Sec-CH-UA-Model` header to subsequent requests.
 For example, on mobile phone 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: ?1
Sec-CH-UA-Platform: "Android"
Sec-CH-UA-Bitness: "64"
Sec-CH-UA-Model: "Pixel 3 XL"
```

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

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

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`
Save-Data
=========

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

 The **`Save-Data`** network client hint request header field is a boolean which indicates the client's preference for reduced data usage.
 This could be for reasons such as high transfer costs, slow connection speeds, etc.

**`Save-Data`** is a low entropy hint, and hence may be sent by the client even if not requested by the server using an `Accept-CH` response header.
 Further, it should be used to reduce data sent to the client irrespective of the values of other client hints that indicate network capability, like `Downlink` and `RTT`.


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

 A value of `On` indicates explicit user opt-in into a reduced data usage
 mode on the client, and when communicated to origins allows them to deliver alternative
 content to reduce the data downloaded such as smaller image and video resources,
 different markup and styling, disabled polling and automatic updates, and so on.

**Note:** Disabling HTTP/2 Server Push (RFC 7540, section 8.2: Server Push) might be desirable too for reducing data downloads.

Syntax
------


```http
Save-Data: <sd-token>
```

Directives
----------

`<sd-token>`

 A value indicating whether the client wants to opt in to reduced data usage mode.
 `on` indicates yes, while `off` (the default) indicates no.


Examples
--------

 The `Vary` header ensures that the content is cached properly (for
 instance ensuring that the user is not served a lower-quality image from the cache when
 `Save-Data` header is no longer present [*e.g.* after having switched from cellular to Wi-Fi]).

### With `Save-Data: on`

Request:


```http
GET /image.jpg HTTP/1.1
Host: example.com
Save-Data: on
```


Response:


```http
HTTP/1.1 200 OK
Content-Length: 102832
Vary: Accept-Encoding, Save-Data
Cache-Control: public, max-age=31536000
Content-Type: image/jpeg

[…]
```

### Without `Save-Data`

Request:


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


Response:


```http
HTTP/1.1 200 OK
Content-Length: 481770
Vary: Accept-Encoding, Save-Data
Cache-Control: public, max-age=31536000
Content-Type: image/jpeg

[…]
```

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

| Specification |
| --- |
| Save Data API # save-data-request-header-field |

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

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

See also
--------

* Help Your Users `Save-Data` - CSS Tricks
* Delivering Fast and Light Applications with Save-Data - web.dev
* `Vary` header which indicates that the content served varies depending on the value of `Save-Data` (see HTTP Caching > Vary)
* CSS @media feature `prefers-reduced-data` 
Experimental
* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* `NetworkInformation.saveData`
Accept-Patch
============

The **`Accept-Patch`** response HTTP header advertises which media-type the server is able to understand in a PATCH request.

**`Accept-Patch`** in response to any method means that PATCH is allowed on the resource identified by the Request-URI. Two common cases lead to this:

A server receiving a PATCH request with an unsupported media type could reply with `415` `Unsupported Media Type` and an Accept-Patch header referencing one or more supported media types.

**Note:**

* An IANA registry maintains a complete list of official content encodings.
* Two others content encoding, `bzip` and `bzip2`, are sometimes used, though not standard. They implement the algorithm used by these two UNIX programs. Note that the first one was discontinued due to patent licensing problems.


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

Syntax
------


```http
Accept-Patch: application/example, text/example
Accept-Patch: text/example;charset=utf-8
Accept-Patch: application/merge-patch+json
```

Directives
----------

None

Examples
--------


```http
Accept-Patch: application/example, text/example

Accept-Patch: text/example;charset=utf-8

Accept-Patch: application/merge-patch+json
```

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

| Specification |
| --- |
| RFC 5789 # section-3.1 |

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

Browser compatibility is not relevant for this header (header is sent by server, and the specification does not define client behavior).

See also
--------

* Http method `PATCH`
* HTTP Semantic and context RFC 7231, section 4.3.4: PUT
Alt-Used
========

The `Alt-Used` HTTP header is used in requests to identify the alternative service in use, just as the `Host` HTTP header field identifies the host and port of the origin.

The is intended to allow alternative services to detect loops, differentiate traffic for purposes of load balancing, and generally to ensure that it is possible to identify the intended destination of traffic, since introducing this information after a protocol is in use has proven to be problematic.

When a client uses an alternative service for a request, it can indicate this to the server using the `Alt-Used` HTTP header.

Syntax
------


```http
Alt-Used: <host>:<port>
```

Directives
----------

<host>

the domain name of the server.

<port> Optional

TCP port number on which the server is listening.

Examples
--------


```http
Alt-Used: alternate.example.net
```

See also
--------

* `Alt-Svc`
* `Host`
Date
====

 The **`Date`** general HTTP header contains the date and time
 at which the message originated.


**Warning:** `Date` is listed
 in the forbidden header names
 in the fetch spec, so this code will not send the `Date` header:



```js
fetch("https://httpbin.org/get", {
  headers: {
    Date: new Date().toUTCString(),
  },
});
```


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

Syntax
------


```http
Date: <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
Date: Wed, 21 Oct 2015 07:28:00 GMT
```

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

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

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

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

See also
--------

* `Age`
Access-Control-Allow-Methods
============================

 The **`Access-Control-Allow-Methods`** response header
 specifies one or more methods allowed when accessing a resource in response to a
 preflight request.


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

Syntax
------


```http
Access-Control-Allow-Methods: <method>, <method>, …
Access-Control-Allow-Methods: \*
```

Directives
----------

<method>

A comma-delimited list of the allowed HTTP request methods.

`*` (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 method name "`*`" without special semantics.


Examples
--------


```http
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Methods: \*
```

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

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

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

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

See also
--------

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers`
* `Access-Control-Allow-Headers`
* `Access-Control-Request-Method`
X-Forwarded-Proto
=================

 The **`X-Forwarded-Proto`** (XFP) header is a de-facto standard
 header for identifying the protocol (HTTP or HTTPS) that a client used to connect to
 your proxy or load balancer. Your server access logs contain the protocol used between
 the server and the load balancer, but not the protocol used between the client and the
 load balancer. To determine the protocol used between the client and the load balancer,
 the `X-Forwarded-Proto` request header can be used.

A standardized version of this header is the HTTP `Forwarded` header.

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

Syntax
------


```http
X-Forwarded-Proto: <protocol>
```

Directives
----------

<protocol>

The forwarded protocol (http or https).

Examples
--------


```http
X-Forwarded-Proto: https
```


Other non-standard forms:


```http
# Microsoft
Front-End-Https: on

X-Forwarded-Protocol: https
X-Forwarded-Ssl: on
X-Url-Scheme: https
```

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

 Not part of any current specification. The standardized version of this header is
 `Forwarded`.

See also
--------

* `Forwarded`
* `X-Forwarded-For`
* `X-Forwarded-Host`
Device-Memory
=============

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

The **`Device-Memory`** device client hint request header field indicates the approximate amount of available RAM on the client device. The header is part of the Device Memory API.

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

**Note:**

* Client Hints are accessible only on secure origins (via TLS).
* A server has to opt in to receive the `Device-Memory` header from the client, by sending the `Accept-CH` response header.
* Servers that opt in to the `Device-Memory` 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.

Syntax
------


```http
Device-Memory: <number>
```

Directives
----------

`<number>`

The approximate amount of device RAM. Possible values are: `0.25`, `0.5`, `1`, `2`, `4`, `8`.

The amount of device RAM can be used as a fingerprinting variable, so values for the header are intentionally coarse to reduce the potential for its misuse.

Examples
--------

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


```http
Accept-CH: Device-Memory
```


Then on subsequent requests the client might send `Device-Memory` header back:


```http
Device-Memory: 1
```

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

| Specification |
| --- |
| Device Memory # iana-device-memory |

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 Memory API
* `Navigator.deviceMemory`
* `WorkerNavigator.deviceMemory`
* Device client hints
    + `Content-DPR`
    + `DPR`
    + `Viewport-Width`
    + `Width`
* `Accept-CH`
* HTTP Caching > Vary and `Vary`
Sec-CH-UA-Platform-Version
==========================

**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-Version`** user agent client hint request header provides the version of the operating system on which the user agent is running.

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

Syntax
------


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

### Directives

`<version>`

 The version string typically contains the operating system version in a string, consisting of dot-separated major, minor and patch version numbers.
 For example, `"11.0.0"`

The version string on Linux is always empty.

Examples
--------

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


 The client may choose to provide the hint, and add the `Sec-CH-UA-Platform-Version` header to subsequent requests.
 For example, the following request headers might be sent from a browser running on Windows 10.


```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-Platform-Version: "10.0.0"
```

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

| Specification |
| --- |
| User-Agent Client Hints # sec-ch-ua-platform-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`