如何測試代理路徑中的 Multipart 上傳完整性
HTTP 代理可能在一般頁面請求中運作正常，卻在真實上傳流程中失敗。Multipart 請求把文字欄位、重複名稱、檔名、逐段標頭與任意二進位位元組組合在同一個本文中。代理若緩衝、截斷、重試或變換本文，用戶端可能仍收到成功狀態，但應用程式實際得到缺少欄位、損壞檔案或重複提交。
本指南建立確定性的 multipart/form-data 驗收測試。只可使用自有或明確獲准測試的端點，目標是驗證正確性與有效業務結果，不是在無關服務上推送大型檔案。
理解邊界約定
請求的 Content-Type 含有 boundary 參數，同一邊界必須以精確分隔格式出現在本文，並以結束分隔符收尾。每個 part 都有自己的標頭、空行與內容。
通常應由用戶端函式庫同時產生本文與相符標頭。在瀏覽器程式碼中手動設定 Content-Type: multipart/form-data，常會遺漏自動產生的邊界而形成無效請求。測試必須檢查實際傳送結果，不能只看建立表單的程式碼。
合規中間節點不應靜默修改邊界、part 標頭或位元組。兩個傳輸段可以使用不同合法框架，因此應比較解碼後的 HTTP 訊息，而不是要求封包邊界完全一致。
建立自有上傳測試夾具
建立每次接收單一請求並回傳精簡收據的實驗端點，包含：
| Part | 測試值 | 目的 |
|---|---|---|
| text | 短 ASCII 值 | 驗證一般欄位 |
| note | 多語言 UTF-8 文字 | 驗證編碼與長度 |
| tag | 兩個同名欄位 | 驗證重複欄位數量與順序 |
| empty | 零位元組欄位 | 驗證空值保留 |
| file_a | 確定性二進位檔案 | 驗證位元組完整性 |
| file_b | 零位元組檔案 | 驗證空檔案行為 |
使用固定種子在本機產生二進位夾具並記錄 SHA-256。內容可涵蓋零位元組、高位元組、CRLF 與類似一般邊界文字的片段，但不得包含憑證、個人資料或正式環境檔案。
伺服器收據只回傳安全證據：欄位數、有序欄位名稱雜湊、清理後的檔名、宣告媒體類型、接收位元組數、逐檔摘要與一個業務結果 ID。
建立直連基準
使用預計投入正式環境的相同用戶端及版本，在無代理時傳送夾具，確認：
- 標頭邊界與本文分隔符相符；
- 除刻意重複的欄位外，每個預期 part 恰好出現一次；
- 重複值保留應用要求的順序；
- 空欄位和零位元組檔案都沒有消失；
- UTF-8 文字正確往返；
- 檔案長度與摘要一致；
- 結束分隔符存在；
- 一個請求只建立一個業務結果。
保存去識別化收據作為基準。能以雜湊與計數證明時，不要保留完整上傳本文。
每次只比較一條代理路線
固定用戶端、夾具、端點與逾時，只改變代理閘道、區域、認證方式、工作階段策略或位址族。每次記錄：
test_id
route_alias
client_version
client_to_proxy_protocol
proxy_to_origin_protocol
request_content_type_hash
part_count
repeated_field_count
received_file_bytes
received_file_digest_match
final_status
application_result_count
retry_count若完整 Content-Type 含有隨機邊界，可只保存其雜湊。禁止記錄代理密碼、Cookie、認證標頭、原始工作階段 ID 或私密檔案內容。
邊界參數消失或改變時，搭配代理請求標頭完整性測試定位；收據不完整時，使用代理回應完整性測試。
同時測試緩衝與串流本文
用戶端支援時應執行兩種模式：
- 傳送前即可知道總長度的本文；
- 傳輸期間才決定框架方式的串流本文。
即使一條路徑使用 Content-Length，另一條路徑採用分塊或協定原生框架，應用層 multipart 結構也必須一致。測試小型及適度大小的合成檔案，並保持在服務商與端點限制內。
若只有串流代理上傳失敗，應記錄失敗發生在代理認證、通道、標頭、首批本文、中途傳輸或最終回應。單一總逾時不足以定位。
安全測試檔名與重複欄位
不同用戶端與伺服器處理非 ASCII 檔名的方式可能不同。先測試一般檔名，應用明確支援時再加入無害的多語言名稱。伺服器必須移除目錄部分，絕不能把用戶端檔名直接當作檔案系統路徑。
重複欄位名稱合法且常見。確認框架回傳所有值，而不是只保留第一個或最後一個。若順序具有業務意義，應寫明約定並測試。字典比較會遺失重複項，不能作為 multipart 等價證明。
有意測試重新導向
上傳端點應盡量避免不必要的重新導向。自有流程確實包含重新導向時，應測試正確狀態碼與用戶端行為。有些處理會改變方法或拒絕重放本文。記錄用戶端是否重送、哪個目標收到請求，以及產生多少業務結果。
禁止跟隨到未核准主機。設定允許清單，目標超出自有測試範圍時立即停止。
讓重試保持安全
最後一個本文位元組送出後發生網路故障，會產生不確定狀態：伺服器可能已經提交上傳，但用戶端沒有收到收據。盲目輪換代理再送一次可能製造重複結果。
使用應用冪等鍵或自有上傳工作階段識別碼，並限制嘗試次數、總耗時與傳送位元組數。同一邏輯操作必須回傳或引用同一結果。啟用自動容錯切換前，先執行重試風暴預防指南。
大型本文可能在標頭階段被拒絕時，可搭配Expect: 100-continue 上傳測試。本測試驗證 multipart 本文與業務結果，Expect 測試驗證標頭與本文握手順序。
常見故障模式
| 現象 | 優先檢查 |
|---|---|
| boundary 參數遺失 | 用戶端手動設定 Content-Type 或標頭被修改 |
| 伺服器只解析出一個巨大欄位 | 分隔符或換行格式錯誤 |
| 最後一個 part 遺失 | 截斷或結束分隔符遺失 |
| 二進位摘要不符 | 本文變換、截斷或夾具錯誤 |
| 重複值只剩一個 | 框架或應用折疊重複項 |
| 直連正常、串流代理失敗 | 緩衝、框架、逾時或閘道限制 |
| 產生兩個業務結果 | 不確定失敗後的不安全重放 |
| 狀態成功但收據錯誤 | 應用驗證或回應完整性故障 |
不要把每個 multipart 故障都歸因於出口 IP 信譽。本測試的大多數問題來自訊息建構、傳輸框架、緩衝、限制或重試邏輯。
驗收清單
- 用戶端產生的邊界與本文一致。
- 預期 part 數與重複值被保留。
- 空欄位和零位元組檔案仍存在。
- 多語言文字正確往返。
- 清理後的檔名符合應用約定。
- 檔案長度與 SHA-256 一致。
- 已測試緩衝及串流模式。
- 重新導向目標和重放行為受控。
- 一個邏輯上傳只產生一個業務結果。
- 重試有上限且具冪等性。
- 記錄只含雜湊與計數，不含秘密或私密原檔。
常見問題
瀏覽器程式碼應手動設定 multipart Content-Type 嗎？
通常不應。當瀏覽器或表單函式庫產生本文時，讓它設定標頭，確保 boundary 參數相符。仍需驗證所用用戶端的實際行為。
HTTP 200 能證明上傳完整嗎？
不能。還要核對伺服器收據、part 數、位元組長度、檔案摘要及業務結果數量。
代理可以改變傳輸框架而不破壞 multipart 嗎？
可以。兩段路徑可採用不同合法框架，必須保持的是解碼後的 HTTP 訊息及 multipart 結構。
上傳失敗後是否應立即輪換代理 IP？
不應。先確定失敗階段，並判斷伺服器是否已提交操作。只有在有界且冪等的策略下才可輪換。
合規說明
Multipart 上傳測試僅可針對自有或明確獲准使用的系統。遵守檔案大小、速率、內容政策、區域資料要求及代理條款。使用合成夾具、清理檔名、減少資料保留，絕不能透過代理輪換繞過上傳控制。
