Copied: httpd/httpd/branches/2.0.x/docs/manual/upgrading.html.ja.utf8 (from r643946, httpd/httpd/branches/2.0.x/docs/manual/upgrading.html.ja.euc-jp) URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.0.x/docs/manual/upgrading.html.ja.utf8?p2=httpd/httpd/branches/2.0.x/docs/manual/upgrading.html.ja.utf8&p1=httpd/httpd/branches/2.0.x/docs/manual/upgrading.html.ja.euc-jp&r1=643946&r2=643967&rev=643967&view=diff ============================================================================== --- httpd/httpd/branches/2.0.x/docs/manual/upgrading.html.ja.euc-jp [euc-jp] (original) +++ httpd/httpd/branches/2.0.x/docs/manual/upgrading.html.ja.utf8 [iso-8859-1] Wed Apr 2 09:46:34 2008 @@ -1,222 +1,222 @@ - + -1.3 から 2.0 へのアップグレード - Apache HTTP サーバ +1.3 から 2.0 へのアップグレード - Apache HTTP サーバ
-

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

-

Apache HTTP サーバ バージョン 2.0

+

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

+

Apache HTTP サーバ バージョン 2.0

<-
-Apache > HTTP サーバ > ドキュメンテーション > バージョン 2.0

1.3 から 2.0 へのアップグレード

+Apache > HTTP サーバ > ドキュメンテーション > バージョン 2.0

1.3 から 2.0 へのアップグレード

Available Languages:  de  |  en  | - es  | - fr  | + es  | + fr  |  ja  |  ko  |  ru 

-

アップグレードを簡単にするために、既存の Apache ユーザに - 非常に重要な情報をこの文書にまとめています。これは短い - 注意書きとして書かれています。より詳しい情報は - 新機能の文書や - src/CHANGES ファイルで見つけられると思います。

+

アップグレードを簡単にするために、既存の Apache ユーザに + 非常に重要な情報をこの文書にまとめています。これは短い + 注意書きとして書かれています。より詳しい情報は + 新機能の文書や + src/CHANGES ファイルで見つけられると思います。

- +
top
-

コンパイル時の設定の変更

+

コンパイル時の設定の変更

    -
  • Apache は ビルド処理の設定 - に autoconf と libtool を使うようになりました。 - このシステムは Apache 1.3 の APACI システムと似ていますが、 - まったく同じというわけではありません。
    • - -
  • 通常のコンパイルするかどうかを選択できるモジュール群に加えて、 - Apache 2.0 は - リクエスト処理の主な部分を マルチプロセッシング - モジュール (MPM) に移動しました。
    • +
  • Apache は ビルド処理の設定 + に autoconf と libtool を使うようになりました。 + このシステムは Apache 1.3 の APACI システムと似ていますが、 + まったく同じというわけではありません。
    • + +
  • 通常のコンパイルするかどうかを選択できるモジュール群に加えて、 + Apache 2.0 は + リクエスト処理の主な部分を マルチプロセッシング + モジュール (MPM) に移動しました。
top
-

実行時の設定の変更

+

