<% Web Applications with Apache & mod_perl %>


Powered by Apache::ASP
Powered by ModPerl and Apache
Powered by Perl
You may use a <Files ...> directive in your httpd.conf Apache configuration file to make Apache::ASP start ticking. Configure the optional settings if you want, the defaults are fine to get started. The settings are documented below. Make sure Global is set to where your web applications global.asa is if you have one!
 PerlModule  Apache::ASP
 <Files ~ (\.asp)>    
   SetHandler  perl-script
   PerlHandler Apache::ASP
   PerlSetVar  Global .
   PerlSetVar  StateDir /tmp/asp
NOTE: do not use this for the examples in ./site/eg. To get the examples working, check out the Quick Start section of INSTALL
You may use other Apache configuration tags like <Directory>, <Location>, and <VirtualHost>, to separately define ASP configurations, but using the <Files> tag is natural for ASP application building because it lends itself naturally to mixed media per directory. For building many separate ASP sites, you might want to use separate .htaccess files, or <Files> tags in <VirtualHost> sections, the latter being better for performance.

Core XMLSubsMatch
Global XMLSubsStrict
GlobalPackage XMLSubsPerlArgs
UniquePackages XSLT
DynamicIncludes XSLTMatch
IncludesDir XSLTParser
NoCache XSLTCache
State Management
NoState Caching
AllowSessionState CacheDB
AllowApplicationState CacheDir
StateDir CacheSize
StateDB Miscellaneous
StateCache AuthServerVariables
StateSerializer BufferingOn
Sessions RequestParams
CookiePath RequestBinaryRead
CookieDomain StatINC
SessionTimeout StatINCMatch
SecureSession StatScripts
HTTPOnlySession SoftRedirect
ParanoidSession Filter
SessionSerialize CgiHeaders
SessionCount Clean
Cookieless Sessions FormFill
SessionQueryParse TimeHiRes
SessionQuery Mail Administration
SessionQueryMatch MailHost
SessionQueryForce MailFrom
Developer Environment MailAlertTo
UseStrict MailAlertPeriod
DebugBufferLength File Uploads
PodComments FileUploadMax
CollectionItem FileUploadTemp



Global is the nerve center of an Apache::ASP application, in which
the global.asa may reside defining the web application's 
event handlers.
This directory is pushed onto @INC, so you will be able to "use" and "require" files in this directory, and perl modules developed for this application may be dropped into this directory, for easy use.
Unless StateDir is configured, this directory must be some writeable directory by the web server. $Session and $Application object state files will be stored in this directory. If StateDir is configured, then ignore this paragraph, as it overrides the Global directory for this purpose.
Includes, specified with <!--#include file=somefile.inc--> or $Response->Include() syntax, may also be in this directory, please see section on includes for more information.
  PerlSetVar Global /tmp


Perl package namespace that all scripts, includes, & global.asa
events are compiled into.  By default, GlobalPackage is some
obscure name that is uniquely generated from the file path of 
the Global directory, and global.asa file.  The use of explicitly
naming the GlobalPackage is to allow scripts access to globals
and subs defined in a perl module that is included with commands like:
  in perl script: use Some::Package;
  in apache conf: PerlModule Some::Package

  PerlSetVar GlobalPackage Some::Package


default 0.  Set to 1 to compile each script into its own perl package,
so that subroutines defined in one script will not collide with another.
By default, ASP scripts in a web application are compiled into the *same* perl package, so these scripts, their includes, and the global.asa events all share common globals & subroutines defined by each other. The problem for some developers was that they would at times define a subroutine of the same name in 2+ scripts, and one subroutine definition would redefine the other one because of the namespace collision.
  PerlSetVar UniquePackages 0


default 0.  SSI file includes are normally inlined in the calling 
script, and the text gets compiled with the script as a whole. 
With this option set to TRUE, file includes are compiled as a
separate subroutine and called when the script is run.  
The advantage of having this turned on is that the code compiled
from the include can be shared between scripts, which keeps the 
script sizes smaller in memory, and keeps compile times down.
  PerlSetVar DynamicIncludes 0


