Further notes regarding subrequests...

[Anthony Wells <aw...@cd-crafters.com>]

I thought you guys might also be interested to note the following:

When a subrequest is created using ap_sub_req_lookup_uri in mod_include, it
inherents all of the input filters of the original request, including apreq
if present.  I find this interesting since the code for
ap_sub_req_lookup_uri states that subrequests don't have input filters but
goes on to set the input filters of the subrequest to that of the main
request anyway.

	rr->input_filters = r->input_filters;
	rr->proto_input_filters = r->proto_input_filters;

Thus, if I don't want my subrequest to use mod_apreq, I have to remove it
from the filter chain before calling ap_run_sub.  However, by adding an
input filter to the subrequest chain before running the request(provided I
specify passpost="true" in my include statement), I can insert data into the
brigade, which is exactly what I do to pass post data to the subrequests.

Also, before destroying the subrequest, I take any headers, mainly cookies,
from rr->headers_out and add them to my main request headers out,
r->headers_out.

I think it's really neat that I can use ".html" files for form actions.  It
will really keep a lot of tech people guessing how my site works.  And, it's
also cool that I can mix and match different handlers, including Java, Perl,
PHP, C, etc... (Not that I would do that!)

Anthony