recursal/MDN huggingface dataset:
Origin
======

 The **`Origin`** request header indicates the origin (scheme, hostname, and port) that *caused* the request.
 For example, if a user agent needs to request resources included in a page, or fetched by scripts that it executes, then the origin of the page may be included in the request.


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

Syntax
------


```http
Origin: null
Origin: <scheme>://<hostname>
Origin: <scheme>://<hostname>:<port>
```

Directives
----------

`null`

The origin is "privacy sensitive", or is an *opaque origin* as defined by the HTML specification (specific cases are listed in the description section).

`<scheme>`

 The protocol that is used.
 Usually, it is the HTTP protocol or its secured version, HTTPS.


`<hostname>`

The domain name or the IP address of the origin server.

`<port>` Optional

 Port number on which the server is listening.
 If no port is given, the default port for the requested service is implied (e.g., "80" for an HTTP URL) .


Description
-----------

 The `Origin` header is similar to the `Referer` header, but does not disclose the path, and may be `null`.
 It is used to provide the "security context" for the origin request, except in cases where the origin information would be sensitive or unnecessary.

Broadly speaking, user agents add the `Origin` request header to:

* cross origin requests.
* same-origin requests except for `GET` or `HEAD` requests (i.e. they are added to same-origin `POST`, `OPTIONS`, `PUT`, `PATCH`, and `DELETE` requests).

There are some exceptions to the above rules; for example, if a cross-origin `GET` or `HEAD` request is made in no-cors mode, the `Origin` header will not be added.

The `Origin` header value may be `null` in a number of cases, including (non-exhaustively):

* Origins whose scheme is not one of `http`, `https`, `ftp`, `ws`, `wss`, or `gopher` (including `blob`, `file` and `data`).
* Cross-origin images and media data, including that in `<img>`, `<video>` and `<audio>` elements.
* Documents created programmatically using `createDocument()`, generated from a `data:` URL, or that do not have a creator browsing context.
* Redirects across origins.
* iframes with a sandbox attribute that doesn't contain the value `allow-same-origin`.
* Responses that are network errors.
* `Referrer-Policy` set to `no-referrer` for non-`cors` request modes (e.g. simple form posts).

**Note:** There is a more detailed listing of cases that may return `null` on Stack Overflow: When do browsers send the Origin header? When do browsers set the origin to null?

Examples
--------


```http
Origin: https://developer.mozilla.org
```



```http
Origin: http://developer.mozilla.org:80
```

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

| Specification |
| --- |
| The Web Origin Concept # section-7 |
| Fetch Standard # origin-header |

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

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

See also
--------

* `Host`
* `Referer`
* Same-origin policy
* When do browsers send the Origin header? When do browsers set the origin to null? (Stack Overflow)
Vary
====

The **`Vary`** HTTP response header describes the parts of the request message aside from the method and URL that influenced the content of the response it occurs in. Most often, this is used to create a cache key when content negotiation is in use.

The same `Vary` header value should be used on all responses for a given URL, including `304` `Not Modified` responses and the "default" response.

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

Syntax
------


```http
Vary: \*
Vary: <header-name>, <header-name>, ...
```

Directives
----------

\*

Indicates that factors other than request headers influenced the generation of this response. Implies that the response is uncacheable.

<header-name>

A comma-separated list of request header names that could have influenced the generation of this response.

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

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

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

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

### Compatibility notes

* Vary with care – Vary header problems in IE6-9
See also
--------

* Understanding The Vary Header - Smashing Magazine
* Best Practices for Using the Vary Header – fastly.com
* Content negotiation
Sec-WebSocket-Accept
====================

 The **Sec-WebSocket-Accept** header is used in the websocket opening
 handshake. It would appear in the response headers. That is, this is header is sent from
 server to client to inform that server is willing to initiate a websocket connection.


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

Syntax
------


```http
Sec-WebSocket-Accept: <hashed key>
```

Directives
----------

<hashed key>

 The server takes the value of the Sec-WebSocket-Key sent in the handshake request,
 appends `258EAFA5-E914-47DA-95CA-C5AB0DC85B11`, takes SHA-1 of the new
 value, and is then base64
 encoded.


