From: Yoshiki Hayashi Date: Fri, 19 Jul 2002 10:54:56 +0000 (+0000) Subject: New Japanese translation. X-Git-Tag: 2.0.40~178 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=8f24cf35b15c0323bed3f208f2d0b0f864c28f91;p=apache New Japanese translation. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96124 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/urlmapping.html b/docs/manual/urlmapping.html deleted file mode 100755 index a127bb1c16..0000000000 --- a/docs/manual/urlmapping.html +++ /dev/null @@ -1,333 +0,0 @@ - - - - - Mapping URLs to Filesystem Locations - Apache HTTP - Server - - - - - - -

Mapping URLs to Filesystem Locations

- -

This document explains how Apache uses the URL of a request - to determine the filesystem location from which to serve a - file.

- - -
- - - - - - - -
Related Modules
-
- mod_alias
- mod_proxy
- mod_rewrite
- mod_userdir
- mod_speling
- mod_vhost_alias
- 		Related Directives
-
- Alias
- AliasMatch
- CheckSpelling
- DocumentRoot
- ErrorDocument
- Options
- ProxyPass
- ProxyPassReverse
- Redirect
- RedirectMatch
- RewriteCond
- RewriteRule
- ScriptAlias
- ScriptAliasMatch
- UserDir
-
- -

DocumentRoot

- -

In deciding what file to serve for a given request, Apache's - default behavior is to take the URL-Path for the request (the - part of the URL following the hostname and port) and add it to - the end of the DocumentRoot specified in - your configuration files. Therefore, the files and directories - underneath the DocumentRoot make up the basic - document tree which will be visible from the web.

- -

Apache is also capable of Virtual - Hosting, where the server receives requests for more than - one host. In this case, a different DocumentRoot - can be specified for each virtual host, or alternatively, the - directives provided by the module mod_vhost_alias can be used - to dynamically determine the appropriate place from which to - serve content based on the requested IP address or - hostname.

- -

Files Outside the - DocumentRoot

- -

There are frequently circumstances where it is necessary to - allow web access to parts of the filesystem that are not - strictly underneath the DocumentRoot. Apache - offers several different ways to accomplish this. On Unix - systems, symbolic links can bring other parts of the filesystem - under the DocumentRoot. For security reasons, - Apache will follow symbolic links only if the Options setting for the - relevant directory includes FollowSymLinks or - SymLinksIfOwnerMatch.

- -

Alternatively, the Alias directive will map - any part of the filesystem into the web space. For example, - with

- -
- Alias /docs /var/web/ -
- -

the URL - http://www.example.com/docs/dir/file.html will be - served from /var/web/dir/file.html. The ScriptAlias directive - works the same way, with the additional effect that all content - located at the target path is treated as CGI scripts.

- -

For situations where you require additional flexibility, you - can use the AliasMatch and ScriptAliasMatch - directives to do powerful regular-expression based matching and - substitution. For example,

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

will map a request to - http://example.com/~user/cgi-bin/script.cgi to the - path /home/user/cgi-bin/script.cgi and will treat - the resulting file as a CGI script.

- -

User Directories

- -

Traditionally on Unix systems, the home directory of a - particular user can be referred to as - ~user/. The module mod_userdir extends this idea - to the web by allowing files under each user's home directory - to be accessed using URLs such as the following.

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

For security reasons, it is inappropriate to give direct - access to a user's home directory from the web. Therefore, the - UserDir directive - specifies a directory underneath the user's home directory - where web files are located. Using the default setting of - Userdir public_html, the above URL maps to a file - at a directory like - /home/user/public_html/file.html where - /home/user/ is the user's home directory as - specified in /etc/passwd.

- -

There are also several other forms of the - Userdir directive which you can use on systems - where /etc/passwd does not contain the location of - the home directory.

- -

Some people find the "~" symbol (which is often encoded on - the web as %7e) to be awkward and prefer to use an - alternate string to represent user directories. This - functionality is not supported by mod_userdir. However, if - users' home directories are structured in a regular way, then - it is possible to use the AliasMatch directive - to achieve the desired effect. For example, to make - http://www.example.com/upages/user/file.html map - to /home/user/public_html/file.html, use the - following AliasMatch directive:

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

URL Redirection

- -

The configuration directives discussed in the above sections - tell Apache to get content from a specific place in the - filesystem and return it to the client. Sometimes, it is - desirable instead to inform the client that the requested - content is located at a different URL, and instruct the client - to make a new request with the new URL. This is called - redirection and is implemented by the Redirect directive. For - example, if the contents of the directory /foo/ - under the DocumentRoot are moved to the new - directory /bar/, you can instruct clients to - request the content at the new location as follows:

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

This will redirect any URL-Path starting in - /foo/ to the same URL path on the - www.example.com server with /bar/ - substituted for /foo/. You can redirect clients to - any server, not only the origin server.

- -

