Re: ./httpd -l

[Stas Bekman]

> When I run ./httpd -l should I see mod_perl.c in the list of modules?

Yes, unless httpd was created as DSO and it wasn't configured to load this
module in httpd.conf. 


__
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
--

First argument to Apache::Cookie->new

[Zeqing Xia]

I have noticed that although it is required to pass $r to
Apache::Cookie->new() as the first argument, it appears that no type
checking is performed. In other words, if I pass anything else as the
first arg, no error is reported. However the subsequent call to
$cookie->as_string will result in an empty string. I wonder if it is
possible to do a simple type checking there, since this is the biggest
difference from CGI::Cookie, and for people familiar with CGI::Cookie it
would be a nice debugging info. Thanks very much.

Fred Xia

[RFC] mod_perl Guide/book -- the future

[Stas Bekman]

Hi all,

The Guide release I've just made is one of the planned milestones is has
reached. I've intergrated most of the backlog emails. I still have to
cleanup the TODO file and covert all the META: tags into corrections that
should be done in places you see these tags. 

After I complete the above I re-joins Eric Cholet to work on the book as
delivery deadlines cannot wait. 

I'll continue to watch the list for a new material to add and integrate
your comments and corrections that you send directly to me as before,
reconstruct the guide to improve the navigatability, but the main target
now is to deliver you the book.

This all said, before I make the switch -- this is your chance to review
the current version of the Guide and tell me whether something is wrong or
missing, so the book will include everything you need. 

This is your chance to tell what do you want to see in the book, which is
not yet in the Guide.

Please notice that the new book != Guide.  We will reuse the material from
the guide, but expect lots of other material to be added in the printed
version. 

Regarding the mod_perl2.0/apache2.0/perl5.6 -- we will insert the relevant
material as it becomes available, so don't worry about this. Comments
about other issues are most welcome. 

Thanks!

__
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: memory leak during server graceful restarts

[Douglas Leonard]

I have run into the same issue also both with mod_perl as a DSO module or
compiled staticly.  I have tested it using apache-1.3.6 and apache-1.3.12
w/ mod_perl-1.22 and mod_perl-1.21.  The memory growth also occurs if I
HUP the server rather than sending USR1.  Since the problem only occurs if
mod_perl is loaded (DSO) or staticly loaded, I assume the problem lies in
memory cleanup by modperl.  Even if I do nothing other than have mod_perl
installed and HUP the parent, the process will grow at a relatively rapid
rate of over 1MB per HUP instance.

The reason I noticed this is that I cache some relatively static database
information in the parent process by assignment to a package's scoped hash
variables in my startup.pl.  I wanted to refresh this cache hourly just in
case changes did happen to occur in the database tables I was caching.

I am curious as to whether there is a better way to go about caching this
data and refreshing it without the problem of watching your apache process
size grow every time you HUP it.  Any helpful hints would be appreciated.

The platforms are various Linux kernels ranging from 2.0x to 2.3x.  The
majority of which are linux-2.2.10.


<[EMAIL PROTECTED]>

On Fri, 7 Apr 2000, Nikki Chumakov wrote:

> mod_perl probaly have memory leakage during rereading configs (e.g. on
> the apachectl graceful)
> 
> My system:
> 
> RH 6.1,
> linux-2.2.15pre17
> glibc-2.1
> 
> apache-1.3.12
> mod_ssl-2.6.2
> russian patches (ftp.lexa.ru/pub/apache-rus/) PL29.4
> mm-1.0.12
> mod_perl-1.22
> 
> With mod_perl module enabled in httpd.conf every 'apachectl graceful'
> increase the data memory segment of parent server (and thus the child's
> as well).
> 
> 
> 
> 
> 

./httpd -l

[James Gosnell]

When I run ./httpd -l should I see mod_perl.c in the list of modules?

--

James Gosnell
 [EMAIL PROTECTED]
 ICQ#1727569
 http://premed.dhs.org



 startup.pl

Apache::URI port() problem

[Zeqing Xia]

Hello,

It seems the method unparse() of Apache::URI does not take the port
value into the result string. For example, I have:

 my $uri = Apache::URI->parse($r, $r->uri);
 $uri->scheme('http');
 $uri->hostname($r->get_server_name);
 $uri->port(8080);
 $uri->query(scalar $r->args);

