HTTP アップロードの停止と Expect: 100-continue
Expect: 100-continue のやり取りを認識し、その短い判断点と、データ転送中に止まったアップロードとを見分けます。
接続が開きます。リクエストヘッダーが出ていきます。ファイルが動いていないように見えます。ひとつの説明は、クライアントが本文を送る前に Expect: 100-continue への応答を待っているというものです。
この仕組みにより、受信側は、大きなアップロードが送られる前にヘッダーだけでリクエストを拒否できます。通常の成功時の流れは次のとおりです。
request headers → 100 Continue → request body → final response100 は情報提供用です。クライアントが続行できることを示しますが、ファイルが保存されたことやアプリケーションの処理が成功したことを意味しません。Git push が HTTP 417 を返すのは、期待が失敗する具体的な一例です。
クライアントが受け取った応答を特定する
| 観察 | 調べるべき意味 |
|---|---|
| 100 Continue | クライアントは本文を送って続行できる |
| 本文の前の最終的な拒否 | ヘッダーの段階で処理が拒否された |
| 期待した中間応答がない | クライアントの待機方針とその経路での扱い |
curl には expect-continue 専用の待機設定があります。その libcurl の待機が期待した応答なしに切れると、本文はそのまま送られます。期限切れは、転送全体の失敗を自動的に意味するものではありません。この設定は、転送全体に許される時間とは別です。後者を増やしても、同じ最初の停止は説明されないままになります。
どの HTTP 会話が Expect を運んでいるかも特定してください。HTTPS 宛先への通常の CONNECT では、Web サイトのアップロードのやり取りは TLS の内側にあります。フォワードプロキシは、その内側の期待ヘッダーを単純に検査するわけではありません。傍受や平文転送の経路は別です。
期待を外すことは意図的な互換性の選択になり得ますが、それは、早期の拒否を知る前にクライアントが大きな本文を送り始める可能性があることを意味します。その挙動を実際の要件と比べてください。古いプロキシ向けの過去の回避策を、すべてのアップロードからヘッダーを外す普遍的な指示として説明しないでください。