引用来源策略

1. 引言

本节不具有规范性。

从文档发出的请求以及离开该文档的导航都与 Referer 标头相关联。虽然对于使用 noreferrer 链接类型的链接，该标头可以被禁止，但由于多种原因，作者可能希望更直接地控制 Referer 标头。

1.1. 隐私

社交网站为每个用户提供个人资料页面，用户可以在其个人资料页面中添加指向其最喜爱乐队的超链接。当其他用户点击这些超链接时，社交网站可能不希望向乐队网站泄露用户的个人资料网址（因为个人资料网址可能会泄露资料所有者的身份）。

然而，一些社交网站可能希望告知乐队网站这些链接源自该社交网站，但不希望透露包含这些链接的具体是哪位用户的个人资料。

1.2. 安全

Web 应用程序使用 HTTPS 和基于网址的会话标识符。Web 应用程序可能希望链接到其他网站上的 HTTPS 资源，而不泄露网址中的用户会话标识符。

或者，Web 应用程序可能使用自身授予某种能力的网址。控制引荐来源有助于防止这些能力网址通过引荐来源标头泄露。[CAPABILITY-URLS]

请注意，能力网址还有其他泄露方式，仅控制引荐来源不足以控制所有潜在的泄露。

1.3. 引用通告（Trackback）

托管在 HTTPS 上的博客可能希望链接到托管在 HTTP 上的博客并接收引用通告链接。

2. 关键概念和术语

引用来源策略

引荐来源网址策略会修改在 获取 子资源、预获取或执行导航时用于填充 Referer 标头的算法。本文档定义了每种 引荐来源网址策略 的各种行为。

每个 环境设置对象 都有一种获取 引荐来源网址策略 的算法，默认情况下，所有以该 环境设置对象 为 客户端 的 请求 都会使用该策略。

同源请求

如果 Request 请求 的 源 与 请求 的 当前网址 的 源 相同，则该 请求 为同源请求。

跨源请求

如果 Request 不是 同源 的，则该 请求 为跨源请求。

3. 引荐来源网址策略

引荐来源网址策略可以是空字符串、“no-referrer”、“no-referrer-when-downgrade”、“same-origin”、“origin”、“strict-origin”、“origin-when-cross-origin”、“strict-origin-when-cross-origin”或“unsafe-url”。

enum ReferrerPolicy {
  "",
  "no-referrer",
  "no-referrer-when-downgrade",
  "same-origin",
  "origin",
  "strict-origin",
  "origin-when-cross-origin",
  "strict-origin-when-cross-origin",
  "unsafe-url"
};

下面解释了每种可能的 引荐来源网址策略。关于评估其效果的详细算法，请参见 §5 与 Fetch 的集成 和 §8 算法 章节。

注意：当 环境设置对象 被用作 请求客户端 时，该对象的引荐来源网址策略为其请求提供了默认的基础策略。对于特定请求，该策略可以通过诸如 noreferrer 链接类型等机制进行强化。

3.1. "no-referrer"

最简单的策略是 "no-referrer"，它指定从特定 请求客户端 向任何 源 发出的请求不应发送引荐来源信息。标头将被完全省略。

3.2. "no-referrer-when-downgrade"

"no-referrer-when-downgrade" 策略会在从 受 TLS 保护的 环境设置对象 向 潜在可信网址 发出请求，以及从 非 受 TLS 保护的 客户端 向任何 源 发出请求时，发送完整的网址。

另一方面，从 受 TLS 保护的 客户端 向非 潜在可信网址 发出的请求将不包含任何引荐来源信息。Referer HTTP 标头将不会被发送。

这是在未另行指定策略时，用户代理的默认行为。

3.3. "same-origin"

"same-origin" 策略指定在从特定 客户端 发出 同源请求 时，将 剥离用于引荐来源 的完整网址作为引荐来源信息发送。

另一方面，跨源请求 将不包含任何引荐来源信息。Referer HTTP 标头将不会被发送。

3.4. "origin"

"origin" 策略指定在从特定 客户端 发出 同源请求 和 跨源请求 时，仅将 请求客户端 源 的 ASCII 序列化 作为引荐来源信息发送。

