recursal/MDN huggingface dataset:
Sec-CH-UA-Full-Version-List
===========================

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

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

**`Sec-CH-UA-Full-Version-List`** 用户代理客户端提示请求标头提供用户代理的品牌和完整版本信息。

|  |  |
| --- | --- |
| 标头类型 | 请求标头、客户端提示 |
| Forbidden header name | 是 |

**`Sec-CH-UA-Full-Version-List`** 标头以逗号分隔的列表提供与每个浏览器关联的品牌的名称和完整版本信息。

品牌是用户代理的商业名称，例如：Chromium、Opera、Google Chrome、Microsoft Edge、Firefox 和 Safari。用户代理可能有多个关联的品牌。例如，Opera、Chrome 和 Edge 都基于 Chromium，并将在 **`Sec-CH-UA-Full-Version-List`** 标头中会提供这两个品牌。

因此，标头允许服务器根据共享品牌及其各自特定版本中的特定自定义项（particular customizations）来自定义其响应。

标头可能包含任何位置和任何名称的“假冒”品牌。此功能旨在防止服务器直接拒绝未知用户代理，迫使用户代理在其品牌标识上撒谎。

**备注：** 这类似于 `Sec-CH-UA`，但包含完整的版本号，而不是每个品牌的重要版本号。

语法
--

用户代理品牌列表中以逗号分隔的品牌列表及其关联的完整版本号。单个条目的语法具有以下格式：


```http
Sec-CH-UA-Full-Version-List: "<brand>";v="<full version>", ...
```

### 指令

`<brand>`

 与用户代理相关的品牌，如“Chromium”和“Google Chrome”。
 这可能是一个故意不正确的品牌，如 `" Not A;Brand"` 或 `"(Not(A:Brand"`（实际值是预期随时间变化且不可预测的）。


`<full version>`

完整的版本号，例如 98.0.4750.0。

示例
--

服务器通过在来自客户端的任何请求的*响应*中包含 `Accept-CH` 来请求 `Sec-CH-UA-Full-Version-List` 标头，并使用所需标头的名称作为令牌：


```http
HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Full-Version-List
```


客户端可以选择提供提示，并将 `Sec-CH-UA-Full-Version-List` 标头添加到后续请求中，如下所示：


```http
GET /my/page HTTP/1.1
Host: example.site

Sec-CH-UA: " Not A;Brand";v="99", "Chromium";v="98", "Google Chrome";v="98"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Full-Version-List: " Not A;Brand";v="99.0.0.0", "Chromium";v="98.0.4750.0", "Google Chrome";v="98.0.4750.0"
Sec-CH-UA-Platform: "Linux"
```

规范
--

| Specification |
| --- |
| User-Agent Client Hints # sec-ch-ua-full-version-list |

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

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

请求首部 **`DNT`** (**D**o **N**ot **T**rack) 表明了用户对于网站追踪的偏好。它允许用户指定自己是否更注重个人隐私还是定制化内容。

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

语法
--
```

DNT: 0
DNT: 1
```

指令
--

0

表示用户愿意目标站点追踪用户个人信息。

1

表示用户不愿意目标站点追踪用户个人信息。

示例
--

### 使用 JavaScript 读取“不追踪”（Do Not Track）状态

用户对 DNT 的设置还可以使用 `Navigator.doNotTrack` 属性进行读取：


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

规范
--

#### 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.

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

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

相关内容
----

* `Navigator.doNotTrack`
* `Tk` header
* Do Not Track on Wikipedia
* "Do Not Track"中的"Track"指什么？– EFF
* donottrack.us
* DNT 浏览器设置帮助：
    + Firefox
    + Chrome
Digest
======

**`Digest`** 响应 HTTP 头提供了请求资源一个 摘要 。

在 RFC 7231 术语中，它是一个资源的选定表示。这个选定代表依赖于 `Content-Type` 和 `Content-Encoding` 头部值：所以一个单一的资源可能有多个不同的摘要值。

摘要是整个表示的计算。这个表示可以是：

