摘要

  • 传统HTTP CONNECT指出TCP连接要去哪里，却没有给代理服务本身明确的源站和路径。新模式用URI模板标识服务，并通过Capsule消息承载字节流。
  • IESG在10月30日批准该草案按Proposed Standard发布。支持它的网关需要在自己处理的HTTP版本间转换隧道；公开材料没有部署数量或现场测试结果。

代理终于有了自己的地址。网关则多了一份作业。

多年来，HTTP CONNECT让客户端请求代理连接到某个TCP主机和端口，再由代理在客户端与目标之间搬运字节。但请求标识的是隧道终点，不是代理服务。它没有为代理服务本身带上路径或源站。

同一台HTTP服务器承载多个代理服务时，这个缺口就会显形。没有服务路径或源站，服务器无法像区分普通网页资源或虚拟主机那样区分这些代理服务。草案还指出一个安全后果：传统CONNECT没有明确的代理源站，服务器端口误导攻击的常规防护难以适用；Alt-Svc或Strict-Transport-Security等源站级响应头也失去清晰的作用范围。

10月30日，IESG批准draft-ietf-httpbis-connect-tcp按Proposed Standard发布。第17版文本在前一天发布。它提出一种新的HTTP承载TCP隧道方式，并没有决定用户可以访问哪些目的地。代理端点获得更清楚的地址，访问授权仍由代理运营者决定。

草案用包含target_host和target_port变量的URI模板标识代理服务。客户端填入目标地址，生成请求URI，再交给代理。HTTP/1.1使用GET并升级到connect-tcp；HTTP/2和HTTP/3使用Extended CONNECT，:protocol设为connect-tcp。代理还要通过设置帧声明是否支持Extended CONNECT。

TCP流通过Capsule协议消息传输。DATA携带字节；FINAL_DATA携带最后一批字节，并表示与TCP FIN等效的关闭。Capsule边界不冒充TCP分段或TLS记录，只负责把字节流装进HTTP传输。

明确的源站和路径让代理服务进入常规HTTP语义：一台服务器可以区分多个服务，源站级响应头也有了作用范围。但授权仍是另一项决策。代理依然需要自己的目的地规则；URI模板不是访问控制表。

作业落到了网关身上。承诺兼容的网关必须处理HTTP/1.1 Upgrade或Extended CONNECT，转发connect-tcp，并在所支持的HTTP版本之间转换请求。它还必须保留Proxy-Status。如果源站以TLS客户端证书认证用户，网关就必须自行完成认证，或把相关证书信息传给源站。

IETF把这次交接写进了要求，却没有替运营商升级网关。草案和决议记录没有提供已部署网关数量、采用预测或生产环境互通结果。标准可以定下消息格式；运营团队仍得找出链路上的每个代理、网关和身份认证边界。

来源