Examples
--------


```http
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
```

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

#### No specification found

No specification data found for `http.headers.Sec-WebSocket-Accept`.  
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.

See also
--------

* `Sec-WebSocket-Key`
Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
Sec-Fetch-Mode
==============

The **`Sec-Fetch-Mode`** fetch metadata request header indicates the mode of the request.

Broadly speaking, this allows a server to distinguish between: requests originating from a user navigating between HTML pages, and requests to load images and other resources. For example, this header would contain `navigate` for top level navigation requests, while `no-cors` is used for loading an image.

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

Syntax
------


```http
Sec-Fetch-Mode: cors
Sec-Fetch-Mode: navigate
Sec-Fetch-Mode: no-cors
Sec-Fetch-Mode: same-origin
Sec-Fetch-Mode: websocket
```


Servers should ignore this header if it contains any other value.

Directives
----------

**Note:** These directives correspond to the values in `Request.mode`.

`cors`

The request is a CORS protocol request.

`navigate`

The request is initiated by navigation between HTML documents.

`no-cors`

The request is a no-cors request (see `Request.mode`).

`same-origin`

The request is made from the same origin as the resource that is being requested.

`websocket`

The request is being made to establish a WebSocket connection.

Examples
--------

If a user clicks on a page link to another page on the same origin, the resulting request would have the following headers (note that the mode is `navigate`):


```http
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
```


A cross-site request generated by an `<img>` element would result in a request with the following HTTP request headers (note that the mode is `no-cors`):


```http
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site
```

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

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

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

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

See also
--------

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

 The **`Accept-Language`** request HTTP header indicates the natural language and locale that the client prefers.
 The server uses content negotiation to select one of the proposals and informs the client of the choice with the `Content-Language` response header. Browsers set required values for this header according to their active user interface language. Users rarely change it, and such changes are not recommended because they may lead to fingerprinting.

This header serves as a hint when the server cannot determine the target content language otherwise (for example, use a specific URL that depends on an explicit user decision). The server should never override an explicit user language choice. The content of `Accept-Language` is often out of a user's control (when traveling, for instance). A user may also want to visit a page in a language different from the user interface language.

The server possibly can send back a `406` (Not Acceptable) error code when unable to serve content in a matching language. However, such a behavior is rarely implemented for a better user experience, and servers often ignore the `Accept-Language` header in such cases.

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

Syntax
------


```http
Accept-Language: <language>
Accept-Language: \*

// Multiple types, weighted with the quality value syntax:
Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, \*;q=0.5
```

Directives
----------

`<language>`

 A language tag (which is sometimes referred to as a "locale identifier"). This
 consists of a 2-3 letter base language tag that indicates a language, optionally
 followed by additional subtags separated by `'-'`. The most common extra
 information is the country or region variant (like `'en-US'` or
 `'fr-CA'`) or the type of alphabet to use (like `'sr-Latn'`).
 Other variants, like the type of orthography (`'de-DE-1996'`), are usually
 not used in the context of this header.


`*`

Any language; `'*'` is used as a wildcard.

`;q=` (q-factor weighting)

 Any value placed in an order of preference expressed using a relative
 quality value called *weight*.


Examples
--------


```http
Accept-Language: de
```



```http
Accept-Language: de-CH
```



```http
Accept-Language: en-US,en;q=0.5
```

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

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

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

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

See also
--------

* HTTP content negotiation
* A header with the result of the content negotiation:
 `Content-Language`
* Other similar headers: `TE`, `Accept-Encoding`, `Accept`
Trailer
=======

 The **Trailer** response header allows the sender to include additional
 fields at the end of chunked messages in order to supply metadata that might be
 dynamically generated while the message body is sent, such as a message integrity check,
 digital signature, or post-processing status.


**Note:** The `TE` request header needs to be set to "trailers" to allow
 trailer fields.



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

Syntax
------


```http
Trailer: header-names
```

Directives
----------

`header-names`

 HTTP header fields which will be present in the trailer part of chunked messages.
 These header fields are **disallowed**:


* message framing headers (e.g., `Transfer-Encoding` and
 `Content-Length`),
