Apache::ASP::Config

<% Web Applications with Apache & mod_perl %>
| INTRO
| INSTALL
% | CONFIG
| SYNTAX
| EVENTS
| OBJECTS
| SSI
| SESSIONS
| XML/XSLT
| CGI
| PERLSCRIPT
| STYLE GUIDE
| FAQ
| TUNING
| CREDITS
| SUPPORT
| SITES USING
| TESTIMONIALS
| RESOURCES
| TODO
| CHANGES
| LICENSE
| EXAMPLES

CONFIG

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
     </Files>

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
| XSLTCacheSize
State Management |
NoState | Caching
AllowSessionState | CacheDB
AllowApplicationState | CacheDir
StateDir | CacheSize
StateManager |
StateDB | Miscellaneous
StateCache | AuthServerVariables
StateSerializer | BufferingOn
| InodeNames
Sessions | RequestParams
CookiePath | RequestBinaryRead
CookieDomain | StatINC
SessionTimeout | StatINCMatch
SecureSession | StatScripts
ParanoidSession | SoftRedirect
SessionSerialize | Filter
SessionCount | CgiHeaders
| Clean
Cookieless Sessions | CompressGzip
SessionQueryParse | FormFill
SessionQueryParseMatch | TimeHiRes
SessionQuery |
SessionQueryMatch | Mail Administration
SessionQueryForce | MailHost
| MailFrom
Developer Environment | MailErrorsTo
UseStrict | MailAlertTo
Debug | MailAlertPeriod
DebugBufferLength |
PodComments | File Uploads
CollectionItem | FileUploadMax
| FileUploadTemp
XML / XSLT |

Core

Global

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

GlobalPackage

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

UniquePackages

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

DynamicIncludes

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

IncludesDir

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.

NoCache

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

NoState

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

AllowSessionState

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) }"

AllowApplicationState

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

StateDir

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

StateManager

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

StateDB

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 MLDBM::Sync::SDBM_File.

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

StateCache

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 subsystem.

StateSerializer

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

Sessions

CookiePath

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 /

CookieDomain

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

SessionTimeout

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

SecureSession

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

ParanoidSession

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

SessionSerialize

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

SessionCount

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

SessionQueryParse

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

SessionQueryParseMatch

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

SessionQuery

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

SessionQueryMatch

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

SessionQueryForce

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

UseStrict

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

Debug

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

DebugBufferLength

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.htm script, and turn buffering on.

PodComments

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:

     =pod
     text or perl code here
     =cut

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

CollectionItem

Enables PerlScript syntax like:

      $Request->Form('var')->Item;
      $Request->Form('var')->Item(1);
      $Request->Form('var')->Count;

Old PerlScript syntax, enabled with

      use Win32::OLE qw(in valof with OVERLOAD);

is like native syntax

      $Request->Form('var');

Only in Apache::ASP, can the above be written as:

      $Request->{Form}{var};

which you would do if you _really_ needed the speed.

XML / XSLT

XMLSubsMatch

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\-]+

XMLSubsStrict

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

XMLSubsPerlArgs

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

XSLT

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

XSLTMatch

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$

XSLTParser

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

XSLTCache

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

XSLTCacheSize

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

Caching

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 --
      <Perl>
        use Apache::ASP;
      </Perl>

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.

CacheDB

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.

CacheDB | Output Cached | Operation | Ops/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.

CacheDir

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.

CacheSize

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.

Miscellaneous

AuthServerVariables

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

BufferingOn

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

InodeNames

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.

      PerlSetVar InodeNames 1

RequestParams

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

RequestBinaryRead

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

StatINC

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

StatINCMatch

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.

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 .*

StatScripts

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

SoftRedirect

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

Filter

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

CgiHeaders

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

      <html>...

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

Clean

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

CompressGzip

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 compressed.

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

FormFill

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

TimeHiRes

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.

MailHost

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

MailFrom

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

MailErrorsTo

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

MailAlertTo

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

MailAlertPeriod

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

FileUploadMax

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

FileUploadTemp

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

Copyright © 1998-2004, Chamas Enterprises Inc.