HTTP 100(エイチティーティーピーハンドレッド)とは | 意味や読み方など丁寧でわかりやすい用語解説
HTTP 100(エイチティーティーピーハンドレッド)の意味や読み方など、初心者にもわかりやすいように丁寧に解説しています。
読み方
日本語表記
続行 (ゾッコウ)
英語表記
Continue (コンティニュー)
用語解説
HTTP 100は、HTTPプロトコルにおける情報レスポンスステータスコードの一つであり、「Continue(継続)」を意味する。これは、クライアントがリクエストを続行すべきであることを示すためのもので、HTTPステータスコードの1xx(情報レスポンス)カテゴリに分類される。主に、クライアントがサーバーに対して大きなリクエストボディ(例えば、大量のデータを含むファイルアップロードなど)を送信する前に、サーバーがリクエストのヘッダ部分を受け入れ、処理する準備ができているかを確認する目的で使用される。クライアントはリクエストヘッダにExpect: 100-continueというフィールドを含めてリクエストの一部を送信し、サーバーがそのヘッダを検証した結果、リクエストボディの送信を許可する場合にHTTP 100レスポンスを返す。このメカニズムによって、クライアントは不要なデータ送信を回避し、ネットワークリソースの無駄を削減できる。
このHTTP 100が導入された背景には、ネットワークリソースの効率的な利用という重要な目的がある。もしクライアントがPUTやPOSTメソッドで非常に大きなリクエストボディをサーバーに送信し終えてから、サーバー側で認証の失敗や不正なヘッダといった問題が発覚した場合、すでに送信された大量のデータは無駄になり、ネットワーク帯域も不必要に消費されてしまう。このような非効率な状況を防ぐために、HTTP 100 Continueという事前確認の仕組みが考案された。
このメカニズムの動作は以下の通りである。まず、クライアントはリクエストヘッダのみをサーバーに送信する。このヘッダにはExpect: 100-continueというフィールドが含まれており、これはクライアントが「もしサーバーがこのリクエストを受け入れる準備ができていなければ、私はリクエストボディ全体を送るべきではない」という意図を伝える役割を持つ。サーバーはこのヘッダを受け取ると、リクエストのヘッダ部分だけを解析し、認証情報の検証、リクエスト形式のチェック、リクエストされたリソースへのアクセス権限の確認などを行う。
サーバーがリクエストヘッダ部分を問題なく受け入れ、リクエストボディの送信を続行して良いと判断した場合、サーバーは速やかにHTTP 100 Continueという情報レスポンスをクライアントに返す。このレスポンスを受け取ったクライアントは、その後安心してリクエストボディの残りの部分をサーバーに送信し始めることができる。リクエストボディ全体がサーバーに届いた後、サーバーは全体の処理を完了し、最終的なステータスコード(例えば、リクエストが成功した場合は200 OKや201 Created、エラーの場合は400 Bad Requestなど)を含む最終レスポンスをクライアントに送り返す。
しかし、もしサーバーがリクエストヘッダの段階で問題を発見した場合、例えば認証情報が不正であるため401 Unauthorizedを返す必要がある、リクエスト形式が誤っているため400 Bad Requestを返す必要がある、あるいはリクエストされたリソースが存在しないため404 Not Foundを返す必要があるといった状況では、サーバーはHTTP 100を返さず、直接適切なエラーレスポンスをクライアントに返す。この場合、クライアントはエラーレスポンスを受け取った時点で、リクエストボディを送信する必要がないと判断し、データの送信を中止する。これにより、不要なデータ転送による帯域幅の浪費を防ぐだけでなく、サーバー側での不必要な処理も回避できる。
ただし、すべてのHTTPサーバーがExpect: 100-continueヘッダを完全にサポートしているわけではない。もしサーバーがこのヘッダを理解しない場合、いくつかの異なる挙動が起こりうる。一つは、サーバーがこのヘッダを単純に無視し、クライアントからのリクエストボディの送信を待ち続けるパターンである。この状況では、クライアントは通常、一定時間(タイムアウト期間)待機した後、自動的にリクエストボディの送信を開始する。もう一つは、サーバーがExpectヘッダで示されたクライアントの期待に応えられないことを示すエラーコード、例えば417 Expectation Failedを返すパターンである。現代の多くのHTTPクライアントライブラリやWebブラウザは、これらの異なるサーバーの挙動を適切に処理するように内部で設計されているため、システムエンジニアを目指す初心者が日常的にこのメカニズムを意識してコーディングすることは少ないかもしれないが、その裏側でこのような効率化のためのやり取りが行われていることを理解しておくことは非常に重要である。
このメカニズムは、特に大規模なデータ転送が頻繁に行われるWebアプリケーションやAPIにおいては、ネットワーク効率の向上に大きく貢献する。しかし、HTTP 100レスポンスを送信するためには、クライアントとサーバー間で追加のネットワークラウンドトリップが発生する。そのため、リクエストボディが非常に小さい場合や、サーバーがリクエストヘッダを即座に処理できるような単純なケースでは、この追加のやり取り自体がわずかながらオーバーヘッドとなる可能性もある。そのため、多くのHTTPクライアントは、リクエストボディのサイズが一定の閾値を超える場合にのみExpect: 100-continueヘッダを使用するようになっている。また、GETやHEADといったリクエストボディを持たないHTTPメソッドでは、このメカニズムはそもそも使用されない。この機能はHTTP/1.1以降のプロトコルで導入されたものであり、HTTP/1.0以前のプロトコルではサポートされていない。HTTP 100 Continueは、単なる情報レスポンスに留まらず、クライアントとサーバー間の協調的な通信を通じて、より堅牢で効率的なデータ転送を実現するための重要なプロトコル機能の一つなのである。