no defaults.  If set, this directory will also be used to look
for includes when compiling scripts.  By default the directory 
the script is in, and the Global directory are checked for includes.  
This extension was added so that includes could be easily shared between ASP applications, whereas placing includes in the Global directory only allows sharing between scripts in an application.
  PerlSetVar IncludesDir .
Also, multiple includes directories may be set by creating a directory list separated by a semicolon ';' as in
  PerlSetVar IncludesDir ../shared;/usr/local/asp/shared
Using IncludesDir in this way creates an includes search path that would look like ., Global, ../shared, /usr/local/asp/shared The current directory of the executing script is checked first whenever an include is specified, then the Global directory in which the global.asa resides, and finally the IncludesDir setting.


Default 0, if set to 1 will make it so that neither script nor
include compilations are cached by the server.  Using this configuration
will save on memory but will slow down script execution.  Please
see the TUNING section for other strategies on improving site performance.
  PerlSetVar NoCache 0

State Management


default 0, if true, neither the $Application nor $Session objects will
be created.  Use this for a performance increase.  Please note that 
this setting takes precedence over the AllowSessionState and
AllowApplicationState settings.
  PerlSetVar NoState 0


Set to 0 for no session tracking, 1 by default
If Session tracking is turned off, performance improves,
but the $Session object is inaccessible.
  PerlSetVar AllowSessionState 1    
Note that if you want to dissallow session creation for certain non web browser user agents, like search engine spiders, you can use an init handler like:
  PerlInitHandler "sub { $_[0]->dir_config('AllowSessionState', 0) }"


Default 1.  If you want to leave $Application undefined, then set this
to 0, for a performance increase of around 2-3%.  Allowing use of 
$Application is less expensive than $Session, as there is more
work for the StateManager associated with $Session garbage collection
so this parameter should be only used for extreme tuning.
  PerlSetVar AllowApplicationState 1


default $Global/.state.  State files for ASP application go to 
this directory.  Where the state files go is the most important
determinant in what makes a unique ASP application.  Different
configs pointing to the same StateDir are part of the same
ASP application.
The default has not changed since implementing this config directive. The reason for this config option is to allow operating systems with caching file systems like Solaris to specify a state directory separately from the Global directory, which contains more permanent files. This way one may point StateDir to /tmp/myaspapp, and make one's ASP application scream with speed.
  PerlSetVar StateDir ./.state


default 10, this number specifies the numbers of times per SessionTimeout
that timed out sessions are garbage collected.  The bigger the number,
the slower your system, but the more precise Session_OnEnd's will be 
run from global.asa, which occur when a timed out session is cleaned up,
and the better able to withstand Session guessing hacking attempts.
The lower the number, the faster a normal system will run.  
The defaults of 20 minutes for SessionTimeout and 10 times for StateManager, has dead Sessions being cleaned up every 2 minutes.
  PerlSetVar StateManager 10


