recursal/MDN huggingface dataset:
Permissions-Policy
==================

**实验性:** **这是一项实验性技术**  
在将其用于生产之前，请仔细检查浏览器兼容性表格。

**`Permissions-Policy`** 响应标头提供了一种可以在本页面或包含的 iframe 上启用或禁止浏览器特性的机制。

更多的信息，请查看Feature Policy

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

语法
--
```

Permissions-Policy: <directive> <allowlist>
```


`<allowlist>`

一个来源列表，在括号中包含的以下一个或多个值，并用空格分隔：

* `*`: 允许在当前文档和所有包含的内容（比如 iframes）中使用本特性。
* `'self'`: 允许在当前文档中使用本特性，但在包含的内容（比如 iframes）仍使用原值。
* `'src'`: (只在 iframe 中允许) 只要在src 中的 URL 和加载 iframe 用的 URL 相同，则本特性在 iframe 中允许，
* `'none'`: 从最上层到包含的内容都禁止本特性。 <origin(s)>: 在特定的源中允许，源 URL 以空格分割。

`*` 或 `none` 值只允许单独使用，而 `self` 和 `src` 值可以与多个源一起使用。

所有的特性都有一个如下的默认的 allowlist

* `*`: 本特性默认在最上层和包含的内容中（iframes）允许。
* `'self'`: 本特性默认在最上层允许，而包含的内容中（iframes）使用源地址相同设定。也就是说本特性在 iframe 中不允许跨域访问。
* `'none'`: 本特性默认在最上层和包含的内容中（iframes）都禁止。
指令
--

`autoplay` 
实验性

控制是否允许当前文档自动播放媒体。这种控制是通过接口 `HTMLMediaElement` 来实现。当这种规则被禁用，而且没有用户操作的时候，`HTMLMediaElement.play()` 返回的 `Promise` (en-US) 会拒绝并抛出一个 `DOMException` 异常。`<audio>` 和 `<video>` 上的 autoplay 属性会被忽略。

`camera`

控制是否允许当前文档使用视频输入设备。当这种规则被禁用时，`MediaDevices.getUserMedia()` 返回的 `Promise` 会拒绝并抛出 `NotAllowedError` `DOMException` 异常。

`document-domain` (en-US) 
实验性

控制是否允许当前文档设置 `document.domain`。当这种规则被禁用时，尝试设置 `document.domain` 会失败并抛出 `SecurityError` `DOMException` 异常。

`encrypted-media` (en-US) 
实验性

控制是否允许当前文档使用 Encrypted Media Extension (en-US) API（EME）。当这种规则被禁用时，`Navigator.requestMediaKeySystemAccess()` (en-US) 返回的 `Promise` (en-US) 会拒绝并抛出 `DOMException` 异常。

`fullscreen` (en-US)

控制是否允许当前文档使用 `Element.requestFullScreen()`。当这种规则被禁用时，返回的 `Promise` 会拒绝并抛出 `TypeError`。

`geolocation` (en-US)

控制是否允许当前文档使用 `Geolocation` 接口。当这种规则被禁用时，调用 `getCurrentPosition()` 和 `watchPosition()` 会返回包含 `PERMISSION_DENIED` 的 `PositionError`。

`microphone` (en-US)

控制是否允许当前文档使用音频输入设备。当这种规则被禁用时，`MediaDevices.getUserMedia()` 返回的 `Promise` 会拒绝并抛出错误 `NotAllowedError`。

`midi` (en-US)

控制是否允许当前文档使用 Web MIDI API (en-US)。当这种规则被禁用时，`Navigator.requestMIDIAccess()` (en-US) 返回的 `Promise` 会拒绝并抛出错误 `DOMException`。

`payment` (en-US)

控制是否允许当前文档使用 Payment Request API。当这种规则被启用时，构造函数 `PaymentRequest()` (en-US) 会抛出错误 `SecurityError`。

`vr` / `xr`

控制是否允许当前文档使用 WebVR API。当这种规则被禁用时，`Navigator.getVRDisplays()` (en-US) 返回的 `Promise` 会拒绝并抛出错误 `DOMException`。

示例
--

SecureCorp Inc. 公司想要在应用中禁用震动和定位 API，则可以在返回的 response 中传递以下定义权限策略的 HTTP 的标头信息：
```

Permissions-Policy: vibrate 'none'; geolocation 'none'
```


