Apache :: ASP
< % Web Applications with Apache & mod_perl % >
はじめに
インストール
% 設定
構文
イベント
オブジェクト
SSI
セッション
XML/XSLT
CGI
PERLスクリプト
FAQ
チューニング
謝辞
サポート
使用サイト
リソース
計画
履歴
ライセンス

実例

ASP 工作室
日本語訳について

Powered by Apache::ASP
Powered by ModPerl and Apache
Powered by Perl
Links Checked by NodeWorks
SourceForge.jp
設定


		
			Apache の設定ファイル--httpd.confに、<Files ...> を使用すると、
			Apache::ASPが起動し始めます。
			オプションの設定は、お望みのように、書き変えることができますが、
			スタート時には、デフォールトが無難です。
			設定例は、この文書の下方にあります。
			あなたのウェブ・アプリケーションへの Global 設定は、
			global.asa の名称で、以下のようにファイルに書き込んでください。
		
		
  <Files ~ (\.asp)>    
    SetHandler  perl-script
    PerlModule  Apache::ASP
    PerlHandler Apache::ASP
    PerlSetVar  Global .
    PerlSetVar  StateDir /tmp/asp
  </Files>
		
注意: (実例のある)../site/eg ディレクトリでは、この例を使わないでください。実例を稼動させるには、
インストールセクションのクイックスタートをチェックしてください。
		
ASP の定義設定とは別に、<Directory> や <Location> や <VirtualHost> のような Apache 設定タグも使えます。 しかし、ディレクトリ毎に、<Files> タグを使う方が、様々なメディアにナチュラルに適応できるという点の方で、ASP アプリケーション構築時には、自然です。 また、多くの別個のアプリケーション構築では、<VirtualHost> セクションに個別の .htaccess ファイルを使い分けるか、 <Files> タグを使う方が、パーフォーマンス上良好な結果になります。

基幹部分 XMLSubsStrict
Global XSLT
GlobalPackage XSLTMatch
UniquePackages XSLTParser
DynamicIncludes XSLTCache
IncludesDir XSLTCacheSize
State Management(状態の管理) キャッシング
NoState CacheDB
AllowSessionState CacheDir
AllowApplicationState CacheSize
StateDir
StateManager 雑多
StateDB AuthServerVariables
StateCache BufferingOn
StateSerializer InodeNames
RequestParams
セッション StatINC
CookiePath StatINCMatch
SessionTimeout StatScripts
SecureSession SoftRedirect
ParanoidSession Filter
SessionSerialize CgiHeaders
SessionCount Clean
CompressGzip
クッキーなしのセッション FormFill
SessionQueryParse TimeHiRes
SessionQueryParseMatch
SessionQuery Mail Administration(メール管理)
SessionQueryMatch MailHost
MailFrom
開発環境 MailErrorsTo
UseStrict MailAlertTo
Debug MailAlertPeriod
DebugBufferLength
PodComments ファイルアップロード
CollectionItem FileUploadMax
FileUploadTemp
XML / XSLT  
XMLSubsMatch  

基幹部分

Global

Global (Global) は、Apache::ASPアプリケーションの中枢部分で、global.asa でウェブ・アプリケーションのイベント・ハンドラーを定義します。

このディレクトリーは、@INCにプッシュされ、このディレクトリーのファイルを "use" や "require" で使用でき、アプリケーション開発のためには、このディレクトリー内での、perlモジュールは、簡単に扱う事ができます。
StateDir が設定されない時は、このディレクトリはウェブサーバで 書き換え可能なディレクトリを使用され、$Session と $Application オブジェクトのState は、このディレクトリに保持されます。 StateDir が設定されたら、このパラグラフは無視され、保持には、Global なディレクトリに上書き保存されます。
このディレクトリ内の、<!--#include file=somefile.inc--> のような、インクルード設定、ないし、$Response->Include() 構文に関しての詳細情報は、IncludesDir セクションを見てください。
  PerlSetVar Global /tmp

GlobalPackage

全てのスクリプト、Includes、global.asa でのイベントは、 Perl パッケージの名前空間としてコンパイルされます。デフォールトでは、Global なディレクトリ内のファイルや global.asa ファイルから一意的に生成される、GlobalPackage は、幾分あいまいになっています。 GlobalPackage での名前使用を明確にすると、次のようなスクリプトで、Perl モジュールで定義した、Global 変数やサブルーチンにアクセスする事が可能です。

  Perl スクリプトで: use Some::Package;
  Apache 設定で: PerlModule Some::Package

  PerlSetVar GlobalPackage Some::Package

UniquePackages


デフォールトは、0 です。  1 にセットすると、固有の、Perl パッケージにコンパイルされていた、v.10 以前の、ASP スクリプトのコンパイル時動作へのエミュレーションになります。

v.10 以前では、ASP スクリプトは、固有の perl パッケージの名前空間にコンパイルされていましたので、同一の、ASP アプリケーションで同じ名前のサブルーチンが定義されるという問題がありました。
v.10 では、デフォールトで、ウェブアプリケーションの、ASP スクリプトは、*同一の* Perl パッケージにコンパイルされますので、スクリプト、Includes や、global.asa でのイベントは、すべて、互いに共通のGlobal 変数やサブルーチンを共有します。 開発者によっては、名前の衝突が起こるので、2つ以上のスクリプトで同じ名前でサブルーチンを定義したり、あるサブルーチンが、他のサブルーチンを再定義する弊害が起こります。
  PerlSetVar UniquePackages 0

