At 10:37 AM 10/18/2002, André Malo wrote:
>* 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?
Because without the first location walk, the translate name hook doesn't
know -what- it's operating on. The translate name hook is promised the
per-dir-config structures for the URI it's translating.
>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.
Yes - but translate name may have transformed the URI itself. That's
why it must be rerun.
>What do I overlook here? ;-) Any implications about subrequests or
>something?
Yes - because of additive properties like Options, order becomes very
significant. Both walks start with the vhost config (already merged
with the base server config.) But the +/- operations behave in a
somewhat different order. That's why the 'cached' location config
(which isn't recomputed unless the URI changes) isn't merged to
anything ... we do the 'final' merge on the product of the merge
vhost+directory+files, adding location to end up with something
that exactly reflects how the old 1.3 merger worked.
Bill
