Here's a little snippet from a sample script:

package MyApache::MyPackage;

use strict;
use warnings;

use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::DBI;
use APR::Table;
use Apache::Const qw(OK REDIRECT DECLINED);
use Apache::RequestUtil ();

sub handler {

my $r = shift;
my $current_uri = $r->uri;
my $content_type = $r->content_type;
my @fields = split(/\//, $current_uri);


# Let's see if the file exists first


return Apache::DECLINED unless !-e $r->filename;


# other stuff happens past this point but this is enough to document the problem.
}


Here's my the relevant settings in my config file:

 <Location /b>
       PerlSendHeader On
       SetHandler perl-script
       PerlHandler MyApache::MyPackage
 </Location>

OK, so this is set up as a PerlResponseHandler on a virtual server. When the handler is invoked, it loads the page (a php page) but doesn't parse it in PHP before displaying to the browser. I just get back the raw php code. Actually, this is somewhat misleading. On Opera it displays the code. In IE it asks me whether or not I want to download it or open it. When I remove the handler config in the conf files Apache handles it just as it should (it parses the php correctly) but with the handler in there when I go to http://localhost/b/b.php I get.

<?php

print "Hello World";

?>

instead of the actual printing out of "Hello World". Here's the results from a telnet session:

GET /b/b.php HTTP/1.1
Host: localhost

HTTP/1.1 200 OK
Date: Wed, 20 Aug 2003 19:54:02 GMT
Server: Apache/2.0.47 (Unix) mod_perl/1.99_09 Perl/v5.8.0 mod_ssl/2.0.47 OpenSSL/0.9.7a DAV/2 PHP/4.3.2
Last-Modified: Wed, 20 Aug 2003 10:45:31 GMT
ETag: "21c229-3f-ef2ea8c0"
Accept-Ranges: bytes
Content-Length: 63
Content-Type: application/x-httpd-php


<?php

print "Hello World";

?>
Connection closed by foreign host.

When I've telneted into the the machine and called the file directly it seems that the proper content type is being set but in the browser (as mentioned above) IE reports the content-type as blank (there's a null value in the popup box for content-type when it asks me to download or open the file). No errors appear in the log files.

Now, I know it's executing because it actually processes the code below that line which ends in a redirect. But if I try to exit the handler because it's not the correct type of request it seems to mess up the proper handling of php and html files. Image files seem to appear correctly but that may be the browser compensating or reading the encoding type.

Of course, if anybody has an easier suggestion on what I'm trying to do:

I want the document root directory to be handled by the PerlResponseHandler (i.e. Location /). For specific types of requests I would like the above handler to look up some information in the database and return the info dynamically. The only time I don't want that to happen is if the file already exists OR it's pointing to a directory that exists that has a default document type in it (ie index.html or index.php). Everything else I want the handler to do something special with.

So, for instance, if I have the following files:

/index.html
/somefile.html
/somedir/index.html
/somedir/somefile2.html

Any request to:

http://localhost/
http://localhost/index.html
http://localhost/somefile.html
http://localhost/somedir/
http://localhost/somedir/index.html
http://localhost/somedir/somefile2.html

Should all just be handled normally. But if I get a request for:

http://localhost/abc/def/
or
http://localhost/somedir/abcdef

I want the above perl handler to parse the uri and do
something different (directories /abc/def and /abcdef/ would not
actually exist).

TIA for any help on this.

Bill



````````````````````````````````````````
DISCLAIMER: The views expressed by the author of this email may or may not be his/her views, the views of any company s/he represents, or the views of any persons living, dead, or undead. This email message, including any attachments, is for the sole use of the intended recipient(s). If you have received this e-mail in error do not open it. Any errors in facts, spelling, or tact are transmission errors caused by your email client.


http://www.windowsix.com

_________________________________________________________________
<b>Get MSN 8</b> and help protect your children with advanced parental controls. http://join.msn.com/?page=features/parental




--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html



Reply via email to