Re[2]: [mp2] make test failed

[Alan Rafagudinov]

Hi!

>> My guess is that you've been hit by this Apache problem:
>> http://httpd.apache.org/docs-2.0/faq/error.html#error.sendfile
>> 
>> As the URL above suggests, try to add 'EnableSendfile On' somewhere in 
>> t/conf/httpd.conf and rerun:
>> 
>> t/TEST -v filter/in_bbs_msg.t hooks/trans.t
>> 
>> don't run 'make test' as it'll rewrite t/conf/httpd.conf, use t/TEST 
>> instead.
>> 
>> I wonder why http://httpd.apache.org/docs-2.0/mod/core.html#enablesendfile
>> says that it's on by default.

SB> Argh, I confused "simply use the EnableSendfile directive" as to be turned on. 
SB> It should be:

SB>EnableSendfile Off

SB> of course.

I guessed :-)

Thank you, but your advice helped with hooks/trans.t only,
filter/in_bbs_msg.t is still failed:

 t/TEST -v filter/in_bbs_msg.t
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST -v 'filter/in_bbs_msg.t'
*** root mode: changing the fs ownership to 'nobody' (99:99)
/usr/local/httpd_perl/bin/httpd  -d /usr/src/httpd_perl/mod_perl-1.99_09/t -f
/usr/src/httpd_perl/mod_perl-1.99_09/t/conf/htt
pd.conf -DAPACHE2
using Apache/2.0.47 (prefork MPM)

waiting for server to start: .[Fri Aug 29 18:10:56 2003] [info] 20 Apache:: modules 
loaded
[Fri Aug 29 18:10:56 2003] [info] 3 APR:: modules loaded
[Fri Aug 29 18:10:56 2003] [info] base server + 8 vhosts ready to run tests
..
waiting for server to start: ok (waited 2 secs)
server www.myhost.ru:8529 started
server www.myhost.ru:8530 listening (TestProtocol::echo_filter)
server www.myhost.ru:8531 listening (TestProtocol::echo)
server www.myhost.ru:8532 listening (TestPreConnection::note)
server www.myhost.ru:8533 listening (TestFilter::in_str_msg)
server www.myhost.ru:8534 listening (TestFilter__both_str_con_add)
server www.myhost.ru:8535 listening (TestFilter::in_bbs_msg)
server www.myhost.ru:8536 listening (TestDirective::perlmodule)
server www.myhost.ru:8537 listening (TestDirective::perlrequire)
server www.myhost.ru:8538 listening (TestDirective::perlloadmodule4)
server www.myhost.ru:8539 listening (TestDirective::perlloadmodule5)
server www.myhost.ru:8540 listening (TestDirective::perlloadmodule3)
server www.myhost.ru:8541 listening (TestDirective::perlloadmodule6)
filter/in_bbs_msg# connecting to www.myhost.ru:8535
server side has failed (response code: 404),
see t/logs/error_log for more details
dubious
Test returned status 29 (wstat 7424, 0x1d00)
*** server www.myhost.ru:8529 shutdown
!!! error running tests (please examine t/logs/error_log)

-- 

[Fri Aug 29 18:10:56 2003] [info] mod_unique_id: using ip addr 127.0.0.1
END in modperl_extra.pl, pid=26270
[Fri Aug 29 18:10:57 2003] [notice] Digest: generating secret for digest 
authentication ...
[Fri Aug 29 18:10:57 2003] [notice] Digest: done
[Fri Aug 29 18:10:57 2003] [info] mod_unique_id: using ip addr 127.0.0.1
[Fri Aug 29 18:10:58 2003] [notice] Apache/2.0.47 (Unix) mod_perl/1.99_09 Perl/v5.8.0 
DAV/2 configured -- resuming
normal ope
rations
[Fri Aug 29 18:10:58 2003] [info] Server built: Aug 28 2003 18:59:50
[Fri Aug 29 18:10:58 2003] [debug] prefork.c(1037): AcceptMutex: sysvsem (default: 
sysvsem)
[Fri Aug 29 18:10:58 2003] [error] [client 127.0.0.1] File does not exist:
/usr/src/httpd_perl/mod_perl-1.99_09/t/htdocs/inpu
t_filter.html
[Fri Aug 29 18:10:58 2003] [error] server reached MaxClients setting, consider raising 
the MaxClients setting
[Fri Aug 29 18:10:58 2003] [info] Child process pid=26290 is exiting
[Fri Aug 29 18:10:58 2003] [info] removed PID file 
/usr/src/httpd_perl/mod_perl-1.99_09/t/logs/httpd.pid (pid=26289)
[Fri Aug 29 18:10:58 2003] [notice] caught SIGTERM, shutting down
END in modperl_extra.pl, pid=26289

I've used standard distributive. Any ideas why I have no
input_filter.html ?

--
Alan Rafagudinov
E-mail: [EMAIL PROTECTED] | [EMAIL PROTECTED]
Homepage: http://www.rafagudinov.com
Phone: +7(926)22-5



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

[mp2] make test failed

[Alan Rafagudinov]

f_t='off_t', lseeksize=8
alignbytes=4, prototype=define
  Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldl -lm -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.2.4'
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl):
  Compile-time options: USE_LARGE_FILES
  Built under linux
  Compiled at Aug 28 2003 15:10:57
  %ENV:
PERL_LWP_USE_HTTP_10="1"
  @INC:
/usr/local/lib/perl5/5.8.0/i686-linux
/usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl
.


-- 
Alan Rafagudinov
E-mail: [EMAIL PROTECTED] | [EMAIL PROTECTED]
Homepage: http://www.rafagudinov.com
Phone: +7(926)22-5



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re[2]: [mp1.0] Installation problem

[Alan Rafagudinov]

Hello Ged,

Wednesday, August 27, 2003, 6:11:13 PM, you wrote:

GH> Hi there,

GH> On Wed, 27 Aug 2003, Alan Rafagudinov wrote:

>> I've downloaded apache_1.3.28.tar.gz & mod_perl-1.28.tar.gz
>> [snip]
>> tests failed:
>> [snip]
>> Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
>>   Platform:
>> osname=linux, osvers=2.2.16-22smp, archname=i386-linux

GH> Upgrade Perl (and your operating system?:). that might help, and
GH> version 5.6.0 of Perl is a disaster just waiting to happen anyway.
GH> You should be OK with 5.6.1 but I would think 5.8.1 might be better.

>> [snip]
>>   Compiler:
>> cc='gcc', optimize='-O2 -march=i386 -mcpu=i686', gccversion=2.96 2731 
>> (ASPLinux 7.0 2.96-79)

GH> Please post the output of

GH> gcc -v

Reading specs from /usr/lib/gcc-lib/i386-asplinux-linux/2.96/specs
gcc version 2.96 2731 (ASPLinux 7.1 2.96-85.asp)

GH> on your system.

GH> 73,
GH> Ged.




-- 
Alan Rafagudinov
E-mail: [EMAIL PROTECTED] | [EMAIL PROTECTED]
Homepage: http://www.rafagudinov.com
Phone: +7(926)22-5



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

[mp1.0] Installation problem

[Alan Rafagudinov]

5  83.33%  1-4, 6
internal/rwrite   22 100.00%  1-2
internal/stacke 111 28416??   ??   %  ??
internal/table.  ??   ??   %  ??
internal/taint. 111 28416 33 100.00%  1-3
modules/request  10   10 100.00%  1-10
modules/status. 111 2841610   10 100.00%  1-10
modules/symbol.  ??   ??   %  ??
modules/uri.t??   ??   %  ??
modules/util.t   ??   ??   %  ??
3 tests skipped.
sh: kill: (2584) - No such pid
httpd terminated
Failed 18/34 test scripts, 47.06% okay. 74/258 subtests failed, 71.32% okay.
make: *** [run_tests] Error 2

--

Output of perl -V:

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
osname=linux, osvers=2.2.16-22smp, archname=i386-linux
uname='linux build.asplinux.ru 2.2.16-22smp #1 smp thu dec 28 12:06:28 msk 2000 
i686 unknown '
config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc 
-Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr -D
archname=i386-linux -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm -Di_shadow 
-Di_syslog -Dman3ext=3pm -Uuselargefiles'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=undef
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
  Compiler:
cc='gcc', optimize='-O2 -march=i386 -mcpu=i686', gccversion=2.96 2731 
(ASPLinux 7.0 2.96-79)
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccflags ='-fno-strict-aliasing -I/usr/local/include'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -ldl -lm -lc -lcrypt
libc=/lib/libc-2.2.2.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl):
  Compile-time options:
  Built under linux
  Compiled at Apr  7 2001 23:26:14
  @INC:
/usr/lib/perl5/5.6.0/i386-linux
/usr/lib/perl5/5.6.0
/usr/lib/perl5/site_perl/5.6.0/i386-linux
/usr/lib/perl5/site_perl/5.6.0
/usr/lib/perl5/site_perl




-- 
Alan Rafagudinov
E-mail: [EMAIL PROTECTED] | [EMAIL PROTECTED]
Homepage: http://www.rafagudinov.com
Phone: +7(926)22-5



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Installation problem

[Alan Rafagudinov]

  22 100.00%  1-2
internal/stacke 111 28416??   ??   %  ??
internal/table.  ??   ??   %  ??
internal/taint. 111 28416 33 100.00%  1-3
modules/request  10   10 100.00%  1-10
modules/status. 111 2841610   10 100.00%  1-10
modules/symbol.  ??   ??   %  ??
modules/uri.t??   ??   %  ??
modules/util.t   ??   ??   %  ??
3 tests skipped.
sh: kill: (2584) - No such pid
httpd terminated
Failed 18/34 test scripts, 47.06% okay. 74/258 subtests failed, 71.32% okay.
make: *** [run_tests] Error 2

-- 
Alan Rafagudinov
E-mail: [EMAIL PROTECTED] | [EMAIL PROTECTED]
Homepage: http://www.rafagudinov.com
Phone: +7(926)22-5



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re[2]: Multiple select

[Alan Rafagudinov]

Perrin Harkins> On Tue, 2003-08-05 at 12:34, Alan Rafagudinov wrote:
>> Hello!
>> 
>> I have the next html code:
>> 
>> 
>>  Smth_1
>> ...
>>  Smth_n
>> 
>> 
>> User is able to select many values in the list, how can I get all of
>> them in my mod_perl script?

Perrin Harkins> Use Apache::Request or CGI.pm.