DynamicIncludes



デフォールトは、0 です。
 SSI ファイルは、呼び出す側のスクリプトに、通常にインライン展開され、そのスクリプト全体でコンパイルされます。このオプションを、TRUE にセットすれば、インクルードされるファイルは、別個のサブルーチンとしてコンパイルされ、スクリプトが実行する時に呼び出されます。利点は、(あらかじめ)インクルードからコンパイルされたコードは、スクリプト間で共有でき、メモリサイズが小さくなり、コンパイル時間も短くなります。
  PerlSetVar DynamicIncludes 0

IncludesDir

デフォールトは「他のディレクトリはセットされない」です。ディレクトリがセットされると、スクリプトコンパイル時に、合わせて参照されます。
デフォールトは、スクリプトが存在するディレクトリ、ないしGlobal ディレクトリが、Includes として、チェックされます。
Global ディレクトリでは、スクリプトと一つのアプリケーション間だけで、コード共有されるのに対して、この拡張で、(複数の)ASP アプリケーション間で、簡単に、(コードが)共有化できます
  PerlSetVar IncludesDir .
また、次のように、複数の Includes ディレクトリを、セミコロン ';' で並列させることも可能です。
  PerlSetVar IncludesDir ../shared;/usr/local/asp/shared
このような IncludesDir の設定では、Includes の検索は .(カレントディレクトリ)、$Global 、../shared、/usr/local/asp/shared で行われます。 カレントディレクトリが最初にチェックされ、 次に、global.asa で設定された、Global ディレクトリへ、最終的に、IncludesDir のセット内容へとチェックが移ります。

State Manage(State の管理)

NoState

デフォールトは 0 です。そのときは、$Application と $Session オブジェクトとも生成されません。
パフォーマンスの改善のために使ってください。この設定は、AllowSessionState と
AllowApplicationState セッティングを上書きすることに留意してください。
  PerlSetVar NoState 0

AllowSessionState


1 がデフォールトです。0 にセットすると、セッショントラックを行わず、
パーフォーマンスが向上しますが、$Session オブジェクトが操作できません。
  PerlSetVar AllowSessionState 1    
セッション生成を不可とする場合、 サーチエンジンのようなブラウザ機能のないユーザエージェントに対しては、 初期化のハンドラは次のように用いることができることに留意してください。
  PerlInitHandler "sub { $_[0]->dir_config('AllowSessionState', 0) }"

AllowApplicationState


デフォールトは、1 です。$Application を未定義のままにしたいなら、
0 にセットしてください。パーフォーマンスが、2〜3% 向上します。
StateManager は、$Session のガベージコレクション(ごみ集め)時に関連して稼動しますので、
$Application の常時使用は、$Session より、(メモリ資源などを)消費しません。
したがって、このパラメータは、極端なチューニングをする時のみにお使いください。
  PerlSetVar AllowApplicationState 1

StateDir


デフォールトは、$Global/.stateです。
ASP アプリケーションのState ファイルは、このディレクトリに置かれます。
State ファイルの置き場所は、ユニークな、ASP アプリケーションを作成する上で、
最も大事な事です。
同一の、ASP アプリケーションでは、同一のState ファイルを違った仕方で、
参照させます。

設定の指令をした後でも、このデフォールトは変わりません。 この設定の理由は、ファイルキャッシングを行う、 Solaris のようなオペーレションシステムでは、 永続的なファイルが置かれる、Global ディレクトリと別の場所に、 State ディレクトリが作られるからです。 このように、StateDir を /tmp/myaspapp にすれば、速度の速い、 ASP アプリケーションの流れを作成できます。
  PerlSetVar StateDir ./.state

StateManager


デフォールトは、10 です。この数字は、失効したセッションの
ガベージコレクションを行う、SessionTimeout あたりの回数です。
大きくなれば、システムは遅くなりますが、
時間切れセッションの後始末のときに、
global.asa から(定義されている)の、
Session_OnEnd が、より正確になり、
ハック攻撃と考えられる、セッションから、(システムを)防御しやすくなります。
数字が小さければ、システム速度はアップします。

デフォールトでは、SessionTimeout は、20 分間、StateManager は、10 回ですので、亡くなったセッションは、2 分毎に、後始末をされます。
  PerlSetVar StateManager 10

StateDB