通过使用 `'none'` 关键词，不管原来如何设定，这些特性在所有浏览的上下文中都会被禁用。

规范
--

| Specification |
| --- |
| Permissions Policy # permissions-policy-http-header-field |

浏览器兼容性
------

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

参见
--

* Feature Policy
* Using Feature Policy
* Permissions-Policy Tester (Chrome Developer Tools extension)
* `Content-Security-Policy`
* `Referrer-Policy`
Via
===

**`Via`** 是一个通用首部，是由代理服务器添加的，适用于正向和反向代理，在请求和响应首部中均可出现。这个消息首部可以用来追踪消息转发情况，防止循环请求，以及识别在请求或响应传递链中消息发送者对于协议的支持能力。

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

语法
--
```

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

指令
--

<protocol-name>

可选。所使用的协议名称，如 "HTTP"。

<protocol-version>

所使用的协议版本号，例如 "1.1"。

<host> and <port>

公共代理的 URL 及端口号。

<pseudonym>

内部代理的名称或别名。

示例
--
```

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

规范
--

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

浏览器兼容性
------

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

相关内容
----

* `X-Forwarded-For`
* Heroku 的代理库 Vegur
Accept-Encoding
===============

HTTP 请求头 **Accept-Encoding** 会将客户端能够理解的内容编码方式——通常是某种压缩算法——进行通知（给服务端）。通过内容协商的方式，服务端会选择一个客户端提议的方式，使用并在响应头 `Content-Encoding` 中通知客户端该选择。

即使客户端和服务器都支持相同的压缩算法，在 identity 指令可以被接受的情况下，服务器也可以选择对响应主体不进行压缩。导致这种情况出现的两种常见的情形是：

* 要发送的数据已经经过压缩，再次进行压缩不会导致被传输的数据量更小。一些图像格式的文件会存在这种情况；
* 服务器超载，无法承受压缩需求导致的计算开销。通常，如果服务器使用超过 80% 的计算能力，微软建议不要压缩。

只要 identity——表示不需要进行任何编码——没有被明确禁止使用（通过 identity;q=0 指令或是 \*;q=0 而没有为 identity 明确指定权重值），则服务器禁止返回表示客户端错误的 `406` Not Acceptable 响应。

**备注：** IANA 维护了一个完整的官方支持的编码方式列表。

* 另外两种编码方式——bzip 和 bzip2——有时候也会用到，尽管并未在标准中出现。这两种方式实现了 UNIX 系统上的同名程序所采用的算法。注意第一种由于专利许可问题已经停止维护。


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

语法
--
```

Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *

// Multiple algorithms, weighted with the quality value syntax:
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5
```

指令
--

`gzip`

表示采用 Lempel-Ziv coding (LZ77) 压缩算法，以及 32 位 CRC 校验的编码方式。

`compress`

采用 Lempel-Ziv-Welch (LZW) 压缩算法。

`deflate`

采用 zlib 结构和 *deflate* 压缩算法。

`br`

表示采用 Brotli 算法的编码方式。

`identity`

用于指代自身（例如：未经过压缩和修改）。除非特别指明，这个标记始终可以被接受。

`*`

匹配其他任意未在该请求头字段中列出的编码方式。假如该请求头字段不存在的话，这个值是默认值。它并不代表任意算法都支持，而仅仅表示算法之间无优先次序。

`;q=` (qvalues weighting)

值代表优先顺序，用相对质量价值 表示，又称为权重。

示例
--
```

Accept-Encoding: gzip

Accept-Encoding: gzip, compress, br

Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1
```

规范
--

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

浏览器兼容性
------

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

相关内容
----

* HTTP 内容协商
* 包含有内容协商结果的响应头： `Content-Encoding`
* 其他相似的请求头：`TE`, `Accept`, `Accept-Charset`, `Accept-Language`
Content-Type
============

**`Content-Type`** 实体头部用于指示资源的 MIME 类型 media type 。

在响应中，Content-Type 标头告诉客户端实际返回的内容的内容类型。浏览器会在某些情况下进行 MIME 查找，并不一定遵循此标题的值; 为了防止这种行为，可以将标题 `X-Content-Type-Options` 设置为 **nosniff**。

在请求中 (如`POST` 或 `PUT`)，客户端告诉服务器实际发送的数据类型。

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

句法
--
```

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something
```

指令
--

`media-type`