Please small example of using Apache::Request.

 $r->content;
 $r = Apache->request;

 does not work :-(

Multiple select

[Alan Rafagudinov]

Hello!

I have the next html code:


 Smth_1
...
 Smth_n


User is able to select many values in the list, how can I get all of
them in my mod_perl script?

Thanx!
Good luck!

mod_perl 2 & APache 2.0 MPM

[Sinclair, Alan (CORP, GEAccess)]

All,
Starting to strike the first blows with Apache 2.0. I am now wondering about
thread safety with mod_perl 2. Will mod_perl support a threaded MPM Apache
config ?

Thanks,

RE: 1.3.27 DSO hassles

[Sinclair, Alan (CORP, GEAccess)]

Here's the solution to resolve the __floatdisf symbol error. Thanks to Paul
Weiss who provided the hint.

Configure and install Apache
Relink mod_negotiation.so with libgcc.a (I opted to statically link mod_perl
into the core)
cd apache_1.3.27/src/modules
ld -G -o mod_negotiation.so mod_negotiation.lo /pathto/libgcc.a

This will extract the floatdisf function from libgcc.a and link it into
mod_negotiation.so which can be verified with nm. The libgcc.a archive will
be contained into your gcc build tree under gcc-3.2.1/gcc

Thanks to all who replied.
Alan



-Original Message-
From: Paul Weiss [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 15, 2003 11:20 AM
To: Sinclair, Alan (CORP, GEAccess); [EMAIL PROTECTED]
Subject: Re: 1.3.27 DSO hassles


Hi--

I also had this problem when I built on Solaris (2.7).

Here is how I fixed it:

The symbol is in libgcc.a.  Use
  gcc -print-libgcc-file-name
to see where that file is.

Now, delete mod_negotiation.so and re-make.
See how make does the link.
Then, just re-link adding the file to the command line.

I think you have to do it for one other module as well, but I
don't remember which one.

I never came up with a fully automated way to do it, but I didn't
rebuild Apache that often.


-P

- Original Message -
From: "Sinclair, Alan (CORP, GEAccess)" <[EMAIL PROTECTED]>
To: "Sinclair, Alan (CORP, GEAccess)" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, January 15, 2003 12:40 PM
Subject: RE: 1.3.27 DSO hassles


> I was attempting to configure mod_perl first before factoring in mod_ssl.
I
> cannot find the library that contains the symbol __floatdisf. It's not in
> libcrypt or libssl libraries from openssl, it does not appear to be in any
> library in /usr/lib or /lib. The symbol is not defined in any Apache
object
> file either. I'm kinda stumped ont this. I was thinking of upgrading to
> Solaris 8.
>
> Thanks
> as
>
>
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 13, 2003 4:29 PM
> To: Sinclair, Alan (CORP, GEAccess)
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: 1.3.27 DSO hassles
>
>
> Sinclair, Alan (CORP, GEAccess) wrote:
> > All,
> > Having been successfully using modperl for the last 2 years statically
> > linked with Apache, I have been trying again to make modperl work with
> > 1.3.27 when the Apache core modules are loaded as DSOs. There has been
> some
> > traffic in the past on this subject and I checked the archives  and
> followed
> > through on some of the suggestions
> > - Recompiled perl 5.6 with the --Ubincompat5005 option for specific use
> with
> > modperl
> > - Setup modperl using the perl compiled with --Ubincompat5005
> > - I use the following configure options for the APACI for Apache 1.3.27
> > ./configure --prefix=/opt/apache-so \
> > --enable-rule=SHARED_CORE \
> > --enable-module=most \
> > --enable-shared=max \
> > --activate-module=src/modules/perl/libperl.a \
> > --disable-shared=perl
> >
> > Apache is compiled and statically links modperl without any problems
> > (Solaris 2.6). When Apache is executed, I receive this error:
> > fatal: relocation error: file /opt/apache-so/libexec/mod_negotiation.so:
> > symbol __floatdisf: referenced symbol not found
> > I have tried the recommendations, specifically the issue with perl's
> malloc
> > on Solaris which can be corrected with the --Ubincompat5005  option.
>
> There were some suggestions offered in this thread (large files CFLAGS?)
> http://marc.theaimsgroup.com/?t=10168427183&r=1&w=2
> Though I didn't see a success report.
>
> If somebody on Solaris 2.6 were able to get it to work, please chime in.
>
> __
> 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
>

RE: 1.3.27 DSO hassles

[Sinclair, Alan (CORP, GEAccess)]

I was attempting to configure mod_perl first before factoring in mod_ssl. I
cannot find the library that contains the symbol __floatdisf. It's not in
libcrypt or libssl libraries from openssl, it does not appear to be in any
library in /usr/lib or /lib. The symbol is not defined in any Apache object
file either. I'm kinda stumped ont this. I was thinking of upgrading to
Solaris 8.

Thanks
as


-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 13, 2003 4:29 PM
To: Sinclair, Alan (CORP, GEAccess)
Cc: '[EMAIL PROTECTED]'
Subject: Re: 1.3.27 DSO hassles


Sinclair, Alan (CORP, GEAccess) wrote:
> All,
> Having been successfully using modperl for the last 2 years statically
> linked with Apache, I have been trying again to make modperl work with
> 1.3.27 when the Apache core modules are loaded as DSOs. There has been
some
> traffic in the past on this subject and I checked the archives  and
followed
> through on some of the suggestions
> - Recompiled perl 5.6 with the --Ubincompat5005 option for specific use
with
> modperl
> - Setup modperl using the perl compiled with --Ubincompat5005 
> - I use the following configure options for the APACI for Apache 1.3.27
> ./configure --prefix=/opt/apache-so \
> --enable-rule=SHARED_CORE \
> --enable-module=most \
> --enable-shared=max \
> --activate-module=src/modules/perl/libperl.a \
> --disable-shared=perl 
>  
> Apache is compiled and statically links modperl without any problems
> (Solaris 2.6). When Apache is executed, I receive this error:
> fatal: relocation error: file /opt/apache-so/libexec/mod_negotiation.so:
> symbol __floatdisf: referenced symbol not found 
> I have tried the recommendations, specifically the issue with perl's
malloc
> on Solaris which can be corrected with the --Ubincompat5005  option.

There were some suggestions offered in this thread (large files CFLAGS?)
http://marc.theaimsgroup.com/?t=10168427183&r=1&w=2
Though I didn't see a success report.

If somebody on Solaris 2.6 were able to get it to work, please chime in.

__
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

1.3.27 DSO hassles

[Sinclair, Alan (CORP, GEAccess)]

All,
Having been successfully using modperl for the last 2 years statically
linked with Apache, I have been trying again to make modperl work with
1.3.27 when the Apache core modules are loaded as DSOs. There has been some
traffic in the past on this subject and I checked the archives  and followed
through on some of the suggestions
- Recompiled perl 5.6 with the --Ubincompat5005 option for specific use with
modperl
- Setup modperl using the perl compiled with --Ubincompat5005 
- I use the following configure options for the APACI for Apache 1.3.27
./configure --prefix=/opt/apache-so \
--enable-rule=SHARED_CORE \
--enable-module=most \
--enable-shared=max \
--activate-module=src/modules/perl/libperl.a \
--disable-shared=perl 
 
Apache is compiled and statically links modperl without any problems
(Solaris 2.6). When Apache is executed, I receive this error:
fatal: relocation error: file /opt/apache-so/libexec/mod_negotiation.so:
symbol __floatdisf: referenced symbol not found 
I have tried the recommendations, specifically the issue with perl's malloc
on Solaris which can be corrected with the --Ubincompat5005  option.

Any ideas
Thanks
Alan

HELP with mod_perl version

[Alan Chung]

Hi,

I have tried to upgrade my apache from 1.3.12 to 1.3.26 and openssl from 
0.9.5a to 0.9.6g.
But when I upgraded mod_perl from 1.24 to 1.26 (it seems that I have to), 
it could be compiled with no error but httpd couldn't be started with the 
following error:

Apache.pm version 1.26 required!
/usr/lib/perl5/site_perl/5.6.0/i686-linux/Apache.pm is version 1.27
Perhaps you forgot to 'make install' or need to uninstall an old version?
Found: /usr/lib/perl5/site_perl/5.6.0/i686-linux/Apache.pm

From the error, it looks like I need to fall back to order version for 
mod_perl (?),
So I did try to uninstall the current Perl and mod_perl and reinstall again.
I even tried the different version of mod_perl (1.25, 1.27) but with the 
same error.

Could anyone give me an advice?

Alan 

Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?

[Alan]

On Wed, Oct 09, 2002 at 02:43:18PM -0700, Paul wrote:
> The company is making us migrate (some baloney about being legally
> vulnerable because we're using open source), and I've got to convert a
> nice, simple, efficient Apache/mod_perl/MySQL solution to iPlanet/LDAP.
> 
> Am I looking at a complete redesign here?

That totally sux0rs :(  Maybe you should try hitting the powers-that-be
with a large 2x4" clue-stick?  Or mention that other huge businesses
such as imdb, banner ad companies, etc use it and are still sucessful
and raking in the cash.  A long shot but.

alan

-- 
Alan "Arcterex" <[EMAIL PROTECTED]>   -=][=-   http://arcterex.net
"I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson

Re: virtualhost based variables

[Alan]

On Wed, Oct 02, 2002 at 06:04:03PM -0500, James G Smith wrote:
> Alan <[EMAIL PROTECTED]> wrote:
> >Greetings again.
> >
> >I'm trying to figure out the best/fastest/most elegant way of setting
> >virtualhost based variables.  Basically I have three sites, and the only
> >difference between them is the DocumentRoot ($htdocroot) and the database
> >their data is being accessed from ($dbh).
> 
> Document root should be accessable from $r.
> 
> I would use Apache::DBI for persistent connections.  Then connect at
> the beginning of the request with the DBI connection parameters
> coming from $r->dir_config.

Yup, and this is exactly how I have it working right now.  Each module
starts by re-instantiating $dbh and $htdocroot via dir_config and a
function that uses dir_config to find the database it's supposed to grab
stuff from.

The problem is that it seems like I've incurred a pretty high speed
penalty, and my requests/sec have dropped from about 165 to 83 :(  I'm
still pushing enough data to saturate a T1, so at the end it's not 
going to be a noticable difference.  I wanted to know if there was a
better/faster way to do this though, without having to call $r->dir_config
and $r->document_root for /every/ request.

Alan

-- 
Alan "Arcterex" <[EMAIL PROTECTED]>   -=][=-   http://arcterex.net
"I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson

virtualhost based variables

[Alan]

Greetings again.

I'm trying to figure out the best/fastest/most elegant way of setting
virtualhost based variables.  Basically I have three sites, and the only
difference between them is the DocumentRoot ($htdocroot) and the database
their data is being accessed from ($dbh).

When it was a single site I had $documentroot and $dbh declared in my 
startup.pl, and my modules accessed it through $main::dbh, and it was
all find and dandy.  

Is there a way to do this? Or do I have to use $r->dir_config in every
module to get the document root and re-create $dbh? 

I know mod_perl 2.0 will solve this problem with the +Parent option, but
heading to apache 2.0 might not be an option at this point.

So how does everyone else do it? :)

TIA

alan

-- 
Alan "Arcterex" <[EMAIL PROTECTED]>   -=][=-   http://arcterex.net
"I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson

Re: cookies and IE

[Alan]

On Wed, Oct 02, 2002 at 08:30:54PM +0200, Per Einar Ellefsen wrote:
> At 20:12 02.10.2002, Alan wrote:
> >On Wed, Oct 02, 2002 at 01:21:49PM -0400, Geoffrey Young wrote:
> >> so, it's not really a bug if you dig down into the docs and examples.
> >>  looks like a feature, though :)
> >
> >Agreed... more of a 'gotcha' though, ready to bite people in the butt.
> >Personally I think it might make more sense to do a check to see if the
> >val =~ /(\d+)(h|m|d|M)/ before it's sent off as a literal, but who
> >knows.  I'll email someone about it anyway.
> 
> It's because you can put a correctly formatted date string in the -expires 
> option, AFAIK. So if using your idea, the "literal" string might be 
> misinterpreted. Also, don't forget that you have +1d and -1d as another 
> possibility. I think the +/- makes sense. It's just one character :)

Oh, totally agreed, I just figured that it might be a good way to set a
default if there was no + or -, which could eliminate headaches for
people like me :)  Also, as there's no chance of a correctly formatted
date string being "\d(h|m|d|etc)", it could be a fair assumption.

My $0.02 anyway! :)

alan

-- 
Alan "Arcterex" <[EMAIL PROTECTED]>   -=][=-   http://arcterex.net
"I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson

Re: cookies and IE

[Alan]

On Wed, Oct 02, 2002 at 01:21:49PM -0400, Geoffrey Young wrote:
> so, it's not really a bug if you dig down into the docs and examples. 
>  looks like a feature, though :)

Agreed... more of a 'gotcha' though, ready to bite people in the butt.
Personally I think it might make more sense to do a check to see if the
val =~ /(\d+)(h|m|d|M)/ before it's sent off as a literal, but who
knows.  I'll email someone about it anyway.

alan

-- 
Alan "Arcterex" <[EMAIL PROTECTED]>   -=][=-   http://arcterex.net
"I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson

Re: cookies and IE

[Alan]

On Wed, Oct 02, 2002 at 08:15:23AM -0500, Nicholas Studt wrote:
> > Alan wrote [ 01 October 2002 at 03:09 pm ]
> > 
> > On Tue, Oct 01, 2002 at 11:30:59AM -0700, Alan wrote:
> > 
> > Turns out the issue was the 'expires' tag... IE wouldn't set the cookie
> > until it was set to '+1d'
> 
> If setting the expires tag to +1d fixed the problem you may want to look
> at the time on the machine running IE. I ran into a problem where the
> clients clock was in the wrong timezone, this of course changed the
> distance from GMT and caused the cookie to be expired as it was sent. IE
> did not accept the cookie at all. However once the time was set
> correctly the cookie worked correctly.

Nope... one of the versions of IE that I was running was on the same
machine (running through crossover office).  

Looks like my little problem really had nothing to do with refreshing
and setting cookies, but it was actually in the way that parsing works in 
Apache::Cookie (and CGI/CGI::Cookie).  When the expires is set to "+3d" 
the cookie is set as follows:

Set-Cookie=name=value; path=/path; expires=Sat, 05-Oct-2002 15:10:06 GMT 

But when it's set to "3d" the cookie is set as:
Set-Cookie=name=value; path=/path; expires=3d 

Which makes sense, but it's a very subtle thing IMHO, and to me "1d"
means "expire in one day", the same as "+1d".

Anything think that this deserves a bug report, or chalk it up to stupid
user syndrome?

Alan

-- 
Alan "Arcterex" <[EMAIL PROTECTED]>   -=][=-   http://arcterex.net
"I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson

Re: cookies and IE

[Alan]

On Tue, Oct 01, 2002 at 07:23:39PM -0400, Kee Hinckley wrote:
> At 11:30 AM -0700 10/1/02, Alan wrote:
> >Hi folks... I'm having a bit of a weird problem with Apache::Cookie and
> >IE.
> >
> >I'm setting a cookie and then doing a redirect as follows:
> 
> This must come up once every few months.  I'd complain about that 
> fact, but the irony is that just last week I couldn't figure out why 
> a new site I was working on wasn't setting cookies in IE and  I'd 
> done the same thing I'd read about a dozen times.
> 
> IE doesn't reliably set cookies on a refresh.  I believe the only 
> solution is to rearchitect the site.

Interesting... on the several browsers/OSs I had it tested on it seemed
to work.  

Anyway, if this is such a common question, who do you talk to to get it
stuck in the perl.apache.org page about cookies? :)

alan

