Re: [RFC] Exceptions addition for the guide.

2000-04-09 Thread Matt Sergeant

On Sat, 8 Apr 2000, Autarch wrote:

 On Sat, 8 Apr 2000, Matt Sergeant wrote:
 
  I've written a short document on exception handling for the guide, even
  though it's not particularly mod_perl specific, Stas thinks it would be a
  good addition. Take a look at it, and let me know if there is anything you
  would change before it's added:
  
  http://modperl.sergeant.org/guide/exceptions.html
 
 This is a good tutorial.  You might want to take a look at some exception
 code I wrote (ftp://ftp.urth.org/pub/, grab the Exception and StackTrace
 tar balls) that lets you declare all your exception types via 'use'
 statements.  I think its a bit cleaner than the AUTOLOAD method you
 propose as it can catch typos later on.  Plus it lets you create actual
 class hierarchies for your exceptions, which could be nice if you want to
 create exception classes that do more stuff and then inherit from them.

Right, the intention isn't to provide the perfect exceptions system, but
to give enough of a grounding in 5.005+ exception handling to build
on. I'll add a bunch of URL's (for Error, Try and Exception modules) to a
SEE ALSO section at the end.

-- 
Matt/

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org




Apache::ASP Install - Need help

2000-04-09 Thread Wimpy

Hello
I installed ASP for apache according to the readme.
I have a linux box with slackware 7.0 and 2.2.14
When I try to look at asp code, it give me the % and everything between
them.
What could be wrong?
Thanks
JIm




Sometimes stdout ends in the error_log!

2000-04-09 Thread René Seindal

I have a problem thats bothering me.  Sometimes one of the httpd childs
start to send normal output to the error_log, and browsers report
'document contains no data'. Normally only one child does it, and the
others respond normally, meaning that the user sees sporadic failure.

Is this a known problem?  Is it in apache or in mod_perl? I don't recall
having seen anything on the mod_perl list, and dejanews didn't turn up
anything for apache.

It seems to happen after restarts, so I have taken to the habit of
stopping the server completely and starting from scratch.  Not a good
solution, but better than serving docs to the error_log.

It is not a very busy server, so high load is not a likely source of the
problem.

I am not running the latest and greatest, but neither very old versions:

Perl version 5.00503 for Apache/1.3.11 (Unix) PHP/3.0.14 mod_perl/1.21
Statically linked mod_perl (php is a DSO).  I also use HTML::Mason 0.81
on one vhost. Server is a PC, Linux 2.2.13 from slackware 7, 128Mb ram.

-- 
René Seindal ([EMAIL PROTECTED])  http://www.seindal.dk/rene/



[newbie] diffs and cvs

2000-04-09 Thread JoshNarins

I'll probably never be applying a lot of the diffs I see
here, but I have to wonder, what are they made for?

They only thing I know is they aren't made by diff for ed.

Oh, and is there a place in the Guide for "getting the latest
release from CVS," as is often recommended to mod_ers with
troubles?

-Josh

"I thought of a really great .sig last night. That's about 
when I forgot it, too." --Josh Narins



HTML glitch on perl.apache.org

2000-04-09 Thread Dan McCormick

FYI, there's a  missing from the perl.apache.org main page at the line:

   Latest stable release is 1.22, get it from a href="dist/"this
site/a or from a
   href="http://www.cpan.org/ CPAN  -- HERE

   p

It causes the page to read 

   Latest stable release is 1.22, get it from this site or from mod_perl
programmers.

Which may cause some headscratching.

Dan



my first mod_perl works but ...

2000-04-09 Thread Peter J. Schoenster

Hello,

Nearly all my work has been on virtual servers and recently our 
hosting company (iserver) began to support mod_perl on their 
freebsd servers ... so other than one time in the past I have 
not had the opportunity to write code for mod_perl (except on 
our intranet where it has been for personal use).  As this code 
will be going out for public use I feel more responsiblity. I'm 
still in a situation of 'not knowing what I don't know'.  I 
would really, really appreciate criticisms (with suggestion for 
improvement) for the following code.  I would have used some of 
the modules that seem to do what this does but I did not 
like/understand them and, as  you can imagine, the client wants 
this to work asap.  Thanks.

#!/usr/local/bin/perl5 -w

$|++;

