PR

レスポンス・メッセージ

 レスポンス・メッセージ(図2)も基本的な構造はリクエスト・メッセージと同じです。ただ、スタート行が違っていて、先頭にプロトコル・バージョンを表す文字列があり、スペースで区切って、応答コードと応答コード文字列が続き、最後にCRLFが来ます。

図2 レスポンス・メッセージの先頭には、バージョンや応答コードの行があり、それにヘッダー、そして本文データが続く。
図2 レスポンス・メッセージの先頭には、バージョンや応答コードの行があり、それにヘッダー、そして本文データが続く。
[画像のクリックで拡大表示]

 レスポンスは、この応答コードで、リクエストの実行状況などを通知し、応答コード文字列は、この応答コードを補助するものとして使われています。この後ろに、レスポンス・メッセージ・ヘッダーが並び、単独のCRLFを置いて、その後ろにメッセージ本体が置かれます。なお、HEADメソッドに対するレスポンス・メッセージなど、メッセージ本体がない場合もあります。

 応答コードは、3ケタの数字で表現されており、その先頭の数字1~5が分類を表します(表3)。このあたりは、SMTP(簡易メール転送プロトコル)などとよく似ています。この先頭の数字を見るだけで、コマンドが受理されたのか、エラーなのか、実行できないのかといったことがわかり、残りを見ることでその原因を推定できます。

[画像のクリックで拡大表示]

 ステータス・コードが4もしくは5で始まる場合、エラーであり、1もしくは2の場合、コマンドは受け付けられたことが判定できます。このステータス・コードは、対応するリクエストに応じて戻ってくるものが決まっています。

 予想もつかないステータス・コードが返ってくることはありません。なお、RFC2616では、表4のステータス・コードを定義しています。

[画像のクリックで拡大表示]