Re: Question on possible effects of mod_perl on mod_cgi
That was it. I redefined Sig{__WARN__} to drop all STDERR output and my
script output everything it was supposed to and exited cleanly. Now
there is another bug that undoubtedly came from my trying to track down
the original issue...
Thanks. That saved me a ton of time.
Tom
Terra Info wrote:
Ugh! I checked the users list archives but I never checked the dev
archives. I liked p5p back in the day because it was all one in the
same. Chaos, but oddly efficient. Thanks for the pointer.
As for the docs, I freely admit I missed it. I was not looking for
PerlRun stuff when I went through that migration piece (I was looking
for a different project) so when I started dealing with this I did not
remember seeing it, therefore in my warped mind it did not exist.
Right now, int/0 looks perfectly fine to me. Anyhow, I doubt listing
all of them would help, just add in Apache::PerlRun into the header so
it reads "The Apache::Registry and Apache::PerlRun Families" (or ~)
and that would get people's attention a little bit better.
Thanks,
Tom
Stas Bekman wrote:
OK, now it's clear, thanks for the explanation. FWIW, there were
discussions of possible pipes read/write deadlocks in the current
mod_cgi implementation in Apache 2.0, so you may experience just
that. Check the httpd-dev list archives.
[...]
* Given that, I noticed PerlRun was no longer prominintly displayed
in the docs
What made you think so? The PerlRun docs weren't touched for ages.
and the migration FAQ did not to my knowledge even touch on it.
Because all you have to do is to s/Apache::/ModPerl::/ for all
registry handlers, which includes PerlRun. Do you think that it'll
help to explicitly list them all?
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
-
Terra Novum Research
[EMAIL PROTECTED]
www.terranovum.com
(617) 923-4132
PO Box 362
Watertown, MA 02471-0362
They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.
Benjamin Franklin,
Historical Review of Pennsylvania, 1759
Re: perl's system() w/ apache under win2k
Doh! I avoid doing system calls to external apps like the plague so I forget things like that. Thanks for catching it, Tom Stas Bekman wrote: Terra Info wrote: [...] > application. If you would like to take output from that application then > you should write to STDOUT all text you want the perl application to see > as a return value from your system() call or `` (backticks) call. you probably meant qx(), as system doesn't return the sub-process' STDOUT, but only the exec status. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- - Terra Novum Research [EMAIL PROTECTED] www.terranovum.com (617) 923-4132 PO Box 362 Watertown, MA 02471-0362 Nothing's so loud, as hearing when we lie; the truth is not kind, and you've said neither am I. - Glenn Philips
Re: Question on possible effects of mod_perl on mod_cgi
Ugh! I checked the users list archives but I never checked the dev archives. I liked p5p back in the day because it was all one in the same. Chaos, but oddly efficient. Thanks for the pointer. As for the docs, I freely admit I missed it. I was not looking for PerlRun stuff when I went through that migration piece (I was looking for a different project) so when I started dealing with this I did not remember seeing it, therefore in my warped mind it did not exist. Right now, int/0 looks perfectly fine to me. Anyhow, I doubt listing all of them would help, just add in Apache::PerlRun into the header so it reads "The Apache::Registry and Apache::PerlRun Families" (or ~) and that would get people's attention a little bit better. Thanks, Tom Stas Bekman wrote: OK, now it's clear, thanks for the explanation. FWIW, there were discussions of possible pipes read/write deadlocks in the current mod_cgi implementation in Apache 2.0, so you may experience just that. Check the httpd-dev list archives. [...] * Given that, I noticed PerlRun was no longer prominintly displayed in the docs What made you think so? The PerlRun docs weren't touched for ages. and the migration FAQ did not to my knowledge even touch on it. Because all you have to do is to s/Apache::/ModPerl::/ for all registry handlers, which includes PerlRun. Do you think that it'll help to explicitly list them all? __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- - Terra Novum Research [EMAIL PROTECTED] www.terranovum.com (617) 923-4132 PO Box 362 Watertown, MA 02471-0362 "The wireless telegraph is not difficult to understand. The ordinary telegraph is like a very long cat. You pull the tail in New York, and it meows in Los Angeles. The wireless is the same, only without the cat." -- Einstein
Re: perl's system() w/ apache under win2k
Here is that doc addition: Why can't my scripts execute external programs with GUI frontends from within Apache/mod_perl when I could under Win9.x? The issue is not an Apache/mod_perl issue per se. Any service that allows execution of external binaries that try to initialize and display GUI components will have problems under OSs like Windows 2K+, Unix, Linux and MacOS X. This would have worked in Win 98 because apps all run in the same user space (under the same user ID). Those resources happened to be, for the most part, linked to almost everything else running on the system. Hence when you ran a gui app from within Apache the system would display the gui part of it on the screen. The OS saw no difference between the web server running in the background and the user's desktop. The best way to deal with this is to see if the application you are trying to run has a /quiet switch or something that will keep it from trying to draw any GUI components/dialog boxes to the screen. If you wrote the application you are trying to execute then you should put a hook into it that will allow that option (obviously adding the code to bypass the gui code) and then execute it with the new option. The best way to execute programs under Perl's system call is to write a console application. If you would like to take output from that application then you should write to STDOUT all text you want the perl application to see as a return value from your system() call or `` (backticks) call. Tom Stas Bekman wrote: Terra Info wrote: I will write up a more publically palatable version of the below and post it for someone more intimately associated with the docs and development to merge into the tree. Great, thank you! Keep in mind that this is an issue not just for MP but also any CGI script or frankly any service that allows execution of external binaries that try to initialize and display GUI components. Although I have not tested it, I would imagine that this would be an issue on a Unix/linix variant as well as the design of the OS is similar to WinNT and up. Or the other way around if you want to follow the timeline correctly ;-}. I believe that Unix users are aware of this issue from the very first steps of using the system and therefore we hardly ever see this kind of questions on this list. Apparently permissions on winNT is something unexpected and new for those who are used to older win32 systems. Moreover, error_log usually tells what the exact problem is when the code is written properly to report errors (e.g., checking the return status of system()). My guess is that this should work on winNT too. If there are similar issues with MacOS X or other platforms, please send the info in, so we will add it to the docs. Though my guess is that MacOS X is based on FreeBSD and therefore all the normal Unix perms concepts apply as is. Correct me if I'm wrong. __ Stas Bekman JAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- - Terra Novum Research [EMAIL PROTECTED] www.terranovum.com (617) 923-4132 PO Box 362 Watertown, MA 02471-0362 "The wireless telegraph is not difficult to understand. The ordinary telegraph is like a very long cat. You pull the tail in New York, and it meows in Los Angeles. The wireless is the same, only without the cat." -- Einstein
Re: Question on possible effects of mod_perl on mod_cgi
Stas Bekman wrote: I still don't understand you. When do you see the problem? When you run the script under mod_cgi or mod_perl? I don't understand why do you keep referring to mod_cgi. And we are talking about Apache/mod_perl 2.0 here, right? No. I am talking about mod_cgi when I say mod_cgi. In short you answered my questions with answers I pretty much expected but I wanted my asumptions valiidated. For that I am grateful. Long answer: Let me state why I was looking (ie; the [il]logic to my thinking) to eliminate mod_perl from the list of of possible reasons why a standard CGI would be failing. * It was a perl CGI. * It was failing in ways that were similar, although not directly alike, ways that poorly written perl apps under mod_perl fail. For example, it would hangup, it would bahave oddly like there were variables set that should have been cleared (ie; unscoped globals). * It was a perl CGI. Hence I know that because of the excellent integration of perl into apache (perl in conf files, etc) as a result of mod_perl, I was looking to see if anyone here on mod_perl's list knew of any interactions, etc that could have spilled over into mod_cgi's handling of perl scripts for instance. * Given that, I noticed PerlRun was no longer prominintly displayed in the docs and the migration FAQ did not to my knowledge even touch on it. I was thiking maybe it had become an automatic thing in mod_cgi for mod_perl enabled httpds to try to speed up perl CGI's by using an in-process perl interpretor instead of backticking it. If that was happening I figured someone here would probably know about it. I posted questions to apache's list but it has been slow going getting people knowledgable about mod_cgi to answer. * There was more (il)logic but I think that should be enough to fill in the holes. Thanks, Tom -- - Terra Novum Research [EMAIL PROTECTED] www.terranovum.com (617) 923-4132 PO Box 362 Watertown, MA 02471-0362 "The wireless telegraph is not difficult to understand. The ordinary telegraph is like a very long cat. You pull the tail in New York, and it meows in Los Angeles. The wireless is the same, only without the cat." -- Einstein
Re: perl's system() w/ apache under win2k
I will write up a more publically palatable version of the below and post it for someone more intimately associated with the docs and development to merge into the tree. Keep in mind that this is an issue not just for MP but also any CGI script or frankly any service that allows execution of external binaries that try to initialize and display GUI components. Although I have not tested it, I would imagine that this would be an issue on a Unix/linix variant as well as the design of the OS is similar to WinNT and up. Or the other way around if you want to follow the timeline correctly ;-}. Tom Stas Bekman wrote: Terra Info wrote: Two things: 1) this is not the list for this question. 2) a probable answer anyhow-> If that's a real pitfall and it's doomed to be a recurrent question, can we please document this under win32/? Also, Randy, it seems that there is whole lot of win32 issues which apply to all mod_perl versions (per our faq discussion), so rather than duplicating them in docs/1.0/os/win32 and docs/2.0/os/win32, we should probably have an area for general win32 issues, e.g. docs/general/os/win32 and point to it from both 1.0 and 2.0. The issue is not file permissions (per se) or anything like that. It is the way WinNT and up is built. What you were doing in Win 98 worked because apps all ran in the same user space. Despite logging into a 98 machine you were really executing all programs as the default user and inside that users memory space. That happened to be, for the most part, shared by almost everything else running on the system. Hence when you ran a gui app from within apache the system would display the gui part of it on the screen. Instead of going into how WinNT and up is designed (go over to mikeysoft's site and you may see something there or maybe a MCSE book on Win2K will have the design philosophy in it) let's just skip to the possible fix. Check to see if the user you run apache under is allowed to "interact with the desktop". It should be in the services CPL applet under the entry for that service. Check that and restart the service. This may allow your app to run but I doubt it. Also, keep in mind this is not secure at all and your best bet is to see if the app you are running has a /quiet switch or something that will keep it from trying to paint any dialog boxes. If you wrote that app then you should put a hook into it that will allow that option (obviously adding the code to bypass init'n the gui code) and then execute it with that option. Tom Philip Fibiger wrote: Hello all, I've got a pretty simple perl script that used to run on a windows 98 machine running apache just fine. It would use system() to launch a windows app that has a graphical display to sync a ms-sql database to a mysql one. Anyway, it's been replaced by a new machine running win2k, and I'm having some problems. When I attempt to use system() to execute the program under win2k, the program appears to start (it shows up in the task list) but it never gets past that point. The same thing happens with any program that has a gui. I checked permissions, and I can log in w/ the same account apache uses, and I can execute the program just fine. Is there some permissions issue, or some alternate way of launching the program via perl that i'm not seeing? Thanks! Philip -- - Terra Novum Research [EMAIL PROTECTED] www.terranovum.com (617) 923-4132 PO Box 362 Watertown, MA 02471-0362 In time-keeping, in trading, in fighting, men counted numbers; and finally, as the habit grew, only numbers counted. Lewis Mumford
Re: Question on possible effects of mod_perl on mod_cgi
The threads issue is my bag. I know better but was busy and distracted,
hence I just did a reply to all and trimmed out the excess. Anyhow, I
think you may have misunderstood my question. Although I have a specific
issue at hand, my question was more generic. My questions are more
related to the overall design of mod_perl and its effects on the
functioning of Apache's other components. Anyhow, in answer to your
question, I have not tried it under mod_perl 1 or 2 because this script
would never function under them. It is that poorly written.
So, is there any link between mod_perl (1.99..) and mod_cgi (Apache 2)?
Does mod_perl in anyway influence or maybe cause PerlRun like caching
under mod_cgi? I realize the answers are probably no but I am at my wits
end with this bug and am trying to elminate things as causes that
normally I would not even think were related.
So you have a better handle on why I am asking, I have a script that
runs fine from the cmd line under all parameter combinations, runs fine
in most situations under CGI but when a few param combinations occur it
fails to execute to completion. The odd thing is the place it hangs up
is the line before exit;. I added a warn('foo at line nnn') after every
line and it warns all they way to the line for exit; but never exists
and apache tells me that the script times out. That combined with the
fact that the script, when executed on the command line, under a faked
up ENV that matches exactly what it gets from httpd runs flawlessly and
to completion, seems to suggest something is happening in the in-process
handling of the CGI script. Does that problem lie in mod_cgi, perl or in
some funky interaction between components? With some of the symptoms I
saw I wanted to rule out mod_perl before I went any further.
Thanks and I hope this made it more clear what I was looking for and why,
Tom
Stas Bekman wrote:
[When starting a new thread, please remember to create a new mail,
rather than doing a reply to one of the threads. If you don't do that,
your mail software attaches reference ids to the original thread and
your post gets folded into the thread you've replied to. people may
delete the whole thread without seeing your post if they weren't
interested in this thread. it also has an ill effect on mail archives.]
Terra Info wrote:
I am debugging a particularly nasty issue right now on a perl script
that when written 2+ yrs ago worked fine. NB: It does not run under
mod_perl and it has not been modified since then.
You mean, it has never worked under mod_perl 1.0? Can you test it with
mod_perl 1.0?
I run it from the cmd line (with the identical query string and all
referenced %ENV vars set identical as well) and it runs fine. I run
it as a typical CGI and it has problems that, in *some* ways, mirror
the behavior of a poorly written (symptoms associated with unscoped
globals, etc;) perl app under mod_perl. And since this is a poorly
written app I am curious. Is there any link between mod_perl (1.99..)
and mod_cgi (Apache 2)? Does mod_perl in anyway influence or maybe
cause PerlRun like caching under mod_cgi? I am just trying to
eliminate all possibilities as this one has been a real PITFA.
You can turn the debugging on and see whether it gets cached.
in ModPerl::RegistryCooker set:
use constant DEBUG => 4;
restart the server and watch error_log, compare the output of Registry
with PerlRun.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
-
Terra Novum Research
[EMAIL PROTECTED]
www.terranovum.com
(617) 923-4132
PO Box 362
Watertown, MA 02471-0362
In time-keeping, in trading, in fighting, men counted numbers;
and finally, as the habit grew, only numbers counted.
Lewis Mumford
Question on possible effects of mod_perl on mod_cgi
I am debugging a particularly nasty issue right now on a perl script that when written 2+ yrs ago worked fine. NB: It does not run under mod_perl and it has not been modified since then. I run it from the cmd line (with the identical query string and all referenced %ENV vars set identical as well) and it runs fine. I run it as a typical CGI and it has problems that, in *some* ways, mirror the behavior of a poorly written (symptoms associated with unscoped globals, etc;) perl app under mod_perl. And since this is a poorly written app I am curious. Is there any link between mod_perl (1.99..) and mod_cgi (Apache 2)? Does mod_perl in anyway influence or maybe cause PerlRun like caching under mod_cgi? I am just trying to eliminate all possibilities as this one has been a real PITFA. Thanks, Tom
Re: perl's system() w/ apache under win2k
Two things: 1) this is not the list for this question. 2) a probable answer anyhow-> The issue is not file permissions (per se) or anything like that. It is the way WinNT and up is built. What you were doing in Win 98 worked because apps all ran in the same user space. Despite logging into a 98 machine you were really executing all programs as the default user and inside that users memory space. That happened to be, for the most part, shared by almost everything else running on the system. Hence when you ran a gui app from within apache the system would display the gui part of it on the screen. Instead of going into how WinNT and up is designed (go over to mikeysoft's site and you may see something there or maybe a MCSE book on Win2K will have the design philosophy in it) let's just skip to the possible fix. Check to see if the user you run apache under is allowed to "interact with the desktop". It should be in the services CPL applet under the entry for that service. Check that and restart the service. This may allow your app to run but I doubt it. Also, keep in mind this is not secure at all and your best bet is to see if the app you are running has a /quiet switch or something that will keep it from trying to paint any dialog boxes. If you wrote that app then you should put a hook into it that will allow that option (obviously adding the code to bypass init'n the gui code) and then execute it with that option. Tom Philip Fibiger wrote: Hello all, I've got a pretty simple perl script that used to run on a windows 98 machine running apache just fine. It would use system() to launch a windows app that has a graphical display to sync a ms-sql database to a mysql one. Anyway, it's been replaced by a new machine running win2k, and I'm having some problems. When I attempt to use system() to execute the program under win2k, the program appears to start (it shows up in the task list) but it never gets past that point. The same thing happens with any program that has a gui. I checked permissions, and I can log in w/ the same account apache uses, and I can execute the program just fine. Is there some permissions issue, or some alternate way of launching the program via perl that i'm not seeing? Thanks! Philip -- - Terra Novum Research [EMAIL PROTECTED] www.terranovum.com (617) 923-4132 PO Box 362 Watertown, MA 02471-0362 Nothing's so cold as closing the heart when all we need is to free the soul, but we wouldn't be that brave I know. - Glenn Philips
Re: sesion managing
See http://search.cpan.org/author/SHERZODR/CGI-Session-3.11/ It is info on the Perl Module CGI::Session. Tom Mrs. Brisby wrote: There are many solutions to your problem that are perl specific and some minor twists that are mod_perl specific. You may have better luck using a perl-oriented mailing list for this topic, or read up on how HTTP works and all the various places that you can store session information (query string, path information, the hostname, cookies, etc), and decide how much data you need to save and where you need to save it. If you then decide that the _best_ place to do this requires mod_perl (btw: none of the places I just suggested technically require it) then come back and we can tell you how to accomplish that. On Mon, 2002-12-30 at 04:46, koudjo ametepe wrote: hi everbody , How do you do I developping an intranet project with perl and Mysql . I encounter a problem and still i haven't found a solution .The problem is previously i was using php/mysql ; with the function sesssion_xxx i was able to keep user id through all the pages and store it any time that the user save something in the database . Umfortunately i don't know how to do this with perl , i read some articles on the net about it but i get nothing. Please can you give me some ideas about the session managing in perl/mysql thanks koudjo -- - Terra Novum Research [EMAIL PROTECTED] www.terranovum.com (617) 923-4132 PO Box 362 Watertown, MA 02471-0362 Nothing's so cold as closing the heart when all we need is to free the soul, but we wouldn't be that brave I know. - Glenn Philips
Re: mod_perl 2 and problems w/ ErrorDocument Directive
Sounds good. Thanks for the help. I will patch my copy. Will all MP1 functionality be migrating over to MP2? In particular the PerlHandler Apache::Status functionality. Thanks, Tom Stas Bekman wrote: Terra Info wrote: PS: I forgot to let you know if it works on MP1. I do not have that installed on any machines so if someone out there on the list could check that out and post back I would appreciate it. Everything you need is below. Here is the fix, I've messed up this part while porting. I'll commit that fix soonish + a new test. Index: lib/ModPerl/RegistryCooker.pm === RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v retrieving revision 1.23 diff -u -r1.23 RegistryCooker.pm --- lib/ModPerl/RegistryCooker.pm 16 Aug 2002 09:01:17 - 1.23 +++ lib/ModPerl/RegistryCooker.pm 24 Dec 2002 01:44:52 - @@ -157,7 +157,8 @@ # handlers shouldn't set $r->status but return it my $old_status = $self->[REQ]->status; my $rc = $self->run; -my $new_status = $self->[REQ]->status($old_status); +my $new_status = $self->[STATUS]; +$self->[REQ]->status($old_status); return ($rc != Apache::OK) ? $rc : $new_status; } __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- - Terra Novum Research [EMAIL PROTECTED] www.terranovum.com (617) 923-4132 PO Box 362 Watertown, MA 02471-0362 Patriotism means being loyal to your country all the time and to its government when it deserves it. - Mark Twain
Re: mod_perl 2 and problems w/ ErrorDocument Directive
PS: I forgot to let you know if it works on MP1. I do not have that
installed on any machines so if someone out there on the list could
check that out and post back I would appreciate it. Everything you need
is below.
Tom
Terra Info wrote:
Thanks for the help. Below is all the info you requested. I have also
attached the test script (code below for those attachement challenged,
et al;) and an example can be seen at
http://dev.terranovum.com/some-bad-link/. To see what it should be
doing call it directly at
http://dev.terranovum.com/cgi-bin/mod_perl_list.pl. Both links are the
same script under the same mod_perl directives. The only difference is
how they are being called. If you need anything else let me know.
Tom
Relevant httpd.conf entries:
ErrorDocument 404 /cgi-bin/mod_perl_list.pl
SetHandler perl-script
PerlHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
Only Log Entry:
[Sat Dec 21 17:35:46 2002] [error] [client 146.115.56.67] File does
not exist: /var/www/terradev/docs/bad-link
Output:
[snip]Additionally, a 404 Not Found error was encountered while trying
to use an ErrorDocument to handle the request.[snip]
[root@nova t]# ./TEST.PL
*** setting ulimit to allow core files
ulimit -c unlimited; ./TEST.PL
/usr/sbin/httpd -d
/root/downloads/mod_perl-1.99_07/ModPerl-Registry/t -f
/root/downloads/mod_perl-1.99_07/ModPerl-Registry/t/conf/httpd.conf
-DAPACHE2 -DPERL_USEITHREADS
using Apache/2.0.40 (prefork MPM)
waiting for server to start: ...
waiting for server to start: ok (waited 2 secs)
server localhost.localdomain:8529 started
basic.ok
closure...ok
redirect..ok
special_blocksok
All tests successful.
Files=4, Tests=30, 5 wallclock secs ( 1.91 cusr + 0.18 csys = 2.09
CPU)
*** server localhost.localdomain:8529 shutdown
#!/usr/bin/perl -Tw
$ENV{'PATH'} = '';
use strict;
my $retstr = "Content-Type: text/html\n";
#$retstr .= sprintf("Status: %s %s\n", $status, $codes{$status}[0]);
$retstr .= sprintf("Status: %s %s\n", 404, 'Object Not Found!');
$retstr .= "\n";
$retstr .= 'Error 404: Object Not
Found!Error 404: Object Not
Found!Blah, blah, blah...';
print($retstr);
exit;
Stas Bekman wrote:
Terra Info wrote:
I have a script that provides custom error messages that I set up
using the ErrorDocument directive (ie; ErrorDocument 400
/cgi-global/error.pl?error=400&useXML=1). When run under typical
mod_cgi all works as planned and it outputs the proper stuff. When
run under mod_perl it outputs the same but then appends the default
ErrorDocument (ie; ErrorDocument 500
/error/HTTP_INTERNAL_SERVER_ERROR.html.var) output on the end so I
have effectively two HTML docs on the output page.
The odd part of this issue is this. When it is a 404 error The stock
error doc says that "Additionally, a 404 Not Found error was
encountered while trying to use an ErrorDocument to handle the
request" which makes no sense since the only log entry is "File does
not exist: /var/www/terradev/docs/bad-link". When you use the 500.pl
example below you get "Additionally, a 500 Internal Server Error
error was encountered while trying to use an ErrorDocument to handle
the request." despite the fact that the custom error script did work
and output what it was supposed to and the error logs confirm that.
Looks like ModPerl::Registry is not handling correctly the return
status , hence you get the run of the default handler as well. I'll
look into it. But first, does it work properly with mod_perl 1.0?
Finally please attach the script that fails, preferrably removing all
but the very minimal code that allows to reproduce the problem. Thanks.
And if you can a test to modperl-2.0/ModPerl-Registry/t that
reproduces the problem, that would be even better. If you don't know
Apache::Test, you can learn more about it at:
http://perl.apache.org/docs/general/testing/testing.html
and looking at the existing tests. To run the registry tests you need
to cd to the ModPerl-Registry dir first and run 'make test'. If it
seems like too much work, I'll take care of adding the test. But it'd
be cool if people who encounter problems were able to submit tests
with their reports.
Thanks.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
#!/usr/bin/perl -Tw
# Relevant httpd.conf entries:
# ErrorDocument 404 /cgi-bin/mod_perl_list.pl
#
#SetHandler perl-script
#PerlHandle
Re: mod_perl 2 and problems w/ ErrorDocument Directive
Thanks for the help. Below is all the info you requested. I have also
attached the test script (code below for those attachement challenged,
et al;) and an example can be seen at
http://dev.terranovum.com/some-bad-link/. To see what it should be doing
call it directly at http://dev.terranovum.com/cgi-bin/mod_perl_list.pl.
Both links are the same script under the same mod_perl directives. The
only difference is how they are being called. If you need anything else
let me know.
Tom
Relevant httpd.conf entries:
ErrorDocument 404 /cgi-bin/mod_perl_list.pl
SetHandler perl-script
PerlHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
Only Log Entry:
[Sat Dec 21 17:35:46 2002] [error] [client 146.115.56.67] File does not
exist: /var/www/terradev/docs/bad-link
Output:
[snip]Additionally, a 404 Not Found error was encountered while trying
to use an ErrorDocument to handle the request.[snip]
[root@nova t]# ./TEST.PL
*** setting ulimit to allow core files
ulimit -c unlimited; ./TEST.PL
/usr/sbin/httpd -d /root/downloads/mod_perl-1.99_07/ModPerl-Registry/t
-f /root/downloads/mod_perl-1.99_07/ModPerl-Registry/t/conf/httpd.conf
-DAPACHE2 -DPERL_USEITHREADS
using Apache/2.0.40 (prefork MPM)
waiting for server to start: ...
waiting for server to start: ok (waited 2 secs)
server localhost.localdomain:8529 started
basic.ok
closure...ok
redirect..ok
special_blocksok
All tests successful.
Files=4, Tests=30, 5 wallclock secs ( 1.91 cusr + 0.18 csys = 2.09 CPU)
*** server localhost.localdomain:8529 shutdown
#!/usr/bin/perl -Tw
$ENV{'PATH'} = '';
use strict;
my $retstr = "Content-Type: text/html\n";
#$retstr .= sprintf("Status: %s %s\n", $status, $codes{$status}[0]);
$retstr .= sprintf("Status: %s %s\n", 404, 'Object Not Found!');
$retstr .= "\n";
$retstr .= 'Error 404: Object Not
Found!Error 404: Object Not
Found!Blah, blah, blah...';
print($retstr);
exit;
Stas Bekman wrote:
Terra Info wrote:
I have a script that provides custom error messages that I set up
using the ErrorDocument directive (ie; ErrorDocument 400
/cgi-global/error.pl?error=400&useXML=1). When run under typical
mod_cgi all works as planned and it outputs the proper stuff. When
run under mod_perl it outputs the same but then appends the default
ErrorDocument (ie; ErrorDocument 500
/error/HTTP_INTERNAL_SERVER_ERROR.html.var) output on the end so I
have effectively two HTML docs on the output page.
The odd part of this issue is this. When it is a 404 error The stock
error doc says that "Additionally, a 404 Not Found error was
encountered while trying to use an ErrorDocument to handle the
request" which makes no sense since the only log entry is "File does
not exist: /var/www/terradev/docs/bad-link". When you use the 500.pl
example below you get "Additionally, a 500 Internal Server Error
error was encountered while trying to use an ErrorDocument to handle
the request." despite the fact that the custom error script did work
and output what it was supposed to and the error logs confirm that.
Looks like ModPerl::Registry is not handling correctly the return
status , hence you get the run of the default handler as well. I'll
look into it. But first, does it work properly with mod_perl 1.0?
Finally please attach the script that fails, preferrably removing all
but the very minimal code that allows to reproduce the problem. Thanks.
And if you can a test to modperl-2.0/ModPerl-Registry/t that
reproduces the problem, that would be even better. If you don't know
Apache::Test, you can learn more about it at:
http://perl.apache.org/docs/general/testing/testing.html
and looking at the existing tests. To run the registry tests you need
to cd to the ModPerl-Registry dir first and run 'make test'. If it
seems like too much work, I'll take care of adding the test. But it'd
be cool if people who encounter problems were able to submit tests
with their reports.
Thanks.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
-
Terra Novum Research
[EMAIL PROTECTED]
www.terranovum.com
(617) 923-4132
PO Box 362
Watertown, MA 02471-0362
"When a man sits with a pretty girl for an hour,
it seems like a minute. But let him sit on a hot stove
for a minute and it's longer than any hour. That's relativity."
-- Einstein, Journal of Exothermic Science and Technology (JEST, Vol. 1, No. 9; 1938)
#!/usr/bin/perl -Tw
# Relevant httpd.c
mod_perl 2 and problems w/ ErrorDocument Directive
I have a script that provides custom error messages that I set up using the ErrorDocument directive (ie; ErrorDocument 400 /cgi-global/error.pl?error=400&useXML=1). When run under typical mod_cgi all works as planned and it outputs the proper stuff. When run under mod_perl it outputs the same but then appends the default ErrorDocument (ie; ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var) output on the end so I have effectively two HTML docs on the output page. The odd part of this issue is this. When it is a 404 error The stock error doc says that "Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request" which makes no sense since the only log entry is "File does not exist: /var/www/terradev/docs/bad-link". When you use the 500.pl example below you get "Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request." despite the fact that the custom error script did work and output what it was supposed to and the error logs confirm that. The setup is plain vanilla on RH 8 and httpd2. The latest patch level of everything RH8 basically. The config of the cgi-global is: SetHandler perl-script PerlHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI Output of perl -V and httpd -V are below and not that this is a vhost using named vhosts via the directive "NameVirtualHost *". If you need anything else let me know since I do not have the script on my system you set up for posting bug reports. (RH did not include it) Examples can be seen at http://dev.terranovum.com/cgi-global/500.pl or http://dev.terranovum.com/bad-link Thomas Bolioli PS: Any idea if there will be a replacement for Apache::Status? #httpd -V Server version: Apache/2.0.40 Server built: Oct 9 2002 08:01:13 Server's Module Magic Number: 20020628:0 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/etc/httpd" -D SUEXEC_BIN="/usr/sbin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" # perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.18-11smp, archname=i386-linux-thread-multi uname='linux daffy.perf.redhat.com 2.4.18-11smp #1 smp thu aug 15 06:41:59 edt 2002 i686 i686 i386 gnulinux ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2 -march=i386 -mcpu=i686', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/include/gdbm' ccversion='', gccversion='3.2 20020822 (Red Hat Linux Rawhide 3.2-5)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil libc=/lib/libc-2.2.92.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.2.92' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Sep 1 2002 23:56:49 @I
