Re: Apache::ASP - I think bug...
> > > Not that if you are using the same sub routine name,
> > > you might want to just define it once in global.asa,
> > > and have it vary its behavior based on what script
> > > is calling it, which you can get from $0, or
> > > &File::Basename::basename($0)
> >
> > Shit, It was in your documentation, and I forget about it. May be there
is a
> > reason write down some attentions to Windows ASP programmers, I just
migrate
> > my Windows ASP technology to Apache::ASP did't get any attentions while
>
> Let me know if you had any hiccups in particular while
> migrating that I can help, like compatibility issues ?
There was a need of IncludesDir and Buffering was broke, but you done it.
And may be you need to try insert some attentions on compile while there are
subs with the same name in 2+ scripts
Btw, we can suppose that two users place their own scripts in one
application and named subs the same...
Although you may say, that for every independent user we need create new
application.
> > Nope, routines has very different implementation, which is own for every
> > script. I'll need to give subs different names, for example, with
prefix - script name.
> > What a pity... Compiling to unique packages a little decreased
performance,
> > as I understand, because default for UniquePackages is off...
> >
>
> Try the UniquePackages config, I don't think there is a difference
> on performance, not much anyway, it seemed more natural to that
> compiled includes be able to see the same globals as the main script,
> which was the motivation for not making it the default.
With UniquePackages I can't call subs defined in DynamicIncludes, because
DynamicInclude is compiled to own package.
May be is there reason to give by compiler a unique name for subs in scripts
and leave UniquePackages off ?
Global.asa
-
sub shared_one {
print "Some global text";
};
-
include.inc
-
<%
sub shared_two {
%>
Some global text
<%
};
%>
-
script.asp
-
<%
sub test{
};
shared_one();
shared_two();
test();
%>
-
But compiler translate it to
script.asp
-
<%
sub _test{
};
shared_one();
shared_two();
_test();
%>
-
While I writing it, I think, it is more Windows ASP way than perl
Apache::ASP, although I don't know perl good as C or ASP.
May be better way is implement include.inc as package and use
UniquePackages? And my includes contains only subs.
Package.pm
---
sub shared_two {
my($request) = $main::Request;<<< But it
is not elegant as include.inc
my($env) = $request->Write("some global text");
};
-
script.asp
-
<%
use Package;
sub test{
};
shared_one();
shared_two();
test();
%>
-
The only one method I see, it is call all subs in scripts with unique
prefix.
--
Sergey Polyakov (BeerBong)
Chief of Web Lab (http://www.mustdie.ru/~beerbong)
Re: Error in make test
Greetings, On Thu, 9 Dec 1999, Sakuji Toyama wrote: > I have compiled mod_perl-1.21 with apache_1.3.9 under Solaris2.5 machine. > ... > "--prefix=/usr/local/etc/httpd" I think this is your problem. Something similar happened to me. Try putting everything in /usr/local/apache_1.3.9 with a soft link/usr/local/apache -> /usr/local/apache_1.3.9 and use --prefix=/usr/local/apache put mod_perl in /usr/local/mod_perl-1.21 with a soft link/usr/local/mod_perl -> /usr/local/mod_perl-1.21 Delete the original apache installation and start again with a fresh set of files from the distribution. Please tell me if this works for you. Kind regards, Ged Haywood.
Newbie: Running script using Apache API
Howdy all,
Trying to run a script from the Eagle Book (ch.4 Example 4-14)
Using the Apache API, so it looks like:
#!/usr/bin/perl -w
# file perl/hello3.pl
use strict:
my $r-> = Apache->request;
$r->content_type('text/html');
$r->send_http_header;
return OK unless $r->header_only;
.
.
.
And so on. Like a module.pm in other words.
It doesn't work. The 'perl/' dir is the one set up for other scripts.
The perl.conf for this dir is per book directions.
SetHandler perl-script
PerlHandlerApache::Registry
PerlSendHeader On
Options+ExecCGI
Using current versions of Apache and mod_perl on Intel.
What the error_log shows is that apparently Registry is trying
to wrap the script in a handler subroutine, as Stas's guide describes -
But there's also the bareword warning first.
hello3.pl:Bareword "OK" not allowed while "strict subs" in use at
/usr/local/apache/perl/hello3.pl line 9.
Undefined subroutine &Apache::ROOT::perl::hello3_2epl::handler called at
line 135
Just before the example in the book, there is a discussion about
checking the environment variable MOD_PERL or GATEWAY_INTERFACE.
But not clear if this should be done somehow for this script.
Would appreciate any help on what I'm not understanding about this.
Thanks,
M. Dearman
Re: Newbie: Running script using Apache API
- Original Message -
From: "Michael Dearman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 10, 1999 5:35 AM
Subject: Newbie: Running script using Apache API
> Howdy all,
>
> Trying to run a script from the Eagle Book (ch.4 Example 4-14)
> Using the Apache API, so it looks like:
>
> #!/usr/bin/perl -w
> # file perl/hello3.pl
>
> use strict:
>
> my $r-> = Apache->request;
> $r->content_type('text/html');
> $r->send_http_header;
> return OK unless $r->header_only;
> .
> And so on. Like a module.pm in other words.
>
> It doesn't work. The 'perl/' dir is the one set up for other scripts.
> The perl.conf for this dir is per book directions.
>
>
> SetHandler perl-script
> PerlHandlerApache::Registry
> PerlSendHeader On
> Options+ExecCGI
>
[snip]
> Thanks,
> M. Dearman
Hey Michael,
You seem to have missed something along the way. The answer actually lies in
your own explanation of the problem.
For that location, you already have a handler -> Apache::Registry, what you
want* is your .pm as the handler for a particular location. I think if you
page back a chapter or two you'll see examples of how httpd.conf or
.htaccess files should be setup.
-Jay J
(omitting all mention [except this] of stacked handlers for this example)
Re: calling htpasswd from perl ...
Dave, In your htaccess file, I would imagine that you are pointing to a password file via the AuthUserFile directive so as long as you have permissions to edit that file, use the perl function crypt() to generate the password and then just append it to the password file. Just remember to have the user enter the password 2 times for error checking and make sure you parse the password file to check and see if the username is already in it. I have this script already written somewhere, If you need it, let me know and I will send it to you privately. Also...This question would probaby be best served by an apache or cgi list, not this one. Bill === Bill Desjardinshttp://www.carracing.com [EMAIL PROTECTED]Tel: 305.205.8644 FREE Homepages for Racers and Race Tracks!! On Thu, 9 Dec 1999, dave_dunstan wrote: > Here's my question - since I can't use an Auth module and a database, can I > write up a widget that will write .htaccess and .htpasswd files ...? I'm > thinking I can call htpasswd from perl, but I'm not sure how I'd have perl > "confirm" the new password at the confirmation prompt from htpasswd. > > Any help would be much appreciated! > Is this just a cracked idea altogether? > > Happy Holidays! > > Dave Dunstan > Mission Control Consulting LLC > 301 8th Street, Suite 215 > San Francisco CA 94103 > ph 415.701.0088 > fx 415.241.0807 >
Re: Compilation Problem
http://perl.apache.org/guide/troubleshooting.html#Can_t_load_auto_DBI_DBI_so_ maybe ? > Stas Bekman wrote: > > > > Do you have a symlink from /usr/local/lib/libgdbm.so.2 to > > /usr/local/lib/libgdbm.so.2.x.x? replace x.x with the version that you > > have. > > > Thanks. This is exactly what was wrong. I was able to 'make' modperl, > BUT > make test failed: > > /usr/local/etc/apache_1.3.9.orig/src//httpd -f `pwd`/t/conf/httpd.conf > -X -d `pwd`/t & > httpd listening on port 8529 > will write error_log to: t/logs/error_log > letting apache warm up...[Thu Dec 9 18:56:21 1999] [error] Can't load > '/usr/local/lib/perl5/5.00503/sun4-solaris/auto/IO/IO.so' for module IO: > ld.so.1: /usr/local/etc/apache_1.3.9.orig/src//httpd: fatal: relocation > error: file /usr/local/lib/perl5/5.00503/sun4-solaris/auto/IO/IO.so: > symbol main: referenced symbol not found at > /usr/local/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169. > at /usr/local/lib/perl5/5.00503/sun4-solaris/IO/Handle.pm line 241 > BEGIN failed--compilation aborted at > /usr/local/lib/perl5/5.00503/sun4-solaris/IO/Handle.pm line 241. > BEGIN failed--compilation aborted at > /usr/local/lib/perl5/5.00503/sun4-solaris/IO/Seekable.pm line 51. > BEGIN failed--compilation aborted at > /usr/local/lib/perl5/5.00503/sun4-solaris/IO/File.pm line 112. > BEGIN failed--compilation aborted at > /usr/local/tmp/mod_perl-1.21/t//docs/startup.pl line 33. > > ... > What could be causing this? > > -- > Eugene Miretskiy <[EMAIL PROTECTED]> > InVision, INC. (516) 543-1000x219 > http://www.invision.net > ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o-> + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: Newbie: Running script using Apache API
Jay J wrote:
>
> - Original Message -
> From: "Michael Dearman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, December 10, 1999 5:35 AM
> Subject: Newbie: Running script using Apache API
>
> > Howdy all,
> >
> > Trying to run a script from the Eagle Book (ch.4 Example 4-14)
> > Using the Apache API, so it looks like:
> >
> > #!/usr/bin/perl -w
> > # file perl/hello3.pl
> >
> > use strict:
> >
> > my $r-> = Apache->request;
> > $r->content_type('text/html');
> > $r->send_http_header;
> > return OK unless $r->header_only;
> > .
> > And so on. Like a module.pm in other words.
> >
> > It doesn't work. The 'perl/' dir is the one set up for other scripts.
> > The perl.conf for this dir is per book directions.
> >
> >
> > SetHandler perl-script
> > PerlHandlerApache::Registry
> > PerlSendHeader On
> > Options+ExecCGI
> >
> [snip]
> > Thanks,
> > M. Dearman
>
> Hey Michael,
>
> You seem to have missed something along the way. The answer actually lies in
> your own explanation of the problem.
>
> For that location, you already have a handler -> Apache::Registry, what you
> want* is your .pm as the handler for a particular location. I think if you
> page back a chapter or two you'll see examples of how httpd.conf or
> .htaccess files should be setup.
>
> -Jay J
>
> (omitting all mention [except this] of stacked handlers for this example)
Hi Jay, and all,
Can appreciate that - and have seen this mentioned in the GuestBook
example.
But on page 144 the authors state that you can use scripts in an
Apache::Registry
enabled directory (in may case /perl) that either use the CGI
environment OR scripts
that use the API environment. Heck, they state you can mix the 2 types.
And have been successful in using calls to apache like 'my $r =
Apache->request'
I have refined my problem while writing this.
When I comment out the line ' return OK unless $r->header_only ' it
works.
So apparently I just got to get Apache::Constants to pick up the 'OK'.
Otherwise it sees it as a bareword.
I had tried sticking in a ' use Apache::Constants qw(:common) in the
script.
Below the ' use strict '. Did not work.
And I do have ' use Apache::Constants (); ' in the startup.pl file
Shouldn't that catch the :common variety?
Also tried return 200, return HTTP_OK, in all manner of quote schemes
and
still not working.
Thanks,
M. Dearman
Re: FindBin/Apache::Registry bug
> Don't use FindBin. It's not compatible with mod_perl since it uses
> BEGIN block which is executed only ones and for correct work it should
> be executed every time when the request comes.
That's correct that FindBin doesn't work under mod_perl. But the reason is
different. It doesn't work because its invocation happens during the load
of the module itself and as any other module under mod_perl it's loaded
only once per process.
It has nothing to do with BEGIN block.
A possible workaround is to mess with %INC:
delete $INC{FindBin};
use FindBin;
Anyway, thank you for this spot. I've offered this solution in the guide
and didn't know it has a problem. I'll update the guide.
> On Thu, Dec 09, 1999 at 12:03:56PM -0800, Joao Fonseca wrote:
> > This message was sent from Geocrawler.com by "Joao Fonseca"
><[EMAIL PROTECTED]>
> > Be sure to reply to that address.
> >
> > Hello,
> >
> > I'm having problems migrating a site to mod_perl,
> > using the Apache::Registry module.
> > Scenario:
> >
> > -I have 2 CGIs (cgi1 and cgi2).
> > -CGI1 is a soft link, and uses FindBin:
> > use FindBin;
> > use lib "$FindBin::RealBin";
> > use MyLib;
> >
> > -CGI2 is not a soft link and also uses FindBin;
> >
> > After running several times, CGI1 sometimes fails
> > with:
> > Can't locate MyTag.pm in @INC...
> >
> > After debugging, I found out that FindBin thinks
> > it's running
> > CGI2 instead of CGI1, and the use lib statement
> > doesn't go
> > to the proper location.
> >
> > Here's my theory:
> >
> > -On a previous request, CGI2 was run, and used
> > FindBin.
> > FindBin recorded all it's info for CGI2
> > (RealBin, Bin, Script,
> > and RealScript).
> >
> > -Later, a request for CGI1 came, which also tried
> > to use
> > FindBin.
> >
> > -Apache::Registry doesn't load the FindBin module
> > again.
> > Instead, uses the cached version from the
> > previous request.
> > FindBin doesn't refresh the RealBin variable,
> > and the
> > use lib statement now points to the CGI2
> > directory.
> >
> > -Of course, MyLib isn't found in @INC, because
> > it's pointing
> > to the wrong directory!
> >
> >
> > Any thoughts on how to overcome this problem? I
> > want to
> > keep a soft link on CGI1.
> >
> > Thanks,
> > Joao Fonseca
> >
> >
> >
> > Geocrawler.com - The Knowledge Archive
>
> --
>
RE: Trouble in proxyland
Dave Hayes wrote: > On Fri, 6 Aug 1999, Vivek Khera wrote: > > Running Apache/1.3.7-dev (Unix) mod_perl/1.19_01-dev, it seems that > > PerlPostReadRequestHandler is virtual-host bound. > > Yep, and I really have to ask why this is implemented in this fashion? Because mod_perl lacks a per-server merge configuration merge function. > Turns out I beat my head against the wall for a few hours until I > found this mail message. Is there a way to globalize this parameter > (i.e. allow this handler to be set outside of a virtual host section)? Yes it's fixed in the CVS tree. If a PostReadRequest handler is installed in the main server config, it will be used by vhosts, unless they define their own. -- Eric
Re: Newbie: Running script using Apache API
Ah... > So apparently I just got to get Apache::Constants to pick up the 'OK'. > Otherwise it sees it as a bareword. OK, got that 'OK' is an Apache return code. *bow* M. Dearman
RE: FindBin/Apache::Registry bug (fwd)
> A possible workaround is to mess with %INC:
>
> delete $INC{FindBin};
> use FindBin;
Of course, as Eric corrected me, it should be 'require()' instead of
'use()', since use is done at compile time. do() is another option.
But require() wouldn't import tags, so ether use FQ variable $FindBin::Bin
or use:
import FindBin;
if you need to import them.
RE: Unloading a library
I am also wondering how to do that. My scripts call multiple pre-loaded modules that put heavy stuff in their proper lexical variables, which seems to cause memory leaks, which results in consistent growth of children's size. So I would love to "garbage-collect" whatever had been put into lexical variables, at the end of each subroutine call. Victor. >> Behalf Of Matt Sergeant >> >> How can I completely unload a library and all memory >> associated with it, >> and unload any dso's connected with that library? For >> example, say I use >> XML::Parser in a section - I don't want that hanging >> around - it's a >> big library, so I'd like to completely unload it - is it possible? >> >Any one have any thoughts on the above. I'd like to do >this also. Was wondering if there were any ideas.
Re: Can't load /..../Fcntl.so
I never exactly found my problem, but it stemmed from something to do with dynamic loading, and I ultimately rebuilt Perl. Lessons learned: 1- Before attempting to rebuild Apache with mod_perl, be sure to back up both the operational Apache and Perl, because mod_perl diddles with some of the things in Perl's directories. (I think it was libperl.a.) 2- Don't NFS-mount Perl from the production system while doing your build on another machine. 3- Keep careful notes on the build process, including every step you did. If it takes several tries with changes to get it right, start over from scratch and make sure you didn't omit something in your notes. You don't want to have doubts about what options you chose six months later. 4- Don't send a note to someone who's having trouble, teasing him for having done something foolish, unless you're real good friends or have something substantive to offer. (Someone sent me a note telling me I'd done something stupid, but he didn't have anything helpful to say. It's a pity that cow chips won't fit into email.) -- Bruce A. JohnsonPictureVision, Inc. Sr. Software Engineer 250-A Exchange Pl. (703)925-4075 Herndon, VA 20170 http://info.photonet.com "Bruce A. Johnson" wrote: > > I just rebuilt my Apache server (1.3.6) last week. I enabled the > cern_meta module, the usertrack module, and the expires module, > and I upgraded mod_perl from 1.19 to 1.21. I did a clean build > from the distribution tar-balls. > > My "tricky" applications seemed to work okay, so I put it into > production. Now I find that one of my other apps is broken: > > > Software error: > > > > Can't load '/opt/perl/lib/5.00502/sun4-solaris/auto/Fcntl/Fcntl.so' for module > > Fcntl: ld.so.1: /opt/apache/bin/httpd: fatal: relocation error: file > > /opt/perl/lib/5.00502/sun4-solaris/auto/Fcntl/Fcntl.so: symbol main: referenced > > symbol not found at /opt/perl/lib/5.00502/sun4-solaris/DynaLoader.pm line 168. at > > (eval 168) line 3 > > I don't know whether I've stumbled across a problem in mod_perl > 1.21 or whether I inadvertently mucked something up. I'm > starting a rebuild with 1.19 to see if the problem can be > reproduced; however, if anyone has some advice for a dumb > so-and-so, I'll gladly accept it. > > Thanks! > -- > Bruce A. JohnsonPictureVision, Inc. > Sr. Software Engineer 250-A Exchange Pl. > (703)925-4075 Herndon, VA 20170 > http://info.photonet.com
"Can't locate loadable...." Apache::Util
I've been looking through the archives of this list and I've seen the error I'm getting mentioned before in several forms. Syntax error on line 198 of /usr/local/apache/conf/httpd.conf: Can't locate loadable object for module Apache::Util in @INC (@INC contains: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 . /usr/local/apache/ /usr/local/apache/lib/perl) at /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 14 BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.005/Apache/EmbperlChain.pm line 4. Line 198 being "PerlModule Apache::EmbperlChain Okay, now I know the standard answer for this is compile mod_perl with EVERYTHING=1, PERL_UTIL_API=1, or DYNAMIC=1. PERL_UTIL_API compiles and tests correctly, but it doesn't change anything about the error I'm getting. EVERYTHING and DYNAMIC don't work either, and also cause an error when I run "make test" which is this: ../apache_1.3.9/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c Syntax error on line 3 of /usr/src/perlmods/mod_perl-1.21/t/conf/srm.conf: Invalid command 'PerlTransHandler', perhaps mis-spelled or defined by a module not included in the server configuration done /usr/bin/perl t/TEST 0 still waiting for server to warm upnot ok server failed to start! at t/TEST line 95. make: *** [run_tests] Error 9 I also noticed that even after doing PERL_UTIL_API=1, when I run "make test" it says something to the effect of "not for this platform, skipping" when it gets to Apache::Util. Which I suppose brings us to the question, what platform? Red Hat Linux, kernel 2.2.5-15, i686. mod-perl: 1.21. Apache: 1.3.9. Perl: 5.00503. I'd appreciate any help anyone could give.
Re: ASP Cookieless Sessions (WAS Re: Apache::ASP)
> "Serge" == Serge Sozonoff <[EMAIL PROTECTED]> writes: Serge> Hello, >> It will work fine, but the problem still remains that the >> incoming page URL has the session-id in it, so that when you go >> offsite, the referer header sent by the client has the client's >> session id in it still, and the unethical webmaster could easily >> then access the users sessions by looking at the referer logs. Serge> There is a little article about cookie-less sessions at: Serge> www.webdevelopersjournal.com/columns/stateful.html And this method requires client-side javascript enabled (mine is not, thank you), *and* frames your entire site, so bookmarking is useless. Nope, I wouldn't put it into the "useful robust" category. You're still back to: cookies (maybe disabled) hidden fields (only with form submissions) mangled URLs (all pages must be dynamic generated) auth (like BasicAuth where you "log in") And one *new* one that I pondered recently, that can be used as long as you presume HTTP/1.1... I don't have time to write it up here, but it permits: 1) bookmarking of sessions 2) no rewriting of URLs for static pages, even if they have links 3) access to session ID even by mod_cgi scripts 4) new sessions are started by a simple external redirect 5) one simplePerlTransHandler could provide the master session-start for any URL downside: you must have access to a UDP port 53 somewhere and DNS delegation I'll write up more after I've done some testing. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Newbie: Running script using Apache API
Anthony Gardner wrote: > > Michael, > > You are there, believe it or not. > > Have a look at the attached and run it. > > That pop up window is telling you that the script has finished and that it > received no data. > > Include Apache::Constants; and change unless to if where it's testing for > header_only. > > There are more than one type of method that the browser uses to request > data. The two most common are GET and POST but another one is HEAD. That's > what that line is checking for, whether the browser is just requesting HEAD > information. > > We are using GET so it should fail that test and return the HTML stuff > thereafter. That dit it! Change the 'unless' to 'if'. *chuckle* You know, I sat and looked at the 'return OK unless ...' and thought it didn't make sense. Thanks! M. Dearman > > >From: Michael Dearman <[EMAIL PROTECTED]> > >To: Anthony Gardner <[EMAIL PROTECTED]> > >Subject: Re: Newbie: Running script using Apache API > >Date: Fri, 10 Dec 1999 08:49:28 -0700 > > > > > > > >Anthony Gardner wrote: > > > > > > Does that mean you've solved it? If it does, what did yo do? I haven't > > > really touched Registry (will do this weekend). > > > >No. Haven't solved it. Just that 'OK' is an internal return code. I'm > >assuming > >that means it should work without being addressed by Apache::Constants > >qw(:common) > >or whatever. Which I've tried in the script and that just makes things > >worse. > >Meaning that a window pops up saying something about 'no data in file'. > >*shrug* > > > >M. Dearman > > __ > Get Your Private, Free Email at http://www.hotmail.com > > > Name: hello3.cgi >hello3.cgiType: unspecified type (application/octet-stream) > Encoding: base64
Re: Newbie: Running script using Apache API
Michael Dearman wrote: > > That dit it! Change the 'unless' to 'if'. *chuckle* > You know, I sat and looked at the 'return OK unless ...' and thought it > didn't > make sense. > Thanks! > M. Dearman I just checked the example in my copy of the book and the line had an 'if', which is correct, not an 'unless'. Either you have an old edition of the book where it was a typo, or you may have misread it when you typed. /prakash
Re: Compilation Problem
Eugene, I just finished (I think) dealing with that same blamed error about not being able to find symbol "main". Here are my notes on how I did my build on Solaris 2.6: 1- Built Perl5.005.02 a- Configure settings: No threading use Perl's malloc Nm extracts C libraries Dynamic loading = yes. Build shared libperl.so No vfork b- setenv LD_LIBRARY_PATH `pwd` because Configure warned me to do this. c- make; make test; make install (only if tests succeeded) 2- Installed LWP packages because mod_perl's test is going to need them: libnet HTML-Parser MIME-Base 64 URI Digest-MD5 libwww-perl (LWP) 3- Installed CGI.pm, although I'm still not clear if this is necessary with Apache::Registry. (Anyone who is willing to enlighten me, please do so, but make it a separate thread.) 4- Built Apache 1.3.6 w/ mod_perl 1.21: Checked path to ensure new Perl is the one I'm using. cd mod_perl-1.21 perl Makefile.PL DO_HTTPD=1 USE_APACI=1 \ PREP_HTTPD=1 EVERYTHING=1 make make install (may not have been needed) cd ../apache_1.3.6 ./configure --enable-prefix=/where/ever \ --enable-rule=SHARED_CORE \ --with-perl=/path/to/perl/executable \ --with-layout=Apache \ --activate-module=src/module/perl/libperl.a \ --enable-module=so (I added other stuff, but it's not germane to the discussion) make make install cd ../mod_perl-1.21 make test (everything passed) make install The reason I did an install of Apache before I went back to mod_perl to do the make test is that in previous attempts, if I tried to test mod_perl without installing Apache, it complained about some library not being in either the Apache directory or the Perl directory. And I did the last install of mod_perl because although all my tests passed, when I fired up httpd in the target Apache directory, it curled up and died with the "unknown symbol main" stuff that's biting you now. I may be doing this wrong, but I tried following the installation directions in mod_perl installation docs and the Apache docs and met with failure, possibly because my libperl.a file was mucked up from an even earlier attempt. And so far the new server hasn't given me any trouble yet. I hope this helps! -- Bruce A. JohnsonPictureVision, Inc. Sr. Software Engineer 250-A Exchange Pl. (703)925-4075 Herndon, VA 20170 http://info.photonet.com
Configuring Apache with Problems
Hello all. Two questions:
1) These two *look* equivalent:
$FilesMatch{'"^.*\.pl$"'} =
{
SetHandler => 'perl-script',
PerlHandler => 'Apache::Registry',
Options => '+ExecCGI'
};
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
but the second one works and the first doesn't. When I try to use the
first one I get .pl files returned as text, as though the directive were
being ignored. The second one works as expected - *.pl files are handled
by Apache::Registry. Any ideas?
2) Is there any way to get the same warning/error messages from mistakes
in a block that you do from "normal" configuration? I'm thinking
particularily of the warnings you get from setting *SpareServers to
innapropriate values.
I'm working on a server that says "mod_perl/1.15 Red Hat Secure/2.0 (Unix)
mod_perl/1.15 mod_ssl/2.0.7 SSLeay/0.9.0b", in case that helps.
Thanks!
-sam
Re: Error in make test
this is a good idea. i had the same one. i thought it would be easy to test out a new release, and if i could not get things working - change the link back to the old one. i did have problems which i believe were related to the softlink. i have since gone back to hardlinks for the apache server directory. i'd be interested to see if this produces good results in a production environment. cliff rayman genwax.com "G.W. Haywood" wrote: > Greetings, > > On Thu, 9 Dec 1999, Sakuji Toyama wrote: > > > I have compiled mod_perl-1.21 with apache_1.3.9 under Solaris2.5 machine. > > ... > > "--prefix=/usr/local/etc/httpd" > > I think this is your problem. Something similar happened to me. > > Try putting everything in /usr/local/apache_1.3.9 > with a soft link/usr/local/apache -> /usr/local/apache_1.3.9 > and use --prefix=/usr/local/apache > put mod_perl in /usr/local/mod_perl-1.21 > with a soft link/usr/local/mod_perl -> /usr/local/mod_perl-1.21 > > Delete the original apache installation and start again with a fresh > set of files from the distribution. > > Please tell me if this works for you. > > Kind regards, > Ged Haywood.
Re: Newbie: Running script using Apache API
Prakash Kailasa wrote: > > > Hi Prakash, > > > > Well. It's example 4-14, on page 146 > > I have a march 1999 first edition. You mean there's already a second > > edition!? > > It's definitely a 'return OK unless' for mine. > > > > Thanks, > > M. Dearman > > I just went back and checked again and _again_. > > I am looking at the same example 4-14 on the same page 146 > and I swear it is 'return OK if $r->header_only;' > > And, mine is a March 1999 First Edition too. > > Go figure. > > Most likely, its just a new printing of the same edition > with the typos fixed. > > /prakash That is wierd. Wish we could figure out how else to tell the difference in the printings beside that date. Would help track any other problems. Thanks Prakash, M. Dearman
Hanging processes
I am having a problem with hanging httpd processes. I have done some AV searches as well as investigated the list archives and did not find any conclusive answer to this problem. If I missed it, can someone point me in the right direction? If any more information will help decode this problem, I can reproduce the problem really easily (bot hitting our stage site causes a few of these processes to pop up). Thanks in advance, - Tony Env: Apache 1.3.9 mod-perl 1.21 gcc version 2.8.1 perl v5.005_03 Solaris 2.7 Static Build Output from top (osiz): PID USERNAME THR PRI NICE SIZE RES STATE TIMECPU COMMAND 2178 dbuser 1 330 137M 64M run 8:33 10.93% httpd 2112 dbuser 1 330 131M 62M run 7:52 10.19% httpd Fresh httpd process: 3282 dbuser 1 580 8200K 2120K sleep 0:00 0.05% httpd Output from gdb ... 2112 : #0 0x118e40 in Perl_av_store () #1 0x1194a4 in Perl_av_push () #2 0xfbc74 in Perl_start_subparse () #3 0x44168 in empty_anon_sub () #4 0x455c0 in XS_Apache__Constants___AUTOLOAD () #5 0x120230 in Perl_pp_entersub () #6 0x159dd0 in Perl_runops_standard () #7 0xe1fb8 in perl_call_sv () #8 0x34564 in perl_call_handler () #9 0x33dd4 in perl_run_stacked_handlers () #10 0x32654 in perl_handler () #11 0x80fb8 in ap_invoke_handler () #12 0x9cdb0 in ap_some_auth_required () #13 0x9d2c8 in ap_internal_redirect () #14 0x9c530 in ap_die () #15 0x9cdd4 in ap_some_auth_required () #16 0x9ce30 in ap_process_request () #17 0x90c70 in ap_child_terminate () #18 0x90fc8 in ap_child_terminate () #19 0x914e0 in ap_child_terminate () #20 0x91c50 in ap_child_terminate () #21 0x92558 in main () (gdb) quit pmap output: /usr/proc/bin/pmap 2112 2112: /opt/apache/bin/httpd -f /opt/apache/conf/httpd.conf 0001 1464K read/exec /opt/local/apache/bin/httpd 0018C000 56K read/write/exec /opt/local/apache/bin/httpd 0019A000 129752K read/write/exec [ heap ] FEF8 8K read/write/exec [ anon ] FEF9 24K read/exec /opt/local/lib/perl5/auto/Socket/Socket.so FEFA4000 8K read/write/exec /opt/local/lib/perl5/auto/Socket/Socket.so FEFB 8K read/write/exec [ anon ] FEFC 24K read/exec /opt/local/lib/perl5/auto/IO/IO.so FEFD4000 8K read/write/exec /opt/local/lib/perl5/auto/IO/IO.so FEFE 16K read/exec /usr/lib/nss_files.so.1 FEFF2000 8K read/write/exec /usr/lib/nss_files.so.1 FF00504K read/exec /opt/local/lib/perl5/auto/DB_File/DB_File.so FF08C000 16K read/write/exec /opt/local/lib/perl5/auto/DB_File/DB_File.so FF0A 48K read/write/shared [ anon ] FF0B 16K read/exec /opt/local/perl/auto/Time/HiRes/HiRes.so FF0C2000 8K read/write/exec /opt/local/perl/auto/Time/HiRes/HiRes.so FF0D 16K read/exec /opt/local/lib/perl5/auto/Fcntl/Fcntl.so FF0E2000 8K read/write/exec /opt/local/lib/perl5/auto/Fcntl/Fcntl.so FF0F 80K read/exec /opt/local/lib/perl5/auto/B/B.so FF112000 16K read/write/exec /opt/local/lib/perl5/auto/B/B.so FF12 24K read/exec /opt/local/lib/perl5/auto/Data/Dumper/Dumper .so FF134000 16K read/write/exec /opt/local/lib/perl5/auto/Data/Dumper/Dumper .so FF14 24K read/exec /usr/lib/libgen.so.1 FF154000 16K read/write/exec /usr/lib/libgen.so.1 FF16 16K read/exec /usr/lib/libmp.so.2 FF172000 8K read/write/exec /usr/lib/libmp.so.2 FF18648K read/exec /usr/lib/libc.so.1 FF23 40K read/write/exec /usr/lib/libc.so.1 FF24 8K read/write/exec [ anon ] FF25 16K read/exec /usr/platform/sun4u/lib/libc_psr.so.1 FF26 8K read/exec /usr/lib/libcrypt_i.so.1 FF27 16K read/write/exec /usr/lib/libcrypt_i.so.1 FF28512K read/exec /usr/lib/libnsl.so.1 FF30E000 40K read/write/exec /usr/lib/libnsl.so.1 FF318000 32K read/write/exec [ anon ] FF33 88K read/exec /usr/lib/libm.so.1 FF354000 8K read/write/exec /usr/lib/libm.so.1 FF37 32K read/exec /usr/lib/libsocket.so.1 FF386000 16K read/write/exec /usr/lib/libsocket.so.1 FF39 8K read/exec /usr/lib/libdl.so.1 FF3A 8K read/write/exec [ anon ] FF3B120K read/exec /usr/lib/ld.so.1 FF3DC000 8K read/write/exec /usr/lib/ld.so.1 FFBE6000 40K read/write/exec [ stack ] total 133840K truss output: truss -p 2112 brk(0x08807800) = 0 ...
Re: ASP Cookieless Sessions (WAS Re: Apache::ASP)
sorry - you peaked my interest so I have to jump the gun a little. are you basing it on unique host names which are resolved by some type of dns delegation? if so, only problem is with SSL pages. the host name has to match the one in the certificate otherwise the browser will give a warning. in this case we would have to rely on the first HTTP_REFERER from a non SSL page, and then back to mangled URL's or hidden fields (we know we are using a form or we wouldn't need SSL). cliff rayman genwax.com "Randal L. Schwartz" wrote: > > "Serge" == Serge Sozonoff <[EMAIL PROTECTED]> writes: > > Serge> Hello, > >> It will work fine, but the problem still remains that the > >> incoming page URL has the session-id in it, so that when you go > >> offsite, the referer header sent by the client has the client's > >> session id in it still, and the unethical webmaster could easily > >> then access the users sessions by looking at the referer logs. > > Serge> There is a little article about cookie-less sessions at: > > Serge> www.webdevelopersjournal.com/columns/stateful.html > > And this method requires client-side javascript enabled (mine is not, > thank you), *and* frames your entire site, so bookmarking is useless. > > Nope, I wouldn't put it into the "useful robust" category. > You're still back to: > > cookies (maybe disabled) > hidden fields (only with form submissions) > mangled URLs (all pages must be dynamic generated) > auth (like BasicAuth where you "log in") > > And one *new* one that I pondered recently, that can be used as long > as you presume HTTP/1.1... > > I don't have time to write it up here, but it permits: > > 1) bookmarking of sessions > 2) no rewriting of URLs for static pages, even if they have links > 3) access to session ID even by mod_cgi scripts > 4) new sessions are started by a simple external redirect > 5) one simplePerlTransHandler could provide the master session-start for any URL > > downside: you must have access to a UDP port 53 somewhere and DNS delegation > > I'll write up more after I've done some testing. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> > Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. > See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Compilation Problem
Thank you very much. Enabling dynamic loading helped. Bruce Johnson wrote: > > Eugene, > > I just finished (I think) dealing with that same blamed error > about not being able to find symbol "main". Here are my notes on > how I did my build on Solaris 2.6: > > 1- Built Perl5.005.02 > a- Configure settings: > No threading > use Perl's malloc > Nm extracts C libraries > Dynamic loading = yes. > Build shared libperl.so > No vfork > b- setenv LD_LIBRARY_PATH `pwd` because Configure warned me > to do this. > c- make; make test; make install (only if tests succeeded) > > 2- Installed LWP packages because mod_perl's test is going to > need them: > libnet > HTML-Parser > MIME-Base 64 > URI > Digest-MD5 > libwww-perl (LWP) > > 3- Installed CGI.pm, although I'm still not clear if this is > necessary with Apache::Registry. (Anyone who is willing to > enlighten me, please do so, but make it a separate thread.) > > 4- Built Apache 1.3.6 w/ mod_perl 1.21: > Checked path to ensure new Perl is the one I'm using. > cd mod_perl-1.21 > perl Makefile.PL DO_HTTPD=1 USE_APACI=1 \ > PREP_HTTPD=1 EVERYTHING=1 > make > make install (may not have been needed) > > cd ../apache_1.3.6 > ./configure --enable-prefix=/where/ever \ > --enable-rule=SHARED_CORE \ > --with-perl=/path/to/perl/executable \ > --with-layout=Apache \ > --activate-module=src/module/perl/libperl.a \ > --enable-module=so > > (I added other stuff, but it's not germane to the discussion) > make > make install > cd ../mod_perl-1.21 > make test (everything passed) > make install > > The reason I did an install of Apache before I went back to > mod_perl to do the make test is that in previous attempts, if I > tried to test mod_perl without installing Apache, it complained > about some library not being in either the Apache directory or > the Perl directory. And I did the last install of mod_perl > because although all my tests passed, when I fired up httpd in > the target Apache directory, it curled up and died with the > "unknown symbol main" stuff that's biting you now. > > I may be doing this wrong, but I tried following the installation > directions in mod_perl installation docs and the Apache docs and > met with failure, possibly because my libperl.a file was mucked > up from an even earlier attempt. And so far the new server > hasn't given me any trouble yet. > > I hope this helps! > -- > Bruce A. JohnsonPictureVision, Inc. > Sr. Software Engineer 250-A Exchange Pl. > (703)925-4075 Herndon, VA 20170 > http://info.photonet.com -- Eugene Miretskiy <[EMAIL PROTECTED]> InVision, INC. (516) 543-1000x219 http://www.invision.net
Can you get the mod_perl performance gains under NT?
It seems that mod_perl is _wonderful_ for gaining performance improvements under UNIX. Can these types of performance gains be done under Windows NT? What technologies/produts do this on NT? It doesn't appear that a person can put mod_perl under IIS! - CGI language interpreter loading with web server - CGI is done directly to the web server API - Code compiled to PCode and PCode subsequently executed - Persistent database connections - Did I miss any and do I have these right? -- Scott Chapman Technical Support Specialist Lund Performance Solutions [EMAIL PROTECTED] or [EMAIL PROTECTED] Phone: 541-926-3800 www.lund.com
Re: Can you get the mod_perl performance gains under NT?
On Fri, 10 Dec 1999, Scott Chapman wrote: > It seems that mod_perl is _wonderful_ for gaining performance > improvements under UNIX. > > Can these types of performance gains be done under Windows NT? > > What technologies/produts do this on NT? > > It doesn't appear that a person can put mod_perl under IIS! > > - CGI language interpreter loading with web server > - CGI is done directly to the web server API > - Code compiled to PCode and PCode subsequently executed > - Persistent database connections Just don't expect it to be free: Check out Velocigen and PerlEx (from Activestate - makers of Perl for Win32). Not quite the same (you don't have access to the web server API in either products - they're both just CGI speeders) but often good enough. There's also Apache on NT, but it's single threaded (may change now that Perl for Win32 has a fork() as of 5.005_63). -- Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
apache segfaults on mod_perl dlclose
Hi, After building apache with --shared-module=max and building mod_perl using apxs, I get some strange behavior. I've also built my perl with -g -DDEBUGGING. On starting the web server, I get a bunch of "Bad free() ignored." messages that seem to occur at the end of every block of perl code (ie. scripts, loaded modules, etc.). Then the server segfaults. Using httpd -X and gdb I've found that it cores when trying to do a dlclose() on the mod_perl shared library. Does anyone have an insights as to what might be happening? Backtrace below. Thanks, -Saar Picker Backtrace: (gdb) bt #0 0x401f4624 in ?? () #1 0x4009d0c0 in dlclose_doit (handle=0x80b5fb0) at dlclose.c:26 #2 0x4000a12b in _dl_catch_error (errstring=0x4009ed00, operate=0x4009d0a8 , args=0x80b5fb0) at dl-error.c:141 #3 0x4009d608 in _dlerror_run (operate=0x4009d0a8 , args=0x80b5fb0) at dlerror.c:122 #4 0x4009d08e in dlclose (handle=0x80b5fb0) at dlclose.c:32 #5 0x806f590 in ap_os_dso_unload (handle=0x80b5fb0) at os.c:130 #6 0x804f280 in unload_module (modi=0x80ad2d4) at mod_so.c:181 #7 0x805102e in run_cleanups (c=0x80ae05c) at alloc.c:1706 #8 0x804f85d in ap_clear_pool (a=0x80ad0dc) at alloc.c:531 #9 0x805f803 in standalone_main (argc=4, argv=0xb954) at http_main.c:4469 #10 0x8060093 in main (argc=4, argv=0xb954) at http_main.c:4830 #11 0x400b7cb3 in __libc_start_main (main=0x805fd5c , argc=4, argv=0xb954, init=0x804e890 <_init>, fini=0x8093d6c <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xb94c) at ../sysdeps/generic/libc-start.c:78
RE: Configuring Apache with Problems
Try:
$FilesMatch{'^.*\.pl$'} =
and see if that works (no double quotes).
HTH,
Paul
--
Paul O'Fallon
Project Manager
Manheim Auctions
www.manheim.com
-Original Message-
From: Sam Tregar [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 10, 1999 12:49 PM
To: [EMAIL PROTECTED]
Subject: Configuring Apache with Problems
Hello all. Two questions:
1) These two *look* equivalent:
$FilesMatch{'"^.*\.pl$"'} =
{
SetHandler => 'perl-script',
PerlHandler => 'Apache::Registry',
Options => '+ExecCGI'
};
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
but the second one works and the first doesn't. When I try to use the
first one I get .pl files returned as text, as though the directive were
being ignored. The second one works as expected - *.pl files are handled
by Apache::Registry. Any ideas?
2) Is there any way to get the same warning/error messages from mistakes
in a block that you do from "normal" configuration? I'm thinking
particularily of the warnings you get from setting *SpareServers to
innapropriate values.
I'm working on a server that says "mod_perl/1.15 Red Hat Secure/2.0 (Unix)
mod_perl/1.15 mod_ssl/2.0.7 SSLeay/0.9.0b", in case that helps.
Thanks!
-sam
Re: Configuring Apache with Problems
I had similar problems and discovered that bugs had been fixed in the latest
CVS version, and those fixes fixed my problems. Might be worth a shot.
[EMAIL PROTECTED] (Sam Tregar) wrote:
>Hello all. Two questions:
>
>1) These two *look* equivalent:
>
>
>$FilesMatch{'"^.*\.pl$"'} =
> {
>SetHandler => 'perl-script',
>PerlHandler => 'Apache::Registry',
>Options => '+ExecCGI'
> };
>
>
>
> SetHandler perl-script
> PerlHandler Apache::Registry
> Options +ExecCGI
>
>
>but the second one works and the first doesn't. When I try to use the
>first one I get .pl files returned as text, as though the directive were
>being ignored. The second one works as expected - *.pl files are handled
>by Apache::Registry. Any ideas?
>
>2) Is there any way to get the same warning/error messages from mistakes
>in a block that you do from "normal" configuration? I'm thinking
>particularily of the warnings you get from setting *SpareServers to
>innapropriate values.
>
>I'm working on a server that says "mod_perl/1.15 Red Hat Secure/2.0 (Unix)
>mod_perl/1.15 mod_ssl/2.0.7 SSLeay/0.9.0b", in case that helps.
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: Configuring Apache with Problems
i don't think that:
$FilesMatch{'"^.*\.pl$"'}
should work - it is asking to match a url with quotes around it.
i believe that:
$FilesMatch{'^.*\.pl$'}
is what you are looking for.
if not, then I don't understand the regexp library that apache uses.
if I am wrong - can someone point me to the manual section that
contains the regex rules that the library does use.
cliff rayman
genwax.com
Ken Williams wrote:
> I had similar problems and discovered that bugs had been fixed in the latest
> CVS version, and those fixes fixed my problems. Might be worth a shot.
>
> [EMAIL PROTECTED] (Sam Tregar) wrote:
> >Hello all. Two questions:
> >
> >1) These two *look* equivalent:
> >
> >
> >$FilesMatch{'"^.*\.pl$"'} =
> > {
> >SetHandler => 'perl-script',
> >PerlHandler => 'Apache::Registry',
> >Options => '+ExecCGI'
> > };
> >
> >
> >
> > SetHandler perl-script
> > PerlHandler Apache::Registry
> > Options +ExecCGI
> >
> >
> >but the second one works and the first doesn't. When I try to use the
> >first one I get .pl files returned as text, as though the directive were
> >being ignored. The second one works as expected - *.pl files are handled
> >by Apache::Registry. Any ideas?
> >
> >2) Is there any way to get the same warning/error messages from mistakes
> >in a block that you do from "normal" configuration? I'm thinking
> >particularily of the warnings you get from setting *SpareServers to
> >innapropriate values.
> >
> >I'm working on a server that says "mod_perl/1.15 Red Hat Secure/2.0 (Unix)
> >mod_perl/1.15 mod_ssl/2.0.7 SSLeay/0.9.0b", in case that helps.
>
> ------
> Ken Williams Last Bastion of Euclidity
> [EMAIL PROTECTED]The Math Forum
EmbPerl use HTML::Embperl failed
Hello, I successfully use Modperl together with Embperl for building an Intranet. My environment: NT4.0 / Win95 ( Office / at home ) Perl 5.005_61 mod_perl 1.21 EmbPerl 1.2b9 Everything works fine! Now for the purpose of "offline-browsing" I wanted to generate the HTML-files not dynamically via http but with using "embpexec.bat" in batch. The "use HTML::Embperl" - line fails along with the message Can't load 'C:/perl5/site/5.00561/lib/MSWin32-x86/auto/HTML/Embperl/Embperl.dll' for module HTML::Embperl: load_file:Eine DLL-Initialisierungsroutine ist fehlgeschlagen at C:/perl5/5.00561/lib/MSWin32-x86/DynaLoader.pm line 178. at embp.pl line 1BEGIN failed--compilation aborted at embp.pl line 1. In the PATH-Environment I included the library containing ApacheCore.dll as I found in a previous mail in the mailing list but it didn't work. I suppose it's the same reason as if I include the "use HTML::EmbPerl" into the startup.pl ! When I do this, the server does not start without any message, but if I leave it, EmbPerl loads on the first request so I didn't matter in the past about that (concerning that Apache on Win32 is still an experimental feature ...). Why does my Modperl/EmbPerl work but my EmbPerl (standalone) not ??? Thanks for any help !!! Rolf
RE: Configuring Apache with Problems
On Fri, 10 Dec 1999, O'Fallon, Paul (MAN-Atlanta) wrote:
> $FilesMatch{'^.*\.pl$'} =
>
> and see if that works (no double quotes).
Nope. Actually, I've given up in the block stuff. I switched to a
templatized conf setup which outputs standard Apache configuration syntax
at runtime and a lot of problems have gone away. Configuring in a giant
gave me random seg-faults and strange Apache::DBI errors.
Ah well, it was pretty anyway!
-sam
Re: Configuring Apache with Problems
On Fri, 10 Dec 1999, Ken Williams wrote: > I had similar problems and discovered that bugs had been fixed in the latest > CVS version, and those fixes fixed my problems. Might be worth a shot. I figured as much - I'm saddled with an old mod_perl here, with almost no ability to upgrade. Another time perhaps... Besides, using HTML::Template to configure Apache dynamically has a certain sureal quality that appeals to me. Probably that's because I'm obsessed with HTML::Template, but who's counting? -sam
Intermittent Insecure dependency error
mod_perl group,
I have an issue with mod_perl I'm trying to resolve for several days. I
have a module called Apache::StartPage and is mapped with a Location
directive. Occasionally I have the following error showing up in the error
log from routines in Carp module mapped to $SIG{__WARN__} and $SIG{__DIE__}
interrupts in httpd -X mode:
[Fri Dec 10 17:51:44 1999] [error] Insecure dependency in require while
running with -T switch at (eval 38) line 3.
eval 'require Apache::StartPage
;' called at (eval 38) line 0
[Fri Dec 10 17:51:44 1999] [error] Undefined subroutine
&Apache::StartPage::handler called.
eval {...} called at /dev/null line 0
I have two different mod_perl projects on different architectures (Linux,
HP), and I'm seeing this error type in both. Each project uses only Apache
API (no CGI or Registry) is involved. I like using the strict module, but
it's driving me nuts. Do I have serious problems with the following module
because modperl occasionally rejects it? Is there a mechanism I can put in
place to further trace this error;
package Apache::StartPage;
# File: Apache/StartPage.pm
use strict;
use Apache::Constants qw(:common);
use DBI;
sub handler {
my $r = shift;
my $filename = $r->dir_config('ContentPath') . "start.html";
my $fh = Apache::gensym();
open($fh, $filename) || return NOT_FOUND;
my $projectoptions = undef;
my $id = undef;
my $option = undef;
my $dbh = DBI->connect("DBI:mysql:database","username","password");
my $sth = $dbh->prepare("SELECT projectid,project FROM projects ORDER by
project ASC");
$sth->execute;
while (($id,$option) = $sth->fetchrow) {
$projectoptions .= "$option";
}
$sth->finish;
$dbh->disconnect;
$r->send_http_header("text/html");
read $fh, my $data, -s $filename;
close($fh);
$data =~ s//$projectoptions/;
my $dataref = \$data;
$r->print($$dataref);
return OK;
}
1;
