You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Udlei Nattis <ma...@anankeit.com.br> on 2004/05/03 21:21:43 UTC

[mp2] default handler

Hi,

I have problem to set default handler when enter in my website

httpd.conf:

        $Location{"/"} = {
            SetHandler  => "perl-script",
            PerlHandler => "eShop::Web::Shop::home",
            PerlOptions => "+SetupEnv",
        };

but when i access /image.gif, apache open module Shop::home
exist one solution for dont use module when i open another file
or for exemplo i rename location for /default and apache
load this modulos when i set DirectoryIndex

i look for one ModuleIndex...

thanks all and sorry my english

-- 
Udlei Nattis
Gerente de desenvolvimento
-----------------------------
www.linuxmall.com.br
+55 11 5087-9441 


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp1] subprocess_env and non-mod_perl handlers

Posted by John Wittkoski <jo...@aol.com>.

Geoffrey Young wrote on 5/3/04, 8:02 PM:

 > > If I do the void subprocess_env trick:
 > >
 > > $r->subprocess()
 > >
 > > before retrieving $something, then it's populated along with the
 > rest of
 > > the environment.
 >
 > that only affects %ENV, not the ability of $r->subprocess_env to grab
 > something from the subprocess_env table.  %ENV is not automatically
 > populated with the contents of subprocess_env, so if you're really
 > talking
 > about %ENV then your Example 2 + subprocess_env() trick sounds right.


Nope, I'm talking about the table itself (via subprocess_env), which is 
why I am confused.


 >
 > >
 > > However, as mentioned in many of the docs/books, this is expensive
 > and I
 > > really only need the one variable.
 > >
 > > I've also tried walking the subprocess_env table in the perl handler,
 > > but the value set in the C handler is not there.
 >
 > that's really strange.  are you sure that you are not removing it in your
 > application someplace?  try tweaking the test tarball I mentioned bit
 > by bit
 > until it has the relevant logic from your code in it.  I can't tell
 > you the
 > number of bugs I've "fixed" by trying to reproduce the bug, only to
 > find I
 > was the bug :)


Understood. :-) Thanks for the code, I'll keep working on it trying to 
narrow down the problem. At least I know that the behavior I'm seeing is 
definitely wrong and it should work without the void subprocess_env call.


 >
 > >
 > > Are the C API subprocess_env table and the mod_perl API subprocess_env
 > > table distict until something (like the void call) merges the
 > tables? Is
 > > this some sort of scoping issue between C and Perl?
 >
 > it shouldn't be, so long as you're hitting the tables directly with
 > $r->subprocess_env.  %ENV is another matter entirely.


Thanks,

    --John





-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp1] subprocess_env and non-mod_perl handlers

Posted by Geoffrey Young <ge...@modperlcookbook.org>.

John Wittkoski wrote:
> 
> Geoffrey Young wrote on 5/4/04, 4:18 PM:
> 
>  > not really.  but clearly you have some kind of problem.
> 
> Doh! I definitely do, I think I'm it.
> 
> Remember earlier when you said how in debugging you often find that you 
> are the bug? Well, I am the bug in this case. :-)

:)

> 
> In the process of trying to figure out why I wasn't seeing anything in 
> the subprocess_env table, I decided to take a look at the headers_in 
> table. And there it was.
> 
> Turns out that the C handler I am using (for which I have limited docs) 
> is putting it's data into the headers_in table and not the 
> subprocess_env table. (Insert embarrassed big red face here.) Based on 
> everything I've read on handlers and the types of things being populated 
> (i.e. not headers from the client) the headers_in table didn't seem to 
> be the right place so I wasn't looking there.
> 
> Sorry about that.

no problem at all :)

at least you know a little more about both your app and some apache/mod_perl
internals, so it was positive overall.

--Geoff

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp1] subprocess_env and non-mod_perl handlers

Posted by John Wittkoski <jo...@aol.com>.

Geoffrey Young wrote on 5/4/04, 4:18 PM:

 > not really.  but clearly you have some kind of problem.