资源或数据的 MIME type 。

charset

字符编码标准。

boundary

对于多部分实体，boundary 是必需的，其包括来自一组字符的 1 到 70 个字符，已知通过电子邮件网关是非常健壮的，而不是以空白结尾。它用于封装消息的多个部分的边界。

例子
--

### `Content-Type` 在 HTML 表单中

在通过 HTML form 提交生成的`POST`请求中，请求头的 Content-Type 由`<form>`元素上的 enctype 属性指定


```html
<form action="/" method="post" enctype="multipart/form-data">
  <input type="text" name="description" value="some text" />
  <input type="file" name="myFile" />
  <button type="submit">Submit</button>
</form>
```


请求头看起来像这样（在这里省略了一些 headers）：
```

POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575

---------------------------974767299852498929531610575
Content-Disposition: form-data; name="description"

some text
---------------------------974767299852498929531610575
Content-Disposition: form-data; name="myFile"; filename="foo.txt"
Content-Type: text/plain

(content of the uploaded file foo.txt)
---------------------------974767299852498929531610575
```

规范
--

| Specification |
| --- |
| HTTP Semantics # status.206 |
| HTTP Semantics # field.content-type |

浏览器兼容性
------

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

参见
--

* `Accept` and `Accept-Charset`
* `Content-Disposition`
* `206` Partial Content
* `X-Content-Type-Options`
Location
========

**`Location`** 首部指定的是需要将页面重新定向至的地址。一般在响应码为 3xx 的响应中才会有意义。

发送新请求，获取 Location 指向的新页面所采用的方法与初始请求使用的方法以及重定向的类型相关：

* `303` (See Also) 始终引致请求使用 `GET` 方法，而，而 `307` (Temporary Redirect) 和 `308` (Permanent Redirect) 则不转变初始请求中的所使用的方法；
* `301` (Permanent Redirect) 和 `302` (Found) 在大多数情况下不会转变初始请求中的方法，不过一些比较早的用户代理可能会引发方法的变更（所以你基本上不知道这一点）。

状态码为上述之一的所有响应都会带有一个 Location 首部。

除了重定向响应之外，状态码为 `201` (Created) 的消息也会带有 Location 首部。它指向的是新创建的资源的地址。

`Location` 与 `Content-Location`是不同的，前者（`Location` ）指定的是一个重定向请求的目的地址（或者新创建的文件的 URL），而后者（ `Content-Location`）指向的是经过内容协商后的资源的直接地址，不需要进行进一步的内容协商。Location 对应的是响应，而 Content-Location 对应的是要返回的实体。

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

语法
--
```

Location: <url>
```

指令
--

<url>

相对地址（相对于要访问的 URL）或绝对地址。

示例
--
```

Location: /index.html
```

规范
--

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

浏览器兼容性
------

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

相关内容
----

* `Content-Location`
* 包含 `Location` 首部的响应状态码：`201`, `301`, `302`, `303`, `307`, `308`。
Early-Data
==========

**实验性:** **这是一项实验性技术**  
在将其用于生产之前，请仔细检查浏览器兼容性表格。

**`Early-Data`** 头（header）由某个中间者设置来表示请求已在 TLS early data 中传送，且表示 某个中间者理解 `425 (Too Early)` 状态码。**`Early-Data`** 头（header）不由请求的发起者设置 (例如，浏览器)。

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

语法
--
```

Early-Data: 1
```

示例
--
```

GET /resource HTTP/1.0
Host: example.com
Early-Data: 1
```

规范
--

| Specification |
| --- |
| Using Early Data in HTTP # header |

浏览器兼容性
------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
X-Forwarded-Proto
=================

**`X-Forwarded-Proto`** (XFP) 是一个事实上的标准首部，用来确定客户端与代理服务器或者负载均衡服务器之间的连接所采用的传输协议（HTTP 或 HTTPS）。在服务器的访问日志中记录的是负载均衡服务器与服务器之间的连接所使用的传输协议，而非客户端与负载均衡服务器之间所使用的协议。为了确定客户端与负载均衡服务器之间所使用的协议，X-Forwarded-Proto 就派上了用场。

HTTP 协议中的 `Forwarded` 是这个消息首部的标准化版本。

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

语法
--
```

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

指令
--

<protocol>

经过转发的传输协议（http 或 https）。

示例
--
```

X-Forwarded-Proto: https
```


其他非标准形式：
```

