如何測試代理鏈中的 HTTP 尾部欄位完整性
部分串流系統只有在本文傳送完成後，才能計算校驗值、簽章或最終處理狀態。HTTP 尾部欄位允許這些中繼資料在訊息末端抵達。代理鏈可能完整交付每一個本文位元組，卻丟棄、改名、合併或隱藏尾部欄位。若應用程式只檢查狀態碼和本文長度，就可能把未經驗證的結果當成完整資料。
本指南適用於已授權的資料收集、檔案傳輸、API 串流處理和可觀測性工作，建立一套受控測試。它可以區分協定行為、用戶端程式庫限制以及代理中介層問題，並定位尾部欄位在哪一跳消失。
理解訊息結束邊界
在 HTTP/1.1 中，尾部欄位可出現在結束 chunked 訊息的零長度區塊之後。用戶端可以宣告 TE: trailers，但 TE 屬於連線層級欄位，不能讓中介層盲目轉送。HTTP/2 與 HTTP/3 則使用本文資料之後的最終欄位區段承載尾部欄位。
尾部欄位並不是普通的「延遲標頭」。路由、驗證、訊息分幀和內容格式通常必須在接收本文前確定，因此許多欄位不允許放入尾部。只能使用欄位規範明確允許出現在尾部的名稱。
標準也允許中介層在某些情況下丟棄尾部欄位。因此，除非每一個必要跳點和用戶端契約都保證保留，否則服務不能把不可缺少的資訊只放在尾部。
先定義通過條件
測試前寫出機器可判定的契約：
- 本文抵達乾淨的協定結束點；
- 預期的尾部欄位名稱全部出現；
- 欄位值與獨立計算的期望結果一致；
- 尾部與初始標頭保持分離，除非欄位定義允許安全合併；
- 尾部不包含禁止延遲處理的分幀、路由或驗證欄位；
- 任一路線都不會靜默降低驗證政策；
- 用戶端 API 會在結果提交前揭露尾部欄位。
只要業務依賴末端摘要或處理狀態，200 和正確位元組數都不足以證明成功。
建立自有測試端點
使用自己控制的端點。將確定性本文分成多個區塊串流傳回，最後傳送允許用於尾部的合成狀態欄位和摘要欄位。期望摘要應透過獨立驗證控制通道取得，或由測試端依固定種子在本機計算。
準備以下案例：
- 本文和尾部值都正確；
- 本文正確但尾部缺失；
- 本文正確但尾部值錯誤；
- 本文截斷且沒有乾淨的尾部區段；
- 依欄位列表語義傳送重複尾部欄位；
- 故意傳送禁止放在尾部的欄位，作為負向對照；
- 初始標頭先宣告欄位，結尾再傳送預期尾部；
- 若技術堆疊支援，測試未預先宣告但規範允許的尾部欄位。
只使用合成值。絕不能將代理憑證、Cookie、個人資料或真實授權材料放入尾部。
記錄每一跳
建議記錄：
case_id
client_version
proxy_route
address_family
incoming_http_version
outgoing_http_version
body_bytes
body_digest
stream_end_clean
initial_trailer_declaration
received_trailer_names
received_trailer_digest
trailer_api_state
retry_count
failure_phase協定轉換時必須標明兩側。用戶端到代理可能使用 HTTP/2，而代理到目標使用 HTTP/1.1，也可能相反。若不說明具體跳點，「已測試 HTTP/2」沒有足夠意義。
先建立直連對照
分別使用原始協定用戶端和業務用戶端程式庫直連執行全部案例，從而把來源正確性與 API 揭露能力分開。
部分高階用戶端會讀取完整本文，但只有本文乾淨結束後才揭露尾部欄位；有些需要專門 callback、future 或低階回應物件；還有一些會直接丟棄尾部。應記錄真實 API 行為，不能假設尾部會出現在初始標頭映射中。
若原始用戶端可以看到尾部而業務用戶端看不到，此時尚不能認定代理有問題。
經每條代理路線重複測試
保持測試種子、請求欄位、用戶端版本和逾時不變，對每個必要閘道、地區和位址家族分別測試新連線與重用連線。
HTTP/1.1 必須先驗證 chunked 正確終止，再檢查尾部。HTTP/2 與 HTTP/3 則要求最終欄位區段之後出現乾淨串流結束，不能對 frame 協定套用 HTTP/1.1 chunk 規則。
| 結果 | 解釋 |
|---|---|
| 直連和代理都保留尾部 | 此路徑支援測試契約 |
| 原始代理用戶端可見，業務應用程式不可見 | 用戶端 API 或封裝層限制 |
| 直連可見，代理鏈遺失 | 中介層或協定轉換行為 |
| 本文摘要先失敗 | 應先處理傳輸或內容完整性問題 |
| 僅一個地區失敗 | 閘道或協定設定不一致 |
| 尾部變成初始標頭 | 需要審核緩衝或不安全合併 |
測試協商，避免連線層級欄位洩漏
在 HTTP/1.1 中，TE: trailers 只作用於目前連線。傳送 TE 時還要把它標識為連線選項，避免不理解語義的中介層將它當成端到端欄位轉送。
不要把 TE 原樣複製到每個代理跳點。應分別驗證兩側是否依照自己的協定正確宣告和處理尾部支援。HTTP/2 連線不能繼承無效的 HTTP/1.1 連線層級欄位。
記錄用戶端要求了什麼，以及每個受控伺服器實際觀察到什麼。若下游用戶端不能處理尾部，即使網路完成交付，業務上仍不可用。
獨立驗證尾部值
看到欄位名稱不代表通過。依應用程式實際接受的精確位元組計算摘要，再依欄位定義的演算法與表示規則和尾部值比較。
分開記錄：
- 線路上接收的位元組；
- 移除傳輸編碼後的位元組；
- 內容解碼後的表示位元組；
- 業務解析後的記錄。
摘要可能刻意涵蓋其中某一層，拿另一層比較會造成假失敗。gzip 與 Brotli 完整性指南說明如何同時保存線路與解碼證據。
偵測「假完成」
在尾部判定完成前，不要提交下載物件、API 批次或資料集分區。常見缺陷是本文串流 Promise 已完成便立即儲存結果，而尾部驗證仍在等待。
可以採用最終狀態機：
body_complete -> trailer_received -> trailer_valid -> commit任何必要尾部缺失、格式錯誤或值不正確，都必須產生獨立的非成功結果。本文乾淨結束但缺少必要驗證中繼資料，不能等同於已驗證結果。
還要在最終資料區塊前後分別測試取消。代理請求取消測試可協助確認末端中繼資料及 socket 不會停留在不確定狀態。
防止重試掩蓋缺陷
若某條路線總是丟棄尾部，更換出口重試最後可能成功，卻會掩蓋確定性的相容問題。應記錄首次嘗試結果、路線、兩側協定及用戶端版本。
只有操作安全且政策明確允許時才能重試。若目標端可能已處理本文，絕不能因尾部驗證失敗便自動重播有副作用的請求。應採用冪等設計或獨立狀態查詢。
對下載與收集工作，應隔離未經驗證的資料，而非放入正式資料集。代理回應完整性測試提供更完整的訊息分幀與結束檢查。
供應商與用戶端驗收清單
- 受控來源能產生確定性本文與尾部。
- 直連原始用戶端對照通過。
- 業務用戶端只在本文乾淨結束後揭露尾部。
- 已驗證 HTTP/1.1 chunk 正確終止。
- HTTP/2 與 HTTP/3 使用原生最終欄位區段。
- 分別記錄入站與出站協定版本。
TE依連線層級欄位處理，而非端到端欄位。- 尾部欄位名稱獲其規範允許。
- 尾部值與正確的位元組層比較。
- 必要尾部缺失或錯誤時採取失敗關閉。
- 驗證完成前不會提交結果。
- 重試不會重播不安全操作。
- IPv4、IPv6 與必要地區行為一致。
- 記錄只保存欄位名與結果，不保存敏感值。
常見問題
尾部欄位一定能穿過代理嗎？
不能保證。協定轉換、緩衝、中介層和用戶端 API 都可能丟棄或隱藏尾部。必須測試每條必要路徑，並將結果寫入能力契約。
Trailer 標頭能保證尾部送達嗎？
不能。它只是預告稍後可能出現的欄位，協助接收方提前準備，不能保證每個中介層和用戶端都保留。
尾部可以攜帶驗證或路由資訊嗎？
通常不可以。接收本文前必須決定的路由、分幀和驗證控制不適合放在尾部，除非特定欄位規範明確允許。
HTTP/2 尾部和 HTTP/1.1 chunked 尾部完全相同嗎？
語義目的可能相似，但分幀方式不同。HTTP/2 在 DATA frame 後使用最終欄位區塊，不使用 HTTP/1.1 chunk 語法。
可選尾部缺失時是否應判定失敗？
取決於應用程式契約。應明確區分可選的可觀測中繼資料，以及決定完整性或業務完成狀態的必要尾部。
合規說明
只測試自有或明確獲准評估的代理帳號、端點、資料與路線。使用合成測試、保守流量和遮罩證據。不得在尾部放入憑證或個人資訊，不得繞過存取控制，也不得利用重試超過平台限制。
來源說明：IETF，RFC 9110《HTTP Semantics》、RFC 9112《HTTP/1.1》與 RFC 9113《HTTP/2》；查閱日期為 2026 年 9 月 24 日。外部研究位置僅保存在內部營運記錄中。
