Re: cvs: php4(PHP_4_2_0) /sapi/apache2filter php_apache.h sapi_apache2.c

From: Date: Thu, 11 Apr 2002 20:16:37 +0000
Subject: Re: cvs: php4(PHP_4_2_0) /sapi/apache2filter php_apache.h sapi_apache2.c
References: 1  Groups: php.cvs 
Request: Send a blank email to php-cvs+get-11056@lists.php.net to get a copy of this message
Sorry for the lengthy commit message, this is sort of a big issue. Aparently the ChangeLog is constructed from the commit messages? In the future I'll try to keep these brief. :) -aaron On Thu, Apr 11, 2002 at 07:27:28PM -0000, Aaron Bannert wrote: > aaron Thu Apr 11 15:27:28 2002 EDT > > Modified files: (Branch: PHP_4_2_0) > /php4/sapi/apache2filter php_apache.h sapi_apache2.c > Log: > PHP filters and Apache 2 aren't quite a perfect match yet, so we have > to do some trickery with the server_context to make sure it is always > valid within the current thread. > > This patch makes sure the server_context is created in apache's > post_read_request hook phase, and then registeres a cleanup that > will NULL out the server context when the request goes out of scope. > Then, inside the output filters, if the server_context is null we > throw an error. Finally, instead of saving the output filter in > the server_context, now we store the entire request_rec pointer > in there. > > POST bodies appear to be working now, although they are very inefficient. > The input filter is still just realloc()ing for whatever data comes > down the input pipe, and then sending this to PHP. This means that > we are doing some really nasty memory management on big POST bodies. > For now this it allows for unlimited input bodies, which means that > a big POST could potentially DoS a box by making it run out of memory. > We might want to put a limit on here just in case, at least until > we figure out how to consume input data more efficiently into php.

« previous php.cvs (#11056) next »