Apache-ASP
view release on metacpan or search on metacpan
If you define StatINCMatch, you do not need to define StatINC.
PerlSetVar StatINCMatch .*
StatScripts
default 1, if set to 0, changed scripts, global.asa, and includes will
not be reloaded. Coupled with Apache mod_perl startup and restart
handlers executing Apache::ASP->Loader() for your application this
allows your application to be frozen, and only reloaded on the next
server restart or stop/start.
There are a few advantages for not reloading scripts and modules in
production. First there is a slight performance improvement by not
having to stat() the script, its includes and the global.asa every
request.
From an application deployment standpoint, you also gain the ability to
deploy your application as a snapshot taken when the server starts and
restarts. This provides you with the reassurance that during a
production server update from development sources, you do not have to
worry with sources being used for the wrong libraries and such, while
they are all being copied over.
Finally, though you really should not do this, you can work on a live
production application, with a test server reloading changes, but your
production server does see the changes until you restart or stop/start
it. This saves your public from syntax errors while you are just doing a
quick bug fix.
PerlSetVar StatScripts 1
SoftRedirect
default 0, if true, a $Response->Redirect() does not end the script.
Normally, when a Redirect() is called, the script is ended
automatically. SoftRedirect 1, is a standard way of doing redirects,
allowing for html output after the redirect is specified.
PerlSetVar SoftRedirect 0
Filter
On/Off, default Off. With filtering enabled, you can take advantage of
full server side includes (SSI), implemented through Apache::SSI. SSI is
implemented through this mechanism by using Apache::Filter. A sample
configuration for full SSI with filtering is in the ./site/eg/.htaccess
file, with a relevant example script ./site/eg/ssi_filter.ssi.
You may only use this option with modperl v1.16 or greater installed and
PERL_STACKED_HANDLERS enabled. Filtering may be used in conjunction with
other handlers that are also "filter aware". If in doubt, try building
your mod_perl with
perl Makefile.PL EVERYTHING=1
With filtering through Apache::SSI, you should expect near a a 20%
performance decrease.
PerlSetVar Filter Off
CgiHeaders
default 0. When true, script output that looks like HTTP / CGI headers,
will be added to the HTTP headers of the request. So you could add:
Set-Cookie: test=message
<html>...
to the top of your script, and all the headers preceding a newline
will be added as if with a call to $Response->AddHeader(). This
functionality is here for compatibility with raw cgi scripts,
and those used to this kind of coding.
When set to 0, CgiHeaders style headers will not be parsed from the
script response.
PerlSetVar CgiHeaders 0
Clean
default 0, may be set between 1 and 9. This setting determine how much
text/html output should be compressed. A setting of 1 strips mostly
white space saving usually 10% in output size, at a performance cost of
less than 5%. A setting of 9 goes much further saving anywhere 25% to
50% typically, but with a performance hit of 50%.
This config option is implemented via HTML::Clean. Per script
configuration of this setting is available via the $Response->{Clean}
property, which may also be set between 0 and 9.
PerlSetVar Clean 0
CompressGzip
default 0, if true will gzip compress HTML output on the fly if
Compress::Zlib is installed, and the client browser supports it.
Depending on the HTML being compressed, the client may see a 50% to 90%
reduction in HTML output. I have seen 40K of HTML squeezed down to just
under 6K. This will come at a 5%-20% hit to CPU usage per request
compressed.
Note there are some cases when a browser says it will accept gzip
encoding, but then not render it correctly. This behavior has been seen
with IE5 when set to use a proxy but not using a proxy, and the URL does
not end with a .html or .htm. No work around has yet been found for this
case so use at your own risk.
PerlSetVar CompressGzip 1
FormFill
default 0, if true will auto fill HTML forms with values from
$Request->Form(). This functionality is provided by use of
HTML::FillInForm. For more information please see "perldoc
HTML::FillInForm", and the example ./site/eg/formfill.asp.
This feature can be enabled on a per form basis at runtime with
$Response->{FormFill} = 1
PerlSetVar FormFill 1
TimeHiRes
default 0, if set and Time::HiRes is installed, will do sub second
timing of the time it takes Apache::ASP to process a request. This will
not include the time spent in the session manager, nor modperl or
Apache, and is only a rough approximation at best.
For an example of BinaryWrite, see the binary_write.htm example in
./site/eg/binary_write.htm
Please note that if you are on Win32, you will need to call binmode on a
file handle before reading, if its data is binary.
$Response->Clear()
Erases buffered ASP output.
$Response->Cookies($name, [$key,] $value)
Sets the key or attribute of cookie with name $name to the value $value.
If $key is not defined, the Value of the cookie is set. ASP CookiePath
is assumed to be / in these examples.
$Response->Cookies('name', 'value');
--> Set-Cookie: name=value; path=/
$Response->Cookies("Test", "data1", "test value");
$Response->Cookies("Test", "data2", "more test");
$Response->Cookies(
"Test", "Expires",
&HTTP::Date::time2str(time+86400)
);
$Response->Cookies("Test", "Secure", 1);
$Response->Cookies("Test", "Path", "/");
$Response->Cookies("Test", "Domain", "host.com");
--> Set-Cookie:Test=data1=test%20value&data2=more%20test; \
expires=Fri, 23 Apr 1999 07:19:52 GMT; \
path=/; domain=host.com; secure
The latter use of $key in the cookies not only sets cookie attributes
such as Expires, but also treats the cookie as a hash of key value pairs
which can later be accesses by
$Request->Cookies('Test', 'data1');
$Request->Cookies('Test', 'data2');
Because this is perl, you can (NOT PORTABLE) reference the cookies
directly through hash notation. The same 5 commands above could be
compressed to:
$Response->{Cookies}{Test} =
{
Secure => 1,
Value =>
{
data1 => 'test value',
data2 => 'more test'
},
Expires => 86400, # not portable, see above
Domain => 'host.com',
Path => '/'
};
and the first command would be:
# you don't need to use hash notation when you are only setting
# a simple value
$Response->{Cookies}{'Test Name'} = 'Test Value';
I prefer the hash notation for cookies, as this looks nice, and is quite
perlish. It is here to stay. The Cookie() routine is very complex and
does its best to allow access to the underlying hash structure of the
data. This is the best emulation I could write trying to match the
Collections functionality of cookies in IIS ASP.
For more information on Cookies, please go to the source at
http://home.netscape.com/newsref/std/cookie_spec.html
$Response->Debug(@args)
API Extension. If the Debug config option is set greater than 0, this
routine will write @args out to server error log. refs in @args will be
expanded one level deep, so data in simple data structures like
one-level hash refs and array refs will be displayed. CODE refs like
$Response->Debug(sub { "some value" });
will be executed and their output added to the debug output. This
extension allows the user to tie directly into the debugging
capabilities of this module.
While developing an app on a production server, it is often useful to
have a separate error log for the application to catch debugging output
separately. One way of implementing this is to use the Apache ErrorLog
configuration directive to create a separate error log for a virtual
host.
If you want further debugging support, like stack traces in your code,
consider doing things like:
$Response->Debug( sub { Carp::longmess('debug trace') };
$SIG{__WARN__} = \&Carp::cluck; # then warn() will stack trace
The only way at present to see exactly where in your script an error
occurred is to set the Debug config directive to 2, and match the error
line number to perl script generated from your ASP script.
However, as of version 0.10, the perl script generated from the asp
script should match almost exactly line by line, except in cases of
inlined includes, which add to the text of the original script, pod
comments which are entirely yanked out, and <% # comment %> style
comments which have a \n added to them so they still work.
If you would like to see the HTML preceding an error while developing,
consider setting the BufferingOn config directive to 0.
$Response->End()
Sends result to client, and immediately exits script. Automatically
called at end of script, if not already called.
$Response->ErrorDocument($code, $uri)
API extension that allows for the modification the Apache ErrorDocument
at runtime. $uri may be a on site document, off site URL, or string
containing the error message.
This extension is useful if you want to have scripts set error codes
with $Response->{Status} like 401 for authentication failure, and to
then control from the script what the error message looks like.
For more information on the Apache ErrorDocument mechanism, please see
ErrorDocument in the CORE Apache settings, and the
Apache->custom_response() API, for which this method is a wrapper.
$Response->Flush()
Sends buffered output to client and clears buffer.
$Response->Include($filename, @args)
This API extension calls the routine compiled from asp script in
$filename with the args @args. This is a direct translation of the SSI
tag
<!--#include file=$filename args=@args-->
Please see the SSI section for more on SSI in general.
This API extension was created to allow greater modularization of code
by allowing includes to be called with runtime arguments. Files included
are compiled once, and the anonymous code ref from that compilation is
cached, thus including a file in this manner is just like calling a perl
subroutine. The @args can be found in @_ in the includes like:
# include.inc
<% my @args = @_; %>
As of 2.23, multiple return values can be returned from an include like:
my @rv = $Response->Include($filename, @args);
$Response->Include(\%cache_args, @sub_args) *CACHE API*
As of version 2.23, output from an include may be cached with this API
and the CONFIG settings CacheDir & CacheDB. This can be used to execute
expensive includes only rarely where applicable, drastically increasing
performance in some cases.
This API extension applies to the entire include family:
my @rv = $Response->Include(\%cache_args, @include_args)
my $html_ref = $Response->TrapInclude(\%cache_args, @include_args)
$Server->Execute(\%cache_args, @include_args)
For this output cache to work, you must load Apache::ASP in the Apache
parent httpd like so:
# httpd.conf
PerlModule Apache::ASP
The cache arguments are shown here
$Response->Include({
File => 'file.inc',
Cache => 1, # to activate cache layer
Expires => 3600, # to expire in one hour
LastModified => time() - 600, # to expire if cached before 10 minutes ago
Key => $Request->Form, # to cache based on checksum of serialized form data,
Clear => 1, # always executes include & cache output
}, @include_args);
File - include file to execute, can be file name or \$script
## Collection->Contents($name)
[C] $Application->Contents('XYZ')
[N] $Application->{XYZ}
## Collection->SetProperty($property, $name, $value)
[C] $Application->Contents->SetProperty('Item', 'XYZ', "Fred");
[N] $Application->{XYZ} = "Fred"
## Collection->GetProperty($property, $name)
[C] $Application->Contents->GetProperty('Item', 'XYZ')
[N] $Application->{XYZ}
## Collection->Item($name)
[C] print $Request->QueryString->Item('message'), "<br>\n\n";
[N] print $Request->{QueryString}{'message'}, "<br>\n\n";
## Working with Cookies
[C] $Response->SetProperty('Cookies', 'Testing', 'Extra');
[C] $Response->SetProperty('Cookies', 'Testing', {'Path' => '/'});
[C] print $Request->Cookies(Testing) . "<br>\n";
[N] $Response->{Cookies}{Testing} = {Value => Extra, Path => '/'};
[N] print $Request->{Cookies}{Testing} . "<br>\n";
Several incompatibilities exist between PerlScript and Apache::ASP:
> Collection->{Count} property has not been implemented.
> VBScript dates may not be used for Expires property of cookies.
> Win32::OLE::in may not be used. Use keys() to iterate over.
> The ->{Item} property does not work, use the ->Item() method.
STYLE GUIDE
Here are some general style guidelines. Treat these as tips for best
practices on Apache::ASP development if you will.
UseStrict
One of perl's blessings is also its bane, variables do not need to be
declared, and are by default globally scoped. The problem with this in
mod_perl is that global variables persist from one request to another even
if a different web browser is viewing a page.
To avoid this problem, perl programmers have often been advised to add to
the top of their perl scripts:
use strict;
In Apache::ASP, you can do this better by setting:
PerlSetVar UseStrict 1
which will cover both script & global.asa compilation and will catch "use
strict" errors correctly. For perl modules, please continue to add "use
strict" to the top of them.
Because its so essential in catching hard to find errors, this configuration
will likely become the default in some future release. For now, keep setting
it.
Do not define subroutines in scripts.
DO NOT add subroutine declarations in scripts. Apache::ASP is optimized by
compiling a script into a subroutine for faster future invocation. Adding a
subroutine definition to a script then looks like this to the compiler:
sub page_script_sub {
...
... some HTML ...
...
sub your_sub {
...
}
...
}
The biggest problem with subroutines defined in subroutines is the side
effect of creating closures, which will not behave as usually desired in a
mod_perl environment. To understand more about closures, please read up on
them & "Nested Subroutines" at:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html
Instead of defining subroutines in scripts, you may add them to your sites
global.asa, or you may create a perl package or module to share with your
scripts. For more on perl objects & modules, please see:
http://perldoc.perl.org/perlobj.html
Use global.asa's Script_On* Events
Chances are that you will find yourself doing the same thing repeatedly in
each of your web application's scripts. You can use Script_OnStart and
Script_OnEnd to automate these routine tasks. These events are called before
and after each script request.
For example, let's say you have a header & footer you would like to include
in the output of every page, then you might:
# global.asa
sub Script_OnStart {
$Response->Include('header.inc');
}
sub Script_OnEnd {
$Response->Include('footer.inc');
}
Or let's say you want to initialize a global database connection for use in
your scripts:
# global.asa
use Apache::DBI; # automatic persistent database connections
use DBI;
use vars qw($dbh); # declare global $dbh
sub Script_OnStart {
# initialize $dbh
$dbh = DBI->connect(...);
# force you to explicitly commit when you want to save data
$Server->RegisterCleanup(sub { $dbh->rollback; });
}
sub Script_OnEnd {
# not really necessary when using persistent connections, but
$Response->Include($file, @args);
$Response->End();
added test case at t/server_transfer.t
+ Removed dependency of StatINC functionality on Apache::Symbol. Apache::Symbol
is no longer required. Added test of t/stat_inc.t for correct StatINC initialization
for platforms where Devel::Symdump is present.
+ Better error message when $Request->Params has not been defined with RequestParams
config & it gets used in script. Added test case as t/request_params_none.t
+ Directories cannot now be included as scripts via $Response->Include(), added
test case to t/include.t
- No longer make $Response->Flush dependent on $Response->IsClientConnected() to
be true to write output to client. There have been spurious errors reported
about the new ( >= 2.25 ) IsClientConnected code, and this will limit the impact
of that functionality possibly not working still to those users explicitly using
that API.
+ $Response->AddHeader($header_name, $value) now will set $Response members
for these headers: Content-Type, Cache-Control, Expires. This is to avoid
both the application & Apache::ASP sending out duplicate headers. Added
test cases for this to t/response.t
+ split up Bundle::Apache::ASP into that, and Bundle::Apache::ASP::Extra
the former with just the required modules to run, and the latter
for extra functionality in Apache::ASP
+ new $Request->{Method} member to return $r->method of GET or POST that
client browser is requesting, added t/request.t sub test to cover this member.
$VERSION = 2.29; $DATE="11/19/2001";
+Added some extra help text to the ./cgi/asp --help message
to clarify how to pass arguments to a script from the command line.
+When using $Server->Mail() API, if Content-Type header is set,
and MIME-Version is not, then a "MIME-Version: 1.0" header will be sent
for the email. This is correct according to RFC 1521 which specifies
for the first time the Content-Type: header for email documents.
Thanks to Philip Mak for pointing out this correct behavior.
+Made dependent on MLDBM::Sync version .25 to pass the taint_check.t test
+Improved server_mail.t test to work with mail servers were relaying is denied
+Added <html><body> tags to MailErrorsTo email
--Fixed SessionCount / Session_OnEnd bug, where these things were not
working for $Sessions that never had anything written to them.
This bug was introduced in 2.23/2.25 release.
There was an optimization in 2.23/2.25 where a $Session that was never
used does not write its state lock file & dbm files to disk, only if
it gets written too like $Session->{MARK}++. Tracking of these NULL $Sessions
then is handled solely in the internal database. For $Session garbage
collection though which would fire Session_OnEnd events and update
SessionCount, the Apache::ASP::State->GroupMembers() function was just
looking for state files on disk ... now it looks in the internal database
too for SessionID records for garbage collection.
Added a test at ./t/session_events.t for these things.
+Some optimizations for $Session API use.
+Added support for XSLT via XML::LibXSLT, patch courtesy of Michael Buschauer
-Got rid of an warning when recompiling changing includes under perl 5.6.1...
undef($code) method did not work for this perl version, rather undef(&$code) does.
Stopped using using Apache::Symbol for this when available.
-Make Apache::ASP script run under perl taint checking -T for perl 5.6.1...
$code =~ tr///; does not work to untaint here, so much use the slower:
$code =~ /^(.*)$/s; $code = $1; method to untaint.
-Check for inline includes changing, included in a dynamic included
loaded at runtime via $Response->Include(). Added test case for
this at t/include_change.t. If an inline include of a dynamic include
changes, the dynamic include should get recompiled now.
-Make OK to use again with PerlTaintCheck On, with MLDBM::Sync 2.25.
Fixed in ASP.pm, t/global.asa, and created new t/taint_check.t test script
+Load more modules when Apache::ASP is loaded so parent will share more
with children httpd:
Apache::Symbol
Devel::Symdump
Config
lib
MLDBM::Sync::SDBM_File
+When FileUploadMax bytes is exceeded for a file upload, there will not
be an odd error anymore resulting from $CGI::POST_MAX being triggered,
instead the file upload input will simply be ignored via $CGI::DISABLE_UPLOADS.
This gives the developer the opportunity to tell the user the the file upload
was too big, as demonstrated by the ./site/eg/file_upload.asp example.
To not let the web client POST a lot of data to your scripts as a form
of a denial of service attack use the apache config LimitRequestBody for the
max limits. You can think of PerlSetVar FileUploadMax as a soft limit, and
apache's LimitRequestBody as a hard limit.
--Under certain circumstances with file upload, it seems that IsClientConnected()
would return an aborted client value from $r->connection->aborted, so
the buffer output data would not be flushed to the client, and
the HTML page would return to the browser empty. This would be under
normal file upload use. One work-around was to make sure to initialize
the $Request object before $Response->IsClientConnected is called,
then $r->connection->aborted returns the right value.
This problem was probably introduced with IsClientConnected() code changes
starting in the 2.25 release.
$VERSION = 2.27; $DATE="10/31/2001";
+ Wrapped call to $r->connection->fileno in eval {} so to
preserve backwards compatibility with older mod_perl versions
that do not have this method defined. Thanks to Helmut Zeilinger
for catching this.
around many read/writes, you will increase performance.
+Added StateCache config which, if set will cache
the file handle locks for $Application and an internal
database used for tracking $Session info. This caching can
make an ASP application perform up to 10% faster,
at a cost of each web server process holding 2 more
cached file handles open, per ASP application using
this configuration. The data written to or read from
these state databases is not cached, just the locking
file handles are held open.
-Added in much more locking in session manager
and session garbage collector to help avoid collisions
between the two. There were definite windows that the
two would collide in, during which bad things could
happen on a high volume site.
-Fixed some warnings in DESTROY and ParseParams()
$VERSION = 0.14; $DATE="07/29/1999";
-CGI & StatINC or StatINCMatch would have bad results
at times, with StatINC deleting dynamically compiled
CGI subroutines, that were imported into other scripts
and modules namespaces.
A couple tweaks, and now StatINC & CGI play nice again ;)
StatINCMatch should be safe to use in production with CGI.
This affects in particular environments that use file upload,
since CGI is loaded automatically by Apache::ASP to handle
file uploads.
This fix should also affect other seemingly random
times when StatINC or StatINCMatch don't seem to do
the right thing.
+use of ASP objects like $Response are now "use strict"
safe in scripts, while UniquePackages config is set.
+Better handling of "use strict" errors in ASP scripts.
The error is detected, and the developer is pointed to the
Apache error log for the exact error.
The script with "use strict" errors will be recompiled again. Its seems
though that "use strict" will only throw its error once, so that a script
can be recompiled with the same errors, and work w/o any use strict
error messaging.
$VERSION = 0.12; $DATE="07/01/1999";
-Compiles are now 10 +times faster for scripts with lots of big
embedded perl blocks <% #perl %>
Compiles were slow because of an old PerlScript compatibility
parsing trick where $Request->QueryString('hi')->{item}
would be parsed to $Request->QueryString('hi') which works.
I think the regexp that I was using had O(n^2) characteristics
and it took a really big perl block to 10 +seconds to parse
to understand there was a problem :(
I doubt anyone needed this compatibility, I don't even see
any code that looks like this in the online PerlScript examples,
so I've commented out this parsing trick for now. If you
need me to bring back this functionality, it will be in the
form of a config setting.
For information on PerlScript compatibility, see the PerlScript
section in the ASP docs.
-Added UniquePackages config option, that if set brings back
the old method of compiling each ASP script into its own
separate package. As of v.10, scripts are compiled by default
into the same package, so that scripts, dynamic includes & global.asa
can share globals. This BROKE scripts in the same ASP Application
that defined the same sub routines, as their subs would redefine
each other.
UniquePackages has scripts compiled into separate perl packages,
so they may define subs with the same name, w/o fear of overlap.
Under this settings, scripts will not be able to share globals.
-Secure field for cookies in $Response->Cookies() must be TRUE to
force cookie to be secure. Before, it just had to be defined,
which gave wrong behavior for Secure => 0.
+$Response->{IsClientConnected} set to one by default. Will
work out a real value when I upgrade to apache 1.3.6. This
value has no meaning before, as apache aborts the perl code
when a client drops its connection in earlier versions.
+better compile time debugging of dynamic includes, with
Debug 2 setting
+"use strict" friendly handling of compiling dynamic includes
with errors
$VERSION = 0.11; $DATE="06/24/1999";
+Lots of documentation updates
+The MailHost config option is the smtp server used for
relay emails for the Mail* config options.
+MailAlertTo config option used for sending a short administrative
alert for an internal ASP error, server code 500. This is the
compliment to MailErrorsTo, but is suited for sending a to a
small text based pager. The email sent by MailErrorsTo would
then be checked by the web admin for quick response & debugging
for the incident.
The MailAlertPeriod config specifies the time in minutes during
which only one alert will be sent, which defaults to 20.
+MailErrorsTo config options sends the results of a 500 error
to the email address specified as if Debug were set to 2.
If Debug 2 is set, this config will not be on, as it is
for production use only. Debug settings less than 2 only
log errors to the apache server error log.
-StatINCMatch / StatINC can be used in production and work
even after a server graceful restart, which is essential for
a production server.
$VERSION = 0.09; $DATE="04/22/1999";
+Updated Makefile.PL optional modules output for CGI & DB_File
+Improved docs on $Response->Cookies() and $Request->Cookies()
+Added PERFORMANCE doc to main README, and added sub section
on precompiling scripts with Apache::ASP->Loader()
+Naming of CompileIncludes switched over to DynamicIncludes
for greater clarity.
+Dynamic includes can now reference ASP objects like $Session
w/o the $main::* syntax. These subs are no longer anonymous
subs, and are now compiled into the namespace of the global.asa package.
+Apache::ASP->Loader() precompiles dynamic includes too. Making this work
required fixing some subtle bugs / dependencies in the compiling process.
+Added Apache::ASP->Loader() similar to Apache::RegistryLoader for
precompiling ASP scripts. Precompile a whole site at server
startup with one function call.
+Prettied the error messaging with Debug 2.
+$Response->Debug(@args) debugging extension, which
allows a developer to hook into the module's debugging,
and only have @args be written to error_log when Debug is greater
than 0.
-Put write locking code around State writes, like $Session
and $Application. I thought I fixed this bug a while ago.
-API change: converted $Session->Timeout() and $Session->SessionID()
methods into $Session->{Timeout} and $Session->{SessionID} properties.
The use of these properties as methods is deprecated, but
backwards compatibility will remain. Updated ./eg/session.asp
to use these new properties.
+Implemented $Response->{PICS} which if set sends out a PICS-Label
HTTP header, useful for ratings.
+Implemented $Response->{CacheControl} and $Response->{Charset} members.
By default, CacheControl is 'private', and this value gets sent out
every request as HTTP header Cache-Control. Charset appends itself
onto the content type header.
+Implemented $Request->BinaryRead(), $Request->{TotalBytes},
documented them, and updated ./eg/form.asp for an example usage.
+Implemented $Response->BinaryWrite(), documented, and created
and example in ./eg/binary_write.htm
+Implemented $Server->MapPath() and created example of its use
in ./eg/server.htm
-$Request->Form() now reads file uploads correctly with
the latest CGI.pm, where $Request->Form('file_field') returns
the actual file name uploaded, which can be used as a file handle
to read in the data. Before, $Request->Form('file_field') would
return a glob that looks like *Fh::filename, so to get the file
name, you would have to parse it like =~ s/^\*Fh\:\://,
which you no longer have to do. As long as parsing was done as
mentioned, the change should be backwards compatible.
+Updated +enhanced documentation on file uploads. Created extra
comments about it as an FAQ, and under $Response->Form(), the latter
being an obvious place for a developer to look for it.
+Updated ./eg/file_upload.asp to show use of non file form data,
with which we had a bug before.
+Finished retieing *STDIN to cached STDIN contents, so that
CGI input routines may be used transparently, along side with
use of $Request->Form()
+Cleaned up and optimized $Request code
+Updated documentation for CGI input & file uploads. Created
file upload FAQ.
+Reworked ./eg/cgi.htm example to use CGI input routines
after doing a native read of STDIN.
++Added dynamic includes with <!--include file=file args=@args-->
extension. This style of include is compiled as an anonymous sub &
cached, and then executed with @args passed to the subroutine for
execution. This is include may also be rewritten as a new API
extension: $Response->Include('file', @args)
+Added ./eg/compiled_includes.htm example documenting new dynamic includes.
+Documented SSI: native file includes, and the rest with filtering
to Apache::SSI
+Turned the documentation of Filter config to value of Off so
people won't cut and paste the On config by default.
+Added SecureSession config option, which forces session cookie to
be sent only under https secured www page requests.
+Added StateDB config option allows use of DB_File for $Session, since
default use of SDBM_File is limited. See StateDB in README.
+file include syntax w/o quotes supported like <!--#include file=test.inc-->
+Nested includes are supported, with includes including each other.
Recursive includes are detected and errors out when an include has been
included 100 times for a script. Better to quit early than
have a process spin out of control. (PORTABLE ? probably not)
+Allow <!--include file=file.inc--> notation w/o quotes around file names
-PerlSetEnv apache conf setting now get passed through to
$Request->ServerVariables. This update has ServerVariables
getting data from %ENV instead of $r->cgi_env
+README FAQ for PerlHandler errors
$VERSION = 0.08; $DATE="02/06/1999";
++SSI with Apache::Filter & Apache::SSI, see config options & ./eg files
( run in 1.551 second using v1.01-cache-2.11-cpan-39bf76dae61 )