* 完全包含在响应消息体中
* 完全不包含在消息体中中 (例如，在一个 `HEAD` 请求的响应中)
* 部分包含在消息体中 (例如，在一个 range request 的响应中)。

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

语法
--
```

Digest: <digest-algorithm>=<digest-value>

Digest: <digest-algorithm>=<digest-value>,<digest-algorithm>=<digest-value>
```

指令
--

`<digest-algorithm>`

已支持的摘要算法在 RFC 3230 和 RFC 5843,中定义，包括 `SHA-256` 和 `SHA-512`。一些支持的算法 (如 `unixsum` 和 `MD5`) 容易发生冲突，因此不适合冲突阻力很重要的应用。

`<digest-value>`

对资源表示的摘要算法的结果和编码的结果。摘要算法的选择决定了编码类型：例如 `SHA-256` 用 base64 编码。

示例
--
```

Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=,unixsum=30637
```

规范
--

| Specification |
| --- |
| Digest Fields # section-3 |

该头最初在 RFC 3230 中定义，但在 RFC 7231 里的 "选中的表示" 定义使原始定与当前 HTTP 规范中不一致。发布时，"HTTP 资源摘要" 草案将废弃 RFC 3230 并将更新标准以保持一致。

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

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

参见
--

* `Want-Digest` (en-US)
* HTTP range requests
* `206 Partial Content`
Accept-Ranges
=============

服务器使用 HTTP 响应头 **`Accept-Ranges`** 标识自身支持范围请求 (partial requests)。字段的具体值用于定义范围请求的单位。

当浏览器发现`Accept-Ranges`头时，可以尝试*继续*中断了的下载，而不是重新开始。

| 头部类型 | Response header |
| --- | --- |
| Forbidden header name（禁止修改的 HTTP 头） | 否 |

语法
--
```

Accept-Ranges: bytes
Accept-Ranges: none
```

指令
--

`none`

不支持任何范围请求单位，由于其等同于没有返回此头部，因此很少使用。不过一些浏览器，比如 IE9，会依据该头部去禁用或者移除下载管理器的暂停按钮。

`bytes`

范围请求的单位是 bytes（字节）。

示例
--
```

Accept-Ranges: bytes
```

规范
--

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

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

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

参见
--

* `If-Range`
* `Range`
Content-Length
==============

**`Content-Length`** 是一个实体消息首部，用来指明发送给接收方的消息主体的大小，即用十进制数字表示的八位元组的数目。

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

语法
--
```

Content-Length: <length>
```

指令
--

<length>

消息的长度，用十进制数字表示的八位字节的数目。

规范
--

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

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

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

相关内容
----

* `Transfer-Encoding`
Timing-Allow-Origin
===================

响应头 **`Timing-Allow-Origin`** 用于指定特定站点，以允许其访问Resource Timing API提供的相关信息，否则这些信息会由于跨源限制将被报告为零

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

语法
--
```

Timing-Allow-Origin: *
Timing-Allow-Origin: <origin>[, <origin>]*
```

指令
--

\*

服务器可以以“`*`”作为通配符，从而允许所有域都具有访问定时信息的权限。

<origin>

指定一个可以访问资源的 URI。你也可以通过逗号隔开，指定多个 URI。

示例
--

如需允许任何资源都可以看到的计时 (timing) 信息，你可以如此设置：
```

Timing-Allow-Origin: *
```


如需允许`https://developer.mozilla.org`查看你的计时信息，你可以设置：
```

Timing-Allow-Origin: https://developer.mozilla.org
```

规范
--

| Specification |
| --- |
| Resource Timing # sec-timing-allow-origin |

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

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

参见
--

* Resource Timing（概览）
* `Vary`
Authorization
=============

HTTP **`Authorization`** 请求标头用于提供服务器验证用户代理身份的凭据，允许访问受保护的资源。

