URL からファイルシステム上の位置へのマップ

翻訳済み言語: en | + fr | + ja | + ko | + tr

この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +

+ +

この文書は Apache がリクエストの URL から送信するファイルの + ファイルシステム上の位置を決定する方法を説明します。

関連するモジュールとディレクティブ
DocumentRoot
DocumentRoot 外のファイル
ユーザディレクトリ
URL リダイレクション
リバースプロキシ
リライトエンジン
File Not Found

参照

関連モジュール	関連ディレクティブ
`mod_alias` `mod_proxy` `mod_rewrite` `mod_userdir` `mod_speling` `mod_vhost_alias`	`Alias` `AliasMatch` `CheckSpelling` `DocumentRoot` `ErrorDocument` `Options` `ProxyPass` `ProxyPassReverse` `ProxyPassReverseCookieDomain` `ProxyPassReverseCookiePath` `Redirect` `RedirectMatch` `RewriteCond` `RewriteMatch` `ScriptAlias` `ScriptAliasMatch` `UserDir`

DocumentRoot

+ +

リクエストに対してどのファイルを送信するかを決定するときの + Apache のデフォルトの動作は、リクエストの URL-Path (URL のホスト名と + ポート番号の後に続く部分) を取り出して設定ファイルで指定されている + DocumentRoot + の最後に追加する、というものです。ですから、 + DocumentRoot + の下のディレクトリやファイルがウェブから見える基本のドキュメントの木構造を + なします。

+ +

Apache にはサーバが複数のホストへのリクエストを受け取る + バーチャルホストの機能もあります。 + この場合、それぞれのバーチャルホストに対して違う + DocumentRoot + を指定することができます。また、mod_vhost_alias + モジュールにより提供されるディレクティブを使って、 + 送信するためのコンテンツの場所をリクエストされた IP + アドレスやホスト名から動的に決めることもできます。

DocumentRoot 外のファイル

+ +

ファイルシステム上の、 + 厳密には DocumentRoot + の下にはない部分へのウェブアクセスを許可する必要がある + 場合がよくあります。Apache はこのために複数の方法を用意しています。 + Unix システムでは、ファイルシステムの他の部分をシンボリックリンクを + 使って DocumentRoot + の下に持ってくることができます。セキュリティ上の理由により、 + Apache は該当するディレクトリの + Options の設定に + FollowSymLinks か SymLinksIfOwnerMatch が + ある場合にのみシンボリックリンクをたどります。

+ +

代わりの方法として、Alias + ディレクティブを使ってファイルシステムの任意の部分をウェブの空間に + マップできます。たとえば、

+ +

Alias /docs /var/web

+ +

という設定のときは、URL + http://www.example.com/docs/dir/file.html には + /var/web/dir/file.html が送信されます。 + ScriptAlias も、 + 対象となっているパスが CGI スクリプトとして扱われるという追加の + 効果以外は同じように動作します。

+ +

もっと柔軟な設定が必要な状況では、 + AliasMatch ディレクティブや + ScriptAliasMatch ディレクティブ + を使って強力な正規表現に基づいたマッチと置換を行なうことができます。 + たとえば、

+ +

ScriptAliasMatch ^/~([a-zA-Z0-9]+)/cgi-bin/(.+) + /home/$1/cgi-bin/$2

+ +

は http://example.com/~user/cgi-bin/script.cgi への + リクエストを /home/user/cgi-bin/script.cgi というパスへ + マップし、このマップの結果としてのファイルを CGI スクリプトとして + 扱います。

ユーザディレクトリ

+ +

伝統的に Unix システムではユーザ user のホームディレクトリを + ~user/ として参照できます。mod_userdir + モジュールはこの概念をウェブに拡張して、 + それぞれのユーザのホームディレクトリのファイルを + 以下のような URL を使ってアクセスできるようにします。

+ +

http://www.example.com/~user/file.html

+ +

セキュリティの観点から、ウェブからユーザのホームディレクトリへ + 直接アクセスできるようにすることは適切ではありません。ですから、 + UserDir ディレクティブには + ユーザのホームディレクトリの下の、ウェブファイルの + 置かれているディレクトリを指定します。デフォルトの設定の + Userdir public_html を使うと、上の URL は + /home/user/public_html/file.html というようなファイルに + マップされます。ここで、/home/user/ は + /etc/passwd で指定されているユーザのホームディレクトリです。

+ +

Userdir には、 + /etc/passwd にホームディレクトリの位置が書かれていない + システムでも使うことのできる他の形式もあります。

+ +

中にはシンボル "~" (%7e のように符号化されることが多い) + を格好が悪いと思って、ユーザのディレクトリを表すために別の文字列の + 使用を好む人がいます。mod_userdir はこの機能をサポートしていません。 + しかし、ユーザのホームディレクトリが規則的な構成のときは、 + AliasMatch を使って望みの + 効果を達成することができます。たとえば、 + http://www.example.com/upages/user/file.html が + /home/user/public_html/file.html にマップされるようにするには、 + 以下のように AliasMatch ディレクティブを使います:

+ +

AliasMatch ^/upages/([a-zA-Z0-9]+)/?(.*) + /home/$1/public_html/$2

URL リダイレクション

+ +

上の節で説明した設定用のディレクティブは Apache に + ファイルシステムの特定の場所からコンテンツを取ってきて + クライアントに送り返すようにします。ときには、その代わりに + クライアントにリクエストされたコンテンツは別の URL にあることを + 知らせて、クライアントが新しい URL へ新しいリクエストを行なうように + する方が望ましいことがあります。これはリダイレクションと + 呼ばれていて、Redirect + ディレクティブにより実装されています。たとえば、 + DocumentRoot の下のディレクトリ + /foo/ が新しいディレクトリ /bar/ に移動したときは、 + 以下のようにしてクライアントが新しい場所のコンテンツをリクエストするように + 指示することができます:

