Accept-Encoding - HTTP

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

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

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

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

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

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

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

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

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

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`


WWW-Authenticate - HTTP

WWW-Authenticate
================

HTTP **`WWW-Authenticate`** 响应标头定义了 HTTP 身份验证的方法（“质询”），它用于获取特定资源的访问权限。

**备注：** 该标头是通用的 HTTP 认证框架的一部分，可用于多种身份验证方案。每个“质询”都列出了服务器支持的方案以及为该方案类型添加的额外参数。

使用 HTTP 身份验证的服务器将以 `401` `Unauthorized` 响应去响应受保护资源的请求。该响应必须包含至少一个 `WWW-Authenticate` 标头和至少一个质询，以指示使用哪些身份验证方案访问资源（以及每个特定方案的任意额外的数据）。

一个 `WWW-Authenticate` 标头中允许多个质询，并且一个响应中允许多个 `WWW-Authenticate` 标头。服务器也可以在其他的响应消息中包含 `WWW-Authenticate` 标头，以指示提供的凭据可能会影响响应。

客户端在接收 `WWW-Authenticate` 标头之后，通常会提示用户接收凭据，然后重新请求资源。这个新的请求会使用 `Authorization` 标头向服务器提供凭据，并针对所选择的“质询”身份验证方法进行合适的编码。客户端应该选择它理解的最安全的质询（注意，在某些情况下，“最安全”方法是有争议的）。

|  |  |
| --- | --- |
| 标头类型 | 响应标头 |
| 禁止修改的标头 | 否 |

语法
--

至少指定一个质询。可以在多个标头或者单独的标头中指定多个质询，以逗号分隔：

```http
// Challenges specified in single header
WWW-Authenticate: challenge1, ..., challengeN

// Challenges specified in multiple headers
WWW-Authenticate: challenge1
...
WWW-Authenticate: challengeN
```

单个质询有着以下的格式。请注意，这些方案的 token（`<auth-scheme>`）是强制性的。`realm`、`token68` 以及其他参数的存在依赖于所选方案的定义。

```http
// Possible challenge formats (scheme dependent)
WWW-Authenticate: <auth-scheme>
WWW-Authenticate: <auth-scheme> realm=<realm>
WWW-Authenticate: <auth-scheme> token68
WWW-Authenticate: <auth-scheme> auth-param1=token1, ..., auth-paramN=auth-paramN-token
WWW-Authenticate: <auth-scheme> realm=<realm> token68
WWW-Authenticate: <auth-scheme> realm=<realm> token68 auth-param1=auth-param1-token , ..., auth-paramN=auth-paramN-token
WWW-Authenticate: <auth-scheme> realm=<realm> auth-param1=auth-param1-token, ..., auth-paramN=auth-paramN-token
WWW-Authenticate: <auth-scheme> token68 auth-param1=auth-param1-token, ..., auth-paramN=auth-paramN-token
```

例如，Basic 身份验证允许可选的 `realm` 和 `charset` 密钥，但是并不支持 `token68`。

```http
WWW-Authenticate: Basic
WWW-Authenticate: Basic realm=<realm>
WWW-Authenticate: Basic realm=<realm>, charset="UTF-8"
```

指令
--

`<auth-scheme>`

身份验证方案。一些更常见的类型是（不区分大小写）：`Basic`、`Digest`、`Negotiate` 和 `AWS4-HMAC-SHA256`。

**备注：** 更多信息和选项，请参见 HTTP 身份验证 > 身份验证方案

**realm=**<realm> 可选

描述受保护区域的字符串。realm 允许服务器对它受保护的区域进行区分（如果允许支持这种划分方案），并通知用户需要哪个特定的用户名/密码。如果未指定 realm，客户端通常会显示格式化的主机名。

`<token68>` 可选

一个 token，可能对某些方案有用。该 token 允许使用 66 个未保留的 URI 字符以及其他的一些字符。根据规范，它可以支持 base64、base64url、base32 或者 base16（十六进制）编码，有或者没有填充，但是不包括空格。

除了 `<auth-scheme>` 和关键字 `realm`，authorization 参数特定于每个身份验证方案。总的来说，你将需要为这些检查相关的规范（下面列出了一小部分方案的关键字）。

### Basic

`<realm>` 可选

见上方。

`charset="UTF-8"` 可选

当提交用户名和密码时，告诉客户端服务器的首选编码方案。仅允许的值是不区分大小写的“UTF-8”字符串。这与 realm 字符串的编码无关。

### Digest

`<realm>` 可选

一个指示要使用的用户名/密码的字符串。至少应该包括主机名，但是可能指示具有访问权限的用户或组。

`domain` 可选

一个带引号，以空格分隔的 URI 前缀列表，定义了可以使用身份验证信息的所有位置。如果未指定此关键字，则可以在 web 根目录的任意位置使用身份验证信息。

`nonce`

一个服务器指定的带引号的字符串，在每次的 401 响应期间，服务器可以使用它去验证指定的凭据。这必须是在每次 401 响应时唯一的生成，并且可以更频繁地重新生成（例如，允许一个摘要仅使用一次）。该规范包含有关生成此值算法的建议。nonce 值对客户端是不透明的。

`opaque`

一个服务器指定的带引号的字符串，应在 `Authorization` 中原封不动的返回。这对客户端是不透明的。建议服务器包含 Base64 或十六进制数据。

`stale` 可选

一个不区分大小写的标志，指示客户端之前的请求因 `nonce` 太旧了（过期）而被拒绝。如果为 `true`，则可以使用新的 `nonce` 加密相同用户名/密码重试请求。如果它是任意其他的值，那么用户名/密码无效，并且必须向用户重新请求。

`algorithm` 可选

algorithm 被用于产生一个摘要。有效的非会话值是：`"MD5"`（如果未指定，则是默认）、`"SHA-256"`、`"SHA-512"`。有效的会话值是：`"MD5-sess"`、`"SHA-256-sess"`、`"SHA-512-sess"`。

`qop`

带引号的字符串，表示服务器支持的保护程度。这必须提供，并且必须忽略无法识别的选项。

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

`charset="UTF-8"` 可选

当提交用户名和密码时，告诉客户端服务器的首选编码方案。仅允许的值是不区分大小写的“UTF-8”字符串。

`userhash` 可选

服务器可能指定为 `"true"`，以指示它支持用户名哈希（默认是 `"false"`）。

示例
--

### Basic 身份验证

仅支持 basic 身份验证的服务器，可能有如下所示的 `WWW-Authenticate` 响应标头：

```http
WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"
```

用户代理接收到该标头，首先将提示用户输入他们的用户名和密码，然后重新请求资源：这次在 `Authorization` 标头中会包含（编码的）凭据。`Authorization` 标头看起来可能像这样。

```http
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

对于 `"Basic"` 身份验证，凭据的构造方式是，首先将用户名和密码与冒号组合（`aladdin:opensesame`），然后将结果字符串编码为 `base64`（`YWxhZGRpbjpvcGVuc2VzYW1l`）。

**备注：** 有关如何配置 Apache 或 Nginx 服务器以使用 HTTP 基本身份验证密码保护你站点的示例，另请参阅 HTTP 身份验证。

### 使用 SHA-256 和 MD5 的 Digest 身份验证

**备注：** 该示例取自 RFC 7616“HTTP Digest Access Authentication”（在规范中的其他示例，展示了 `SHA-512`、`charset` 和 `userhash` 的使用）。

客户端试图访问“`http://www.example.org/dir/index.html`”处的文档，该文档受到 digest 身份验证的保护。这个文档的用户名是“Mufsas”，并且它的密码是“Circle of Life”（注意，每个单词之间的单个空格）。

客户端第一次请求该文档时，不会发送 `Authorization` 标头字段。在这里，服务器使用 HTTP 401 消息响应，其中包括对它支持的每个摘要算法的质询，按照其优先顺序（`SHA256`，然后是 `MD5`）。

```http
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
 realm="http-auth@example.org",
 qop="auth, auth-int",
 algorithm=SHA-256,
 nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
 opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
WWW-Authenticate: Digest
 realm="http-auth@example.org",
 qop="auth, auth-int",
 algorithm=MD5,
 nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
 opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
```

客户端提示用户输入他们的用户名和密码，然后响应一个新的请求，该请求在 `Authorization` 标头字段中对凭据进行加密。如果客户端选择 MD5 摘要，则 `Authorization` 标头字段看起来可能像如下这样：

```http
Authorization: Digest username="Mufasa",
 realm="http-auth@example.org",
 uri="/dir/index.html",
 algorithm=MD5,
 nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
 nc=00000001,
 cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
 qop=auth,
 response="8ca523f5e9506fed4657c9700eebdbec",
 opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
```

如果客户端选择 SHA-256 摘要，则 `Authorization` 标头看起来可能像以下这样：

```http
Authorization: Digest username="Mufasa",
 realm="http-auth@example.org",
 uri="/dir/index.html",
 algorithm=SHA-256,
 nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
 nc=00000001,
 cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
 qop=auth,
 response="753927fa0e85d155564e2e272a28d1802ca10daf449
 6794697cf8db5856cb6c1",
 opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
```

规范
--

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

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

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

参见
--

* HTTP 身份验证
* `Authorization`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `401`、`403`、`407`


