Apache設定ディレクティブ¶
リクエストハンドラ¶
Python*Handlerディレクティブの構文¶
リクエストハンドラのディレクティブは、全て次のような構文です:
Python*Handler handler [handler ...] [ | .ext [.ext ...] ]
handler は呼び出し可能オブジェクトで、単一の引数、リクエストオブジェクトをとります。 .ext はファイルの拡張子です。
一つの行には複数のハンドラを指定できます。 複数指定すると、ハンドラを左から右へ順に呼びます。 同じハンドラの設定を繰り返して指定でき、同じ結果になります。 すなわち、全てのハンドラが最初から最後まで順次実行されます。
ハンドラ列のうちいずれかが apache.OK
または apache.DECLINED
以外の値を返すと、それ以降のハンドラの実行を中止します。
ハンドラが apache.OK
や apache.DECLINED
すと何が起きるかは、処理フェイズによって異なります。
mod_python 3.3 以前は、リクエストの処理フェイズに関係なく、ハンドラのいずれかが apache.OK
以外の値を返すと、その時点でフェイズの処理を中断していました。
ハンドラリストの後ろには、 |
を続け、その後ろにファイル拡張子を複数個指定できます。
この指定を行うと、該当するファイル拡張子に対してのみ、ハンドラが実行されるよう制限します。
この機能は trans フェイズ後に実行されるハンドラにのみ作用します。
ハンドラ の構文は、以下の通りです:
module[::object]
module は完全なモジュール名 (パッケージ名のドット表記も利用できます) か、モジュールコードのファイルの実際のパスです。
モジュールは mod_python のモジュール import 機構、 apache.import_module()
で読み込まれます。
モジュールの import 方法について詳しく知りたければ、この関数のドキュメントを参照してください。
オプションの object はモジュール内のオブジェクト名です。
オブジェクトの指定にもドット(.)を含められます。
ドットを含める場合、左から右に名前解決を行ってゆきます。
解決処理中に <class>
型のオブジェクトに遭遇すると、 mod_python はリクエストオブジェクトを引数にしてクラスのインスタンスを生成しようとします。
オブジェクト名を指定しない場合、ハンドラのディレクティブ名をすべて小文字にして、先頭の python
を除いた名前をデフォルトとして使います。
例えば、 PythonAuthenHandler
に対するデフォルトのオブジェクト名は authenhandler
です。
例:
PythonAuthzHandler mypackage.mymodule::checkallowed
ハンドラの詳細については「 Overview of a Request Handler 」を参照してください。
注釈
::
を使っているのは、パフォーマンス上の理由からです。
Python は、モジュール内のオブジェクトを使用する場合、まず最初にモジュールを import しておく必要があります。
区切りを単に .
にしてしまうと、区切った語が、それぞれパッケージ、モジュール、クラスなどのどれにあたるかを順に評価していくプロセスがかなり複雑になってしまいます。
そこで、(Pythonらしくない) ::
を使うことで、モジュールを指定する部分がどこで終わり、モジュール内のオブジェクトの指定がどこから始まるのかを判定するためのオーバヘッド mod_python から省き、パフォーマンスをそこそこ稼いでいます。
このドキュメントの各ハンドラは、Apache が各フェイズで呼び出す順番に並んでいます。
Python*Handlers と Python のモジュールサーチパス¶
Python*Handler
ディレクティブを ディレクトリセクション (<Directory></Directory>
や <DirectoryMatch></DirectoryMatch>
の中、または .htaccess
ファイルの中) で使うと、そのディレクトリは自動的に Python モジュールサーチパス (sys.path
) の先頭に付加されます。 ただし 、 PythonPath
を明に設定した場合は別です。
Python*Handler
ディレクティブを ロケーションセクション (<Location></Location>
や <LocationMatch></LocationMatch>
の中) で使った場合には、モジュールパスは変更されないので、ハンドラモジュールを読み込むためにパスを設定したい場合などには PythonPath
ディレクティブが必要です。
また、ロケーションセクション中で Python*Handlers
を使うと、 mod_python は、 URI からファイルへのマッピングを行なうリクエスト処理フェイズ (ap_hook_map_to_storage
) のハンドラを無効にします。
なぜなら、通常は <Location>
とファイルシステムにはリンクがない上に、ファイルシステム上からファイルを探して対応付けるために、不要で実行コストの大きいファイルシステムコールが発生するからです。
この仕様の重要な副作用として、リクエストが mod_python のハンドラが定義された <Location>
にマッチすると、そのリクエストの以降の処理では、 <Directory>
や <DirectoryMatch>
ディレクティブとその内容は無視されるということにも注意してください。
PythonPostReadRequestHandler¶
書式: Python*Handler Syntax
コンテキスト: server config, virtual host
オーバライド: not None
モジュール: mod_python.c
このハンドラは、Apacheがリクエストの内容を読み込み終わった後で、かつ、他のフェイズの処理が行われるよりも前に呼び出されます。 このハンドラは入力ヘッダフィールドに基づいて何らかの判定を行う場合に便利です。
複数のハンドラを指定した場合、いずれかのハンドラが
apache.OK
や apache.DECLINED
以外の値を返すと、それ以降のハンドラはこのフェイズでは実行しません。
注釈
このリクエスト処理フェイズでは、URI はまだパス名に変換されていません。
従って、 <Directory>
や <Location>
、 <File>
といったディレクティブの中や .htaccess
ファイルの中でこのディレクティブを指定しても Apache は設定値を使えません。
このディレクティブを置けるのはメインの設定ファイルのみで、そのコードはメインのインタプリタが実行します。
また、このフェイズはリクエストのコンテキストタイプ (例えば、要求が Python プログラムを指しているのか、それとも gif ファイルなのか) を特定するよりも前に発生するので、このハンドラで指定した Python のルーチンは、このサーバに対する、 (Pythonプログラム以外も含む) あらゆる リクエストに対して呼び出されてしまいます。
このことは、パフォーマンスが優先課題の場合には充分考慮してください。
PythonTransHandler¶
書式: Python*Handler Syntax
コンテキスト: server config, virtual host
オーバライド: not None
モジュール: mod_python.c
このハンドラは、元のリクエストの URI を、 Apache がデフォルトの規則で (Alias ディレクティブなどの効果によって) 書き換えてしまうより前に、 URI から実際のファイル名を切り出したりするのに使えます。
複数のハンドラを指定した場合、ハンドラのいずれかが apache.DECLINED
以外の値を返すと、それ以降のハンドラの実行を停止します。
注釈
このリクエスト処理フェイズでは、URI はまだパス名に変換されていません。
従って、 <Directory>
や <Location>
、 <File>
といったディレクティブの中や、 .htaccess
ファイルの中で指定しても、 Apache はこのディレクティブを実行できません。
このディレクティブを置けるのはメインの設定ファイルのみで、
そのコードはメインのインタプリタが実行します。
PythonHeaderParserHandler¶
書式: Python*Handler Syntax
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
このハンドラは、リクエスト処理の早期に、モジュールがリクエストヘッダを調べて、何らかの適切な動作を行うチャンスを設けるために呼び出されます。
複数のハンドラを指定した場合、いずれかのハンドラが
apache.OK
や apache.DECLINED
以外の値を返すと、それ以降のハンドラはこのフェイズでは実行しません。
PythonInitHandler¶
書式: Python*Handler Syntax
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
リクエスト処理フェイズの中で最初に呼び出されるハンドラで、 .htaccess
とディレクトリの内外で使用できます。
複数のハンドラを指定した場合、いずれかのハンドラが apache.OK
や apache.DECLINED
以外の値を返すと、それ以降のハンドラはこのフェイズでは実行しません。
このハンドラは、実際には異なる2つのハンドラの別名です。
メイン設定ファイル中でディレクトリタグの外に設定したときは、 PostReadRequestHandler
の別名です。
ディレクトリタグの内側 (PostReadRequestHandler
を置けない) に設定したときには、 PythonHeaderParserHandler
の別名です。
*(このアイデアはmod_perlをもとにしています)*
PythonAccessHandler¶
書式: Python*Handler Syntax
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
このルーチンは、リクエストされたリソースに対し、モジュールでアクセス制限をかけるのに使われます。
複数のハンドラを指定した場合、いずれかのハンドラが apache.OK
や apache.DECLINED
以外の値を返すと、それ以降のハンドラはこのフェイズでは実行しません。
例えば、このハンドラを使って、 IP アドレスによる制限を行えます。
アクセス不許可を示したければ、このハンドラで HTTP_FORBIDDEN
などを返します。
PythonAuthenHandler¶
書式: Python*Handler Syntax
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
このハンドラは、認証情報をチェックするときに呼ばれます。 認証情報は、リクエストと同時に送信されてきます。 送られてきた認証情報を、ユーザがデータベースの中にあるかどうか、また [暗号化された] パスワードが、データベース上のパスワードと一致しているかを調べるなどしてチェックしてください。
複数のハンドラを指定した場合、いずれかのハンドラが apache.DECLINED
以外の値を返すと、それ以降のハンドラはこのフェイズでは実行しません。
ユーザ名を得るには、 req.user
を使ってください。
また、ユーザが入力したパスワードを得るには req.get_basic_auth_pw()
関数を使ってください。
apache.OK
を返すと、認証が成功したことを意味します。
apache.HTTP_UNAUTHORIZED
を返すと、大抵のブラウザは認証ダイアログ (パスワード入力ダイアログ) を再表示します。
apache.HTTP_FORBIDDEN
を返すと、ブラウザはエラーを表示し、認証(パスワード)ダイアログを表示しません。
認証に成功しても、ユーザが特定のURLにアクセスできないような場合には、 HTTP_FORBIDDEN
を使ってください。
認証ハンドラの例は以下のようになります:
def authenhandler(req):
pw = req.get_basic_auth_pw()
user = req.user
if user == "spam" and pw == "eggs":
return apache.OK
else:
return apache.HTTP_UNAUTHORIZED
注釈
req.get_basic_auth_pw()
は req.user()
の値を使う前に呼び出さねばなりません。
Apacheは req.get_basic_auth_pw()
を呼び出すまで、認証情報のデコードを試みません。
PythonAuthzHandler¶
書式: Python*Handler Syntax
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
このハンドラは AuthenHandler
の後に実行されます。
このハンドラは、ユーザが特定のリソースにアクセスできるかどうかを調べるときに使います。
とはいえ、その処理を AuthenHandler
中で完結してしまう場合もよくあります。
複数のハンドラを指定した場合、いずれかのハンドラが apache.DECLINED
以外の値を返すと、それ以降のハンドラはこのフェイズでは実行しません。
PythonTypeHandler¶
書式: Python*Handler Syntax
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
このルーチンは、様々なドキュメントタイプ情報を決定したり設定したりするために呼び出されます。
ドキュメントタイプ情報とは、 (r->content_type
で判る) Content-type や、言語などです。
複数のハンドラを指定した場合、いずれかのハンドラが apache.DECLINED
以外の値を返すと、それ以降のハンドラはこのフェイズでは実行しません。
PythonFixupHandler¶
書式: Python*Handler Syntax
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
このハンドラは、ヘッダフィールドの特別な修正などを行なうのに使います。 コンテンツハンドラの直前に呼び出されます。
複数のハンドラを指定した場合、いずれかのハンドラが apache.OK
や apache.DECLINED
以外の値を返すと、それ以降のハンドラはこのフェイズでは実行しません。
PythonHandler¶
書式: Python*Handler Syntax
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
メインのリクエストハンドラです。 多くのアプリケーションではこのハンドラだけを指定することになるでしょう。
複数のハンドラを指定した場合、いずれかのハンドラが apache.OK
や apache.DECLINED
以外の値を返すと、それ以降のハンドラはこのフェイズでは実行せず、その戻り値をコンテンツハンドラフェーズ全体の戻り値にします。
最終的に戻り値が apache.DECLINED
だった場合、Apache はデフォルトハンドラへのフォールバックを試み、リクエストを静的ファイルの要求として処理しようとします。
PythonLogHandler¶
書式: Python*Handler Syntax
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
このルーチンはモジュール固有のログ関連の処理を行なうために呼び出されます。
複数のハンドラを指定した場合、いずれかのハンドラが apache.OK
や apache.DECLINED
以外の値を返すと、それ以降のハンドラはこのフェイズでは実行しません。
PythonCleanupHandler¶
書式: Python*Handler Syntax
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
一番最後のハンドラで、Apache がリクエストオブジェクトを捨てる直前に呼ばれます。
他のハンドラと違い、戻り値は無視されます。
エラーはエラーログに書きこまれますが、 PythonDebug
が On
になっていても、クライアントには何も送信しません。
このハンドラは rec.add_handler()
関数の引数には使えません。
動的に後処理 (cleanup) を登録したければ、あらかじめ req.register_cleanup()
を使っておいてください。
一度後処理が始まると、それ以上後処理は登録できません。
そのため、 req.register_cleanup()
はこのハンドラ内では効果がありません。
このディレクティブで登録したハンドラは、 req.register_cleanup()
で
登録した後処理ハンドラよりも 後 に実行されます。
フィルタ¶
PythonInputFilter¶
書式: PythonInputFilter handler name
コンテキスト: server config
モジュール: mod_python.c
name という名前で入力フィルタ handler を登録します。
Handler はモジュール名で、 ::
のあとに続けて呼出し可能オブジェクトの名前を指定できます。
呼出し可能オブジェクトの名前を省略した場合、デフォルト値の inputfilter
になります。
慣例で、 name に登録するフィルタ名は大抵は全て大文字にします。
handler で参照する モジュール は、完全なモジュール名にできます (パッケージのドット表記を使えます)。
また、モジュールのコードが書かれたファイルの実際のパスでもかまいません。
モジュールは mod_python のモジュールインポート機構である apache.import_module()
がロードします。
モジュールをインポートするメカニズムを詳しく知りたければ、 apache.import_module()
のドキュメントを参照してください。
フィルタを有効にするには AddInputFilter
を設定します。
PythonOutputFilter¶
書式: PythonOutputFilter handler name
コンテキスト: server config
モジュール: mod_python.c
name という名前で出力フィルタ handler を登録します。
Handler はモジュール名で、 ::
のあとに続けて呼出し可能オブジェクト名をつけられます。
呼出し可能オブジェクトの名前を省略した場合、デフォルト値の outputfilter
になります。
慣例で Name に登録するフィルタ名は大抵は全て大文字にします。
handler で参照する モジュール は、完全なモジュール名にできます (パッケージのドット表記を使えます)。
また、モジュールのコードが書かれたファイルの実際のパスでもかまいません。
モジュールは mod_python のモジュールインポート機構である apache.import_module()
がロードします。
モジュールをインポートするメカニズムを詳しく知りたければ、 apache.import_module()
のドキュメントを参照してください。
フィルタを有効にするには AddOutputFilter
を設定します。
接続ハンドラ¶
PythonConnectionHandler¶
書式: PythonConnectionHandler handler
コンテキスト: server config
モジュール: mod_python.c
接続を接続ハンドラ*handler* で処理するよう指定します。 Handler には単一の引数、接続オブジェクトが渡されます。
*Handler*はモジュール名で、
::
のあとに続けて呼出し可能オブジェクト名をつけられます。
呼出し可能オブジェクトの名前を省略した場合、デフォルトで connectionhandler
になります。
handler で参照する モジュール は、完全なモジュール名にできます (パッケージのドット表記を使えます)。
また、モジュールのコードが書かれたファイルの実際のパスでもかまいません。
モジュールは mod_python のモジュールインポート機構である apache.import_module()
がロードします。
モジュールをインポートするメカニズムを詳しく知りたければ、 apache.import_module()
のドキュメントを参照してください。
その他のディレクティブ¶
PythonEnablePdb¶
書式: PythonEnablePdb {On, Off}
Default: PythonEnablePdb Off
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
On
の場合、 mod_python
は pdb.runcall()
関数を使って、 Pythonデバッガ pdb
の下でハンドラを実行します。
pdb
は対話的なツールなので、このディレクティブを使う場合には -DONE_PROCESS
オプション付きで httpd を起動してください。
ハンドラコードに到達すると、すぐに pdb のプロンプトが表示され、コードをステップごとに進めて変数を調べられるはずです。
PythonDebug¶
書式: PythonDebug {On, Off}
Default: PythonDebug Off
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
通常、Python のエラーが捕捉されずに上がってくると、トレースバック出力はログに送られます。
PythonDebug を On に設定すると、 IOError
が出るまでは、トレースバックの出力は (ログの他に) クライアントにも送信されます。
ただし、出力時の IOError
の場合にはエラーログだけに送信されます。
このディレクティブは開発時に非常に有用です。 しかし、このディレクティブを使うと、意に反した、場合によっては重大なセキュリティ上の 情報をクライアントに暴露してしまう恐れがあるので、実運用では使わないよう勧めます。
PythonImport¶
書式: PythonImport module interpreter_name
コンテキスト: server config
モジュール: mod_python.c
interpreter_name
に指定した名前を持つインタプリタの下で Python モジュール module
を import するよう、サーバに指示します。
import は子プロセスの初期化時に起こるので、実際には起動した子プロセスあたり一度だけモジュールの import が起こります。
handler で参照する モジュール は、完全なモジュール名にできます (パッケージのドット表記を使えます)。
また、モジュールのコードが書かれたファイルの実際のパスでもかまいません。
モジュールは mod_python のモジュールインポート機構である apache.import_module()
がロードします。
モジュールをインポートするメカニズムを詳しく知りたければ、 apache.import_module()
のドキュメントを参照してください。
PythonImport
は、例えば、データベース接続の初期化など、時間がかかり、リクエスト処理時に実行するのが望ましくない初期化タスクに便利です。
初期化のコードが失敗することがあり、それによってモジュールのインポートが失敗する場合は、関数名を指定したもう一つの書き方を使ってください:
PythonImport *module::function* *interpreter_name*
ここに指定した関数は、モジュールが正しくインポートされた時にのみ実行されます。 関数は引数なしで呼びだされます。
注釈
モジュールのインポートが起きるとき、設定は完全に読み込まれてはいないため、 PythonInterpreter を含む他のどのディレクティブも、このディレクティブでインポートするモジュールに影響を及ぼせません。
この制約があるので、インタプリタ名を明示的に指定しておいて、後のリクエスト処理の仮定で、ここでの処理結果に依存した操作をするときに、名前の一致するインタプリタが使われるようにせねばならないのです。
どんな名前のインタプリタでリクエストを処理しているかわからないときは、リクエストオブジェクトの request.interpreter
メンバを調べてください。
多重インタプリタ (Multiple Interpreters) の節も参照して下さい。
PythonInterpPerDirectory¶
書式: PythonInterpPerDirectory {On, Off}
Default: PythonInterpPerDirectory Off
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
インタプリタの名前を、サーバ名からではなく、リクエスト中のファイルのディレクトリ名(req.filename
) からつけるよう、 mod_python
に指示します。
その結果、デフォルトポリシの場合と違って、二つのスクリプトが別々のディレクトリに置かれていると、それらが互いに別個のサブインタプリタで実行されます。
デフォルトポリシでは、同じ仮想サーバ上のあるスクリプトは、同じサブリンタプリタで実行されます。
- 例えば、
/directory/subdirectory
があると仮定します。/directory
には、PythonHandler
ディレクティブの定義された.htaccess
ファイルがあり、/directory/subdirectory
には.htaccess
がないとします。 /directory
の下のスクリプトと/directory/subdirectory
の下のスクリプトは、同じ仮想サーバを介してアクセスされていれば、同じインタプリタ下で実行されます。
PythonInterpPerDirectory
が有効な場合は各ディレクトリ毎に別個の二つのインタプリタになります。
注釈
URIの変換より前の早い段階のリクエスト処理フェイズ (PostReadRequestHandlerやTransHandler) では、URIがまだ変換されていないため、パスがまだ決まっていません。 その間は、PythonInterpPerDirectoryがOnであったとしても、ハンドラはメインのインタプリタによって実行されます。 この動作は期待にそぐわないかもしれませんが、残念ながら回避する方法はありません。
参考
- Multiple Interpreters
- for more information
PythonInterpPerDirective¶
書式: PythonInterpPerDirective {On, Off}
Default: PythonInterpPerDirective Off
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
サブインタプリタの名前をつけるよう mod_python
に指示します。
名前は、有効な Python*Handler ディレクティブのあるディレクトリの名前になります。
例えば、 /directory/subdirectory
があると仮定します。
/directory
にはPythonHandlerディレクティブの入った .htaccess
ファイルがあり、 /directory/subdirectory
には別の PythonHandler の入った .htaccess
ファイルがあるとします。
デフォルトでは、同じ仮想サーバを介してアクセスされていれば、 /directory
の下のスクリプトと /directory/subdirectory
の下のスクリプトは同じインタプリタ下で実行されます。
PythonInterpPerDirective
が有効な場合、各ディレクティブ毎に別個の二つのインタプリタになります。
参考
- seetitle[pyapi-interps.html]{ref{pyapi-interps} 節、複数のインタプリタ}
- {詳しい情報です}
- Multiple Interpreters
- for more information
PythonInterpreter¶
書式: PythonInterpreter name
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
インタプリタの名前を強制的に name にするよう mod_python
に指示します。
デフォルトの仕様や、 dir-other-ipd`および :ref:`dir-other-ipdv ディレクティブで設定した名前をオーバライドします。
このディレクティブを使うと、通常なら別々のサブインタプリタ下で行われるスクリプトの実行を、同じサブインタプリタ下で行えます。 DocumentRoot の下で使うと、サーバ全体で一つのサブインタプリタを使うようになります。
参考
- Multiple Interpreters
- 詳しい説明です。
PythonHandlerModule¶
書式: PythonHandlerModule module
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
PythonHandlerModule は、他の Python*Handler ディレクティブの代わりとして使えます。 このハンドラでモジュールを指定すると、各種ハンドラ関数を探すときのデフォルトの検索対象モジュールとして使われ、このモジュール中に関数があればそれを実行します。
例えば以下のような設定は:
PythonAuthenHandler mymodule
PythonHandler mymodule
PythonLogHandler mymodule
このように単純に書けます。:
PythonHandlerModule mymodule
PythonAutoReload¶
書式: PythonAutoReload {On, Off}
Default: PythonAutoReload On
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
Off
にセットすると、モジュールファイルの更新日時を調べないよう mod_python
に指示します。
デフォルトでは、 mod_python
はファイルのタイムタンプをチェックし、以前のインポート、またはリロード時よりモジュールファイルの更新時刻が新しければ、そのモジュールをリロードします。
この仕組みでモジュールを自動的に再 import するので、モジュールを更新するたびにサーバーを再起動させる必要が無くなります。
自動リロードを無効化は、モジュールの変化がないプロダクション環境で便利です。 いくらか処理時間を節約でき、わずかなパフォーマンス向上をもたらすからです。
PythonOptimize¶
書式: PythonOptimize {On, Off}
Default: PythonOptimize Off
コンテキスト: server config
モジュール: mod_python.c
Pythonの最適化を有効にします。Pythonの -O
オプションと同じです。
PythonOption¶
書式: PythonOption key [value]
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
キーと値のペアをテーブルに保存して、あとで request.get_options()
で取り出せるようにします。
設定ファイル ( httpd.conf
や .htaccess
など) と、Pythonプログラムの間で情報を受け渡すのに便利です。
値を省略したり空文字 (""
) にすると、そのキーを設定から除去します。
予約済の PythonOption キーワード¶
PythonOption
で指定できるキーワードの中には、 mod_python の様々な動作を設定するのに使われているものがあります。 mod_python.* で始まるキーワードは予約済みで、 mod_python の中で使うことを想定しています。
ユーザは、自分のアドオンモジュールを作る際、独自の名前空間を使って、決してグローバルの名前空間を使わないようにしましょう。
以下の PythonOption は、実際に mod_python で使われています。
PythonPath¶
書式: PythonPath path
コンテキスト: server config, virtual host, directory, htaccess
オーバライド: not None
モジュール: mod_python.c
PythonPath ディレクティブは、 PythonPath をセットします。 パスはPython のリスト表記で指定せねばなりません:
PythonPath "['/usr/local/lib/python2.0', '/usr/local/lib/site_python', '/some/other/place']"
このディレクティブで設定したパスは、既存のパスへの追加ではなく、置き換えになります。
ただし、パスの指定値は eval
で評価されるので、ディレクトリを追加したければ、以下のように指定できます:
PythonPath "sys.path+['/mydir']"
mod_python
は PythonPath ディレクティブに関係する eval の実行回数を最低限にしようと試みます。というのも、 eval は低速で、とりわけ、 .htaccess
ファイル内で指定すると毎回ヒットするたびに評価されるので、強烈な悪影響を及ぼすことがあるからです。
mod_python
はPythonPathディレクティブの引数 (評価する前の状態) を覚えておき、値を評価する前に覚えておいた値と比較して、値が同じならば何も行いません。
そのため、コード内で sys.path を変更している場合、このディレクティブがパスの内容を元に戻す手段になるなどと当てにしてはなりません。
PythonPath ディレクティブを複数回指定しても、効果が足し合わされたりはせず、最後に指定したディレクティブが以前のディレクティブの設定を上書きします。
注釈
このディレクティブをセキュリティ対策に使ってはなりません。 Pythonパスはスクリプトで簡単に操作できるからです。