HTTP 客户端提示

在本文档中，关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和 "OPTIONAL" 应按 BCP 14 中描述的方式解释（见 [RFC2119] 与 [RFC8174]），仅当它们以全大写形式出现时，才具有该含义。

本文档使用扩展巴科斯-诺尔范式 (ABNF) 表示法，参见 [RFC5234]。

用户代理基于其默认设置、用户配置以及服务器在 Accept-CH 中表达的偏好来选择在请求中发送哪些客户端提示。用户代理和服务器可以使用下面概述的选择加入(opt-in)机制来协商需要发送的首部字段，以实现高效的内容适配，并且它们可以可选地使用额外机制（例如在 [CLIENT-HINTS-INFRASTRUCTURE] 中概述的机制）来协商委托策略，从而控制第三方对相同首部字段的访问。用户代理 SHOULD 要求对任何不被视为低熵的提示进行选择加入。有关暴露低熵量的提示示例，请参阅 [CLIENT-HINTS-INFRASTRUCTURE] 中的低熵提示表。

实现者在实现对客户端提示的支持时需要注意指纹识别的影响，并遵循本文档“安全性考量”一节中概述的注意事项（见 第4节）。

当收到包含一个或多个客户端提示首部字段的请求时，服务器可以基于其中的信息优化响应。当这样做时，如果资源是可缓存的，服务器 MUST 还必须生成一个 Vary 响应头字段（参见 RFC7231 第7.1.4节），以指示哪些提示可能影响所选择的响应以及该响应是否适用于后续请求。

服务器 MUST 忽略它们不理解或不支持的提示。当前没有机制让服务器向用户代理指示哪些提示被忽略。

此外，服务器可以生成与所使用的提示指定的相关值的附加响应头字段，以帮助客户端处理。

Accept-CH 响应头字段指示服务器对其值中所示提示的支持。希望通过客户端提示接收用户代理信息的服务器 SHOULD 尽早在响应中添加 Accept-CH 响应头。

  Accept-CH = sf-list

Accept-CH: Sec-CH-Example, Sec-CH-Example-2

当用户代理接收到包含 Accept-CH 的 HTTP 响应时，表示该源已选择接收所指示的请求首部字段以用于随后同源请求。如果该选择加入是通过非安全传输（使用与 HTTPS 不同的方案）发送的，则 MUST 忽略该选择加入。该选择加入 SHOULD 被持久化并绑定到该源，以便在用户会话期间（由用户代理定义）向服务器的源发送客户端提示。一个选择加入会覆盖先前持久化的选择加入值，并且 SHOULD 用其替代先前的持久化值。

基于上面的 Accept-CH 示例，若在用户代理导航到 "https://site.example" 时收到该响应并通过安全传输发送，则持久化的 Accept-CH 偏好将绑定到 "https://site.example"。随后它会用于诸如 "https://site.example/foobar.html" 的导航，但不会用于例如 "https://foobar.site.example/"。它也会用于由该导航响应构造的页面发起的任何同源资源请求（例如 "https://site.example/image.jpg"），但不会用于跨源资源请求（例如 "https://thirdparty.example/resource.js"）。该偏好不会扩展到从其他源发起到 "https://site.example" 的资源请求（例如从 "https://other.example/" 的导航）。

当基于一个或多个客户端提示选择响应且资源是可缓存的时，服务器需要生成一个 Vary 响应头字段（参见 [RFC7234]）以指示哪些提示可能影响所选择的响应以及该响应是否适用于后续请求。

Vary: Sec-CH-Example

上述示例指示缓存键需要包含 Sec-CH-Example 首部字段。

Vary: Sec-CH-Example, Sec-CH-Example-2

上述示例指示缓存键需要包含 Sec-CH-Example 和 Sec-CH-Example-2 首部字段。

在依赖本文档的功能中使用的请求首部字段会暴露用户环境的信息，以实现隐私保护的主动内容协商并避免暴露被动指纹识别向量。然而，实现者需要记住，在最坏情况下，不受控制和不受监测的主动指纹识别并不优于被动指纹识别。为了提供用户隐私的好处，用户代理需要应用进一步的策略以防止滥用通过客户端提示暴露的信息。

这些功能暴露的信息可能会揭示关于用户的新信息，实现者应考虑下列注意事项、建议和最佳实践。

潜在的基本假设是，通过请求首部暴露关于用户的信息在安全角度上等价于通过其他方式暴露这些信息。（例如，如果请求的源可以使用 JavaScript API 访问该信息并将其传输到其服务器。）

