摘要

  • Content-Location 标识消息所携表示内容对应的具体资源。它的含义取决于请求方法、响应状态，以及解析后的值是否等于目标 URI；无论哪一种情况，它都不会替代请求目标。
  • 客户端可用它更新本地副本、识别内容协商选中的变体，或以后获取一份操作报告。它本身不构成重定向、规范网址声明、共同所有权证明，也不授予后续 GET 或写入权限。

客户端向购买服务发送一次 POST，收到成功响应。正文是一张收据，响应头还有 Content-Location: /receipts/47。这时，系统最容易犯的错误，是把最后出现的 URI 当成整个操作的新地址。

实际上，POST 的目标仍是交易服务。正文对应的是收据资源。若操作还创建了新对象，Location 又可能指向那个对象。三个身份可以同时成立，并不需要压成一个“规范 URL”。

Content-Location 所说的只是：随消息返回的这份表示内容，对应某个具体资源。它没有要求客户端把 POST 重发到收据地址，没有把原响应变成跳转，也没有赋予编辑收据的权力。

目标 URI 不会被响应头追溯改写

请求发出时，目标 URI 与方法共同界定这次操作落在哪里。它参与 HTTP 路由，也是认证、授权、日志和应用处理的基本上下文。响应到达后，其中的字段可以描述所选表示、链接其他资源或给出来源信息，却不能追溯性地把刚才的目标换掉。

RFC 9110 将 Content-Location 定义为绝对 URI 或部分 URI 引用。它可用来标识与消息正文中的表示相对应的具体资源。标准用一个带时间的假设解释这层关系：在消息生成之时，对该 URI 执行 GET，200 响应会包含同一份表示。

若值是部分引用，就按照普通 URI 解析规则，以目标 URI 为基准得到绝对形式。完成解析后，接收者可以比较二者是否相同。紧接着，规范给出最重要的边界：Content-Location 不是目标 URI 的替代品，它是表示元数据。

二者都长得像地址，正是混淆的来源。软件很擅长把 URI 规范化、打开、索引或当作主键，于是容易采用“后出现的更具体地址覆盖之前地址”的捷径。但“这个方法作用于谁”与“这份正文表示谁”是两个问题。

Location 又是第三种问题。它在特定状态码下可标识新创建的资源，或提供重定向引用。同一响应允许同时包含 Location 与 Content-Location，因为状态码所定义的目的地和正文所表示的资源可能相同，也可能不同。

值相等时，字段说明正文是什么

在成功的 2xx 响应里，如果解析后的 Content-Location 与目标 URI 相同，接收者可以把正文视为消息起始日期时该资源的当前表示。

对于 GET 或 HEAD，这与字段缺席时的默认含义一致。成功的 GET 本来就返回目标资源选中的表示；字段没有额外创造读取权或所有权。

对于 PUT 或 POST 这类改变状态的方法，相等关系更有信息量。编辑工具把文档 PUT 到某个地址，服务器返回 200，且 Content-Location 等于 PUT 目标。此时正文是资源更新后的表示，而不只是“成功了”这样的操作报告。工具可以直接刷新本地副本，省去一次随后的 GET。

省去往返不等于延长授权。先前 PUT 是否允许，已经在请求处理过程中决定。响应字段不能批准下一次修改，不能保证资源以后不变，也不能保证其他缓存已经同步。

时间限定也很重要。标准描述的是消息生成时的对应关系。以后 GET 可能读到新版本、另一种协商结果、变化后的访问规则，甚至 404。Content-Location 不是永续的字节承诺。

值不相等时，必须先看方法与状态

成功响应中的 Content-Location 若与目标不同，不能套用一条通用“跟随它”的规则。RFC 9110 分出几种语义。

对于 GET 或 HEAD，它可以表示内容协商。目标 URI 指向一个有多种表示的资源，字段则提供本次被选中表示的更具体标识符。例如，请求一个多语言报告的通用地址，响应选中中文版，并给出这份中文版表示对应的 URI。

更具体不等于更规范。通用目标仍可根据下一位读者的语言或格式偏好作选择，具体 URI 则说明这一次究竟返回了什么。是否设置规范关系，应由专门机制和明确出版政策决定，不能从 Content-Location 自动推导。

对于改变状态的方法，201 响应形成另一种情形。若 Content-Location 与 Location 相同，正文就是新创建资源的当前表示。Location 根据 201 的语义标出新资源，Content-Location 解释正文；即使值一样，两项职责仍然不同。

其余成功操作中，不同的 Content-Location 可以标识一份报告操作状态的资源，而且说明以后可对该 URI 执行 GET 来取得同一报告。RFC 9110 使用购买收据举例：POST 作用于交易端点，正文和其内容位置则对应收据。

审计记录应分别保存操作目标、新资源与状态报告。如果只留一个“最终 URL”，后来的动作会失去含义：GET 读的是商品、交易还是收据？PUT 改的是业务对象，还是描述它的报告？

HTTP 不能替接收者判断共同所有权

当两个 URI 不同时，源服务器声称：另一个 URI 标识与当前正文相对应的不同资源。RFC 9110 随即限制这项主张的可信度——只有两个标识符共享同一资源所有者时才可信，而 HTTP 无法用程序自行确定这种关系。

同源比较是一项有用安全边界，却不是所有权登记簿。共享托管平台可能在同一源下放置互不相关的租户；同一组织也可能合理控制多个源。代理、发布平台和委托关系还会把技术保管者与内容权威分开。

高风险客户端必须配置应用层证据：已认证的账户关系、经过审核的命名空间、范围明确的签名清单，或人工确认。要多少证据，取决于下一步会造成什么后果。