デフォールトは、 SDBM_File です。
$Application と $Session のような状態オブジェクトには、
内部データベースが使われます。
SDBM_File ファイルの、%hash は、キーと値のペアのサイズは、
通常 1024 バイトですので、別のデータベースとして、 DB_File ないし
MLDBM::Sync::SDBM_File ファイルを使おうと思えば、可能です。
軽量の、$Session と $Application を使うなら、SDBM_File で何とかできますが、
  $Session{key} = { # 巨大な複合体オブジェクト }
のような複合体を扱おうとすると、1024 のリミットを使い切るかも知れません。
現在使用可能なのは StateDB は SDBM_File、 MLDBM::Sync::SDBM_File、 DB_File と GDBM_File です。他に、追加希望がありましたら、 お知らせください。
version .18 で、この設定が、現実に走っている環境でも 変更可能になり、新規の StateDB がこの(同じ)形式で、 作られるようになりました。 以前のバージョンでは、新しい StateDB に切り替えようとすると、 元の StateDB を消すことになり、相違するデータベース形式間で ガベージコレクション操作の方法など、非互換性がありました。
  PerlSetVar StateDB SDBM_File

StateCache

Version 2.23 で大幅変更(?)。
このバージョンから実現した機能で、設定にいかなる等価物もありません。
2.23 は、MLDBM::Sync をシステムに組む込むなど、大幅な状態管理の書き換えを行っています。


StateSerializer


デフォールトは、 Data::Dumper で、いっそう速いデータの順序化と記憶格納を
状態オブジェクトへ入れるためには、 Storable にセットできます。
これは、特に、$Session と $Application に、
ラージオブジェクト格納するのに役立ちます。
Storable.pm モジュールに、Perl 構造から、ないし、
構造へデータを圧縮や解凍の際に、より速い実装があるからです。
状態データベースに多量のデータを格納したいなら、
SDBM_File が key/value の長さが、1024 バイトの限界があるのに対して、
(限界のない) DB_File を使うべき点に留意してください。

この設定は、状態データベースの順序化のタイプが、 常に Data::Dumper & SDBMファイルを使用してデータ格納する 内部の状態管理に応じて、変更されて生成されています。(?)
  PerlSetVar StateSerializer Data::Dumper

セッション

CookiePath


クライアントが反応し、セッションクッキーを送るための、URL ルート。
もし、ASP アプリケーションをサーバの、"/asp" に置くなら、
この変数を、/asp にしてください。
同一のサーバで違うアプリケーションを、
各々のアプリケーションで異なったユーザセッションで、稼動できますので。
  PerlSetVar CookiePath /

SessionTimeout


デフォールトは、20 分です。ユーザセッションは、
この時間でアクティブでなくなると、セッションに対して定義済なら、
Session_OnEnd が稼働し、セッション内容は、破壊されます。
  PerlSetVar SessionTimeout 20

SecureSession


デフォールトは、0 です。セッションクッキーで、安全なタグをタグをセットし、
クッキーーは、https 送信を使ったブラウザのみで、送信されます。
  PerlSetVar SecureSession 1

ParanoidSession


デフォールトは、0 です。「真」にセットされると、セッションを構成する
ブラウザのユーザエージェントのヘッダに蓄えられ、
提示されたセッションクッキーに対して、(ヘッダが)安全確認されます。
このチェックが失敗すると、なんらかのハッキングが試みられたという根拠で
セッションは停止されます。

この設定オプションは、On と Off の切替えで、 カレントのセッションが崩壊しないように、 スムーズに変更できるよう実装されています。 セッションは、設定 On で、安全上、効果あるように、構築されるべきです。
この設定は、野蛮で強制的なクッキーを接続可能にしないように、 防御するのに役立ちます。 可能なクッキーの番号は、2^128 と巨大で、ハッキングを試みられるのは、 *めったに*ありそうもないと思われがちです。成功は見込薄でも、 セッションで認証される同一のブラウザのヘッダを送り付け、 セッションを破壊するハッカーもまた存在するものです。 ここでは、ユーザエージェントのセッションは、 現実のセッション id のバックアップとして作用します。ブラウザの、IP アドレスは、 プロキシ(代理)サーバを介すると、セッション中にリクエスト間で変更されるため 使用されません。
いくつかのブラウザは、ユーザエージェントヘッダを提示しません。 これらのブラウザは、 "Unknown" タイプとして、考慮され、 メソッドは同様に作用します。
大抵の人々は、こんなレベルの安全性は不要と考えるでしょう。 したがって、パラノイドと名付けました :)
  PerlSetVar ParanoidSession 0

SessionSerialize



デフォールトは、 0 です。(値が) 真なら、スクリプト(実行)の間、
$Session オブジェクトへのリクエストを、順序化するよう、
$Session をロックします。
ユーザ $Session 毎に、セッションが許容されたただ一つのスクリプトが、
同時期に稼動するからです。
Session オブジェクトへの順序化されたリクエストは、 マイクロソフトの ASP と同じ方法になります。 プロセスが長時間稼動や暴走する可能性のリスクがあるので、 製品環境では危険なものになります。これら(リスクが)起こると、 セッションは、不定の時間で、ロックされるでしょうが、 ユーザの *中止* ボタンで、セッションを安全に休止させる必要があります。
  PerlSetVar SessionSerialize 0

SessionCount


デフォールトは、 0 です。(値が) 真なら、
アプリケーションで、現在アクティブなセッションの数を返す
$Application->SessionCount API を可能にします。
v.19 で、この設定は、このカウントがトラックする事で、
パフォーマンスヒット(?)があるとの理由で作成されました。
デフォールトでは、不可にしています。
  PerlSetVar SessionCount 1

クッキーなしのセッション

SessionQueryParse


デフォールトは、 0 です。(値が) 真なら、
自動的に $Session でのセッション id を
$Response バッファにある、ローカルな URL の問い合わせ文字列へと
構文解析(パース)します。この設定は、このようにはたらくので、
バッファーは使用可能にしなければなりません。
この構文解析は、ブラウザによって、セッションクッキーが送出されない時に
行われます。したがって、セッションが可能なサイトの最初のスクリプトと
クッキー不可とした Web ブラウザが閲覧したスクリプトが、
この動作のトリガになります。

このランタイムでのパーシング(構文解析)のメソッドは、 コンピュータ資源を費やしますが、 そのコストは、この URL パーシングを必要としない多くのユーザにも 割りあてるべきものです。 不精なプログラマの夢みたいなものです。 より効率的な設定法は、SessionQuery セッティングをご覧ください。 このソリューションの詳細情報は、 セッション セクションを見てください。
  PerlSetVar SessionQueryParse 0

