HTTP リクエストメッセージとレスポンスメッセージ

HTTPリクエストメッセージ

URLを解読することで、Webサーバーとファイル名が判明したら、ブラウザはそれ元に、HTTPリクエストメッセージを作成します。実際のリクエストメッセージは、あらかじめフォーマットが決まっているので、ブラウザはこのフォーマットに合わせてリクエストメッセージを作成します。

 

リクエスト・ライン

最初に、リクエストメッセージの第1行目にあるリクエスト・ラインを記述します。先頭に記述するメソッドは、WebブラウザにWebサーバーにどうして欲しいのかを要求するためのものですが、メソッドは何種類もあるので、どのメソッドを書くべきか判断しなければなりません。通常は、ブラウザのURL記述欄にURLを入力して、そのページをそのまま表示することを前提にした場合と、Webページ内に埋め込まれたハイパーリンクをクリックしたり、フォームにデータを記述して送信ボタンを押した場合では、メソッドの種類がそれぞれ変わってきます。

URL欄にURLを入力した場合には、そのページをそのまま表示することになっているのと、ハイパーリンクをクリックした場合も同様に、GETメソッドを使用します。

フォームの場合は、フォーム部分のHTMLソースコードの中にどのメソッドを使ってリクエストを送るのかを指定しているので、その都度GETとPOSTを使い分けます。

なお、GETで送ることができるデータの量は数百バイトと小さいので、フィールドに入力するデータがそれを超える場合にはPOSTメソッドを使わなければなりません。

メソッドを記述したら空白を空け、次にURIを記述します。URIの部分には下記のような形式でファイルやプログラムのパス名を記述するのが通例です。

/<ディレクトリ名>/……/<ファイル名>

通常パス名は、URLの中に埋め込まれているので、URLからパス名を取り出し、それを書き写すことになります。そして、1行目の最後に、そのメッセージがHTTPのどのバージョン仕様に則って記述してあるのかを表すために、バージョン番号を記述することになっています。これで1行目は終了です。

メッセージ・ヘッダーとメッセージ・ボディ

2行目からはメッセージ・ヘッダーという行が続きます。1行目でリクエストの内容を明示していて、2行目のメッセージ・ヘッダーには付加的な必要情報を記述します。日付、クライアント側が扱えるデータの種類、言語、圧縮形式、クライアントやサーバーの有効期限や最終更新日時など多数の項目が仕様で定められています。その詳細な情報の表す意味を正確に理解するにはHTTPの詳しい知識が必要になります。

表1:HTTPで使われる主要なヘッダー・フィールド

  • ジェネラル・ヘッダー:リクエストとレスポンスの両方で使われるヘッダー・フィールド

 

Date リクエストやレスポンスが作成された日時を表す
Pragma データのキャッシュを許すかどうかといった、通信のオプションを表す
Cache-Control キャッシュを制御するための情報
Connection レスポンス送信後にTCPの接続を継続するか切断するか、といった通信オプションの指定
Transfer-Encoding メッセージ本体のエンコーディング方式を表す
Via 途中経由したプロキシやゲートウェイを記録しておく

 

  • リクエスト・ヘッダー:リクエストの付加情報として使われるヘッダー・フィールド
Authorization ユーザー認証用のデータ
From リクエスト発信者のメールアドレス
If-Modified-Since ある日時以降情報が更新されている場合にだけリクエストを実行したいときに、フィールド値としてリクエストを実行したいときに、フィールド値としてその日時を指定する。通常、クライアント側にキャッシュした情報と比較して、それが古くなった場合に新しい情報を受け取りたい、というときに使う
Referer ハイパーリンクをたどって次のページを読み込む場合などに、リンク元となったURIを表す
User-Agent クライアント・ソフトウエアの名称やバージョンに関する情報
Accept クライアント側がContent-Typeとして受け取れるデータの種類。MINE仕様のデータタイプで表現したもの
Accept-Charset クライアント側が受け取れる文字コードセット
Accept-Encoding クライアント側がContent-Encodingとして受け取れるエンコーディング方式。通常データの圧縮の形式を表す
Accept-Language クライアント側が受け取れる言語の種類。日本語はja、英語はen
Host リクエストを受けるサーバーのIPアドレスとポート番号

メッセージ・ヘッダーに記述する内容は、ブラウザの種類やバージョン、設定などによって異なります。メッセージ・ヘッダーを記述したら、その後に空白行を1行入れて、メッセージ・ボディという送信データの本体となる部分を記述していきます。但し、メソッドがGETの場合には、メソッドとURIだけでWebサーバーは何をすべきか判断できるため、送信データ本体である送信データを記述する必要はありません。メッセージ・ヘッダーまででメッセージは終了です。

