Apache-ASP
view release on metacpan or search on metacpan
site/config.html view on Meta::CPAN
long term running of dbms than deleting individual records,
because dbm formats will often degrade in performance with
lots of insert & deletes.
<font face="courier new" size=3><pre>
</pre></font>Units of M, K, and B are supported for megabytes, kilobytes, and bytes,
with the default unit being B, so the following configs all mean the
same thing;
<font face="courier new" size=3><pre>
PerlSetVar CacheSize 10M
PerlSetVar CacheSize 10240K
PerlSetVar CacheSize 10485760B
PerlSetVar CacheSize 10485760
</pre></font>There are 2 caches currently, the XSLTCache, and the
Response cache, the latter which is currently invoked
for caching output from includes with special syntax.
See $Response->Include() for more info on the Response cache.</font>
<p>
<a name=Miscellaneou387baf01></a>
<font face=verdana><font class=title size=+0 color=#555555><b>Miscellaneous</b></font>
</font>
<p>
<a name=AuthServerVaa7584921></a>
<font face=verdana><font class=title size=-1 color=#555555><b>AuthServerVariables</b></font>
<font face="courier new" size=3><pre>
</pre></font>default 0. If you are using basic auth and would like
$Request->ServerVariables set like AUTH_TYPE, AUTH_USER,
AUTH_NAME, REMOTE_USER, & AUTH_PASSWD, then set this and
Apache::ASP will initialize these values from Apache->*auth*
commands. Use of these environment variables keeps applications
cross platform compatible as other servers set these too
when performing basic 401 auth.
<font face="courier new" size=3><pre>
PerlSetVar AuthServerVariables 0
</pre></font>
<p>
<a name=BufferingOn></a>
<font face=verdana><font class=title size=-1 color=#555555><b>BufferingOn</b></font>
<font face="courier new" size=3><pre>
</pre></font>default 1, if true, buffers output through the response object.
$Response object will only send results to client browser if
a $Response->Flush() is called, or if the asp script ends. Lots of
output will need to be flushed incrementally.
<font face="courier new" size=3><pre>
</pre></font>If false, 0, the output is immediately written to the client,
<a href=cgi.html><font size=-1 face=verdana><b>CGI</b></font></a> style. There will be a performance hit server side if output
is flushed automatically to the client, but is probably small.
<font face="courier new" size=3><pre>
</pre></font>I would leave this on, since error handling is poor, if your asp
script errors after sending only some of the output.
<font face="courier new" size=3><pre>
PerlSetVar BufferingOn 1
</pre></font>
<p>
<a name=InodeNames></a>
<font face=verdana><font class=title size=-1 color=#555555><b>InodeNames</b></font>
<font face="courier new" size=3><pre>
</pre></font>Default 0. Set to 1 to uses a stat() call on scripts and includes to
derive subroutine namespace based on device and inode numbers. In case of
multiple symbolic links pointing to the same script this will result
in the script being compiled only once. Use only on unix flavours
which support the stat() call that know about device and inode
numbers.
<font face="courier new" size=3><pre>
PerlSetVar InodeNames 1
</pre></font>
<p>
<a name=RequestParam25a784ba></a>
<font face=verdana><font class=title size=-1 color=#555555><b>RequestParams</b></font>
<font face="courier new" size=3><pre>
</pre></font>Default 0, if set creates $Request->Params object with combined
contents of $Request->QueryString and $Request->Form. This
is for developer convenience simlar to <a href=http://stein.cshl.org/WWW/software/CGI/cgi_docs.html><font size=-1 face=verdana><b>CGI.pm</b></font></a>'s param() method.
<font face="courier new" size=3><pre>
PerlSetVar RequestParams 1
</pre></font>
<p>
<a name=RequestBinarc4419e4b></a>
<font face=verdana><font class=title size=-1 color=#555555><b>RequestBinaryRead</b></font>
<font face="courier new" size=3><pre>
</pre></font>Default On, if set to Off will not read POST data into $Request->Form().
<font face="courier new" size=3><pre>
</pre></font>One potential reason for configuring this to Off might be to initialize the Apache::ASP
object in an Apache handler phase earlier than the normal PerlRequestHandler
phase, so that it does not interfere with normal reading of POST data later
in the request.
<font face="courier new" size=3><pre>
PerlSetVar RequestBinaryRead On
</pre></font>
<p>
<a name=StatINC></a>
<font face=verdana><font class=title size=-1 color=#555555><b>StatINC</b></font>
<font face="courier new" size=3><pre>
</pre></font>default 0, if true, reloads perl libraries that have changed
on disk automatically for ASP scripts. If false, the www server
must be restarted for library changes to take effect.
<font face="courier new" size=3><pre>
</pre></font>A known bug is that any functions that are exported, e.g. confess
Carp qw(confess), will not be refreshed by StatINC. To refresh
these, you must restart the www server.
<font face="courier new" size=3><pre>
</pre></font>This setting should be used in development only because it is so slow.
For a production version of StatINC, see StatINCMatch.
<font face="courier new" size=3><pre>
PerlSetVar StatINC 1
</pre></font>
<p>
<a name=StatINCMatch></a>
<font face=verdana><font class=title size=-1 color=#555555><b>StatINCMatch</b></font>
<font face="courier new" size=3><pre>
</pre></font>default undef, if defined, it will be used as a regular expression
to reload modules that match as in StatINC. This is useful because
StatINC has a very high performance penalty in production, so if
you can narrow the modules that are checked for reloading each
script execution to a handful, you will only suffer a mild performance
penalty.
<font face="courier new" size=3><pre>
</pre></font>The StatINCMatch setting should be a regular expression like: Struct|LWP
which would match on reloading Class/Struct.pm, and all the LWP/.*
libraries.
<font face="courier new" size=3><pre>
</pre></font>If you define StatINCMatch, you do not need to define StatINC.
<font face="courier new" size=3><pre>
PerlSetVar StatINCMatch .*
</pre></font>
<p>
<a name=StatScripts></a>
<font face=verdana><font class=title size=-1 color=#555555><b>StatScripts</b></font>
<font face="courier new" size=3><pre>
</pre></font>default 1, if set to 0, changed scripts, global.asa, and includes
will not be reloaded. Coupled with Apache <a href=http://perl.apache.org><font size=-1 face=verdana><b>mod_perl</b></font></a> startup and restart
handlers executing Apache::ASP->Loader() for your application
this allows your application to be frozen, and only reloaded on the
next server restart or stop/start.
<font face="courier new" size=3><pre>
</pre></font>There are a few advantages for not reloading scripts and modules
in production. First there is a slight performance improvement
by not having to stat() the script, its includes and the global.asa
every request.
<font face="courier new" size=3><pre>
</pre></font>From an application deployment standpoint, you
also gain the ability to deploy your application as a
snapshot taken when the server starts and restarts.
This provides you with the reassurance that during a
production server update from development sources, you
do not have to worry with sources being used for the
wrong libraries and such, while they are all being
copied over.
<font face="courier new" size=3><pre>
</pre></font>Finally, though you really should not do this, you can
work on a live production application, with a test server
reloading changes, but your production server does see
the changes until you restart or stop/start it. This
saves your public from syntax errors while you are just
doing a quick bug fix.
<font face="courier new" size=3><pre>
PerlSetVar StatScripts 1
</pre></font>
<p>
<a name=SoftRedirect></a>
<font face=verdana><font class=title size=-1 color=#555555><b>SoftRedirect</b></font>
<font face="courier new" size=3><pre>
</pre></font>default 0, if true, a $Response->Redirect() does not end the
script. Normally, when a Redirect() is called, the script
is ended automatically. SoftRedirect 1, is a standard
way of doing redirects, allowing for html output after the
redirect is specified.
<font face="courier new" size=3><pre>
PerlSetVar SoftRedirect 0
</pre></font>
<p>
<a name=Filter></a>
<font face=verdana><font class=title size=-1 color=#555555><b>Filter</b></font>
<font face="courier new" size=3><pre>
</pre></font>On/Off, default Off. With filtering enabled, you can take advantage of
full server side includes (<a href=ssi.html><font size=-1 face=verdana><b>SSI</b></font></a>), implemented through Apache::SSI.
SSI is implemented through this mechanism by using Apache::Filter.
A sample configuration for full SSI with filtering is in the
<a href=eg/.htaccess>./site/eg/.htaccess</a> file, with a relevant example script <a href=eg/ssi_filter.ssi>./site/eg/ssi_filter.ssi</a>.
<font face="courier new" size=3><pre>
</pre></font>You may only use this option with modperl v1.16 or greater installed
and PERL_STACKED_HANDLERS enabled. Filtering may be used in
conjunction with other handlers that are also "filter aware".
If in doubt, try building your <a href=http://perl.apache.org><font size=-1 face=verdana><b>mod_perl</b></font></a> with
<font face="courier new" size=3><pre>
perl Makefile.PL EVERYTHING=1
</pre></font>With filtering through Apache::SSI, you should expect near a
a 20% performance decrease.
<font face="courier new" size=3><pre>
PerlSetVar Filter Off
</pre></font>
<p>
<a name=CgiHeaders></a>
<font face=verdana><font class=title size=-1 color=#555555><b>CgiHeaders</b></font>
<font face="courier new" size=3><pre>
( run in 1.115 second using v1.01-cache-2.11-cpan-39bf76dae61 )