recursal/MDN huggingface dataset:
Via
===

 The **`Via`** general header is added by proxies, both forward
 and reverse, and can appear in the request or response headers. It
 is used for tracking message forwards, avoiding request loops, and identifying the
 protocol capabilities of senders along the request/response chain.


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

Syntax
------


```http
Via: [ <protocol-name> "/" ] <protocol-version> <host> [ ":" <port> ]
Via: [ <protocol-name> "/" ] <protocol-version> <pseudonym>
```

Directives
----------

<protocol-name>

Optional. The name of the protocol used, such as "HTTP".

<protocol-version>

The version of the protocol used, such as "1.1".

<host> and <port>

Public proxy URL and port.

<pseudonym>

Name/alias of an internal proxy.

Examples
--------


```http
Via: 1.1 vegur
Via: HTTP/1.1 GWA
Via: 1.0 fred, 1.1 p.example.net
```

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

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

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

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

See also
--------

* `X-Forwarded-For`
* Heroku's proxy library Vegur
X-Forwarded-Host
================

 The **`X-Forwarded-Host`** (XFH) header is a de-facto standard
 header for identifying the original host requested by the client in the
 `Host` HTTP request header.

 Host names and ports of reverse proxies (load balancers, CDNs) may differ from the
 origin server handling the request, in that case the `X-Forwarded-Host`
 header is useful to determine which Host was originally used.


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

Syntax
------


```http
X-Forwarded-Host: <host>
```

Directives
----------

<host>

The domain name of the forwarded server.

Examples
--------


```http
X-Forwarded-Host: id42.example-cdn.com
```

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

Not part of any current specification.

See also
--------

* `Host`
* `Forwarded`
* `X-Forwarded-For`
* `X-Forwarded-Proto`
TE
==

 The **`TE`** request header specifies the transfer encodings
 the user agent is willing to accept. (you could informally call it
 `Accept-Transfer-Encoding`, which would be more intuitive).


**Note:** In
 HTTP/2 and
 HTTP/3, the `TE`
 header field is only accepted if the `trailers` value is set.


 See also the `Transfer-Encoding` response header for more details on
 transfer encodings. Note that `chunked` is always acceptable for HTTP/1.1
 recipients and you don't have to specify `"chunked"` using the
 `TE` header. However, it is useful for setting if the client is accepting
 trailer fields in a chunked transfer coding using the "trailers" value.


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

Syntax
------


```http
TE: compress
TE: deflate
TE: gzip
TE: trailers

// Multiple directives, weighted with the quality value syntax:
TE: trailers, deflate;q=0.5
```

Directives
----------

`compress`

 A format using the Lempel-Ziv-Welch (LZW) algorithm is
 accepted as a transfer coding name.


`deflate`

 Using the zlib
 structure is accepted as a transfer coding name.


`gzip`

 A format using the Lempel-Ziv coding
 (LZ77), with a 32-bit CRC is accepted as a transfer coding name.


`trailers`

 Indicates that the client is willing to accept trailer fields in a chunked transfer
 coding.


`q`

 When multiple transfer codings are acceptable, the `q` parameter of the
 quality value syntax can rank
 codings by preference.


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

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

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

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

See also
--------

* `Transfer-Encoding`
* `Trailer`
* Chunked transfer encoding
Sec-Purpose
===========

The **`Sec-Purpose`** fetch metadata request header indicates the purpose for which the requested resource will be used, when that purpose is something other than immediate use by the user-agent.

 The only purpose that is currently defined is `prefetch`, which indicates that the resource is being requested in anticipation that it will be needed by a page that is likely to be navigated to in the near future, such as a page linked in search results or a link that a user has hovered over.
 The server can use this knowledge to: adjust the caching expiry for the request, disallow the request, or perhaps to treat it differently when counting page visits.

 The header is sent when a page is loaded that has a `<link>` element with attribute `rel="prefetch"`.
 Note that if this header is set then a `Sec-Fetch-Dest` header in the request must be set to `empty` (any value in the `<link>` attribute `as` is ignored) and the `Accept` header should match the value used for normal navigation requests.


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

