Apacheのトラブルを解決する10のヒント
文:Scott Lowe(TechRepublic)
翻訳校正:石橋啓一郎
翻訳校正:石橋啓一郎
2008/01/24 08:00
Apacheの良くある問題を解決するための10のヒントをお教えしよう。
10:HTTP/1.1のさまざまなエラーコードを理解する。
クライアントやサーバログに残っているHTTPエラーは、正しい方向を示してくれる場合がある。例えば、ユーザーがサイトに訪れるリンクをクリックしても、いつも「404」エラーばかりだと文句を言っていれば、Apacheサーバ上のページを指すリンクは存在していない。あるいは、もしクライアントが「501」エラーを受け取っていれば、そのクライアントはサーバにハンドラーが存在しないコンテンツにアクセスしようとしている。このエラーはCGIスクリプトに問題がある場合に起きることがある。
表Cに、HTTPエラーメッセージを首尾一貫したものに保つ責任を負う団体であるW3Cから(許可をもらって)得た情報を、フォーマットを変えて若干読みやすくし、無関係な情報を除いたものを掲載した。
表C| 200 | OK | 要求は成功した。応答で返された情報は要求で使われたメソッドによって異なる。例えば、GET - 応答では要求されたリソースに対応するエンティティが送られる。HEAD - 応答では要求されたリソースに対応するエンティティのヘッダフィールドがメッセージボディなしで送られる。POST - 動作の結果を説明あるいは保持するエンティティが送られる。TRACE - エンドサーバーで受信した要求メッセージを保持したエンティティが送られる。 |
| 201 | Created | 要求は実行され、その結果新しいリソースが作成された。新規に作成されたリソースは応答のエンティティで返されたURIから参照でき、このリソースのもっとも具体的なURIはLocationヘッダフィールドで与えられる。応答には、ユーザーやユーザーエージェントがもっとも適切なものを選択できるよう、リソースの性質と場所のリストを含むエンティティが含まれるべき(SHOULD)である。エンティティのフォーマットはContent-Typeヘッダフィールドで与えられるメディアタイプで指定される。発信元サーバーは、ステータスコード201を返す前にこのリソースを作成しなくてはならない(MUST)。この処理が直ちに実行できない場合は、サーバは代わりに202(Accepted)応答を返すべき(SHOULD)である。 |
| 202 | Accepted | 要求は処理のために受理されたが、処理はまだ終了していない。要求は処理される可能性も、処理されない可能性もあり、実際に処理が行われる時点で許可されない可能性がある。このような非同期な処理から、ステータスコードを再送する手段はない。202応答が保証をしないのは意図的なものである。その目的は、処理が完了するまでユーザーエージェントのサーバに対する接続を維持する必要なしに、サーバが何らかの処理(1日に1度だけ実行されるバッチ指向の処理かもしれない)のための要求を受け付けることだ。応答で返されたエンティティには、応答の現在の状態を示す情報と、状態モニタへのポインタか、ユーザーがこの要求がいつ実行されると期待できるかという見積もりが含まれているべき(SHOULD)である。 |
| 203 | Non-Authoritative Information | エンティティヘッダで返されたメタ情報は、発信元サーバから提供される確実なセットではなく、ローカルあるいは第三者のコピーから集められたものである。このセットは元のバージョンの部分集合あるいは上位集合である場合がある(MAY)。例えば、リソースに関するローカルの注釈情報が含まれていれば、発信元サーバーが知っているメタ情報の上位集合になる場合がある。この応答コードを使うことは必須ではなく、これを返すのでなければ200(OK)を返す場合にのみ適切なものである。 |
| 204 | No Content | サーバーは要求を実行したが、エンティティボディを返す必要がなく、更新されたメタ情報を返したい場合がある。応答には新規の、あるいは更新されたメタ情報がエンティティヘッダの形で含まれている場合があり(MAY)、もしこれが存在する場合には要求されたバリアントと関連づけられるべき(SHOULD)である。もしクライアントがユーザーエージェントであれば、要求の送信を引き起こしたドキュメント表示を変えるべきではない(SHOULD NOT)。この応答は主にユーザーエージェントのドキュメント表示を変更せずに変更を引き起こすような入力を行うために設けられたものだが、新しい、あるいは更新されたメタ情報は、ユーザーエージェントのドキュメント表示に適用されるべき(SHOULD)である。204応答にはメッセージボディを含んではならず(MUST NOT)、従って常にヘッダフィールドに続く最初の空行で終了する。 |
| 205 | Reset Content | サーバーは要求を実行し、ユーザーエージェントはこの要求の送信を引き起こしたドキュメント表示をリセットすべき(SHOULD)である。この応答は、主としてユーザーの入力によって入力を行い、その後入力が行われたフォームを空にすることで、ユーザーが次の入力を開始しやすくするためのものである。この応答はエンティティを含んではならない(MUST NOT)。 |
| 206 | Partial Content | サーバはリソースのための部分的なGET要求を実行した。要求には望んでいる範囲を示すRangeヘッダフィールドが含まれていなくてはならず(MUST)、条件付き要求を行うためのIf-Rangeヘッダフィールドを含んでいてもよい(MAY)。 |
| 300 | Multiple Choices | 一連の表現の1つに対応する要求されたリソースが、その中からユーザー(あるいはユーザーエージェント)が望ましい表現を選択し、その表現の場所へリダイレクトできるよう、それぞれ表現の特定の場所とエージェントが行うネゴシエーション情報を伴って提供される。 |
| 301 | Moved Permanently | 要求されたリソースは、新しい恒久的なURIを付与され、このリソースに対する将来的な参照は、返されたURIの1つを使って行われるべきである(SHOULD)。リンク編集機能を持ったクライアントは、可能な場合には自動的にサーバから返された新しい参照情報のうち1つ以上を使って、Request-URIへの参照を自動的に再リンクすべきである。この応答は、特に指定されていない限りキャッシュしてよい。新しい恒久的なURIは応答のLocationフィールドで与えられるべき(SHOULD)である。要求メソッドがHEADでない限り、応答のエンティティは新しいURIへのハイパーリンクを伴ったハイパーテキストによる短い注記であるべき(SHOULD)である。 |
| 302 | Found | 要求されたリソースは一時的に異なるURIにある。リダイレクションは時々変更される場合があるため、クライアントは将来の要求でもRequest-URIを使い続けるべき(SHOULD)である。この応答は、Cache-ContorolヘッダフィールドかExpiresヘッダフィールドで明示されている場合にのみキャッシュしてよい。 |
| 303 | See Other | この要求への応答は異なるURIで見いだすことができ、そのリソースをGETメソッドを使って読み出すべき(SHOULD)である。このメソッドは、主としてPOSTによって実行されたスクリプトの出力がユーザーエージェントを、選択されたリソースにリダイレクトするために存在している。新しいURIは元々要求されたリソースの代わりとなる参照情報ではない。303応答はキャッシュしてはならない(MUST NOT)が、2番目の(リダイレクトされた)応答はキャッシュしてもよい場合がある。 |
| 304 | Not Modified | クライアントが条件付きGET要求を実行し、アクセスが許可されたがドキュメントは変更されていない場合、サーバーはこのステータスコードで応答すべき(SHOULD)である。304応答はメッセージボディを含んではならず(MUST NOT)、従って常にヘッダフィールドに続く最初の空行で終了する。 |
| 305 | Use Proxy | 要求されたリソースはLocationフィールドで与えられたプロクシを通じてアクセスされなくてはならない(MUST)。LocationフィールドにはプロクシのURIが記述される。受信側にはこの要求をプロクシ経由で繰り返すことが期待される。305応答を生成するのは、発信元サーバのみでなくてはならない(MUST)。 |
| 307 | Temporary Redirect | 要求されたリソースは一時的に異なるURIにある。リダイレクションは時々変更される場合がある(MAY)ため、クライアントは将来の要求でもRequest-URIを使い続けるべき(SHOULD)である。この応答は、Cache-ContorolヘッダフィールドかExpiresヘッダフィールドで明示されている場合にのみキャッシュしてよい。 |
| 400 | Bad Request | 構文が正しくないため、サーバは要求を理解できなかった。クライアントは修正なしにこの要求を繰り返すべきではない(SHOULD NOT)。 |
| 401 | Unauthorized | 要求にはユーザー認証が必要である。応答には要求されたリソースに当てはまるチャレンジを含むWWW-Authenticateヘッダフィールドが含まれていなくてはならない(MUST)。クライアントは適切なAuthorizationヘッダフィールドを伴う要求を再送してよい(MAY)。要求にすでにAuthoraizationのクレデンシャルが含まれている場合、401応答はそれらのクレデンシャルに対する認証が拒否されたことを示す。もし401応答が前回の応答と同じチャレンジを含んでおり、ユーザーエージェントは少なくとも1度は認証を試みている場合、ユーザーには応答で与えられたエンティティが示されるべき(SHOULD)である。これは、そのエンティティに必要な診断情報が含まれている可能性があるためだ。HTTPアクセス認証については、"HTTP Authentication: Basic and Digest Access Authentication"で説明されている。[43] |
| 403 | Forbidden | サーバーは要求を理解したが、それを実行することを拒否している。認証を行っても役に立たず、要求は再送されるべきではない(SHOULD NOT)。要求のメソッドがHEADではなく、サーバーがなぜこの要求が実行されないのかを明らかにしたい場合は、サーバは拒否の理由をエンティティの中に記述すべき(SHOULD)である。サーバーがこの情報をクライアントに開示したくない場合には、代わりに404(Not Found)を使うことができる。 |
| 404 | Not Found | サーバーはRequest-URIに一致するものを発見できなかった。この状態が一時的なものか恒久的なものかという情報は与えられない。410(Gone)のステータスコードは、サーバーが何らかの内部的な設定メカニズムによって、古いリソースは恒久的に利用できず、転送のためのアドレスも持たないことを知っている場合に使われるべき(SHOULD)である。このステータスコードは、サーバーがなぜ要求を拒否したかを明らかにしたくない場合や、他の応答が適用できない場合にも共通して使われる。 |
| 405 | Method Not Allowed | Request-URIで指定されたリソースに対しては、Request-Lineで指定されたメソッドが許可されていない。この応答には、要求されたリソースに対する有効なメソッドのリストを含むAllowヘッダが含まれていなくてはならない(MUST)。 |
| 406 | Not Acceptable | 送られた要求のAcceptヘッダによれば、要求で指定されたリソースは、受信側が受け入れられない性質のコンテンツを持つ応答エンティティしか生成できない。 |
| 407 | Proxy Authentication Required | このコードは401(Unauthorized)と似ているが、クライアントがまずプロクシに対して自分自身を認証しなくてはならない(MUST)ということを示している。プロクシは要求されたリソースへのプロクシに適したチャレンジを含むProxy-Authenticateヘッダフィールドを返さなくてはならない(MUST)。クライアントは適切なProxy-Auhtenticationヘッダフィールドを持つ要求を再送してよい(MAY)。 |
| 408 | Request Timeout | クライアントはサーバーが待つ用意をしていた時間内に要求を生成しなかった。クライアントはそれ以降いつでも修正をせずに要求を再送してもよい(MAY)。 |
| 409 | Conflict | リソースの現在の状態と衝突するため、要求を完了することができない。このコードは、ユーザーがこの衝突を解消し、要求を再送信できる可能性があると期待される状況にのみ使うことが許されている。応答の本文には、ユーザーが衝突の原因を認識するのに十分な情報が含まれているべき(SHOULD)である。応答エンティティにはユーザーあるいはユーザーエージェントが問題を解決できるだけの情報が含まれているのが理想的だが、これは不可能かもしれず、必要条件でもない。衝突はPUT要求の場合に起こる可能性が高い。例えば、バージョン管理が行われており、エンティティが以前(第三者に)行われた要求と衝突するリソースへの修正の要求を含むPUTである場合、サーバーは409応答を使って、要求が完了できないことを示す場合がある。この場合、応答エンティティには応答のContent-Typeで定義された形式による、2つのバージョンの差分のリストが含まれているだろう。 |
| 410 | Gone | 要求されたリソースはそのサーバーではもう提供されておらず、転送アドレスも不明である。この状態は恒久的なものだと考えられている。リンク編集機能を持つクライアントは、ユーザーの許可を得てRequest-URIへの参照を削除すべき(SHOULD)である。この状態が恒久的なものかどうかをサーバーが知らないか、判断する手段がない場合、代わりにステータスコード404(Not Found)が使われるべき(SHOULD)である。この応答は、特に指定されていなければキャッシュしてよい。410応答は主として、リソースが意図的に提供されておらず、サーバーの所有者ががそのリソースに対する遠隔からのリンクを削除したい場合に受信者にそれを知らせることによって、ウェブのメンテナンス作業を支援することを意図されている。このようなことは、時間が限られている広告的なサービスや、そのサーバーのサイトにはもう働いていない個人に属するリソースなどの場合によく起こる。恒久的に利用できなくなった資源すべてに「Gone」の印を使う必要はなく、この印を長期間保持する必要もない。これらはサーバー所有者の判断に任されている。 |
| 411 | Length Required | サーバーはContent-Lengthが定義されていない要求を受け取るのを拒否している。クライアントは要求メッセージのメッセージボディの長さを含む有効なContent-Lengthヘッダフィールドを追加すれば、その要求を再送してよい(MAY)。 |
| 412 | Precondition Failed | 1つ以上の要求のヘッダフィールドで与えられた前提条件がサーバーで検証された結果成立しないと評価された。この応答コードは、クライアントが現在のリソースのメタ情報(ヘッダフィールドのデータ)に前提条件を持たせ、意図したもの以外のリソースに要求されたメソッドが適用されることを防ぐことを可能にする。 |
| 413 | Request Entity Too Large | 要求エンティティがサーバーが処理する用意がない、あるいは処理できない大きさであるため、サーバーは要求の処理を拒否している。サーバーは接続を閉じ、クライアントから要求が送られ続けるのを防いでよい(MAY)。 |
| 414 | Request-URI Too Long | Request-URIがそのサーバーが処理する用意がある長さよりも長いため、サーバーが要求に応えるのを拒否している。この稀な状況が起こるのは、長いクエリー情報を持つPOST要求を不適切にGET要求に変換した場合や、クライアントがリダイレクションの「ブラックホール」となっているURIに引き込まれた場合(例えばリダイレクトされたURIプレフィックスが、それ自身のサフィックスを指している場合など)、あるいはRequest-URIの読み込みや操作に固定長のバッファを使っている一部のサーバにあるセキュリティホールを悪用しようとするクライアントによって、サーバーが攻撃を受けている場合だけだろう。 |
| 415 | Unsupported Media Type | 要求のエンティティが要求されたメソッドの要求されたリソースがサポートしていない形式を取っているため、サーバーがサービス要求に応えることを拒否している。 |
| 416 | Requested Range Not Satisfiable | 要求にRange要求ヘッダフィールドが含まれており、このフォールドの範囲指示子に現在の選択されたリソースの範囲と重なるものがなく、要求にIf-Range要求ヘッダフィールドが含まれていない場合、サーバはこのステータスコードを返すべき(SHOULD)である。(byte-rangesについては、これはすべてのbyte-range-specの最初のbyte-posの値が現在の選択されたリソースの長さよりも大きい場合を意味する。) |
| 417 | Expectation Failed | Expect要求ヘッダフィールドで与えられた期待値をこのサーバーによって満たすことができなかったか、もしこのサーバーがプロクシである場合、サーバーがその要求が次ホップサーバによって達成できないという確実な証拠を持っている。 |
| 500 | Internal Server Error | サーバが要求を実行することができない想定外の状態に遭遇した。 |
| 501 | Not Implemented | サーバーが要求を実行するのに必要な機能をサポートしていない。これは、サーバーが要求メソッドを認識しておらず、リソースの提供のためにそのメソッドをサポートできない場合には適切な応答となる。 |
| 502 | Bad Gateway | サーバーがゲートウェイかプロクシとして振る舞っており、要求を実行しようとして上流のサーバーにアクセスして、無効な応答を受け取った。 |
| 503 | Service Unavailable | 一時的な過負荷あるいはサーバーのメンテナンスにより、現在サーバーが要求を処理することができない。ここではこの状態が一定時間の後に緩和される一時的な状態であることを意味している。遅れの時間がわかっている場合には、その時間をRetry-Afterヘッダで示してもよい(MAY)。Retry-Afterが与えられていない場合には、クライアントはステータスコード500を受け取ったものとして処理すべき(SHOULD)である。 |
| 504 | Gateway Timeout | サーバーがゲートウェイかプロクシとして振る舞っており、URI(例えばHTTP、FTP、LDAP)や、その要求の完了のためにアクセスする必要のあるその他の補助サーバー(例えばDNS)によって指定された上流サーバーから、時間内に応答を受け取らなかった。 |
| 505 | HTTP Version Not Supported | サーバーは、要求メッセージで使われているHTTPプロトコルバージョンをサポートしていないか、サポートすることを拒否している。これは、このエラーメッセージで示されているバージョン以外の、クライアントと同じメジャーバージョンを使った要求をこのサーバーが完了することは、不可能であるか望んでいないことを示している。ている。応答にはなぜこのバージョンがサポートされておらず、このサーバで他にどんなプロトコルがサポートされているかを説明するエンティティが含まれるべき(SHOULD)である。 |
許可を受けてhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlから使った。
まとめ
これらの10のヒントで、読者の問題はすべて解決しただろうか。おそらく解決しないだろうが、これらのヒントは読者を問題解決への正しい方向を指し示すようにデザインされている。読者のApacheのトラブルシューティングのヒントを、この記事の将来のバージョンのためにコメントなどで教えて欲しい。
この記事は海外CNET Networks発のニュースをシーネットネットワークスジャパン編集部が日本向けに編集したものです。海外CNET Networksの記事へ
- 5人の推薦記事
- 3人がクリップ
-
ソーシャルブックマーク(-)
- トラックバック(0)
-
- タグ
- 501
- 404
- HTTP/1.1
- ServerSignature
- configtest
- DocumentRoot
- fullstatus
- apachectrl
- graceful
- ポート
- httpd
- connection reset by
- ポートの競合
- DirectoryIndex
- Limit
- AuthConfig
- .htaccess
- Indexes
- AllowOverride
- access_log
- error_log
- LoadModule
- httpd.conf
- Wiki
- ErrorLog
- リソース
- コミュニティ
- トラブルシュート
- IRC
- 設定
- Tips
- リファレンス
- まとめ
- Apache
- Linux
- PHP
- トラブル
- 昨日のトップ記事
- 2日前
- 3日前
- 4日前
- 5日前
- ホワイトペーパー
- 話題のタグ
HTML
リファレンス
Windows
イロハ
RIA
Webデザイン
iPhone 3G
Off Topic
SOA
フレームワーク
Adobe
server
入門
Mac OS X
Ruby
Google
Internet Explorer
Safari
Database
開発環境
Opera
Firefox
Microsoft
Java
Webアプリケーション開発
CSS
Eclipse
オープンソース
Apache
Python
iPod touch
Tips
Linux
小技
Apple
CSS 3
Flash
PHP
iPhone
Leopard
JavaScript
Ajax
Solaris
ライブラリ
C/C++
Firefox 3
Mozilla
ブラウザ
XHTML
仮想化
話題のタグを見る »
動画再生耐久レース―フル充電からどれだけ耐えた?
心当たりありませんか--あなたの上司がイヤがる5つの話し方
フォームデザイン虎の巻:複数の選択肢を提供する
フォトレポート:技術サポートの悪夢
無料の「Oracle Database XE」で高速バッチ処理:実装のポイント
Firefoxで情報をカンタン・ベンリに整理する
iPhone Safari、Acidテストでは高得点でも…… Firefoxは載らないの?:WebサイトのiPhone 3G対応問題を考える(ソフト編)
WebサイトのiPhone 3G対応問題を考える(ハード編)
フォトレポート:時代を振り返る--「MS-DOS 4」のインストール
SOAと仮想化の関係は?--常に進化を続けるBEAのミドルウェア戦略
ウェブ開発の生産性はどうしたら上がる?--MODIPHI Appsで半日で作るマッシュアップサイト(1)
JailBreakついに:PwnageTool公開
プロジェクトの進行でよくある4つのトラブル
DELLが掲げる「新・仮想化アセスメントサービス」
Techno Exchange
ZDNet Japan ホスティング特集
ZDNet Japan Green IT