**`Authorization`** 标头通常在用户代理首次尝试请求受保护的资源（没有携带凭据）之后发送的，但并不总是发送。服务器响应一条 `401` `Unauthorized` 信息，其中包含至少一个 `WWW-Authenticate` 标头。该标头表示哪些身份验证的方案可用于访问资源（以及客户端使用它们时需要的额外的信息）。用户代理应该从这些提供的身份验证方案中选择它支持的最安全的身份验证方案，并提示用户提供凭据，然后重新获取资源（包含 **`Authorization`** 标头中编码的凭据）。

**备注：** 此标头是通用的 HTTP 认证框架的一部分。它可以与许多身份验证方案一起使用。


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

语法
--


```http
Authorization: <auth-scheme> <authorization-parameters>
```


Basic 身份验证


```http
Authorization: Basic <credentials>
```


Digest 身份验证


```http
Authorization: Digest username=<username>,
 realm="<realm>",
 uri="<url>",
 algorithm=<algorithm>,
 nonce="<nonce>",
 nc=<nc>,
 cnonce="<cnonce>",
 qop=<qop>,
 response="<response>",
 opaque="<opaque>"
```

指令
--

`<auth-scheme>`

身份验证方案定义了凭据如何编码。一些常见的类型是（不区分大小写）：`Basic`、`Digest`、`Negotiate` 和 `AWS4-HMAC-SHA256`。

**备注：** 有关更多信息/选项，请参阅 HTTP 身份验证 > 身份验证方案


除 `<auth-scheme>` 外，其余指令特定于每个身份验证方案。通常，你需要检查这些方案的相关规范（下面列出了一小部分方案的要点）。

### Basic

<credentials>

凭据，根据指定的方案编码。

**备注：** 有关编码算法的信息，请参阅以下示例：`WWW-Authenticate`、HTTP 身份验证方案和相关规范。

### Digest

<response>

证明用户知道该密码，它是该密码的十六进制数字字符串形式。该算法对用户名和密码、realm、cnonce、qop、nc 等进行编码。它在规范中进行了详细描述。

`username`

带引号的字符串，其中包含指定 `realm` 的用户名，可以是纯文本，也可以是十六进制表示的哈希编码。如果名称包含字段中不允许的字符，则可以使用 `username*` 替换它（而不是“同时包含两者”）。

`username*`

使用 RFC5987 中定义的扩展符号格式化的用户名。只有当名称无法在 `username` 中编码并且 `userhash` 设置为 `"false"` 时，才应使用此字段。

`uri`

*有效的请求 URI*。有关更多信息，请参阅规范。

`realm`

请求的用户名/密码的 realm（同样，应该与所请求资源中对应的 `WWW-Authenticate` 响应中的值相匹配）。

`opaque`

所请求资源中对应的 `WWW-Authenticate` 响应中的值。

`algorithm`

用于计算 digest 的算法。必须是所请求资源的 `WWW-Authenticate` 响应中支持的算法。

`qop`

指示应用于消息的*保护质量*的令牌。必须与在 `WWW-Authenticate` 响应中，为被请求的资源指定的集合中的一个值匹配。

* `"auth"`：身份验证
* `"auth-int"`：有完整保护的身份验证

`cnonce`

客户端提供的带引号的 ASCII 字符串值。客户端和服务器都使用它来提供相互身份验证，提供一些消息完整性保护，并避免“选择明文攻击”。有关更多信息，请参阅规范。

`nc`

随机数。客户端发送当前 `cnonce` 值（包括当前请求）的请求的十六进制计数。服务器可以使用重复的 `nc` 值来识别重放请求。

`userhash` 可选

如果用户名已经被哈希运算，则为 `"true"`。默认情况下是 `"false"`。

示例
--

### Basic 身份验证

对于 `"Basic"` 身份验证，凭据首先将用户名和密码使用一个冒号（`aladdin:opensesame`）相结合，然后将生成的字符串编码为 `base64`（`YWxhZGRpbjpvcGVuc2VzYW1l`）。


```http
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```


**警告：** Base64 编码很容易被解码，以得到原始的名称和密码，所以 Basic 身份验证是完全不安全的。当时用身份验证时，总是推荐使用 HTTPS，而在使用 `Basic` 身份验证时，更是如此。

