Using Apache 2.0.43 internal redirects with PHP4.3.0 
either cause a segfault or expose a part of the original 
PHP script.

I have an authentication module in Apache, which checks 
the user access rghts in the ap_hook_auth_checker hook and
diverts the user to an error document if authentication
fails. The Apache module does this:

r->method = apr_pstrdup(r->pool, "GET");
r->method_number = M_GET;
ap_internal_redirect(url, r);
return OK;

If the url of the error document points to a PHP file, 
the error document is processed immediately, as it should
be, but parts of the source text of the original PHP script
that the user tried to access is also sent before Apache
finishes the request.

What happens is that Apache calls the php_output_filter in
sapi_apache2.c first with a brigade that only contains
the error document's filename. This gets processed normally.
Apache then calls the php_output_filter *again* with a
brigade that contains the filename of the original PHP
script (to which access was denied). The output filter 
looks at the ctx->request_processed flag, which is now set,
and passes the brigade to the next filter. Unfortunately, 
for some reason at this stage the ctx->r->handler field 
has been cleared to NULL, which is probably why some other
filter downstream actually delivers the PHP script source 
as text, appended to the original PHP output. The appended
text is not visible in the browser, but easy enough to see
in a packet dump between the client and the server.

If the error document is a HTML file, the same thing 
happens, except in this case apache makes the second call 
to the php_output_filter with ctx->r->handler = NULL and
ctx->request_processed = 0, which means that the filter 
code reaches the strncp() that checks if this is a
php-source request. Since the handler pointer is NULL, the
strncmp call causes a segmentation fault at this point.

For all I know, this whole problem could be caused by an
incorrect use of the ap_internal_redirect call in Apache,
but it may still be a good idea to check that if the PHP
output filter does get called, that there really is a
non-NULL handler field in ctx->r.