-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 14 August 2003 14:49, Geoffrey Young wrote:
> trans handlers are used to map the URI to a filename, the result of which
> lets Apache know to which <Directory> the URI belongs to. it can also
> affect which <Location> the URI belongs to if that <Location> is paired
> with an Alias directive. trying to make a trans handler <Location>
> specific doesn't really make sense - if you are already in a <Location>
> section then you should already know which file (or lack thereof) you want
> to serve. that's just how Apache works.
Thanks for the explanation. But...
I understand translation handlers cannot be <Directory>-specific. But
<Location> directives apply before any translation handler is called (see
below). Even more I found a note in Apache docs on mod_alias:
"Aliasing occurs before <Directory> sections are checked, so only the
destination of aliases are affected. (Note however <Location> sections are
run through once before aliases are performed, so they will apply.)"
I admit there can be confusion if a translation handler changes r->uri since
<Location> directives are applied again after <Directory> and <File> sections
after the translation handler has returned. But mod_alias doesn't do that. It
sets r->filename and returns OK (and finishs the translation phase).
> > return DECLINED
> > if(grep {$_ eq __PACKAGE__.'::handler'}
> > @{$r->get_handlers('PerlHandler')}); ...
> > }
>
> I don't think that will work the way you desire - the PerlHandler directive
> should not be merged into the current configuration for the request until
> after the trans handler runs, so I wouldn't expect it to be present in
> get_handlers() yet.
But it actually does work, as does Frank's variant (PerlSetVar
SkipTransHandler 1). I've read a little source
(apache_1.3.26/src/main/http_request.c: process_request_internal()):
if ((access_status = location_walk(r))) {
ap_die(access_status, r);
return;
}
if ((access_status = ap_translate_name(r))) {
decl_die(access_status, "translate", r);
return;
}
...
/*
* NB: directory_walk() clears the per_dir_config, so we don't inherit
* from location_walk() above
*/
if ((access_status = directory_walk(r))) {
ap_die(access_status, r);
return;
}
if ((access_status = file_walk(r))) {
ap_die(access_status, r);
return;
}
if ((access_status = location_walk(r))) {
ap_die(access_status, r);
return;
}
as I understand location_walk() applies <Location> sections. It is called just
before the translation handlers (ap_translate_name()). Later on they are
applied again because directory_walk() clears that data. That means it can
lead to confusion if a translation handler changes r->uri a different
<Location> section gets applied.
BTW, the same steps are also performed for subrequests.
Torsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/O51+wicyCTir8T4RAnJmAJ96c1oepdttLD/NsD0RVIfblXfT3ACfepf9
l6APcLfK6u/Mp3un7t5GYYg=
=akE9
-----END PGP SIGNATURE-----