Accept-Language - HTTP

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`


Large-Allocation - HTTP

Large-Allocation
================

非标准的\*\*`Large-Allocation`\*\* 响应头部是用来告诉浏览器加载该页面可能需要申请大内存。当前只有 Firefox 实现该特性，但是对其他浏览器也无损害。

WebAssembly 或者 asm.js 会使用比较大的连续内存空间。例如，对于一些复杂的游戏，其申请的空间将会非常大，甚至会达到 1GB。`Large-Allocation` 告诉浏览器其将要加载的页面可能需要申请一个大的连续内存空间，浏览器依据该头部可能会单独启动一个专有的进程用于处理该页面。

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

语法
--
```

Large-Allocation: 0
Large-Allocation: <megabytes>
```

指令
--

`0`

0 是一个特殊的值，代表给它分配的大小是不确定的 (动态允许).

`<megabytes>`

预期需要申请的内存大小，以 M 为单位

示例
--
```

Large-Allocation: 0
Large-Allocation: 500
```

排除错误
----

如果使用不当， `Large-Allocation` 会抛出警告或者错误信息，你可以在 web console 查看它们。

由于`Large-Allocation 报头存在，这个页面会在一个新的进程处理和加载`

This message means that the browser saw the `Large-Allocation` header, and was able to reload the page into a new process which should have more available contiguous memory.

`Large-Allocation` 报头由于非`non-GET 请求而直接忽略`

当一个 `POST` 请求用语加载文档，that load cannot currently be redirected into a new process. This error is displayed when loading a document with a `Large-Allocation` header with a non-GET HTTP method. This could be caused due to the document being loaded by a form submission, for example.

A `Large-Allocation` header was ignored due to the presence of windows which have a reference to this browsing context through the frame hierarchy or `window.opener`.

This error means that the document was not loaded at the top level of an user-opened or noopener-opened tab or window. It can occur in these situations:

* The document with the `Large-Allocation` header was loaded in an `<iframe>`. Firefox cannot move an iframe into a new process currently, so the document must load in the current process.
* The document with the `Large-Allocation` header was loaded in a window which was opened by `window.open()`, `<a target="_blank">` or other similar methods without `rel="noopener"` or the `"noopener"` feature being set. These windows must remain in the same process as their opener, as they can communicate, meaning that we cannot allow them to switch processes.
* The document with the `Large-Allocation header` has opened another window with `window.open()`, `<a target="_blank">` or other similar methods without `rel="noopener"` or the `"noopener"` feature being set. This is for the same reason as above, namely that they can communicate and thus we cannot allow them to switch processes.

`Large-Allocation` 报头由于 文档在加载过程没有被加载而直接忽略

Firefox has moved to a multiprocess architecture, and this architecture is required in order to support the `Large-Allocation` header. Some legacy Addons can prevent Firefox from using this new, faster, multiprocess architecture. If you have one of these Addons installed, then we will continue to use the old single process architecuture for compatibility, and cannot handle the `Large-Allocation` header.

由于`Large-Allocation`头部，此页面应将被加载到新进程中，但是在非 Win32 平台上禁用此选项。

由于在 64 位系统里内存碎片不是问题，Firefox 只在 32 位系统支持`Large-Allocation`头部。如果你运行一个非 32 位的程序，这类信息就会出现。可以设置 about:config 里面的"dom.largeAllocation.forceEnable"布尔值来关闭此检查。

规范
--

现还不属于任何规范，可以通过这篇文档了解该头部的背后思想。

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

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

参见
--

* WebAssembly


Save-Data - HTTP

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

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

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

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`


Cache-Control - HTTP

Cache-Control
=============

**`Cache-Control`** 通用消息头字段，被用于在 http 请求和响应中，通过指定指令来实现缓存机制。缓存指令是单向的，这意味着在请求中设置的指令，不一定被包含在响应中。

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

语法
--

指令格式具有以下有效规则：

* 不区分大小写，但建议使用小写。
* 多个指令以逗号分隔。
* 具有可选参数，可以用令牌或者带引号的字符串语法。
### 缓存请求指令

客户端可以在 HTTP 请求中使用的标准 Cache-Control 指令。
```

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: only-if-cached
```

### 缓存响应指令

服务器可以在响应中使用的标准 Cache-Control 指令。
```

Cache-control: must-revalidate
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: public
Cache-control: private
Cache-control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-control: s-maxage=<seconds>
```

### 扩展`Cache-Control`指令

拓展缓存指令不是核心 HTTP 缓存标准文档的一部分，使用前请注意检查兼容性！
```

Cache-control: immutable
Cache-control: stale-while-revalidate=<seconds>
Cache-control: stale-if-error=<seconds>
```

指令
--

### 可缓存性

`public`

表明响应可以被任何对象（包括：发送请求的客户端，代理服务器，等等）缓存，即使是通常不可缓存的内容。（例如：1.该响应没有`max-age`指令或`Expires`消息头；2. 该响应对应的请求方法是 POST 。）

`private`

表明响应只能被单个用户缓存，不能作为共享缓存（即代理服务器不能缓存它）。私有缓存可以缓存响应内容，比如：对应用户的本地浏览器。

`no-cache`

在发布缓存副本之前，强制要求缓存把请求提交给原始服务器进行验证 (协商缓存验证)。

`no-store`

缓存不应存储有关客户端请求或服务器响应的任何内容，即不使用任何缓存。

### 到期

`max-age=<seconds>`

设置缓存存储的最大周期，超过这个时间缓存被认为过期 (单位秒)。与`Expires`相反，时间是相对于请求的时间。

`s-maxage=<seconds>`

覆盖`max-age`或者`Expires`头，但是仅适用于共享缓存 (比如各个代理)，私有缓存会忽略它。

`max-stale[=<seconds>]`

表明客户端愿意接收一个已经过期的资源。可以设置一个可选的秒数，表示响应不能已经过时超过该给定的时间。

`min-fresh=<seconds>`

表示客户端希望获取一个能在指定的秒数内保持其最新状态的响应。

`stale-while-revalidate=<seconds>`
实验性

表明客户端愿意接受陈旧的响应，同时在后台异步检查新的响应。秒值指示客户愿意接受陈旧响应的时间长度。

`stale-if-error=<seconds>`
实验性

表示如果新的检查失败，则客户愿意接受陈旧的响应。秒数值表示客户在初始到期后愿意接受陈旧响应的时间。

### 重新验证和重新加载

`must-revalidate`

一旦资源过期（比如已经超过`max-age`），在成功向原始服务器验证之前，缓存不能用该资源响应后续请求。

`proxy-revalidate`

与 must-revalidate 作用相同，但它仅适用于共享缓存（例如代理），并被私有缓存忽略。

`immutable`
实验性

表示响应正文不会随时间而改变。资源（如果未过期）在服务器上不发生改变，因此客户端不应发送重新验证请求头（例如`If-None-Match`或 I`f-Modified-Since`）来检查更新，即使用户显式地刷新页面。在 Firefox 中，immutable 只能被用在 `https://` transactions. 有关更多信息，请参阅这里。

### 其他

`no-transform`

不得对资源进行转换或转变。`Content-Encoding`、`Content-Range`、`Content-Type`等 HTTP 头不能由代理修改。例如，非透明代理或者如Google's Light Mode可能对图像格式进行转换，以便节省缓存空间或者减少缓慢链路上的流量。`no-transform`指令不允许这样做。

`only-if-cached`

表明客户端只接受已缓存的响应，并且不要向原始服务器检查是否有更新的拷贝。

示例
--

### 禁止缓存

发送如下响应头可以关闭缓存。此外，可以参考`Expires`和`Pragma`消息头。
```

Cache-Control: no-store
```

### 缓存静态资源

对于应用程序中不会改变的文件，你通常可以在发送响应头前添加积极缓存。这包括例如由应用程序提供的静态文件，例如图像，CSS 文件和 JavaScript 文件。另请参阅 Expires 标题。
```

Cache-Control:public, max-age=31536000
```

### 需要重新验证

指定 `no-cache` 或 `max-age=0, must-revalidate` 表示客户端可以缓存资源，每次使用缓存资源前都必须重新验证其有效性。这意味着每次都会发起 HTTP 请求，但当缓存内容仍有效时可以跳过 HTTP 响应体的下载。

```http
Cache-Control: no-cache
```

```http
Cache-Control: max-age=0, must-revalidate
```

**注意**: 如果服务器关闭或失去连接，下面的指令可能会造成使用缓存。

```http
Cache-Control: max-age=0
```

规范
--

| Specification |
| --- |
| HTTP Caching # field.cache-control |
| HTTP Immutable Responses # the-immutable-cache-control-extension |

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

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

参见
--

* HTTP Caching FAQ
* Caching Tutorial for Web Authors and Webmasters
* Guide: *`Cache-Control` for civilians*
* `Age`
* `Expires`
* `Pragma`


DPR - HTTP

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

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`


Sec-CH-UA-Full-Version-List - HTTP

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

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

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

服务器使用 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 - HTTP

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

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

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

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

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

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

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


Referrer-Policy - HTTP

Referrer-Policy
===============

**`Referrer-Policy`** 首部用来监管哪些访问来源信息——会在 `Referer` 中发送——应该被包含在生成的请求当中。

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

语法
--

注意 `Referer` 实际上是单词 "referrer" 的错误拼写。`Referrer-Policy` 这个首部并没有延续这个错误拼写。

```http
Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url
```

指令
--

`no-referrer`

整个 `Referer` 首部会被移除。访问来源信息不随着请求一起发送。

`no-referrer-when-downgrade`

在同等安全级别或安全级别提升的情况下（HTTP→HTTP、HTTP→HTTPS、HTTPS→HTTPS），在 `Referer` 中发送来源、路径和查询字符串。而在目标的安全级别下降的情况下（HTTPS→HTTP、HTTPS→file）则不发送 `Referer` 标头。

`origin`

仅在 `Referer` 标头中发送来源。例如 `https://example.com/page.html` 文档会将 `https://example.com/` 作为引用地址。

