HTTP リクエストメッセージとレスポンスメッセージ
HTTPリクエストメッセージ
URLを解読することで、Webサーバーとファイル名が判明したら、ブラウザはそれ元に、HTTPリクエストメッセージを作成します。実際のリクエストメッセージは、あらかじめフォーマットが決まっているので、ブラウザはこのフォーマットに合わせてリクエストメッセージを作成します。
- リクエストメッセージ
<メソッド><空白><URL><空白><HTTPバージョン> ……①
<フィールド名>:<フィールド値> ……②
……
<空白行>
<メッセージボディ> ……③①：この最初の行をリクエストラインと呼び、この１行でリクエストの内容がおおよそわかる。
②：この部分をメッセージヘッダーといい、１行にひとつのヘッダーフィールドを記述する。このことにより、リクエストに関する付加価値的な情報を表す。その行数は状況によって異なり、空白行までがメッセージヘッダーと見なされる。
③：メッセージボディの中身はクライアントからサーバーへ送信するデータや、フォーム入力されたデータをPOSTメソッドでWebサーバーへ送るときなどにデータそれらのデータが記述される。
- レスポンスメッセージ
<HTTPバージョン><空白><ステータスコード><空白><レスポンスフレーズ> ……①
<フィールド名>:<フィールド値>
……
<空白行>
<メッセージボディ> ……②①：この行をステータスラインといい、レスポンスフレーズにはステータスコードの内容を表す短い説明文が記述される。
②：メッセージボディの内容は、サーバーからクライエントに送信するデータである。ファイルから読み出したデータやCGIアプリケーションが出力したデータが記述される。これらのメッセージボディはバイナリデータとして扱う。
リクエスト・ライン
最初に、リクエストメッセージの第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はそれを標準化したもの |