|
ログ解析スクリプトAWStats 7.7ドキュメント |
お気に入りへの追加数 = round((x+y) / r)
ここで、|
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のより新しいバージョンに変更するという事は、古いバージョン以上に有益だし、リアルタイムに、同期するプロトコルを変更する事はそのような機能を使うリソースを配布するときに都合が良いだろう。 |
|
|
このステータスコードのクラスは、クライアントのリクエストがうまく受信され、理解され、そして受け入れられた事を示す。 | ||
| 200 | 200 Successful
リクエストは成功した。レスポンスと共に返される情報はリクエストに使用されたメソッドに依存し、例えば以下の様になる。
|
|
| 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 ヘッダフィールドを含んだ方がよい。 レスポンスは、以下のヘッダフィールドを含め なければならない。
もし 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 レスポンスはレスポンスボディを含ん ではならない ので、いつもヘッダフィールドの後の最初の空行で終了する。 レスポンスは以下のヘッダフィールドを含ま なければならない。
条件付き 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 で表されるように、クライアントと同じメジャーバージョンを使用してリクエストを完了させる事は不可能、 あるいはそれを望んでいないという事を示している。レスポンスは、何故このバージョンがサポートされていないか、どんな別のプロトコルがこのサーバによってサポートされているかを記述したエンティティを含むべきである。 |
|
|
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
リソースは一時的に使用できない。(恐らく)なんらかのスパム対策に拒否された。 |