実行時の設定の変更

    -
  • Apache 1.3 の時にコアサーバにあった多くのディレクティブは - MPM に移動しました。サーバに Apache 1.3 とできるだけ同じ振る舞いを - させたい場合は、prefork MPM を - 選んでください。他の MPM はプロセスの作成やリクエストの処理の - 制御に異なったディレクティブを使います。
    • - -
  • Proxy モジュール は - HTTP/1.1 に対応するために再構成されました。重要な変更点としては、 - プロキシのアクセス制御が <Directory proxy:> ブロックの - 代わりに <Proxy> - ブロックに置かれるようになった、というものがあります。
    • - -
  • モジュールの中には、PATH_INFO (本当のファイル名の後に続く - パス情報) の扱いが変わったものがあります。以前はハンドラとして - 実装されていたものがフィルタとして実装されるようになったものは - PATH_INFO のあるリクエストを受け付けません。INCLUDES や - PHP などのフィルタは - コアハンドラの上に実装されていますので、PATH_INFO - 付きのリクエストを拒否します。 +
  • Apache 1.3 の時にコアサーバにあった多くのディレクティブは + MPM に移動しました。サーバに Apache 1.3 とできるだけ同じ振る舞いを + させたい場合は、prefork MPM を + 選んでください。他の MPM はプロセスの作成やリクエストの処理の + 制御に異なったディレクティブを使います。
    • + +
  • Proxy モジュール は + HTTP/1.1 に対応するために再構成されました。重要な変更点としては、 + プロキシのアクセス制御が <Directory proxy:> ブロックの + 代わりに <Proxy> + ブロックに置かれるようになった、というものがあります。
    • + +
  • モジュールの中には、PATH_INFO (本当のファイル名の後に続く + パス情報) の扱いが変わったものがあります。以前はハンドラとして + 実装されていたものがフィルタとして実装されるようになったものは + PATH_INFO のあるリクエストを受け付けません。INCLUDES や + PHP などのフィルタは + コアハンドラの上に実装されていますので、PATH_INFO + 付きのリクエストを拒否します。 AcceptPathInfo - ディレクティブを使ってコアハンドラが PATH_INFO - 付きのリクエストを受け付けるようにでき、それによって SSI 等で - PATH_INFO を使う機能を復活させることができます。
    • + ディレクティブを使ってコアハンドラが PATH_INFO + 付きのリクエストを受け付けるようにでき、それによって SSI 等で + PATH_INFO を使う機能を復活させることができます。
  • CacheNegotiatedDocs - ディレクティブは on もしくは off という引数を - 取るようになりました。既に存在している - CacheNegotiatedDocs は + ディレクティブは on もしくは off という引数を + 取るようになりました。既に存在している + CacheNegotiatedDocs は CacheNegotiatedDocs on - に置き換えてください。
    • + に置き換えてください。
  • ErrorDocument - ディレクティブはテキストメッセージを - 示すために引数の最初に使われていた引用符を使わないようになりました。 - 代わりに、メッセージを二重引用符で囲むようになっています。 - 例えば、既存の + ディレクティブはテキストメッセージを + 示すために引数の最初に使われていた引用符を使わないようになりました。 + 代わりに、メッセージを二重引用符で囲むようになっています。 + 例えば、既存の

    ErrorDocument 403 "Some Message

    - は + は

    ErrorDocument 403 "Some Message"

    - に置き換える必要があります。 - 二番目の引数は、有効な URL やパス名でない限り - テキストメッセージとして扱われます。 + に置き換える必要があります。 + 二番目の引数は、有効な URL やパス名でない限り + テキストメッセージとして扱われます。
    • -
  • AccessConfig ディレクティブと - ResourceConfig ディレクティブは削除されました。 - これらのディレクティブは同等の機能を持つ - Include で - 置き換えることができます。設定ファイルに取り込む代わりに、 - 上のディレクティブのデフォルト値を使っていた場合は、 - httpd.conf に Include conf/access.conf と - Include conf/srm.conf を追加する必要があるでしょう。 - 以前のディレクティブによる順番のように Apache が設定ファイルを - 読み込むようにするためには、httpd.conf の最後に - srm.conf、access.conf の順にそれぞれ +
  • AccessConfig ディレクティブと + ResourceConfig ディレクティブは削除されました。 + これらのディレクティブは同等の機能を持つ + Include で + 置き換えることができます。設定ファイルに取り込む代わりに、 + 上のディレクティブのデフォルト値を使っていた場合は、 + httpd.conf に Include conf/access.conf と + Include conf/srm.conf を追加する必要があるでしょう。 + 以前のディレクティブによる順番のように Apache が設定ファイルを + 読み込むようにするためには、httpd.conf の最後に + srm.conf、access.conf の順にそれぞれ Include - ディレクティブを書いてください。
    • + ディレクティブを書いてください。 -
  • BindAddress ディレクティブと Port - ディレクティブは削除されました。同等の機能はより柔軟な +
  • BindAddress ディレクティブと Port + ディレクティブは削除されました。同等の機能はより柔軟な Listen - ディレクティブにより提供されています。
    • + ディレクティブにより提供されています。 -
  • Port ディレクティブは Apache-1.3 には自己参照 URL で - 使われるポート番号を設定する、という使用法もありました。 - これは Apache-2.0 では新しい +
  • Port ディレクティブは Apache-1.3 には自己参照 URL で + 使われるポート番号を設定する、という使用法もありました。 + これは Apache-2.0 では新しい ServerName - 構文によって行ないます。一つのディレクティブでホスト名と - 自己参照 URL の両方を設定できるように構文が変更されました。
    • + 構文によって行ないます。一つのディレクティブでホスト名と + 自己参照 URL の両方を設定できるように構文が変更されました。 -
  • ServerName ディレクティブは削除されました。 - リクエストを扱う方法は MPM の選択により決定されるようになりました。 - 現時点では inetd から起動されるように設計された MPM はありません。
    • - -
  • AgentLog ディレクティブ、 - RefererLog ディレクティブ、 - RefererIgnore ディレクティブを提供していた - mod_log_agent と mod_log_referer - モジュールは削除されました。 - Agent ログと refere ログは mod_log_config の +
  • ServerName ディレクティブは削除されました。 + リクエストを扱う方法は MPM の選択により決定されるようになりました。 + 現時点では inetd から起動されるように設計された MPM はありません。
    • + +
  • AgentLog ディレクティブ、 + RefererLog ディレクティブ、 + RefererIgnore ディレクティブを提供していた + mod_log_agent と mod_log_referer + モジュールは削除されました。 + Agent ログと refere ログは mod_log_config の CustomLog - ディレクティブにより実現可能です。
    • + ディレクティブにより実現可能です。 -
  • AddModule ディレクティブと ClearModuleList - ディレクティブは削除されました。これらのディレクティブは、 - モジュールが正しい順番で呼ばれるようにするために使われていました。 - Apache 2.0 の新 API はモジュールが明示的に順番を指定できるように - なっており、これらのディレクティブは必要なくなりました。
    • - -
  • FancyIndexing ディレクティブは削除されました。 - 同じ機能は IndexOptions - ディレクティブの FancyIndexing オプションで - 実現できます。
    • - -
  • mod_negotiation による MultiViews - コンテントネゴシエーション技術は、 - デフォルトのファイルマッチングがより厳密なものに変更されました。 - ネゴシエート可能なファイルの場合にのみ選択されます。 - 以前の挙動は、MultiviewsMatch - ディレクティブを使用することで復活できます。
    • - -
  • (バージョン 2.0.51 から) -

    ErrorHeader ディレクティブは不適切な名前 - だったために廃止され、その機能は Header ディレクティブに統合されました。 - 望みの動作を得るためには ErrorHeader の代わりに

    +
  • AddModule ディレクティブと ClearModuleList + ディレクティブは削除されました。これらのディレクティブは、 + モジュールが正しい順番で呼ばれるようにするために使われていました。 + Apache 2.0 の新 API はモジュールが明示的に順番を指定できるように + なっており、これらのディレクティブは必要なくなりました。
    • + +
  • FancyIndexing ディレクティブは削除されました。 + 同じ機能は IndexOptions + ディレクティブの FancyIndexing オプションで + 実現できます。
    • + +
  • mod_negotiation による MultiViews + コンテントネゴシエーション技術は、 + デフォルトのファイルマッチングがより厳密なものに変更されました。 + ネゴシエート可能なファイルの場合にのみ選択されます。 + 以前の挙動は、MultiviewsMatch + ディレクティブを使用することで復活できます。
    • + +
  • (バージョン 2.0.51 から) +

    ErrorHeader ディレクティブは不適切な名前 + だったために廃止され、その機能は Header ディレクティブに統合されました。 + 望みの動作を得るためには ErrorHeader の代わりに

    Header always set foo bar

    -

    を使ってください。

    • +

    を使ってください。

