| ログ解析スクリプトAWStats 7.8ドキュメント |

# 用語集

一意な訪問者数:
  一意な訪問者数とは、レポートに表示されている期間の間に、Webサイトの最低1ページで1ヒットを記録したホストの数です。もし同一のホストがその期間中に複数回訪問した場合でも、1回しかカウントされません。 AWStatsのレポートに表示されるデフォルトの期間は、その月(当月)です。 AWStatsをCGIとして利用した場合、1年間のレポートを表示されるために"年"のリンクをクリックすることができます。"年"のレポートの中では期間は1年間となり、一意な訪問者が意味するところは、その1年間にあなたのWebサイトの最低1ページで1ヒットを記録したホストの数ということになります。
訪問回数:
  全ての訪問者によって記録された、延べ訪問回数。 "滞在時間"をここで考えてみてください。例えばある特定のIPアドレスからのアクセスがあるページにあり、どのアクセスの間も1時間はあいていなくて、3ページにアクセスがあったと仮定すると、これら全ての"ページ"はその訪問に含まれることになります。つまり、複数ページのアクセスを単一の訪問と期待することも、複数の訪問を単一の訪問者に期待することもできることになります(特定のIPアドレスから1時間以上の間隔を空けてアクセスがあった場合)。
ページ:
  ログに記録された"ページ"の数。設定ファイルのNotPageListパラメーターに含まれているエントリに合致しない(そしてOnlyFilesが設定されている場合、そのエントリに合致する)ファイルのみが"ページ"としてカウントされます。通常、ページはHTMLファイルもしくはCGIファイルに予約されており、イメージファイルや"ページ"をロードした結果として発生したリクエスト(js、ccsなど)は"ページ"としてカウントされません。
ヒット:
  設定ファイルのSkipFilesパラメーターにするファイルを除いた、サーバーからリクエストされた全てのファイル("ページ"ファイルも含む)。
帯域
  ウェブ閲覧でダウンロードされたページ、イメージ、ファイルのバイト数の合計。
  註1: もちろん、この量はウェブだけ(または、LogTypeの値によりメールだけ、ftpだけ)のトラフィックの値です。
  註2: この量はHTTPかHTTPSプロトコルや下位プロトコルで(TCP、IP…)のヘッダー・データサイズを含んでいません。
  前の2つの註のために、この量はプロバイダーが報告する帯域よりしばしば少なくなります(プロバイダーは、多くの場合、下位で帯域を計り、すべてのIPとUDPトラフィックを含んでいます)。
最初に閲覧されたページ
  ある訪問の中で、最初に閲覧されたページ。
  註: 訪問が月末に開始され、翌月頭に終了した場合、その月のレポートには最初に閲覧されたページのみが記録され、最後に閲覧されたページは記録されません。 このため、最初に閲覧したページの数と最後に閲覧したページの数とが、合わない可能性があります。
最後に閲覧されたページ:
  ある訪問の中で、最後に閲覧されたページ。
  註: 訪問が月末に開始され、翌月頭に終了した場合、その月のレポートには最初に閲覧されたページのみが記録され、最後に閲覧されたページは記録されません。 このため、最初に閲覧したページの数と最後に閲覧したページの数とが、合わない可能性があります。
滞在時間:
  一回の訪問について、訪問者がサイトで費やした時間。
  訪問の一部の滞在時間が"不明"になるのは、必ずしも計算できるとは限らないからです。以下にいくつかの主な理由を示します:
  - ログファイルの'更新'が発生したときに訪問が終了するわけではない。
  - 訪問がその月の最後の日の最後の1時間(23:00以降)に開始された場合(技術的な理由で、AWStatsはこのような訪問の滞在時間を計算することができません)。
Grabber
  サイト全体をローカルにコピーするのを主な目的としているブラウザ。"teleport"、"webcapture"、"webcopier"などが代表例です。
直接URLを入力/ブックマーク
  サイトへの訪問が直接アクセスから来るとき、この数はヒットの数かヒットの比率を表します。これは、ウェブサイトの最初のページが呼ばれたことを意味します:
  - ウェブブラウザアドレスバーにURLをタイプすることによって
  - お気に入りに訪問者が格納したURLをクリックすることによって
  - 別のインターネットウェブページではない所で見つけられたURLをクリックするのによる(ドキュメント、アプリケーションなどにおけるリンク。)
  - メールでサイトのURLをクリックするのはしばしばこれに数えられます。
お気に入りへの追加[6.9以降、「favicon.icoへのヒット」に変更]
  この「その他の情報」チャートで利用可能な値は、訪問者がウェブサイトをお気に入りやブックマークに加えた回数の概算を報告します。
  以下の式で算出しています。

  お気に入りへの追加数 = round((x+y) / r)

  ここで、
  - xは、IEブラウザから、refererフィールドなしで、かつ404エラーコードなしで、"/任意のディレクトリ/favicon.ico"にヒットした数。
  - yは、IEブラウザから、refererフィールドなしで、かつ404エラーコードあってもなくても、/favicon.icoにヒットした数。
  - rは、すべてのブラウザのなかで、IEブラウザにるヒットの割合(r<=1)
  公式から分かるように、信頼できる「追加」を数えるためにIEだけが使用されています。他のブラウザの「お気に入りへの追加」はIEでの比率から見積もられています。理由は、IEだけが、ほぼユーザがお気に入りにページを加えるときだけに、favicon.icoにヒットするということです。他のブラウザは他の理由でもこのファイルにヒットするので、1「ヒット」を1「追加」にみなすことができません。それが別のためのヒットであるかもしれないからです。
  また、AWStatsは誤りでヒットを区別します。それにより、favicon.icoファイルが深いディレクトリで見つけられないときの上位のパスで再帰的にされた複数のヒットを数えるのを避けます。
  この数が、本当より高い値を出すことの多い、目安であることに注意してください。理由はIEブラウザでさえ、でユーザによる「お気に入りに加えてください」動作なしでfaviconをヒットすることが時々あるからです。