-- 
Alan "Arcterex" <[EMAIL PROTECTED]>   -=][=-   http://arcterex.net
"I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson

Re: cookies and IE

[Alan]

On Tue, Oct 01, 2002 at 11:30:59AM -0700, Alan wrote:
> Hi folks... I'm having a bit of a weird problem with Apache::Cookie and
> IE.
> 
> I'm setting a cookie and then doing a redirect as follows:
> 
> my $c = Apache::Cookie->new( $r,
> -name => 'userdata',
> -value => $cookie,
> -expires => '1d',
> -path => '/dealers'
> );
> 
> $r->content_type('text/html');
> $c->bake;
> $r->header_out("Refresh"=>"0;url=/dealers$request_uri");
> $r->no_cache(1);
> $r->send_http_header;
> $r->print( print_refresh_page_content() );

Turns out the issue was the 'expires' tag... IE wouldn't set the cookie
until it was set to '+1d'

alan

-- 
Alan "Arcterex" <[EMAIL PROTECTED]>   -=][=-   http://arcterex.net
"I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson

cookies and IE

[Alan]

Hi folks... I'm having a bit of a weird problem with Apache::Cookie and
IE.

I'm setting a cookie and then doing a redirect as follows:

my $c = Apache::Cookie->new( $r,
-name => 'userdata',
-value => $cookie,
-expires => '1d',
-path => '/dealers'
);

$r->content_type('text/html');
$c->bake;
$r->header_out("Refresh"=>"0;url=/dealers$request_uri");
$r->no_cache(1);
$r->send_http_header;
$r->print( print_refresh_page_content() );

(print_refresh_page_content() just returns a string of "authenticated")

After the authenticated message is printed it should refresh back to the
/dealers/ URL, except this time the handler will see there is a cookie
and print out the real data, not a username/pass prompt.

This works *perfectly* in mozilla linux, galeon, mozilla windows, and
ie6 under windows XP.  It *doesn't* work on ie 6 under win98, winME, or
ie 5.5 run through crossover office.  It displays the authenticated
page, but then refreshes back to the login page.  No cookie is set, but
debug when setting the cookie shows the following:

Set-Cookie=userdata=[data]; path=/dealers; expires=1d at 
/home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm line 139.
Refresh=0;url=/dealers/ at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm 
line 139.
Pragma=no-cache at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm line 139.
Cache-control=no-cache at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm 
line 139.
Connection=close at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm line 139.
Content-Type=text/html at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm 
line 139.
Expires=Tue, 01 Oct 2002 18:30:31 GMT at 
/home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm line 139.

This is the same that is printed out when a working browser gets cookies
set.

I've played around with the security settings, and even at the lowest
setting, with IE set to prompt for any cookies, it won't even
acknowledge that I'm trying to set a cookie.

Anyone have any ideas/solutions/thoughts?


-- 
Alan "Arcterex" <[EMAIL PROTECTED]>   -=][=-   http://arcterex.net
"I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson

Re: newbie: file uploads not working :(

[Alan]

On Thu, Sep 12, 2002 at 03:24:50PM -0400, Geoffrey Young wrote:
> 
> 
> [snip]
> >
> ># This is a copy of the form code from the snippets page
> >sub form {
> >   use Apache::Request;
> >   my $r = Apache->request();
> >   my $apr = Apache::Request->new($r, DISABLE_UPLOADS => 1);
> 
> I think DISABLE_UPLOADS should be 0, not 1.  I can't find any other 
> obvious errors in what you have...

Yea, caught this just after I sent the email :)

> and see if it helps clarify things.  in particular, you might want to 
> add a call to $apr->parse to see what it returns - that may help you 
> debug things some more.

It returns 0.  I threw the example code from the apache::request parse()
section into sub form and nada.  I'm wondering if it has somthing to do
with my HTML or something?  Is my html-fu doing something stupid?

Thanks

alan

-- 
Alan "Arcterex" <[EMAIL PROTECTED]>   -=][=-   http://arcterex.net
"I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson

Re: newbie: file uploads not working :(

[Alan]

(replying to self in true newbie style)

On Thu, Sep 12, 2002 at 12:08:11PM -0700, Alan wrote:
> # This is a copy of the form code from the snippets page
> sub form {
>use Apache::Request;
>my $r = Apache->request();
>my $apr = Apache::Request->new($r, DISABLE_UPLOADS => 1);

The DISABLE_UPLOADS wasn't actually there, that was a holdover from
testing to try to get *any* response from an upload that I forgot about
when I pasted the code in.  Even if it was in there, it should have
errored out if an upload was attempted right?

alan the sheepish



-- 
Alan "Arcterex" <[EMAIL PROTECTED]>   -=][=-   http://arcterex.net
"I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson

newbie: file uploads not working :(

[Alan]

Hi folks.  I'm new to the list, and relatively new to mod_perl, but a
big project thrown my way put me right in the middle, and I think I've
fared well so far, with one exception... file uploads.  I've based my
code off the apache::request documentation and the file upload code
snippet posted here and on the perl.apache.org site.

I have the following configured:



SetHandler perl-script
PerlHandler Test::Upload
PerlInitHandler Apache::StatINC


My Test/Upload.pm looks something like this:

-
package Test::Upload;
use strict;
use Apache::Constants qw(:common);
use Apache::Log;
use Apache::File();
use Apache::Request;

sub handler {
   my $r = shift;

   my $form = form();

   if (my $file = $form->{UPLOAD})
   {
  my $filelocation="/home/alan/code/test/htdocs/files";
  my $filename = $file->filename; # If you need the name
  open F, ">$filelocation";
  my $filehandle = $file->fh;
  while (my $d = <$filehandle>) 
  {
 print F $d;
  }
  close F;
   }

   $r->content_type('text/html');
   $r->send_http_header;
   print <

Upload a file:  

END

   return OK;
}

1;

# This is a copy of the form code from the snippets page
sub form {
   use Apache::Request;
   my $r = Apache->request();
   my $apr = Apache::Request->new($r, DISABLE_UPLOADS => 1);
   my @keys = $apr->param;

   my %form;
   foreach my $key(@keys) {

  my @value = $apr->param($key);
  next unless scalar @value;

  if ( @value > 1 ) {
 $form{$key} = \@value;
  } else {
 $form{$key} = $value[0];
  }
   }

   my $upload = $apr->upload;
   if ($upload) {
  $form{UPLOAD} = $upload;
   }

   return \%form;
}

-

As far as I can tell, the code should see the upload, grab the upload
via $apr->upload, and use it.  However, nothing happens. 

Even if I put in copious debug (for example, code that prints out when
if($upload){ } is hit), nothing.  It's as if the upload is not taking
place at all.

Can anyone give me a hand with this, I'm literally beating my head
against the table!

TIA

Alan

-- 
Alan "Arcterex" <[EMAIL PROTECTED]>   -=][=-   http://arcterex.net
"I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson

Re: #perl SSI directive not recognised

[Alan Burlison]

Doug MacEachern wrote:

> >  I want Apache to switch into a
> > resource-managed Project at startup, but to do so I need to find out the
> > value of the "User" parameter in httpd.conf, and I can't find a way to do
> > this - is there one?
> 
> Apache::Server::uid returns the uid of the configured User.
> you can access via:
> Apache->server->uid at startup time
> or
> $r->server->uid at request time

Brilliant - works a treat.  Thanks :-)

-- 
Alan Burlison
--
$ head -1 /dev/bollocks
initiate customer-directed OEMs

Re: #perl SSI directive not recognised

[Alan Burlison]

Doug MacEachern wrote:
 
> the #perl directive is disabled if modperl is built as dso, Makefile.PL
> prints a message about this.  won't be an issue with 2.0 thanks to apr
> optional functions.  but in 1.x, the modperl .so cannot resolve symbols
> from mod_include.so.  at least, it can't on all platforms and can't if one
> were to disable LoadModule of mod_include.so

Thanks Doug.  I'm using the Apache/perl/mod_perl that will ship as part of
Solaris 9, so I was a little concerned that we'd screwed something up :-)

>From your description, I'm guessing that the root cause of this that that
two dlopen'ed shared objects need to be able to cross-call each other,
correct?  This might not be of much use if you already have a fix for 2.0,
but I have a little trick which makes this work on Solaris, at least.  You
stick the following in the call to WriteMakefile in Makefile.PL

dynamic_lib  => { OTHERLDFLAGS =>
'-h $(DLBASE).$(DLEXT) ' .
'-R\$$ORIGIN/.. $(INST_ARCHAUTODIR)/../OtherModule.so'
},

The '-h' establishes a location-independent name for the XSUB you are
currently building.  The '-R' establishes a runpath to search for the
other .so that you want to link against, and the MyOtherModule.so bit says
where to find the other .so, relative to the obe you are currently
building.  Here is a bit more info from a  Makefile.PL where I actually
use this trick:

# The various .so files that comprise this module need to be able to
# cross-call each other, and therefore to prevent runtime linker errors it
is
# necessary to establish linker dependencies between the various .so
files.
#
# This causes several problems.  The first of these is that perl .so files
are
# built in one directory (under ../blib in this case) and installed into
# another, so it is necessary to record the dependency using a path
relative to
# the dependent. This can be done with the $ORIGIN linker mechanism.
#
# The second problem is that it is necessary to specify the name of the
# dependee at link edit time in a manner that doesn't result in the
build-time
# path of the dependee being hard coded in to the dependent, as this would
# stop ld.so.1 performing its normal search process for the files.  This
can't
# be done with the normal '--L/my/lib/path -lmylib' mechanism, because the
XSUB
# .so files aren't prefixed with 'lib'.  To do this the -h linker flag is
used
# to explicitly set the SONAME in the dependee.  This is then used as the
name
# of the dependent in the dependee rather than the full path by which it
was
# found at link edit time.

The appropriate bits of a 'dump -Lv of the resulting .so file are:

[INDEX] Tag Value
[1] NEEDED  OtherModule.so  <-- Dependency
[4] SONAME  ThisModule.so   <-- Name of this module
[5] RUNPATH $ORIGIN/..  <-- Where to search
[6] RPATH   $ORIGIN/..

Hope this might help somebody sometime - it may be possible to pull a
similar stunt on other platforms.

Alan Burlison

#perl SSI directive not recognised

[Alan Burlison]

I'm sure this is a FAQ, but I can't find it anywhere, and the mail
archives seem to be down.

I am trying to get the following SSI directive to work:



and I get the following error in the server log:

unknown directive "perl" in parsed doc /var/apache/htdocs/index.html

I know that I have SSI set up OK because if I replace the above with



I see the date as expected.  The /perl-status pages show that the MySSI
module is loaded, and that the PerlSSI directive is enabled.  I've
carefully read through the example in the eagle book, and I can't spot
what is wrong.  Can someone spare me a clue?

Thanks,

-- 
Alan Burlison
--
$ head -1 /dev/bollocks
risk manage three-tier high-volume price performance

Re: Berkeley DB 4.0.14 not releasing lockers under mod_perl

[Michael Alan Dorman]

Perrin Harkins <[EMAIL PROTECTED]> writes:
> This sort of begs the question: why not use DB 3.x?  Is there some new
> feature you need in DB 4?

Anecdotaly, I believe the OpenLDAP and Cyrus projects have both found
DB4 to be more reliable under load than DB3.

Mike.

Re: [WOT] emacs and WEBDAV

[Michael Alan Dorman]

"Rob Bloodgood" <[EMAIL PROTECTED]> writes:
> DW also speaks WEBDAV natively, but emacs does not.

Not natively, but there is a DAV mode for emacs, apparently fairly
new.  From the Debian package:

Package: eldav
Priority: optional
Section: net
Installed-Size: 61
Maintainer: Fumitoshi UKAI <[EMAIL PROTECTED]>
Architecture: all
Version: 0.0.20020311-1
Depends: emacs21 | emacsen, nd (>= 0.5.0)
Filename: pool/main/e/eldav/eldav_0.0.20020311-1_all.deb
Size: 14286
MD5sum: 71271d5d4998dcdb78f83d79e98a4f75
Description: an interface to the WebDAV servers for Emacs.
 WebDAV files can be treated just like a normal file in Emacsen.
 Emacs/w3 is not required. External program is used for WebDAV access.

Re: testing server response time

[Alan Raetz]

Perrin,

> You want something more like this:
> 
>  Alias /perl-bin/ "c:/IndigoPerl//perl-bin/"
>  PerlModule Apache::Registry
>  
>SetHandler perl-script
>PerlHandler Apache::Registry
>Options ExecCGI
>  

Yup, this gets it working (It does need the line 
"LoadModule perl_module modules/mod_perl.so").
The response time for the one-liner script is 
reduced by a 10x factor after the first request,
according to my test script. The conf snippet I 
gave you was somehow corrupted when I copied it, 
but just to make sure, I reinstalled indigoperl 
from scratch, and the conf file from the original 
install does not work; "PerlModule Apache::Registry"
is not declared, and it uses "ScriptAlias /perl-bin/"
instead of "Alias /perl-bin/" and I verified that 
both of these lines cause problems. 

IndigoStar says that the server comes with mod_perl
enabled by default, and so I just assumed those
lines were correct. You saved me a lot of time,
thanks! I'll email IndigoStar this info...

-alan




__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

Re: testing server response time

[Alan Raetz]

Perrin,

Thanks for the response,

--- Perrin Harkins <[EMAIL PROTECTED]> wrote:
> No offense, but your script must not have been doing
> much in this test.
> The difference between putting everything in one
> script vs. using
> modules is just the time it takes to open and read
> the files.  It's a
> tiny difference in most cases.  

I was also thinking it would only make a small
difference, but I see many perl/CGI scripts that boast
'all this functionality in a single script' as 
if multiple module was some sort of huge performance 
hit. My app has 13 separate modules, so I tried to 
test it. I'm sure both version had 
the same code, because they both worked fine. It's 
about 4000 lines of perl code (with CGI_Lite built 
in). So I was surprised it made such a big difference,
as well. You can see a demo of the app at 
http://chicodigital.com/demo.html

> 
> There could be a problem in your config.  How about
> posting the part you
> changed to enable mod_perl?

This is the lines in C:\indigoperl\conf\httpd.conf.
I either commented out and restarted the server to 
disable, or uncommented, stopped apache and restarted 
to enable:

# BEGIN MOD_PERL CONFIG
#LoadModule perl_module modules/mod_perl.so
#ScriptAlias /perl-bin/ "c:/IndigoPerl//perl-bin/"
#PerlSendHeader On
#SetHandler perl-script
#Options ExecCGI
#
# END MOD_PERL CONFIG

The application under test runs fine in either case.

thanks again,

-alan






__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

testing server response time

[Alan Raetz]

I was trying to test the CGI response time of a
Perl/CGI script under two conditions: as multiple
modules versus a single big script. First I installed
IndigoPerl (from indigostar.com) on my Windows machine
(which has an integrated apache server with mod_perl
enabled by default). Then I ran this script locally
against the local server:

#!/usr/local/bin/perl

use strict;

use LWP::Simple;
use Time::HiRes;

my $script = $ARGV[0];

my $totalTime = 0;

my $i; for ($i=0; $i < 20; $i++) {

 my $before = Time::HiRes::gettimeofday();

 if ( $script eq 'big' ) {

  print "Running big: ";

  if ( !defined( my $content =
  
LWP::Simple::get('http://localhost/cgi-bin/bigtool.cgi')))
{
  print "failed get\n";
  }

 } else {

  if ( !defined( my $content =
  
LWP::Simple::get('http://localhost/cgi-bin/webtool.cgi')))
{
  print "failed get\n"; }

 }

 my $elapsed = Time::HiRes::gettimeofday() -
$before;

 print "did $i in $elapsed seconds.\n";

 $totalTime = $totalTime + $elapsed;
}

$totalTime = $totalTime / 20;

print "Average response time for 20 requests was:
$totalTime seconds.\n";

 end of script #

After I set up my app (webtool.cgi) and created the
single script version (bigtool.cgi), I ran this script
on my machine and it showed that the single file was
about 10-15% faster than the multiple modules.

My first question is, is the above script a valid test
of CGI response time? So, for example, should the
results reflect any improvements with mod_perl
enabled? Because what I found is that the response
time differed 
less than 5% between mod_perl-enabled and mod_perl
disabled configurations.

The CGI application I'm testing this on is about 4,100
lines of Perl, and 114k bytes.

I emailed support@indigostar, but it's been over two
days and no reply yet. I figure I'd just throw this
out
there for feedback. From other postings, it seems like
Windows mod_perl works great, and I should see a
significant speed-up.

btw, I'm running Windows 98 SE on a 500 MHz machine.

Here's another test I did: I ran my test script
remotely against my local IndigoPerl server
from my remote unix account on sourceforge (because
I thought maybe an interaction between the test
script and the server running on the same machine).
Basically, it shows the same results: enabling
mod_perl only improves performance about 0-5%. I
even tried this timing test against the simple
one-line
'hellocgi.pl' script that came with IndigoPerl, and
it's response is also similar with or without mod_perl
(0.47 sec versus 0.54 seconds).

Here's the thing I discoved in doing this though: when
mod_perl is enabled, the disk indicator on my machine
does not blink on when running the remote test script;
with mod_perl disabled, the light blinks! So this 
would indicate that mod_perl is getting enabled
and is 'working', not going to disk for requests...
unfortunately, it doesn't seem to improve the overall
response time much.

Comments? I'm certainly hoping that either this isn't
a valid test, or that IndigoPerl is just broken...

-alan


__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

Apache and Perl togheter

[Alan Civita]

Surely...
and I've done all of it...
..have i to use sonme particular option during the 
configuration and installation of apache in order to 
use/enable the perl in Apache?
thx again

Apache and Perl togheter

[Alan Civita]

is it possible that i have to do something special 
in compiling apache to activate the perl mode?

Apache and Perl togheter

[Alan Civita]

Hello can some help me pelase?
i've recently installed Apace 1.3.22...i've configured the 
CGI directive to work as well
but when i try to execute a CGI script written in perl 
that message appears:

Internal Server Error
The server encountered an internal error or 
misconfiguration and was unable to complete your request.
Please contact the server administrator, 
[EMAIL PROTECTED] and inform them of the time the error 
occurred, and anything you might have done that may have 
caused the error.
More information about this error may be available in the 
server error log

The CGI script is a stupid test " hello world" CGI script 
...

Script written in sh script work.
Can someone solve my problem please...
Thx to all
Alan

Apache ASP help not helpful. I'm not alone

[alan matthews]

I've just seen a pile of posts on a Yahoo board full
of people with ASP problems.

__
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music 
Charts
http://uk.my.yahoo.com

Apache ASP help not helpfull :(

[alan matthews]

After twenty years in hardware and real-time
programming,
I'm back at university getting into business
computing, so I'm very new to this server stuff and
I'm trying to learn.

I wanted to run a local server but Microsoft PWS
doesn't run on Win ME. Searching around I came across
this http://www.ricocheting.com/sever/index.html I
found it very helpful, albeit a bit out of date.
  
So, I've installed apache_1.3.22-win32-x86.msi onto
this Win ME machine as a localhost and it works fine.

I've installed ActivePerl, and it works fine too.

I want to run ASP, so I download Apache-ASP-2.29

Then as per the instructions I did
___
 shell prompt> perl -MCPAN -e shell
 ...
 cpan> install Bundle::Apache::ASP
___

A huge amount of text flowed down the screen which
ended with
___
Removing previously used
\.cpan\build\Apache-ASP-2.29\.
Couldn't find \.cpan\build\Apache-ASP-2.29\. at
C:/Perl/lib/CPAN.pm line 1972
___

I tried to run some of Perl's sample asp pages but
nothing worked. Clealy the phrase:-

'The easiest way to install Apache::ASP for the first
time from perl is to fire up the CPAN shell like:'

isn't quite as easy as it claims.

The rest of the information at
http://www.nodeworks.com/asp/install.html
is unitelligable to anyone who hasn't worked with
servers, and all the FAQ's seem to assume your an
expert, so I'm no better off.

The main confusion I'm getting is figuring which is
Perl stuff from Apache. Also links like:-
___
There are several other Perl modules that you might
wish to have installed, to take full advantage of
mod_perl functionality. Provided you have Andreas
König's CPAN.pm module, simply run:
___

is just a long list of meaningles files. 

So, is there any chance of an Idiot's guide to getting
this ASP to work?

Python

__
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music 
Charts
http://uk.my.yahoo.com

Re: Children dying

[Alan Burlison]

Stas Bekman wrote:

> > > No need for an apology :-) The trick is to build perl using the
> > > Solaris malloc (-Dusemymalloc as a flag to Configure), then apache,
> > > mod_perl and perl all agree on who manages memory.
> >
> > Might I suggest that this golden piece of information find it's way into the
> > guide?  It's so rare to see a DEFINITIVE answer to one of the many ("YMMV!"
> > :-)exceptions to the vanilla mod_perl build process.
> 
> The definitive answer is there for at least 2 years: "If in doubt compile
> statically", which covers Solaris as well. Why having a special case?

So what is the point of having DSO at all then?

The question was 'How do I build on Solaris with DSO?', the answer was
'Build perl to use the system malloc', I don't see what the problem with
that is.

-- 
Alan Burlison
--
$ head -1 /dev/bollocks
repurpose collaborative focus groups, going forwards

Re: Children dying

[Alan Burlison]

Andrew Ho wrote:

> AB>Untrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine.
> 
> I apologize. Let me qualify my original statement. In general, you want to
> compile mod_perl statically on Solaris 2.6 or 2.7 because in many
> instances, it core dumps when built as a DSO. FWIW, my particular
> experiences were with Perl 5.005_03 and 5.6.0, mod_perl 1.24 and 1.25, and
> Apache 1.3.12, 1.3.14, 1.3.17, and 1.3.19 under Solaris 2.6 (both Sparc
> and Intel) and 2.7 (Intel only).

No need for an apology :-)  The trick is to build perl using the Solaris
malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and
perl all agree on who manages memory.

> Humbly,

And no need for that either! :-)

Regards,

-- 
Alan Burlison
--
$ head -1 /dev/bollocks
drive proximal infomediaries, going forwards

Re: Children dying

[Alan Burlison]

"Vasily S. Petrushin" wrote:

> > Untrue.  We ship mod_perl in Solaris 8 as a DSO, and it works fine.
> 
> Fine, point us please to documentation how to do it.

http://cpan.valueclick.com/authors/Doug_MacEachern/mod_perl-1.26.tar.gz

Alan Burlison

Re: Children dying

[Alan Burlison]

Andrew Ho wrote:

> A few other folks have given useful references on how to get stack traces,
> as well as some other common causes of core dumps (compiling Apache with
> its bundled expat is a big one). Here's another one--did you build
> mod_perl on Solaris as a DSO? In general, you want to compile mod_perl
> statically on Solaris because it will core otherwise.

Untrue.  We ship mod_perl in Solaris 8 as a DSO, and it works fine.

Alan Burlison

Re: compiling troubles on Solaris 8

[Alan Burlison]

Geoffrey Young wrote:

> > As an aside, Solaris 8 comes with prebuilt versions of Apache
> > and mod_perl,
> 
> does anyone familiar with HP-UX, AIX, or IRIX know whether this is true of
> these platforms as well?
> 
> Whether they are DSO mod_perl or not would also be helpful.

On Solaris it is built as a DSO.

-- 
Alan Burlison
Solaris Kernel Development, Sun Microsystems

Re: compiling troubles on Solaris 8

[Alan Burlison]

Ged Haywood wrote:

> Well OK, read "What Compiler Should Be Used to Build mod_perl?" in the
> "install" section of Stas' new book if you want to use different compilers
> - but don't say I didn't warn you!  :)