`origin-when-cross-origin`

对于同源的请求，会发送完整的 URL 作为引用地址，但是对于非同源请求仅发送文件的源。

`same-origin`

对于同源的请求会发送引用地址，但是对于非同源请求则不发送引用地址信息。

`strict-origin`

在同等安全级别的情况下，发送文件的源作为引用地址 (HTTPS->HTTPS)，但是在降级的情况下不会发送 (HTTPS->HTTP)。

`strict-origin-when-cross-origin`（默认值）

对于同源的请求，发送来源、路径以及查询字符串。对于在相同安全级别的情况下（HTTPS→HTTPS）的跨源请求，仅发送来源。在目标的安全级别下降的情况下（HTTPS→HTTP）则不发送 `Referer` 标头。

`unsafe-url`

无论是同源请求还是非同源请求，都发送完整的 URL（移除参数信息之后）作为引用地址。

**备注：** 这项设置会将受 TLS 安全协议保护的资源的源和路径信息泄露给非安全的源服务器。进行此项设置的时候要慎重考虑。

集成到 HTML
--------

你也可以在 HTML 内设置 referrer 策略。例如，你可以用一个 name 为 referrer 的 `<meta>` 元素为整个文档设置 referrer 策略。

```html
<meta name="referrer" content="origin" />
```

或者用 `<a>`、`<area>`、`<img>`、`<iframe>`、`<script>` 或者 `<link>` 元素上的 `referrerpolicy` 属性为其设置独立的请求策略。

```html
<a href="http://example.com" referrerpolicy="origin">…</a>
```

另外也可以在 `<a>`、`<area>` 或者 `<link>` 元素上将 `rel` 属性设置为 `noreferrer`。

```html
<a href="http://example.com" rel="noreferrer">…</a>
```

集成到 CSS
-------

CSS 可以从样式表获取引用的资源，这些资源也可以遵从 referrer 策略：

* 外部 CSS 样式表使用默认策略 (`no-referrer-when-downgrade`)，除非 CSS 样式表的响应消息通过 `Referrer-Policy` 首部覆盖该策略。
* 对于 `<style>` 元素或 `style` 属性，则遵从文档的 referrer 策略。
示例
--

| Policy | Document | Navigation to | Referrer |
| --- | --- | --- | --- |
| **`no-referrer`** | `https://example.com/page.html` | any domain or path | no referrer |
| **`no-referrer-when-downgrade`** | `https://example.com/page.html` | `https://example.com/otherpage.html` | `https://example.com/page.html` |
| **`no-referrer-when-downgrade`** | `https://example.com/page.html` | `https://mozilla.org` | `https://example.com/page.html` |
| **`no-referrer-when-downgrade`** | `https://example.com/page.html` | **http**://example.org | no referrer |
| **`origin`** | `https://example.com/page.html` | any domain or path | `https://example.com/` |
| **`origin-when-cross-origin`** | `https://example.com/page.html` | `https://example.com/otherpage.html` | `https://example.com/page.html` |
| **`origin-when-cross-origin`** | `https://example.com/page.html` | `https://mozilla.org` | `https://example.com/` |
| **`origin-when-cross-origin`** | `https://example.com/page.html` | **http**://example.com/page.html | `https://example.com/` |
| **`same-origin`** | `https://example.com/page.html` | `https://example.com/otherpage.html` | `https://example.com/page.html` |
| **`same-origin`** | `https://example.com/page.html` | `https://mozilla.org` | no referrer |
| **`strict-origin`** | `https://example.com/page.html` | `https://mozilla.org` | `https://example.com/` |
| **`strict-origin`** | `https://example.com/page.html` | **http**://example.org | no referrer |
| **`strict-origin`** | **http**://example.com/page.html | any domain or path | `http://example.com/` |
| **`strict-origin-when-cross-origin`** | `https://example.com/page.html` | `https://example.com/otherpage.html` | `https://example.com/page.html` |
| **`strict-origin-when-cross-origin`** | `https://example.com/page.html` | `https://mozilla.org` | `https://example.com/` |
| **`strict-origin-when-cross-origin`** | `https://example.com/page.html` | **http**://example.org | no referrer |
| **`unsafe-url`** | `https://example.com/page.html` | any domain or path | `https://example.com/page.html` |

### 指定后备策略

如果你要为那些策略未获广泛的浏览器支持的情况指定一种后备策略，使用逗号分隔的列表，并将希望使用的策略放在最后：

```http
Referrer-Policy: no-referrer, strict-origin-when-cross-origin
```

在上面的场景中，`no-referrer` 仅在 `strict-origin-when-cross-origin` 不被浏览器支持的情况下被使用。

规范
--

| Specification |
| --- |
| Referrer Policy # referrer-policy-header |

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

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

**备注：** 从版本 53 起，Gecko 在 about:config 中提供了一项偏好设置，使得用户可以自行设定默认的 Referrer-Policy 值——network.http.referer.userControlPolicy。可选的值包括：

* 0 — `no-referrer`
* 1 — `same-origin`
* 2 — `strict-origin-when-cross-origin`
* 3 — `no-referrer-when-downgrade` (the default)
参见
--

* HTTP referer on Wikipedia
* 其他设定页面引用策略的方式：
    + A `<meta>` element with a name of `referrer`.
    + A `referrerpolicy` attribute on an `<a>`, `<area>`, `<img>`, `<iframe>`, or `<link>` element.
    + The `noreferrer` link relation on an a, area, or link element (`rel="noreferrer"`).
    + When using Fetch: `Request.referrerPolicy` (en-US)
* 同源策略
* Tighter Control Over Your Referrers – Mozilla Security Blog


X-DNS-Prefetch-Control - HTTP

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

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

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

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

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

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

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

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

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


SourceMap - HTTP

SourceMap
=========

**`SourceMap`** HTTP 响应头链接生成的代码到一个 source map，使浏览器能够重建原始的资源然后显示在调试器里。

| Header 类型 | Response header |
| --- | --- |
| Forbidden header name | no |

语法
--
```

SourceMap: <url>
X-SourceMap: <url> (deprecated)
```

### 指令

`<url>`

指向一个 source map 文件的一个相对（于请求的 URL）或者一个绝对的 URL。

例子
--
```

SourceMap: /path/to/file.js.map
```

规范
--

| Specification |
| --- |
| Source Map # linking-generated-code |

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

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

参见
--

* Firefox Developer Tools: using a source map


Pragma - HTTP

Pragma
======

**`Pragma`** 是一个在 HTTP/1.0 中规定的通用首部，这个首部的效果依赖于不同的实现，所以在“请求 - 响应”链中可能会有不同的效果。它用来向后兼容只支持 HTTP/1.0 协议的缓存服务器，那时候 HTTP/1.1 协议中的 Cache-Control 还没有出来。

**备注：** 由于 Pragma 在 HTTP 响应中的行为没有确切规范，所以不能可靠替代 HTTP/1.1 中通用首部 Cache-Control，尽管在请求中，假如 Cache-Control 不存在的话，它的行为与 Cache-Control: no-cache 一致。建议只在需要兼容 HTTP/1.0 客户端的场合下应用 Pragma 首部。

| Header type | General header, but response behavior is not specified and thus implementation-specific. |
| --- | --- |
| Forbidden header name | no |
| CORS-safelisted response-header | yes |

语法
--
```

Pragma: no-cache
```

指令
--

no-cache

与 Cache-Control: no-cache 效果一致。强制要求缓存服务器在返回缓存的版本之前将请求提交到源头服务器进行验证。

示例
--
```

Pragma: no-cache
```

规范
--

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

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

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

相关内容
----

* `Cache-Control`
* `Expires`


Access-Control-Expose-Headers - HTTP

Access-Control-Expose-Headers
=============================

响应标头 **`Access-Control-Expose-Headers`** 允许服务器指示那些响应标头可以暴露给浏览器中运行的脚本，以响应跨源请求。

默认情况下，仅暴露 CORS 安全列表的响应标头 (en-US)。如果想要让客户端可以访问到其他的标头，服务器必须将它们在 `Access-Control-Expose-Headers` 里面列出来。

|  |  |
| --- | --- |
| 标头类型 | 响应标头 |
| 禁止修改的标头 | 否 |

语法
--

```http
Access-Control-Expose-Headers: [<header-name>[, <header-name>]\*]
Access-Control-Expose-Headers: \*
```

指令
--

<header-name>

允许客户端从响应中访问的 0 个或多个使用逗号分隔的标头名称列表。这些标头是对 CORS 安全列表的响应标头 (en-US)的*补充*。

`*`（通配符）

若请求没有携带凭据（请求没有 HTTP Cookie或认证信息），“`*`”才会被当作一个特殊的通配符。对于带有凭据的请求，会被简单地当作标头名称“`*`”，没有特殊的语义。

示例
--

想要暴露一个非简单响应标头，可以这样指定：

```http
Access-Control-Expose-Headers: Content-Encoding
```

