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



Reply via email to