Re: Patch for easy testing of Apache::* modules (resend)
[EMAIL PROTECTED] (Doug MacEachern) wrote:
>On Mon, 17 Jul 2000, Ken Williams wrote:
>
>> Hi all,
>>
>> Here's a resend of the Apache::test patch that I sent yesterday, this
>> time sent as type text/plain from a Unix mailer. Rick Myers noted
>> that the version I sent before was encoded with Macintosh BinHex,
>> which is probably not the most appropriate choice for this list. ;-)
>
>looks great ken, applied, thanks!
>btw, when i first skimmed the patch, i thought it modified the
>mod_perl Makefile.PL test foo, which is why i was holding off.
In looking over the changes, I found that I've done a little more work
since the last patch I sent. I didn't send it on because I wasn't sure
whether the first patch would be accepted or not. Anyway, I beefed up
the fetch() method and documented it. It's fully backward compatible,
so no changes are necessary to existing code that calls fetch(). I also
added/fixed tiny pieces in my previous work here and there.
===
RCS file: /home/cvspublic/modperl/lib/Apache/test.pm,v
retrieving revision 1.17
diff -u -r1.17 test.pm
--- lib/Apache/test.pm 2000/09/28 21:16:13 1.17
+++ lib/Apache/test.pm 2000/10/02 05:38:43
@@ -57,7 +57,7 @@
User $args{user}
Group $args{group}
ServerName localhost
-DocumentRoot $DIR/t/eg
+DocumentRoot $DIR/t
$args{modules}
@@ -73,7 +73,10 @@
AddType text/html .html
# Look in ./blib/lib
-PerlModule ExtUtils::testlib
+#PerlModule ExtUtils::testlib
+
+ use lib "$DIR/blib/lib", "$DIR/t/lib";
+
$args{include}
EOF
@@ -82,6 +85,7 @@
}
sub _ask {
+# Just a function for asking the user questions
my ($prompt, $default, $mustfind) = @_;
my $response;
@@ -193,8 +197,8 @@
}
}
-
sub test {
+shift() if UNIVERSAL::isa($_[0], __PACKAGE__);
my $s = $_[1] ? "ok $_[0]\n" : "not ok $_[0]\n";
if($ENV{MOD_PERL}) {
Apache->request->print($s);
@@ -205,21 +209,26 @@
}
sub fetch {
-my($ua, $url);
-if(@_ == 1) {
- $url = shift;
- $ua = $UA;
-}
-else {
- ($ua, $url) = @_;
-}
-unless ($url =~ /^http/) {
- $url = "http://$net::httpserver${url}";
-}
+# Old code calls fetch() as a function, new code as a method
+shift() if UNIVERSAL::isa($_[0], __PACKAGE__);
+my ($ua, $url) = (@_ == 1 ? ($UA, shift()) : @_);
+my $request = ref $url ? $url : {uri=>$url};
+
+# Set some defaults
+$ENV{PORT} ||= 8529; # For mod_perl's own tests
+$request->{method} ||= 'GET';
+$request->{content} = '' unless exists $request->{content};
+$request->{uri} = "http://localhost:$ENV{PORT}$request->{uri}"
+ unless $request->{uri} =~ /^http/;
+$request->{headers}{Content_Type} = 'application/x-www-form-urlencoded'
+ if (!$request->{headers} and $request->{method} eq 'POST'); # Is this
+necessary?
+
+# Create & send the request
+$request->{headers} = new HTTP::Headers(%{$request->{headers}||{}});
+my $req = new HTTP::Request(@{$request}{'method','uri','headers','content'});
+my $response = $ua->request($req);
-my $request = new HTTP::Request('GET', $url);
-my $response = $ua->request($request, undef, undef);
-$response->content;
+return wantarray ? ($response->content, $response) : $response->content;
}
sub simple_fetch {
@@ -340,6 +349,7 @@
}
sub MM_test {
+# Writes the test section for the Makefile
shift(); # Don't need package name
my %conf = @_;
@@ -569,9 +579,58 @@
*MY::test = sub { Apache::test->MM_test(%params) };
+=head2 fetch
+
+ Apache::test->fetch($request);
+ Apache::test->fetch($user_agent, $request);
+
+Call this method in a test script in order to fetch a page from the
+running web server. If you pass two arguments, the first should be an
+LWP::UserAgent object, and the second should specify the request to
+make of the server. If you only pass one argument, it specifies the
+request to make.
+
+The request can be specified either by a simple string indicating the
+URI to fetch, or by a hash reference, which gives you more control
+over the request. The following keys are recognized in the hash:
+
+=over 4
+
+=item * uri
+
+The URI to fetch from the server. If the URI does not begin with
+"http", we prepend "http://localhost:$PORT" so that we make requests
+of the test server.
+
+=item * method
+
+The request method to use. Default is 'GET'.
+
+=item * content
+
+The request content body. Typically used to simulate HTML fill-out
+form submission for POST requests. Default is null.
+
+=item * headers
+
+A hash of headers you want sent with the request. You might use this
+to send cookies or provide some application-specific header.
+
+=back
+
+If you don't provide a 'headers' parameter and you set the 'method'
+to 'POST', then we assume that you're trying to simulate HTML form
+submission and we add a 'Content_Type' header with a value of
+'application/x-www-form-urlencod
Re: Patch for easy testing of Apache::* modules (resend)
[EMAIL PROTECTED] (Doug MacEachern) wrote: >On Mon, 17 Jul 2000, Ken Williams wrote: > >> Hi all, >> >> Here's a resend of the Apache::test patch that I sent yesterday, this time >> sent as type text/plain from a Unix mailer. Rick Myers noted that the >> version I sent before was encoded with Macintosh BinHex, which is probably >> not the most appropriate choice for this list. ;-) > >looks great ken, applied, thanks! >btw, when i first skimmed the patch, i thought it modified the >mod_perl Makefile.PL test foo, which is why i was holding off. Awesome, it looks like you've applied my two biggest patches. Now I'll go off and make sure they work =). ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Time estimate
Hi I am a totally new mod_perl user. I have to estimate the developement schedule for a mod_perl - cgi - mysql - small project. Where can I find references about the standard time estimates for this kind of project ? thanks
Re: CyberCash and mod_perl Experiences
> "YR" == Yann Ramin <[EMAIL PROTECTED]> writes: YR> CyberCash is not reliable. Perfectly valid credit cards fail auth YR> at times, and the service has a tendancy to crap out. What the YR> book suggested to do was to have a backend which goes and queries This has never been my experience with cybercash. We were one of their first customers, and though things were hard to set up in those dark days, their latest incarnation of the software is quite trivial to install and use (once you figure out how to program it). It involves three Perl modules (pure perl, even) to be installed. Then you just "use" the appropriate one, and call the right function. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG & MIME spoken herehttp://www.khera.org/~vivek/
Re: One httpd.conf for both apache heavy and apache-light [IfModule]
> "ml" == martin langhoff <[EMAIL PROTECTED]> writes: ml> Perrin, Robin, et al ml> at least I don't feel alone on this one :) ml> now let me seize the opportunity and (while you're around, ml> having ml> admitted you're using a 2 tiered apache setup,) ask you if you are doing ml> the mod_rewrite/mod_proxy trick, and how were you able to pull it off. I've posted complete copies of my live www.morebusiness.com httpd configs for the lightweight proxy front end and the mod_perl backend. Check the list archives for it. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG & MIME spoken herehttp://www.khera.org/~vivek/
Apache::Request CORE DUMPS
Hi ,
I have few very strange coredumps when using Apache::Request
here my script :
The *strange thing is that It only coredump when i put any
param
like www.me.com?param=value
=>coredump
but www.me.com
=>works fine
Any ideas ??
Thanks !
use strict;use Apache::Request;my $r=shift;my $cgi
= Apache::Request->new($r);use lib "/usr/local/abc/perl/carpe";use
Banner::Sql;use Banner::Html;use Banner::Config qw(valuor);
my $sql = new
Banner::Sql(valuor('db_name'),valuor('db_host'),valuor('db_login'),valuor('db_pwd'));$sql->DB_connect();
my $tbl_name=valuor('tbl_name');my
$prog=valuor('stat_prog');eval{ my $actor =
$cgi->param("actor")||''; #le lien du serveur ou est stocke
l'image if($actor eq
'del_link'){&afficher_liste; exit; }else{ &afficher_liste; exit; }};sub
afficher_liste{ my $html=new Banner::Html($cgi); my
$start=$cgi->param('start')||'0'; my
$stop=$cgi->param('stop')||'25'; my $limit = "LIMIT
$start,$stop"; my $c =
$sql->sqlSelectMany('uid,lien,email',$tbl_name,1,$limit); my
$nbr=$sql->getDBI('rows'); my @loop_data = (); # initialize an
array to hold your loop while(my $S =
$c->fetchrow_hashref){ my
%row_data; $row_data{LIEN} =
$S->{lien}; $row_data{UID} =
$S->{uid}; $row_data{PROG} =
$prog; push(@loop_data, \%row_data);
}
$c->finish; $sql->DB_disconnect; my
$cnt=1; my $st; my $stp; my $nav =qq(Page 1 > \n); my
$j; for($j=25;$j<$nbr;$j+=25){ $cnt++; $st=$j; $stp=$j+25; $nav
.= qq(Page $cnt
>
\n); } $html->afficher_stat(\@loop_data,$nav);}
RE: CyberCash and mod_perl Experiences
I was thinking about Phillip's approach, actually, but the technical details in his ACS system are all in Tcl for AOLServer. Also, I'm not really excited about the liability involved in storing the credit card number in my database. I decided to jump in and start hacking the CyberCash perl libraries and they are full of junk. They don't use "use strict" and when I put it in all of them, it blew up. They don't use scoping in any kind of consistent way and seem to have fundamental issues with perl syntax (They used $#Foo to find the size of %Foo - can you do that? I didn't think so, and the interpreter didn't seem to either - wanted me to declare @Foo...) On a completely unrelated note, my picture is actually in "P&A's Guide to Web Publishing". I'm in the section about the dating game. I'm the model they used (not the girl... ;) the guy in the suit. Thanks for the input, RYAN -Original Message- From: Yann Ramin [mailto:[EMAIL PROTECTED]] Sent: Sunday, October 01, 2000 6:06 PM To: Ryan Adams Cc: [EMAIL PROTECTED] Subject: Re: CyberCash and mod_perl Experiences I haven't dealt with CyerCash before, but have some ideas which I read from a somewhat useful book I got for free (Phillip and Alex's Guide to Web Publishing). CyberCash is not reliable. Perfectly valid credit cards fail auth at times, and the service has a tendancy to crap out. What the book suggested to do was to have a backend which goes and queries new orders every x minutes and tries to auth them. They are attempted three times, and after that rejected (and credit card numbers yanked from your DB, replaced with a CyberCash reference). That way what the user sees is a perfectly working system, not knowing that things are dead behind that. My $0.01 Yann On Sun, 01 Oct 2000, you (Ryan Adams) might of written: > Hello all, > > I'm trying to integrate CyberCash with a shopping system that we've > developed in-house using mod_perl almost exclusively. I haven't been > particularly impressed with the way it installs. We're on a Linux machine > and it has a very NT-centric design, in my opinion. > > I have been able to get test scripts to run from the command-line and > through > basic mod_cgi execution, but I can't get consistent results when executing > them via mod_perl ContentHandlers. In looking through their library files, > they are doing some IPC::Open2 calls to executables and some other pretty > ugly > stuff that may or may not be causing the problems. > > Does anyone have experience doing this? What approach did you take? Any > good > documentation? I've read all the CyberCash stuff, but it hasn't given me > the > kind of answers I wanted. > > Thanks in advance. > > Ryan -- Yann Ramin [EMAIL PROTECTED] Atrus Trivalie Productions www.redshift.com/~yramin Monterey High ITwww.montereyhigh.com AIM oddatrus Marina, CA IRM Developer Network Toaster Developer SNTS Developer KLevel Developer
Re: CyberCash and mod_perl Experiences
I haven't dealt with CyerCash before, but have some ideas which I read from a somewhat useful book I got for free (Phillip and Alex's Guide to Web Publishing). CyberCash is not reliable. Perfectly valid credit cards fail auth at times, and the service has a tendancy to crap out. What the book suggested to do was to have a backend which goes and queries new orders every x minutes and tries to auth them. They are attempted three times, and after that rejected (and credit card numbers yanked from your DB, replaced with a CyberCash reference). That way what the user sees is a perfectly working system, not knowing that things are dead behind that. My $0.01 Yann On Sun, 01 Oct 2000, you (Ryan Adams) might of written: > Hello all, > > I'm trying to integrate CyberCash with a shopping system that we've > developed in-house using mod_perl almost exclusively. I haven't been > particularly impressed with the way it installs. We're on a Linux machine > and it has a very NT-centric design, in my opinion. > > I have been able to get test scripts to run from the command-line and > through > basic mod_cgi execution, but I can't get consistent results when executing > them via mod_perl ContentHandlers. In looking through their library files, > they are doing some IPC::Open2 calls to executables and some other pretty > ugly > stuff that may or may not be causing the problems. > > Does anyone have experience doing this? What approach did you take? Any > good > documentation? I've read all the CyberCash stuff, but it hasn't given me > the > kind of answers I wanted. > > Thanks in advance. > > Ryan -- Yann Ramin [EMAIL PROTECTED] Atrus Trivalie Productions www.redshift.com/~yramin Monterey High ITwww.montereyhigh.com AIM oddatrus Marina, CA IRM Developer Network Toaster Developer SNTS Developer KLevel Developer
CyberCash and mod_perl Experiences
Hello all, I'm trying to integrate CyberCash with a shopping system that we've developed in-house using mod_perl almost exclusively. I haven't been particularly impressed with the way it installs. We're on a Linux machine and it has a very NT-centric design, in my opinion. I have been able to get test scripts to run from the command-line and through basic mod_cgi execution, but I can't get consistent results when executing them via mod_perl ContentHandlers. In looking through their library files, they are doing some IPC::Open2 calls to executables and some other pretty ugly stuff that may or may not be causing the problems. Does anyone have experience doing this? What approach did you take? Any good documentation? I've read all the CyberCash stuff, but it hasn't given me the kind of answers I wanted. Thanks in advance. Ryan
Makefile.PL bug???
I am having the following "problem" when building mod_perl/Apache. I have a .makepl_args.mod_perl file in my $HOME, and "perl Makefile.PL" works almost perfectly, using Apaci to configure both Apache and mod_perl compilation just the way I want. Then "make" from the mod_perl dir, fails in the Apache src/support dir, trying to compile suexec. Here are the two "errors" that are generated, and their commands, the second coming after fixing the first: gcc -c -I.. -I/opt/perl5.6.0/lib/5.6.0/sun4-solaris/CORE -I../os/unix -I../include -DSOLARIS2=280 -DMOD_PERL -DUSE_PERL_SSI -fno-strict-aliasing -I/opt/BerkeleyDB.3.1/include -I/opt/include/X11 \ -DHTTPD_USER=\"httpd\" \ -DUID_MIN=100 \ -DGID_MIN=100 \ -DUSERDIR_SUFFIX=\"public_html\" \ -DLOG_EXEC=\"/opt/Apache.new/logs/suexec_log\" \ -DDOC_ROOT=\"/export/home/htdocs\" \ -DSAFE_PATH=\"/usr/local/bin:/usr/bin:/bin\" \ suexec.c gcc: suexec.c: No such file or directory gcc: No input files *** Error code 1 make: Fatal error: Command failed for target `suexec.o' Copy/pasting this into a shell that is in the Apache src/support dir, and removing the \ before suexec.c at the end, works fine. (Or, I could put in a cr after the \ :):) Then, back in the mod_perl dir, "make" gives me this: gcc -DSOLARIS2=280 -DMOD_PERL -DUSE_PERL_SSI -fno-strict-aliasing -I/opt/BerkeleyDB.3.1/include -I/opt/include/X11 \ -DHTTPD_USER=\"httpd\" \ -DUID_MIN=100 \ -DGID_MIN=100 \ -DUSERDIR_SUFFIX=\"public_html\" \ -DLOG_EXEC=\"/opt/Apache.new/logs/suexec_log\" \ -DDOC_ROOT=\"/export/home/htdocs\" \ -DSAFE_PATH=\"/usr/local/bin:/usr/bin:/bin\" \ -o suexec -L../os/unix -L../ap suexec.o -lap -los -lsocket -lnsl-L/opt/BerkeleyDB.3.1/lib -L/opt/lib/X11 /opt/perl5.6.0/lib/5.6.0/sun4-solaris/auto/DynaLoader/DynaLoader.a -L/opt/perl5.6.0/lib/5.6.0/sun4-solaris/CORE -lperl -lsocket -lnsl -ldb -ldl -lm -lc -lcrypt -lsec -ldl gcc: -o: No such file or directory gcc: suexec: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `suexec' Again, I copy/paste, remove the \ before the -o suexec, and the command works. Back in mod_perl, "make", "make test", and "make install" all work perfectly. Obviously, a problem in the Makefile generation, and a simple one for someone who understands all the interaction between all the Makefiles. But, unfortunately, that is not me. :( Yet ;) This is not a show-stopper, but it does it make it impossible to do a clean "install Apache" from the CPAN shell, or a Bundle file. :( Relevant info: Solaris 2.6 and 8 perl 5.6.0 mod_perl 1.24 Apache 1.3.12 gcc 2.95.2 19991024 (release) Everything was compiled from the same gcc, the packages from sunfreeware.com, for 2.6 and 8. As a matter of fact, on new installations, I build _everything_ I need/use from nice shell/perl scripts and CPAN Bundle files that I have built over the past four years. That is why I would love to have this fixed. :):) (I can run the patch program, or even apply by hand. I have done both many times. :):) David McCabe Unix System Administrator Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 Microsoft seems to have gotten a lot of mileage out of the C2 rating for NT with no network connection. I wonder if a B3 rating for Linux with no power cord might be of value. -- unknown