有关如何配置 Apache 或 Nginx 服务器，以通过 HTTP basic 身份验证保护你的网站，请参见 HTTP 身份验证。

规范
--

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

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

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

参见
--

* HTTP 身份验证
* `WWW-Authenticate`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `401`、`403`、`407`
Keep-Alive
==========

**`Keep-Alive`** 是一个通用消息头，允许消息发送者暗示连接的状态，还可以用来设置超时时长和最大请求数。

**备注：** 需要将 The `Connection` 首部的值设置为 "keep-alive" 这个首部才有意义。同时需要注意的是，在 HTTP/2 协议中， `Connection` 和 `Keep-Alive` 是被忽略的；在其中采用其他机制来进行连接管理。


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

语法
--
```

Keep-Alive: parameters
```

指令
--

*parameters*

一系列用逗号隔开的参数，每一个参数由一个标识符和一个值构成，并使用等号 (`'='`) 隔开。下述标识符是可用的：

* `timeout`：指定了一个空闲连接需要保持打开状态的最小时长（以秒为单位）。需要注意的是，如果没有在传输层设置 keep-alive TCP message 的话，大于 TCP 层面的超时设置会被忽略。
* `max`：在连接关闭之前，在此连接可以发送的请求的最大值。在非管道连接中，除了 0 以外，这个值是被忽略的，因为需要在紧跟着的响应中发送新一次的请求。HTTP 管道连接则可以用它来限制管道的使用。

示例
--

`含有 Keep-Alive` 首部的响应示例：
```

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Thu, 11 Aug 2016 15:23:13 GMT
Keep-Alive: timeout=5, max=1000
Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT
Server: Apache

(body)
```

规范
--

| Specification |
| --- |
| HTTP/1.1 # compatibility.with.http.1.0.persistent.connections |

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

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

相关内容
----

* `Connection`
* Connection management in HTTP/1.x
Expect
======

**`Expect`** 是一个请求消息头，包含一个期望条件，表示服务器只有在满足此期望条件的情况下才能妥善地处理请求。

规范中只规定了一个期望条件，即 `Expect: 100-continue`, 对此服务器可以做出如下回应：

* `100` 如果消息头中的期望条件可以得到满足，使得请求可以顺利进行的话，
* `417` (Expectation Failed) 如果服务器不能满足期望条件的话；也可以是其他任意表示客户端错误的状态码（4xx）。

例如，如果请求中 `Content-Length` 的值太大的话，可能会遭到服务器的拒绝。

常见的浏览器不会发送 `Expect` 消息头，但是其他类型的客户端如 cURL 默认会这么做。

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

语法
--

目前规范中只规定了 "100-continue" 这一个期望条件。
```

Expect: 100-continue
```

指令
--

100-continue

通知接收方客户端要发送一个体积可能很大的消息体，期望收到状态码为`100` (Continue) 的临时回复。

示例
--

### 大消息体

客户端发送带有 Expect 消息头的请求，等服务器回复后再发送消息体。
```

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue
```


服务器开始检查请求消息头，可能会返回一个状态码为 `100` (Continue) 的回复来告知客户端继续发送消息体，也可能会返回一个状态码为`417` (Expectation Failed) 的回复来告知对方要求不能得到满足。

规范
--

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

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

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

参见
--

* `417` `Expectation Failed`
* `100` `Continue`
Content-Location
================

**`Content-Location`** 首部指定的是要返回的数据的地址选项。最主要的用途是用来指定要访问的资源经过内容协商后的结果的 URL。

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

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

语法
--
```

Content-Location: <url>
```

指令
--

<url>

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

示例
--
```

Content-Location: /index.html
```

规范
--

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

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

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

相关内容
----

* `Location`
Max-Forwards
============

**`Max-Forwards`** 请求标头被用于限制 `TRACE` 方法可经过的服务器（通常指代理服务器）数目。它的值是一个整数，指定可经过的服务器最大数目。服务器在转发 `TRACE` 请求之前，将递减 `Max-Forwards` 的值，直到到达目标服务器，或服务器接收到 `Max-Forwards` 的值为 0 的请求。而后直接返回一个 `200 OK` 的响应（可以包含一些标头）。

