|
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
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
HTTPOnlySession
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
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.asp 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
|
|
