which is not always wanted or expected. Set XMLSubsStrict to 1 if this
is the case.
XSLT
default not defined, if set to a file, ASP scripts will be regarded as
XML output and transformed with the given XSL file with XML::XSLT. This
XSL file will also be executed as an ASP script first, and its output
will be the XSL data used for the transformation. This XSL file will be
executed as a dynamic include, so may be located in the current
directory, Global, or IncludesDir.
Please see the XML/XSLT section for an explanation of its use.
PerlSetVar XSLT template.xsl
XSLTMatch
default .*, if XSLT is set by default all ASP scripts will be XSL
transformed by the specified XSL template. This regexp setting will tell
XSLT which file names to match with doing XSL transformations, so that
regular HTML ASP scripts and XML ASP scripts can be configured with the
same configuration block. Please see ./site/eg/.htaccess for an example
of its use.
PerlSetVar XSLTMatch \.xml$
XSLTParser
default XML::XSLT, determines which perl module to use for XSLT parsing.
This is a new config as of 2.11. Also supported is XML::Sablotron which
does not handle XSLT with the exact same output, but is about 10 times
faster than XML::XSLT.
PerlSetVar XSLTParser XML::Sablotron
XSLTCache
Activate XSLT file based caching through CacheDB, CacheDir, and
CacheSize settings. This gives cached XSLT performance near AxKit and
greater than Cocoon. XSLT caches transformations keyed uniquely by XML &
XSLT inputs.
PerlSetVar XSLTCache 1
XSLTCacheSize
as of version 2.11, this config is no longer supported.
Caching
Currently only XSLTCache uses the dbm caching layer. The caching layer
is built generically to be able to use it for convenient output and user
data caching.
CacheDB
Like StateDB, sets dbm format for caching. Since SDBM_File only support
key/values pairs of around 1K max in length, the default for this is
MLDBM::Sync::SDBM_File, which is very fast for < 50K file sizes. For
caching larger data than 50K, DB_File or GDBM_File are probably better
to use.
PerlSetVar CacheDB MLDBM::Sync::SDBM_File
CacheDir
By default, the cache directory is at StateDir/cache, but if StateDir is
not set, then CacheDir can be used to set the StateDir value for caching
purposes. This is to make things less confusing when NoState 1 is set.
PerlSetVar CacheDir /tmp/asp_demo
CacheSize
By default, this is 10000000, or nearly 10M of data per cache. When any
cache, like the XSLTCache, reaches this limit, the cache will be purged
by deleting the cached dbm files entirely. This is better for long term
running of dbms than deleting individual records, because dbm formats
will often degrade in performance with lots of insert & deletes.
PerlSetVar CacheSize 10000000
Currently the only cache that can be used is the XSLTCache.
Miscellaneous
AuthServerVariables
default 0. If you are using basic auth and would like $Request-
>ServerVariables set like AUTH_TYPE, AUTH_USER, AUTH_NAME, REMOTE_USER,
& AUTH_PASSWD, then set this and Apache::ASP will initialize these
values from Apache->*auth* commands. Use of these environment variables
keeps applications cross platform compatible as other servers set these
too when performing basic 401 auth.
PerlSetVar AuthServerVariables 0
BufferingOn
default 1, if true, buffers output through the response object.
$Response object will only send results to client browser if a
$Response->Flush() is called, or if the asp script ends. Lots of output
will need to be flushed incrementally.
If false, 0, the output is immediately written to the client, CGI style.
There will be a performance hit server side if output is flushed
automatically to the client, but is probably small.
I would leave this on, since error handling is poor, if your asp script
errors after sending only some of the output.
PerlSetVar BufferingOn 1
InodeNames
Default 0. Set to 1 to uses a stat() call on scripts and includes to
derive subroutine namespace based on device and inode numbers. In case
of multiple symbolic links pointing to the same script this will result
in the script being compiled only once. Use only on unix flavours which
support the stat() call that know about device and inode numbers.
PerlSetVar InodeNames 1
RequestParams
Default 0, if set creates $Request->Params object with combined contents
of $Request->QueryString and $Request->Form. This is for developer
convenience simlar to CGI.pm's param() method.
PerlSetVar RequestParams 1
StatINC
default 0, if true, reloads perl libraries that have changed on disk
automatically for ASP scripts. If false, the www server must be
restarted for library changes to take effect.
A known bug is that any functions that are exported, e.g. confess Carp
qw(confess), will not be refreshed by StatINC. To refresh these, you
must restart the www server.
This setting should be used in development only because it is so slow.
For a production version of StatINC, see StatINCMatch.
PerlSetVar StatINC 1
StatINCMatch
default undef, if defined, it will be used as a regular expression to
reload modules that match as in StatINC. This is useful because StatINC
has a very high performance penalty in production, so if you can narrow
the modules that are checked for reloading each script execution to a
handful, you will only suffer a mild performance penalty.
The StatINCMatch setting should be a regular expression like: Struct|LWP
which would match on reloading Class/Struct.pm, and all the LWP/.*
libraries.
If you define StatINCMatch, you do not need to define StatINC.
PerlSetVar StatINCMatch .*
StatScripts
default 1, if set to 0, changed scripts, global.asa, and includes will
not be reloaded. Coupled with Apache mod_perl startup and restart
handlers executing Apache::ASP->Loader() for your application this
allows your application to be frozen, and only reloaded on the next
server restart or stop/start.
There are a few advantages for not reloading scripts and modules in
production. First there is a slight performance improvement by not
having to stat() the script, its includes and the global.asa every
request.
From an application deployment standpoint, you also gain the ability to
deploy your application as a snapshot taken when the server starts and
restarts. This provides you with the reassurance that during a
production server update from development sources, you do not have to
worry with sources being used for the wrong libraries and such, while
they are all being copied over.
Finally, though you really should not do this, you can work on a live
production application, with a test server reloading changes, but your
production server does see the changes until you restart or stop/start
it. This saves your public from syntax errors while you are just doing a
quick bug fix.
PerlSetVar StatScripts 1
SoftRedirect
default 0, if true, a $Response->Redirect() does not end the script.
Normally, when a Redirect() is called, the script is ended
automatically. SoftRedirect 1, is a standard way of doing redirects,
allowing for html output after the redirect is specified.
PerlSetVar SoftRedirect 0
Filter
On/Off, default Off. With filtering enabled, you can take advantage of
full server side includes (SSI), implemented through Apache::SSI. SSI is
implemented through this mechanism by using Apache::Filter. A sample
configuration for full SSI with filtering is in the ./site/eg/.htaccess
file, with a relevant example script ./site/eg/ssi_filter.ssi.
You may only use this option with modperl v1.16 or greater installed and
PERL_STACKED_HANDLERS enabled. Filtering may be used in conjunction with
other handlers that are also "filter aware". If in doubt, try building
your mod_perl with
perl Makefile.PL EVERYTHING=1
With filtering through Apache::SSI, you should expect near a a 20%
performance decrease.
PerlSetVar Filter Off
CgiHeaders
default 0. When true, script output that looks like HTTP / CGI headers,
will be added to the HTTP headers of the request. So you could add: Set-
Cookie: test=message ... to the top of your script, and all the
headers preceding a newline will be added as if with a call to
$Response->AddHeader(). This functionality is here for compatibility
with raw cgi scripts, and those used to this kind of coding.
When set to 0, CgiHeaders style headers will not be parsed from the
script response.
PerlSetVar CgiHeaders 0
Clean
default 0, may be set between 1 and 9. This setting determine how much
text/html output should be compressed. A setting of 1 strips mostly
white space saving usually 10% in output size, at a performance cost of
less than 5%. A setting of 9 goes much further saving anywhere 25% to
50% typically, but with a performance hit of 50%.
This config option is implemented via HTML::Clean. Per script
configuration of this setting is available via the $Response->{Clean}
property, which may also be set between 0 and 9.
PerlSetVar Clean 0
CompressGzip
default 0, if true will gzip compress HTML output on the fly if
Compress::Zlib is installed, and the client browser supports it.
Depending on the HTML being compressed, the client may see a 50% to 90%
reduction in HTML output. I have seen 40K of HTML squeezed down to just
under 6K. This will come at a 5%-20% hit to CPU usage per request
compressed.
Note there are some cases when a browser says it will accept gzip
encoding, but then not render it correctly. This behavior has been seen
with IE5 when set to use a proxy but not using a proxy, and the URL does
not end with a .html or .htm. No work around has yet been found for this
case so use at your own risk.
PerlSetVar CompressGzip 1
FormFill
default 0, if true will auto fill HTML forms with values from $Request-
>Form(). This functionality is provided by use of HTML::FillInForm. For
more information please see "perldoc HTML::FillInForm", and the example
./site/eg/formfill.asp.
This feature can be enabled on a per form basis at runtime with
$Response->{FormFill} = 1
PerlSetVar FormFill 1
TimeHiRes
default 0, if set and Time::HiRes is installed, will do sub second
timing of the time it takes Apache::ASP to process a request. This will
not include the time spent in the session manager, nor modperl or
Apache, and is only a rough approximation at best.
If Debug is set also, you will get a comment in your HTML output that
indicates the time it took to process that script.
If system debugging is set with Debug -1 or -2, you will also get this
time in the Apache error log with the other system messages.
Mail Administration
Apache::ASP has some powerful administrative email extensions that let
you sleep at night, knowing full well that if an error occurs at the web
site, you will know about it immediately. With these features already
enabled, it was also easy to provide the $Server->Mail(\%mail) API
extension which you can read up about in the OBJECTS section.
MailHost
The mail host is the smtp server that the below Mail* config directives
will use when sending their emails. By default Net::SMTP uses smtp mail
hosts configured in Net::Config, which is set up at install time, but
this setting can be used to override this config.
The mail hosts specified in the Net::Config file will be used as backup
smtp servers to the MailHost specified here, should this primary server
not be working.
PerlSetVar MailHost smtp.yourdomain.com.foobar
MailFrom
Default NONE, set this to specify the default mail address placed in the
From: mail header for the $Server->Mail() API extension, as well as
MailErrorsTo and MailAlertTo.
PerlSetVar MailFrom youremail@yourdomain.com.foobar
MailErrorsTo
No default, if set, ASP server errors, error code 500, that result while
compiling or running scripts under Apache::ASP will automatically be
emailed to the email address set for this config. This allows an
administrator to have a rapid response to user generated server errors
resulting from bugs in production ASP scripts. Other errors, such as 404
not found will be handled by Apache directly.
An easy way to see this config in action is to have an ASP script which
calls a die(), which generates an internal ASP 500 server error.
The Debug config of value 2 and this setting are mutually exclusive, as
Debug 2 is a development setting where errors are displayed in the
browser, and MailErrorsTo is a production setting so that errors are
silently logged and sent via email to the web admin.
PerlSetVar MailErrorsTo youremail@yourdomain.com
MailAlertTo
The address configured will have an email sent on any ASP server error
500, and the message will be short enough to fit on a text based pager.
This config setting would be used to give an administrator a heads up
that a www server error occurred, as opposed to MailErrorsTo would be
used for debugging that server error.
This config does not work when Debug 2 is set, as it is a setting for
use in production only, where Debug 2 is for development use.
PerlSetVar MailAlertTo youremail@yourdomain.com
MailAlertPeriod
Default 20 minutes, this config specifies the time in minutes over which
there may be only one alert email generated by MailAlertTo. The purpose
of MailAlertTo is to give the admin a heads up that there is an error at
the www server. MailErrorsTo is for to aid in speedy debugging of the
incident.
PerlSetVar MailAlertPeriod 20
File Uploads
FileUploadMax
default 0, if set will limit file uploads to this size in bytes. This is
currently implemented by setting $CGI::POST_MAX before handling the file
upload. Prior to this, a developer would have to hardcode a value for
$CGI::POST_MAX to get this to work.
PerlSetVar 100000
FileUploadTemp
default 0, if set will leave a temp file on disk during the request,
which may be helpful for processing by other programs, but is also a
security risk in that other users on the operating system could
potentially read this file while the script is running.
The path to the temp file will be available at $Request-
>{FileUpload}{$form_field}{TempFile}. The regular use of file uploads
remains the same with the <$filehandle> to the upload at $Request-
>{Form}{$form_field}. Please see the CGI section for more information on
file uploads, and the $Request section in OBJECTS.
PerlSetVar FileUploadTemp 0
SYNTAX
General
ASP embedding syntax allows one to embed code in html in 2 simple ways.
The first is the <% xxx %> tag in which xxx is any valid perl code. The
second is <%= xxx %> where xxx is some scalar value that will be
inserted into the html directly. An easy print.
A simple asp page would look like:
For loop incrementing font size:
<% for(1..5) { %>
Size = <%=$_%>
<% } %>
Notice that your perl code blocks can span any html. The for loop above
iterates over the html without any special syntax.
XMLSubs
XMLSubs allows a developer to define custom handlers for HTML & XML
tags, which can extend the natural syntax of the ASP environment.
Configured like:
PerlSetVar XMLSubsMatch site:\w+
A simple tag like:
can be constructed that could translate into:
sub site::header {
my $args = shift;
print "
$args->{title}\n";
print "\n";
}
Better yet, one can use this functionality to trap and post process
embedded HTML & XML like:
... some HTML here ...
and then:
sub site::page {
my($args, $html) = @_;
&site::header($args);
$main::Response->Write($html);
$main::Response->Write("");
}
Though this could be used to fully render XML documents, it was not
built for this purpose, but to add powerful tag extensions to HTML
development environments. For full XML rendering, you ought to try an
XSLT approach, also supported by Apache::ASP.
Editors
As Apache::ASP supports a mixing of perl and HTML, any editor which
supports development of one or the other would work well. The following
editors are known to work well for developing Apache::ASP web sites:
* Emacs, in perl or HTML modes. For a mmm-mode config
that mixes HTML & perl modes in a single buffer, check
out the editors/mmm-asp-perl.el file in distribution.
* Microsoft Frontpage
* Vim, special syntax support with editors/aasp.vim file in distribution.
* UltraEdit32 ( http://www.ultraedit.com/ ) has syntax highlighting,
good macros and a configurable wordlist (so one can have syntax
highlighting both for Perl and HTML).
Please feel free to suggest your favorite development environment for
this list.
EVENTS
The ASP platform allows developers to create Web Applications. In
fulfillment of real software requirements, ASP allows event-triggered
actions to be taken, which are defined in a global.asa file. The
global.asa file resides in the Global directory, defined as a config
option , and may define the following actions:
Action Event
------ ------
Script_OnStart * Beginning of Script execution
Script_OnEnd * End of Script execution
Script_OnFlush * Before $Response being flushed to client.
Application_OnStart Beginning of Application
Application_OnEnd End of Application
Session_OnStart Beginning of user Session.
Session_OnEnd End of user Session.
* These are API extensions that are not portable, but were
added because they are incredibly useful
These actions must be defined in the $Global/global.asa file as
subroutines, for example:
sub Session_OnStart {
$Application->{$Session->SessionID()} = started;
}
Sessions are easy to understand. When visiting a page in a web
application, each user has one unique $Session. This session expires,
after which the user will have a new $Session upon revisiting.
A web application starts when the user visits a page in that
application, and has a new $Session created. Right before the first
$Session is created, the $Application is created. When the last user
$Session expires, that $Application expires also.
Script_OnStart & Script_OnEnd
The script events are used to run any code for all scripts in an
application defined by a global.asa. Often, you would like to run the
same code for every script, which you would otherwise have to add by
hand, or add with a file include, but with these events, just add your
code to the global.asa, and it will be run.
There is one caveat. Code in Script_OnEnd is not guaranteed to be run
when $Response->End() is called, since the program execution ends
immediately at this event. To always run critical code, use the API
extension:
$Server->RegisterCleanup()
Session_OnStart
Triggered by the beginning of a user's session, Session_OnStart gets run
before the user's executing script, and if the same session recently
timed out, after the session's triggered Session_OnEnd.
The Session_OnStart is particularly useful for caching database data,
and avoids having the caching handled by clumsy code inserted into each
script being executed.
Session_OnEnd
Triggered by a user session ending, Session_OnEnd can be useful for
cleaning up and analyzing user data accumulated during a session.
Sessions end when the session timeout expires, and the StateManager
performs session cleanup. The timing of the Session_OnEnd does not occur
immediately after the session times out, but when the first script runs
after the session expires, and the StateManager allows for that session
to be cleaned up.
So on a busy site with default SessionTimeout (20 minutes) and
StateManager (10 times) settings, the Session_OnEnd for a particular
session should be run near 22 minutes past the last activity that
Session saw. A site infrequently visited will only have the
Session_OnEnd run when a subsequent visit occurs, and theoretically the
last session of an application ever run will never have its
Session_OnEnd run.
Thus I would not put anything mission-critical in the Session_OnEnd,
just stuff that would be nice to run whenever it gets run.
Script_OnFlush
API extension. This event will be called prior to flushing the $Response
buffer to the web client. At this time, the $Response->{BinaryRef}
buffer reference may be used to modify the buffered output at runtime to
apply global changes to scripts output without having to modify all the
scripts.
sub Script_OnFlush {
my $ref = $Response->{BinaryRef};
$$ref =~ s/\s+/ /sg; # to strip extra white space
}
Check out the ./site/eg/global.asa for an example of its use.
Application_OnStart
This event marks the beginning of an ASP application, and is run just
before the Session_OnStart of the first Session of an application. This
event is useful to load up $Application with data that will be used in
all user sessions.
Application_OnEnd
The end of the application is marked by this event, which is run after
the last user session has timed out for a given ASP application.
OBJECTS
The beauty of the ASP Object Model is that it takes the burden of CGI
and Session Management off the developer, and puts them in objects
accessible from any ASP script & include. For the perl programmer, treat
these objects as globals accessible from anywhere in your ASP
application.
The Apache::ASP object model supports the following:
Object Function
------ --------
$Session - user session state
$Response - output to browser
$Request - input from browser
$Application - application state
$Server - general methods
These objects, and their methods are further defined in the following
sections.
If you would like to define your own global objects for use in your
scripts and includes, you can initialize them in the global.asa
Script_OnStart like:
use vars qw( $Form $Site ); # declare globals
sub Script_OnStart {
$Site = My::Site->new; # init $Site object
$Form = $Request->Form; # alias form data
$Server->RegisterCleanup(sub { # garbage collection
$Site->DESTROY;
$Site = $Form = undef;
});
}
In this way you can create site wide application objects and simple
aliases for common functions.
$Session Object
The $Session object keeps track of user and web client state, in a
persistent manner, making it relatively easy to develop web
applications. The $Session state is stored across HTTP connections, in
database files in the Global or StateDir directories, and will persist
across web server restarts.
The user session is referenced by a 128 bit / 32 byte MD5 hex hashed
cookie, and can be considered secure from session id guessing, or
session hijacking. When a hacker fails to guess a session, the system
times out for a second, and with 2**128 (3.4e38) keys to guess, a hacker
will not be guessing an id any time soon.
If an incoming cookie matches a timed out or non-existent session, a new
session is created with the incoming id. If the id matches a currently
active session, the session is tied to it and returned. This is also
similar to the Microsoft ASP implementation.
The $Session reference is a hash ref, and can be used as such to store
data as in:
$Session->{count}++; # increment count by one
%{$Session} = (); # clear $Session data
The $Session object state is implemented through MLDBM, and a user
should be aware of the limitations of MLDBM. Basically, you can read
complex structures, but not write them, directly:
$data = $Session->{complex}{data}; # Read ok.
$Session->{complex}{data} = $data; # Write NOT ok.
$Session->{complex} = {data => $data}; # Write ok, all at once.
Please see MLDBM for more information on this topic. $Session can also
be used for the following methods and properties:
$Session->{CodePage}
Not implemented. May never be until someone needs it.
$Session->{LCID}
Not implemented. May never be until someone needs it.
$Session->{SessionID}
SessionID property, returns the id for the current session, which is
exchanged between the client and the server as a cookie.
$Session->{Timeout} [= $minutes]
Timeout property, if minutes is being assigned, sets this default
timeout for the user session, else returns the current session
timeout.
If a user session is inactive for the full timeout, the session is
destroyed by the system. No one can access the session after it
times out, and the system garbage collects it eventually.
$Session->Abandon()
The abandon method times out the session immediately. All Session
data is cleared in the process, just as when any session times out.
$Session->Lock()
API extension. If you are about to use $Session for many consecutive
reads or writes, you can improve performance by explicitly locking
$Session, and then unlocking, like:
$Session->Lock();
$Session->{count}++;
$Session->{count}++;
$Session->{count}++;
$Session->UnLock();
This sequence causes $Session to be locked and unlocked only 1 time,
instead of the 6 times that it would be locked otherwise, 2 for each
increment with one to read and one to write.
Because of flushing issues with SDBM_File and DB_File databases,
each lock actually ties fresh to the database, so the performance
savings here can be considerable.
Note that if you have SessionSerialize set, $Session is already
locked for each script invocation automatically, as if you had
called $Session->Lock() in Script_OnStart. Thus you do not need to
worry about $Session locking for performance. Please read the
section on SessionSerialize for more info.
$Session->UnLock()
API Extension. Unlocks the $Session explicitly. If you do not call
this, $Session will be unlocked automatically at the end of the
script.
$Response Object
This object manages the output from the ASP Application and the client
web browser. It does not store state information like the $Session
object but does have a wide array of methods to call.
$Response->{BinaryRef}
API extension. This is a perl reference to the buffered output of
the $Response object, and can be used in the Script_OnFlush
global.asa event to modify the buffered output at runtime to apply
global changes to scripts output without having to modify all the
scripts. These changes take place before content is flushed to the
client web browser.
sub Script_OnFlush {
my $ref = $Response->{BinaryRef};
$$ref =~ s/\s+/ /sg; # to strip extra white space
}
Check out the ./site/eg/global.asa for an example of its use.
$Response->{Buffer}
Default 1, when TRUE sends output from script to client only at the
end of processing the script. When 0, response is not buffered, and
client is sent output as output is generated by the script.
$Response->{CacheControl}
Default "private", when set to public allows proxy servers to cache
the content. This setting controls the value set in the HTTP header
Cache-Control
$Response->{Charset}
This member when set appends itself to the value of the Content-Type
HTTP header. If $Response->{Charset} = 'ISO-LATIN-1' is set, the
corresponding header would look like:
Content-Type: text/html; charset=ISO-LATIN-1
$Response->{Clean} = 0-9;
API extension. Set the Clean level, default 0, on a per script
basis. Clean of 1-9 compresses text/html output. Please see the
Clean config option for more information. This setting may also be
useful even if using compression to obfuscate HTML.
$Response->{ContentType} = "text/html"
Sets the MIME type for the current response being sent to the
client. Sent as an HTTP header.
$Response->{Debug} = 1|0
API extension. Default set to value of Debug config. May be used to
temporarily activate or inactivate $Response->Debug() behavior.
Something like:
{
local $Response->{Debug} = 1;
$Response->Debug($values);
}
maybe be used to always log something. The Debug() method can be
better than AppendToLog() because it will log data in data
structures one level deep, whereas AppendToLog prints just raw
string/scalar values.
$Response->{Expires} = $time
Sends a response header to the client indicating the $time in
SECONDS in which the document should expire. A time of 0 means
immediate expiration. The header generated is a standard HTTP date
like: "Wed, 09 Feb 1994 22:23:32 GMT".
$Response->{ExpiresAbsolute} = $date
Sends a response header to the client with $date being an absolute
time to expire. Formats accepted are all those accepted by
HTTP::Date::str2time(), e.g.
"Wed, 09 Feb 1994 22:23:32 GMT" -- HTTP format
"Tuesday, 08-Feb-94 14:15:29 GMT" -- old rfc850 HTTP format
"08-Feb-94" -- old rfc850 HTTP format
"09 Feb 1994" -- proposed new HTTP format
"Feb 3 1994" -- Unix 'ls -l' format
"Feb 3 17:03" -- Unix 'ls -l' format
$Response->{FormFill} = 0|1
If true, HTML forms generated by the script output will be auto
filled with data from $Request->Form. This feature requires
HTML::FillInForm to be installed. Please see the FormFill CONFIG for
more information.
This setting overrides the FormFill config at runtime for the script
execution only.
$Response->{IsClientConnected}
1 if web client is connected, 0 if not. This value starts set to 1,
and will be updated whenever a $Response->Flush() is called. If
BufferingOn is set, by default $Response->Flush() will only be
called at the end of the HTML output.
$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
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->TrapInclude($file, @args)
Calls $Response->Include() with same arguments as passed to it, but
instead traps the include output buffer and returns it as as a perl
scalar ref. This allows one to postprocess the output buffer before
sending to the client.
my $string_ref = $Response->TrapInclude('file.inc');
$$string_ref =~ s/\s+/ /sg; # squash whitespace like Clean 1
print $$string_ref;
The scalar is returned as a referenece to save on what might be a
large string copy. You may dereference the scalar with the
$$string_ref notation.
$Response->Write($data)
Write output to the HTML page. <%=$data%> syntax is shorthand for a
$Response->Write($data). All final output to the client must at some
point go through this method.
$Request Object
The request object manages the input from the client browser, like
posts, query strings, cookies, etc. Normal return results are values if
an index is specified, or a collection / perl hash ref if no index is
specified. WARNING, the latter property is not supported in ActiveState
PerlScript, so if you use the hashes returned by such a technique, it
will not be portable.
A normal use of this feature would be to iterate through the form
variables in the form hash...
$form = $Request->Form();
for(keys %{$form}) {
$Response->Write("$_: $form->{$_}
\n");
}
Please see the ./site/eg/server_variables.htm asp file for this method
in action.
Note that if a form POST or query string contains duplicate values for a
key, those values will be returned through normal use of the $Request
object:
@values = $Request->Form('key');
but you can also access the internal storage, which is an array
reference like so:
$array_ref = $Request->{Form}{'key'};
@values = @{$array_ref};
Please read the PERLSCRIPT section for more information on how things
like $Request->QueryString() & $Request->Form() behave as collections.
$Request->{TotalBytes}
The amount of data sent by the client in the body of the request,
usually the length of the form data. This is the same value as
$Request->ServerVariables('CONTENT_LENGTH')
$Request->BinaryRead($length)
Returns a scalar whose contents are the first $length bytes of the
form data, or body, sent by the client request. This data is the raw
data sent by the client, without any parsing done on it by
Apache::ASP.
$Request->ClientCertificate()
Not implemented.
$Request->Cookies($name [,$key])
Returns the value of the Cookie with name $name. If a $key is
specified, then a lookup will be done on the cookie as if it were a
query string. So, a cookie set by:
Set-Cookie: test=data1=1&data2=2
would have a value of 2 returned by $Request-
>Cookies('test','data2').
If no name is specified, a hash will be returned of cookie names as
keys and cookie values as values. If the cookie value is a query
string, it will automatically be parsed, and the value will be a
hash reference to these values.
When in doubt, try it out. Remember that unless you set the Expires
attribute of a cookie with $Response->Cookies('cookie', 'Expires',
$xyz), the cookies that you set will only last until you close your
browser, so you may find your self opening & closing your browser a
lot when debugging cookies.
For more information on cookies in ASP, please read $Response-
>Cookies()
$Request->FileUpload($form_field, $key)
API extension. The FileUpload interface to file upload data is
stabilized. The internal representation of the file uploads is a
hash of hashes, one hash per file upload found in the $Request-
>Form() collection. This collection of collections may be queried
through the normal interface like so:
$Request->FileUpload('upload_file', 'ContentType');
$Request->FileUpload('upload_file', 'FileHandle');
$Request->FileUpload('upload_file', 'BrowserFile');
$Request->FileUpload('upload_file', 'Mime-Header');
$Request->FileUpload('upload_file', 'TempFile');
* note that TempFile must be use with the UploadTempFile
configuration setting.
The above represents the old slow collection interface, but like all
collections in Apache::ASP, you can reference the internal hash
representation more easily.
my $fileup = $Request->{FileUpload}{upload_file};
$fileup->{ContentType};
$fileup->{BrowserFile};
$fileup->{FileHandle};
$fileup->{Mime-Header};
$fileup->{TempFile};
$Request->Form($name)
Returns the value of the input of name $name used in a form with
POST method. If $name is not specified, returns a ref to a hash of
all the form data.
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->Config($setting)
API extension. Allows a developer to read the CONFIG settings, like
Global, GlobalPackage, StateDir, etc. Currently implemented as a
wrapper around
Apache->dir_config($setting)
$Server->CreateObject($program_id)
Allows use of ActiveX objects on Win32. This routine returns a
reference to an Win32::OLE object upon success, and nothing upon
failure. It is through this mechanism that a developer can utilize
ADO. The equivalent syntax in VBScript is
Set object = Server.CreateObject(program_id)
For further information, try 'perldoc Win32::OLE' from your favorite
command line.
$Server->Execute($file, @args)
New method from ASP 3.0, this does the same thing as
$Response->Include($file, @args)
and internally is just a wrapper for such. Seems like we had this
important functionality before the IIS/ASP camp!
$Server->GetLastError()
Not implemented, will likely not ever be because this is dependent
on how IIS handles errors and is not relevant in Apache.
$Server->HTMLEncode($string)
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->Mail(\%mail, %smtp_args);
With the Net::SMTP and Net::Config modules installed, which are part
of the perl libnet package, you may use this API extension to send
email. The \%mail hash reference that you pass in must have values
for at least the To, From, and Subject headers, and the Body of the
mail message.
You could send an email like so:
$Server->Mail({
To => 'somebody@yourdomain.com.foobar',
From => 'youremail@yourdomain.com.foobar',
Subject => 'Subject of Email',
Body =>
'Body of message. '.
'You might have a lot to say here!',
Organization => 'Your Organization',
});
Any extra fields specified for the email will be interpreted as
headers for the email, so to send an HTML email, you could set
'Content-Type' => 'text/html' in the above example.
If you have MailFrom configured, this will be the default for the
From header in your email. For more configuration options like the
MailHost setting, check out the CONFIG section.
The return value of this method call will be boolean for success of
the mail being sent.
If you would like to specially configure the Net::SMTP object used
internally, you may set %smtp_args and they will be passed on when
that object is initialized. "perldoc Net::SMTP" for more into on
this topic.
$Server->RegisterCleanup($sub)
non-portable extension
Sets a subroutine reference to be executed after the script ends,
whether normally or abnormally, the latter occurring possibly by the
user hitting the STOP button, or the web server being killed. This
subroutine must be a code reference created like:
$Server->RegisterCleanup(sub { $main::Session->{served}++; });
or
sub served { $main::Session->{served}++; }
$Server->RegisterCleanup(\&served);
The reference to the subroutine passed in will be executed. Though
the subroutine will be executed in anonymous context, instead of the
script, all objects will still be defined in main::*, that you would
reference normally in your script. Output written to $main::Response
will have no affect at this stage, as the request to the www client
has already completed.
Check out the ./site/eg/register_cleanup.asp script for an example
of this routine in action.
$Server->Transfer($file)
New method from ASP 3.0. Transfers control to another script. The
Response buffer will not be cleared automatically, so if you want
this to serve as a faster $Response->Redirect(), you will need to
call $Response->Clear() before calling this method.
This new script will take over current execution and the current
script will not continue to be executed afterwards. It differs from
Execute() because the original script will not pick up where it left
off.
$Server->URLEncode($string)
Returns the URL-escaped version of the string $string. +'s are
substituted in for spaces and special characters are escaped to the
ascii equivalents. Strings encoded in this manner are safe to put in
urls... they are especially useful for encoding data used in a query
string as in:
$data = $Server->URLEncode("test data");
$url = "http://localhost?data=$data";
$url evaluates to http://localhost?data=test+data, and is a
valid URL for use in anchor tags and redirects, etc.
$Server->URL($url, \%params)
Will return a URL with %params serialized into a query string like:
$url = $Server->URL('test.asp', { test => value });
which would give you a URL of test.asp?test=value
Used in conjunction with the SessionQuery* settings, the returned
URL will also have the session id inserted into the query string,
making this a critical part of that method of implementing
cookieless sessions. For more information on that topic please read
on the setting in the CONFIG section, and the SESSIONS section too.
$Server->XSLT($xsl_data_ref, $xml_data_ref)
* NON-PORTABLE ASP EXTENSION *
This method takes scalar refs for XSL and XML data and returns the
XSLT output as a scalar ref like:
my $xslt_data_ref = $Server->XSLT($xsl_data_ref, $xml_data_ref)
The XSLT parser defaults to XML::XSLT, and is configured with the
XSLTParser setting. Please see the CONFIG section for more
information on the setting.
This API was created to allow developers easy XSLT component
rendering without having to render the entire ASP scripts via XSLT.
This will make an easy plugin architecture for those looking to
integrate XML into their existing ASP application frameworks.
At some point, the API will likely take files as arguments, but not
as of the 2.11 release.
SSI
SSI is great! One of the main features of SSI is to include other files
in the script being requested. In Apache::ASP, this is implemented in a
couple ways, the most crucial of which is implemented in the file
include. Formatted as
,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
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
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 config section to let the
.htaccess file in the ./site/eg installation directory do its work.
IMPORTANT (FAQ): Make sure that the web server has write access to that
directory. Usually a
chmod -R 0777 eg
will do the trick :)
SESSIONS
Cookies are used by default for user $Session support ( see OBJECTS ).
In order to track a web user and associate server side data with that
client, the web server sets, and the web client returns a 32 byte
session id identifier cookie. This implementation is very secure and may
be used in secure HTTPS transactions, and made stronger with
SecureSession and ParanoidSession settings (see CONFIG ).
However good cookies are for this kind of persistent state management
between HTTP requests, they have long been under fire for security risks
associated with JavaScript security exploits and privacy abuse by large
data tracking companies.
Because of these reasons, web users will sometimes turn off their
cookies, rendering normal ASP session implementations powerless,
resulting in a new $Session generated every request. This is not good
for ASP style sessions.
Cookieless Sessions
*** See WARNING Below ***
So we now have more ways to track sessions with the SessionQuery* CONFIG
settings, that allow a web developer to embed the session id in URL
query strings when use of cookies is denied. The implementations work
such that if a user has cookies turned on, then cookies will be used,
but for those users with cookies turned off, the session ids will be
parsed into document URLs.
The first and easiest method that a web developer may use to implement
cookieless sessions are with SessionQueryParse* directives which enable
Apache::ASP to the parse the session id into document URLs on the fly.
Because this is resource inefficient, there is also the SessionQuery*
directives that may be used with the $Server->URL($url,\%params) method
to generate custom URLs with the session id in its query string.
To see an example of these cookieless sessions in action, check out the
./site/eg/session_query_parse.asp example.
*** WARNING ***
If you do use these methods, then be VERY CAREFUL of linking offsite
from a page that was accessed with a session id in a query string. This
is because this session id will show up in the HTTP_REFERER logs of the
linked to site, and a malicious hacker could use this information to
compromise the security of your site's $Sessions, even if these are run
under a secure web server.
In order to shake a session id off an HTTP_REFERER for a link taking a
user offsite, you must point that link to a redirect page that will
redirect a user, like so:
<%
# "cross site scripting bug" prevention
my $sanitized_url =
$Server->HTMLEncode($Response->QueryString('OffSiteUrl'));
%>
Redirecting you offsite to
>here...
Because the web browser visits a real page before being redirected with
the tag, the HTTP_REFERER will be set to this page. Just be sure
to not link to this page with a session id in its query string.
Unfortunately a simple $Response->Redirect() will not work here, because
the web browser will keep the HTTP_REFERER of the original web page if
only a normal redirect is used.
XML/XSLT
Custom Tags with XMLSubsMatch
Before XML, there was the need to make HTML markup smarter. Apache::ASP
gives you the ability to have a perl subroutine handle the execution of
any predefined tag, taking the tag descriptors, and the text contained
between, as arguments of the subroutine. This custom tag technology can
be used to extend a web developer's abilities to add dynamic pieces
without having to visibly use <% %> style code entries.
So, lets say that you have a table that you want to insert for an
employee with contact info and the like, you could set up a tag like:
Jane Doe has been here since 1998.
To render it with a custom tag, you would tell the Apache::ASP parser to
render the tag with a subroutine:
PerlSetVar XMLSubsMatch my:employee
Any colons, ':', in the XML custom tag will turn into '::', a perl
package separator, so the my:employee tag would translate to the
my::employee subroutine, or the employee subroutine in the my package.
Then you would create the my::employee subroutine in the my perl package
or whereever like so
sub my::employee {
my($attributes, $body) = @_;
$Response->Include('employee.inc', $attributes, $body);
}
<% my($attributes, $body) = @_; %>
<% for('name', 'last', 'phone') { %>
| <%=ucfirst $_ %>: |
<%= $attributes->{$_} %> |
<% } %>
| <%= $body %> |
The $Response->Include() would then delegate the rendering of the
employee to the employee.inc ASP script include.
Though XML purists would not like this custom tag technology to be
related to XML, the reality is that a careful site engineer could render
full XML documents with this technology, applying all the correct styles
that one might otherwise do with XSLT.
Custom tags defined in this way can be used as XML tags are defined with
both a body and without as it
...
and just
These tags are very powerful in that they can also enclose normal ASP
logic, like:
<% my $birthday = &HTTP::Date::time2str(time - 25 * 86400 * 365); %>
This employee has been online for <%= int(rand()*600)+1 %>
seconds, and was born near <%= $birthday %>.
For an example of this custom XML tagging in action, please check out
the ./site/eg/xml_subs.asp script. Note the one limitation that
currently exists is that tags of the same name may not be used in each
other, but otherwise customs tags may be used in other custom tags.
XSLT Tranformations
XML is good stuff, but what can you use it for? The principle is that by
having data and style separated in XML and XSL files, you can reformat
your data more easily in the future, and you can render your data in
multiple formats, just as easily as for your web site, so you might
render your site to a PDA, or a cell phone just as easily as to a
browser, and all you have to do is set up the right XSL stylesheets to
do the transformation (XSLT).
In the first release of XML/XSLT support, ASP scripts may be the source
of XML data that the XSL file transforms, and the XSL file itself will
be first executed as an ASP script also. The XSLT transformation is
handled by XML::XSLT or XML::Sablotron and you can see an example of it
in action at the ./site/eg/xslt.xml XML script.
To specify a XSL stylesheet, use the setting:
PerlSetVar XSLT template.xsl
where template.xsl could be any file. By default this will XSLT
transform all ASP scripts so configured, but you can separate xml
scripts from the rest with the setting:
PerlSetVar XSLTMatch xml$
where all files with the ending xml would undergo a XSLT transformation.
Note that XSLT depends on the installation of XML::XSLT, which in turn
depends on XML::DOM, and XML::Parser. As of version 2.11, XML::Sablotron
may also be used by setting:
PerlSetVar XSLTParser XML::Sablotron
If you would like to cache XSLT tranformations, which is highly
recommended, just set:
PerlSetVar XSLTCache 1
Please see the Cache settings in the CONFIG section for more about how
to configure the XSLTCache.
Reference OSS Implementations
For their huge ground breaking XML efforts, these other XML OSS projects
need mention:
Cocoon - XML-based web publishing, in Java
http://xml.apache.org/cocoon/
AxKit - XML web publishing with Apache & mod_perl
http://www.axkit.org/
XML::XSLT - Core engine that Apache::ASP uses for XSLT
http://xmlxslt.sourceforge.net/
CGI
CGI has been the standard way of deploying web applications long before
ASP came along. In the CGI gateway world, CGI.pm has been a widely used
module in building CGI applications, and Apache::ASP is compatible with
scripts written with CGI.pm. Also, as of version 2.19, Apache::ASP can
run in standalone CGI mode for the Apache web server without mod_perl
being available. See "Standalone CGI Mode" section below.
Following are some special notes with respect to compatibility with CGI
and CGI.pm. Use of CGI.pm in any of these ways was made possible through
a great amount of work, and is not guaranteed to be portable with other
perl ASP implementations, as other ASP implementations will likely be
more limited.
Standalone CGI Mode, without mod_perl
As of version 2.19, Apache::ASP scripts may be run as standalone CGI
scripts without mod_perl being loaded into Apache. Work to date has
only been done with mod_cgi scripts under Apache on a Unix platform,
and it is unlikely to work under other web servers or Win32
operating systems without further development.
To run the ./site/eg scripts as CGI scripts, you copy the ./site
directory to some location accessible by your web server, in this
example its /usr/local/apache/htdocs/aspcgi, then in your httpd.conf
activate Apache::ASP cgi scripts like so:
Alias /aspcgi/ /usr/local/apache/htdocs/aspcgi/
AddType application/x-httpd-cgi .htm
AddType application/x-httpd-cgi .html
AddType application/x-httpd-cgi .asp
AddType application/x-httpd-cgi .xml
AddType application/x-httpd-cgi .ssi
AllowOverride None
Options +ExecCGI +Indexes
Then copy the cgi/asp script from the distribution into the
installed ./site/eg directory. This is so the CGI execution line at
the top of those scripts will invoke the asp wrapper like so:
#!/usr/local/bin/perl asp
The asp script is a cgi wrapper that sets up the Apache::ASP
environment in lieu of the normal mod_perl handler request. Because
there is no Apache->dir_config() data available under mod_cgi, the
asp script will load a asp.config file that may define a hash
%Config of data for populating the dir_config() data. An example of
a complex asp.config file is at ./site/eg/asp.config
So, a trivial asp.config file might look like:
# asp.config
%Config = (
'Global' => '.',
'StateDir' => '/tmp/aspstate',
'NoState' => 0,
'Debug' => 3,
);
The default for NoState is 1 in CGI mode, so one must set NoState to
0 for objects like $Session & $Application to be defined.
CGI.pm
CGI.pm is a very useful module that aids developers in the building
of these applications, and Apache::ASP has been made to be
compatible with function calls in CGI.pm. Please see cgi.htm in the
./site/eg directory for a sample ASP script written almost entirely
in CGI.
As of version 0.09, use of CGI.pm for both input and output is
seamless when working under Apache::ASP. Thus if you would like to
port existing cgi scripts over to Apache::ASP, all you need to do is
wrap <% %> around the script to get going. This functionality has
been implemented so that developers may have the best of both worlds
when building their web applications.
Query Object Initialization
You may create a CGI.pm $query object like so:
use CGI;
my $query = new CGI;
As of Apache::ASP version 0.09, form input may be read in by CGI.pm
upon initialization. Before, Apache::ASP would consume the form
input when reading into $Request->Form(), but now form input is
cached, and may be used by CGI.pm input routines.
CGI headers
Not only can you use the CGI.pm $query->header() method to put out
headers, but with the CgiHeaders config option set to true, you can
also print "Header: value\n", and add similar lines to the top of
your script, like:
Some-Header: Value
Some-Other: OtherValue
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 you will avoid this problem.
print()ing CGI
CGI is notorious for its print() statements, and the functions in
CGI.pm usually return strings to print(). You can do this under
Apache::ASP, since print just aliases to $Response->Write(). Note
that $| has no affect.
print $query->header();
print $query->start_form();
File Upload
CGI.pm is used for implementing reading the input from file upload.
You may create the file upload form however you wish, and then the
data may be recovered from the file upload by using $Request-
>Form(). Data from a file upload gets written to a file handle, that
may in turn be read from. The original file name that was uploaded
is the name of the file handle.
my $filehandle = $Request->Form('file_upload_field_name');
print $filehandle; # will get you the file name
my $data;
while(read($filehandle, $data, 1024)) {
# data from the uploaded file read into $data
};
Please see the docs on CGI.pm (try perldoc CGI) for more information
on this topic, and ./site/eg/file_upload.asp for an example of its
use.
There is a $Request->FileUpload() API extension that you can use to
get more data about a file upload, so that the following properties
are available for querying:
my $file_upload = $Request->{FileUpload}{upload_field};
$file_upload->{BrowserFile}
$file_upload->{FileHandle}
$file_upload->{ContentType}
# only if FileUploadTemp is set
$file_upload->{TempFile}
# whatever mime headers are sent with the file upload
# just "keys %$file_upload" to find out
$file_upload->{?Mime-Header?}
Please see the $Request section in OBJECTS for more information.
PERLSCRIPT
Much work has been done to bring compatibility with ASP applications
written in PerlScript under IIS. Most of that work revolved around
bringing a Win32::OLE Collection interface to many of the objects in
Apache::ASP, which are natively written as perl hashes.
New as of version 2.05 is new functionality enabled with the
CollectionItem setting, to giver better support to more recent
PerlScript syntax. This seems helpful when porting from an
IIS/PerlScript code base. Please see the CONFIG section for more info.
The following objects in Apache::ASP respond as Collections:
$Application
$Session
$Request->FileUpload *
$Request->FileUpload('upload_file') *
$Request->Form
$Request->QueryString
$Request->Cookies
$Response->Cookies
$Response->Cookies('some_cookie')
* FileUpload API Extensions
And as such may be used with the following syntax, as compared with the
Apache::ASP native calls. Please note the native Apache::ASP interface
is compatible with the deprecated PerlScript interface.
C = PerlScript Compatibility N = Native Apache::ASP
## Collection->Contents($name)
[C] $Application->Contents('XYZ')
[N] $Application->{XYZ}
## Collection->SetProperty($property, $name, $value)
[C] $Application->Contents->SetProperty('Item', 'XYZ', "Fred");
[N] $Application->{XYZ} = "Fred"
## Collection->GetProperty($property, $name)
[C] $Application->Contents->GetProperty('Item', 'XYZ')
[N] $Application->{XYZ}
## Collection->Item($name)
[C] print $Request->QueryString->Item('message'), "
\n\n";
[N] print $Request->{QueryString}{'message'}, "
\n\n";
## Working with Cookies
[C] $Response->SetProperty('Cookies', 'Testing', 'Extra');
[C] $Response->SetProperty('Cookies', 'Testing', {'Path' => '/'});
[C] print $Request->Cookies(Testing) . "
\n";
[N] $Response->{Cookies}{Testing} = {Value => Extra, Path => '/'};
[N] print $Request->{Cookies}{Testing} . "
\n";
Several incompatibilities exist between PerlScript and Apache::ASP:
> Collection->{Count} property has not been implemented.
> VBScript dates may not be used for Expires property of cookies.
> Win32::OLE::in may not be used. Use keys() to iterate over.
> The ->{Item} property does not work, use the ->Item() method.
FAQ
The following are some frequently asked questions about Apache::ASP.
Installation
Examples don't work, I see the ASP script in the browser?
This is most likely that Apache is not configured to execute the
Apache::ASP scripts properly. Check the INSTALL QuickStart section for
more info on how to quickly set up Apache to execute your ASP scripts.
Why do variables retain their values between requests?
Unless scoped by my() or local(), perl variables in mod_perl are treated
as globals, and values set may persist from one request to another. This
can be seen in as simple a script as this:
$counter++;
$Response->Write("
Counter: $counter");
The value for $counter++ will remain between requests. Generally use of
globals in this way is a BAD IDEA, and you can spare yourself many
headaches if do "use strict" perl programming which forces you to
explicity declare globals like:
use vars qw($counter);
You can make all your Apache::ASP scripts strict by default by setting:
PerlSetVar UseStrict 1
Apache errors on the PerlHandler directive ?
You do not have mod_perl correctly installed for Apache. The PerlHandler
directive in Apache *.conf files is an extension enabled by mod_perl and
will not work if mod_perl is not correctly installed.
Common user errors are not doing a 'make install' for mod_perl, which
installs the perl side of mod_perl, and not starting the right httpd
after building it. The latter often occurs when you have an old apache
server without mod_perl, and you have built a new one without copying
over to its proper location.
To get mod_perl, go to http://perl.apache.org
Error: no request object (Apache=SCALAR(0x???????):)
Your Apache + mod_perl build is not working properly, and is likely a
RedHat Linux RPM DSO build. Make sure you statically build your Apache +
mod_perl httpd, recompiled fresh from the sources.
I am getting a tie or MLDBM / state error message, what do I do?
Make sure the web server or you have write access to the eg directory,
or to the directory specified as Global in the config you are using.
Default for Global is the directory the script is in (e.g. '.'), but
should be set to some directory not under the www server document root,
for security reasons, on a production site.
Usually a
chmod -R -0777 eg
will take care of the write access issue for initial testing purposes.
Failing write access being the problem, try upgrading your version of
Data::Dumper and MLDBM, which are the modules used to write the state
files.
Sessions
How can I use $Session to store complex data structures.
Very carefully. Please read the $Session documentation in the OBJECTS
section. You can store very complex objects in $Session, but you have to
understand the limits, and the syntax that must be used to make this
happen.
In particular, stay away from statements that that have more than one
level of indirection on the left side of an assignment like:
$Session->{complex}{object} = $data;
How can I keep search engine spiders from killing the session manager?
If you want to dissallow session creation for certain non web browser
user agents, like search engine spiders, you can use an init handler
like:
PerlInitHandler "sub { $_[0]->dir_config('NoState', 1) }"
This will configure your environment before Apache::ASP executes and
sees the configuration settings. You can use the mod_perl API in this
way to configure Apache::ASP at runtime.
Insecure dependency in eval while running with - T switch ?
If you are running your mod_perl with "PerlTaintCheck On", which is
recommended if you are highly concerned about security issues, you may
get errors like "Insecure dependency ... with - T switch".
Apache::ASP automatically untaints data internally so that you may run
scripts with PerlTaintCheck On, but if you are using state objects like
$Session or $Application, you must also notify MLDBM, which Apache::ASP
uses internally, to also untaint data read from disk, with this setting:
$MLDBM::RemoveTaint = 1;
You could put the above line in your global.asa, which is just like a
perl module, outside any event handlers you define there.
How can I use $Session to store a $dbh database handle ?
You cannot use $Session to store a $dbh handle. This can be awkward for
those coming from the IIS/NT world, where you could store just about
anything in $Session, but this boils down to a difference between
threads vs. processes.
Database handles often have per process file handles open, which cannot
be shared between requests, so though you have stored the $dbh data in
$Session, all the other initializations are not relevant in another
httpd process.
All is not lost! Apache::DBI can be used to cache database connections
on a per process basis, and will work for most cases.
Development
How is database connectivity handled?
Database connectivity is handled through perl's DBI & DBD interfaces.
Please see http://www.symbolstone.org/technology/perl/DBI/ for more
information. In the UNIX world, it seems most databases have cross
platform support in perl.
DBD::ODBC is often your ticket on Win32. On UNIX, commercial vendors
like OpenLink Software (http://www.openlinksw.com/) provide the nuts and
bolts for ODBC.
Database connections can be cached per process with Apache::DBI.
What is the best way to debug an ASP application ?
There are lots of perl-ish tricks to make your life developing and
debugging an ASP application easier. For starters, you will find some
helpful hints by reading the $Response->Debug() API extension, and the
Debug configuration directive.
How are file uploads handled?
Please see the CGI section. File uploads are implemented through CGI.pm
which is loaded at runtime only for this purpose. This is the only time
that CGI.pm will be loaded by Apache::ASP, which implements all other
cgi-ish functionality natively. The rationale for not implementing file
uploads natively is that the extra 100K in memory for CGI.pm shouldn't
be a big deal if you are working with bulky file uploads.
How do I access the ASP Objects in general?
All the ASP objects can be referenced through the main package with the
following notation:
$main::Response->Write("html output");
This notation can be used from anywhere in perl, including routines
registered with $Server->RegisterCleanup().
You use the normal notation in your scripts, includes, and global.asa:
$Response->Write("html output");
Can I print() in ASP?
Yes. You can print() from anywhere in an ASP script as it aliases to the
$Response->Write() method. Using print() is portable with PerlScript
when using Win32::ASP in that environment.
Do I have access to ActiveX objects?
Only under Win32 will developers have access to ActiveX objects through
the perl Win32::OLE interface. This will remain true until there are
free COM ports to the UNIX world. At this time, there is no ActiveX for
the UNIX world.
Can I script in VBScript or JScript ?
Yes, but not with this perl module. For ASP with other scripting
languages besides perl, you will need to go with a commercial vendor in
the UNIX world. ChiliSoft at http://www.chilisoft.com/ has one such
solution. Of course on NT, you get this for free with IIS.
Support and Production
How do I get things I want done?!
If you find a problem with the module, or would like a feature added,
please mail support, as listed in the SUPPORT section, and your needs
will be promptly and seriously considered, then implemented.
What is the state of Apache::ASP? Can I publish a web site on it?
Apache::ASP has been production ready since v.02. Work being done on the
module is on a per need basis, with the goal being to eventually have
the ASP API completed, with full portability to ActiveState PerlScript
and MKS PScript. If you can suggest any changes to facilitate these
goals, your comments are welcome.
TUNING
A little tuning can go a long way, and can make the difference between a
web site that gets by, and a site that screams with speed. With
Apache::ASP, you can easily take a poorly tuned site running at 10
hits/second to 50+ hits/second just with the right configuration.
Documented below are some simple things you can do to make the most of
your site.
For more tips & tricks on tuning Apache and mod_perl, please see the
tuning documents at:
Stas Bekman's mod_perl guide
http://perl.apache.org/guide/
Vivek Khera's mod_perl performance tuning
http://perl.apache.org/tuning/
$Application & $Session State
Use NoState 1 setting if you don't need the $Application or $Session
objects. State objects such as these tie to files on disk and will incur
a performance penalty.
If you need the state objects $Application and $Session, and if running
an OS that caches files in memory, set your "StateDir" directory to a
cached file system. On WinNT, all files may be cached, and you have no
control of this. On Solaris, /tmp is 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. Linux tends
to do a good job caching its file systems, so pick a StateDir for ease
of system administration.
On Win32 systems, where mod_perl requests are serialized, you can freely
use SessionSerialize to make your $Session requests faster, and you can
achieve similar performance benefits for $Application if you call
$Application->Lock() in your global.asa's Script_OnStart.
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.
Low MaxClients
Set your MaxClients low, such that if you have that many httpd servers
running, which will happen on busy site, your system will not start
swapping to disk because of excessive RAM usage. Typical settings are
less than 100 even with 1 gig RAM! To handle more client connections,
look into a dual server, mod_proxy front end.
Precompile Modules
For those modules that your Apache::ASP application uses, make sure that
they are loaded in your sites startup.pl file, or loaded with PerlModule
in your httpd.conf, so that your modules are compiled pre-fork in the
parent httpd.
Precompile Scripts
Precompile your scripts by using the Apache::ASP->Loader() routine
documented below. This will at least save the first user hitting a
script from suffering compile time lag. On UNIX, precompiling scripts
upon server startup allows this code to be shared with forked child www
servers, so you reduce overall memory usage, and use less CPU compiling
scripts for each separate www server process. These savings could be
significant. On 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 argument. If a file,
that file will be compiled. If a directory, that directory will be
recursed, and all files in it whose file name matches $pattern will be
compiled. $pattern defaults to .*, which says that all scripts in a
directory will be compiled by default.
The %config args, are the config options that you want set that affect
compilation. These options include Debug, Global, GlobalPackage,
DynamicIncludes, StatINC, 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:
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,
);
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 (1000's+) of scripts, and limited memory, set NoCache
to 1, so that compiled scripts are not cached in memory. You lose about
10-15% in speed for small scripts, but save at least 10K RAM per cached
script. These numbers are very rough. If you use includes, you can
instead try setting DynamicIncludes to 1, which will share compiled code
for includes between scripts by turning an into a
$Response->Include().
SEE ALSO
perl(1), mod_perl(3), Apache(3), MLDBM(3), HTTP::Date(3), CGI(3),
Win32::OLE(3)
KEYWORDS
Apache, ASP, perl, apache, mod_perl, asp, Active Server Pages, perl,
asp, web application, ASP, session management, Active Server, scripting,
dynamic html, asp, perlscript, Unix, Linux, Solaris, Win32, WinNT, cgi
compatible, asp, response, ASP, request, session, application, server,
Active Server Pages
NOTES
Many thanks to those who helped me make this module a reality. ASP +
Apache, web development could not be better! Kudos go out to:
!! Doug MacEachern, for moral support and of course mod_perl
:) Dariusz Pietrzak for a nice parser optimization.
:) Ime Smits, for his inode patch facilitating cross site code reuse, and
some nice performance enhancements adding another 1-2% speed.
:) Michael Davis, for easier CPAN installation.
:) Brian Wheeler, for keeping up with the Apache::Filter times,
and pulling off filtering ASP->AxKit.
:) Ged Haywood, for his great help on the list & professionally.
:) Vee McMillen, for OSS patience & understanding.
:) Craig Samuel, at LRN, for his faith in open source for his LCEC.
:) Geert Josten, for his wonderful work on XML::XSLT
:) Gerald Richter, for his Embperl, collaboration and competition!
:) Stas Bekman, for his beloved guide, and keeping us all worldly.
:) Matt Sergeant, again, for ever the excellent XML critique.
:) Remi Fasol + Serge Sozonoff who inspired cookieless sessions.
:) Matt Arnold, for the excellent graphics !
:) Adi, who thought to have full admin control over sessions
:) Dmitry Beransky, for sharable web application includes, ASP on the big.
:) Russell Weiss again, for finding the internal session garbage collection
behaving badly with DB_File sensitive i/o flushing requirements.
:) Tony Merc Mobily, inspiring tweaks to compile scripts 10 times faster
:) Paul Linder, who is Mr. Clean... not just the code, its faster too !
Boy was that just the beginning. Work with him later facilitated better
session management and XMLSubsMatch custom tag technology.
:) Russell Weiss, for being every so "strict" about his code.
:) Bill McKinnon, who understands the finer points of running a web site.
:) Richard Rossi, for his need for speed & boldly testing dynamic includes.
:) Greg Stark, for endless enthusiasm, pushing the module to its limits.
:) Marc Spencer, who brainstormed dynamic includes.
:) Doug Silver, for finding most of the bugs.
:) Darren Gibbons, the biggest cookie-monster I have ever known.
:) Ken Williams, for great teamwork bringing full SSI to the table
:) Matt Sergeant, for his great tutorial on PerlScript and love of ASP
:) Jeff Groves, who put a STOP to user stop button woes
:) Alan Sparks, for knowing when size is more important than speed
:) Lincoln Stein, for his blessed CGI.pm module
:) Michael Rothwell, for his love of Session hacking
:) Francesco Pasqualini, for bringing ASP to CGI
:) Bryan Murphy, for being a PerlScript wiz
:) Lupe Christoph, for his immaculate and stubborn testing skills
:) Ryan Whelan, for boldly testing on Unix in the early infancy of ASP
SUPPORT
MAILING LIST ARCHIVE
Try the Apache::ASP mailing list archive first when working through an
issue as others may have had the same question as you, then try the
mod_perl list archives since often problems working with Apache::ASP are
really mod_perl ones.
The Apache::ASP mailing list archives are located at:
http://www.mail-archive.com/asp%40perl.apache.org/
The mod_perl mailing list archives are located at:
http://forum.swarthmore.edu/epigone/modperl
http://www.geocrawler.com/lists/3/web/182/0/
http://www.egroups.com/group/modperl/
EMAIL
Please subscribe to the Apache::ASP mailing list by sending an email to
asp-subscribe@perl.apache.org and send your questions or comments to the
list after your subscription is confirmed.
To unsubscribe from the Apache::ASP mailing list, just send an email to
asp-unsubscribe@perl.apache.org
If you think this is a mod_perl specific issue, you can send your
question to modperl@apache.org
SITES USING
What follows is a list of public sites that are using Apache::ASP. If
you use the software for your site, and would like to show your support
of the software by being listed, please send your URL to me at
joshua@chamas.com and I'll be sure to add it to the list.
Alumni.NET
http://www.alumni.net
Anime Wallpapers dot com
http://www.animewallpapers.com/
Chamas Enterprises Inc.
http://www.chamas.com
Cine.gr
http://www.cine.gr
Condo-Mart Web Service
http://www.condo-mart.com
Direct.it
http://www.direct.it/
Discountclick.com
http://www.discountclick.com/
HCST
http://www.hcst.net
International Telecommunication Union
http://www.itu.int
Integra
http://www.integra.ru/
Internetowa Gielda Samochodowa
http://www.gielda.szczecin.pl
Money FM
http://www.moneyfm.gr
Motorsport.com
http://www.motorsport.com
Multiple Listing Service of Greater Cincinnati
http://www.cincymls.com
NodeWorks - web link monitoring
http://www.nodeworks.com
OnTheWeb Services
http://www.ontheweb.nu
Planet Of Music
http://www.planetofmusic.com
Provillage
http://www.provillage.com
Prices for Antiques
http://www.p4a.com
redhat.com | support
http://www.redhat.com/apps/support/
Samara.RU
http://portal.samara.ru/
Sex Shop Online
http://www.sex.shop.pl
Spotlight
http://www.spotlight.com.au
USCD Electrical & Computer Engineering
http://ece-local.ucsd.edu
Watthai Net Syndey Australia
http://watthai.net
RESOURCES
Here are some important resources listed related to the use of
Apache::ASP for publishing web applications:
mod_perl Apache web module
http://perl.apache.org
mod_perl Guide
http://perl.apache.org/guide/
mod_perl book
http://www.modperl.com
Perl Programming Language
http://www.perl.com
Apache Web Server
http://www.apache.org
PerlMonth Online Magazine
http://www.perlmonth.com
Apache & mod_perl Reference Cards
http://www.refcards.com/
Perl DBI Database Access
http://www.symbolstone.org/technology/perl/DBI/
TODO
There is no specific time frame in which these things will be
implemented. Please let me know if any of these is of particular
interest to you, and I will give it higher priority.
WILL BE DONE
+ Database storage of $Session & $Application, so web clusters
may scale better than the current NFS/CIFS StateDir implementation
allows, maybe via Apache::Session.
MAY BE DONE
+ VBScript, ECMAScript interpreters
+ allow use of Apache::Session for session management
+ BerkeleyDB2 integration for state management, maybe getting
shared memory to work.
+ asp.pl, CGI method of doing asp
+ Dumping state of Apache::ASP during an error, and being
able to go through it with the perl debugger.
+ $Request->ClientCertificate()
CHANGES
+ = improvement; - = bug fix
$VERSION = 2.19; $DATE="7/10/2001";
+update docs in various parts
+added ./make_httpd/build_httpds.sh scripts for quick builds
of apache + mod_perl + mod_ssl
++plain CGI mode available for ASP execution.
cgi/asp script can now be used to execute ASP
scripts in CGI mode. See CGI perldoc section for more info.
The examples in ./site/eg have been set up to run
in cgi mode if desired. Configuration in CGI section
only tested for Apache on Linux.
-Fixed some faulty or out of date docs in XML/XSLT section.
+added t/server_mail.t test for $Server->Mail(), requires
Net::SMTP to be configured properly to succeed.
+Net::SMTP debugging not enabled by Debug 1,2,3 configs,
not only when system debugging is set with Debug -1,-2,-3
However, a Debug param passed to $Server->Mail() will
sucessfully override the Debug -1,-2,-3 setting even
when its Debug => 0
-Check for undef values during stats for inline includes
so we don't trigger unintialized warnings
+Documented ';' may separate many directories in the IncludesDir
setting for creating a more flexible includes search path.
$VERSION = 2.17; $DATE="6/17/2001";
+Added ASP perl mmm-mode subclass and configuration
in editors/mmm-asp-perl.el file for better emacs support.
Updated SYNTAX/Editors documentation.
+Better debugging error message for Debug 2 or 3 settings
for global.asa errors. Limit debug output for lines
preceding rendered script.
-In old inline include mode, there should no longer
be the error "need id for includes" when using
$Response->Include() ... if DynamicIncludes were
enabled, this problem would not have likely occured
anyway. DynamicIncludes are preferrable to use so
that compiled includes can be shared between scripts.
This bug was likely introduced in version 2.11.
-Removed logging from $Response->BinaryWrite() in regular
debug mode 1 or 2. Logging still enabled in system Debug mode, -1 or -2
-Removed other extra system debugging call that is really not
necessary.
$VERSION = 2.15; $DATE="06/12/2001";
-Fix for running under perl 5.6.1 by removing parser optimization
introduced in 2.11.
-Now file upload forms, forms with ENCTYPE="multipart/form-data"
can have multiple check boxes and select items marked for
@params = $Request->Form('param_name') functionality. This
will be demonstrated via the ./site/eg/file_upload.asp example.
$VERSION = 2.11; $DATE="05/29/2001";
+Parser optimization from Dariusz Pietrzak
-work around for global destruction error message for perl 5.6
during install
+$Response->{IsClientConnected} now will be set
correctly with ! $r->connection->aborted after each
$Response->Flush()
+New XSLTParser config which can be set to XML::XSLT or
XML::Sablotron. XML::Sablotron renders 10 times faster,
but differently. XML::XSLT is pure perl, so has wider
platform support than XML::Sablotron. This config affects
both the XSLT config and the $Server->XSLT() method.
+New $Server->XSLT(\$xsl_data, \$xml_data) API which
allows runtime XSLT on components instead of having to process
the entire ASP output as XSLT.
-XSLT support for XML::XSL 0.32. Things broke after .24.
-XSLTCacheSize config no longer supported. Was a bad
Tie::Cache implementation. Should be file based cache
to greatly increases cache hit ratio.
++$Response->Include(), $Response->TrapInclude(),
and $Server->Execute() will all take a scalar ref
or \'asdfdsafa' type code as their first argument to execute
a raw script instead of a script file name. At this time,
compilation of such a script, will not be cached. It is
compiled/executed as an anonymous subroutine and will be freed
when it goes out of scope.
+ -p argument to cgi/asp script to set GlobalPackage
config for static site builds
-pod commenting fix where windows clients are used for
ASP script generation.
+Some nice performance enhancements, thank to submissions from
Ime Smits. Added some 1-2% per request execution speed.
+Added StateDB MLDBM::Sync::SDBM_File support for faster
$Session + $Application than DB_File, yet still overcomes
SDBM_File's 1024 bytes value limitation. Documented in
StateDB config, and added Makefile.PL entry.
+Removed deprecated MD5 use and replace with Digest::MD5 calls
+PerlSetVar InodeNames 1 config which will compile scripts hashed by
their device & inode identifiers, from a stat($file)[0,1] call.
This allows for script directories, the Global directory,
and IncludesDir directories to be symlinked to without
recompiling identical scripts. Likely only works on Unix
systems. Thanks to Ime Smits for this one.
+Streamlined code internally so that includes & scripts were
compiled by same code. This is a baby step toward fusing
include & script code compilation models, leading to being
able to compile bits of scripts on the fly as ASP subs,
and being able to garbage collect ASP code subroutines.
-removed @_ = () in script compilation which would trigger warnings
under PerlWarn being set, thanks for Carl Lipo for reporting this.
-StatINC/StatINCMatch fix for not undeffing compiled includes
and pages in the GlobalPackage namespace
-Create new HTML::FillInForm object for each FormFill
done, to avoid potential bug with multiple forms filled
by same object. Thanks to Jim Pavlick for the tip.
+Added PREREQ_PM to Makefile.PL, so CPAN installation will
pick up the necessary modules correctly, without having
to use Bundle::Apache::ASP, thanks to Michael Davis.
+ > mode for opening lock files, not >>, since its faster
+$Response->Flush() fixed, by giving $| = 1 perl hint
to $r->print() and the rest of the perl sub.
+$Response->{Cookies}{cookie_name}{Expires} = -86400 * 300;
works so negative relative time may be used to expire cookies.
+Count() + Key() Collection class API implementations
+Added editors/aasp.vim VIM syntax file for Apache::ASP,
courtesy of Jon Topper.
++Better line numbering with #line perl pragma. Especially
helps with inline includes. Lots of work here, & integrated
with Debug 2 runtime pretty print debugging.
+$Response->{Debug} member toggles on/off whether
$Response->Debug() is active, overriding the Debug setting
for this purpose. Documented.
-When Filter is on, Content-Length won't be set and compression
won't be used. These things would not work with a filtering
handler after Apache::ASP
$VERSION = 2.09; $DATE="01/30/2001";
+Examples in ./site/eg are now UseStrict friendly.
Also fixed up ./site/eg/ssi_filter.ssi example.
+Auto purge of old stale session group directories, increasing
session manager performance when using Sessions when migrating
to Apache::ASP 2.09+ from older versions.
+SessionQueryParse now works for all $Response->{ContentType}
starting with 'text' ... before just worked with text/html,
now other text formats like wml will work too.
+32 groups instead of 64, better inactive site session group purging.
+Default session-id length back up to 32 hex bytes.
Better security vs. performance, security more important,
especially when performance difference was very little.
+PerlSetVar RequestParams 1 creates $Request->Params
object with combined contents of $Request->QueryString
and $Request->Form
++FormFill feature via HTML::FillInForm. Activate with
$Response->{FormFill} = 1 or PerlSetVar FormFill 1
See site/eg/formfill.asp for example.
++XMLSubs tags of the same name may be embedded in each other
recursively now.
+No umask() use on Win32 as it seems unclear what it would do
+simpler Apache::ASP::State file handle mode of >> when opening
lock file. saves doing a -e $file test.
+AuthServerVariables config to init $Request->ServerVariables
with basic auth data as documented. This used to be default
behavior, but triggers "need AuthName" warnings from recent
versions of Apache when AuthName is not set.
-Renamed Apache::ASP::Loader class to Apache::ASP::Load
as it collided with the Apache::ASP->Loader() function
namespace. Class used internally by Apache::ASP->Loader()
so no public API changed here.
+-Read of POST input for $Request->BinaryRead() even
if its not from a form. Only set up $Request->Form
if this is from a form POST.
+faster POST/GET param parsing
$VERSION = 2.07; $DATE="11/26/2000";
-+-+ Session Manager
empty state group directories are not removed, thus alleviating
one potential race condition. This impacted performance
on idle sites severely as there were now 256 directories
to check, so made many performance enhancements to the
session manager. The session manager is built to handle
up to 20,000 client sessions over a 20 minute period. It
will slow the system down as it approaches this capacity.
One such enhancement was session-ids now being 11 bytes long
so that its .lock file is only 16 characters in length.
Supposedly some file systems lookup files 16 characters or
less in a fast hashed lookup. This new session-id has
4.4 x 10^12 possible values. I try to keep this space as
large as possible to prevent a brute force attack.
Another enhancement was to limit the group directories
to 64 by only allowing the session-id prefix to be [0-3][0-f]
instead of [0-f][0-f], checking 64 empty directories on an
idle site takes little time for the session manager, compared
to 256 which felt significant from the client end, especially
on Win32 where requests are serialized.
If upgrading to this version, you would do well to delete
empty StateDir group directories while your site is idle.
Upgrading during an idle time will have a similar effect,
as old Apache::ASP versions would delete empty directories.
-$Application->GetSession($session_id) now creates
an session object that only lasts until the next
invocation of $Application->GetSession(). This is
to avoid opening too many file handles at once,
where each session requires opening a lock file.
+added experimental support for Apache::Filter 1.013
filter_register call
+make test cases for $Response->Include() and
$Response->TrapInclude()
+Documented CollectionItem config.
+New $Request->QueryString('multiple args')->Count()
interface implemented for CollectionItem config.
Also $Request->QueryString('multiple args')->Item(1) method.
Note ASP collections start counting at 1.
--fixed race condition, where multiple processes might
try creating the same state directory at the same time, with
one winning, and one generating an error. Now, web process
will recheck for directory existence and error if
it doesn't.
-global.asa compilation will be cached correctly, not
sure when this broke. It was getting reloaded every request.
-StateAllWrite config, when set creates state files
with a+rw or 0666 permissions, and state directories
with a+rwx or 0777 permissions. This allows web servers
running as different users on the same machine to share a
common StateDir config. Also StateGroupWrite config
with perms 0770 and 0660 respectively.
-Apache::ASP->Loader() now won't follow links to
directories when searching for scripts to load.
+New RegisterIncludes config which is on by default only
when using Apache::ASP->Loader(), for compiling includes
when precompiling scripts.
+Apache::ASP::CompileInclude path optimized, which underlies
$Response->Include()
+$Request->QueryString->('foo')->Item() syntax enabled
with CollectionItem config setting. Default syntax
supported is $Request->QueryString('foo') which is
in compatible. Other syntax like $Request->{Form}{foo}
and $Request->Form->Item('foo') will work in either case.
+New fix suggested for missing Apache reference in
Apache::ASP handler startup for RedHat RPMs. Added
to error message.
--Backup flock() unlocking try for QNX will not corrupt the
normal flock() LOCK_UN usage, after trying to unlock a file
that doesn't exist. This bug was uncovered from the below
group deletion race condition that existed.
-Session garbage collection will not delete new group
directories that have just been created but are empty.
There was a race condition where a new group directory would
be created, but then deleted by a garbage collector before
it could be initialized correctly with new state files.
+Better random session-id checksums for $Session creation.
per process srand() initialization, because srand()
may be called once prefork and never called again.
Call without arguments to rely on perl's decent rand
seeding. Then when calling rand() in Secret() we have
enough random data, that even if someone else calls srand()
to something fixed, should not mess things up terribly since
we checksum things like $$ & time, as well as perl memory
references.
+XMLSubs installation make test.
-Fix for multiline arguments for XMLSubs
$VERSION = 2.03; $DATE="08/01/2000";
+License change to GPL. See LICENSE section.
+Setup of www.apache-asp.org site, finally!
-get rid of Apache::ASP->Loader() warning message for perl 5.6.0
$VERSION = 2.01; $DATE="07/22/2000";
+$data_ref = $Response->TrapInclude('file.inc') API
extension which allows for easy post processing of
data from includes
+./site/eg/source.inc syntax highlighting improvements
+XMLSubsMatch compile time parsing performance improvement
$VERSION = 2.00; $DATE="07/15/2000";
-UniquePackages config works again, broke a couple versions back
+better error handling for methods called on $Application
that don't exist, hard to debug before
$VERSION = 1.95; $DATE="07/10/2000";
!!!!! EXAMPLES SECURITY BUG FOUND & FIXED !!!!!
--FIXED: distribution example ./site/eg/source.asp now parses
out special characters of the open() call when reading local
files.
This bug would allow a malicious user possible writing
of files in the same directory as the source.asp script. This
writing exploit would only have effect if the web server user
has write permission on those files.
Similar bug announced by openhack.org for minivend software
in story at:
http://www.zdnet.com/eweek/stories/general/0,11011,2600258,00.html
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-$0 now set to transferred file, when using $Server->Transfer
-Fix for XMLSubsMatch parsing on cases with 2 or more args passed
to tag sub that was standalone like
$VERSION = 1.93; $DATE="07/03/2000";
-sub second timing with Time::HiRes was adding
comments by HTML by default, which would possibly
break specific programs looking for precise HTML output.
Now this behavior must be explicitly turned on with
the TimeHiRes config setting.
These comments will only appear in HTML only if
Debug is enabled as well.
Timed log entries will only occur if
system debugging is enabled, with Debug -1 or -2
$VERSION = 1.91; $DATE="07/02/2000";
+Documented XMLSubsMatch & XSLT* configuration
settings in CONFIG section.
+XSLT XSL template is now first executed as an
ASP script just like the XML scripts. This is
just one step away now from implementing XSP logic.
+$Server->Execute and $Server->Transfer API extensions
implemented. Execute is the same as $Request->Include()
and $Server->Transfer is like an apache internal redirect
but keeps the current ASP objects for the next script.
Added examples, transfer.htm, and modified dynamic_includes.htm.
+Better compile time error debugging with Debug 2 or -2.
Will hilite/link the buggy line for global.asa errors,
include errors, and XML/XSLT errors just like with
ASP scripts before.
+Nice source hiliting when viewing source for the example
scripts.
+Runtime string writing optimization for static HTML going
through $Response.
+New version numbering just like everyone else. Starting at 1.91
since I seem to be off by a factor of 10, last release would have
been 1.9.
$VERSION = 0.19; $DATE="NOT RELEASED";
+XMLSubsMatch and XSLT* settings documented in
the XML/XSLT section of the site/README.
-XMLSubsMatch will strip parens in a pattern match
so it does not interfere with internal matching use.
+XSLT integration allowing XML to be rendered by XSLT
on the fly. XSLT specifies XSL file to transform XML.
XSLTMatch is a regexp that matches XML file names, like \.xml$,
which will be transformed by XSLT setting, default .*
XSLTCacheSize when specified uses Tie::Cache to cached XML DOMs
internally and cache XSLT transformations output per XML/XSL
combination. XML DOM objects can take a lot of RAM, so use
this setting judiciously like setting to 100. Definitely
experiment with this value.
+More client info in the error mail feature, including
client IP, form data, query string, and HTTP_* client headers
+With Time::HiRes loaded, and Debug set to non 0,
will add a
to text/html output, similar to Cocoon, per user request
Will also add this to the system debug error log output
when Debug is < 0
-bug fix on object initialization optimization earlier
in this release, that was introduced for faster event
handler execution.
+Apache::ASP::Parse() takes a file name, scalar, or
scalar ref for arguments of data to parse for greater
integration ability with other applications.
+PodComments optimization, small speed increase at
compilation time.
+String optimization on internal rendering that avoids
unnecessary copying of static html, by using refs. Should
make a small difference on sites with large amounts of
static html.
+CompressGzip setting which, when Compress::Zlib is installed,
will compress text/html automatically going out to the web
browser if the client supports gzip encoding.
++Script_OnFlush event handler, and auxiliary work optimizing
asp events in general. $Response->{BinaryRef} created which
is a reference to outgoing output, which can be used
to modify the data at runtime before it goes out to the client.
+Some code optimizations that boost speed from 22 to 24
hits per second when using Sessions without $Application,
on a simple hello world benchmark on a WinNT PII300.
++Better SessionManagement, more aware of server farms that
don't have reliable NFS locking. The key here is to have only
one process on one server in charge of session garbage collection
at any one time, and try to create this situation with a snazzy
CleanupMaster routine. This is done by having a process register
itself in the internal database with a server key created at
apache start time. If this key gets stale, another process can
become the master, and this period will not exceed the period
SessionTimeout / StateManager.
** Work on session manager sponsored by LRN, http://www.lrn.com. **
** This work was used to deploy a server farm in production with **
** NFS mounted StateDir. Thanks to Craig Samuel for his belief in **
** open source. :) **
Future work for server farm capabilities might include breaking
up the internal database into one of 256 internal databases
hashed by the first 2 chars of the session id. Also on the plate
is Apache::Session like abilities with locking and/or data storage
occuring in a SQL database. The first dbs to be done will include
MySQL & Oracle.
+Better session security which will create a new session id for an
incoming session id that does not match one already seen. This will
help for those with Search engines that have bookmarked
pages with the session ids in the query strings. This breaks away
from standard ASP session id implementation which will automatically
use the session id presented by the browser, now a new session id will
be returned if the presented one is invalid or expired.
-$Application->GetSession will only return a session if
one already existed. It would create one before by default.
+Script_OnFlush global.asa event handler, and $Response->{BinaryRef}
member which is a scalar reference to the content about to be flushed.
See ./site/eg/global.asa for example usage, used in this case to
insert font tags on the fly into the output.
+Highlighting and linking of line error when Debug is set to 2 or -2.
--removed fork() call from flock() backup routine? How did
that get in there? Oh right, testing on Win32. :(
Very painful lesson this one, sorry to whom it may concern.
+$Application->SessionCount support turned off by default
must enable with SessionCount config option. This feature
puts an unnecessary load on busy sites, so not default
behavior now.
++XMLSubsMatch setting that allows the developer to
create custom tags XML style that execute perl subroutines.
See ./site/eg/xml_subs.asp
+MailFrom config option that defaults the From: field for
mails sent via the Mail* configs and $Server->Mail()
+$Server->Mail(\%mail, %smtp_args) API extension
+MailErrorsTo & MailAlertTo now can take comma
separated email addresses for multiple recipients.
-tracking of subroutines defined in scripts and includes so
StatINC won't undefine them when reloading the GlobalPackage,
and so an warning will be logged when another script redefines
the same subroutine name, which has been the bane of at least
a few developers.
-Loader() will now recompile dynamic includes that
have changed, even if main including script has not.
This is useful if you are using Loader() in a
PerlRestartHandler, for reloading scripts when
gracefully restarting apache.
-Apache::ASP used to always set the status to 200 by
default explicitly with $r->status(). This would be
a problem if a script was being used to as a 404
ErrorDocument, because it would always return a 200 error
code, which is just wrong. $Response->{Status} is now
undefined by default and will only be used if set by
the developer.
Note that by default a script will still return a 200 status,
but $Response->{Status} may be used to override this behavior.
+$Server->Config($setting) API extension that allows developer
to access config settings like Global, StateDir, etc., and is a
wrapper around Apache->dir_config($setting)
+Loader() will log the number of scripts
recompiled and the number of scripts checked, instead
of just the number of scripts recompiled, which is
misleading as it reports 0 for child httpds after
a parent fork that used Loader() upon startup.
-Apache::ASP->Loader() would have a bad error if it didn't load
any scripts when given a directory, prints "loaded 0 scripts" now
$VERSION = 0.18; $DATE="02/03/2000";
+Documented SessionQuery* & $Server->URL() and
cleaned up formatting some, as well as redoing
some of the sections ordering for better readability.
Document the cookieless session functionality more
in a new SESSIONS section. Also documented new
FileUpload configs and $Request->FileUpload collection.
Documented StatScripts.
+StatScripts setting which if set to 0 will not reload
includes, global.asa, or scripts when changed.
+FileUpload file handles cleanup at garbage collection
time so developer does not have to worry about lazy coding
and undeffing filehandles used in code. Also set
uploaded filehandles to binmode automatically on Win32
platforms, saving the developer yet more typing.
+FileUploadTemp setting, default 0, if set will leave
a temp file on disk during the request, which may be
helpful for processing by other programs, but is also
a security risk in that others could potentially read
this file while the script is running.
The path to the temp file will be available at
$Request->{FileUpload}{$form_field}{TempFile}.
The regular use of file uploads remains the same
with the <$filehandle> to the upload at
$Request->{Form}{$form_field}.
+FileUploadMax setting, default 0, currently an
alias for $CGI::POST_MAX, which determines the
max size for a file upload in bytes.
+SessionQueryParse only auto parses session-ids
into links when a session-id COOKIE is NOT found.
This feature is only enabled then when a user has
disabled cookies, so the runtime penalty of this
feature won't drag down the whole site, since most
users will have cookies turned on.
-StatINC & StatINCMatch will not undef Fnctl.pm flock
functions constants like O_RDWR, because the code references
are not well trackable. This would result in sporadic 500 server
errors when a changed module was reloaded that imported O_* flock
functions from Fnctl.
+SessionQueryParse & SessionQueryParseMatch
settings that enable auto parsing session ids into
URLs for cookieless sessions. Will pick up URLs in
, ,