curl 8.22 不再默默丟棄大型自訂請求標頭：代理客戶端該重新測試什麼
curl 8.22.0 於 2026 年 9 月 2 日發布，其中修正一項官方稱為「http: stop dropping large custom headers」的請求建構問題。專案紀錄指出，自 curl 8.13.0 起，超過回應標頭解析器限制的自訂請求標頭可能被默默省略或錯誤解讀。
修正後，出站自訂欄位與權杖檢查改用分隔符號解析。能放入目的請求緩衝區的欄位會被送出；無法放入時，請求明確回傳 CURLE_TOO_LARGE。相較於送出一個驗證、簽章、追蹤或業務上下文已悄悄改變的請求，明確失敗更安全也更容易排查。
為什麼代理工作流程需要關注
使用代理的資料蒐集與驗證工作，常為已授權的目的 API、內部關聯、內容協商或簽章請求加入自訂標頭。欄位遺失可能造成：
- 代理連線正常，但目的站拒絕請求；
- 實際線上請求與簽章輸入不同，導致簽章失敗；
- 追蹤系統遺失用來關聯客戶端與閘道證據的操作編號；
- 應用進入通用重試並無意義地輪換出口；
- 上游回傳預設內容，表面狀態碼正常但業務結果錯誤。
這不代表所有代理驗證標頭都受影響，也不表示 curl 現在允許無限大的標頭。修正針對自訂出站 HTTP 標頭處理；請求緩衝區、伺服器、代理與閘道仍有各自限制。
識別需要檢查的客戶端
盤點使用 curl 或 libcurl 8.13.0 至 8.21.0 且會送出自訂 HTTP 標頭的應用。檢查嵌入式 SDK、容器及語言繫結，不能用同一主機上的命令列 curl 版本代替實際執行函式庫。
優先檢查：
- 較大的簽章中繼資料或結構化授權欄位；
- 合法但較長的追蹤或政策上下文；
- 動態組合的標頭清單；
- 涉及重新導向或代理通道、欄位範圍會改變的請求；
- 只依賴 HTTP 狀態碼判斷成功的工作；
- 目的站拒絕後自動重試的流程。
盤點表不得複製真實欄位值，只記錄欄位名稱、長度範圍、負責人、敏感等級、目的範圍及建構路徑。
建立受控迴歸測試
使用自行控制的測試目的站與代理。目的端只回傳收到的欄位名稱、位元組長度及欄位值摘要，絕不能回傳敏感值。測試內容使用不含憑證與個人資料的合成字串。
至少準備四種尺寸：
- 一般小型欄位；
- 低於舊回應解析邊界的欄位；
- 較大但應能放入出站請求緩衝區的欄位；
- 明確無法放入的超大欄位。
在現行正式客戶端與 curl 8.22.0 上執行相同用例。對預期可送出的欄位，目的端觀察到的長度及摘要必須完全一致；對超限用例，應明確得到 CURLE_TOO_LARGE，並確認目的端沒有收到部分請求。
驗證線上請求，而非設定物件
傳輸前記錄「已加入標頭」，只能證明應用產生了值，不能證明欄位已送出。應在授權測試目的站或受控 TLS 終止閘道驗證線上證據。
建議記錄測試編號、客戶端版本、欄位名稱、預期與實際長度、預期與實際摘要、curl 結果、HTTP 狀態、重新導向序號及代理路線別名。儲存前將值去識別化或雜湊。禁止開啟會暴露代理密碼、Cookie、權杖或客戶資料的正式環境詳細追蹤。
分開測試代理與目的欄位範圍
HTTP 代理請求和目的站請求屬於不同邊界。存取 HTTPS 目的時，客戶端可能先向代理送出 CONNECT，再於通道內送出目的請求。代理專用欄位屬於代理交換，目的欄位屬於通道內請求。
測試必須證明目的自訂標頭不會洩漏到無關代理交換，同時代理專用欄位不會轉送到目的站。至少包含直接連線對照、HTTP 代理路線及透過 CONNECT 存取 HTTPS 目的三種路徑。
遇到 407 可參考 curl 代理驗證疑難排解指南，並將代理驗證與目的站回傳的 401 或 403 分開記錄。
納入重新導向及方法變更
重新導向可能改變目的主機，也會改變敏感欄位的安全範圍。分別測試同源與跨源重新導向，並在測試前定義哪些欄位允許跟隨。不能只因新主機可連線，就把敏感欄位轉送給未核准的主機。
記錄每一跳、有效目的別名及欄位存在結果。若 URL 含使用者資料或權杖，不要儲存完整位址。最終回傳 200，也不能證明中間請求沒有遺失或洩漏欄位。
檢查簽章及正規化
簽章請求對默默變更特別敏感。客戶端簽署的欄位名稱和值，必須與目的站收到並依規則正規化後的內容一致。只在簽章規格允許的範圍內測試空白、空值、重複欄位及欄位名稱大小寫。
不能為了讓簽章通過，就在未經安全審查時把欄位移出簽章集合。應升級受影響客戶端，確保請求在正式限制內，並在無法證明線上請求時安全失敗。
限制失敗與重試
CURLE_TOO_LARGE 是確定性的本地建構失敗，不是暫時網路問題。它不應觸發代理輪換、快速重試或直接連線回退，應進入設定或負載尺寸警示。
如果升級後把過去的默默省略變成明確失敗，應檢查欄位為何過大。協定支援時，優先改用有文件的請求內容欄位、伺服器端參照或較小的宣告集合。除非接收協定明確允許，不要任意把一個邏輯欄位拆成多個標頭。
上線門檻
安全的灰度應要求：
- 所有預期可送出用例的長度與摘要一致；
- 超限用例明確回傳
CURLE_TOO_LARGE； - 建構失敗後沒有部分請求抵達目的站；
- 目的欄位不洩漏到代理交換；
- 代理專用欄位不轉送到目的站；
- 直接連線、HTTP 代理及 CONNECT 路線行為正確；
- 敏感欄位不會跟隨到未核准的重新導向主機；
- 重試有界且不會默默直接連線；
- 有效結果率及尾端延遲保持穩定。
先部署至少量工作節點，監控 curl 結果碼、目的拒絕類型、簽章失敗、重試放大及每個有效結果成本。
升級檢查清單
- [ ] 已盤點執行中的 curl 與 libcurl 版本；
- [ ] 已整理自訂欄位及最大預期長度；
- [ ] 測試與日誌不含真實欄位值；
- [ ] 涵蓋小型、邊界、大型有效及超限用例；
- [ ] 測試目的站驗證長度與摘要；
- [ ] 已比較直接連線、HTTP 代理與 CONNECT；
- [ ] 明確測試重新導向欄位範圍；
- [ ] 已驗證簽章請求正規化；
- [ ] 超限請求明確失敗且不會送出；
- [ ] 確定性錯誤不會輪換出口或重試；
- [ ] 強制代理流程不會回退至直接連線；
- [ ] 已記錄回復方案與監控門檻。
常見問題
哪些版本需要檢查？
curl 專案紀錄指出，該默默省略或誤解行為從 8.13.0 開始存在，並於 8.22.0 修正。務必確認每個應用實際載入的 libcurl。
curl 8.22 是否允許任意大小的欄位？
不是。能放入請求緩衝區的欄位可以送出，無法放入時回傳 CURLE_TOO_LARGE；其他網路元件還可能設定更小限制。
狀態碼成功能否證明修正有效？
不能。測試目的站必須驗證收到的長度及摘要。遺失選用欄位時，伺服器仍可能回傳 200。
CURLE_TOO_LARGE 應換代理重試嗎？
不應。它描述本地請求建構問題，改變出口不會縮小欄位，應作為有界設定錯誤處理。
相關 98IP 內容包括代理重試放大控制、HAR 憑證去識別化及代理連線池設計。
來源說明：curl 專案《Changes in 8.22.0》，2026 年 9 月 2 日發布；curl 專案紀錄《http: stop dropping large custom headers》。外部資料位址僅保留於內部營運紀錄。
僅在自行控制或明確獲授權的測試系統及目的站執行驗證。遵守端點條款、欄位尺寸政策、頻率限制、隱私義務與適用法律。標頭尺寸測試不得包含真實憑證或個人資料。