SessionQueryParseMatch


デフォールトは、0 です。この設定は、セッション id を解析した
SessionQueryParse を得た結果、全ての URL にマッチするよう、
正規表現のパターンをセットします。
デフォールトでは、SessionQueryParse は、ローカルの URL のみ修正しますが、
サイト内で、http://localhost のように、完全な形で、
名前をつけたい時には、この設定を使う必要があります。
http://localhost という URL にマッチさせるには、
このパターンを、http://localhost.に設定してください。
この設定では、また SessionQueryParse へのセッティングも
行われていることに注目!
  PerlSetVar SessionQueryParseMatch ^https?://localhost

SessionQuery


デフォールトは、0 です。セットされると、セッション id が、
最初にクッキーとして見つからなければ、
$Request->QueryString (の値)から初期化されます。
この設定は、一対のものとして、以下のように使用できます。
  $Server->URL($url, \%params) 
クッキーなしのセッションを効率的にサポートするため、問い合わせ文字列内に セッション id があるローカルな URL を作り出す、API 拡張です。 ブラウザが、クッキーを不可した場合、 自動的に作られる SessionQueryParse を使わないなら、 $Session へアクセスする 任意のページに対する URL は、このメソッドによって作られることに注目!
  PerlSetVar SessionQuery 0

SessionQueryMatch


デフォールトは、0 です。セットすると、$Server->URL() での URL に
マッチする正規表現のパターンを、セッション id に付け加えます。
SessionQuery は、通常では、$Server->URL() がセッション id を
ローカル URL に付け加えることができるようにします。
その結果、Web サイトで http://localhost/ のような、
絶対的な URL 参照を使う場合には、SessionQueryParseMatch を使ったように
このパターンを ^http://localhost にセットできるでしょう。

セットされると、(SessionQueryは、)自動的にセットされるので、 SessionQuery への設定は不要です。
  PerlSetVar SessionQueryMatch ^http://localhost

開発環境

UseStrict


デフォールトは、0 です。1 にセットすると、
スクリプト、global.asa、インクルードファイルが全て、
"use strict;" が先頭に付け加えられ、
記述しなくても、strict 化(コードの厳密化)がされて、
骨の折れるプロセスから、救ってくれることになります。
"use strict" プログラムのエッセンスは、 mod_perl 環境にありますので、いつか、デフォールトは、1 にセットしていますが、 この判断には、議論があると思われます。
この設定がセットされる際に、 "use strict" によって引き起こされるエラーは、 通常の Apache::ASP エラーの一部分として、捉えられる一方で、 "use strict" のエラーは、適切に操作できないので、 ご自身で、"use strict" 命令文を記述するより、 UseStrict を用いるほうがベターであることにも注目してください。
  PerlSetVar UseStrict 1

Debug


1 で、サーバでのデバグログを有効にします。
2 は、クライアントの、HTML 付加出力を有効、
3 は、ミリ秒単位の時間計測のログが有効です。
1 は、製品段階でのデバグ、2 と 3 は、開発時に使ってください。
デバグ不要の時は、オフにしてください。
これらの設定は、$Response->Debug() を作動させます。
  PerlSetVar Debug 2	
デバグ(レベル)が 3 で、Time::HiRes がインストールされているなら、 ミリ秒単位の経過時間がログに現れるでしょうし、 ある $Response->Debug() と他のそれとの時間間隔を計算するので、 ログを見たとき、すばやくベンチマークを取るのに役立つでしょう。
  PerlSetVar Debug 3
システムレベルのデバグを有効にしたのなら、 Debug をマイナスの値にセットしてください。 システムデバグが行われ、ブラウザには、 (デバグの結果は)一切現れてきません。
  PerlSetVar Debug -1

DebugBufferLength


デフォールトは、100 です。
この設定は、バッファーされた出力の末尾にセットされるバイト数です。
そして、Debug 2 になっているか、
MailErrorTo がセットされており、
しかも BufferingOn になっている場合、
エラー発生時に、見てみたいものです。
出力がバッファーされていると、スクリプトエラーが起こっても、 $Response オブジェクトにバッファーされているので、 当然のことながら、現れてきません。 そこで、バッファーされた出力の最終バイトに、デバグ情報が含まれていると スクリプト出力で、どこでエラーがスクリプトを中断させるのかを見てとる、 手助けになります。
この機能のデモは、 ../site/eg/syntax_error.htm スクリプトを試し、バッファーをオンにしてください。

PodComments


デフォールトは、1 です。
Pod コメントをオンにすると、
Perl スタイルのコメントとドキュメントが、スクリプトのコンパイル時に、
構文解析から外れます。
これ(pod)は、卓越したドキュメントとすてきなデバグのツールになりますので、
Perl のコードと、HTML をブロックとしてコメントアウトしましょう。
具体的には、以下のように書くと、
=pod
  テキストか Perl のコードをここに書きます。
=cut 
(この部分は)コンパイルの前に切り取られます。 =pod と =cut の Perl 命令は、行の先頭になければならず、 また後に行末端が続かなければなりません。
  PerlSetVar PodComments 1

CollectionItem


次のようなPerlScript 
類似の構文を可能にします。
  $Request->Form('var')->Item;
  $Request->Form('var')->Item(1);
  $Request->Form('var')->Count;
以下(の宣言)で可能となる、元の PerlScript 構文は、
  use Win32::OLE qw(in valof with OVERLOAD);
以下のような元来の構文と類似です。
  $Request->Form('var');