Syntax
------


```http
Sec-Purpose: prefetch
```

Directives
----------

The allowed tokens are:

`prefetch`

The purpose is to prefetch a resource that may be needed in a probable future navigation.

Examples
--------

A prefetch request
------------------

 Consider the case where a browser loads a file with a `<link>` element that has the attribute `rel="prefetch"` and an `href` attribute containing the address of an image file.
 The resulting `fetch()` should result in an HTTP request where `Sec-Purpose: prefetch`, `Sec-Fetch-Dest: empty`, and an `Accept` value that is the same as the browser uses for page navigation.

An example of such a header (on Firefox) is given below:


```http
GET /images/some\_image.png HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Sec-Purpose: prefetch
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
Pragma: no-cache
Cache-Control: no-cache
```


**Note:** At time of writing FireFox incorrectly sets the `Accept` header as `Accept: */*` for prefetches.
 The example has been modified to show what the `Accept` value should be.
 This issue can be tracked in Firefox bug 1836334.


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

| Specification |
| --- |
| Fetch Standard # sec-purpose-header |
| Prefetch # sec-purpose-header |

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

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

See also
--------

* Prefetch (Glossary)
* `<link>` element with attribute `rel="prefetch"`
If-Range
========

 The **`If-Range`** HTTP request header makes a range request
 conditional: if the condition is fulfilled, the range request is issued, and the
 server sends back a `206` `Partial Content` answer with the
 appropriate body. If the condition is not fulfilled, the full resource is sent back
 with a `200` `OK` status.

 This header can be used either with the `Last-Modified` validator or
 with `ETag`, but not with both.

 The most common use case is to resume a download, to guarantee that the stored resource
 has not been modified since the last fragment has been received.


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

Syntax
------


```http
If-Range: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
If-Range: <etag>
```

Directives
----------

<etag>

 An entity tag uniquely representing the requested resource. It is a string of ASCII
 characters placed between double quotes (Like `"675af34563dc-tr34"`). A weak entity tag (one prefixed by `W/`) must not be used in this header.


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

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

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

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

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

See also
--------

* `ETag`
* `Last-Modified`
* `If-Modified-Since`
* `If-Unmodified-Since`
* `If-Match`
* `If-None-Match`
* `206 Partial Content`
* HTTP Conditional Requests
Connection
==========

 The **`Connection`** general header controls whether the
 network connection stays open after the current transaction finishes. If the value sent
 is `keep-alive`, the connection is persistent and not closed, allowing for
 subsequent requests to the same server to be done.


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


 All hop-by-hop headers used by the message - including standard hop-by-hop headers (`Keep-Alive`,
 `Transfer-Encoding`, `TE`, `Connection`,
 `Trailer`, `Upgrade`,
 `Proxy-Authorization` and `Proxy-Authenticate`) - must be listed in the `Connection`
 header, so that the first proxy knows it has to consume them and not forward them
 further.


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

Syntax
------


```http
Connection: keep-alive
Connection: close
```

Directives
----------

`close`

 Indicates that either the client or the server would like to close the connection.
 This is the default on HTTP/1.0 requests.


any comma-separated list of HTTP headers [Usually `keep-alive` only]

 Indicates that the client would like to keep the connection open. Keeping a connection open
 is the default on HTTP/1.1 requests. The list of headers are the
 name of the header to be removed by the first non-transparent proxy or cache
 in-between: these headers define the connection between the emitter and the first
 entity, not the destination node.


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

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

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

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

The **`Sec-Fetch-User`** fetch metadata request header is only sent for requests initiated by user activation, and its value will always be `?1`.

A server can use this header to identify whether a navigation request from a document, iframe, etc., was originated by the user.

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

Syntax
------


```http
Sec-Fetch-User: ?1
```

Directives
----------