想要额外暴露自定义的标头，例如 `Kuma-Revision`，可以指定多个，用逗号隔开：

```http
Access-Control-Expose-Headers: Content-Encoding, Kuma-Revision
```

服务器可以为不带凭据的请求响应通配符：

```http
Access-Control-Expose-Headers: \*
```

但是，这并不会匹配 `Authorization` 标头，所以如果你要暴露它，需要显式指定：

```http
Access-Control-Expose-Headers: \*, Authorization
```

规范
--

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

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

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

参见
--

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Origin`


X-Content-Type-Options - HTTP

X-Content-Type-Options
======================

**`X-Content-Type-Options`** HTTP 消息头相当于一个提示标志，被服务器用来提示客户端一定要遵循在 `Content-Type` 首部中对 MIME 类型 的设定，而不能对其进行修改。这就禁用了客户端的 MIME 类型嗅探行为，换句话说，也就是意味着网站管理员确定自己的设置没有问题。

该消息头最初是由微软在 IE 8 浏览器中引入的，提供给网站管理员用作禁用内容嗅探的手段，内容嗅探技术可能会把不可执行的 MIME 类型转变为可执行的 MIME 类型。在此之后，其他浏览器也相继引入了这个消息头，尽管它们的 MIME 嗅探算法没有那么有侵略性。

安全测试人员通常期望站点设置了该消息头。

注意：`nosniff` 只应用于 "`script`" 和 "`style`" 两种类型。事实证明，将其应用于图片类型的文件会导致与现有的站点冲突。

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

语法
--
```

X-Content-Type-Options: nosniff
```

指令
--

`nosniff`

下面两种情况的请求将被阻止：

* 请求类型是"`style`" 但是 MIME 类型不是 "`text/css`"，
* 请求类型是"`script`" 但是 MIME 类型不是 JavaScript MIME 类型。

规范
--

| Specification |
| --- |
| Fetch Standard # x-content-type-options-header |

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

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

相关内容
----

* `Content-Type`
* The original definition of X-Content-Type-Options by Microsoft.
* The Mozilla Observatory tool testing the configuration (including this header) of Web sites for safety and security
* Mitigating MIME Confusion Attacks in Firefox


Origin - HTTP

Origin
======

请求标头 **`Origin`** 表示了请求的来源（协议、主机、端口）。例如，如果一个用户代理需要请求一个页面中包含的资源，或者执行脚本中的 HTTP 请求（fetch），那么该页面的来源（origin）就可能被包含在这次请求中。

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

语法
--
```

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

指令
--

`null`

请求的来源是“隐私敏感”的，或者是 HTML 规范定义的*不透明来源*（具体情况在描述部分列出）。

`<scheme>`

请求所使用的协议，通常是 HTTP 协议或者它的安全版本（HTTPS 协议）。

`<hostname>`

源站的域名或 IP 地址。

`<port>` 可选

服务器正在监听的端口号。缺省为服务的默认端口（对于 HTTP 请求而言，默认端口为 80）。

描述
--

`Origin` 标头与 `Referer` 标头类似，但前者不会暴露 URL 的 path 部分，而且其可以为 `null` 值。其用于为源站的请求提供“安全上下文”，除非源站的信息敏感或不必要的。

从广义上讲，用户代理会在以下情况中添加 `Origin` 请求标头：

* 跨源请求。
* 除 `GET` 和 `HEAD` 以外的同源请求（即它会被添加到同源的 `POST`、`OPTIONS`、`PUT`、`PATCH` 和 `DELETE` 请求中）。

除上述规则外，还有一些特殊情况。例如，在 no-cors 模式下的跨源 `GET` 或 `HEAD` 请求不会发送 `Origin` 标头。

`Origin` 标头在以下情况中（不完整）会被设置为 `null`：

* 请求来源的协议不是 `http`、`https`、`ftp`、`ws`、`wss` 或 `gopher` 中的任意一个（如：`blob`、`file` 和 `data`）。
* 跨源的图像或媒体，包括：`<img>`、`<video>` 和 `<audio>` 元素。
* 属于以下几种文档类型的：使用 `createDocument()` 创建的、通过 `data:` URL 生成的或没有创建者的浏览上下文的。
* 跨源重定向。
* 没有为 sandbox 属性设置 `allow-same-origin` 值的 iframe。
* 响应（response）是网络错误。

**备注：** 了解更详细的关于其值何时为 `null` 的清单，请参见 Stack Overflow：When do browsers send the Origin header? When do browsers set the origin to null?。

示例
--

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

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

规范
--

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

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

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

参见
--

* `Host`
* `Referer`
* 同源策略
* 浏览器在何时会发送 Origin 请求标头？又会在何时将其设置为 null？（Stack Overflow）


Access-Control-Allow-Origin - HTTP

Access-Control-Allow-Origin
===========================

**`Access-Control-Allow-Origin`** 响应标头指定了该响应的资源是否被允许与给定的来源（origin）共享。

|  |  |
| --- | --- |
| 标头类型 | 响应标头 |
| 禁止修改的标头 | 否 |

语法
--

```http
Access-Control-Allow-Origin: \*
Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Origin: null
```

指令
--

`*`

对于*不包含凭据*的请求，服务器会以“`*`”作为通配符，从而允许任意来源的请求代码都具有访问资源的权限。尝试使用通配符来响应包含凭据的请求会导致错误。

`<origin>`

指定一个来源（只能指定一个）。如果服务器支持多个来源的客户端，其必须以与指定客户端匹配的来源来响应请求。

`null`

指定来源为“null”。

**备注：** `null` 不应该被使用：“返回 `Access-Control-Allow-Origin: "null"` 似乎是安全的，但任何使用非分级协议（如 `data:` 或 `file:`）的资源和沙盒文件的 Origin 的序列化都被定义为‘null’。许多用户代理将授予这类文件对带有 `Access-Control-Allow-Origin: "null"` 头的响应的访问权，而且任何源都可以用 `null` 源创建一个恶意文件。因此，应该避免将 ACAO 标头设置为‘null’值。”

示例
--

一个告诉浏览器允许任何来源的代码访问资源的响应将包括以下内容：

```http
Access-Control-Allow-Origin: \*
```

如需允许 `https://developer.mozilla.org` 源访问资源，响应应包含以下内容：

```http
Access-Control-Allow-Origin: https://developer.mozilla.org
```

将可能的 `Access-Control-Allow-Origin` 值限制在一组允许的源，需要服务器端的代码检查 `Origin` 请求标头的值，将其与允许的来源列表进行比较，如果 `Origin` 值在列表中，将 `Access-Control-Allow-Origin` 设置为与 `Origin` 标头相同的值。

### CORS 和缓存

如果服务器未使用通配符“`*`”，而是指定了明确的来源，那么为了向客户端表明服务器的返回会根据 `Origin` 请求标头而有所不同，必须在 `Vary` 响应标头中包含 `Origin`。

```http
Access-Control-Allow-Origin: https://developer.mozilla.org
Vary: Origin
```

规范
--

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

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

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

参见
--

* `Origin`
* `Vary`
* 跨源资源共享（CORS）
* `Cross-Origin-Resource-Policy`


Cookie - HTTP

Cookie
======

**`Cookie`** 是一个 HTTP 请求标头，其中含有先前由服务器通过 `Set-Cookie` 标头投放或通过 JavaScript 的 `Document.cookie` 方法设置，然后存储到客户端的 HTTP cookie 。

这个标头是可选的，而且可能会被忽略，例如在浏览器的隐私设置里面设置为禁用 cookie。

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

语法
--
```

Cookie: <cookie-list>
Cookie: name=value
Cookie: name=value; name2=value2; name3=value3
```

<cookie-list>

一系列的名称/值对，形式为 `<cookie-name>=<cookie-value>`。名称/值对之间用分号和空格（`'; '`）隔开。

示例
--
```

Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1
```

规范
--

| Specification |
| --- |
| HTTP State Management Mechanism # cookie |

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

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

参见
--

* `Set-Cookie`
* `Document.cookie`


Set-Cookie - HTTP

Set-Cookie
==========

**`Set-Cookie`** HTTP 响应标头用于将 cookie 由服务器发送到用户代理，以便用户代理在后续的请求中可以将其发送回服务器。要发送多个 cookie，则应在同一响应中发送多个 **`Set-Cookie`** 标头。

**警告：** 根据 Fetch 规范，`Set-Cookie` 是一个禁止修改的响应标头，对应的响应在被暴露给前端代码前，必须滤除这一响应标头，即浏览器会阻止前端 JavaScript 代码访问该标头。

更多信息请查阅指南：使用 HTTP cookie。

|  |  |
| --- | --- |
| 标头类型 | 响应标头 |
| 禁止修改的标头 | 否 |
| 禁止修改的响应标头 | 是 |

语法
--

```http
Set-Cookie: <cookie-name>=<cookie-value>
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<number>
Set-Cookie: <cookie-name>=<cookie-value>; Partitioned
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
Set-Cookie: <cookie-name>=<cookie-value>; Secure

Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None; Secure

// 可以同时有多个属性，例如：
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly
```

属性
--

`<cookie-name>=<cookie-value>`

定义 cookie 的名称和值。cookie 的定义以一个名称/值对开始。

`<cookie-name>` 可以包含除了控制字符（ASCII 字符 0 至 31，以及 ASCII 字符 127）和分隔符（空格、制表符和以下字符：`( ) < > @ , ; : \ " / [ ] ? = { }`）之外的任何 US-ASCII 字符。

