Mailing List Archive

Non-forking servers (and fun with NCSA 1.4b2)
A few weeks ago, in a discussion of non-forking server strategy, I wrote:

From: rst@ai.mit.edu (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
time).

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

rst
Re: Non-forking servers (and fun with NCSA 1.4b2) [ In reply to ]
Last time, Robert S. Thau uttered the following other thing:
>
> 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).

hmm. No, I didn't add any code for the AddType, because I didn't
think it worked. I tried it, and it didn't seem to work. This
could be because I was in a scriptaliased directory though. I've
got code now to fix it, though. It will also fix the memory leak (
not really a memory leak, since we don't lose the memory, but
we do keep adding it)

> 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
> time).

The code cleans up after itself as it goes along (with init_header_vars,
and elsewhere) so it doesn't clean up after itself in a die (at least,
not completely). It would probably be more efficient that way, but
its a hack.

Brandon

--
Brandon Long (N9WUC) "I think, therefore, I am confused." -- RAW
Computer Engineering Run Linux 1.1.xxx It's that Easy.
University of Illinois blong@uiuc.edu http://www.uiuc.edu/ph/www/blong
Don't worry, these aren't even my views.