テクノロジー · 実用ガイド
100 や 103 の後に curl が Empty reply？ 最終応答を確認する
ヘッダーの受信だけでは完了とは限りません。curl 8.5.0 の6つの対照実験で、情報応答と正常な空本文、エラー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/' です。直後にPOSIXシェルなら rc=$? などで終了状態を保存してください。対象URLに置き換え、必要な認証情報は非公開で保持します。
最初の比較では本文を別プログラムへパイプせず、パイプ末尾のコマンドの状態をcurlの終了状態と混同しないでください。write-outのHTTPコードとプロセス終了は別の情報です。この例には --fail がないため、HTTP4xx/5xxを完全に受信してcurlが0で終了しても、アプリケーション上は失敗し得ます。実際の最終状態と内容を確認します。
すべての応答ブロックを順に読む
RFC9110は暫定的な1xxと最終応答を区別し、RFC8297は103のヒントが最終応答ヘッダーの代わりにならないと定めます。最初のHTTP状態行だけで止めず、保存した全ブロックを読みます。ここでは100/103の後に切断する場合と、103の後に最終200が来る場合を分けます。
プロキシCONNECTやリダイレクトの履歴でも複数ブロックが現れるので、メソッド、接続相手、順序を残します。以前のブロックをすべて情報応答と呼ばないでください。100Continueは要求の進行を示し、アップロードによる処理完了を証明しません。103のLinkもヒントであり、リンク先や主要求の成功を証明しません。
既知のバイト列を使う6つの対照実験
Python3.12.14で127.0.0.1上に6種類の人工応答を用意し、GET要求ヘッダーを最後まで読んでから正常に接続を閉じました。クライアントはUbuntu curl8.5.0-2ubuntu10.13で、--http1.1、--noproxy '*'、接続上限2秒、総上限3秒を使用しました。プロキシ設定はローカル実験の分離用で、本番の必須プロキシを迂回する指示ではありません。TLS、アプリケーションサーバー、中継機器は試していません。
応答バイトなしではコード000、ヘッダーと本文0、終了52。最終204ではコード204、ヘッダー46バイト、本文なし、終了0。Content-Length: 0付き最終200はコード200、ヘッダー57バイト、本文なし、終了0でした。100のみはコード100、ヘッダー25バイト、終了52。103のみはコード103、ヘッダー71バイト、終了52で、どちらも本文なしです。同じ103の後に最終200、Content-Length: 2、本文OKを追加すると、コード200、ヘッダー128バイト、本文2バイト、終了0になりました。100のみは意図的に不完全な解析用入力で、通常の完全な応答ではありません。バイト数はこの実験のヘッダーに固有です。
最終応答が届かなくなった境界を調べる
OpenLiteSpeedの過去のコミュニティ投稿には、クライアントが100の後に52となる一方、上流ログには200がある例が掲載されています。実在する疑問の証拠ですが、現在の製品の欠陥が確認されたという意味ではありません。ローカル実験で再現したのはクライアントに見える応答の形だけで、その構成や原因ではありません。
管理権限のあるシステムで、安全な1件の要求を時刻と要求IDでクライアント、プロキシ、オリジンのログに対応付けます。どこが実際の最終応答を記録し、どこが下流へ渡したかを確認します。オリジンの200ログだけでcurlへの到達は証明できません。実際のビルドを保存してください。2026年の別のcurl-library議論は異なる再現例の52と56を扱っており、バージョンや故障形態を越えて同じコードになるとは保証できません。
最終結果で修復を確認する
範囲を絞った元に戻せる修正を1つ行い、本来の経路で意図した安全な要求を再実行します。期待する最終状態、curl転送の完了、正しい本文または正当な本文不在をすべて確認します。204には本来応答内容がなく、長さゼロを明示した200も有効です。どちらも情報応答しか届かない場合とは異なります。
アップロードや状態を変更するAPIは、再試行前に処理済みか確認します。52は未処理を証明しません。認証と証明書検証を維持し、標準エラーの隠蔽、無関係なタイムアウト延長、100/103の完了扱いで成功を装わないでください。責任境界が不明なら、秘密情報を除いた応答順序、終了コード、ビルド、対応するログを引き継ぎます。