注意：源的序列化看起来像 https://example.com。为了确保在 `Referer` 标头中发送有效的网址，用户代理会在源后附加一个 U+002F SOLIDUS ("/") 字符（例如 https://example.com/）。

注意："origin" 策略会导致 HTTPS 引荐来源的源在非加密的 HTTP 请求中通过网络发送。"strict-origin" 策略解决了这一问题。

3.5. "strict-origin"

"strict-origin" 策略在发出请求时发送 请求客户端 源 的 ASCII 序列化

• 从 受 TLS 保护的 环境设置对象 向 潜在可信网址 发出请求时，以及
• 从 非 受 TLS 保护的 环境设置对象 向任何 源 发出请求时。

另一方面，从 受 TLS 保护的 请求客户端 向非 潜在可信网址 发出的请求将不包含任何引荐来源信息。Referer HTTP 标头将不会被发送。

4. 引荐来源网址策略的传递

请求 的 引荐来源网址策略 通过以下五种方式之一进行传递

• 通过 Referrer-Policy HTTP 标头（在 §4.1 通过 Referrer-Policy 标头传递 中定义）。
• 通过 meta 元素，其 name 为 referrer。
• 通过 a、area、img、iframe 或 link 元素上的 referrerpolicy 内容属性。
• 通过 a、area 或 link 元素上的 noreferrer 链接关系。
• 隐式地，通过继承。

4.1. 通过 Referrer-Policy 标头传递

Referrer-Policy HTTP 标头指定了用户代理在确定请求时应包含哪些引荐来源信息，以及在从受保护资源的上下文中创建的 浏览上下文 中应包含哪些引荐来源信息时所应用的引荐来源网址策略。标头的名称和值的语法由以下 ABNF 文法描述。

"Referrer-Policy:" 1#policy-token

policy-token   = "no-referrer" / "no-referrer-when-downgrade" / "strict-origin" / "strict-origin-when-cross-origin" / "same-origin" / "origin" / "origin-when-cross-origin" / "unsafe-url"

注意：此标头名称不具有 HTTP Referer 标头的拼写错误。

§5 与 Fetch 的集成 和 §6 与 HTML 的集成 描述了如何处理 Referrer-Policy 标头。

Referrer-Policy: no-referrer

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

7. 与 CSS 的集成

CSS 标准未指定其如何获取样式表中引用的资源。但是，实现应确保按如下方式设置样式表所发起的任何 请求 的引荐来源相关属性：

1. 如果 CSS 声明块 对请求负责，则将 引荐来源 设置为块的 所有者节点 的 节点文档 的 网址，并将 引荐来源网址策略 设置为块的 所有者节点 的 节点文档 的 引荐来源网址策略。
2. 如果 CSS 样式表 对请求负责，且其 位置 不为 null，则将 引荐来源 设置为它的 位置，并将 引荐来源网址策略 设置为它的 引荐来源网址策略。 这要求 CSS 样式表处理 `Referrer-Policy` 标头，并以与 Documents do 相同的方式存储 引荐来源网址策略。
3. 否则，具有 null 位置 的 CSS 样式表 对请求负责：将 引荐来源 设置为它的 所有者节点 的 节点文档 的 网址，并将 引荐来源网址策略 设置为块的 所有者节点 的 节点文档 的 引荐来源网址策略。

注意：请求 的 引荐来源 和 引荐来源网址策略 的值都是在创建给定 请求 时根据当时的值设置的。如果文档的引荐来源网址策略在其生命周期内发生变化，关联的内联样式表请求的策略也将发生变化。

8. 算法

8.1. 从 Referrer-Policy 标头解析引荐来源网址策略

给定一个 Response 响应，以下步骤根据 响应 的 `Referrer-Policy` 标头返回一个 引荐来源网址策略

1. 令 策略标记 为 响应 的 标头列表 中 `Referrer-Policy` 的 解析 结果。
2. 令 策略 为空字符串。
3. 对于 策略标记 中的每个 标记，如果 标记 是一个 引荐来源网址策略 且 标记 不是空字符串，则将 策略 设置为 标记。注意：此算法会循环遍历多个策略值，以便在较旧的用户代理中部署具有回退功能的新策略值，如 §11.1 未知的策略值 中所述。
4. 返回 策略。