如果 `TRACE` 请求中没有 `Max-Forwards` 标头，就可以认为，不限制可经过的服务器最大数目。

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

语法
--


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

示例
--


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

规范
--

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

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

此特性既不针对浏览器，也不在浏览器中实现。

参见
--

* HTTP `TRACE` 方法
X-DNS-Prefetch-Control
======================

**`X-DNS-Prefetch-Control`** 头控制着浏览器的 DNS 预读取功能。DNS 预读取是一项使浏览器主动去执行域名解析的功能，其范围包括文档的所有链接，无论是图片的，CSS 的，还是 JavaScript 等其他用户能够点击的 URL。

因为预读取会在后台执行，所以 DNS 很可能在链接对应的东西出现之前就已经解析完毕。这能够减少用户点击链接时的延迟。

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

语法
--
```

X-DNS-Prefetch-Control: on
X-DNS-Prefetch-Control: off
```

### 参数

on

启用 DNS 预解析。在浏览器支持 DNS 预解析的特性时即使不使用该标签浏览器依然会进行预解析。

off

关闭 DNS 预解析。这个属性在页面上的链接并不是由你控制的或是你根本不想向这些域名引导数据时是非常有用的。

介绍
--

DNS 请求需要的带宽非常小，但是延迟却有点高，这一点在手机网络上特别明显。预读取 DNS 能让延迟明显减少一些，例如在用户点击链接时。在某些情况下，延迟能减少一秒钟。

在某些浏览器中这个预读取的行为将会与页面实际内容并行发生（而不是串行）。正因如此，某些高延迟的域名的解析过程才不会卡住资源的加载。

这样可以极大的加速（尤其是移动网络环境下）页面的加载。在某些图片较多的页面中，在发起图片加载请求之前预先把域名解析好将会有至少 5% 的图片加载速度提升。

### 在浏览器中设置预读取配置

一般来说并不需要去管理预读取，但是可能会有用户希望关闭预读取功能。这时只需要将 `network.dns.disablePrefetch` 选项值设置为 `true` 就可以了。

另外，默认情况下，通过 HTTPS 加载的页面上内嵌链接的域名并不会执行预加载。在 Firefox 浏览器中，可以通过 about:config 设置 `network.dns.disablePrefetchFromHTTPS` 值为 `false` 来改变这一默认行为。

示例
--

### 打开和关闭 DNS 预读取

你可以通过在服务器端发送 `X-DNS-Prefetch-Control` 报头，或是在文档中使用值为 `http-equiv` 的 `<meta>` 标签：
```

<meta http-equiv="x-dns-prefetch-control" content="off">
```


你可以通过将 `content` 的参数设置为“`on`”来改变设置。

### 强制查询特定主机名

你可以通过使用 `rel` 属性值为 link type 中的 `dns-prefetch` 的 `<link>` 标签来对特定域名进行预读取：


```html
<link rel="dns-prefetch" href="http://www.spreadfirefox.com/" />
```


在这个例子中，Firefox 将预解析域名"www.spreadfirefox.com"。

而且，`<link>` 元素也可以使用不完整的 URL 的主机名来标记预解析，但这些主机名前必需要有双斜线：


```html
<link rel="dns-prefetch" href="//www.spreadfirefox.com" />
```


强制对域名进行预读取在一些情况下很有用，比如，在网站的主页上，强制在整个网站上频繁引用的域名的预解析，即使它们不在主页本身上使用。即使主页的性能可能不受影响，这将提高整体站点性能。

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

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

参考
--

* DNS Prefetching for Firefox (blog post)
* Google Chrome handles DNS prefetching control
Proxy-Authorization
===================

**`Proxy-Authorization`** 是一个请求首部，其中包含了用户代理提供给代理服务器的用于身份验证的凭证。这个首部通常是在服务器返回了 `407` `Proxy Authentication Required` 响应状态码及 `Proxy-Authenticate` 首部后发送的。

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

