urlmapping.xml.ja

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
<!-- English Revision: 421100:732823 (outdated) -->

<!--
 Licensed to the Apache Software Foundation (ASF) under one or more
 contributor license agreements.  See the NOTICE file distributed with
 this work for additional information regarding copyright ownership.
 The ASF licenses this file to You under the Apache License, Version 2.0
 (the "License"); you may not use this file except in compliance with
 the License.  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
-->

<manualpage metafile="urlmapping.xml.meta">

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

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

<section id="related"><title>関連するモジュールとディレクティブ</title>

<related>
<modulelist>
<module>mod_alias</module>
<module>mod_proxy</module>
<module>mod_rewrite</module>
<module>mod_userdir</module>
<module>mod_speling</module>
<module>mod_vhost_alias</module>
</modulelist>
<directivelist>
<directive module="mod_alias">Alias</directive>
<directive module="mod_alias">AliasMatch</directive>
<directive module="mod_speling">CheckSpelling</directive>
<directive module="core">DocumentRoot</directive>
<directive module="core">ErrorDocument</directive>
<directive module="core">Options</directive>
<directive module="mod_proxy">ProxyPass</directive>
<directive module="mod_proxy">ProxyPassReverse</directive>
<directive module="mod_proxy">ProxyPassReverseCookieDomain</directive>
<directive module="mod_proxy">ProxyPassReverseCookiePath</directive>
<directive module="mod_alias">Redirect</directive>
<directive module="mod_alias">RedirectMatch</directive>
<directive module="mod_rewrite">RewriteCond</directive>
<directive module="mod_rewrite">RewriteMatch</directive>
<directive module="mod_alias">ScriptAlias</directive>
<directive module="mod_alias">ScriptAliasMatch</directive>
<directive module="mod_userdir">UserDir</directive>
</directivelist>
</related>
</section>

<section id="documentroot"><title>DocumentRoot</title>

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

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

<section id="outside"><title>DocumentRoot 外のファイル</title>

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

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

<example>Alias /docs /var/web</example>

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

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

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

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

<section id="user"><title>ユーザディレクトリ</title>

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

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

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

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

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

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

<section id="redirect"><title>URL リダイレクション</title>

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

<example>Redirect permanent /foo/
      http://www.example.com/bar/</example>

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

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

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

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

<example>RedirectMatch temp .*
      http://othersite.example.com/startpage.html</example>
</section>

<section id="proxy"><title>リバースプロキシ</title>

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

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

<example>
ProxyPass /foo/ http://internal.example.com/bar/<br />
ProxyPassReverse /foo/ http://internal.example.com/bar/<br />
ProxyPassReverseCookieDomain internal.example.com public.example.com<br />
ProxyPassReverseCookiePath /foo/ /bar/
</example>

<p><directive module="mod_proxy">ProxyPass</directive> ディレクティブは
サーバが適切なドキュメントを取得するように設定し、
<directive module="mod_proxy">ProxyPassReverse</directive> ディレクティブは
<code>internal.example.com</code> からのリダイレクトがローカルサーバの
適切なディレクトリを指すように書き換えます。
同様に <directive module="mod_proxy">ProxyPassReverseCookieDomain</directive>
と <directive module="mod_proxy">ProxyPassReverseCookiePath</directive>
でバックエンド側サーバの発行した Cookie を書き換えることができます。</p>
<p>ただし、ドキュメントの中のリンクは書き換えられない、
ということは知っておいてください。
ですから、<code>internal.example.com</code> への絶対パスによるリンクでは、
クライアントがプロキシサーバを抜け出して <code>internal.example.com</code> に
直接リクエストを送る、ということになります。
サードパーティ製モジュールの <a 
href="http://apache.webthing.com/mod_proxy_html/">mod_proxy_html</a>
は、HTML と XHTML 中のリンクを書き換えることができます。</p>
</section>

<section id="rewrite"><title>リライトエンジン</title>

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

<section id="notfound"><title>File Not Found</title>

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

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

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

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

</manualpage>