`<cookie-value>` 可以选择包裹在双引号中。支持除了控制字符（ASCII 字符 0 至 31，以及 ASCII 字符 127）、空白字符、双引号、逗号、分号以及反斜杠之外的任意 US-ASCII 字符。

**编码**：许多实现会对 cookie 值进行 URL 编码。但是按照 RFC 规范，这不是必须的。不过 URL 编码有助于满足 `<cookie-value>` 对允许使用的字符的要求。

**备注：** 一些 `<cookie-name>` 具有特殊的语义：

**`__Secure-` 前缀**：以 `__Secure-` 为前缀的 cookie（连接符是前缀的一部分），必须与 `secure` 标志一同设置，同时必须应用于安全页面（HTTPS）。

**`__Host-` 前缀**：以 `__Host-` 为前缀的 cookie，必须与 `secure` 标志一同设置，必须应用于安全页面（HTTPS），也禁止指定 domain 属性（也就不会发送给子域名），同时 path 属性的值必须为 `/`。

`Domain=<domain-value>` 可选

指定 cookie 可以送达的主机。

只能将值设置为当前域名或更高级别的域名（除非是公共后缀）。设置域名将会使 cookie 对指定的域名及其所有子域名可用。

若缺省，则此属性默认为当前文档 URL 的主机（不包括子域名）。

与之前的规范不同，域名（`.example.com`）的前导点号会被忽略。

多个主机/域名的值是*不*被允许的，但如果*指定*了一个域名，则其子域名也总会被包含。

`Expires=<date>` 可选

以 HTTP 日期时间戳形式指定的 cookie 的最长有效时间。参见 `Date` 以了解要求的格式。

如果没有指定，那么会是一个**会话期 cookie**。会话在客户端被关闭时结束，这意味着会话期 cookie 会在彼时被移除。

**警告：** 然而，很多 Web 浏览器支持*会话恢复*特性，这可以使浏览器保留所有的标签，然后在重新打开浏览器的时候将其还原。与此同时，cookie 也会恢复，就跟从来没有关闭浏览器一样。

如果设置了 `Expires` 日期，其截止时间与*客户端*相关，而非服务器的时间。

`HttpOnly` 可选

阻止 JavaScript 通过 `Document.cookie` 属性访问 cookie。注意，设置了 `HttpOnly` 的 cookie 仍然会通过 JavaScript 发起的请求发送。例如，调用 `XMLHttpRequest.send()` 或 `fetch()`。其用于防范跨站脚本攻击（XSS）。

`Max-Age=<number>` 可选

在 cookie 过期之前需要经过的秒数。秒数为 0 或负值将会使 cookie 立刻过期。假如同时设置了 `Expires` 和 `Max-Age` 属性，那么 `Max-Age` 的优先级更高。

`Partitioned` 可选
实验性

表示应使用分区存储来存储 cookie。有关更多详细信息，请参见具有独立分区状态的 Cookie（CHIPS） (en-US)。

`Path=<path-value>` 可选

表示浏览器要发送该 `Cookie` 标头时，请求的 URL 中所*必须*存在的路径。

正斜杠（`/`）字符可以解释为目录分隔符，且子目录也满足匹配的条件。例如，如果 `path=/docs`，那么

* 请求路径 `/docs`、`/docs/`、`/docs/Web/` 和 `/docs/Web/HTTP` 都满足匹配条件。
* 请求路径 `/`、`/docsets` 或者 `/fr/docs` 则不满足匹配条件。

`SameSite=<samesite-value>` 可选

控制 cookie 是否随跨站请求一起发送，这样可以在一定程度上防范跨站请求伪造攻击（CSRF）。

可选的属性值有：

`Strict`

这意味浏览器仅对同一站点的请求发送 cookie，即请求来自设置 cookie 的站点。如果请求来自不同的域名或协议（即使是相同域名），则携带有 `SameSite=Strict` 属性的 cookie 不会被发送。

`Lax`

这意味着 cookie 不会在跨站请求中被发送，如：加载图像或框架（frame）的请求。但 cookie 在用户从外部站点导航到源站时，cookie 也会被发送（例如，访问一个链接）。这是 `SameSite` 属性未被设置时的默认行为。

`None`

这意味着浏览器在跨站和同站请求中均会发送 cookie。在设置这一属性值时，必须同时设置 `Secure` 属性，就像这样：`SameSite=None; Secure`。如果未设置 `Secure`，则会出现以下错误：
```

Cookie "myCookie" rejected because it has the "SameSite=None" attribute but is missing the "secure" attribute.

This Set-Cookie was blocked because it had the "SameSite=None" attribute but did not have the "Secure" attribute, which is required in order to use "SameSite=None".
```

**备注：** `Secure` cookie 仅在使用 HTTPS 协议发送加密请求时才会被发送到服务器。请注意，非安全站点（`http:`）无法为 cookie 设置 `Secure` 指令，因此也无法使用 `SameSite=None`。

`Secure` 可选

表示仅当请求通过 `https:` 协议（localhost 不受此限制）发送时才会将该 cookie 发送到服务器，因此其更能够抵抗中间人攻击。

**备注：** 不要假设 `Secure` 会阻止所有的对 cookie 中敏感信息（会话密钥、登录信息，等等）的访问。携带这一属性的 cookie 在不设置 `HttpOnly` 属性的情况下仍能从客户端的硬盘或是从 JavaScript 中访问及更改。

非安全站点（`http:`）不能在 cookie 中设置 `Secure` 属性（从 Chrome 52 和 Firefox 52 开始）。当 `Secure` 属性由 localhost 设置时，`https:` 的要求会被忽略（从 Chrome 89 和 Firefox 75 开始）。

示例
--

### 会话期 cookie

**会话期 cookie** 会在客户端关闭时被移除。若 cookie 不设置 `Expires` 或 `Max-Age` 属性，则其为会话期 cookie。

```http
Set-Cookie: sessionId=38afes7a8
```

### 持久化 cookie

**持久化 cookie** 不会在客户端关闭时失效，而是在特定的日期（`Expires`）或者经过一段特定的时间（`Max-Age`）之后才会失效。

```http
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT
```

```http
Set-Cookie: id=a3fWa; Max-Age=2592000
```

### 无效域名

如果 cookie 的域名不包含设置该域名的服务器，则其应该被用户代理拒绝。

以下的 cookie 如果是由托管在 `originalcompany.com` 上的服务器设置的，则会被拒绝：

```http
Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk
```

服务器尝试为其域名的子域名设置的 cookie 也会被拒绝。

以下的 cookie 假如是由托管在 `example.com` 上的服务器设置的，则会被拒绝：

```http
Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com
```

### Cookie 前缀

仅在使用了安全（HTTPS）来源，并同时设置 `secure` 属性时才能使用名称中包含 `__Secure-` 或 `__Host-` 前缀的 cookie。

另外，假如 cookie 以 `__Host-` 为前缀，那么 path 属性的值必须为 `/`（表示主机的任何路径），且不能含有 `Domain` 属性。

**警告：** 对于不支持 cookie 前缀的客户端，无法保证这些附加的条件成立，所以带前缀的 cookie 将始终被接受。

```http
// 当响应来自安全来源（HTTPS）时，二者都会被接受
Set-Cookie: \_\_Secure-ID=123; Secure; Domain=example.com
Set-Cookie: \_\_Host-ID=123; Secure; Path=/

// 缺少 Secure 属性，会被拒绝
Set-Cookie: \_\_Secure-id=1

// 缺少 Path=/ 属性，会被拒绝
Set-Cookie: \_\_Host-id=1; Secure

// 由于设置了 Domain 属性，会被拒绝
Set-Cookie: \_\_Host-id=1; Secure; Path=/; domain=example.com
```

### 分区 cookie

```http
Set-Cookie: \_\_Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;
```

**备注：** 分区 cookie 必须设置 `Secure` 和 `Path=/`。此外，建议在设置分区 cookie 时使用 `__Host` 前缀，以使其绑定到主机名而不是可注册的域名。

规范
--

| Specification |
| --- |
| HTTP State Management Mechanism # sane-set-cookie |

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

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

### 兼容性说明

* 从 Chrome 52 和 Firefox 52 开始，非安全站点（`http:`）无法在 cookie 中设置 `Secure` 属性。
参见
--

* HTTP cookie
* `Cookie`
* `Document.cookie`
* SameSite Cookie 说明（web.dev 博客）


Sec-CH-UA-Bitness - HTTP

Sec-CH-UA-Bitness
=================

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

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

**`Sec-CH-UA-Bitness`** 用户代理客户端提示请求标头提供用户代理底层 CPU 架构（architecture）的“位数”。这是一种以位为单位的指示内存地址大小的整数，通常为 64 位或 32 位。

这个标头可能被服务器用作类似选择并提供可执行文件的正确二进制格式供用户下载等用途。

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

语法
--

```http
Sec-CH-UA-Bitness: <bitness>
```

指令
--

`<bitness>`

指示基础平台架构位数的字符串，例如：`"64"`、`"32"`。

示例
--

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

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

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

```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-Bitness: "64"
```

