Slightly OT: DBD::Oracle::ping
Hi!
In the code for DBD::Oracle::db::ping method there are lines
local $SIG{__DIE__};
local $SIG{__WARN__};
As I understand these lines don't do anything though I guess they are supposed
to suppress warning messages and possibly 'die' messages. Currently everytime
when ping fails and we have PrintError => 1 then the message goes into Apache error
log. What is worse if $dbh was disconnected then ping dies and kills the whole
process. As temporary fix we can user $dbh->{RaiseError} = 0, but then we'd
have to rewrite the code that was placed into eval blocks.
Is this a feature or something that should be fixed? Was it supposed to be
local $SIG{__WARN__} = sub {};
Andrei
Apache::DBI usage
Hi!
Apache::DBI is great module of course because it makes things transparent. But
it also makes things confusing. In few cases we have to open and close
connection to database on each request (in particular Oracle on NT gives a lot
of trouble with cached connections).
Currently in such cases I'm using
my $dbh = DBI->connect($dbs, $user, $pass, {AutoCommit => 0}, undef, 'connect')
but this is naturally not documented anywhere. Any chance that this is added
to documentation or some cleaner way of doing this is added to Apache::DBI?
Andrei
tracing memory usage for modules in mod_perl??
Hi! Just wanted to check if it is possible to trace memory usage of each mod_perl modules. It's kind of does not look very realistic, but I do not know the whole truth... Thanks Andrei
Re: Segmentation Fault
The funny part is that in our case we also get Segmentation fault from time to time but there's no coredump file. I even tried to attach gdb to apache child and wait for Segfault. I got it but I'm not sure I could understand it. Please see below for examples. The only thing I can say here that after we drastically reduced usage of module Carp.pm the Segmentation faults almost disappeared. (I mean it. Before the change we had Segfaults 5-6 times every minute. Now we have it once in 20-30 minutes). Please note that Carp::croak was used by Mason object in method 'abort' so we had to stop using it. Andrei -- Program received signal SIGSEGV, Segmentation fault. 0x406041ec in Perl_sv_setsv () from /etc/httpd/modules/libperl.so (gdb) bt #0 0x406041ec in Perl_sv_setsv () from /etc/httpd/modules/libperl.so #1 0x405fa329 in Perl_pp_sassign () from /etc/httpd/modules/libperl.so #2 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so #3 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so #4 0x405ba028 in perl_call_sv () from /etc/httpd/modules/libperl.so #5 0x405ef71f in Perl_vdie () from /etc/httpd/modules/libperl.so #6 0x405ef859 in Perl_die () from /etc/httpd/modules/libperl.so #7 0x406231f6 in Perl_pp_die () from /etc/httpd/modules/libperl.so #8 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so #9 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so #10 0x405ba231 in perl_call_sv () from /etc/httpd/modules/libperl.so #11 0x4059c225 in perl_call_handler () from /etc/httpd/modules/libperl.so #12 0x4059ba6b in perl_run_stacked_handlers () from /etc/httpd/modules/libperl.so #13 0x4059a1c8 in perl_handler () from /etc/httpd/modules/libperl.so #14 0x08054ead in ap_invoke_handler () at eval.c:41 #15 0x0806704c in ap_some_auth_required () at eval.c:41 #16 0x080670c3 in ap_process_request () at eval.c:41 #17 0x0805f6d7 in ap_child_terminate () at eval.c:41 #18 0x0805f919 in ap_child_terminate () at eval.c:41 #19 0x0805fc6b in ap_child_terminate () at eval.c:41 #20 0x080601ac in ap_child_terminate () at eval.c:41 #21 0x080608a3 in main () at eval.c:41 #22 0x40141177 in __libc_start_main (main=0x8060420 , argc=3, ubp_av=0xbb3c, init=0x804fa50 <_init>, fini=0x808a570 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbb2c) at ../sysdeps/generic/libc-start.c:129 (gdb) info frame Stack level 0, frame at 0xb418: eip = 0x406041ec in Perl_sv_setsv; saved eip 0x405fa329 called by frame at 0xb448 Arglist at 0xb418, args: Locals at 0xb418, Previous frame's sp is 0x0 Saved registers: ebx at 0xb40c, ebp at 0xb418, esi at 0xb410, edi at 0xb414, eip at 0xb41c - (gdb) bt #0 0x406059be in Perl_sv_clear () from /etc/httpd/modules/libperl.so #1 0x40605d6f in Perl_sv_free () from /etc/httpd/modules/libperl.so #2 0x405f8afd in Perl_av_clear () from /etc/httpd/modules/libperl.so #3 0x40618ea9 in Perl_leave_scope () from /etc/httpd/modules/libperl.so #4 0x4061758c in Perl_pop_scope () from /etc/httpd/modules/libperl.so #5 0x4061c535 in Perl_die_where () from /etc/httpd/modules/libperl.so #6 0x405efb5a in Perl_vcroak () from /etc/httpd/modules/libperl.so #7 0x405efbf9 in Perl_croak () from /etc/httpd/modules/libperl.so #8 0x406039a5 in Perl_sv_setsv () from /etc/httpd/modules/libperl.so #9 0x405fbd47 in Perl_pp_aassign () from /etc/httpd/modules/libperl.so #10 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so #11 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so #12 0x405ba028 in perl_call_sv () from /etc/httpd/modules/libperl.so #13 0x405ef71f in Perl_vdie () from /etc/httpd/modules/libperl.so #14 0x405ef859 in Perl_die () from /etc/httpd/modules/libperl.so #15 0x406231f6 in Perl_pp_die () from /etc/httpd/modules/libperl.so #16 0x405f9f0a in Perl_runops_standard () from /etc/httpd/modules/libperl.so #17 0x405ba456 in S_call_body () from /etc/httpd/modules/libperl.so #18 0x405ba231 in perl_call_sv () from /etc/httpd/modules/libperl.so #19 0x4059c225 in perl_call_handler () from /etc/httpd/modules/libperl.so #20 0x4059ba6b in perl_run_stacked_handlers () from /etc/httpd/modules/libperl.so #21 0x4059a1c8 in perl_handler () from /etc/httpd/modules/libperl.so #22 0x08054ead in ap_invoke_handler () at eval.c:41 #23 0x0806704c in ap_some_auth_required () at eval.c:41 #24 0x080670c3 in ap_process_request () at eval.c:41 #25 0x0805f6d7 in ap_child_terminate () at eval.c:41 #26 0x0805f919 in ap_child_terminate () at eval.c:41 #27 0x0805fc6b in ap_child_terminate () at eval.c:41 #28 0x080601ac in ap_child_terminate () at eval.c:41 #29 0x080608a3 in main () at eval.c:41 #30 0x40141177 in __libc_start_main (main=0x8060420 , argc=3, ubp_av=0xbb3c, init=0x804fa50 <_init>, fini=0x808a570 <_fini>, rtld_fini=0x4000e184 <_
Re: mod_proxy and mod_perl in guide
These are protected files so we have to use authentication and authorization that is done by mod_perl. And Internet Explorer that use most of our customers has bug that prevents displaying of PDF (and any other large non-dynamic non-HTML) files if the URL to that file was result of "Redirect". Thanks for help. Andrei On Mon, Sep 17, 2001 at 08:55:03AM -0700, ed phillips wrote: > Thanks Vivek, > > Andrei, use the front end to directly handle any binaries, static files, > etc. > > I doubt they are generating of these on the fly. > > > > Vivek Khera wrote: > > > > >>>>> "AAV" == Andrei A Voropaev <[EMAIL PROTECTED]> writes: > > > > AAV> In our system we have to pass large PDF files thru mod_perl to > > AAV> proxy and we noticed that it takes the same time as sending it > > AAV> directly to customer. > > > > Why do you have to pass the PDF thru mod_perl? Are you generating it > > on the fly? If not, configure your proxy front end to intercept > > static documents like .pdf .txt .html etc. to be handled by the front > > end directly. I use mod_rewrite for this, and my configs have been > > posted to this list at least twice. > > > > -- > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Vivek Khera, Ph.D.Khera Communications, Inc. > > Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 > > AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
mod_proxy and mod_perl in guide
Hi! I have one question. According to the Guide there's buffering feature of mod_proxy that allows to release heavy mod_perl process from delivering data over slow connection to the user. In our system we have to pass large PDF files thru mod_perl to proxy and we noticed that it takes the same time as sending it directly to customer. After checking Apache code for mod_proxy looks like it is normal behaviour. File modules/proxy/proxy_util.c function ap_proxy_send_fb. This function reads from originating server into buffer and then writes to the customer from this buffer. BUT the socket is closed AFTER all the data is sent to the client (file module/proxy/proxy_http.c function ap_proxy_http_handler. So the heavy mod_perl server is not released for serving other requests untill the data is sent to the client by proxy. Maybe I'm missing something but the practice shows that this is true and Guide contains error. Please someone check this. Thank you Andrei
Segmentation faults, some strace logs
Here's some output from strace on Linux
Apache 1.13.19 with mod_perl 1.24 and perl 5.6.0
=
04:48:26 stat64("/proj/Web/EMIS/Mason/live/redirect", {st_mode=S_IFREG|0775,
st_size=243, ...}) = 0
04:48:26 stat64("/proj/Web/EMIS/Mason/obj/live/redirect", {st_mode=S_IFREG|0644,
st_size=902, ...})
= 0
04:48:26 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
04:48:26 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
04:48:26 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
04:48:26 --- SIGSEGV (Segmentation fault) ---
04:48:26 chdir("/etc/httpd/core") = 0
04:48:26 rt_sigaction(SIGSEGV, {SIG_DFL}, {SIG_DFL}, 8) = 0
04:48:26 getpid() = 5320
04:48:26 kill(5320, SIGSEGV)= 0
04:48:26 sigreturn()= ? (mask now [])
04:48:26 --- SIGSEGV (Segmentation fault) ---
==
Here's "redirect" Mason component.
<%init>
#$r->status(200);
$r->header_out(Location=>$url);
# Do this so Apache doesn't try to re-read post data
$r->method('GET');
$r->headers_in->unset('Content-length');
# Exit with 302 status
$m->abort(302);
<%args>
$url
===
Looks like the problem is caused by 'abort'. I did not do much digging yet but looks
like
abort calls 'croak'. Unrelational to segv we expirienced strange
"Bizzare copy of ARRAY in aassign in Carp/Heavy.pm line 79" messages at random instead
of display
of nice stack trace.
Could it be some perl5.6.0 bug?
Andrei
An idea on END_REQUEST handler
Hi! Everyone knows that END handlers in packages under mod_perl are executed only when apache terminates. But from time to time there might be a need to execute something when the Request is finished. In practice what I do in these cases is install PerlCleanupHandler which checks all loaded packages and if they define 'END_REQUEST' function then execute that function. Maybe it's worth making it standart feature of mod_perl? Andrei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Make test error!!
Hi! Just to confirm that this is not a single case. I tried the same with apache_1.3.12 and it didn't work. Exactly the same error messages. Finally I gave up and compiled static version. That works without any problem. Andrei On Fri, Sep 15, 2000 at 10:45:32AM +0200, François Chenais wrote: > Hello > > Using perl 5.6.0 > apache_1.3.9 > > I 'm trying to build DSO mod_perl.1.24 > > => perl Makefile.PL USE_DSO=1 EVERYTHING=1 PERL_DEBUG=1 > > All is ok but "make test" says : > > --- > ./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 > done > /usr/local/bin/perl t/TEST 0 > still waiting for server to warm up...not ok > server failed to start! (please examine t/logs/error_log) at t/TEST line > 95. > make: *** [run_tests] Error 111 > --- > > > t/logs/error_log > --- > [notice] END block called for startup.pl > [notice] Destruction->DESTROY called for $global_object > [Fri Sep 15 10:34:40 2000] [warn] [notice] child_init for process 10374, > report > any problems to [no address given] > --- > > > > Any idea ? > > François > -- > [EMAIL PROTECTED] >BULL-CITBtel:(+33) 556 437 848 Home: [EMAIL PROTECTED] > 207, cours du Médoc fax:(+33) 556 437 978 http://www.citb.bull.net > 33000 Bordeaux BullCom: 227 7848 ICQ :3886291 > > Linux - --
Re: MS IE does not accept my cookies!
Actually I can confirm that some of IE browsers refuse to support some
cookies. It sounds weird but I had a case when the broswer would
ignore cookies with 'expires' and accept without it. Though replacing
'expire' with 'Max-Age' helped.
The worst part is that the browser seemed to be "regular" IE 5.x
Andrei
On Fri, Apr 28, 2000 at 09:48:41PM +0200, Ime Smits wrote:
> | $ENV{EMBPERL_SESSION_CLASSES} = "FileStore SysVSemaphoreLocker";
> | $ENV{EMBPERL_SESSION_ARGS}= "Directory=/tmp/algebra.com/sessions";
> | $ENV{EMBPERL_COOKIE_PATH} = "/";
> | $ENV{EMBPERL_COOKIE_DOMAIN} = ".algebra.com";
> | #$ENV{EMBPERL_DEBUG} = 1;
>
> Well... I don't know if you fixed this already but when I click "My
> Homework" on your site, both MSIE 4 and MSIE 5 with Cookie Security Alerts
> enabled (under Content) say:
>
> Cookie Information:
>
> Name: EMBPERL_UID
> Domain: www.algebra.com
> Path: /algebra/homework/my-homework/
> Expires: End of session
> Data: blabalabla
>
> As expected, wget -S shows:
>
> 4 Set-Cookie: EMBPERL_UID=8969568a86ec577a; domain=.algebra.com; path=/;
> expires=Thu, 15 Apr 2010
>
> I can also browse your site without any problem. Some nice things you have
> there! ;)
>
> Bottom line: I guess *your* MSIE is to blame here.
>
> Ime
--
Re: modperl success story
On Fri, Jan 14, 2000 at 12:34:00PM -0800, Ed Phillips wrote: > > >The troll vanisheth! > > ha! > > Reminds me of the Zen story of an old fisherman in a boat on a lake in a heavy can't >see your hands fog. He bumps into another boat, and shouts at the other guy, "Look >where you're going would you! You almost knocked me over." He pulls up beside the >boat and is about to give the other guy a piece of his mind, but when he looks in the >other boat, he discovers that no one else is there. > > Flame trolls on mailing lists are virtual empty boats, whose only value is the >sometimes humorous apoplexy elicited in the old sea salts on the list. Wow, what a story. But poor man probably just didn't realize that this list is not for sucess stories sharing. But for problems discussion :) Andrei --
Re: Attempt to free unreferenced scalar (again)
Could that be somehow connected with the stuff done in modules? I have perl 5.004.04 but I didn't have that problem with the first version of my modules, but after I launched new version that problem became really "popular" I have quite a few of those warnings in my logs. The only big thing that I've changed was using 'push_handlers'. For executing some stuff in the logging phase. But it could be anything else. One more reason why I have suspicion about run time installed handlers is - they broke 'idexdir' directive when I tried to use them for authentication phase. Andrei On Wed, Jan 05, 2000 at 02:16:30PM +, Pete Jordan wrote: > Matt Sergeant wrote: > > > Hmm.. maybe you have an original 5.005 (and no patchlevel) then. I > > seriously recommend a perl upgrade. There were bugs there that have since > > been fixed, and some of those may lead to your error. > > Happens here on Perl 5.005_03, Apache 1.3.6, mod_perl 1.21 all built > locally with gcc 2.95 under Solaris 2.6. > > It's odd: used to happen a lot on server shutdown (ie. when doing an > apachectl graceful), stopped pretty much altogether for a while and just > started again this week under normal operation as well as shutdown. > > Nothing changed at this end that I can think of... > > Pete > -- > use Disclaimer::Standard; # Motorola GSM Software Factory > my $phone='+44 1793 564450'; # "'Not twisted,' Salzy once said of > my $fax='+44 1793 566918';# her own passion, 'it is helical. > my $mobile='+44 7973 725120'; # That sounds better.'" --
Re: [Re: [Re: again - more then one PerlTransHandler]]
I believe this should be reflected in the documentation. Because after reading Eagle book one gets absolutely different understanding. It doesn't diffirentiate Perl stacked handlers and Apache handlers. From Doug's words (and from practice :) those are slightly different in the way how their return codes are treated. BTW. Do I understand it correctly now that if my PERL handler returns either OK or DECLINED then the next PERL handler (if any) for this phase will be called anyway, but Apache "native" handlers will be called depending on what is the phase. Ie. for URL translation the "native" handler will be called only if last Perl handler returned DECLINED. Andrei On Tue, Dec 21, 1999 at 01:45:40PM -0800, Doug MacEachern wrote: > > At least that's what I thought ! > > > > In fact now Apache lets me use more then one > > PerlTransHandler, but it doesn't care > > of what is the return codes are!!! > > > > Even I return OK, it still calls > > next registered handlers. Really weird! > > mod_perl does care. but, mod_perl stacked handlers are not quite the same > as Apache C handlers. unless the return status from a Perl handler is > something other than OK or DECLINED, mod_perl propagates the status code > of the last handler run back up to Apache. > originally, stacked handlers were introduced for chaining multiple content > handlers. if the OK status from the first handler was propagated back to > Apache, there would be no chain, and little use for stacked handlers. > > you can always override this behavior by using a single Perl*Handler which > decides what path to take based on the return status, or use a > PerlDispatchHandler, or PerlDirectiveHandlers, to name a few. > > --
Re: Killing a child process
On Sun, Dec 19, 1999 at 02:12:11PM -0500, Andrei A. Voropaev wrote: > On Sat, Dec 18, 1999 at 12:02:27AM -0800, Bill Moseley wrote: > > > > I think the close() does the wait, so I don't really need to worry about > > reaping my children. > > You are right here. close() does implicit wait on child to finish. > I don't really understand why are you getting SIGPIPE. That signal is > supposed to come only when you WRITE to the pipe and pipe dies. At > least in my tests I could get that signal from pipes that I read from. Sorry I meant to say that I couldn't get SIGPIPE from pipes open for read.
Re: Killing a child process
On Sat, Dec 18, 1999 at 12:02:27AM -0800, Bill Moseley wrote:
>
> I think the close() does the wait, so I don't really need to worry about
> reaping my children.
You are right here. close() does implicit wait on child to finish.
I don't really understand why are you getting SIGPIPE. That signal is
supposed to come only when you WRITE to the pipe and pipe dies. At
least in my tests I could get that signal from pipes that I read from.
>From all my experiments when I have a pipe that I read from then
close() doesn't actually finish the process. It only waits for it to
finish. If you really need to terminate your pipe before it naturally
finishes then you should kill it and then call close. The last will
return you $? non-zero because child terminated abnormally. But it
shouldn't send SIG{PIPE}. All of this I tested under regular perl.
Mod perl could be different because it's actually httpd running.
I took a rule for myself. If I have to execute external program from
my code then that code doesn't make it into mod_perl. Simply because
it's not worth it. All my savings are nothing comparing to the effort
of doing fork and starting external program. The chain is as weak as
the weakest ring.
Andrei
--
Re: again - more then one PerlTransHandler
It works perfectly well for me. I have modperl 1.21, apache 1.3.9 on RedHad linux (5.2). I install any number of TransHandlers and as long as each one of them returns DECLINED they are all executed. I tried both ways (one line and multiple lines) and everything has worked. Probably you just need to make sure that you used EVERYTHING=1 when you compiled modperl. That's what I had and nothing else. Andrei On Mon, Dec 13, 1999 at 06:41:45AM -0700, Evgenii Bazarov wrote: > Hi everybody, > > Sorry for the poor wording of my question. Once again: > > I am trying to install and use more then one translation > handler. I tried two approaches to specifying handlers > in the Apache config file (both recommended in the > "Eagle" book.) First, have both handlers on the same line, > e.g. in httpd.conf > > PerlTransHandler SimpleTranslation::handler FancyTranslation::handler > > In this case Apache spits out error: > > Syntax error on line 29 of /etc/httpd/conf/perl.conf > PerlTransHandler takes one argument, the Perl Translation handler routine > name. > > and exits. > > Secondly I tried to put two lines in config: > > PerlTransHandler SimpleTranslation::handler > PerlTransHandler FancyTranslation::handler > > In this case, only second handler gets invoked. > Am I missing something?!!! > > Evg > > > > > Hi! > > I tried to set more then one PerlTransHandler but > if I specify both on the same line, Apache says > "syntax error", otherwise it see only the last one. > > Apache 1.3.6 on Linux with mod_perl 1.19 > > According to "Apache Modules" book it should be > possible... Any advice will be highly appreciated! > > Cheers, > Evg > > > > > Get free email and a permanent address at http://www.netaddress.com/?N=1 --
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. Andrei 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 --
PerlRun and fork
Hi! I'm thinking about using PerlRun for some legacy scripts that don't use 'my' or use it in wrong places. But I hit one question that I'd like to know the answer for. PerlRun provides perl interperter that is built into Apache which saves time on starting new interpreter. Does it mean that it evals CGI script? If it does then what happens when that script does fork? Does it create new instance of httpd since perl interpreter is built into httpd? Thank you. Andrei --
Re: Redirect While Maintaining Environment?
Where do you get that sensitive information from? If it is originated on your own server then why can't CGI script get it without mod_perl? Or why can't you do internal redirect and put that information into query string? It doesn't go outside of your server anyway. If it is coming from client machine then there's nothing secure about it. Cookies are stored in flat file and anyone can see what you hiding there. As to ENV variables. Could PassEnv directive have something to do with that? Andrei On Wed, Dec 08, 1999 at 03:45:50PM -0500, Jason Simms wrote: > Thanks for the advice, and this brings up another question... Honestly, if > I were using an internal redirect, I wouldn't need to bother with these > environment variables at all. The problem is that many times before I do > this redirect, I also need to set a cookie. Am I correct in assuming that > an internal redirect does NOT have the ability to set a cookie? > > The entire reason I have to do this is that I need to pass sensitive values > to the CGI script from the module. I do not wish to use a simple query > string, as the end user would then be able to intercept this. I want to > pass values to the "child" CGI script (even though it is an entirely new > request) without them being able to be intercepted easily. Hence, I thought > if I could give the script access to the environment, I wouldn't need to > pass the parameters over through the URI. Is there anohter way to do this? > > Jason > > >If you redirect, that's most likely telling the web browser to fetch > >the new page. This makes it a totally new request. > > > >However, if you're using internal_redirect, then subprocess_env >should do > >the trick, but the ENV values will be prefixed with >"REDIRECT_". > > __ > Get Your Private, Free Email at http://www.hotmail.com --
Re: Associative Arrays problem
Since the broken code worked in regular perl (and it was supposed to work
because $rech and %rech are different things) and it didn't want to work
in emb perl then there must be something strange about it.
Was it an error in testing code (ie. checking $rech->{keys} instead of
$rech{keys} at the end) or emb perl puts some restrictions on variables that
I can use? Again. There's nothing wrong from the regular perl stand point if
I say $rech = {}; and then $rech{'key'} = $value; perl creates different
variables and as long as I use them correctly there shouldn't be a problem.
Of course if I try to access $rech->{'key'} I'll get empty value later :)
So, was it an error in real testing code? Because the code that I saw didn't
contain that error.
Andrei
On Tue, Dec 07, 1999 at 12:18:32PM -0700, Tim Tompkins wrote:
>
> $rech is a hashref, not a hash. de-reference it with arrow notation.
>
>
> %toto = ( "001" => 1, "002" => 2, "003" => 3 );
> %tato = ( "004"=> 4, "002"=> 5, "005"=> 6 );
> $rech = {};
> $nb = 2;
> for $mot (keys %toto) { $rech->{$mot} = 1; }
> for $mot (keys %tato) { if (defined $rech->{$mot}) { $rech->{$mot}++; } }
> $recherche = join(',', map { "'$_'" } grep { $rech->{$_}==$nb } (keys
> %$rech));
>
> DUMP --
>
> $rech = {
> '001' => 1,
> '002' => 2,
> '003' => 1
> };
>
> $recherche = '002'
>
>
>
>
> Thanks,
>
> Tim Tompkins
> --
> Programmer / IS Technician
> http://www.arttoday.com/
>
>
> - Original Message -
> From: Cédric Avena <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, December 07, 1999 6:27 AM
> Subject: Associative Arrays problem
>
>
> > Hi,
> >
> > I'm using associative arrays in ASP 0.16, but it doesn't work... I have
> > taken the same portion of code in a .pl file and execute it, it works...
> >
> > Do associative arrays work with modperl ? Could anybody help me ?
> >
> > An extract of my program:
> > %toto = ( "001" => 1, "002" => 2, "003" => 3 );
> > %tato = ( "004"=> 4, "002"=> 5, "005"=> 6 );
> > $rech = {};
> > $nb = 2;
> > for $mot (keys %toto) { $rech{$mot} = 1; }
> > for $mot (keys %tato) { if (defined $rech{$mot}) { $rech{$mot}++; } }
> > $recherche = "";
> > for $mot (keys %rech) { if ($rech{$mot}==$nb) { $recherche .=
> > "'$mot',"; } }
> > chop($recherche);
> >
> > $recherche equals "'002'" with single perl programming
> > $recherche equals "" with ASP programming
> >
> > Thanks in advance...
> > --
> > Cedric Avena
> > WAW - Web At Work - Tel: +33 (0)491 812 145
> > mailto:[EMAIL PROTECTED] - http://www.waw.com
> >
> >
--
Re: System calls to return data via STDOUT
It's better not to put this stuff into mod_perl because you'll have issues with memory
etc. And the time you gain is nothing to compare with the time needed
to start external process.
Put it in regular CGI script. And to catch output from external program
use standart methods like backticks, pipe, etc. If you need to provide some
input to that external program then you may want to use the following method.
$pid = open(IN, "-|");
if($pid == 0){ #child, STDOUT -> parent
open(OUT, "|external_program");
print OUT @stuff_for_external_program;
close(OUT); # wait for it to finish;
exit 0;
}
@from_external_program = ;
Add child reaper and you should be all set.
Andrei
On Tue, Dec 07, 1999 at 01:53:20AM -0800, hamid khoshnevis wrote:
> I am trying to call Glimpse from modperl and capture the data set back.
> After I wrote the email, I was told by a friend that I should use temporary
> files to capture the output of Glimpse.
>
> Any ideas??
>
> hamid
>
>
> >From: "G.W. Haywood" <[EMAIL PROTECTED]>
> >To: mod_perl Mailing List <[EMAIL PROTECTED]>
> >Subject: System calls to return data via STDOUT
> >Date: Mon, 6 Dec 1999 19:01:23 + (GMT)
> >
> >Hi all,
> >
> >On Sun, 5 Dec 1999, hamid khoshnevis <[EMAIL PROTECTED]> wrote:
> >
> > > I am a newbie modperl'er
> >
> >Welcome to the club.
> >
> > > I am tyring to get system calls to return data to modperl (via stdout).
> >
> >The idea of mod_perl is to get things to go faster by avoiding as much
> >as possible the (time consuming) launching of new processes and things
> >like that. Are your system calls launching new processes? If so, you
> >may not be getting the benefits of mod_perl but you'll be getting the
> >disadvantages (huge memory consumption to name but a few).
> >
> >What is making the system calls and why?
> >Is There More Than One Way To Do It?
> >
> >73
> >Ged.
> >
>
> __
> Get Your Private, Free Email at http://www.hotmail.com
--
Re: PerlFreshRestart and %INC
As far as I know connect_cached didn't show up untill latest versions
of DBI. And unfortunately our production services don't use those
versions.
Though there's still a disclaimer saying that the behaviour is subject
to change. Whatever. Can't I simply get rid of Apache::DBI since DBI
itself offers almost the same thing?
Andrei
On Sun, Dec 05, 1999 at 06:27:50PM -0800, Jeffrey W. Baker wrote:
> Tim Bunce wrote:
>
> > > I've always thought the "must load Apache::DBI before DBI" thing was a
> > > bit weird anyway. Can't you just make it a flag that DBI looks at
> > > that Apache::DBI sets?
> >
> > The idea was to avoid run-time overhead by setting things up a
> > compile time.
> >
> > I guess I could add something like this:
> >
> > DBI->default_connect_method("Apache::DBI::connect");
> >
> > which Apache::DBI could call, after a "use DBI;", to get itself
> > plugged in.
>
> Ew. That is pegging my wankometer. Doesn't connect_cached do the same
> thing that most of Apache::DBI does? Why doesn't Apache::DBI just
> inherit everything but connect() and disconnect() from DBI?
>
> IMHO Apache::DBI causes more problems than it solves with it's
> "transparent" replacement of DBI functions. Can anyone point to an
> example where a subclass of DBI would not do everything that Apache::DBI
> does, except without the headaches?
>
> -jwb
--
Re: fragment in $r->uri
Correct too. Though Apache::URI::fragment() is present and even documented :) Probably because some browsers pass this fragment to the server? Andrei On Mon, Nov 29, 1999 at 10:16:04AM -0800, Randal L. Schwartz wrote: > > "brian" == brian moseley <[EMAIL PROTECTED]> writes: > > brian> im requesting the url > > brian> http://www.maz.org/foo/index.html#perl > > brian> it appears that neither $r->uri nor $r->parsed_uri retain > brian> any knowledge of the fragment. they both return > > brian> /foo/index.html > > brian> is there any way for me to retrieve the fragment info short > brian> of parsing $r->the_request? > > The server never sees the "fragment", and rightfully so. > That's for the client only, to scroll down to by looking for > once the page has been downloaded. The server never knows that happened. > > -- > 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: fragment in $r->uri
I've had the same problem. There's a mistake in the Eagle book when it
states that $r->the_request() eq join(' ', $r->method, $r->uri,
$r->protocol).
Proper way to access fragment as well as query_string is to use
my $uri = $r->parsed_uri();
my $fragment = $uri->fragment();
Andrei
On Mon, Nov 29, 1999 at 10:04:24AM -0800, brian moseley wrote:
>
> im requesting the url
>
> http://www.maz.org/foo/index.html#perl
>
> it appears that neither $r->uri nor $r->parsed_uri retain
> any knowledge of the fragment. they both return
>
> /foo/index.html
>
> is there any way for me to retrieve the fragment info short
> of parsing $r->the_request?
>
--
Re: HTTP 1.0 / 1.1
When a browser claims that it supports HTTP/1.1 it doesn't mean that it uses it for each request. I believe that in general case browser always uses HTTP/1.0 which is logged in apache log. I'm not sure how to make the same browser to use HTTP/1.1 as default protocol. I guess you shouldn't because not all webservers support it yet :) Still I think that if Apache returns HTTP/1.1 as protocol then browser will correctly handle it (multi-part transactions etc.) Andrei On Mon, Nov 29, 1999 at 08:20:19AM -0800, Jeffrey Baker wrote: > Pouneh Mortazavi wrote: > > > > OK. so this is unrelated to the modperl mailing list. but its an > > interesting question. If you know anywhere else I could post this, > > please tell me. > > > > I'm trying to find out how many clients support HTTP 1.1 features such as > > keepalives and domain-name based virtual hosts. > > > > Apparently netscape 3+,ie4+ all run HTTP 1.1. Which is good. This is 95% > > of my user agents. > > > > When I look through the logs however, I see a *huge* amount of HTTP 1.0 > > requests from what are claimed to be http 1.1 compliant browsers. I get 3 > > times more HTTP1.0 requests than HTTP1.1 requests. I can understand that > > some of these user agent strings may be rogue spiders/browsers > > masquarading as netscape/ie ... but not that many! > > > > Can anyone explain, why this would be the case? I know that my apache > > servers can implement HTTP protocol negotiation, but I definately do not > > do that in my conf files... > > > > Has anyone else done any analysis on their webserver logs for http > > protocols? > > I'm not terribly familiar with the Apache log format. Are you sure that > the log records the protocol level in the request, or the protocol level > of the response? The standard Apache config files include a rule to > downgrade certain user agents to HTTP 1.0. Is this rule in your config > file? > > Might an intervening proxy downgrade the request to 1.0? > > Regards, > Jeffrey > > -- > Jeffrey W. Baker * [EMAIL PROTECTED] > Critical Path, Inc. * we handle the world's email * www.cp.net > 415.808.8807 --
Re: directoryindex is not retrieved
On Thu, Nov 25, 1999 at 08:18:04PM +0100, Eric Cholet wrote: > > Pushing a handler for the current phase ? Is this legal ? I wonder. > I don't remember it for sure and don't have the book around to check but I think this is used for content handling and even given as an example of chained handlers. In reality the only reason why I used it was to ensure that second handler is executed AFTER the first one. Since it didn't work I had to rely on good behaviour of system administrator that he will not swap the lines in Apache configuration. :) Andrei --
Re: directoryindex is not retrieved
Well, since nobody replied I started digging myself. Here's what I
found.
The problem below is caused by push_handlers method in Authorization
handler.
You can reproduce it if you use the following set up.
--- module
package Apache::MasterAuth;
use Apache::Constants qw(:common);
use strict;
sub authz1_handler{
my $r = shift;
$r->warn('Session handling' . $r->is_initial_req);
return OK;# unless $r->is_initial_req;
}
sub authen_handler{
my $r = shift;
my $log = $r->log;
$log->warn("AUTN: Checking " . $r->filename() . 'Initial ' . $r->is_initial_req());
return OK;# unless $r->is_initial_req;
}
sub authz_handler{
my $r = shift;
my $log = $r->log;
$log->warn("AUTZ: Checking " . $r->filename() . ' Initial '. $r->is_initial_req());
return OK unless $r->is_initial_req;
$r->push_handlers('PerlAuthzHandler' , \&authz1_handler);
return OK;
}
1;
--- configuration ---
DirectoryIndex index.html
AuthType Basic
AuthName "test"
PerlAuthenHandler Apache::MasterAuth::authen_handler
PerlAuthzHandler Apache::MasterAuth::authz_handler
Options FollowSymLinks
AllowOverride None
require valid-user
--
As soon as you comment out the line with push_handlers from perl
module everything starts working fine.
The set up which I have Linux box, Apache1.3.9, mod_perl 1.21 with
patch for fixing corrupted PATH aplied, perl 5.004_4
It is important because I couldn't reproduce this problem on the
system with perl 5.005_3 and without patch for PATH corruption.
In both cases Apache is statically linked.
While testing this stuff I hit one unclear situation. push_handlers is
supposed to install new handler for duration of one request only. But
when subrequests (or internal redirects) happen does it mean that new
handlers I've installed during initial request are still going to be
called in subrequests?
I'm asking because in the error log I can clearly see that after
internal redirect the handler that I've installed using push_handlers
is not called.
Some specualtions of mine :)
As the side note I should mention that this has also helped problem
with "Attempts to free unreferenced scalar..." error. It almost
completely is gone. I still use push_handlers in other handlers but
that doesn't happen very often and probably this explains why there's
just few of those errors.
Andrei
PS. If this is problem due to older version of perl then it's
great. I'll just upgrade perl. If on the other hand this is problem
with patch for PATH then this needs fix. Just in case here's the patch
I've used.
--- mod_perl.h 1999/08/03 22:56:09 1.84
+++ mod_perl.h 1999/08/04 02:53:38
@@ -286,9 +286,10 @@
#define mp_setenv(key, val) \
{ \
int klen = strlen(key); \
-hv_store(GvHV(envgv), key, klen, newSVpv(val,0), FALSE); \
+SV *sv = newSVpv(val,0); \
+hv_store(GvHV(envgv), key, klen, sv, FALSE); \
HV_SvTAINTED_on(GvHV(envgv), key, klen); \
-my_setenv(key, val); \
+my_setenv(key, SvPVX(sv)); \
}
#define mp_SetEnv(key, val) \
>
>
> PerlAuthenHandlerApache::MyAuth::authen_handler
> .
>
>
> Everything works fine except for retrieving index files for
> directories. Requests for http://my.site.com/any/dir/
> end up with message "you don't have permission to access
> /any/dir/ on this server" and line in error log
> "Directory index forbidden by rule: /proj/Web/94dec/any/dir/"
>
> I'm running Apache 1.3.9, mod_perl 1.21 staticaly linked on Linux box.
>
> And unfortunately I can't rewrite my configuration to use
> And there is DirectoryIndex directive in my configuration files.
> And my authentication/authorization handler doesn't care about the URL being
> requested, only the require field values.
>
> Anyone has looked into that really?
>
> Andrei
>
> --
--
directoryindex is not retrieved
Hi! I have problem with index files for directories not being read under mod_perl. According to mod_perl guide this happened for those who "declared mod_perl configuration inside a section for all files matching to *.pl. The problem has gone away after placing the usage of mod_perl in a - section." This is not true for me. My configuration is PerlAuthenHandlerApache::MyAuth::authen_handler . Everything works fine except for retrieving index files for directories. Requests for http://my.site.com/any/dir/ end up with message "you don't have permission to access /any/dir/ on this server" and line in error log "Directory index forbidden by rule: /proj/Web/94dec/any/dir/" I'm running Apache 1.3.9, mod_perl 1.21 staticaly linked on Linux box. And unfortunately I can't rewrite my configuration to use And there is DirectoryIndex directive in my configuration files. And my authentication/authorization handler doesn't care about the URL being requested, only the require field values. Anyone has looked into that really? Andrei --
Duplicated emails from mod_perl list
Hi! Probably this is off-topic. But it's about the list itself. Why do I get OLD emails from time to time. Today I got about 7 or 8 of those. I'm absolutely positive that I've seen them once before. Some of those emails are dated Nov. 16th This happened 2 or 3 times already so I decided to ask. Maybe there's some problem? Does anyone else gets them? Andrei --
Re: perl variable in configs for few virtual servers
It's Apache 1.3.9, mod_perl 1.21 on Linux.
The only change I have is patch for correcting PATH enviroment
corruption provided by Doug.
Andrei
On Tue, Nov 16, 1999 at 05:29:46PM +0100, Eric Cholet wrote:
> Which version of mod_perl are you using, 1.21 or the CVS version perhaps?
>
> > Hi!
> >
> > I've encountered very interesting problem. When I set some variable
> > using PerlSetVar in configuration files for different virtual servers
> > they seem to be available to ALL of those virtual servers.
> >
> > Here's details to clarify.
> >
> > In httpd.conf I have
> >
> >
> > ServerName myhost1.domain.com
> > DocumentRoot /httpd/docs
> > ErrorLog logs/httpd-errors
> > CustomLog logs/httpd-log common
> > AccessConfig conf/access.conf
> > ResourceConfig conf/srm.conf
> >
> >
> >
> > ServerName myhost2.domain.com
> > DocumentRoot /httpd/docs
> > ErrorLog logs/httpd2-errors
> > CustomLog logs/httpd2-log common
> > AccessConfig conf/access2.conf
> > ResourceConfig conf/srm2.conf
> >
> >
> >
> > Now in srm.conf I set
> >
> > PerlSetVar MyVariable MyValue
> > PerlAuthenHandlerApache::Myhandler
> >
> >
> > And in srm2.conf I have
> >
> > PerlSetVar MyVariable2 MyValue2
> > PerlAuthenHandlerApache::Myhandler
> >
> > In Myhandler::handler I do
> > $myvar1 = $r->dir_config('MyVariable');
> > $myvar2 = $r->dir_config('MyVariable2);
> >
> > if($myvar1){
> > ## do stuff for first virtual server
> > }else{
> > ## do stuff for the second one
> > }
> >
> > But $myvar1 appears to be ALWAYS set. Which leads me to belief that
> > mod_perl "shares" variables between virtual servers if those variables
> > are not explicitly set in configuration for that server.
> >
> > Is this supposed to be this way? Or am I missing something?
> >
> > Andrei
> >
> > --
>
--
Re: PATH corruption in mod_perl
I've used the patch sent by Doug.
--- mod_perl.h 1999/08/03 22:56:09 1.84
+++ mod_perl.h 1999/08/04 02:53:38
@@ -286,9 +286,10 @@
#define mp_setenv(key, val) \
{ \
int klen = strlen(key); \
-hv_store(GvHV(envgv), key, klen, newSVpv(val,0), FALSE); \
+SV *sv = newSVpv(val,0); \
+hv_store(GvHV(envgv), key, klen, sv, FALSE); \
HV_SvTAINTED_on(GvHV(envgv), key, klen); \
-my_setenv(key, val); \
+my_setenv(key, SvPVX(sv)); \
}
#define mp_SetEnv(key, val) \
If works fine for me. (Apache 1.3.9, mod_perl 1.21, Linux)
Andrei
On Tue, Nov 16, 1999 at 11:03:01AM -0500, Carl Tichler wrote:
> Hello,
>
> I have seen a series of previous posts on this problem in mod_perl. I am
> running Linux (Red Hat 6.0, kernel 2.2.5), Perl 5.00503 and mod_perl 1.21. My
> symptoms are that the PATH environment variable is corrupted in the Apache
> runtime (visible using cgi-bin), but NOT in anything executing through mod_perl
> (Apache::Registry). I would just like to know the status of tracing this bug,
> and any patches or testing I might do to help trace this.
>
> Carl Tichler
> [EMAIL PROTECTED]
--
Re: perl variable in configs for few virtual servers
Well, sorry. I've forgotten to put 'my' in front of those varibles in
the example. In the actual code it is there (I use strict :)
The problem is not there.
Andrei
On Tue, Nov 16, 1999 at 05:02:49PM +0100, Gerald Richter wrote:
> > In Myhandler::handler I do
> > $myvar1 = $r->dir_config('MyVariable');
> > $myvar2 = $r->dir_config('MyVariable2);
> >
> > if($myvar1){
> > ## do stuff for first virtual server
> > }else{
> > ## do stuff for the second one
> > }
> >
> If $myvar1 is a global it will hold it's content forever...
>
> so try
>
> my $myvar1 = $r->dir_config('MyVariable');
> my $myvar2 = $r->dir_config('MyVariable2);
>
> Gerald
--
perl variable in configs for few virtual servers
Hi!
I've encountered very interesting problem. When I set some variable
using PerlSetVar in configuration files for different virtual servers
they seem to be available to ALL of those virtual servers.
Here's details to clarify.
In httpd.conf I have
ServerName myhost1.domain.com
DocumentRoot /httpd/docs
ErrorLog logs/httpd-errors
CustomLog logs/httpd-log common
AccessConfig conf/access.conf
ResourceConfig conf/srm.conf
ServerName myhost2.domain.com
DocumentRoot /httpd/docs
ErrorLog logs/httpd2-errors
CustomLog logs/httpd2-log common
AccessConfig conf/access2.conf
ResourceConfig conf/srm2.conf
Now in srm.conf I set
PerlSetVar MyVariable MyValue
PerlAuthenHandlerApache::Myhandler
And in srm2.conf I have
PerlSetVar MyVariable2 MyValue2
PerlAuthenHandlerApache::Myhandler
In Myhandler::handler I do
$myvar1 = $r->dir_config('MyVariable');
$myvar2 = $r->dir_config('MyVariable2);
if($myvar1){
## do stuff for first virtual server
}else{
## do stuff for the second one
}
But $myvar1 appears to be ALWAYS set. Which leads me to belief that
mod_perl "shares" variables between virtual servers if those variables
are not explicitly set in configuration for that server.
Is this supposed to be this way? Or am I missing something?
Andrei
--
Re: setting cookies?
No. This is not true. If browser gets 401 in response to request with user authentication then it pops up the dialog box. And only if user clicks "Cancel" then it displays the Authentication failed document. Only if you send 403 then browser will not prompt user for new user name and password. At least it works this way with IE and Netscape. Andrei On Tue, Nov 02, 1999 at 02:29:10PM -0500, Greg Stark wrote: > > I think if you send a 401 in response to a request that contained auth data > the user will typically see a "Authentication failed" box, which may look bad > compared to just getting the password dialog. > > Actually I couldn't get this to work a while back, but I didn't try very hard. > > > "Andrei A. Voropaev" <[EMAIL PROTECTED]> writes: > > > On Mon, Nov 01, 1999 at 05:03:58PM -0500, Robin Berjon wrote: > > > I've never tried this but doesn't sending two 401s in a row for the same > > > document have the auth popup appear again ? > > > > I feel like this topic gets slightly confusing. Browser sends request, > > gets 401 back, asks user for username and password if it doesn't have > > one cached already. If it has one cached for this particular realm > > then it attempts to send the cached values. If in response it gets 401 > > again then it asks user for new username and password for this realm. > > As far as I know it always takes 2 requests to get protected > > document. First one returns with 401 code and realm for authentication, > > second request is done with appropriate user name and password. > > > > So if for some reason you decide that some user name and password is > > not valid any more then you should make sure that if they are sent any > > number of times later then your authentication handler says no > > always. > > > > Andrei > > > > -- > > > > -- > greg --
Re: setting cookies?
On Mon, Nov 01, 1999 at 05:03:58PM -0500, Robin Berjon wrote: > I've never tried this but doesn't sending two 401s in a row for the same > document have the auth popup appear again ? I feel like this topic gets slightly confusing. Browser sends request, gets 401 back, asks user for username and password if it doesn't have one cached already. If it has one cached for this particular realm then it attempts to send the cached values. If in response it gets 401 again then it asks user for new username and password for this realm. As far as I know it always takes 2 requests to get protected document. First one returns with 401 code and realm for authentication, second request is done with appropriate user name and password. So if for some reason you decide that some user name and password is not valid any more then you should make sure that if they are sent any number of times later then your authentication handler says no always. Andrei --
Re: Intentional Premature Finish in an Apache Module
On Thu, Oct 28, 1999 at 02:07:12PM -0400, Ken Y. Clark wrote: > > when i tried to assign my error intothe pnotes hash with the comma operator > e.g., "$r->pnotes(ERROR_NAME =>$err)" > i got errors, and i don't know why. Oh, that's because everything to the left of => is treated as string unless there's something that tells perl otherwise. I used +CONSTANT syntax and it worked for me. Andrei --
[andrei@securities.com: Installing handler. Anonymous subs vs code returning ref]
Sorry. Contrary to the replies I couldn't install handler as arbitrary
perl code that returns reference to code. Only "sub {your code here}"
actually works. Everything else logs error when attempting to fetch
the URL.
Andrei
- Forwarded message from "Andrei A. Voropaev" <[EMAIL PROTECTED]> -
Date: Fri, 15 Oct 1999 08:53:25 -0400
From: "Andrei A. Voropaev" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Installing handler. Anonymous subs vs code returning ref
Mail-Followup-To: [EMAIL PROTECTED]
X-Mailer: Mutt 0.95.4i
Hi!
Quick question. It's mentioned in the book that I may provide
anonymous subroutine as a handler. Does it have to be sub declaration
or any arbitrary perl code that return reference to sub would do?
Andrei
--
- End forwarded message -
--
Installing handler. Anonymous subs vs code returning ref
Hi! Quick question. It's mentioned in the book that I may provide anonymous subroutine as a handler. Does it have to be sub declaration or any arbitrary perl code that return reference to sub would do? Andrei --
Re: internal_redirect and POST
On Fri, Oct 08, 1999 at 05:05:41PM +0200, Eric Cholet wrote: > On Friday, October 08, 1999 3:35 PM, Andrei A. Voropaev > > Well. I wish you have also mentioned how to unset $r->content() > > because it reads content only once. Second time returns undef. The > > But you shoudn't be radubg $r->content for a GET, right? > Right :) You just missed the point. I want to read content (using $r->content) to check what is being passed and then redirect that same content to another handler. That new handler should be able to read it from some place. I fool it to believe that method is get not post, so it'll try to read $r->args. But it will also return empty string. So far the only way around it that I know is to chain handlers, and not use internal redirect. Andrei --
Re: internal_redirect and POST
On Fri, Oct 08, 1999 at 09:39:30AM +0200, Eric Cholet wrote:
> On Friday, October 08, 1999 3:35 AM, Dmitry Beransky [SMTP:[EMAIL PROTECTED]] wrote:
> > I've been playing around with internal redirects of POST requests. They
> > seem to work fine as long as I don't call Apache::content() or any other
> > function that reads a request's content. However, as soon as I read it,
>
> This has come up before. Try this (snippet courtesy DougM :-)
>
> my $r = shift;
> $r->method("GET");
> $r->method_number(M_GET);
> $r->headers_in->unset("Content-length");
> $r->internal_redirect_handler("/new/url");
>
Well. I wish you have also mentioned how to unset $r->content()
because it reads content only once. Second time returns undef. The
same seems to be true for $r->read. As to $r->args it's not mentioned
in the book that you can call $r->args($new_query_string) to set new
query string. And if we do internal redirect then we usually need to
provide the content string for it.
Andrei
Re: Guide addition?
On Thu, Oct 07, 1999 at 03:59:37PM +0200, Stas Bekman wrote:
> That's almost correct, what it does is taken a script sitting at
> URI /perl/test.pl:
>
> print "Content-type: text/plain\n\n"
> print "mod_perl rules!\n"
>
> perl actually sees it as:
>
> package Apache::ROOT::perl::test_2epl;
> use Apache qw(exit);
> sub handler {
>print "Content-type: text/plain\n\n"
>print "mod_perl rules!\n"
> }
>
>
> So if you script included __END__ or __DATA__ token like:
>
> print "Content-type: text/plain\n\n"
> print "mod_perl rules!\n"
> __END__
> some junk here
>
>
> perl actually sees it as:
>
> package Apache::ROOT::perl::test_2epl;
> use Apache qw(exit);
> sub handler {
>print "Content-type: text/plain\n\n"
>print "mod_perl rules!\n"
> __END__
> some junk here
> }
Would it be possible to remove everything after __END__ before
wrapping it into a function? Very often this is simply
documentation. How about =pod and other tokens? Do they also break the code?
Sorry, didn't use Registry so far :)
Andrei
--
Re: perl variable in configs for few virtual servers
Ok. I think I've figured that out
Reading documentation on Apache ResourceConfig directive. It states
--
Syntax: ResourceConfig filename
Default: ResourceConfig conf/srm.conf
Context: server config, virtual host
Status: core
The server will read this file for more directives after reading the
httpd.conf file. Filename is relative to the ServerRoot. This feature
can be disabled using:
ResourceConfig /dev/null
--
Which explains everything. I have 2 configs srm.conf and srm1.conf.
The first one is read BEFORE defining virtual servers that is why
variables from it are available in all virtual servers.
As usually I should have RTFM before complaining :)
Andrei
On Fri, Nov 19, 1999 at 10:09:33AM -0500, Andrei A. Voropaev wrote:
> Let me try that.
>
> Andrei
>
> On Fri, Nov 19, 1999 at 03:43:40PM +0100, Eric Cholet wrote:
> > But do you see the behaviour I see, that is, the problem is related to
> > the fact that you're using ResourceConfig? If you do this:
> >
> >
> > PerlSetVar var1 value1
> >
> >
> >
> > PerlSetVar var2 value2
> >
> >
> >
> > Now when you call a script in host2 do you see var1 as being set?
> >
> >
> > > Interesting. I can reproduce this problem on my machine easily. And
> > > it's pretty painful too because customers couldn't access my second
> > > virtual server for exactly that reason. As a quick fix I had to set
> > > the same variable to have different values. This works perfectly.
> > >
> > > Maybe it has something to do with the way I've set up my virtual
> > > hosts?
> > >
> > > I've checked few times already. I don't source srm.conf anywhere
> > > outside of , so the problem is not there
> > > definetely.
> > >
> > > Anyway, I'll read Apache documentation on setting up Virtual
> > > Hosts. And do more testing. Basically this has come up only because I
> > > was too lazy to change couple lines in my module to expect different
> > > values from the same variable.
> > >
> > > Andrei
> > >
> > >
> > > On Fri, Nov 19, 1999 at 12:40:24PM +0100, Eric Cholet wrote:
> > > > Andrei,
> > > >
> > > > I do not see this behavior if I use PerlSetVar directly inside a
> > > > section instead of via a ResourceConfig. I do see it if I move the directive
> > > > to the main server, so I suppose it's a scope issue with ResourceConfig.
> > > >
> > > >
> > > > > It's Apache 1.3.9, mod_perl 1.21 on Linux.
> > > > >
> > > > > The only change I have is patch for correcting PATH enviroment
> > > > > corruption provided by Doug.
> > > > >
> > > > > Andrei
> > > > >
> > > > > On Tue, Nov 16, 1999 at 05:29:46PM +0100, Eric Cholet wrote:
> > > > > > Which version of mod_perl are you using, 1.21 or the CVS version perhaps?
> > > > > >
> > > > > > > Hi!
> > > > > > >
> > > > > > > I've encountered very interesting problem. When I set some variable
> > > > > > > using PerlSetVar in configuration files for different virtual servers
> > > > > > > they seem to be available to ALL of those virtual servers.
> > > > > > >
> > > > > > > Here's details to clarify.
> > > > > > >
> > > > > > > In httpd.conf I have
> > > > > > >
> > > > > > >
> > > > > > > ServerName myhost1.domain.com
> > > > > > > DocumentRoot /httpd/docs
> > > > > > > ErrorLog logs/httpd-errors
> > > > > > > CustomLog logs/httpd-log common
> > > > > > > AccessConfig conf/access.conf
> > > > > > > ResourceConfig conf/srm.conf
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ServerName myhost2.domain.com
> > > > > > > DocumentRoot /httpd/docs
> > > > > > > ErrorLog logs/httpd2-errors
> > > > > > > CustomLog logs/httpd2-log common
> > > > > > > AccessConfig conf/access2.conf
> > > > > > > ResourceConfig conf/srm2.conf
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Now in srm.conf I set
> > > > > > >
> > > > > > > PerlSetVar MyVariable MyValue
> > > > > > > PerlAuthenHandlerApache::Myhandler
> > > > > > >
> > > > > > >
> > > > > > > And in srm2.conf I have
> > > > > > >
> > > > > > > PerlSetVar MyVariable2 MyValue2
> > > > > > > PerlAuthenHandlerApache::Myhandler
> > > > > > >
> > > > > > > In Myhandler::handler I do
> > > > > > > $myvar1 = $r->dir_config('MyVariable');
> > > > > > > $myvar2 = $r->dir_config('MyVariable2);
> > > > > > >
> > > > > > > if($myvar1){
> > > > > > > ## do stuff for first virtual server
> > > > > > > }else{
> > > > > > > ## do stuff for the second one
> > > > > > > }
> > > > > > >
> > > > > > > But $myvar1 appears to be ALWAYS set. Which leads me to belief that
> > > > > > > mod_perl "shares" variables between virtual servers if those variables
> > > > > > > are not explicitly set in configuration for that server.
> > > > > > >
> > > > > > > Is this supposed to be this way? Or am I missing something?
> > > > > > >
> > > > > > > Andrei
> > > >
> > > > --
> > > > Eric
> > >
> > > --
> >
>
> --
--
Re: embperl-intermittant sig11 seg faults
I get those too even without embperl. The same symptoms. Everything is fine untill child is terminated. Then "child pid x exit signal Segmentation fault (11)" appears in error log. I was said that this disappears after upgrade to perl 5.005_3. Couldn't try it because can't upgrade. But looks like you have the same problem even with that version of perl. Andrei PS. My configuration is Apache 1.3.9, mod_perl 1.21, perl 5.004_4. On Wed, Nov 17, 1999 at 02:17:39PM -0800, Cliff Rayman wrote: > I am getting losts of SIGV 11 VIOLATIONS. I have been > pulling my hair out for several weeks. It does not happen on startup > seems to happen only after a child has been running a while. > > I have reved up to latest and greatest. Rebuilt perl and everything > else from clean sources. when I test it myself - everything runs > great. > > any help greatly appreciated. > > cliff rayman > genwax.com > > === > here is my config - > > Server: Apache/1.3.9 (Unix) mod_perl/1.21 mod_ssl/2.4.8 OpenSSL/0.9.4 > Embperl 1.2b11 > > Linux www.genwax.com 2.0.36 #1 Mon Dec 7 03:44:15 PST 1998 i686 unknown > > Summary of my perl5 (5.0 patchlevel 5 subversion 2) configuration: > Platform: > osname=linux, osvers=2.0.36, archname=i686-linux > uname='linux www.genwax.com 2.0.36 #1 mon dec 7 03:44:15 pst 1998 > i686 unknown ' > hint=previous, useposix=true, d_sigaction=define > usethreads=undef useperlio=undef d_sfio=undef > Compiler: > cc='cc', optimize='-O2', gccversion=2.7.2.3 > cppflags='-Dbool=char -DHAS_BOOL' > ccflags ='-Dbool=char -DHAS_BOOL' > stdchar='char', d_stdstdio=define, usevfork=false > intsize=4, longsize=4, ptrsize=4, doublesize=8 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 > alignbytes=4, usemymalloc=n, prototype=define > Linker and Libraries: > ld='cc', ldflags =' -L/usr/local/lib' > libpth=/usr/local/lib /lib /usr/lib > libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt > libc=, so=so, useshrplib=false, libperl=libperl.a > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' > > cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' > > > Characteristics of this binary (from libperl): > Built under linux > Compiled at Nov 16 1999 11:24:18 > @INC: > /usr/lib/perl5/5.00502/i686-linux > /usr/lib/perl5/5.00502 > /usr/lib/perl5/site_perl/5.005/i686-linux > /usr/lib/perl5/site_perl/5.005 > . > > > below is my backtrace > > > > #0 0x80be37c in ap_palloc () > #1 0x80be46d in ap_pstrdup () > #2 0x80bedcd in ap_table_set () > #3 0x80b5108 in XS_Apache_header_out () > #4 0x81964e2 in Perl_pp_entersub () > #5 0x81bff92 in Perl_runops_standard () > #6 0x8167765 in perl_call_sv () > #7 0x4013d7f5 in CallCV () > #8 0x4013df3f in EMBPERL_EvalTransFlags () > #9 0x4013df6b in EMBPERL_EvalTrans () > #10 0x4013588f in ScanCmdEvals () > #11 0x4013851c in EMBPERL_ProcessBlock () > #12 0x40138783 in EMBPERL_ProcessSub () > #13 0x401308f1 in XS_HTML__Embperl_ProcessSub () > #14 0x81964e2 in Perl_pp_entersub () > #15 0x81bff92 in Perl_runops_standard () > #16 0x8167765 in perl_call_sv () > #17 0x4013d7f5 in CallCV () > #18 0x4013df3f in EMBPERL_EvalTransFlags () > #19 0x4013df6b in EMBPERL_EvalTrans () > #20 0x4013588f in ScanCmdEvals () > #21 0x4013851c in EMBPERL_ProcessBlock () > #22 0x40138783 in EMBPERL_ProcessSub () > #23 0x401308f1 in XS_HTML__Embperl_ProcessSub () > #24 0x81964e2 in Perl_pp_entersub () > #25 0x81bff92 in Perl_runops_standard () > #26 0x8167765 in perl_call_sv () > #27 0x4013d7f5 in CallCV () > #28 0x4013df3f in EMBPERL_EvalTransFlags () > #29 0x4013df6b in EMBPERL_EvalTrans () > #30 0x4013588f in ScanCmdEvals () > #31 0x4013851c in EMBPERL_ProcessBlock () > #32 0x4013e51c in EMBPERL_EvalMain () > #33 0x40138261 in ProcessFile () > #34 0x40138940 in EMBPERL_ExecuteReq () > #35 0x401323b5 in XS_HTML__Embperl__Req_ExecuteReq () > #36 0x81964e2 in Perl_pp_entersub () > #37 0x81bff92 in Perl_runops_standard () > #38 0x8167765 in perl_call_sv () > #39 0x80abb2e in perl_call_handler () > #40 0x80ab539 in perl_run_stacked_handlers () > #41 0x80aa471 in perl_handler () > #42 0x80c2bbb in ap_invoke_handler () > #43 0x80d60d9 in ap_some_auth_required () > #44 0x80d6138 in ap_process_request () > #45 0x80cd901 in ap_child_terminate () > #46 0x80cdb50 in ap_child_terminate () > #47 0x80cdeaa in ap_child_terminate () > #48 0x80ce3b1 in ap_child_terminate () > #49 0x80cea53 in main () > --
Re: Attempt to free unreferenced scalar during global destruction.
Hi! I've searched thru archives and came up with the following conclusion. Please correct me if I'm wrong. There was some patch related to the problem that made it to mod_perl 1.21 but seems like that patch fixes something else and not the problem. To really fix the problem I need to upgrade from perl 5.004_04 to 5.005_03. Am I correct? Thank you. Andrei On Thu, Nov 04, 1999 at 03:55:20PM -0500, Andrei A. Voropaev wrote: > Hi! > > For some reason I get lots of > > 'Attempt to free unreferenced scalar during global destruction.' > > in my error log. Any one can give me a pointer where to search for the > problem? > > Thank you > > Andrei > -- --
Attempt to free unreferenced scalar during global destruction.
Hi! For some reason I get lots of 'Attempt to free unreferenced scalar during global destruction.' in my error log. Any one can give me a pointer where to search for the problem? Thank you Andrei --