Apache::ASP でのみ、上記は以下のように書かれると有効になります。
  $Request->{Form}{var};
_真に_スピードが求められる時に、こういう風にしてください。

XML / XSLT

XMLSubsMatch


デフォールトでは、定義されていません。
Perl サブルーチンで扱いたい、
全ての XML と HTML タグにマッチするように、
ある正規表現のパターンをセットします。
これは、Apache::ASP でのカスタムタグの技術で、
XML と HTML 変換のさい、強力な機能拡張を作り出すことができます。
使用説明はXML/XSLT セクションを 見てください。
  PerlSetVar XMLSubsMatch my:\w+

XMLSubsStrict


デフォールトは、0 です。
XMLSubs へのセットは、
以下のような常に正しく整形された XML タグの引数をとります。
  <my:sub arg1="value" arg2="value"/>
デフォールトでは、XMLSubs は、引数の値として以下のように、 恣意的な Perl コードが可能ですが、
  <my:sub arg1=1+1 arg2=&perl_sub()/>
常に期待する結果になるとは限りません。 この場合には、XMLSubsStrict を 1 にセットしてください。

XSLT


デフォールトでは、定義されていません。
(ある)ファイルにセットされると、ASP スクリプトは、
XML 出力としてみなされて
XML::XSLT.
を用い、与えられた XSL ファイルに基づき、転換されます。
この XSL ファイルは、最初は ASP スクリプトとして実行され、
その出力は、転換の際の XML データになります。
この XML ファイルは、動的なインクルードとして実行されるので、
現ディレクトリか、Global か IncludesDir (で設定された) ディレクトリに
置かれます。
使用法説明は、XML/XSLT を見てください。
  PerlSetVar XSLT template.xsl

XSLTMatch


デフォールトは、.* です。XSLT がデフォールトで設定されていますと
すべての ASP スクリプトは、指定の XSL テンプレートで、XSL 転換されます。
この正規表現の設定は、XSLT が、ファイル名にマッチすると、
XSL 転換を行うようにしますので、
通常の HTML ASP スクリプトと XML ASP スクリプトは、
ともに同様の設定ブロックとして設定されます。
この使用例として、../site/eg/.htaccess を見てください。
  PerlSetVar XSLTMatch \.xml$

XSLTParser


デフォールトは、
XML::XSLT ですが、
設定では、XSLT 構文解析にどの Perl モジュールを使うかを決めます。
これは、2.11 での新規の設定項目です。
XML::Sablotron も同じようにサポートします。
XSLT を扱ううえで、同一の出力になるとは限りませんが、
XML::XSLT より 約 10 倍速くなります。
  PerlSetVar XSLTParser XML::Sablotron

XSLTCache


CacheDB、CacheDir、CacheSize の設定による、キャッシュに基づく
XSLT ファイルを可能にします。
このことで、Axkit に近い、また、Cocoon より強大な XSLTでのキャッシュができあがります。
XSLT でのキャッシュを用いた転換は、
XML & XSLT 入力のキーによって(それぞれ)独自なものになっています(?)
  PerlSetVar XSLTCache 1

XSLTCacheSize


Version 2.11 で、この設定はもはやサポートされなくなりました。


Caching


出力時のキャッシング層は、MLDBM::Sync (モジュール)の
トップで稼動している出力キャッシュに基づく、dbm ファイルで、
その (MLDBMの) パーフォーマンスでの特色を継承しています。
CacheDB を MLDBM::Sync::SDBM_File にセットすると、キャッシュ層は、
20K のファイルサイズまでは、キャッシュ登録は非常に速いですが、
それ以上のキャッシュ項目では、
DB_File か GDBM_File のような他の dbm へ、
CacheDB をセットする必要があります。
キャッシュ層が、正確に機能するためには、 $Response->Include() 出力キャッシング (オブジェクト参照)であれ XSLT キャッシング (XML/XSLT 参照)であれ 以下のように、Apache::ASP が、親プロセスの httpd にロードされなければなりません。
  # httpd.conf
  PerlModule Apache::ASP
  -- or --
  <Perl>
  use Apache::ASP;
  </Perl>
キャッシュ層は、サーバが再スタートのたびに、自動的に 登録を失効させますが、Apache::ASP モジュールが キャッシュ項目をストアできるように、ロードされる時には、 $ServerID が計算されなおさなければなりません。 上記(の設定)が、ない場合は、httpd の各々のチャイルドプロセスは、 独自の $ServerID を持つことになり、キャッシングは全く働きません。
すなわち、出力キャッシングは、 mod_perl での 下の 生のCGI モードでは 働かないのです。

CacheDB


StateDB と同じように、キャッシングでの、dbm 形式をセットします。
SDBM_File は、サイズ長が、最大 1k の、キー/値のペアのみサポートしませんので、
この設定のデフォールトは、20K 未満の出力では、
非常に高速の MLDBM::Sync::SDBM_File です。
キャッシングが、20K 以上を越す際には、
DB_File か GDBM_File を使うほうが良いでしょう。
  PerlSetVar CacheDB MLDBM::Sync::SDBM_File
