1 <?xml version="1.0" encoding="UTF-8" ?>
2 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
4 <!-- English Revision: 151408:567425 (outdated) -->
7 Licensed to the Apache Software Foundation (ASF) under one or more
8 contributor license agreements. See the NOTICE file distributed with
9 this work for additional information regarding copyright ownership.
10 The ASF licenses this file to You under the Apache License, Version 2.0
11 (the "License"); you may not use this file except in compliance with
12 the License. You may obtain a copy of the License at
14 http://www.apache.org/licenses/LICENSE-2.0
16 Unless required by applicable law or agreed to in writing, software
17 distributed under the License is distributed on an "AS IS" BASIS,
18 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
19 See the License for the specific language governing permissions and
20 limitations under the License.
23 <manualpage metafile="urlmapping.xml.meta">
25 <title>URL からファイルシステム上の位置へのマップ</title>
28 <p>この文書は Apache がリクエストの URL から送信するファイルの
29 ファイルシステム上の位置を決定する方法を説明します。</p>
32 <section id="related"><title>関連するモジュールとディレクティブ</title>
36 <module>mod_alias</module>
37 <module>mod_proxy</module>
38 <module>mod_rewrite</module>
39 <module>mod_userdir</module>
40 <module>mod_speling</module>
41 <module>mod_vhost_alias</module>
44 <directive module="mod_alias">Alias</directive>
45 <directive module="mod_alias">AliasMatch</directive>
46 <directive module="mod_speling">CheckSpelling</directive>
47 <directive module="core">DocumentRoot</directive>
48 <directive module="core">ErrorDocument</directive>
49 <directive module="core">Options</directive>
50 <directive module="mod_proxy">ProxyPass</directive>
51 <directive module="mod_proxy">ProxyPassReverse</directive>
52 <directive module="mod_proxy">ProxyPassReverseCookieDomain</directive>
53 <directive module="mod_proxy">ProxyPassReverseCookiePath</directive>
54 <directive module="mod_alias">Redirect</directive>
55 <directive module="mod_alias">RedirectMatch</directive>
56 <directive module="mod_rewrite">RewriteCond</directive>
57 <directive module="mod_rewrite">RewriteMatch</directive>
58 <directive module="mod_alias">ScriptAlias</directive>
59 <directive module="mod_alias">ScriptAliasMatch</directive>
60 <directive module="mod_userdir">UserDir</directive>
65 <section id="documentroot"><title>DocumentRoot</title>
67 <p>リクエストに対してどのファイルを送信するかを決定するときの
68 Apache のデフォルトの動作は、リクエストの URL-Path (URL のホスト名と
69 ポート番号の後に続く部分) を取り出して設定ファイルで指定されている
70 <directive module="core">DocumentRoot</directive>
71 の最後に追加する、というものです。ですから、
72 <directive module="core">DocumentRoot</directive>
73 の下のディレクトリやファイルがウェブから見える基本のドキュメントの木構造を
76 <p>Apache にはサーバが複数のホストへのリクエストを受け取る
77 <a href="vhosts/">バーチャルホスト</a> の機能もあります。
78 この場合、それぞれのバーチャルホストに対して違う
79 <directive module="core">DocumentRoot</directive>
80 を指定することができます。また、<module>mod_vhost_alias</module>
81 モジュールにより提供されるディレクティブを使って、
82 送信するためのコンテンツの場所をリクエストされた IP
83 アドレスやホスト名から動的に決めることもできます。</p>
86 <section id="outside"><title>DocumentRoot 外のファイル</title>
89 厳密には <directive module="core">DocumentRoot</directive>
90 の下にはない部分へのウェブアクセスを許可する必要がある
91 場合がよくあります。Apache はこのために複数の方法を用意しています。
92 Unix システムでは、ファイルシステムの他の部分をシンボリックリンクを
93 使って <directive module="core">DocumentRoot</directive>
94 の下に持ってくることができます。セキュリティ上の理由により、
96 <directive module="core">Options</directive> の設定に
97 <code>FollowSymLinks</code> か <code>SymLinksIfOwnerMatch</code> が
98 ある場合にのみシンボリックリンクをたどります。</p>
100 <p>代わりの方法として、<directive module="mod_alias">Alias</directive>
101 ディレクティブを使ってファイルシステムの任意の部分をウェブの空間に
104 <example>Alias /docs /var/web</example>
107 <code>http://www.example.com/docs/dir/file.html</code> には
108 <code>/var/web/dir/file.html</code> が送信されます。
109 <directive module="mod_alias">ScriptAlias</directive> も、
110 対象となっているパスが CGI スクリプトとして扱われるという追加の
114 <directive module="mod_alias">AliasMatch</directive> ディレクティブや
115 <directive module="mod_alias">ScriptAliasMatch</directive> ディレクティブ
116 を使って強力な正規表現に基づいたマッチと置換を行なうことができます。
119 <example>ScriptAliasMatch ^/~([a-zA-Z0-9]+)/cgi-bin/(.+)
120 /home/$1/cgi-bin/$2</example>
122 <p>は <code>http://example.com/~user/cgi-bin/script.cgi</code> への
123 リクエストを <code>/home/user/cgi-bin/script.cgi</code> というパスへ
124 マップし、このマップの結果としてのファイルを CGI スクリプトとして
128 <section id="user"><title>ユーザディレクトリ</title>
130 <p>伝統的に Unix システムではユーザ <em>user</em> のホームディレクトリを
131 <code>~user/</code> として参照できます。<module>mod_userdir</module>
133 それぞれのユーザのホームディレクトリのファイルを
134 以下のような URL を使ってアクセスできるようにします。</p>
136 <example>http://www.example.com/~user/file.html</example>
138 <p>セキュリティの観点から、ウェブからユーザのホームディレクトリへ
139 直接アクセスできるようにすることは適切ではありません。ですから、
140 <directive module="mod_userdir">UserDir</directive> ディレクティブには
141 ユーザのホームディレクトリの下の、ウェブファイルの
142 置かれているディレクトリを指定します。デフォルトの設定の
143 <code>Userdir public_html</code> を使うと、上の URL は
144 <code>/home/user/public_html/file.html</code> というようなファイルに
145 マップされます。ここで、<code>/home/user/</code> は
146 <code>/etc/passwd</code> で指定されているユーザのホームディレクトリです。</p>
148 <p><directive module="mod_userdir">Userdir</directive> には、
149 <code>/etc/passwd</code> にホームディレクトリの位置が書かれていない
150 システムでも使うことのできる他の形式もあります。</p>
152 <p>中にはシンボル "~" (<code>%7e</code> のように符号化されることが多い)
153 を格好が悪いと思って、ユーザのディレクトリを表すために別の文字列の
154 使用を好む人がいます。mod_userdir はこの機能をサポートしていません。
155 しかし、ユーザのホームディレクトリが規則的な構成のときは、
156 <directive module="mod_alias">AliasMatch</directive> を使って望みの
158 <code>http://www.example.com/upages/user/file.html</code> が
159 <code>/home/user/public_html/file.html</code> にマップされるようにするには、
160 以下のように <code>AliasMatch</code> ディレクティブを使います:</p>
162 <example>AliasMatch ^/upages/([a-zA-Z0-9]+)/?(.*)
163 /home/$1/public_html/$2</example>
166 <section id="redirect"><title>URL リダイレクション</title>
168 <p>上の節で説明した設定用のディレクティブは Apache に
169 ファイルシステムの特定の場所からコンテンツを取ってきて
170 クライアントに送り返すようにします。ときには、その代わりに
171 クライアントにリクエストされたコンテンツは別の URL にあることを
172 知らせて、クライアントが新しい URL へ新しいリクエストを行なうように
173 する方が望ましいことがあります。これは<em>リダイレクション</em>と
174 呼ばれていて、<directive module="mod_alias">Redirect</directive>
175 ディレクティブにより実装されています。たとえば、
176 <directive module="core">DocumentRoot</directive> の下のディレクトリ
177 <code>/foo/</code> が新しいディレクトリ <code>/bar/</code> に移動したときは、
178 以下のようにしてクライアントが新しい場所のコンテンツをリクエストするように
181 <example>Redirect permanent /foo/
182 http://www.example.com/bar/</example>
184 <p>これは、<code>/foo/</code> で始まるすべての URL-Path を、
185 <code>www.example.com</code> サーバの <code>/bar/</code> が
186 <code>/foo/</code> に置換されたものにリダイレクトします。
187 サーバは自分自身のサーバだけでなく、どのサーバにでもクライアントを
190 <p>Apache はより複雑な書き換えの問題のために、
191 <directive module="mod_alias">RedirectMatch</directive> ディレクティブを
192 提供しています。たとえば、サイトのホームページを違うサイトにリダイレクト
193 するけれど、他のリクエストはそのまま扱う、というときは以下の設定を
196 <example>RedirectMatch permanent ^/$
197 http://www.example.com/startpage.html</example>
199 <p>あるいは、一時的にサイトのすべてのページを他のサイトの特定の
200 ページへリダイレクトするときは、以下を使います:</p>
202 <example>RedirectMatch temp .*
203 http://othersite.example.com/startpage.html</example>
206 <section id="proxy"><title>リバースプロキシ</title>
208 <p>Apache は遠隔地にあるドキュメントをローカルのサーバの URL 空間に
209 持ってくることもできます。この手法は<em>リバースプロキシ</em>と呼ばれています。
210 ウェブサーバが遠隔地のドキュメントを取得してクライアントに送り返すのが
211 プロキシサーバの動作のように見えるからです。クライアントにはドキュメントが
212 リバースプロキシサーバから送られてきているように見える点が通常の
215 <p>次の例では、クライアントが <code>/foo/</code> ディレクトリの下にある
216 ドキュメントをリクエストすると、サーバが <code>internal.example.com</code> の
217 <code>/bar/</code> ディレクトリから取得して、さもローカルサーバからの
218 ドキュメントのようにしてクライアントに返します。</p>
221 ProxyPass /foo/ http://internal.example.com/bar/<br />
222 ProxyPassReverse /foo/ http://internal.example.com/bar/<br />
223 ProxyPassReverseCookieDomain internal.example.com public.example.com<br />
224 ProxyPassReverseCookiePath /foo/ /bar/
227 <p><directive module="mod_proxy">ProxyPass</directive> ディレクティブは
228 サーバが適切なドキュメントを取得するように設定し、
229 <directive module="mod_proxy">ProxyPassReverse</directive> ディレクティブは
230 <code>internal.example.com</code> からのリダイレクトがローカルサーバの
231 適切なディレクトリを指すように書き換えます。
232 同様に <directive module="mod_proxy">ProxyPassReverseCookieDomain</directive>
233 と <directive module="mod_proxy">ProxyPassReverseCookiePath</directive>
234 でバックエンド側サーバの発行した Cookie を書き換えることができます。</p>
235 <p>ただし、ドキュメントの中のリンクは書き換えられない、
237 ですから、<code>internal.example.com</code> への絶対パスによるリンクでは、
238 クライアントがプロキシサーバを抜け出して <code>internal.example.com</code> に
239 直接リクエストを送る、ということになります。
241 href="http://apache.webthing.com/mod_proxy_html/">mod_proxy_html</a>
242 は、HTML と XHTML 中のリンクを書き換えることができます。</p>
245 <section id="rewrite"><title>リライトエンジン</title>
247 <p>より一層強力な置換が必要なときは、<module>mod_rewrite</module>
248 が提供するリライトエンジンが役に立つでしょう。
249 このモジュールにより提供されるディレクティブは
250 ブラウザの種類、リクエスト元の IP アドレスなどのリクエストの特徴を
251 使って送り返すコンテンツの場所を決めます。さらに、<module>mod_rewrite</module>
252 は外部のデータベースファイルやプログラムを使ってリクエストの扱い方を
253 決めることもできます。リライトエンジンは上で挙げられている三つのマッピング
254 すべてを行なうことができます: 内部のリダイレクト (エイリアス)、
255 外部のリダイレクト、プロキシです。mod_rewrite を使う多くの実用的な例は
256 <a href="misc/rewriteguide.html">URL リライトガイド</a>
260 <section id="notfound"><title>File Not Found</title>
262 <p>必ず、リクエストされた URL に対応するファイルがファイルシステムに
263 無いという場合が発生します。これが起こるのにはいくつかの理由があります。
264 場合によっては、ドキュメントを別の場所に移動した結果であることがあります。
265 この場合は、クライアントにリソースの新しい位置を知らせるために
266 <a href="#redirect">URL リダイレクション</a>を使うのが最善の方法です。
267 そうすることによって、リソースは新しい位置に移動しているけれども、
268 古いブックマークやリンクが動作し続けるようにすることができます。</p>
270 <p>"File Not Found" エラーのもう一つのよくある理由は、
271 ブラウザへの直接入力や HTML リンクからの偶発的な URL の入力間違いです。
272 Apache はこの問題を改善するために、<module>mod_speling</module>
274 (訳注: 正しくは spelling) を提供しています。このモジュールが
275 使用されているときは、"File Not Found" エラーを横取りして、
276 似たファイル名のリソースを探します。もし一つだけ見つかった場合は
277 mod_speling はクライアントに正しい位置を知らせるために HTTP リダイレクトを
278 送ります。もし複数の「近い」ファイルが見つかった場合は、それら
279 代替となりえるもののリストがクライアントに表示されます。</p>
281 <p>mod_speling の非常に有用な機能は、大文字小文字を区別せずに
282 ファイル名を比較するものです。これは URL と unix の
283 ファイルシステムが両方とも大文字小文字を区別するものである、
284 ということをユーザが知らないシステムで役に立ちます。ただし、
285 時折の URL 訂正程度で済まず、mod_speling をより多く使用すると、サーバに
286 さらなる負荷がかかります。すべての「正しくない」リクエストの後に
287 URL のリダイレクトとクライアントからの新しいリクエストがくることに
290 <p>コンテンツの位置を決めようとするすべての試みが失敗すると、
291 Apache は、HTTP ステータスコード 404 (file not found) と共に
292 エラーページを返します。このエラーページの外観は
293 <directive module="core">ErrorDocument</directive>
295 <a href="custom-error.html">カスタムエラーレスポンス</a> で
296 説明されているように、柔軟な設定を行なうことができます。</p>