RFC 2616 によると、HTTPサーバーから送信される情報は、Status-Line (Status行) と呼ばれる文字列を一番はじめに送信することになっています。
ステータス行は、
HTTP-Version SP Status-Code SP Reason-Phrase
という一文です。ここで、SP は空白を示します。すなわち、ステータス行とは、使用する HTTP のバージョン、Status-Code、Reason-Phrase の3つを、空白で区切った一行です。
Status Code
ここでは、Status-Code について説明します。
Status Code は3桁の数字で、その1桁目が大まかな分類を示します。
| 1xx | 経過情報 | リクエストは受理された。処理を続行する。 |
| 2xx | 成功 | リクエストは正しく受理され、理解できた。 |
| 3xx | リダイレクション | リクエストを完了するためには、さらにアクションが必要である。 |
| 4xx | クライアントのエラー | リクエストの構文が間違っていたり、完全ではない |
| 5xx | サーバーのエラー | サーバーはリクエストに応えることができなかった |
そして、残りの2桁も含めて、詳細が定義されています。ですが、Webクライアントは必ずしもすべての数字を知っている必要はありません。もし、Webクライアントがその最後の2桁を理解できなかったとき、Webクライアントは、最後の2桁を "00" と見なすことができます。すなわち、
HTTP/1.1 492 Undefined Code
のような ステータス行の場合は、492という一般的ではない値が帰ってきたので、Webクライアントはそれを「400」と見なします。理由はどうあれ、これにより「クライアントがなにかおかしなことをした」ということがわかるのです。
なお、3桁の完全な Status Code のリストは、以下のようになっています。
| Status-Code | 原因文字列 |
| 100 | 続行 |
| 101 | プロトコルの変更 |
| 200 | OK |
| 201 | 作成された |
| 202 | 受理された |
| 203 | Non-Authoritative Information |
| 204 | 内容がないよう |
| 205 | Reset Content |
| 206 | Partial Content |
| 300 | いくつかの選択肢がある |
| 301 | 永久に移動した |
| 302 | 一時的に移動している |
| 303 | 他を参照せよ |
| 304 | 変更されていない |
| 305 | プロキシーを使え |
| 400 | リクエストが不正 |
| 401 | 認証されていない |
| 402 | 支払いが必要 |
| 403 | 許可されていない |
| 404 | 見つからない |
| 405 | そのメソッドは許されない |
| 406 | 受理できない |
| 407 | プロキシによる認証が必要 |
| 408 | リクエストはタイムアウトした |
| 409 | Conflict |
| 410 | Gone |
| 411 | Length Required |
| 412 | Precondition Failed |
| 413 | リクエストの内容が大きすぎる |
| 414 | リクエストしている URI が長すぎる |
| 415 | そのメディアはサポートしていない |
| 500 | サーバー内部エラー |
| 501 | まだ実装されていない |
| 502 | ゲートウェイが不正 |
| 503 | サービスが利用できない |
| 504 | ゲートウェイがタイムアウトした |
| 505 | そのHTTPバージョンはサポートしていない |
結局のところ
実際に ステータス行を送信している CGI プログラムはあまり見かけませんが、本当にエレガントでスマートな CGI を目指すのであれば、当然この ステータス行を生成するべきです。エラーを含んだリクエストに対して、「エラーはありません」という意味の ステータス行を送りつけるのは、矛盾していて、意味がないことです。
なお、Microsoft Internet Explorer などでは、「エラーメッセージの簡略表示」という機能を持っていますが、この簡略表示も、Status Code によって判断されています。