8.2. 在重定向时设置 请求 的引荐来源网址策略

给定一个 请求 请求 和一个 响应 实际响应，此算法会根据 实际响应 中的 Referrer-Policy 标头（如有）更新 请求 关联的 引荐来源网址策略。

1. 令 策略 为对 实际响应 执行 §8.1 从 Referrer-Policy 标头解析引荐来源网址策略 的结果。
2. 如果 策略 不为空字符串，则将 请求 关联的引荐来源网址策略设置为 策略。

8.3. 确定 请求 的引荐来源

给定一个 Request 请求，我们可以通过检查与之关联的 引荐来源网址策略 来确定要发送的正确引荐来源信息，如下列步骤所述，这些步骤返回 no referrer 或一个网址

1. 令 策略 为 请求 关联的 引荐来源网址策略。
2. 令 环境 为 请求 的 客户端。
3. 根据 请求 的 引荐来源 进行切换
   "client"
   1. 如果 环境 的 全局对象 是一个 Window 对象，则
   2. 令 文档 为 环境 的 全局对象 的 关联 Document。
   3. 如果 文档 的 源 是一个 不透明源，则返回 no referrer。
   4. 当 文档 是 一个 iframe srcdoc 文档 时，令 文档 为 文档 的 浏览上下文 的 浏览上下文容器 的 节点文档。
   5. 令 引荐来源源 为 文档 的 网址。
4. 否则，令 引荐来源源 为 环境 的 创建网址。

注意：Fetch 将确保 请求 的 引荐来源网址策略 在调用此算法之前不为空字符串。

8.4. 剥离 网址 以用作引荐来源

在将网址作为 `Referer` 标头的值发送时，不得包含网址的某些部分：在发送网址之前，应剥离其片段、用户名和密码组件。此算法接受一个 origin-only 标志，其默认值为 false。如果设置为 true，算法将额外删除网址的路径和查询组件，仅保留方案、主机和端口。

1. 如果 网址 为 null，返回 no referrer。
2. 如果 网址 的 方案 是一个 本地方案，则返回 no referrer。
3. 将 网址 的 用户名 设置为空字符串。
4. 将 网址 的 密码 设置为 null。
5. 将 网址 的 片段 设置为 null。
6. 如果 origin-only 标志 为 true，则
7. 将 网址 的 路径 设置为 null。
8. 将 网址 的 查询 设置为 null。

9. 隐私考量

9.1. 用户控制

本规范中的任何内容都不应被解释为阻止用户代理向用户提供选项，从而更改通过 `Referer` 标头发送的信息。例如，用户代理可以允许用户完全禁止引荐来源标头，而不考虑页面上的活动 引荐来源网址策略。

10. 安全考量

10.1. 信息泄露

引荐来源网址策略 "origin"、"origin-when-cross-origin" 和 "unsafe-url" 可能会分别通过不安全的传输方式泄露安全站点的源和网址。

尽管如此，这三种策略仍被包含在规范中，以降低站点采用安全传输的阻力。

希望确保不泄露比默认策略更多信息的作者，应转而使用策略状态 "same-origin"、"strict-origin"、"strict-origin-when-cross-origin" 或 "no-referrer"。

10.2. 降级到较宽松的策略

规范并未禁止降级到较宽松的策略，例如从 "no-referrer" 到 "unsafe-url"。

一方面，对于所有可能的策略对，并不清楚哪种策略更为严格：虽然 "no-referrer-when-downgrade" 不会通过不安全的传输泄露任何信息，而 "origin" 会，但后者在跨源导航中泄露的信息较少。

另一方面，允许设置较宽松的策略使作者能够定义安全的回退方案，如 §11.1 未知的策略值 中所述。

11. 创作注意事项

11.1. 未知的策略值

如 §8.1 从 Referrer-Policy 标头解析引荐来源网址策略 和 meta referrer 算法中所述，未知的策略值将被忽略；当多个来源指定了引荐来源网址策略时，将使用最新的值。这使得部署新的策略值成为可能。

12. 致谢

本规范在很大程度上基于 Adam Barth 和 Jochen Eisinger 的 Meta referrer 文档。