语法
--
```

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

指令
--

<type>

身份验证类型。一个常见的类型是 "基本验证"。IANA 机构维护了 一系列的身份验证机制。

<credentials>

凭证的构成方式如下：

* 将用户名和密码用冒号拼接（aladdin:opensesame）。
* 将拼接生成的字符串使用 base64 编码方式进行编码（YWxhZGRpbjpvcGVuc2VzYW1l）。

**备注：** Base64 编码方式不是用来加密或者获取摘要的！这种方法的安全性相当于将凭证使用明文发送（base64 是一种可逆编码方式）。在使用基本身份验证方式的时候推荐与 HTTPS 搭配使用。

示例
--
```

Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

规范
--

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

相关内容
----

* HTTP authentication
* `Proxy-Authenticate`
* `WWW-Authenticate`
* `Authorization`
* `401`, `403`, `407`
Access-Control-Allow-Credentials
================================

**`Access-Control-Allow-Credentials`** 响应头用于在请求要求包含 credentials（`Request.credentials` 的值为 `include`）时，告知浏览器是否可以将对请求的响应暴露给前端 JavaScript 代码。

当请求的 credentials 模式（`Request.credentials`）为 `include` 时，浏览器仅在响应标头 `Access-Control-Allow-Credentials` 的值为 `true` 的情况下将响应暴露给前端的 JavaScript 代码。

Credentials 可以是 cookies、authorization headers 或 TLS client certificates。

当作为对预检请求的响应的一部分时，这能表示是否真正的请求可以使用 credentials。注意简单的`GET` 请求没有预检，所以若一个对资源的请求带了 credentials，如果这个响应头没有随资源返回，响应就会被浏览器忽视，不会返回到 web 内容。

`Access-Control-Allow-Credentials` 标头需要与 `XMLHttpRequest.withCredentials` 或 Fetch API 的 `Request()` 构造函数中的 `credentials` 选项结合使用。Credentials 必须在前后端都被配置（即 `Access-Control-Allow-Credentials` header 和 XHR 或 Fetch request 中都要配置）才能使带 credentials 的 CORS 请求成功。

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

语法
--
```

Access-Control-Allow-Credentials: true
```

指令
--

true

这个头的唯一有效值（区分大小写）。如果不需要 credentials，相比将其设为 false，请直接忽视这个头。

例子
--

允许 credentials:
```

Access-Control-Allow-Credentials: true
```


使用带 credentials 的 XHR：


```js
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://example.com/", true);
xhr.withCredentials = true;
xhr.send(null);
```


使用带 credentials 的 Fetch：


```js
fetch(url, {
  credentials: "include",
});
```

规范
--

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

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

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

参见
--

* `XMLHttpRequest.withCredentials`
* `Request()`
Access-Control-Request-Headers
==============================

请求头 **`Access-Control-Request-Headers`** 出现于 preflight request（预检请求）中，用于通知服务器在真正的请求中会采用哪些请求头。

| 报头类型 | Request header |
| --- | --- |
| Forbidden header name | yes |

语法
--
```

Access-Control-Request-Headers: <header-name>, <header-name>, ...
```

指令
--

<header-name>

在实际请求中将要包含的一系列 HTTP 头，以逗号分隔。

示例
--
```

Access-Control-Request-Headers: X-PINGOTHER, Content-Type
```

规范
--

| Specification |
| --- |
| Fetch Standard # http-access-control-request-headers |

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

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

相关内容
----

* `Access-Control-Request-Method`
TE
==

**`TE`** 请求型头部用来指定用户代理希望使用的传输编码类型。(可以将其非正式称为 `Accept-Transfer-Encoding`，这个名称显得更直观一些)。

可以参考 `Transfer-Encoding` 来获取更多关于传输编码的细节信息。值得注意的是，支持 HTTP/1.1 协议的接收方一定可以处理 `chunked` 传输编码请求，所以没有必要一定在 `TE` 首部指定“chunked”关键字。然而，如果客户端将要接收编码在 chunked 包体里面的"trailer"信息的时候，主动指定该头部将会非常有用。

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

