-----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-----