RE: Auth Handlers

[J. Zobel]

On Tue, 2001-12-11 at 21:00, Stathy Touloumis wrote:
> Actually, I DON'T want the browser to prompt for a username/pass.  I saw the
> examples in the eagle book and they all seem to use Authz, with Auth
> handlers using the example you showed.
> Perhaps I need to modify the headers so that the prompt does not occur?

I have the exact same problem. I want my AuthenHandler to decide if the
user is prompted for a password. Unfortunately "the book" tells me:

"By the time the handler is called, Apache will have done most of the
work in negotiating the HTTP Basic authentication protocol. It will have
alerted the browser that authentication is required to access the page,
and the browser will have prompted the user to enter his name and
password." 

Has anybody got an idea how to let a handler decide, if autthen. is
required?

Thanx,
Joachim 

> >
> > # *This* is what you need if you want the
> > # browser to prompt for a username/pass
> > AuthType Basic
> > > > > require valid-user
> > > > >
> > > > > PerlAuthenHandler Base::Session::Handler
> > > > > 

Re: Apache crashing on mod_perl installation.

[Ged Haywood]

Hi there,

On Tue, 11 Dec 2001, Titus Brown wrote:

> Do you know how I can turn on debugging symbols so that gdb can give me
> more info (about line number, etc.)?
> 
> I've forced 'gcc' to always have the -g flag on, but that doesn't seem
> to be enough for some reason...

The Guide is your friend:

http://perl.apache.org/guide/debug.html#gdb_says_there_are_no_debugging_

Please keep the mod_perl Mailing List included in your posts, so that
everyone feels the benefit.

73,
Ged.

Re: Comparison of different caching schemes

[Perrin Harkins]

> One important aspect missing from my tests is the actual concurrency
testing.

Oh, I guess I should have checked your code.  I thought these were
concurrent.  That makes a huge difference.

> 2. Lock some part of cache for a request
> (Cache::Mmap buckets, MLDBM pages?)

MLDBM::Sync locks the whole thing.

- Perrin

Re: Comparison of different caching schemes

[Rob Mueller (fastmail)]

Just wanted to add an extra thought that I 
forgot to include in the previous post.
 
One important aspect missing from my tests 
is the actual concurrency testing. In most real world programs, multiple 
applications will be reading from/writing to the cache at the same time. 
Depending on the cache synchronisation scheme, you'll get varying levels of 
performance degradation:
 

1 being worst, 3 being the 
best.
 
1. Lock entire cache for a 
request (Cache::SharedMemoryCache, MySQL normal - table 
locks?)
2. Lock some part of cache for a request 
(Cache::Mmap buckets, MLDBM pages?)
3. Lock only the key/value for a request 
(Cache::FileCache, MySQL InnoDB - row locks?)
 
Uggg, to do a complete test you really need 
to generate an entire modelling system:
1. Number of concurrent 
processes
2. Average reads/writes to cache per 
second
3. Ratio of reused/new entries
etc
 
Rob
 

Re: Case of the Vanishing Symbol Tables

[Daniel Jacobowitz]

On Tue, Dec 11, 2001 at 04:15:49PM -0600, Stephen Clouse wrote:
> With the PerlModule/%INC problem recently being rehashed, here's another one 
> involving PerlModule vs. use that will really bake your noodle.
> 
> Attached is a full mod_perl trace, where I hacked into perl_require_module a 
> dump of one of my vanishing namespaces on each module load.  So you can 
> definitely see it's loading up properly.  All is well until you reach the end, 
> where it starts reloading everything, and the namespace is now completely gone.  
> Exporter predictably throws an error at this point (since @EXPORT_OK is now 
> undefined) and the server fails to start.  OTOH, one wonders how Exporter got 
> the call, since @ISA is gone as well.
> 
> I posted this once before and got blown off -- a pox on to those who tell me to 
> check @INC or what not.  There is nothing wrong with my code or my setup -- the 
> only change I have to make to get things working is to `use` all the PerlModule 
> modules in startup.pl first, before they're called with PerlModule.  And don't 
> tell me to just use `use` either -- they all load up Apache config directives, 
> so PerlModule has to be called at some point so Apache recognizes the 
> directives.  But if things were working as advertised, PerlModule would be all I 
> need.
> 
> The two obvious questions:
> 
> 1) Where the fsck did everything go?
> 2) Why does this only emanate when stuff is loaded up via PerlModule?  I mean, 
>look at perl_require_module -- all it does is `eval "require $foo"`.  Hard to 
>go wrong there.

I'm willing to bet that this is the Known Nasty having to do with how
Apache re-reloads modules.

Are you using mod_perl as a DSO?  If so, have you tried it statically?



-- 
Daniel Jacobowitz   Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer

Re: Case of the Vanishing Symbol Tables

