摘要

  • RFC 9110 允许客户端发送 Upgrade，邀请服务器在同一连接上切换协议；服务器可以忽略邀请，而中间方在普通转发前必须删除这一由 Connection 指定的逐连接字段。
  • 完成切换的证据至少包括有效的 101 Switching Protocols 响应、从客户端提议中选择的协议、原请求发送完毕的边界，以及新协议下首个格式有效的交换。

设想一个迁移仪表盘：它在客户端请求中看见 Upgrade: websocket，便立即把会话标为“WebSocket 已启用”。但客户端和源站之间的代理按 Connection 字段处理逐连接选项，删除了这项邀请。源站从未看见它，只通过 HTTP/1.1 返回普通的 200 OK。两端都没有切换协议，仪表盘却因为把提议当成结果而记录了一次成功迁移。

这是一个假设场景，不针对任何具名服务。错误在于证据范围：单侧抓到的一项标头，被用来证明必须跨越明确边界、并由两侧有序事实共同支持的状态变化。

RFC 9110 把 Upgrade 定义为在同一连接上从 HTTP/1.1 切换到另一协议的机制。客户端可以发送按偏好排序的协议列表，邀请服务器切换；服务器可以忽略这项邀请。因此，该字段表达的是意愿和偏好，而不是接受、协商成功、部署覆盖或应用已经就绪。

邀请具有逐连接属性。发送 Upgrade 的一方必须同时在 Connection 字段中加入 upgrade。这一要求告诉中间方，不能把收到的选项当作端到端字段盲目转发。中间方会先删除 Connection 指定的字段。若代理支持所请求的协议并决定向下一跳发出邀请，它可以生成一个新的逐跳 Upgrade 字段，同时必须在自己转发消息的 Connection 字段中加入 upgrade。客户端边缘的抓包因此不能证明源站收到同一提议；源站侧的抓包也不能证明客户端收到的后续响应未经改变。HTTP/1.0 服务器若收到 Upgrade，必须忽略它。

有效接受的条件更严格。决定切换的服务器必须发送 101 Switching Protocols，并在 Upgrade 字段中标明所选协议；它绝不能选择客户端没有提议的协议。因此，101 是一条决策边界：在它之前，客户端只是提出建议；在有效响应之后，双方才同意用所选协议重新解释同一连接。

即使出现 101，证据记录仍未完整。客户端只有在承载邀请的原请求完全发送后，才可以开始使用升级后的协议。若新协议无法遵守收到消息的语义，服务器绝不能切换。切换后，预期服务器会继续响应原请求，并在新协议中采用等同于 HTTP 响应的形式。因此，运营证据必须保留请求完成边界和新协议下首个格式有效的交换，而不能只摘录日志里的一行状态码。

此机制不会更换底层传输，也不会创建另一条连接。改变的只是现有连接最上层的应用协议。若遥测把一条连接上的请求同另一条连接上的 101 或新协议帧拼接起来，就制造了 RFC 9110 并未描述的切换。连接身份、字节顺序和抓取方向缺一不可。

这一视角与相邻文章严格分开：R067 讨论 Via 是否列全中间方，R064 讨论 Alt-Svc 是否证明替代路径，Strategic Local 关注优先级恢复，B842 关注临时 IPv6 标识符的关联。本篇控制的是绑定于单条连接的应用协议切换，证据角度是有序的协商与交换记录。

可信证据记录应连接原始请求、按序提议、Connection 令牌、每个受控中间方前后的观测、最终状态、响应选定的协议、请求字节完成点、精确切换偏移、新协议首条有效消息，以及回退或关闭结果。这份记录不是 IETF 定义的协议元素，而是对运营证据的编辑性综合。“观察到提议”必须始终与“完成切换”分开。

来源