Re: mod_perl PerlTransHandler weirdness
just fyi, mod_rewrite should be capable of handling those tests. See the file tests under http://httpd.apache.org/docs-2.1/en/mod/mod_rewrite.html#rewritecond HTH, Aaron On Tue, 2003-06-17 at 08:56, Joel Bernstein wrote: Alternatively, can anybody suggest a different way to offer this functionality? I don't think mod_rewrite applies, since the tests are too complicated, but would stand corrected if somebody knows different... I posted this to london.pm earlier and had no joy. /joel, getting a bit desperate. -- Aaron Ross company . Alias I, Inc mail . 10 East 39th Street New York, NY 10016 email . [EMAIL PROTECTED] phone . 212 696 0690 fax . 212 696 0626 cell . 917 753 2323
mod_perl PerlTransHandler weirdness
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.phpname=david . As I understand it, this needs to run at the URI Translation stage in Apache, which is exposed thru mod_perl via PerlTransHandlers. In the event that the request doesn't match these criteria, it needs to return control to Apache in order that the page gets served as normal (through mod_php). Without the handler in place, this all works, but the /david form doesn't, since there's no code in place to do it. Basically, I have a handler Apache::Publicprofile::Redirector::handler() which is in Apache/Publicprofile/Redirector.pm It is loaded in the site Apache config like: ##begin apache config excerpt## [ inside a VirtualHost block, outside Location block ] PerlModule Apache::Publicprofile::Redirector SetHandler perl-script PerlTransHandler Apache::Publicprofile::Redirector PerlSendHeader Off ##end apache config excerpt## I'm attaching the module, with a slight change to remove the actual webserver details, as requested by the guy whose project this is. I hope the code is self-explanatory, please query any bits that aren't. Currently, the behaviour exhibited is as follows: In any case, regardless of whether the handler is returning OK or DECLINED, Apache tries to serve the *source* of /index.php - ie without running it through mod_php. Is the issue perhaps that PerlTransHandler is the wrong stage to run at? Is it even possible to do what they want to do? FWIW, changing $r-path_info to $r-uri changes from 404 Not Found to 400 Bad Request. It was suggested that path_info may not be available yet by the trans phase. Any help _much_ appreciated - I'm lost here! /joel -- S. Joel Bernstein joel at fysh dot org Apache-Publicprofile-Redirector.pm Description: Perl program
Re: mod_perl PerlTransHandler weirdness
Alternatively, can anybody suggest a different way to offer this functionality? I don't think mod_rewrite applies, since the tests are too complicated, but would stand corrected if somebody knows different... I posted this to london.pm earlier and had no joy. /joel, getting a bit desperate.
Re: mod_perl PerlTransHandler weirdness
On Tue, 2003-06-17 at 13:56, Joel Bernstein wrote: Alternatively, can anybody suggest a different way to offer this functionality? I don't think mod_rewrite applies, since the tests are too complicated, but would stand corrected if somebody knows different... Have you tried moving the index.php out of root into a directory (virtual or otherwise) where all content is passed thru mod_php - can't remember the settings off the top of my head. or you could use an internal redirect so that apache treats the new url as a new request and starts from the beginning of its cycle. hth, A. -- Aaron Trevena, BSc (Hons) --- Software Engineer Tusker Direct :: www.tuskerdirect.com
Re: mod_perl PerlTransHandler weirdness
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.phpname=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.phpname=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