语法
--
```

TE: compress
TE: deflate
TE: gzip
TE: trailers

// 多个指令，使用 quality value 语法来表示优先级：
TE: trailers, deflate;q=0.5
```

指令
--

`compress`

这个名称代表采用了 Lempel-Ziv-Welch (LZW) 压缩算法的传输编码格式。

`deflate`

这个名称代表采用了 zlib 结构的传输编码格式。

`gzip`

这个名称代表采用了 Lempel-Ziv coding (LZ77) 压缩算法，以及 32 位 CRC 校验的传输编码格式。

trailers

表示客户端期望在采用分块传输编码的响应中接收挂载字段。

q

当多种形式的传输编码格式都可以接受的时候，这个采用了质量价值语法的参数可以用来对不同的编码形式按照优先级进行排序。

规范
--

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

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

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

相关资料
----

* `Transfer-Encoding`
* `Trailer`
* Chunked transfer encoding
Sec-Fetch-Site
==============

**`Sec-Fetch-Site`** 获取元数据标头表明了一个请求发起者的来源与目标资源来源之间的关系。

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

语法
--
```

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

值
-

`cross-site`

TBD

`same-origin`

TBD

`same-site`

TBD

`none`

这一请求与任意上下文无关，例如站点、源，或者框架。当用户采用某些方式发起请求时该值会被使用，例如：直接在地址栏中输入 URL、打开一个书签，或者往浏览器窗口中拖放一个文件。

示例
--

暂时没有内容

规范
--

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

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

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

参见
--

* `Sec-Fetch-Mode`
* `Sec-Fetch-User`
* `Sec-Fetch-Dest`
Clear-Site-Data
===============

**`Clear-Site-Data`** 响应头，表示清除当前请求网站有关的浏览器数据（cookie，存储，缓存）。它让 Web 开发人员对浏览器本地存储的数据有更多控制能力。

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

语法
--

`Clear-Site-Data` 可以接受一个或多个参数，如果想要清除所有类型的数据，可以使用通配符 (`"*"`)
```

// 单个参数
Clear-Site-Data: "cache"

// 多个参数 (用逗号分隔)
Clear-Site-Data: "cache", "cookies"

// 通配
Clear-Site-Data: "*"
```

指令
--

`"cache"`

表示服务端希望删除本 URL 原始响应的本地缓存数据（即：浏览器缓存，请参阅 HTTP 缓存）。根据浏览器的不同，可能还会清除预渲染页面，脚本缓存，WebGL 着色器缓存或地址栏建议等内容。

`"cookies"`

表示服务端希望删除 URL 响应的所有 cookie。HTTP 身份验证凭据也会被清除。会影响整个主域，包括子域。所以 `https://example.com` 以及 `https://stage.example.com` 的 Cookie 都会被清除。

`"storage"`

表示服务端希望删除 URL 原响应的所有 DOM 存储。这包括存储机制，如

* localStorage (执行 `localStorage.clear`),
* sessionStorage (执行 `sessionStorage.clear`),
* IndexedDB (对每个库执行 `IDBFactory.deleteDatabase` (en-US)),
* 服务注册线程 (对每个服务之注册线程执行 `ServiceWorkerRegistration.unregister`),
* AppCache,
* WebSQL 数据库，
* FileSystem API data,
* Plugin data (Flash via `NPP_ClearSiteData`).

`"executionContexts"`

表示服务端希望浏览器重新加载本请求 (`Location.reload`).

`"*"` (通配符)

表示服务端希望清除原请求响应的所有类型的数据。如果在此头的未来版本中添加了更多数据类型，它们也将被涉及。

示例
--

### 登出

如果用户退出你的网站或服务，你可能希望删除本地存储的数据。你可以通过在 `https://example.com/logout` 的响应头增加 Clear-Site-Data，以达到目的：
```

Clear-Site-Data: "cache", "cookies", "storage", "executionContexts"
```

### 清除 cookie

如果它在 `https://example.com/clear-cookies` 的响应头中出现，则同一域 `https://example.com` 和所有子域（如 `https://stage.example.com` 等）中的所有 Cookie，将都被清除。
```

Clear-Site-Data: "cookies"
```

