You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by André Malo <nd...@perlig.de> on 2002/10/18 04:30:53 UTC
Why initial location walk?
The docs (developer/request.html) say:
| Every request is subject to an ap_location_walk() call. This ensures
| that | <Location > 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?
Posted by André Malo <nd...@perlig.de>.
* 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;.*;aaaaaoaaaoaaaaooooaaoaaaomaaaa: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 <nd...@perlig.de>;;print;
Re: Why initial location walk?
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
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
Re: Why initial location walk?
Posted by André Malo <nd...@perlig.de>.
* 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/ #
Re: Why initial location walk?
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
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 | <Location > 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 <Location >
which overrides any other container-specific configuration (such as
the <Proxy>, or <Directory> or <Files> 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
RE: Why initial location walk?
Posted by Bill Stoddard <bi...@wstoddard.com>.
> The docs (developer/request.html) say:
>
> | Every request is subject to an ap_location_walk() call. This ensures
> | that | <Location > 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 <Location> blocks that apply to certain URLs.
If you do not perform location_walk, you will miss those config directives.
Bill