NAME
      Apache::ASP - Active Server Pages for Apache with mod_perl 

SYNOPSIS
      SetHandler  perl-script
      PerlModule  Apache::ASP
      PerlHandler Apache::ASP
      PerlSetVar  Global /tmp/asp

DESCRIPTION
    Apache::ASP provides an Active Server Pages port to the Apache Web
    Server with Perl scripting only, and enables developing of dynamic web
    applications with session management and embedded perl code. There are
    also many powerful extensions, including XML taglibs, XSLT rendering,
    and new events not originally part of the ASP API!

    This module works under the Apache Web Server with the mod_perl module
    enabled. See http://www.apache.org and http://perl.apache.org for
    further information.

    This is a portable solution, similar to ActiveState's PerlScript for
    NT/IIS ASP. Work has been done and will continue to make ports to and
    from this implementation as smooth as possible.

    For Apache::ASP downloading and installation, please read the INSTALL
    section. For installation troubleshooting check the FAQ and the SUPPORT
    sections.

    For database access, ActiveX, scripting languages, and other
    miscellaneous issues please read the FAQ section.

WEBSITE
    The Apache::ASP web site is at http://www.apache-asp.org/ which you can
    also find in the ./site directory of the source distribution.

INSTALL
    The latest Apache::ASP can be found at your nearest CPAN, and also:

      http://www.perl.com/CPAN-local/modules/by-module/Apache/
      ftp://ftp.duke.edu/pub/perl/modules/by-module/Apache/

    As a perl user, you should make yourself familiar with the CPAN.pm
    module, and how it may be used to install Apache::ASP, and other related
    modules.

  Perl Module Install

    Once you have downloaded it, Apache::ASP installs easily using the make
    or nmake commands as shown below. Otherwise, just copy ASP.pm to
    $PERLLIB/site/Apache

      > perl Makefile.PL
      > make 
      > make test
      > make install

      * use nmake for win32

    Please note that you must first have the Apache Web Server & mod_perl
    installed before using this module in a web server environment. The
    offline mode for building static html at ./cgi/asp may be used with just
    perl.

  Need Help

    Often, installing the mod_perl part of the Apache server can be the
    hardest part. If this is the case for you, check out the FAQ and SUPPORT
    sections for further help, as well as the "Build Apache" notes in this
    section.

    Please also see the mod_perl guide at http://perl.apache.org/guide which
    one ought to give a good read before undertaking a mod_perl project.

  Linux Distributions

    If you have a linux distribution, like a RedHat Linux server, with an
    RPM style Apache + mod_perl, seriously consider building a static
    version of the httpd server yourself, not DSO. DSO is marked as
    experimental for mod_perl, and often does not work, resulting in "no
    request object" error messages, and other oddities, and are terrible to
    debug, because of the strange kinds of things that can go wrong.

  Build Apache

    For a quick build of apache, there is a script in the distribution at
    ./make_httpd/build_httpds.sh that can compile a statically linked Apache
    with mod_ssl and mod_perl. Just drop the sources into the make_httpd
    directory, configure the environments as appropriate, and execute the
    script like this:

     make_httpd> ./build_httpds.sh

    You might also find helpful a couple items:

      Stas's mod_perl guide install section
      http://perl.apache.org/guide/install.html

      Apache Toolbox
      http://www.apachetoolbox.com/

    People have been using Apache Toolbox to automate their complex builds
    with great success.

  Quick Start

    Once you have successfully built the Apache Web Server with mod_perl,
    copy the ./site/eg/ directory from the Apache::ASP installation to your
    Apache document tree and try it out! You must put "AllowOverride All" in
    your httpd.conf <Directory> config section to let the .htaccess file in
    the ./site/eg installation directory do its work. If you want a starter
    config file for Apache::ASP, just look at the .htaccess file in the
    ./site/eg/ directory.

    So, you might add this to your Apache httpd.conf file just to get the
    scripts in ./site/eg working:

      <Directory />
        Options FollowSymLinks
        AllowOverride All
      </Directory>

    This is not a good production config, because it is insecure with the
    FollowSymLinks, and tells Apache to look for .htaccess files all the way
    up to / which is bad for performance, but it should be handy for getting
    started with development.

    You will know that Apache::ASP is working normally if you can run the
    scripts in ./site/eg/ without any errors. Common problems can be found
    in the FAQ section.

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!

     <Files ~ (\.asp)>    
       SetHandler  perl-script
       PerlModule  Apache::ASP
       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 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

    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.

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

    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 /   

    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. As of
    v.19, 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

  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.

    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.

      PerlSetVar XSLTParser XML::Sablotron

    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 file 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   Cache Fetch/sec
     -------                 -------------   ---------------
     MLDBM::Sync::SDBM_File  32000 bytes     41.7
     DB_File                 32000 bytes     53
     MLDBM::Sync::SDBM_File   3200 bytes     177
     DB_File                  3200 bytes     59

     CacheDB                 Output Cached   Cache Store/sec
     -------                 -------------   ---------------
     MLDBM::Sync::SDBM_File   3200 bytes     42
     DB_File                  3200 bytes     39

    CacheDir
    By default, the cache directory is at StateDir/cache, but if StateDir is
    not set, then CacheDir can be used to set the StateDir value for caching
    purposes. This is to make things less confusing when NoState 1 is set.

      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 cache 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

    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

