Re: cvs: php4(PHP_4_2_0) /sapi/apache2filter php_apache.h sapi_apache2.c
| From: | Aaron Bannert | 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.