# Microsoft
Front-End-Https: on

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

规范
--

不属于任何一份既有规范。这个消息首部的标准版本是 `Forwarded`.

相关内容
----

* `Forwarded`
* `X-Forwarded-For`
* `X-Forwarded-Host`
Allow
=====

**`Allow`** 首部字段用于枚举资源所支持的 HTTP 方法的集合。

若服务器返回状态码 `405` `Method Not Allowed`，则该首部字段亦需要同时返回给客户端。如果 `Allow` 首部字段的值为空，说明资源不接受使用任何 HTTP 方法的请求。这是可能的，比如服务器需要临时禁止对资源的任何访问。

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

语法
--
```

Allow: <http-methods>
```

声明
--

<http-methods>

HTTP 请求方法的集合。

示例
--
```

Allow: GET, POST, HEAD
```

规范
--

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

参见
--

* `405`
* `Server`
X-XSS-Protection
================

HTTP **`X-XSS-Protection`** 响应头是 Internet Explorer，Chrome 和 Safari 的一个特性，当检测到跨站脚本攻击 (XSS (en-US)) 时，浏览器将停止加载页面。若网站设置了良好的 `Content-Security-Policy` 来禁用内联 JavaScript (`'unsafe-inline'`)，现代浏览器不太需要这些保护，但其仍然可以为尚不支持 CSP 的旧版浏览器的用户提供保护。

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

语法
--
```

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>
```


0

禁止 XSS 过滤。

1

启用 XSS 过滤（通常浏览器是默认的）。如果检测到跨站脚本攻击，浏览器将清除页面（删除不安全的部分）。

1;mode=block

启用 XSS 过滤。如果检测到攻击，浏览器将不会清除页面，而是阻止页面加载。

1; report=<reporting-URI> (Chromium only)

启用 XSS 过滤。如果检测到跨站脚本攻击，浏览器将清除页面并使用 CSP `report-uri` (en-US)指令的功能发送违规报告。

范例
--

当检测到 XSS 攻击时阻止页面加载：


```bash
X-XSS-Protection: 1;mode=block
```


PHP


```php
header("X-XSS-Protection: 1; mode=block");
```


Apache (.htaccess)


```bash
<IfModule mod_headers.c>
  Header set X-XSS-Protection "1; mode=block"
</IfModule>
```


Nginx


```bash
add_header "X-XSS-Protection" "1; mode=block";
```

规范
--

不属于任何一个规范或草案的一部分。

浏览器兼容性
------

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

了解更多
----

* `Content-Security-Policy`
* Controlling the XSS Filter – Microsoft
* Understanding XSS Auditor – Virtue Security
* The misunderstood X-XSS-Protection – blog.innerht.ml
X-Forwarded-Host
================

The **`X-Forwarded-Host`** (XFH) 是一个事实上的标准首部，用来确定客户端发起的请求中使用 `Host` 指定的初始域名。

反向代理（如负载均衡服务器、CDN 等）的域名或端口号可能会与处理请求的源头服务器有所不同，在这种情况下，X-Forwarded-Host 可以用来确定哪一个域名是最初被用来访问的。

这个消息首部会被用来进行调试和统计，以及生成基于位置的定制化内容，按照设计的目的，它会暴露一定的隐私和敏感信息，比如客户端的 IP 地址。所以在应用此消息首部的时候，需要将用户的隐私问题考虑在内。

HTTP 协议中的 `Forwarded` 是这个消息首部的标准化版本。

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

语法
--
```

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

指令
--

<host>

被转发的服务器的域名。

示例
--
```

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

规范
--

不属于任何一份既有规范。这个消息首部的标准版本是 `Forwarded`.

相关内容
----

* `Host`
* `Forwarded`
* `X-Forwarded-For`
* `X-Forwarded-Proto`
If-Match
========

请求首部 **`If-Match`** 的使用表示这是一个条件请求。在请求方法为 `GET` 和 `HEAD` 的情况下，服务器仅在请求的资源满足此首部列出的 `ETag`值时才会返回资源。而对于 `PUT` 或其他非安全方法来说，只有在满足条件的情况下才可以将资源上传。

`ETag` 之间的比较使用的是**强比较算法**，即只有在每一个字节都相同的情况下，才可以认为两个文件是相同的。在 ETag 前面添加 `W/` 前缀表示可以采用相对宽松的算法。