default SDBM_File, this is the internal database used for state
objects like $Application and $Session.  Because an SDBM_File %hash 
has a limit on the size of a record key+value pair, usually 1024 bytes,
you may want to use another tied database like DB_File or
With lightweight $Session and $Application use, you can get away with SDBM_File, but if you load it up with complex data like
  $Session{key} = { # very large complex object }
you might max out the 1024 limit.
Currently StateDB can be: SDBM_File, MLDBM::Sync::SDBM_File, DB_File, and GDBM_File. Please let me know if you would like to add any more to this list.
As of version .18, you may change this setting in a live production environment, and new state databases created will be of this format. With a prior version if you switch to a new StateDB, you would want to delete the old StateDir, as there will likely be incompatibilities between the different database formats, including the way garbage collection is handled.
  PerlSetVar StateDB SDBM_File


Deprecated as of 2.23.  There is no equivalent config for
the functionality this represented from that version on.
The 2.23 release represented a significant rewrite
of the state management, moving to MLDBM::Sync for its


default Data::Dumper, you may set this to Storable for 
faster serialization and storage of data into state objects.
This is particularly useful when storing large objects in
$Session and $Application, as the Storable.pm module has a faster
implementation of freezing and thawing data from and to
perl structures.  Note that if you are storing this much
data in your state databases, you may want to use 
DB_File since it does not have the default 1024 byte limit 
that SDBM_File has on key/value lengths.
This configuration setting may be changed in production as the state database's serializer type is stored in the internal state manager which will always use Data::Dumper & SDBM_File to store data.
  PerlSetVar StateSerializer Data::Dumper



URL root that client responds to by sending the session cookie.
If your asp application falls under the server url "/asp", 
then you would set this variable to /asp.  This then allows
you to run different applications on the same server, with
different user sessions for each application.
  PerlSetVar CookiePath /


Default 0, this NON-PORTABLE configuration will allow sessions to span
multiple web sites that match the same domain root.  This is useful if
your web sites are hosted on the same machine and can share the same
StateDir configuration, and you want to shared the $Session data 
across web sites.  Whatever this is set to, that will add a 
  ; domain=$CookieDomain
part to the Set-Cookie: header set for the session-id cookie.
  PerlSetVar CookieDomain .your.global.domain


Default 20 minutes, when a user's session has been inactive for this
period of time, the Session_OnEnd event is run, if defined, for 
that session, and the contents of that session are destroyed.
  PerlSetVar SessionTimeout 20


default 0.  Sets the secure tag for the session cookie, so that the cookie
will only be transmitted by the browser under https transmissions.
  PerlSetVar SecureSession 1


default 0. Sets HttpOnly flag to session cookie to mitigate XSS attacks.
Supported by most modern browsers, it only allows access to the
session cookie by the server (ie NOT Javascript)
  PerlSetVar HTTPOnlySession 1


default 0.  When true, stores the user-agent header of the browser 
that creates the session and validates this against the session cookie presented.
If this check fails, the session is killed, with the rationale that 
there is a hacking attempt underway.
This config option was implemented to be a smooth upgrade, as you can turn it off and on, without disrupting current sessions. Sessions must be created with this turned on for the security to take effect.
This config option is to help prevent a brute force cookie search from being successful. The number of possible cookies is huge, 2^128, thus making such a hacking attempt VERY unlikely. However, on the off chance that such an attack is successful, the hacker must also present identical browser headers to authenticate the session, or the session will be destroyed. Thus the User-Agent acts as a backup to the real session id. The IP address of the browser cannot be used, since because of proxies, IP addresses may change between requests during a session.
There are a few browsers that will not present a User-Agent header. These browsers are considered to be browsers of type "Unknown", and this method works the same way for them.
Most people agree that this level of security is unnecessary, thus it is titled paranoid :)
  PerlSetVar ParanoidSession 0


default 0, if true, locks $Session for duration of script, which
serializes requests to the $Session object.  Only one script at
a time may run, per user $Session, with sessions allowed.
Serialized requests to the session object is the Microsoft ASP way, but is dangerous in a production environment, where there is risk of long-running or run-away processes. If these things happen, a session may be locked for an indefinite period of time. A user STOP button should safely quit the session however.
  PerlSetVar SessionSerialize 0


default 0, if true enables the $Application->SessionCount API
which returns how many sessions are currently active in 
the application.  This config was created 
because there is a performance hit associated with this
count tracking, so it is disabled by default.
  PerlSetVar SessionCount 1

Cookieless Sessions


default 0, if true, will automatically parse the $Session
session id into the query string of each local URL found in the 
$Response buffer.  For this setting to work therefore, 
buffering must be enabled.  This parsing will only occur
when a session cookie has not been sent by a browser, so the 
first script of a session enabled site, and scripts viewed by 
web browsers that have cookies disabled will trigger this behavior.
Although this runtime parsing method is computationally expensive, this cost should be amortized across most users that will not need this URL parsing. This is a lazy programmer's dream. For something more efficient, look at the SessionQuery setting. For more information about this solution, please read the SESSIONS section.
  PerlSetVar SessionQueryParse 0


default 0, set to a regexp pattern that matches all URLs that you 
want to have SessionQueryParse parse in session ids.  By default
SessionQueryParse only modifies local URLs, but if you name
your URLs of your site with absolute URLs like http://localhost
then you will need to use this setting.  So to match 
http://localhost URLs, you might set this pattern to 
^http://localhost.  Note that by setting this config,
you are also setting SessionQueryParse.
  PerlSetVar SessionQueryParseMatch ^https?://localhost


