如何測試代理路徑中的 Expect: 100-continue 大型檔案上傳
大型上傳的重複成本很高。HTTP Expect: 100-continue 允許 HTTP/1.1 用戶端先傳送標頭並短暫等待；若伺服器只依方法、路徑或憑證就能拒絕要求，用戶端無須先傳完整內容。代理可能刪除標頭、吞掉暫時回應、延遲超過用戶端計時器、在錯誤節點產生回應，或在最終拒絕前提前轉送內容，破壞這項機制。
本指南用於代理採購與營運驗收。只測試自有或已獲授權的端點與檔案，不得未經許可探測第三方上傳服務。
釐清預期交換
用戶端先傳送要求行與標頭（包含 Expect: 100-continue），暫不傳內容。HTTP/1.1 來源站可依標頭立即回傳最終拒絕，或先回傳 100 Continue，收完內容後再回傳唯一最終回應。中介設備通常應轉送資訊性回應，除非預期是它自行加入的。
用戶端不能無限等待。若設定的預期計時器內沒有暫時或最終回應，它可能開始傳送內容。計時器是用戶端行為，因此測試必須記錄時序，不能假設所有函式庫一致。
HTTP/2 與 HTTP/3 可終止單一要求串流而不關閉整條連線，用戶端未必以相同方式使用這項機制。應分別記錄代理兩側的實際協定，不要假定 HTTP/1.1 交換在轉換後完全不變。
建立自有上傳夾具
建立四種確定模式：
| 模式 | 標頭階段 | 內容預期 |
|---|---|---|
| 接受 | 回傳100，再回傳最終成功 | 完整內容只接收一次 |
| 未授權 | 內容前回傳最終401 | 不接收內容 |
| 不支援預期 | 回傳最終417 | 僅依明確政策決定是否重試 |
| 延遲 | 控制暫時回應延遲 | 測出用戶端等待門檻 |
使用不同大小的合成非敏感負載。記錄負載摘要、宣告長度、實收長度與最終摘要，並讓伺服器統計每個回應前後收到的位元組。
按階段蒐集證據
每次記錄測試編號、路由別名、用戶端版本、用戶端到代理協定、代理到來源站協定、是否看見 Expect、第一個暫時狀態、暫時回應耗時、內容開始時間、最終回應前位元組數、最終狀態、實收位元組、摘要是否符合、連線是否重用與重試次數。
路由與工作階段識別碼只保留雜湊，不記錄代理密碼、驗證標頭、Cookie、權杖或私有負載。
先建立直連基線
使用真實生產用戶端，在不經代理時執行全部模式。確認接受模式在 100 後只傳一次內容；標頭階段的 401 不傳內容；417 符合用戶端文件政策；延遲模式能呈現實際等待計時器。
同時測試小型與大型負載。部分用戶端會依內容大小、方法或長度是否已知加入或抑制 Expect。以線路證據為準，不能只看命令設定。
逐條加入代理路徑
分別測試每個閘道、區域、驗證方式與位址族，固定用戶端、負載、端點與逾時。比較來源站是否收到 Expect、用戶端是否收到 100、內容是否提前開始、最終拒絕是否停止內容、協定轉換是否改變順序，以及最終回應後連線能否安全重用。
標頭消失或改變時，使用代理要求標頭完整性測試；最終結果可搭配代理回應完整性測試驗證。
驗證提前拒絕節省頻寬
在未授權模式，只使用刻意無效的實驗憑證。端點應依標頭回傳最終 401，健康路徑不應繼續上傳大型內容。
同時測量用戶端傳送與來源站接收位元組。即使來源站沒有收到，代理仍可能緩衝資料，所以兩個視角都重要。負面測試不得使用真實憑證。
安全處理 417
417 Expectation Failed 表示回應鏈不支援該預期。部分用戶端可能移除 Expect 後再次要求，但這不代表所有自動重試都安全。
只有當應用能證明第一次操作未生效，或服務接受冪等機制時才能重試。限制要求次數、總時間與位元組，並在大量啟用回退前使用重試風暴預防指南。
常見故障歸因
| 現象 | 可能原因 |
|---|---|
| 每次上傳前固定停頓 | 用戶端等待未到達的100 |
| 來源站看見Expect，用戶端沒看見100 | 代理或協定轉換吞掉暫時回應 |
| 來源站從未看見Expect | 用戶端抑制或代理刪除 |
| 拒絕前內容已到達 | 計時器到期、代理提前緩衝或用戶端未等待 |
| 401後仍傳完整內容 | 回應處理或緩衝錯誤 |
| 收到兩份完整內容 | 417或傳輸重試失控 |
| 只有直連成功 | 閘道處理、協定轉換或逾時不符 |
不要把所有延遲都歸因於出口 IP 品質。在路由證據證明前，它首先是訊息流與時序問題。
驗收門檻
路由僅在以下條件全部滿足時通過：接受模式產生一個驗證成功的內容和一個最終回應；標頭階段拒絕能避免不必要上傳；暫時與最終回應順序正確；計時器有界；重試不會複製應用效果；日誌能定位失敗階段且不含祕密。
還應追蹤暫時回應耗時、拒絕節省位元組、完整上傳率、重複內容率、最終回應延遲與每次驗證成功上傳成本。單看吞吐量不能證明交握正確。
發布檢查清單
- 已掌握確切用戶端版本的直連行為。
- 已測試小型、大型、已知長度與串流內容。
- 已記錄代理兩側協定。
- 已涵蓋接受、401、417與延遲模式。
- 已比較用戶端與來源站位元組計數。
- 每個接受要求只產生一次業務結果。
- 最終拒絕能停止內容。
- Expect計時器與上傳總期限有界。
- 重試必須可安全重放或具備冪等性。
- 日誌不含憑證及私有內容。
常見問題
所有上傳都應使用 Expect: 100-continue 嗎？
不應。對小型內容，額外往返成本可能高於節省。應測試用戶端門檻與業務拒絕機率。
沒有收到100一定是代理故障嗎？
不一定。伺服器可立即回傳最終回應，用戶端也可能在計時器到期後開始傳送。需比較直連與代理線路證據。
收到100是否代表上傳成功？
不是。它只表示初始要求尚未被拒絕，用戶端仍需接收並驗證最終回應。
417是否應觸發代理輪換？
不應。它描述回應鏈對預期的支援，不代表住宅 IP 信譽。應先診斷協定路徑。
合規說明
上傳與拒絕測試只能針對自有或明確獲授權的系統。遵守服務限制、資料規則與代理政策；使用合成負載並最小化保留，不得利用代理輪換規避上傳拒絕或存取控制。
