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」，應記錄每一跳的實際協商結果。

傳統 TCP CONNECT 不會自動承載 QUIC。實驗性 HTTP/3 代理與一般目標站 HTTP/3 是不同案例。測試代理這一跳時參考HTTP/3 代理評估指南，並明確標示實驗性質。

建立安全回歸矩陣

只對自有或明確獲授權的伺服器及代理路徑測試，並使用不含秘密或使用者資料的合成回應標頭。

1. 記錄準確的 curl/libcurl 版本、quiche 版本與建置特性。
2. 在支援的 HTTP/1.1、HTTP/2 及 HTTP/3 路徑建立小標頭基準。
3. 逐步增加解碼後大小：低於 32 KB、略高於 32 KB、明顯低於 curl 上限、接近上限及超過上限。
4. 固定回應本文、端點、連線政策與請求標頭。
5. 記錄協商協定、curl 錯誤碼、關閉原因、解碼大小、重試次數與記憶體峰值。
6. 分別測試新連線與可重用連線。
7. 比較實際代理路徑與另外核准的直連控制，禁止靜默直連。
8. 確認超過支援上限時會明確失敗，部分資料不可被視為有效結果。

不要使用正式 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 路徑必須獨立執行與量測。

合規說明

僅對自有或明確授權的基礎設施和代理帳戶執行大型回應標頭測試。使用合成值、遵守速率與資源限制、防止直連繞過，不得為達到大小邊界而蒐集認證資料或個人資訊。