From: <[EMAIL PROTECTED]>
Sent: Thursday, August 30, 2001 8:50 PM
> Modified: server request.c
> Log:
> Normalize all paths to run the same, common code for pre-request setup
> from the primary request, redirects and sub-requests.
>
> This will significantly reduce opporunities for inconsistancy (such
> as Ian observed, and as I repaired only a month ago.)
>
> This promotes process_request_internal to an ap_ namespace protected
> entity in server/request.c (from it's old home in http/http_request.c)
> since this fn has no http specifics.
>
> Reviewed (in concept): Cliff Woolley, Ian Holsman
>
> Revision Changes Path
> 1.39 +158 -66 httpd-2.0/server/request.c
>
> +AP_DECLARE(int) ap_process_request_internal(request_rec *r)
...
> + if ((access_status = ap_run_fixups(r)) != 0) {
> + return access_status;
> + }
> +
> + /* The new insert_filter stage makes sense here IMHO. We are sure that
> + * we are going to run the request now, so we may as well insert filters
> + * if any are available. Since the goal of this phase is to allow all
> + * modules to insert a filter if they want to, this filter returns
> + * void. I just can't see any way that this filter can reasonably
> + * fail, either your modules inserts something or it doesn't. rbb
> + */
> + ap_run_insert_filter(r);
Right here is a significant change. I don't know that it's wrong.
If a subrequest is text/plain, and the parent request is text/html - isn't a text->html
converter appropriate here?
This places a burden on a filter author (or user, yuck!) to note that this is a
subrequest.
I don't know that I like this - let's see what the tests reveal.
> + if ((access_status = ap_invoke_handler(r)) != 0) {
> + return access_status;
> + }
> +
> + return OK;
> +}
> +
> +
...
> @@ -1592,7 +1684,7 @@
> {
> int retval;
>
> - /* see comments in process_request_internal() */
> + /* see comments in ap_process_request_internal() */
> ap_run_insert_filter(r);
> retval = ap_invoke_handler(r);
> ap_finalize_sub_req_protocol(r);
WAIT ... this burden always exists. It -appears- that we simply nix this
ap_run_insert_filter
from ap_run_sub_req, and rely on this happening in ap_process_request_internal.
I like this better - it gives the sub_req invoker the chance to do _anything_ to the
subrequest
they feel they should.
Comments?
Bill