Re: Why initial location walk?
* William A. Rowe, Jr. wrote: [a lot of explanations about location walks] I'll trace it in the source these days, thanks a lot! (and will ask further if neccessary ;-) nd -- s;.*;aoaaaoaaoaaaom:a:alataa:aaoat:a:a:a maoaa:a:laoata:a:oia:a:o:a:m:a:o:alaoooat:aaool:aaoaa matooololaaatoto:aaa:o:a:o:m;;s:\s:\::g;y;mailto:; \40\51/\134\137|ndparker <[EMAIL PROTECTED]>;;print;
Re: Why initial location walk?
At 10:37 AM 10/18/2002, André Malo wrote: >* Bill Stoddard wrote: > >> There are config directives in 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 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
Re: Why initial location walk?
* Bill Stoddard wrote: > There are config directives in 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 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/ #
RE: Why initial location walk?
> The docs (developer/request.html) say: > > | Every request is subject to an ap_location_walk() call. This ensures > | that | sections are consistently enforced for all > | requests. > > Perhaps a silly question, but I don't understand why that is necessary. There are config directives in blocks that apply to certain URLs. If you do not perform location_walk, you will miss those config directives. Bill
Why initial location walk?
The docs (developer/request.html) say: | Every request is subject to an ap_location_walk() call. This ensures | that | sections are consistently enforced for all | requests. Perhaps a silly question, but I don't understand why that is necessary. AFAICS it returns OK everytime (currently?). Just for creating an inital cache? I hope, someone can enlighten me :) TIA, nd -- Real programmers confuse Christmas and Halloween because DEC 25 = OCT 31. -- Unknown (found in ssl_engine_mutex.c)
Re: Why initial location walk?
At 09:30 PM 10/17/2002, André Malo wrote: >The docs (developer/request.html) say: > >| Every request is subject to an ap_location_walk() call. This ensures >| that | sections are consistently enforced for all >| requests. > >Perhaps a silly question, but I don't understand why that is necessary. >AFAICS it returns OK everytime (currently?). Just for creating an inital >cache? I hope, someone can enlighten me :) All walks begin (and end) with the interpretation of their which overrides any other container-specific configuration (such as the , or or sections.) It essentially suggests that every URI is *MOST* strongly bound to the URI, not the container it resides in. The behavior dates to 1.3 and earlier. Does that answer your question, or can you spell out your questions a bit more clearly? Bill