以下是两个常见的应用场景：

* 对于 `GET` 和 `HEAD` 方法，搭配 `Range`首部使用，可以用来保证新请求的范围与之前请求的范围是对同一份资源的请求。如果 ETag 无法匹配，那么需要返回 `416` (Range Not Satisfiable，范围请求无法满足) 响应。
* 对于其他方法来说，尤其是 `PUT`, `If-Match` 首部可以用来避免更新丢失问题。它可以用来检测用户想要上传的不会覆盖获取原始资源之后做出的更新。如果请求的条件不满足，那么需要返回 `412` (Precondition Failed，先决条件失败) 响应。

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

语法
--
```

If-Match: <etag_value>
If-Match: <etag_value>, <etag_value>, …
```

指令
--

<etag\_value>

唯一地表示一份资源的实体标签。标签是由 ASCII 字符组成的字符串，用双引号括起来（如 "675af34563dc-tr34"）。前面可以加上 W/ 前缀表示应该采用弱比较算法。

`*`

星号是一个特殊值，可以指代任意资源。

示例
--
```

If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

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

If-Match: *
```

规范
--

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

浏览器兼容性
------

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

相关内容
----

* `ETag`
* `If-Unmodified-Since`
* `If-Modified-Since`
* `If-None-Match`
* `416` `Range Not Satisfiable`
* `412` `Precondition Failed`
Tk
==

**`Tk`** 响应首部显示了对相应请求的跟踪情况。

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

语法
--
```

Tk: !  (under construction)
Tk: ?  (dynamic)
Tk: G  (gateway or multiple parties)
Tk: N  (not tracking)
Tk: T  (tracking)
Tk: C  (tracking with consent)
Tk: P  (potential consent)
Tk: D  (disregarding DNT)
Tk: U  (updated)
```

### 指令

!

待建。源头服务器目前正在测试它对跟踪情况的通信功能。

?

不确定。源头服务器需要更多的信息来确定跟踪状态。

G

网关或多方。服务器扮演了网关的角色，与多方进行信息交换。

N

不跟踪。

T

跟踪。

C

在经过用户同意的情况下进行跟踪。源头服务器相信它事先得到了许可来跟踪用户、用户代理或者设备。

P

尚未接收到的许可。源头服务器不能实时知道它是否获得了事先许可来跟踪用户、用户代理或者设备，但是会承诺不采用或者共享标记为 `DNT:1` 的数据，直到获得了事先许可，并进一步承诺将会在 48 小时之内对未经许可的资源进行删除或者对其进行消除身份识别信息处理。

D

忽略 DNT 首部。源头服务器不支持或者不愿意遵守用户代理发送的跟踪偏好。

U

更新。请求即将对应用于用户、用户代理或者设备的跟踪情况进行更新。

示例
--

声明不对相应资源进行跟踪的 `Tk` 首部，如下图所以：
```

Tk: N
```

规范
--

#### No specification found

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

相关内容
----

* `DNT` header
* `Navigator.doNotTrack`
Accept-Language
===============

**`Accept-Language`** 请求头允许客户端声明它可以理解的自然语言，以及优先选择的区域方言。借助内容协商机制，服务器可以从诸多备选项中选择一项进行应用，并使用 `Content-Language` 应答头通知客户端它的选择。浏览器会基于其用户界面语言为这个请求头设置合适的值，即便是用户可以进行修改，但是这种情况极少发生（因为可增加指纹独特性，通常也不被鼓励）（译者注：通常只在测试网站的多语言支持时手动修改它；或为进一步减少指纹独特性，改为最常见的英文）。

当服务器无法通过其他方式来确定应当使用的语言时——例如某一特定的 URL，这是用户明确指定的——这个请求头可以用作提示。建议服务器端永远不要覆盖明确指定的信息。`Accept-Language` 消息头的内容通常不在用户的掌控之中（例如在国外旅行时到提供网络服务的场所上网）；另外用户可能会想要浏览非本地用户界面语言的页面。

如果服务器不能提供任何可以匹配的语言的版本，那么理论上来说应该返回一个 `406`（Not Acceptable，不被接受）的错误码。但是为了更好的用户体验，这种方法很少被采用，取而代之的是将其忽略。

| Header type | Request header |
| --- | --- |
| Forbidden header name | no |
| CORS-safelisted request-header | yes |

