* Bill Stoddard wrote:

> There are config directives in <Location> blocks that apply to certain
> URLs. If you do not perform location_walk, you will miss those config
> directives. 

Thank you both; I will try to ask more clearly ;-)

This is the code from server/request.c (shortened):

AP_DECLARE(int) ap_process_request_internal(request_rec *r)
{
    int file_req = (r->main && r->filename);

    /* Ignore embedded %2F's in path for proxy requests */
[...]
    ap_getparents(r->uri);     /* OK --- shrinking transformations... */
[...]

/* initial location walk */

    if (!file_req) {
        if ((access_status = ap_location_walk(r))) {
            return access_status;
        }


        if ((access_status = ap_run_translate_name(r))) {
            return decl_die(access_status, "translate", r);
        }
    }

/* results dropped here */
    r->per_dir_config = r->server->lookup_defaults;

    if ((access_status = ap_run_map_to_storage(r))) {
        /* This request wasn't in storage (e.g. TRACE) */
        return access_status;
    }

/* second location walk (rerun) */
    if (!file_req) {
        if ((access_status = ap_location_walk(r))) {
            return access_status;
        }
    }

I simply try to understand, why the first initial location walk is
neccessary. It does only create a <location> section config cache for
the current request and returns OK everytime (currently?). After running
the translate_name hook the results will be dropped (except for the
cache (?)). Are the results of that inital location walk used anywhere in
the translate name hook or is that intended? 

If the request is a main request it will run always (as far as I can
see) through map_to_storage and then through the second (normal)
location walk. 

What do I overlook here? ;-) Any implications about subrequests or
something? 

Thanks, nd
-- 
Gefunden auf einer "Webdesigner"-Seite:
        > Programmierung in HTML, XML, WML, CGI, FLASH <

# André Malo # http://www.perlig.de/ #

Reply via email to