:)
You put almost as much effort into this as I, and I have to admit, this
is fairly fustrating, and it is just an old bug, one that should
have been resolved long ago. And I think the bug is in apache, not
mod_perl, but I could be wrong. I was going to, on my next attempt on
this, try recompiling the apache and modperl code with some alterations
but then I discovered that I might not have correct information.
Is it that mod_dir has to run first BEFORE embperl
or does embperl have to run first, which is what
we have been concluding.
I think mod_dir has to run FIRST... why?
Because if you get a directory, it needs to translate it to an html file
FIRST, fetched anded off to embperl and mod_perl.
My regular perl module though needs to go FIRST and then hand off to
mod_dir. Why? Because it is examining the url for nastiness. Once it
is ok, it should hand off to mod_dir... which seems to be what is
broken.
When I run embperl, which will only work with
sethandler perl-script, and never with addhandler: see below
it functions fine until I add the mod_perl module I wrote. So
mod_dir is probably supposed to be sliced between them.
<VirtualHost *:80>
ServerAdmin ru...@mrbrklyn.com
DocumentRoot "/usr/local/apache/htdocs/nylxs"
ServerName www.nylxs.com
DirectoryIndex index.html
PerlModule Embperl
Embperl_UseEnv on
ErrorLog logs/nylxs_error_log
CustomLog logs/nylxs_access_log common
<Directory /usr/local/apache/htdocs/nylxs>
Options Indexes ExecCGI
DirectoryIndex index.html
<Files *.html>
SetHandler perl-script
# PerlResponseHandler URL_BLOCK
PerlHandler Embperl
</Files>
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</Virtualhost>
When I use AddHanlder with my custom mod_perl url module, the mod_dir
stuff works and it seems to handoff to mod_dir correctly
For example:
<VirtualHost *:80>
ServerAdmin ru...@mrbrklyn.com
DocumentRoot "/usr/local/apache/htdocs"
ServerName www.mrbrklyn.com
Options Indexes
AddHandler perl-script *
PerlTransHandler +URL_BLOCK
<Files *.html>
AddHandler perl-script *
PerlHandler Embperl
</Files>
<Location "/resources">
Options +Indexes +FollowSymLinks
</Location>
<Location "/images">
# AddHandler perl-script *
# PerlTransHandler URL_BLOCK
</Location>
<Location "/pharmacy/sales">
Deny from All
</Location>
ErrorLog logs/error_log
CustomLog logs/access_log common
</VirtualHost>
~~~~~~~~~~~~``
Here, embperl silently fails (see http://www.mrbrklyn.com and the
localtime command is visable).
the URL_BLOCK works (try http://www.mrbrklyn.com/////index.html)
mod_dir functions
try: http://www.mrbrklyn.com/images/
On Thu, Sep 18, 2014 at 02:15:43AM -0400, Rick Myers wrote:
> On Wed, Sep 17, 2014 at 09:18:38PM -0400, Ruben Safir wrote:
> > On 09/17/2014 03:08 PM, Rick Myers wrote:
> > > o, just declining from the perl response simply drops you off
> > > into the void since there are no other responses even set up.
> > >
> > > Does that make sense? I hope so. :-)
> >
> >
> > that has been my assessment thusly...
>
> Just for fun, I dusted off the old mod_perl machine and took a stab at
> this.
>
> If I put a new Location section in an existing VirtualHost, I got the
> same sort of result you're seeing. That is, mod_perl above the
> directory, mod_perl below the directory, but a 500 error on the
> directory itself.
>
> The 500 was because it was trying to run the Perl code. And that was
> running Template, which didn't like being handed a directory.
>
> No matter what I did though, I couldn't figure out how to get a
> directory index. I tried Trans, Fixup, MapToStorage, returning OK,
> returning DECLINED - I even read the Fine Manual - all with the same
> result. It insisted on running the Perl code.
>
> Even after I gave up, it still bugged me. I eventually got around to
> setting up a new VirtualHost. Like so...
>
> <VirtualHost *>
>
> ServerName www.example.com
> ServerAlias example.com
> ServerAdmin webmas...@example.com
>
> DocumentRoot /home/dev/perl/lib/Experimental/public
>
> <Directory />
> Order deny,allow
> Deny from all
> Options None
> AllowOverride None
> </Directory>
>
> <Directory /home/dev/perl/lib/Experimental/public>
> Order allow,deny
> Allow from all
> Options Indexes
> AllowOverride None
> </Directory>
>
> <Location /mp>
> SetHandler modperl
> PerlResponseHandler Experimental::ResponseHandler
> </Location>
>
> </VirtualHost>
>
> And a module...
>
> package Experimental::ResponseHandler;
> use strict;
> use warnings;
>
> use Apache2::Const -compile => qw/OK DECLINED/;
>
> sub handler {
> my $r = shift;
> my $f = $r->filename;
> warn "FILE: $f\n";
>
> if ( -d $f ) {
> warn "DIR!\n";
> return Apache2::Const::DECLINED;
> }
>
> $r->print( 'Hi!' );
> return Apache2::Const::OK;
> }
>
> 1;
>
> And the index on /mp worked perfectly. Files below the directory got the
> Perl-generated response, and files above didn't trigger the handler.
>
> >From there I tried to break it, without much success. The only thing I
> did that made any difference was to add a <Location /> section below the
> existing /mp section. Even then, it gave me a 403 and logged 'index
> forbidden by Options'.
>
> So all I can say is, Beats Me.
>
> I do know though, I've pulled my hair out too many times trying to
> figure out what eventually wound up being configuration merging
> problems. It's pretty whacked sometimes.
>
> If you want to track it down further, go for it. I really don't care so
> much anymore after moving most of my stuff to Nginx/Dancer. I just
> thought I'd save you a few follicles. ;-)
>
> HTH
>
> Cheers,
> Rick
>
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
