Apache-ASP

 view release on metacpan or  search on metacpan

site/changes.html  view on Meta::CPAN

  in $Application.  Documented.

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

 <b>&#045;&#064;&#097;&#114;&#114;&#097;&#121;</b> context of $Request-&gt;Form(&#39;name&#39;) returns
  undef when value for &#39;name&#39; is undefined.  Put extra
  logic in there to make sure this happens.
</pre></font>
	
	<p>
	<a name=%24VERSION%20%3D%2003dd1597d></a>
	<font face=verdana><font class=title size=+0 color=#555555><b>$VERSION = 0.16; $DATE="09/22/99";</b></font>
<font face="courier new" size=3><pre>
 -$Response-&gt;{Buffer} and PerlSetVar BufferingOn
  configs now work when set to 0, to unbuffer output,
  and send it out to the web client as the script generates it.

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

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

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

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

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

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

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

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

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

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

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

 -MailErrorsTo should report the right file now that generates
  the error.
</pre></font>
	
	<p>
	<a name=%24VERSION%20%3D%200a2fa9027></a>
	<font face=verdana><font class=title size=+0 color=#555555><b>$VERSION = 0.15; $DATE="08/24/1999";</b></font>
<font face="courier new" size=3><pre>
 --State databases like $Session, $Application are 
  now tied/untied to every lock/unlock triggered by read/write 
  access.  This was necessary for correctness issues, so that 
  database file handles are flushed appropriately between writes
  in a highly concurrent multi-process environment.

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

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

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

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

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

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

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

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

 +Updated documentation with new config settings and
  API extensions.

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

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

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

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

 -Fixed some warnings in DESTROY and ParseParams()
</pre></font>
	
	<p>
	<a name=%24VERSION%20%3D%200b667e0c4></a>
	<font face=verdana><font class=title size=+0 color=#555555><b>$VERSION = 0.14; $DATE="07/29/1999";</b></font>
<font face="courier new" size=3><pre>
 -CGI &amp; 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 &amp; 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&#39;t seem to do 
  the right thing.

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

 +Better handling of &quot;use strict&quot; 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 &quot;use strict&quot; errors will be recompiled again.  Its seems 
  though that &quot;use strict&quot; 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.
</pre></font>
	
	<p>
	<a name=%24VERSION%20%3D%200fcc7c76f></a>
	<font face=verdana><font class=title size=+0 color=#555555><b>$VERSION = 0.12; $DATE="07/01/1999";</b></font>
<font face="courier new" size=3><pre>
 -Compiles are now 10 +times faster for scripts with lots of big



( run in 1.169 second using v1.01-cache-2.11-cpan-0b5f733616e )