Frank Maas wrote:
On Thu, Aug 14, 2003 at 11:07:13AM -0400, Geoffrey Young wrote:
"There is actually a <Location>/<LocationMatch> sequence performed just before the name translation phase (where Aliases and DocumentRoots are used to map URLs to filenames). The results of this sequence are completely thrown away after the translation has completed."
which is what you found in the code - note the "completely thrown away" part. in essence, this means that the results of the <Location> config merging are discarded prior to translation, after which <Location> merging is done again.
Ehm... considering both solutions worked and the quoted paragraph, shouldn't we read it as 'the results of this sequence can be used during
the translation phase, but are thrown away after the translation has
completed'. This would mean that the results are not discarded prior to translation, but after translation and that would also explain why the two solutions work...
well, they can only be used during translation if the URI is unaltered. for instance, given the example we've seen already
PerlTransHandler MyPackage::transhandler <Location ...> PerlHandler MyPackage::handler </Location>
checking get_handlers() in transhandler() only works because the initial merge (which is thrown away) ends up being the same merge as after translation. if any (other) trans handlers meddle with $r->uri (which is perfectly valid) then the initial get_handlers() call will report settings completely different than the end <Location> that is finally applied to the URL.
so, I guess <Location>-specific settings can be used during translation, much in the same way that you can break encapsulation in Perl by simply accessing the object via its underlying hash - the "feature" works currently due to the way things are implemented, but using it is not guaranteed to work in the future (apache 2.0?), and may have unintended consequences in the present. in other words, it's a bad idea and people who know better certainly don't rely on it.
--Geoff
