6. 对使用现有 Upgrade Token 的 HTTP Upgrade 的影响

本节描述本文档中的考虑事项对一些已注册且据信在撰写时正在使用的 upgrade token [IANA-UPGR] 的影响.

6.1. "TLS"

"TLS" upgrade token 系列定义于 [RFC2817], 该文档正确强调了服务器拒绝 upgrade 的可能性. 如果客户端忽略这种可能性并 optimistic 地发送 TLS 数据, 结果不可能是有效的 HTTP/1.1: TLS 连接的第一个 octet 必须是 22 (ContentType.handshake), 但这不是 HTTP/1.1 方法中允许的字符 (见 [TLS], Section 5.1 和 [HTTP/1.1], Section 3). 符合规范的 HTTP/1.1 服务器会将其视为解析错误, 并关闭连接而不处理更多请求.

6.2. "WebSocket"/"websocket"

[WEBSOCKET] 的 Section 4.1 说:

一旦客户端的 opening handshake 已发送, 客户端必须等待服务器响应, 然后才能发送任何更多数据.

因此, WebSocket 协议已经禁止 optimistic 使用 HTTP Upgrade. 此外, WebSocket 协议要求对客户端到服务器的帧进行高熵 masking ([WEBSOCKET] 的 Section 5.1).

6.3. "connect-udp"

[CONNECT-UDP] 的 Section 5 说:

客户端可以在收到 UDP proxying 请求响应之前, optimistic 地开始在 HTTP Datagram 中发送 UDP packet.

然而, 在 HTTP/1.1 中, 这个 "proxying request" 是一个 HTTP Upgrade 请求. 在某些情况下, 此 upgrade 很可能被拒绝, 例如 UDP 目标地址 (它是 attacker-controlled) 无效时. 此外, "connect-udp" 协议流的内容可以包含不可信材料 (即 UDP packet, 它们可能来自客户端设备上的其他应用). 这造成了 Request Smuggling 攻击的可能性. 为避免这些顾虑, 本文档替换该文本, 以便从任何 optimistic 发送中排除 HTTP/1.1, 如下:

仅当所使用的 HTTP 版本为 HTTP/2 或更高版本时, 客户端可以在收到 UDP proxying 请求响应之前, optimistic 地开始在 HTTP Datagram 中发送 UDP packet. 由于存在 Request Smuggling 攻击风险, 客户端不得在 HTTP/1.x 中 optimistic 地发送 UDP packet.

6.4. "connect-ip"

"connect-ip" upgrade token 定义于 [CONNECT-IP]. [CONNECT-IP] 的 Section 11 禁止客户端在 HTTP/1.1 中 optimistic 地发送 packet, 从而避免了此问题.