top
-

その他の変更

+

その他の変更

    -
  • Apache 1.3 で実験的なモジュールだった - mod_auth_digest は - 標準モジュールになりました。
    • - -
  • Apache 1.3 で実験的なモジュールだった mod_mmap_static は - mod_file_cache で置き換えられました。
    • - -
  • Apache の配布は独立した src ディレクトリが - なくなるように、完全に再構成されました。その代わりに、 - ソースは主ディレクトリに論理的に配置されるようになり、 - コンパイルされたサーバのインストールは別ディレクトリへ - 行なうようになりました。
    • +
  • Apache 1.3 で実験的なモジュールだった + mod_auth_digest は + 標準モジュールになりました。
    • + +
  • Apache 1.3 で実験的なモジュールだった mod_mmap_static は + mod_file_cache で置き換えられました。
    • + +
  • Apache の配布は独立した src ディレクトリが + なくなるように、完全に再構成されました。その代わりに、 + ソースは主ディレクトリに論理的に配置されるようになり、 + コンパイルされたサーバのインストールは別ディレクトリへ + 行なうようになりました。
top
-

サードパーティモジュール

+

サードパーティモジュール

-

Apache 2.0 のサーバ API には多くの変更が加えられました。 - Apache 1.3 用の既存のモジュールは Apache 2.0 では修正なしでは - 動きません。詳細は 開発者向け文書 にあります。

