mod_include broken?

[Rodent of Unusual Size <co...@nephi.zko.dec.com>]

I just tried to compile the latest HEAD, and received some problems against
ap_call_exec.  Most notably, mod_include.c:789 calls it w/o the new
child_info *pinfo argument.  The only other caller of this function seems
to be mod_cgi, which gets the child_info stuff from ap_spawn_child_err_buff.
I'm not in a position to research this further at the moment (maybe to-night),
but I suspect this is a result of the recent Win32 CGI fixes.

mod_include needs to get some child_info stuff to pass to ap_call_exec,
but I don't know from where.

I'm 'waaaay behing on my new-httpd mail, so maybe this is already known.
But just in case..

#ken	P-)}

Re: mod_include broken?

[Randy Terbush <ra...@Covalent.NET>]

I've seen some related warnings in mod_rewrite as well that I will
commit some fixes for later if someone has not beat me to it.

FWIW - I'm also tracking down a problem where IP addresses are getting 
resolved in the logs for certain URLs even if it is explicitly turned
off. I'll post more about this later today.

-Randy


coar@nephi.zko.dec.com (Rodent of Unusual Size) writes:
> I just tried to compile the latest HEAD, and received some problems against
> ap_call_exec.  Most notably, mod_include.c:789 calls it w/o the new
> child_info *pinfo argument.  The only other caller of this function seems
> to be mod_cgi, which gets the child_info stuff from ap_spawn_child_err_buff.
> I'm not in a position to research this further at the moment (maybe to-night),
> but I suspect this is a result of the recent Win32 CGI fixes.
> 
> mod_include needs to get some child_info stuff to pass to ap_call_exec,
> but I don't know from where.
> 
> I'm 'waaaay behing on my new-httpd mail, so maybe this is already known.
> But just in case..
> 
> #ken	P-)}

Re: mod_include broken?

[Ben Laurie <be...@algroup.co.uk>]

Rodent of Unusual Size wrote:
> 
> I just tried to compile the latest HEAD, and received some problems against
> ap_call_exec.  Most notably, mod_include.c:789 calls it w/o the new
> child_info *pinfo argument.  The only other caller of this function seems
> to be mod_cgi, which gets the child_info stuff from ap_spawn_child_err_buff.
> I'm not in a position to research this further at the moment (maybe to-night),
> but I suspect this is a result of the recent Win32 CGI fixes.
> 
> mod_include needs to get some child_info stuff to pass to ap_call_exec,
> but I don't know from where.

Basically, you MUST call ap_spawn_child_err_buff - since children MUST
use Win32 native handles rather than FILE *s or file descriptors. If you
do that, then you get handed a child_info *. However, a short term fix
is to simply pass NULL for the child_info, which is unused on Unix, and
fail to work on Windows.

The requirement to use ap_spawn_child_err_buff is not a consequence of
the particular approach I took, it is a consequence of the buggy MS
libraries, so no amount of rearranging the way the patch works will fix
it.

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|  Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd,     |Apache-SSL author    http://www.apache-ssl.org/
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache