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

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

DESCRIPTION
    This perl module provides an Active Server Pages port to the Apache HTTP
    Server with perl as the host scripting language. Active Server Pages is
    a web application platform that originated with the Microsoft IIS
    server. Under Apache for both Win32 and Unix, it allows a developer to
    create dynamic web applications with session management and perl code
    embedded in static html files.

    This is a portable solution, similar to ActiveState PerlScript and MKS
    PScript implementation of perl for IIS ASP. Work has been done and will
    continue to make ports to and from these other implementations as smooth
    as possible.

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

    For database access, ActiveX, and scripting language issues, please read
    the FAQ section.

WEBSITE
    For an online version of this REAME, please go to
    http://www.nodeworks.com/asp/, or the ./site directory of the
    Apache::ASP 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/

    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.

    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 HTTP Server & mod_perl
    installed before using this module in a web server environment. The
    offline mode for building static html may be used with just perl.

    If you have 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.

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

      AllowOverride All

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

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

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

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

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

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

    This directory is pushed onto @INC, you will be able to "use" and
    "require" files in this directory, so perl modules developed for this
    application may be dropped into this directory, for easy use.

    Unless StateDir is configured, this directory must be some writeable
    directory by the web server. $Session and $Application object state
    files will be stored in this directory. If StateDir is configured, then
    ignore this paragraph, as it overrides the Global directory for this
    purpose.

    Includes, specified with <!--#include file=somefile.inc--> or $Response-
    >Include() syntax, may also be in this directory, please see section on
    includes for more information.

      PerlSetVar Global /tmp

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

      PerlSetVar CookiePath /   

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

      in perl script: use Some::Package;
      in apache conf: PerlModule Some::Package

      PerlSetVar GlobalPackage Some::Package

    UniquePackages
    default 0. Set to 1 to emulate pre-v.10 ASP script compilation behavior,
    which compiles each script into its own perl package.

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

    As of v.10, ASP scripts in a web application are compiled into the
    *same* perl package by default, so these scripts, their includes, and
    the global.asa events all share common globals & subroutines defined by
    each other. The problem for some developers was that they would at times
    define a subroutine of the same name in 2+ scripts, and one subroutine
    definition would redefine the other one because of the namespace
    collision.

      PerlSetVar UniquePackages 0

    AllowSessionState
    Set to 0 for no session tracking, 1 by default If Session tracking is
    turned off, performance improves, but the $Session object is
    inaccessible.

      PerlSetVar AllowSessionState 1    

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

      PerlSetVar SessionTimeout 20 

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

      PerlSetVar SecureSession 1

    ParanoidSession
    default 0. When true, stores the user-agent header of the browser that
    creates the session and validates this against the session cookie
    presented. If this check fails, the session is killed, with the
    rationale that there is a hacking attempt underway.

    This config option was implemented to be a smooth upgrade, as you can
    turn it off and on, without disrupting current sessions. Sessions must
    be created with this turned on for the security to take effect.

    This config option is to help prevent a brute force cookie search from
    being successful. The number of possible cookies is huge, 2^128, thus
    making such a hacking attempt VERY unlikely. However, on the off chance
    that such an attack is successful, the hacker must also present
    identical browser headers to authenticate the session, or the session
    will be destroyed. Thus the User-Agent acts as a backup to the real
    session id. The IP address of the browser cannot be used, since because
    of proxies, IP addresses may change between requests during a session.

    There are a few browsers that will not present a User-Agent header.
    These browsers are considered to be browsers of type "Unknown", and this
    method works the same way for them.

    Most people agree that this level of security is unnecessary, thus it is
    titled paranoid :)

      PerlSetVar ParanoidSession 0

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

      PerlSetVar Debug 2    

    BufferingOn
    default 1, if true, buffers output through the response object.
    $Response object will only send results to client browser if a
    $Response->Flush() is called, or if the asp script ends. Lots of output
    will need to be flushed incrementally.

    If false, 0, the output is immediately written to the client, CGI style.
    There will be a performance hit server side if output is flushed
    automatically to the client, but is probably small.

    I would leave this on, since error handling is poor, if your asp script
    errors after sending only some of the output.

      PerlSetVar BufferingOn 1

    DebugBufferLength
    Default 100, set this to the number of bytes of the buffered output's
    tail you want to see when an error occurs and Debug 2 or MailErrorsTo is
    set, and when BufferingOn is enabled.

    With buffering the script output will not naturally show up when the
    script errors, as it has been buffered by the $Response object. It helps
    to see where in the script output an error halted the script, so the
    last bytes of the buffered output are included with the rest of the
    debugging information.

    For a demo of this functionality, try the ./site/eg/syntax_error.htm
    script, and turn buffering on.

    StatINC
    default 0, if true, reloads perl libraries that have changed on disk
    automatically for ASP scripts. If false, the www server must be
    restarted for library changes to take effect.

    A known bug is that any functions that are exported, e.g. confess Carp
    qw(confess), will not be refreshed by StatINC. To refresh these, you
    must restart the www server.

    This setting should be used in development only because it is so slow.
    For a production version of StatINC, see StatINCMatch.

      PerlSetVar StatINC 1

    StatINCMatch
    default undef, if defined, it will be used as a regular expression to
    reload modules that match as in StatINC. This is useful because StatINC
    has a very high performance penalty in production, so if you can narrow
    the modules that are checked for reloading each script execution to a
    handful, you will only suffer a mild performance penalty.

    The StatINCMatch setting should be a regular expression like: Struct|LWP
    which would match on reloading Class/Struct.pm, and all the LWP/.*
    libraries.

    If you define StatINCMatch, you do not need to define StatINC.

      PerlSetVar StatINCMatch .*

    SessionSerialize
    default 0, if true, locks $Session for duration of script, which
    serializes requests to the $Session object. Only one script at a time
    may run, per user $Session, with sessions allowed.

    Serialized requests to the session object is the Microsoft ASP way, but
    is dangerous in a production environment, where there is risk of long-
    running or run-away processes. If these things happen, a session may be
    locked for an indefinite period of time. A user STOP button should
    safely quit the session however.

      PerlSetVar SessionSerialize 0

    SoftRedirect
    default 0, if true, a $Response->Redirect() does not end the script.
    Normally, when a Redirect() is called, the script is ended
    automatically. SoftRedirect 1, is a standard way of doing redirects,
    allowing for html output after the redirect is specified.

      PerlSetVar SoftRedirect 0

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

      PerlSetVar NoState 0

    StateDir
    default $Global/.state. State files for ASP application go to this
    directory. Where the state files go is the most important determinant in
    what makes a unique ASP application. Different configs pointing to the
    same StateDir are part of the same ASP application.

    The default has not changed since implementing this config directive.
    The reason for this config option is to allow OS's with caching file
    systems like Solaris to specify a state directory separately from the
    Global directory, which contains more permanent files. This way one may
    point StateDir to /tmp/myaspapp, and make one's ASP application scream
    with speed.

      PerlSetVar StateDir ./.state

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

    The defaults of 20 minutes for SessionTimeout and 10 times for
    StateManager, has dead Sessions being cleaned up every 2 minutes.

      PerlSetVar StateManager 10

    StateDB
    default SDBM_File, this is the internal database used for state objects
    like $Application and $Session. Because an %sdbm_file hash has a limit
    on the size of a record / key value pair, usually 1024 bytes, you may
    want to use another tied database like DB_File.

    With lightweight $Session and $Application use, you can get away with
    SDBM_File, but if you load it up with complex data like $Session{key} =
    { # very large complex object } you might max out the 1024 limit.

    Currently StateDB can only be: SDBM_File, DB_File Please let me know if
    you would like to add any more to this list.

    If you switch to a new StateDB, you will want to delete the old
    StateDir, as there will likely be incompatibilities between the
    different database formats, including the way garbage collection is
    handled.

      PerlSetVar StateDB SDBM_File

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

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

      PerlSetVar StateCache 0

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

      PerlSetVar AllowApplicationState 1

    Filter
    On/Off, default Off. With filtering enabled, you can take advantage of
    full server side includes (SSI), implemented through Apache::SSI. SSI is
    implemented through this mechanism by using Apache::Filter. A sample
    configuration for full SSI with filtering is in the ./site/eg/.htaccess
    file, with a relevant example script ./site/eg/ssi_filter.ssi.

    You may only use this option with modperl v1.16 or greater installed and
    PERL_STACKED_HANDLERS enabled. Filtering may be used in conjunction with
    other handlers that are also "filter aware".

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

      PerlSetVar Filter Off

    PodComments
    default 1. With pod comments turned on, perl pod style comments and
    documentation are parsed out of scripts at compile time. This make for
    great documentation and a nice debugging tool, and it lets you comment
    out perl code and html in blocks. Specifically text like this:

     =pod
     text or perl code here
     =cut 

    will get ripped out of the script before compiling. The =pod and =cut
    perl directives must be at the beginning of the line, and must be
    followed by the end of the line.

      PerlSetVar PodComments 1

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

      PerlSetVar DynamicIncludes 0

    IncludesDir
    no defaults. If set, this directory will also be used to look for
    includes when compiling scripts. By default the directory the script is
    in, and the Global directory are checked for includes.

    This extension was added so that includes could be easily shared between
    ASP applications, whereas placing includes in the Global directory only
    allows sharing between scripts in an application.

      PerlSetVar IncludesDir .

    CgiHeaders
    default 0. When true, script output that looks like HTTP / CGI headers,
    will be added to the HTTP headers of the request. So you could add: Set-
    Cookie: test=message <html>... to the top of your script, and all the
    headers preceding a newline will be added as if with a call to
    $Response->AddHeader(). This functionality is here for compatibility
    with raw cgi scripts, and those used to this kind of coding.

    When set to 0, CgiHeaders style headers will not be parsed from the
    script response.

      PerlSetVar CgiHeaders 0

    Clean
    default 0, may be set between 1 and 9. This setting determine how much
    text/html output should be compressed. A setting of 1 strips mostly
    white space saving usually 10% in output size, at a performance cost of
    less than 5%. A setting of 9 goes much further saving anywhere 25% to
    50% typically, but with a performance hit of 50%.

    This config option is implemented via HTML::Clean. Per script
    configuration of this setting is available via the $Response->{Clean}
    property, which may also be set between 0 and 9.

      PerlSetVar Clean 0

    MailHost
    The mail host is the smtp server that the below Mail* config directives
    will use when sending their emails. By default Net::SMTP uses smtp mail
    hosts configured in Net::Config, which is set up at install time, but
    this setting can be used to override this config.

    The mail hosts specified in the Net::Config file will be used as backup
    smtp servers to the MailHost specified here, should this primary server
    not be working.

      PerlSetVar MailHost smtp.yourdomain.com

    MailErrorsTo
    No default, if set, ASP server errors, error code 500, that result while
    compiling or running scripts under Apache::ASP will automatically be
    emailed to the email address set for this config. This allows an
    administrator to have a rapid response to user generated server errors
    resulting from bugs in production ASP scripts. Other errors, such as 404
    not found will be handled by Apache directly.

    An easy way to see this config in action is to have an ASP script which
    calls a die(), which generates an internal ASP 500 server error.

    The Debug config of value 2 and this setting are mutually exclusive, as
    Debug 2 is a development setting where errors are displayed in the
    browser, and MailErrorsTo is a production setting so that errors are
    silently logged and sent via email to the web admin.

      PerlSetVar MailErrorsTo youremail@yourdomain.com

    MailAlertTo
    The address configured will have an email sent on any ASP server error
    500, and the message will be short enough to fit on a text based pager.
    This config setting would be used to give an administrator a heads up
    that a www server error occurred, as opposed to MailErrorsTo would be
    used for debugging that server error.

    This config does not work when Debug 2 is set, as it is a setting for
    use in production only, where Debug 2 is for development use.

      PerlSetVar MailAlertTo youremail@yourdomain.com

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

      PerlSetVar MailAlertPeriod 20

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

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

  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 the user hits a STOP button, since the program execution ends
    immediately at this event. To always run critical code, use the API
    extension:

            $Server->RegisterCleanup()

  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.

  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.

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.

      Currently the Apache::ASP object model supports the following:
      
        Object       -      Function
        ------              --------
        $Session     -      session state
        $Response    -      output
        $Request     -      input
        $Application -      application state
        $Server      -      OLE support + misc.

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

  $Session Object

    The $Session object keeps track of user + 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 directory, and will persist across 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 explains what its
        supposed to do.

    $Session->{LCID}
        Not implemented. May never be until someone explains what its
        supposed to do.

    $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->{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-
        Length 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.

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

    $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    (no weekday, no time)
         "09 Feb 1994"       -- proposed new HTTP format  (no weekday, no time)

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

    $Response->{IsClientConnected}
        Not implemented, but returns 1 currently for portability. This is
        value is not yet relevant, and may not be until apache 1.3.6, which
        will be tested shortly. Apache versions less than 1.3.6 abort the
        perl code immediately upon the client dropping the connection.

    $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 shortcut, 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($error_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.

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

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

        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->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($session_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->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->HTMLEncode($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. "

    $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->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->RegisterCleanup($sub_reference)
         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.

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

CGI
    CGI has been the standard way of deploying web applications long before
    ASP came along. 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.

    Following are some special notes with respect to compatibility with CGI.
    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.

    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.

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.

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

            $Application
            $Session
            $Request->Form
            $Request->QueryString
            $Request->Cookies
            $Response->Cookies
            $Response->Cookies('Any Cookie')

    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 Collections.
     > The ->{Item} property does not work, use the ->Item() method.

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

    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.

    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;

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

    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.

    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

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

    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 (http://www.chilisoft.com/) has one
        such solution. Of course on NT, you get this for free with IIS.

    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.

    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.

    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.

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 5
    hits/second to 25+ 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:

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

            Stas Beckman's modperl Guide
            http://perl.apache.org/guide/

  $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 cached 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.

  High MaxRequests

    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 100 - 1000 is probably pretty
    good.

  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 my PII300, 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 child httpd servers.

    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 arg. 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, and StatINCMatch. 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(
                    'c:/proj/site', "(asp|htm)\$", 
                    Global => '/proj/perllib',
                    Debug => 1, # see 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,           
                    ); 
     </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.

  Turn off Debugging

    Turn debugging off by setting Debug to 0. Having the debug config option
    on slows things down immensely.

  RAM Sparing

    If you have a lot 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 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.

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
     :) Ryan Whelan, for boldly testing on Unix in the early infancy of ASP
     :) Lupe Christoph, for his immaculate and stubborn testing skills
     :) Bryan Murphy, for being a PerlScript wiz
     :) Francesco Pasqualini, for bringing ASP to CGI
     :) Michael Rothwell, for his love of Session hacking
     :) Lincoln Stein, for his blessed CGI.pm module
     :) Alan Sparks, for knowing when size is more important than speed
     :) Jeff Groves, who put a STOP to user stop button woes
     :) Matt Sergeant, for his great tutorial on PerlScript and love of ASP
     :) Ken Williams, for great teamwork bringing full SSI to the table
     :) Darren Gibbons, the biggest cookie-monster I have ever known.
     :) Doug Silver, for finding most of the bugs.
     :) Marc Spencer, who brainstormed dynamic includes.
     :) Greg Stark, for endless enthusiasm, pushing the module to its limits.
     :) Richard Rossi, for his need for speed & boldly testing dynamic includes.
     :) Bill McKinnon, who understands the finer points of running a web site.
     :) Russell Weiss, for being every so "strict" about his code.
     :) Paul Linder, who is Mr. Clean... not just the code, its faster too !
     :) Tony Merc Mobily, inspiring tweaks to compile scripts 10 times faster
     :) Russell Weiss again, for finding the internal session garbage collection 
        behaving badly with DB_File's sensitive i/o flushing requirements.
     :) Dmitry Beransky, for sharable web application includes, ASP on the big.
     :) Adi, who thought to have full admin control over sessions
     :) Matt Arnold, for the excellent graphics !

SUPPORT
    Support is available via email and mailing list archive.

  MAILING LIST ARCHIVE

    The modperl mailing list archive is located at
    http://forum.swarthmore.edu/epigone/modperl , and allows searching for
    previously asked Apache::ASP questions.

  EMAIL

    Please send any questions or comments to the Apache modperl mailing list
    at modperl@apache.org with Apache::ASP in the subject line, or if you do
    not feel appropriate for the list, just to me directly at
    chamas@alumni.stanford.org .

    Please email the modperl list when possible, as it allows other
    Apache::ASP users the opportunity to answer your questions, and archives
    the answer at the above list mailing list archive.

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.

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

            CertSite
            http://www.certsite.com/

            HCST
            http://www.hcst.net

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

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

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

            NODEWORKS - web site link monitoring                            
            http://www.nodeworks.com

            OnTheWeb Services
            http://www.ontheweb.nu

            Provillage
            http://www.provillage.com

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

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

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

            Wild Technologies Limited
            http://wild.com.hk

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

    All rights reserved. This program is free software; you can redistribute
    it and/or modify it under the same terms as Perl itself.