If I call $uri->unparse(), the string returned does not have port 8080
in it. Can anyone shed some light? Thanks.

Fred Xia

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

[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

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

[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: Apache::Cookie problems

[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;
%>


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



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

PATCH for Apache::AuthCookie to overwrite the login_form display

[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

Apache::Cookie problems

[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

Core dump on startup

[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 , 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

Re: [RFC] Exceptions addition to the guide

[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.

>   L - Graham Barr's excellent OO try/catch/finally module.
>   L - Another exceptions module.
>   L - 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
==*/

Re: [newbie] diffs and cvs

[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

[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: [newbie] diffs and cvs

[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 
http://www.escape.com/~billy

Re: [newbie] diffs and cvs

[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

[Matt Sergeant]

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.

-- 


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

Re: [newbie] diffs and cvs

[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: Sometimes stdout ends in the error_log!

[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: Apache::ASP Install - Need help

[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: HTML glitch on perl.apache.org

[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 this
> site or from href="http://www.cpan.org/ CPAN  <-- HERE
> 
>
> 
> 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

[RFC] Exceptions addition to the guide

[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 S 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 C construct. Many
people initially make the mistake that this is the same as the C construct, which compiles and executes code at run time, but
that's not the case. C 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 I 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 C 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 C 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 handling. This is much more 

Re: Mod_Perl install - "no apxs" error

[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.

  Alias /perl/ /home/httpd/cgi-bin/
  
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
  

*
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.

Re: Sometimes stdout ends in the error_log!

[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/

Pls discard prev msg

[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

Diff between Apache::Cookie and CGI::Cookie

[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

my first mod_perl works but ...

[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  $level|;
}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_level|;
}
}

##
##   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

HTML glitch on perl.apache.org

[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 this
site or from http://www.cpan.org/ CPAN  <-- HERE

   

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

Mod_Perl install - "no apxs" error

[Kenneth Frankel]

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.

Following instructions in INSTALL:
 perl Makefile.pl
 make
I get a dozen of these:
 which: no apxs in (/usr/local/bin:/bin:/usr/bin:/usr/local/mysql/bin:.)

Following instructions in INSTALL.apaci, method 2 - the flexible way:
  Makefile.PL \
  APACHE_SRC=../apache_1.3.12/src \
  DO_HTTPD=1 \
  USE_APACI=1 \
  PREP_HTTPD=1 \
  EVERYTHING=1
I get a dozen of these:
 which: no apxs in (/usr/local/bin:/bin:/usr/bin:/usr/local/mysql/bin:.)
After which, make test fails and nothing goes on.

Now, apxs is apache's DSO compiler and I am trying to get mod_perl 
installed statically, so I was guessing mod_perl is reading an old config 
file from somewhere and thinking it wants to be a DSO, so I uninstalled 
(rpm -e) redhat's php,mod_perl, and apache, rebooted just for fun, created 
clean source from the tar.gz's, and still, I am getting the "no apxs" 
messages.

Anywhere I should be looking / anything I could be trying?  Is mod_perl 
really dependent on apxs?  Do I really have to build Apache to get the apxs 
to install mod_perl?  Nowhere in the instructions does it says that's 
necessary.

(BTW, when I do compile+install Apache first, then compile+install 
mod_perl, it does end up with an executable, but that segmentation faults 
when I try hitting the web server with a browser.)

Please help me!!!

Many Thanks,
Kenneth

P.S.  Here's output from the perl Makefile.PL:
 >perl Makefile.PL \
 >  APACHE_SRC=../apache_1.3.12/src \
 >  DO_HTTPD=1 \
 >  USE_APACI=1 \
 >  PREP_HTTPD=1 \
 >  EVERYTHING=1
 >Will configure via APACI
 >(cd ../apache_1.3.12/src && ./Configure -file Configuration)cp
 >apaci/Makefile.libdir ../apache_1.3.12/src/modules/perl/Makefile.libdir
 >cp apaci/Makefile.tmpl ../apache_1.3.12/src/modules/perl/Makefile.tmpl
 >cp apaci/README ../apache_1.3.12/src/modules/perl/README
 >cp apaci/configure ../apache_1.3.12/src/modules/perl/configure
 >cp apaci/libperl.module ../apache_1.3.12/src/modules/perl/libperl.module
 >cp apaci/mod_perl.config.sh
 >../apache_1.3.12/src/modules/perl/mod_perl.config.sh
 >cp apaci/load_modules.pl.PL
 >../apache_1.3.12/src/modules/perl/load_modules.pl.PL
 >cp apaci/find_source.PL ../apache_1.3.12/src/modules/perl/find_source.PL
 >cp apaci/apxs_cflags.PL ../apache_1.3.12/src/modules/perl/apxs_cflags.PL
 >cp apaci/mod_perl.exp ../apache_1.3.12/src/modules/perl/mod_perl.exp
 >PerlDispatchHandler.enabled
 >PerlChildInitHandlerenabled
 >PerlChildExitHandlerenabled
 >PerlPostReadRequestHandler..enabled
 >PerlTransHandlerenabled
 >PerlHeaderParserHandler.enabled
 >PerlAccessHandler...enabled
 >PerlAuthenHandler...enabled
 >PerlAuthzHandlerenabled
 >PerlTypeHandler.enabled
 >PerlFixupHandlerenabled
 >PerlHandler.enabled
 >PerlLogHandler..enabled
 >PerlInitHandler.enabled
 >PerlCleanupHandler..enabled
 >PerlRestartHandler..enabled
 >PerlStackedHandlers.enabled
 >PerlMethodHandlers..enabled
 >PerlDirectiveHandlers...enabled
 >PerlTableApienabled
 >PerlLogApi..enabled
 >PerlUriApi..enabled
 >PerlUtilApi.enabled
 >PerlFileApi.enabled
 >PerlConnectionApi...enabled
 >PerlServerApi...enabled
 >PerlSectionsenabled
 >PerlSSI.enabled
 >Will run tests as User: 'kenneth' Group: 'kenneth'
 >Checking CGI.pm VERSION..ok
 >Checking for LWP::UserAgent..ok
 >Checking for HTML::HeadParserok
 >Checking if your kit is complete...
 >Looks good
 >which: no apxs in (/usr/local/bin:/bin:/usr/bin:/usr/local/mysql/bin:.)
 >Writing Makefile for Apache
 >which: no apxs in (/usr/local/bin:/bin:/usr/bin:/usr/local/mysql/bin:.)
 >Writing Makefile for Apache::Connection
 >which: no apxs in (/usr/local/bin:/bin:/usr/bin:/usr/local/mysql/bin:.)
 >Writing Makefile for Apache::Constants
 >which: no apxs in (/usr/local/bin:/bin:/usr/bin:/usr/local/mysql/bin:.)
 >Writing Makefile for Apache::File
 >Writing Makefile for Apache::Leak
 >which: no apxs in (/usr/local/bin:/bin:/usr/bin:/usr/local/mysql/bin:.)
 >Writing Makefile for Apache::Log
 >which: no apxs in (/usr/local/bin:/bin:/usr/bin:/usr/local/mysql/bin:.)
 >Writing Makefile for Apache::ModuleConfig
 >which: no apxs in (/usr/local/bin:/bin:/usr/bin:/usr/local/mysql/bin:.)
 >Writing Makefile for Apache::PerlRunXS
 >which: no apxs in (/usr/local/bin:/bin:/usr/bin:/usr/local/mysql/bin:.)
 >Writing Makefile for Apache::Server
 >Writing Makefile for Apache::Symbol

Re: [newbie] diffs and cvs

[Mark Imbriaco]

On Sun, 9 Apr 2000 [EMAIL PROTECTED] 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.

They're for use with patch(1).
 
> 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?

http://perl.apache.org/mod_perl_cvs.html

 
-Mark

[newbie] diffs and cvs

[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

Sometimes stdout ends in the error_log!

[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/

ANNOUNCE: mod_perl Guide ver 1.22

[Stas Bekman]

The mod_perl Guide version 1.22 is out. Read it online at
http://perl.apache.org/guide or grab the POD sources from CPAN:

  file: $CPAN/authors/id/S/ST/STAS/Apache-mod_perl_guide-1.22.tar.gz
  size: 423613 bytes
   md5: 05fe69c80269e561490ad41a72b6a412

Please allow up to six hours for your favorite mirror to get the new
version.

Changes:

* intro: updated the long due credits section

* snippets: new: "Authentication Snippets" (Michael Finke, Eric
  Cholet)

* debug: new: "Apache::DumpHeaders" (Ask Bjoern Hansen)

* debug: new: "Apache::DebugInfo" (Geoffrey Young)

* config: updated: "PerlFreshRestart" with DSO notes (Doug, Vivek
  Khera)

* troubleshooting: new: "Can't upgrade that kind of scalar ..." (Doug)

* performance: new: "Bloatware" (Tom Christiansen)

* performance: new: "CGI.pm versus Apache::Request" (Doug)

* performance: new: "Apache::Registry versus pure PerlHandler" (Doug)

* performance: new: "TMTOWTDI: Convenience and Performance"

* install: "Is it possible to run mod_perl enabled Apache as suExec?"
  (Randal L. Schwartz, Matt Sergeant)

* performance: updated: "Benchmarking PerlHandlers"

* performance: new: "Keeping the Shared Memory Limit"

* porting: new: "File tests operators"

* performance: updated "PerlSetupEnv Off" with a test script

* snippets: new: "Getting the Front-end Server's Name in the Back-end
  Server" (Sean Dague)

* porting: extended "Taint mode" -- a suggestion for services that
  move to mod_perl and have part of the scripts that won't run under
  enabled Taint mode (Gunther Birznieks, Ken Williams)

* modules: new: "Apache::OutputChain -- Chain Stacked Perl Handlers"
  (Honza Pazdziora, Eric Cholet)

* snippets: new: "SSI and Embperl -- Doing Both" (Michael Schout)

* performance: new: "-Dusemymalloc Perl Build Option" (Doug, Jeffrey
  W. Baker)

* strategy: added unedited answer for the question "Multithreading or
  not Multithreading" (Shane [EMAIL PROTECTED])

* install: updated "Automating installation" (James G Smith)

* performance: added a workaround for limiting memory usage under
  Linux to "Limiting the Resources Used by httpd Children" (Kevin
  Murphy)

* debug: added clarification fd leakage in "Safe Resource Locking"
  (Bill Moseley)

* multiuser: extended the scenario for multi-user/multi-webserver on
  one machine option, how to enforce port and similar settings without
  forbidding user to modify his httpd.conf. (inspired by Greg Cope)

* scenario: new: "Caching in mod_proxy" (Ilya Obshadko)

* porting: new: "Accessing Request Object in non-Perl*Handler Modules"
  (Doug)

* config: new: "Adding Custom Configuration Directives" (Doug)

* snippets: new: "Convert a POST Request into a GET Request" (Doug)

* scenario: extended the "Getting the Remote Server IP in the Back-end
  server in the Proxy Setup" section with notes about the modules
  configuration precedence problem and its solution. (Ilya Obshadko,
  Ewan Edwards)

* strategy: new "Pros and Cons of Building mod_perl as DSO" (based on
  http://www.apache.org/docs/dso.html by Ralf S. Engelschall)

* strategy: new: "mod_perl and mod_ssl" (Tom Mornini, Vivek Khera, Mads
  Toftum)

* snippets: added a "PerlTransHandler example" (Randal L. Schwartz,
  Ajay Shah)

* config: extended examples for " sections", added the package
  declaration caveat, Apache::ReadConfig namespace and more.

* performance: extended the "Reducing the Number of stat() Calls"
  section, with examples of PerlTransHandler and reducing stat()s for
  .htaccess look-ups

* help: added the perlmonth.com and Gerald Richter's article reference

* porting: updated the "Right headers generation": OS with EBCDIC as
  character set and sending proper headers. (Doug)

* porting: added: "Apache::print() and CORE::print()" (Doug)

* debug: updated: Sys::Signal, SIGALRM and perl5.6 issue (Doug and Bill
  Moseley)

* config: $Apache::Server::StrictPerlSections (Doug)

* scenario: more practical mod_rewrite examples by Geoffrey Young.

* minor corrections: download.pod by Ron Pool, scenario.pod by Terry
  West and Eric Cholet, config.pod by Richard More, performance.pod by
  Stephen Judd and Steve Reppucci, frequent.pod by Andreas Piesk.

* review: Mark Summerfield has joined the group of the kind people who
  review and correct the Guide. He has reviewed these chapters:
  advocacy, config, control, databases, dbm, debug, download,
  frequent, hardware, help, install.

* review: Ged W. Haywood was very kind to review and correct the
  debug chapter.


Enjoy!

__
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
--

Apache::ASP Install - Need help

[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

Re: [RFC] Exceptions addition for the guide.

[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.

-- 


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