摘要

  • draft-ietf-httpbis-connect-tcp-14 要求客户端把 target_host 与 target_port 展开进代理 URI 模板，由展开后的 URI 标识 connect-tcp Capsule Protocol 连接。
  • 模板把代理 origin、资源路径、认证 protection space、网关策略和 origin-scoped 状态连到同一个入口，因此模板来源与变量约束本身就是授权证据。
  • IETF Last Call 截止日为 2026 年 10 月 1 日；当前文件仍是 Internet-Draft，不是已批准 RFC，也没有证明任何产品已实现或部署。

配置字符串开始承担控制权

经典 CONNECT 把目标写成主机和端口。新草案则让客户端先持有一个 URI 模板，再把目的主机与端口填入 target_host 和 target_port。看似只是多了一层展开，实际却改变了请求落在哪个代理 origin、经过哪条网关路径、携带哪组凭据，以及哪些 HSTS、Alt-Svc、Cookie 等 origin 范围状态会影响后续请求。

所以，模板不是“地址长什么样”的说明。它还在回答“谁是门”和“门在哪里”。如果模板来自被篡改的自动发现、错误的企业配置或未经授权的管理端，即使展开算法完全正确，请求仍可能被送到错误的控制点。

revision 14复用 RFC 9298 的 CONNECT-UDP 校验规则：模板必须是绝对形式，scheme、authority 和 path 不能为空，路径必须以斜线开始，变量只能位于 path 或 query，还要包含两个目标变量并限制部分展开运算符。客户端发现不合规配置时必须在发请求之前拒绝。

这些规则能证明“配置是否符合协议语法”。它们不能证明“配置由谁发布”“发布者是否有权改变出口”“该 origin 是否属于预期的代理服务”。格式校验与来源授权必须分开保存。

三种 HTTP，三个阶段不能混写

在 HTTP/1.1 中，客户端对展开后的 URI 发 GET，请求升级到 connect-tcp。代理只有在请求格式正确且政策允许时才尝试连接目的地；TCP 成功后返回 101 Switching Protocols。格式错误或政策不允许应返回 4xx，未建连则不得切换协议。

在 HTTP/2 与 HTTP/3 中，代理先声明 extended CONNECT 能力。请求以 :protocol = connect-tcp 标识协议，:authority 指向代理，:path 与 :scheme 来自模板展开。成功的 CONNECT 响应把该流交给 Capsule Protocol。

草案还支持 Expect: 100-continue。这里的 100 Continue 只说明代理收到请求且没有立即拒绝，特意不等待代理到目标的 TCP 握手。它比“发送成功”更窄，也比“隧道成立”更早。随后出现 101 或成功的 extended CONNECT，能证明代理按规范报告 TCP 已建立，但仍不能回答目标程序是谁、TLS 证书是否通过、请求字节是否送达、业务动作是否完成。

运维日志如果只留下一个“success”，会把至少三类故障压成同一项：入口拒绝、TCP 建连失败、隧道建立后的应用失败。每一类都有不同责任人，也有不同修复路径。

普通 HTTP 认证把网关纳入代理权限

模板化代理拥有明确的 HTTP origin，因此通常使用 401、WWW-Authenticate 与 Authorization，而不是经典代理使用的 407 系列字段。草案解释，407 相关字段无法穿过普通 HTTP gateway。一个模板生成的资源通常共用一个 protection space，也可以使用 TLS 客户端证书。

这种选择让现有网关能力可以直接参与：路径路由、DDoS 防护、请求清洗、用户授权都可以放在隧道之前。高熵路径或 concealed authentication 还可以降低未授权探测者发现服务的机会。

但凭据的效力对象必须写清。通过代理认证，只说明某个主体满足了代理 protection space 的认证要求。目的主机和端口是否允许，仍由目的地策略决定；DNS 解析得到哪个地址，仍是另一个记录；目标端 TLS 身份与应用权限，还要在隧道内部重新判断。

RFC 9110早已提醒：开放任意 CONNECT 端口可能让代理成为其他协议的中继。URI 模板没有消除这个问题。它只是把目的地准入放进了更可辨认的 HTTP 控制面。

DATA 保留顺序，FINAL_DATA 保留方向性关闭

TCP 负载装入 DATA capsule；FINAL_DATA 既能携带最后一段负载，也表示该方向相当于发送了 TCP FIN。发送 FINAL_DATA 后，不得再发送 DATA 或第二个 FINAL_DATA。收到 TCP FIN 必须转成 FINAL_DATA；收到有效 FINAL_DATA 必须向 TCP 侧发送 FIN。

这里没有承诺 capsule 边界等于 TCP segment、TLS record、HTTP DATA frame 或应用消息。中间层可以合并或拆分连续 capsule，只要字节顺序不变，并让最后输出保留最后输入的 DATA/FINAL_DATA 类型。

这是一个很好的最小互操作合同：协议保护字节次序和半关闭含义，不为应用层发明虚假的记录边界。它也意味着，客户端把数据写入 HTTP 流，不等于目标应用收到；代理写入 TCP socket，不等于对端处理；FINAL_DATA 传递了一个方向的 FIN，也不等于反向数据已经完整返回。

HTTP/2 与 HTTP/3 允许客户端乐观发送数据，但代理必须先缓存，等选中的 TCP 连接可写后才能转发；连接失败就必须丢弃。若多个地址并行竞速，未被选中的连接不得收到负载。要判断真实结果，至少要分别记录模板来源、代理证书、认证、目标政策、解析地址、连接尝试、响应状态、字节计数、DATA/FINAL_DATA 顺序、目标 TLS 身份、reset 与应用结果。

Last Call 是程序状态，不是部署事实

IESG 公告显示，HTTPBIS 工作组请求把该文件按 Proposed Standard 审议，意见截止 10 月 1 日。Datatracker 显示 revision 14 已提交 IESG，并处于 Last Call。

这些记录证明标准程序走到哪里，却不证明程序已经结束。Internet-Draft 仍可能修改、被替代或过期。即使未来成为 RFC，也只是共同协议合同，不是客户端验证正确、网关兼容、半关闭互通或生产采用的证明。

运行代码优先要求证据只承担它真正观察到的结果；最小初始规范与本地未来决策则提示，公共规范应约束语法、顺序和错误传播，而模板来源、目的地政策与可接受结果仍由承担损失的人决定。

代理可以批准一条隧道。它没有权替目标、应用和最终结果作证。

来源