规范
--

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

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

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`


Strict-Transport-Security - HTTP

Strict-Transport-Security
=========================

HTTP **`Strict-Transport-Security`**（通常简称为 HSTS）响应标头用来通知浏览器应该只通过 HTTPS 访问该站点，并且以后使用 HTTP 访问该站点的所有尝试都应自动重定向到 HTTPS。

**备注：** 这比在你的服务器上简单地配置 HTTP 到 HTTPS（301）重定向要安全，因为初始的 HTTP 连接仍然易受到中间人攻击。

|  |  |
| --- | --- |
| 标头类型 | 响应标头 |
| 禁止修改的标头 | 否 |

语法
--

```http
Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains; preload
```

指令
--

`max-age=<expire-time>`

浏览器应该记住的，只能使用 HTTPS 访问站点的最大时间量（以秒为单位）。

`includeSubDomains` 可选

如果这个可选的参数被指定，那么说明此规则也适用于该网站的所有子域名。

`preload` 可选
非标准

查看预加载 HSTS 获得详情。当使用 `preload`，`max-age` 指令必须至少是 `31536000`（一年），并且必须存在 `includeSubDomains` 指令。这不是标准的一部分。

描述
--

如果一个网站接受 HTTP 的请求，然后重定向到 HTTPS，用户可能在开始重定向前，通过没有加密的方式与服务器通信，比如，用户输入 `http://foo.com` 或者仅是输入 foo.com。这样为中间人攻击创造了机会。可以利用重定向将用户引导至恶意站点，而不是原始站的安全版本。

网站通过 HTTP Strict Transport Security 标头通知浏览器，这个网站禁止使用 HTTP 方式加载，并且浏览器应该自动把所有尝试使用 HTTP 的请求自动替换为 HTTPS 请求。

**备注：** `Strict-Transport-Security` 标头在通过 HTTP 访问时会被浏览器**忽略**。只有在你的网站通过 HTTPS 访问并且没有证书错误时，浏览器才认为你的网站支持 HTTPS，然后遵守 `Strict-Transport-Security` 标头。浏览器这样做是因为攻击者可以拦截到站点的 HTTP 连接，然后注入或者删除标头。

### 示例场景

你登录到一个免费 Wi-Fi 热点，然后开始浏览网站，访问你的网上银行，查看你的支出，并且支付一些订单。很不幸，你接入的 Wi-Fi 实际上是黑客的笔记本热点，他们拦截了你原始的 HTTP 请求，然后重定向到一个与你银行网站一模一样的钓鱼网站。现在，你的隐私数据暴露给黑客了。

Strict Transport Security 解决了这个问题；只要你通过 HTTPS 请求访问银行网站，并且银行网站配置好 Strict Transport Security，你的浏览器知道自动使用 HTTPS 请求，这可以阻止黑客的中间人攻击的把戏。

### 浏览器如何处理

你的网站第一次通过 HTTPS 请求，服务器响应 `Strict-Transport-Security` 标头，浏览器记录下这些信息，然后后面尝试访问这个网站的请求都会自动把 HTTP 替换为 HTTPS。

当 `Strict-Transport-Security` 标头设置的过期时间到了，后面通过 HTTP 的访问恢复到正常模式，不会再自动重定向到 HTTPS。

每次浏览器接收到 Strict-Transport-Security 标头，它都会更新这个网站的过期时间，所以网站可以刷新这些信息，防止过期发生。如果有禁用 Strict-Transport-Security 的需求，将 `max-age` 设置为 0（通过 https 连接）将立即使 `Strict-Transport-Security` 标头失效，从而可以通过 http 访问。

预加载 HSTS
--------

谷歌维护着一个 HSTS 预加载服务。按照如下指示成功提交你的域名后，浏览器将会永不使用非安全的方式连接到你的域名。虽然该服务是由谷歌提供的，但所有浏览器都在使用这个预加载列表。但是，这不是 HSTS 标准的一部分，也不该被当作正式的内容。

* Chrome 的 HSTS 预加载列表：https://www.chromium.org/hsts
* Firefox 的 HSTS 预加载列表：nsSTSPreloadList.inc
示例
--

现在和未来的所有子域名会自动使用 HTTPS，有效期（`max-age`）为一年。同时阻止了只能通过 HTTP 访问页面或者子域的内容。

```http
Strict-Transport-Security: max-age=31536000; includeSubDomains
```

虽然将域的有效期（`max-age`）设置为 1 年是可以的，但 https://hstspreload.org 推荐将其设置为 2 年。

在以下示例中，有效期（`max-age`）被设置为 2 年，并带有 `preload` 后缀，该后缀是网站被收录到所有主流的 web 浏览器（如 Chromium、Edge 以及 Firefox）的 HSTS 预加载列表所必须的。

```http
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
```

规范
--

| Specification |
| --- |
| HTTP Strict Transport Security (HSTS) # section-6.1 |

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

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

参见
--

* 博文：HTTP Strict Transport Security 已经落地！
* 博文：HTTP Strict Transport Security（强制 HTTPS）
* OWASP 文章：HTTP Strict Transport Security
* 维基百科：HTTP Strict Transport Security
* HSTS 预加载服务
* 仅限于安全上下文的功能


Cross-Origin-Resource-Policy - HTTP

Cross-Origin-Resource-Policy
============================

**备注：** 由于Chrome 浏览器中的一个 Bug, 设置 Cross-Origin-Resource-Policy（跨域资源策略）会使文件下载失败：当从设置了 CORP 请求头的资源服务器下载资源时，浏览器会阻止用户使用“保存”或“另存为”按钮将文件保存到本地。在决定生产环境中是否使用这一特性（CORP）之前需要慎重考虑。

**`Cross-Origin-Resource-Policy`** 响应头会指示浏览器阻止对指定资源的无源跨域/跨站点请求。

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

语法
--
```

Cross-Origin-Resource-Policy: same-site | same-origin
```

案例
--

下面的响应头会导致兼容该响应头的用户代理禁止跨域访问和跨域资源共享：
```

Cross-Origin-Resource-Policy: same-origin
```

规范
--

| Specification |
| --- |
| Fetch Standard # cross-origin-resource-policy-header |

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

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

相关文章
----

* Cross-Origin Resource Policy (CORP) explainer (en-US)


Accept - HTTP

Accept
======

**`Accept`** 请求头用来告知（服务器）客户端可以处理的内容类型，这种内容类型用MIME 类型来表示。借助内容协商机制, 服务器可以从诸多备选项中选择一项进行应用，并使用 `Content-Type` 应答头通知客户端它的选择。浏览器会基于请求的上下文来为这个请求头设置合适的值，比如获取一个 CSS 层叠样式表时值与获取图片、视频或脚本文件时的值是不同的。

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

语法
--
```

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, */*;q=0.8
```

指令
--

`<MIME_type>/<MIME_subtype>`

单一精确的 MIME 类型，例如`text/html`.

`<MIME_type>/*`

一类 MIME 类型，但是没有指明子类。`image/*` 可以用来指代 `image/png`、`image/svg`、`image/gif` 以及任何其他的图片类型。

`*/*`

任意类型的 MIME 类型

`;q=` (q 因子权重)

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

示例
--
```

Accept: text/html

Accept: image/*

Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
```

规范
--

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

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

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

参见
--

* HTTP 内容协商
* 表示内容协商结果的消息头：`Content-Type`
* 其他相似消息头：`TE`、`Accept-Encoding`、`Accept-Charset`、`Accept-Language`


Accept-Charset - HTTP

Accept-Charset
==============

**`Accept-Charset`** 请求头用来告知（服务器）客户端可以处理的字符集类型。借助内容协商机制，服务器可以从诸多备选项中选择一项进行应用，并使用`Content-Type` 应答头通知客户端它的选择。浏览器通常不会设置此项值，因为每种内容类型的默认值通常都是正确的，但是发送它会更有利于识别。

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

**备注：** 在早期版本的 HTTP/1.1 协议中，规定了一个默认的字符集 (ISO-8859-1)。但是现在情况不同了，目前每一种内容类型都有自己的默认字符集。

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

句法
--
```

Accept-Charset: <charset>

// Multiple types, weighted with the quality value syntax:
Accept-Charset: utf-8, iso-8859-1;q=0.5
```

指令
--

`<charset>`

诸如 `utf-8` 或 `iso-8859-15` 的字符集。

`*`

`在这个消息头中未提及的任意其他字符集；'*'` 用来表示通配符。

`;q=` (q-factor weighting)

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

例子
--
```

Accept-Charset: iso-8859-1

Accept-Charset: utf-8, iso-8859-1;q=0.5

Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1
```

参见
--

* HTTP 内容协商机制
* 不要再用 Accept-Charset 了
* 用来表示内容协商结果的标头：`Content-Type`
* 其他类似的标头：`TE`、`Accept-Encoding`、`Accept-Language`、`Accept`


Content-Disposition - HTTP

Content-Disposition
===================

在常规的 HTTP 应答中，**`Content-Disposition`** 响应标头指示回复的内容该以何种形式展示，是以*内联*的形式（即网页或者页面的一部分），还是以*附件*的形式下载并保存到本地。

在 `multipart/form-data` 类型的应答消息体中，**`Content-Disposition`** 通用标头可以被用在 multipart 消息体的子部分中，用来给出其对应字段的相关信息。各个子部分由在 `Content-Type` 中定义的*边界*（boundary）分隔。用在消息体自身则无实际意义。

`Content-Disposition` 标头最初是在 MIME 标准中定义的，HTTP 表单及 `POST` 请求只用到了其所有参数的一个子集。只有 `form-data` 以及可选的 `name` 和 `filename` 三个参数可以应用在 HTTP 上下文中。

|  |  |
| --- | --- |
| 标头类型 | 响应标头（对于消息主体），请求标头、响应标头（对于多部分主体） |
| 禁止修改的标头 | 否 |

语法
--

### 作为消息主体的标头

在 HTTP 场景中，第一个参数或者是 `inline`（默认值，表示回复中的消息体会以页面的一部分或者整个页面的形式展示），或者是 `attachment`（意味着消息体应该被下载到本地；大多数浏览器会呈现一个“保存为”的对话框，将 `filename` 的值预填为下载后的文件名，假如它存在的话）。

```http
Content-Disposition: inline
Content-Disposition: attachment
Content-Disposition: attachment; filename="filename.jpg"
```

**备注：** 在同源 URL情况下，Chrome 和 Firefox 82 以及更高的版本会优先使用 HTML 的 <a> 元素的 `download` 属性而不是 `Content-Disposition: inline` 参数来处理下载。而 Firefox 的早期版本则优先使用标头信息并内联显示内容。

### 作为多部分主体的标头

当使用 `multipart/form-data` 格式提交表单数据时，每个子部分（例如每个表单字段和任何与字段数据相关的文件）都需要提供一个 `Content-Disposition` 标头，以提供相关信息。标头的第一个指令始终为 `form-data`，并且还*必须*包含一个 `name` 参数来标识相关字段。额外的指令不区分大小写，并使用带引号的字符串语法在 `=` 号后面指定参数。多个参数之间使用分号（`;`）分隔。

```http
Content-Disposition: form-data; name="fieldName"
Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"
```

### 指令

`name`

后面是一个表单字段名的字符串，每一个字段名会对应一个子部分。在同一个字段名对应多个文件的情况下（例如，带有 `multiple` 属性的 <input type=file> 元素），则多个子部分共用同一个字段名。

如果 `name` 参数的值为 `'_charset_'`，意味着这个子部分表示的不是一个 HTML 字段，而是在未明确指定字符集信息的情况下各部分使用的默认字符集。

`filename`

后面是要传送的文件的初始名称的字符串。这个参数总是可选的，而且不能盲目使用：路径信息必须舍掉，同时要进行一定的转换以符合服务器文件系统规则。这个参数主要用来提供展示性信息。当与 `Content-Disposition: attachment` 一同使用的时候，它被用作"保存为"对话框中呈现给用户的默认文件名。

`filename\*`

`filename` 和 `filename*` 两个参数的唯一区别在于，`filename*` 采用了 RFC 5987 中规定的编码方式。当 `filename` 和 `filename*` 同时出现的时候，应该优先采用 `filename*`，假如二者都支持的话。

**警告：** `filename` 参数后面的字符串应该始终用引号包裹。但由于兼容性原因，许多浏览器会尝试解析不带引号的带有空格的文件名。

示例
--

以下是一则可以触发“保存为”对话框的服务器应答：

```http
200 OK
Content-Type: text/html; charset=utf-8
Content-Disposition: attachment; filename="cool.html"
Content-Length: 22

<HTML>Save me!</HTML>
```

这个简单的 HTML 文件会被下载到本地而不是在浏览器中展示。大多数浏览器默认会建议将 `cool.html` 作为文件名。

以下是一个 HTML 表单的示例，展示了在 `multipart/form-data` 格式的报文中使用`Content-Disposition` 标头的情况：

```http
POST /test.html HTTP/1.1
Host: example.org
Content-Type: multipart/form-data;boundary="boundary"

--boundary
Content-Disposition: form-data; name="field1"

value1
--boundary
Content-Disposition: form-data; name="field2"; filename="example.txt"

value2
--boundary--
```

规范
--

| Specification |
| --- |
| Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) # header.field.definition |
| Returning Values from Forms: multipart/form-data # section-4.2 |

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

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

兼容性说明
-----

* 在 `filename` 和 `filename*` 两个参数同时出现的情况下，Firefox 5 可以更好地处理 `Content-Disposition` HTTP 响应标头。它会遍历所有提供的名称，假如 `filename*` 存在的话，就采用它的值，即使 `filename` 更靠前。之前的版本会采用出现在前面的参数的值，导致有更合适的名称而不被使用。参见 Firefox bug 588781。
* Firefox 82（及更高版本）和 Chrome 优先考虑 HTML <a> 元素的 `download` 属性，而不是 `Content-Disposition：inline` 参数（对于同源 URL）。早期的 Firefox 版本优先考虑标头，并会内联显示内容。
参见
--

* HTML 表单
* `Content-Type` 中定义了消息中多部分主体的边界。
* `FormData` 接口可以用来操作在 `XMLHttpRequest` API 中使用的表单数据。


Vary - HTTP

Vary
====

**`Vary`** HTTP 响应标头描述了除方法和 URL 之外影响响应内容的请求消息。大多数情况下，这用于在使用内容协商时创建缓存键。

给定 URL 的所有响应都应使用相同的 `Vary` 标头值，包括 `304` `Not Modified` 响应和“默认”响应。

|  |  |
| --- | --- |
| 标头类型 | 响应标头 |
| 禁止修改的标头 | 否 |

语法
--

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

指令
--

\*

表示请求标头以外的因素影响了此响应的生成。意味着响应不可缓存。

<header-name>

可能影响此响应生成的请求标头名称的逗号分隔列表。

规范
--

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

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

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

### 兼容性备注

* 小心使用 Vary – Vary 标头在 IE6-9 的问题
参见
--

* 理解 Vary 标头 - Smashing Magazine
* 使用 Vary 标头的最佳实践 – fastly.com
* 内容协商


Expires - HTTP

Expires
=======

**`Expires`** 响应头包含日期/时间，即在此时候之后，响应过期。
无效的日期，比如 0，代表着过去的日期，即该资源已经过期。

如果在`Cache-Control`响应头设置了 "max-age" 或者 "s-max-age" 指令，那么 `Expires` 头会被忽略。

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

语法
--
```

Expires: <http-date>
```

指南
--

<http-date>

一个 HTTP-日期 时间戳

示例
--
```

Expires: Wed, 21 Oct 2015 07:28:00 GMT
```

规范
--

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

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

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

其他
--

* `Cache-Control`
* `Age`


X-Frame-Options - HTTP

X-Frame-Options
===============

**`X-Frame-Options`** HTTP 响应头是用来给浏览器指示允许一个页面可否在 `<frame>`、`<iframe>`、`<embed>` 或者 `<object>` 中展现的标记。站点可以通过确保网站没有被嵌入到别人的站点里面，从而避免点击劫持 (en-US)攻击。

仅当访问文档的用户使用支持 `X-Frame-Options` 的浏览器时，此附加的安全性才会被提供。

**备注：** `Content-Security-Policy` HTTP 响应头有一个 `frame-ancestors` 指令，支持这一指令的浏览器已经废弃了 `X-Frame-Options` 响应头。

|  |  |
| --- | --- |
| 首部类型 | 响应首部 |
| 禁止修改的消息首部 | 否 |

语法
--

`X-Frame-Options` 有两个可能的值：
```

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
```

### 指南

如果设置为 `DENY`，不光在别人的网站 frame 嵌入时会无法加载，在同域名页面中同样会无法加载。另一方面，如果设置为 `SAMEORIGIN`，那么页面就可以在同域名页面的 frame 中嵌套。

`DENY`

表示该页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。

`SAMEORIGIN`

表示该页面可以在相同域名页面的 frame 中展示。规范让浏览器厂商决定此选项是否应用于顶层、父级或整个链，有人认为该选项不是很有用，除非所有的祖先页面都属于同一来源（origin）（见 Firefox bug 725490）。参见浏览器兼容性以获取详细的兼容性信息。

`ALLOW-FROM uri`
已弃用

这是一个被弃用的指令，不再适用于现代浏览器，请不要使用它。在支持旧版浏览器时，页面可以在指定来源的 frame 中展示。请注意，在旧版 Firefox 上，它会遇到与 `SAMEORIGIN` 相同的问题——它不会检查 frame 所有的祖先页面来确定他们是否是同一来源。`Content-Security-Policy` HTTP 首部有一个 `frame-ancestors` 指令，你可以使用这一指令来代替。

示例
--

**备注：** 使用 `<meta>` 标签来设置 `X-Frame-Options` 是无效的！例如 `<meta http-equiv="X-Frame-Options" content="deny">` 没有任何效果。不要这样用！只有当像下面示例那样设置 HTTP 头 `X-Frame-Options` 才会生效。

### 配置 Apache

配置 Apache 在所有页面上发送 `X-Frame-Options` 响应头，需要把下面这行添加到 'site' 的配置中：
```

Header always set X-Frame-Options "SAMEORIGIN"
```

要将 Apache 的配置 `X-Frame-Options` 设置成 `DENY`，按如下配置去设置你的站点：
```

Header set X-Frame-Options "DENY"
```

### 配置 Nginx

配置 Nginx 发送 `X-Frame-Options` 响应头，把下面这行添加到 'http', 'server' 或者 'location' 的配置中：
```

add_header X-Frame-Options SAMEORIGIN always;
```

### 配置 IIS

配置 IIS 发送 `X-Frame-Options` 响应头，添加下面的配置到 `Web.config` 文件中：

```xml
<system.webServer>
  ...

  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
    </customHeaders>
  </httpProtocol>

  ...
</system.webServer>
```

