-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 14 August 2003 18:20, Geoffrey Young wrote:
> Frank Maas wrote:
> > 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.
well, if a transhandler alters the Uri than maybe MyPackage::handler will not
be called at all, yes. But from the point of view at start of the request it
would be called.
> 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.
I'm wondering then for what reason that initial merge is done at all if not to
be used during name translation?
well, a translation handler cannot be sure that the $r->dir_config it gets was
really caused by the $r->uri it sees. Further, other handlers in later phases
can get completely different settings.
I've searched the standard modules for /r->uri\s*=/ and found only one
occurence in mod_rewrite with the [PT] flag. I assume the right solution
would be to do another merge based on the new uri if someone alters the uri
during name translation and plans to return DECLINED.
And as for apache 2, there I have found these lines:
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);
}
Torsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/O+VtwicyCTir8T4RAiiEAJ4rtu6tMCVrkho5eP3L3+Yz8NGQ9QCguIUb
oxm9P4ttWWeO0g7/BRb4raQ=
=iiYV
-----END PGP SIGNATURE-----