* routing headers (e.g., `Host`),
* request modifiers (e.g., controls and conditionals, like
 `Cache-Control`, `Max-Forwards`, or
 `TE`),
* authentication headers (e.g., `Authorization` or
 `Set-Cookie`),
* or `Content-Encoding`, `Content-Type`,
 `Content-Range`, and `Trailer` itself.

Examples
--------

### Chunked transfer encoding using a trailing header

 In this example, the `Expires` header is used at the end of the chunked
 message and serves as a trailing header.


```http
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
Trailer: Expires

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
Expires: Wed, 21 Oct 2015 07:28:00 GMT\r\n
\r\n
```

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

| Specification |
| --- |
| HTTP Semantics # field.trailer |
| HTTP/1.1 # chunked.trailer.section |

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

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

See also
--------

* `Transfer-Encoding`
* `TE`
* Chunked transfer encoding
Sec-CH-UA-Arch
==============

**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-Arch`** user agent client hint request header provides the user-agent's underlying CPU architecture, such as ARM or x86.

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-Arch: <arch>
```

### Directives

`<arch>`

A string indicating the underlying platform architecture, such as: `"x86"`, `"ARM"`, `"[arm64-v8a, armeabi-v7a, armeabi]"`.

Examples
--------

A server requests the `Sec-CH-UA-Arch` header by including the `Accept-CH` in a response to some 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-Arch
```


 The client may choose to provide the hint, and add the `Sec-CH-UA-Arch` header to subsequent requests.
 For example, on a Windows X86 based 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-Arch: "x86"
```


Note above that the low entropy headers are added to the request even though not specified in the server response.

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

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

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`
Referer
=======

 The **`Referer`** HTTP request header contains the absolute or partial address from which a resource has been requested.
 The `Referer` header allows a server to identify referring pages that people are visiting from or where requested resources are being used.
 This data can be used for analytics, logging, optimized caching, and more.

 When you click a link, the **`Referer`** contains the address of the page that includes the link.
 When you make resource requests to another domain, the **`Referer`** contains the address of the page that uses the requested resource.

 The `Referer` header can contain an *origin*, *path*, and *querystring*, and may not contain URL fragments (i.e. `#section`) or `username:password` information.
 The request's *referrer policy* defines the data that can be included. See `Referrer-Policy` for more information and examples.


**Note:** The header name "referer" is actually a misspelling of the word "referrer".
 See HTTP referer on Wikipedia for more details.



**Warning:** This header may have undesirable consequences for user security and privacy.
 See Referer header: privacy and security concerns for more information and mitigation hints.



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

Syntax
------


```http
Referer: <url>
```

Directives
----------

<url>

 An absolute or partial address of the web page that makes the request.
 URL fragments (i.e. `#section`) and userinfo (i.e. `username:password` in `https\://username:password\@example.com/foo/bar/`) are not included.
 Origin, path, and querystring may be included, depending on the referrer policy.


Examples
--------


```http
Referer: https://developer.mozilla.org/en-US/docs/Web/JavaScript
Referer: https://example.com/page?q=123
Referer: https://example.com/
```

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

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

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

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

See also
--------

* HTTP referer on Wikipedia
* Fetch: `Request.referrerPolicy`
* The obsolete `Content-Security-Policy` `referrer` 
Deprecated
 directive.
* Same-origin policy
* Tighter Control Over Your Referrers – Mozilla Security Blog
Cross-Origin-Opener-Policy
==========================

The HTTP **`Cross-Origin-Opener-Policy`** (COOP) response header allows you to ensure a top-level document does not share a browsing context group with cross-origin documents.

COOP will process-isolate your document and potential attackers can't access your global object if they were to open it in a popup, preventing a set of cross-origin attacks dubbed XS-Leaks.

If a cross-origin document with COOP is opened in a new window, the opening document will not have a reference to it, and the `window.opener` property of the new window will be `null`. This allows you to have more control over references to a window than `rel=noopener`, which only affects outgoing navigations.

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

Syntax
------


```http
Cross-Origin-Opener-Policy: unsafe-none
Cross-Origin-Opener-Policy: same-origin-allow-popups
Cross-Origin-Opener-Policy: same-origin
```