参见 Microsoft 关于使用 IIS Manager 来修改这一配置的支持文章用户界面。

### 配置 HAProxy

配置 HAProxy 发送 `X-Frame-Options` 响应头，添加这些到你的前端、监听（listen），或者后端的配置里面：
```

rspadd X-Frame-Options:\ SAMEORIGIN
```

或者，在较新的版本中：
```

http-response set-header X-Frame-Options SAMEORIGIN
```

### 配置 Express

要配置 Express 以发送 `X-Frame-Options` 响应头，你可以使用借助了 frameguard 的 helmet 来设置首部。在你的服务器配置里面添加：

```js
const helmet = require("helmet");
const app = express();
app.use(helmet.frameguard({ action: "SAMEORIGIN" }));
```

或者，你也可以直接用 frameguard：

```js
const frameguard = require("frameguard");
app.use(frameguard({ action: "SAMEORIGIN" }));
```

规范
--

| Specification |
| --- |
| HTML Standard # the-x-frame-options-header |

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

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

参见
--

* `Content-Security-Policy` 的 `frame-ancestors` 指令
* HTTP Header Field X-Frame-Options - RFC 7034
* ClickJacking Defenses - IEBlog
* Combating ClickJacking with X-Frame-Options - IEInternals


ETag - HTTP

ETag
====

**`ETag`** HTTP 响应头是资源的特定版本的标识符。这可以让缓存更高效，并节省带宽，因为如果内容没有改变，Web 服务器不需要发送完整的响应。而如果内容发生了变化，使用 ETag 有助于防止资源的同时更新相互覆盖（“空中碰撞”）。

如果给定 URL 中的资源更改，则*一定*要生成新的 `ETag` 值。比较这些 `ETag` 能快速确定此资源是否变化。

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

语法
--
```

ETag: W/"<etag_value>"
ETag: "<etag_value>"
```

指令
--

`W/` 可选

`'W/'`(大小写敏感) 表示使用弱验证器。弱验证器很容易生成，但不利于比较。强验证器是比较的理想选择，但很难有效地生成。相同资源的两个弱`Etag`值可能语义等同，但不是每个字节都相同。

"<etag\_value>"

实体标签唯一地表示所请求的资源。它们是位于双引号之间的 ASCII 字符串（如“675af34563dc-tr34”）。没有明确指定生成 ETag 值的方法。通常，使用内容的散列，最后修改时间戳的哈希值，或简单地使用版本号。例如，MDN 使用 wiki 内容的十六进制数字的哈希值。

示例
--
```

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"
```

### 避免“空中碰撞”

在`ETag`和 `If-Match` 头部的帮助下，你可以检测到"空中碰撞"的编辑冲突。

例如，当编辑 MDN 时，当前的 wiki 内容被散列，并在响应中放入`Etag`：
```

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4
```

将更改保存到 Wiki 页面（发布数据）时，`POST`请求将包含有 ETag 值的`If-Match`头来检查是否为最新版本。
```

If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

如果哈希值不匹配，则意味着文档已经被编辑，抛出`412`前提条件失败错误。

### 缓存未更改的资源

`ETag`头的另一个典型用例是缓存未更改的资源。如果用户再次访问给定的 URL（设有`ETag`字段），显示资源过期了且不可用，客户端就发送值为`ETag`的`If-None-Match` header 字段：
```

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

服务器将客户端的 `ETag`（与 `If-None-Match` 一起发送）与其当前版本的资源的 `ETag` 进行比较，如果两个值匹配（即资源未更改），服务器将返回不带任何内容的 `304` `Not Modified` 状态，告诉客户端缓存版本可用（*fresh*）。

规范
--

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

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

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

相关内容
----

* `If-Match`
* `If-None-Match`
* `304` `Not Modified`
* `412` `Precondition Failed`
* W3C Note: Editing the Web – Detecting the Lost Update Problem Using Unreserved Checkout


Retry-After - HTTP

Retry-After
===========

在 HTTP 协议中，响应首部 **`Retry-After`** 表示用户代理需要等待多长时间之后才能继续发送请求。这个首部主要应用于以下两种场景：

* 当与 `503` (Service Unavailable，当前服务不存在) 响应一起发送的时候，表示服务下线的预期时长。
* 当与重定向响应一起发送的时候，比如 `301` (Moved Permanently，永久迁移)，表示用户代理在发送重定向请求之前需要等待的最短时间。

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

语法
--
```

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

指令
--

<http-date>

表示在此时间之后可以重新尝试。参见 `Date` 首部来获取 HTTP 协议中关于日期格式的细节信息。

<delay-seconds>

一个非负的十进制整数，表示在重试之前需要等待的秒数。

示例
--

### 对于计划内宕机时间的处理

不同的客户端与服务器端应用对于 Retry-After 首部的支持依然不太一致。不过，一些爬虫程序，比如谷歌的爬虫程序 Googlebot，会遵循 Retry-After 首部的规则。将其与 `503` (Service Unavailable，当前服务不存在) 响应一起发送有助于互联网引擎做出判断，在宕机结束之后继续对网站构建索引。
```

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

规范
--

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

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

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

相关内容
----

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


Connection - HTTP

Connection
==========

**`Connection`** 通用标头控制网络连接在当前会话完成后是否仍然保持打开状态。如果发送的值是 `keep-alive`，则连接是持久的，不会关闭，允许对同一服务器进行后续请求。

**警告：** 在 HTTP/2 和 HTTP/3 中，禁止使用特定于连接的标头字段，如 `Connection` 和 `Keep-Alive`。Chrome 和 Firefox 会在 HTTP/2 响应中忽略它们，但 Safari 遵循 HTTP/2 规范要求，不会加载包含这些字段的任何响应。

除去标准的逐段传输（hop-by-hop）头（`Keep-Alive`, `Transfer-Encoding`, `TE`, `Connection`, `Trailer`, `Upgrade` (en-US), `Proxy-Authorization` and `Proxy-Authenticate`），任何逐段传输头都需要在 Connection 头中列出，这样才能让第一个代理知道必须处理它们且不转发这些头。标准的逐段传输头也可以列出（常见的例子是 `Keep-Alive`，但这不是必须的）。

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

语法
--

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

指令
--

`close`

表明客户端或服务器想要关闭该网络连接，这是 HTTP/1.0 请求的默认值

以逗号分隔的 HTTP 头 [通常仅有 `keep-alive`]

表明客户端想要保持该网络连接打开，HTTP/1.1 的请求默认使用一个持久连接。这个请求头列表由头部名组成，这些头将被第一个非透明的代理或者代理间的缓存所移除：这些头定义了发出者和第一个实体之间的连接，而不是和目的地节点间的连接。

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

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


Accept-Patch - HTTP

Accept-Patch
============

服务器使用 HTTP 响应头 **`Accept-Patch`** 通知浏览器请求的媒体类型 (media-type) 可以被服务器理解。

**`Accept-Patch`** in response to any method means that PATCH is allowed on the resource identified by the Request-URI. Two common cases lead to this:

A server receiving a PATCH request with an unsupported media type could reply with `415` `Unsupported Media Type` and an Accept-Patch header referencing one or more supported media types.

**备注：** An IANA registry maintains a complete list of official content encodings.

* Two others content encoding, `bzip` and `bzip2`, are sometimes used, though not standard. They implement the algorithm used by these two UNIX programs. Note that the first one was discontinued due to patent licensing problems.

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

语法
--
```

Accept-Patch: application/example, text/example
Accept-Patch: text/example;charset=utf-8
Accept-Patch: application/merge-patch+json
```

指令
--

(无)

示例
--
```

Accept-Patch: application/example, text/example

Accept-Patch: text/example;charset=utf-8

Accept-Patch: application/merge-patch+json
```

规范
--

| Specification |
| --- |
| RFC 5789 # section-3.1 |

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

浏览器的兼容性与此标头无关（标头是由服务器发送的，规范没有定义客户端行为）。

参见
--

* HTTP 方法 `PATCH`
* HTTP 语义和上下文 RFC 7231, section 4.3.4: PUT


Access-Control-Request-Method - HTTP

Access-Control-Request-Method
=============================

请求头 **`Access-Control-Request-Method`** 出现于 preflight request（预检请求）中，用于通知服务器在真正的请求中会采用哪种 HTTP 方法。因为预检请求所使用的方法总是 `OPTIONS` ，与实际请求所使用的方法不一样，所以这个请求头是必要的。

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

语法
--
```

Access-Control-Request-Method: <method>
```

指令
--

<method>

一种 HTTP 请求方法, 例如 `GET`、`POST` 或 `DELETE`。

示例
--
```

Access-Control-Request-Method: POST
```

规范
--

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

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

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

相关内容
----

* `Access-Control-Request-Headers`


Proxy-Authenticate - HTTP

Proxy-Authenticate
==================

The HTTP **`Proxy-Authenticate`** 是一个响应首部，指定了获取 proxy server（代理服务器）上的资源访问权限而采用的身份验证方式。代理服务器对请求进行验证，以便它进一步传递请求。

`Proxy-Authenticate` 首部需要与 `407` `Proxy Authentication Required` 响应一起发送。

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

语法
--
```

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

指令
--

<type>

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

realm=<realm>

对于被保护区域（即安全域）的描述。如果没有指定安全域，客户端通常用一个格式化的主机名来代替。

示例
--
```

Proxy-Authenticate: Basic

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

规范
--

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

相关内容
----

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