Re: [ANN] Testing Tool for mod_perl CGI Applications: Puffin

2002-05-05 Thread Mark Fowler

What's a mod_perl CGI Application?

:-)

Mark.

-- 
s''  Mark Fowler London.pm   Bath.pm
 http://www.twoshortplanks.com/  [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t-Tputs(cl);for$w(split/  +/
){for(0..30){$|=print$t-Tgoto(cm,$_,$y). $w;select$k,$k,$k,.03}$y+=2}




Re: Scope of Perl Special Variables

2002-05-05 Thread Bill Catlan

Stas Bekman wrote:

 This explains why by default %ENV is set for each request afresh.
 http://perl.apache.org/guide/performance.html#PerlSetupEnv_Off

Great.  Thank you Stas.  Now I know /how/ that happens, but I don't know /why/
the existing inctances' ENV is not clobbered.

My guess is that a localized copy of the %ENV variable is created by the above
referenced process, thus no clobbering of existing instances' %ENV occurs.
Would that be correct?

-Bill




Re: Scope of Perl Special Variables

2002-05-05 Thread Bill Catlan

 I thought that using 'local' would successfully scope those globals to
 within a sub, so you could,k for example, slurp an entire file by doing:

 local $/ = undef;
 my $file = FH;

 Or am I wrong in that?  I use it frequently, and don't seem to have any
 troubles.

 --Jon R.

It is my understanding that that is correct.  I am a novice at mod_perl, but
your experience would seem to match up with my understanding of the Guide.

Local would scope it to within the enclosing block; so you could scope a
variable within a bare block so that it would be local to you package, but
shareable between subs.

