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