SYNTAX
  General

    ASP embedding syntax allows one to embed code in html in 2 simple ways.
    The first is the <% xxx %> tag in which xxx is any valid perl code. The
    second is <%= xxx %> where xxx is some scalar value that will be
    inserted into the html directly. An easy print.

      A simple asp page would look like:
      
      <!-- sample here -->
      <html>
      <body>
      For loop incrementing font size: <p>
      <% for(1..5) { %>
            <!-- iterated html text -->
            <font size="<%=$_%>" > Size = <%=$_%> </font> <br>
      <% } %>
      </body>
      </html>
      <!-- end sample here -->

    Notice that your perl code blocks can span any html. The for loop above
    iterates over the html without any special syntax.

  XMLSubs

    XMLSubs allows a developer to define custom handlers for HTML & XML
    tags, which can extend the natural syntax of the ASP environment.
    Configured like:

      PerlSetVar XMLSubsMatch site:\w+

    A simple tag like:

      <site:header title="Page Title" />

    can be constructed that could translate into:

      sub site::header {
          my $args = shift;
          print "<html><head><title>$args->{title}</title></head>\n";
          print "<body bgcolor=white>\n";
      }

    Better yet, one can use this functionality to trap and post process
    embedded HTML & XML like:

      <site:page title="Page Title">
        ... some HTML here ...
      </site:page>

    and then:

      sub site::page {
        my($args, $html) = @_;
        &site::header($args);
        $main::Response->Write($html);
        $main::Response->Write("</body></html>");
      }

    Though this could be used to fully render XML documents, it was not
    built for this purpose, but to add powerful tag extensions to HTML
    development environments. For full XML rendering, you ought to try an
    XSLT approach, also supported by Apache::ASP.

  Editors

    As Apache::ASP supports a mixing of perl and HTML, any editor which
    supports development of one or the other would work well. The following
    editors are known to work well for developing Apache::ASP web sites:

     * Emacs, in perl or HTML modes.  For a mmm-mode config
       that mixes HTML & perl modes in a single buffer, check 
       out the editors/mmm-asp-perl.el file in distribution.

     * Microsoft Frontpage

     * Vim, special syntax support with editors/aasp.vim file in distribution.

     * UltraEdit32 ( http://www.ultraedit.com/ ) has syntax highlighting, 
       good macros and a configurable wordlist (so one can have syntax 
       highlighting both for Perl and HTML).

    Please feel free to suggest your favorite development environment for
    this list.

EVENTS
  Overview

    The ASP platform allows developers to create Web Applications. In
    fulfillment of real software requirements, ASP allows event-triggered
    actions to be taken, which are defined in a global.asa file. The
    global.asa file resides in the Global directory, defined as a config
    option, and may define the following actions:

            Action                  Event
            ------                  ------
            Script_OnStart *        Beginning of Script execution
            Script_OnEnd *          End of Script execution
            Script_OnFlush *        Before $Response being flushed to client.
            Application_OnStart     Beginning of Application
            Application_OnEnd       End of Application
            Session_OnStart         Beginning of user Session.
            Session_OnEnd           End of user Session.

      * These are API extensions that are not portable, but were
        added because they are incredibly useful

    These actions must be defined in the $Global/global.asa file as
    subroutines, for example:

      sub Session_OnStart {
          $Application->{$Session->SessionID()} = started;
      }

    Sessions are easy to understand. When visiting a page in a web
    application, each user has one unique $Session. This session expires,
    after which the user will have a new $Session upon revisiting.

    A web application starts when the user visits a page in that
    application, and has a new $Session created. Right before the first
    $Session is created, the $Application is created. When the last user
    $Session expires, that $Application expires also. For some web
    applications that are always busy, the Application_OnEnd event may never
    occur.

  Script_OnStart & Script_OnEnd

    The script events are used to run any code for all scripts in an
    application defined by a global.asa. Often, you would like to run the
    same code for every script, which you would otherwise have to add by
    hand, or add with a file include, but with these events, just add your
    code to the global.asa, and it will be run.

    There is one caveat. Code in Script_OnEnd is not guaranteed to be run
    when $Response->End() is called, since the program execution ends
    immediately at this event. To always run critical code, use the API
    extension:

            $Server->RegisterCleanup()

  Session_OnStart

    Triggered by the beginning of a user's session, Session_OnStart gets run
    before the user's executing script, and if the same session recently
    timed out, after the session's triggered Session_OnEnd.

    The Session_OnStart is particularly useful for caching database data,
    and avoids having the caching handled by clumsy code inserted into each
    script being executed.

  Session_OnEnd

    Triggered by a user session ending, Session_OnEnd can be useful for
    cleaning up and analyzing user data accumulated during a session.

    Sessions end when the session timeout expires, and the StateManager
    performs session cleanup. The timing of the Session_OnEnd does not occur
    immediately after the session times out, but when the first script runs
    after the session expires, and the StateManager allows for that session
    to be cleaned up.

    So on a busy site with default SessionTimeout (20 minutes) and
    StateManager (10 times) settings, the Session_OnEnd for a particular
    session should be run near 22 minutes past the last activity that
    Session saw. A site infrequently visited will only have the
    Session_OnEnd run when a subsequent visit occurs, and theoretically the
    last session of an application ever run will never have its
    Session_OnEnd run.

    Thus I would not put anything mission-critical in the Session_OnEnd,
    just stuff that would be nice to run whenever it gets run.

  Script_OnFlush

    API extension. This event will be called prior to flushing the $Response
    buffer to the web client. At this time, the $Response->{BinaryRef}
    buffer reference may be used to modify the buffered output at runtime to
    apply global changes to scripts output without having to modify all the
    scripts.

     sub Script_OnFlush {
       my $ref = $Response->{BinaryRef};
       $$ref =~ s/\s+/ /sg; # to strip extra white space
     }

    Check out the ./site/eg/global.asa for an example of its use.

  Application_OnStart

    This event marks the beginning of an ASP application, and is run just
    before the Session_OnStart of the first Session of an application. This
    event is useful to load up $Application with data that will be used in
    all user sessions.

  Application_OnEnd

    The end of the application is marked by this event, which is run after
    the last user session has timed out for a given ASP application.

  Server_OnStart ( pseudo-event )

    Some might want something like a Server_OnStart event, where some code
    gets runs when the web server starts. In mod_perl, this is easy to
    achieve outside of the scope of an ASP application, by putting some
    initialization code into a <Perl> section in the httpd.conf file.
    Initializations that you would like to be shared with the child httpds
    are particularly useful, one such being the Apache::ASP->Loader()
    routine which you can read more about in the TUNING section - Precompile
    Scripts subsection. It is could be called like:

      # httpd.conf
      <Perl>
         Apache::ASP->Loader($path, $pattern, %config)
      </Perl>

    So a <Perl> section is your Server_OnStart routine!

  mod_perl handlers

    If one wants to extend one's environment with mod_perl handlers,
    Apache::ASP does not stop this. Basic use of Apache::ASP in fact only
    involves the content handler phase of mod_perl's PerlHandler, like

      SetHandler perl-script
      PerlModule Apache::ASP
      PerlHandler Apache::ASP 

    But mod_perl allows for direct access to many more Apache event stages,
    for full list try "perldoc mod_perl" or buy the mod_perl Eagle book.
    Some commonly used ones are:

      PerlInitHandler
      PerlTransHandler
      PerlFixupHandler
      PerlHandler
      PerlLogHandler
      PerlCleanupHandler

    For straight Apache::ASP programming, there are some equivalents, say
    Script_OnStart event instead of Init/Fixup stages, or $Server-
    >RegisterCleanup() for Log/Cleanup stages, but you can do things in the
    mod_perl handlers that you cannot do in Apache::ASP, especially if you
    want to handle all files globally, and not just ASP scripts.

    For many Apache::* modules for use with mod_perl, of which Apache::ASP
    is just one, check out http://perl.apache.org/src/apache-modlist.html

    To gain access to the ASP objects like $Session outside in a non-
    PerlHandler mod_perl handler, you may use this API: my $ASP =
    Apache::ASP->new($r); # $r is Apache->request object

    as in this possible Authen handler:

      <Perl>
        use Apache::ASP;
        sub My::Auth::handler {
          my $r = shift;
          my $ASP = Apache::ASP->new($r) 
          my $Session = $ASP->Session;
        }
      </Perl>

    Here are some examples of do-it-yourself mod_perl handler programming...

     === Forbid Bad HSlide User Agent ===

     # httpd.conf
     PerlAccessHandler My::Access
     <Perl>
       sub My::Access::handler {
         my $r = shift;
         if($r->header_in('USER_AGENT') =~ /HSlide/) {
             403;
         } else {
             200;
         }
       }
     </Perl>

     === Runtime Path Parsing ===

    This example shows how one might take an arbitrary URL path
    /$path/$file.asp, and turn that into a runtime config for your site, so
    your scripts get executed always in your sites DocumentRoot.

     INPUT URL /SomeCategory/
     OUTPUT
      Script: index.asp
      $Server->Config('PATH') eq '/SomeCategory'

     INPUT URL /SomeCategory/index.asp
     OUTPUT
      Script: index.asp
      $Server->Config('PATH') eq '/SomeCategory'

     INPUT URI /index.asp
     OUTPUT
      Script: index.asp
      $Server->Config('PATH') eq ''

     # httpd.conf
     PerlTransHandler My::Init
     use lib qw( $custom_perllib );

     # $custom_perllib/My/Init.pm
     package My::Init;
     use strict;
     use Apache::Constants qw(:common);
     sub handler {
        my $r = shift;

        my $uri = $r->uri || '/';
        unless($uri =~ m|^(.*)(/([^/.]+\.[\w]+)?)$|i) {
            warn("can't parse uri $uri");
            return DECLINED;
        }
        $uri = $2;
        my $PATH = $1 || '';
        $r->dir_config('PATH', $PATH);

        if($uri eq '/') {
            $uri = '/index.asp';
        }

        $r->uri($uri);
        $r->filename($r->document_root.$uri);

        DECLINED;
     }

     1;

OBJECTS
    The beauty of the ASP Object Model is that it takes the burden of CGI
    and Session Management off the developer, and puts them in objects
    accessible from any ASP script & include. For the perl programmer, treat
    these objects as globals accessible from anywhere in your ASP
    application.

     The Apache::ASP object model supports the following:

     Object         Function
     ------         --------
     $Session      - user session state
     $Response     - output to browser
     $Request      - input from browser
     $Application  - application state
     $Server       - general methods

    These objects, and their methods are further defined in the following
    sections.

    If you would like to define your own global objects for use in your
    scripts and includes, you can initialize them in the global.asa
    Script_OnStart like:

     use vars qw( $Form $Site ); # declare globals
     sub Script_OnStart {
         $Site = My::Site->new;  # init $Site object
         $Form = $Request->Form; # alias form data
         $Server->RegisterCleanup(sub { # garbage collection
                                      $Site->DESTROY; 
                                      $Site = $Form = undef; 
                                  });
     }

    In this way you can create site wide application objects and simple
    aliases for common functions.

  $Session Object

    The $Session object keeps track of user and web client state, in a
    persistent manner, making it relatively easy to develop web
    applications. The $Session state is stored across HTTP connections, in
    database files in the Global or StateDir directories, and will persist
    across web server restarts.

    The user session is referenced by a 128 bit / 32 byte MD5 hex hashed
    cookie, and can be considered secure from session id guessing, or
    session hijacking. When a hacker fails to guess a session, the system
    times out for a second, and with 2**128 (3.4e38) keys to guess, a hacker
    will not be guessing an id any time soon.

    If an incoming cookie matches a timed out or non-existent session, a new
    session is created with the incoming id. If the id matches a currently
    active session, the session is tied to it and returned. This is also
    similar to the Microsoft ASP implementation.

    The $Session reference is a hash ref, and can be used as such to store
    data as in:

        $Session->{count}++;        # increment count by one
        %{$Session} = ();   # clear $Session data

    The $Session object state is implemented through MLDBM, and a user
    should be aware of the limitations of MLDBM. Basically, you can read
    complex structures, but not write them, directly:

      $data = $Session->{complex}{data};     # Read ok.
      $Session->{complex}{data} = $data;     # Write NOT ok.
      $Session->{complex} = {data => $data}; # Write ok, all at once.

    Please see MLDBM for more information on this topic. $Session can also
    be used for the following methods and properties:

    $Session->{CodePage}
        Not implemented. May never be until someone needs it.

    $Session->{LCID}
        Not implemented. May never be until someone needs it.

    $Session->{SessionID}
        SessionID property, returns the id for the current session, which is
        exchanged between the client and the server as a cookie.

    $Session->{Timeout} [= $minutes]
        Timeout property, if minutes is being assigned, sets this default
        timeout for the user session, else returns the current session
        timeout.

        If a user session is inactive for the full timeout, the session is
        destroyed by the system. No one can access the session after it
        times out, and the system garbage collects it eventually.

    $Session->Abandon()
        The abandon method times out the session immediately. All Session
        data is cleared in the process, just as when any session times out.

    $Session->Lock()
        API extension. If you are about to use $Session for many consecutive
        reads or writes, you can improve performance by explicitly locking
        $Session, and then unlocking, like:

          $Session->Lock();
          $Session->{count}++;
          $Session->{count}++;
          $Session->{count}++;
          $Session->UnLock();  

        This sequence causes $Session to be locked and unlocked only 1 time,
        instead of the 6 times that it would be locked otherwise, 2 for each
        increment with one to read and one to write.

        Because of flushing issues with SDBM_File and DB_File databases,
        each lock actually ties fresh to the database, so the performance
        savings here can be considerable.

        Note that if you have SessionSerialize set, $Session is already
        locked for each script invocation automatically, as if you had
        called $Session->Lock() in Script_OnStart. Thus you do not need to
        worry about $Session locking for performance. Please read the
        section on SessionSerialize for more info.

    $Session->UnLock()
        API Extension. Unlocks the $Session explicitly. If you do not call
        this, $Session will be unlocked automatically at the end of the
        script.

  $Response Object

    This object manages the output from the ASP Application and the client
    web browser. It does not store state information like the $Session
    object but does have a wide array of methods to call.

    $Response->{BinaryRef}
        API extension. This is a perl reference to the buffered output of
        the $Response object, and can be used in the Script_OnFlush
        global.asa event to modify the buffered output at runtime to apply
        global changes to scripts output without having to modify all the
        scripts. These changes take place before content is flushed to the
        client web browser.

         sub Script_OnFlush {
           my $ref = $Response->{BinaryRef};
           $$ref =~ s/\s+/ /sg; # to strip extra white space
         }

        Check out the ./site/eg/global.asa for an example of its use.

    $Response->{Buffer}
        Default 1, when TRUE sends output from script to client only at the
        end of processing the script. When 0, response is not buffered, and
        client is sent output as output is generated by the script.

    $Response->{CacheControl}
        Default "private", when set to public allows proxy servers to cache
        the content. This setting controls the value set in the HTTP header
        Cache-Control

    $Response->{Charset}
        This member when set appends itself to the value of the Content-Type
        HTTP header. If $Response->{Charset} = 'ISO-LATIN-1' is set, the
        corresponding header would look like:

          Content-Type: text/html; charset=ISO-LATIN-1

    $Response->{Clean} = 0-9;
        API extension. Set the Clean level, default 0, on a per script
        basis. Clean of 1-9 compresses text/html output. Please see the
        Clean config option for more information. This setting may also be
        useful even if using compression to obfuscate HTML.

    $Response->{ContentType} = "text/html"
        Sets the MIME type for the current response being sent to the
        client. Sent as an HTTP header.

    $Response->{Debug} = 1|0
        API extension. Default set to value of Debug config. May be used to
        temporarily activate or inactivate $Response->Debug() behavior.
        Something like:

         {
           local $Response->{Debug} = 1;
           $Response->Debug($values);
         }

        maybe be used to always log something. The Debug() method can be
        better than AppendToLog() because it will log data in data
        structures one level deep, whereas AppendToLog prints just raw
        string/scalar values.

    $Response->{Expires} = $time
        Sends a response header to the client indicating the $time in
        SECONDS in which the document should expire. A time of 0 means
        immediate expiration. The header generated is a standard HTTP date
        like: "Wed, 09 Feb 1994 22:23:32 GMT".

    $Response->{ExpiresAbsolute} = $date
        Sends a response header to the client with $date being an absolute
        time to expire. Formats accepted are all those accepted by
        HTTP::Date::str2time(), e.g.

         "Wed, 09 Feb 1994 22:23:32 GMT"     -- HTTP format
         "Tuesday, 08-Feb-94 14:15:29 GMT"   -- old rfc850 HTTP format

         "08-Feb-94"       -- old rfc850 HTTP format    
         "09 Feb 1994"     -- proposed new HTTP format  

         "Feb  3  1994"    -- Unix 'ls -l' format
         "Feb  3 17:03"    -- Unix 'ls -l' format

    $Response->{FormFill} = 0|1
        If true, HTML forms generated by the script output will be auto
        filled with data from $Request->Form. This feature requires
        HTML::FillInForm to be installed. Please see the FormFill CONFIG for
        more information.

        This setting overrides the FormFill config at runtime for the script
        execution only.

    $Response->{IsClientConnected}
        1 if web client is connected, 0 if not. This value starts set to 1,
        and will be updated whenever a $Response->Flush() is called. If
        BufferingOn is set, by default $Response->Flush() will only be
        called at the end of the HTML output.

        As of version 2.23 this value is updated correctly before global.asa
        Script_OnStart is called, so global script termination may be
        correctly handled during that event, which one might want to do with
        excessive user STOP/RELOADS when the web server is very busy.

        An API extension $Response->IsClientConnected may be called for
        refreshed connection status without calling first a $Response->Flush

    $Response->{PICS}
        If this property has been set, a PICS-Label HTTP header will be sent
        with its value. For those that do not know, PICS is a header that is
        useful in rating the internet. It stands for Platform for Internet
        Content Selection, and you can find more info about it at:
        http://www.w3.org

    $Response->{Status} = $status
        Sets the status code returned by the server. Can be used to set
        messages like 500, internal server error

    $Response->AddHeader($name, $value)
        Adds a custom header to a web page. Headers are sent only before any
        text from the main page is sent, so if you want to set a header
        after some text on a page, you must turn BufferingOn.

    $Response->AppendToLog($message)
        Adds $message to the server log. Useful for debugging.

    $Response->BinaryWrite($data)
        Writes binary data to the client. The only difference from
        $Response->Write() is that $Response->Flush() is called internally
        first, so the data cannot be parsed as an html header. Flushing
        flushes the header if has not already been written.

        If you have set the $Response->{ContentType} to something other than
        text/html, cgi header parsing (see CGI notes), will be automatically
        be turned off, so you will not necessarily need to use BinaryWrite
        for writing binary data.

        For an example of BinaryWrite, see the binary_write.htm example in
        ./site/eg/binary_write.htm

        Please note that if you are on Win32, you will need to call binmode
        on a file handle before reading, if its data is binary.

    $Response->Clear()
        Erases buffered ASP output.

    $Response->Cookies($name, [$key,] $value)
        Sets the key or attribute of cookie with name $name to the value
        $value. If $key is not defined, the Value of the cookie is set. ASP
        CookiePath is assumed to be / in these examples.

         $Response->Cookies('name', 'value'); 
          --> Set-Cookie: name=value; path=/

         $Response->Cookies("Test", "data1", "test value");     
         $Response->Cookies("Test", "data2", "more test");      
         $Response->Cookies(
                "Test", "Expires", 
                &HTTP::Date::time2str(time+86400)
                ); 
         $Response->Cookies("Test", "Secure", 1);               
         $Response->Cookies("Test", "Path", "/");
         $Response->Cookies("Test", "Domain", "host.com");
          -->   Set-Cookie:Test=data1=test%20value&data2=more%20test;   \
                        expires=Fri, 23 Apr 1999 07:19:52 GMT;          \
                        path=/; domain=host.com; secure

        The latter use of $key in the cookies not only sets cookie
        attributes such as Expires, but also treats the cookie as a hash of
        key value pairs which can later be accesses by

         $Request->Cookies('Test', 'data1');
         $Request->Cookies('Test', 'data2');

        Because this is perl, you can (NOT PORTABLE) reference the cookies
        directly through hash notation. The same 5 commands above could be
        compressed to:

         $Response->{Cookies}{Test} = 
                { 
                        Secure  => 1, 
                        Value   =>      
                                {
                                        data1 => 'test value', 
                                        data2 => 'more test'
                                },
                        Expires => 86400, # not portable, see above
                        Domain  => 'host.com',
                        Path    => '/'
                };

        and the first command would be:

         # you don't need to use hash notation when you are only setting 
         # a simple value
         $Response->{Cookies}{'Test Name'} = 'Test Value'; 

        I prefer the hash notation for cookies, as this looks nice, and is
        quite perlish. It is here to stay. The Cookie() routine is very
        complex and does its best to allow access to the underlying hash
        structure of the data. This is the best emulation I could write
        trying to match the Collections functionality of cookies in IIS ASP.

        For more information on Cookies, please go to the source at
        http://home.netscape.com/newsref/std/cookie_spec.html

    $Response->Debug(@args)
        API Extension. If the Debug config option is set greater than 0,
        this routine will write @args out to server error log. refs in @args
        will be expanded one level deep, so data in simple data structures
        like one-level hash refs and array refs will be displayed. CODE refs
        like

         $Response->Debug(sub { "some value" });

        will be executed and their output added to the debug output. This
        extension allows the user to tie directly into the debugging
        capabilities of this module.

        While developing an app on a production server, it is often useful
        to have a separate error log for the application to catch debugging
        output separately. One way of implementing this is to use the Apache
        ErrorLog configuration directive to create a separate error log for
        a virtual host.

        If you want further debugging support, like stack traces in your
        code, consider doing things like:

         $Response->Debug( sub { Carp::longmess('debug trace') };
         $SIG{__WARN__} = \&Carp::cluck; # then warn() will stack trace

        The only way at present to see exactly where in your script an error
        occurred is to set the Debug config directive to 2, and match the
        error line number to perl script generated from your ASP script.

        However, as of version 0.10, the perl script generated from the asp
        script should match almost exactly line by line, except in cases of
        inlined includes, which add to the text of the original script, pod
        comments which are entirely yanked out, and <% # comment %> style
        comments which have a \n added to them so they still work.

        If you would like to see the HTML preceding an error while
        developing, consider setting the BufferingOn config directive to 0.

    $Response->End()
        Sends result to client, and immediately exits script. Automatically
        called at end of script, if not already called.

    $Response->ErrorDocument($code, $uri)
        API extension that allows for the modification the Apache
        ErrorDocument at runtime. $uri may be a on site document, off site
        URL, or string containing the error message.

        This extension is useful if you want to have scripts set error codes
        with $Response->{Status} like 401 for authentication failure, and to
        then control from the script what the error message looks like.

        For more information on the Apache ErrorDocument mechanism, please
        see ErrorDocument in the CORE Apache settings, and the Apache-
        >custom_response() API, for which this method is a wrapper.

    $Response->Flush()
        Sends buffered output to client and clears buffer.

    $Response->Include($filename, @args)
        This API extension calls the routine compiled from asp script in
        $filename with the args @args. This is a direct translation of the
        SSI tag

          <!--#include file=$filename args=@args-->

        Please see the SSI section for more on SSI in general.

        This API extension was created to allow greater modularization of
        code by allowing includes to be called with runtime arguments. Files
        included are compiled once, and the anonymous code ref from that
        compilation is cached, thus including a file in this manner is just
        like calling a perl subroutine. The @args can be found in @_ in the
        includes like:

          # include.inc
          <% my @args = @_; %>

        As of 2.23, multiple return values can be returned from an include
        like:

         my @rv = $Response->Include($filename, @args);

    $Response->Include(\%cache_args, @sub_args) *CACHE API*
        As of version 2.23, output from an include may be cached with this
        API and the CONFIG settings CacheDir & CacheDB. This can be used to
        execute expensive includes only rarely where applicable, drastically
        increasing performance in some cases.

        This API extension applies to the entire include family:

          my @rv = $Response->Include(\%cache_args, @include_args)
          my $html_ref = $Response->TrapInclude(\%cache_args, @include_args)
          $Server->Execute(\%cache_args, @include_args)

        For this output cache to work, you must load Apache::ASP in the
        Apache parent httpd like so:

          # httpd.conf
          PerlModule Apache::ASP

        The cache arguments are shown here

          $Response->Include({
            File => 'file.inc',
            Cache => 1, # to activate cache layer
            Expires => 3600, # to expire in one hour
            LastModified => time() - 600, # to expire if cached before 10 minutes ago
            Key => $Request->Form, # to cache based on checksum of serialized form data,
            Clear => 1, # always executes include & cache output
          }, @include_args);

          File - include file to execute, can be file name or \$script 
            script data passed in as scalar ref.

          Cache - activate caching, will run like normal include without this

          Expires - only cache for this long in seconds

          LastModified - if cached before this time(), expire

          Key - The cache item identity.  Can be $data, \$data, \%data, \@data, 
            this data is serialized and combined with the filename & @include_args 
            to create a MD5 checksum to fetch from the cache with. If you wanted
            to cache the results of a search page from form data POSTed, 
            then this key could be 

              { Key => $Request->Form }

          Clear - If set to 1, or boolean true, will always execute the include 
            and update the cache entry for it.

        Motivation: If an include takes 1 second to execute because of
        complex SQL to a database, and you can cache the output of this
        include because it is not realtime data, and the cache layer runs at
        .01 seconds, then you have a 100 fold savings on that part of the
        script. Site scalability can be dramatically increased in this way
        by intelligently caching bottlenecks in the web application.

        Use Sparingly: If you have a fast include, then it may execute
        faster than the cache layer runs, in which case you may actually
        slow your site down by using this feature. Therefore try to use this
        sparingly, and only when sure you really need it. Apache::ASP
        scripts generally execute very quickly, so most developers will not
        need to use this feature at all.

    $Response->IsClientConnected()
        API Extension. 1 for web client still connected, 0 if disconneted
        which might happen if the user hits the stop button. The original
        API for this $Response->{IsClientConnected} is only updated after a
        $Response->Flush is called, so this method may be called for a
        refreshed status.

        Note $Response->Flush calls $Response->IsClientConnected to update
        $Response->{IsClientConnected} so to use this you are going straight
        to the source! But if you are doing a loop like:

          while(@data) {
            $Response->End if ! $Response->{IsClientConnected};
            my $row = shift @data;
            %> <%= $row %> <%
            $Response->Flush;
          }

        Then its more efficient to use the member instead of the method
        since $Response->Flush() has already updated that value for you.

    $Response->Redirect($url)
        Sends the client a command to go to a different url $url. Script
        immediately ends.

    $Response->TrapInclude($file, @args)
        Calls $Response->Include() with same arguments as passed to it, but
        instead traps the include output buffer and returns it as as a perl
        scalar ref. This allows one to postprocess the output buffer before
        sending to the client.

          my $string_ref = $Response->TrapInclude('file.inc');
          $$string_ref =~ s/\s+/ /sg; # squash whitespace like Clean 1
          print $$string_ref;

        The scalar is returned as a referenece to save on what might be a
        large string copy. You may dereference the scalar with the
        $$string_ref notation.

    $Response->Write($data)
        Write output to the HTML page. <%=$data%> syntax is shorthand for a
        $Response->Write($data). All final output to the client must at some
        point go through this method.

  $Request Object

    The request object manages the input from the client browser, like
    posts, query strings, cookies, etc. Normal return results are values if
    an index is specified, or a collection / perl hash ref if no index is
    specified. WARNING, the latter property is not supported in ActiveState
    PerlScript, so if you use the hashes returned by such a technique, it
    will not be portable.

    A normal use of this feature would be to iterate through the form
    variables in the form hash...

     $form = $Request->Form();
     for(keys %{$form}) {
            $Response->Write("$_: $form->{$_}<br>\n");
     }

    Please see the ./site/eg/server_variables.htm asp file for this method
    in action.

    Note that if a form POST or query string contains duplicate values for a
    key, those values will be returned through normal use of the $Request
    object:

      @values = $Request->Form('key');

    but you can also access the internal storage, which is an array
    reference like so:

      $array_ref = $Request->{Form}{'key'};
      @values = @{$array_ref};

    Please read the PERLSCRIPT section for more information on how things
    like $Request->QueryString() & $Request->Form() behave as collections.

    $Request->{TotalBytes}
        The amount of data sent by the client in the body of the request,
        usually the length of the form data. This is the same value as
        $Request->ServerVariables('CONTENT_LENGTH')

    $Request->BinaryRead($length)
        Returns a scalar whose contents are the first $length bytes of the
        form data, or body, sent by the client request. This data is the raw
        data sent by the client, without any parsing done on it by
        Apache::ASP.

    $Request->ClientCertificate()
        Not implemented.

    $Request->Cookies($name [,$key])
        Returns the value of the Cookie with name $name. If a $key is
        specified, then a lookup will be done on the cookie as if it were a
        query string. So, a cookie set by:

         Set-Cookie: test=data1=1&data2=2

        would have a value of 2 returned by $Request-
        >Cookies('test','data2').

        If no name is specified, a hash will be returned of cookie names as
        keys and cookie values as values. If the cookie value is a query
        string, it will automatically be parsed, and the value will be a
        hash reference to these values.

        When in doubt, try it out. Remember that unless you set the Expires
        attribute of a cookie with $Response->Cookies('cookie', 'Expires',
        $xyz), the cookies that you set will only last until you close your
        browser, so you may find your self opening & closing your browser a
        lot when debugging cookies.

        For more information on cookies in ASP, please read $Response-
        >Cookies()

    $Request->FileUpload($form_field, $key)
        API extension. The FileUpload interface to file upload data is
        stabilized. The internal representation of the file uploads is a
        hash of hashes, one hash per file upload found in the $Request-
        >Form() collection. This collection of collections may be queried
        through the normal interface like so:

          $Request->FileUpload('upload_file', 'ContentType');
          $Request->FileUpload('upload_file', 'FileHandle');
          $Request->FileUpload('upload_file', 'BrowserFile');
          $Request->FileUpload('upload_file', 'Mime-Header');
          $Request->FileUpload('upload_file', 'TempFile');

          * note that TempFile must be use with the UploadTempFile 
            configuration setting.

        The above represents the old slow collection interface, but like all
        collections in Apache::ASP, you can reference the internal hash
        representation more easily.

          my $fileup = $Request->{FileUpload}{upload_file};
          $fileup->{ContentType};
          $fileup->{BrowserFile};
          $fileup->{FileHandle};
          $fileup->{Mime-Header};
          $fileup->{TempFile};

    $Request->Form($name)
        Returns the value of the input of name $name used in a form with
        POST method. If $name is not specified, returns a ref to a hash of
        all the form data. One can use this hash to create a nice alias to
        the form data like:

         # in global.asa
         use vars qw( $Form );
         sub Script_OnStart {
           $Form = $Request->Form;
         }
         # then in ASP scripts
         <%= $Form->{var} %>

        File upload data will be loaded into $Request->Form('file_field'),
        where the value is the actual file name of the file uploaded, and
        the contents of the file can be found by reading from the file name
        as a file handle as in:

         while(read($Request->Form('file_field_name'), $data, 1024)) {};

        For more information, please see the CGI / File Upload section, as
        file uploads are implemented via the CGI.pm module. An example can
        be found in the installation samples ./site/eg/file_upload.asp

    $Request->Params($name)
        API extension. If RequestParams CONFIG is set, the $Request->Params
        object is created with combined contents of $Request->QueryString
        and $Request->Form. This is for developer convenience simlar to
        CGI.pm's param() method. Just like for $Response->Form, one could
        create a nice alias like:

         # in global.asa
         use vars qw( $Params );
         sub Script_OnStart {
           $Params = $Request->Params;
         }

    $Request->QueryString($name)
        Returns the value of the input of name $name used in a form with GET
        method, or passed by appending a query string to the end of a url as
        in http://localhost/?data=value. If $name is not specified, returns
        a ref to a hash of all the query string data.

    $Request->ServerVariables($name)
        Returns the value of the server variable / environment variable with
        name $name. If $name is not specified, returns a ref to a hash of
        all the server / environment variables data. The following would be
        a common use of this method:

         $env = $Request->ServerVariables();
         # %{$env} here would be equivalent to the cgi %ENV in perl.

  $Application Object

    Like the $Session object, you may use the $Application object to store
    data across the entire life of the application. Every page in the ASP
    application always has access to this object. So if you wanted to keep
    track of how many visitors there where to the application during its
    lifetime, you might have a line like this:

     $Application->{num_users}++

    The Lock and Unlock methods are used to prevent simultaneous access to
    the $Application object.

    $Application->Lock()
        Locks the Application object for the life of the script, or until
        UnLock() unlocks it, whichever comes first. When $Application is
        locked, this guarantees that data being read and written to it will
        not suddenly change on you between the reads and the writes.

        This and the $Session object both lock automatically upon every read
        and every write to ensure data integrity. This lock is useful for
        concurrent access control purposes.

        Be careful to not be too liberal with this, as you can quickly
        create application bottlenecks with its improper use.

    $Application->UnLock()
        Unlocks the $Application object. If already unlocked, does nothing.

    $Application->GetSession($sess_id)
        This NON-PORTABLE API extension returns a user $Session given a
        session id. This allows one to easily write a session manager if
        session ids are stored in $Application during Session_OnStart, with
        full access to these sessions for administrative purposes.

        Be careful not to expose full session ids over the net, as they
        could be used by a hacker to impersonate another user. So when
        creating a session manager, for example, you could create some other
        id to reference the SessionID internally, which would allow you to
        control the sessions. This kind of application would best be served
        under a secure web server.

        The ./site/eg/global_asa_demo.asp script makes use of this routine
        to display all the data in current user sessions.

    $Application->SessionCount()
        This NON-PORTABLE method returns the current number of active
        sessions, in the application. This method is not implemented as part
        of the ASP object model, but is implemented here because it is
        useful. In particular, when accessing databases with license
        requirements, one can monitor usage effectively through accessing
        this value.

        This is a new feature as of v.06, and if run on a site with previous
        versions of Apache::ASP, the count may take a while to synch up. To
        ensure a correct count, you must delete all the current state files
        associated with an application, usually in the $Global/.state
        directory.

  $Server Object

    The server object is that object that handles everything the other
    objects do not. The best part of the server object for Win32 users is
    the CreateObject method which allows developers to create instances of
    ActiveX components, like the ADO component.

    $Server->{ScriptTimeout} = $seconds
        Not implemented. May never be. Please see the Apache Timeout
        configuration option, normally in httpd.conf.

    $Server->Config($setting)
        API extension. Allows a developer to read the CONFIG settings, like
        Global, GlobalPackage, StateDir, etc. Currently implemented as a
        wrapper around

          Apache->dir_config($setting)

        May also be invoked as $Server->Config(), which will return a hash
        ref of all the PerlSetVar settings.

    $Server->CreateObject($program_id)
        Allows use of ActiveX objects on Win32. This routine returns a
        reference to an Win32::OLE object upon success, and nothing upon
        failure. It is through this mechanism that a developer can utilize
        ADO. The equivalent syntax in VBScript is

         Set object = Server.CreateObject(program_id)

        For further information, try 'perldoc Win32::OLE' from your favorite
        command line.

    $Server->Execute($file, @args)
        New method from ASP 3.0, this does the same thing as

          $Response->Include($file, @args)

        and internally is just a wrapper for such. Seems like we had this
        important functionality before the IIS/ASP camp!

    $Server->GetLastError()
        Not implemented, will likely not ever be because this is dependent
        on how IIS handles errors and is not relevant in Apache.

    $Server->HTMLEncode( $string || \$string )
        Returns an HTML escapes version of $string. &, ", >, <, are each
        escapes with their HTML equivalents. Strings encoded in this nature
        should be raw text displayed to an end user, as HTML tags become
        escaped with this method.

        As of version 2.23, $Server->HTMLEncode() may take a scalar
        reference for an optmization when encoding a large buffer as an API
        extension. Here is how one might use one over the other:

          my $buffer = '&' x 100000;
          $buffer = $Server->HTMLEncode($buffer);
          print $buffer;
            - or -
          my $buffer = '&' x 100000;
          $Server->HTMLEncode(\$buffer);
          print $buffer;

        Using the reference passing method in benchmarks on 100K of data was
        5% more efficient, but maybe useful for some. It saves on copying
        the 100K buffer twice.

    $Server->MapPath($url);
        Given the url $url, absolute, or relative to the current executing
        script, this method returns the equivalent filename that the server
        would translate the request to, regardless or whether the request
        would be valid.

        Only a $url that is relative to the host is valid. Urls like "." and
        "/" are fine arguments to MapPath, but http://localhost would not
        be.

        To see this method call in action, check out the sample
        ./site/eg/server.htm script.

    $Server->Mail(\%mail, %smtp_args);
        With the Net::SMTP and Net::Config modules installed, which are part
        of the perl libnet package, you may use this API extension to send
        email. The \%mail hash reference that you pass in must have values
        for at least the To, From, and Subject headers, and the Body of the
        mail message.

        You could send an email like so:

         $Server->Mail({
                        To => 'somebody@yourdomain.com.foobar',
                        From => 'youremail@yourdomain.com.foobar',
                        Subject => 'Subject of Email',
                        Body => 
                         'Body of message. '.
                         'You might have a lot to say here!',
                        Organization => 'Your Organization',
                       });

        Any extra fields specified for the email will be interpreted as
        headers for the email, so to send an HTML email, you could set
        'Content-Type' => 'text/html' in the above example.

        If you have MailFrom configured, this will be the default for the
        From header in your email. For more configuration options like the
        MailHost setting, check out the CONFIG section.

        The return value of this method call will be boolean for success of
        the mail being sent.

        If you would like to specially configure the Net::SMTP object used
        internally, you may set %smtp_args and they will be passed on when
        that object is initialized. "perldoc Net::SMTP" for more into on
        this topic.

    $Server->RegisterCleanup($sub)
         non-portable extension

        Sets a subroutine reference to be executed after the script ends,
        whether normally or abnormally, the latter occurring possibly by the
        user hitting the STOP button, or the web server being killed. This
        subroutine must be a code reference created like:

         $Server->RegisterCleanup(sub { $main::Session->{served}++; });
           or
         sub served { $main::Session->{served}++; }
         $Server->RegisterCleanup(\&served);

        The reference to the subroutine passed in will be executed. Though
        the subroutine will be executed in anonymous context, instead of the
        script, all objects will still be defined in main::*, that you would
        reference normally in your script. Output written to $main::Response
        will have no affect at this stage, as the request to the www client
        has already completed.

        Check out the ./site/eg/register_cleanup.asp script for an example
        of this routine in action.

    $Server->Transfer($file)
        New method from ASP 3.0. Transfers control to another script. The
        Response buffer will not be cleared automatically, so if you want
        this to serve as a faster $Response->Redirect(), you will need to
        call $Response->Clear() before calling this method.

        This new script will take over current execution and the current
        script will not continue to be executed afterwards. It differs from
        Execute() because the original script will not pick up where it left
        off.

    $Server->URLEncode($string)
        Returns the URL-escaped version of the string $string. +'s are
        substituted in for spaces and special characters are escaped to the
        ascii equivalents. Strings encoded in this manner are safe to put in
        urls... they are especially useful for encoding data used in a query
        string as in:

         $data = $Server->URLEncode("test data");
         $url = "http://localhost?data=$data";

         $url evaluates to http://localhost?data=test+data, and is a 
         valid URL for use in anchor <a> tags and redirects, etc.

    $Server->URL($url, \%params)
        Will return a URL with %params serialized into a query string like:

          $url = $Server->URL('test.asp', { test => value });

        which would give you a URL of test.asp?test=value

        Used in conjunction with the SessionQuery* settings, the returned
        URL will also have the session id inserted into the query string,
        making this a critical part of that method of implementing
        cookieless sessions. For more information on that topic please read
        on the setting in the CONFIG section, and the SESSIONS section too.

    $Server->XSLT($xsl_data_ref, $xml_data_ref)
         * NON-PORTABLE ASP EXTENSION *

        This method takes scalar refs for XSL and XML data and returns the
        XSLT output as a scalar ref like:

          my $xslt_data_ref = $Server->XSLT($xsl_data_ref, $xml_data_ref)

        The XSLT parser defaults to XML::XSLT, and is configured with the
        XSLTParser setting. Please see the CONFIG section for more
        information on the setting.

        This API was created to allow developers easy XSLT component
        rendering without having to render the entire ASP scripts via XSLT.
        This will make an easy plugin architecture for those looking to
        integrate XML into their existing ASP application frameworks.

        At some point, the API will likely take files as arguments, but not
        as of the 2.11 release.

SSI
    SSI is great! One of the main features of SSI is to include other files
    in the script being requested. In Apache::ASP, this is implemented in a
    couple ways, the most crucial of which is implemented in the file
    include. Formatted as

     <!--#include file=filename.inc-->

    ,the .inc being merely a convention, text from the included file will be
    inserted directly into the script being executed and the script will be
    compiled as a whole. Whenever the script or any of its includes change,
    the script will be recompiled.

    Includes go a great length to promote good decomposition and code
    sharing in ASP scripts, but they are still fairly static. As of version
    .09, includes may have dynamic runtime execution, as subroutines
    compiled into the global.asa namespace. The first way to invoke includes
    dynamically is

     <!--#include file=filename.inc args=@args-->

    If @args is specified, Apache::ASP knows to execute the include at
    runtime instead of inlining it directly into the compiled code of the
    script. It does this by compiling the script at runtime as a subroutine,
    and caching it for future invocations. Then the compiled subroutine is
    executed and has @args passed into its as arguments.

    This is still might be too static for some, as @args is still hardcoded
    into the ASP script, so finally, one may execute an include at runtime
    by utilizing this API extension

       $Response->Include("filename.inc", @args);

    which is a direct translation of the dynamic include above.

    Although inline includes should be a little faster, runtime dynamic
    includes represent great potential savings in httpd memory, as includes
    are shared between scripts keeping the size of each script to a minimum.
    This can often be significant saving if much of the formatting occurs in
    an included header of a www page.

    By default, all includes will be inlined unless called with an args
    parameter. However, if you want all your includes to be compiled as subs
    and dynamically executed at runtime, turn the DynamicIncludes config
    option on as documented above.

    That is not all! SSI is full featured. One of the things missing above
    is the

     <!--#include virtual=filename.cgi-->

    tag. This and many other SSI code extensions are available by filtering
    Apache::ASP output through Apache::SSI via the Apache::Filter and the
    Filter config options. For more information on how to wire Apache::ASP
    and Apache::SSI together, please see the Filter config option documented
    above. Also please see Apache::SSI for further information on the
    capabilities it offers.

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

    IMPORTANT (FAQ): Make sure that the web server has write access to that
    directory. Usually a

     chmod -R 0777 eg

    will do the trick :)

SESSIONS
    Cookies are used by default for user $Session support ( see OBJECTS ).
    In order to track a web user and associate server side data with that
    client, the web server sets, and the web client returns a 32 byte
    session id identifier cookie. This implementation is very secure and may
    be used in secure HTTPS transactions, and made stronger with
    SecureSession and ParanoidSession settings (see CONFIG ).

    However good cookies are for this kind of persistent state management
    between HTTP requests, they have long been under fire for security risks
    associated with JavaScript security exploits and privacy abuse by large
    data tracking companies.

    Because of these reasons, web users will sometimes turn off their
    cookies, rendering normal ASP session implementations powerless,
    resulting in a new $Session generated every request. This is not good
    for ASP style sessions.

  Cookieless Sessions

     *** See WARNING Below ***

    So we now have more ways to track sessions with the SessionQuery* CONFIG
    settings, that allow a web developer to embed the session id in URL
    query strings when use of cookies is denied. The implementations work
    such that if a user has cookies turned on, then cookies will be used,
    but for those users with cookies turned off, the session ids will be
    parsed into document URLs.

    The first and easiest method that a web developer may use to implement
    cookieless sessions are with SessionQueryParse* directives which enable
    Apache::ASP to the parse the session id into document URLs on the fly.
    Because this is resource inefficient, there is also the SessionQuery*
    directives that may be used with the $Server->URL($url,\%params) method
    to generate custom URLs with the session id in its query string.

    To see an example of these cookieless sessions in action, check out the
    ./site/eg/session_query_parse.asp example.

     *** WARNING ***

    If you do use these methods, then be VERY CAREFUL of linking offsite
    from a page that was accessed with a session id in a query string. This
    is because this session id will show up in the HTTP_REFERER logs of the
    linked to site, and a malicious hacker could use this information to
    compromise the security of your site's $Sessions, even if these are run
    under a secure web server.

    In order to shake a session id off an HTTP_REFERER for a link taking a
    user offsite, you must point that link to a redirect page that will
    redirect a user, like so:

     <% 
        # "cross site scripting bug" prevention
        my $sanitized_url = 
            $Server->HTMLEncode($Response->QueryString('OffSiteUrl'));
     %>
     <html>
     <head>
     <meta http-equiv=refresh content='0;URL=<%=$sanitized_url%>'>
     </head>
     <body> 
            Redirecting you offsite to 
            <a href=<%=$sanitized_url%> >here</a>...
     </body>
     </html>

    Because the web browser visits a real page before being redirected with
    the <meta> tag, the HTTP_REFERER will be set to this page. Just be sure
    to not link to this page with a session id in its query string.

    Unfortunately a simple $Response->Redirect() will not work here, because
    the web browser will keep the HTTP_REFERER of the original web page if
    only a normal redirect is used.

XML/XSLT
  Custom Tags with XMLSubsMatch

    Before XML, there was the need to make HTML markup smarter. Apache::ASP
    gives you the ability to have a perl subroutine handle the execution of
    any predefined tag, taking the tag descriptors, and the text contained
    between, as arguments of the subroutine. This custom tag technology can
    be used to extend a web developer's abilities to add dynamic pieces
    without having to visibly use <% %> style code entries.

    So, lets say that you have a table that you want to insert for an
    employee with contact info and the like, you could set up a tag like:

     <my:employee name="Jane" last="Doe" phone="555-2222">
       Jane Doe has been here since 1998.
     </my:employee>

    To render it with a custom tag, you would tell the Apache::ASP parser to
    render the tag with a subroutine:

      PerlSetVar XMLSubsMatch my:employee

    Any colons, ':', in the XML custom tag will turn into '::', a perl
    package separator, so the my:employee tag would translate to the
    my::employee subroutine, or the employee subroutine in the my package.

    Then you would create the my::employee subroutine in the my perl package
    or whereever like so

      sub my::employee {
        my($attributes, $body) = @_;
        $Response->Include('employee.inc', $attributes, $body);
      }

      <!-- # employee.inc file somewhere else -->
      <% my($attributes, $body) = @_; %>
      <table>
      <% for('name', 'last', 'phone') { %>
        <tr>
          <td><b><%=ucfirst $_ %></b>:</td>
          <td><%= $attributes->{$_} %></td>
        </tr>
      <% } %>
      <tr><td colspan=2><%= $body %></td></tr>
      </table>
      <!-- # end employee.inc file -->

    The $Response->Include() would then delegate the rendering of the
    employee to the employee.inc ASP script include.

    Though XML purists would not like this custom tag technology to be
    related to XML, the reality is that a careful site engineer could render
    full XML documents with this technology, applying all the correct styles
    that one might otherwise do with XSLT.

    Custom tags defined in this way can be used as XML tags are defined with
    both a body and without as it

      <my:employee>...</my:employee>

    and just

      <my:employee/>

    These tags are very powerful in that they can also enclose normal ASP
    logic, like:

      <my:employee>
        <!-- normal ASP logic -->
        <% my $birthday = &HTTP::Date::time2str(time - 25 * 86400 * 365); %>

        <!-- ASP inserts -->
        This employee has been online for <%= int(rand()*600)+1 %>
        seconds, and was born near <%= $birthday %>.
      </my:employee>   

    For an example of this custom XML tagging in action, please check out
    the ./site/eg/xml_subs.asp script. Note the one limitation that
    currently exists is that tags of the same name may not be used in each
    other, but otherwise customs tags may be used in other custom tags.

  XSLT Tranformations

    XML is good stuff, but what can you use it for? The principle is that by
    having data and style separated in XML and XSL files, you can reformat
    your data more easily in the future, and you can render your data in
    multiple formats, just as easily as for your web site, so you might
    render your site to a PDA, or a cell phone just as easily as to a
    browser, and all you have to do is set up the right XSL stylesheets to
    do the transformation (XSLT).

    In the first release of XML/XSLT support, ASP scripts may be the source
    of XML data that the XSL file transforms, and the XSL file itself will
    be first executed as an ASP script also. The XSLT transformation is
    handled by XML::XSLT or XML::Sablotron and you can see an example of it
    in action at the ./site/eg/xslt.xml XML script.

    To specify a XSL stylesheet, use the setting:

      PerlSetVar XSLT template.xsl

    where template.xsl could be any file. By default this will XSLT
    transform all ASP scripts so configured, but you can separate xml
    scripts from the rest with the setting:

      PerlSetVar XSLTMatch xml$

    where all files with the ending xml would undergo a XSLT transformation.

    Note that XSLT depends on the installation of XML::XSLT, which in turn
    depends on XML::DOM, and XML::Parser. As of version 2.11, XML::Sablotron
    may also be used by setting:

       PerlSetVar XSLTParser XML::Sablotron

    If you would like to cache XSLT tranformations, which is highly
    recommended, just set:

      PerlSetVar XSLTCache 1

    Please see the Cache settings in the CONFIG section for more about how
    to configure the XSLTCache.

  Reference OSS Implementations

    For their huge ground breaking XML efforts, these other XML OSS projects
    need mention:

      Cocoon - XML-based web publishing, in Java 
      http://xml.apache.org/cocoon/

      AxKit - XML web publishing with Apache & mod_perl
      http://www.axkit.org/

      XML::XSLT - Core engine that Apache::ASP uses for XSLT
      http://xmlxslt.sourceforge.net/

CGI
    CGI has been the standard way of deploying web applications long before
    ASP came along. In the CGI gateway world, CGI.pm has been a widely used
    module in building CGI applications, and Apache::ASP is compatible with
    scripts written with CGI.pm. Also, as of version 2.19, Apache::ASP can
    run in standalone CGI mode for the Apache web server without mod_perl
    being available. See "Standalone CGI Mode" section below.

    Following are some special notes with respect to compatibility with CGI
    and CGI.pm. Use of CGI.pm in any of these ways was made possible through
    a great amount of work, and is not guaranteed to be portable with other
    perl ASP implementations, as other ASP implementations will likely be
    more limited.

    Standalone CGI Mode, without mod_perl
        As of version 2.19, Apache::ASP scripts may be run as standalone CGI
        scripts without mod_perl being loaded into Apache. Work to date has
        only been done with mod_cgi scripts under Apache on a Unix platform,
        and it is unlikely to work under other web servers or Win32
        operating systems without further development.

        To run the ./site/eg scripts as CGI scripts, you copy the ./site
        directory to some location accessible by your web server, in this
        example its /usr/local/apache/htdocs/aspcgi, then in your httpd.conf
        activate Apache::ASP cgi scripts like so:

         Alias /aspcgi/ /usr/local/apache/htdocs/aspcgi/
         <Directory /usr/local/apache/htdocs/aspcgi/eg/>
           AddType application/x-httpd-cgi .htm
           AddType application/x-httpd-cgi .html
           AddType application/x-httpd-cgi .asp
           AddType application/x-httpd-cgi .xml
           AddType application/x-httpd-cgi .ssi
           AllowOverride None
           Options +ExecCGI +Indexes
         </Directory>

        Then copy the cgi/asp script from the distribution into the
        installed ./site/eg directory. This is so the CGI execution line at
        the top of those scripts will invoke the asp wrapper like so:

         #!/usr/local/bin/perl asp

        The asp script is a cgi wrapper that sets up the Apache::ASP
        environment in lieu of the normal mod_perl handler request. Because
        there is no Apache->dir_config() data available under mod_cgi, the
        asp script will load a asp.config file that may define a hash
        %Config of data for populating the dir_config() data. An example of
        a complex asp.config file is at ./site/eg/asp.config

        So, a trivial asp.config file might look like:

         # asp.config
         %Config = (
           'Global' => '.',
           'StateDir' => '/tmp/aspstate',
           'NoState' => 0,
           'Debug' => 3,
         );

        The default for NoState is 1 in CGI mode, so one must set NoState to
        0 for objects like $Session & $Application to be defined.

    CGI.pm
        CGI.pm is a very useful module that aids developers in the building
        of these applications, and Apache::ASP has been made to be
        compatible with function calls in CGI.pm. Please see cgi.htm in the
        ./site/eg directory for a sample ASP script written almost entirely
        in CGI.

        As of version 0.09, use of CGI.pm for both input and output is
        seamless when working under Apache::ASP. Thus if you would like to
        port existing cgi scripts over to Apache::ASP, all you need to do is
        wrap <% %> around the script to get going. This functionality has
        been implemented so that developers may have the best of both worlds
        when building their web applications.

    Query Object Initialization
        You may create a CGI.pm $query object like so:

                use CGI;
                my $query = new CGI;

        As of Apache::ASP version 0.09, form input may be read in by CGI.pm
        upon initialization. Before, Apache::ASP would consume the form
        input when reading into $Request->Form(), but now form input is
        cached, and may be used by CGI.pm input routines.

    CGI headers
        Not only can you use the CGI.pm $query->header() method to put out
        headers, but with the CgiHeaders config option set to true, you can
        also print "Header: value\n", and add similar lines to the top of
        your script, like:

         Some-Header: Value
         Some-Other: OtherValue

         <html><body> Script body starts here.

        Once there are no longer any cgi style headers, or the there is a
        newline, the body of the script begins. So if you just had an asp
        script like:

            print join(":", %{$Request->QueryString});

        You would likely end up with no output, as that line is interpreted
        as a header because of the semicolon. When doing basic debugging, as
        long as you start the page with <html> you will avoid this problem.

    print()ing CGI
        CGI is notorious for its print() statements, and the functions in
        CGI.pm usually return strings to print(). You can do this under
        Apache::ASP, since print just aliases to $Response->Write(). Note
        that $| has no affect.

                print $query->header();
                print $query->start_form();

    File Upload
        CGI.pm is used for implementing reading the input from file upload.
        You may create the file upload form however you wish, and then the
        data may be recovered from the file upload by using $Request-
        >Form(). Data from a file upload gets written to a file handle, that
        may in turn be read from. The original file name that was uploaded
        is the name of the file handle.

                my $filehandle = $Request->Form('file_upload_field_name');
                print $filehandle; # will get you the file name
                my $data;
                while(read($filehandle, $data, 1024)) {
                        # data from the uploaded file read into $data
                };

        Please see the docs on CGI.pm (try perldoc CGI) for more information
        on this topic, and ./site/eg/file_upload.asp for an example of its
        use.

        There is a $Request->FileUpload() API extension that you can use to
        get more data about a file upload, so that the following properties
        are available for querying:

          my $file_upload = $Request->{FileUpload}{upload_field};
          $file_upload->{BrowserFile}
          $file_upload->{FileHandle}
          $file_upload->{ContentType}

          # only if FileUploadTemp is set
          $file_upload->{TempFile}      

          # whatever mime headers are sent with the file upload
          # just "keys %$file_upload" to find out
          $file_upload->{?Mime-Header?}

        Please see the $Request section in OBJECTS for more information.

PERLSCRIPT
    Much work has been done to bring compatibility with ASP applications
    written in PerlScript under IIS. Most of that work revolved around
    bringing a Win32::OLE Collection interface to many of the objects in
    Apache::ASP, which are natively written as perl hashes.

    New as of version 2.05 is new functionality enabled with the
    CollectionItem setting, to giver better support to more recent
    PerlScript syntax. This seems helpful when porting from an
    IIS/PerlScript code base. Please see the CONFIG section for more info.

    The following objects in Apache::ASP respond as Collections:

            $Application
            $Session
            $Request->FileUpload *
            $Request->FileUpload('upload_file') *
            $Request->Form
            $Request->QueryString
            $Request->Cookies
            $Response->Cookies
            $Response->Cookies('some_cookie')       

      * FileUpload API Extensions

    And as such may be used with the following syntax, as compared with the
    Apache::ASP native calls. Please note the native Apache::ASP interface
    is compatible with the deprecated PerlScript interface.

     C = PerlScript Compatibility   N = Native Apache::ASP 
      
     ## Collection->Contents($name) 
     [C] $Application->Contents('XYZ')              
     [N] $Application->{XYZ}

     ## Collection->SetProperty($property, $name, $value)
     [C] $Application->Contents->SetProperty('Item', 'XYZ', "Fred");
     [N] $Application->{XYZ} = "Fred"
            
     ## Collection->GetProperty($property, $name)
     [C] $Application->Contents->GetProperty('Item', 'XYZ')         
     [N] $Application->{XYZ}

     ## Collection->Item($name)
     [C] print $Request->QueryString->Item('message'), "<br>\n\n";
     [N] print $Request->{QueryString}{'message'}, "<br>\n\n";              

     ## Working with Cookies
     [C] $Response->SetProperty('Cookies', 'Testing', 'Extra');
     [C] $Response->SetProperty('Cookies', 'Testing', {'Path' => '/'});
     [C] print $Request->Cookies(Testing) . "<br>\n";
     [N] $Response->{Cookies}{Testing} = {Value => Extra, Path => '/'};
     [N] print $Request->{Cookies}{Testing} . "<br>\n";

    Several incompatibilities exist between PerlScript and Apache::ASP:

     > Collection->{Count} property has not been implemented.
     > VBScript dates may not be used for Expires property of cookies.
     > Win32::OLE::in may not be used.  Use keys() to iterate over.
     > The ->{Item} property does not work, use the ->Item() method.

FAQ
    The following are some frequently asked questions about Apache::ASP.

  Installation

    Examples don't work, I see the ASP script in the browser?
    This is most likely that Apache is not configured to execute the
    Apache::ASP scripts properly. Check the INSTALL QuickStart section for
    more info on how to quickly set up Apache to execute your ASP scripts.

    Why do variables retain their values between requests?
    Unless scoped by my() or local(), perl variables in mod_perl are treated
    as globals, and values set may persist from one request to another. This
    can be seen in as simple a script as this:

      <HTML><BODY>
        $counter++;
        $Response->Write("<BR>Counter: $counter");
      </BODY></HTML>

    The value for $counter++ will remain between requests. Generally use of
    globals in this way is a BAD IDEA, and you can spare yourself many
    headaches if do "use strict" perl programming which forces you to
    explicity declare globals like:

      use vars qw($counter);

    You can make all your Apache::ASP scripts strict by default by setting:

      PerlSetVar UseStrict 1

    Apache errors on the PerlHandler directive ?
    You do not have mod_perl correctly installed for Apache. The PerlHandler
    directive in Apache *.conf files is an extension enabled by mod_perl and
    will not work if mod_perl is not correctly installed.

    Common user errors are not doing a 'make install' for mod_perl, which
    installs the perl side of mod_perl, and not starting the right httpd
    after building it. The latter often occurs when you have an old apache
    server without mod_perl, and you have built a new one without copying
    over to its proper location.

    To get mod_perl, go to http://perl.apache.org

    Error: no request object (Apache=SCALAR(0x???????):)
    Your Apache + mod_perl build is not working properly, and is likely a
    RedHat Linux RPM DSO build. Make sure you statically build your Apache +
    mod_perl httpd, recompiled fresh from the sources.

    I am getting a tie or MLDBM / state error message, what do I do?
    Make sure the web server or you have write access to the eg directory,
    or to the directory specified as Global in the config you are using.
    Default for Global is the directory the script is in (e.g. '.'), but
    should be set to some directory not under the www server document root,
    for security reasons, on a production site.

    Usually a

     chmod -R -0777 eg

    will take care of the write access issue for initial testing purposes.

    Failing write access being the problem, try upgrading your version of
    Data::Dumper and MLDBM, which are the modules used to write the state
    files.

  Sessions

    How can I use $Session to store complex data structures.
    Very carefully. Please read the $Session documentation in the OBJECTS
    section. You can store very complex objects in $Session, but you have to
    understand the limits, and the syntax that must be used to make this
    happen.

    In particular, stay away from statements that that have more than one
    level of indirection on the left side of an assignment like:

      $Session->{complex}{object} = $data;

    How can I keep search engine spiders from killing the session manager?
    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('NoState', 1) }"

    This will configure your environment before Apache::ASP executes and
    sees the configuration settings. You can use the mod_perl API in this
    way to configure Apache::ASP at runtime.

    Insecure dependency in eval while running with - T switch ?
    If you are running your mod_perl with "PerlTaintCheck On", which is
    recommended if you are highly concerned about security issues, you may
    get errors like "Insecure dependency ... with - T switch".

    Apache::ASP automatically untaints data internally so that you may run
    scripts with PerlTaintCheck On, but if you are using state objects like
    $Session or $Application, you must also notify MLDBM, which Apache::ASP
    uses internally, to also untaint data read from disk, with this setting:

      $MLDBM::RemoveTaint = 1;

    You could put the above line in your global.asa, which is just like a
    perl module, outside any event handlers you define there.

    How can I use $Session to store a $dbh database handle ?
    You cannot use $Session to store a $dbh handle. This can be awkward for
    those coming from the IIS/NT world, where you could store just about
    anything in $Session, but this boils down to a difference between
    threads vs. processes.

    Database handles often have per process file handles open, which cannot
    be shared between requests, so though you have stored the $dbh data in
    $Session, all the other initializations are not relevant in another
    httpd process.

    All is not lost! Apache::DBI can be used to cache database connections
    on a per process basis, and will work for most cases.

  Development

    How is database connectivity handled?
    Database connectivity is handled through perl's DBI & DBD interfaces.
    Please see http://www.symbolstone.org/technology/perl/DBI/ for more
    information. In the UNIX world, it seems most databases have cross
    platform support in perl.

    DBD::ODBC is often your ticket on Win32. On UNIX, commercial vendors
    like OpenLink Software (http://www.openlinksw.com/) provide the nuts and
    bolts for ODBC.

    Database connections can be cached per process with Apache::DBI.

    What is the best way to debug an ASP application ?
    There are lots of perl-ish tricks to make your life developing and
    debugging an ASP application easier. For starters, you will find some
    helpful hints by reading the $Response->Debug() API extension, and the
    Debug configuration directive.

    How are file uploads handled?
    Please see the CGI section. File uploads are implemented through CGI.pm
    which is loaded at runtime only for this purpose. This is the only time
    that CGI.pm will be loaded by Apache::ASP, which implements all other
    cgi-ish functionality natively. The rationale for not implementing file
    uploads natively is that the extra 100K in memory for CGI.pm shouldn't
    be a big deal if you are working with bulky file uploads.

    How do I access the ASP Objects in general?
    All the ASP objects can be referenced through the main package with the
    following notation:

     $main::Response->Write("html output");

    This notation can be used from anywhere in perl, including routines
    registered with $Server->RegisterCleanup().

    You use the normal notation in your scripts, includes, and global.asa:

     $Response->Write("html output");

    Can I print() in ASP?
    Yes. You can print() from anywhere in an ASP script as it aliases to the
    $Response->Write() method. Using print() is portable with PerlScript
    when using Win32::ASP in that environment.

    Do I have access to ActiveX objects?
    Only under Win32 will developers have access to ActiveX objects through
    the perl Win32::OLE interface. This will remain true until there are
    free COM ports to the UNIX world. At this time, there is no ActiveX for
    the UNIX world.

    Can I script in VBScript or JScript ?
    Yes, but not with this perl module. For ASP with other scripting
    languages besides perl, you will need to go with a commercial vendor in
    the UNIX world. ChiliSoft at http://www.chilisoft.com/ has one such
    solution. Of course on NT, you get this for free with IIS.

  Support and Production

    How do I get things I want done?!
    If you find a problem with the module, or would like a feature added,
    please mail support, as listed in the SUPPORT section, and your needs
    will be promptly and seriously considered, then implemented.

    What is the state of Apache::ASP?  Can I publish a web site on it?
    Apache::ASP has been production ready since v.02. Work being done on the
    module is on a per need basis, with the goal being to eventually have
    the ASP API completed, with full portability to ActiveState PerlScript
    and MKS PScript. If you can suggest any changes to facilitate these
    goals, your comments are welcome.

TUNING
    A little tuning can go a long way, and can make the difference between a
    web site that gets by, and a site that screams with speed. With
    Apache::ASP, you can easily take a poorly tuned site running at 10
    hits/second to 50+ hits/second just with the right configuration.

    Documented below are some simple things you can do to make the most of
    your site.

    For more tips & tricks on tuning Apache and mod_perl, please see the
    tuning documents at:

            Stas Bekman's mod_perl guide
            http://perl.apache.org/guide/

            Vivek Khera's mod_perl performance tuning
            http://perl.apache.org/tuning/ 

  $Application & $Session State

    Use NoState 1 setting if you don't need the $Application or $Session
    objects. State objects such as these tie to files on disk and will incur
    a performance penalty.

    If you need the state objects $Application and $Session, and if running
    an OS that caches files in memory, set your "StateDir" directory to a
    cached file system. On WinNT, all files may be cached, and you have no
    control of this. On Solaris, /tmp is a RAM disk and would be a good
    place to set the "StateDir" config setting to. When cached file systems
    are used there is little performance penalty for using state files.
    Linux tends to do a good job caching its file systems, so pick a
    StateDir for ease of system administration.

    On Win32 systems, where mod_perl requests are serialized, you can freely
    use SessionSerialize to make your $Session requests faster, and you can
    achieve similar performance benefits for $Application if you call
    $Application->Lock() in your global.asa's Script_OnStart.

  Low MaxClients

    Set your MaxClients low, such that if you have that many httpd servers
    running, which will happen on busy site, your system will not start
    swapping to disk because of excessive RAM usage. Typical settings are
    less than 100 even with 1 gig RAM! To handle more client connections,
    look into a dual server, mod_proxy front end.

  High MaxRequestsPerChild

    Set your max requests per child thread or process (in httpd.conf) high,
    so that ASP scripts have a better chance being cached, which happens
    after they are first compiled. You will also avoid the process fork
    penalty on UNIX systems. Somewhere between 50 - 500 is probably pretty
    good. You do not want to set this too high though or you will risk
    having your web processes use too much RAM. One may use
    Apache::SizeLimit or Apache::GTopLimit to optimally tune
    MaxRequestsPerChild at runtime.

  Precompile Modules

    For those modules that your Apache::ASP application uses, make sure that
    they are loaded in your sites startup.pl file, or loaded with PerlModule
    in your httpd.conf, so that your modules are compiled pre-fork in the
    parent httpd.

  Precompile Scripts

    Precompile your scripts by using the Apache::ASP->Loader() routine
    documented below. This will at least save the first user hitting a
    script from suffering compile time lag. On UNIX, precompiling scripts
    upon server startup allows this code to be shared with forked child www
    servers, so you reduce overall memory usage, and use less CPU compiling
    scripts for each separate www server process. These savings could be
    significant. On a PII300 Solaris x86, it takes a couple seconds to
    compile 28 scripts upon server startup, with an average of 50K RAM per
    compiled script, and this savings is passed on to the ALL child httpd
    servers, so total savings would be 50Kx28x20(MaxClients)=28M!

    Apache::ASP->Loader() can be called to precompile scripts and even
    entire ASP applications at server startup. Note also that in modperl,
    you can precompile modules with the PerlModule config directive, which
    is highly recommended.

     Apache::ASP->Loader($path, $pattern, %config)

    This routine takes a file or directory as its first argument. If a file,
    that file will be compiled. If a directory, that directory will be
    recursed, and all files in it whose file name matches $pattern will be
    compiled. $pattern defaults to .*, which says that all scripts in a
    directory will be compiled by default.

    The %config args, are the config options that you want set that affect
    compilation. These options include Debug, Global, GlobalPackage,
    DynamicIncludes, StatINC, StatINCMatch, XMLSubsMatch, and XMLSubsStrict.
    If your scripts are later run with different config options, your
    scripts may have to be recompiled.

    Here is an example of use in a *.conf file:

     <Perl> 
     Apache::ASP->Loader(
            '/usr/local/proj/site', "(asp|htm)\$", 
            'Global' => '/proj/perllib',
            'Debug' => -3, # see system output when starting apache

            # OPTIONAL configs if you use them in your apache configuration
            # these settings affect how the scripts are compiled and loaded
            'GlobalPackage' => 'SomePackageName',
            'DynamicIncludes' => 1, 
            'StatINC' => 1,         
            'StatINCMatch' => 'My',
            'UseStrict' => 1,
            'XMLSubsMatch' => 'my:\w+',
            'XMLSubsStrict' => 0 || 1,
            );
     </Perl>

    This config section tells the server to compile all scripts in
    c:/proj/site that end in asp or htm, and print debugging output so you
    can see it work. It also sets the Global directory to be /proj/perllib,
    which needs to be the same as your real config since scripts are cached
    uniquely by their Global directory. You will probably want to use this
    on a production server, unless you cannot afford the extra startup time.

    To see precompiling in action, set Debug to 1 for the Loader() and for
    your application in general and watch your error_log for messages
    indicating scripts being cached.

  No .htaccess or StatINC

    Don't use .htaccess files or the StatINC setting in a production system
    as there are many more files touched per request using these features.
    I've seen performance slow down by half because of using these. For
    eliminating the .htaccess file, move settings into *.conf Apache files.

    Instead of StatINC, try using the StatINCMatch config, which will check
    a small subset of perl libraries for changes. This config is fine for a
    production environment, and if used well might only incur a 10-20%
    performance penalty, depending on the number of modules your system
    loads in all, as each module needs to be checked for changes on a per
    request basis.

  Turn off Debugging

    Turn off system debugging by setting Debug to 0-3. Having the system
    debug config option on slows things down immensely, but can be useful
    when troubleshooting your application. System level debugging is
    settings -3 through -1, where user level debugging is 1 to 3. User level
    debugging is much more light weight depending on how many $Reponse-
    >Debug() statements you use in your program, and you may want to leave
    it on.

  RAM Sparing

    If you have a lot (1000's+) of scripts, and limited memory, set NoCache
    to 1, so that compiled scripts are not cached in memory. You lose about
    10-15% in speed for small scripts, but save at least 10K RAM per cached
    script. These numbers are very rough. If you use includes, you can
    instead try setting DynamicIncludes to 1, which will share compiled code
    for includes between scripts by turning an <!--#include file..--> into a
    $Response->Include().

  Resource Limits

    Make sure your web processes do not use too many resources like CPU or
    RAM with the handy Apache::Resource module. Such a config might look
    like:

     PerlModule Apache::Resource
     PerlSetEnv PERL_RLIMIT_CPU  1000
     PerlSetEnv PERL_RLIMIT_DATA 60:60

    If ever a web process should begin to take more than 60M ram or use more
    than 1000 CPU seconds, it will be killed by the OS this way. You only
    want to use this configuration to protect against runaway processes and
    web program errors, not for terminating a normally functioning system,
    so set these limits HIGH!

SEE ALSO
    perl(1), mod_perl(3), Apache(3), MLDBM(3), HTTP::Date(3), CGI(3),
    Win32::OLE(3)

KEYWORDS
    Apache, ASP, perl, apache, mod_perl, asp, Active Server Pages, perl,
    asp, web application, ASP, session management, Active Server, scripting,
    dynamic html, asp, perlscript, Unix, Linux, Solaris, Win32, WinNT, cgi
    compatible, asp, response, ASP, request, session, application, server,
    Active Server Pages

NOTES
    Many thanks to those who helped me make this module a reality. ASP +
    Apache, web development could not be better! Kudos go out to:

     !! Doug MacEachern, for moral support and of course mod_perl

     :) Dariusz Pietrzak for a nice parser optimization.
     :) Ime Smits, for his inode patch facilitating cross site code reuse, and
        some nice performance enhancements adding another 1-2% speed.
     :) Michael Davis, for easier CPAN installation.
     :) Brian Wheeler, for keeping up with the Apache::Filter times,
        and pulling off filtering ASP->AxKit.
     :) Ged Haywood, for his great help on the list & professionally.
     :) Vee McMillen, for OSS patience & understanding.
     :) Craig Samuel, at LRN, for his faith in open source for his LCEC.
     :) Geert Josten, for his wonderful work on XML::XSLT
     :) Gerald Richter, for his Embperl, collaboration and competition!
     :) Stas Bekman, for his beloved guide, and keeping us all worldly.
     :) Matt Sergeant, again, for ever the excellent XML critique.
     :) Remi Fasol + Serge Sozonoff who inspired cookieless sessions.
     :) Matt Arnold, for the excellent graphics !
     :) Adi, who thought to have full admin control over sessions
     :) Dmitry Beransky, for sharable web application includes, ASP on the big.
     :) Russell Weiss again, for finding the internal session garbage collection 
        behaving badly with DB_File sensitive i/o flushing requirements.
     :) Tony Merc Mobily, inspiring tweaks to compile scripts 10 times faster
     :) Paul Linder, who is Mr. Clean... not just the code, its faster too !
        Boy was that just the beginning.  Work with him later facilitated better
        session management and XMLSubsMatch custom tag technology.
     :) Russell Weiss, for being every so "strict" about his code.
     :) Bill McKinnon, who understands the finer points of running a web site.
     :) Richard Rossi, for his need for speed & boldly testing dynamic includes.
     :) Greg Stark, for endless enthusiasm, pushing the module to its limits.
     :) Marc Spencer, who brainstormed dynamic includes.
     :) Doug Silver, for finding most of the bugs.
     :) Darren Gibbons, the biggest cookie-monster I have ever known.
     :) Ken Williams, for great teamwork bringing full SSI to the table
     :) Matt Sergeant, for his great tutorial on PerlScript and love of ASP
     :) Jeff Groves, who put a STOP to user stop button woes
     :) Alan Sparks, for knowing when size is more important than speed
     :) Lincoln Stein, for his blessed CGI.pm module
     :) Michael Rothwell, for his love of Session hacking
     :) Francesco Pasqualini, for bringing ASP to CGI
     :) Bryan Murphy, for being a PerlScript wiz
     :) Lupe Christoph, for his immaculate and stubborn testing skills
     :) Ryan Whelan, for boldly testing on Unix in the early infancy of ASP

