URL からファイルシステム上の位置へのマップ
この文書は Apache がリクエストの URL から送信するファイルの ファイルシステム上の位置を決定する方法を説明します。
Apache にはサーバが複数のホストへのリクエストを受け取る バーチャルホスト の機能もあります。 この場合、それぞれのバーチャルホストに対して違う
モジュールにより提供されるディレクティブを使って、 送信するためのコンテンツの場所をリクエストされた IP アドレスやホスト名から動的に決めることもできます。modvhostalias
ディレクティブを使ってファイルシステムの任意の部分をウェブの空間に マップできます。たとえば、Alias
Alias /docs /var/web
という設定のときは、URL http://www.example.com/docs/dir/file.html
も、 対象となっているパスが CGI スクリプトとして扱われるという追加の 効果以外は同じように動作します。ScriptAlias
ディレクティブ を使って強力な正規表現に基づいたマッチと置換を行なうことができます。 たとえば、ScriptAliasMatch
ScriptAliasMatch ^/~([a-zA-Z0-9]+)/cgi-bin/(.+) /home/$1/cgi-bin/$2
への リクエストを /home/user/cgi-bin/script.cgi
というパスへ マップし、このマップの結果としてのファイルを CGI スクリプトとして 扱います。
セキュリティの観点から、ウェブからユーザのホームディレクトリへ 直接アクセスできるようにすることは適切ではありません。ですから、
ディレクティブには ユーザのホームディレクトリの下の、ウェブファイルの 置かれているディレクトリを指定します。デフォルトの設定の UserDirUserdir public_html
というようなファイルに マップされます。ここで、/home/user/
には、 Userdir/etc/passwd
のように符号化されることが多い) を格好が悪いと思って、ユーザのディレクトリを表すために別の文字列の 使用を好む人がいます。mod_userdir はこの機能をサポートしていません。 しかし、ユーザのホームディレクトリが規則的な構成のときは、
を使って望みの 効果を達成することができます。たとえば、 AliasMatchhttp://www.example.com/upages/user/file.html
に置換されたものにリダイレクトします。 サーバは自分自身のサーバだけでなく、どのサーバにでもクライアントを リダイレクトすることができます。
ディレクティブを 提供しています。たとえば、サイトのホームページを違うサイトにリダイレクト するけれど、他のリクエストはそのまま扱う、というときは以下の設定を 使います:RedirectMatch
RedirectMatch permanent ^/$ http://www.example.com/startpage.html
あるいは、一時的にサイトのすべてのページを他のサイトの特定の ページへリダイレクトするときは、以下を使います:
RedirectMatch temp .* http://othersite.example.com/startpage.html
ディレクトリの下にある ドキュメントをリクエストすると、サーバが internal.example.com
ProxyPassReverseCookieDomain internal.example.com public.example.com
ディレクティブは ProxyPassReverseinternal.example.com
でバックエンド側サーバの発行した Cookie を書き換えることができます。ProxyPassReverseCookiePath
ただし、ドキュメントの中のリンクは書き換えられない、 ということは知っておいてください。 ですから、internal.example.com
への絶対パスによるリンクでは、 クライアントがプロキシサーバを抜け出して internal.example.com
に 直接リクエストを送る、ということになります。 サードパーティ製モジュールの modproxyhtml は、HTML と XHTML 中のリンクを書き換えることができます。
"File Not Found" エラーのもう一つのよくある理由は、 ブラウザへの直接入力や HTML リンクからの偶発的な URL の入力間違いです。 Apache はこの問題を改善するために、
modspeling の非常に有用な機能は、大文字小文字を区別せずに ファイル名を比較するものです。これは URL と unix の ファイルシステムが両方とも大文字小文字を区別するものである、 ということをユーザが知らないシステムで役に立ちます。ただし、 時折の URL 訂正程度で済まず、modspeling をより多く使用すると、サーバに さらなる負荷がかかります。すべての「正しくない」リクエストの後に URL のリダイレクトとクライアントからの新しいリクエストがくることに なりますから。
コンテンツの位置を決めようとするすべての試みが失敗すると、 Apache は、HTTP ステータスコード 404 (file not found) と共に エラーページを返します。このエラーページの外観は
ディレクティブで制御され、 ErrorDocumentカスタムエラーレスポンス で 説明されているように、柔軟な設定を行なうことができます。
モジュール | ディレクティブ | FAQ | 用語 | サイトマップ
Apache HTTP サーバ バージョン 2.4
URL からファイルシステム上の位置へのマップ
翻訳済み言語: en | fr | ja | ko | tr
関連するモジュールとディレクティブ
DocumentRoot
リクエストに対してどのファイルを送信するかを決定するときの Apache のデフォルトの動作は、リクエストの URL-Path (URL のホスト名と ポート番号の後に続く部分) を取り出して設定ファイルで指定されている DocumentRoot の最後に追加する、というものです。ですから、 DocumentRoot の下のディレクトリやファイルがウェブから見える基本のドキュメントの木構造を なします。
DocumentRoot 外のファイル
ファイルシステム上の、 厳密には DocumentRoot の下にはない部分へのウェブアクセスを許可する必要がある 場合がよくあります。Apache はこのために複数の方法を用意しています。 Unix システムでは、ファイルシステムの他の部分をシンボリックリンクを 使って DocumentRoot の下に持ってくることができます。セキュリティ上の理由により、 Apache は該当するディレクトリの Options の設定に FollowSymLinks か SymLinksIfOwnerMatch が ある場合にのみシンボリックリンクをたどります。
ユーザディレクトリ
伝統的に Unix システムではユーザ user のホームディレクトリを ~user/ として参照できます。mod_userdir モジュールはこの概念をウェブに拡張して、 それぞれのユーザのホームディレクトリのファイルを 以下のような URL を使ってアクセスできるようにします。
URL リダイレクション
上の節で説明した設定用のディレクティブは Apache に ファイルシステムの特定の場所からコンテンツを取ってきて クライアントに送り返すようにします。ときには、その代わりに クライアントにリクエストされたコンテンツは別の URL にあることを 知らせて、クライアントが新しい URL へ新しいリクエストを行なうように する方が望ましいことがあります。これはリダイレクションと 呼ばれていて、Redirect ディレクティブにより実装されています。たとえば、 DocumentRoot の下のディレクトリ /foo/ が新しいディレクトリ /bar/ に移動したときは、 以下のようにしてクライアント
リバースプロキシ
Apache は遠隔地にあるドキュメントをローカルのサーバの URL 空間に 持ってくることもできます。この手法はリバースプロキシと呼ばれています。 ウェブサーバが遠隔地のドキュメントを取得してクライアントに送り返すのが プロキシサーバの動作のように見えるからです。クライアントにはドキュメントが リバースプロキシサーバから送られてきているように見える点が通常の プロキシとは異なります。
リライトエンジン
より一層強力な置換が必要なときは、mod_rewrite が提供するリライトエンジンが役に立つでしょう。 このモジュールにより提供されるディレクティブは ブラウザの種類、リクエスト元の IP アドレスなどのリクエストの特徴を 使って送り返すコンテンツの場所を決めます。さらに、mod_rewrite は外部のデータベースファイルやプログラムを使ってリクエストの扱い方を 決めることもできます。リライトエンジンは上で挙げられている三つのマッピング すべてを行なうことができます: 内部のリダイレクト (エイリアス)、 外部のリダイレクト、プロキシです。mod_rewrite を使う多くの実用的な例は
File Not Found
必ず、リクエストされた URL に対応するファイルがファイルシステムに 無いという場合が発生します。これが起こるのにはいくつかの理由があります。 場合によっては、ドキュメントを別の場所に移動した結果であることがあります。 この場合は、クライアントにリソースの新しい位置を知らせるために URL リダイレクションを使うのが最善の方法です。 そうすることによって、リソースは新しい位置に移動しているけれども、 古いブックマークやリンクが動作し続けるようにすることができます。