[Stephen Clouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Dec 11, 2001 at 05:33:12PM -0800, David Pisoni wrote:
> IMHO, this looks similar to (though more catastrophic than) the problem I 
> have been dealing with for some time now.
> 
> >From the archive :
> 
> 
> There is a long thread about it.  It is presently unresolved.  (We're hoping 
> for Divine intervention.  We'd settle for Doug. :-)

This is actually the thread I was referring to :)  The first time I encountered 
this, Apache actually would start successfully, but accessing the application 
would error with "undefined subroutine App::Class::handler".  A glance at 
Apache::Status revealed the exact behavior you're describing.  But you're right, 
it *is* more catastrophic now, in that it's no longer content with nuking just 
PerlModule modules, it's eating other ones as well.

Just wish I could spot *where* they're vanishing at...tried all day today but 
no luck.  I'll give it another try tomorrow.

- -- 
Stephen Clouse <[EMAIL PROTECTED]>
Senior Programmer, IQ Coordinator Project Lead
The IQ Group, Inc. 

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.8

iQA/AwUBPBbxNQOGqGs0PadnEQI/kgCg5I9fxWtVp5+WuS/ostqbSNVSCKsAniNK
C4lgQ9YycR91+N02vi4pS2l7
=Vl6Y
-END PGP SIGNATURE-

Re: Case of the Vanishing Symbol Tables

[Stephen Clouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Dec 11, 2001 at 11:08:07PM -0500, Perrin Harkins wrote:
> Are you using PerlFreshRestart?

Same behavior, on or off.

> No need to get testy.

That came out wrong, apparently.  Sorry.

> You should be able to replace a PerlModule call with use
> MyModule; in the same place in httpd.conf.  Does that work for
> you?  The Eagle book says to do that with earlier versions.

This doesn't work either.  They simply refuse to be loaded anywhere other 
than the startup.pl.

- -- 
Stephen Clouse <[EMAIL PROTECTED]>
Senior Programmer, IQ Coordinator Project Lead
The IQ Group, Inc. 

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.8

iQA/AwUBPBbuAwOGqGs0PadnEQK1agCZAS4ksWa1P1ddy5v+5TnTnusq07oAn0jt
fjNlzg6pzLmMRCSfpJwp5F2o
=1Msz
-END PGP SIGNATURE-

Re: User customisable website application?

[Stas Bekman]

Chris Winters wrote:

> * Russell Matbouli ([EMAIL PROTECTED]) [011209 19:44]:
> 
>>As the final year project for my degree, I'm implementing a
>>user-customisable website application (aimed at multiuser websites)
>>in mod_perl. Can anyone tell me if something like this already
>>exists? My searches so far haven't turned up anything like this.
>>
>>Just to clarify what I mean by customisable - the user can log in
>>and change their colour scheme, font, ordering of components, choose
>>a theme... The sort of thing you see on some commercial websites.
>>
> 
> The application servers listed at the mod_perl site [1] should be a
> good start. (Altho I note that the recently announced OpenFrame [2]
> isn't on there.) 


It's there now :)

_
Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

Can't call Apache::Request->new()

[Paul Makepeace]

I'm getting the following error,

$ perl -MApache::Request -e 'Apache::Request->new'
Can't locate object method "new" via package "Apache::Request" (perhaps you forgot to 
load "Apache::Request"?) at -e line 1.
$

...both from the command line and under a PerlHandler Apache::Registry'd
script.

Of course, it is installed:

$ perl -MApache::Request -le 'print grep /Request/, values %INC; print 
$Apache::Request::VERSION'
/usr/local/lib/perl/5.6.1/Apache/Request.pm
0.33
$

In all other respects I'm able to discern so far mod_perl, Perl and
Apache are working here (I have a number of sites using Template Toolkit
with a custom PerlHandler and a few scripts under Apache::Registry). I'm
getting this error from both a fresh CPAN install and Debian's
libapache-request-perl package (not installed at the same time!).

Any suggestions where to start looking?

Thanks,
Paul

PS Rather than cluttering your inbox, perl -V is at
   http://paulm.com/tmp/perl_v.txt

-- 
Paul Makepeace ... http://paulm.com/

"If laughter can heal, then a priest will behave very oddly."
   -- http://paulm.com/toys/surrealism/

Re: Re(2): Apache::SizeLimit Exit is Delayed

[Perrin Harkins]

> That was it.  The child exited immediately when I hit the limit with
> KeepAlive Off.  Now the question is:  Is there a way to force an exit
even
> with KeepAlive On?

As Jay already pointed out, you usually don't want KeepAlive on with
mod_perl.  However, you could try changing the call
$r->child_terminate() to Apache::exit().  If this seems to work better
for you, let me know and I'll consider changing this in a future release
of Apache::SizeLimit.

- Perrin

Re: Re(2): Apache::SizeLimit Exit is Delayed

[Perrin Harkins]

> That was it.  The child exited immediately when I hit the limit with
> KeepAlive Off.  Now the question is:  Is there a way to force an exit
even
> with KeepAlive On?

As Jay already pointed out, you usually don't want KeepAlive on with
mod_perl.  However, you could try changing the call
$r->child_terminate() to Apache::exit().  If this seems to work better
for you, let me know and I'll consider changing this in a future release
of Apache::SizeLimit.

- Perrin

Re: Comparison of different caching schemes

[Perrin Harkins]

> I sat down the other day and wrote a test script to try
> out various caching implementations.

Very interesting.  Looks like Cache::Mmap deserves more attention (and
maybe a Cache::Cache subclass).

> Have I missed something obvious?

Nothing much, but I'd like to see how these numbers vary with the size
of the data being written.  And it would be good if there were a way to
ensure that the data had not been corrupted at the end of a run.

Also, I'd like to see MLDBM + BerkeleyDB (not DB_File) with BerkeleyDB
doing automatic locking, and IPC::MM, and IPC::Shareable, and
IPC::ShareLite (though it doesn't serialize complex data by itself), and
MySQL with standard tables.  Of course I could just do them myself,
since you were kind enough to provide code.

- Perrin

Re: Case of the Vanishing Symbol Tables

[Perrin Harkins]

> All is well until you reach the end,
> where it starts reloading everything, and the namespace is
> now completely gone.

Are you using PerlFreshRestart?

> I posted this once before and got blown off -- a pox
> on to those who tell me to check @INC or what not.

No need to get testy.  If this is causing a problem for your business,
and free volunteer help is not working quickly enough for you, you can
always contract Covalent to solve the problem.

> And don't  tell me to just use `use` either -- they all load up
> Apache config directives,
> so PerlModule has to be called at some point so Apache
> recognizes the directives.

You should be able to replace a PerlModule call with use
MyModule; in the same place in httpd.conf.  Does that work for
you?  The Eagle book says to do that with earlier versions.

- Perrin

Comparison of different caching schemes

[Rob Mueller (fastmail)]

Just thought people might be 
interested...
 
I sat down the other day and wrote a test 
script to try out various caching implementations. The script is pretty basic at 
the moment, I just wanted to get an idea of the performance of different 
methods.
 
The basic scenario is the common mod_perl 
situation:
* Multiple processes
* You need to share perl structures between 
processes
* You want to index the data structure on 
some key
* Same key is written and read multiple 
times
 
I tried out the following 
systems.
* Null reference case (just store in 'in 
process' hash)
* Storable reference case (just store in 
'in process' hash after 'freeze')
* Cache::Mmap (uses Storable)
* Cache::FileCache (uses 
Storable)
* DBI (I used InnoDB), use Storable, always 
do 'delete' then 'insert'
* DBI, use Storable, do 'select' then 
'insert' or 'update'
* MLDBM::Sync::SDBM_File (uses 
Storable)
* Cache::SharedMemoryCache (uses 
Storable)
 
For systems like Cache::* which can 
automatically delete items after an amount of time or size, I left these options 
off or made the cache big enough that this wouldn't happen.
 
I've included the script for people to try 
out if they like and add other test cases.
 
Now to the results, here they 
are.
 Package C0 - In process hashSets per sec = 147116Gets per sec = 
81597Mixes per sec = 124120Package C1 - Storable freeze/thawSets per 
sec = 2665Gets per sec = 6653Mixes per sec = 3880Package C2 - 
Cache::MmapSets per sec = 809Gets per sec = 3235Mixes per sec = 
1261Package C3 - Cache::FileCacheSets per sec = 393Gets per sec = 
831Mixes per sec = 401Package C4 - DBI with freeze/thawSets per sec 
= 651Gets per sec = 1648Mixes per sec = 816Package C5 - DBI (use 
updates with dup) with freeze/thawSets per sec = 657Gets per sec = 
1994Mixes per sec = 944Package C6 - MLDBM::Sync::SDBM_FileSets per 
sec = 334Gets per sec = 1279Mixes per sec = 524Package C7 - 
Cache::SharedMemoryCacheSets per sec = 42Gets per sec = 29Mixes per 
sec = 32
 
Notes:
* System = Pentium III 866, Linux 
2.4.16-0.6, Ext3 (no special file filesystem flags), MySQL (with InnoDB 
tables)
* Null reference hash is slower reading 
because it does a very basic check to see that the retrieved hash has the same 
number of keys as the stored hash
* Approximate performance order (best to 
worst) = Cache::Mmap, DBI, MLDBM::Sync::SDBM_File, Cache::FileCache, 
Cache::SharedMemoryCache
* Remember what Knuth said, "Premature 
optimisation is the root of all evil." This data won't help you if something 
else in your application is the bottleneck...
* The code is available at: http://fastmail.fm/users/robm/perl/cacheperltest.pl
 
Have I missed something 
obvious?
 
Rob
. <- Grain of salt to be taken with this 
post
 
 

Re: Re(2): Apache::SizeLimit Exit is Delayed

[Jay Thorne]

On December 11, 2001 04:25 pm, Mod_perl Mailing List wrote:
>
> Hi Perrin,
>
> That was it.  The child exited immediately when I hit the limit with
> KeepAlive Off.  Now the question is:  Is there a way to force an exit even
> with KeepAlive On?
>
> Thanks!
>
> Bob

For what its worth, I'd recommend KeepAlive Off for almost any mod_perl 
deployment. It basically is a waste of memory and a process slot. Especially 
if you put graphics on a separate server.

-- 
Jay "yohimbe" Thorne  [EMAIL PROTECTED]
Mgr Sys & Tech, Userfriendly.org

Re: Case of the Vanishing Symbol Tables

[David Pisoni]

IMHO, this looks similar to (though more catastrophic than) the problem I have been 
dealing with for some time now.

>From the archive :


There is a long thread about it.  It is presently unresolved.  (We're hoping for 
Divine intervention.  We'd settle for Doug. :-)

Good luck,
David

Re(2): Apache::SizeLimit Exit is Delayed

[Mod_perl Mailing List]

[EMAIL PROTECTED] writes:
>> I'm using Apache::SizeLimit (on both Solaris and Linux) and getting the
>> error_log entry:
>>
>> [Tue Dec 11 15:01:19 2001] (2520) Apache::SizeLimit httpd process too
>big,
>> exiting at SIZE=44964 KB  SHARE=10900 KB  REQUESTS=389  LIFETIME=9505
>> seconds
>>
>> But the child process often doesn't exit right away.  It may hang around
>> for a couple of minutes or even an hour with the message occuring with
>> every hit:
>
>Maybe this is because of a keep-alive connection.  It's possible that
>Apache::exit() waits for all keep-alive activity to complete before
>exiting.
>Is there any way you can test it without keep-alive?
>
>- Perrin
>
Hi Perrin,

That was it.  The child exited immediately when I hit the limit with
KeepAlive Off.  Now the question is:  Is there a way to force an exit even
with KeepAlive On?

Thanks!

Bob

Pushing Handlers from sections

[Issac Goldstand]

Can I _upsh_ handlers from within  sections?  If so, how?  

  Issac

-- 
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
  --Anonymous

Moving the mouse won't get you into trouble...  Clicking it might.
  --Anonymous

PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B

Re: Apache::SizeLimit Exit is Delayed

[Perrin Harkins]

> I'm using Apache::SizeLimit (on both Solaris and Linux) and getting the
> error_log entry:
>
> [Tue Dec 11 15:01:19 2001] (2520) Apache::SizeLimit httpd process too big,
> exiting at SIZE=44964 KB  SHARE=10900 KB  REQUESTS=389  LIFETIME=9505
> seconds
>
> But the child process often doesn't exit right away.  It may hang around
> for a couple of minutes or even an hour with the message occuring with
> every hit:

Maybe this is because of a keep-alive connection.  It's possible that
Apache::exit() waits for all keep-alive activity to complete before exiting.
Is there any way you can test it without keep-alive?

- Perrin

Apache::SizeLimit Exit is Delayed

[Mod_perl Mailing List]

Hi,

I'm using Apache::SizeLimit (on both Solaris and Linux) and getting the
error_log entry:

[Tue Dec 11 15:01:19 2001] (2520) Apache::SizeLimit httpd process too big,
exiting at SIZE=44964 KB  SHARE=10900 KB  REQUESTS=389  LIFETIME=9505
seconds

But the child process often doesn't exit right away.  It may hang around
for a couple of minutes or even an hour with the message occuring with
every hit:

[Tue Dec 11 15:20:22 2001] (2520) Apache::SizeLimit httpd process too big,
exiting at SIZE=48852 KB  SHARE=10944 KB  REQUESTS=458  LIFETIME=10648
seconds

Eventually the child will exit.  (I'd like it to exit on the very first
occurrence.)

I've looked through the documentation and the archives and can't find a
solution to this.  Can anyone give me some insight?

Thanks!

Bob Foster

Re: anyone know a trick with displaying 401 error messages for top level protected sites?

[DJ \(David J Radunz\)]

Works fantasticaly!

thanks so much.

DJ

- Original Message -
From: "Rob Bloodgood" <[EMAIL PROTECTED]>
To: "DJ (David J Radunz)" <[EMAIL PROTECTED]>
Cc: "mod_perl" <[EMAIL PROTECTED]>
Sent: Wednesday, December 12, 2001 6:09 AM
Subject: RE: anyone know a trick with displaying 401 error messages for top
level protected sites?


>
> > for example if the protected url was http://www.site.com/ the user
> > would be redirected to http://www.site.com/error/401 for the error
> > message.. and because its protected wouldnt display the custom error
> > page instead displaying the following error "Additionally, a 401
> > Authorization Required error was encountered while trying to use an
> > ErrorDocument to handle the request.". Which i can understand.
>
>
> How about
> Put your 401 html page into a directory like /error.
> Set the PerlAuthenHandler for /error to Apache::Constants::OK:
>
> 
> AuthType Basic
> PerlAuthenHandler Apache::Constants::OK
>
> # This 'require' is actually required. :-)
> require valid-user
> 
>
> Do the same for the dir where any/all of its images are located
> -- or --
> Put the images specific to the 401 handler in /error.
>
> That should do it.
> (but I haven't tested it, so YMMV :-).
>
>
> L8r,
> Rob
>
> #!/usr/bin/perl -w
> use Disclaimer qw/:standard/;
>
>

Case of the Vanishing Symbol Tables

[Stephen Clouse]

With the PerlModule/%INC problem recently being rehashed, here's another one 
involving PerlModule vs. use that will really bake your noodle.

Attached is a full mod_perl trace, where I hacked into perl_require_module a 
dump of one of my vanishing namespaces on each module load.  So you can 
definitely see it's loading up properly.  All is well until you reach the end, 
where it starts reloading everything, and the namespace is now completely gone.  
Exporter predictably throws an error at this point (since @EXPORT_OK is now 
undefined) and the server fails to start.  OTOH, one wonders how Exporter got 
the call, since @ISA is gone as well.

I posted this once before and got blown off -- a pox on to those who tell me to 
check @INC or what not.  There is nothing wrong with my code or my setup -- the 
only change I have to make to get things working is to `use` all the PerlModule 
modules in startup.pl first, before they're called with PerlModule.  And don't 
tell me to just use `use` either -- they all load up Apache config directives, 
so PerlModule has to be called at some point so Apache recognizes the 
directives.  But if things were working as advertised, PerlModule would be all I 
need.

The two obvious questions:

1) Where the fsck did everything go?
2) Why does this only emanate when stuff is loaded up via PerlModule?  I mean, 
   look at perl_require_module -- all it does is `eval "require $foo"`.  Hard to 
   go wrong there.

-- 
Stephen Clouse <[EMAIL PROTECTED]>
Senior Programmer, IQ Coordinator Project Lead
The IQ Group, Inc. 


perl_parse args: '/dev/null' ...allocating perl interpreter...ok
constructing perl interpreter...ok
ok
running perl interpreter...ok
mod_perl: 0 END blocks encountered during server startup
PerlRequire: arg=`/opt/apache/conf/mod_perl.startup.pl'
attempting to require `/opt/apache/conf/mod_perl.startup.pl'
loading perl module 'Apache'...Dump of IQGroup::Core::Utility namespace:
$VAR1 = {};
loading perl module 'Apache::Constants::Exports'...Dump of IQGroup::Core::Utility 
namespace:
$VAR1 = {};
ok
ok
PerlModule: arg='IQGroup'
loading perl module 'IQGroup'...Dump of IQGroup::Core::Utility namespace:
$VAR1 = {};
fetching PerlChildInitHandler stack
PerlChildInitHandler handlers stack undef, creating
pushing CODE ref into `PerlChildInitHandler' handlers
ok
loading perl module 'Apache'...Dump of IQGroup::Core::Utility namespace:
$VAR1 = {
  'import' => *IQGroup::Core::Utility::import,
  'EXPORT_FAIL' => *IQGroup::Core::Utility::EXPORT_FAIL,
  'iqsprintf' => *IQGroup::Core::Utility::iqsprintf,
  'is_spider_or_bot' => *IQGroup::Core::Utility::is_spider_or_bot,
  'VERSION' => *IQGroup::Core::Utility::VERSION,
  'ISA' => *IQGroup::Core::Utility::ISA,
  'EXPORT' => *IQGroup::Core::Utility::EXPORT,
  'commify' => *IQGroup::Core::Utility::commify,
  'htmlize_nowrap' => *IQGroup::Core::Utility::htmlize_nowrap,
  'htmlize' => *IQGroup::Core::Utility::htmlize,
  'EXPORT_OK' => *IQGroup::Core::Utility::EXPORT_OK,
  'BEGIN' => *IQGroup::Core::Utility::BEGIN,
  'EXPORT_TAGS' => *IQGroup::Core::Utility::EXPORT_TAGS
};
ok
PerlModule: arg='IQGroup::IQCoordinator'
loading perl module 'IQGroup::IQCoordinator'...Dump of IQGroup::Core::Utility 
namespace:
$VAR1 = {
  'import' => *IQGroup::Core::Utility::import,
  'EXPORT_FAIL' => *IQGroup::Core::Utility::EXPORT_FAIL,
  'iqsprintf' => *IQGroup::Core::Utility::iqsprintf,
  'is_spider_or_bot' => *IQGroup::Core::Utility::is_spider_or_bot,
  'VERSION' => *IQGroup::Core::Utility::VERSION,
  'ISA' => *IQGroup::Core::Utility::ISA,
  'EXPORT' => *IQGroup::Core::Utility::EXPORT,
  'commify' => *IQGroup::Core::Utility::commify,
  'htmlize_nowrap' => *IQGroup::Core::Utility::htmlize_nowrap,
  'htmlize' => *IQGroup::Core::Utility::htmlize,
  'EXPORT_OK' => *IQGroup::Core::Utility::EXPORT_OK,
  'BEGIN' => *IQGroup::Core::Utility::BEGIN,
  'EXPORT_TAGS' => *IQGroup::Core::Utility::EXPORT_TAGS
};
ok
loading perl module 'Apache'...Dump of IQGroup::Core::Utility namespace:
$VAR1 = {
  'import' => *IQGroup::Core::Utility::import,
  'EXPORT_FAIL' => *IQGroup::Core::Utility::EXPORT_FAIL,
  'iqsprintf' => *IQGroup::Core::Utility::iqsprintf,
  'is_spider_or_bot' => *IQGroup::Core::Utility::is_spider_or_bot,
  'VERSION' => *IQGroup::Core::Utility::VERSION,
  'ISA' => *IQGroup::Core::Utility::ISA,
  'EXPORT' => *IQGroup::Core::Utility::EXPORT,
  'commify' => *IQGroup::Core::Utility::commify,
  'htmlize_nowrap' => *IQGroup::Core::Utility::htmlize_nowrap,
  'htmlize' => *IQGroup::Core::Utility::htmlize,
  'EXPORT_OK' => *IQGroup::Core::Utility::EXPORT_OK,
  'BEGIN' => *IQGroup::Core::Utility::BEGIN,
  'EXPORT_TAGS' => *I

RFC: CGI vs. Apache Namespace Question

[Thomas Klausner]

Hi!

I've got a small CPAN Namespace Question:

Some time ago I wrote CGI::URI2param (
http://search.cpan.org/search?mode=module&query=URI2param
).

Now, thanks to an idea by darren chamberlain, I wrote a small
PerlInitHandler that does nothing more than parse some PerlSetVars and then
call uri2param(). But still it is very convienient to use it like this.

So should I:
1* put the Apache Handler into CGI::URI2param, which maybe is some sort of
Namespace violation (you'd have to say 
  PerlInitHandler CGI::URI2param
in httpd.conf)
  
2* create a new module, Apache::URI2param, which only contains the config
parsing stuff and requires CGI::URI2param. This would result in two small
modules cluttering CPAN, where one of those (Apache::URI2param) is useless
without the other

3* dump CGI::URI2param in favour of Apache::URI2param, which wouldn't make
much sense either, because the code does not depend on mod_perl (and not
even on Apache)

4* let the users write there own handlers

I tend to use solution 1, but if you would like to comment on this, I would 
really appreciate some feedback!


-- 
 D_OMM  +>  http://domm.zsi.at <-+
 O_xyderkes |   neu:  Arbeitsplatz   |   
 M_echanen  | http://domm.zsi.at/d/d162.html |
 M_asteuei  ++

RE: Auth Handlers

[Stathy Touloumis]

Actually, I DON'T want the browser to prompt for a username/pass.  I saw the
examples in the eagle book and they all seem to use Authz, with Auth
handlers using the example you showed.
Perhaps I need to modify the headers so that the prompt does not occur?

Thanks for the info,

> -Original Message-
> From: Rob Bloodgood [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 11, 2001 12:54 PM
> To: Stathy Touloumis
> Cc: mod_perl
> Subject: RE: Auth Handlers
>
>
> > : )  No problem,  I guess I am unsure if this is the proper way
> > to setup an
> > Access, Authen, Authz handler.  When I use this configuration my
> > 'handler()'
> > method does not get called and I get an error in the logs:
>
> This is *not* the correct way to invoke it.
>
> > > > 
> > > > AuthName "Login"
>
> # This is incorrect
> #  AuthType Base::Session::Handler
>
> # *This* is what you need if you want the
> # browser to prompt for a username/pass
>   AuthType Basic
> > > > require valid-user
> > > >
> > > > PerlAuthenHandler Base::Session::Handler
> > > > 
>
>
> I just checked my answers from the Eagle (Writing Apache Modules with Perl
> and C), and that's the correct way.  If I'm not mistaken, the chapter on
> Authentication is one of the sample chapters that's online at
> http://www.modperl.com.  Have a look over there, it'll straighten
> you right
> out. :-)
>
> L8r,
> Rob
>
> #!/usr/bin/perl -w
> use Disclaimer qw/:standard/;
>
>
>

RE: anyone know a trick with displaying 401 error messages for top level protected sites?

[Rob Bloodgood]

> for example if the protected url was http://www.site.com/ the user
> would be redirected to http://www.site.com/error/401 for the error
> message.. and because its protected wouldnt display the custom error
> page instead displaying the following error "Additionally, a 401
> Authorization Required error was encountered while trying to use an
> ErrorDocument to handle the request.". Which i can understand.


How about 
Put your 401 html page into a directory like /error.
Set the PerlAuthenHandler for /error to Apache::Constants::OK:


AuthType Basic
PerlAuthenHandler Apache::Constants::OK

# This 'require' is actually required. :-)
require valid-user


Do the same for the dir where any/all of its images are located 
-- or -- 
Put the images specific to the 401 handler in /error.

That should do it.
(but I haven't tested it, so YMMV :-).


L8r,
Rob

#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
 

RE: Auth Handlers

[Rob Bloodgood]

> : )  No problem,  I guess I am unsure if this is the proper way
> to setup an
> Access, Authen, Authz handler.  When I use this configuration my
> 'handler()'
> method does not get called and I get an error in the logs:

This is *not* the correct way to invoke it.

> > > 
> > > AuthName "Login"

# This is incorrect
#  AuthType Base::Session::Handler

# *This* is what you need if you want the
# browser to prompt for a username/pass
AuthType Basic
> > > require valid-user
> > >
> > > PerlAuthenHandler Base::Session::Handler
> > > 


I just checked my answers from the Eagle (Writing Apache Modules with Perl
and C), and that's the correct way.  If I'm not mistaken, the chapter on
Authentication is one of the sample chapters that's online at
http://www.modperl.com.  Have a look over there, it'll straighten you right
out. :-)

L8r,
Rob

#!/usr/bin/perl -w
use Disclaimer qw/:standard/;

Re: Q - Apache::Request->new(undef) works?

[darren chamberlain]

Jay Lawrence <[EMAIL PROTECTED]> said something to this effect on 12/11/2001:
> In my development I neglected to supply the Apache request
> object when I called Apache::Request->new( $r ). Actually $r
> was undef. It still works! I am just wondering if this is
> expected behaviour and if it will be supported going forward or
> was this just a fluke?

The Apache instance that gets passed to Apache::Request::new
apepars to not be required:

# From libapreq-0.33/Request/Request.xs:
165 static ApacheRequest *sv_2apreq(SV *sv)
166 {
167 if (SvROK(sv) && sv_derived_from(sv, "Apache::Request")) {
168 SV *obj = sv;
169 
*snip*
179 return (ApacheRequest *)SvIV((SV*)SvRV(obj));
180 }
181 else {
182 return ApacheRequest_new(perl_request_rec(NULL));
183 }
184 }

perl_request_rec is defined in mod_perl/src/modules/perl/mod_perl.c
(from the mod_perl distribution); it sets the static IV
mp_request_rec to a request_rec:

# mod_perl/src/modules/perl/mod_perl.c:
 66 static IV mp_request_rec;
   1685 request_rec *perl_request_rec(request_rec *r)
   1686 {
   1687 if(r != NULL) {
   1688 mp_request_rec = (IV)r;
   1689 return NULL;
   1690 }
   1691 else
   1692 return (request_rec *)mp_request_rec;
   1693 }

So, at least with the current versions of mod_perl (1.26) and
libapreq (0.33), not passing Apache->request to
Apache::Request::new seems safe.

(darren)

-- 
Democracy is a form of government that substitutes election by the
incompetent many for appointment by the corrupt few.
-- George Bernard Shaw

Re: [modperl site design challenge] please vote

[Stas Bekman]

This is just a reminder that we need your votes. So far we have about 
130 votes. Please help us to choose.

Stas Bekman wrote:

> Thomas Klausner, Allan Juul and Carlos Ramirez have answered the 
> challenge and submitted their modperl site designs. Thank you folks!
> 
> Now it's a time for you to chose the design that you like the most by 
> voting at http://www.tohubohu.net/cgi/mpchallenge
> 
> In order to let everybody enough time to vote, the votes will be 
> collected in 12 days from this announce, i.e. Monday December 17.
> 
> Notice that in order to avoid cheating please submit your email address 
> along with your vote. At the end of the voting process, only votes with 
> email addresses matching the modperl list's subscribers list will be 
> considered as valid. That's why you cannot see the current votes' spread.
> 
> If you want to add some notes (how to improve things, etc), please add 
> these when you vote in the 'comments' field.
> 
> If you have any problems with voting email me directly, and not the list.
> 
> Thanks to Eric Cholet for providing this voting script and hosting it.
> 
> Thanks to Nathan Torkington for pushing for the site's change :)
> 
> _
> Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
> http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
> mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
> http://singlesheaven.com http://perl.apache.org http://perlmonth.com/



-- 


_
Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

RE: Auth Handlers

[Stathy Touloumis]

: )  No problem,  I guess I am unsure if this is the proper way to setup an
Access, Authen, Authz handler.  When I use this configuration my 'handler()'
method does not get called and I get an error in the logs:
[Mon Dec 10 13:13:03 2001] [crit] [client 192.168.0.1] configuration error:
couldn't check user.  No user file?: /index.html

I tried moving it down to be an Authz handler but the same error occurs.
However, if I push this package as a FixupHandler it works fine and the
'handler()' method gets called.

Thanks,

> -Original Message-
> From: Ged Haywood [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 10, 2001 7:16 PM
> To: Stathy Touloumis
> Cc: mod_perl List
> Subject: RE: Auth Handlers
>
>
> On Mon, 10 Dec 2001, Stathy Touloumis wrote:
>
> > 
> > AuthName "Login"
> > AuthType Base::Session::Handler
> > require valid-user
> >
> > PerlAuthenHandler Base::Session::Handler
> > 
>
> Forgive me, it's late, and I'm afraid I've deleted the original
> question.  But there isn't much here to go on...
>
> 73,
> Ged.
>

Re: Defeating mod_perl Persistence

[ed phillips]

Ged Haywood wrote:
> 
> Hi there,
> 
> On Tue, 11 Dec 2001, Jonathan M. Hollin wrote:
> 
> > When using Mail::Sender only the first email is sent on my mod_perl server.
> > When I investigated, I realised that the socket to the SMTP server was
> > staying open after the completion of that first email (presumably mod_perl
> > is responsible for this persistence).
> >
> > Is there any way to defeat the persistence on the socket while running my
> > script under mod_perl, or do such scripts always need to be mod_cgi?
> 
> The idea is for the mod_perl process to complete its job and get on
> with another as quickly as possible.  Waiting around for nameserver
> timeouts and such doesn't help things.
> 
> You might be better off re-thinking the design for use under mod_perl.
> This is a well-trodden path, have a browse through the archives.
> 

Yes, this has come up before. Ideally you want to separate out your mail
service and pass your mails to a queue. Then, wholly independent of your
app, your smtp server can negotiate with remote hosts and generally do
its thing. That is, you shouldn't even make your app wait for your SMTP
server to send an email before you free it to handle the next request.
This is analagous to using a proxy server to handle slowish clients. See
the guide, archives.


Ed

Re: Defeating mod_perl Persistence

[[EMAIL PROTECTED]]

should one not unlink() after the close?

> > When using Mail::Sender only the first email is sent on my mod_perl
> server.
> > When I investigated, I realised that the socket to the SMTP server was
> > staying open after the completion of that first email (presumably mod_perl
> > is responsible for this persistence).
> >
> > Is there any way to defeat the persistence on the socket while running my
> > script under mod_perl, or do such scripts always need to be mod_cgi?
> 
> You're probably storing it in a global so it never gets cleaned up.  Don't
> do that.
> - Perrin
> 

Re: Q - Apache::Request->new(undef) works?

[Joe Schaefer]

"Jay Lawrence" <[EMAIL PROTECTED]> writes:

> In my development I neglected to supply the Apache request object when
> I called Apache::Request->new( $r ). Actually $r was undef. It still
> works! I am just wondering if this is expected behaviour and if it
> will be supported going forward or was this just a fluke?

I'd say it's a fluke- $r needs to be attached somehow to the actual
request object; otherwise I think you're introducing a memory leak 
and/or possibly a segfault.  Unless Doug says otherwise, I wouldn't 
rely on this behavior for an undef'd arg to Apache::Request::new.

-- 
Joe Schaefer

Re: chroot .. jail2 || other .pm ?

[Geoffrey Young]

"[EMAIL PROTECTED]" wrote:
> 
> hi,
>   Was digging around CPAN looking for a module that would
> allow the following..
> 
> user is authenticated .. via web.. ok got that..
> If they are successful that are
> chroot or jailed or caged in a specific
> directory which becomes their root..
> eg ..
> $HOME/public_html
> which is ln || lndir to
> /var/www/htdocs/userdomain

well, you can change document_root on a per-request basis using
$r->document_root(), but its a bit hairy (since DocumentRoot is a
per-server attribute and not a per-request attribute).  make sure you
understand the full implications of doing so before you tread there...

HTH

--Geoff

> 
> That way they get only very limited access to their account..
> They can see their html .. js .. etc files and upload them
> and that is it.. They can't see anything below /var/www/userdomain
> I hope i have been clear and this is the right list to ask modperl
> questions apache related.
> 
> TIA
> 
> Best Regards

Re: Preloading Fcntl.pm

[Stas Bekman]

Andrew Green wrote:

> In article <[EMAIL PROTECTED]>,
>Stas Bekman <[EMAIL PROTECTED]> wrote:
> 
> 
>>Weird, what Perl version are you using? Can you do:
>>
> 
>>perl -MFcntl -le1
>>or
>>perl -le 'require Fcntl'
>>
> 
> Both seem to work (producing no output, but no errors either).  The
> *really* peculiar thing is that actual scripts that "use Fcntl" work with
> no problems -- but I can't preload the module, or preload other modules
> that use it.
> 
> According to /perl-status, I'm using perl 5.00503 for Apache 1.3.19 on
> Red Hat 6.2, mod_perl 1.21.  On processes that have accessed these
> scripts, Fcntl shows up on /perl-status?inc and claims to be version 1.03.
> 
> If it's any help, HTML::Entities displays exactly the same behaviour (and
> claims to be version 1.22).

Hmm, how about upgrading modperl?

May be it has something to do with the module getting loaded twice 
(since Apache restarts)? I see that HTML::Entities runs code on require 
and loads .so, the same goes for Fcntl; I'm not sure whether this 
$Apache::Server::ReStarting flag was available at mod_perl 1.21 (Check 
the Changes file), but if it does try to do this:

if ( $Apache::Server::ReStarting ) {
   require Fcntl;
}


_
Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

chroot .. jail2 || other .pm ?

[[EMAIL PROTECTED]]

hi,
  Was digging around CPAN looking for a module that would 
allow the following..

user is authenticated .. via web.. ok got that..
If they are successful that are 
chroot or jailed or caged in a specific 
directory which becomes their root..
eg ..
$HOME/public_html
which is ln || lndir to 
/var/www/htdocs/userdomain

That way they get only very limited access to their account..
They can see their html .. js .. etc files and upload them
and that is it.. They can't see anything below /var/www/userdomain
I hope i have been clear and this is the right list to ask modperl
questions apache related. 

TIA 

Best Regards

Re: Defeating mod_perl Persistence

[Perrin Harkins]

> When using Mail::Sender only the first email is sent on my mod_perl
server.
> When I investigated, I realised that the socket to the SMTP server was
> staying open after the completion of that first email (presumably mod_perl
> is responsible for this persistence).
>
> Is there any way to defeat the persistence on the socket while running my
> script under mod_perl, or do such scripts always need to be mod_cgi?

You're probably storing it in a global so it never gets cleaned up.  Don't
do that.
- Perrin

Re: Preloading Fcntl.pm

[Stas Bekman]

Jean-Michel Hiver wrote:

>>>Wouldn't that affect mod_perl's advantage of sharing the modules? I
>>>mean, would everything be in it's separate namespace and loaded only
>>>once for every module as it is with use?
>>>
> 
> I don't know about you guys, but I don't feel that sharing the modules
> is that much of an advantage. 


It is. It can save you a lot of memory. Check the numbers in the 
performance and scenario chapters of the mod_perl guide.

> If you write large scripts that actually
> use modules of your own which can be different depending on the version
> of the script, it means that you cannot run different versions of the
> script on the same box, which IMHO is not very convenient...


But this has nothing to do with sharing. You've this problem when you 
share or not. modperl-2.0 solves this problem. In 1.x you have to use 
various workarounds, some of the are explained in the guide.


> Do you know if there's a way to avoid this?
> Cheers,
> 



-- 


_
Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

Re: Apache::can_stack_handlers()

[Geoffrey Young]

Issac Goldstand wrote:
> 
> What version of mod_perl starts supporting this?

egads, that's old...

looks like 0.95

http://www.bitmechanic.com/mail-archives/modperl/Mar1997/0145.html

--Geoff

Apache::can_stack_handlers()

[Issac Goldstand]

What version of mod_perl starts supporting this?

  Issac

-- 
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
  --Anonymous

Moving the mouse won't get you into trouble...  Clicking it might.
  --Anonymous

PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B

Re: Defeating mod_perl Persistence

[Eric Cholet]

--On mardi 11 décembre 2001 12:25 + "Jonathan M. Hollin" 
<[EMAIL PROTECTED]> wrote:

> Hey Gang,
>
> When using Mail::Sender only the first email is sent on my mod_perl
> server. When I investigated, I realised that the socket to the SMTP
> server was staying open after the completion of that first email
> (presumably mod_perl is responsible for this persistence).
>
> Is there any way to defeat the persistence on the socket while running my
> script under mod_perl, or do such scripts always need to be mod_cgi?
>
> FYI, the script works fine under mod_cgi.

maybe you should just call Close() on the Mail::Sender object,
from the docs:

 Close
  $sender->Close;

 Close and send the mail. This method should be called
 automatically when destructing the object, but you
 should call it yourself just to be sure it gets called.
 And you should do it as soon as possible to close the
 connection and free the socket.

 The mail is being sent to server, but is not processed
 by the server till the sender object is closed!

--
Eric Cholet

Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler

[Geoffrey Young]

Paul Lindner wrote:
> 
[snip]
> 
> I suppose that one could put the whole uri->cachefile mapping into a
> custom PerlTransHandler and leave Apache::CacheContent as-is..

yeah, I think that we're starting to talk about two different
approaches now.  the cool thing about the current logic is that no
filename mapping has to take place making it rather fast - basically,
after a simple call to some cached stat() properties and you're done,
Apache's native translation mechanism has done all the work.  the
price you pay for that quick simplicity is stuff written to your
document root.  adding a URI->filename translation step adds overhead,
though it may be preferable to some.  it shouldn't be a requirement,
however.

one of the neat things is about this module is that it makes (pretty
creative) use of method handlers.  the base class comes with
disk_cache(), but memory_cache(), uri_cache(),
i_dont_want_the_file_in_my_docroot_cache(), or whatever can be added
either to the module proper or a subclass.  

so, maybe disk_cache() needs a better and less generic name, like
docroot_cache().

--Geoff

Re: Preloading Fcntl.pm

[Jean-Michel Hiver]

>> Wouldn't that affect mod_perl's advantage of sharing the modules? I
>> mean, would everything be in it's separate namespace and loaded only
>> once for every module as it is with use?

I don't know about you guys, but I don't feel that sharing the modules
is that much of an advantage. If you write large scripts that actually
use modules of your own which can be different depending on the version
of the script, it means that you cannot run different versions of the
script on the same box, which IMHO is not very convenient...

Do you know if there's a way to avoid this?
Cheers,
-- 
IT'S TIME FOR A DIFFERENT KIND OF WEB

  Jean-Michel Hiver - Software Director
  [EMAIL PROTECTED]
  +44 (0)114 221 4968

  VISIT HTTP://WWW.MKDOC.COM

Re: Defeating mod_perl Persistence

[Ged Haywood]

Hi there,

On Tue, 11 Dec 2001, Jonathan M. Hollin wrote:

> When using Mail::Sender only the first email is sent on my mod_perl server.
> When I investigated, I realised that the socket to the SMTP server was
> staying open after the completion of that first email (presumably mod_perl
> is responsible for this persistence).
> 
> Is there any way to defeat the persistence on the socket while running my
> script under mod_perl, or do such scripts always need to be mod_cgi?

The idea is for the mod_perl process to complete its job and get on
with another as quickly as possible.  Waiting around for nameserver
timeouts and such doesn't help things.

You might be better off re-thinking the design for use under mod_perl.
This is a well-trodden path, have a browse through the archives.

73,
Ged.

Defeating mod_perl Persistence

[Jonathan M. Hollin]

Hey Gang,

When using Mail::Sender only the first email is sent on my mod_perl server.
When I investigated, I realised that the socket to the SMTP server was
staying open after the completion of that first email (presumably mod_perl
is responsible for this persistence).

Is there any way to defeat the persistence on the socket while running my
script under mod_perl, or do such scripts always need to be mod_cgi?

FYI, the script works fine under mod_cgi.

Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/

Q - Apache::Request->new(undef) works?

[Jay Lawrence]

Howdy!
 
In my development I neglected to supply the Apache 
request object when I called Apache::Request->new( $r ). Actually $r was 
undef. It still works! I am just wondering if this is expected behaviour and if 
it will be supported going forward or was this just a 
fluke?Thanks,
J

Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler

[DeWitt Clinton]

On Tue, Dec 11, 2001 at 02:31:36AM -0800, Paul Lindner wrote:

> Right.  A more elaborate Apache::CacheContent would have a filename
> hash function, and a separate cache directory structure along the
> lines of Cache::FileCache.

Just curious -- any reason not to use Cache::Cache as the persistance
mechanism?  It was designed for exactly this scenario and could
provide a nice abstraction for the filesystem or shared memory, as
well as handle things like filename hashing and branching directories
(and namespaces, size limits, OS independance, taint checking, and
more).

-DeWitt

Re: Preloading Fcntl.pm

[Jorge Godoy]

Stas Bekman <[EMAIL PROTECTED]> writes:

> Jorge Godoy wrote:
>
>> Stas Bekman <[EMAIL PROTECTED]> writes:
>>
>>>I think the general advise is to always call require() and not use()
>>>in startup.pl, unless you have a reason for calling certain modules'
>>>import() method.
>>>
>> Wouldn't that affect mod_perl's advantage of sharing the modules? I
>> mean, would everything be in it's separate namespace and loaded only
>> once for every module as it is with use?
>
>
> Please read the doc for use().



I stand corrected. 

I read it just after sending that message. My fingers were faster on
the e-mail than on the docs. Sorry :-)



See you,
-- 
Godoy. <[EMAIL PROTECTED]>

Solutions Developer   - Conectiva Inc. - http://en.conectiva.com
Desenvolvedor de Soluções - Conectiva S.A. - http://www.conectiva.com.br


msg23409/pgp0.pgp
Description: PGP signature

Re: Preloading Fcntl.pm

[Andrew Green]

In article <[EMAIL PROTECTED]>,
   Stas Bekman <[EMAIL PROTECTED]> wrote:

> Weird, what Perl version are you using? Can you do:

> perl -MFcntl -le1
> or
> perl -le 'require Fcntl'

Both seem to work (producing no output, but no errors either).  The
*really* peculiar thing is that actual scripts that "use Fcntl" work with
no problems -- but I can't preload the module, or preload other modules
that use it.

According to /perl-status, I'm using perl 5.00503 for Apache 1.3.19 on
Red Hat 6.2, mod_perl 1.21.  On processes that have accessed these
scripts, Fcntl shows up on /perl-status?inc and claims to be version 1.03.

If it's any help, HTML::Entities displays exactly the same behaviour (and
claims to be version 1.22).

Cheers,
Andrew.

-- 
   ::
  article seven  Andrew Green
 automatic internet  [EMAIL PROTECTED] | www.article7.co.uk

Re: Preloading Fcntl.pm

[Stas Bekman]

Andrew Green wrote:

> In article <[EMAIL PROTECTED]>,
>Stas Bekman <[EMAIL PROTECTED]> wrote:
> 
> 
>>Try to call:
>>require Fcntl;
>>instead.
>>
> 
> Thanks for the tip.  I'm afraid the above verbatim produces the following
> error on restart:
> 
> | Shutting down http:[  OK  ]
> | Starting httpd: [Mon Dec 10 20:41:18 2001] [error] syntax error at
> | /etc/httpd/lib/perl/modperl.pl line 14, near "require Fcntl"
> | BEGIN not safe after errors--compilation aborted at
> | /etc/httpd/lib/perl/modperl.pl line 15.
> | Syntax error on line 395 of /etc/httpd/conf/httpd.conf:
> | syntax error at /etc/httpd/lib/perl/modperl.pl line 14, near "require
> | Fcntl"
> | BEGIN not safe after errors--compilation aborted at
> | /etc/httpd/lib/perl/modperl.pl line 15.
> |   [FAILED]


Weird, what Perl version are you using? Can you do:

perl -MFcntl -le1

or

perl -le 'require Fcntl'

I've tested with 5.6.1, it works.

 
> I should note that /etc/httpd/lib/perl/modperl.pl is my startup script,
> and that line 395 of httpd.conf is the PerlRequire directive.  Beyond
> that, I'm not at all sure whether the above is especially instructive.
> 
> Changing the startup script to:
> 
>  require "Fcntl.pm";
> 
> instead avoids the error, but displays the same
> "pretends-to-restart-OK-but-actually-doesn't" behaviour I described
> before.  I should also mention that trying a PerlModule directive instead
> doesn't help either.
> 
> It's very bewildering!



_
Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

(fwd) [ANNOUNCE] Module::Info 0.09

[Stas Bekman]

[This seems to be a very useful module for those who try to minimize the 
memory usage, by finding out irrelevant modules loaded without your 
consent :)

Michael G Schwern said:

Module::Use appears to use the "let's sniff through %INC" approach,
which is clever and useful and sometimes more accurate, but requires
you actually run the program/module.

Module::Info uses the backend compiler.  It compiles the module but
doesn't not run it.  It finds all 'use' and 'require' statements using
the opcode tree.  As a result its perfectly accurate, except it can't
see things inside an eval().  Module::Use can.

The other nice thing Module::Info does (err, will do) is tell you one
what line and file module was used.  Useful for refactoring and
figuring out what uses what.
]

Michael G Schwern has then announced at [EMAIL PROTECTED]:

[I've fixed the message as Michael, has just released 0.09, the original 
announcement was for 0.08.]

This is the Egg Shen release [1] of Module::Info.
http://www.pobox.com/~schwern/src/Module-Info-0.09.tar.gz

This release adds modules_used().  Tells you all the modules and files
required or used by the module in question using the backend compiler.
As such its more reliable than a regex-based one.

modules_used
  my @used = $module->modules_used;

Returns a list of all modules and files which may be
"use"'d or "require"'d by this module.

NOTE These modules may be conditionally loaded, can't
tell.  Also can't find modules which might be used
inside an "eval".

I had to do some severe cargo-cultery from B::Deparse to make this
work.  If anyone's curious they can look at B::Module::Info, but I'd
recommend against it.

This method simply returns a list of all the modules used.  I plan on
providing another method which provides additional info such as where
each is used, how many times and if it was required as a bareword or
not (ie. "require Foo" vs "require 'Foo.pm'").  I've got all that
information internally, just need to put an interface on it.
That should make the refactoring folks happy.


0.08  Mon Dec 10 14:24:56 EST 2001
 * Implemented modules_used()
 - Fixed a little bug in walkoptree_filtered() and $B::Utils::file/line

0.07  Mon Dec 10 11:09:40 EST 2001
 * Implemented subroutines().  Need help getting modules_used() done.
 - Fixed up $B::Utils::file/line handling in B::Utils.
 - Fixed a little bug in is_core involving cannonical paths.
   I forget who gave me the patch!




-- 


_
Stas Bekman JAm_pH  --   Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide   http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler

[Paul Lindner]

On Tue, Dec 11, 2001 at 01:50:52AM -0800, Ask Bjoern Hansen wrote:
> On Thu, 6 Dec 2001, Paul Lindner wrote:
> 
> > > BTW -- I think where the docs are cached should be configurable.  I don't
> > > like the idea of the document root writable by the web process.
> > 
> > That's the price you pay for this functionality.  Because we use
> > Apache's native file serving code we need a url->directory mapping
> > somewhere.
> 
> uh, why couldn't Apache::CacheContent just set 
> $r->filename("/where/we/put/the/cache/$file") ?

Simplicity really.  This was an example in our upcoming book so I
didn't want to add a filename generator to the code, instead we use
Apache's url->file mapping mechanism.  Also this code was derived from
a 404 error handler that I wrote ages ago :)

I assume (since you suggested it) that you can set $r->filename to any
file in any directory without adding a  config?  I'll have
to see how this interacts with the built-in access control logic .

> If you add Bill's suggestion about caching on args, headers and
> whatnot you would (on some filesystems) need something like that
> anyway to make a hashed directory tree.

Right.  A more elaborate Apache::CacheContent would have a filename
hash function, and a separate cache directory structure along the
lines of Cache::FileCache.

I suppose that one could put the whole uri->cachefile mapping into a
custom PerlTransHandler and leave Apache::CacheContent as-is..

-- 
Paul Lindner   [EMAIL PROTECTED]| | | | |  |  |  |   |   |

mod_perl Developer's Cookbook   http://www.modperlcookbook.org
 Human Rights Declaration   http://www.unhchr.ch/udhr/index.htm

Re: Preloading Fcntl.pm

[Andrew Green]

In article <[EMAIL PROTECTED]>,
   Stas Bekman <[EMAIL PROTECTED]> wrote:

> Try to call:
> require Fcntl;
> instead.

Thanks for the tip.  I'm afraid the above verbatim produces the following
error on restart:

| Shutting down http:[  OK  ]
| Starting httpd: [Mon Dec 10 20:41:18 2001] [error] syntax error at
| /etc/httpd/lib/perl/modperl.pl line 14, near "require Fcntl"
| BEGIN not safe after errors--compilation aborted at
| /etc/httpd/lib/perl/modperl.pl line 15.
| Syntax error on line 395 of /etc/httpd/conf/httpd.conf:
| syntax error at /etc/httpd/lib/perl/modperl.pl line 14, near "require
| Fcntl"
| BEGIN not safe after errors--compilation aborted at
| /etc/httpd/lib/perl/modperl.pl line 15.
|   [FAILED]

I should note that /etc/httpd/lib/perl/modperl.pl is my startup script,
and that line 395 of httpd.conf is the PerlRequire directive.  Beyond
that, I'm not at all sure whether the above is especially instructive.

Changing the startup script to:

 require "Fcntl.pm";

instead avoids the error, but displays the same
"pretends-to-restart-OK-but-actually-doesn't" behaviour I described
before.  I should also mention that trying a PerlModule directive instead
doesn't help either.

It's very bewildering!

Cheers,
Andrew.

-- 
   ::
  article seven  Andrew Green
 automatic internet  [EMAIL PROTECTED] | www.article7.co.uk

Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler

[Ask Bjoern Hansen]

On Thu, 6 Dec 2001, Paul Lindner wrote:

> > BTW -- I think where the docs are cached should be configurable.  I don't
> > like the idea of the document root writable by the web process.
> 
> That's the price you pay for this functionality.  Because we use
> Apache's native file serving code we need a url->directory mapping
> somewhere.

uh, why couldn't Apache::CacheContent just set 
$r->filename("/where/we/put/the/cache/$file") ?

If you add Bill's suggestion about caching on args, headers and
whatnot you would (on some filesystems) need something like that
anyway to make a hashed directory tree.


 - ask

-- 
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
more than a billion impressions per week, http://valueclick.com