SUPPORT
  MAILING LIST ARCHIVE

    Try the Apache::ASP mailing list archive first when working through an
    issue as others may have had the same question as you, then try the
    mod_perl list archives since often problems working with Apache::ASP are
    really mod_perl ones.

    The Apache::ASP mailing list archives are located at:

     http://www.mail-archive.com/asp%40perl.apache.org/

    The mod_perl mailing list archives are located at:

     http://forum.swarthmore.edu/epigone/modperl
     http://www.geocrawler.com/lists/3/web/182/0/
     http://www.egroups.com/group/modperl/

  EMAIL

    Please subscribe to the Apache::ASP mailing list by sending an email to
    asp-subscribe@perl.apache.org and send your questions or comments to the
    list after your subscription is confirmed.

    To unsubscribe from the Apache::ASP mailing list, just send an email to
    asp-unsubscribe@perl.apache.org

    If you think this is a mod_perl specific issue, you can send your
    question to modperl@apache.org

SITES USING
    What follows is a list of public sites that are using Apache::ASP. If
    you use the software for your site, and would like to show your support
    of the software by being listed, please send your URL to me at
    joshua@chamas.com and I'll be sure to add it to the list.

            Alumni.NET
            http://www.alumni.net

            Anime Wallpapers dot com
            http://www.animewallpapers.com/

            Chamas Enterprises Inc.         
            http://www.chamas.com

            Cine.gr
            http://www.cine.gr

            Condo-Mart Web Service
            http://www.condo-mart.com 

            Direct.it
            http://www.direct.it/

            Discountclick.com
            http://www.discountclick.com/

            HCST
            http://www.hcst.net

            International Telecommunication Union
            http://www.itu.int

            Integra
            http://www.integra.ru/

            Internetowa Gielda Samochodowa          
            http://www.gielda.szczecin.pl

            Money FM
            http://www.moneyfm.gr

            Motorsport.com
            http://www.motorsport.com

            Multiple Listing Service of Greater Cincinnati
            http://www.cincymls.com

            NodeWorks - web link monitoring                         
            http://www.nodeworks.com

            OnTheWeb Services
            http://www.ontheweb.nu

            Planet Of Music
            http://www.planetofmusic.com 

            Provillage
            http://www.provillage.com

            Prices for Antiques
            http://www.p4a.com

            redhat.com | support
            http://www.redhat.com/apps/support/

            Samara.RU
            http://portal.samara.ru/

            Sex Shop Online                         
            http://www.sex.shop.pl
            
            Spotlight
            http://www.spotlight.com.au

            USCD Electrical & Computer Engineering
            http://ece-local.ucsd.edu

            Watthai Net Syndey Australia
            http://watthai.net