# $/ equals default, global value
{
local $/ = undef;

sub { ... # $/ equals undef }
sub { ... # $/ equals undef }
sub { local $/ = \n\n; # localized value for sub }

# $/ back to undef
}
# $/ back to default, global value

-Bill




Pb with Win32 Installation

2002-05-05 Thread Jean-Marc Paulin

Hi there,

I have downloaded the CSV Image file modperl-2.0_20020502042105.tar.gz and
tried to compile it for Apache 2.0.35.

The build is ok (or looks good anyway) but Apache dies during the nmake
test.

Any ideas ?

I do not mind trying to debug this, but I have no idea where to start
Any hint ?

thanks a lot

JM


=== stdout 

 D:\Perl\ModuleSetup\mod_perl\modperl-2.0nmake test

Microsoft (R) Program Maintenance Utility Version 7.00.9466
Copyright (C) Microsoft Corporation.  All rights reserved.

cd src/modules/perl  nmake

Microsoft (R) Program Maintenance Utility Version 7.00.9466
Copyright (C) Microsoft Corporation.  All rights reserved.

D:\Perl\bin\perl.exe -Iblib\arch -Iblib\lib  t/TEST -clean
  D:\Perl\bin\perl.exe -Iblib\arch -Iblib\lib  t/TEST
*** : cannot build c-modules without apxs
D:\Progra~1\Apache~1\Apache2/bin/Apache.exe  -d
D:/Perl/ModuleSetup/mod_perl/modperl-2.0/t -f
D:/Perl/ModuleSetup/mod_perl/modperl-2
.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS
using Apache/2.0.35 (winnt MPM)
waiting for server to start: 00:00[Thu May 02 22:12:24 2002] [info] 12
Apache:: modules loaded
[Thu May 02 22:12:24 2002] [info] 5 APR:: modules loaded
[Thu May 02 22:12:24 2002] [info] base server + 6 vhosts ready to run tests
[Thu May 02 22:12:24 2002] [info] 11 Apache:: modules loaded
[Thu May 02 22:12:24 2002] [info] 5 APR:: modules loaded
[Thu May 02 22:12:24 2002] [info] base server + 6 vhosts ready to run tests
waiting for server to start: 00:01END in modperl_extra.pl, pid=2284
END in modperl_extra.pl, pid=2284
END in modperl_extra.pl, pid=2284
END in modperl_extra.pl, pid=2284
END in modperl_extra.pl, pid=2284
END in modperl_extra.pl, pid=2284
END in modperl_extra.pl, pid=2284
waiting for server to start: ok (waited 2 secs)
server fox:8529 started
server fox:8530 listening (TestDirective::perlmodule)
server fox:8531 listening (TestDirective::perlrequire)
server fox:8532 listening (TestProtocol::echo)
server fox:8533 listening (TestProtocol::echo_filter)
server fox:8534 listening (TestProtocol::eliza)
server fox:8535 listening (TestFilter::input_msg)
apache\cgihandlerok
apache\compatok
apache\compat2...ok
apache\conftree..FAILED before any test output arrived
apache\constants.ok
apache\post..dubious
Test returned status 58 (wstat 14848, 0x3a00)
DIED. FAILED tests 1-2
Failed 2/2 tests, 0.00% okay
apache\read..*** :
halting tests
NMAKE : fatal error U1058: terminated by user
Stop.



Error.gif
Description: GIF image


Using a 404 ErrorDocument to serve content

2002-05-05 Thread Ken Williams

Hi,

I was thinking of writing yet-another-photo-album-server, and I 
had the idea that I'd write a handler to serve resized versions 
of JPEGs (very original, I know ;-).  The idea is that I'd put a 
bunch of JPEGs on the server at locations like foo/123.jpg , and 
then if a request came for foo/123-medium.jpg , I'd catch that 
with a 404 ErrorDocument and generate the resized image using 
Imager.  If I wanted to, I could also create the resized image 
on disk, so it wouldn't need to be generated next time.

Some questions arise, however.  I've got it working by setting 
$r-content_type(image/jpeg) in the 404 subrequest.  Should I 
also be setting $r-prev-content_type ?  Same question for 
$r-status and $r-prev-status.  It seems to be working 
either way, but I don't know what the proper thing to do is.

The idea is that I'm not just trying to give the user a friendly 
404 error message, I'm trying to fool the user into thinking the 
requested document really does exist.  I've done this a lot with 
Location and so on, but I don't think I've ever tried it with 
an ErrorDocument, so I'm interested in feedback.

  -Ken




Re: Can mod_perl help me use ENV variables in httpd.conf?

2002-05-05 Thread Jason Woodward

You'll also need to use a PerlPassEnv directive prior to your Perl block.

For debug purposes, try adding the following inside your Perl block:

print join(\n, map { $_ = $ENV{$_} } (keys %ENV)), \n;

OR, my personal quick-debugging catch-all:

use Data::Dumper;
print Dumper \%ENV;

You'll be able to see what is available in %ENV when running under 
mod_perl.  See also Chapter 9, page 498 of the Eagle.

jason

Ken Williams wrote:
 
 On Wednesday, May 1, 2002, at 05:04 AM, Fran Fabrizio wrote:
 

 I spoke too soon.

 I need:

 Perl
   push Alias, [ qw(/cgi-bin/chimpkit/ $ENV{SERVER_ROOT}/cgi-
 bin/chimpkit/) ];
 /Perl

 This does not appear to be possible because there's no way to pass in 
 SERVER_ROOT to the apache startup.
 
 
 I think the problem is your Perl syntax, not the value of the variable.  
 Scalars do not interpolate in qw() constructs.  Try this instead:
 
 Perl
   push Alias, '/cgi-bin/chimpkit/', $ENV{SERVER_ROOT}/cgi-
 bin/chimpkit/;
 /Perl
 
 or even
 
 Perl
   push Alias, '/cgi-bin/chimpkit/',
$r-server_root_relative . '/cgi-bin/chimpkit/';
 /Perl
 
  -Ken
 





question on apache::asp

2002-05-05 Thread minghong

So can I use this module to run asp.net on apache(installed on windows)?

I need to run asp.net on apache(windows).

Thanks.



Re: Scope of Perl Special Variables

2002-05-05 Thread Jon

I thought that using 'local' would successfully scope those globals to
within a sub, so you could,k for example, slurp an entire file by doing:

local $/ = undef;
my $file = FH;

Or am I wrong in that?  I use it frequently, and don't seem to have any
troubles.

--Jon R.

PGP Key fingerprint = 12 DA FC 06 AB 4C D6 A4  DE 03 E0 77 D6 DE E0 73
PGP public key available by fingering [EMAIL PROTECTED]

On Fri, 3 May 2002, Bill Catlan wrote:

 Hello,
 
 The online mod_perl guide
 (http://thingy.kcilink.com/modperlguide/perl/The_Scope_of_the_Special_Perl_Va.ht
 ml) states:
 
 Special Perl variables like $| (buffering), $^T (script's start time), $^W
 (warnings mode), $/ (input record separator), $\ (output record separator) and
 many more are all true global variables; they do not belong to any particular
 package (not even main::) and are universally available. This means that if you
 change them, you change them anywhere across the entire program; furthermore you
 cannot scope them with my().
 
 My question pertains the CGI %ENV hash.  First, I'm assumong that this is a
 global variable in the sense of a Perl Special Variable, and not just a main::
 or other package global.  My question is how is it the case that the %ENV
 variable script instance might be working with doesn't get clobbered or reset
 by the next incoming request.  Are some variables, like %ENV treated differently
 by mod_perl?
 
 Also, how can special variables be reliably initialized?  For example, if one
 request provides a certain attribute, such as HTTP_IDENT, but a subsequent
 request does not, how do I know that the value of $ENV{HTTP_IDENT} on the second
 request will indeed be undefined?
 
 Thanks.
 
 Bill
 
 




Re: question on apache::asp

2002-05-05 Thread Joshua Chamas

[EMAIL PROTECTED] wrote:
 
 So can I use this module to run asp.net on apache(installed on windows)?
 
 I need to run asp.net on apache(windows).
 

No.  Apache::ASP supports perl scripting for ASP v2.0 model.
ASP.net is not supported, nor C#, VBScript, etc.

-- Josh
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks Founder   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051



Re: Scope of Perl Special Variables

2002-05-05 Thread Mark Fowler

On Sun, 5 May 2002, Jon wrote:

 I thought that using 'local' would successfully scope those globals to
 within a sub, so you could,k for example, slurp an entire file by doing:
 
 local $/ = undef;
 my $file = FH;
 
 Or am I wrong in that?  I use it frequently, and don't seem to have any
 troubles.

Okay, local takes a temporary copy of the variable and then restores the
original value at the end of the block.  It's the same variable though. my
creates a new variable that is only visible from within the block and
can't be seen from other subroutines.  With my there are two variables 
that just happen to be called the same things, and which one you get 
depends if you're in within the enclosing block.

The difference is that when you use local any subroutines that you call
from within that subroutine will *also* see the variable.  With a 
my variable whatever you change can't be seen in other subroutines

The practical difference is if you set $/ and you call any routine from
within that same subroutine (that same block) they will also see the new 
version of $/.  This means that anything that you call from within that 
routine will also slurp in the whole file when it tries to read a line - 
if it was expecting it or not.

In terms of mod_perl this isn't so bad.  The local is fine when used in a 
subroutine like you described, as this subroutine will be exited by the 
time the handler returns, meaning you won't get any interaction between 
calls.

Of course there's still ways for you to screw yourself over with local, 
but used carefully it should be fine...

Later.

Mark.

-- 
s''  Mark Fowler London.pm   Bath.pm
 http://www.twoshortplanks.com/  [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t-Tputs(cl);for$w(split/  +/
){for(0..30){$|=print$t-Tgoto(cm,$_,$y). $w;select$k,$k,$k,.03}$y+=2}




Re: Pb with Win32 Installation

2002-05-05 Thread Randy Kobes

On Thu, 2 May 2002, Jean-Marc Paulin wrote:

 Hi there,

 I have downloaded the CSV Image file modperl-2.0_20020502042105.tar.gz and
 tried to compile it for Apache 2.0.35.

 The build is ok (or looks good anyway) but Apache dies during the nmake
 test.
[ .. ]
 apache\cgihandlerok
 apache\compatok
 apache\compat2...ok
 apache\conftree..FAILED before any test output arrived
 apache\constants.ok

As you're using the cvs mod_perl sources, it's probably a good
idea to also use the Apache cvs sources, to keep in sync with
changes. The above problem with apache\conftree doesn't occur for
me with the current cvs apache-2.0.37-dev.

best regards,
randy kobes




Re: Scope of Perl Special Variables

2002-05-05 Thread Stas Bekman

Bill Catlan wrote:
 Stas Bekman wrote:
 
 
This explains why by default %ENV is set for each request afresh.
http://perl.apache.org/guide/performance.html#PerlSetupEnv_Off
 
 
 Great.  Thank you Stas.  Now I know /how/ that happens, but I don't know /why/
 the existing inctances' ENV is not clobbered.
 
 My guess is that a localized copy of the %ENV variable is created by the above
 referenced process, thus no clobbering of existing instances' %ENV occurs.
 Would that be correct?

Can you send a reproducable example of a problem? For example this code 
does the right thing:

$r-send_http_header('text/plain');
print exists $ENV{FOO} ? $ENV{FOO}\n : NONE\n;
local $ENV{FOO} = BAR;
print exists $ENV{FOO} ? $ENV{FOO}\n : NONE\n;

it'll always print:
NONE
BAR

Make sure that you test under httpd -X mode so you won't get mislead.

__
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




localizing $dbh attributes with Apache::DBI to minimize the numberof connections made

2002-05-05 Thread Stas Bekman

Recently 5.8.0-tobe has fixed the leak with localization of tied hash 
values, so I'm fixing the following guide's section as follows. This is 
an important update, since the guide didn't say anything about $dbh attr 
changes affecting other handlers in the same process. Please review that 
everything is correct and I'll replace the old section with this one.

=head3 Opening Connections with Different Parameters

When CApache::DBI receives a connection request, before it decides
to use an existing cached connection it insists that the new
connection be opened in exactly the same way as the cached
connection. If you have one script that sets CAutoCommit and one
that does not, CApache::DBI will make two different connections.  So
if for example you have limited Apache to 40 servers at most, instead
of having a maximum of 40 open connections you may end up with 80.

So these two connect() calls will create two different connections:

   my $dbh = DBI-connect
   (DBI:mysql:test:localhost, '', '',
{
 PrintError = 1, # warn() on errors
 RaiseError = 0, # don't die on error
 AutoCommit = 1, # don't commit executes immediately
}
   ) or die Cannot connect to database: $DBI::errstr;

   my $dbh = DBI-connect
   (DBI:mysql:test:localhost, '', '',
{
 PrintError = 1, # warn() on errors
 RaiseError = 0, # don't die on error
 AutoCommit = 0, # don't commit executes immediately
}
   ) or die Cannot connect to database: $DBI::errstr;

Notice that the only difference is in the value of CAutoCommit.

However, you are free to modify the handle immediately after you get
it from the cache. So always initiate connections using the same
parameters and set CAutoCommit (or whatever) afterwards. Let's
rewrite the second connect call to do the right thing (not to create
a new connection):

   my $dbh = DBI-connect
   (DBI:mysql:test:localhost, '', '',
{
 PrintError = 1, # warn() on errors
 RaiseError = 0, # don't die on error
 AutoCommit = 1, # commit executes immediately
}
   ) or die Cannot connect to database: $DBI::errstr;
   $dbh-{AutoCommit} = 0; # don't commit if not asked to

When you aren't sure whether you're doing the right thing, turn debug
mode on.

However, when the C$dbh attribute is altered after connect() it
affects all other handlers retrieving this database handle. Therefore
it's the best to restore the modified attributes to their original
value at the end of database handle usage. As of CApache::DBI
version 0.88 the caller has to do it manually. The simplest way to
handle this is to localize the attributes when modifying them:

   my $dbh = DBI-connect(...) ...
   {
 local $dbh-{LongReadLen} = 40;
   }

Here the CLongReadLen attribute overrides the value set in the
connect() call or its default value only within the enclosing block.

The problem with this approach is that prior to Perl version 5.8.0
this causes memory leaks. So the only clean alternative for older Perl
versions is to manually restore the Cdbh's values:

   my @attrs = qw(LongReadLen PrintError);
   my %orig = ();

   my $dbh = DBI-connect(...) ...
   # store the values away
   $orig{$_} = $dbh-{$_} for @attrs;
   # do local modifications
   $dbh-{LongReadLen} = 40;
   $dbh-{PrintError}  = 1;
   # do something with the filehandle
   # ...
   # now restore the values
   $dbh-{$_} = $orig{$_} for @attrs;

Another thing to remember is that with some database servers it's
possible to access more than one database using the same database
connection. MySQL is one of those servers. It allows you to use a
fully qualified table specification notation. So if there is a
database Ifoo with a table Itest and database Ibar with its own
table Itest, you can always use:

   SELECT from foo.test ...

or:

   SELECT from bar.test ...

So no matter what database you have used in the database name string
in the connect() call (e.g.: CDBI:mysql:foo:localhost) you can still
access both tables by using a fully qualified syntax.

Alternatively you can switch databases with CUSE foo and CUSE bar,
but this approach seems less convenient, and therefore error-prone.

__
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