科技 · 實用指南
curl 收到 100 或 103 仍報 Empty reply？檢查最終回應
收到標頭不代表請求完整結束。6 組 curl 8.5.0 對照實驗區分資訊回應、合法空本文與錯誤 52。
HTTP/1.1 紀錄已經出現 100 Continue 或 103 Early Hints，最後仍可能報 curl: (52) Empty reply from server。我們的 curl 8.5.0 對照實驗中，只傳送 103 後關閉連線，保存了 71 位元組標頭，response_code 為 103，但結束碼仍是 52。標頭檔案非空、狀態碼不是 000，都不能證明最終回應已經送達。
關鍵是資訊回應後有沒有最終回應，以及傳輸和預期業務結果是否完成。本文補充這個具體例外，承認現有空回應排障說明已解決的基礎問題；不會僅憑錯誤碼判斷哪個元件中斷了連線。
分別記錄 HTTP 狀態和程序結束碼
先保留 curl --version、完整方法和 URL、執行環境、代理選擇、錯誤原文與時間。針對已獲授權且無害的請求，將標頭和本文分開保存。例如 curl -sS -D response.headers -o response.body -w 'code=%{response_code} headers=%{size_header} body=%{size_download}\n' 'https://example.com/'；隨後立即保存 shell 結束狀態，POSIX shell 可用 rc=$?。替換成真正要檢查的端點，必要認證資訊僅私下保留。
第一次對照不要把本文送入另一個程式，也不要用管線最後命令的狀態代替 curl 結束碼。write-out 的 HTTP 狀態與程序結束狀態意義不同。範例沒有加入 --fail，因此完整收到 HTTP 4xx/5xx 時 curl 仍可能以 0 結束，而業務依舊失敗。必須檢查真正的最終狀態及預期內容。
按順序讀完每個回應區塊
RFC 9110 區分暫時的 1xx 回應與最終回應；RFC 8297 明確指出 103 的標頭提示不能取代最終回應標頭。閱讀保存的全部區塊，不要看到第一條 HTTP 狀態列就停止。就本問題而言，100 或 103 後斷線，與 103 後又收到最終 200，是兩種結果。
代理 CONNECT 回應及重新導向歷程也會產生多個區塊，所以要把請求方法、對端與順序一起保留，不能把所有較早的回應都當作資訊回應。100 Continue 反映請求進度，不能證明上傳的業務動作已完成；103 的 Link 只是提示，也不能證明提示的資源或主請求已成功。
對照六組已知位元組實驗
我們用 Python 3.12.14 在 127.0.0.1 提供六組人工回應，先完整讀取 GET 請求標頭，再依序關閉連線。客戶端為 Ubuntu curl 8.5.0-2ubuntu10.13，使用 --http1.1、--noproxy '*'、兩秒連線上限和三秒總時限。略過代理僅用於隔離本地實驗，不是要求略過正式環境的必要代理。實驗沒有 TLS、應用程式伺服器或中間代理。
完全不回傳位元組時，狀態為 000、標頭和本文皆為零、結束碼 52。最終 204 為狀態 204、46 位元組標頭、無本文、結束碼 0；最終 200 加 Content-Length: 0 為狀態 200、57 位元組標頭、無本文、結束碼 0。僅 100 的結果是狀態 100、25 位元組標頭、結束碼 52；僅 103 是狀態 103、71 位元組標頭、結束碼 52，兩者皆無本文。在同一個 103 後補上最終 200、Content-Length: 2 和本文 OK，結果變成狀態 200、128 位元組標頭、兩位元組本文、結束碼 0。僅 100 是刻意不完整的剖析器輸入，不是正常完整回應；精確位元組數取決於本實驗選用的標頭。
定位最終回應在哪一段未送達
OpenLiteSpeed 社群已有對應疑問：客戶端收到 100 後報 52，上游紀錄卻是 200。這個歷史討論證明使用者確實遇過這種困惑，不能據此認定目前產品仍有已確認缺陷。本地實驗只重現客戶端看見的回應形態，沒有重現該部署或其成因。
在你有權管理的系統中，以時間和請求識別碼關聯同一次安全請求的客戶端、代理及來源站紀錄，核實哪一段記錄了真實最終回應，哪一段確實向下游交付。來源站紀錄出現 200，不等於這些位元組已到 curl。保留實際組建版本；另一段 2026 年 curl-library 討論涉及不同重現案例中的 52 與 56，不能保證不同版本與故障形態一定回傳相同碼。
用最終結果驗收修復
只做一項範圍明確、可復原的修復後，在真實路徑重跑預期的安全請求，同時要求最終狀態符合預期、curl 傳輸完整、本文正確或確實合法為空。204 本來就沒有回應內容；明確使用零長度訊息框定的 200 也可以有效。兩者都不同於只收到資訊回應區塊。
對上傳或會改變狀態的 API，重試前先核實業務動作是否已發生；錯誤 52 不能證明它沒有發生。保留認證與憑證驗證，不要透過隱藏錯誤、增加無關逾時或把 100/103 當完成來製造成功。無法確定責任邊界時，提交去識別化後的有序回應區塊、結束碼、組建版本及關聯紀錄。
