curl 8.22 让 quiche 的 HTTP/3 响应头上限与 curl 保持一致
curl 8.22 修复了 quiche 后端的一处 HTTP/3 限制不一致。quiche 0.29.3 开始执行 32 KB 的默认最大字段段大小，而 curl 本身允许更大的汇总响应头。因此，同一响应可能在其他 HTTP 版本或后端成功，却在 quiche 路径上以 CURLE_HTTP3 关闭整个连接。
curl 项目的变更“quiche: set the max field section size”会显式配置 quiche 使用 curl 的响应头上限，并向服务器公布真实能力。项目记录指出，curl 可接受最高 300 KB 的响应头，而此前 quiche 的 32 KB 默认值可能导致连接终止。
对授权数据采集、监控与 API 客户端而言，这是兼容性修正，并不是接受无限响应头的许可。正式迁移前仍要验证边界、内存保护与协议回退。
HTTP/3 字段段上限控制什么
HTTP/3 以字段段表示响应头。对端可以公布它愿意接收的最大字段段。该限制针对解码后的字段集合，而不只是网络上传输的压缩字节数。
压缩可能让逻辑上很大的响应头在网络上看起来较小。因此，测试夹具应记录解码后大小和客户端结果，不能只看抓包长度。
curl 8.22 让 quiche 表达 curl 已经执行的上限，并未把 curl 的上限继续提高，也不能保证服务器、网关或其他客户端库接受同样大小。
为什么数据采集系统更容易遇到
普通响应头通常不大，但长期 Cookie、缓存与追踪字段、安全策略、重复链接元数据、认证挑战和业务元数据都可能扩大响应头。
自动采集系统还会比较多种协议路径。如果 HTTP/2 成功，而 HTTP/3 只在响应头较大时失败，问题容易被误判为代理出口不稳定、QUIC 丢包或目标站偶发异常，实际原因可能只是后端字段段上限。
完成分类前不要轮换住宅出口。确定性的大小限制会跟随请求，盲目轮换只会形成昂贵的重试风暴。
明确网络路径
不要把整个请求笼统标为“HTTP/3”，应记录每一跳实际协商结果。
| 观察 | 能证明的内容 |
|---|---|
| 目标站使用 HTTP/3 | 客户端到目标站路径协商了 HTTP/3 |
| HTTPS 代理使用 HTTP/2 | 客户端到代理这一跳使用 HTTP/2 |
| CONNECT 成功 | 隧道建立，不代表内部协议类型 |
| 直连回退 | 请求可能绕过代理，结果不可直接比较 |
传统 TCP CONNECT 不会自动承载 QUIC。实验性 HTTP/3 代理与普通目标站 HTTP/3 是不同用例。测试代理这一跳时参考HTTP/3 代理评估指南，并明确标记实验性质。
建立安全回归矩阵
只对自有或明确获授权的服务器与代理路径测试，并使用不含秘密或用户数据的合成响应头。
- 记录准确的 curl/libcurl 版本、quiche 版本和构建特性。
- 在支持的 HTTP/1.1、HTTP/2 与 HTTP/3 路径上建立小响应头基线。
- 逐步增加解码后响应头大小：低于 32 KB、略高于 32 KB、明显低于 curl 上限、接近上限以及超过上限。
- 固定正文、端点、连接策略和请求头。
- 记录协商协议、curl 错误码、关闭原因、解码大小、重试次数和内存峰值。
- 分别测试新连接与可复用连接。
- 对实际代理路径和单独批准的直连控制做比较，禁止静默直连。
- 确认超过支持上限时会明确失败，且部分数据不会被当作有效结果。
不要用生产 Cookie 制造大型测试。合成重复字段既可复现边界，也不会泄露客户或认证信息。
定义预期结果
对于使用修复后 quiche 后端的 curl 8.22，超过旧 32 KB 默认值但仍低于 curl 支持上限的合成字段段，不应再仅因为 quiche 保留较小默认值而失败。
达到或超过实际 curl 上限时，应得到明确、有界的错误。不能因为收到状态行就判定成功；必须确认所有必需响应头和完整正文均已交付、解析并归入正确请求。
按语义结果比较协议：完整有效响应、明确的响应头上限错误、HTTP/3 连接错误、策略允许的协议回退、禁止的直连绕过、超时或无关网络错误。
保护内存与重试预算
较大的响应头上限意味着客户端可能缓冲和解析更多元数据。应统一 curl、应用解析器、日志和下游存储的限制。即便 curl 接受传输，自定义解析器仍可能过载。
- 按请求和目标限制重试次数；
- 确定性的上限错误不得换出口重试；
- 限制大型响应头测试的并发；
- 脱敏或哈希敏感响应头值；
- 不需要内容时只保存大小与摘要；
- 拒绝不完整记录；
- 监控 p95 与最大响应头大小的异常增长。
大型自定义请求头测试处理出站方向；本次 curl 8.22 变化针对 quiche HTTP/3 后端的响应字段段，两类边界应分开验证。
升级检查清单
- 确认 curl 8.22 与实际 quiche 后端共同部署。
- 测量授权夹具的解码响应头大小。
- 覆盖旧 32 KB 边界上下。
- 把真实 curl 上限作为明确失败边界测试。
- 记录每一跳协议并禁止静默直连。
- 比较 HTTP/1.1、HTTP/2 与 HTTP/3 的语义结果。
- 验证连接复用和重试分类。
- 统一应用、日志和存储上限。
- 脱敏所有捕获的响应头材料。
- 灰度发布并监控错误码和内存。
还可结合代理重试放大控制、HAR 凭据脱敏与代理绕过审计完善运营控制。
常见问题
curl 8.22 是否允许无限响应头？
不是。修复只是让 quiche 使用 curl 现有上限，而不是较小默认值。超过支持上限仍应失败。
这是代理服务器的问题吗？
不一定。报告中的不一致发生在 curl 接受的响应头大小与 quiche 默认 HTTP/3 字段段大小之间。代理可能增加另一层限制，因此必须标记每一跳。
HTTP/3 错误应触发代理轮换吗？
必须先分类。确定性的字段段上限并非出口质量问题，提前轮换只会浪费流量并掩盖兼容性原因。
HTTP/2 成功能否证明 HTTP/3 已修复？
不能。它只证明该 HTTP/2 路径可接受响应，修复后的 quiche 路径必须单独执行和测量。
合规说明
仅对自有或明确授权的基础设施和代理账户执行大型响应头测试。使用合成值、遵守速率与资源限制、防止直连绕过，不得为了达到大小边界而收集凭据或个人数据。
