informing per "Lel Bruce Peto" on current newsflash:

2003-03-28 Thread info
informing per "Lel Bruce Peto" on current newsflash:

The battle is on to put out fires at Iraqi oil wells 
Oil prices have marched higher and key share indexes have fallen, as the 
war in Iraq continues to dominate world markets. 
The North Sea's Brent oil - a benchmark for world oil prices - gained 
$1.53 to $26.82, while US-grade oil rose by nearly two dollars to $30.37.




Re: Question on possible effects of mod_perl on mod_cgi

2003-01-03 Thread Terra Info
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

2003-01-03 Thread Terra Info
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

2003-01-02 Thread Terra Info
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

2003-01-02 Thread Terra Info




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

2003-01-02 Thread Terra Info
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

2003-01-02 Thread Terra Info
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

2003-01-02 Thread Terra Info
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

2003-01-02 Thread Terra Info
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

2003-01-02 Thread Terra Info
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

2002-12-30 Thread Terra Info
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

2002-12-27 Thread Terra Info
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

2002-12-23 Thread Terra Info
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

2002-12-23 Thread Terra Info
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

2002-12-20 Thread Terra Info
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