default 0, if set, the session id will be initialized from
the $Request->QueryString if not first found as a cookie.
You can use this setting coupled with the 
  $Server->URL($url, \%params) 
API extension to generate local URLs with session ids in their query strings, for efficient cookieless session support. Note that if a browser has cookies disabled, every URL to any page that needs access to $Session will need to be created by this method, unless you are using SessionQueryParse which will do this for you automatically.
  PerlSetVar SessionQuery 0


default 0, set to a regexp pattern that will match
URLs for $Server->URL() to add a session id to.  SessionQuery
normally allows $Server->URL() to add session ids just to 
local URLs, so if you use absolute URL references like 
http://localhost/ for your web site, then just like 
with SessionQueryParseMatch, you might set this pattern
to ^http://localhost
If this is set, then you don't need to set SessionQuery, as it will be set automatically.
  PerlSetVar SessionQueryMatch ^http://localhost


default 0, set to 1 if you want to disallow the use of cookies
for session id passing, and only allow session ids to be passed
on the query string via SessionQuery and SessionQueryParse settings.
  PerlSetVar SessionQueryForce 1

Developer Environment


default 0, if set to 1, will compile all scripts, global.asa
and includes with "use strict;" inserted at the head of 
the file, saving you from the painful process of strictifying
code that was not strict to begin with.
Because of how essential "use strict" programming is in a mod_perl environment, this default might be set to 1 one day, but this will be up for discussion before that decision is made.
Note too that errors triggered by "use strict" are now captured as part of the normal Apache::ASP error handling when this configuration is set, otherwise "use strict" errors will not be handled properly, so using UseStrict is better than your own "use strict" statements.
PerlSetVar UseStrict 1


1 for server log debugging, 2 for extra client html output,
3 for microtimes logged. Use 1 for production debugging, 
use 2 or 3 for development.  Turn off if you are not 
debugging.  These settings activate $Response->Debug().
  PerlSetVar Debug 2	
If Debug 3 is set and Time::HiRes is installed, microtimes will show up in the log, and also calculate the time between one $Response->Debug() and another, so good for a quick benchmark when you glance at the logs.
  PerlSetVar Debug 3
If you would like to enable system level debugging, set Debug to a negative value. So for system level debugging, but no output to browser:
  PerlSetVar Debug -1


Default 100, set this to the number of bytes of the 
buffered output's tail you want to see when an error occurs
and Debug 2 or MailErrorsTo is set, and when 
BufferingOn is enabled.  
With buffering the script output will not naturally show up when the script errors, as it has been buffered by the $Response object. It helps to see where in the script output an error halted the script, so the last bytes of the buffered output are included with the rest of the debugging information.
For a demo of this functionality, try the ./site/eg/syntax_error.asp script, and turn buffering on.


default 1.  With pod comments turned on, perl pod style comments
and documentation are parsed out of scripts at compile time.
This make for great documentation and a nice debugging tool,
and it lets you comment out perl code and html in blocks.  
Specifically text like this:
 text or perl code here
will get ripped out of the script before compiling. The =pod and =cut perl directives must be at the beginning of the line, and must be followed by the end of the line.
  PerlSetVar PodComments 1


Enables PerlScript syntax like:
Old PerlScript syntax, enabled with
  use Win32::OLE qw(in valof with OVERLOAD);
is like native syntax
Only in Apache::ASP, can the above be written as:
which you would do if you _really_ needed the speed.



default not defined, set to some regexp pattern
that will match all XML and HTML tags that you want
to have perl subroutines handle.  The is Apache::ASP's
custom tag technology, and can be used to create
powerful extensions to your XML and HTML rendering.
Please see XML/XSLT section for instructions on its use.
  PerlSetVar XMLSubsMatch my:[\w\-]+


default 0, when set XMLSubs will only take arguments
that are properly formed XML tag arguments like:
 <my:sub arg1="value" arg2="value" />
By default, XMLSubs accept arbitrary perl code as argument values:
 <my:sub arg1=1+1 arg2=&perl_sub()/>
which is not always wanted or expected. Set XMLSubsStrict to 1 if this is the case.
  PerlSetVar XMLSubsStrict 1


