Joel Bernstein wrote:
Hi,
I would not be surprised if this problem has arisen due to me expecting more from Apache+mod_perl than it's capable of.
The server is running Apache 1.3.mumble with mod_perl and mod_php. The site has been entirely built in PHP, by somebody else. They want the facility for http://foo.bar.com/david to redirect to http://foo.bar.com/?page=publicprofile.php&name=david .
the secret to the PerlTransHandler is this: it is there to make the URI into a file.
so, if you deconstruct the URI to a point where you know which real file you want to serve (at a filesystem level, that is, like /usr/local/apache/htdocs/foo.html) then set $r->filename and return OK.
otherwise, what you want to do is set $r->uri to the relative URI you want Apache to deconstruct and return DECLINED. the default Apache trans handler will then map it to a filename for you. Apache will also take care of directories, non-files (like URIs such as /server-status which do not map to files) and so on.
so, given http://foo.bar.com/?page=publicprofile.php&name=david you might want to really execute http://foo.bar.com/publicprofile.php?name=david, right? so, parse the incoming $uri and set $r->uri to '/publicprofile.php?name=david' and return DECLINED.
now, if publicprofile.php is not running as PHP it means that mod_php is not set up properly - perhaps you not used AddHandler to specify .php files as mod_php scripts, or perhaps have used SetHandler to override the default handler for the <Location> that governs. the way to test this is to request the resulting uri (/publicprofile.php?name=david) and see if it works without your trans handler. once that works, just insert the trans handler and try again.
It was suggested that path_info may not be available yet by the trans phase.
yup. $r->path_info is what is left over from the URI once the URI is mapped to a file or <Location>, so it should be empty until after translation (and possibly empty after as well).
HTH
--Geoff
