08:00:00ツイート印刷コメントを書く10:HTTP/1.1のさまざまなエラーコードを理解する。クライアントやサーバログに残っているHTTPエラーは、正しい方向を示してくれる場合がある。ユーザーがサイトに訪れるリンクをクリックしても、いつも「404」エラーばかりだと文句を言っていれば、Apacheサーバ上のページを指すリンクは存在していない。クライアントが「501」エラーを受け取っていれば、そのクライアントはサーバにハンドラーが存在しないコンテンツにアクセスしようとしている。このエラーはCGIスクリプトに問題がある場合に起きることがある。表Cに、HTTPエラーメッセージを首尾一貫したものに保つ責任を負う団体であるW3Cから(許可をもらって)得た情報を、フォーマットを変えて若干読みやすくし、無関係な情報を除いたものを掲載した。応答で返された情報は要求で使われたメソッドによって異なる。応答では要求されたリソースに対応するエンティティが送られる。応答では要求されたリソースに対応するエンティティのヘッダフィールドがメッセージボディなしで送られる。動作の結果を説明あるいは保持するエンティティが送られる。エンドサーバーで受信した要求メッセージを保持したエンティティが送られる。要求は実行され、その結果新しいリソースが作成された。新規に作成されたリソースは応答のエンティティで返されたURIから参照でき、このリソースのもっとも具体的なURIはLocationヘッダフィールドで与えられる。応答には、ユーザーやユーザーエージェントがもっとも適切なものを選択できるよう、リソースの性質と場所のリストを含むエンティティが含まれるべき(SHOULD)である。エンティティのフォーマットはContent-Typeヘッダフィールドで与えられるメディアタイプで指定される。発信元サーバーは、ステータスコード201を返す前にこのリソースを作成しなくてはならない(MUST)。この処理が直ちに実行できない場合は、サーバは代わりに202(Accepted)応答を返すべき(SHOULD)である。要求は処理のために受理されたが、処理はまだ終了していない。要求は処理される可能性も、処理されない可能性もあり、実際に処理が行われる時点で許可されない可能性がある。このような非同期な処理から、ステータスコードを再送する手段はない。202応答が保証をしないのは意図的なものである。その目的は、処理が完了するまでユーザーエージェントのサーバに対する接続を維持する必要なしに、サーバが何らかの処理(1日に1度だけ実行されるバッチ指向の処理かもしれない)のための要求を受け付けることだ。応答で返されたエンティティには、応答の現在の状態を示す情報と、状態モニタへのポインタか、ユーザーがこの要求がいつ実行されると期待できるかという見積もりが含まれているべき(SHOULD)である。エンティティヘッダで返されたメタ情報は、発信元サーバから提供される確実なセットではなく、ローカルあるいは第三者のコピーから集められたものである。このセットは元のバージョンの部分集合あるいは上位集合である場合がある(MAY)。リソースに関するローカルの注釈情報が含まれていれば、発信元サーバーが知っているメタ情報の上位集合になる場合がある。この応答コードを使うことは必須ではなく、これを返すのでなければ200(OK)を返す場合にのみ適切なものである。サーバーは要求を実行したが、エンティティボディを返す必要がなく、更新されたメタ情報を返したい場合がある。応答には新規の、あるいは更新されたメタ情報がエンティティヘッダの形で含まれている場合があり(MAY)、もしこれが存在する場合には要求されたバリアントと関連づけられるべき(SHOULD)である。この応答は主にユーザーエージェントのドキュメント表示を変更せずに変更を引き起こすような入力を行うために設けられたものだが、新しい、あるいは更新されたメタ情報は、ユーザーエージェントのドキュメント表示に適用されるべき(SHOULD)である。NOT)、従って常にヘッダフィールドに続く最初の空行で終了する。サーバーは要求を実行し、ユーザーエージェントはこの要求の送信を引き起こしたドキュメント表示をリセットすべき(SHOULD)である。この応答は、主としてユーザーの入力によって入力を行い、その後入力が行われたフォームを空にすることで、ユーザーが次の入力を開始しやすくするためのものである。サーバはリソースのための部分的なGET要求を実行した。要求には望んでいる範囲を示すRangeヘッダフィールドが含まれていなくてはならず(MUST)、条件付き要求を行うためのIf-Rangeヘッダフィールドを含んでいてもよい(MAY)。一連の表現の1つに対応する要求されたリソースが、その中からユーザー(あるいはユーザーエージェント)が望ましい表現を選択し、その表現の場所へリダイレクトできるよう、それぞれ表現の特定の場所とエージェントが行うネゴシエーション情報を伴って提供される。要求されたリソースは、新しい恒久的なURIを付与され、このリソースに対する将来的な参照は、返されたURIの1つを使って行われるべきである(SHOULD)。リンク編集機能を持ったクライアントは、可能な場合には自動的にサーバから返された新しい参照情報のうち1つ以上を使って、Request-URIへの参照を自動的に再リンクすべきである。この応答は、特に指定されていない限りキャッシュしてよい。新しい恒久的なURIは応答のLocationフィールドで与えられるべき(SHOULD)である。要求メソッドがHEADでない限り、応答のエンティティは新しいURIへのハイパーリンクを伴ったハイパーテキストによる短い注記であるべき(SHOULD)である。要求されたリソースは一時的に異なるURIにある。リダイレクションは時々変更される場合があるため、クライアントは将来の要求でもRequest-URIを使い続けるべき(SHOULD)である。この応答は、Cache-ContorolヘッダフィールドかExpiresヘッダフィールドで明示されている場合にのみキャッシュしてよい。この要求への応答は異なるURIで見いだすことができ、そのリソースをGETメソッドを使って読み出すべき(SHOULD)である。このメソッドは、主としてPOSTによって実行されたスクリプトの出力がユーザーエージェントを、選択されたリソースにリダイレクトするために存在している。新しいURIは元々要求されたリソースの代わりとなる参照情報ではない。NOT)が、2番目の(リダイレクトされた)応答はキャッシュしてもよい場合がある。クライアントが条件付きGET要求を実行し、アクセスが許可されたがドキュメントは変更されていない場合、サーバーはこのステータスコードで応答すべき(SHOULD)である。NOT)、従って常にヘッダフィールドに続く最初の空行で終了する。要求されたリソースはLocationフィールドで与えられたプロクシを通じてアクセスされなくてはならない(MUST)。LocationフィールドにはプロクシのURIが記述される。受信側にはこの要求をプロクシ経由で繰り返すことが期待される。305応答を生成するのは、発信元サーバのみでなくてはならない(MUST)。要求されたリソースは一時的に異なるURIにある。リダイレクションは時々変更される場合がある(MAY)ため、クライアントは将来の要求でもRequest-URIを使い続けるべき(SHOULD)である。この応答は、Cache-ContorolヘッダフィールドかExpiresヘッダフィールドで明示されている場合にのみキャッシュしてよい。構文が正しくないため、サーバは要求を理解できなかった。要求にはユーザー認証が必要である。応答には要求されたリソースに当てはまるチャレンジを含むWWW-Authenticateヘッダフィールドが含まれていなくてはならない(MUST)。クライアントは適切なAuthorizationヘッダフィールドを伴う要求を再送してよい(MAY)。要求にすでにAuthoraizationのクレデンシャルが含まれている場合、401応答はそれらのクレデンシャルに対する認証が拒否されたことを示す。401応答が前回の応答と同じチャレンジを含んでおり、ユーザーエージェントは少なくとも1度は認証を試みている場合、ユーザーには応答で与えられたエンティティが示されるべき(SHOULD)である。これは、そのエンティティに必要な診断情報が含まれている可能性があるためだ。Authentication"で説明されている。サーバーは要求を理解したが、それを実行することを拒否している。要求のメソッドがHEADではなく、サーバーがなぜこの要求が実行されないのかを明らかにしたい場合は、サーバは拒否の理由をエンティティの中に記述すべき(SHOULD)である。Found)を使うことができる。サーバーはRequest-URIに一致するものを発見できなかった。この状態が一時的なものか恒久的なものかという情報は与えられない。410(Gone)のステータスコードは、サーバーが何らかの内部的な設定メカニズムによって、古いリソースは恒久的に利用できず、転送のためのアドレスも持たないことを知っている場合に使われるべき(SHOULD)である。このステータスコードは、サーバーがなぜ要求を拒否したかを明らかにしたくない場合や、他の応答が適用できない場合にも共通して使われる。Request-URIで指定されたリソースに対しては、Request-Lineで指定されたメソッドが許可されていない。この応答には、要求されたリソースに対する有効なメソッドのリストを含むAllowヘッダが含まれていなくてはならない(MUST)。送られた要求のAcceptヘッダによれば、要求で指定されたリソースは、受信側が受け入れられない性質のコンテンツを持つ応答エンティティしか生成できない。このコードは401(Unauthorized)と似ているが、クライアントがまずプロクシに対して自分自身を認証しなくてはならない(MUST)ということを示している。プロクシは要求されたリソースへのプロクシに適したチャレンジを含むProxy-Authenticateヘッダフィールドを返さなくてはならない(MUST)。クライアントは適切なProxy-Auhtenticationヘッダフィールドを持つ要求を再送してよい(MAY)。クライアントはサーバーが待つ用意をしていた時間内に要求を生成しなかった。クライアントはそれ以降いつでも修正をせずに要求を再送してもよい(MAY)。リソースの現在の状態と衝突するため、要求を完了することができない。このコードは、ユーザーがこの衝突を解消し、要求を再送信できる可能性があると期待される状況にのみ使うことが許されている。応答の本文には、ユーザーが衝突の原因を認識するのに十分な情報が含まれているべき(SHOULD)である。応答エンティティにはユーザーあるいはユーザーエージェントが問題を解決できるだけの情報が含まれているのが理想的だが、これは不可能かもしれず、必要条件でもない。衝突はPUT要求の場合に起こる可能性が高い。バージョン管理が行われており、エンティティが以前(第三者に)行われた要求と衝突するリソースへの修正の要求を含むPUTである場合、サーバーは409応答を使って、要求が完了できないことを示す場合がある。この場合、応答エンティティには応答のContent-Typeで定義された形式による、2つのバージョンの差分のリストが含まれているだろう。要求されたリソースはそのサーバーではもう提供されておらず、転送アドレスも不明である。この状態は恒久的なものだと考えられている。リンク編集機能を持つクライアントは、ユーザーの許可を得てRequest-URIへの参照を削除すべき(SHOULD)である。Found)が使われるべき(SHOULD)である。この応答は、特に指定されていなければキャッシュしてよい。410応答は主として、リソースが意図的に提供されておらず、サーバーの所有者ががそのリソースに対する遠隔からのリンクを削除したい場合に受信者にそれを知らせることによって、ウェブのメンテナンス作業を支援することを意図されている。このようなことは、時間が限られている広告的なサービスや、そのサーバーのサイトにはもう働いていない個人に属するリソースなどの場合によく起こる。恒久的に利用できなくなった資源すべてに「Gone」の印を使う必要はなく、この印を長期間保持する必要もない。これらはサーバー所有者の判断に任されている。サーバーはContent-Lengthが定義されていない要求を受け取るのを拒否している。クライアントは要求メッセージのメッセージボディの長さを含む有効なContent-Lengthヘッダフィールドを追加すれば、その要求を再送してよい(MAY)。1つ以上の要求のヘッダフィールドで与えられた前提条件がサーバーで検証された結果成立しないと評価された。この応答コードは、クライアントが現在のリソースのメタ情報(ヘッダフィールドのデータ)に前提条件を持たせ、意図したもの以外のリソースに要求されたメソッドが適用されることを防ぐことを可能にする。要求エンティティがサーバーが処理する用意がない、あるいは処理できない大きさであるため、サーバーは要求の処理を拒否している。サーバーは接続を閉じ、クライアントから要求が送られ続けるのを防いでよい(MAY)。Request-URIがそのサーバーが処理する用意がある長さよりも長いため、サーバーが要求に応えるのを拒否している。この稀な状況が起こるのは、長いクエリー情報を持つPOST要求を不適切にGET要求に変換した場合や、クライアントがリダイレクションの「ブラックホール」となっているURIに引き込まれた場合(例えばリダイレクトされたURIプレフィックスが、それ自身のサフィックスを指している場合など)、あるいはRequest-URIの読み込みや操作に固定長のバッファを使っている一部のサーバにあるセキュリティホールを悪用しようとするクライアントによって、サーバーが攻撃を受けている場合だけだろう。要求のエンティティが要求されたメソッドの要求されたリソースがサポートしていない形式を取っているため、サーバーがサービス要求に応えることを拒否している。要求にRange要求ヘッダフィールドが含まれており、このフォールドの範囲指示子に現在の選択されたリソースの範囲と重なるものがなく、要求にIf-Range要求ヘッダフィールドが含まれていない場合、サーバはこのステータスコードを返すべき(SHOULD)である。(byte-rangesについては、これはすべてのbyte-range-specの最初のbyte-posの値が現在の選択されたリソースの長さよりも大きい場合を意味する。Expect要求ヘッダフィールドで与えられた期待値をこのサーバーによって満たすことができなかったか、もしこのサーバーがプロクシである場合、サーバーがその要求が次ホップサーバによって達成できないという確実な証拠を持っている。サーバが要求を実行することができない想定外の状態に遭遇した。サーバーが要求を実行するのに必要な機能をサポートしていない。これは、サーバーが要求メソッドを認識しておらず、リソースの提供のためにそのメソッドをサポートできない場合には適切な応答となる。サーバーがゲートウェイかプロクシとして振る舞っており、要求を実行しようとして上流のサーバーにアクセスして、無効な応答を受け取った。一時的な過負荷あるいはサーバーのメンテナンスにより、現在サーバーが要求を処理することができない。ここではこの状態が一定時間の後に緩和される一時的な状態であることを意味している。遅れの時間がわかっている場合には、その時間をRetry-Afterヘッダで示してもよい(MAY)。Retry-Afterが与えられていない場合には、クライアントはステータスコード500を受け取ったものとして処理すべき(SHOULD)である。サーバーがゲートウェイかプロクシとして振る舞っており、URI(例えばHTTP、FTP、LDAP)や、その要求の完了のためにアクセスする必要のあるその他の補助サーバー(例えばDNS)によって指定された上流サーバーから、時間内に応答を受け取らなかった。サーバーは、要求メッセージで使われているHTTPプロトコルバージョンをサポートしていないか、サポートすることを拒否している。これは、このエラーメッセージで示されているバージョン以外の、クライアントと同じメジャーバージョンを使った要求をこのサーバーが完了することは、不可能であるか望んでいないことを示している。応答にはなぜこのバージョンがサポートされておらず、このサーバで他にどんなプロトコルがサポートされているかを説明するエンティティが含まれるべき(SHOULD)である。許可を受けてhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlから使った。まとめこれらの10のヒントで、読者の問題はすべて解決しただろうか。解決しないだろうが、これらのヒントは読者を問題解決への正しい方向を指し示すようにデザインされている。読者のApacheのトラブルシューティングのヒントを、この記事の将来のバージョンのためにコメントなどで教えて欲しい。Networks発のニュースをシーネットネットワークスジャパン編集部が日本向けに編集したものです。permission.×このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。