default 1, when set attribute values will be interpreted
as raw perl code so that these all would execute as one
would expect:
 <my:xmlsubs arg='1' arg2="2" arg3=$value arg4="1 $value" />
With the 2.45 release, 0 may be set for this configuration or a more ASP style variable interpolation:
 <my:xmlsubs arg='1' arg2="2" args3="<%= $value %>" arg4="1 <%= $value %>" />
This configuration is being introduced experimentally in version 2.45, as it will become the eventual default in the 3.0 release.
  PerlSetVar XMLSubsPerlArgs Off


default not defined, if set to a file, ASP scripts will
be regarded as XML output and transformed with the given
XSL file with XML::XSLT.  This XSL file will also be
executed as an ASP script first, and its output will be
the XSL data used for the transformation.  This XSL file
will be executed as a dynamic include, so may be located
in the current directory, Global, or IncludesDir.
Please see the XML/XSLT section for an explanation of its use.
  PerlSetVar XSLT template.xsl


default .*, if XSLT is set by default all ASP scripts 
will be XSL transformed by the specified XSL template.
This regexp setting will tell XSLT which file names to 
match with doing XSL transformations, so that regular
HTML ASP scripts and XML ASP scripts can be configured
with the same configuration block.  Please see
./site/eg/.htaccess for an example of its use.
  PerlSetVar XSLTMatch \.xml$


default XML::XSLT, determines which perl module to use for 
XSLT parsing.  This is a new config as of 2.11.
Also supported is XML::Sablotron which does not
handle XSLT with the exact same output, but is about
10 times faster than XML::XSLT.  XML::LibXSLT may
also be used as of version 2.29, and seems to be
about twice again as fast as XML::Sablotron,
and a very complete XSLT implementation.
  PerlSetVar XSLTParser XML::XSLT
  PerlSetVar XSLTParser XML::Sablotron
  PerlSetVar XSLTParser XML::LibXSLT


Activate XSLT file based caching through CacheDB, CacheDir,
and CacheSize settings.  This gives cached XSLT performance
near AxKit and greater than Cocoon.  XSLT caches transformations
keyed uniquely by XML & XSLT inputs.
  PerlSetVar XSLTCache 1


as of version 2.11, this config is no longer supported.


The output caching layer is a file dbm based output cache that runs
on top of the MLDBM::Sync so inherits its performance characteristics.  
With CacheDB set to MLDBM::Sync::SDBM_File, the cache layer is 
very fast at caching entries up to 20K in size, but for greater 
cached items, you should set CacheDB to another dbm like DB_File 
or GDBM_File.
In order for the cache layer to function properly, whether for $Response->Include() output caching, see OBJECTS, or XSLT caching, see XML/XSLT, then Apache::ASP must be loaded in the parent httpd like so:
  # httpd.conf
  PerlModule Apache::ASP
    -- or --
    use Apache::ASP;
The cache layer automatically expires entries upon server restart, but for this to work, a $ServerID must be computed when the Apache::ASP module gets loaded to store in each cached item. Without the above done, each child httpd process will get its own $ServerID, so caching will not work at all.
This said, output caching will not work in raw CGI mode, just running under mod_perl.


Like StateDB, sets dbm format for caching.  Since SDBM_File
only support key/values pairs of around 1K max in length,
the default for this is MLDBM::Sync::SDBM_File, which is very
fast for < 20K output sizes.  For caching larger data than 20K,
DB_File or GDBM_File are probably better to use.
  PerlSetVar CacheDB MLDBM::Sync::SDBM_File

Here are some benchmarks about the CacheDB when used with caching output from $Response->Include(\%cache) running on a Linux 2.2.14 dual PIII-450. The variables are output size being cached & the CacheDB used, the default being MLDBM::Sync::SDBM_File.
CacheDBOutput CachedOperationOps/sec
MLDBM::Sync::SDBM_File 3200 bytes read 177
DB_File 3200 bytes read 59
MLDBM::Sync::SDBM_File 32000 bytes read 42
DB_File 32000 bytes read 53
MLDBM::Sync::SDBM_File 3200 bytes write 42
DB_File 3200 bytes write 39
For your own benchmarks to test the relative speeds of the various DBMs under MLDBM::Sync, which is used by CacheDB, you may run the ./bench/bench_sync.pl script from the MLDBM::Sync distribution on your system.