Doh! I definitely do, I think I'm it.

Remember earlier when you said how in debugging you often find that you 
are the bug? Well, I am the bug in this case. :-)

In the process of trying to figure out why I wasn't seeing anything in 
the subprocess_env table, I decided to take a look at the headers_in 
table. And there it was.

Turns out that the C handler I am using (for which I have limited docs) 
is putting it's data into the headers_in table and not the 
subprocess_env table. (Insert embarrassed big red face here.) Based on 
everything I've read on handlers and the types of things being populated 
(i.e. not headers from the client) the headers_in table didn't seem to 
be the right place so I wasn't looking there.

Sorry about that.

Thanks for the help,


    --John




-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp1] subprocess_env and non-mod_perl handlers

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Geoff,
> So I haven't been able to get very far on the code to test this further, 
> but in the Eagle book I noticed this (section 9.1.4):
> 
> "subprocess_env() is only required if you need to change the environment 
> in a subprocess launched by a different handler or module."

what this section is talking about is the ability of mod_perl to alter the
environment of other handlers, such as mod_php.  in those cases, you are
required to use subprocess_env.

> 
> So what would happen if the C module is setting it's own ENV instead of 
> using ap_table_set? 


ou're thinking too hard :)  there is no ENV in C-land, really.  I mean,
there are ways to get to perl's %ENV via C but that's not what you say
you're doing.  so forget about %ENV for the moment - %ENV gets set
specifically my modules (mod_cgi, mod_perl, mod_php) based on the contents
of the subprocess_env table and has no bearing at all if you're accessing
the table directly.

> Would that explain why I can't see the value in the
> perl module using subprocess_env, but when I call void subprocess_env(),
> the value suddenly appears in %ENV and the subprocess table?

not really.  but clearly you have some kind of problem.  unfortunately I've
never seen this before and I don't see anything in the code to suggest what
your problem might be.  and if I can't reproduce it I can't solve it.

here are a few things to try though.

first, see if changing your calls make any difference.  that is, use
$r->subprocess_env->get() and $r->subprocess_env->set() instead of other
forms to remove the tie magic from the equation and see if that helps at all.

next I would try fiddling with PerlSetupEnv to see if that has some hidden
interaction with your reads.

you seem to know some C, so I'd try creating a C content handler and use
that to just dump the subprocess_env table.  you can use mod_example.c as a
guide.  if you can see the variable in your own content handler but not when
mod_perl is the content handler then I guess that at least verifies
something.  (what, I don't know :)

anyway, if you are able to reproduce the problem and roll it up into the
tarball I posted then I could fix whatever it is in mod_perl core that's
causing you harm.

HTH

--Geoff



-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp1] subprocess_env and non-mod_perl handlers

Posted by John Wittkoski <jo...@aol.com>.

Geoffrey Young wrote on 5/3/04, 8:02 PM:

 > > Example 2:
 > >
 > > Basically the same except I have a C handler defined for TypeHandler
 > and
 > >   a mod_perl handler defined for FixupHandler. When the C code does:
 > >
 > > ap_table_set(r->subprocess_env, "TEST", "value");
 > >
 > > The mod_perl handler for FixupHandler doesn't see it using:
 > >
 > > $something = $r->subprocess_env("TEST");


 > > However, as mentioned in many of the docs/books, this is expensive
 > and I
 > > really only need the one variable.
 > >
 > > I've also tried walking the subprocess_env table in the perl handler,
 > > but the value set in the C handler is not there.
 >
 > that's really strange.  are you sure that you are not removing it in your
 > application someplace?  try tweaking the test tarball I mentioned bit
 > by bit
 > until it has the relevant logic from your code in it.  I can't tell
 > you the
 > number of bugs I've "fixed" by trying to reproduce the bug, only to
 > find I
 > was the bug :)


Geoff,
So I haven't been able to get very far on the code to test this further, 
but in the Eagle book I noticed this (section 9.1.4):

