recursal/MDN huggingface dataset:
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
======

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

响应标头 **`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
======================

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

请求标头 **`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
===========================

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

**`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`
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`**（通常简称为 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
============================

**备注：** 由于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
======

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

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

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

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

**`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`** 表示用户代理需要等待多长时间之后才能继续发送请求。这个首部主要应用于以下两种场景：

* 当与 `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
==========

**`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`** 通知浏览器请求的媒体类型 (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