HTTPステータスコード
  ウェブサーバーは、HTTPステータスコードを返して、要求の状態を示します。コード200と304は、ページを見ることができるとブラウザに伝えるに使用します。他のすべてのコードが訪問者によって'見られなかった'ヒットとトラフィックの場合にを生成されます。例えば、コード301か302は、^別のページを要求するようにブラウザに伝えます。ブラウザは、別のヒットをして、最終的にコード200か304でページを受信するはずです。AWStatsでは、'見えない'トラフィックで、コードすべてがHTTPステータスコードチャートにのみ表示して、この表示は構成ファイルのShowHTTPErrorsStatsディレクティブによって表示が制御されます。ValidHTTPcodesディレクティブで、(デフォルトでは200か304になっている)'エラーでない'値を変更することができます。
  「ハイパーテキスト転送プロトコル -- HTTP/1.1」(IETF rfc 2616)で定義されているすべてのステータスコードの概要を以下の表に示しました。3ケタのコードのうち最初の1桁がステータスコードのクラスを示し、残り2桁が応答のクラスの中の特定の状態に対応し、5つのクラスに分類されます。
  - 1xx - informational
  - 2xx - successful
  - 3xx - redirection
  - 4xx - client error
  - 5xx - server error

  1xx class - Informational このステータスコードのクラスは一時的なレスポンスを示し、ステータスラインとオプション的なヘッダからのみなり、空行で終了する。このステータスコードのクラスのための必要なリクエストヘッダは無い。HTTP/1.0では、どんな1xxステータスコードも定義していないので、サーバは実験的な状況下以外ではHTTP/1.0クライアントに1xxレスポンスを送ってはならない。 クライアントは、例え100(Continue)ステータスメッセージを期待していなかったとしても、通常のレスポンスの前の一つ以上の1xxレスポンスを受け入れるよう準備されていなければならない。ユーザエージェントは、期待していない1xxレスポンスを無視する事ができる。 プロクシは、もしプロクシとクライアント間の接続が切断されている、あるいはプロクシ自身が1xxレスポンスの生成を要求したという場合以外は、1xxレスポンスを転送しなければならない。(例えば、プロクシがリクエストを転送する時に"Expect:100-continue"というフィールドを付け加えた時には、それに相当する100(Continue)レスポンスを転送する必要はない。) |
  100 | 100 Continue クライアントは、そのリクエストを続けるべきである。この暫定的レスポンスは、リクエストの始めの部分は受け取られ、サーバによって拒否されたものではないという事をクライアントに知らせるために使用される。クライアントは、リクエストの残りを送り続けるか、もし既にリクエストが完了していれば、このレスポンスを無視すべきである。サーバは、リクエストが完了した後に最終的なレスポンスを送らなければならない。
  101 | 101 Switching Protocols サーバは理解し、Upgradeメッセージヘッダフィールドを使って、この接続で使用されているアプリケーションプロトコルを変更する事でクライアントのリクエストに従おうとしている。サーバは101レスポンスを終了する空行のあと、すぐにレスポンスのUpgradeヘッダフィールドによって定義されたプロトコルに変更するだろう。 プロトコルは、変更した方が有益な場合にのみ変更されるべきである。例えば、HTTPのより新しいバージョンに変更するという事は、古いバージョン以上に有益だし、リアルタイムに、同期するプロトコルを変更する事はそのような機能を使うリソースを配布するときに都合が良いだろう。
  2xx class - Successful このステータスコードのクラスは、クライアントのリクエストがうまく受信され、理解され、そして受け入れられた事を示す。 |
  200 | 200 Successful リクエストは成功した。レスポンスと共に返される情報はリクエストに使用されたメソッドに依存し、例えば以下の様になる。 GETリクエストされたリソースに対応するエンティティがレスポンスとして送られる。 HEADリクエストされたリソースに対応するエンティティヘッダフィールドがメッセージボディを伴わずにレスポンスとして送信される。 POST動作の結果を記述もしくは含んでいるエンティティ TRACE端末サーバによって受信されたリクエストメッセージを含んでいるエンティティ
  201 | 201 Created リクエストは果たされ、結果として新しいリソースが作成された。新しく作成されたリソースはLocationヘッダにより与えられるリソースに対する最も明確なURIを伴って、レスポンスのエンティティにおいて返されるURIによって参照される。レスポンスは、ユーザあるいはユーザエージェントが最も適切なものを選択するために、リソースの特徴と場所のリストをエンティティとして含むべきである。エンティティのフォーマットは、Content-Typeヘッダフィールドにて与えられるメディアタイプによって指定される。オリジンサーバは、201ステータスコードを返す前にリソースを作成しなければならない。もし動作がすぐに実行できないのであれば、サーバは代わりに202(Accepted)レスポンスを返すべきである。 201レスポンスは、作成されたばかりのリクエストされたバリアントのために、現在のエンティティタグの値を示すETagレスポンスヘッダフィールドを含む事ができる。
  202 | 202 Accepted リクエストは処理のために受け入れられたが、処理は完了されていない。このリクエストは、実際に処理される時に拒否されるかもしれないので、最終的に動作されるかどうかは不明である。このような非同期操作からステータスコードを再送信するための機能は存在しない。 202 レスポンスは、意図的に責任を持たない。これはサーバが、プロセスが完了されるまでユーザエージェントとの接続を持続させる事無く、他のいくつかのプロセス (多分一日に一度しか実行されないバッチ志向プロセス) のためのリクエストを受け入れる事を可能にするという目的を持つ。このレスポンスによって返されるエンティティは、リクエストの現在の状態を表すものと、状態モニタへのポインタ、あるいはそのリクエストがいつ果たされるかをユーザが予期できる見積もりのどちらかを含むべきである。
  203 | 203 Non-Authorative Information エンティティヘッダにおいて返された外部情報は、オリジンサーバから利用できるような決定的なセットではなく、ローカルもしくはサードパーティコピーから集められたものである。提示されたセットは元のバージョンのサブセットかスーパーセットで あろう。例えば、リソースについてのローカルな注釈情報を含む事はオリジンサーバによって知らされる外部情報のスーパーセットとなるかもしれない。そのレスポンスが 200 (OK) とは別の方法で示したい場合、このレスポンスコードを使用する必要はないが、そのような場合にのみ適切である。
  204 | 204 No Content サーバはリクエストを受け入れたが、エンティティボディを送り返す必要は無く、更新された外部情報を返す事を望むだろう。レスポンスは、エンティティヘッダ形式の中に、新規あるいは更新された外部情報を含む事ができ、もしあればリクエストされたバリアントが関連付けられる べきである。 もしクライアントがユーザエージェントなら、リクエストの送信をもたらした状態からその文書画面{view} を変える べきではない。このレスポンスは主に、ユーザエージェントの現在の{active} 文書画面を変える事無く、動作を起こすための入力をさせる意図を持つが、どんな新規あるいは更新された外部情報もユーザエージェントの現在の画面中にある現在の文書に適用される べきである。 204 レスポンスは メッセージボディを含んではならないので、常にヘッダフィールドの後の最初の空行で終了する。
  205 | 205 Reset Content サーバはリクエストを受け入れたので、ユーザエージェントは送信されたリクエストをもたらした現在の画面をリセットすべきである。このレスポンスは主に、ユーザが別の入力動作を簡単に始められるように、入力が与えられたフォームをクリアして、ユーザの入力経由で動作を起こすための入力をさせる意図を持つ。レスポンスはエンティティを含ん ではならない。
  206 | 206 Partial Content サーバはリソースに対する部分的 GET リクエストを受け入れた。リクエストは、望む範囲を示すための Range ヘッダフィールドを含め なければならない し、またリクエストを条件付きにしたいければ If-Range ヘッダフィールドを含んだ方がよい。 レスポンスは、以下のヘッダフィールドを含め なければならない。 このレスポンスに含まれる範囲を示す Content-Range ヘッダフィールドか、それぞれの部分に Content-Range フィールドを含む multipart/byteranges という Content-Type のどちらか。このレスポンスにて Content-Length ヘッダフィールドが送られた場合、その値はメッセージボディで転送される OCTET の実際の数と一致し なければならない。 Date もしそのヘッダが、同じリクエストに対して 200 レスポンス を返すであろう場合は ETag, Content-Location のうち一つ以上 もしフィールド値が、同じバリアントのための以前のレスポンスで送られたものと異なるならば、Expires, Cache-Control, Vary のうち一つ以上 もし 206 レスポンスが、強いキャッシュバリディタを使った If-Range リクエストの結果ならば、レスポンスは他のエンティティヘッダを含める べきではない。もし、レスポンスが弱いバリディタを使った If-Range リクエストの結果がとしたら、レスポンスは他のエンティティヘッダを含め てはならない。これはキャッシュされたエンティティボディと更新されたエンティティヘッダとの不一致を避ける為である。そうで無ければ、レスポンスは同じリクエストに対して 200 (OK) レスポンスと共に返されたであろうすべてのエンティティヘッダを含め なければならない。 もし ETag か Last-Modified ヘッダが正確に一致しなければ、キャッシュは他の以前キャッシュされた要素と 206 レスポンスとを結びつけ てはならない。 Range や Content-Range ヘッダをサポートしていないキャッシュは、206 (Partial) レスポンスをキャッシュし てはならない。
  3xx class - Redirection このステータスコードのクラスは、リクエストを果たすためにはユーザエージェントによって更なる動作が行われる必要がある事を示す。二番目のリクエストで使われたメソッドが GET か HEAD である場合にのみ、ユーザとの相互動作無しに、ユーザエージェントによって要求された動作を実行する事ができる。リダイレクションループによって各々のリダイレクションはネットワーク渋滞を生み出す事になるので、クライアントは無限リダイレクションループを発見す べきである。
  300 | 300 Multiple Choices リクエストされたリソースは、表現セットの一つに対応し、各々が特有の場所にあり、エージェント駆動型ネゴシエーション情報が、ユーザ (あるいはユーザエージェント) が望む表現を選択でき、その位置にリクエストをリダイレクトできるように供給されている。 もし HEAD リクエストでなければ、レスポンスはエンティティにユーザかユーザエージェントが最も適切なものを選択するためのリソースの特徴と場所のリストを含む べきである。エンティティのフォーマットは、Content-Type ヘッダフィールドにて与えられるメディアタイプによって指定される。データフォーマットやユーザエージェントの能力に依存する事なので、最も適切な選択は自動的に行われる かもしれない。しかし、この仕様書ではそのような自動選択に対してどのような標準も定義しない。 サーバが選択された表現を持っているのであれば、Location フィールド内にその表現のための具体的な URI を含む べきである。ユーザエージェントは、自動リダイレクションのためにその Location フィールドの値を使うことが できる。このレスポンスは、別のものを示しているのでなければキャッシュ可能である。
  301 | 301 Moved Permanently リクエストされたリソースは新しい恒久的な URI に割り当てられたので、以降そのリソースへの参照は返された URI の一つを使用す べきである。リンク編集機能を持つクライアントは、可能であればサーバにより返された新しい参照の一つ以上の Request-URI を参照するように自動的に再リンクすべきである。このレスポンスは、別のものを示しているのでなければキャッシュ可能である。 新しい恒久的 URI は、レスポンス内の Location フィールドによって与えられる べきである。リクエストメソッドが HEAD でなければ、レスポンスのエンティティは新しい URI へのハイパーリンクを持った短いハイパーテキストの注釈を含む べきである。 もし 301 ステータスコードが GET や HEAD 以外のリクエストのレスポンスとして受信されたら、リクエストが発行された時点の条件から変わっているかもしれないため、ユーザエージェントはユーザに確認せずに、リクエストを自動的にリダイレクトし てはならない。
  302 | 302 Found リクエストされたリソースは、一時的に別の URI に属している。このリダイレクションは場合によって変更されるかもしれないので、クライアントは将来のリクエストではその Request-URI を使い続ける べきである。このレスポンスは Cache-Control か Expires のどちらかのヘッダフィールドによって期限が示されている場合にのみキャッシュ可能である。 一時的 URI は、レスポンス内の Location フィールドによって与えられるべきである。リクエストメソッドが HEAD でなければ、レスポンスのエンティティは新しい URI へのハイパーリンクを持った短いハイパーテキストの注釈を含む べきである。 もし 302 ステータスコードが GET や HEAD 以外のリクエストのレスポンスとして受信されたら、リクエストが発行された時点の条件から変わっているかもしれないため、ユーザエージェントはユーザに確認せずに、リクエストを自動的にリダイレクトし てはならない。
  303 | 303 See Other リクエストに対するレスポンスは別の URI の元から発見でき、このリソースを GET メソッドを使用して回収す べきである。このメソッドは、主にPOST によって活性化されるスクリプトの出力が選択されたリソースへユーザエージェントをリダイレクトできるようにするために存在する。新しい URI は元々リクエストされたリソースに対する代わりの参照ではない。303 レスポンスはキャッシュ可能し てはならない が、二番目の (リダイレクトされた) リクエストへのレスポンスはキャッシュ可能である。 異なる URI は、レスポンス内の Location フィールドによって与えられるべきである。リクエストメソッドが HEAD でなければ、レスポンスのエンティティは新しい URI へのハイパーリンクを持った短いハイパーテキストの注釈を含む べきである。
  304 | 304 Not Modified クライアントが条件付き GET リクエストを実行し、アクセスは許可されたがその文書は更新されていなかった場合、サーバはこのステータスコードもって応答す べきである。304 レスポンスはレスポンスボディを含ん ではならない ので、いつもヘッダフィールドの後の最初の空行で終了する。 レスポンスは以下のヘッダフィールドを含ま なければならない。 その省略が[RFC 2616] の section 14.18.1 によって要求されていなければ、Date 時計の無いオリジンサーバがこのルールに従っている場合、プロクシやクライアントは ([RFC 2068] の section 14.19 にて既に記されているように)受信した Date ヘッダを持たないいかなるレスポンスにも自身の Date を付け加える事で、キャッシュは正常に作動するであろう。 もしそのヘッダが、同じリクエストに対して 200 レスポンス を返すであろう場合は ETag, Content-Location のうち一つ以上 もしフィールド値が、同じバリアントのための以前のレスポンスで送られたものと異なるならば、Expires, Cache-Control, Vary のうち一つ以上 条件付き GET に、強いキャッシュバリディタを使う場合、レスポンスは他のエンティティヘッダを含める べきではない。そうでない (例えば条件付き GET が弱いバリディタを使う) 場合、レスポンスは他のエンティティヘッダを含め てはならない。これは、キャッシュされたエンティティボディと更新されたエンティティヘッダとの不一致を避ける為である。 304 レスポンスが現在キャッシュされていないエンティティを示すならば、キャッシュはレスポンスを無視し、条件なしのリクエストを反復しなければならない。 キャッシュが受信された 304 レスポンスをキャッシュエントリを更新するために使用する場合、キャッシュはレスポンスで与えられたあらゆる新しいフィールド値をも反映させるため、エントリを更新し なければならない。
  305 | 305 Use Proxy リクエストされたリソースは Location フィールドによって与えられるプロクシを通してアクセスされ なければならない。Location フィールドはプロクシの URI を与える。受信側はプロクシ経由で単一のリクエストを再送信する事を期待する。305 レスポンスはオリジンサーバによってのみ生成されなければならない。
  4xx class - Client Error ステータスコードの 4xx クラスは、クライアントが間違えているような場合を示す。HEAD リクエストへのレスポンスを除き、サーバはエラー状況が一時的か恒久的かに拘わらず、エラー状況の説明を含むエンティティを返すべきである。これらのステータスコードは、あらゆるリクエストメソッドに適用されうる。ユーザエージェントは、含まれるエンティティすべてをユーザに表示すべきである。 もしクライアントがデータを送信している最中ならば、TCP を使用しているサーバインプリメンテーションは、サーバが入力接続を切断する前に、レスポンスを含んでいるパケットの受領をクライアントが認識できる事を保証するために気を配る べきである。もし切断後にもクライアントがサーバにデータを送信し続けていたら、サーバの TCP スタックはクライアントにリセットパケットを送り、これによって、HTTP アプリケーションがリクエストを読み出して中間処理する前に、クライアントの認識されない入力バッファを消去するだろう。
  400 | 400 Bad Request リクエストは、不正なシンタックスのためサーバに理解されなかった。クライアントは、修正しないままでそのリクエストを再送信すべきではない。
  401 | 401 Unauthorized リクエストはユーザ認証を必要とする。レスポンスは、リクエストされたリソースに適用できる challenge を含む WWW-Authenticate ヘッダフィールド (section 14.47) を含まなければならない。クライアントは、適切な Authorization ヘッダフィールド (section 14.8) を伴うリクエストを繰り返す事ができる。もしリクエストがすでに Authorization credentials を含んでいるのであれば、この 401 レスポンスは認証がそれらの credentials に対して拒否された事を示す。もし 401 レスポンスが前のレスポンス時と同じ challenge を含み、ユーザエージェントが既に最低一回認証を試みているならば、そのエンティティに関連する診断情報を含んでいるであろうから、ユーザエージェントはレスポンスで与えられたエンティティを表示すべきである。 HTTP アクセス認証は、"HTTP Authentication: Basic and Digest Access Authentication" において説明されている。
  402 | 402 Payment Required このコードは、将来の使用のため予約されている。
  403 | 403 Forbidden サーバはリクエストを理解したが、それを実行する事を拒否した。認証は役に立たないであろうから、リクエストは繰り返されるべきではない。リクエストメソッドが HEAD で無い時に、サーバはなぜリクエストが実行されなかったかを公にしたいならば、エンティティにおいて拒否の理由を記すべきである。サーバはこの情報をクライアントに利用されたくないならば、ステータスコードとして 404 (Not Found) を代わりに使う事が出来る。
  404 | 404 Not Found リクエストラインに記述されたメソッドは、 Request-URI によって識別されるリソースに許可されていない。レスポンスは、リクエストされたリソースへ適用できるメソッドのリストを含む Allow ヘッダを含まなければならない。
  405 | 400 Method Not Allowed リクエストラインに記述されたメソッドは、 Request-URI によって識別されるリソースに許可されていない。レスポンスは、リクエストされたリソースへ適用できるメソッドのリストを含む Allow ヘッダを含まなければならない。
  406 | 400 Not Acceptable リクエストによって識別されるリソースは、リクエスト中に送られた Accept ヘッダによれば、受け入れられない内容特性を持つレスポンスエンティティを生成する事ができるのみである。 もし HEAD リクエストでなければ、レスポンスはエンティティにユーザかユーザエージェントが最も適切なものを選択するためのリソースの特徴と場所のリストを含むべきである。エンティティのフォーマットは、Content-Type ヘッダフィールドにて与えられるメディアタイプによって指定される。データフォーマットやユーザエージェントの能力に依存する事なので、最も適切な選択は自動的に行われるかもしれない。しかし、この仕様書ではそのような自動選択に対してどのような標準も定義しない。 注: HTTP/1.1 サーバは、リクエスト中に送られた Accept ヘッダによれば受け入れる事ができないとされるレスポンスを返す事を許されている。そのような場合、406 レスポンスを送る事が望ましい。ユーザエージェントは、もしそれを受け入れられるなら、それを決定するために送られてきたレスポンスのヘッダを詳しく調べる事が推奨される。 もしレスポンスが受け入れる事ができなければ、ユーザエージェントはそれ以上のデータの受信を一時的に中止し、それ以降の動作を決定するためユーザに尋ねるべきである。
  407 | 400 Proxy Authentication Required このコードは、401 (Unauthorized) と似ているが、クライアントが最初にプロクシに認証されなければならない事を示す。プロクシは、リクエストされたリソースのためのプロクシに適用できる challenge を含んだ Proxy-Authenticate ヘッダフィールド (section 14.33) を返さなければならない。クライアントは、適切な Proxy-Authorization ヘッダフィールド (section 14.34) を伴うリクエストを繰り返す事ができる。 HTTP アクセス認証は、"HTTP Authentication: Basic and Digest Access Authentication" [43] において説明されている。
  408 | 400 Request Timeout クライアントは、サーバの待ち時間内にリクエストを発行しなかった。クライアントは、それ以降に修正しないでリクエストを繰り返してもよい。
  409 | 409 Conflict リクエストは、リソースの現在の状態との矛盾のため完了できなかった。このコードは、ユーザが矛盾を解決し、リクエストを再提出できる事が期待できる状況のみに許される。レスポンスボディには、ユーザが矛盾の原因を認識するための十分な情報を含むべきである。理論的には、そのレスポンスエンティティはユーザやユーザエージェントが問題を修正するための十分な情報を含んでいるであろうが、実際それは不可能だろうしその必要もない。 矛盾は、PUT リクエストへのレスポンス時に最も発生しやすい。例えば、もしバージョン処理{versioning} が使用され、PUT されているエンティティが初期 (サードパーティ) のリクエストによって作られたものと矛盾しているリソースに変わるものを含んでいるならば、サーバはリクエストが完了できない事を示す 409 レスポンスを使用できる。この場合、レスポンスエンティティにはおそらく、レスポンスの Content-Type によって定義されるフォーマット中で二つのバージョンの違いについてのリストを含むであろう。
  410 | 410 Gone リクエストされたリソースは、もはやそのサーバでは利用できないし、転送先のアドレスも分からない。この状況は、恒久的なものとみなされるであろう。リンク編集機能を持つクライアントは、ユーザから承認を得た後にリクエスト URI の参照を削除すべきである。サーバがその状況が恒久的なものかどうかを、知らないか、あるいはそれを決定するための能力が無いのであれば、代わりにステータスコード 404 (Not Found) が使用されるべきである。別の方法が示されなければ、このレスポンスはキャッシュできる。 410 レスポンスは主に、リソースが故意に利用不可能であったり、サーバのオーナーがリソースへのリモートリンクを削除したい事を受信者に通知する事でウェブメンテナンスの作業を補助する意図を持つ。そのような事は、期間限定の宣伝サービスや、サーバのサイト内でもはや働いていない個人が所有していたリソースに対して一般的である。 "無くなった{gone}" ような恒久的に利用できないすべてのリソースをマークしたり、いつまでもそのマークを維持しておく必要はないが、これをいつ破棄するかはサーバオーナーの判断にまかされる。
  411 | 411 Length Required サーバは、定義された Content-Length の無いリクエストを受け入れる事を拒否した。リクエストメッセージにメッセージボディの長さを含んでいる妥当な Content-Length ヘッダフィールドを追加すれば、クライアントはリクエストを繰り返す事ができる。
  412 | 412 Precondition Failed 一つ以上のリクエストヘッダフィールドで与えられた前提条件は、それがサーバでテストされたときに偽であると評価された。このレスポンスコードはクライアントが現在のリソースの外部情報 (ヘッダフィールドデータ) を前提条件として置けるようにし、それによってリクエストされたメソッドを目的以外のリソースに適用されないようにする。
  413 | 413 Request Entity Too Long リクエストエンティティがサーバが想定、あるいは処理可能なものより大きいため、サーバはリクエストの処理を拒否している。サーバは、クライアントにリクエストを続けさせないため接続を閉じてよい。 もしその状態が一時的なものであれば、サーバはそれが一時的であるという事と、クライアントが再試行してもよい経過時間を示す Retry-After ヘッダフィールドを含むべきである。
  414 | 414 Request-URI Too Long サーバが中間処理をするために想定している Request-URI より長いため、サーバはリクエストのサービスを拒否している。このまれな状態は、クライアントが長いクエリ情報を伴った POST リクエストを GET リクエストに不適当に変換した時、クライアントがリダイレクションの URI "ブラックホール" (例えば、リダイレクトされた URI が自身の末尾を指すようなものを自身の前に置いてしまうような状態) に陥った時、あるいはサーバが Request-URI の読み出しや操作のために固定長バッファを使用しているいくつかのサーバに存在する当面のセキュリティホールを利用しようとしているクライアントからアタックを受けている時にのみ起こる傾向がある。
  415 | 415 Unsupported Media Type リクエストのエンティティは、リクエストされたメソッドに対してリクエストされたリソースがサポートしていないフォーマットであるため、サーバはリクエストのサービスを拒否している。
  5xx class - Server Error 数字 "5" で始まるレスポンスステータスコードは、サーバがエラー状態にあるか、リクエストを実行する能力が無いと気づいた場合を表す。 HEAD リクエストに応答する場合以外は、サーバはそのエラー状況と、それが一時的か恒久的なのかの説明を含むエンティティを返すべきである。ユーザエージェントは、ユーザに返されたあらゆるエンティティを表示すべきである。これらのレスポンスコードは、あらゆるリクエストメソッドにも適用できる。
  500 | 500 Internal Server Error サーバは、リクエストの実行を妨げる予測しない状態に遭遇した。
  501 | 501 Not Implemented サーバは、リクエストを実行するのに必要な機能をサポートしていない。これは、サーバがリクエストメソッドを認識できない時の適切なレスポンスであり、どんなリソースに対してもそれをサポートする能力がない。
  502 | 502 Bad Gateway ゲートウェイやプロクシとして動作しているようなサーバが、リクエストを実行しようと呼び出しているアップストリームサーバから不正なレスポンスを受け取った。
  503 | 503 Service Unavailable サーバは、一時的な過負荷かあるいはサーバのメンテナンスのため、現在リクエストを扱う事ができない。これは、いくらか遅延された後に軽減されるであろうという一時的な状態も含む。もし分かるなら、遅延時間の長さを Retry-After ヘッダで示す事ができる。もし Retry-After が与えられなければ、クライアントはそれを 500 レスポンスと同様に処理すべきである。 注: 503 ステータスコードの存在は、サーバが過負荷状態になった時には常にそれを使わなければならないという事を暗黙的に意味するものではない。単に接続の拒否を望むサーバもあるだろう。
  504 | 504 Gateway Timeout ゲートウェイやプロクシとして動作するサーバは、URI によって特定されるアップストリームサーバ (例えば HTTP, FTP, LDAP) や、リクエストを完了させようとするためにアクセスに必要な他の補助のサーバ (例えば DNS) から適時のレスポンスを受信しなかった。 注: 実装者向け: 設置されたプロクシの中には、DNSルックアップがタイムアウトした時に 400 あるいは 500 を返すものがあるという事が知られている。
  505 | 505 HTTP Version Not Supported サーバは、リクエストメッセージで使用された HTTP プロトコルバージョンをサポートしていない、あるいはサポートを拒否している。サーバは、このエラーメッセージ以外は、section 3.1 で表されるように、クライアントと同じメジャーバージョンを使用してリクエストを完了させる事は不可能、 あるいはそれを望んでいないという事を示している。レスポンスは、何故このバージョンがサポートされていないか、どんな別のプロトコルがこのサーバによってサポートされているかを記述したエンティティを含むべきである。