Linux 2.2.14 dual PIII-450 (の環境)で $Response->Include(\%cache) からのキャッシング出力を用いた場合の CacheDB に関するベンチマークを示します。 値は、MLDBM::Sync::SDBM_File をデフォールトにして、 CacheDB を用い、キャッシュさせた出力サイズです。(?)
CacheDBキャッシュ出力サイズ動作動作/秒
MLDBM::Sync::SDBM_File 3200 バイト 読込み 177
DB_File 3200 バイト 読込み 59
MLDBM::Sync::SDBM_File 32000 バイト 読込み 42
DB_File 32000 バイト 読込み 53
MLDBM::Sync::SDBM_File 3200 バイト 書込み 42
DB_File 3200 バイト 書込み 39
あなた自身、MLDBM::Sync での CacheDB として使用する、 様々な DBM の相対的な速度をテストするベンチマークをとるには、 あなたのシステムの、MLDBM::Sync の配布物にある、 ./bench/bench_sync.pl スクリプトを実行させてください。

CacheDir


デフォールトでは、キャッシュディレクトリは、
StateDir/cache にセットされていますが、
StateDir がセットされていなければ、
CacheDir が、使われ、
StateDirに、キャッシング目的で値をセットします。
これは、NoState に 1 がセットされている際に、
混乱が少なくてすみます。
  PerlSetVar CacheDir /tmp/asp_demo
Solaris のように、/tmp 下に、 RAM ディスクがマウントされているようなシステムでは、 キャシュをここに置けばよいでしょう。 もともと、ファイルキャッシュがうまく出来ている Linux のようなシステムでは あまり重要ではありません。

CacheSize


デフォールトでは、キャッシュ毎に、10M です。
XSLTCache のような任意のキャッシュが、上限に達すると、
キャッシュされた dbm ファイルが完全に削除されることで、
キャッシュが取り除かれます。
dbms が長期にわたって稼動している際には、
dbm 形式は、しばしば、多量の挿入と削除があるとパーフォーマンス低下がありますので、
個々のレコードを削除するより、
良好な結果になります。

M、K、B の単位はそれぞれ、メガバイト、キロバイト、バイトをサポートします。 デフォールトは、B です。以下の設定は、全て同じ意味になります。
  PerlSetVar CacheSize 10M
  PerlSetVar CacheSize 10240K
  PerlSetVar CacheSize 10485760B
  PerlSetVar CacheSize 10485760
現状は、XSLTCache と Response キャッシュの 2 通りがあります。 後者は、特別な構文のあるインクルードから出力の際のキャッシング目的で 呼び出されます。 詳細情報は、 $Response->Include() を見てください。

Miscellaneous

AuthServerVariables


デフォールトは、0 です。
基礎認証を使って、
AUTH_TYPE, AUTH_USER, AUTH_NAME, REMOTE_USER, & AUTH_PASSWD のように
$Request->ServerVariables をセットしたいなら、
このようにセットすると、Apache::ASPは、Apache->*auth* 命令から
上記の値を初期化します。
これらの環境変数を使うことは、
クロスプラットフォームでアプリケーションでの互換性を保たれるので
401 番の基礎認証を行っている際に、他のサーバでも同じようにセットされます。
  PerlSetVar AuthServerVariables 0

BufferingOn


デフォールトは、1 です。
真なら、バッファーは、Response オブジェクトを介し、出力されます。
Response オブジェクトは、$Response->Flush() が呼ばれた時か、
ASP スクリプトの終了時にのみ、クライアントブラウザに結果を送ります。
漸増的に多量の出力がフラッシュする事が必要になってきます。
0 で偽なら、CGI 様式で、クライアントへ直ちに出力されます。 出力が自動的にクライアントにフラッシュされると、 サーバ側でパフォーマンスで利点があるかもしれませんが、 可能性は小さいでしょう。
私は、いくらかの出力送信をしてから後で ASP スクリプトがエラーになると、 エラーの扱いが貧弱になりますので、on にしてあります。
  PerlSetVar BufferingOn 1

InodeNames


デフォールトは、0 です。1 にセットされると、
(OS の)デバイスと、i ノード数に基づいたサブルーチン名前空間に由来する
スクリプトとインクルードで、stat() の呼び出しを使います。
同じスクリプトへのシンボリックリンクを多用している場合には、
スクリプトが 1 回でコンパイルされる結果になるでしょう。
デバイスと、i ノード数を把握する、stat() コールがサポートされている
UNIX の趣きの(お好みの?)時のみ、お使いください。
  PerlSetVar InodeNames 1

RequestParams


デフォールトは、0 です。セットされると、
$Request->QueryString と $Request->Form の合わさった内容で
$Request->Params オブジェクトが生成されます。
こちらの方が、開発者には、
CGI.pm の param() メソッドに似て、便利でしょう。
  PerlSetVar RequestParams 1

StatINC


デフォールトは、0 です。真なら、ASP スクリプトでディスク上で、
自動的に変更されたPerl のライブラリを、再ロードします。
偽なら、ライブラリ変更を有効にするには、
www サーバを再スタートする必要があります。
例えば、confess Carp qw(confess) のような、エクスポートされる、 いかなる機能も、StatINC でリフレッシュされないのが、既知のバグです。 リフレッシュするには、www サーバを再スタートする必要があります。
この設定では、速度が遅くなるので、開発時のみお使いください。 製品版の StatINC は、StatINCMatch の項を見てください。
  PerlSetVar StatINC 1

StatINCMatch