语法
--
```

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

指令
--

`<language>`

用含有两到三个字符的字符串表示的语言码或完整的语言标签。除了语言本身之外，还会包含其他方面的信息，显示在中划线（"-"）后面。最常见的额外信息是国家或地区变种（如"en-US"）或者表示所用的字母系统（如"sr-Lat"）。其他变种诸如拼字法（"de-DE-1996"）等通常不被应用在这种场合。

`*`

任意语言；`"*"` 表示通配符（wildcard）。

`;q=` (q-factor weighting)

此值代表优先顺序，用相对质量价值表示，又称为*权重*。

示例
--
```

Accept-Language: de

Accept-Language: de-CH

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

Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
```

规范
--

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

浏览器兼容性
------

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

参见
--

* HTTP 内容协商
* 表示此 Header 的内容协商结果的消息头：`Content-Language`
* 其他类似的消息头：`TE`、`Accept-Encoding`、`Accept-Charset`、`Accept`
Save-Data
=========

Save-Data 请求头字段是一个布尔值，在请求中，表示客户端对减少数据使用量的偏好。这可能是传输成本高，连接速度慢等原因。

值为 on 时，明确表示用户选择使用客户端简化数据使用模式，并且当与源进行通信时允许他们提供替代内容以减少下载的数据，例如较小的图像和视频资源，不同的标记和样式，禁用轮询和自动更新等。

**备注：** 禁用 HTTP/2 服务器端推送 (RFC 7540, section 8.2: Server Push) 也可以用于减少数据下载。

语法
--
```

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

指令
--

<`sd-token`>

一个数值，表示客户端是否想要选择简化数据使用模式。on 表示是，而 off（默认值）表示不。

示例
--

请求头`Vary` 确保正确缓存内容（例如，当 Save-Data 标头不再存在时，确保不从缓存向用户提供较低质量的图像 [例如在从蜂窝网络切换到 Wi-Fi 后]）

### 携带 `Save-Data: on` 请求头

请求示例：
```

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


响应示例：
```

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

[...]
```

### 不携带 `Save-Data 请求头`

请求示例：
```

GET /image.jpg HTTP/1.0
Host: example.com
```


响应示例：
```

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

[...]
```

规范
--

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

浏览器兼容性
------

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

参见
--

* Help Your Users `Save-Data` - CSS Tricks
* Delivering Fast and Light Applications with Save-Data - Google Developers
* Network Information API - WICG
* Header to indicate that the content served varies by `Save-Data`: `Vary`
X-Forwarded-For
===============

**`X-Forwarded-For`**（XFF）请求标头是一个事实上的用于标识通过代理服务器连接到 web 服务器的客户端的原始 IP 地址的标头。

**警告：** 对此标头的不恰当使用可能带来安全风险。有关详细信息，请参阅安全和隐私考虑。

当客户端直接连接到服务器时，其 IP 地址被发送给服务器（并且经常被记录在服务器的访问日志中）。但是如果客户端通过正向或反向代理服务器进行连接，服务器就只能看到最后一个代理服务器的 IP 地址，这个 IP 通常没什么用。如果最后一个代理服务器是与服务器安装在同一台主机上的负载均衡服务器，则更是如此。`X-Forwarded-For` 的出现，就是为了向服务器提供更有用的客户端 IP 地址。

有关使用此标头的详细指引，请参阅解析和选择一个 IP 地址部分。

|  |  |
| --- | --- |
| 标头类型 | 请求标头 |
| 禁止修改的标头 | 否 |

此标头的标准化版本是 HTTP `Forwarded` 标头。

安全和隐私考虑
-------

按照设计的目的，此标头暴露隐私敏感信息，比如客户端的 IP 地址。因此，在应用此标头时，需要将用户的隐私问题考虑在内。

当在客户端和服务器之间没有受信任的反向代理服务器时（比如一个负载均衡服务器），`X-Forwarded-For` 标头是不可信的。如果客户端和所有的代理服务器都没有恶意且行为良好，那么此标头中的 IP 地址列表具有指令部分所描述的意义。但是如果客户端或任意代理服务器存有恶意或配置错误，那么此标头的任意部分（或整体）可能是伪造的（并且有可能不是一个列表或者甚至不包含 IP 地址）。

如果客户端和服务器之间存在任意受信任的反向代理服务器，最终 `X-Forwarded-For` 中的 IP 地址列表是可信的，因为这些 IP 是由受信任的代理服务器添加的（只要服务器*只能*通过这些代理服务器进行访问而不是可以被直接访问）。

使用 `X-Forwarded-For` 进行安全相关的操作时（比如速率限制或基于 IP 的访问控制），*必须仅*使用由受信任的代理服务器添加的 IP 地址。使用不可信的 IP，可能导致速率限制被规避、访问控制被绕过、内存耗尽，或其他与安全性或可用性相关的负面后果。

反过来，只有当使用伪造的值不会导致负面影响时，最左边的（不可信的）值才能被使用。

语法
--


```http
X-Forwarded-For: <client>, <proxy1>, <proxy2>
```


元素用逗号分隔，逗号两边可以加上空格。

指令
--

<client>

客户端的 IP 地址。

<proxy1>, <proxy2>

如果请求经过多个代理服务器，每个代理服务器的 IP 地址会依次出现在列表中。这意味着，如果客户端和代理服务器行为良好，最右边的 IP 地址会是最近的代理服务器的 IP 地址，最左边的 IP 地址会是原始客户端的 IP 地址。

示例
--


```http
X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348