By all means, please feel free to buy our compiler.

Alan Burlison

Re: compiling troubles on Solaris 8

[Alan Burlison]

> > > When I first started, it did not seem to be using gcc, so I renamed
> > > /usr/ucb/cc to cc.default, and make /usr/ucb/cc a link to gcc.

Please don't do that - switch it back and just make sure gcc is somewhere on
your path.

> Please note that the same compiler must be used to build Perl and mod_perl,

Not so.  gcc should work just fine.  The problem is that when perl is
configured and built, it saves the compiler name and flags in Config.pm.  We
build Solaris with the Workshop compilers, and therefore subsequent attempts
to build modules (e.g. mod_perl) also try to use the same compiler.  A
workaround is to modify /usr/perl5/5.00503/sun4-solaris/Config.pm so it
contains the correct information (flags etc) for gcc rather than Workshop. 
I've attached a sample Config.pm that should work with the copy of gcc that
is shipped on the Solaris 8 companion cd.  I suggest you move the standard
Config.pm somewhere safe and use the attached file in its place.  There are
only 4 differences between it and the standard Config.pm.

I'm working on something a little cleaner for Solaris 9, probably requiring
you to set PERL5LIB to point perl to a gcc-ized version of Config.pm, rather
than the standard one.

As an aside, Solaris 8 comes with prebuilt versions of Apache and mod_perl,
so unless you need the latest and greatest you might find it easiest to use
the bundled versions - see 'man apache' for details. 

Alan Burlison
Solaris Kernel Development, Sun Microsystems
 Config.pm.gz

Re: Problems building Bundle::Apache - libapreq-0.33

[Alan Burlison]

Stas Bekman wrote:

> > Here is the output of 'make install'
> 
> I don't think it logs the install of these headers. Please check the
> created Makefile. Does it include the mod_perl.h in one of the targets?

No.

Alan Burlison

Re: Problems building Bundle::Apache - libapreq-0.33

[Alan Burlison]

Stas Bekman wrote:

> Looks like an issue with APACHE_HEADER_INSTALL
> http://perl.apache.org/guide/install.html#APACHE_HEADER_INSTALL
> 
> Did you install mod_perl by yourself?

Yes, as my attempt to build it as part of Bundle::Apache barfed.

Here is the contents of my makepl_args.mod_perl:

APACHE_SRC=/home1/software/apache/build/apache_1.3.20/src
EVERYTHING=1
USE_APXS=1
WITH_APXS=/home1/web/apache_1.3.20/bin/apxs

Here is the output of 'make install'