"subprocess_env() is only required if you need to change the environment 
in a subprocess launched by a different handler or module."

So what would happen if the C module is setting it's own ENV instead of 
using ap_table_set? Would that explain why I can't see the value in the 
perl module using subprocess_env, but when I call void subprocess_env(), 
the value suddenly appears in %ENV and the subprocess table?


    --John






-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp1] subprocess_env and non-mod_perl handlers

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Example 1:
> 
> I have mod_perl handlers defined for the TypeHandler and FixupHandler 
> phases. If in the TypeHandler code I do this:
> 
> $r->subprocess_env("TEST" => "value");
> 
> Then in FixupHandler I can "see" TEST using:
> 
> $something = $r->subprocess_env("TEST");
> 
> Which is what you would expect.

indeed.

> 
> 
> Example 2:
> 
> Basically the same except I have a C handler defined for TypeHandler and 
>   a mod_perl handler defined for FixupHandler. When the C code does:
> 
> ap_table_set(r->subprocess_env, "TEST", "value");
> 
> The mod_perl handler for FixupHandler doesn't see it using:
> 
> $something = $r->subprocess_env("TEST");

that's not right.  however, I can't reproduce this with the attached minimal
test case.  see

  http://perl.apache.org/~geoff/subprocess-env.tar.gz

> 
> 
> If I do the void subprocess_env trick:
> 
> $r->subprocess()
> 
> before retrieving $something, then it's populated along with the rest of 
> the environment.

that only affects %ENV, not the ability of $r->subprocess_env to grab
something from the subprocess_env table.  %ENV is not automatically
populated with the contents of subprocess_env, so if you're really talking
about %ENV then your Example 2 + subprocess_env() trick sounds right.

> 
> However, as mentioned in many of the docs/books, this is expensive and I 
> really only need the one variable.
> 
> I've also tried walking the subprocess_env table in the perl handler, 
> but the value set in the C handler is not there.

that's really strange.  are you sure that you are not removing it in your
application someplace?  try tweaking the test tarball I mentioned bit by bit
until it has the relevant logic from your code in it.  I can't tell you the
number of bugs I've "fixed" by trying to reproduce the bug, only to find I
was the bug :)

> 
> Are the C API subprocess_env table and the mod_perl API subprocess_env 
> table distict until something (like the void call) merges the tables? Is 
> this some sort of scoping issue between C and Perl?

it shouldn't be, so long as you're hitting the tables directly with
$r->subprocess_env.  %ENV is another matter entirely.

--Geoff

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

[mp1] subprocess_env and non-mod_perl handlers

Posted by John Wittkoski <jo...@aol.com>.
Greetings all,

So I've been trying to find an answer to this in both the archives and 
in the available mod_perl books, but I have not had any luck, so I was 
hoping someone on the list would know the answer.

Generally: how does subprocess_env in mod_perl 1.x behave with 
non-mod_perl handlers?

It seems from the details I can find that subprocess_env is tied to the 
"live" table of the apache process. However, I am seeing behavior that 
seems to indicate otherwise.

Example 1:

I have mod_perl handlers defined for the TypeHandler and FixupHandler 
phases. If in the TypeHandler code I do this:

$r->subprocess_env("TEST" => "value");

Then in FixupHandler I can "see" TEST using:

$something = $r->subprocess_env("TEST");

Which is what you would expect.


Example 2:

Basically the same except I have a C handler defined for TypeHandler and 
  a mod_perl handler defined for FixupHandler. When the C code does:

ap_table_set(r->subprocess_env, "TEST", "value");

The mod_perl handler for FixupHandler doesn't see it using:

$something = $r->subprocess_env("TEST");


If I do the void subprocess_env trick:

$r->subprocess()

before retrieving $something, then it's populated along with the rest of 
the environment.

However, as mentioned in many of the docs/books, this is expensive and I 
really only need the one variable.

I've also tried walking the subprocess_env table in the perl handler, 
but the value set in the C handler is not there.