RESOURCES
    Here are some important resources listed related to the use of
    Apache::ASP for publishing web applications:

            mod_perl Apache web module
            http://perl.apache.org

            mod_perl Guide
            http://perl.apache.org/guide/

            mod_perl book
            http://www.modperl.com
            
            Perl Programming Language
            http://www.perl.com

            Apache Web Server
            http://www.apache.org
     
            PerlMonth Online Magazine
            http://www.perlmonth.com

            Apache & mod_perl Reference Cards
            http://www.refcards.com/

            Perl DBI Database Access
            http://www.symbolstone.org/technology/perl/DBI/         

TODO
    There is no specific time frame in which these things will be
    implemented. Please let me know if any of these is of particular
    interest to you, and I will give it higher priority.

  WILL BE DONE

     + Database storage of $Session & $Application, so web clusters 
       may scale better than the current NFS/CIFS StateDir implementation
       allows, maybe via Apache::Session.

  MAY BE DONE

     + VBScript, ECMAScript interpreters
     + allow use of Apache::Session for session management
     + BerkeleyDB2 integration for state management, maybe getting
       shared memory to work.
     + asp.pl, CGI method of doing asp
     + Dumping state of Apache::ASP during an error, and being
       able to go through it with the perl debugger.
     + $Request->ClientCertificate()