X-Forwarded-For: 203.0.113.195

X-Forwarded-For: 203.0.113.195, 2001:db8:85a3:8d3:1319:8a2e:370:7348

X-Forwarded-For: 203.0.113.195,2001:db8:85a3:8d3:1319:8a2e:370:7348,150.172.238.178
```

解析
--

对 `X-Forwarded-For` 标头的不当解析可能导致伪造的值被用于安全相关的目地，造成上文提及过的负面后果。

在一个请求中可能出现多个 `X-Forwarded-For` 标头。这些标头中的 IP 地址必须被当作一个列表进行处理，从第一个标头中的第一个 IP 地址开始，直到最后一个标头中的最后一个 IP 地址结束。有两种方法生成这个列表：

* 用逗号拼接所有 `X-Forwarded-For` 标头的值，然后用逗号将其分割成一个列表
* 用逗号将每一个 `X-Forwarded-For` 标头的值都分割成一个列表，然后将这些列表合并成一个列表

只使用多个 `X-Forwarded-For` 标头中的一个是不够的。

（一些反向代理服务器会自动将多个 `X-Forwarded-For` 标头合并成一个，但是最安全的做法是不要假设就是这种情况。）

选择一个 IP 地址
----------

选择地址时，必须使用从所有 `X-Forwarded-For` 标头生成的完整 IP 列表。

当选择离客户端最近的 `X-Forwarded-For` IP 地址时（不可信并且*不用于*安全相关的目地），应该选择最左边的、第一个*有效且不是私有/内部地址*的 IP 地址。（要求”有效“是因为伪造的值可能根本就不是 IP 地址；要求“不是私有/内部地址”是因为客户端使用的代理服务器可能在它们的内部网络中，在这种情况下代理服务器可能添加了私有 IP 地址空间中的地址。）

当选择第一个*可信的* `X-Forwarded-For` 客户端 IP 地址时，需要进行额外的配置。有两种常用的方法：

* **受信任代理服务器数量**：配置了互联网和服务器之间的反向代理服务器数量。从 `X-Forwarded-For` IP 列表的最右边开始搜索，第（受信任代理服务器数量 - 1）个地址就是目标地址。（例如，如果只有一个反向代理服务器，这个代理服务器会添加客户端的 IP 地址，因此应该使用最右边的地址。如果有三个反向代理服务器，最后两个 IP 地址将是内部地址。）
* **受信任代理服务器列表**：配置了受信任反向代理服务器的 IP 或 IP 范围。从 `X-Forwarded-For` IP 列表的最右边开始搜索，跳过受信任代理服务器列表中的所有地址。第一个不匹配的地址就是目标地址。

第一个可信的 `X-Forwarded-For` IP 地址可能属于一个不受信任的中间代理服务器，而不是实际的客户计算机，但这是唯一一个适用于安全用途的 IP 了。

注意如果从互联网可直接连接到服务器——即使服务器也位于一个受信任的反向代理服务器之后——`X-Forwarded-For` IP 列表中的*任何部分*都不能被认为是可信赖的，或者可安全地用于安全相关的用途。

规范
--

不属于任何既有规范。标准版本是 `Forwarded`。

参见
--

* `Forwarded`
* `X-Forwarded-Host`
* `X-Forwarded-Proto`
* `Via`
Sec-Fetch-Mode
==============

**`Sec-Fetch-Mode`** 获取元数据标头表明了一个请求的模式。

| Header type | Fetch Metadata Request Header |
| --- | --- |
| Forbidden header name | 只要包含前缀 `Sec-` 都属于应用程序禁止修改的 HTTP 消息头，用户代理保留全部对它们的控制权 |
| CORS-safelisted request header (en-US) |  |

语法
--
```

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

