Apache/mod_perl woes...

PsychoSpunk has asked for the wisdom of the Perl Monks concerning the following question:

Okay, so after a month of being diverted from my new project, I finally got some time to play with it today. I set up a <VirtualHost> and began to put things in place. Only now, I'm running into a minor problem. My handler isn't able to get the filename when I issue the $r->path_info command. As a result, TT2 isn't able to process the file.

After reading the relevant portions of the Eagle, I have become disappointed with the fact that it would appear that the path_info method is not working as most people would presume. Maybe I'm just not looking at it correctly.

From my httpd.conf:

<VirtualHost 192.168.0.1:8080>
    DocumentRoot "/usr/local/apache/sites/test/htdocs"
    PerlRequire conf/startup.pl
    PerlFreshRestart On

    PerlModule Apache::TTProc

    <Directory />
        SetHandler perl-script
        PerlHandler Apache::TTProc
    </Directory>

    ErrorLog logs/test-error.log
</VirtualHost>
[download]

Now one might think that if I made a request to http://192.168.0.1:8080/index.html that the $r->path_info would return "/index.html", and that's what one would truly expect. Only, it's not. Here, for all intents and purposes, is what my handler setup is like.

ALL HAIL BRAK!!!

Comment on Apache/mod_perl woes... Select or Download Code

Replies are listed 'Best First'.
Re: Apache/mod_perl woes... by btrott (Parson) on Jan 31, 2001 at 05:01 UTC
I'm not sure exactly of the problem you're having, but I know that in my experience I don't really like using path_info. The path_info is what's left over after the URL->filename translation done by the transhandler (you could, by the way, probably implement your own transhandler to solve some of these issues). Anyway, the translation gets rather confused when you have URLs that you want handled by your custom handler, but when pieces of the URL exist in the filesystem. I don't know if this is what's happening in your case, but it's certainly possible. The solution? For me, I've just switched over to using the uri method of the request object: `my $uri = $r->uri;` [download] From that you can determine which file was requested. The other issue is when your handler root isn't the document root. For example, if you configured your Apache like this: `<Location /bar> PerlHandler MyHandler </Location>` [download] Depending on whether "/bar" is part of the filepath you wish to handle, you may need to strip it out, or not. Make sense? In short: try using uri instead of path_info. And if you start writing a more complex application, look into using a custom PerlTransHandler to do the URL->filename translation.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Apache/mod_perl woes...
by btrott (Parson) on Jan 31, 2001 at 05:01 UTC

Anyway, the translation gets rather confused when you have URLs that you want handled by your custom handler, but when pieces of the URL exist in the filesystem. I don't know if this is what's happening in your case, but it's certainly possible.

The solution? For me, I've just switched over to using the uri method of the request object:

    my $uri = $r->uri;
[download]

    <Location /bar>
        PerlHandler MyHandler
    </Location>
[download]

In short: try using uri instead of path_info. And if you start writing a more complex application, look into using a custom PerlTransHandler to do the URL->filename translation.

[reply]
[d/l]
[select]