Max-Forwards 计算跳数，不证明权限

摘要

RFC 9110 规定，Max-Forwards 的十进制数值表示 TRACE 或 OPTIONS 请求还能被代理转发多少次。收到零的中间节点必须作为本次请求的最终接收者响应。
计数单位是协议转发，不是企业、部门、信任区或司法辖区；“最终接收者”也不等于源服务器或资源所有者。
Via 与 Proxy-Status 能补充路径证据，但允许假名、删减和按授权披露。可靠审计必须把请求观察、身份判断与访问授权分开保存。

HTTP 请求可能依次经过出口代理、边缘节点、负载均衡器、服务网格和反向代理。排查循环时，操作者常常不需要先取得完整拓扑，只需要让不同请求在不同深度停下，比较各处看到的消息。Max-Forwards 为这个有限问题提供了共同规则。

字段值是一串十进制数字，表示剩余转发次数。中间节点收到带有该字段的 TRACE 或 OPTIONS 后，必须在继续转发前检查并更新。数值为零时，它不得再转发，而要作为最终接收者回答；数值大于零时，新值取“原值减一”与自身支持上限中的较小者。其他方法上的 Max-Forwards 可以被忽略。

因此，数字变化描述消息处理，并不描述组织结构。一家公司可以在同一平台内部运营多个转发组件，一次请求会消耗多个跳数；数家公司也可能被一个托管边缘入口遮蔽。合同、控制权或安全级别发生变化时，计数器不会自动变化。把“第二跳”写成“第二家机构”，是把技术过程误写成法律事实。

零也只具有本次请求的程序含义。当前中间节点必须停止并回应，却没有因此变成源服务器，更没有取得目标资源的所有权。另一请求可能走向不同节点，同一节点也可能在别的请求中继续转发。准确记录应当是“某时刻、某目标、某方法、某初值下由此节点回应”，而不是“此节点永久主管后方系统”。

OPTIONS 用来询问目标资源或服务器的通信选项，不暗示对资源执行动作。星号目标针对服务器总体；普通目标针对与特定资源通信时的选项。客户端可以利用 Max-Forwards 把询问停在链条中的某个接收者。代理若收到的 OPTIONS 没有该字段，就不能自行添加。

RFC 9110 并未为 OPTIONS 规定一份普遍适用的完整清单。成功响应应提供能说明可选功能的字段，但部署可以有扩展、过滤和本地披露规则。某一深度没有返回某项能力，不证明整个机构都不支持；返回某项能力，也不表示请求者已获准使用。

TRACE 要求最终接收者在应用层回送其收到的请求消息，因而能暴露字段变换并帮助查看 Via。反射同时带来泄露风险。客户端不得发送可能被回显的凭据、Cookie 或其他敏感字段；接收者应排除看起来敏感的内容。TRACE 请求不能携带内容，响应也不能被缓存。

这说明可选深度并不等于检查权。部署可以禁用 TRACE，也可以只向经过认证的运维人员返回过滤后的结果。Max-Forwards 决定转发何时终止，却不决定谁能提出问题、回应应透露多少信息，或该信息可以保存多久。

Via 记录沿途接收者和使用的协议版本，可用于发现循环和判断兼容性。但 received-by 部分在真实主机名敏感时可以用假名替代，注释也是可选的并可在转发前删除。只有在共同组织控制和接收协议等条件满足时，多个成员才可以合并。

这些规则主动保留了“可互操作”与“完全公开”之间的距离。一个 Via 成员可能代表假名化组件，也可能在允许条件下概括多个组件。缺少真实主机名不等于没有该节点，更不等于不当隐瞒。协议需要足够证据维持转发与有限诊断，并不要求全网公开内部机器清单。

RFC 9209 定义的 Proxy-Status 能补充某次响应的中间处理信息，包括错误、下一跳、接收状态和部署细节。列表成员按靠近源站到靠近用户代理的方向排列。但中间节点自行决定何时添加；为了防止内部信息外泄，也可以删除此前的成员。源服务器不得生成该字段。

这种可选择披露有明确安全理由。后端地址、配置和拓扑可能帮助攻击者直接冲击未准备承受外部流量或恶意输入的服务；部分信息只适合授权方。因而，没有 Proxy-Status 成员只表示“没有收到这项断言”，不证明没有节点；出现一个成员也只是一项协议断言，不自动等于经验证的法人身份。

边缘路由、健康检查、故障切换和负载均衡都会改变请求链。同一目标、方法与初值在不同时间可能停到不同接收者。如果监控系统只保存一个“第三跳节点”并不断覆盖旧值，它会把瞬时路径加工成虚假的稳定拓扑。

合理的观察包应保存目标 URI、方法、Max-Forwards 初值、时间、传输上下文、状态码以及响应摘要。Via 和 Proxy-Status 若存在，应按收到时的原值保存，并注明当时的披露政策。后续结果不同，就增加一条新观察，而不是把先前事实抹去。

OPTIONS 与 TRACE 响应不可缓存，正好强化了这个边界。组织可以为审计目的存档一次响应，但 HTTP 缓存不能拿旧响应满足新请求。审计留存回答“当时发生了什么”，缓存复用则声称“这个响应现在仍可用于请求”；两者不是一回事。

HTTP 消息签名可以在应用配置中保护明确覆盖的组件，帮助确认计数或路径字段从认可签名者处发出后没有被无声改动。但签名不会恢复被省略的节点，不证明签名者的组织控制权，也不授权接收者继续探测。完整性提高一项断言的可信度，却不会扩大断言的含义。

第一本是协议账本，记录请求如何转发、在哪里停止以及得到什么响应。第二本是身份账本，用合同、资产登记、运维确认等独立证据，把技术接收者映射到实际操作者，并设置失效时间。第三本是授权账本，记录谁批准诊断、允许哪些目标和字段、有效期多长。Max-Forwards 只能进入第一本。

这样，自动化不会因为零值响应就开放管理入口，也不会因为一个 Via 名称改变就指控未经披露的外包关系。一个新 Proxy-Status 成员可能来自备用路径，一个消失的成员可能源于隐私策略，一次 OPTIONS 差异可能只针对资源。每种解释都需要本地证据。

诊断本身也应最小化。先提出具体故障假设，再逐步增加深度，证据足够即停止。TRACE 请求中清除所有秘密且不发送内容。OPTIONS 即便可以带有声明媒体类型的内容，RFC 9110 也没有规定该内容的用途；不应借此发送试验数据。