Are the C API subprocess_env table and the mod_perl API subprocess_env 
table distict until something (like the void call) merges the tables? Is 
this some sort of scoping issue between C and Perl?


Thanks,

    --John




-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] default handler

Posted by Stas Bekman <st...@stason.org>.
Udlei Nattis wrote:
> Thanks Stas,
> 
> That is my problem,
> subdirectoy is ok now
> but in directory index problem persist
> exists for example:
> 
>    # Modulo home default
>    $Location{"/"} = {
>        SetHandler  => "modperl",
>        PerlHandler => "eShop::Web::Shop::home",
>        PerlOptions => "+SetupEnv",
>    };
> 
>  >        $Location{"/*"} = { # or != "/"
>  >            SetHandler  => "default-handler",
>  >        };
> 
> because i have /file.js and /file.css
> or i need change all files to one directory in default handler?

I guess something like:

<FilesMatch "*.(js|css)">
     SetHandler  => "default-handler",
</FilesMatch>

You should read the Apache docs. It's not really a mod_perl specific issue.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] $r->auth_name

Posted by Geoffrey Young <ge...@modperlcookbook.org>.

Fred Moyer wrote:
>>>
>>> Is there an mp2 implementation of $r->auth_name?  I'm working with
>>> Apache::AuthCookie in a native mp2 environment and am getting an error
>>> message of:
>>
>>
>> I believe this module has been ported to mp2 already.  you might want to
>> check the archives so you don't end up doing more work than you need.
> 
> I followed the threads to
> http://marc.theaimsgroup.com/?l=apache-modperl&m=105264164428847&w=2
> 
> Most of this I got working.

try

http://marc.theaimsgroup.com/?l=apache-modperl&m=105978462618590&w=2

which notes that a pre-release of 3.05 supports mp2 and is available from here:

  https://sourceforge.net/project/showfiles.php?group_id=12701

> 
>>>
>>> Can't locate class method 'Apache::RequestRec::auth_name' via package
>>> 'Apache::ReqestRec' at Apache/AuthCookie.pm line 18
>>>
>>> I've found references to $r->auth_name and ap_auth_name in the source
>>> but have not come across it in the api docs.
>>
>>
>> you need to
>>
>>   use Apache::Access ();
>>
>> first.
> 
> 
> Aha, the missing piece. Thanks!

sure :)

--Geoff

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] $r->auth_name

Posted by Fred Moyer <fr...@taperfriendlymusic.org>.
>>
>> Is there an mp2 implementation of $r->auth_name?  I'm working with
>> Apache::AuthCookie in a native mp2 environment and am getting an error
>> message of:
>
> I believe this module has been ported to mp2 already.  you might want 
> to
> check the archives so you don't end up doing more work than you need.
I followed the threads to 
http://marc.theaimsgroup.com/?l=apache-modperl&m=105264164428847&w=2

Most of this I got working.

>>
>> Can't locate class method 'Apache::RequestRec::auth_name' via package
>> 'Apache::ReqestRec' at Apache/AuthCookie.pm line 18
>>
>> I've found references to $r->auth_name and ap_auth_name in the source
>> but have not come across it in the api docs.
>
> you need to
>
>   use Apache::Access ();
>
> first.

Aha, the missing piece. Thanks!


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] $r->auth_name

Posted by Geoffrey Young <ge...@modperlcookbook.org>.

Fred Moyer wrote:
> Greetings,
> 
> Is there an mp2 implementation of $r->auth_name?  I'm working with
> Apache::AuthCookie in a native mp2 environment and am getting an error
> message of:

I believe this module has been ported to mp2 already.  you might want to
check the archives so you don't end up doing more work than you need.

> 
> Can't locate class method 'Apache::RequestRec::auth_name' via package
> 'Apache::ReqestRec' at Apache/AuthCookie.pm line 18
> 
> I've found references to $r->auth_name and ap_auth_name in the source
> but have not come across it in the api docs.

you need to

  use Apache::Access ();

first.

