【入門編】HTTP/1.1のExpect: 100-continueのフロー – HTTPプロトコル・通信規格実践ガイド

「とりあえず送る」から「確認してから送る」へ。HTTP/1.1の『Expect: 100-continue』が解決する意外な問題

こんにちは！ネットワークの世界へようこそ。
普段、私たちがブラウザでWebサイトを見たり、APIを叩いたりするとき、裏側では「HTTP」というプロトコルが猛スピードで情報を運んでいます。

さて、皆さんは大きな荷物を送る時、いきなり相手の家のドアをぶち破って中まで入ろうとはしませんよね？まずは「今から大きな荷物を送ってもいい？」とインターホンで確認するのがマナーであり、効率的です。

実は、HTTP/1.1の世界にもこれと全く同じ仕組みがあるんです。それが今回解説する『Expect: 100-continue』というヘッダーです。

—

1. なぜ「確認」が必要なのか？：ネットワークの現場から

例えば、あなたが100MBもの巨大な動画ファイルをアップロードしようとしているとします。

もし、確認なしにデータを送り始めたらどうなるでしょう？
もしサーバー側が「ごめん、そのファイル形式は受け付けないよ」とか「認証が足りないからダメ！」と拒否する設定だったら、あなたは100MB分のパケットをドブに捨てたことになります。

ネットワーク帯域を無駄に使い、時間も無駄にする。これ、インフラエンジニアとしては一番避けたい「無駄な通信」ですよね。

そこで登場するのが、この『Expect: 100-continue』という「事前交渉」の仕組みです。

—

2. 郵便配達で例える『Expect: 100-continue』のフロー

このやり取りを、郵便配達に例えてみましょう。

1. クライアント（あなた）： 「今からめちゃくちゃ重い荷物を送ります！受け取れますか？（`Expect: 100-continue` を含めた手紙を送る）」
2. サーバー（配達先）： （中身を確認して…）「OK！準備万端だよ。送ってくれ！（`100 Continue` という返事を返す）」
3. クライアント： 「了解！それじゃあ荷物を送るよ！（本体データを送信）」

もしサーバーがダメだと言えば、その時点でやり取りは終了。本体データを送る必要がないので、ネットワークは平和なままです。

—

3. 実際にどう書くの？（コード例）

では、具体的にリクエストを投げる時のイメージを見てみましょう。エンジニアとしてコードで理解しておくと、デバッグの時に「今、何が起きているか」が手に取るようにわかります。

クライアントから送るリクエストの例

POST /upload-video HTTP/1.1
Host: example.com
Content-Type: video/mp4
Content-Length: 104857600
Expect: 100-continue // 「このヘッダーが、『送ってもいい？』の合図です」

(※ここではまだ本体データは送らない)

サーバーからの返答

もしサーバーが受け入れ可能なら、以下のような返事が返ってきます。

HTTP/1.1 100 Continue // 「準備できたよ！本体を送ってくれ」

この返事を受け取ってから、クライアントは本体のデータを流し込み始めます。もしエラーがあれば、`417 Expectation Failed` や `403 Forbidden` などが返ってくるので、そこで中断すればいいわけです。

—

4. この仕組み、どこで意識すればいい？

「普段開発していて、このヘッダーを意識したことないよ」という方も多いはずです。それもそのはず。最近のライブラリ（Pythonの `requests` や JavaScriptの `fetch` など）は、ある程度の大きさのリクエストになると、自動的にこの交渉をやってくれることが多いからです。

でも、トラブルシューティングの現場では重要です。
例えば、「なぜかPOSTリクエストを送ると、サーバー側で少し反応が遅れる（あるいはエラーになる）」という時、実はこの `100-continue` が原因だったりします。

サーバーが古い、または設定が厳格で、`Expect` ヘッダーをうまく処理できずにエラーを返している。
プロキシサーバーが間に入っていて、このやり取りを勝手に遮断している。

こんな時、「あ、これって事前確認のやり取りのところでコケてるのかも？」とピンとくるだけで、問題解決のスピードは劇的に上がります。

—

まとめ：一歩ずつ理解していきましょう！

HTTP/1.1の `Expect: 100-continue` は、決して難解な魔法ではありません。
「無駄な通信を減らすための、ちょっとしたマナーと確認の仕組み」だと捉えてみてください。

1. 大きなデータを送る前に「送っていい？」と聞く。
2. 「いいよ」と言われたら、本体を送る。
3. ダメなら送らない（＝帯域の節約！）。

このシンプルな流れを知っているだけで、ネットワークの挙動が今までより少しだけクリアに見えてくるはずです。最初はピンとこなくても大丈夫。実務でパケットキャプチャを眺めながら、「お、今『100 Continue』が走ったな」と確認できた時、きっと面白さがわかるはずですよ。

それでは、また次のネットワークの深淵でお会いしましょう！