Perl Perl_7 mod_perl 翻訳 Web Server
Perl mp2 翻訳 mod_perl 2.0 サーバ構成 (d188)
目次 - Perl Index
Perl について、復習を兼ねて断片的な情報を掲載して行く連載その d188 回。
今回は、「 mod_perl Home / The mod_perl Web Site / Documentation / mod_perl 2.0 Documentation / User's guide / Part II: Installation / mod_perl 2.0 Server Configuration 」を翻訳して確認します。
正確な内容は 原文 を確認してください。誤解や誤訳がある場合はご指摘ください。
Theme
Perl について、復習を兼ねて断片的な情報を掲載して行く連載その d188 回。
今回は、「 mod_perl Home / The mod_perl Web Site / Documentation / mod_perl 2.0 Documentation / User's guide / Part II: Installation / mod_perl 2.0 Server Configuration 」を翻訳して確認します。
正確な内容は 原文 を確認してください。誤解や誤訳がある場合はご指摘ください。
- 説明 : Description
- mod_perl 構成ディレクティブ : mod_perl configuration directives
- mod_perl の有効化 : Enabling mod_perl
- サーバ構成ディレクティブ : Server Configuration Directives
- サーバライフサイクル ハンドラ : Server Life Cycle Handlers Directives
- プロトコル ハンドラ : Protocol Handlers Directives
- フィルタ ハンドラ : Filter Handlers Directives
- HTTP プロトコル : HTTP Protocl Handler Directives
- スレッドモード固有 : Threads Mode Specific Directives
- デバッグ : Debug Directives
- 引数タイプと許可される場所 : mod_perl Directives Argument Types and Allowed Location
- サーバ起動オプションの回収 : Server Startup Options Retrieval
- Apache 構成ツリーへの Perl インターフェイス : Perl Interface to the Apache Configuration Tree
- @INC の調整 : Adjusting @INC
- 一般的な問題 : General Issues
- メンテナ : Maintainers
- 作者 : Authors
説明 : Description
This chapter provides an in-depth mod_perl 2.0 configuration details.
このチャプタは mod_perl 2.0 構成の深い詳細を提供します。
mod_perl 構成ディレクティブ : mod_perl configuration directives
Similar to mod_perl 1.0, in order to use mod_perl 2.0 a few configuration settings should be added to httpd.conf. They are quite similar to 1.0 settings but some directives were renamed and new directives were added.
mod_perl 1.0 と同じく, mod_perl 2.0 を使うためにはいくつかの構成設定をを httpd.conf に追加する必要があります。 1.0 の設定ととても似ていますがいくつかのディレクティブはリネームされていて新しいディレクティブが追加されています。
mod_perl の有効化 : Enabling mod_perl
To enable mod_perl built as DSO add to httpd.conf:
DSO としてのビルドした mod_perl を有効にするには httpd.conf に追加します:
LoadModule perl_module modules/mod_perl.so
This setting specifies the location of the mod_perl module relative to theServerRoot
setting, therefore you should put it somewhere afterServerRoot
is specified.
この設定は ServerRoot 設定に相対的な mod_perl モジュールの位置を指定します, ですからあなたは ServerRoot を指定した後にそれをどこかに置きます。
If mod_perl has been statically linked it's automatically enabled.
もし mod_perl が静的にリンクされているならそれは自動的に有効化されます。
For Win32 specific details, see the documentation on Win32 configuration.
Win32 固有の詳細は, Win32 configuration ドキュメントを参照します。
Remember that you can't use mod_perl until you have configured Apache to use it. You need to configure Registry scripts or custom handlers.
あなたが Apache で mod_perl の利用を構成するまであなたはそれを使えないことを覚えておいてください。あなたは Registry script or custom handlers の構成が必要です。
サーバ構成ディレクティブ : Server Configuration Directives
<Perl> Sections
With <Perl>...</Perl> sections, it is possible to configure your server entirely in Perl.
<Perl>...</Perl> セクションでは, あなたのサーバ全体を Perl で構成できるようにします。
Please refer to the Apache2::PerlSections manpage for more information.
詳細は (a href="")Apache2::PerlSections(/a) man ページを参照してください。
META: a dedicated chapter with examples?
META: 例示ありの専用のチャプタはいる ?
See also: this directive argument types and allowed location.
=pod, =over, and =cut
It's known that anything written between tokens=pod
and=cut
is ignored by the Perl parser. mod_perl allows you to use the same technique to make Apache ignore things in httpd.conf (similar to # comments). With an exception to=over apache
and=over httpd
sections which are visible to Apache.
=pod and =cut トークン間に書かれたものは Perl パーサから無視されることが知られています (# Perl's Pod)。mod_perl は同じテクニックで httpd.conf 内のものを Apache に ("#" コメントと同じように) 無視させることができます。Apache に表示される =over apache と =over httpd セクションを除きます。
For example the following configuration:
例えば次の構成で:
#file: httpd.conf
=pod
PerlSetVar A 1
=over apache
PerlSetVar B 2
=back
PerlSerVar C 3
=cut
PerlSetVar D 4
Apache will see:
PerlSetVar B 2
PerlSetVar D 4
but not:
PerlSetVar A 1
PerlSetVar C 3
=over httpd
is just an alias to=over apache
. Remember that=over
requires a corresponding=back
.
=over httpd は =over apache への単なるエイリアスです。=over は対応する =back を必要とすることを覚えておいてください。
PerlAddVar
PerlAddVar
is useful if you need to pass in multiple values into the same variable emulating arrays and hashes. For example:
もしあなたが配列やハッシュをエミュレートしておなじ変数に複数の値を渡したいときに PerlAddVar は便利です。例えば:
PerlAddVar foo bar
PerlAddVar foo bar1
PerlAddVar foo bar2
You would retrieve these values with:
あなたはこれらの値をこれで回収します:
my @foos = $r->dir_config->get('foo');
This would fill the @foos
array with 'bar', 'bar1', and 'bar2'.
これは @foos 配列を 'bar', 'bar1', and 'bar2' で満たします。
To pass in hashed values you need to ensure that you use an even number of directives per key. For example:
ハッシュ値で渡すためにはあなたはあなたは key ごとに偶数のディレクティブを使っていることを確認している必要があります。例えば:
PerlAddVar foo key1
PerlAddVar foo value1
PerlAddVar foo key2
PerlAddVar foo value2
You can then retrieve these values with:
あなたはそれからこれでそれらの値を回収します:
my %foos = $r->dir_config->get('foo');
Where %foos
will have a structure like:
ここで %foos はこのような構造になります:
%foos = (
key1 => 'value1',
key2 => 'value2',
);
See also: this directive argument types and allowed location.
PerlConfigRequire
PerlConfigRequire
does the same thing as PerlPostConfigRequire, but it is executed as soon as it is encountered, i.e. during the configuration phase.
PerlConfigRequire は PerlPostConfigRequire と同じことをしますが, それが検出されるとすぐに実行されます, i.e. 構成フェーズの間です。
You should be using this directive to load only files that introduce new configuration directives, used later in the configuration file. For any other purposes (like preloading modules) use PerlPostConfigRequire.
あなたはこのディレクティブを使って後で構成ファイルで使われる新しい構成ディレクトリを導入するファイルだけをロードできます。他の目的 (モジュールの事前読み込みなど) のためには PerlPostConfigRequire を使います。
One of the reasons for avoding using thePerlConfigRequire
directive, is that theSTDERR
stream is not available during the restart phase, therefore the errors will be not reported. It is not a bug in mod_perl but an Apache limitation. UsePerlPostConfigRequire
if you can, and there you have theSTDERR
stream sent to the error_log file (by default).
PerlConfigRequire ディレクティブを使うこと避ける理由のひとつは, STDERR ストリームがリスタートフェーズの間に使えないため, エラーがリポートされないことです。それは mod_perl のバグではなく Apache の制限です。 もしあなたが PerlPostConfigRequire を使うなら, あなたの STDERR ストリームは error_log ファイルに送られます (デフォルトです)。
See also: this directive argument types and allowed location.
PerlLoadModule
ThePerlLoadModule
directive is similar toPerlModule
, in a sense that it loads a module. The difference is that it's used to triggers an early Perl startup. This can be useful for modules that need to be loaded early, as is the case for modules that implement new Apache directives, which are needed during the configuration phase.
PerlLoadModule ディレクティブはモジュールをロードするという意味で, PerlModule と似ています。違いはそれが初期 Perl スタートアップのトリガーに使われることです。これは構成フェーズの間で必要になる, 新しい Apache ディレクティブを実装するモジュールのように, 初期に読み込む必要のあるモジュールで便利です。
See also: this directive argument types and allowed location.
PerlModule
PerlModule Foo::Bar
is equivalent to Perl's:
これは次の Perl と同等です:
require Foo::Bar;
PerlModule
is used to load modules using their package names.
PerlModule はこれらのパッケージ名を使ってモジュールのロードするために使われます。
You can pass one or more module names as arguments to PerlModule
:
あなたは PerlModule への引数として 1 つ以上のモジュール名を渡せます:
PerlModule Apache::DBI CGI DBD::Mysql
Notice, that normally, the Perl startup is delayed until after the configuration phase.
注意して下さい, 通常は, 構成フェーズの後になるまで Perl のスタートアップは遅らされます。
See also: PerlRequire.
See also: this directive argument types and allowed location.
PerlOptions
The directivePerlOptions
provides fine-grained configuration for what were compile-time only options in the first mod_perl generation. It also provides control over what class of Perl interpreter pool is used for a<VirtualHost>
or location configured with<Location>
,<Directory>
, etc.
このディレクティブ PerlOptions は最初の世代の mod_perl ではコンパイルタイムでのみのオプションであったようなきめ細かい構成を提供します。それはまた <VirtualHost> や <Location>, <Directory>, etc でのロケーション構成のために Perl インタープリタプールに使われるクラスの制御も提供します。
$r->is_perl_option_enabled($option)
and$s->is_perl_option_enabled($option)
can be used at run-time to check whether a certain $option has been enabled. (META: probably need to add/move this to the coding chapter)
$r->is_perl_option_enabled($option) と $s->is_perl_option_enabled($option) をランタイムに使うことで特定の $option が有効化どうかをチェックできます。(META: おそらくこれは the coding chapter に add/move する必要があります)
Options are enabled by prepending + and disabled with -.
オプションは + 追加で有効化し - で無効化されます。
See also: this directive argument types and allowed location.
Enable
On by default, can be used to disable mod_perl for a given VirtualHost
. For example:
デフォルトでは, VirtualHost に与えることで mod_perl を無効化することに使えます。例えば:
<VirtualHost ...>
PerlOptions -Enable
</VirtualHost>
Clone
Share the parent Perl interpreter, but give the VirtualHost its own interpreter pool. For example should you wish to fine tune interpreter pools for a given virtual host:
親の Perl インタプリタを共有しますが, VirtualHost にはそれ独自のインタプリタプールを与えます。例えばあなたが与えられたバーチャルホストのためにインタプリタプールを微調整したいとき:
<VirtualHost ...>
PerlOptions +Clone
PerlInterpStart 2
PerlInterpMax 3
</VirtualHost>
This might be worthwhile in the case where certain hosts have their own sets of large-ish modules, used only in each host. By tuning each host to have its own pool, that host will continue to reuse the Perl allocations in their specific modules.
これはそれぞれのホストでしか使われない, それ独自の大規模なモジュールのセットを特定のホストが持っているケースで, 価値があるかもしれません。 それぞれのホストがそれ独自のプールを持つように調整することで, それら特定のモジュールでの Perl アロケーションを継続してリユースします。
InheritSwitches
Off by default, can be used to have aVirtualHost
inherit the value of thePerlSwitches
from the parent server.
デフォルトでオフにすることで, 親サーバから継承した PerlSwitches の値を VirtualHost が使うようにできます。
For instance, when cloning a Perl interpreter, to inherit the base Perl interpreter's PerlSwitches
use:
実際に, Perl インタプリタをクローンするときに, ベースの Perl インタプリタの PerlSwitches を継承するために使うには:
<VirtualHost ...>
PerlOptions +Clone +InheritSwitches
...
</VirtualHost>
Parent
Create a new parent Perl interpreter for the given VirtualHost and give it its own interpreter pool (implies the Clone option).
与えらえた VirtualHost のために新しい親 Perl インタプリタを作成してそれ独自のインタプリタプールを与えます (Clone オプションを伴います)。
A common problem with mod_perl 1.0 was the shared namespace between all code within the process. Consider two developers using the same server and each wants to run a different version of a module with the same name. This example will create two parent Perl interpreters, one for each<VirtualHost>
, each with its own namespace and pointing to a different paths in@INC
:
mod_perl 1.0 での一般的な問題はプロセスのすべてのコード間で共有される名前空間でした。同じサーバを使いそれぞれがことなるモジュールのバージョンを同じ名前で実行したい 2 人の開発者を考えてみます。この例は 1 つずつの <VirtualHost>, それぞれ独自の名前空間と異なる @INC のパスを示す, 2 つの親 Perl インタプリタを作成します。
META: is -Mlib portable? (problems with -Mlib on Darwin/5.6.0?)
META: -Mlib は移植可能 ? (Darwin/5.6.0 の -Mlib での問題?)
<VirtualHost ...>
ServerName dev1
PerlOptions +Parent
PerlSwitches -Mlib=/home/dev1/lib/perl
</VirtualHsot>
<VirtualHost ...>
ServerName dev2
PerlOptions +Parent
PerlSwitches -Mlib=/home/dev2/lib/perl
</VirtualHsot>
Remember that+Parent
gives you a completely new Perl interpreters pool, so all your modifications to@INC
and preloading of the modules should be done again. Consider usingPerlOptions +Clone
if you want to inherit from the parent Perl interpreter.
+Parent はあなたに完全に新しい Perl インタプリタプールを与えることを覚えておいてください, ですから @INC へのあなたのすべての変更とモジュールの事前読み込みは再度実行する必要があります。もしあなたが親 Perl インタプリタから継承したいなら PerlOptions +Clone の利用を考慮します。
Or even for a given location, for something like "dirty" cgi scripts:
また "汚れた" cgi スクリプトのようなもののために, 与えられたロケーションでも:
<Location /cgi-bin>
PerlOptions +Parent
PerlInterpMaxRequests 1
PerlInterpStart 1
PerlInterpMax 1
PerlResponseHandler ModPerl::Registry
</Location>
will use a fresh interpreter with its own namespace to handle each request.
これは各リクエストを処理するためにその独自の名前空間をもつフレッシュなインタプリタを使います。
Perl*Handler
DisablePerl*Handlers
, all compiled-in handlers are enabled by default. The option name is derived from thePerl*Handler
name, by stripping thePerl
andHandler
parts of the word. SoPerlLogHandler
becomesLog
which can be used to disablePerlLogHandler
:
Perl*Handler を無効化します, デフォルトではすべてのコンパイル済みハンドラは有効化されています。このオプションは Perl*Handler からの派生で, 単語のパーツ Perl と Handler をはぎとったものです。 ですから PerlLogHandler は log になり PerlLogHandler の無効化に使います:
PerlOptions -Log
Suppose one of the hosts does not want to allow users to configurePerlAuthenHandler
,PerlAuthzHandler
,PerlAccessHandler
and<Perl>
sections:
ホストのひとつでユーザに PrelAuthenHndler, PerlAuthzHandler, PerlAccessHandler それから <Perl> セクションの構成を許可したくないとします:
<VirtualHost ...>
PerlOptions -Authen -Authz -Access -Sections
</VirtualHost>
Or maybe everything but the response handler:
あるいはレスポンスハンドラ以外すべて:
<VirtualHost ...>
PerlOptions None +Response
</VirtualHost>
AutoLoad
Resolve Perl*Handlers
at startup time, which includes loading the modules from disk if not already loaded.
スタートアップタイムで Perl*Handlers を解決します, それはディスクからまだ読み込んでいないモジュールも含みます。
In mod_perl 1.0, configuredPerl*Handlers
which are not a fully qualified subroutine names are resolved at request time, loading the handler module from disk if needed. In mod_perl 2.0, configuredPerl*Handlers
are resolved at startup time. By default, modules are not auto-loaded during startup-time resolution. It is possible to enable this feature with:
mod_perl 1.0 では, 非完全修飾サブルーチン名で構成された Perl*Handlers はリクエストタイムで解決されて, 必要に応じてディスクからハンドラモジュールが読み込まれていました。mod_perl 2.0 では, 構成された Perl*Handlers はスタートアップタイムで解決されます。デフォルトでは, モジュールはスタートアップタイムでの解決では自動ロードされません。それはこの機能で有効化できます:
PerlOptions +Autoload
Consider this configuration:
この構成を検討します:
PerlResponseHandler Apache::Magick
In this case,Apache::Magick
is the package name, and the subroutine name will default to handler. If theApache::Magick
module is not already loaded,PerlOptions
+Autoload
will attempt to pull it in at startup time. With this option enabled you don't have to explicitly load the handler modules. For example you don't need to add:
この場合, Apache::Magick はパッケージ名で, そのサブルーチン名はデフォルトでハンドラになります。もし Apache::Magick モジュールがまだロードされていないなら, PerlOptions +Autoload はスタートアップタイムでそれをプルすることを試みます。このオプションが有効化されるとあなたはハンドラモジュールを明示的にロードする必要はありません。例えばあなたは次を追加する必要はありません:
PerlModule Apache::Magick
in our example.
私たちの例では。
Another way to preload only specific modules is to add +
when configuring those, for example:
特定のモジュールだけを事前読み込みする他の方法はそれらを構成するときに + を追加することで, 例えば:
PerlResponseHandler +Apache::Magick
will automatically preload the Apache::Magick module
.
自動的に Apache::Magick モジュールを事前読み込みします。
GlobalRequest
Setup the global$r
object for use withApache2->request
Apache2->request で使うためにグローバル $r オブジェクトをセットアップします。
This setting is enabled by default during the PerlResponseHandler
phase for sections configured as:
この設定は次のように構成されたセクションの PerlResponseHandler フェーズの間でデフォルトで有効化されます:
<Location ...>
SetHandler perl-script
...
</Location>
but is not enabled by default for sections configured as:
しかし次のように構成されたセクションではデフォルトで有効化されません:
<Location ...>
SetHandler modperl
...
</Location>
And can be disabled with:
それからこれで無効化できます:
<Location ...>
SetHandler perl-script
PerlOptions -GlobalRequest
...
</Location>
Notice that if you need the global request object during other phases, you will need to explicitly enable it in the configuration file.
もしあなたが他のフェーズの間でグローバルリクエストオブジェクトが必要な場合, あなたは構成ファイルでそれを明示的に有効にする必要があることに注意してください。
You can also set that global object from the handler code, like so:
あなたはハンドラコードからグローバルオブジェクトをセットすることもできます, このように:
sub handler {
my $r = shift;
Apache2::RequestUtil->request($r);
...
}
The+GlobalRequest
setting is needed for example if you use older versions ofCGI.pm
to process the incoming request. Starting from version 2.93,CGI.pm
optionally accepts $r as an argument tonew()
, like so:
+GlobalRequest 設定は例えばあなたが CGI.pm 古いバージョンを使ってインカミングのリクエストを処理する場合に必要とされます。バージョン 2.93 から, CGI.pm はオプションで $r を new() の引数として受け入れます, このように:
sub handler {
my $r = shift;
my $q = CGI->new($r);
...
}
Remember that inside registry scripts you can always get $r at the beginning of the script, since it gets wrapped inside a subroutine and accepts $r as the first and the only argument. For example:
レジストリスクリプトの内部では $r がサブルーチン内にラップされ最初で唯一の引数として受け入れられるため, あなたはスクリプトの先頭で常に $r を取得できることを覚えておいてください。例えば:
#!/usr/bin/perl
use CGI;
my $r = shift;
my $q = CGI->new($r);
...
of course you won't be able to run this under mod_cgi, so you may need to do:
もちろん mod_cgi のもとで実行することはできません, ですからあなたはこれをする必要があります:
#!/usr/bin/perl
use CGI;
my $q = $ENV{MOD_PERL} ? CGI->new(shift @_) : CGI->new();
...
in order to have the script running under mod_perl and mod_cgi.
mod_perl と mod_cgi のもとでスクリプトを実行するためです。
ParseHeaders
Scan output for HTTP headers, same functionality as mod_perl 1.0's PerlSendHeader
, but more robust. This option is usually needs to be enabled for registry scripts which send the HTTP header with:
HTTP ヘッダの出力をスキャンします, mod_perl 1.0 の PerlSendHeader と同じ機能ですが, より堅牢です。このオプションは通常このような HTTP ヘッダを送信するレジストリスクリプトを有効化するために必要とされます:
print "Content-type: text/html\n\n";
MergeHandlers
Turn on merging of Perl*Handler
arrays. For example with a setting:
Perl*Handler 配列のマージをオンにします。例えばこのような設定で:
PerlFixupHandler Apache2::FixupA
<Location /inside>
PerlFixupHandler Apache2::FixupB
</Location>
a request for/inside
only runsApache2::FixupB
(mod_perl 1.0 behavior). But with this configuration:
/inside へのリクエストは Apache2::FixupB のみを実行します (mod_perl 1.0 の動作)。しかしこのような構成では:
PerlFixupHandler Apache2::FixupA
<Location /inside>
PerlOptions +MergeHandlers
PerlFixupHandler Apache2::FixupB
</Location>
a request for/inside
will run bothApache2::FixupA
andApache2::FixupB
handlers.
/inside へのリクエストは Apach2::FixupA と Apache2::FixupB ハンドラの両方を実行します。
SetupEnv
Set up environment variables for each request ala mod_cgi.
各リクエストのために mod_cgi 式で環境変数をセットアップします。
When this option is enabled, mod_perl fiddles with the environment to make it appear as if the code is called under the mod_cgi handler. For example, the$ENV{QUERY_STRING}
environment variable is initialized with the contents ofApache2::args()
, and the value returned byApache2::server_hostname()
is put into$ENV{SERVER_NAME}
.
このオプションが有効にすると, mod_perl は環境変数をいじってコードが mod_cgi ハンドラのもとで呼び出されたように見せます。例えば, $ENV{QUERY_STRING} 環境変数が Apache2::args() のコンテンツで初期化され, Apache2::hostname() による戻り値が $ENV{SERVER_NAME} に入れられます。
But%ENV
population is expensive. Those who have moved to the Perl Apache API no longer need this extra%ENV
population, and can gain by disabling it. A code using the CGI.pm module requirePerlOptions +SetupEnv
because that module relies on a properly populated CGI environment table.
しかし %ENV 実装は高価です。Perl Apache API に移行した人たちはもうこの余分な %ENV 実装を必要とせず, それを無効にすることでゲインできます。CGI.pm モジュールを使うコードはモジュールが適切に実装された CGI 環境テーブルを頼りにしているため PerlOptions +SetupEnv を必要とします。
This option is enabled by default for sections configured as:
このオプションはこのように構成されたセクションでデフォルトで有効化されています:
<Location ...>
SetHandler perl-script
...
</Location>
Since this option adds an overhead to each request, if you don't need this functionality you can turn it off for a certain section:
このオプションはは各リクエストにオーバーヘッドを追加するので, もしあなたがこの機能を必要としないならあなたは特定のセクションでそれを off にできます:
PerlOptions -SetupEnv
<Location ...>
...
</Location>
and then it'll affect the whole server. It can still be enabled for sections that need this functionality.
そしてそれはサーバ全体に影響します。この機能を必要とするセクションには引き続き有効にすることができます。
When this option is disabled you can still read environment variables set by you. For example when you use the following configuration:
このオプションが無効化されていてもあなたはまだあなたがセットした環境変数を読むことができます。例えば次の構成を使い:
PerlOptions -SetupEnv
PerlModule ModPerl::Registry
<Location /perl>
PerlSetEnv TEST hi
SetHandler perl-script
PerlResponseHandler ModPerl::Registory
Options +ExecCGI
</Location>
and you issue a request for this script:
それからあなたはこのスクリプトにリクエストを発行します:
$VAR1 = {
'GATEWAY_INTERFACE' => 'CGI-Perl/1.1',
'MOD_PERL' => 'mod_perl/2.0.1',
'PATH' => 'bin:/usr/bin',
'TEST' => 'hi',
};
Notice that we have got the value of the environment variable TEST
.
私たちは環境変数 TEST の値を取得していることに注意してください。
PerlPassEnv
PerlPassEnv
instructs mod_perl to pass the environment variables you specify to your mod_perl handlers. This is useful if you need to set the same environment variables for your shell as well as mod_perl. For example if you had this in your.bash_profile
:
PerlPassEnv は mod_perl にあなたが指定したあなたの mod_perl ハンドラに環境変数を渡すよう指示します。これはあなたが mod_perl とあなたのシェルに同じ環境変数をセットする必要がある場合に便利です。例えばあなたがあなたの .bash_profile でこれを持っているなら:
export ORACLE_HOME=/oracle
And defined the following in your httpd.conf
:
あなたの httpd.conf で次を定義します:
PerlPassEnv ORACLE_HOME
The your mod_perl handlers would have access to the value via the standard Perl mechanism:
あなたの mod_perl ハンドラは基本的な Perl メカニズムを介してその値にアクセスできるはずです:
my $oracle_home = $ENV{'ORACLE_HOME'};
See also: this directive argument types and allowed location.
PerlPostConfigRequire
PerlPostConfigRequire /home/httpd/perl/lib/startup.pl
is equivalent to Perl's:
require "/home/httpd/perl/lib/startup.pl
APerlRequire
filename argument can be absolute or relative toServerRoot
or a filepath in Perl's@INC
.
PerlRequire のファイル名の引数は絶対 or ServerRoot への相対 or Perl の @INC 内のファイルパスにできます。
You can pass one or more filenames as arguments to PerlPostConfigRequire
:
あなたは PerlPostConfigRequire への引数として 1 つ以上のファイル名を渡せます:
PerlPostConfigRequire path1/startup.pl /path2/startup.pl
PerlPostConfigRequire is used to load files with Perl code to be run at the server startup. It's not executed as soon as it is encountered, but as late as possible during the server startup.
PerlPostConfigRequire はサーバのスタートアップで実行される Perl コードのファイルの読み込みに使われます。それは検出されてもすぐには実行されず, サーバのスタートアップの間でできるだけ遅らされます。
Most of the time you should be using this directive. For example to preload some modules or run things at the server startup). Only if you need to load modules that introduce new configuration directives, used later in the configuration file you should use PerlConfigRequire
.
ほとんどの場合あなたはこの (# PerlPostConfigRequire) ディレクティブを使ったほうがよいです。例えばサーバのスタートアップで何かのモジュールを事前読み込みする or 何かを実行する)。あなたが後で構成ファイルで使われる, 新しい構成ディレクティブを導入するモジュールを読み込みたいだけならあなたは PerlConfigRequire を使ったほうがよいです。
As with any file with Perl code that getsuse()
'd orrequire()
'd, it must return a true value. To ensure that this happens don't forget to add1;
at the end ofstartup.pl
.
use() or require() で取得する Perl コードの他のファイルと同じく, それは 真 値を返す必要があります。startup.pl の最後で 1; を追加し忘れていないかを確認してください。
See also: PerlModule and PerlLoadModule.
See also: this directive argument types and allowed location.
PerlRequire
PerlRequire
does the same thing asPerlPostConfigRequire
, but you have almost no control of when this code is going to be executed. Therefore you should be using eitherPerlConfigRequire
(executes immediately) orPerlPostConfigRequire
(executes just before the end of the server startup) instead. Most of the time you want to use the latter.
PerlRequire は PerlPostConfigRequire と同じことをしますが, あなたはこのコードがいつ実行されるかをほぼ制御できません。従ってあなたはかわりに PerlConfigRequire (即時実行) or PerlPostConfigRequire (サーバスタートアップの終わる直前で実行) を使うとよいです。ほとんどの場合あなたは後者を使うでしょう。
See also: this directive argument types and allowed location.
PerlSetEnv
PerlSetEnv
allows you to specify system environment variables and pass them into your mod_perl handlers. These values are then available through the normal perl%ENV
mechanisms. For example:
PerlSetEnv はあなたにシステムの環境変数を指定してそれらをあなたの mod_perl ハンドラに渡せるようにします。これらの値は普通の perl %ENV メカニズムを通じて利用出来ます。例えば:
PerlSetEnv TEMPLATE_PATH /usr/share/templates
would create$ENV{'TEMPLATE_PATH'}
and set it to/usr/share/templates
.
これは $ENV{'TEMPLATE_PATH'} を作成してそれに /usr/share/templates をセットします。
See also: this directive argument types and allowed location.
PerlSetVar
PerlSetVar
allows you to pass variables into your mod_perl handlers from yourhttpd.conf
. This method is preferable to usingPerlSetEnv
or Apache'sSetEnv
andPassEnv
methods because of the overhead of having to populate%ENV
for each request. An example of how this can be used is:
PerlSetVar はあなたにあなたの httpd.conf からあなたの mod_perl ハンドラに変数を渡せるようにします。このメソッドは各リクエストで %ENV を実装するためのオーバヘッドをもつ PerlSetEnv or Apache の SetEnv and PassEnv メソッドを使うよりも好ましいです。どのようにこれを使うかの例:
PerlSetVar foo bar
To retrieve the value of that variable in your Perl code you would use:
あなたの Perl コードでその変数の値を扱うためにあなたはこれを使います:
my $foo = $r->dir_config('foo');
In this example$foo
would then hold the value 'bar
'. NOTE: that these directives are parsed at request time which is a slower method than using custom Apache configuration directives
この例で $foo は値 'bar' を保持しています。NOTE: これらのディレクティブはカスタム Apache 構成ディレクティブを使うよりも遅い方法でリクエストタイムでパースされます
See also: this directive argument types and allowed location.
PerlSwitches
Now you can pass any Perl's command line switches inhttpd.conf
using thePerlSwitches
directive. For example to enable warnings and Taint checking add:
あなたは PerlSwitches ディレクティブをつかって httod.conf で Perl コマンドラインスイッチを渡せます。例えば warnings と Taint チェックを追加します:
PerlSwitches -wT
As an alternative to usinguse lib
instartup.pl
to adjust@INC
, now you can use the command line switch-I
to do that:
@INC の調整のために startup.pl で use lib を使う代わりに, あなたはそれを行うためにコマンドラインスイッチ -I を使えます:
PerlSwitches -I/home/stas/modperl
You could also use-Mlib=/home/stas/modperl
which is the exact equivalent asuse lib
, but it's broken on certain platforms/version (e.g. Darwin/5.6.0).use lib
is removing duplicated entries, whereas-I
does not.
あなたはまた use lib とまったく同等の -Mlib=/home/stas/modperl を使えますが, それは特定のプラットフォーム/バージョン (e.g. Darwin/5.6.0) では壊れています。 use lib は重複したエントリを削除します, 一方で -I はそうではありません。
See also: this directive argument types and allowed location.
SetHandler
mod_perl 2.0 provides two types ofSetHandler
handlers:modperl
andperl-script
. TheSetHandler
directive is only relevant for response phase handlers. It doesn't affect other phases.
mod_perl 2.0 は 2 つのタイプの SetHandler ハンドラを提供します: modperl と perl-script です。SetHandler ディレクティブはレスポンスフェーズのハンドラにのみ関連します。他のフェーズには影響しません。
See also: this directive argument types and allowed location.
modperl
Configured as:
これで構成されます:
SetHandler modperl
The bare mod_perl handler type, which just calls thePerl*Handler
's callback function. If you don't need the features provided by theperl-script
handler, with themodperl
handler, you can gain even more performance. (This handler isn't available in mod_perl 1.0.)
この裸の mod_perl ハンドラタイプは, 単なる Perl*Handler のコールバックファンクションです。もしあなたは perl-script ハンドラによって提供される機能を必要としないなら, この modperl ハンドラで, あなたはよりよいパフォーマンスをゲインできます。 (このハンドラは mod_perl 1.0 では利用できません。)
Unless thePerl*Handler
callback, running under themodperl
handler, is configured with:
Perl*Handler コールバックが, modperl ハンドラの下で実行されている場合を除きます, これで構成される:
PerlOptions +SetupEnv
or calls:
$r->subprocess_env;
in a void context with no arguments (which has the same effect asPerlOptions +SetupEnv
for the handler that called it), only the following environment variables are accessible via%ENV
:
MOD_PERL
andMOD_PERL_API_VERSION
(always)
PATH
andTZ
(if you had them defined in the shell orhttpd.conf
)
引数のない void コンテキストでは (それは呼び出されたハンドラの PerlOptions +SetupEnv と同じ効果です), 次の環境変数だけが %ENV を介してアクセスできます:
- MOD_PERL と MOD_PERL_API_VERSION (常に)
- PATH と TZ (もしあなたがシェル or httpd.conf でこれらを定義しているなら)
Therefore if you don't want to add the overhead of populating%ENV
, when you simply want to pass some configuration variables fromhttpd.conf
, consider usingPerlSetVar
andPerlAddVar
instead ofPerlSetEnv
andPerlPassEnv
. In your code you can retrieve the values using thedir_config()
method. For example if you set inhttpd.conf
:
したがってもしあなたが %ENV の実装のオーバーヘッドの追加したくなくて, あなたはシンプルにいくつかの構成変数を httpd.conf から渡したいときは, PerlSetEnv と PerlPassEnv のかわりに PerlSetVar と PerlAddVar の利用を考えてください。あなたのコードであなたは dir_config() メソッドを使って値を扱えます。例えばあなたがこれを httpd.conf でセットしているなら:
<Location /print_env2>
SetHandler modperl
PerlResponseHandler Apache2::VarTest
PerlSetVar VarTest VarTestValue
</Location>
this value can be retrieved inside Apache2::VarTest::handler()
with:
この値は Apache2::VarTest::handler() の内部で扱われます:
$r->dir_config('VarTest');
Alternatively use the Apache core directivesSetEnv
andPassEnv
, which always populater->subprocess_env
, but this doesn't happen until the Apachefixups
phase, which could be too late for your needs.
あるいは Apache core ディレクティブの SetEnv や PassEnv を使います, それは常に r->subprocess_env を実装しますが, これは Apache のフィックスアップ (# fixups) フェーズまで発生しませんし, あなたのニーズにたいして遅すぎるかもしれません。
Notice also that this handler does not reset %ENV after each request's response phase, so if one response handler has changed %ENV without localizing the change, it'll affect other handlers running after it as well.
このハンドラは各リクエストのレスポンスフェーズの後で %ENV をリセットしませんので, もしあるレスポンスハンドラがその変更をローカライズせずに %ENV を変更すると, それはその後で実行される他のハンドラに影響することにも注意しておいてください。
perl-script
Configured as:
構成されます:
SetHandler perl-script
Most mod_perl handlers use the perl-script handler. Among other things it does:
ほとんどの mod_perl ハンドラは perl-script ハンドラを使います。なかでもそれは行います:
PerlOptions +GlobalRequest
is in effect only during thePerlResponseHandler
phase unless:
PerlOptions -GlobalRequest
is specified.
- PerlOptions +GlobalRequest は PerlResponseHandler フェーズの間でのみ影響があります 次を除いて:
PerlOptions -GlobalRequest
が指定されている。
PerlOptions +SetupEnv
is in effect unless:
PerlOptions -SetupEnv
is specified.
- PerlOptions +SetupEnv は効果があります 次を除いて:
PerlOptions -SetupEnv
が指定されている.
STDIN
andSTDOUT
get tied to the request object$r
, which makes possible to read fromSTDIN
and print directly toSTDOUT
viaCORE::print()
, instead of implicit calls like$r->puts()
.
- STDIN と STDOUT はリクエストオブジェクト $r に tie され, $r->puts() のような暗黙の呼び出しのかわりに, STDIN からの読み取りと CORE::print() を介した STDOUT への直接の出力ができるようになります。
- Several special global Perl variables are saved before the response handler is called and restored afterwards (similar to mod_perl 1.0). This includes:
%ENV
,@INC
,$/
,STDOUT
's $| andEND blocks array (PL_endav
).
- いくつかの特別なグローバルな Perl 変数はレスポンスハンドラが呼び出される前に保存されそのあとで復元されます (mod_perl 1.0 と同じです)。これは含みます: %ENV, @INC, $/, STDOUT の $| と END ブロック配列 (PL_endav)。
- Entries added to
%ENV
are passed on to thesubprocess_env
table, and are thus accessible viar->subprocess_env
during the laterPerlLogHandler
andPerlCleanupHandler
phases.
- %ENV に追加されたエントリは subprocess_env テーブルに渡されるので, 後の PerlLogHandler と PerlCleacupHandler フェーズで r->subprocess_env を介してアクセスできます。
Examples
Let's demonstrate the differences between themodperl
and theperl-script
core handlers in the following example, which represents a simple mod_perl response handler which prints out the environment variables as seen by it:
次の例で modperl と perl-script コアハンドラの間の違いを示しましょう, それは環境変数を出力して見れるようにするシンプルな mod_perl レスポンスハンドラを表しています:
file:MyApache2/PrintEnv1.pm
-----------------------
package MyApache2::PrintEnv1;
use strict;
use Apache2::RequestRec (); # for $r->content_type
use Apache2::RequestIO (); # for print
use Apache2::Const -compile => ':common';
sub handler {
my $r = shift;
$r->content_type('text/plain');
for (sort keys %ENV) {
print "$_ => $ENV{$_}\n";
}
return Apache2::Const::OK;
}
1;
This is the required configuration:
これは次の構成を必要とします:
PerlModule MyApache2::PrintEnv1
<Location /print_env1>
SetHandler perl-script
PerlResponseHnadler MyApache2::PrintEnv1
</Location>
Now issue a request to http://localhost/print_env1
and you should see all the environment variables printed out.
これで http://localhost/print_env1 へのリクエストを発行するとあなたは出力されたすべての環境変数を見れるはずです。
Here is the same response handler, adjusted to work with the modperl
core handler:
こちらは同じレスポンスハンドラを, modperl コアハンドラで動作するように調整したものです:
file:MyApache2/PrintEnv2.pm
-----------------------
package MyApache2::PrintEnv2;
use strict;
use Apache2::RequestRec (); # for $r->content_type
use Apache2::RequestIO (); # for $r->print
use Apache2::Const -compile => ':common';
sub handler {
my $r = shift;
$r->content_type('text/plain');
$r->subprocess_env;
for (sort keys %ENV) {
$r->print("$_ => $ENV{$_}\n");
}
return Apache2::Const::OK;
}
1;
The configuration now will look as:
この構成はこのようになります:
PerlModule MyApache2::PrintEnv2
<Location /print_env2>
SetHandler modperl
PerlResponseHandler MyApache2::PrintEnv2
</Location>
MyApache2::PrintEnv2
cannot useprint()
and therefore uses$r->print()
to generate a response. Under themodperl
core handler%ENV
is not populated by default, thereforesubprocess_env()
is called in a void context. Alternatively we could configure this section to do:
MyApache2::PrintEnv2 は print() を使えませんのでレスポンスの生成に $r->print() を使います。modperl コアハンドラのもとで %ENV はデフォルトでは実装されません, したがって void コンテキストで subprocess_env() が呼ばれます。あるいは私たちはこのセクションをこのように構成することもできます:
PerlOptions +SetupEnv
If you issue a request to http://localhost/print_env2, you should see all the environment variables printed out as with http://localhost/print_env1.
もしあなたが http://localhost/print_env2 にリクエストを発行すると, あなたは http://localhost/print_env1 と同じく出力されたすべての環境変数を見ることができるはずです。
サーバライフサイクル ハンドラ : Server Life Cycle Handlers Directives
See Server life cycle.
PerlOpenLogsHandler
See PerlOpenLogsHandler.
PerlPostConfigHandler
See PerlPostConfigHandler.
PerlChildInitHandler
See PerlChildInitHandler.
PerlChildExitHandler
See PerlChildExitHandler.
プロトコル ハンドラ : Protocol Handlers Directives
See Protocol handlers.
PerlPreConnectionHandler
See PerlPreConnectionHandler.
PerlProcessConnectionHandler
See PerlProcessConnectionHandler.
フィルタ ハンドラ : Filter Handlers Directives
mod_perl filters are described in the filter handlers tutorial, Apache2::Filter and Apache2::FilterRec manpages.
mod_perl フィルタは filter handlers tutorial, Apache2::Filter と Apache2::FilterRec man ページで説明されています。
The following filter handler configuration directives are available:
次のフィルタハンドラ構成ディレクティブは利用可能です:
PerlInputFilterHandler
See PerlInputFilterHandler.
PerlOutputFilterHandler
See PerlOutputFilterHandler.
PerlSetInputFilter
See PerlSetInputFilter.
PerlSetOutputFilter
See PerlSetInputFilter.
HTTP プロトコル : HTTP Protocl Handler Directives
See HTTP protocol handlers.
PerlPostReadRequestHandler
See PerlPostReadRequestHandler.
PerlTransHandler
See PerlTransHandler.
PerlMapToStorageHandler
See PerlMapToStorageHandler.
PerlInitHandler
See PerlInitHandler.
PerlHeaderParserHandler
See PerlHeaderParserHandler.
PerlAccessHandler
See PerlAccessHandler.
PerlAuthzHandler
See PerlAuthenHandler.
PerlTypeHandler
See PerlTypeHandler.
PerlFixupHandler
See PerlFixupHandler.
PerlResponseHandler
See PerlResponseHandler.
PerlLogHandler
See PerlLogHandler.
PerlCleanupHandler
See PerlCleanupHandler.
スレッドモード固有 : Threads Mode Specific Directives
These directives are enabled only in a threaded mod_perl+Apache combo:
これらのディレクティブはスレッド化された mod_perl+Apache コンボでのみ有効化されます:
PerlInterpStart
The number of interpreters to clone at startup time.
Default value: 3
スターアップタイムでクローンするインタプリタの数です。
デフォルト値: 3
See also: this directive argument types and allowed location.
PerlInterpMax
If all running interpreters are in use, mod_perl will clone new interpreters to handle the request, up until this number of interpreters is reached. whenPerlInterpMax
is reached, mod_perl will block (viaCOND_WAIT()
) until one becomes available (signaled viaCOND_SIGNAL()
).
Default value: 5
もしすべての実行中のインタプリタが使われているなら, mod_perl はリクエストを処理するために新しいインタプリタをクローンします, このインタプリタの数に到達するまで。PerlInterpMax に達すると, mod_perl はそれが (COND_SIGNAL() を介したシグナルで) 利用可能になるまで (COND_WAIT() を介して) ブロックします 。
デフォルト値: 5
See also: this directive argument types and allowed location.
PerlInterpMinSpare
The minimum number of available interpreters this parameter will clone interpreters up toPerlInterpMax
, before a request comes in.
Default value: 3
利用可能なインタプリタの最小の数でこのパラメータはリクエストがくる前に, PerlInterpMax までインタプリタをクローンします。
デフォルト値: 3
See also: this directive argument types and allowed location.
PerlInterpMaxSpare
mod_perl will throttle down the number of interpreters to this number as those in use become available.
Default value: 3
mod_perl は利用中のインタプリタが利用可能になるとこの数までそれらを絞り込みます。
デフォルト値: 3
PerlInterpMaxRequests
The maximum number of requests an interpreter should serve, the interpreter is destroyed when the number is reached and replaced with a fresh clone.
Default value: 2000
インタプリタがサーブするべきリクエストの最大数, インタプリタはこの数に達すると破棄されフレッシュなクローンにリプレイスされます。
デフォルト値: 2000
See also: this directive argument types and allowed location.
デバッグ : Debug Directives
PerlTrace
ThePerlTrace
is used for tracing the mod_perl execution. This directive is enabled when mod_perl is compiled with theMP_TRACE=1
option.
PerlTrace は mod_perl の実行のトレースに使われます。このディレクティブは mod_perl が MP_TRACE=1 オプションでコンパイルされたときに有効化されます。
To enable tracing, add to httpd.conf
:
トレースを有効にするためには, httpd.conf に追加します:
PerlTrace [level]
where level
is either:
ここでの level はどちらかです:
all
which sets maximum logging and debugging levels;
これはロギングとデバッギングレベルを最大にセットします;
a combination of one or more option letters from the following list:
次のリストからの 1 つ以上のコンビネーション:
a Apache API の相互作用 : Apache API interaction
c ディレクティブハンドラの構成 : configuration for directive handlers
d ディレクティブの処理 : directive processing
f フィルタ : filters
e 環境変数 : environment variables
g グローバル管理 : globals management
h ハンドラ : handlers
i インタプリタプール管理 : interpreter pool management
m メモリ割り当て : memory allocations
o I/O
r Perl ランタイムの相互作用 : Perl runtime interaction
s Perl セクション : Perl sections
t ベンチマーク的なタイミング : benchmark-ish timings
Tracing options add to the previous setting and don't override it. So for example:
トレーシングオプションは前の設定に追加し上書きはしません。ですから例えば:
PerlTrace c
...
PerlTrace f
will set tracing level first to 'c' and later to 'cf'. If you wish to override settings, unset any previous setting by assigning 0 (zero), like so:
トレーシングレベルは最初に 'c' その後に 'cf' にセットされます。もしあなたが設定を上書きしたいなら, 前の設定を 0 (zero) を割り当てることでアンセットします, このように:
PerlTrace c
...
PerlTrace 0
PerlTrace f
now the tracing level is set only to 'f'. You can't mix the number 0 with letters, it must be alone.
これでトレーシングレベルは 'f' でのみセットされます。あなたは番号 0 と文字のミックスはできません, それは単独でなければいけません。
When PerlTrace is not specified, the tracing level will be set to the value of the $ENV{MOD_PERL_TRACE} environment variable.
PerlTrace が指定されていないとき, トレーシングレベルは $ENV{MOD_PERL_TRACE} 環境変数の値にセットされます。
See also: this directive argument types and allowed location.
引数タイプと許可される場所 : mod_perl Directives Argument Types and Allowed Location
The following table shows where in the configuration files mod_perl configuration directives are allowed to appear, what kind and how many arguments they expect:
General directives:
次のテーブルは構成ファイルで mod_perl 構成ディレクティブがどこに現れることが許可されているか, どのような種類といくつの引数が期待されているかを示しています:
一般的なディレクティブ:
Directive Arguments Scope
--------------------------------------------
PerlSwitches ITERATE SRV
PerlRequire ITERATE SRV
PerlConfigRequire ITERATE SRV
PerlPostConfigRequire ITERATE SRC
PerlModule ITERATE SRV
PerlLoadModule RAW_ARGS SRV
PerlOptions ITERATE DIR
PerlSetVar TAKE2 DIR
PerlAddVar ITERATE2 DIR
PerlSetEnv TAKE2 DIR
PerlPassEnv TAKE1 SRV
<Perl> Sections RAW_ARGS SRV
PerlTrace TAKE1 SRV
Handler assignment directives:
ハンドラをアサインするディレクティブ:
Directive Arguments Scope
--------------------------------------------
PerlOpenLogsHandler ITERATE SRV
PerlPostConfigHandler ITERATE SRV
PerlChildInitHandler ITERATE SRV
PerlChildExitHandler ITERATE SRV
PerlPreConnectionHandler ITERATE SRV
PerlProcessConnectionHandler ITERATE SRV
PerlPostReadRequestHandler ITERATE SRV
PerlTransHandler ITERATE SRV
PerlMapToStorageHandler ITERATE SRV
PerlInitHandler ITERATE DIR
PerlHeaderParserHandler ITERATE DIR
PerlAccessHandler ITERATE DIR
PerlAuthenHandler ITERATE DIR
PerlAuthzHandler ITERATE DIR
PerlTypeHandler ITERATE DIR
PerlFixupHandler ITERATE DIR
PerlResponseHandler ITERATE DIR
PerlLogHandler ITERATE DIR
PerlCleanupHandler ITERATE DIR
PerlInputFilterHandler ITERATE DIR
PerlOutputFilterHandler ITERATE DIR
PerlSetInputFilter ITERATE DIR
PerlSetOutputFilter ITERATE DIR
Perl Interpreter management directives:
Perl インタプリタのマネージメントディレクティブ:
Directive Arguments Scope
--------------------------------------------
PerlInterpStart TAKE1 SRV
PerlInterpMax TAKE1 SRV
PerlInterpMinSpare TAKE1 SRV
PerlInterpMaxSpare TAKE1 SRV
PerlInterpMaxRequests TAKE1 SRV
mod_perl 1.0 back-compatibility directives:
mod_perl 1.0 後方互換ディレクティブ:
Directive Arguments Scope
--------------------------------------------
PerlHandler ITERATE DIR
PerlSendHeader FLAG DIR
PerlSetupEnv FLAG DIR
PerlTaintCheck FLAG SRV
PerlWarn FLAG SRV
The Arguments
column represents the type of arguments directives accepts, where:
Arguments カラムはディレクティブが受け入れる引数のタイプを表します, こちら:
- ITERATE
Expects a list of arguments.
引数リストを期待します。
- ITERATE2
Expects one argument, followed by at least one or more arguments.
1 つの引数を期待して, 少なくとも 1 つ以上の引数が続きます。
- TAKE1
Expects one argument only.
1 つの引数のみを期待します。
- TAKE2
Expects two arguments only.
2 つの引数の実を期待します。
- FLAG
One of On or Off (case insensitive).
On か Off のどちらかです (大小文字は区別しません)。
- RAW_ARGS
The function parses the command line by itself.
このファンクションはそれ自身でコマンドラインをパースします。
The Scope
column shows the location the directives are allowed to appear in:
Scope カラムはディレクティブが現れることが許可されたロケーションを示します:
- SRV
Global configuration and <VirtualHost> (mnemonic: SeRVer). These directives are defined as
RSRC_CONF
in the source code.
グローバル構成と <VirtualHost> です (ニーモニック: SeRVer)。これらのディレクティブはソースコード内の RSRC_CONF として定義されています。
- DIR
<Directory>
,<Location>
,<Files>
and all their regular expression variants (mnemonic: DIRectory). These directives can also appear in.htaccess
files. These directives are defined asOR_ALL
in the source code.
<Directory>, <Location>, <Files> とそれらすべての正規表現バリアントです (ニーモニック: DIRectory)。これらのディレクティブは .htaccess ファイル内でも表すことができます。これらのディレクティブはソースコード内で OR_ALL として定義されています。
These directives can also appear in the global server configuration and <VirtualHost>
.
これらのディレクティブはグローバルサーバ構成と <VirtualHost> 内でも表すことが出来ます。
Apache specifies other allowed location types which are currently not used by the core mod_perl directives and their definition can be found ininclude/httpd_config.h
(hint: search forRSRC_CONF
).
Apache は include/httpd.config.h で定義を見つけることができる現在コア mod_perl ディレクティブでは使われていない他の許可されたロケーションタイプを指定します (ヒント: RSRC_CONF で検索)。
Also see Stacked Handlers.
サーバ起動オプションの回収 : Server Startup Options Retrieval
Inside httpd.conf
one can do conditional configuration based on the define options passed at the server startup. For example:
httpd.conf の内側でサーバスタートアップで渡される定義したオプションに基づいた条件付き構成ができます。例えば:
<IfDefine PERLDB>
<Perl>
use Apache::DB ();
Apache::DB->init;
<Perl>
<Location />
PerlFixupHandler Apache::DB
</Location>
</IfDefine>
So only when the server is started as:
ですからサーバがこのようにスタートされたときのみ:
% httpd -DPERLDB
The configuration insideIfDefine
will have an effect. If you want to have some configuration section to have an effect if a certain define wasn't defined use!
, for example here is the opposite of the previous example:
IfDefine の内側の構成が効果をもちます。もしあなたが特定の定義が定義されていない場合に効果をもつ構成セクションを持ちたい場合は ! を使います, 例えばこちらは前の例の反対です:
<IfDefine !PERLDB>
# ...
</IfDefine>
If you need to access any of the startup defines in the Perl code you use Apache2::ServerUtil::exists_config_define()
. For example in a startup file you can say:
もしあなたが Perl コード内でスタートアップ定義へのいずれかへのアクセスが必要なら Apache2::ServerUtil::exists_config_define() を使います。例えばスタートアップファイル内であなたはこのように言えます:
use Apache2::ServerUtil ();
if (Apache2::ServerUtil::extists_config_define("PERLDB")) {
require Apache::DB;
Apache::DB->init;
}
For example to check whether the server has been started in a single mode use:
例えばサーバがシングルモードでスタートしているかどうかをチェックするために使います:
if (Apache2::ServerUtil::exists_config_define("ONE_PROCESS")) {
print "Running in a single mode";
}
MODPERL2 定義オプション : MODPERL2 Define Option
When running under mod_perl 2.0 a special configuration "define" symbolMODPERL2
is enabled internally, as if the server had been started with-DMODPERL2
. For example this can be used to write a configuration file which needs to do something different whether it's running under mod_perl 1.0 or 2.0:
mod_perl 2.0 のもとで実行するとき特別な構成 "define" シンボル MODPERL2 が内部で有効化されます, サーバが -DMODPERL2 でスタートされたのと同様です。例えばこれは mod_perl 1.0 と 2.0 で実行されているかどうかで違う何かを行うように構成ファイルを書くことに使われます。
<IfDefine MODPERL2>
# 2.0 configration
</IfDefine>
<IfDefine !MODPERL2>
# else
</IfDefine>
From within Perl code this can be tested with Apache2::ServerUtil::exists_config_define()
, for example:
Perl コードの中からは Apache2::ServerUtil::exists_config_define() でこれをテストできます, 例えば:
use Apache2::ServerUtil ();
if (Apache2::ServerUtil::exists_config_define("MODPERL2")) {
# some 2.0 specific code
}
Apache 構成ツリーへの Perl インターフェイス : Perl Interface to the Apache Configuration Tree
For now refer to theApache2::Directive
manpage and the testt/response/TestApache2/conftree.pm
in the mod_perl source distribution.
META: need help to write the tutorial section on this with examples.
今のところは Apache2::Directive の man ページと mod_perl ソースディストリビューションの中のテスト t/response/TestApache2/conftree.pm を参照します。
META: これに例示でチュートリアルセクションを書くためのヘルプが必要。
@INC の調整 : Adjusting @INC
You can always adjust contents of @INC before the server starts. There are several ways to do that.
あなたはサーバがスタートする前に @INC のコンテンツをいつでも調整できます。それを行う方法はいくつかあります。
- startup.pl
In the startup file you can use the
lib
pragma like so:
startup ファイルであなたはこのように lib プラグマを使えます:
use lib qw(/home/httpd/project1/lib /tmp/lib);
use lib qw(/home/httpd/project2/lib);
- httpd.conf
In httpd.conf you can use the PerlSwitches directive to pass arguments to perl as you do from the command line, e.g.:
httpd.conf であなたはコマンドラインであなたが perl に引数を渡すのと同じように PerlSwitches ディレクティブを使えます, e.g.:
PerlSwitches -I/home/httpd/project1/lib -I/tmp/lib
PerlSwitches -I/home/httpd/project2/lib
PERL5LIB と PERLIB 環境変数 : PERL5LIB and PERLLIB Environment Variables
The effect of thePERL5LIB
andPERLLIB
environment variables on@INC
is described in the perlrun manpage. mod_perl 2.0 doesn't do anything special about them.
@INC での PERL5LIB と PERLLIB 環境変数の影響は perlrun man ページで説明されています。mod_perl 2.0 はそれらについて特別な何かは行いません。
It's important to remind that bothPERL5LIB
andPERLLIB
are ignored when the taint mode (PerlSwitches -T
) is in effect. Since you want to make sure that your mod_perl server is running under the taint mode, you can't use thePERL5LIB
andPERLLIB
environment variables.
PERL5LIB と PERLLIB は両方とも taint モードが有効 (PerlSwitches -T) な場合に無視されることを覚えておくのは重要です。ですからあなたがあなたの mod_perl サーバを taint モードで実行していることを確認したいなら, あなたは PERL5LIB と PERLLIB 環境変数を使うことはできません。
However there is theperl5lib
module on CPAN, which, if loaded, bypasses perl's security and will affect@INC
. Use it only if you know what you are doing.
しかしながら CPAN には perl5lib モジュールがあり, それが, ロードされると, perl のセキュリティをバイパスして @INC に作用します。あなたが何をするのかあなたが知っている場合にのみそれを使ってください。
バーチャルホスト毎の @INC の変更 : Modifying @INC on a Per-VirtualHost
If Perl used with mod_perl was built with ithreads support one can specify different@INC
values for different VirtualHosts, using a combination ofPerlOptions +Parent
andPerlSwitches
. For example:
もし mod_perl で使われる Perl が ithreads サポートでビルドされているならそれは, PerlOptions +Parent と PerlSwitches の組み合わせを使って, 異なる VirtualHost のための異なる @INC の値を指定出来ます. 例えば:
<VirtualHost ...>
ServerName dev1
PerlOptions +Parent
PerlSwitches -I/home/dev1/lib/perl
</VirtualHost>
<VirtualHost ...>
ServerName dev2
PerlOptions +Parent
PerlSwitches -I/home/dev2/lib/perl
</VirtualHost>
This technique works under any MPM with ithreads-enabled perl. It's just that under prefork your procs will be huge, because you will build a pool of interpreters in each process. While the same happens under threaded mpm, there you have many threads per process, so you need just 1 or 2 procs and therefore less memory will be used.
このテクニックは ithreads が有効化された perl のどの MPM のもとでも動作します。それは prefork のもとではあなたが各プロセスでインタプリタのプールをビルドすることになるので, あなたの proc がただ巨大になるだけです。スレッド化された mpm のもとでも同じことが起こりますが, あなたはプロセス毎に多くのスレッドをもつので, あなたは 1 つか 2 つの proc を必要とするだけとなり使われるメモリが少なくなります。
一般的な問題 : General Issues
メンテナ : Maintainers
Maintainer is the person(s) you should contact with updates, corrections and patches.
メンテナはアップデート, 修正それからパッチであなたが連絡をするとよい人々です。
- Stas Bekman [http://stason.org/]
作者 : Authors
- Doug MacEachern
- Stas Bekman [http://stason.org/]
Only the major authors are listed above. For contributors see the Changes file.
主な作者のみが上記にリストされます。コントリビュータは Changes ファイルを参照します。
NEXT
次回は、「 Apache Server Configuration Customization in Perl 」を「 mod_perl 」公式サイト (https://perl.apache.org/index.html) より確認します。
参考情報は書籍「 続・初めての Perl 改訂版 」, 「 Effective Perl 第 2 版 」を中心に perldoc, Wikipedia および各 Web サイト。それと詳しい先輩。
目次 - Perl Index
Perl mp2 翻訳 Web コンテンツ圧縮の FAQ (d228)
Perl mp2 翻訳 既知のブラウザのバグの回避策をいくつか (d227)
Perl mp2 翻訳 Perl と Apache でのキュートなトリック (d226)
Perl mp2 翻訳 テンプレートシステムの選択 (d225)
Perl mp2 翻訳 大規模 E コマースサイトの構築 (d224)
Perl mp2 翻訳 チュートリアル (d223)
Perl mp2 翻訳 既知のブラウザのバグの回避策をいくつか (d227)
Perl mp2 翻訳 Perl と Apache でのキュートなトリック (d226)
Perl mp2 翻訳 テンプレートシステムの選択 (d225)
Perl mp2 翻訳 大規模 E コマースサイトの構築 (d224)
Perl mp2 翻訳 チュートリアル (d223)