+ +

Redirect permanent /foo/ + http://www.example.com/bar/

+ +

これは、/foo/ で始まるすべての URL-Path を、 + www.example.com サーバの /bar/ が + /foo/ に置換されたものにリダイレクトします。 + サーバは自分自身のサーバだけでなく、どのサーバにでもクライアントを + リダイレクトすることができます。

+ +

Apache はより複雑な書き換えの問題のために、 + RedirectMatch ディレクティブを + 提供しています。たとえば、サイトのホームページを違うサイトにリダイレクト + するけれど、他のリクエストはそのまま扱う、というときは以下の設定を + 使います:

+ +

RedirectMatch permanent ^/$ + http://www.example.com/startpage.html

+ +

あるいは、一時的にサイトのすべてのページを他のサイトの特定の + ページへリダイレクトするときは、以下を使います:

+ +

RedirectMatch temp .* + http://othersite.example.com/startpage.html

リバースプロキシ

+ +

Apache は遠隔地にあるドキュメントをローカルのサーバの URL 空間に +持ってくることもできます。この手法はリバースプロキシと呼ばれています。 +ウェブサーバが遠隔地のドキュメントを取得してクライアントに送り返すのが +プロキシサーバの動作のように見えるからです。クライアントにはドキュメントが +リバースプロキシサーバから送られてきているように見える点が通常の +プロキシとは異なります。

+ +

次の例では、クライアントが /foo/ ディレクトリの下にある +ドキュメントをリクエストすると、サーバが internal.example.com の +/bar/ ディレクトリから取得して、さもローカルサーバからの +ドキュメントのようにしてクライアントに返します。

+ +

+ProxyPass /foo/ http://internal.example.com/bar/ +ProxyPassReverse /foo/ http://internal.example.com/bar/ +ProxyPassReverseCookieDomain internal.example.com public.example.com +ProxyPassReverseCookiePath /foo/ /bar/ +

+ +

ProxyPass ディレクティブは +サーバが適切なドキュメントを取得するように設定し、 +ProxyPassReverse ディレクティブは +internal.example.com からのリダイレクトがローカルサーバの +適切なディレクトリを指すように書き換えます。 +同様に ProxyPassReverseCookieDomain +と ProxyPassReverseCookiePath +でバックエンド側サーバの発行した Cookie を書き換えることができます。

ただし、ドキュメントの中のリンクは書き換えられない、 +ということは知っておいてください。 +ですから、internal.example.com への絶対パスによるリンクでは、 +クライアントがプロキシサーバを抜け出して internal.example.com に +直接リクエストを送る、ということになります。 +サードパーティ製モジュールの mod_proxy_html +は、HTML と XHTML 中のリンクを書き換えることができます。

リライトエンジン

+ +

より一層強力な置換が必要なときは、mod_rewrite + が提供するリライトエンジンが役に立つでしょう。 + このモジュールにより提供されるディレクティブは + ブラウザの種類、リクエスト元の IP アドレスなどのリクエストの特徴を + 使って送り返すコンテンツの場所を決めます。さらに、mod_rewrite + は外部のデータベースファイルやプログラムを使ってリクエストの扱い方を + 決めることもできます。リライトエンジンは上で挙げられている三つのマッピング + すべてを行なうことができます: 内部のリダイレクト (エイリアス)、 + 外部のリダイレクト、プロキシです。mod_rewrite を使う多くの実用的な例は + URL リライトガイド + で説明されています。

File Not Found

+ +

必ず、リクエストされた URL に対応するファイルがファイルシステムに + 無いという場合が発生します。これが起こるのにはいくつかの理由があります。 + 場合によっては、ドキュメントを別の場所に移動した結果であることがあります。 + この場合は、クライアントにリソースの新しい位置を知らせるために + URL リダイレクションを使うのが最善の方法です。 + そうすることによって、リソースは新しい位置に移動しているけれども、 + 古いブックマークやリンクが動作し続けるようにすることができます。

+ +

"File Not Found" エラーのもう一つのよくある理由は、 + ブラウザへの直接入力や HTML リンクからの偶発的な URL の入力間違いです。 + Apache はこの問題を改善するために、mod_speling + モジュール (意図的な綴り間違い) + (訳注: 正しくは spelling) を提供しています。このモジュールが + 使用されているときは、"File Not Found" エラーを横取りして、 + 似たファイル名のリソースを探します。もし一つだけ見つかった場合は + mod_speling はクライアントに正しい位置を知らせるために HTTP リダイレクトを + 送ります。もし複数の「近い」ファイルが見つかった場合は、それら + 代替となりえるもののリストがクライアントに表示されます。

+ +

mod_speling の非常に有用な機能は、大文字小文字を区別せずに + ファイル名を比較するものです。これは URL と unix の + ファイルシステムが両方とも大文字小文字を区別するものである、 + ということをユーザが知らないシステムで役に立ちます。ただし、 + 時折の URL 訂正程度で済まず、mod_speling をより多く使用すると、サーバに + さらなる負荷がかかります。すべての「正しくない」リクエストの後に + URL のリダイレクトとクライアントからの新しいリクエストがくることに + なりますから。

+ +

コンテンツの位置を決めようとするすべての試みが失敗すると、 + Apache は、HTTP ステータスコード 404 (file not found) と共に + エラーページを返します。このエラーページの外観は + ErrorDocument + ディレクティブで制御され、 + カスタムエラーレスポンスで + 説明されているように、柔軟な設定を行なうことができます。