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 Apache::ASP downloading and installation, please read the INSTALL
section.
For database access, ActiveX, and scripting language issues, please read
the FAQ section.
WEBSITE
The Apache::ASP website is at http://www.nodeworks.com/asp/ 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/
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.
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.
RedHat Issues
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.
Quick Start
Once you have successfully built the Apache HTTP 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.
You will know that Apache::ASP is working normally if you can run the
scripts in ./site/eg/ without any errors.
CONFIG
You may use a generic <Location> directive in your httpd.conf Apache
configuration file to make Apache::ASP start ticking. Configure the
optional setting 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!
<Location /asp/>
SetHandler perl-script
PerlHandler Apache::ASP
PerlSetVar Global /tmp
</Location>
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 also use the <Files ~ (\.asp)> tag in the httpd.conf Apache
configuration file or .htaccess, which allows a developer to mix other
file types in the application, static or otherwise. This method is more
natural for ASP coding, with mixed media per directory.
Core
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
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 .
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
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 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.
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
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 COOKIES 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 website, 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 Use 1 for
production debugging, use 2 for development. Turn off if you are not
debugging.
PerlSetVar Debug 2
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
Miscellaneous
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
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".
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
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
Mail Administration
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
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
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 - user session state
$Response - output to browser
$Request - input from browser
$Application - application state
$Server - general support methods
These objects, and their methods are further defined in the following
sections.
$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->{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
"09 Feb 1994" -- proposed new HTTP format
"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, 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.
$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->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() colletion. 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.
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($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->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)
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->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 the setting in the CONFIG section, and the COOKIES section
too.
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.
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.
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.
COOKIES
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/cookieless_session.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.
FAQ
The following are some frequently asked questions about Apache::ASP.
Installation
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;
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 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:
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 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 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 !
:) Remi Fasol + Serge Sozonoff who inspired cookieless sessions.
:) Matt Sergeant, again, for ever the excellent XML critique.
:) Stas Bekman, for his beloved guide, and keeping us all worldly.
:) Gerald Richter, for his Embperl, collaboration and competition!
SUPPORT
MAILING LIST ARCHIVE
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.bitmechanic.com/mail-archives/modperl/
http://www.egroups.com/group/modperl/
and allow searching for previously asked Apache::ASP and mod_perl
questions. Often times what may seem to be an Apache::ASP issue is
really a mod_perl issue.
EMAIL
Please send any questions or comments to the Apache mod_perl mailing
list at modperl@apache.org with at least Apache::ASP in the subject
line. Note that answers to these questions will be archived at the above
mailing archives, and you may be able to find your answer there.
COMMERCIAL
We are considering a commercial support offering for Apache::ASP, with
varying levels of service, ranging from 24x7 incident support packages,
high priority module development, web application tuning and basic
guaranteed email support.
If you are interested in any of the above commercial support offerings,
please email asp@chamas.com and we will pursue an official support
channel if there is enough interest. Please note that this would likely
be modeled on the MySQL support features and pricing.
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
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 link monitoring
http://www.nodeworks.com
OnTheWeb Services
http://www.ontheweb.nu
Provillage
http://www.provillage.com
Prices for Antiques
http://www.p4a.com
redhat.com | support
http://www.redhat.com/apps/support/
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
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
+ Better debugging, line numbers for dynamic includes.
Maybe also some lightweight syntax error checking.
+ MailErrorsPower, sends duplicate errors every 1,10,100... occurances
+ MailErrorsPowerPeriod, resets the duplicate errors counter.
+ XML extensions allowing full rendering of XML documents, and
custom tag extensions for a site.
+ Database storage of $Session & $Application, so web clusters may be used
to serve up Apache::ASP content, maybe via Apache::Session.
+ Dumping state of Apache::ASP during an error, and being
able to go through it with the perl debugger.
+ Investigating possibility of hooking $Session timeout into
client/server 401 authentication failure. Seems like IE
caches passwords which makes things tough
+ $Request->ClientCertificate()
+ asp.pl, CGI method of doing asp
MAY BE DONE
+ VBScript, ECMAScript interpreters
+ allow use of Apache::Session for session management
+ Close integration with HTML::Embperl
+ BerkeleyDB2 integration for state management, maybe getting
shared memory to work.
CHANGES
+ = improvement; - = bug fix
$VERSION = .18; $DATE="02/03/00";
+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 COOKIES 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 filehandles 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://www.mysite.com, 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 enableb,
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 = .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 get's 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 = .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 cacheing ... 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 = .15; $DATE="08/24/99";
--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
perfomance 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 definate 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 = .14; $DATE="07/29/99";
-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 = .12; $DATE="07/01/99";
-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 = .11; $DATE="06/24/99";
+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 undef'ing 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 = .10; $DATE="05/24/99";
+= 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
whitespace 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 dir, script output is written to STDOUT
$VERSION = .09; $DATE="04/22/99";
+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 = .08; $DATE="02/06/99";
++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 = .07; $DATE="01/20/99";
-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 seemlessly.
-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 garabage collection under modperl, esp. w/ file uploads
$VERSION = .06; $DATE="12/21/98";
+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 OS's with caching filesystems.
+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 = .05; $DATE="10/19/98";
+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 = .04; $DATE="10/14/98";
+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 = .03; $DATE="09/14/98";
+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 = .02; $DATE="07/12/98";
++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 = .01; $DATE="06/26/98";
Syntax Support
--------------
Intial realease, 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.
COPYRIGHT
Copyright (c) 1998-2000, 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.