Apache :: ASP :: CONFIG [ Active Server Pages for Apache with mod_perl ]

INTRO
INSTALL
CONFIG
SYNTAX
EVENTS
OBJECTS
SSI
CGI
PERLSCRIPT
FAQ
TUNING
CREDITS
SUPPORT
SITES USING
EXAMPLES

CONFIG

Use with Apache. Copy the ./site/eg directory from the ASP installation to your Apache document tree and try it out! You have to put

      AllowOverride All

in your <Directory> config section to let the .htaccess file in the ./site/eg installation directory do its work.

If you want a STARTER config file, just look at the .htaccess file in the ./site/eg directory.

Here is a Location directive that you might put in a *.conf Apache configuration file. Set the optional ones if you want, the defaults are fine. The settings are documented below.

     # Generic apache directives to make asp start ticking.
     <Location /asp/>
      SetHandler perl-script
      PerlHandler Apache::ASP
      PerlSetVar Global /tmp
     </Location>

You can use the same config in .htaccess files without the Location tag. I use the <Files ~ (\.asp)> tag in the .htaccess file of the directory that I want to run my asp application. This allows me to mix other file types in my application, static or otherwise. Again, please see the ./site/eg directory in the installation for some good starter .htaccess configs, and see them in action on the example scripts.

Global |  | StateDir
CookiePath |  | StateManager
GlobalPackage |  | StateDB
UniquePackages |  | StateCache
AllowSessionState |  | AllowApplicationState
SessionTimeout |  | Filter
SecureSession |  | PodComments
ParanoidSession |  | DynamicIncludes
Debug |  | IncludesDir
BufferingOn |  | CgiHeaders
DebugBufferLength |  | Clean
StatINC |  | MailHost
StatINCMatch |  | MailErrorsTo
SessionSerialize |  | MailAlertTo
SoftRedirect |  | MailAlertPeriod
NoState |  |

Global

Global is the nerve center of an ASP application, in which the global.asa may reside, which defines the web application's event handlers.

This directory is pushed onto @INC, you will be able to "use" and "require" files in this directory, so 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

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 /

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 emulate pre-v.10 ASP script compilation behavior, which compiles each script into its own perl package.

Before v.10, ASP scripts were compiled into their own perl package namespace. This allowed ASP scripts in the same ASP application to defined subroutines of the same name without a problem.

As of v.10, ASP scripts in a web application are compiled into the *same* perl package by default, 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

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

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

Debug

1 for server log debugging, 2 for extra client html output Use 1 for production debugging, use 2 for development. Turn off if you are not debugging.

      PerlSetVar Debug 2

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

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.

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

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

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

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

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 OS's 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.

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 only be: SDBM_File, DB_File Please let me know if you would like to add any more to this list.

If you switch to a new StateDB, you will 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

Default 0, set to 1 for lock files that are acquired for $Application and an internal database used for session management to be cached and held open between requests, for up to a 10% performance gain. Per ASP application this is will keep up to 2 extra file handles open per httpd process, one for the internal database, and one for $Application.

The only problem with this caching is that you can only delete the StateDir if you have first shutdown the web server, as the lock files will not be recreated between requests. Not that you should be deleting your StateDir anyway, but if you are, there is more to worry about.

      PerlSetVar StateCache 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

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

With filtering through Apache::SSI, you should expect at least a 20% performance decrease, increasing as your files get bigger, increasing the work that SSI must do.

      PerlSetVar Filter Off

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

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 .

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

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

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

Copyright (c) 1998-1999, Joshua Chamas, Chamas Enterprises Inc.