HTTP 消息签名也不会自动解答所有权。RFC 9421 可以把选定消息组件纳入签名，并在应用配置下关联到签名者；文档同时说明，它只是完整安全系统的一部分。字段完好无改动，只能说明被覆盖数据的完整性。应用仍要判断签名者是否有权声称两个资源属于同一控制范围，以及允许什么后续方法。

“这句话未被篡改”与“说话者有资格授权这个动作”不是同一结论。

请求中的 Content-Location 只是来路上下文

用户代理也可以在请求里发送 Content-Location。它表达的是：当前附带表示在被用户代理修改之前，最初从哪个位置取得。这个字段是一条回到来源的链接。

源服务器必须把它当作临时请求上下文，而不能原样保存为表示自身的元数据。服务器可以在处理时参考，也可以经过适当判断后将其记录为来源链接或版本信息；但不得让它改变请求语义。

RFC 9110 用协商资源上的 PUT 划清界线。客户端从某个具体变体开始编辑，在字段里写出变体 URI，却把 PUT 发往协商资源。如果服务器不重定向而直接接受，操作仍然作用于 PUT 的目标，目标的新状态应与提交的表示一致。字段不能把它偷偷变成“只更新这个变体”。

如果客户端真正想执行后者，就应把 PUT 直接发给变体 URI。这样，请求目标、授权检查和操作日志都公开指向同一资源。

这条规则阻止在元数据里夹带第二写入目标。否则，网关可能只批准请求行里的地址，应用却修改字段里的地址，事后双方日志对不上，访问控制也被绕开。

来源上下文与动作范围都能写成 URI，不表示它们应该共享权力。

缓存失效是受限效果，不是导航

RFC 9111 给 Content-Location 规定了一项缓存侧后果。当不安全方法收到非错误响应时，缓存会让目标 URI 的已存响应失效；Location 与 Content-Location 中的 URI 也可以成为候选。

这项行为具有明确同源边界。若候选 URI 的源与目标 URI 不同，缓存不得触发该失效。限制可以防止一个站点的写操作被用来消耗或破坏另一个站点的缓存条目。

所谓失效，是删除匹配的已存响应，或把它标记为再次使用前必须验证。它不是写入源资源，不是全球删除，也不是把读者重定向到候选地址。只有请求实际经过的缓存能够行动，所以标准不保证所有地方的副本都同步失效。

这说明同一字段可以在特定子系统内产生明确定义的保守效果。缓存维护自己副本的一致性，并不会由此授予浏览器导航命令、授予编辑器 PUT 权，或授予搜索索引规范化结论。

解释字段时应始终说明“由谁消费、产生什么效果”。缓存规则不能靠类比扩展成路由规则。

表示更具体，不代表名字更高贵

内容协商允许一个资源按语言、格式或编码提供多个表示。Content-Location 可为当前消息里的那一份提供具体标识符。

这种精度很有价值。客户端可保存确切版本，追踪副本来源，也可以在以后尝试取得同一报告。但具体性不自动建立层级：变体 URI 不必取代协商目标，协商目标也不必成为所有变体唯一的永久名称。

Web Linking 提供了资源之间的类型化关系。如果发布者要声明 canonical、alternate 或其他关系，应使用相应机制与语义。把 Content-Location 默认为所有关系的合集，会让互操作依赖私人约定。

自动发布系统尤其容易走过头。它收到一个具体 URI，把它写进规范索引，再把后续编辑路由过去，最后按那个地址签名请求。每一步看似只是省事，最初字段却只承诺了“在某一时刻，这份表示对应这个资源”。

清晰模型分别保存目标 URI、响应状态、Location、Content-Location、协商维度、已认证对端与时间。每一项下游决策都应注明自己用了哪份证据。

一个共同字段，不需要中央所有权裁判

IANA HTTP 字段名登记表把 Content-Location 列为永久字段，并指向 RFC 9110。共同登记避免不同应用为相同表示关系各造一个名称，却没有建立全球 URI 所有权数据库。

这种结构符合卢恒的顺序：先有最小初始规范，再把未来决策放回本地，由参与者知情自愿采用。共同层只规定语法、URI 解析，以及方法、状态、值相等与否所构成的语义矩阵。

源站判断自己能负责任地声明哪个表示标识；客户端判断所有权证据是否足够；缓存执行同源失效；编辑工具判断能否用返回正文更新本地副本。承担后果的一端保留决定权。

无需由中央服务逐条批准变体、收据或缓存动作。这不是放弃互操作性，而是用严格的字段边界避免把互操作性误建成集中控制。

保存表示回执，不覆盖地址

可靠实现可以保存一份紧凑回执：请求方法、原目标、响应状态、消息日期、解析后的 Content-Location、任何 Location、协商维度、已认证对端与正文哈希。

接着，它在规范矩阵中选择解释：目标的当前表示、选中变体、新建资源表示，或操作状态报告。不能只用一条“看到地址就跟随”的通用规则。

随后产生的效果分别记账：更新编辑器本地副本、安排以后 GET、让同源缓存条目失效，或提出规范关系，是四种权力来源不同的动作。若使用签名，还要记录覆盖哪些组件，以及哪项本地信任政策接受签名者。

回执也必须允许修正。资源会更新，变体会消失，所有权证据会撤回，服务器会纠正错误字段。初始消息应保留为历史事实，而不是永久路由命令。

Content-Location 只回答一个有限问题：这份表示对应哪个资源？它不决定客户端下一步去哪里，不决定哪个 URI 取代其他地址，不证明两个资源属于谁，也不允许后续方法。正是这份克制，使一个小型元数据字段可以长久协作而不越权。

来源