HTH

--Geoff

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

[mp2] $r->auth_name

Posted by Fred Moyer <fr...@taperfriendlymusic.org>.
Greetings,

Is there an mp2 implementation of $r->auth_name?  I'm working with 
Apache::AuthCookie in a native mp2 environment and am getting an error 
message of:

Can't locate class method 'Apache::RequestRec::auth_name' via package 
'Apache::ReqestRec' at Apache/AuthCookie.pm line 18

I've found references to $r->auth_name and ap_auth_name in the source 
but have not come across it in the api docs.

TIA,

Fred


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] default handler

Posted by Udlei Nattis <ma...@anankeit.com.br>.
Thanks Stas,

That is my problem,
subdirectoy is ok now
but in directory index problem persist
exists for example:

    # Modulo home default
    $Location{"/"} = {
        SetHandler  => "modperl",
        PerlHandler => "eShop::Web::Shop::home",
        PerlOptions => "+SetupEnv",
    };

 >        $Location{"/*"} = { # or != "/"
 >            SetHandler  => "default-handler",
 >        };

because i have /file.js and /file.css
or i need change all files to one directory in default handler?

thanks

Stas Bekman wrote:

> Udlei Nattis wrote:
>
>> Hi,
>>
>> I have problem to set default handler when enter in my website
>>
>> httpd.conf:
>>
>>        $Location{"/"} = {
>>            SetHandler  => "perl-script",
>>            PerlHandler => "eShop::Web::Shop::home",
>>            PerlOptions => "+SetupEnv",
>>        };
>>
>> but when i access /image.gif, apache open module Shop::home
>> exist one solution for dont use module when i open another file
>> or for exemplo i rename location for /default and apache
>> load this modulos when i set DirectoryIndex
>>
>> i look for one ModuleIndex...
>>
>> thanks all and sorry my english
>
>
> Let's see whether I understood you correctly. You want to have 
> Shop::Web::Shop::home to handle everything but a few other resources, 
> for which you want to run the default handler (like images).
> In which case, take a look at:
>
> http://perl.apache.org/docs/1.0/guide/config.html#Overriding_E_lt_LocationE_gt__Setting_in__Sub_Location_ 
>
>
> Since you use <Perl> sections, you need to ensure that things are kept 
> in the correct order, so / won't override other setting. So you will 
> probably need to use Tie::IxHash...
>
> Philippe, could you please update
> http://perl.apache.org/docs/2.0/api/Apache/PerlSections.html
> with examples on how to keep things in the order? Thanks!
>
>


-- 
Udlei Nattis
Gerente de desenvolvimento
-----------------------------
www.linuxmall.com.br
+55 11 5087-9441 


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] default handler

Posted by Stas Bekman <st...@stason.org>.
Udlei Nattis wrote:
> Hi,
> 
> I have problem to set default handler when enter in my website
> 
> httpd.conf:
> 
>        $Location{"/"} = {
>            SetHandler  => "perl-script",
>            PerlHandler => "eShop::Web::Shop::home",
>            PerlOptions => "+SetupEnv",
>        };
> 
> but when i access /image.gif, apache open module Shop::home
> exist one solution for dont use module when i open another file
> or for exemplo i rename location for /default and apache
> load this modulos when i set DirectoryIndex
> 
> i look for one ModuleIndex...
> 
> thanks all and sorry my english

Let's see whether I understood you correctly. You want to have 
Shop::Web::Shop::home to handle everything but a few other resources, for 
which you want to run the default handler (like images).
In which case, take a look at:

http://perl.apache.org/docs/1.0/guide/config.html#Overriding_E_lt_LocationE_gt__Setting_in__Sub_Location_

Since you use <Perl> sections, you need to ensure that things are kept in the 
correct order, so / won't override other setting. So you will probably need to 
use Tie::IxHash...

Philippe, could you please update
http://perl.apache.org/docs/2.0/api/Apache/PerlSections.html
with examples on how to keep things in the order? Thanks!


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html