The value will always be `?1`. When a request is triggered by something other than a user activation, the spec requires browsers to omit the header completely.

Examples
--------

If a user clicks on a page link to another page on the same origin, the resulting request would have the following headers:


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

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

| Specification |
| --- |
| Fetch Metadata Request Headers # sec-fetch-user-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-Mode`
    + `Sec-Fetch-Site`
* Protect your resources from web attacks with Fetch Metadata (web.dev)
* Fetch Metadata Request Headers playground (secmetadata.appspot.com)
If-Unmodified-Since
===================

 The HyperText Transfer Protocol (HTTP) **`If-Unmodified-Since`** request header makes the
 request for the resource conditional: the server will send the requested resource or accept it in
 the case of a `POST` or another non-safe method only if the resource has not been modified after the date specified by this HTTP header. If the resource has been modified
 after the specified date, the response will be a `412 Precondition Failed` error.

The **`If-Unmodified-Since`** HTTP header is commonly used in the following situations:

* In conjunction with non-safe methods, like `POST`,
 this header can be used to implement an optimistic concurrency control, as is done by some wikis: editions are rejected if the
 stored document has been modified since the original was retrieved.
* In conjunction with a range request using the `Range` header, this header can
 be used to ensure that the new fragment requested comes from an unmodified document.

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

Syntax
------


