Re: Apache::PerlRun weird behavior?
Perrin Harkins wrote:
> valerian wrote:
>
>> So the weird thing is that it runs fine the first time, but when I
>> reload the page, it doesn't show the variable I imported from
>> My::Config
>
>
> Try changing this:
>
> use My::Config;
>
> to this:
>
> require My::Config;
> import My::Config;
>
> BEGIN blocks are only run once in PerlRun/Registry, and PerlRun clears
> the current namespace after each request, erasing the aliases created by
> import.
> Of course I can't explain why this worked for Stas. Maybe there is
> something about the specific versions of Perl/mod_perl that affects this.
I think I've had enough coffee. PerlRun recompiles the code on each
request, meaning that it re-runs any BEGIN blocks on each request.
Meaning that My::Config will re-import %CF afresh.
It's simply to check, add to your script:
BEGIN { warn "BEGIN was called\n"; }
you will see the message on every reload.
Since use is almost the same as: require+import. require won't be called
because the module will be already in %INC, but import will be always
called. Again it's simply to check. Add to My::Config:
sub import { warn "import was called" }
and don't inherit from Exporter. Again you will see import() called on
each request.
> In general, you'd be better off just avoiding aliases and
> Exporter altogether, since they waste memory and can cause confusion.
Seconded. See
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Using_Global_Variables_and_Sharing_Them_Between_Modules_Packages
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: SetEnvIf Directive
Pierre Vaudrey wrote: > I'm trying to build a web site on the built-in Apache server of a Mac > OSX 10.1.5 machine . > Extract of httpd.conf is : > .. > LoadModule setenvif_modulelibexec/httpd/mod_setenvif.so > .. > AddModule mod_setenvif.c Pierre, this has nothing to do with mod_perl. Please see http://httpd.apache.org/lists.html#http-users __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: $r->push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
Rodney Broom wrote:
> From: Stas Bekman <[EMAIL PROTECTED]>
>
>
>>What happens if you do:
>> $r->set_handlers('PerlAuthenHandler', 'Some::handler');
>
> Either of these:
> $r->set_handlers('PerlAuthenHandler', 'Some::handler');
> $r->set_handlers('PerlAuthenHandler', \&Some::handler);
>
> Yeild:
> "Can't set_handler with that value..."
> Which agrees with the Apache.pm docs.
Ah, sorry. I'm living in the future. in mod_perl 2.0 you can pass
\@handlers or \&handler for both set_handlers() and push_handlers().
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
SetEnvIf Directive
I'm trying to build a web site on the built-in Apache server of a Mac OSX 10.1.5 machine . Extract of httpd.conf is : .. LoadModule setenvif_modulelibexec/httpd/mod_setenvif.so .. AddModule mod_setenvif.c .. # Customize behaviour based on the browser # # # The following directives modify normal HTTP response behavior. # The first directive disables keepalive for Netscape 2.x and browsers that # spoof it. There are known problems with these browser implementations. # The second directive is for Microsoft Internet Explorer 4.0b2 # which has a broken HTTP/1.1 implementation and does not properly # support keepalive when it is used on 301 or 302 (redirect) responses. # BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 # # The following directive disables HTTP/1.1 responses to browsers which # are in violation of the HTTP/1.0 spec by not being able to grok a # basic 1.1 response. # BrowserMatch "RealPlayer 4\.0" force-response-1.0 BrowserMatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0 ... Is the following error related to a misconfigured Apache server ? Syntax error on line 18 of /Library/WebServer/Documents/conf/httpd-shared.conf: Invalid command 'SetEnvIf', perhaps mis-spelled or defined by a module not included in the server configuration line 18 is :SetEnvIf Request_URI \.(gif|jpg|css)$ image-request Pierre Vaudrey email [EMAIL PROTECTED]
Re: $r->push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
From: Per Einar Ellefsen <[EMAIL PROTECTED]>
> dir_config is the Perl{Set,Add}Var configuration...
Yep, you're right. But I'm sort of grasping at straws at this point.
> You can just add that and let your handler decide regardless of the value
> of requires...
Yes, but there are side effects:
1. When the access handler finds a URI that doesn't need authentication turned on:
# httpd.conf
require jack handy
# Access handler
return OK; # Since we don't care about the current URI.
# Error log
Some::handler(): Starting in [PerlAccessHandler].
Some::handler(): This uri [/one/onezie.fil] not under access control, returning OK.
configuration error: couldn't perform authentication. AuthType \
not set!: /one/onezie.fil
Although on areas where authentication is desired, this method works fine. We just
have to set r->auth_type and r->auth_name before returning from access control.
2. I don't want to have to add several lines to each that I use this
code in. Instead, we add a single handler at the URI Translation phase and let it
set up the rest of the handlers for the request. Actually, we already have a
system doing this and are very happy with the results. This Authen handler is just
intended to be an add-on to that.
> ...which is accessed through $r->requires btw...
Ah, you're right. Thank you. Unfortunately, this is read-only.
---
Rodney Broom
President, R.Broom Consulting
http://www.rbroom.com/
Re: $r->push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
At 21:05 01.09.2002, Rodney Broom wrote:
> > Apache will not run the Authen or Authz phases unless there is a
> > Require directive, no matter what you put onto the mod_perl handler stack.
>
>I sort of thought this myself, so I tried $r->dir_config->add('require',
>'valid-user') in the access handler. No help.
dir_config is the Perl{Set,Add}Var configuration, and has nothing to do
with Requires. Requires is set within httpd.conf like:
Require valid-user
You can just add that and let your handler decide regardless of the value
of requires (which is accessed through $r->requires btw, see the Eagle or
the cookbook).
--
Per Einar Ellefsen
[EMAIL PROTECTED]
Re: $r->push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
From: Geoffrey Young <[EMAIL PROTECTED]>
> you probably don't have a Require directive in your httpd.conf for
> this particular .
You're right, I don't. In fact, I can't. One of the things the access handler does is
to look up the URI in a database, which happens at run time. (The directive
would happen at server load time.) I need the access handler to decide wether or not
the requested URI needs authentication.
> Apache will not run the Authen or Authz phases unless there is a
> Require directive, no matter what you put onto the mod_perl handler stack.
I sort of thought this myself, so I tried $r->dir_config->add('require', 'valid-user')
in the access handler. No help.
---
Rodney Broom
President, R.Broom Consulting
http://www.rbroom.com/
Re: $r->push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
Rodney Broom wrote:
> Hi all,
>
> I'm sure I'm just missing something, but I'm stumped.
>
> I've got an access handler that does some tests and then conditionaly does this:
>
> $r->push_handlers('PerlAuthenHandler', 'Some::handler');
> return OK;
>
> Some::handler() starts by printing the current callback to the error log, which
>never happens if it's set to run in the 'PerlAuthenHandler'. If I change the
>push_handlers() to use 'PerlFixupHandler', then Some::handler() gets called and I see
>it in the error log.
>
> What am I doing wrong? I know it has to be me.
you probably don't have a Require directive in your httpd.conf for
this particular . Apache will not run the Authen or Authz
phases unless there is a Require directive, no matter what you put
onto the mod_perl handler stack.
HTH
--Geoff
Re: $r->push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
From: Stas Bekman <[EMAIL PROTECTED]>
> What happens if you do:
>$r->set_handlers('PerlAuthenHandler', 'Some::handler');
Either of these:
$r->set_handlers('PerlAuthenHandler', 'Some::handler');
$r->set_handlers('PerlAuthenHandler', \&Some::handler);
Yeild:
"Can't set_handler with that value..."
Which agrees with the Apache.pm docs.
This:
$r->set_handlers('PerlAuthenHandler', ['Some::handler']);
Yeilds:
Gives no error, Some::handler() doesn't get run.
> could be that with push_handlers() you have some other handler that
> takes over, before Some::handler has a chance to run.
With either push_handlers() or set_handlers(), get_handlers() says that
'Some::handler' is the only handler in 'PerlAuthenHandler'. So I know the action is
working according to mod_perl. As for something else taking over, there's nothing that
I can find on this sandbox installation. No Auth* in the config, no htaccess files,
and no other Perl*Handler directives in use.
Just on a lark, I tried installing a PerlAuthenHandler in the config, it worked just
fine.
---
Rodney Broom
President, R.Broom Consulting
http://www.rbroom.com/
Re: Apache::PerlRun weird behavior?
valerian wrote: > So the weird thing is that it runs fine the first time, but when I > reload the page, it doesn't show the variable I imported from > My::Config Try changing this: use My::Config; to this: require My::Config; import My::Config; BEGIN blocks are only run once in PerlRun/Registry, and PerlRun clears the current namespace after each request, erasing the aliases created by import. In general, you'd be better off just avoiding aliases and Exporter altogether, since they waste memory and can cause confusion. Of course I can't explain why this worked for Stas. Maybe there is something about the specific versions of Perl/mod_perl that affects this. - Perrin
RE: mod_perl & mod_php
all- Interesting topic, to be sure. Although no one touched on the relationship I almost always see between Perl and PHP: Rapid Application Deployment. You can get a massively complex application out to users as a beta much more quickly with PHP (Sorry Perl), additionally capitalizing on the fast ramp-up to make junior developers actually useful. Correct me if I'm wrong, but I thought that was why languages like PHP and Python existed in the first place. >I'm using both at work because we're slowly migrating from PHP to Perl. >PHP is better than Perl in some cases, I've found. If you're >predominantly templating and don't want to futz around with Mason or TT >or whatever, PHP will do a fine job. I'm considering changing my stationery to that quote, it is so right on. >But there are some good >things written in PHP, it's just that there are a WHOLE lot more people >writing PHP than Perl (just look at the mailing lists and script >archives). Isn't that the Bazaar we open-sourcers dreamed of? A million users, who also happened to be developers? Except that the mailing lists are comparatively useless, point taken. mod_perl is viewed by the unitiated as a Cathedral for all practical purposes, even if it is the One True Language. One final point: everyone else besides developers care about one thing: using a working application. They give no flying expletives whatsoever about what language or platform it is in. Those of you not saying "Duh!" right now may want to take a moment or two to mull. Thanks to all who contributed to this topic: what makes this mailing list great is that in addition to gaining insight into mod_perl development, you gain insight into mod_perl developers. grant stevens http://l-eet.com