+

Apache 2.0 のサーバ API には多くの変更が加えられました。 + Apache 1.3 用の既存のモジュールは Apache 2.0 では修正なしでは + 動きません。詳細は 開発者向け文書 にあります。

Available Languages:  de  |  en  | - es  | - fr  | + es  | + fr  |  ja  |  ko  |  ru 

+

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

Modified: httpd/httpd/branches/2.0.x/docs/manual/urlmapping.html URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.0.x/docs/manual/urlmapping.html?rev=643967&r1=643966&r2=643967&view=diff ============================================================================== --- httpd/httpd/branches/2.0.x/docs/manual/urlmapping.html (original) +++ httpd/httpd/branches/2.0.x/docs/manual/urlmapping.html Wed Apr 2 09:46:34 2008 @@ -2,9 +2,9 @@ Content-Language: en Content-type: text/html; charset=ISO-8859-1 -URI: urlmapping.html.ja.euc-jp +URI: urlmapping.html.ja.utf8 Content-Language: ja -Content-type: text/html; charset=EUC-JP +Content-type: text/html; charset=UTF-8 URI: urlmapping.html.ko.euc-kr Content-Language: ko Copied: httpd/httpd/branches/2.0.x/docs/manual/urlmapping.html.ja.utf8 (from r643946, httpd/httpd/branches/2.0.x/docs/manual/urlmapping.html.ja.euc-jp) URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.0.x/docs/manual/urlmapping.html.ja.utf8?p2=httpd/httpd/branches/2.0.x/docs/manual/urlmapping.html.ja.utf8&p1=httpd/httpd/branches/2.0.x/docs/manual/urlmapping.html.ja.euc-jp&r1=643946&r2=643967&rev=643967&view=diff ============================================================================== --- httpd/httpd/branches/2.0.x/docs/manual/urlmapping.html.ja.euc-jp [euc-jp] (original) +++ httpd/httpd/branches/2.0.x/docs/manual/urlmapping.html.ja.utf8 [iso-8859-1] Wed Apr 2 09:46:34 2008 @@ -1,271 +1,271 @@ - + -URL からファイルシステム上の位置へのマップ - Apache HTTP サーバ +URL からファイルシステム上の位置へのマップ - Apache HTTP サーバ
-

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

-