值
-

`cors`

TBD

`navigate`

TBD

`nested-navigate`

TBD

`no-cors`

TBD

`same-origin`

TBD

`websocket`

TBD

示例
--

暂时没有内容

规范
--

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

浏览器兼容性
------

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

参见
--

* `Sec-Fetch-Site`
* `Sec-Fetch-User`
* `Sec-Fetch-Dest`
Sec-CH-UA-Arch
==============

**实验性:** **这是一项实验性技术**  
在将其用于生产之前，请仔细检查浏览器兼容性表格。

 **安全上下文:** 此项功能仅在一些支持的浏览器的安全上下文（HTTPS）中可用。

**`Sec-CH-UA-Arch`** 用户代理客户端提示请求标头提供了用户代理的底层 CPU 架构，例如 ARM 或 x86。

例如，服务器可以使用它来选择并提供可执行文件的正确二进制格式供用户下载。

|  |  |
| --- | --- |
| 标头类型 | Request header,
 客户端提示 |
| Forbidden header name | 是 |

语法
--


```http
Sec-CH-UA-Arch: <arch>
```

### 指令

`<arch>`

指示底层平台架构的字符串，例如 `"x86"`、`"ARM"`、`"[arm64-v8a, armeabi-v7a, armeabi]"` 等。

示例
--

服务器通过在响应客户端的某些请求时包含 `Accept-CH` 来请求 `Sec-CH-UA-Arch` 标头，并使用所需标头的名称作为令牌：


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


客户端可以选择提供提示，并将 `Sec-CH-UA-Arch` 标头添加到后续请求中。例如，在基于 Windows X86 的计算机上，客户端可能会添加如下所示标头：


```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"
```


请注意，即使服务器响应中未指定，低熵标头也会被添加到请求中。

规范
--

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

浏览器兼容性
------

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

参见
--

* 客户端提示
* 用户代理客户端提示 API (en-US)
* 通过用户代理客户端提示改善用户隐私和开发人员体验（web.dev）
* `Accept-CH`
* HTTP 缓存 > Vary 响应和 `Vary`
DPR
===

**安全上下文:** 此项功能仅在一些支持的浏览器的安全上下文（HTTPS）中可用。

**实验性:** **这是一项实验性技术**  
在将其用于生产之前，请仔细检查浏览器兼容性表格。

\*\*`DPR`\*\*请求头是“ 客户端提示” (en-US)消息头，它代表客户端设备的像素比 (DPR)，该比例是与每个 CSS 像素相对应的物理设备像素的数量。

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

**备注：** Client Hints are accessible only on secure origins (via TLS). Server has to opt in to receive `DPR` header from the client by sending `Accept-CH` and `Accept-CH-Lifetime` response headers.

语法
--
```

DPR: <number>
```

示例
--

Server first needs to opt in to receive `DPR` header by sending the response headers `Accept-CH` containing `DPR` and `Accept-CH-Lifetime`.
```

Accept-CH: DPR
Accept-CH-Lifetime: 86400
```


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

DPR: 1.0
```

浏览器兼容性
------

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

参见
--

* `Accept-CH`
* `Accept-CH-Lifetime`
* `Vary`
Age
===

**`Age`** 消息头里包含对象在缓存代理中存贮的时长，以秒为单位。.

Age 的值通常接近于 0。表示此对象刚刚从原始服务器获取不久；其他的值则是表示代理服务器当前的系统时间与此应答中的通用头 `Date` 的值之差。

| 报头类型 | Response header |
| --- | --- |
| Forbidden header name | no |

语法
--
```

Age: <delta-seconds>
```

指令
--

<delta-seconds>

一个非负整数，表示对象在缓存代理服务器中存贮的时长，以秒为单位。

示例
--
```

Age: 24
```

规范
--

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

浏览器兼容性
------

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

参见
--

* `Cache-Control`
* `Expires`