デフォールトは、undef (未定義) です。
定義されると、StatINC でマッチした、モジュールを再ロードすべく、
正規表現として使われます。
StatINC は、製品としては、多大なパフォーマンス上での、
足かせとなります。、
したがって、実行時に手のかかる各スクリプトの再ロード際にチェックされる
モジュール(名)を絞り込めるので、
パフォーマンスでの足かせを緩和させる効果があり、有用と思われます。
StatINCMatch の設定は、 Class/Struct.pm, とすべての the LWP/.* ライブラリを再ロードすべく 一致させたいなら Struct|LWP という風な、正規表現であるべきです。
StatINCMatch を定義づけているなら、StatINC の定義は不要です。
  PerlSetVar StatINCMatch .*

StatScripts


デフォールトは、1 です。0 にセットされると、
スクリプト、global.asa、インクルードファイルは、再ロードされません。
あなたのアプリケーションで、Apache::ASP->Loader() 実行するような
Aoache mod_perl でのスタートと再スタートが対になるような操作では、
アプリケーションが固まってしまい、
次に、サーバが再スタートないしストップ/スタートをさせないと、
再ロードしない恐れがあります。(?)
製品では、スクリプトとモジュールを再ロードさせない利点がいくつかあります。 第一に、リクエスト毎に、スクリプト、そのインクルードファイル、 および global.asa を stat() しなければ、パーフォーマンス上、 若干の改善があります。
(第二に)アプリケーション開発の立場から見れば、 サーバがスタートないし再スタートする時に、 あなたのアプリケーションをスナップ写真のように 垣間見ることが出来ます。 この事は、開発レベルのソースからサーバでの製品への 修正が安心して行え、誤りのあるライブラリなどが すべてコピーされ紛れ込むような心配をしなくてすむようになります。
最後に、あなたが現実にはこのようにしなくても、 テストサーバでは、変更を再ロードしているのに、 製品段階で、サーバを再スタートないしストップ/スタートするまで、 反映されない、実際の製品で作業することになります。 この事は、あなたが、即座のバグ直しをしている間、 あなたの仲間が、構文エラーに合わずにすみます。
  PerlSetVar StatScripts 1

SoftRedirect


デフォールトは、0 です。真なら、$Response->Redirect() が
スクリプトを終了させません。
通常、Redirect() がコールされると、スクリプトは、自動的に終了します。
SoftRedirect を 1 にすることは、リダイレクトでの標準的な方法で、
リダイレクト後も、Html 出力を指定できるようになります。
  PerlSetVar SoftRedirect 0

Filter


On ないし Off で、デフォールトは、Off です。
フィルタリングを可能にすると、 Apache::SSI を介して実装されている
サーバサイドインクルード (SSI) を
フルに活用できる利点があります。
フィルタリングを伴う、SSI のフル実装した実例は、
./site/eg/.htaccess ファイルと
該当するスクリプトは、
./site/eg/ssi_filter.ssi にあります。
このオプションは、mod_perl v1.16 以上がインストールされ、 PERL_STACKED_HANDLERS が可能な設定になっている時のみ、 使用できます。 フィルタリングは、"filter aware" のような、 他のハンドラ(操作手段)との連携で使うことでしょう。 疑わしければ、あなたのシステムに、 mod_perl を、
  perl Makefile.PL EVERYTHING=1
を使って構築してください。
Apache::SSI を介したフィルタリングでは、 20% 近くのパフォーマンス減が予想されるでしょう。
  PerlSetVar Filter Off

CgiHeaders


デフォールトは、0 です。真なら、スクリプト出力は、
HTTP / CGI ヘッダのように、リクエストを受けた HTTP ヘッダに追加されます。 以下のように
  Set-Cookie: test=message

  <html>...
スクリプトの冒頭に付け加えられ、改行に先立つすべてのヘッダが、 $Response->AddHeader() を呼び出したように、追加されます。 この機能は、生の cgi スクリプトやその種類のコードとの互換性をとるためです。
0 にセットすると、CgiHeaders 様式のヘッダは、 スクリプトレスポンスからは構文解析されません。
  PerlSetVar CgiHeaders 0

Clean


デフォールトは、0 で、1 から 9 の間でセットします。
この設定では、text/html 出力が、どれくらい圧縮されるか決定します。
1 の設定では、空白文字の節約で、出力サイズは。10% 程度圧縮され、
パフォーマンス減は、5% 以下でしょう。
9 の設定では、いかなる場合でも、典型的には、
25% から 50% の節約になりますが、パフォーマンスでも、50% 減になるでしょう。
この設定は、HTML::Clean を介して実装されています。 スクリプト毎でのセッティングは、 $Response->{Clean} プロパティ を同様に、 0 から 9 にセットする事でも実現できます。
  PerlSetVar Clean 0

CompressGzip


デフォールトは、0 で、真なら、
Compress::Zlib がインストールされ、
クライアントのブラウザでサポートされている場合に、
HTML 出力が、gzip で圧縮され送信されます。
HTML 圧縮の程度は、クライアント側では、
その出力は、50% から 90% 減にもなります。
現に、40K の(サイズの) HTML は、圧縮されて、6K になったことを経験しました。
圧縮対象のリクエスト毎に、5% から 20% の、CPU 使用率になるでしょう。
いくつかの例では、ブラウザが、gzip エンコードを受け付けても 正しく変換できない場合もあり、注意してください。 この現象は、IE5 でプロキシを使用する時に見られますが、 プロキシを使用せず、URL が、.html ないし .htm で終わらないときには、 見られません。 このケースでは対処法が見つかっていませんので、 自己責任で、お使いください。
  PerlSetVar CompressGzip 1

FormFill