CHANGES
    Apache::ASP has been in development since 1998, and was production ready
    since its .02 release.

    Releases are tested on a variety of platforms including Linux, Solaris,
    & WinNT, and are used in a production setting on at least Solaris or
    Linux before being made to the public generally. Development releases
    for testing new features are provided privately.

    In July 2000, the version numbers of releases went from .19 to 1.9 which
    is more relevant to software development outside the perl community.
    Where a .10 perl module usually means first production ready release,
    this would be the equivalent of a 1.0 release for other kinds of
    software.

    $VERSION = 2.23; $DATE="10/11/2001";
    Please see README for changes for past versions.

     + = improvement; - = bug fix

     +Make sure a couple other small standard modules get loaded
      upon "PerlModule Apache::ASP", like Time::HiRes, Class::Struct,
      and MLDBM::Serializer::Data::Dumper.  If not available
      these modules won't cause errors, but will promote child httpd
      RAM sharing if they are.

     -XMLSubs args parsing fix so an arg like z-index
      does not error under UseStrict.  This is OK now:

       <my:layer z-index=3 top=0 left=0> HTML </my:layer>

     -Only remove outermost <SCRIPT> tags from global.asa
      for IIS/PerlScript compatibility.  Used to remove
      all <SCRIPT> tags, which hurt when some subs in globa.asa
      would be printing some JavaScript.

     +$Response->{IsClientConnected} now updated correctly 
      before global.asa Script_OnStart.  $Response->IsClientConnect()
      can be used for accurate accounting, while 
      $Response->{IsClientConnected} only gets updated
      after $Response->Flush().  Added test cases to response.t

     +$Server->HTMLEncode(\$data) API extension, now can take
      scalar ref, which can give a 5% improvement in benchmarks
      for data 100K in size.

     -Access to $Application is locked when Application_OnEnd & 
      Application_OnStart is called, creating a critical section
      for use of $Application

     ++MLDBM::Sync used now for core DBM support in Apache::ASP::State.
      This drastically simplifies/stabilizes the code in there
      and will make it easier for future SQL database plugins.

     +New API for accessing ASP object information in non content
      handler phases:

        use Apache::ASP;
        sub My::Auth::handler {
          my $r = shift;
          my $ASP = Apache::ASP->new($r) 
          my $Session = $ASP->Session;
        }

      In the above example, $Session would be the same $Session
      object created later while running the ASP script for this
      same request.  

      Added t/asp_object.t test for this.  Fixed global.asa to only 
      init StateDir when application.asp starts which is the first 
      test script to run.

     -Fixed on Win32 to make Apache::ASP->new($r) able to create
      multiple master ASP objects per request.  Was not reentrant 
      safe before, particularly with state locking for dbms like 
      $Application & $Session.  

     ++Output caching for includes, built on same layer ( extended )
      as XSLTCache, test suite at t/cache.t.  Enabled with special 
      arguments to 

        $Response->Include(\%args, @include_args)
        $Response->TrapInclude(\%args, @include_args)
        $Server->Execute(\%args, @include_args)

      where %args = (
        File => 'file.inc',
        Cache => 1, # to activate cache layer
        Expires => 3600, # to expire in one hour
        LastModified => time() - 600, # to expire if cached before 10 minutes ago
        Key => $Request->Form, # to cache based on checksum of serialized form data,
        Clear => 1, # to not allow fetch from cache this time, will always execute include
      );

      Like the XSLTCache, it uses MLDBM::Sync::SDBM_File
      by default, but can use DB_File or GDBM_File if
      CacheDB is set to these.

      See t/cache.t for API support until this is documented.

     +CacheSize now supports units of M, K, B like 

       CacheSize 10M
       CacheSize 10240K
       CacheSize 10000000B
       CacheSize 10000000

     -Better handling of $Session->Abandon() so multiple
      request to the same session while its being destroyed
      will have the right effect.

     +Optimized XMLSubs parsing.  Scripts with lots lof XMLSubs 
      now parse faster for the first time.  One test script with 
      almost 200 such tags went from a parse time of around 3 seconds
      to .7 seconds after optimizations.

     +Updated performance tuning docs, particularly for using
      Apache::ASP->Loader()

     +$Server->URL($url, \%params) now handles array refs
      in the params values like
        $Server->URL($url, { key => [ qw( value1 value2 ) ] })

      This is so that query string data found in 
      $Request->QueryString that gets parsed into this form
      from a string like: ?key=value&key=value2 would be 
      able to be reused passed back to $Server->URL to 
      create self referencing URLs more easily.

     -Bug fix where XMLSubs like <s:td /> now works on perl 
      5.005xx, thanks to Philip Mak for reporting & fix.

     +When searching for included files, will now join
      the absolute path of the directory of the script
      with the name of the file if its a relative file
      name like ./header.inc.  Before, would just look
      for something like ././header.inc by using '.'
      as the first directory to look for includes in.

      The result of this is that scripts in two directories
      configured with the same Global setting should be able
      to have separate local header.inc files without causing
      a cached namespace collision.

     +$Server->Config() call will return a hash ref 
      to all the config setting for that request, like
      Apache->dir_config would.

     -StatINC setting with Apache::ASP->Loader() works again.
      This makes StatINC & StatINCMatch settings viable 
      for production & development use when the system has
      very many modules.

     -Cookieless session support with configs like SessionQueryParse
      and SessionQuery now work for URLs with frags in them
      like http://localhost?arg=value#frag

     +@rv = $Response->Include() now works where there are
      multiple return values from an include like:
      <% return(1,2); %>

    $VERSION = 2.21; $DATE="8/5/2001";
     +Documented RequestParams config in CONFIG misc section.

     +Documented new XSLT caching directives.

     +Updated ./site/eg/.htaccess XSLT example config
      to use XSLTCache setting.

     +New FAQ section on why perl variables are sticky globals,
      suggested by Mark Seger.

     -push Global directory onto @INC during ASP script execution
      Protect contents of original @INC with local.  This makes
      things compatible with .09 Apache::ASP where we always had
      Global in @INC.  Fixed needed by Henrik Tougaard

     - ; is a valid separator like & for QueryString Parameters
      Fixed wanted by Anders

     -XSMLSubsMatch doc fix in CONFIG section

     +Reduces number of Session groups to 16 from 32, so 
      session manager for small user sets will be that much faster.

     +optimizations for internal database, $Application, and $Session
      creation.

     +XSLTCache must be set for XSLT caching to begin using CacheDir

     +CacheDB like StateDB bug sets dbm format for caching, which
      defaults to MLDBM::Sync::SDBM_File, which works well for caching
      output sizes < 50K

     +CacheDir config for XSLT caching ... defaults to StateDir

     +CacheSize in bytes determines whether the caches in CacheDir
      are deleted at the end of the request.  A cache will be 
      reset in this way back to 0 bytes. Defaults to 10000000 bytes
      or about 10M.

     +Caching infrastructure work that is being used in XSLT
      can be leveraged later for output caching of includes,
      or arbitrary user caching.

     -t/server_mail.t test now uses valid email for testing
      purposes ... doesn't actually send a mail, but for SMTP
      runtime validation purposes it should be OK.

     +fixed where POST data was read from under MOD_PERL,
      harmless bug this was that just generated the wrong
      system debugging message.

    $VERSION = 2.19; $DATE="7/10/2001";
     +update docs in various parts

     +added ./make_httpd/build_httpds.sh scripts for quick builds
      of apache + mod_perl + mod_ssl

     ++plain CGI mode available for ASP execution.  
      cgi/asp script can now be used to execute ASP 
      scripts in CGI mode.  See CGI perldoc section for more info.
      The examples in ./site/eg have been set up to run
      in cgi mode if desired.  Configuration in CGI section
      only tested for Apache on Linux.

     -Fixed some faulty or out of date docs in XML/XSLT section.

     +added t/server_mail.t test for $Server->Mail(), requires
      Net::SMTP to be configured properly to succeed.

     +Net::SMTP debugging not enabled by Debug 1,2,3 configs,
      not only when system debugging is set with Debug -1,-2,-3
      However, a Debug param passed to $Server->Mail() will 
      sucessfully override the Debug -1,-2,-3 setting even
      when its Debug => 0

     -Check for undef values during stats for inline includes
      so we don't trigger unintialized warnings

     +Documented ';' may separate many directories in the IncludesDir
      setting for creating a more flexible includes search path.

    $VERSION = 2.17; $DATE="6/17/2001";
     +Added ASP perl mmm-mode subclass and configuration
      in editors/mmm-asp-perl.el file for better emacs support.
      Updated SYNTAX/Editors documentation.

     +Better debugging error message for Debug 2 or 3 settings 
      for global.asa errors.  Limit debug output for lines
      preceding rendered script.

     -In old inline include mode, there should no longer
      be the error "need id for includes" when using
      $Response->Include() ... if DynamicIncludes were
      enabled, this problem would not have likely occured
      anyway.  DynamicIncludes are preferrable to use so
      that compiled includes can be shared between scripts.
      This bug was likely introduced in version 2.11.

     -Removed logging from $Response->BinaryWrite() in regular
      debug mode 1 or 2.  Logging still enabled in system Debug mode, -1 or -2

     -Removed other extra system debugging call that is really not
      necessary.

    $VERSION = 2.15; $DATE="06/12/2001";
     -Fix for running under perl 5.6.1 by removing parser optimization
      introduced in 2.11.

     -Now file upload forms, forms with ENCTYPE="multipart/form-data"
      can have multiple check boxes and select items marked for 
      @params = $Request->Form('param_name') functionality.  This 
      will be demonstrated via the ./site/eg/file_upload.asp example.

    $VERSION = 2.11; $DATE="05/29/2001";
     +Parser optimization from Dariusz Pietrzak

     -work around for global destruction error message for perl 5.6
      during install

     +$Response->{IsClientConnected} now will be set
      correctly with ! $r->connection->aborted after each
      $Response->Flush()

     +New XSLTParser config which can be set to XML::XSLT or
      XML::Sablotron.  XML::Sablotron renders 10 times faster, 
      but differently.  XML::XSLT is pure perl, so has wider
      platform support than XML::Sablotron.  This config affects
      both the XSLT config and the $Server->XSLT() method.

     +New $Server->XSLT(\$xsl_data, \$xml_data) API which 
      allows runtime XSLT on components instead of having to process
      the entire ASP output as XSLT.  

     -XSLT support for XML::XSL 0.32.  Things broke after .24.

     -XSLTCacheSize config no longer supported.  Was a bad 
      Tie::Cache implementation.  Should be file based cache
      to greatly increases cache hit ratio.

     ++$Response->Include(), $Response->TrapInclude(),
      and $Server->Execute() will all take a scalar ref
      or \'asdfdsafa' type code as their first argument to execute 
      a raw script instead of a script file name.  At this time, 
      compilation of such a script, will not be cached.  It is 
      compiled/executed as an anonymous subroutine and will be freed
      when it goes out of scope.

     + -p argument to cgi/asp script to set GlobalPackage
      config for static site builds

     -pod commenting fix where windows clients are used for 
      ASP script generation.

     +Some nice performance enhancements, thank to submissions from
      Ime Smits.  Added some 1-2% per request execution speed.

     +Added StateDB MLDBM::Sync::SDBM_File support for faster
      $Session + $Application than DB_File, yet still overcomes
      SDBM_File's 1024 bytes value limitation.  Documented in 
      StateDB config, and added Makefile.PL entry.

     +Removed deprecated MD5 use and replace with Digest::MD5 calls

     +PerlSetVar InodeNames 1 config which will compile scripts hashed by 
      their device & inode identifiers, from a stat($file)[0,1] call.
      This allows for script directories, the Global directory,
      and IncludesDir directories to be symlinked to without
      recompiling identical scripts.  Likely only works on Unix
      systems.  Thanks to Ime Smits for this one.

     +Streamlined code internally so that includes & scripts were
      compiled by same code.  This is a baby step toward fusing
      include & script code compilation models, leading to being
      able to compile bits of scripts on the fly as ASP subs, 
      and being able to garbage collect ASP code subroutines.

     -removed @_ = () in script compilation which would trigger warnings 
      under PerlWarn being set, thanks for Carl Lipo for reporting this.

     -StatINC/StatINCMatch fix for not undeffing compiled includes
      and pages in the GlobalPackage namespace

     -Create new HTML::FillInForm object for each FormFill
      done, to avoid potential bug with multiple forms filled
      by same object.  Thanks to Jim Pavlick for the tip.

     +Added PREREQ_PM to Makefile.PL, so CPAN installation will
      pick up the necessary modules correctly, without having
      to use Bundle::Apache::ASP, thanks to Michael Davis. 

     + > mode for opening lock files, not >>, since its faster

     +$Response->Flush() fixed, by giving $| = 1 perl hint
      to $r->print() and the rest of the perl sub.

     +$Response->{Cookies}{cookie_name}{Expires} = -86400 * 300;
      works so negative relative time may be used to expire cookies.

     +Count() + Key() Collection class API implementations

     +Added editors/aasp.vim VIM syntax file for Apache::ASP,
      courtesy of Jon Topper.

     ++Better line numbering with #line perl pragma.  Especially
      helps with inline includes.  Lots of work here, & integrated
      with Debug 2 runtime pretty print debugging.

     +$Response->{Debug} member toggles on/off whether 
      $Response->Debug() is active, overriding the Debug setting
      for this purpose.  Documented.

     -When Filter is on, Content-Length won't be set and compression
      won't be used.  These things would not work with a filtering
      handler after Apache::ASP

    $VERSION = 2.09; $DATE="01/30/2001";
     +Examples in ./site/eg are now UseStrict friendly.  
      Also fixed up ./site/eg/ssi_filter.ssi example.

     +Auto purge of old stale session group directories, increasing 
      session manager performance when using Sessions when migrating
      to Apache::ASP 2.09+ from older versions.

     +SessionQueryParse now works for all $Response->{ContentType}
      starting with 'text' ... before just worked with text/html,
      now other text formats like wml will work too. 

     +32 groups instead of 64, better inactive site session group purging.

     +Default session-id length back up to 32 hex bytes.
      Better security vs. performance, security more important,
      especially when performance difference was very little.

     +PerlSetVar RequestParams 1 creates $Request->Params
      object with combined contents of $Request->QueryString
      and $Request->Form

     ++FormFill feature via HTML::FillInForm.  Activate with
      $Response->{FormFill} = 1 or PerlSetVar FormFill 1
      See site/eg/formfill.asp for example.

     ++XMLSubs tags of the same name may be embedded in each other
      recursively now.

     +No umask() use on Win32 as it seems unclear what it would do

     +simpler Apache::ASP::State file handle mode of >> when opening 
      lock file.  saves doing a -e $file test.

     +AuthServerVariables config to init $Request->ServerVariables
      with basic auth data as documented.  This used to be default
      behavior, but triggers "need AuthName" warnings from recent
      versions of Apache when AuthName is not set.

     -Renamed Apache::ASP::Loader class to Apache::ASP::Load
      as it collided with the Apache::ASP->Loader() function
      namespace.  Class used internally by Apache::ASP->Loader()
      so no public API changed here.

     +-Read of POST input for $Request->BinaryRead() even
       if its not from a form.  Only set up $Request->Form
       if this is from a form POST.

     +faster POST/GET param parsing

    $VERSION = 2.07; $DATE="11/26/2000";
     -+-+ Session Manager
      empty state group directories are not removed, thus alleviating
      one potential race condition.  This impacted performance
      on idle sites severely as there were now 256 directories
      to check, so made many performance enhancements to the 
      session manager.  The session manager is built to handle
      up to 20,000 client sessions over a 20 minute period.  It
      will slow the system down as it approaches this capacity.

      One such enhancement was session-ids now being 11 bytes long 
      so that its .lock file is only 16 characters in length.  
      Supposedly some file systems lookup files 16 characters or 
      less in a fast hashed lookup.  This new session-id has
      4.4 x 10^12 possible values.  I try to keep this space as
      large as possible to prevent a brute force attack.

      Another enhancement was to limit the group directories
      to 64 by only allowing the session-id prefix to be [0-3][0-f]
      instead of [0-f][0-f], checking 64 empty directories on an
      idle site takes little time for the session manager, compared
      to 256 which felt significant from the client end, especially
      on Win32 where requests are serialized.  

      If upgrading to this version, you would do well to delete
      empty StateDir group directories while your site is idle.
      Upgrading during an idle time will have a similar effect,
      as old Apache::ASP versions would delete empty directories.

     -$Application->GetSession($session_id) now creates
      an session object that only lasts until the next
      invocation of $Application->GetSession().  This is 
      to avoid opening too many file handles at once,
      where each session requires opening a lock file.

     +added experimental support for Apache::Filter 1.013 
      filter_register call

     +make test cases for $Response->Include() and 
      $Response->TrapInclude()

     +Documented CollectionItem config.

     +New $Request->QueryString('multiple args')->Count()
      interface implemented for CollectionItem config.
      Also $Request->QueryString('multiple args')->Item(1) method.
      Note ASP collections start counting at 1.

     --fixed race condition, where multiple processes might 
      try creating the same state directory at the same time, with
      one winning, and one generating an error.  Now, web process
      will recheck for directory existence and error if 
      it doesn't. 

     -global.asa compilation will be cached correctly, not
      sure when this broke.  It was getting reloaded every request.

     -StateAllWrite config, when set creates state files
      with a+rw or 0666 permissions, and state directories
      with a+rwx or 0777 permissions.  This allows web servers
      running as different users on the same machine to share a 
      common StateDir config.  Also StateGroupWrite config
      with perms 0770 and 0660 respectively.

     -Apache::ASP->Loader() now won't follow links to 
      directories when searching for scripts to load.

     +New RegisterIncludes config which is on by default only
      when using Apache::ASP->Loader(), for compiling includes
      when precompiling scripts.

     +Apache::ASP::CompileInclude path optimized, which underlies
      $Response->Include()

     +$Request->QueryString->('foo')->Item() syntax enabled
      with CollectionItem config setting.  Default syntax
      supported is $Request->QueryString('foo') which is
      in compatible.  Other syntax like $Request->{Form}{foo}
      and $Request->Form->Item('foo') will work in either case.

     +New fix suggested for missing Apache reference in 
      Apache::ASP handler startup for RedHat RPMs.  Added
      to error message.

     --Backup flock() unlocking try for QNX will not corrupt the 
      normal flock() LOCK_UN usage, after trying to unlock a file
      that doesn't exist.  This bug was uncovered from the below 
      group deletion race condition that existed. 

     -Session garbage collection will not delete new group
      directories that have just been created but are empty.
      There was a race condition where a new group directory would
      be created, but then deleted by a garbage collector before
      it could be initialized correctly with new state files.

     +Better random session-id checksums for $Session creation.
      per process srand() initialization, because srand() 
      may be called once prefork and never called again.
      Call without arguments to rely on perl's decent rand
      seeding.  Then when calling rand() in Secret() we have
      enough random data, that even if someone else calls srand()
      to something fixed, should not mess things up terribly since
      we checksum things like $$ & time, as well as perl memory
      references.

     +XMLSubs installation make test.

     -Fix for multiline arguments for XMLSubs

    $VERSION = 2.03; $DATE="08/01/2000";
     +License change to GPL.  See LICENSE section.

     +Setup of www.apache-asp.org site, finally!

     -get rid of Apache::ASP->Loader() warning message for perl 5.6.0

    $VERSION = 2.01; $DATE="07/22/2000";
     +$data_ref = $Response->TrapInclude('file.inc') API
      extension which allows for easy post processing of
      data from includes

     +./site/eg/source.inc syntax highlighting improvements

     +XMLSubsMatch compile time parsing performance improvement

    $VERSION = 2.00; $DATE="07/15/2000";
     -UniquePackages config works again, broke a couple versions back

     +better error handling for methods called on $Application
      that don't exist, hard to debug before

    $VERSION = 1.95; $DATE="07/10/2000";
     !!!!! EXAMPLES SECURITY BUG FOUND & FIXED !!!!!

     --FIXED: distribution example ./site/eg/source.asp now parses 
      out special characters of the open() call when reading local 
      files.

      This bug would allow a malicious user possible writing
      of files in the same directory as the source.asp script.  This
      writing exploit would only have effect if the web server user
      has write permission on those files.

      Similar bug announced by openhack.org for minivend software
      in story at: 
        http://www.zdnet.com/eweek/stories/general/0,11011,2600258,00.html

      !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

     -$0 now set to transferred file, when using $Server->Transfer

     -Fix for XMLSubsMatch parsing on cases with 2 or more args passed
      to tag sub that was standalone like 
        <Apps:header type="header" title="Moo" foo="moo" />

    $VERSION = 1.93; $DATE="07/03/2000";
     -sub second timing with Time::HiRes was adding <!-- -->
      comments by HTML by default, which would possibly
      break specific programs looking for precise HTML output.
      Now this behavior must be explicitly turned on with
      the TimeHiRes config setting.

      These comments will only appear in HTML only if 
      Debug is enabled as well.

      Timed log entries will only occur if 
      system debugging is enabled, with Debug -1 or -2

    $VERSION = 1.91; $DATE="07/02/2000";
     +Documented XMLSubsMatch & XSLT* configuration
      settings in CONFIG section.

     +XSLT XSL template is now first executed as an 
      ASP script just like the XML scripts.  This is 
      just one step away now from implementing XSP logic.

     +$Server->Execute and $Server->Transfer API extensions
      implemented.  Execute is the same as $Request->Include()
      and $Server->Transfer is like an apache internal redirect
      but keeps the current ASP objects for the next script.

      Added examples, transfer.htm, and modified dynamic_includes.htm.

     +Better compile time error debugging with Debug 2 or -2.
      Will hilite/link the buggy line for global.asa errors, 
      include errors, and XML/XSLT errors just like with 
      ASP scripts before.

     +Nice source hiliting when viewing source for the example
      scripts.

     +Runtime string writing optimization for static HTML going
      through $Response.

     +New version numbering just like everyone else.  Starting at 1.91
      since I seem to be off by a factor of 10, last release would have
      been 1.9.

    $VERSION = 0.19; $DATE="NOT RELEASED";
     +XMLSubsMatch and XSLT* settings documented in 
      the XML/XSLT section of the site/README.

     -XMLSubsMatch will strip parens in a pattern match
      so it does not interfere with internal matching use.

     +XSLT integration allowing XML to be rendered by XSLT
      on the fly.  XSLT specifies XSL file to transform XML.
      XSLTMatch is a regexp that matches XML file names, like \.xml$,
      which will be transformed by XSLT setting, default .*
      
      XSLTCacheSize when specified uses Tie::Cache to cached XML DOMs 
      internally and cache XSLT transformations output per XML/XSL 
      combination.  XML DOM objects can take a lot of RAM, so use
      this setting judiciously like setting to 100.  Definitely 
      experiment with this value.

     +More client info in the error mail feature, including
      client IP, form data, query string, and HTTP_* client headers

     +With Time::HiRes loaded, and Debug set to non 0, 
      will add a <!-- Apache::ASP served request in xx.xx seconds -->
      to text/html output, similar to Cocoon, per user request  
      Will also add this to the system debug error log output
      when Debug is < 0

     -bug fix on object initialization optimization earlier
      in this release, that was introduced for faster event
      handler execution.

     +Apache::ASP::Parse() takes a file name, scalar, or
      scalar ref for arguments of data to parse for greater
      integration ability with other applications.

     +PodComments optimization, small speed increase at
      compilation time.

     +String optimization on internal rendering that avoids 
      unnecessary copying of static html, by using refs.  Should 
      make a small difference on sites with large amounts of 
      static html.

     +CompressGzip setting which, when Compress::Zlib is installed,
      will compress text/html automatically going out to the web
      browser if the client supports gzip encoding.

     ++Script_OnFlush event handler, and auxiliary work optimizing
      asp events in general.  $Response->{BinaryRef} created which
      is a reference to outgoing output, which can be used 
      to modify the data at runtime before it goes out to the client. 

     +Some code optimizations that boost speed from 22 to 24 
      hits per second when using Sessions without $Application,
      on a simple hello world benchmark on a WinNT PII300.

     ++Better SessionManagement, more aware of server farms that 
      don't have reliable NFS locking.  The key here is to have only
      one process on one server in charge of session garbage collection
      at any one time, and try to create this situation with a snazzy
      CleanupMaster routine.  This is done by having a process register
      itself in the internal database with a server key created at
      apache start time.  If this key gets stale, another process can 
      become the master, and this period will not exceed the period
      SessionTimeout / StateManager.

      ** Work on session manager sponsored by LRN, http://www.lrn.com.  **
      ** This work was used to deploy a server farm in production with  **
      ** NFS mounted StateDir. Thanks to Craig Samuel for his belief in **
      ** open source. :)                                                **

      Future work for server farm capabilities might include breaking
      up the internal database into one of 256 internal databases 
      hashed by the first 2 chars of the session id.  Also on the plate
      is Apache::Session like abilities with locking and/or data storage
      occuring in a SQL database.  The first dbs to be done will include
      MySQL & Oracle.

     +Better session security which will create a new session id for an 
      incoming session id that does not match one already seen.  This will
      help for those with Search engines that have bookmarked
      pages with the session ids in the query strings.  This breaks away
      from standard ASP session id implementation which will automatically
      use the session id presented by the browser, now a new session id will
      be returned if the presented one is invalid or expired.

     -$Application->GetSession will only return a session if
      one already existed.  It would create one before by default.

     +Script_OnFlush global.asa event handler, and $Response->{BinaryRef}
      member which is a scalar reference to the content about to be flushed.
      See ./site/eg/global.asa for example usage, used in this case to
      insert font tags on the fly into the output.

     +Highlighting and linking of line error when Debug is set to 2 or -2.

     --removed fork() call from flock() backup routine? How did 
       that get in there?  Oh right, testing on Win32. :(
       Very painful lesson this one, sorry to whom it may concern.

     +$Application->SessionCount support turned off by default
      must enable with SessionCount config option.  This feature
      puts an unnecessary load on busy sites, so not default 
      behavior now.  

     ++XMLSubsMatch setting that allows the developer to 
      create custom tags XML style that execute perl subroutines.
      See ./site/eg/xml_subs.asp

     +MailFrom config option that defaults the From: field for 
      mails sent via the Mail* configs and $Server->Mail()

     +$Server->Mail(\%mail, %smtp_args) API extension

     +MailErrorsTo & MailAlertTo now can take comma
      separated email addresses for multiple recipients.

     -tracking of subroutines defined in scripts and includes so 
      StatINC won't undefine them when reloading the GlobalPackage, 
      and so an warning will be logged when another script redefines 
      the same subroutine name, which has been the bane of at least
      a few developers.

     -Loader() will now recompile dynamic includes that 
      have changed, even if main including script has not.
      This is useful if you are using Loader() in a 
      PerlRestartHandler, for reloading scripts when
      gracefully restarting apache.

     -Apache::ASP used to always set the status to 200 by 
      default explicitly with $r->status().  This would be 
      a problem if a script was being used to as a 404 
      ErrorDocument, because it would always return a 200 error
      code, which is just wrong.  $Response->{Status} is now 
      undefined by default and will only be used if set by 
      the developer.  

      Note that by default a script will still return a 200 status, 
      but $Response->{Status} may be used to override this behavior.

     +$Server->Config($setting) API extension that allows developer
      to access config settings like Global, StateDir, etc., and is a 
      wrapper around Apache->dir_config($setting)

     +Loader() will log the number of scripts
      recompiled and the number of scripts checked, instead
      of just the number of scripts recompiled, which is
      misleading as it reports 0 for child httpds after
      a parent fork that used Loader() upon startup.        

     -Apache::ASP->Loader() would have a bad error if it didn't load 
      any scripts when given a directory, prints "loaded 0 scripts" now

    $VERSION = 0.18; $DATE="02/03/2000";
     +Documented SessionQuery* & $Server->URL() and 
      cleaned up formatting some, as well as redoing
      some of the sections ordering for better readability.
      Document the cookieless session functionality more
      in a new SESSIONS section.  Also documented new 
      FileUpload configs and $Request->FileUpload collection.
      Documented StatScripts.

     +StatScripts setting which if set to 0 will not reload
      includes, global.asa, or scripts when changed.

     +FileUpload file handles cleanup at garbage collection
      time so developer does not have to worry about lazy coding
      and undeffing filehandles used in code.  Also set 
      uploaded filehandles to binmode automatically on Win32 
      platforms, saving the developer yet more typing.

     +FileUploadTemp setting, 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 others 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}.

     +FileUploadMax setting, default 0, currently an 
      alias for $CGI::POST_MAX, which determines the 
      max size for a file upload in bytes.  

     +SessionQueryParse only auto parses session-ids
      into links when a session-id COOKIE is NOT found.
      This feature is only enabled then when a user has
      disabled cookies, so the runtime penalty of this
      feature won't drag down the whole site, since most
      users will have cookies turned on.   

     -StatINC & StatINCMatch will not undef Fnctl.pm flock 
      functions constants like O_RDWR, because the code references
      are not well trackable.  This would result in sporadic 500 server
      errors when a changed module was reloaded that imported O_* flock 
      functions from Fnctl.

     +SessionQueryParse & SessionQueryParseMatch
      settings that enable auto parsing session ids into 
      URLs for cookieless sessions.  Will pick up URLs in 
      <a href>, <area href>, <form action>, <frame src>,
      <iframe src>, <img src>, <input src>, <link href>
      $Response->Redirect($URL) and the first URL in 
      script tags like <script>*.location.href=$URL</script>

      These settings require that buffering be enabled, as
      Apache::ASP will parse through the buffer to parse the URLs.

      With SessionQueryParse on, it will just parse non-absolute
      URLs, but with SessionQueryParseMatch set to some server
      url regexp, like ^http://localhost , will also parse
      in the session id for URLs that match that.

      When testing, the performance hit from this parsing
      a script dropped from 12.5 hits/sec on my WinNT box
      to 11.7 hits per second for 1K of buffered output.
      The difference is .007 of my PII300's processing power
      per second.

      For 10K of output then, my guess is that this speed
      of script, would be slowed to 6.8 hits per second.
      This kind of performance hit would also slow a
      script running at 40 hits per second on a UNIX box
      to 31 hits/sec for 1K, and to 11 hits/sec for 10K parsed.

      Your mileage may vary and you will have to test the difference
      yourself.  Get yourself a valid URL with a session-id in
      it, and run it through ab, or Socrates, with SessionQuery
      turned on, and then with SessionQueryParse set to see 
      the difference.  SessionQuery just enables of session id
      setting from the query string but will not auto parse urls.

     -If buffering, Content-Length will again be set.
      It broke, probably while I was tuning in the past 
      couple versions.

     +UseStrict setting compiles all scripts including
      global.asa with "use strict" turned on for catching
      more coding errors.  With this setting enabled,
      use strict errors die during compilation forcing
      Apache::ASP to try to recompile the script until
      successful.

     -Object use in includes like $Response->Write() 
      no longer error with "use strict" programming.  

     +SessionQuery config setting with $Server->URL($url, { %params } ) 
      alpha API extensions to enable cookieless sessions.

     +Debugging not longer produces internal debugging
      by default.  Set to -1,-2 for internal debugging
      for Debug settings 1 & 2.

     +Both StateSerializer & StateDB can be changed 
      without affecting a live web site, by storing 
      the configurations for $Application & $Session 
      in an internal database, so that if $Session was
      created with SDBM_File for the StateDB (default),
      it will keep this StateDB setting until it ends.

     +StateSerializer config setting.  Default Data::Dumper,
      can also be set to Storable.  Controls how data is
      serialized before writing to $Application & $Session.

     +Beefed up the make test suite.

     +Improved the locking, streamlining a bit of the 
      $Application / $Session setup process.  Bench is up to 
      22 from 21 hits / sec on dev NT box.

     +Cut more fat for faster startup, now on my dev box 
      I get 44 hits per sec Apache::ASP vs. 48 Embperl 
      vs. 52 CGI via Apache::Registry for the HelloWorld Scripts.

     -Improved linking for the online site documentation, 
      where a few links before were bad.

    $VERSION = 0.17; $DATE="11/15/99";
     ++20%+ faster startup script execution, as measured by the 
      HelloWorld bench.  I cut a lot of the fat out of 
      the code, and is now at least 20% faster on startup 
      both with and without state.

      On my dev (NT, apache 1.3.6+mod_perl) machine, I now get:

            42 hits per sec on Apache::ASP HelloWorld bench
            46 hits per sec on Embperl (1.2b10) and
            51 hits per sec for CGI Apache::Registry scripts  

      Before Apache::ASP was clocking some 31 hits per sec.
      Apache::ASP also went from 75 to 102 hits per second 
      on Solaris.

     +PerlTaintCheck On friendly.  This is mod_perl's way 
      of providing -T taint checking.  When Apache::ASP
      is used with state objects like $Session or $Application,
      MLDBM must also be made taint friendly with:

        $MLDBM::RemoveTaint = 1;

      which could be put in the global.asa.  Documented.

     +Added $Response->ErrorDocument($error_code, $uri_or_string) 
      API extension which allows for setting of Apache's error
      document at runtime.  This is really just a wrapper 
      for Apache->custom_response() renamed so it syncs with
      the Apache ErrorDocument config setting.  Updated
      documentation, and added error_document.htm example.

     =OrderCollections setting was added, but then REMOVED
      because it was not going to be used.  It bound 
      $Request->* collections/hashes to Tie::IxHash, so that data
      in those collections would be read in the order the 
      browser sent it, when eaching through or with keys.

     -global.asa will be reloaded when changed.  This broke
      when I optimized the modification times with (stat($file))[9]
      rather than "use File::stat; stat($file)->mtime"

     -Make Apache::ASP->Loader() PerlRestartHandler safe,
      had some unstrict code that was doing the wrong thing.

     -IncludesDir config now works with DynamicIncludes.

     +DebugBufferLength feature added, giving control to 
      how much buffered output gets shown when debugging errors.

     ++Tuning of $Response->Write(), which processes all
      static html internally, to be almost 50% faster for
      its typical use, when BufferingOn is enabled, and 
      CgiHeaders are disabled, both being defaults.

      This can show significant speed improvements for tight
      loops that render ASP output.

     +Auto linking of ./site/eg/ text to example scripts
      at web site.

     +$Application->GetSession($session_id) API extension, useful
      for managing active user sessions when storing session ids
      in $Application.  Documented.

     -disable use of flock() on Win95/98 where it is unimplemented

     -@array context of $Request->Form('name') returns
      undef when value for 'name' is undefined.  Put extra
      logic in there to make sure this happens. 

    $VERSION = 0.16; $DATE="09/22/99";
     -$Response->{Buffer} and PerlSetVar BufferingOn
      configs now work when set to 0, to unbuffer output,
      and send it out to the web client as the script generates it.

      Buffering is enabled by default, as it is faster, and
      allows a script to error cleanly in the middle of execution.  

     +more bullet proof loading of Apache::Symbol, changed the 
      way Apache::ASP loads modules in general.  It used to 
      check for the module to load every time, if it hadn't loaded
      successfully before, but now it just tries once per httpd,
      so the web server will have to be restarted to see new installed
      modules.  This is just for modules that Apache::ASP relies on.

      Old modules that are changed or updated with an installation
      are still reloaded with the StatINC settings if so configured. 

     +ASP web site wraps <font face="courier new"> around <pre>
      tags now to override the other font used for the text
      areas.  The spacing was all weird in Netscape before
      for <pre> sections.

     -Fixed Content-Length calculation when using the Clean
      option, so that the length is calculated after the HTML
      is clean, not before.  This would cause a browser to 
      hang sometimes.

     +Added IncludesDir config option that if set will also be
      used to check for includes, so that includes may easily be
      shared between applications.  By default only Global and 
      the directory the script is in are checked for includes.

      Also added IncludesDir as a possible configuration option
      for Apache::ASP->Loader()

     -Re-enabled the Application_OnStart & OnEnd events, after
      breaking them when implementing the AllowApplicationState
      config setting.

     +Better pre-fork caching ... StatINC & StatINCMatch are now 
      args for Apache::ASP->Loader(), so StatINC symbols loading
      may be done pre-fork and shared between httpds.  This lowers
      the child httpd init cost of StatINC.  Documented.

     +Made Apache::ASP Basic Authorization friendly so authentication
      can be handled by ASP scripts.  If AuthName and AuthType Apache
      config directives are set, and a $Response->{Status} is set to 
      401, a user will be prompted for username/password authentication
      and the entered data will show up in ServerVariables as:
        $env = $Request->ServerVariables
        $env->{REMOTE_USER} = $env->{AUTH_USER} = username
        $env->{AUTH_PASSWD} = password
        $env->{AUTH_NAME}   = your realm
        $env->{AUTH_TYPE}   = 'Basic'

      This is the same place to find auth data as if Apache had some 
      authentication handler deal with the auth phase separately.

     -MailErrorsTo should report the right file now that generates
      the error.

    $VERSION = 0.15; $DATE="08/24/1999";
     --State databases like $Session, $Application are 
      now tied/untied to every lock/unlock triggered by read/write 
      access.  This was necessary for correctness issues, so that 
      database file handles are flushed appropriately between writes
      in a highly concurrent multi-process environment.

      This problem raised its ugly head because under high volume, 
      a DB_File can become corrupt if not flushed correctly.  
      Unfortunately, there is no way to flush SDBM_Files & DB_Files 
      consistently other than to tie/untie the databases every access.

      DB_File may be used optionally for StateDB, but the default is
      to use SDBM_File which is much faster, but limited to 1024 byte
      key/value pairs.

      For SDBM_Files before, if there were too many concurrent 
      writes to a shared database like $Application, some of the 
      writes would not be saved because another process
      might overwrite the changes with its own.

      There is now a 10 fold performance DECREASE associated
      with reading from and writing to files like $Session 
      and $Application.  With rough benchmarks I can get about
      100 increments (++) now per second to $Session->{count}, where
      before I could get 1000 increments / second.  

      You can improve this if you have many reads / writes happening
      at the same time, by placing locking code around the group like
      
            $Session->Lock();
            $Session->{count}++;
            $Session->{count}++;
            $Session->{count}++;
            $Session->UnLock();     

      This method will reduce the number of ties to the $Session database
      from 6 to 1 for this kind of code, and will improve the performance
      dramatically.

      Also, instead of using explicit $Session locking, you can 
      create an automatic lock on $Session per script by setting
      SessionSerialize in your config to 1.  The danger here is
      if you have any long running scripts, the user will have
      to wait for it to finish before another script can be run.

      To see the number of lock/unlocks or ties/unties to each database
      during a script execution, look at the last lines of debug output
      to your error log when Debug is set to 1.  This can help you
      performance tweak access to these databases.

     +Updated documentation with new config settings and
      API extensions.

     +Added AllowApplicationState config option which allows
      you to leave $Application undefined, and will not
      execute Application_OnStart or Application_OnEnd.
      This can be a slight performance increase of 2-3% if
      you are not using $Application, but are using $Session.

     +Added $Session->Lock() / $Session->UnLock() API routines
      necessary additions since access to session is not
      serialized by default like IIS ASP.  Also prompted
      by change in locking code which retied to SDBM_File
      or DB_File each lock.  If you $Session->Lock / UnLock
      around many read/writes, you will increase performance.

     +Added StateCache config which, if set will cache
      the file handle locks for $Application and an internal 
      database used for tracking $Session info.  This caching can 
      make an ASP application perform up to 10% faster,
      at a cost of each web server process holding 2 more 
      cached file handles open, per ASP application using
      this configuration.  The data written to or read from
      these state databases is not cached, just the locking 
      file handles are held open.

     -Added in much more locking in session manager 
      and session garbage collector to help avoid collisions
      between the two.  There were definite windows that the
      two would collide in, during which bad things could 
      happen on a high volume site.

     -Fixed some warnings in DESTROY and ParseParams()

    $VERSION = 0.14; $DATE="07/29/1999";
     -CGI & StatINC or StatINCMatch would have bad results
      at times, with StatINC deleting dynamically compiled
      CGI subroutines, that were imported into other scripts
      and modules namespaces.

      A couple tweaks, and now StatINC & CGI play nice again ;)
      StatINCMatch should be safe to use in production with CGI. 
      This affects in particular environments that use file upload, 
      since CGI is loaded automatically by Apache::ASP to handle 
      file uploads.

      This fix should also affect other seemingly random 
      times when StatINC or StatINCMatch don't seem to do 
      the right thing.

     +use of ASP objects like $Response are now "use strict"
      safe in scripts, while UniquePackages config is set.

     +Better handling of "use strict" errors in ASP scripts.
      The error is detected, and the developer is pointed to the 
      Apache error log for the exact error.  

      The script with "use strict" errors will be recompiled again.  Its seems 
      though that "use strict" will only throw its error once, so that a script 
      can be recompiled with the same errors, and work w/o any use strict
      error messaging.  

    $VERSION = 0.12; $DATE="07/01/1999";
     -Compiles are now 10 +times faster for scripts with lots of big
      embedded perl blocks <% #perl %>

      Compiles were slow because of an old PerlScript compatibility
      parsing trick where $Request->QueryString('hi')->{item}
      would be parsed to $Request->QueryString('hi') which works.
      I think the regexp that I was using had O(n^2) characteristics
      and it took a really big perl block to 10 +seconds to parse
      to understand there was a problem :(

      I doubt anyone needed this compatibility, I don't even see
      any code that looks like this in the online PerlScript examples,
      so I've commented out this parsing trick for now.  If you 
      need me to bring back this functionality, it will be in the 
      form of a config setting.

      For information on PerlScript compatibility, see the PerlScript
      section in the ASP docs.

     -Added UniquePackages config option, that if set brings back 
      the old method of compiling each ASP script into its own
      separate package.  As of v.10, scripts are compiled by default
      into the same package, so that scripts, dynamic includes & global.asa
      can share globals.  This BROKE scripts in the same ASP Application
      that defined the same sub routines, as their subs would redefine
      each other.  

      UniquePackages has scripts compiled into separate perl packages,
      so they may define subs with the same name, w/o fear of overlap.
      Under this settings, scripts will not be able to share globals.  

     -Secure field for cookies in $Response->Cookies() must be TRUE to 
      force cookie to be secure.  Before, it just had to be defined, 
      which gave wrong behavior for Secure => 0. 

     +$Response->{IsClientConnected} set to one by default.  Will
      work out a real value when I upgrade to apache 1.3.6.  This
      value has no meaning before, as apache aborts the perl code
      when a client drops its connection in earlier versions.

     +better compile time debugging of dynamic includes, with 
      Debug 2 setting

     +"use strict" friendly handling of compiling dynamic includes
      with errors

    $VERSION = 0.11; $DATE="06/24/1999";
     +Lots of documentation updates

     +The MailHost config option is the smtp server used for 
      relay emails for the Mail* config options.

     +MailAlertTo config option used for sending a short administrative
      alert for an internal ASP error, server code 500.  This is the 
      compliment to MailErrorsTo, but is suited for sending a to a
      small text based pager.  The email sent by MailErrorsTo would
      then be checked by the web admin for quick response & debugging
      for the incident. 

      The MailAlertPeriod config specifies the time in minutes during 
      which only one alert will be sent, which defaults to 20.

     +MailErrorsTo config options sends the results of a 500 error
      to the email address specified as if Debug were set to 2.
      If Debug 2 is set, this config will not be on, as it is
      for production use only.  Debug settings less than 2 only 
      log errors to the apache server error log.

     -StatINCMatch / StatINC can be used in production and work
      even after a server graceful restart, which is essential for 
      a production server.

     -Content-Length header is set again, if BufferingOn is set, and
      haven't $Response->Flush()'d.  This broke when I introduce
      the Script_OnEnd event handler.

     +Optimized reloading of the GlobalPackage perl module upon changes, 
      so that scripts and dynamic includes don't have to be recompiled.  
      The global.asa will still have to be though.  Since we started
      compiling all routines into a package that can be named with
      GlobalPackage, we've been undeffing compiled scripts and includes
      when the real GlobalPackage changed on disk, as we do a full sweep
      through the namespace.  Now, we skip those subs that we know to 
      be includes or scripts. 

     -Using Apache::Symbol::undef() to undefine precompiled scripts
      and includes when reloading those scripts.  Doing just an undef() 
      would sometimes result in an "active subroutine undef" error.
      This bug came out when I started thrashing the StatINC system
      for production use.

     +StatINCMatch setting created for production use reloading of
      perl modules.  StatINCMatch allows StatINC reloading of a
      subset of all the modules defined in %INC, those that match
      $module =~ /$StatINCMatch/, where module is some module name
      like Class/Struct.pm

     +Reoptimized pod comment parsing.  I slowed it down to sync
      lines numbers in the last version, but found another corner I could cut.

    $VERSION = 0.10; $DATE="05/24/1999";
     += improvement; - = bug fix

     +Added index.html file to ./eg to help people wade through
      the examples.  This one has been long overdue.

     +Clean config option, or setting $Response->{Clean} to 1 - 9,
      uses HTML::Clean to compress text/html output of ASP scripts.
      I like the Clean 1 setting which is lightweight, stripping 
      white space for about 10% compression, at a cost of less than
      a 5% performance penalty.

     +Using pod style commenting no longer confuses the line
      numbering.  ASP script line numbers are almost exactly match
      their compiled perl version, except that normal inline includes
      (not dynamic) insert extra text which can confuse line numbering.
      If you want perl error line numbers to entirely sync with your 
      ASP scripts, I would suggest learning how to use dynamic includes,
      as opposed to inline includes.

     -Wrapped StatINC reloading of libs in an eval, and capturing
      error for Debug 2 setting.  This makes changing libs with StatINC
      on a little more friendly when there are errors. 

     -$Request->QueryString() now stores multiple values for the 
      same key, just as $Request->Form() has since v.07.  In
      wantarray() context like @vals = $Request->QueryString('dupkey'),
      @vals will store whatever values where associated with dupkey
      in the query string like (1,2) from: ?dupkey=1&dupkey=2

     +The GlobalPackage config directive may be defined
      to explicitly set the perl module that all scripts and global.asa
      are compiled into.

     -Dynamic includes may be in the Global directory, just like
      normal includes.

     +Perl script generated from asp scripts should match line
      for line, seen in errors, except when using inline (default) 
      includes, pod comments, or <% #comment %> perl comments, which 
      will throw off the line counts by adding text, removing
      text, or having an extra newline added, respectively.

     -Script_OnEnd may now send output to the browser.  Before
      $main::Response->End() was being called at the end of the
      main script preventing further output.

    ++All scripts are compiled as routines in a namespace uniquely defined
    by the global.asa of the ASP application. Thus, scripts, includes, and
    global.asa routines will share all globals defined in the global.asa
    namespace. This means that globals between scripts will be shared, and
    globals defined in a global.asa will be available to scripts.

      Scripts used to have their own namespace, thus globals
      were not shared between them.

     +a -o $output_dir switch on the ./cgi/asp script allows
      it to execute scripts and write their output to an output
      directory.  Useful for building static html sites, based on
      asp scripts.  An example use would be:

        asp -b -o out *.asp

      Without an output directory, script output is written to STDOUT

    $VERSION = 0.09; $DATE="04/22/1999";
     +Updated Makefile.PL optional modules output for CGI & DB_File

     +Improved docs on $Response->Cookies() and $Request->Cookies()

     +Added PERFORMANCE doc to main README, and added sub section
      on precompiling scripts with Apache::ASP->Loader()

     +Naming of CompileIncludes switched over to DynamicIncludes 
      for greater clarity.

     +Dynamic includes can now reference ASP objects like $Session
      w/o the $main::* syntax.  These subs are no longer anonymous
      subs, and are now compiled into the namespace of the global.asa package.

     +Apache::ASP->Loader() precompiles dynamic includes too. Making this work
      required fixing some subtle bugs / dependencies in the compiling process.

     +Added Apache::ASP->Loader() similar to Apache::RegistryLoader for
      precompiling ASP scripts.  Precompile a whole site at server 
      startup with one function call.

     +Prettied the error messaging with Debug 2.

     +$Response->Debug(@args) debugging extension, which
      allows a developer to hook into the module's debugging,
      and only have @args be written to error_log when Debug is greater
      than 0.

     -Put write locking code around State writes, like $Session
      and $Application.  I thought I fixed this bug a while ago.

     -API change: converted $Session->Timeout() and $Session->SessionID() 
      methods into $Session->{Timeout} and $Session->{SessionID} properties.
      The use of these properties as methods is deprecated, but 
      backwards compatibility will remain.  Updated ./eg/session.asp
      to use these new properties.

     +Implemented $Response->{PICS} which if set sends out a PICS-Label
      HTTP header, useful for ratings.

     +Implemented $Response->{CacheControl} and $Response->{Charset} members.
      By default, CacheControl is 'private', and this value gets sent out
      every request as HTTP header Cache-Control.  Charset appends itself
      onto the content type header.

     +Implemented $Request->BinaryRead(), $Request->{TotalBytes},
      documented them, and updated ./eg/form.asp for an example usage. 

     +Implemented $Response->BinaryWrite(), documented, and created
      and example in ./eg/binary_write.htm

     +Implemented $Server->MapPath() and created example of its use
      in ./eg/server.htm

     -$Request->Form() now reads file uploads correctly with 
      the latest CGI.pm, where $Request->Form('file_field') returns
      the actual file name uploaded, which can be used as a file handle
      to read in the data.  Before, $Request->Form('file_field') would
      return a glob that looks like *Fh::filename, so to get the file
      name, you would have to parse it like =~ s/^\*Fh\:\://,
      which you no longer have to do.  As long as parsing was done as
      mentioned, the change should be backwards compatible.

     +Updated  +enhanced documentation on file uploads.  Created extra
      comments about it as an FAQ, and under $Response->Form(), the latter
      being an obvious place for a developer to look for it.

     +Updated ./eg/file_upload.asp to show use of non file form data, 
      with which we had a bug before.

     +Finished retieing *STDIN to cached STDIN contents, so that 
      CGI input routines may be used transparently, along side with
      use of $Request->Form()

     +Cleaned up and optimized $Request code

     +Updated documentation for CGI input & file uploads.  Created
      file upload FAQ.

     +Reworked ./eg/cgi.htm example to use CGI input routines
      after doing a native read of STDIN.

     ++Added dynamic includes with <!--include file=file args=@args-->
      extension.  This style of include is compiled as an anonymous sub & 
      cached, and then executed with @args passed to the subroutine for 
      execution.  This is include may also be rewritten as a new API 
      extension: $Response->Include('file', @args)

     +Added ./eg/compiled_includes.htm example documenting new dynamic includes.

     +Documented SSI: native file includes, and the rest with filtering 
      to Apache::SSI

     +Turned the documentation of Filter config to value of Off so 
      people won't cut and paste the On config by default.

     +Added SecureSession config option, which forces session cookie to 
      be sent only under https secured www page requests.

     +Added StateDB config option allows use of DB_File for $Session, since 
      default use of SDBM_File is limited.  See StateDB in README.

     +file include syntax w/o quotes supported like <!--#include file=test.inc-->

     +Nested includes are supported, with includes including each other.
      Recursive includes are detected and errors out when an include has been 
      included 100 times for a script.  Better to quit early than 
      have a process spin out of control. (PORTABLE ? probably not)

     +Allow <!--include file=file.inc--> notation w/o quotes around file names

     -PerlSetEnv apache conf setting now get passed through to 
      $Request->ServerVariables. This update has ServerVariables 
      getting data from %ENV instead of $r->cgi_env

     +README FAQ for PerlHandler errors

    $VERSION = 0.08; $DATE="02/06/1999";
     ++SSI with Apache::Filter & Apache::SSI, see config options & ./eg files
      Currently filtering only works in the direction Apache::ASP -> Apache::SSI,
      will not work the other way around, as SSI must come last in a set of filters

     +SSI file includes may reference files in the Global directory, better 
      code sharing

     - <% @array... %> no longer dropped from code.

     +perl =pod comments are stripped from script before compiling, and associated
      PodComments configuration options.

     +Command line cgi/asp script takes various options, and allows execution
      of multiple asp scripts at one time.  This script should be used for
      command line debugging.  This is also the beginning of building
      a static site from asp scripts with the -b option, suppressing headers.

     +$Response->AddHeader('Set-Cookie') works for multiple cookies.

     -$Response->Cookies('foo', '0') works, was dropping 0 because of boolean test

     -Fixed up some config doc errors.

    $VERSION = 0.07; $DATE="01/20/1999";
     -removed SIG{__WARN__} handler, it was a bad idea.

     -fixes file locking on QNX, work around poor flock porting

     +removed message about Win32::OLE on UNIX platforms from Makefile.PL

     -Better lock garbage collection.  Works with StatINC seamlessly.

     -Multiple select forms now work in array context with $Response->Form()
            @values = $Response->Form('multi');

     -Better CGI.pm compatibility with $r->header_out('Content-type'),
      improved garbage collection under modperl, esp. w/ file uploads

    $VERSION = 0.06; $DATE="12/21/1998";
     +Application_OnStart & Application_OnEnd event handlers support.

     -Compatible with CGI.pm 2.46 headers() 

     -Compatible with CGI.pm $q = new CGI({}), caveat: does not set params 

     +use strict; followed by use of objects like $Session is fine.

     -Multiple cookies may be set per script execution.

     +file upload implemented via CGI.pm

     ++global.asa implemented with events Session_OnStart and Session_OnEnd
      working appropriately.

     +StateDir configuration directive implemented.
      StateDir allows the session state directory to be specified separately 
      from the Global directory, useful for operating systems with caching file 
      systems.

     +StateManager config directive.  StateManager specifies how frequently
      Sessions are cleaned up, with 10 (default) meaning that old Sessions
      will be cleaned up 10 times per SessionTimeout period (default 20 minutes).

     +$Application->SessionCount() implemented, non-portable method.
            : returns the number of currently active sessions

     -STOP button fix.  Users may hit STOP button during script 
      execution, and Apache::ASP will cleanup with a routine registered
      in Apache's $r->register_cleanup.  Works well supposedly.

     +PerlScript compatibility work, trying to make ports smoother.
            : Collection emulator, no ->{Count} property
            : $.*(.*)->{Item} parsed automatically, 
              shedding the ->{Item} for Collection support (? better way ?)
            : No VBScript dates support, just HTTP RFC dates with HTTP::Date
            : Win32::OLE::in not supported, just use "keys %{$Collection}"  

     +./cgi/asp script for testing scripts from the command line
            : will be upgraded to CGI method of doing asp
            : is not "correct" in anyway, so not documented for now
              but still useful

     +strips DOS carriage returns from scripts automatically, so that
      programs like FrontPage can upload pages to UNIX servers
      without perl choking on the extra \r characters.

    $VERSION = 0.05; $DATE="10/19/1998";
     +Added PERFORMANCE doc, which includes benchmarks  +hints.

     +Better installation warnings and errors for other modules required. 

     -Turned off StatINC in eg/.htaccess, as not everyone installs Devel::Symdump

     -Fixed AUTOLOAD state bug, which wouldn't let you each through state
      objects, like %{$Session}, or each %$Session, (bug introduced in v.04)

     +Parses ASP white space better.  HTML output matches author's intent
      by better dealing with white space surrounding <% perl blocks %>

     -Scalar insertion code <%=$foo%> can now span many lines.

     +Added include.t test script for includes.

     +Script recompiles when included files change.

     +Files can be included in script with 
      SSI <!--#include file="filename"--> syntax, needs to be
      done in ASP module to allow compilation of included code and html 
      into script.  Future chaining with Apache::SSI will allow static 
      html includes, and other SSI directives

    $VERSION = 0.04; $DATE="10/14/1998";
     +Example script eg/cgi.htm demonstrating CGI.pm use for output.

     +Optimized ASP parsing, faster and more legible executing code
            : try 'die();' in code with setting PerlSetVar Debug 2

     +Cleaned up code for running with 'use strict'

     -Fixed directory handle leak on Solaris, from not closing after opendir()

     +StatINC overhaul.  StatINC setting now works as it should, with 
      the caveat that exported functions will not be refreshed.

     +NoState setting optimization, disallows $Application & $Session

     +$Application->*Lock() functions implemented

     -SoftRedirect setting for those who want scripts to keep running
      after a Redirect()

     +SessionSerialize setting to lock session while script is running
            : Microsoft ASP style session locking
            : For a session, scripts execute one at a time 
            : NOT recommended use, please see note.

     -MLDBM can be used for other things without messing up internal use
            : before if it was used with different DB's and serializers,
              internal state could be lost.

     --State file locking.  Corruption worries, and loss of data no more.

     +CGI header support, developer can use CGI.pm for *output*, or just print()
            : print "Set-Cookie: test=cookie\n", and things will just work
            : use CGI.pm for output
            : utilizes $r->send_cgi_header(), thanks Doug!

     +Improved Cookie implementation, more flexible and complete
            - Domain cookie key now works
            : Expire times now taken from time(), and relative time in sec
            : Request->Cookies() reading more flexible, with wantarray()
              on hash cookie values, %hash = $Request->Cookie('test');

     -make test module naming correction, was t.pm, now T.pm for Unix

     +POD / README cleanup, formatting and HTML friendly.

    $VERSION = 0.03; $DATE="09/14/1998";
     +Installation 'make test' now works

     +ActiveX objects on Win32 implemented with $Server->CreateObject() 

     +Cookies implemented: $Response->Cookies() & $Request->Cookies()

     -Fixed $Response object API, converting some methods to object members.
      Deprecated methods, but backwards compatible.

     +Improved error messaging, debug output

     +$, influences $Response->Write(@strings) behavior

     +perl print() works, sending output to $Response object

     +$Response->Write() prints scalars, arrays, and hashes.  Before only scalars.

     +Begin implementation of $Server object.

     +Implemented $Response->{Expires} and $Response->{ExpiresAbsolute}

     +Added "PerlSetVar StatINC" config option

     +$0 is aliased to current script filename

     +ASP Objects ($Response, etc.) are set in main package
      Thus notation like $main::Response->Write() can be used anywhere.

    $VERSION = 0.02; $DATE="07/12/1998";
     ++Session Manager, won't break under denial of service attack

     +Fleshed out $Response, $Session objects, almost full implementation.

     +Enormously more documentation.

     -Fixed error handling with Debug = 2.

     -Documentation fixed for pod2man support.  README now more man-like.

     -Stripped \r\n dos characters from installation files

     -755 mode set for session state directory when created

     -Loads Win32/OLE properly, won't break with UNIX

    $VERSION = 0.01; $DATE="06/26/1998";
     Syntax Support
     --------------
     Initial release, could be considered alpha software.
     Allows developers to embed perl in html ASP style.

     <!-- sample here -->
     <html>
     <body>
     <% for(1..10) { %>
            counting: <%=$_%> <br>
     <% } %>
     </body>
     </html>

     ASP Objects
     -----------
     $Session, $Application, $Response, $Request objects available
     for use in asp pages.

     $Session & $Application data is preserved using SDBM files.

     $Session id's are tracked through the use of cookies.

     Security
     --------
     Timeouts any attempt to use a session id that doesn't already 
     exist.  Should stop hackers, since there is no wire speed guessing
     cookies.

LICENSE
    Copyright (c) 1998-2001, Joshua Chamas, Chamas Enterprises Inc. All
    rights reserved.

    Apache::ASP is a perl native port of Active Server Pages for Apache and
    mod_perl. This software is licensed under the GPL.

    This program is free software; you can redistribute it and/or modify it
    under the terms of the GNU General Public License as published by the
    Free Software Foundation; either version 2 of the License, or (at your
    option) any later version.

    This program is distributed in the hope that it will be useful, but
    WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
    Public License for more details.

    For the full text of the GPL, see the license file in the distribution
    of this software, visit the GPL site at
    http://www.gnu.org/copyleft/gpl.html or write to the Free Software
    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
    USA.

    For general licensing questions, please see the SUPPORT section.

    To contact us about licensing terms, please email asp@chamas.com.

