You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Andrew Nugged <nu...@gmail.com> on 2012/05/20 00:23:03 UTC

Setting up perl-virtual-host handlers from startup script or handler, not from apache config, not hardcoded

I can set handlers directly from Apache config:

<VirtualHost A>
    PerlResponseHandler  code::A
</VirtualHost A>
<VirtualHost B>
    PerlResponseHandler  code::B
</VirtualHost B>

code A called only once and code B once too, only for specific Virtual Hosts.
I need to make same config from my startup perl script, I want to read
some own config data and then decide which handlers to add, which to
not. Bit if I do:

<VirtualHost A>
    <Perl>
        ...
        $s->push_handlers( PerlResponseHandler => 'code::A');
    </Perl>
</VirtualHost A>
<VirtualHost B>
    <Perl>
        ...
        $s->push_handlers( PerlResponseHandler => 'code::B');
    </Perl>
</VirtualHost B>

it presets PerlResponseHandler for code A and then code B in stack for
all requests, not for specific virtual server. That means sub-level
config's context doesn't taken into account in <Perl> sections at all
or by push_handlers routine. Anyway, doesn't work.

I want to set up own perl handlers, from perl script (i.e. through
some push_handlers-like facility) but only for specific virtual hosts,
not for all server, one handler per virtual server (code A / B), so
one mine PerlResponseHandler will act only for virtual server A,
another for B.

I don't want to make additional dispatching in every handler to
analyse, which virtual host at current request is.

Is there's a way to make some fantasy-call like 'push handler per
virtual host' from perl? (there is not, I learned API, maybe I missed
some?)
But... how to do that?

AS one pre-idea I found in API was:

<VirtualHost A>
    <Perl>
        ...
        $s->add_config(['PerlResponseHandler code::A'])
    </Perl>
</VirtualHost A>
<VirtualHost B>
    <Perl>
        ...
        $s->add_config(['PerlResponseHandler code::B'])
    </Perl>
</VirtualHost B>

but does $s->add_config works in current config context, or from
Apache config's root as $s->push_handlers?
and... intuitively I think it's not straight way. Through some strange
backdoor, right?
Maybe there's more fancy way?



P.S. I don't want to enable global request, want to make more
efficient / less memory code.

--
creator, owner and maintainer of http://www.ladoshki.com and http://patent.km.ua
my CV/about: http://patent.km.ua/eng/nugged?nc=lmp20
With respect, Andrew Nugged.

Re: Setting up perl-virtual-host handlers from startup script or handler, not from apache config, not hardcoded

Posted by Ryan Gies <ry...@livesite.net>.
As you have eluded to, it is the request (not the server) which
can be configured as such. Possibly this would work for you:

<VirtualHost A>
    PerlTransHandler +Local::Handlers->startup
</VirtualHost>

<VirtualHost B>
    PerlTransHandler +Local::Handlers->startup
</VirtualHost>

package Local::Handlers;
# ...
sub startup {
   my $r = ref($_[0]) ? $_[0] : $_[1];
   # $r->is_initial_req is handy here
   $r->push_handlers(PerlResponseHandler =>  \&_response_handler); # For this request
   $r->handler('modperl'); # Unless set in Apache config
   return Apache2::Const::DECLINED; # Allow subsequent trans handlers to run
}
sub _response_handler {
   my $r = ref($_[0]) ? $_[0] : $_[1];
   # ...
   return Apache2::Const::OK;
}
1;

Note, the Trans phase was used because it is the earliest chance to hook in. However
if you are only setting the response handler, Fixup is a better place (as it comes after
auth, after headers are parsed, etc).


On 5/19/2012 6:23 PM, Andrew Nugged wrote:
> I can set handlers directly from Apache config:
>
> <VirtualHost A>
>      PerlResponseHandler  code::A
> </VirtualHost A>
> <VirtualHost B>
>      PerlResponseHandler  code::B
> </VirtualHost B>
>
> code A called only once and code B once too, only for specific Virtual Hosts.
> I need to make same config from my startup perl script, I want to read
> some own config data and then decide which handlers to add, which to
> not. Bit if I do:
>
> <VirtualHost A>
>      <Perl>
>          ...
>          $s->push_handlers( PerlResponseHandler =>  'code::A');
>      </Perl>
> </VirtualHost A>
> <VirtualHost B>
>      <Perl>
>          ...
>          $s->push_handlers( PerlResponseHandler =>  'code::B');
>      </Perl>
> </VirtualHost B>
>
> it presets PerlResponseHandler for code A and then code B in stack for
> all requests, not for specific virtual server. That means sub-level
> config's context doesn't taken into account in<Perl>  sections at all
> or by push_handlers routine. Anyway, doesn't work.
>
> I want to set up own perl handlers, from perl script (i.e. through
> some push_handlers-like facility) but only for specific virtual hosts,
> not for all server, one handler per virtual server (code A / B), so
> one mine PerlResponseHandler will act only for virtual server A,
> another for B.
>
> I don't want to make additional dispatching in every handler to
> analyse, which virtual host at current request is.
>
> Is there's a way to make some fantasy-call like 'push handler per
> virtual host' from perl? (there is not, I learned API, maybe I missed
> some?)
> But... how to do that?
>
> AS one pre-idea I found in API was:
>
> <VirtualHost A>
>      <Perl>
>          ...
>          $s->add_config(['PerlResponseHandler code::A'])
>      </Perl>
> </VirtualHost A>
> <VirtualHost B>
>      <Perl>
>          ...
>          $s->add_config(['PerlResponseHandler code::B'])
>      </Perl>
> </VirtualHost B>
>
> but does $s->add_config works in current config context, or from
> Apache config's root as $s->push_handlers?
> and... intuitively I think it's not straight way. Through some strange
> backdoor, right?
> Maybe there's more fancy way?
>
>
>
> P.S. I don't want to enable global request, want to make more
> efficient / less memory code.
>
> --
> creator, owner and maintainer of http://www.ladoshki.com and http://patent.km.ua
> my CV/about: http://patent.km.ua/eng/nugged?nc=lmp20
> With respect, Andrew Nugged.