Apache also provides a RedirectMatch - directive for more complicated rewriting problems. For example, - to redirect requests for the site home page to a different - site, but leave all other requests alone, use the following - configuration:

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

Alternatively, to temporarily redirect all pages on a site - to one particular page, use the following:

- -
- RedirectMatch temp .* - http://www.example.com/startpage.html -
- - -

Reverse Proxy

- -

Apache also allows you to bring remote documents into the URL space -of the local server. This technique is called reverse -proxying because the web server acts like a proxy server by -fetching the documents from a remote server and returning them to the -client. It is different from normal proxying because, to the client, -it appears the documents originate at the reverse proxy server.

- -

In the following example, when clients request documents under the -/foo/ directory, the server fetches those documents from -the /bar/ directory on internal.example.com -and returns them to the client as if they were from the local -server.

- -
-ProxyPass /foo/ http://internal.example.com/bar/
-ProxyPassReverse /foo/ http://internal.example.com/bar/ -
- -

The ProxyPass configures -the server to fetch the appropriate documents, while the ProxyPassReverse -directive rewrites redirects originating at -internal.examle.com so that they target the appropriate -directory on the local server. It is important to note, however, that -links inside the documents will not be rewritten. So any absolute -links on internal.example.com will result in the client -breaking out of the proxy server and requesting directly from -internal.example.com.

- - -

Rewriting Engine

- -

When even more powerful substitution is required, the rewriting - engine provided by mod_rewrite - can be useful. The directives provided by this module use - characteristics of the request such as browser type or source IP - address in deciding from where to serve content. In addition, - mod_rewrite can use external database files or programs to - determine how to handle a request. The rewriting engine is capable - of performing all three types of mappings discussed above: - internal redirects (aliases), external redirects, and proxying. - Many practical examples employing mod_rewrite are discussed in the - URL Rewriting Guide.

- -

File Not Found

- -

Inevitably, URLs will be requested for which no matching - file can be found in the filesystem. This can happen for - several reasons. In some cases, it can be a result of moving - documents from one location to another. In this case, it is - best to use URL redirection to inform - clients of the new location of the resource. In this way, you - can assure that old bookmarks and links will continue to work, - even though the resource is at a new location.

- -

Another common cause of "File Not Found" errors is - accidental mistyping of URLs, either directly in the browser, - or in HTML links. Apache provides the module mod_speling (sic) to help with - this problem. When this module is activated, it will intercept - "File Not Found" errors and look for a resource with a similar - filename. If one such file is found, mod_speling will send an - HTTP redirect to the client informing it of the correct - location. If several "close" files are found, a list of - available alternatives will be presented to the client.

- -

An especially useful feature of mod_speling, is that it will - compare filenames without respect to case. This can help - systems where users are unaware of the case-sensitive nature of - URLs and the unix filesystem. But using mod_speling for - anything more than the occasional URL correction can place - additional load on the server, since each "incorrect" request - is followed by a URL redirection and a new request from the - client.

- -

If all attempts to locate the content fail, Apache returns - an error page with HTTP status code 404 (file not found). The - appearance of this page is controlled with the ErrorDocument directive - and can be customized in a flexible manner as discussed in the - Custom error responses and International Server Error - Responses documents.

- - - - diff --git a/docs/manual/urlmapping.html.ja.jis b/docs/manual/urlmapping.html.ja.jis new file mode 100755 index 0000000000..df241c882b --- /dev/null +++ b/docs/manual/urlmapping.html.ja.jis @@ -0,0 +1,317 @@ + + + + + + Mapping URLs to Filesystem Locations - Apache HTTP + Server + + + + + + + +

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

+ +

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

+ + +
+ + + + + + + +
関連モジュール
+
+ mod_alias
+ mod_proxy
+ mod_rewrite
+ mod_userdir
+ mod_speling
+ mod_vhost_alias
+ 		関連ディレクティブ
+
+ Alias
+ AliasMatch
+ CheckSpelling
+ DocumentRoot
+ ErrorDocument
+ Options
+ ProxyPass
+ ProxyPassReverse
+ Redirect
+ RedirectMatch
+ RewriteCond
+ RewriteRule
+ 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://www.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/ +
+ +

ProxyPass ディレクティブは +サーバが適切なドキュメントを取得するように設定し、ProxyPassReverse ディレクティブは +internal.example.com からのリダイレクトがローカルサーバの +適切なディレクトリを指すように書き換えます。ただし、ドキュメントの中の +リンクは書き換えられない、ということは知っておいてください。 +ですから、internal.example.com への絶対パスによるリンクでは、 +クライアントがプロキシサーバを抜け出して internal.example.com に +直接リクエストを送る、ということになります。

+ +

リライトエンジン

+ +

より一層強力な置換が必要なときは、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 ディレクティブで + 制御され、カスタムエラーレスポンス と + 国際化サーバエラーレスポンス で + 説明されているように、柔軟な設定を行なうことができます。

+ + + + +