blog20100901

2013/08/20 - プログラミング言語 Perl にまつわる etc. - Perl monger
参考 : perldoc, perldoc.jp, search.cpan.org, perldoc.perl.org ...
「 初めての Perl 第 6 版 」(オライリー・ジャパン発行 ISBN978-4-87311-567-2) 」
「 続・初めての Perl 改訂版 」(オライリー・ジャパン発行 ISBN4-87311-305-9) 」
「 Effective Perl 第 2 版 」(翔泳社発行 ISBN978-4-7981-3981-4) 」 ... etc,.

Perl Perl_7 mod_perl 翻訳 Web Server

Perl mp2 翻訳 mod_perl 2.0 サーバ構成 (d188)

目次 - Perl Index


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


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 the ServerRoot setting, therefore you should put it somewhere after ServerRoot 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 the PerlConfigRequire directive, is that the STDERR 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. Use PerlPostConfigRequire if you can, and there you have the STDERR 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


The PerlLoadModule directive is similar to PerlModule, 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 directive PerlOptions 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 a VirtualHost inherit the value of the PerlSwitches 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 using PerlOptions +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


Disable Perl*Handlers, all compiled-in handlers are enabled by default. The option name is derived from the Perl*Handler name, by stripping the Perl and Handler parts of the word. So PerlLogHandler becomes Log which can be used to disable PerlLogHandler:

Perl*Handler を無効化します, デフォルトではすべてのコンパイル済みハンドラは有効化されています。このオプションは Perl*Handler からの派生で, 単語のパーツ Perl と Handler をはぎとったものです。 ですから PerlLogHandler は log になり PerlLogHandler の無効化に使います:

PerlOptions -Log

Suppose one of the hosts does not want to allow users to configure PerlAuthenHandler, 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, configured Perl*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, configured Perl*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 the Apache::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 with Apache2->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 of CGI.pm to process the incoming request. Starting from version 2.93, CGI.pm optionally accepts $r as an argument to new(), 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 runs Apache2::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 both Apache2::FixupA and Apache2::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 of Apache2::args(), and the value returned by Apache2::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 require PerlOptions +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

A PerlRequire filename argument can be absolute or relative to ServerRoot 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 gets use()'d or require()'d, it must return a true value. To ensure that this happens don't forget to add 1; at the end of startup.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 as PerlPostConfigRequire, but you have almost no control of when this code is going to be executed. Therefore you should be using either PerlConfigRequire (executes immediately) or PerlPostConfigRequire (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 your httpd.conf. This method is preferable to using PerlSetEnv or Apache's SetEnv and PassEnv 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 in httpd.conf using the PerlSwitches directive. For example to enable warnings and Taint checking add:

あなたは PerlSwitches ディレクティブをつかって httod.conf で Perl コマンドラインスイッチを渡せます。例えば warnings と Taint チェックを追加します:

PerlSwitches -wT

As an alternative to using use lib in startup.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 as use 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 of SetHandler handlers: modperl and perl-script. The SetHandler 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 the Perl*Handler's callback function. If you don't need the features provided by the perl-script handler, with the modperl 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 the Perl*Handler callback, running under the modperl 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 as PerlOptions +SetupEnv for the handler that called it), only the following environment variables are accessible via %ENV:

  • MOD_PERL and MOD_PERL_API_VERSION (always)

  • PATH and TZ (if you had them defined in the shell or httpd.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 from httpd.conf, consider using PerlSetVar and PerlAddVar instead of PerlSetEnv and PerlPassEnv. In your code you can retrieve the values using the dir_config() method. For example if you set in httpd.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 directives SetEnv and PassEnv, which always populate r->subprocess_env, but this doesn't happen until the Apache fixups 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 the PerlResponseHandler 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 and STDOUT get tied to the request object $r, which makes possible to read from STDIN and print directly to STDOUT via CORE::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 $| and END blocks array (PL_endav).



  • いくつかの特別なグローバルな Perl 変数はレスポンスハンドラが呼び出される前に保存されそのあとで復元されます (mod_perl 1.0 と同じです)。これは含みます: %ENV, @INC, $/, STDOUT の $| と END ブロック配列 (PL_endav)。



  • Entries added to %ENV are passed on to the subprocess_env table, and are thus accessible via r->subprocess_env during the later PerlLogHandler and PerlCleanupHandler phases.



  • %ENV に追加されたエントリは subprocess_env テーブルに渡されるので, 後の PerlLogHandler と PerlCleacupHandler フェーズで r->subprocess_env を介してアクセスできます。


Examples


Let's demonstrate the differences between the modperl and the perl-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 use print() and therefore uses $r->print() to generate a response. Under the modperl core handler %ENV is not populated by default, therefore subprocess_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::FilterApache2::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. when PerlInterpMax is reached, mod_perl will block (via COND_WAIT()) until one becomes available (signaled via COND_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 to PerlInterpMax, 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


The PerlTrace is used for tracing the mod_perl execution. This directive is enabled when mod_perl is compiled with the MP_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 as OR_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 in include/httpd_config.h (hint: search for RSRC_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 inside IfDefine 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" symbol MODPERL2 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 the Apache2::Directive manpage and the test t/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 the PERL5LIB and PERLLIB 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 both PERL5LIB and PERLLIB 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 the PERL5LIB and PERLLIB environment variables.

PERL5LIB と PERLLIB は両方とも taint モードが有効 (PerlSwitches -T) な場合に無視されることを覚えておくのは重要です。ですからあなたがあなたの mod_perl サーバを taint モードで実行していることを確認したいなら, あなたは PERL5LIB と PERLLIB 環境変数を使うことはできません。
However there is the perl5lib 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 of PerlOptions +Parent and PerlSwitches. For example:

もし mod_perl で使われる Perl が ithreads サポートでビルドされているならそれは, PerlOptions +ParentPerlSwitches の組み合わせを使って, 異なる 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)の記事
 Perl mp2 翻訳 Web コンテンツ圧縮の FAQ (d228) (2023-10-11 23:49)
 Perl mp2 翻訳 既知のブラウザのバグの回避策をいくつか (d227) (2023-05-26 15:41)
 Perl mp2 翻訳 Perl と Apache でのキュートなトリック (d226) (2023-05-19 17:05)
 Perl mp2 翻訳 テンプレートシステムの選択 (d225) (2022-08-15 22:23)
 Perl mp2 翻訳 大規模 E コマースサイトの構築 (d224) (2022-06-15 20:43)
 Perl mp2 翻訳 チュートリアル (d223) (2022-06-15 20:42)
上の画像に書かれている文字を入力して下さい
 
<ご注意>
書き込まれた内容は公開され、ブログの持ち主だけが削除できます。

Llama
リャマ
TI-DA
てぃーだブログ
プロフィール
セラ (perlackline)
セラ (perlackline)
QRコード
QRCODE
オーナーへメッセージ

PAGE TOP ▲