By default, the cache directory is at StateDir/cache,
but CacheDir can be used to set the StateDir value for 
caching purposes.  One may want the CacheDir separate
from StateDir for example StateDir might be a centrally
network mounted file system, while CacheDir might be
a local file cache.
  PerlSetVar CacheDir /tmp/asp_demo
On a system like Solaris where there is a RAM disk mounted on the system like /tmp, I could put the CacheDir there. On a system like Linux where files are cached pretty well by default, this is less important.


By default, this is 10M of data per cache.  When any cache, 
like the XSLTCache, reaches this limit, the cache will be purged 
by deleting the cached dbm files entirely.  This is better for 
long term running of dbms than deleting individual records, 
because dbm formats will often degrade in performance with 
lots of insert & deletes.
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;
  PerlSetVar CacheSize 10M
  PerlSetVar CacheSize 10240K
  PerlSetVar CacheSize 10485760B
  PerlSetVar CacheSize 10485760
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.



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.
  PerlSetVar AuthServerVariables 0


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.
If false, 0, the output is immediately written to the client, CGI style. There will be a performance hit server side if output is flushed automatically to the client, but is probably small.
I would leave this on, since error handling is poor, if your asp script errors after sending only some of the output.
  PerlSetVar BufferingOn 1


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 
  PerlSetVar InodeNames 1


Default 0, if set creates $Request->Params object with combined 
contents of $Request->QueryString and $Request->Form.  This
is for developer convenience simlar to CGI.pm's param() method.
  PerlSetVar RequestParams 1


Default On, if set to Off will not read POST data into $Request->Form().
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.
  PerlSetVar RequestBinaryRead On


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.
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.
This setting should be used in development only because it is so slow. For a production version of StatINC, see StatINCMatch.
  PerlSetVar StatINC 1


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 
The StatINCMatch setting should be a regular expression like: Struct|LWP which would match on reloading Class/Struct.pm, and all the LWP/.* libraries.
If you define StatINCMatch, you do not need to define StatINC.
  PerlSetVar StatINCMatch .*


default 1, if set to 0, changed scripts, global.asa, and includes
will not be reloaded.  Coupled with Apache mod_perl 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.
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.
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.
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.
  PerlSetVar StatScripts 1


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.
  PerlSetVar SoftRedirect 0


On/Off, default Off.  With filtering enabled, you can take advantage of 
full server side includes (SSI), 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 
./site/eg/.htaccess file, with a relevant example script ./site/eg/ssi_filter.ssi.
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 mod_perl with
  perl Makefile.PL EVERYTHING=1
With filtering through Apache::SSI, you should expect near a a 20% performance decrease.
  PerlSetVar Filter Off


default 0.  When true, script output that looks like HTTP / CGI
headers, will be added to the HTTP headers of the request.
So you could add:
  Set-Cookie: test=message

to the top of your script, and all the headers preceding a newline will be added as if with a call to $Response->AddHeader(). This functionality is here for compatibility with raw cgi scripts, and those used to this kind of coding.
When set to 0, CgiHeaders style headers will not be parsed from the script response.
  PerlSetVar CgiHeaders 0


default 0, may be set between 1 and 9.  This setting determine how much
text/html output should be compressed.  A setting of 1 strips mostly
white space saving usually 10% in output size, at a performance cost
of less than 5%.  A setting of 9 goes much further saving anywhere
25% to 50% typically, but with a performance hit of 50%.
This config option is implemented via HTML::Clean. Per script configuration of this setting is available via the $Response->{Clean} property, which may also be set between 0 and 9.
  PerlSetVar Clean 0


default 0, if true will gzip compress HTML output on the
fly if Compress::Zlib is installed, and the client browser
supports it.  Depending on the HTML being compressed, 
the client may see a 50% to 90% reduction in HTML output.
I have seen 40K of HTML squeezed down to just under 6K.
This will come at a 5%-20% hit to CPU usage per request
Note there are some cases when a browser says it will accept gzip encoding, but then not render it correctly. This behavior has been seen with IE5 when set to use a proxy but not using a proxy, and the URL does not end with a .html or .htm. No work around has yet been found for this case so use at your own risk.
  PerlSetVar CompressGzip 1