由于客户端提示是一种显式的选择加入机制，这意味着希望访问用户环境信息的服务器需要主动请求该信息，从而使客户端和隐私研究人员能够跟踪哪些源收集这些数据，并可能据此采取行动。基于首部的选择加入意味着可以消除被动指纹识别向量。例如，用户代理可以减少在 User-Agent 字符串中暴露的信息，同时通过用户代理客户端提示（User-Agent Client Hints）以主动方式提供该信息。或者，用户代理可以以不增加被动指纹识别面的方式暴露通过脚本已可获得的信息（例如 Save-Data 客户端提示 <https://wicg.github.io/savedata/#save-data-request-header-field>）。支持客户端提示功能并向选择加入的服务器发送某些信息的用户代理 SHOULD 避免以被动方式发送等效信息。

因此，依赖本文档定义客户端提示首部的功能 MUST NOT 提供用户代理未向应用程序公开的新信息，例如现有的请求首部、HTML、CSS 或 JavaScript 所提供的信息。

熵：

暴露高度细粒度的数据可能被用来帮助识别跨不同源的用户。减少可表达的首部字段值集合，或将其限制为一个枚举范围，其中通告的值接近但并非当前值的精确表示，可以通过确保多个用户发送相同值来提高隐私并降低可连通性风险。

敏感性：

该功能 SHOULD NOT 暴露用户敏感信息。为此，向应用可用但需特定用户操作（例如权限提示或用户激活）才能获得的信息 SHOULD NOT 作为客户端提示暴露。

随时间变化：

除非状态变化本身也被暴露（例如通过 JavaScript 回调），否则该功能 SHOULD NOT 暴露随时间变化的用户信息。

不同的功能将在低熵、非敏感和静态信息（例如用户代理信息）与高熵、敏感和动态信息（例如地理位置）之间的不同位置被定位。用户代理需要权衡特定功能提供的价值与这些考虑，并可能希望对不同功能或其他细粒度基础有不同的策略。

• 实现者 SHOULD 将某些或全部客户端提示首部字段的传递限制为仅限选择加入的源，除非选择加入的源已明确将请求客户端提示首部字段的权限委托给另一个源。
• 考虑提供允许用户在隐私顾虑与带宽限制之间权衡的用户选择机制的实现者，还需要考虑向用户解释所涉隐私含义（例如被动指纹识别的风险）可能具有挑战性甚至不切实际。
• 针对某些用例或威胁模型的实现 MAY 避免传输某些或全部客户端提示首部字段。例如，避免传输可能带来更高可连通性风险的首部字段。

用户代理 MUST 在站点数据、浏览缓存、Cookie 或类似数据被清除时清除持久化的选择加入偏好。

• 可能与已有首部字段名的冲突
• 首部字段值中所传达数据的属性

新的客户端提示作者应谨慎考虑它们是否需要由客户端内容（例如脚本）添加，或是否需要由用户代理专门设置。在后一种情况下，首部字段名上的 Sec- 前缀具有防止脚本和其他应用内容在用户代理中设置它们的效果。使用 "Sec-" 前缀向服务器表明该值是由用户代理生成的——而不是由应用内容生成的。有关详细信息，请参见 [FETCH]。

按惯例，作为客户端提示的请求首部建议使用 CH- 前缀，以便更容易将它们识别为使用该框架的首部；例如 CH-Foo 或带有 "Sec-" 前缀时为 Sec-CH-Foo。这样可以使它们更容易通过编程方式识别（例如，隐私过滤器通过程序化方式从请求中剥离不被识别的提示）。

通过 Accept-CH 选择加入机制协商的客户端提示请求首部 MUST 具有与 sf-token 相匹配的字段名（参见 RFC8941 第3.3.4节）。

跟踪对主动指纹识别信息访问的用户代理 SHOULD 考虑将客户端提示首部的发出视为对等的等同于对等 API 的访问。

关于客户端提示滥用的研究可能会考察包含客户端提示的请求与具有不同值或不带值的请求之间的 HTTP 响应差异。这可能被用来揭示哪些客户端提示正在被使用，从而允许研究人员进一步分析该使用情况。

首部字段名：

Accept-CH

适用协议：

HTTP

状态：

试验性

作者/变更控制：

IETF

规范文档：

本 RFC 第3.1节

相关信息：

用于客户端提示