recursal/MDN huggingface dataset:
Location
========

 The **`Location`** response header indicates the URL to
 redirect a page to. It only provides a meaning when served with a
 `3xx` (redirection) or `201` (created) status response.

 In cases of redirection, the HTTP method used to make the new request to fetch the page
 pointed to by `Location` depends on the original method and the kind of
 redirection:

* `303` (See Other) responses always lead to the use of a
 `GET` method.
* `307` (Temporary Redirect) and
 `308` (Permanent Redirect) don't change the method used in the
 original request.
* `301` (Moved Permanently) and `302` (Found) don't
 change the method most of the time, though older user-agents may (so you basically
 don't know).

All responses with one of these status codes send a `Location` header.

In cases of resource creation, it indicates the URL to the newly created resource.

`Location` and `Content-Location` are different.
 `Location` indicates the target of a redirection or the URL of a newly
 created resource. `Content-Location` indicates the direct URL to
 use to access the resource when content negotiation happened,
 without the need of further content negotiation. `Location` is a header
 associated with the response, while `Content-Location` is associated
 with the entity returned.


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

Syntax
------


```http
Location: <url>
```

Directives
----------

<url>

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

Examples
--------


```http
Location: /index.html
```

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

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

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

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

See also
--------

* `Content-Location`
* Status of responses including a `Location` header: `201`,
 `301`, `302`, `303`,
 `307`, `308`.
Sec-Fetch-Site
==============

The **`Sec-Fetch-Site`** fetch metadata request header indicates the relationship between a request initiator's origin and the origin of the requested resource.

In other words, this header tells a server whether a request for a resource is coming from the same origin, the same site, a different site, or is a "user initiated" request. The server can then use this information to decide if the request should be allowed.

Same-origin requests would usually be allowed by default, but what happens for requests from other origins may further depend on what resource is being requested, or information in other Fetch metadata request headers. By default, requests that are not accepted should be rejected with a `403` response code.

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

Syntax
------


```http
Sec-Fetch-Site: cross-site
Sec-Fetch-Site: same-origin
Sec-Fetch-Site: same-site
Sec-Fetch-Site: none
```

Directives
----------

`cross-site`

The request initiator and the server hosting the resource have a different site (i.e. a request by "potentially-evil.com" for a resource at "example.com").

`same-origin`

The request initiator and the server hosting the resource have the same origin (same scheme, host and port).

`same-site`

The request initiator and the server hosting the resource have the same scheme, domain and/or subdomain, but not necessarily the same port.

`none`

This request is a user-originated operation. For example: entering a URL into the address bar, opening a bookmark, or dragging-and-dropping a file into the browser window.

Examples
--------

 A fetch request to `https://mysite.example/foo.json` originating from a web page on `https://mysite.example` (with the same port) is a same-origin request.
 The browser will generate the `Sec-Fetch-Site: same-origin` header as shown below, and the server will typically allow the request:


```http
GET /foo.json
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
```


A fetch request to the same URL from another site, for example `potentially-evil.com`, causes the browser to generate a different header (e.g. `Sec-Fetch-Site: cross-site`), which the server can choose to accept or reject:


```http
GET /foo.json
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
```

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

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

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

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

See also
--------

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

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

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

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

The **`Content-DPR`** response header is used to confirm the *image* device to pixel ratio in requests where the screen `DPR` client hint was used to select an image resource.

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

If the `DPR` client hint is used to select an image the server must specify `Content-DPR` in the response. If the value in `Content-DPR` is different from the `DPR` value in the request (i.e. image DPR is not the same as screen DPR) then the client must use the `Content-DPR` for determining intrinsic image size and scaling the image.

If the `Content-DPR` header appears more than once in a message the last occurrence is used.

**Note:**

* `Content-DPR` was removed from the client hints specification in draft-ietf-httpbis-client-hints-07. The Responsive Image Client Hints spec proposes to replace this header by specifying intrinsic resolution/dimensions in EXIF metadata.

Syntax
------


```http
Content-DPR: <number>
```

Directives
----------

`<number>`

 The image device pixel ratio, calculated according to the following formula:
 Content-DPR = *Selected image resource size* / (*Width* / *DPR*)


Examples
--------

See the `DPR` header example.

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

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

See also
--------

* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* Device client hints
    + `Device-Memory`
    + `DPR`
    + `Viewport-Width`
    + `Width`
* `Accept-CH`
* HTTP Caching > Vary and `Vary`
Want-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 **`Want-Digest`** HTTP header is primarily used in a request, to ask the server to provide a digest of the requested resource using the `Digest` response header.

 The header contains identifiers for one or more digest algorithms that the sender wishes the server to use to create the digest.
 The request may use quality values to indicate its preference/order for particular digest algorithms.

If `Want-Digest` does not include any digest algorithms that the server supports, the server may respond with:

* a digest calculated using a different digest algorithm, or
* a `400 Bad Request` error, and include another `Want-Digest` header with that response, listing the algorithms that it does support.

See the page for the `Digest` header for more information.

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

Syntax
------


```http
Want-Digest: <digest-algorithm>

// Multiple algorithms, weighted with the quality value syntax:
Want-Digest: <digest-algorithm><q-value>,<digest-algorithm><q-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`.

<q-value>

 The quality value to apply to that
 option.


Examples
--------


```http
Want-Digest: sha-256
Want-Digest: SHA-512;q=0.3, sha-256;q=1, md5;q=0
```

### Basic operation

 The sender provides a list of digests which it is prepared to accept, and the server
 uses one of them:

Request:


```http
GET /item
Want-Digest: sha-256;q=0.3, sha;q=1
```


Response:


```http
HTTP/1.1 200 Ok
Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
```

### Unsupported digests

The server does not support any of the requested digest algorithms, so uses a different algorithm:

Request:


```http
GET /item
Want-Digest: sha;q=1
```


Response:


```http
HTTP/1.1 200 Ok
Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
```


 The server does not support any of the requested digest algorithms.
 In this case it responds with a 400 error and includes another `Want-Digest` header, listing the algorithms that it does support:

Request:


```http
GET /item
Want-Digest: sha;q=1
```


Response:


```http
HTTP/1.1 400 Bad Request
Want-Digest: sha-256, sha-512
```

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

| Specification |
| --- |
| Digest Fields # section-4 |

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

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

See also
--------

* `Digest`
Proxy-Authenticate
==================

 The HTTP **`Proxy-Authenticate`** response header defines the
 authentication method that should be used to gain access to a resource behind a
 proxy server. It authenticates the request to the proxy server, allowing
 it to transmit the request further.

 The `Proxy-Authenticate` header is sent along with a `407`
`Proxy Authentication Required`.


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

Syntax
------


```http
Proxy-Authenticate: <type> realm=<realm>
```

Directives
----------

<type>

Authentication type. A common type is "Basic".
 IANA maintains a list of authentication schemes.


realm=<realm>

 A description of the protected area, the realm. If no realm is specified, clients
 often display a formatted host name instead.


Examples
--------


```http
Proxy-Authenticate: Basic

Proxy-Authenticate: Basic realm="Access to the internal site"
```

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

| Specification |
| --- |
| HTTP Semantics # field.proxy-authenticate |

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

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

See also
--------

* HTTP authentication
* `Authorization`
* `Proxy-Authorization`
* `WWW-Authenticate`
* `401`, `403`, `407`
Server
======

 The **`Server`** header describes the
 software used by the origin server that handled the request — that is, the server that
 generated the response.


**Warning:** Avoid overly-detailed `Server` values, as they can reveal information that
 may make it (slightly) easier for attackers to exploit known security holes.



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

Syntax
------


```http
Server: <product>
```

Directives
----------

<product>

 A name of the software or the product that handled the request. Usually in a format
 similar to `User-Agent`.



 How much detail to include is an interesting balance to strike; exposing the OS version
 is probably a bad idea, as mentioned in the earlier warning about overly-detailed
 values. However, exposed Apache versions helped browsers to work around a bug of the
 versions with `Content-Encoding` and
 `Range` in combination.

Examples
--------


```http
Server: Apache/2.4.1 (Unix)
```

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

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

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

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

See also
--------

* `Allow`
Width
=====

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

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

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

The **`Width`** device client hint request header field indicates the desired resource width in physical pixels — the intrinsic size of an image. The provided pixel value is a number rounded to the smallest following integer (i.e. ceiling value).

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

The hint is particularly useful because it allows the client to request a resource that is optimal for both the screen and the layout: taking into account both the density-corrected width of the screen and the image's extrinsic size within the layout.

If the desired resource width is not known at the time of the request or the resource does not have a display width, the `Width` header field can be omitted.

If the `Width` header appears more than once in a message the last occurrence is used.

**Note:**

* Client Hints are accessible only on secure origins (via TLS).
* A server has to opt in to receive the `Width` header from the client, by sending the `Accept-CH` response header.
* Servers that opt in to the `Width` 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.
* `Width` was removed from the client hints specification in draft-ietf-httpbis-client-hints-07. The proposed replacement is `Sec-CH-Width` (Responsive Image Client Hints).

Syntax
------


```http
Width: <number>
```

Directives
----------

<number>

The width of the resource in physical pixels, rounded up to the nearest integer.

Examples
--------

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


```http
Accept-CH: Width
```


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


```http
Width: 1920
```

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

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

See also
--------

* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* Device client hints
    + `Content-DPR`
    + `Device-Memory`
    + `DPR`
    + `Viewport-Width`
* `Accept-CH`
* HTTP Caching > Vary and `Vary`
ECT
===

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

The **`ECT`** Client hint request header field indicates the effective connection type: `slow-2g`, `2g`, `3g`, `4g`.

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

The value represents the "network profile" that best matches the connection's latency and bandwidth, rather than the actual mechanisms used for transferring the data. For example, `2g` might be used to represent a slow Wi-Fi connection with high latency and low bandwidth, while `4g` might be used to represent a fast fibre-based broadband network.

The hint allows a server to choose what information is sent based on the broad characteristics of the network. For example, a server might choose to send smaller versions of images and other resources on less capable connections. The value might also be used as a starting point for determining what information is sent, which is further refined using information in `RTT` and `Downlink` hints.

**Note:** A server that specifies `ECT` in `Accept-CH` may also specify it in `Vary` to indicate that responses should be cached for different ECT values.

Syntax
------


```http
ECT: <value>
```

Directives
----------

<value>

A value indicating effective connection type. This is one of: `slow-2g`, `2g`, `3g`, or `4g`.

Examples
--------

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


```http
Accept-CH: ECT
```


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


```http
ECT: 2g
```

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

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

 The HTTP **`Proxy-Authorization`** request header contains the
 credentials to authenticate a user agent to a proxy server, usually after the server has
 responded with a `407` `Proxy Authentication Required` status
 and the `Proxy-Authenticate` header.


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

Syntax
------


```http
Proxy-Authorization: <type> <credentials>
```

Directives
----------

<type>

Authentication type. A common type is "Basic".
 See also the IANA registry of Authentication schemes.


<credentials>

The credentials are constructed like this:

* The username and the password are combined with a colon
 (`aladdin:opensesame`).
* The resulting string is base64
 encoded (`YWxhZGRpbjpvcGVuc2VzYW1l`).

**Note:** Base64 encoding does not mean encryption or hashing! This
 method is as secure as sending the credentials in clear text (base64 is a
 reversible encoding). It is preferable to use HTTPS in conjunction with Basic
 Authentication.


Examples
--------


```http
Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

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

| Specification |
| --- |
| HTTP Semantics # field.proxy-authorization |

See also
--------

* HTTP authentication
* `Proxy-Authenticate`
* `WWW-Authenticate`
* `Authorization`
* `401`, `403`, `407`
Viewport-Width
==============

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

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

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

The **`Viewport-Width`** device client hint request header provides the client's layout viewport width in CSS pixels. The value is rounded up to the smallest following integer (i.e. ceiling value).

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

The hint can be used with other screen-specific hints to deliver images optimized for a specific screen size, or to omit resources that are not needed for a particular screen width.

If the `Viewport-Width` header appears more than once in a message the last occurrence is used.

**Note:**

* Client Hints are accessible only on secure origins (via TLS).
* A server has to opt in to receive the `Viewport-Width` header from the client, by sending the `Accept-CH` response header.
* Servers that opt in to the `Viewport-Width` 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.
* `Viewport-Width` was removed from the original client hints specification in draft-ietf-httpbis-client-hints-07. The proposed replacement is `Sec-CH-Viewport-Width` (Responsive Image Client Hints).

Syntax
------


```http
Viewport-Width: <number>
```

Directives
----------

<number>

The width of the user's viewport in CSS pixels, rounded up to the nearest integer.

Examples
--------

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


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


Then on subsequent requests the client might send `Viewport-Width` header back:


```http
Viewport-Width: 320
```

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

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

See also
--------

* Improving user privacy and developer experience with User-Agent Client Hints (developer.chrome.com)
* Device client hints
    + `Content-DPR`
    + `Device-Memory`
    + `DPR`
    + `Width`
* `Accept-CH`
* HTTP Caching > Vary and `Vary`