メソッドがPOSTの場合には、フォームに入力したデータなどをメッセージ・ボディの部分に記述します。これでリクエストメッセージ作成は終了です。

HTTPレスポンスメッセージ

HTTPリクエストメッセージをWebサーバーに送るとHTTPレスポンスメッセージが返ってきます。レスポンスメッセージのフォーマットも基本的なことはリクエストメッセージと同じです。但し、1行目が違っていて、レスポンスメッセージの場合は、リクエストメッセージが正常終了したのかエラーが起きたのかという実行結果を表すステータス・コードとレスポンス・フレーズを1行目に記述することになっています。ステータス・コードは数字で記述されたもので、主に、プログラムなどに実行結果を知らせる目的を持っています。また、レスポンス・フレーズはその詳細を文章形式で記述しています。

  • HTTPのステータス・コードの概要
コード値 説明
1xx 処理の経過状況等を通知する
2xx 正常終了
3xx 何らかの別のアクションが必要であることを表す
4xx クライアント側のエラー
5xx サーバー側のエラー

レスポンス・メッセージが帰ってきたら、そこからデータを取り出して、Webブラウザに表示します。画像など他の要素がある場合にはレスポンスメッセージの中に画像ファイルを表すタグという制御情報が埋め込まれているので、ブラウザはそのタグを探して、画像を貼り付けるという意味のタグを見つけたら、そこに画像用のスペースを空けておきます。そして、もう一度、Webサーバーにアクセスして、タグが示している画像ファイルをWebサーバーに読み出して、空けておいたスペースに表示します。その場合にも、文章ファイルを読み出すときと同じように、URIの部分に画像ファイルの名前を書いたリクエスト・メッセージを作成してWebサーバーに送ります。

リクエスト・メッセージに記述するURIは1つだけと決まっているので、ファイルは一度にひとつずつしか読み出せません。例えば、ひとつの文章に画像が3つ貼り込んであれば、文章ファイルを読み出すリクエストと画像ファイルを読み出すリクエストで、合計4回、リクエストメッセージをWebサーバーに送ることになります。

ブラウザは、必要なファイルを判断して読み出し、レイアウトして画面に表示する。という具合に全体の動作を制御していきます。Webサーバーはそのような役割は負わず、ブラウザの動作を実現するために単純にひとつのリクエストに関して、ひとつのレスポンスを返すだけです。

これが、ブラウザとWebサーバーのやり取りの全容です。

  • レスポンス・ヘッダー:レスポンスの付加情報として使われるヘッダー・フィールド
Location 情報の正確な場所を表す。リクエストのURIが相対名などで指定された場合などに、絶対名での情報の位置を通知するために用いる
Server サーバー・ソフトウエアの名称やバージョンに関する情報
WWW-Authenticate リクエストされた情報へのアクセスが制限されている場合に、ユーザー認証用のデータ(チャレンジなど)を送り返す
Accept-Renges データの一部だけリクエストするRange指定があった場合、サーバーがその機能を持っているかをクライアントに通知する

 

  • エンティティ・ヘッダー:エンティティ(メッセージボディ)の付加機能として使われるヘッダー・フィールド

 

Allow 指定したURIで使用可能なメソッドを表す
Content-Encoding メッセージボディに圧縮などのエンコーディング処理が施されている場合に、その方式を表す
Content-Length メッセージボディの長さを表す
Content-Type メッセージボディがどのようなデータであるか、その種類を表す。MINE仕様で定義されたデータタイプでデータの種類を表す
Expires メッセージボディの有効期限を表す
Last-modified 情報の最終更新日時
Content-Language メッセージボディの言語を表す。日本語の場合はja、英語の場合はen
Content-Location メッセージボディがサーバーの何処に置かれていたか、その位置をURIで表したもの
Content-Range データの全体ではなく一部分がリクエストされたとき、メッセージボディにどの範囲のデータが含まれているかを表す
Etag 更新処理などで、前回のリクエストのレスポンスを元にした更新データを次のリクエストで送信するような場合があるが、そのとき、前回のレスポンスと次のリクエストを関連付けるために使用する情報。前回のレスポンスでサーバーがEtagによってユニークな値をクライアントに渡し、次回のリクエストのif-Match、if-None-March、if-Rangeフィールドでその値をサーバーに通知すれば、サーバーは前回の続きだと認識してくれる。クッキーと呼ぶフィールドと役割は同じ。クッキーはNetScape社の独自仕様であり、Etagはそれを標準化したもの

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です