SMTP Status Codes
  メールサーバは、SMTPステータスコードを返して、発信/受信メールの状態を示します。ステータスコードはログファイルを分析するのに使用されるメールサーバとプリプロセッサによります。
  失敗コードであるすべてのコードは、AWStatsコンフィグファイルのShowSMTPErrorsStatsデイレクティブで有効にされたSMTPステータスレポートチャートに隔離されます。ValidSMTPCodesディレクティブにより、どのコードがこのチャートに載るべきでない成功したメール転送であるかを決めることができます。
  ほとんどのメールサーバが報告する値を示します(また、メールログファイルがmaillogconvert.plの前処理の結果であることもあります)。
  SMTPコードは3つのカテゴリで分類されます:
  - 2xx/3xx - successful
  - 4xx - failure, asking sender to try later
  - 5xx - permanent failure

  2xx/3xx class - Success DSNが、配送アクションにおいて肯定（positive）を返したときを成功とする。詳細のサブコードは、配送に必要とされた変形についての情報を与えるかも知れない。
  200 | 200 Non standard success response 正しくない応答コード
  211 | 211 System status, or system help reply システムの状態、またはシステムヘルプの応答
  214 | 214 Help message そのサーバで使えるコマンドに関するヘルプが返されるときに使われる。
  220 | 220 <domain> Service ready TCP/IP的にSMTPコネクションが確立したときに使われる。ドメイン名をともなう。
  221 | 221 <domain> Service closing transmission channel SMTPの転送チャネルを閉じるときに使われる。つまり、QUITに対する応答。ドメイン名をともなう。
  250 | 250 Requested mail action taken and completed SMTPコマンドに対する成功の応答コード。
  251 | 251 User not local: will forward to <forward-path> そのユーザあてのメールが転送されるときに使われる。
  252 | 252 Recipient cannot be verified 確認しようとしたユーザは、実はこのサーバでは確認できないが、そのユーザあてのメールはとりあえず転送はする。
  354 | 354 Start mail input and end with <CRLF>. メールサーバはメッセージを受信する準備ができた。または、メッセージヘッダを受信後にメッセージ本体を送るように指示する。
  4xx class - Temporary Errors 持続性の一時的な失敗は、送られたメッセージは有効だったが、メッセージを送ることを成功させることを、一時的なイベントが妨げたような状況である。将来送れば成功するかもしれない。
  421 | 421 <domain> Service not available, closing transmission channel サーバのがShutdownされたときなどに発生する。
  450 | 450 Requested mail action not taken: mailbox busy or access denied メールボックスがないかビジーである。送信中にネットワーク接続が切断されたり、メールサーバーが(IPアドレス、送信元アドレス、あて先など)なんらかの理由で受信を拒否した。
  451 | 451 Requested mail action aborted: error in processing データを処理しているときにエラーになった。主としてサーバ側に原因があることが多い。
  452 | 452 Requested mail action not taken: insufficient system storage システムのディスクがたりない。
  453 | 453 Too many messages ODMRで、サーバ(プロバイダ)がそのサイトあて のメールをもっていないことを示す。
  5xx class - Permanent Errors 恒久的な失敗は、現在の形ではメッセージを再送することが解決しそうにないことである。配送を成功させるには、メッセージや送り先へのいくらかの変更が必要である。
  500 | 500 Syntax error, command unrecognized or command line too long 一般的な構文エラー。コマンド名が違うときに使われる。また、入力行が長すぎるときにもこれを使う。
  501 | 501 Syntax error in parameters or arguments パラメータや引数が構文的におかしいときに使う。内容に問題があるときには 504などが使われる。
  502 | 502 Command not implemented そのコマンドは実装されていない。コマンドそのものは知っているが、それを実装していない(あるいは、それを使えなくしている)ときに利用される。
  503 | 503 Server encountered bad sequence of commands 例えば、RCPTコマンドより前にDATAコマンドが使われた、のように、コマンドの順序が正しくないときに利用される。
  504 | 504 Command parameter not implemented あるコマンドで使われたパラメータやオプションが使えない。例えば「MAIL foo@bar.com BY=600」などとされた時、MAILコマンドそのものは実装されているがDELIVERBYが実装されていないとこのエラーとなる。
  521 | 521 <domain> does not accept mail or closing transmission channel メールを(特定のものであれ、一般にであれ)受けとらないことを示す応答コー ドで、RFC 1846に規定される。 ただし、 RFC 2821によれば、常にメールを受けとらないホストは554応答を、ポリシー上の理由で特定のメールを受けとらないホストは550応答をそれぞれ使うよう指示されているので、521を用いる場面はほとんどないものと思われる。
  530 | 530 Access denied 何らかの理由(ファイルパーミッションなど)でアクセスが拒否された。 Authenticationを利用しているとき、この応答はAUTH, EHLO, HELO, NOOP, RSET, QUIT以外のいかなるコマンドに対しても返され、サーバポリシーにより、要求されたアクションをするためには認証が必要であることを示す。
  550 | 550 Requested mail action not taken (Relaying not allowed, Unknown recipient user, ...) メールボックスが見つからない、アクセスできない、ポリシー上の理由でコマンドが拒否されたなど(リレー拒否もこれになる)。
  551 | 551 User not local: please try <forward-path> or Invalid Address: Relay request denied 251と同様、転送先に関する情報で、このサーバでは情報が得られないことと、転送先に関する情報を示す。
  552 | 552 Requested mail action aborted: exceeded storage allocation ストレージの割りあてが上回った。メッセージが長すぎる時などに使われる。
  553 | 553 Requested mail action not taken: mailbox name not allowed メールボックスの構文が不正であるときなどに用いられる。
  554 | 554 Requested mail action rejected: access denied 何らかの理由でトランザクションに問題が生じたことを示す。また、コネクション開始時の応答の場合には、ここにSMTPサービスが存在しないことを示す。
  557 | 557 Too many duplicate messages リソースは一時的に使用できない。(恐らく)なんらかのスパム対策に拒否された。

Article written by " rel="author" style="color: #ccc; font-weight: normal;">Laurent Destailleur.
Follow @awstats_project