$ make install
(cd ./apaci && PERL5LIB=/home1/software/perl/cpan/build/mod_perl-1.26/lib
/usr/ccs/bin/make)
Files found in blib/arch: installing files in blib/lib into architecture
dependent library tree
Installing /usr/perl5/5.6.1/man/man3/Apache::PerlRunXS.3
Installing /usr/perl5/5.6.1/man/man3/Apache.3
Installing /usr/perl5/5.6.1/man/man3/Apache::Log.3
Installing /usr/perl5/5.6.1/man/man3/Apache::Constants.3
Installing /usr/perl5/5.6.1/man/man3/Apache::File.3
Installing /usr/perl5/5.6.1/man/man3/Apache::URI.3
Installing /usr/perl5/5.6.1/man/man3/Apache::Table.3
Installing /usr/perl5/5.6.1/man/man3/Apache::Util.3
Installing /usr/perl5/5.6.1/man/man3/Apache::Symbol.3
Installing /usr/perl5/5.6.1/man/man3/Apache::Leak.3
Installing /usr/perl5/5.6.1/man/man3/mod_perl_cvs.3
Installing /usr/perl5/5.6.1/man/man3/Apache::Registry.3
Installing /usr/perl5/5.6.1/man/man3/Apache::SizeLimit.3
Installing /usr/perl5/5.6.1/man/man3/cgi_to_mod_perl.3
Installing /usr/perl5/5.6.1/man/man3/Apache::Resource.3
Installing /usr/perl5/5.6.1/man/man3/Apache::PerlSections.3
Installing /usr/perl5/5.6.1/man/man3/Apache::PerlRun.3
Installing /usr/perl5/5.6.1/man/man3/Apache::Debug.3
Installing /usr/perl5/5.6.1/man/man3/Apache::Symdump.3
Installing /usr/perl5/5.6.1/man/man3/mod_perl_tuning.3
Installing /usr/perl5/5.6.1/man/man3/Apache::Status.3
Installing /usr/perl5/5.6.1/man/man3/Apache::RedirectLogFix.3
Installing /usr/perl5/5.6.1/man/man3/Apache::ExtUtils.3
Installing /usr/perl5/5.6.1/man/man3/Apache::Include.3
Installing /usr/perl5/5.6.1/man/man3/mod_perl_method_handlers.3
Installing /usr/perl5/5.6.1/man/man3/Apache::StatINC.3
Installing /usr/perl5/5.6.1/man/man3/Apache::test.3
Installing /usr/perl5/5.6.1/man/man3/Apache::RegistryLoader.3
Installing /usr/perl5/5.6.1/man/man3/Apache::httpd_conf.3
Installing /usr/perl5/5.6.1/man/man3/Apache::FakeRequest.3
Installing /usr/perl5/5.6.1/man/man3/mod_perl.3
Installing /usr/perl5/5.6.1/man/man3/mod_perl_traps.3
Installing /usr/perl5/5.6.1/man/man3/Apache::src.3
Installing /usr/perl5/5.6.1/man/man3/Apache::SIG.3
Installing /usr/perl5/5.6.1/man/man3/Bundle::Apache.3
Installing /usr/perl5/5.6.1/man/man3/Apache::Options.3
Writing
/usr/perl5/site_perl/5.6.1/sun4-solaris-64int/auto/mod_perl/.packlist
(cd ./apaci && /usr/ccs/bin/make install;)
/home1/web/apache_1.3.20/bin/apxs -i -a -n perl libperl.so
[activating module `perl' in /home1/web/apache_1.3.20/conf/httpd.conf]
cp libperl.so /home1/web/apache_1.3.20/libexec/libperl.so
chmod 755 /home1/web/apache_1.3.20/libexec/libperl.so
cp /home1/web/apache_1.3.20/conf/httpd.conf
/home1/web/apache_1.3.20/conf/httpd.conf.bak
cp /home1/web/apache_1.3.20/conf/httpd.conf.new
/home1/web/apache_1.3.20/conf/httpd.conf
rm /home1/web/apache_1.3.20/conf/httpd.conf.new
Appending installation info to
/usr/perl5/5.6.1/lib/sun4-solaris-64int/perllocal.pod

No header files installed.

Alan Burlison

Re: Problems building Bundle::Apache - libapreq-0.33

[Alan Burlison]

Jens-Uwe Mager wrote:

> Did you make install modperl yet?

Yes, via APXS.  mod_perl is installed and works just fine.  I can see the
missing mod_perl.h file in the modperl build directory, but it doesn't
appear anywhere under site_perl - should mod_perl copy it somewhere during
'make install'?  I'm using a slightly non-standard perl layout, so instead
of being under /usr/local perl lives under /usr/perl5.  From looking at
where stuff generally goes, and the -I flags used when building libapreq I
guess mod_perl.h should be somewhere under
/usr/perl5/site_perl/5.6.1/sun4-solaris-64int/auto/Apache, but it isn't
there.

Alan Burlison

Problems building Bundle::Apache - libapreq-0.33

[Alan Burlison]

I'm trying to build Bundle::Apache and I get the following error when
building libapreq (everthing else in the bundle builds fine):

cc -c -I../c
-I/usr/perl5/site_perl/5.6.1/sun4-solaris-64int/auto/Apache/include
-I/usr/perl5/site_perl/5.6.1/sun4-solaris-64int/auto/Apache/include/include
-I/usr/perl5/site_perl/5.6.1/sun4-solaris-64int/auto/Apache/include/regex
-I/usr/perl5/site_perl/5.6.1/sun4-solaris-64int/auto/Apache/include/os/unix
-I/home1/web/apache_1.3.20/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -xO3 -xdepend-DVERSION=\"0.33\" 
-DXS_VERSION=\"0.33\" -KPIC -I/usr/perl5/5.6.1/lib/sun4-solaris-64int/CORE 
Request.c
"Request.xs", line 40: cannot find include file: "mod_perl.h"
"Request.xs", line 86: syntax error before or at: SV
"Request.xs", line 86: cannot recover from previous errors
cc: acomp failed for Request.c

The platform is Solaris, Perl 5.6.1 and Apache 1.3.20.  Everything else is
the latest available from CPAN.  The INSTALL file is less than helpful, and
a search of the modperl archives didn't find anything.

Anyone have any suggestions?

thanks,

Alan Burlison

Re: Apache::AuthDBI

[Alan E. Derhaag]

"Christian Heiss" <[EMAIL PROTECTED]> writes:

> [1  ]
> Hi,
> 
> I'm using Apache::AuthDBI to verifying the users on my web site.
> 
> 
> 
> I can connect to the the protected site, but there is a output in the error log:
> 
> 
>
> >Use of uninitialized value at /usr/lib/perl5/site_perl/5.005/Apache/AuthDBI.pm line 
>450
> >Use of uninitialized value at /usr/lib/perl5/site_perl/5.005/Apache/AuthDBI.pm line 
>480
> >Use of uninitialized value at /usr/lib/perl5/site_perl/5.005/Apache/AuthDBI.pm line 
>481

[...]

> then I put it in the database with:
> 
>
> >my $sql = "INSERT INTO  VALUES($userid, $groupid, $pass, ...);
> of course, before I'm using the quote funktion ($dbh->quote($userid)...)...

What database manager allows SQL without supplying the fields the
values go into?

Re: Installation issue

[alan arbizu]

Hmm.. i just got it to build ok on RH 7.0.. 
I'll see if I can just use those binaries...

oh.. i did forget to mention the 6.1 box was an SMP kernel.
Not sure if that could be an issue, but thought it could be
important

/a

alan arbizu wrote:
> 
> Hi folks...
> 
> I've got an issue here that all the rtfm'ing on my part has not
> been able to resolve :/
> 
> Here's the setup
> 
> RH 6.1
> Apache 1.3.19
> mod_ssl 2.8.1
> mod_perl 1.25
> php 4.0.4pl1
> 
> building all from source
> 
> So...
> 
> I first configured mod_ssl by pointing it at the apache source...
> Then I configured mod_perl similarly and had it build apache for me.
> After apache was built/installed, I compiled/installed php4
> independently.
> 
> Now... the only way i've been able to start apache is to uncomment
> the Load Module/Add Module directives for mod_perl in the
> httpd.conf file. PHP and SSL seem to coexist fine.  But if I try
> to enable mod_perl the httpd process exits without spawning the
> specified number of apache processes.
> 
> I tried to debug it, but gdb shows pretty much the same thing:
> 
> $gdb httpd
> GNU gdb 4.18
> 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"...
> (gdb) break main
> Breakpoint 1 at 0x8061312
> (gdb) run
> Starting program: /usr/sbin/httpd
> 
> Breakpoint 1, 0x8061312 in main ()
> (gdb) n
> Single stepping until exit from function main,
> which has no line number information.
> 
> Program exited normally.
> (gdb)
> 
> Any ideas?
> 
> no core file, no nothing :(
> 
> thanks in advance for any ideas/tips
> 
> /a
> 
> --
> Alan E. Arbizu / http://www.arbizu.org
> SW Design Engineer, CSO-eCSL
> Hewlett-Packard
> Cupertino, CA, 47L/J6-L6
> TN-447-0240

--
Alan E. Arbizu / http://www.arbizu.org
SW Design Engineer, CSO-eCSL
Hewlett-Packard
Cupertino, CA, 47L/J6-L6
TN-447-0240

Installation issue

[alan arbizu]

Hi folks...

I've got an issue here that all the rtfm'ing on my part has not
been able to resolve :/

Here's the setup

RH 6.1
Apache 1.3.19
mod_ssl 2.8.1
mod_perl 1.25
php 4.0.4pl1

building all from source

So...

I first configured mod_ssl by pointing it at the apache source... 
Then I configured mod_perl similarly and had it build apache for me.
After apache was built/installed, I compiled/installed php4 
independently.

Now... the only way i've been able to start apache is to uncomment
the Load Module/Add Module directives for mod_perl in the
httpd.conf file. PHP and SSL seem to coexist fine.  But if I try
to enable mod_perl the httpd process exits without spawning the
specified number of apache processes. 


I tried to debug it, but gdb shows pretty much the same thing:

$gdb httpd
GNU gdb 4.18
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"...
(gdb) break main
Breakpoint 1 at 0x8061312
(gdb) run
Starting program: /usr/sbin/httpd 

Breakpoint 1, 0x8061312 in main ()
(gdb) n
Single stepping until exit from function main, 
which has no line number information.

Program exited normally.
(gdb) 


Any ideas?

no core file, no nothing :(

thanks in advance for any ideas/tips

/a

--
Alan E. Arbizu / http://www.arbizu.org
SW Design Engineer, CSO-eCSL
Hewlett-Packard
Cupertino, CA, 47L/J6-L6
TN-447-0240

Re: Can AxKit be used as a Template Engine?

[Michael Alan Dorman]

Matt Sergeant <[EMAIL PROTECTED]> writes:
> It depends a *lot* on the type of content on your site. The above
> www.dorado.com is brochureware, so it's not likely to need to be
> re-styled for lighter browsers, or WebTV, or WAP, or... etc. So your
> content (I'm guessing) is pure HTML, with Mason used as a fancy way
> to do SSI, with Mason components for the title bars/menus, and so
> on. (feel free to correct me if I'm wrong).

It is more sophisticated than that, but you're basically right.  I do
pull some tagset-like tricks for individual pages, so it's not totally
pure HTML, but yeah, if we wanted to do WebTV we'd be fscked.

> AxKit is just as capable of doing that sort of thing, but where it
> really shines is to provide the same content in different ways,
> because you can turn the XML based content into HTML, or WebTV HTML,
> or WML, or PDF, etc.

Ah---well a web site that does all of that isn't what first comes to
mind when someone talkes about doing a "static site"---though now that
you've explained further, I believe I understand exactly what you
intended.

> I talk about how the current Perl templating solutions (including
> Mason) aren't suited to this kind of re-styling in my AxKit talk,
> which I'm giving at the Perl conference, so go there and come see
> the talk :-)

Heh.  I agree entirely with this assesment---I can conceptualize a way
to do it in Mason, but the processing overhead would be unfortunate,
the amount of handwaving involved would be enormous, and it would
probably be rather fragile.

> So I take back that people wouldn't be using Mason for static
> content. I was just trying to find a simple way to classify these
> tools, and to some people (I'd say most people), Mason is more on
> the dynamic content side of things, and AxKit is more on the static
> content side of things, but both tools can be used for both types of
> content.
> 
> (I hate getting into these things - I wish I'd never brought up
> Mason or EmbPerl)

Well I will say that you made an excellent point that hadn't really
occured to me---I use XML + XSL for a lot of stuff (the DTD I use for
my resume is a deeply reworked version of one I believe you had posted
at one time), but not web sites, in part because I'm not currently
obligated to worry about "other devices"---so I don't exactly regret
getting you to clarify things.

Could I suggest that a better tagline would be that AxKit is superior
when creating easily (re-)targetable sites with mostly static content?
It might stave off more ignorant comments.

Mike.

Re: Can AxKit be used as a Template Engine?

[Michael Alan Dorman]

Matt Sergeant <[EMAIL PROTECTED]> writes:
> The one thing I think AxKit does really well, that other
> "templating" solutions aren't really designed for, is allowing you
> to build your whole web site with that solution. So for example,
> Mason and EmbPerl are really great for building the dynamic parts of
> your site, whereas (I imagine, from experience) people will build
> the more static parts of their site with just plain HTML.

If they are doing that with Mason, they're making a _BIG_ mistake, as
you are in suggesting it's not well suited for doing static sites.

> Whereas with AxKit the XML + Stylesheets approach applies much more
> broadly to the whole site.

Errr, respectfully, I think you underestimate Mason's capabilities.

www.dorado.com/ is the website for the company I do most of my
contracting with, built entirely in Mason, and it's almost totally
static content, but we make extensive---almost exclusive---use of
Mason's autohandler capabilities coupled with Mason's "object
oriented" features to divorce individual pages from the overall
presentation.

As a result we were recently able to give the entire site a makeover
in roughly three days from start to finish, because it's designed to
largely separate content from templating.  We had to change almost no
individual page files, just the autohandler (read: template) that
handles the site, plus tweaking the names of some rollover graphics.

No more work than redoing the XPathScript and tweaking your taglibs,
really.

> Now I'm probably going to get replies to this saying how EmbPerl and
> Mason and (insert other solution) can do this. And I'm sure they
> can. I just think it's more natural with AxKit.

Well, you did write AxKit---I'd hope it'd be natural. :-)

I've looked at AxKit a lot, and I think it's a great tool that I want
to use---now that there's a Debian package so I don't have to do the
work to get it installed.  The next static site I do for myself, I'll
probably try out AxKit---though I just admit that I'd like to see XSLT
support, too---but I also think you do Mason a disservice.

I will make the caveat that I think I've been using Mason for three
years now---almost since it's first public release---and I've built
many a static web site with it.  I've even got a site that uses XSLT
to do transforms of XML files which are then handed off to Mason.

Mike.

Re: deprecated our() indicated in perldoc of Getopt::Std

[Alan E. Derhaag]

Paul Johnson <[EMAIL PROTECTED]> writes:

> On Fri, Apr 20, 2001 at 02:36:32PM -0700, Alan E. Derhaag wrote:
> > I upgraded to v5.6.1 of perl and viewed the documentation for the
> > Getopt::Std as I wasn't familiar with its use for command line
> > arguments on a new install function I was building.  The docs indicate
> > use of our( $opt_foo, $opt_bar ) should 'use strict vars' be in use.
> > I wasn't familiar with this deprecated version of global variable
> > definitions but I used it..  much to my chagrin when the install was
> > actually performed on a perl v5.05003 equipped machine.
> 
> This hasn't got much to do with modperl, but 

Oops, quite right..  it was from a helper function to install on a
modperl server machine..

> 
> You installed 5.6.1, read the docs, used "our" and found it didn't work
> on 5.00503, right?
> 
> That's because it's new with 5.6.  From where did you get the idea that
> it is deprecated?  Quite the opposite is the case.

Could have fooled me!  I thought it was a term I'd never learned..
especially since the perl 5.00503 execution indicated that it was
deprecated with:

Use of reserved word "our" is deprecated at /tmp/initcatsrch.pl line
26.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Alan E. Derhaag   N2H2, Creators of Bess and Searchopolis
phone: 206-336-2972 900 Fourth Avenue, Suite 3600
email: [EMAIL PROTECTED],[EMAIL PROTECTED]Seattle, WA 98164
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

deprecated our() indicated in perldoc of Getopt::Std

[Alan E. Derhaag]

I upgraded to v5.6.1 of perl and viewed the documentation for the
Getopt::Std as I wasn't familiar with its use for command line
arguments on a new install function I was building.  The docs indicate
use of our( $opt_foo, $opt_bar ) should 'use strict vars' be in use.
I wasn't familiar with this deprecated version of global variable
definitions but I used it..  much to my chagrin when the install was
actually performed on a perl v5.05003 equipped machine.

How did an older version of Getopt::Std get installed with a later
version of perl?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Alan E. Derhaag   N2H2, Creators of Bess and Searchopolis
phone: 206-336-2972 900 Fourth Avenue, Suite 3600
email: [EMAIL PROTECTED],[EMAIL PROTECTED]Seattle, WA 98164
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

RE: Translation handler continuous loop problem

[Sinclair, Alan (CORP, GEAccess)]

This is a repost because my earlier message from this morning bounced. Since
then I feel we have located the source of the problem. It looks like there
is a most bizarre interaction between Netscape clients and the proxy server.
Netscape was configured with manual proxy settings identifying the web
server with Apache/mod_perl.  Once this was done, Netscape is able to
successfully connect to Apache/mod_perl with no more continuous loops!!  I
don't know the whys or hows.


The following text is a copy of what I posted this morning.

Thanks for the example. I inserted the statement "return DECLINED unless
$r->is_initial_req;"  but the handler still enters a continuous loop.  I
also stripped out my code and tried the example from Doug's module book with
debug statements but still a continuous loop. The problem is bizarre. It
only enters the loop for a URL like http://lions/sp9/whatever  Any other URL
such as http://lions/here/there works fine. I wrote the original handler to
extract a session id from a URL with sp9 in the path but now there is no
reference. I have checked my httpd.conf for anything out of ordinary as
well. As can be seen, the translation handler below is very very basic but
it still enters a continuous loop for that specific URL. If I place a fully
qualified donamin name like http://lions.access.com/sp9/whatever, there is
no loop!!  

Any ideas?

package Apache::URIsid;
use strict;
use Apache::Constants qw(:common);
use CGI::Carp;

sub handler {
  my $r = shift;

  return DECLINED unless $r->is_initial_req;
  my($junk,$session,@rest) = split '/', $r->uri;
#  warn "junk: $junk";
#  warn "session: $session";
#  foreach (@rest) {
#warn "rest: $_";
#  }

  my $uri = $r->uri;
  warn "URI in: $uri";
  return DECLINED;

#  my $uri_in = $r->uri;
#  warn "sp9 URL detected $uri_in"; 
#  $r->subprocess_env('SESSION_ID' => $session); 
#  my $translated_uri = join "/", "",@rest;
#  $r->uri($translated_uri);
#  return DECLINED;
}
1;
__END__



-Original Message-
From: Greg Cope [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 31, 2001 5:47 PM
To: Sinclair, Alan (CORP, GEAccess)
Cc: '[EMAIL PROTECTED]'
Subject: Re: Translation handler continuous loop problem


"Sinclair, Alan (CORP, GEAccess)" wrote:
> 
> I am hoping someone might have a clue on how to resolve this awkward
> problem.
> 
> I have just installed a mod_perl URI translation handler to extract a
> session id from the URI. In general the translation works correctly by
> removing the session id from the URL when detected. However, a Netscape
> browser client triggers Apache to enter a continuous loop if I do not
> specify the domain name in the hostname component of the URL. The problem
> does not occur in Internet Explorer (that surprised me.)
> 
> All these examples are from Nestcape on both NT and Unix.
> For example, say I enter http://lions.access.com/sp9/outage.html  The
> translation handler works correctly.
> If I then enter: http://lions/sp9/outage.html  There is a continuous loop
in
> Apache and on each iteration, an entry is written to access_log. I have to
> stop the request in Netscape.
> 
> The bizarre thing is I can enter any other URL such as
> http://lions/internal/whatever and there is no problem. The mod_perl
> translation header goal is stripping session id info from the URL in the
> form http://hostname/SESSION_ID/sp9/whatever It looks for sp9 in the path.
I
> have attempted to debug by trying to send error messages to the error log
> without success.
> 
> Does anyone have any suggestions on how I can determine why the
translation
> handler is entering into a continuous loop when a request is sent from
> Netscape?
> 
> I would be appreciative of any help!!

I could be completely wrong but ...

I can't see a problem here - although I would need to see the code.

There could be an issue with how IE and Netscape actually format the
header (i.e you may enter the above, but the header that gets sent may
be different) - but I could be completely wrong on this !

You may wish to look at http://sourceforge.net/projects/sessionmanager/

Which is URI transhandler / session manager that I wrote for a project
that never came about.  I may make another release that uses PerlSetVars
to configure the module if I get a chance to test it.

If this does not help, then post either the code, or a URL to the code
if its long, so that some of us can have a look.

Greg

> 
> Env is: Solaris 2.6  Apache 1.3.14  mod_perl 1.24_01

Translation handler continuous loop problem

[Sinclair, Alan (CORP, GEAccess)]

I am hoping someone might have a clue on how to resolve this awkward
problem.

I have just installed a mod_perl URI translation handler to extract a
session id from the URI. In general the translation works correctly by
removing the session id from the URL when detected. However, a Netscape
browser client triggers Apache to enter a continuous loop if I do not
specify the domain name in the hostname component of the URL. The problem
does not occur in Internet Explorer (that surprised me.) 

All these examples are from Nestcape on both NT and Unix.
For example, say I enter http://lions.access.com/sp9/outage.html  The
translation handler works correctly.
If I then enter: http://lions/sp9/outage.html  There is a continuous loop in
Apache and on each iteration, an entry is written to access_log. I have to
stop the request in Netscape.

The bizarre thing is I can enter any other URL such as
http://lions/internal/whatever and there is no problem. The mod_perl
translation header goal is stripping session id info from the URL in the
form http://hostname/SESSION_ID/sp9/whatever It looks for sp9 in the path. I
have attempted to debug by trying to send error messages to the error log
without success. 

Does anyone have any suggestions on how I can determine why the translation
handler is entering into a continuous loop when a request is sent from
Netscape?

I would be appreciative of any help!!

Env is: Solaris 2.6  Apache 1.3.14  mod_perl 1.24_01

Correct LWP package to test mod_perl

[Sinclair, Alan (CORP, GEAccess)]

All,

Which is the correct LWP package to download from CPAN for doing the make
test phase during mod_perl installation. I note there are 2 LWP packages
with the LWP::UserAgent piece: lcwa-1.0.0 and libwww-perl-5.50

Thanks for the advice.
AS

Location vs Directory directives

[Sinclair, Alan (CORP, GEAccess)]

All,

Having read the writing apaches module book, I have noted all the examples
for installing handlers use the Location directive. Are there any hidden
side affects from setting up a handler within an Apache Directory directive?

Thanks for any advice!
AS

Apache.pm location on installation

[Sinclair, Alan (CORP, GEAccess)]

All,

I have successfully installed mod_perl on Solaris. The mod_perl installation
process has installed the Apache.pm module in the perl lib directory. Is
that normal?  I was expecting the Apache perl stuff to be installed under
APACHE_PREFIX.

Thanks!

Re: Remote Hosting

[Alan E. Derhaag]

[EMAIL PROTECTED] (Allen Wilson) writes:

> Does anyone have an idea of how to set up a remote host request. I am attempting
> to set up a web system where the user makes a request and it is process from one
> server to another. The remote server will return a file that will be formatted
> in a web page. 
> 
> I already have the formatting done...it is the connection and requesting from
> the remote server giving me the problem. I tried to run the remote shell (remsh
> ) but that failed.
> 
> Any ideas would be appreciate.

If you must use the user's entries to a form as a subset of that
submitted to the remote server you might use LWP as indicated below
in a sub that posts certificate requests to an internal network
Certificate Management System:

### proc_cert ##
# Process the certificate request

sub proc_cert {
  # Assume a KEYGEN or similar certificate request was generated by browse
  my $keygen = $q->param('subjectKeyGenInfo');
  $keygen =~ tr/\n//d if defined($keygen);  #strip extra newline

  # Post a request to our internal certificate server with the data passed
  my $ua = LWP::UserAgent->new;

  my $page = $ua->request(POST $CMSsrvwport . "/enrollment",
  ['uid' => $q->param('uid'),
   'pwd' => $q->param('pwd'),
   'email' => 'true',
   'ssl_client' => 'true',
   'digital_signature' => 'true',
   'non_repudiation' => 'true',
   'key_encipherment' => 'true',
   'subjectKeyGenInfo' => $keygen,
   'submit' => 'Submit',
   'certType' => 'client',
   'authenticator' => 'UserDirEnrollment',
   'importCert' => 'off'
  ]);

  # Test if server returned a valid page
  if ($page->is_success) {
print $page->content;
  } else {
print $page->error_as_HTML;
  }
}


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Table Joins

[Sinclair, Alan (CORP, GEAccess)]

Speaking from an Oracle perspective, it is generally better to use a join in
preference to an "IN" type subquery since the execution plan is normally
more efficient. However, some types of queries can only be solved with a
subquery clause such is the case with correlated subqueries.

This is a huge subject and the mod_perl list is not an appropriate forum for
this type of discussion.  

Regards,


-Original Message-
From: ASHISH MUKHERJEE [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 16, 2000 9:20 AM
To: [EMAIL PROTECTED]
Subject: Table Joins


Hello everyone ! Can someone shed some light on something related to
databases. I'd like to know is it more expensive to perform a Table Join to
obtain a result or is it better to use a sub-query instead.

Thanks
Ashish

---
cout<<"Hello World !";


Get FREE Email/Voicemail with 15MB at Lycos Communications at
http://comm.lycos.com

Re: Managing to kill httpd (why?)

[David Alan Pisoni]

At 10.41 -0700 10/13/2000, Doug MacEachern wrote:
>On Fri, 13 Oct 2000, Doug MacEachern wrote:
>
>> On Sat, 30 Sep 2000, Yann Ramin wrote:
>>
>> > #0  0x80a2605 in ap_table_get ()
>> > #1  0x808961e in XS_Apache__Table_FETCH ()
>> 
>> > package Magrathea::WebAPI;
>> ...
>> > my $driver;   
>>
>> you cannot cache data that is tied to $r (e.g., notes table), because
>> the $r->pool is cleared after each request.  string values are ok, but not
>> objects such as Apache::Table objects which are tied to the r->pool.
>
>just to be clear on this:  it's ok to cache things such as Apache::Table
>for the lifetime of a request (example, between request phases), but once
>the request is over (and r->pool is cleared), such a cache needs to be
>flushed.

On a related topic, a great way to make your life miserable is to cache the Apache 
request object in the instance data of an "application object" you wish to stick on 
$r->pnotes in order to scope it to the request.  Makes a nice leak when your request 
finishes -- $r goes out of scope to the request lowering the refcount by 1 -- but the 
refcount doesn't drop to 0 because $r->pnotes('APPOBJECT')->{'r'} still holds a 
reference to it.
(Solution?  $r->register_cleanup(sub { $r->pnotes(APPOBJECT => undef) };))

(Yes, I learned that the hard way. :-)

-- 
David Pisoni -- <[EMAIL PROTECTED]>
 Cnation -- 
310/228-6900 -- 310/228-6905 (fax)

"One machine can do the work of fifty ordinary men. No machine can do the work of one 
extraordinary man." -Elbert Hubbard, author, editor, printer (1856-1915)

Re: bytes_sent -> bytes_received?

[David Alan Pisoni]

Title: Re: bytes_sent ->
bytes_received?


At 7.25 PM +0100 10/7/2000, Matthew Byng-Maddick wrote:
On Sat, 7 Oct 2000, Drew Degentesh
wrote:
> In addition to the number of bytes sent to the client, Id like
to log how
> many bytes are sent *by* the client (the size of the request +
posts , etc.)

Fair enough

> I was guessing/hoping that length( scalar( $r->content ) )
would do it, but
> earlier in my application (before the log phase) I use
Apache::Request to
> (potentially) process a file upload, and Im guessing that clears
out
> $r->content.

I'm not sure if it does or not. Anyhow, $r->content won't get you
the full
request, plus all the headers. The best way to do this would be to
put
your measuring code in as a URI Translation handler (with whatever
method
works erm...) and then put the value in a notes field which you
can
then recover later on in the processing.

> Any ideas?

Not very helpful, I'm afraid.

MBM

--
perl -e
'$_=unpack"b196",pack"H50","cafa9c0e0abbdf7474590e8296e56c103a3c".
"5e97e52e104821";while(m(^.{7})){$a.=$&."0";$_=$'"'"'}print
pack"b224",$a'

Well, if you need the length of the POST data, then you should
be able (assuming the browser follows the RFCs) to get it from
$r->header_in( 'Content-length' ).

If you need the length of the ENTIRE request, theoretically you
could get it by adding together :
1) the above value
my $headerlength = $r->header_in(
'Content-length' )

2) the lengths of all the header lines

my $headers = $r->headers_in();
map { $headerlength += length($_) +
length($headers->{$_}) + 2 }
   
##  +2 above for ': ' between the header key and
value
   
keys %$headers;


3) and the request line
$headerlength += length( $r->the_request()
)

Did I miss anything?  Methinks this is the lot, but I'm
just typing here -- I didn't test it. ;-)

Enjoy,

-- 
David Pisoni -- <[EMAIL PROTECTED]>
 Cnation --

310/228-6900 -- 310/228-6905 (fax)

"One machine can do the work of fifty ordinary men. No machine
can do the work of one extraordinary man." -Elbert Hubbard,
author, editor, printer (1856-1915)

RE: CyberCash and mod_perl Experiences

[David Alan Pisoni]

At 11.28 -0400 10/2/2000, Ryan Adams wrote:


>
>Thanks everyone for listening to me rant.  I'll keep you posted on what I
>come up with.  I'm toying
>with the idea of writing an CyberCash module for the Business::OnlinePayment
>interface.  Anyone have
>any idea where to start?
>
>RYAN

Actually, we wrote a module (we called it Business::Payment) which supported different 
payment systems in a DBIish way.  (We wrote a Business::Payment::CyberCash, and a 
Business::Payment::CyberSource.)  Unfortunately, we never considered CPANing the code, 
because I think that because it uses knowledge (e.g., the published API) of these 
payment systems, public release would violate the license agreements of their payment 
libraries.  Furthermore, the systems were just different enough that we had to strip 
down the use of functionality in order to write Business::Payment code that was 
cross-platform (between the payment systems.)

I haven't looked at the licenses for these systems for awhile -- does anyone know if 
they have changed significantly enough to allow for the release of a module such as 
this?

Enjoy,
-- 
David Pisoni -- <[EMAIL PROTECTED]>
 Cnation -- 
310/228-6900 -- 310/228-6905 (fax)

"What is to give light must endure burning." - Viktor Frankl, author,
neurologist and psychiatrist, Holocaust survivor (1905-1997)

Re: recursion in Apache::Constants::AUTOLOAD?

[David Alan Pisoni]

Sorry I don't have much in the way of details, but we had this problem several months 
ago (probably in a previous version of mod_perl), but it silently went away.
(I'm reminded of it because recently I was reviewing the handler() of our recently 
open-sourced embedded parser, Apache::XPP, and found that the constants had been 
hard-coded to avoid the AUTOLOAD() spinning.  I put the constant calls back in :-)

Enjoy,
David

At 8.17 -0700 9/28/2000, Doug MacEachern wrote:
>On Mon, 26 Jun 2000, Jim Winstead wrote:
>
>> We were seeing some servers spin out of control (allocating memory
>> slowly) in Apace::Constants::AUTOLOAD (which apparently has been
>> reported in the mailing list before).
>>
>> The attached patch fixes the problems for us. Could someone who
>> understands what is going on here shed some light?
>
>i still don't understand how __AUTOLOAD can be undefined inside the
>server.  this patch adds an extra check that will prevent recursion if
>__AUTOLOAD is somehow undefined and print a stacktrace to give some idea
>where the problem is.
>
>Index: Constants/Constants.pm
>===
>RCS file: /home/cvs/modperl/Constants/Constants.pm,v
>retrieving revision 1.20
>diff -u -r1.20 Constants.pm
>--- Constants/Constants.pm 2000/03/03 20:42:01 1.20
>+++ Constants/Constants.pm 2000/09/28 15:12:36
>@@ -17,9 +17,16 @@
> if ($ENV{MOD_PERL}) {
> #outside of mod_perl this will recurse looking for __AUTOLOAD, grr
> *AUTOLOAD  = sub {
>-  #why must we stringify first???
>-  __AUTOLOAD() if "$Apache::Constants::AUTOLOAD";
>-  goto &$Apache::Constants::AUTOLOAD;
>+if (defined &__AUTOLOAD) { #make extra sure we don't recurse
>+#why must we stringify first???
>+__AUTOLOAD() if "$Apache::Constants::AUTOLOAD";
>+goto &$Apache::Constants::AUTOLOAD;
>+}
>+else {
>+require Carp;
>+Carp::confess("__AUTOLOAD is undefined, ",
>+  "trying to AUTOLOAD $Apache::Constants::AUTOLOAD");
>+}
> };
> }
> 

Re: Scheduling an Apache child for termination/influenceMaxRequestsPerChild counter

[David Alan Pisoni]

At 18.56 +0200 9/26/2000, Ime Smits wrote:
>Hi,
>
>I wonder if it's possible to somehow alter Apache's internal counter matched
>against MaxRequestPerChild or schedule the launching of a new child from
>withing mod_perl.
>
>The reason I want to do this, is that in the administrator section of my
>website, quite some stuff gets cached from the PostgreSQL backend on a per
>process basis and there is really no use to keep all those caches after the
>administrator hit the logout button.
>
>Plus, I want to be able to terminate a process if some kind cache
>inconsistency is detected. I know it's better to track the origin of that
>inconsistency and fix it there, but I'm using some modules which I did not
>create myself and I'm not planning to dig into 5000+ lines of code I did not
>wrote. What I really would like to do is to just finish the current page,
>dropping a line like "things are getting fishy here", wipe the
>administrator's session cookie and let the child die.
>
>Ime

Can you run the administrative section of your site in a separate server process?  
That way, you can tune your MaxClients and MaxRequestsPerChild levels very low for 
that server, while preventing your front-end server from allocating excessive chunks 
of RAM (and leaving the afformentioned settings optimized.)

Enjoy,
-- 
David Pisoni -- <[EMAIL PROTECTED]>
 Cnation -- 
310/228-6900 -- 310/228-6905 (fax)

"The opposite of a correct statement is a false statement. But the opposite of
a profound truth may well be another profound truth." -Niels Bohr, physicist
(1885-1962)

Re: Can't locate object method "No" via package "such"

[Alan E. Derhaag]

Doug MacEachern <[EMAIL PROTECTED]> writes:

> On 4 Sep 2000, Alan E. Derhaag wrote:
> 
> > I upgraded to openssl-0.9.5a and recompiled apache w/mod_ssl and
> > mod_perl defining the SSL_BASE to the apache src and now the thing
> > won't start and complains about:
> > 
> >  Can't locate object method "No" via package "such" at /dev/null line 1.
> 
> looks to me like /dev/null is broken.  if you run:
> % cat /dev/null
> 

Good try, but /dev/null is not broken on my machine.

I finally gave up and eliminated the DSO version by compiling two
versions of httpd.  Both include mod_ssl but the Engine is only turned
on with the light server.

I did find a slight problem when running `configtest' but I doubt that
that could have been the problem.

Re: question: using Apache for non-HTML messages

[David Alan Pisoni]

Really all you need to do is send your response back like you would any response, just 
without the HTML formatting.  If you wanted to be a bit more "correct", you could 
change the content-type of the respose so that it is not 'text/html'.  (In your case, 
you might just make one up like 'application/x-brians-spiffy-protocol' or whatever you 
think is appropriate preceded with 'x-'.)  Or, if you wanted to debug it using a web 
browser, you could simply use 'text/plain', and your browser will display the raw 
result.

It is important to note that Apache is an HTTP server, not an "HTML server".  It is 
capable of serving any sort of serial content.

So anyway, since it looks like you're using a registry script, you would merely start 
your output with :
print "Content-type: " . $my_content_type . "\n\n"; # note the 2 newlines!

and then proceed directly to your proprietary output.

Make sense?

David

At 9.21 -0400 9/25/2000, B. Burke wrote:
>Here is an example of what I'm looking to do.
>
>GET /perl/app.pl?MODE=search&CITY=Dallas&STATE=TX&ID=195302 HTTP/1.0
>Accept: text/html
>User-Agent:  MyTestClient1.0
>From:  nowhere.com
>
>I want to replace the HTML request above with something like this:
>
>|MODE=search|CITY=Dallas|STATE=TX|ID=195302|
>
>I can hard code the handler to do GET's against only one script.  The request
>format
>is VERY similiar to the arguments in a GET (all I really have to do is
>translate the pipe).
>I think for the response, all I need to do is remove the headers entirely,
>and I can format
>the script output to conform to our API (I don't need protocol headers for
>requests nor
>for responses).
>
>I've been able to basically remove the response headers by removing the
>functionality
>of ap_sen_header_field() before compiling Apache, but it would be nice to
>have a
>more eloquent solution through mod_perl.
>
>Thanks,
>Brian
>
>
>Matt Sergeant wrote:
>
>> On Mon, 25 Sep 2000, B. Burke wrote:
>>
>> >
>> > I'm using Apache/1.3.11 with mod_perl/1.22 on an AIX platform to serve
>> > as an application server, with persistent ties into a MySQL database.
>> >
>> > My company is using an in-house socket API for data transfers.  The
>> > request messages in our API are somewhat similiar to an HTML GET
>> > request, in that we use tagged, delimited fields (pipe delimited
>> > instead of & delimited).
>> >
>> > I have written a socket server gateway to act as a protocol converter,
>> > to convert our API's requests into HTML GET's (and also convert the
>> > HTML output into our API's response format).
>> >
>> > My question is this.  Is it possible using mod_perl for me to
>> > incorporate the protocol conversion into Apache itself?  In other
>> > words, can I strip out the need for HTML headers, and rewrite the
>> > format of GET requests to comply with our proprietary API? I don't
>> > know if this is something that I can do through mod_perl, or if I will
>> > have to dig deeper into C and recompile a new server.
>> >
>> > Any help or ideas will be mucho appreciated!
>>
>> I don't think you'll actually have to re-write anything. Although an
>> example of a transaction would be most helpful. All you have to do is
>> setup mod_perl to handle the connection, Apache _should_ be able to handle
>> the request if it looks enough like a GET request, and you should be able
>> to respond to it with little enough information, provided your responses
>> are also similar to HTTP responses (HTTP response code followed optionally
>> by headers then the body).
>>
>> --
>> 
>>
>> Fastnet Software Ltd. High Performance Web Specialists
>> Providing mod_perl, XML, Sybase and Oracle solutions
>> Email for training and consultancy availability.
>> http://sergeant.org | AxKit: http://axkit.org

Re: [ANNOUNCE] BingoX 1.91 (new package)

[David Alan Pisoni]

At 14.50 -0500 9/22/2000, Dave Rolsky wrote:
>On Fri, 22 Sep 2000, David Alan Pisoni wrote:
>
>> The URL
>>  <http://opensource.cnation.com/downloads/BingoX-current.tar.gz>
>>
>> has entered CPAN as
>>   file: $CPAN/authors/id/C/CN/CNATION/BingoX-1.91.tar.gz
>>   size: 72136 bytes
>>md5: cbf5108d666a83b64843e991eea61d1d
>>
>>
>> BingoX is an open source, object oriented Web Application Framework written in 
>mod_perl meant to dramatically reduce the time required to build large dynamic, 
>database driven web sites and applications. BingoX is also a methodology for building 
>web sites and applications which enables groups of developers to work together in a 
>more consistent manner. With the BingoX framework, it is possible with a minimal 
>amount of code to:
>>
>>  * Create large, database driven, dynamic sites in a fraction of the time.
>>  * Access complex relational databases through an intuitive and consistent 
>object-oriented API.
>
>Wow, this portion (BingoX::Carbon) seems largely identical to a subset of
>what my Alzabo project does (alzabo.sourceforge.net).  Before you guys go
>further, you might want to take a look at it.  There are some things
>BingoX appears to do that Alzabo has yet to get to but there's a lot in
>the other direction too.  Plus dare I say that Alzabo is a lot cleaner?  I
>dare.

Interesting.  BingoX::Carbon is actually the most mature portion of BingoX (that is, 
we've been developing it the longest), and it's also the part which stands to change 
the most dramatically in the next version of BingoX (which is already under 
development.)  This development should certainly be informed by Alzabo (and by the 
POOP list) -- we will look into this thoroughly.

Please note that this is by no means the primary function of BingoX -- database 
abstraction is merely a part (though an integral one) of web application development.

>Anyways, this is already OT so you might want to join the POOP list
>(poop.sourceforge.net) for further discussion.

Actually, that page doesn't seem that very interesting.  Can you give me more 
information on the POOP list please (privately, as we are already OT enough :-)

Enjoy,

-- 
David Pisoni -- <[EMAIL PROTECTED]>
 Cnation -- <http://www.cnation.com/>
310/228-6900 -- 310/228-6905 (fax)

"The opposite of a correct statement is a false statement. But the opposite of
a profound truth may well be another profound truth." -Niels Bohr, physicist
(1885-1962)

[ANNOUNCE] BingoX 1.91 (new package)

[David Alan Pisoni]

Cnation is pleased to announce the initial posting of BingoX to CPAN.

The URL


has entered CPAN as
  file: $CPAN/authors/id/C/CN/CNATION/BingoX-1.91.tar.gz
  size: 72136 bytes
   md5: cbf5108d666a83b64843e991eea61d1d


BingoX is an open source, object oriented Web Application Framework written in 
mod_perl meant to dramatically reduce the time required to build large dynamic, 
database driven web sites and applications. BingoX is also a methodology for building 
web sites and applications which enables groups of developers to work together in a 
more consistent manner. With the BingoX framework, it is possible with a minimal 
amount of code to: 

* Create large, database driven, dynamic sites in a fraction of the time. 
* Access complex relational databases through an intuitive and consistent 
object-oriented API. 
* Create powerful administrative interfaces for managing content in your 
database. 
* Create dynamic web sites which separate business logic from code, letting 
HTML Integrators work on display while Application Programmers write business logic. 
* Reuse code within a project and between projects, cutting development time 
even further. 


What BingoX is not :
* A new form of gambling.
* A domestic or farm animal.

For more detailed information on BingoX (and other Cnation open source projects) go to 
.


-- 
David Pisoni -- <[EMAIL PROTECTED]>
 Cnation -- 
310/228-6900 -- 310/228-6905 (fax)

"The opposite of a correct statement is a false statement. But the opposite of
a profound truth may well be another profound truth." -Niels Bohr, physicist
(1885-1962)

compile runs great but won't execute

[Alan E. Derhaag]

apache_1.3.11
mod_ssl-2.5.0-1.3.11
mod_perl-1.24
perl v5.6.0
RedHat Linux 2.2.12-20

I compiled mod_ssl and mod_perl as DSOs and there were no errors..  a
few warnings but nothing really significant.  When running configtest,
however, with the following in httpd.conf:

LoadModule mod_perl libexec/libperl.so
AddModule mod_perl.c

I get the result:

Syntax error on line 146 of /usr/local/apache/conf/httpd.conf:
Can't locate API module structure `mod_perl' in file \
 /usr/local/apache/libexec/libperl.so: \
/usr/local/apache/libexec/libperl.so: undefined symbol: mod_perl

line continuations are mine.

..never seen this before!  What defines mod_perl to the API?

Can't locate object method "No" via package "such"

[Alan E. Derhaag]

I upgraded to openssl-0.9.5a and recompiled apache w/mod_ssl and
mod_perl defining the SSL_BASE to the apache src and now the thing
won't start and complains about:

 Can't locate object method "No" via package "such" at /dev/null line 1.

The compile had no warnings or errors except a `assignment discards
`const' from pointer target type' warning.

I've grepped the source for all (including openssl) and find nothing
that might emit this error.

Can I get a recommendation of where to look next?

-- 
 Alan E. Derhaag New Era Software Development
 http://www.wolfenet.com/~aderhaag/   Auburn, WA, USA
 email: [EMAIL PROTECTED]  [EMAIL PROTECTED] 

Re: Customized Module For Logging In Transfer Log

[Alan E. Derhaag]

Saurabh Goyal <[EMAIL PROTECTED]> writes:

> Hi,
> 
> I am new to apche and mod_perl. I am trying to write apache module to write
> some additional parameters to transfer log (access.log). Is anybody have an
> idea, how can we write additional stuff to access.log including the
> defaults. Any help appreciated.
> 
> Thanks,
> > SGoyal

You might look into Apache::DBILogger and subclass it more use it for
a template to begin with.

Re: What's this error?

[Alan E. Derhaag]

Paul <[EMAIL PROTECTED]> writes:

> > > I have also noted a fair amount of 
> > > [Wed Jul 19 16:01:58 2000] [notice] child pid 24703 exit signal
> > > Segmentation Fault (11)
> 
> I get this, too, a *LOT*.
> 
> > Err... I'm convinced that our current mod_ssl 2.6.5 is 100% stable
> > and does not produce any segfaults. If you really get segfaults, some
> > other component causes it.  Let me guess: You're running PHP or 
> > mod_ssl+OpenSSL as a DSO underf Solaris, right?
> 
> Forgive the "me, too"-ism, here, but this problem just won't seem to go
> away.  I'm running on HP-UX B.10.20 (best the company will spring for)
> on a PARISC1.1 9000/891.  I probably did build DSO, though, and I
> really don't need it. Hmm think the same prob might apply here?
> 
> > If no, then I've no clue and you have to attach a debugger to find
> out
> > where it segfaults.
> 
> Somebody suggest a debugger? I'm feeling pretty ignorant, here, and
> unfortunately won't have any time to RTFM for a few weeks yet.
> (~mumblegrumble~)

Recently, I had such a concurrence and traced it to a module (loaded
with startup.pl) that was bombing at the initialization when first run
by an access.  Dropping the modules from startup.pl improved the debug
output and allowed tracing its failure.

Re: User-Agent: contype

[Alan Sparks]

My tests show that it often (can't be sure of always) occurs with a PDF
file.  BUT, it doesn't happen with NS Communicator and Acrobat Reader...
only the combo of IE and Acroread.

I've long suspected that it had something to do with IE sniffing the data
stream to figure out the data type.  There's an old bug against IE that
mentioned that IE does sniff the data stream and use its own ideas in
deference to the stated MIME types and content dispositions sometimes.  I've
always wondered if that ties into this.

-Alan

-Original Message-
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: Tony Demark <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, August 01, 2000 11:34 AM
Subject: Re: User-Agent: contype


¡Hola!

Looking at the users that log that make the request, it doesn't seem to
be...
(they are not the type of people that would use something like that, most
have
a hard time each time they have to use a browser)

I'm starting to suspect that is some pdf reader... But i've tried with
acrobat
reader with no luck...

HoraPe

> If I am to believe AltaVista, it looks like a "free Perl CGI script that
sends
> a requested file using user supplied MIME content type[s]".

> URL: http://lambda.nic.fi/~ktmatu/contype/

> - Tony
>
> In message <[EMAIL PROTECTED]>,
horape@tinuviel.
> compendium.com.ar writes:
> >=A1Hola!
> >
> >I've started getting lots of access from the "contype" User-Agent. Does
> >somebody know what is it?
> >
> >TIA,
> > HoraPe
> >---
> >Horacio J. Pe=F1a
> >[EMAIL PROTECTED]
> >[EMAIL PROTECTED]
> >[EMAIL PROTECTED]
> >[EMAIL PROTECTED]
> >
>
>

--
HoraPe
---
Horacio J. Peña
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Apache::Include requires ExecCGI on doc root?

[Alan E. Derhaag]

Theo Petersen <[EMAIL PROTECTED]> writes:

> I was experimenting with Apache::Include and found something odd.  First
> I tried a document in htdocs that used a virtual include like so:
> 
> 
> 
> This works fine, and hello-mod_perl.pl runs via Apache::Registry.
> 
> But when I changed the include to use Apache::Include like so:
> 
> 
> 
> it didn't work, and I got an error in error_logs:
> 
> [Tue Jun 27 11:22:59 2000] [error] access to
> /usr/local/apache/perl/hello-mod_perl.pl failed for 192.168.3.9, reason:
> Options ExecCGI is off in this directory
> 
> I verified that ExecCGI is enabled for /usr/local/apache/perl (besides,
> the Apache::Registry version wouldn't have worked without it).  Turns
> out that Apache::Include worked fine when I enabled ExecCGI for htdocs.
> 
> Is there a reason why Apache::Include requires this when mod_include
> doesn't?

Did you ever get a responce?  I searched the archives and find nothing
touching upon this, otherwise.

I have a similar problem and I was wondering if your httpd.conf file
had either a  or  entry that specified `+ExecCGI'
instead of `ExecCGI' as that appears to make a difference, as well.

-- 
 Alan E. Derhaag New Era Software Development
 http://www.wolfenet.com/~aderhaag/   Auburn, WA, USA
 email: [EMAIL PROTECTED]  [EMAIL PROTECTED] 

Re: Coredump

[Alan Sparks]

The newsgroup comp.infosystems.www.servers.unix is the usual hangout for
Apache-related issues...
-Alan

-Original Message-
From: Dana Powers <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, July 14, 2000 3:39 PM
Subject: Coredump


>Do any of you know a better place to look for help with my apache coredump
>problem? (see earlier message) I looked all over the apache website and
found
>nothing useful. No mailing lists, or newsgroups or the like. All I found
was
>bug-reporting info, which this certainly doesnt fall into yet.
>Dana Powers

Re: Apache/mod_perl

[Alan Sparks]

Can't speak much to Stronghold, got a copy and ultimately put it on the
shelf.  I rather like Raven (covalent.com), works like a peach with mod_perl
etc.
Just wish Apache didn't have to be patched to install the damn stuff...
-Alan

-Original Message-
From: Pramod Sokke <[EMAIL PROTECTED]>
To: Vivek Khera <[EMAIL PROTECTED]>; [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, July 07, 2000 11:03 AM
Subject: Re: Apache/mod_perl


>Has anybody used stronghold? I'm considering using stronghold for SSL
>support since ours is a commercial application. Would mod_perl and all
>related modules work as fine with Stronghold as with plain Apache?
>
>Thanks,
>Pramod
>
>At 10:24 AM 7/7/00 -0400, Vivek Khera wrote:
>>>>>>> "PS" == Pramod Sokke <[EMAIL PROTECTED]> writes:
>>
>>PS> We are running Netscape Enterprise server with cgis written in perl
>and C.
>>PS> I'm looking at moving over to Apache and start using mod_perl. How
>> [ .. ]
>>PS> over to Apache/mod_perl going to be a simple plug-in or would it
involve
>>PS> re-writing lots of stuff?
>>
>>The C stuff will probably not be worth rewriting, but that depends on
>>what it does.
>>
>>The perl stuff will need to be "cleaned" if it is sloppy code.  That
>>is, if it is clean running in Perl under "-w" and "use strict" you're
>>most likely going to have little difficulty with them.
>>
>>But what you should do is use the two-server performance enhancement
>>(using mod_proxy and mod_rewrite) and have your legacy apps run on the
>>front-end server, and then migrate your perl to the mod_perl backend
>>one at a time.
>>
>>--
>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>Vivek Khera, Ph.D.Khera Communications, Inc.
>>Internet: [EMAIL PROTECTED]   Rockville, MD   +1-301-545-6996
>>GPG & MIME spoken herehttp://www.khera.org/~vivek/
>>

Re: Script that stays on the same page

[Alan Sparks]

It's generally not a good idea to follow up a user action with a page
that doesn't change... The lack of feedback makes people very nervous.

Notwithstanding, you can accomplish this by sending back a Status: of
204 (No Change) and a content-type: of text/html -- with no entity
body.  The browser will leave the current page displayed, with no
indication of a reloaded anything.
-Alan

Pierre-Yves BONNETAIN wrote:
> 
>Hello,
> 
>For my server, I need to write some script that will be 'regularly'
> triggered (GET or POST), but that will NOT send the user to another page. The
> user must stay on the same page he is, without ANY html being exchanged as
> a result of the script.
>This will be used to change parameters on the user's session, but since
> those params will not affect the page the user is currently looking at, there
> is no need to send HTML back.
>So, 1/ can it be done ? 2/ How ?
>TIA,
> --
> -+-+ Pierre-Yves BONNETAIN (aka Pyb)
>  Consultant Internet/Sécurité --- B & A Consultants
>  Tel : 0 563.277.241 - Fax : 0 563.277.245

Re: Bitten by -D_FILE_OFFSET_BITS=64

[Alan Burlison]

"Paul G. Weiss" wrote:

> This has been fixed in a post 1.23 patch.
> Change the line
> 
>  $PERL_EXTRA_CFLAGS = "";
> 
> to
> 
>  $PERL_EXTRA_CFLAGS = $] >= 5.006 ? $Config{ccflags} : "";
> 
> and try again.

Note that this is not a complete fix.  It will only work if you allow
mod_perl to build apache, as instructed in the original patch. 
Unfortunately if you are using APXS this is not the case.  In this case,
when you initially build Apache you need to do so with the flags
required to make it largefile aware.  I think it might also be a good
idea to put a test in mod_perl's Makefile.PL to check that the
largefile-ness of both perl and apache agree when using APXS.  On
Solaris you can do this by using nm and looking to see if the normal or
largefile versions of routines are in use, e.g. fstat or fsta64.  I
don't know how portable to other platforms this is though.

-- 
Alan Burlison

Re: segfault in DSO mod_perl 1.23 (perl 5.6.0) with apache-1.3.12

[Alan Burlison]

Michael Poole wrote:

> In hopes that this would fix the APXS build, I tried rebuilding with
> that, but whenever the httpd tried to load the php3 or perl module, it
> would die in pthread_mutex_lock.  This was slightly odd, since php3
> would load fine when httpd was statically linked against mod_perl.
> For the time being, I'll just roll back to using static mod_perl and
> dynamic mod_ssl and php3.

No, that's what you would expect.  The problem is being caused because
perl amd mod_perl are being built to be largefile aware, whereas by
default Apache is not.  By following Doug's instructions to let mod_perl
build httpd you are building it with the same flags needed to make
perl/modperl largefile aware, so Apache too ends up being largefile
aware and all the bits then are in sync.

If you use APXS you are building Apache seperately and with the standard
config, i.e. not largefile aware, so it breaks.  If you want to use APXS
you have to build Apache to be largefile aware yourself.  On Solaris at
least the way to do this is to set CFLAGS='-D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64' in your environment before invoking the Apache
configure.

-- 
Alan Burlison

Re: Bitten by -D_FILE_OFFSET_BITS=64

[Alan Burlison]

Ari Jolma wrote:

> (This may be a general Perl question but since I have this problem
> only with mod_perl I'm asking it here.) Perl's (5.6.0) Configure script
> puts -D_FILE_OFFSET_BITS=64 into Config.pm's variable ccflags in
> my machine (redhat 6.1 with linux 2.2.12). This causes for some
> reason mod_perl.c to have stat structure with size 96 while it
> has the size 88 in apache (and it is 88 usually). The result is
> very poor behavior in make test. When I manually remove that
> compiler directive everything works fine. My mod_perl is 1.23
> and apache is 1.3.12. I believe I've had this problem for long since
> over the years :-) I've had this same problem occasionally but only
> now investigated it thoroughly using gdb. Can anybody give an
> explanation what is going on here?

I was bitten my a similar problem on Solaris.  Basically I built perl
with the default configure settings on Solaris 8, which result in Perl
being made largefile aware, which is A Good Thing.  However, when I
built Apache it was built without being largefile aware, which is A Very
Bad Thing - at least if you want to use mod_perl, that is.  This is
because Perl and Apache don't agree on the size of off_t and other such
things that change between the 32 and 64 bit file offset worlds.  I
fixed this by the simple expedient of making Apache largefile aware.  On
Solaris this was easy - I just set CFLAGS="-D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64" in my environment before calling the Apache
configure.  Apache built with no errors, and as far as I can tell up
until now it works just fine, including mod_perl.  Obviously you are on
a different platform, but perhaps building Apache with the Linux
incantation needed to make it largefile aware will solve the problem for
you?

Alan Burlison

Re: Core dump: Solaris 2.7/mod_perl1.23/Apache1.3.12/perl5.6.0

[Alan Burlison]

Some more info:  I've rebuilt everything with debug, and the SEGV is
happening in mod_perl.c in the following code:

#ifdef PERL_HEADER_PARSER
int PERL_HEADER_PARSER_HOOK(request_rec *r)
{
dSTATUS;
dPPDIR;
#ifdef PERL_INIT
PERL_CALLBACK("PerlInitHandler",
 cld->PerlInitHandler);
#endif
PERL_CALLBACK("PerlHeaderParserHandler",
 cld->PerlHeaderParserHandler);
return status;
}
#endif

specifically the macro dPPDIR.  I notice that the request_rec pointer
passed in has one field that points to an invalid address, I don't know
if it is relevant:

   parsed_uri= {
  scheme = (nil)  
  hostinfo   = (nil)  
  user   = 0x174fa0 "/"  
  password   = (nil)  
  hostname   = (nil)  
  port_str   = (nil)  
  path   = 0x8000 ""  
  query  = 0x175418 ""  
  fragment   = 0x174e20 ""  
  hostent= 0x1755a0 
  port   = 23U 
  is_initialized = 0 
  dns_looked_up  = 1U 
  dns_resolved   = 0

expanding out dPPDIR it refers to r->per_dir_config and &perl_module. 
r->per_dir_config is a void*, and has the value 8, which sure doesn't
look like a valid address to me.  perl_module on the other hand all
looks sane.  I'm not sure where to look next - any suggestions? 

-- 
Alan Burlison

Core dump: Solaris 2.7/mod_perl1.23/Apache1.3.12/perl5.6.0

[Alan Burlison]

This is a new one on me.  mod_perl is built with APXS and perl is built
with -DDL_UNLOAD_ALL_AT_EXIT, so it isn't coredumping during startup,
but it cores the first time an access is made.  Anyone have any
suggestions?

=>[1] perl_header_parser(0xd9480, 0xff16ca04, 0xa, 0xd9480, 0x2f707269,
0x2f617061), at 0xff124acc
  [2] run_method(0xd9480, 0x74, 0x8f764, 0x1, 0xda4e8, 0x4), at 0x32828
  [3] process_request_internal(0xd9480, 0xff0c, 0xd9480, 0xd8440,
0xd9608, 0x40090), at 0x44d74
  [4] ap_process_request(0x89000, 0xd9480, 0xd9480, 0xff0c, 0x0,
0x4), at 0x45090
  [5] child_main(0x8f800, 0x8f800, 0xd9480, 0x0, 0x0, 0x0), at 0x3d0d0
  [6] make_child(0x943d0, 0x0, 0x3916cee9, 0x943d0, 0x0, 0x0), at
0x3d2b8
  [7] startup_children(0x8f988, 0x8d048, 0x8902c, 0x3916cee9, 0x0, 0x0),
at 0x3d42c
  [8] standalone_main(0x8f800, 0x8f800, 0x8f824, 0xa912c, 0xb400, 0x8),
at 0x3da64
  [9] main(0x8f800, 0x8f800, 0x2, 0x88400, 0x0, 0x0), at 0x3e348

Alan Burlison

Re: HTML::Mason and path_info

[Michael Alan Dorman]

[EMAIL PROTECTED] (Alexei V. Barantsev) writes:
> I have the followin problem: HTML::Mason dhandler could not define
> path_info, it tries to select only first part. For example, if my
> request is http://server/test/hello/world and dhandler is in /test
> it decides that $r->path_info is /hello/.

I'm guessing you're using an unpatched 0.81.  There are patches on
www.masonhq.com/bugs (I think that's the folder).  Please apply those.

Mike.

Re: mod_perl (DSO) dumping core with perl 5.6.0

[Alan Burlison]

"Paul G. Weiss" wrote:
> 
> Sad to say still not working.

I'd suggest building perl with -Uusemymalloc.

Alan Burlison

Re: Modperl 1.22 and Perl 5.6.0

[Alan Burlison]

Doug MacEachern wrote:

> i've benchmarked the two, it makes a HUGE difference under solaris, Perl's
> malloc kicks the sh*t out of solaris system malloc.  Perl's malloc is not
> as much of a win under linux, i don't have the numbers handy though.

The only potential gotcha with perl's malloc is that it doesn't work if
you compile perl as a 64-bit app (-Duse64bitall), as it isn't 64 bit
clean.  I don't suppose there are may people trying to build a 63-bit
Apache though...

Alan Burlison

Re: ORA-12154: TNS:could not resolve service name with DBI under Apache

[Alan E. Derhaag]

Jerome MOUREAUX <[EMAIL PROTECTED]> writes:

> David,
> 
> The ORACLE_HOME is set in the httpd.conf with a PerlSetEnv directive.
> (it appears in the extract I sent). (I've checked that is OK in the scripts by
> printing out $ENV{ORACLE_HOME} )
> The SID is not case sensitive (I tried some combination when I was trying to
> figure out what happen) otherwise it would mean that SID are insensitive when
> running the script from command line and sensitive when running from Apache !

[...]

> >  > Here is the error :
> >  >
> >  > DBI->connect failed: ORA-12154: TNS:could not resolve service name (DBD:
> >  > login f
> >  > ailed) at /disc1/sherpa_a/indicators2/perl/activity/toto.pl line 5
> >  > [Wed Mar 29 20:11:32 2000] [error] ORA-12154: TNS:could not resolve 
> > service
> >  > name
> >  >   (DBD: login failed) at 
> > /disc1/sherpa_a/indicators2/perl/activity/toto.pl
> >  > line 5
> >  >

[...]

> >  > #$Apache::DBI::DEBUG=2;
> >  > #Apache::DBI->connect_on_init("dbi:Oracle:indicators", "indic", "",
> >  >   { AutoCommit => 0, RaiseError => 1, PrintError => 0 } )
> >  >   or die $DBI::errstr;
> >  >
> >  > 1;

Have you tried something like:

Apache::DBI->connect_on_init("dbi:Oracle:server=indicators;database=XXX",
  "indic", "", { AutoCommit => 0, RaiseError => 1, PrintError => 0 } )
   or die $DBI::errstr;

explicitly supplying the server and avoiding the `use XXX' on the
first connect?  Works with Sybase, anyway.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Alan E. DerhaagConsultant from Interactive Business Systems
phone: 206-336-2972  Consultant to N2H2
email: [EMAIL PROTECTED]   [EMAIL PROTECTED]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

did CGI::dump get upgraded to CGI::Dump?

[Alan E. Derhaag]

I've got broken CGI scripts after upgrading to CGI version 2.59 when
the CGI::param variables are dumped to a file.  It appears that the
`as_string' replaced the synonym for `dump'.

I would have posted directly to Lincoln but I couldn't find his e-mail
address noted in the module..  although a good many contributors have
their addressed there.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Alan E. DerhaagConsultant from Interactive Business Systems
phone: 206-336-2972  Consultant to N2H2
email: [EMAIL PROTECTED]   [EMAIL PROTECTED]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

RE: How do I send a 404 from Embperl?

[Alan Gutierrez]

> Gerald Richter wrote:
> You can't keep Embperl from doing so, but that isn't really the problem. The
> problem is that you have to tell Apache to generate the error page for you.
> In a Apache::Registry script you can do this by
> 
> sub notfound
>   {
>   return 404 ;
>   }
> 
> but this isn't possible within a Embperl page. So either use
> Apache::Registry for that purpose, because you won't display any HTML
> anyway, or use your code above and generate your own errorpage, instead of
> let Apache do this for you. This should work quite well
> 
> Gerald
> 

I am returning HTML. Lots of it. My example was simply to illustrate my attempt
to return a 404. What follows may be a better way of communicating my
intentions.

[-
# Do a lot of DBI stuff.

.
.
.

if ($records_not_found_so_I_cannot_generate_the_page) {
$req_rec->status('404');
exit;
}

-]



.
.
.



But, I understand what you mean by having to return a 404.

I've managed to do redirects from Embperl by setting the status and adding 
a Location header. I was hoping that I could do the same for a 404.

I suppose I am going to be told that I have to chain handlers and the like,
so I'll start reading the guide.

Wouldn't it be easier if there as a way to set the return value from within
Embperl?

Alan Gutierrez - [EMAIL PROTECTED]

How do I send a 404 from Embperl?

[Alan Gutierrez]

I am attempting to send a 404 not found message from an Embperl script. Here
is the code I am trying to use in its simplest form. This is test.html. Note
that it contains no HTML.

[-
  $req_rec->status('404');
  $req_rec->header_out('Content-Length' => undef);
  exit;
-]

Normally, a 404 looks from Apache looks like this:

GET /monkey.html HTTP/1.0

HTTP/1.1 404 Not Found
Date: Thu, 10 Feb 2000 20:43:34 GMT
Server: Apache/1.3.9 (Unix) mod_perl/1.21
Connection: close
Content-Type: text/html



404 Not Found

Not Found
The requested URL /monkey.html was not found on this server.

Apache/1.3.9 Server at sauron.mindsinc.com Port 8386

Connection closed by foreign host.

I left the "Connection closed ..." so we could see where exactly the
documents end.

Here is the output from test.html:

GET /mtn-dev/resources/test.html HTTP/1.0

HTTP/1.1 404 Not Found
Date: Thu, 10 Feb 2000 20:40:17 GMT
Server: Apache/1.3.9 (Unix) mod_perl/1.21
Content-Length: 2
Connection: close
Content-Type: text/html


Connection closed by foreign host.

Oh! So close! But the Content-Length makes the client think that there is
something worth displaying. Both NS and IE show a blank page. What I'd
rather see is the server's error page.

The question: How do I keep Embperl from adding the content length to the
headers when I want to send an error message?

Alan Gutierrez - [EMAIL PROTECTED]

Re: Forcing user/group unto the log

[Alan Sparks]

After authenticating the user, have you called:

$r->connection->user($username);

-Alan

-Original Message-
From: Nicolas MONNET <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, February 08, 2000 9:56 AM
Subject: Forcing user/group unto the log


>
>Hi there, I have implemented a cookie based authentification mechanism for
>my website. Now I'd like to pass the user and group information in the
>log, both field currently show as "-" currently. Is there any simple way
>to do this? 
>
>Thanks!
>

Re: A fix in sight: Apache::ASP: crash when placed in startup.pl (2)

[Alan Burlison]

Gerald Richter wrote:
> 
> > Seems correct to me, although as I said before the patch should really
> > go in DynaLoader - after all it is conceivable that perl embedders other
> > than Apache could be hit by this problem.
> >
> Yes, I agree, but this will not before perl 5.006 and much people are still
> using perl 5.004...

This is unfortunately true.  However, the next version of perl is
imminent (ish) so it would be nice if the fix could be in it.

Alan Burlison

Re: A fix in sight: Apache::ASP: crash when placed in startup.pl

[Alan Burlison]

Doug MacEachern wrote:

> wow, *nice* catch!!  Daniel, I can't thank you and Alan enough for your
> efforts here.  it's such a thorny problem to debug, the closest I came was
> trying to prevent the dlclose of modperl's libperl.so, but had no idea why
> that bandaid prevented the bleeding.  I hadn't heard of ltrace, what a
> spectacular looking tool.
> I'd really like to get the workaround in 1.22, even if Apache and/or
> DynaLoader is the "right" place, we don't have any control over the
> release schedules of either and modperl-1.22 is already long overdue.

You are welcome - it has always bugged me that I could never get APXS to
work.  Both Perl and Apache are included with Solaris 8
(http://www.sun.com/software/solaris/ea/linux.html), and the only way to
add mod_perl to the preinstalled Apache/Perl is to use APXS.

I've posted a bug against DynaLoader to P5P.  I think the fix is
probably to put an END handler in DynaLoader to unload the XS modules,
but I'm not familiar enough with the perl interpreter cleanup processing
to know if this is the best way.

It might add some weight if you could add your comments to the bug
preport in P5P - after all, the know who you are ;-)

Alan Burlison

Re: A fix in sight: Apache::ASP: crash when placed in startup.pl (2)

[Alan Burlison]

Gerald Richter wrote:

> Just one more thought: The mp_dso_unload, which Daniel has patched, is
> registered as cleanup. So it should be called everytime the modperl
> libraries is unloaded and only when modperl library is unloaded, we need to
> unload the other libraries. So as far as I see this patch is all that is
> neccessary. I am missing something?

Seems correct to me, although as I said before the patch should really
go in DynaLoader - after all it is conceivable that perl embedders other
than Apache could be hit by this problem.

Alan Burlison

Re: Why does Apache do this braindamaged dlclose/dlopen stuff?

[Alan Burlison]

Alan Burlison wrote:

> > AB> from mod_perl -> perl libperl.so).  Unfortunately the perl XS modules
> > AB> loaded in during startup via dlopen are *not* unloaded, nor do they
> > AB> succeed in locking the perl libperl.so into memory (you could construe
> > AB> this as a linker bug).  Then Apache reloads the mod_perl libperl.so,

Actually, I retract that statement.  It is *not* a linker bug.  By
explicitly adding a dependency between the XS .so modules and the perl
libperl.so, the problem can be made to dissapear, as ld.so then knows
that there is a dependency between the XS module and the perl libperl.so

> > I think the linker is in error here for not adding the dependency on
> > the library and that is what should be fixed...

Nope, the *programmer* (or in this case, MakeMaker) is in error for not
specifying the dependency when the XS .so module was built.

Here's what one of our linker developers has to say about the subject:

[You may be assuming that]

> ii) the action of dlopen()'ing an object (say B.so) from an object
> (say A.so) creats a binding between the two objects that insure
> the latter cannot be deleted before the formed is deleted.
> This isn't the case.  ld.so.1 maintains bindings/refence counts
> etc. between the objects it has control over - ie. a relocation
> in one object that references another.  The dlopen() family are
> thought of as user code, and we do not try to interprete how
> objects are bound that use these facilities.  In fact we can
> get in all sorts of issues if we do - a handle, just like a
> function pointer, can be handed to other objects, thus who
> knows what object *expects* another object to be in existance.

i.e. if you decide to use dlopen/dlclose and you screw it up, then it is
*your* fault, not the linkers.  The fact that so many different systems
show the same behaviour suggests that this is a common linker design
decision.

I actually think that the real fault is in DynaLoader.  If you assume
that the exiting of the perl interpreter is the same thing as the exit
of the program, then it makes sense not to dlclose anything, as it will
all be reclaimed on exit anyway.  However, if you embed perl inside an
application, the exit of the perl interpreter is certainly *not* the
same thing as the program exiting, and DynaLoader should explicily
dlclose all the files it has dlopened.

I'm going to submit this as a bug to p5p.

Alan Burlison

Re: Why does Apache do this braindamaged dlclose/dlopen stuff?

[Alan Burlison]

Gerald Richter wrote:

> This works only if this dependencies are know at link time, but look at the
> source of Dynloader. You can retrieve address of any (public)symbol inside a
> library dynamicly at runtime. Now you have the entry address and can pass it
> around. No linker will ever have a chance to know what you do in your
> programm. As soon as you use such things (and Dynloader uses them), the
> linker doesn't have chance!

Nope, that's not how it works.  Take a look at
http://docs.sun.com:80/ab2/coll.45.10/LLM/@Ab2PageView/5121

*All* symbols in a shared library are known by ld.so

Alan Burlison

Re: Why does Apache do this braindamaged dlclose/dlopen stuff?

[Alan Burlison]

Gerald Richter wrote:

> That's the same on NT. It seems to occur on all OSs, so it won't help
> anything to make the linker responsible, there are to much linkers... and I
> am not sure if the linker can know under all circumstances which libraries
> to unload.

Yes it can.  Its main job is to keep track and control the dependencies
between libraries.  It's just that sometimes thy don't do a particularly
good job of it ;-)

> I don't think we will convice the Apache people in the short term, that they
> shouldn't unload the libraries (also we can discuss it with them). The only
> practical solution I see, is the one to unload the libraries, as the patch
> already does. The thing left to do is to port it to other OS's (like NT)
> which does not have a function named dlclose (we need simply use another
> name). This solution will work and if the Apache people one time decide to
> not unload the modules, it won't hurt.

I think they should be persuaded - this is a very insiduous bug and
extremely hard to find.

> P.S. Does you get any feedback from your post to p5p about the unload
> function in Dynaloader?

No.  Nothing meaningful.

Alan Burlison

Re: Why does Apache do this braindamaged dlclose/dlopen stuff?

[Alan Burlison]

Daniel Jacobowitz wrote:
> 
> On Tue, Jan 18, 2000 at 08:03:42PM +, Alan Burlison wrote:
> > The current fix is to forcibly unload the perl XS modules during the
> > unload.  However, on reflection I'm not at all sure this is the correct
> > thing to do.  Although you can unload the .so component of a perl
> > module, you can't unload the .pm component, so just removing the .so
> > part as in the current workaround is suspect at least.
> 
> Remember - mod_perl is being unloaded.  Perl going away.  At this point
> perl_destruct/perl_free have already been called, and thus the .pm
> components are effectively unloaded.

Ah yes, so they are.  I still think dlclosing for no good reason sucks
though.

Alan Burlison