什么是内容协商？HTTP 表示的解释

什么是内容协商？

内容协商是 HTTP 过程，用于在有多个变体时选择资源的一个表示。客户端可以表达媒体类型、语言、内容编码或相关维度的偏好，服务器根据其可用的变体和策略选择合适的响应。资源在概念上保持不变，而返回的表示可以不同。

有用的定义包括机制及其边界。内容协商影响交换中的特定部分，而相邻的责任仍然与 HTTP、浏览器、所选传输、应用程序或服务器的数据模型相关。保持这些层次分开使错误报告可复现，并防止配置变更被误认为是访问控制决策。

对于 API 开发者，第一个问题是由谁创建值或行为。下一个问题是由谁解释它。最后一个问题是可观察的结果是什么，证明解释有效。这三个答案将词汇术语转换为可测试的接口合同。

HTTP 如何选择表示

在主动协商中，客户端发送 Accept、Accept-Language 和 Accept-Encoding 等偏好字段。值可以包括质量权重，用于对替代方案进行排序。服务器应用其自己的选择算法，因为 HTTP 定义了偏好语法，但并不强制一种通用的排序算法。

所选响应携带表示元数据，如 Content-Type、Content-Language 和 Content-Encoding。Vary 告诉缓存哪些请求字段影响了选择。没有正确的变体，缓存可能会向请求了其他语言或编码的客户端提供一种语言或编码。

反应式协商以揭示替代方案的响应开始，并允许用户代理进行选择。对于普通的网络 API 来说，这不太常见，但在概念上是有用的：服务器可以拒绝猜测，并给客户端另一个选择步骤。

当没有可接受的可用表示时，服务器可以返回 406，尽管许多系统选择默认值。对于请求体，415 可以报告不支持的媒体类型。响应偏好和请求体支持是相关的协商，但发生在不同的方向。

表示选择背后的字段

以下术语分离通常合并为一个标签的组件。将它们视为参与者之间的接口，而不是网络跟踪中的装饰。

为什么内容协商在网络数据收集中重要

内容协商可以改变到达的字节、这些字节的解释方式，或浏览器代码是否可以观察结果。收集工作流应该在更改工具之前定位该效应。记录请求的 URL、最终 URL、响应状态、表示类型、相关协议字段和一个预期的内容标记。该紧凑记录区分了正确的页面与访问消息、同意屏幕、重定向目标、空应用程序外壳或不兼容的编码。

直接 HTTP 是最简单的获取路径，当所需数据存在于开放的服务器渲染响应中时。审批的内容依赖于 JavaScript 执行、浏览器管理的状态、导航或浏览器安全策略时，浏览器变得相关。两个路径不应被强制看起来相同：浏览器根据平台规则管理 cookies、压缩、重定向、CORS 和存储，而直接客户端暴露一组不同的默认值。

当一个响应为下一个请求建立状态时，会话连续性很重要。将授权序列保持在一个有界的客户端上下文中，保留所需的区域和网络来源，避免混合不相关作业的状态。代理更改网络来源；它不会重现头部、解码表示、执行脚本或授予对受限内容的访问。

解析仅在表示验证后开始。在提取字段之前，确认最终主机、可用的规范身份、媒体类型、解码状态和所需的业务标记。这个顺序防止解析器将错误文档转换为看似技术成功的空记录。

中介值得明确关注。内容交付网络可以选择编码变体，网关可以响应OPTIONS，缓存可以重用协商的响应，应用服务器可以设置cookie或授权字段。仅比较应用代码与最终页面输出跳过了可能做出决策的层。

无抓取的通用抓取API在团队需要管理允许的公共内容的检索时相关，包括JavaScript渲染的页面。收购合同仍应定义目标、允许字段、预期表示、接受标记和停止条件。产品能力并不能替代源条款、隐私审核或应用级验证。

谈判解决了一个真实的问题

内容协商在架构中占有一席之地，当它改变具体产品行为、兼容性要求或诊断决策时。这些用例首先描述工作，然后描述协议特性。

主动、反应式和基于URL的选择