```http
If-Unmodified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

Directives
----------

<day-name>

A 3-letter description of the day of the week. One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).

<day>

A 2-digit day number of the month. Examples: "04", "23".

<month>

A 3-letter description of the month. One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (case-sensitive).

<year>

A 4-digit year number. Examples: "1990", "2016".

<hour>

A 2-digit hour number based on a 24-hour system. Examples: "09", "23".

<minute>

A 2-digit minute number. Examples: "04", "59".

<second>

A 2-digit second number. Examples: "04", "59".

`GMT`

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

Examples
--------


```http
If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT
```

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

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

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

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

See also
--------

* `Last-Modified`
* `If-Modified-Since`
* `If-Match`
* `If-None-Match`
* `Range`
* `412 Precondition Failed`
Retry-After
===========

 The **`Retry-After`** response HTTP header indicates how long
 the user agent should wait before making a follow-up request. There are three main cases
 this header is used:

* When sent with a `503` (Service Unavailable) response, this indicates
 how long the service is expected to be unavailable.
* When sent with a `429` (Too Many Requests) response, this indicates
 how long to wait before making a new request.
* When sent with a redirect response, such as `301` (Moved Permanently),
 this indicates the minimum time that the user agent is asked to wait before issuing
 the redirected request.

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

Syntax
------


```http
Retry-After: <http-date>
Retry-After: <delay-seconds>
```

Directives
----------

<http-date>

 A date after which to retry. See the `Date` header for more details
 on the HTTP date format.


<delay-seconds>

 A non-negative decimal integer indicating the seconds to delay after the response is
 received.


Examples
--------

### Dealing with scheduled downtime

 Support for the `Retry-After` header on both clients and servers is still
 inconsistent. However, some crawlers and spiders, like the Googlebot, honor the
 `Retry-After` header. It is useful to send it along with a
 `503` (Service Unavailable) response, so that search engines will keep
 indexing your site when the downtime is over.


```http
Retry-After: Wed, 21 Oct 2015 07:28:00 GMT
Retry-After: 120
```

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

| Specification |
| --- |
| HTTP Semantics # field.retry-after |

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

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

See also
--------

* Google Webmaster blog: How to deal with planned site downtime
* `503` (Service Unavailable)
* `301` (Moved Permanently)
From
====

 The **`From`** request header contains an Internet email
 address for a human user who controls the requesting user agent.

 If you are running a robotic user agent (e.g. a crawler), the `From` header
 must be sent, so you can be contacted if problems occur on servers, such as if the
 robot is sending excessive, unwanted, or invalid requests.

**Warning:** You must not use the `From` header for access control or authentication.


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

Syntax
------


```http
From: <email>
```

Directives
----------

<email>

A machine-usable email address.

Examples
--------


```http
From: webmaster@example.org
```

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

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

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

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

See also
--------

* `Host`
Max-Forwards
============

The **`Max-Forwards`** request HTTP header is used with the `TRACE` method to limit the number of nodes (usually proxies) that request goes through. Its value is an integer value indicating the *maximum amount* of nodes it must visit. At each node, the value is decremented and the `TRACE` request is forwarded to the next node, until the destination is reached, or the received value of `Max-Forwards` is zero. The request is then sent back, except for some headers, as the body of a `200 OK` response.

If the `Max-Forwards` header is not present in a `TRACE` request, a node will assume that there is no maximum number of forwards.

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

Syntax
------


```http
Max-Forwards: <integer>
```

Examples
--------


```http
Max-Forwards: 0
Max-Forwards: 10
```

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

| Specification |
| --- |
| HTTP Semantics # field.max-forwards |

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

This feature is neither targeted at, nor implemented in, browsers.

See also
--------

* The HTTP `TRACE` method
Sec-GPC
=======

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

**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 **`Sec-GPC`** (**G**lobal **P**rivacy **C**ontrol) request header indicates whether the user consents to a website or service selling or sharing their personal information with third parties.

 The specification does not define how the user can withdraw or grant consent for website.
 Where possible the mechanism will be indicated in the browser compatibility section below.


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

Syntax
------


```http
Sec-GPC: 1
```

Directives
----------

The `Sec-GPC` is header is sent with a value of `1` if the user has indicated that they prefer their information not be shared with, or sold to, third parties.

Otherwise, the header is not sent, which indicates that either the user has not made a decision or the user is okay with their information being shared with or sold to third parties.

Examples
--------

### Reading Global Privacy Control status from JavaScript

The user's GPC preference can also be read from JavaScript using the `Navigator.globalPrivacyControl` or `WorkerNavigator.globalPrivacyControl` property:


```js
navigator.globalPrivacyControl; // "false" or "true"
```

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

| Specification |
| --- |
| Global Privacy Control (GPC)  |

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

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

See also
--------

* `Navigator.globalPrivacyControl`
* `DNT` header
* `Tk` header
* globalprivacycontrol.org
* Global Privacy Control Spec
* Do Not Track on Wikipedia
DNT
===

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

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

 The **`DNT`** (**D**o **N**ot
 **T**rack) request header indicates the user's tracking preference. It lets
 users indicate whether they would prefer privacy rather than personalized content.


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

Syntax
------


```http
DNT: 0
DNT: 1
DNT: null
```

Directives
----------

0

The user prefers to allow tracking on the target site.

1

The user prefers not to be tracked on the target site.

null

The user has not specified a preference about tracking.

Examples
--------

### Reading Do Not Track status from JavaScript

 The user's DNT preference can also be read from JavaScript using the
 `Navigator.doNotTrack` property:


```js
navigator.doNotTrack; // "0", "1" or null
```

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

#### No specification found

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

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

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

See also
--------

* `Navigator.doNotTrack`
* `Tk` header
* Do Not Track on Wikipedia
* What Does the "Track" in "Do Not Track" Mean? – EFF
* DNT on Electronic Frontier Foundation
* DNT browser settings help:
    + Firefox
    + Chrome
Age
===

The **`Age`** header contains the time in seconds the object was in a proxy cache.

 The `Age` header is usually close to zero. If it is `Age: 0`, it was probably fetched from the origin server; otherwise, it was usually calculated as
 a difference between the proxy's current date and the `Date` general header included in the HTTP response.


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

Syntax
------


```http
Age: <delta-seconds>
```

Directives
----------

<delta-seconds>

A non-negative integer that is time in seconds the object was in a proxy cache.

Examples
--------


```http
Age: 24
```

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

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

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

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

See also
--------

* `Cache-Control`
* `Expires`