デフォールトは、0 です。真なら、$Request->Form() からの値で
HTML フォームを自動的に詰めるようにします。
この機能は、HTML::FillInForm で提供されます。
更なる情報は、(コマンドラインの) "perldoc HTML::FillInForm" と
実例の、./site/eg/formfill.asp で見てください。
この実装は、ランタイムで、$Response->{FormFill} = 1 とすることで HTML フォームベース毎に、可能になります。
  PerlSetVar FormFill 1

TimeHiRes


デフォールトは、0 です。これが、セットされ、
Time::HiRes がインストールされていると、
Apache::ASP がリクエストを処理する所要時間をミリ秒単位で測定できます。
この時間は、セッションマネージャー、modperl、Apache での
所要時間は含まれておらず、せいぜいの、おおざっぱな概算にすぎません。
Debug が同様にセットされていると、HTML 出力が、 そのスクリプトの処理時間を表す注釈になることができます。
システムデバクが、Debug -1 ないし -2 となっていると 他のシステムに関するメッセージといっしょに、 Apache エラーログでも、この時間を得る事ができます。

Mail Administration(メール管理)


Apache::ASP には、強力な電子メール管理の拡張仕様があり、
夜寝ていても、Web サイトにエラーが起こると、
ただちに(エラーを、メールで)知ることが出来ます。
すでに可能になった、これらの実装を用いて、簡単に
$Server->Mail(\%mail) API 拡張仕様が提供されます。
仕様は、オブジェクト セクション
の中(の該当事項)を読んでください。

MailHost


MailHost は、Mail*(群)設定指令が、
電子メールを送信するのに使われる、SMTP サーバ名です。
デフォールトでは、Net::Config のインストール時にセッティングした
Net::SMTP で使用する、SMTP メールホストです。
この(Net::Configの)セッティングは、(Apache::ASPでの)設定を書き変えます。、
Net::Config ファイルで指定した、メールホストは、 MailHost 指定のサーバに対して、プライマリのサーバが動かない時の バックアップの SMTP サーバとして働きます。
  PerlSetVar MailHost smtp.yourdomain.com.foobar

MailFrom


デフォールトは、NONE です。
セットすると、$Server->Mail() API 拡張で使われる
メールヘッダの From: におかれる、デフォールトのメールアドレスを
指定します。これは、MailErrorsTo と MailAlertTo も同じ様に設定されます。
  PerlSetVar MailFrom youremail@yourdomain.com.foobar 

MailErrorsTo


デフォールトはありません。
セットされると、Apache::ASP のスクリプトが、コンパイル時ないし実行時に
ASP サーバエラーのエラーコード 500 が起こると、自動的に、この設定のアドレスへ
メールされます。
この事で、管理者は、ASP スクリプト製品のバグから起こる
ユーザレベルで発生した結果に対して、迅速な対応ができます。
また片一、「ファイルが見つからない」といった 404 でのエラーは、
Apache により直接、操作されます。

実行中に、この設定を検出する簡単な方法は、ASP スクリプトで、die() をコールし、 ASP 500の内部エラーを発生させる事です。
Debug での、2 の設定とこのセッティングは、お互いに相い入れないものです。 Debug 2 は、エラーをブラウザに表示させるという開発段階のセッティングで、 MailErrorTo は、エラーは、サイレントに記録され、 web 管理者にメール送信されるという、製品段階のセッティングです。
  PerlSetVar MailErrorsTo youremail@yourdomain.com

MailAlertTo


このアドレスへは、ASP で、500 番のサーバエラーが起こるといつでも、
メッセージが、ページャ閲覧できる程度の、テキストの短さににフィットされ
送信されます。
この設定は、

Debug 2 がセットされていると、この設定は動きませので、 製品段階でのみ用い、開発段階では、Debug 2 のほうを使ってください。
  PerlSetVar MailAlertTo youremail@yourdomain.com

MailAlertPeriod


デフォールトは、20 分です。
この設定では、MailAlertTo によって作られた一つ一つの警告メールの
間隔時間を指定します。
MailAlertTo の目的は、管理者に、www サーバでのエラーの有無を喚起するためです。
MailErrorsTo は、その現象へ迅速にデバグを行うためにあります。
  PerlSetVar MailAlertPeriod 20

File Uploads

FileUploadMax


デフォールトは、0 です。
セットするのは、ファイルアップロードの大きさのバイト数でのリミットです。
この設定は、ファイルアップロード操作に先立つ、
$CGI::POST_MAXでの設定で、実現させています。
(同じように)動かすには、設定前に、開発者は、$CGI::POST_MAX の値を直接コードすることも可能です。【訳者注】以下の設定では、オリジナルサイトにない、FileUploadMax を補足。
  PerlSetVar FileUploadMax 100000

FileUploadTemp


デフォールトは、0 です。
セットされると、応答(リクエスト)の間、ディスクに一時ファイルを作成します。
他のプログラム処理のためには、有用ですが、
(同じ)オペレーションシステムの他のユーザがスクリプト実行中に、
このファイルを読む可能性があるという、安全上のリスクはあります。
一時ファイルへのパスは、 $Request->{FileUpload}{$form_field}{TempFile} (の値)で得ることが出来ます。 ファイルアップロード の通常の方法は、 $Request->{Form}{$form_field} でアップロードさせる、 <$filehandle> を使っても同じようにできます。 ファイルアップロードについての詳細は、 CGIセクションとオブジェクトの $Request セクションを見てください。.
.
  PerlSetVar FileUploadTemp 0
 
Copyright © 1998-2002, Joshua Chamas, Chamas Enterprises Inc.