### Directives

`unsafe-none`

This is the default value. Allows the document to be added to its opener's browsing context group unless the opener itself has a COOP of `same-origin` or `same-origin-allow-popups`.

`same-origin-allow-popups`

Retains references to newly opened windows or tabs that either don't set COOP or that opt out of isolation by setting a COOP of `unsafe-none`.

`same-origin`

Isolates the browsing context exclusively to same-origin documents. Cross-origin documents are not loaded in the same browsing context.

Examples
--------

### Certain features depend on cross-origin isolation

Certain features like `SharedArrayBuffer` objects or `Performance.now()` with unthrottled timers are only available if your document has a COOP header with the value `same-origin` set.


```http
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
```


See also the `Cross-Origin-Embedder-Policy` header which you'll need to set to `require-corp` or `credentialless` 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);
}
```

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

| Specification |
| --- |
| HTML Standard # the-coop-headers |

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

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

See also
--------

* `Cross-Origin-Embedder-Policy`
If-Match
========

The **`If-Match`** HTTP request header makes a request conditional.

 A server will only return requested resources for `GET` and `HEAD` methods, or upload resource for `PUT` and other non-safe methods, if the resource matches one of the listed `ETag` values.
 If the conditional does not match then the `412` (Precondition Failed) response is returned.

 The comparison with the stored `ETag` uses the *strong comparison algorithm*, meaning two files are considered identical byte by byte only.
 If a listed `ETag` has the `W/` prefix indicating a weak entity tag, this comparison algorithm will never match it.

There are two common use cases:

* For `GET` and `HEAD` methods, used in combination with a `Range` header, it can guarantee that the new ranges requested
 come from the same resource as the previous one.
* For other methods, and in particular for `PUT`, `If-Match` can be used to prevent the lost update problem.
 It can check if the modification of a resource that the user wants to upload will not override another change that has been done since the original resource was fetched.

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

Syntax
------


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

Directives
----------

`<etag_value>`

 Entity tags uniquely representing the requested resources.
 They are a string of ASCII characters placed between double quotes (like `"675af34563dc-tr34"`).
 They may be prefixed by `W/` to indicate that they are "weak", i.e. that they represent the resource semantically but not byte-by-byte.
 However, in an **`If-Match`** header, weak entity tags will never match.


`*`

 The asterisk is a special value representing any resource.
 Note that this must match as `false` if the origin server does not have a current representation for the target resource.


Examples
--------


```http
If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

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

If-Match: \*
```

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

| Specification |
| --- |
| HTTP Semantics # field.if-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-None-Match`
* `412 Precondition Failed`
* `416 Range Not Satisfiable`
Accept
======

The **`Accept`** request HTTP header indicates which content types, expressed as MIME types, the client is able to understand. The server uses content negotiation to select one of the proposals and informs the client of the choice with the `Content-Type` response header. Browsers set required values for this header based on the context of the request. For example, a browser uses different values in a request when fetching a CSS stylesheet, image, video, or a script.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |
| CORS-safelisted request header | 
 yes, with the additional restriction that values can't contain a
 *CORS-unsafe request header byte*: 0x00-0x1F (except 0x09 (HT)),
 `"():<>?@[\]{}`, and 0x7F (DEL).
  |

Syntax
------


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

// Multiple types, weighted with the quality value syntax:
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, \*/\*;q=0.8
```

Directives
----------

`<MIME_type>/<MIME_subtype>`

A single, precise MIME type, like `text/html`.

`<MIME_type>/*`

A MIME type, but without a subtype. `image/*` corresponds to `image/png`, `image/svg`, `image/gif`, and other image types.

`*/*`

Any MIME type

`;q=` (q-factor weighting)

A value used is placed in an order of preference expressed using a relative quality value called the *weight*.

Examples
--------


```http
Accept: text/html

Accept: image/\*

// General default
Accept: \*/\*

// Default for navigation requests
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, \*/\*;q=0.8
```

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

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

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

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

See also
--------

* HTTP content negotiation
* List of default Accept values
* A header with the result of the content negotiation: `Content-Type`
* Other similar headers: `TE`, `Accept-Encoding`, `Accept-Language`