内容协商属于HTTP的一层，不应与相邻层混淆。一个合理的实现识别出哪个组件选择值，哪个组件可以更改它，以及什么证据证明最终表示是正确的。

只有在保留层边界的情况下比较才有用。两个机制可能共存于一个请求中，替换一个并不自动替换另一个。以输入、可观察输出、失败状态和所有权的术语记录选定的行为。

内容协商错误

• 忽视Vary。 缓存需要知道哪些请求偏好改变了选择的表示。
• 将质量权重视为命令。 权重对客户端偏好进行排名，而服务器能力和政策仍然决定结果。
• 重载User-Agent。 User-Agent推断脆弱且不如专用协商字段明确。
• 返回错误的Content-Type。 客户使用响应元数据解析选定的表示，因此错误的类型可能会破坏处理。
• 谈判过多的维度。 每个维度都会增加缓存键、测试以及意外选择的可能性。
• 隐藏规范变体 URL。 不同的 URL 即使在谈判提供方便的默认值时也可以改善链接和调试。

大多数故障在消除关于库或浏览器自动执行的假设后变得更易于诊断。捕获最小痕迹，编辑秘密，每次改变一个受控变量。目标是稳定返回表示的解释，而不是一系列不相关的头部调整。

表示选择审核

此序列在启动前作为设计审查，在行为变化后作为生产诊断工作。它将协议证据与应用结果连接。

1. 列出实际上可用的一个资源的表示和不同的维度。
2. 逐个发送受控的 Accept、Accept-Language 和 Accept-Encoding 值。
3. 记录每个结果的 Content-Type、Content-Language、Content-Encoding 和 Vary。
4. 测试不可接受的优先级，并记录服务器是返回 406 还是默认值。
5. 检查两个表达不同偏好的客户端的共享缓存。
6. 验证重定向是否保留预期的变体合同，并且不删除语言或格式选择。
7. 为读者或系统需要书签、索引或直接比较的变体保持一个不同的 URL。

通过保存一个小的接受样本和一个被拒绝的样本并应用相同的编辑规则来完成审查。未来的更改可以与已知页面身份、预期字段和解码内容进行比较，而不是仅仅依赖内存或屏幕截图。

内容谈判的安全性和可观察性

内容谈判参与一个请求路径，该路径可能穿越浏览器、网关、缓存和源服务器。每个跳转应仅接受它理解的值，保留必须幸存的字段，并避免将凭据或个人数据复制到日志中。协议语法不是授权。

操作记录应捕获请求的 URL、最终 URL、状态、表示类型、相关字段名称和边界内容标记。完整的主体和凭据值在例行诊断中很少需要，并且可能创建不必要的保留风险。

浏览器行为和直接 HTTP 行为是不同的测试表面。CORS、cookie 存储、自动解压缩和重定向处理在应用代码查看结果之前可能由浏览器或库执行。比较抓取时记录客户端及其默认值。

定义内容谈判的标准

HTTP 内容谈判规范 定义主动、反应和请求谈判。此主要来源修正了本文中使用的词汇和边界，同时实现行为仍需在所选客户端和部署中观察。

MDN 的内容谈判指南 解释常见字段和选择模式。此主要来源修正了本文中使用的词汇和边界，同时实现行为仍需在所选客户端和部署中观察。

IANA 媒体类型注册表 列出注册的表示媒体类型。此主要来源修正了本文中使用的词汇和边界，同时实现行为仍需在所选客户端和部署中观察。

语言范围匹配规范 定义语言标签的匹配。此主要来源修正了本文中使用的词汇和边界，同时实现行为仍需在所选客户端和部署中观察。

谈判设计测试

当多个表示真正共享一个资源身份时，使用内容谈判，保持选择维度明确，并将缓存变体和响应元数据作为合同的一部分。

将该规则放入接受测试中。说明哪个参与者发送信号，哪个参与者解释信号，哪些中介可以更改路径，以及哪个内容标记证明成功。这使内容谈判成为一个可观察系统的一部分，而不是在失败后附加的标签。

参考

• 无痛的通用抓取 API 文档
• 无痛的通用抓取 API 产品概述
• 无痛的头部、 Cookies、会话和表示验证指南
• 无痛的 GitHub