Apache HTTP サーバ バージョン 2.0

+

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

+

Apache HTTP サーバ バージョン 2.0

<-
-Apache > HTTP サーバ > ドキュメンテーション > バージョン 2.0

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

+Apache > HTTP サーバ > ドキュメンテーション > バージョン 2.0

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

Available Languages:  en  |  ja  |  ko 

-

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

+

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

-
  • 関連するモジュールとディレクティブ
    • +
    top
    -

    関連するモジュールとディレクティブ

    +

    関連するモジュールとディレクティブ

    -
    関連モジュール関連ディレクティブ
    +
    関連モジュール関連ディレクティブ
    top

    DocumentRoot

    -

    リクエストに対してどのファイルを送信するかを決定するときの - Apache のデフォルトの動作は、リクエストの URL-Path (URL のホスト名と - ポート番号の後に続く部分) を取り出して設定ファイルで指定されている +

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

    + の下のディレクトリやファイルがウェブから見える基本のドキュメントの木構造を + なします。

    -

    Apache にはサーバが複数のホストへのリクエストを受け取る - バーチャルホスト の機能もあります。 - この場合、それぞれのバーチャルホストに対して違う +

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

    + を指定することができます。また、mod_vhost_alias + モジュールにより提供されるディレクティブを使って、 + 送信するためのコンテンツの場所をリクエストされた IP + アドレスやホスト名から動的に決めることもできます。

    top
    -

    DocumentRoot 外のファイル

    +

    DocumentRoot 外のファイル

    -

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

    - -

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

    +

    ファイルシステム上の、 + 厳密には 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 ディレクティブ - を使って強力な正規表現に基づいたマッチと置換を行なうことができます。 - たとえば、

    +

    という設定のときは、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 スクリプトとして - 扱います。

    +

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

    top
    -

    ユーザディレクトリ

    +

    ユーザディレクトリ

    -

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

    +

    伝統的に 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 ディレクティブを使います:

    +

    セキュリティの観点から、ウェブからユーザのホームディレクトリへ + 直接アクセスできるようにすることは適切ではありません。ですから、 + 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

    top
    -

    URL リダイレクション

    +

    URL リダイレクション

    -

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

    +

    上の節で説明した設定用のディレクティブは 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 ディレクティブを - 提供しています。たとえば、サイトのホームページを違うサイトにリダイレクト - するけれど、他のリクエストはそのまま扱う、というときは以下の設定を - 使います:

    +

    これは、/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

    top
    -

    リバースプロキシ

    +

    リバースプロキシ

    -

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

    - -

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

    +

    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 に -直接リクエストを送る、ということになります。

    +

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

    top
    -

    リライトエンジン

    +

    リライトエンジン

    -

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

    +

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

    top

    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) と共に - エラーページを返します。このエラーページの外観は +

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

    + ディレクティブで制御され、 + カスタムエラーレスポンス と + 国際化サーバエラーレスポンス で + 説明されているように、柔軟な設定を行なうことができます。

Available Languages:  en  | @@ -273,5 +273,5 @@  ko 

+

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

Modified: httpd/httpd/branches/2.0.x/docs/manual/vhosts/fd-limits.html URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.0.x/docs/manual/vhosts/fd-limits.html?rev=643967&r1=643966&r2=643967&view=diff ============================================================================== --- httpd/httpd/branches/2.0.x/docs/manual/vhosts/fd-limits.html (original) +++ httpd/httpd/branches/2.0.x/docs/manual/vhosts/fd-limits.html Wed Apr 2 09:46:34 2008 @@ -2,9 +2,9 @@ Content-Language: en Content-type: text/html; charset=ISO-8859-1 -URI: fd-limits.html.ja.euc-jp +URI: fd-limits.html.ja.utf8 Content-Language: ja -Content-type: text/html; charset=EUC-JP +Content-type: text/html; charset=UTF-8 URI: fd-limits.html.ko.euc-kr Content-Language: ko