httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Non-forking servers (and fun with NCSA 1.4b2)
Date Sat, 01 Apr 1995 17:37:36 GMT
A few weeks ago, in a discussion of non-forking server strategy, I wrote:

   From: (Robert S. Thau)
   Date: Tue, 14 Mar 95 09:15:11 EST

   *) You have to be sure to clear out per-transaction state before
      starting a new transaction.  For instance, you don't want the
      current transaction to be affected by an AddType directive which
      was read out of a .htaccess file the last time around.  This
      involves being very careful with global variables; the current code
      is unfortunately rather careless.  

I didn't see any code to do this in NCSA 1.4b2, so I tried it, and I
*think* I saw the bug --- if an httpd child process comes across an
AddType in a .htaccess file, that AddType seems to affect not only
the transaction where it's first seen, but all subsequent transactions
by that child process as well.  (It helps to set MaxServers to one, so
you're guaranteed to get the same child, while testing for this).

FWIW, my test case was adding "Addtype text/plain cgi" to the
.htaccess file of a test directory --- in subsequent transactions,
GETting /foo.cgi URLs in *other directories* caused the source code
of the scripts to be sent back (instead of the scripts being invoked).

Incidentally, this also makes for a memory leak, if one of the
.htaccess files containing these directives is in a heavily used
directory --- each time through, another "struct mime_ext" gets added
onto the front of forced_types; the space used for all of this could
start to add up after a while.

(More generally, and I'm going out on a limb here, I don't see
anything in the code which cleans up space malloc()ed by a transaction
that calls die(), and winds up longjmp()ing back into child_main() ---
perhaps I've missed something, though.  It wouldn't be the first

So much for toying with it.  Now to get serious ;-).


View raw message