use strict;
use Apache::Request();
use Apache::Cookie();
use DBISUPPORT;
use SERMON_HTML;

use vars qw($r $debug);

$r = Apache-request; 
my $q= Apache::Request-new($r, POST_MAX = 25);
my $html = SERMON_HTML-new();
$debug = 0;


print_headers(1) if $debug;

my $level = '';
my $u = $q-param('u') || '';
my $p = $q-param('p') || '';

$level = verify_user() if (!$u  !$p);

if($level) {
print_headers();
print $html-graceful_snippets($level);
print qq|Level  $levelhr|;
}else {
my $user_level = db_lookup($u,$p);
if(!$user_level) {
print_headers();
print $html-graceful_snippets('generic_header');
print $html-graceful_snippets('login');
print $html-graceful_snippets('footer');
}else {
print_headers(1,$user_level);
print $html-graceful_snippets($user_level);
print qq|Level  $user_levelhr|;
}
}

##
##   BEGIN SUBS
 ##
sub print_headers {
my $send_cookie = shift || 0;
my $nivel = shift || 0;
$r-content_type("text/html"); 
if($send_cookie  $nivel  0) {
$r-headers_out-add("Set-Cookie" =qq|nivel=$nivel|); 
}
$r-send_http_header();
}
##
sub verify_user {
my %headers_in = $r-headers_in;
my $cookie = $headers_in{'Cookie'};
my(@bites) = split /;/,$cookie;
my $n = '';
my $v = '';
for(@bites) {
($n,$v) = split /=/;
$n =~ s/^\s+//;
if($n eq 'nivel') {
return $v;
}
}
return undef;
}
##
sub db_lookup {
my($username,$password) = @_;
my $dbi= DBISUPPORT-new('this_cgi'='/cgi-
bin/login.pl','database'='','username'='','password'='
'); 
my $table = 'members';
my $sql = qq|SELECT username,level,password FROM $table WHERE 
username = '$username' AND password = '$password'|;
my $dbu = '';
my $dbg = '';
my $dbp = '';
($dbu,$dbg,$dbp)= $dbi-{'db'}-selectrow_array( qq{ $sql });
$dbi-{'db'}-disconnect();
if($dbu  $dbg  $dbp) {
return $dbg;
}else {
return undef;
}

}
##

---
"Reality is that which, when you stop believing in it, doesn't go
away".
-- Philip K. Dick



Diff between Apache::Cookie and CGI::Cookie

2000-04-09 Thread Fred Xia


Can anyone tell what's the difference between Apache::Cookie
and CGI::Cookie? The eagle book has examples of using CGI::Cookie.

Thanks.

Fred Xia

__
Get Your Private, Free Email at http://www.hotmail.com




Pls discard prev msg

2000-04-09 Thread Fred Xia

Sorry for the laziness. I read the Apache::Cookie manual
after posted the question.

Fred

__
Get Your Private, Free Email at http://www.hotmail.com




Re: Sometimes stdout ends in the error_log!

2000-04-09 Thread Dan McCormick

I've encountered a similar problem, in which 'die' statements that
should never be called end up printing to the error log.  Recently I
even did

if (0) { die "whoops" }

and a "whoops" error message appeared in the error log.  Even weirder,

if (1) { print "hello" } else { die "goodbye" }

outputs both "hello" to the browser and "goodbye" to the error log.

It only seems to happen in somewhat complex pages (inside a module,
which has a bunch of hash refs) and if I try to isolate the cause by
paring things down, the problem just goes away.

My specs:
apache 1.3.12
mod_perl 1.21 static (upgrading to 1.22 now to see if it fixes anything)
Apache::ASP 0.18
perl 5.005_03
Redhat 6.1 / kernel 2.2.12

Dan

René Seindal wrote:
 
 I have a problem thats bothering me.  Sometimes one of the httpd childs
 start to send normal output to the error_log, and browsers report
 'document contains no data'. Normally only one child does it, and the
 others respond normally, meaning that the user sees sporadic failure.
 
 Is this a known problem?  Is it in apache or in mod_perl? I don't recall
 having seen anything on the mod_perl list, and dejanews didn't turn up
 anything for apache.
 
 It seems to happen after restarts, so I have taken to the habit of
 stopping the server completely and starting from scratch.  Not a good
 solution, but better than serving docs to the error_log.
 
 It is not a very busy server, so high load is not a likely source of the
 problem.
 
 I am not running the latest and greatest, but neither very old versions:
 
 Perl version 5.00503 for Apache/1.3.11 (Unix) PHP/3.0.14 mod_perl/1.21
 Statically linked mod_perl (php is a DSO).  I also use HTML::Mason 0.81
 on one vhost. Server is a PC, Linux 2.2.13 from slackware 7, 128Mb ram.
 
 --
 René Seindal ([EMAIL PROTECTED])  http://www.seindal.dk/rene/



Re: Mod_Perl install - no apxs error

2000-04-09 Thread Buddy Lee Haystack

Some cut  paste from previous messages...

For RedHat DSO specific steps in the mod_perl guide see:
http://perl.apache.org/guide/install.html#Installing_separate_Apache_and_m

No need to recompile Apache. My DSO setup works quite well!

**EDIT the "/etc/httpd/conf/httpd.conf" file

#uncomment the line below under the section
# Dynamic Shared Object (DSO) Support
LoadModule perl_modulemodules/libperl.so

#uncomment the line below under the section
# Extra Modules
AddModule mod_perl.c

#add the following line
ScriptAlias /perl/ "/home/httpd/cgi-bin/"

#uncomment the following lines
# If the perl module is installed, this will be enabled.
IfModule mod_perl.c
  Alias /perl/ /home/httpd/cgi-bin/
  Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
  /Location
/IfModule
*
I use my setup to test, so I execute both mod_perl  standard perl
scripts from the same CGI directory...
Now, anything that is accessed as 
http://mysite.com/perl/perlscript.cgi will
run as a mod_perl script, and anything accessed as 
http://mysite.com/cgi-bin/perlscript.cgi will run as a non_mod_perl
script.
Use this setup only if you want to test
scripts as both normal cgi  mod_perl scripts, otherwise you'll need
to point
the "Alias /perl/ /home/httpd/cgi-bin/" line  "ScriptAlias /perl/
"/home/httpd/cgi-bin/" line to point to another CGI directory of your
choice.

Hope this helps!



Kenneth Frankel wrote:
 
 I have tried almost every variation of installation instructions, and all
 have failed.  I can't find anything in the FAQs so please help me.
 
 Situation: Redhat 6.1 Linux 2.2.12, with pre-installed Apache
 httpd.  Removed pre-existing httpd from PATH.  Installing new Apache to
 different path.  Source versions: apache_1.3.12, mod_perl-1.22.

SNIP



[RFC] Exceptions addition to the guide

2000-04-09 Thread Matt Sergeant

This is the 2nd attempt, at Stas' request I'm pasting the whole thing
here so you can reply and/or edit.

=head1 Exception Handling for mod_perl

Provided here are some guidelines for Sclean(er) exception handling
for mod_perl usage, although the technique presented here applies to
all of your perl programming.

The reasoning behind this document is the current broken status of
C$SIG{__DIE__} in the perl core - see both the perl5-porters and
mod_perl mailing list archives for details on this discussion.

=head1 Trapping Exceptions in Perl

To trap an exception in Perl we use the Ceval{} construct. Many
people initially make the mistake that this is the same as the Ceval
EXPR construct, which compiles and executes code at run time, but
that's not the case. Ceval{} compiles at compile time, just like the
rest of your code, and has next to zero run-time penalty.

When in an eval block, if the code executing die()'s for some reason,
rather than terminating your code, the exception is Icaught and the
program is allowed to examine that exception and make decisions based
on it. The full construct looks like this:

eval 
{
# Some code here
}; # Note important semi-colon there
if ($@) # $@ contains the exception that was thrown
{
# Do something with the exception
}
else # optional
{
# No exception was thrown
}

Most of the time when you see these exception handlers there is no else
block, because it tends to be OK if the code didn't throw an exception.

=head1 Alternative Exception Handling Techniques

An often suggested method for handling global exceptions in mod_perl,
and other perl programs in general, is a B__DIE__ handler, which can
be setup by either assigning a function name as a string to
C$SIG{__DIE__} (not particularly recommended) or assigning a code-ref
to C$SIG{__DIE__}, the usual way of doing so is to use an anonymous
sub:

$SIG{__DIE__} = sub { print "Eek - we died with:\n", $_[0]; };

The current problem with this is that C$SIG{__DIE__} is a global
setting in your script, so while you can potentially hide away your
exceptions in some external module, the execution of C$SIG{__DIE__}
is fairly magical, and interferes not just with your code, but with all
code in every module you import. Beyond the magic involved,
C$SIG{__DIE__} actually interferes with perl's normal exception
handling mechanism, the Ceval{} construct. Witness:

$SIG{__DIE__} = sub { print "handler\n"; };

eval {
print "In eval\n";
die "Failed for some reason\n";
};
if ($@) {
print "Caught exception: $@";
}

The code unfortunately prints out:

In eval
handler

Which isn't quite what you would expect, especially if that
C$SIG{__DIE__} handler is hidden away deep in some other module that
you didn't know about. There are work arounds however. One is to
localise C$SIG{__DIE__} in every exception trap you write:

eval {
local $SIG{__DIE__};
...
};

Obviously this just doesn't scale - you don't want to be doing that for
every exception trap in your code, and it's a slow down. A second work
around is to check in your handler if you are trying to catch this
exception:

$SIG{__DIE__} = sub {
die $_[0] if $^S;
print "handler\n";
};

However this won't work under Apache::Registry - you're always in an
eval block there!

My personal solution is to warn people about this danger of
C$SIG{__DIE__} and inform them of better ways to code. This is my
attempt at that.

=head1 Better Exception Handling

The Ceval{} construct in itself is a fairly weak way to handle
exceptions as strings. There's no way to pass more information in your
exception, so you have to handle your exception in more than one place
- at the location the error occured, in order to construct a sensible
error message, and again in your exception handler to deconstruct that
string into something meaningful (unless of course all you want your
exception handler to do is dump the error to the browser).

A little known fact about exceptions in perl 5.005 is that you can call
die with an object. The exception handler receives that object in $@.
This is how I always handle exceptions now, as it provides an extremely
flexible and scaleable exceptions solution.

=head2 A Little Housekeeping

First though, before we delve into the details, a little housekeeping
is in order. Most, if not all, mod_perl programs consist of a main
routine that is entered, and then dispatches itself to a routine
depending on the parameters passed and/or the form values. In a normal
C program this is your main() function, in a mod_perl handler this is
your handler() function/method.

In order for you to be able to use exception handling to it's best
extent you need to change your script to have some sort of global
exception 

Re: HTML glitch on perl.apache.org

2000-04-09 Thread Eric Cholet

On Sun, Apr 09, 2000 at 02:32:37PM -0400, Dan McCormick wrote:
 FYI, there's a  missing from the perl.apache.org main page at the line:
 
Latest stable release is 1.22, get it from a href="dist/"this
 site/a or from a
href="http://www.cpan.org/ CPAN  -- HERE
 
p
 
 It causes the page to read 
 
Latest stable release is 1.22, get it from this site or from mod_perl
 programmers.
 
 Which may cause some headscratching.

It's fixed, thanks!

 
 Dan
 

-- 
Eric



Re: Apache::ASP Install - Need help

2000-04-09 Thread Joshua Chamas

Wimpy wrote:
 
 Hello
 I installed ASP for apache according to the readme.
 I have a linux box with slackware 7.0 and 2.2.14
 When I try to look at asp code, it give me the % and everything between
 them.
 What could be wrong?
 Thanks
 JIm

You probably haven't configured AllowOverride All anywhere,
or didn't copy the .htaccess config correctly.  Check out:
  
  http://www.nodeworks.com/asp/install.html#Quick%20Start

-- Joshua
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks  free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051



Re: Sometimes stdout ends in the error_log!

2000-04-09 Thread Joshua Chamas

Give me the Apache::ASP page, and I'll try to duplicate
the problem on my end.

--Joshua

Dan McCormick wrote:
 
 I've encountered a similar problem, in which 'die' statements that
 should never be called end up printing to the error log.  Recently I
 even did
 
 if (0) { die "whoops" }
 
 and a "whoops" error message appeared in the error log.  Even weirder,
 
 if (1) { print "hello" } else { die "goodbye" }
 
 outputs both "hello" to the browser and "goodbye" to the error log.
 
 It only seems to happen in somewhat complex pages (inside a module,
 which has a bunch of hash refs) and if I try to isolate the cause by
 paring things down, the problem just goes away.
 
 My specs:
 apache 1.3.12
 mod_perl 1.21 static (upgrading to 1.22 now to see if it fixes anything)
 Apache::ASP 0.18
 perl 5.005_03
 Redhat 6.1 / kernel 2.2.12
 
 Dan
 
 René Seindal wrote:
 
  I have a problem thats bothering me.  Sometimes one of the httpd childs
  start to send normal output to the error_log, and browsers report
  'document contains no data'. Normally only one child does it, and the
  others respond normally, meaning that the user sees sporadic failure.
 
  Is this a known problem?  Is it in apache or in mod_perl? I don't recall
  having seen anything on the mod_perl list, and dejanews didn't turn up
  anything for apache.
 
  It seems to happen after restarts, so I have taken to the habit of
  stopping the server completely and starting from scratch.  Not a good
  solution, but better than serving docs to the error_log.
 
  It is not a very busy server, so high load is not a likely source of the
  problem.
 
  I am not running the latest and greatest, but neither very old versions:
 
  Perl version 5.00503 for Apache/1.3.11 (Unix) PHP/3.0.14 mod_perl/1.21
  Statically linked mod_perl (php is a DSO).  I also use HTML::Mason 0.81
  on one vhost. Server is a PC, Linux 2.2.13 from slackware 7, 128Mb ram.
 
  --
  René Seindal ([EMAIL PROTECTED])  http://www.seindal.dk/rene/



Re: [newbie] diffs and cvs

2000-04-09 Thread Stas Bekman

 I'll probably never be applying a lot of the diffs I see
 here, but I have to wonder, what are they made for?
 
 They only thing I know is they aren't made by diff for ed.
 
 Oh, and is there a place in the Guide for "getting the latest
 release from CVS," as is often recommended to mod_ers with
 troubles?

It's much easier than you might think it is. Every Apache project rolls a
new tgz of the cvs every 6 hours, you can grab the latest mod_perl CVS
snapshot from http://perl.apache.org/from-cvs/modperl-2.0/,
all the mod_perl related projects from http://perl.apache.org/from-cvs

I'll update the Guide.

It's much easier than starting with a real CVS server if you do that for
the first time. But it worth the hassle, if you want to use open source
software and live on the cutting edge.

__
Stas Bekman | JAm_pH--Just Another mod_perl Hacker
http://stason.org/  | mod_perl Guide http://perl.apache.org/guide/ 
mailto:[EMAIL PROTECTED]  | http://perl.orghttp://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
--




Re: [newbie] diffs and cvs

2000-04-09 Thread Stas Bekman

On Sun, 9 Apr 2000, Matt Sergeant wrote:

 On Sun, 9 Apr 2000, Stas Bekman wrote:
 
   I'll probably never be applying a lot of the diffs I see
   here, but I have to wonder, what are they made for?
   
   They only thing I know is they aren't made by diff for ed.
   
   Oh, and is there a place in the Guide for "getting the latest
   release from CVS," as is often recommended to mod_ers with
   troubles?
  
  It's much easier than you might think it is. Every Apache project rolls a
  new tgz of the cvs every 6 hours, you can grab the latest mod_perl CVS
  snapshot from http://perl.apache.org/from-cvs/modperl-2.0/,
 ^^^
 
 I don't think that's the directory you want. Try just plain modperl/ -
 modperl-2.0/ is currently just Doug's TODO list for modperl-2.0.

Oops, thanks for the correction Matt!
I'm thinking about 2.0 all the time :)

__
Stas Bekman | JAm_pH--Just Another mod_perl Hacker
http://stason.org/  | mod_perl Guide http://perl.apache.org/guide/ 
mailto:[EMAIL PROTECTED]  | http://perl.orghttp://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
--




Re: [newbie] diffs and cvs

2000-04-09 Thread Billy Donahue

On Sun, 9 Apr 2000 [EMAIL PROTECTED] wrote:

 Date: Sun, 9 Apr 2000 12:21:39 EDT
 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: [newbie] diffs and cvs
 
 I'll probably never be applying a lot of the diffs I see
 here, but I have to wonder, what are they made for?
 
 They only thing I know is they aren't made by diff for ed.

They are unified diffs, made with
diff -u 

--
"The Funk, the whole Funk, and nothing but the Funk."
Billy Donahue mailto:[EMAIL PROTECTED]
http://www.escape.com/~billy




Re: [newbie] diffs and cvs

2000-04-09 Thread Ken Williams

[EMAIL PROTECTED] (Stas Bekman) wrote:
It's much easier than starting with a real CVS server if you do that for
the first time. But it worth the hassle, if you want to use open source
software and live on the cutting edge.

For me it's more than that - even if you don't want to use the latest version
all the time (which can be a bad idea if things haven't been tested enough),
it's handy to be able to use the patching features, always know what changes
have already been made but not released, see change logs, and so on.

By far the easiest way to fix bugs and submit patches.


  ------
  Ken Williams Last Bastion of Euclidity
  [EMAIL PROTECTED]The Math Forum





mod_perl and AuthenDBI headaches

2000-04-09 Thread Drew Degentesh

Hello,

My setup is:

Redhat 6.1 (Linux 2.2.12-20RS )
Apache 1.3.12 (compiled from source)
mod_perl: 1.12 (compiled from source)
ApacheDBI-0.87
DBI-1.13
mysql  Ver 9.36 Distrib 3.22.27 (from distribution)
perl 5.005_03 (from distribution)
Msql-Mysql-modules-1.2211

I'm pulling my hair out trying to authenticate against a database. I keep
getting a segmentation fault immediately upon trying to connect to a
database (somewhere around line 245 of Apache/AuthDBI.pm). Ive tried tons of
workarounds...

I have no difficulties using DBI in a 'regular' perl script
(i.e.
#!/usr/bin/perl
use DBI;
DBI-connect( ...
)

...nor do I have any difficulties with mod_perl in general. Just AuthDBI.

When I compiled mod_perl I used EVERYTHING=1 and ALL_HOOKS=1. I enabled APXS
but mod_perl is not loaded as a dynamic library (though PHP4.0RC1 is...)

Any suggestions/co-lamenters?

Please help!

Drew Degentesh
[EMAIL PROTECTED]




Re: [RFC] Exceptions addition to the guide

2000-04-09 Thread Autarch

On Sun, 9 Apr 2000, Matt Sergeant wrote:

 For similar exception handling techniques, see the Try module, the
 Exception module and the Error module, all on CPAN.

There is no Exception module on CPAN?  If you're referring to my code,
it's not yet on CPAN because I don't think I can justify attempting to
take that namespace especially in light of the fact there eventually
will probably be exceptions in Perl itself.

If you're referring to Peter Seibel's Exceptions module, that module
is totally non-functional with modern Perl and has been superseded by
Graham Barr's Error module.

   LError - Graham Barr's excellent OO try/catch/finally module.
   LExceptions - Another exceptions module.
   LTry - Tony Olekshy's. Adds an unwind stack. Not on CPAN (yet?).

See my above comment about the Exceptions module.  I wouldn't mind
being mentioned here.  You could link to the FTP site I mentioned
before (ftp.urth.org/pub).  Eventually I may come up with a suitable
name and put it on CPAN.


-dave

/*==
www.urth.org
We await the New Sun
==*/




Core dump on startup

2000-04-09 Thread Robert Jenks
Title: Core dump on startup





I'm having problems with httpd core dumping during startup and have been completely unable to track it down. Sometimes it will start up fine and other times it will core dump. Any ideas, hints, etc.. would be GREATLY appreciated.

I'm running:
 VALinux/RedHat 6.0 - Linux 2.2.13
 apache 1.3.12
 mod_perl 1.22
 mod_ssl 2.6.2 / OpenSSL 0.9.5
 mm 1.0.12
 perl 5.005_03 (RedHat 6.0 dist RPM)



 Core Info ---
[root@machine logs]# ls -l
total 33359
-rw--- 1 root 506 34025472 Apr 6 21:57 core
-rw--- 1 root 506 0 Apr 6 21:57 httpd.mm.16267.sem
[root@machine logs]# gdb ../bin/httpd core
GNU gdb 4.17.0.13 with Linux support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-redhat-linux...(no debugging symbols found)...
Core was generated by `/HealthSuite/apache/bin/httpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /usr/lib/libgdbm.so.2...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
Reading symbols from /usr/lib/perl5/5.00503/i386-linux/auto/POSIX/POSIX.so...done.
Reading symbols from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Storable/Storable.so...done.
Reading symbols from /usr/lib/perl5/5.00503/i386-linux/auto/IO/IO.so...done.
Reading symbols from /usr/lib/perl5/5.00503/i386-linux/auto/Fcntl/Fcntl.so...done.
Reading symbols from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Digest/MD5/MD5.so...done.
Reading symbols from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBI/DBI.so...done.
Reading symbols from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/XML/Parser/Expat/Expat.so...done.
Reading symbols from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/HTML/Parser/Parser.so...done.
Reading symbols from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Date/Calc/Calc.so...done.
Reading symbols from /usr/lib/perl5/site_perl/5.005/i386-linux/pdflib.so...done.
Reading symbols from /usr/lib/libpdf2.01.so...done.
Reading symbols from /usr/lib/libtiff.so.3...done.
Reading symbols from /usr/lib/libjpeg.so.62...done.
Reading symbols from /usr/lib/libz.so.1...done.
#0 0x40116f49 in chunk_free (ar_ptr=0x401a9dc0, p=0x9f22bf8) at malloc.c:3030
malloc.c:3030: No such file or directory.
(gdb) where
#0 0x40116f49 in chunk_free (ar_ptr=0x401a9dc0, p=0x9f22bf8) at malloc.c:3030
#1 0x40116dd5 in __libc_free (mem=0x9f22c00) at malloc.c:2942
#2 0x819d02c in Perl_safefree ()
#3 0x81ad3ea in Perl_sv_setsv ()
#4 0x81a5ff3 in Perl_pp_sassign ()
#5 0x81d3f8d in Perl_runops_standard ()
#6 0x817c77c in perl_eval_sv ()
#7 0x80b2c2c in perl_do_file ()
#8 0x80b2c5e in perl_load_startup_script ()
#9 0x80af208 in perl_cmd_require ()
#10 0x80c6d57 in ap_clear_module_list ()
#11 0x80c7203 in ap_handle_command ()
#12 0x80c7299 in ap_srm_command_loop ()
#13 0x80c76a0 in ap_process_resource_config ()
#14 0x80c7f82 in ap_read_config ()
#15 0x80d22a3 in main ()
#16 0x400d6493 in __libc_start_main (main=0x80d200c main, argc=1, argv=0xbc04, init=0x807d694 _init, 
 fini=0x81d4e8c _fini, rtld_fini=0x4000a840 _dl_fini, stack_end=0xbbfc)
 at ../sysdeps/generic/libc-start.c:78
(gdb) 



--
Robert Jenks [EMAIL PROTECTED]





 startup.pl
 httpd.conf


Apache::Cookie problems

2000-04-09 Thread Alvar Freude

Hi,

I have some problems in setting and getting back Cookie Values with
Apache::Cookie.


I'm setting a cookie with Apache::Cookie and it seems that the cookie is
set correct:


my $c = Apache::Cookie-new($r,
-name= 'conf',
-value   = $hash_ref,
-expires = '+30D',
-path= '/'
);
$c-bake;


But while Recovering the Cookie I got some errors:

$cookie_ref = Apache::Cookie-fetch;


Now $cookoe_ref-{conf} contains not a reference to the old values, it
contains a skalar like "Apache::Cookie=SCALAR(0x8b675b8)", but no
hashref ...


Whats going on? It seems that I'm too stupid, argl!


The CGI::Cookie-POD only sais: 

   fetch returns an associative array consisting of all
   cookies returned by the browser.  The keys of the array
   are the cookie names.  

OK, OK, but what's with the Values of the Hash?
How can I get the Cookie Values back?

Whats going wrong?



Thanx and Ciao
  Alvar



PATCH for Apache::AuthCookie to overwrite the login_form display

2000-04-09 Thread Gerald Richter

Hi Ken,

I use your Apache::AuthCookie in an application where the way to display the
login form via the custon_response does not fit my needs. Instead the normal
ContentHandler has to display th login form. I have made a simple patch to
Apache::AuthCookie that splits up the call to custom_response in an separate
method, so I am able to overwrite it.

I append you the patch (against 2.006) and hope you will include it in your
next release

Gerald

-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:   Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151
WWW:http://www.ecos.de  Fax:  +49 6133 925152
-

 Apache-AuthCookie-2.006-patch


Re: Apache::Cookie problems

2000-04-09 Thread Rajesh Kumar Mallah


perldoc Apache::Cookie says

   value
   Get or set the values of the cookie:

1.my $value = $cookie-value;
2.my @values = $cookie-value;

3.$cookie-value("string");
4.$cookie-value(\@array); 

so if you set  a array ref in 4 you retrieve it as in 2
extrapolating that I hope if you set a hash ref with value
you should get a hash back with value. The the same happens.

the following two snippets (set and get cookie) demonstrates
that





set-cookie.html
---
% value
   

use Apache;
use Apache::Cookie;

my $hash_ref = {
 'AGE' = 30,
 'SEX' = 'M'
   };
my $r = Apache-request;

my $c = Apache::Cookie-new($r,
-name= 'conf',
-value   = $hash_ref,
-expires = '+30m',
-path= '/'
   );
$c-bake;
%
---


get-cookie.html
--
%
use Apache::Cookie;
my $cookie_ref = Apache::Cookie-fetch;
my $conf_cookie = $cookie_ref-{conf};
my %hash  = $conf_cookie-value;
my $hash_ref = \%hash;
%

html
cookie 'conf'  has value % print $conf_cookie % br
hash reference is % print $hash_ref % br
content of cookie:
AGE: % print $hash{'AGE'} %br
SEX: % print $hash{'SEX'} %br
/html


Alvar Freude wrote:
 
 Hi,
 
 I have some problems in setting and getting back Cookie Values with
 Apache::Cookie.
 
 I'm setting a cookie with Apache::Cookie and it seems that the cookie is
 set correct:
 
 my $c = Apache::Cookie-new($r,
 -name= 'conf',
 -value   = $hash_ref,
 -expires = '+30D',
 -path= '/'
 );
 $c-bake;
 
 But while Recovering the Cookie I got some errors:
 
 $cookie_ref = Apache::Cookie-fetch;
 
 Now $cookoe_ref-{conf} contains not a reference to the old values, it
 contains a skalar like "Apache::Cookie=SCALAR(0x8b675b8)", but no
 hashref ...
 
 Whats going on? It seems that I'm too stupid, argl!
 
 The CGI::Cookie-POD only sais:
 
fetch returns an associative array consisting of all
cookies returned by the browser.  The keys of the array
are the cookie names.
 
 OK, OK, but what's with the Values of the Hash?
 How can I get the Cookie Values back?
 
 Whats going wrong?
 
 Thanx and Ciao
   Alvar



Re: PATCH for Apache::AuthCookie to overwrite the login_form display

2000-04-09 Thread Ken Williams

[EMAIL PROTECTED] (Gerald Richter) wrote:
Hi Ken,

I use your Apache::AuthCookie in an application where the way to display the
login form via the custon_response does not fit my needs. Instead the normal
ContentHandler has to display th login form. I have made a simple patch to
Apache::AuthCookie that splits up the call to custom_response in an separate
method, so I am able to overwrite it.

Thanks Gerald, I'll roll it in.


  ------
  Ken Williams Last Bastion of Euclidity
  [EMAIL PROTECTED]The Math Forum





Re: Mod_Perl install - no apxs error -- COMPILED AND WORKING !!!

2000-04-09 Thread Kenneth Frankel

Finally installed!!!

Sources Of Problems:

   * I was so focused on "no apxs" messages in mod_perl, I didnt question
 my custom build scripts that built mod_perl and Apache ... for two days!
 Scripts ran my apache's Configure after building mod_perl, wiping
 out mod_perl's changes to apache's config.

   * The mod_perl 'make test' tests fail if DO_PREP is selected.  Ditto if you
 do not select EVERYTHING=1.  Another red-herring-like distraction.

   * I didn't fully get rid of redhat's perl when I moved to 5.6.0, the 
5.0.3 lib still existed
 in /usr/lib, and mod_perl may have been including that.  The DSO 
apache would
 compile, but dump core when hit with a GET.


Thanks *SO* much to everybody for their help, especially those that told me
the 'no apxs' messages were ignorable, and suggested I get the bleeding-edge
version.  That got me to realize that the DO_PREP changes mod_perl were making
to apache were being lost when I did my reconfigures, and boom!  Compilation!

Thanks again,
Kenneth