default 0, if true will auto fill HTML forms with values
from $Request->Form().  This functionality is provided
by use of HTML::FillInForm.  For more information please
see "perldoc HTML::FillInForm", and the 
example ./site/eg/formfill.asp.  
This feature can be enabled on a per form basis at runtime with $Response->{FormFill} = 1
  PerlSetVar FormFill 1


default 0, if set and Time::HiRes is installed, will do 
sub second timing of the time it takes Apache::ASP to process
a request.  This will not include the time spent in the 
session manager, nor modperl or Apache, and is only a 
rough approximation at best.
If Debug is set also, you will get a comment in your HTML output that indicates the time it took to process that script.
If system debugging is set with Debug -1 or -2, you will also get this time in the Apache error log with the other system messages.

Mail Administration

Apache::ASP has some powerful administrative email
extensions that let you sleep at night, knowing full well
that if an error occurs at the web site, you will know
about it immediately.  With these features already enabled,
it was also easy to provide the $Server->Mail(\%mail) API 
extension which you can read up about in the OBJECTS section.


The mail host is the smtp server that the below Mail* config directives
will use when sending their emails.  By default Net::SMTP uses
smtp mail hosts configured in Net::Config, which is set up at
install time, but this setting can be used to override this config.
The mail hosts specified in the Net::Config file will be used as backup smtp servers to the MailHost specified here, should this primary server not be working.
  PerlSetVar MailHost smtp.yourdomain.com.foobar


Default NONE, set this to specify the default mail address placed 
in the From: mail header for the $Server->Mail() API extension, 
as well as MailErrorsTo and MailAlertTo.
  PerlSetVar MailFrom youremail@yourdomain.com.foobar


No default, if set, ASP server errors, error code 500, that result
while compiling or running scripts under Apache::ASP will automatically
be emailed to the email address set for this config.  This allows
an administrator to have a rapid response to user generated server
errors resulting from bugs in production ASP scripts.  Other errors, such 
as 404 not found will be handled by Apache directly.
An easy way to see this config in action is to have an ASP script which calls a die(), which generates an internal ASP 500 server error.
The Debug config of value 2 and this setting are mutually exclusive, as Debug 2 is a development setting where errors are displayed in the browser, and MailErrorsTo is a production setting so that errors are silently logged and sent via email to the web admin.
  PerlSetVar MailErrorsTo youremail@yourdomain.com


The address configured will have an email sent on any ASP server error 500,
and the message will be short enough to fit on a text based pager.  This
config setting would be used to give an administrator a heads up that a www
server error occurred, as opposed to MailErrorsTo would be used for debugging
that server error.
This config does not work when Debug 2 is set, as it is a setting for use in production only, where Debug 2 is for development use.
  PerlSetVar MailAlertTo youremail@yourdomain.com


Default 20 minutes, this config specifies the time in minutes over 
which there may be only one alert email generated by MailAlertTo.
The purpose of MailAlertTo is to give the admin a heads up that there
is an error at the www server.  MailErrorsTo is for to aid in speedy 
debugging of the incident.
  PerlSetVar MailAlertPeriod 20

File Uploads


default 0, if set will limit file uploads to this
size in bytes.  This is currently implemented by 
setting $CGI::POST_MAX before handling the file
upload.  Prior to this, a developer would have to
hardcode a value for $CGI::POST_MAX to get this 
to work.
  PerlSetVar 100000


default 0, if set will leave a temp file on disk during the request, 
which may be helpful for processing by other programs, but is also
a security risk in that other users on the operating system could 
potentially read this file while the script is running. 
The path to the temp file will be available at $Request->{FileUpload}{$form_field}{TempFile}. The regular use of file uploads remains the same with the <$filehandle> to the upload at $Request->{Form}{$form_field}. Please see the CGI section for more information on file uploads, and the $Request section in OBJECTS.
  PerlSetVar FileUploadTemp 0