规范
--

| Specification |
| --- |
| Clear Site Data # header |

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

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

参见
--

* `Cache-Control`
Device-Memory
=============

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

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

**`Device-Memory`** 是一个跟 Device Memory API (en-US) 相关的请求头，它跟 Client Hints (en-US) 请求头的作用相似，用来表示客户端设备内存的近似大小。

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

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

语法
--

设备的内存大小可能会被用作指纹变量，因此将这个取值设置的比较粗糙，以减少滥用它的可能性。请求头采用以下值：0.25、0.5、1、2、4、8。
```

Device-Memory: <number>
```

示例
--

服务器需要先发送包含 `Device-Memory` 的 `Accept-CH` 和 `Accept-CH-Lifetime` 响应头，来表明可以接收 `Device-Memory` 请求头。
```

Accept-CH: Device-Memory
Accept-CH-Lifetime: 86400
```


接下来客户端发送的请求则可能会包含 `Device-Memory` 请求头：
```

Device-Memory: 1
```

规范
--

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

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

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

参见
--

* Device Memory API (en-US)
* `Accept-CH`
* `Accept-CH-Lifetime`
* `Vary`
* `Navigator.deviceMemory`
Transfer-Encoding
=================

**`Transfer-Encoding`** 消息首部指明了将 entity 安全传递给用户所采用的编码形式。

`Transfer-Encoding` 是一个逐跳传输消息首部，即仅应用于两个节点之间的消息传递，而不是所请求的资源本身。一个多节点连接中的每一段都可以应用不同的`Transfer-Encoding` 值。如果你想要将压缩后的数据应用于整个连接，那么请使用端到端传输消息首部 `Content-Encoding` 。

当这个消息首部出现在 `HEAD` 请求的响应中，而这样的响应没有消息体，那么它其实指的是应用在相应的 `GET` 请求的应答的值。

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

语法
--
```

Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip
Transfer-Encoding: identity

// Several values can be listed, separated by a comma
Transfer-Encoding: gzip, chunked
```

指令
--

`chunked`

数据以一系列分块的形式进行发送。 `Content-Length` 首部在这种情况下不被发送。。在每一个分块的开头需要添加当前分块的长度，以十六进制的形式表示，后面紧跟着 '`\r\n`' ，之后是分块本身，后面也是'`\r\n`' 。终止块是一个常规的分块，不同之处在于其长度为 0。终止块后面是一个挂载（trailer），由一系列（或者为空）的实体消息首部构成。

`compress`

 采用 Lempel-Ziv-Welch (LZW) 压缩算法。这个名称来自 UNIX 系统的 *compress* 程序，该程序实现了前述算法。
 与其同名程序已经在大部分 UNIX 发行版中消失一样，这种内容编码方式已经被大部分浏览器弃用，部分因为专利问题（这项专利在 2003 年到期）。


`deflate`

采用 zlib 结构 (在 RFC 1950 中规定)，和 *deflate* 压缩算法 (在 RFC 1951 中规定)。

`gzip`

表示采用 Lempel-Ziv coding (LZ77) 压缩算法，以及 32 位 CRC 校验的编码方式。这个编码方式最初由 UNIX 平台上的 *gzip* 程序采用。处于兼容性的考虑，HTTP/1.1 标准提议支持这种编码方式的服务器应该识别作为别名的 `x-gzip` 指令。

`identity`

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

示例
--

### 分块编码

分块编码主要应用于如下场景，即要传输大量的数据，但是在请求在没有被处理完之前响应的长度是无法获得的。例如，当需要用从数据库中查询获得的数据生成一个大的 HTML 表格的时候，或者需要传输大量的图片的时候。一个分块响应形式如下：
```

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
\r\n
```

规范
--

| Specification |
| --- |
| HTTP/1.1 # field.transfer-encoding |

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

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

参见
--

* `Accept-Encoding`
* `Content-Encoding`
* `Content-Length`
* Header fields that regulate the use of trailers: `TE` (requests) and `Trailer` (responses).
* Chunked transfer encoding