--- Geoffrey Young <geoff@...> wrote:
>     testing php with perl

What kind of nonsense is that? :-)

Chris

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

You're right: both methods (content_languages() and
content_language()) work on the Apache object, although
only content_languages() is documented (perldoc Apache)!

Since Apache::FakeRequest wants to be a complete fake
object, it should implement both methods as well, I think.
Hence, the patch would be to add content_languages()
instead of replacing content_language().

-- Thomas

Um Fri, 27 Aug 2004 19:25:41 -0700
  schrieb Stas Bekman <stas@...>:
> Thomas Lochmatter wrote:
> > (ModPerl 1.29, Apache.pm 1.27, FakeRequest.pm 1.00)
> >
> > In the Apache::FakeRequest module, there is a method
> called
> > "content_language". The Apache module however calls
> this
> > method "content_languages".
> >
> > I guess this is a bug. It could be corrected by
> changing
> > FakeRequest.pm, line 20:
> > <  content content_encoding content_language
> >
> >> content content_encoding content_languages
>
> Why do you think it's a bug? there are both
> content_language and content_languages in
> src/modules/perl/Apache.xs:
>
> char *
> content_language(r, ...)
>      Apache r
>
>      CODE:
>      get_set_PVp(r->content_language,r->pool);
>
>      OUTPUT:
>      RETVAL
>
> void
> content_languages(r, avrv=Nullsv)
>      Apache r
>      SV *avrv
>
>      PREINIT:
>      I32 gimme = GIMME_V;
>
>      CODE:
>      if(avrv && SvROK(avrv))
>          r->content_languages = avrv2array_header(avrv,
> r->pool);
>
>      if(gimme != G_VOID)
>          ST(0) = array_header2avrv(r->content_languages);
>
> --
>
__________________________________________________________________
> Stas Bekman            JAm_pH ------> Just Another
> mod_perl Hacker
> http://stason.org/     mod_perl Guide --->
> http://perl.apache.org
> mailto:stas@... http://use.perl.org
> http://apacheweek.com
> http://modperlbook.org http://apache.org
>   http://ticketmaster.com


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

I am trying (as a starting test) to replace some apache directives by
mod_perl's syntax, so i can hopefully easily yank in specific perl
functions.

Running apache 2.0.50
Mod_perl 1.99
On a debian sarge machine.

All compiled by hand and no errors during compilation/installation.

included in httpd.conf :

	 LoadModule perl_module modules/mod_perl.so
	 PerlModule Apache2

Then i made a vhost according to the example's on perl.apache.org and
included also a snippet of
simple authentication that is there.

<Perl>
   use Apache2 ();
   use Apache::PerlSections ();

       $VirtualHost{"0.0.0.0"} = {
       ServerName => 'test01',
       DAVLockDB => '/tmp/lock.db',
       Documentroot => '/usr/local/apache-dav/htdocs/DAVTEST',
           $Directory{"/usr/local/apache-dav/htdocs/DAVTEST"} = {
           AuthUserFile   => '/tmp/htpasswd',
           AuthType       => 'Basic',
           AuthName       => 'test',
           DirectoryIndex => [qw(index.html index.htm)],
           AllowOverride => 'None',
           Limit          => {
                  METHODS => 'GET POST',
                  require => 'valid-user',
                  Order => 'allow,deny',
                  Allow => 'from all',
                       },
         },
};
print Apache::PerlSections->dump;
</Perl>

If i use these directives 'plain' apache style they work flawless, i
must supply a password when browsing to the directory or when i mount
the webdav.

When used with mod_perl i can enter the directory without
authentication, and the same goes for webdav, no authentiction needed.
Tho the vhost i created works like a charm.

What am i doing wrong?


Thanx in advance.

Martijn van Buytene




--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Hi All,

I am getting the following error:

  Can't locate object method "server_hostname" via package "Apache::ServerRec" at
... 300.\n\t..., 'Apache::RequestRec=SCALAR(0x881968)') called
at -e line 0\n\teval {...} called at -e line 0\n

The line concerned is:

         my $host_name = $r->server->server_hostname;

What's changed?

Regards,



Jie

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

>  Can't locate object method "server_hostname" via package
> "Apache::ServerRec" at
> ... 300.\n\t..., 'Apache::RequestRec=SCALAR(0x881968)') called
> at -e line 0\n\teval {...} called at -e line 0\n
>
> The line concerned is:
>
>         my $host_name = $r->server->server_hostname;

http://perl.apache.org/docs/2.0/api/Apache/ServerRec.html#C_server_hostname_

HTH,

Fred




--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

hello

i use Apache-authenNTLM-2.07 with mod_perl 1.99.14 and windows 2000: it
was ok.

Now i have format my windows 2000, and make a new install.
install the new version of mod perl 1.99_16 on the linux.
and it  don't work !

error msg:
[Wed Sep 01 14:59:35 2004] [error] [client 192.168.0.3] Usage:
Apache::Connection::remote_host(obj) at
/usr/local/lib/perl5/site_perl/5.8.5/i686-linux/Apache/AuthenNTLM.pm
line 534.\n, referer: http://mysite.com/cgi-bin/banniere.pl?langue=fr

so my question is :
does some one use Apache-authenNTLM-2.07 with mp1.99_16 ?

thank
Arnaud.


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

On 1-Sep-04, at 3:57 AM, M.v.Buytene wrote:

>          Limit          => {
>                 METHODS => 'GET POST',
>                 require => 'valid-user',
>                 Order => 'allow,deny',
>                 Allow => 'from all',
>          },


Apparently, the documentation is wrong (which is why I
ended up fixing mod_info and creating the mod_info/mod_perl
patch I announced a couple of days ago.

The following works:

           Limit => {
             'GET POST' => {
                  require => 'valid-user',
                  Order => 'allow,deny',
                  Allow => 'from all',
              },
           }

---------
Rici
Apache hacks at: <http://rici.ricilake.net/src>


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

>>  Can't locate object method "server_hostname" via package
>> "Apache::ServerRec" at
>> ... 300.\n\t..., 'Apache::RequestRec=SCALAR(0x881968)') called
>> at -e line 0\n\teval {...} called at -e line 0\n
>>
>> The line concerned is:
>>
>>         my $host_name = $r->server->server_hostname;
>
> http://perl.apache.org/docs/2.0/api/Apache/ServerRec.html#C_server_hostname_

That answer I just gave was not obvious in its statement of the solution
to your problem.  What you appear to be missing is:

use Apache::ServerRec();

Thank you,

Fred

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

-------------8<---------- Start Bug Report ------------8<----------
1. Problem Description:

make test fails on one of the tests -

t/filter/in_error.......................malformed response at
/usr/local/apache2/build/mod_perl-1.99_16/blib/lib/Apache/TestClient.pm line
102.
t/filter/in_error.......................NOK 1# Failed test 1 in
t/filter/in_error.t at line 13
t/filter/in_error.......................FAILED test 1
         Failed 1/1 tests, 0.00% okay

On a different note, for some very odd reason, sometimes the httpd process does
not start for testing and other times it does.
I have tried the compilation several times with exact same parameters, and I
still cannot pinpoint a reason why that happens.

Thanks in advance for any pointers.

2. Used Components and their Configuration:

*** mod_perl version 1.9916

*** using /usr/local/apache2/build/mod_perl-1.99_16/lib/Apache/BuildConfig.pm

*** Makefile.PL options:
   MP_APR_LIB     => aprext
   MP_APXS        => /usr/local/apache2/bin/apxs
   MP_COMPAT_1X   => 1
   MP_DEBUG       => 1
   MP_GENERATE_XS => 1
   MP_LIBNAME     => mod_perl
   MP_TRACE       => 1
   MP_USE_DSO     => 1
   MP_USE_STATIC  => 1


*** /usr/local/apache2/bin/httpd -V
Server version: Apache/2.0.50
Server built:   Aug 31 2004 15:02:12
Server's Module Magic Number: 20020903:8
Architecture:   32-bit
Server compiled with....
  -D APACHE_MPM_DIR="server/mpm/prefork"
  -D APR_HAS_SENDFILE
  -D APR_HAS_MMAP
  -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
  -D APR_USE_PROC_PTHREAD_SERIALIZE
  -D APR_USE_PTHREAD_SERIALIZE
  -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
  -D APR_HAS_OTHER_CHILD
  -D AP_HAVE_RELIABLE_PIPED_LOGS
  -D HTTPD_ROOT="/usr/local/apache2/"
  -D SUEXEC_BIN="/usr/local/apache2//bin/suexec"
  -D DEFAULT_PIDLOG="logs/httpd.pid"
  -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
  -D DEFAULT_LOCKFILE="logs/accept.lock"
  -D DEFAULT_ERRORLOG="logs/error_log"
  -D AP_TYPES_CONFIG_FILE="conf/mime.types"
  -D SERVER_CONFIG_FILE="conf/httpd.conf"


*** (apr|apu)-config linking info

  -L/usr/local/apache2//lib -lapr-0 -lsendfile -lrt -lm -lsocket -lnsl -lresolv 
-lpthread -ldl
  -L/usr/local/apache2//lib -laprutil-0 -lgdbm -lexpat -liconv



*** /usr/local/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
   Platform:
     osname=solaris, osvers=2.8, archname=sun4-solaris
     uname='sunos 5.8 generic_108528-11 sun4u sparc sunw,ultra-5_10 solaris '
     config_args='-Dcc=gcc -B/usr/ccs/bin/'
     hint=recommended, useposix=true, d_sigaction=define
     usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
     useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
     use64bitint=undef use64bitall=undef uselongdouble=undef
     usemymalloc=n, bincompat5005=undef
   Compiler:
     cc='gcc -B/usr/ccs/bin/', ccflags ='-fno-strict-aliasing
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
     optimize='-O',
     cppflags='-fno-strict-aliasing -I/usr/local/include'
     ccversion='', gccversion='3.3.2', gccosandvers='solaris2.8'
     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
     d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
     ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
     alignbytes=8, prototype=define
   Linker and Libraries:
     ld='gcc -B/usr/ccs/bin/', ldflags =' -L/usr/local/lib '
     libpth=/usr/local/lib /usr/lib /usr/ccs/lib
     libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc
     perllibs=-lsocket -lnsl -ldl -lm -lc
     libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so
     gnulibc_version=''
   Dynamic Linking:
     dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='  -R
/usr/local/lib/perl5/5.8.3/sun4-solaris/CORE'
     cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'


Characteristics of this binary (from libperl):
   Compile-time options: USE_LARGE_FILES
   Built under solaris
   Compiled at Feb 10 2004 05:55:05
   %ENV:
     PERL_LWP_USE_HTTP_10="1"
   @INC:
     /usr/local/lib/perl5/5.8.3/sun4-solaris
     /usr/local/lib/perl5/5.8.3
     /usr/local/lib/perl5/site_perl/5.8.3/sun4-solaris
     /usr/local/lib/perl5/site_perl/5.8.3
     /usr/local/lib/perl5/site_perl
     .

*** Packages of interest status:

Apache::Request: -
CGI            : 3.01
LWP            : -
mod_perl       : -


3. This is the core dump trace: (if you get a core dump):

(gdb) bt
#0  apr_cpystrn (dst=0xffbef010 "", src=0x0, dst_size=4290703375)
     at apr_cpystrn.c:57
#1  0xff1d4c4c in stuffbuffer (buf=0xffbeef10 "", bufsize=256, s=0x0)
     at errorcodes.c:34
#2  0xfee074f0 in modperl_error_strerror (rc=500) at modperl_error.c:37
#3  0xfe990c90 in XS_APR__Error_strerror (cv=0x1f4) at Error.xs:36

bash-2.03# t/TEST -verbose t/filter/in_error.t
[   info] consider removing an old /usr/local/apache2/build/mod_perl-1.99_16/t/c
ore file before running tests
[warning] root mode: changing the files ownership to 'nobody' (60001:60001)
[warning] testing whether 'nobody' is able to -rwx /usr/local/apache2/build/mod_
perl-1.99_16/t
"/usr/local/bin/perl" -Mlib=/usr/local/apache2/build/mod_perl-1.99_16/Apache-Tes
t/lib -MApache::TestRun -e 'eval { Apache::TestRun::run_root_fs_test(60001, 6000
1, q[/usr/local/apache2/build/mod_perl-1.99_16/t]) }';


[warning] result: OK
[warning] the client side drops 'root' permissions and becomes 'nobody'
/usr/local/apache2/bin/httpd -d /usr/local/apache2/build/mod_perl-1.99_16/t -f /
usr/local/apache2/build/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2
using Apache/2.0.50 (prefork MPM)

waiting 120 seconds for server to start: .[Wed Sep 01 10:14:17 2004] [info] 27 A
pache:: modules loaded
[Wed Sep 01 10:14:17 2004] [info] 7 APR:: modules loaded
[Wed Sep 01 10:14:17 2004] [info] base server + 20 vhosts ready to run tests
...
waiting 120 seconds for server to start: ok (waited 3 secs)
server localhost:8529 started
server localhost:8530 listening (TestModperl::setupenv)
server localhost:8531 listening (TestModperl::merge)
server localhost:8532 listening (TestModperl::perl_options)
server localhost:8533 listening (TestVhost::config)
server localhost:8534 listening (TestProtocol::pseudo_http)
server localhost:8535 listening (TestProtocol::echo_filter)
server localhost:8536 listening (TestProtocol::echo_bbs2)
server localhost:8537 listening (TestProtocol::echo_bbs)
server localhost:8538 listening (TestProtocol::echo_timeout)
server localhost:8539 listening (TestProtocol::echo_block)
server localhost:8540 listening (TestPreConnection::note)
server localhost:8541 listening (TestHooks::startup)
server localhost:8542 listening (TestHooks::stacked_handlers2)
server localhost:8543 listening (TestHooks::hookrun)
server localhost:8544 listening (TestFilter::in_bbs_msg)
server localhost:8545 listening (TestFilter::both_str_con_add)
server localhost:8546 listening (TestFilter::in_bbs_inject_header)
server localhost:8547 listening (TestFilter::in_str_msg)
server localhost:8548 listening (TestDirective::perlrequire)
server localhost:8549 listening (TestDirective::perlmodule)
server localhost:8550 listening (TestDirective::perlloadmodule4)
server localhost:8551 listening (TestDirective::perlloadmodule5)
server localhost:8552 listening (TestDirective::perlloadmodule3)
server localhost:8553 listening (TestDirective::perlloadmodule6)
t/filter/in_error....1..1
# Running under perl version 5.008003 for solaris
# Current time local: Wed Sep  1 10:14:21 2004
# Current time GMT:   Wed Sep  1 14:14:21 2004
# Using Test.pm version 1.24
# Using Apache/Test.pm version 1.14
malformed response at /usr/local/apache2/build/mod_perl-1.99_16/blib/lib/Apache/
TestClient.pm line 102.
# testing : an error in a filter should cause 500
# expected: 500
# received: undef
not ok 1
# Failed test 1 in t/filter/in_error.t at line 13
FAILED test 1
         Failed 1/1 tests, 0.00% okay
Failed Test         Stat Wstat Total Fail  Failed  List of Failed
-------------------------------------------------------------------------------
t/filter/in_error.t                1    1 100.00%  1
Failed 1/1 test scripts, 0.00% okay. 1/1 subtests failed, 0.00% okay.
[warning] server localhost:8529 shutdown
[  error] error running tests (please examine t/logs/error_log)
[  error] oh darn, server dumped core
[  error] for stacktrace, run: gdb /usr/local/apache2/bin/httpd -core /usr/local
/apache2/build/mod_perl-1.99_16/t/core



This report was generated by t/REPORT on Tue Aug 31 19:13:57 2004 GMT.

-------------8<---------- End Bug Report --------------8<----------

Note: Complete the rest of the details and post this bug report to
modperl <at> perl.apache.org. To subscribe to the list send an empty
email to modperl-subscribe@...


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

On Tue, Aug 31, 2004 at 08:41:10PM -0700, Ben Hopkins wrote:
> 2:  I added /perl-status and got a 404 error, just like I get for
> /server-status, /server-info, and /howdy locations.  _It's exactly as if
> mod_perl were not installed!_
>
> Wait a minute!  It is exactly as if the "SetHandler" directive is always
> ignored.  (Which is why /server-status and /server-info do not work.)  I
> don't remember if they worked before this.  Is it possible that I forgot
> something that implements SetHandler???

According to your OP, PERL_HANDLER is enabled. I think that you are
right; mod_perl is not properly installed. Have you tried building
without mod_proxy to see if it works? Unfortunately, I can't be of much
further help. I use ApacheToolbox to build my Apache httpd and do not
know enough about APACI et al. to offer further advice.


Good luck,
William

--
Knowmad Services Inc.
http://www.knowmad.com

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

On Tue, 31 Aug 2004, Alex Oboimov wrote:

> Hi folks,
>
> I'm fresh to Apache2/mod-perl2, just migrated from
> mp1.
>
> My system: Apache 2.049/Perl 5.8.4/mod_perl
> 1.99_14/DBI 1.42/DBD::InterBase/FireBird 1.5 on
> linux Mandrake 9.2 engine.
>
> My problem: my old programs were fine in the old
> system. Now after major editing of the programs
> they work except for files uploading that
> does not work properly.
>
> After parsing my multipart/form data I get $buffer
> with file's content, then I twice 'chop' it (for
> extra '\r\n' symbols) & put it in my SQL statement.
> The program executes fine but after downloading
> the file of 'application/msword' type is unusable
> while all other types (zip, rar, pdf, jpg et
> al) download just OK. The file becomes two bytes
> longer and is not recognized as .doc type.
>
> What the reason might be? I suspect that some
> settings in httpd.conf might preclude some sort of
> conversion for this sort of files. Any suggestions?

Are you using libapreq2 to handle the file upload?
Or something else?

Does this problem arise for clients both on Unix and
Windows? Is it browser-specific?

Do you know at what stage the corruption in the .doc
file occurs (eg, on upload, storing it in the database,
or on download)?

Do you know why the extra \r\n occur? Normally these are an
issue only with text files, in going between Unix and
Windows - one might think that for binary files no such
mangling need be done (as long as all appropriate handling
of the files at all stages is done in binary mode, if
applicable). If you don't chop(), is there a difference
between how .doc and other binary (eg, .zip) files are
handled?

--
best regards,
randy kobes

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

On Tue, 31 Aug 2004, Craig Dayton wrote:

>
> Does anyone have an idea how to resolve either of the following errors when
> building libapreq2-2.04_03-dev on either a Windows 2000 Server or on Windows
> XP Pro (SP2)?
>
> Thanks, Craig
>
>
> Windows 2000 Server
> Apache/2.0.49 mod_perl/1.99_15 perl/v5.8.4
>
> The build process on W2K Server made it all the way to the 'nmake perl_glue'
> step on returned the following message.
>
> E:/Projects\libapreq2-2.04-dev\glue\perl\xsbuilder\Apache\Upload\Apache__Upl
> oad.
> h(20) : fatal error C1083: Cannot open include file:
> 'modperl_common_util.h': No such file or directory

I've cc'd the apreq list on this ...

The modperl_common_util.h header file should have been
copied over to your $APACHE2\include directory when you
installed mod_perl (assuming you compiled mod_perl yourself,
and are using a version >= 1.99_15). Is there a file
$APACHE2\include\modperl_common_util.h on your system (where
$APACHE2 is the root of your Apache2 installation)?

> ============================================================================
>
> Windows XP Professional SP2
> Apache/2.0.49 mod_perl/1.99_16 perl/v5.8.4
>
> After the 'nmake test' step the following error messages below were was
> returned. For some reason the 'nmake test' process thinks the root directory
> for Apache2 is on drive D: which in this case is a CD-ROM even though root
> directory has been explictly specified.
>
> >perl makefile.pl --with-apache2=E:\Apache2
> .
> .
> .
> Microsoft (R) Program Maintenance Utility Version 7.10.3077
> Copyright (C) Microsoft Corporation.  All rights reserved.
> .
> .
> >nmake test
>
> 22 tests run:  22 passed, 0 failed, 0 not implemented.
>
>         cd E:\Projects\LIBAPR~1.04-
>         nmake /nologo /f E:\Projects\LIBAPR~1.04-\win32\test_cgi.mak
> CFG="test_c
> gi - Win32 Release" APACHE="E:\Apache2"
> APREQ_HOME="E:\Projects\LIBAPR~1.04-" AP
> R_LIB="E:\Apache2\lib\libapr.lib" APU_LIB="E:\Apache2\lib\libaprutil.lib"
>         cl.exe /nologo /MD /W3 /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D
> "_MBC
> S" /I"E:\Apache2\include" /I"E:\Projects\LIBAPR~1.04-\src"
> /Fp"E:\Projects\LIBAP
> R~1.04-\win32\libs\test_cgi.pch" /YX
> /Fo"E:\Projects\LIBAPR~1.04-\win32\libs\\"
> /Fd"E:\Projects\LIBAPR~1.04-\win32\libs\\" /FD /c
> E:\Projects\LIBAPR~1.04-\env\t
> est_cgi.c
> test_cgi.c
>         link.exe @E:\DOCUME~1\cadayton\LOCALS~1\Temp\nm42.tmp
>         if not exist "E:\Projects\LIBAPR~1.04-\env\t\cgi-bin" mkdir
> "E:\Projects
> \LIBAPR~1.04-\env\t\cgi-bin"
>         copy E:\Projects\LIBAPR~1.04-\win32\libs\test_cgi.exe
> E:\Projects\LIBAPR
> ~1.04-\env\t\cgi-bin\test_cgi.exe
>         1 file(s) copied.
>         cd E:\Projects\LIBAPR~1.04-
>         cd E:\Projects\LIBAPR~1.04-\env
>         E:\Perl\bin\perl.exe t\TEST.PL -apxs E:\Apache2\bin\apxs.bat
> [  debug] loading custom config data from:
> 'E:\Perl\site\lib\Apache\TestConfigData.pm'
> [  debug] overlaying custom config data
> APXS (E:\Apache2\bin\apxs.bat) query for SBINDIR failed
> APXS (E:\Apache2\bin\apxs.bat) query for TARGET failed
> APXS (E:\Apache2\bin\apxs.bat) query for SYSCONFDIR failed
>
> *** at this point a dialog appear request to mount drive D ***
>
> [  debug] configuring httpd
> [  debug] can't figure out Apache revision, from string: '', using a
> non-existin
> g revision 0
> [  debug] generating ..\c-modules\apache_httpd_test.h
> [  error] configure() has failed:
> Can't figure out what Apache server generation we are running at
> E:/Perl/site/lib/Apache/TestServer.pm line 98.
>
> [warning] forcing Apache::TestConfig object save
> [  debug] generating conf\apache_test_config.pm
> [  debug] saving config data to apache_test_config.pm
> [warning] run 't/TEST -clean' to clean up before continuing
> NMAKE : fatal error U1077: 'E:\Perl\bin\perl.exe' : return code '0x1'
> Stop.

I'm not sure what the problem is here - all of the Apache
references above use E:\ as the drive, which appears
correct. When you did the 'perl Makefile.PL', did a
confirmation come up asking you which Apache to use? If so,
was it the correct one, including the drive letter?

Do you have an Apache/TestConfigData.pm somewhere on your
system, either in the main Perl tree or under a .apache-test
directory under, eg, C:\ or E:\? If so, does it help if you
move it out of the way and run the tests again?

--
best regards,
randy kobes

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Thomas Lochmatter wrote:
> You're right: both methods (content_languages() and
> content_language()) work on the Apache object, although
> only content_languages() is documented (perldoc Apache)!
>
> Since Apache::FakeRequest wants to be a complete fake
> object, it should implement both methods as well, I think.
> Hence, the patch would be to add content_languages()
> instead of replacing content_language().

FakeRequest is really kinda painful.  is there any reason why you aren't
using Apache-Test to create a live testing environment instead?

   http://search.cpan.org/dist/Apache-Test/

--Geoff

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Chris Shiflett wrote:
> --- Geoffrey Young <geoff@...> wrote:
>
>>    testing php with perl
>
>
> What kind of nonsense is that? :-)

yeah, I was surprised to see this talk in the lineup.  I mean, who cares
about testing, let alone some boring scripting languages?

--Geoff

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Scott Fagg wrote:
> I have lines like this in my .htaccess file :
>
> AuthName AD
> AuthType Arup::AuthCkLDAP
>
> PerlSetVar ADPath /
> PerlSetVar ADLoginScript /login.perl
>
> .. and i'm using AuthCookie.pm. It picks up on the 'AD' value for
> AuthName, but cannot see the PerlSetVar values.

PerlSetVar merging is currently broken, specifically for multiple
inheritance (like .htaccess files and <Location />) - see the archives if
you want the long explanation.  I really, really plan to fix this "soonish."
  look for it in the next mod_perl release, or in early october in CVS.

sorry for the headaches.

--Geoff

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

On Mon, 2004-08-30 at 14:12, Perrin Harkins wrote:

> The truth is that mod_perl uses the same amount of memory that Perl CGI
> scripts use. The difference is that CGI scripts exit as soon as they
> finish. Serving 10 simultaneous requests with CGI requires the same
> amount of memory as it does with mod_perl (with a small amount extra for
> the apache interface modules). You can do things under mod_perl like
> load tons of stuff into a global variable, but that would be the
> programmer's fault, not mod_perl's.

That's not entirely true. It is in fact the case that mod_perl's
*upper-bound* on memeroy usage is similar to the equivalent script
runnung as a cgi.

A well designed mod_perl application loads as many shared libraries as
possible before Apache forks off the child processes. This takes
advantage of the standard "copy-on-write" behavior of the fork() system
call; meaning that only the portions of the process memory that differ
from the parent will actually take up extra memory, the rest is shared
with the parent until one of them tries to write to that memory, at
which time it is copied before the change is made, effectively
"unsharing" that chunck of memory.

Unfortunately, it's not a perfect world, and the Perl interpreter isn't
perfect either: it mixes code and data segments together throughout the
process address space. This has the effect that as the code runs and
variables/structures are changed, some of the surrounding code segments
in the memory space are swept up into the memory chunks during a
copy-on-write, thereby slowly duplicating the memory between processes
(where the code would ideally be indefinitely shared).
Fortunately, Apache has a built in defence against this memory creep:
the MaxRequestsPerChild directive forces a child process to die and
respawn after a certain number requests have been served, thereby
forcing the child process to "start fresh" with the maximum amount of
shared memory.

In the long run, this means that if you pre-load as many shared
libraries as possible and tweak the MaxRequestsPerChild directive,
you'll probably see significantly less memory usage on average. Not to
mention all the other speed and efficiency increases that you're already
mod_perl provides.

j

>
> That's not entirely true. It is in fact the case that mod_perl's
> *upper-bound* on memeroy usage is similar to the equivalent script
> runnung as a cgi.
>
> A well designed mod_perl application loads as many shared libraries as
> possible before Apache forks off the child processes. This takes
> advantage of the standard "copy-on-write" behavior of the fork() system
> call; meaning that only the portions of the process memory that differ
> from the parent will actually take up extra memory, the rest is shared
> with the parent until one of them tries to write to that memory, at
> which time it is copied before the change is made, effectively
> "unsharing" that chunck of memory.
>
> Unfortunately, it's not a perfect world, and the Perl interpreter isn't
> perfect either: it mixes code and data segments together throughout the
> process address space. This has the effect that as the code runs and
> variables/structures are changed, some of the surrounding code segments
> in the memory space are swept up into the memory chunks during a
> copy-on-write, thereby slowly duplicating the memory between processes
> (where the code would ideally be indefinitely shared).
> Fortunately, Apache has a built in defence against this memory creep:
> the MaxRequestsPerChild directive forces a child process to die and
> respawn after a certain number requests have been served, thereby
> forcing the child process to "start fresh" with the maximum amount of
> shared memory.

The bigger problem is that if one of the modules you include in the
pre-fork is foobarred you may/will not be able to start the server...

> In the long run, this means that if you pre-load as many shared
> libraries as possible and tweak the MaxRequestsPerChild directive,
> you'll probably see significantly less memory usage on average. Not to
> mention all the other speed and efficiency increases that you're already
> mod_perl provides.

Apache::SizeLimit is a better approach as it only reaps large children!!

> j
>
>
>
> --
> Martin@... (please don't reply to @yahoo)
>
>
> ---------------------------------
> Post your free ad now! Yahoo! Canada Personals
>

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Coming to a CPAN mirror near you. Please download it and test.. the
test. Thanks!

1.70_01    2004-09-01

   - Casey West takes the pumpkin.
   - Complete rewrite of test suite to use Test::* modules.
   - Minor documentation tweaks.

   Casey West

--
I'd wipe the machines off the face of the earth again, and end the
industrial epoch absolutely, like a black mistake.
  -- D. H. Lawrence


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

On Wed, 1 Sep 2004, Fred Moyer wrote:

> Date: Wed, 1 Sep 2004 07:02:21 -0700 (PDT)
> From: Fred Moyer <fred@...>
> To: Fred Moyer <fred@...>
> Cc: Jie Gao <j.gao@...>, modperl@...
> Subject: Re: [mp2] 1.99_16 problem
>
>
> >>  Can't locate object method "server_hostname" via package
> >> "Apache::ServerRec" at
> >> ... 300.\n\t..., 'Apache::RequestRec=SCALAR(0x881968)') called
> >> at -e line 0\n\teval {...} called at -e line 0\n
> >>
> >> The line concerned is:
> >>
> >>         my $host_name = $r->server->server_hostname;
> >
> > http://perl.apache.org/docs/2.0/api/Apache/ServerRec.html#C_server_hostname_
>
> That answer I just gave was not obvious in its statement of the solution
> to your problem.  What you appear to be missing is:
>
> use Apache::ServerRec();

Thanks very much; I found that out eventually last night. I am using it
for production; sort of in a rush to get it work.

Regards,



Jie

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Stas Bekman wrote:


> I'd suggest to completely nuke /usr/local/apache2, install Apache from
> scratch and chances are that everything will work fine. You have too
> many old libs there.

I did that, and still had the same problem.  I ended up setting
LD_LIBRARY_PATH to /usr/local/apache2/lib and it was all ok
again.

I've also moved my code to using apreq2, instead of the Stas &
Carl hack job I was running :) (I cheated and used a wrapper change,
so I didn't have to do wholesale changes to my code).

Out of curiosity, is anyone working on docs for apreq2 for
people in a hurry? :)  Ie: with simple examples in it?

Carl



--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Before I take the plunge and write my own, has anyone
here written, or know of, any web forum s/w that runs
under mp2 without using compat?  I know web forums are
kinda evil, but I've got a genuine use for one where I
need to be able to control access to it.

thanks!

Carl



--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Carl Brewer wrote:
> Before I take the plunge and write my own, has anyone
> here written, or know of, any web forum s/w that runs
> under mp2 without using compat?

http://www.mwforum.org/


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Rici Lake wrote:

> On 31-Aug-04, at 10:41 PM, Ben Hopkins wrote:
> ...
> I could be way out to lunch here, but what section of your site are
> you proxying?
>
> mod_proxy causes any SetHandler in a proxied location to be ignored.
> In fact, it
> causes any handler in a proxied location to be ignored, since it jumps
> in before
> any handler runs.


_That_ makes a lot of sense, but I'll have to check out the question
about "what section of your site are you proxying?" because I know
nothing about proxying except that Zope needs it.

Here is the code from httpd.conf that deals with mod_proxy.  I added the
<Directory> statement on the advise of Apache Cookbook.

I also commented-out the line saying "Allow from .my.site" thinking that
stopping proxying would stop this effect, but it didn't.

# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
<IfModule mod_proxy.c>
     ProxyRequests On

     <Directory proxy:*>
         Order deny,allow
         Deny from all
#       Allow from .my.site
         RewriteEngine On
         RewriteRule "^proxy:[a-z]*://[^/]*:25(/|$)" "-" [F,NC,L]
     </Directory>

     #
     # Enable/disable the handling of HTTP/1.1 "Via:" headers.
     # ("Full" adds the server version; "Block" removes all outgoing Via:
headers)
     # Set to one of: Off | On | Full | Block
     #
     ProxyVia On

     #
     # To enable the cache as well, edit and uncomment the following lines:
     # (no cacheing without CacheRoot)
     #
     CacheRoot "/usr/local/apache/proxy"
     CacheSize 5
     CacheGcInterval 4
     CacheMaxExpire 24
     CacheLastModifiedFactor 0.1
     CacheDefaultExpire 1
     NoCache .my.site
</IfModule>
# End of proxy directives.

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Markus Wichitill wrote:
> http://www.mwforum.org/

I'm pleased to see this is still being maintained and is up-to-date for
mp2.  I looked at it once before, but was worried I wouldn't be able to
customize the appearance of it because it doesn't use templates.  It
looks like there are still no templates.  Do you have an alternate
approach for modifying the look and feel?  I'm not just asking to be
difficult -- I have a need for this kind of app now and then, and things
like Scoop seem too heavy for just adding a tiny discussion section to a
site.

- Perrin

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

William McKee wrote:

>On Tue, Aug 31, 2004 at 08:41:10PM -0700, Ben Hopkins wrote:
>
>
>>2:  I added /perl-status and got a 404 error, just like I get for
>>/server-status, /server-info, and /howdy locations.  _It's exactly as if
>>mod_perl were not installed!_
>>
>>Wait a minute!  It is exactly as if the "SetHandler" directive is always
>>ignored.  (Which is why /server-status and /server-info do not work.)  I
>>don't remember if they worked before this.  Is it possible that I forgot
>>something that implements SetHandler???
>>
>>
>
>According to your OP, PERL_HANDLER is enabled. I think that you are
>right; mod_perl is not properly installed. Have you tried building
>without mod_proxy to see if it works? Unfortunately, I can't be of much
>further help. I use ApacheToolbox to build my Apache httpd and do not
>know enough about APACI et al. to offer further advice.
>
>
I just re-built apache, using the method described above, but without
the --enable-module=proxy directive.  I was really up, _this_ was going
to do it  (see the explanation given by Rici in another post in this
chain).  But it didn't change a thing, except now, the output of "httpd
-l" is different (no mod-proxy).  There're piles of hair on the floor
around my chair, and the plasterboard covering the walls here is covered
with cracks and holes.

Here is the output from httpd -l

Compiled-in modules:
   http_core.c
   mod_env.c
   mod_log_config.c
   mod_mime.c
   mod_negotiation.c
   mod_status.c
   mod_include.c
   mod_autoindex.c
   mod_dir.c
   mod_cgi.c
   mod_asis.c
   mod_imap.c
   mod_actions.c
   mod_speling.c
   mod_userdir.c
   mod_alias.c
   mod_rewrite.c
   mod_access.c
   mod_auth.c
   mod_expires.c
   mod_so.c
   mod_setenvif.c
   mod_perl.c


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

On Wed, 1 Sep 2004, Craig Dayton wrote:

> Hi Randy,
>
> For the Windows 2000 Server system its running mod_perl/1.99_14, so this
> explains the missing file problem.  The current mod_perl will get built on
> this system.

Great - that should resolve that problem ...

> >
> >I'm not sure what the problem is here - all of the Apache
> >references above use E:\ as the drive, which appears correct.
> >When you did the 'perl Makefile.PL', did a confirmation come
> >up asking you which Apache to use?  If so, was it the correct
> >one, including the drive letter?
>
> Yes & Yes.
>
> I tried 'perl Makefile.PL' and it found the correct Apache2 location and I
> responded 'yes' to the prompt. Also, I tried 'perl Makefile.PL
> --with-Apache2=E:/Apache2'.  In both cases its trying to find Apache on a
> another drive.  In the first instance, it was expecting Apache2 on drive Z:
> which was a valid network drive. After disconnecting the network drive Z:,
> the second attempt was expecting Apache to be on drive D: (CD-ROM).

I take it this is at the
    nmake test
stage? I can't see why it would be looking in different
drives at this point; it's already found Apache ...

>
> >> [  debug] can't figure out Apache revision, from string: '', using a
> >> non-existin g revision 0
>
> Its interesting that an empty string is referenced in the output above.
>
> >
> >Do you have an Apache/TestConfigData.pm somewhere on your
> >system, either in the main Perl tree or under a .apache-test
> >directory under, eg, C:\ or E:\? If so, does it help if you
> >move it out of the way and run the tests again?
>
> No. TestConfigData.pm is only located at 'E:\Perl\site\lib\Apache\'.
> Looking at this module, I see the following:
>
> "$Apache::TestConfigData::vars = {'httpd' => '\Apache2\bin\Apache.EXE',};"
> I tried changing this to 'E:\Apache2\bin\Apache.EXE'.  This didn't help.

What if you tried moving this file completely away?

> I tried adding 'E:\Apache2\bin' to the Path environmental variable just see
> if that might help.
> It didn't.  The 'nmake test' is still failing for the same apparent reason
> of not being able to resolve Apache2's location.  Also, I find it
> interesting that apxs.bat failed its 3 query attempts too.
>
> Thanks, Craig

The problem with apxs.bat on Win32 is related to something
that changed recently in Apache-Test; I haven't been able to
trace why these warnings are arising ...

To try to eliminate one possibility, what happens if you
move $APACHE2\bin\apxs.bat somewhere outside of the PATH,
and then do
    nmake perl_glue
    nmake perl_test
That should work - it's only the
    nmake test
target that requires apxs.

Also, there's a file $APACHE2\build\config_vars.mak with
various settings used by apxs - for those that reference a
drive, is the letter correct?

--
best regards,
randy

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Markus Wichitill wrote:

> Carl Brewer wrote:
>
>> Before I take the plunge and write my own, has anyone
>> here written, or know of, any web forum s/w that runs
>> under mp2 without using compat?
>
>
> http://www.mwforum.org/

I've played with installing this today, I'm seeing
the following in my error logs :

[Thu Sep 02 13:52:41 2004] [error] Can't locate object method
"cleanup_register" via package "APR::Pool" at
/data/www/aboc/perl/mwf/MwfMain.pm line 250.\n


I've the following in my apache2 config :

<VirtualHost 203.6.241.141:80 [3ffe:8001:5:2::5]:80>
    ServerName www.aboc.com.au
    ServerAdmin carl@...
    ServerAlias coach.bl.echidna.id.au aboc.com.au
    DocumentRoot /data/www/aboc/htdocs
    CustomLog /data/www/aboc/logs/access-log combined
    ErrorLog /data/www/aboc/logs/error-log
    # CustomLog /data/www/aboc/logs/mod_deflate deflate

    Alias /perl/ "/data/www/aboc/perl/"
    Alias /images/ "/data/www/aboc/htdocs/images/"
    Alias /admin/ "/data/www/aboc/admin/"
    Alias /mwf/ "/data/www/aboc/perl/mwf/"

    PerlModule Apache2
    PerlSwitches -T
    #PerlOptions +Parent
    PerlRequire "/data/www/aboc/etc/startup.pl"

    # CB.pm needs to be monitored!
    PerlModule Apache::Reload
    PerlInitHandler Apache::Reload
    PerlSetVar ReloadAll Off

    DeflateFilterNote Input instream
    DeflateFilterNote Output outstream
    DeflateFilterNote Ratio ratio
    <Location />
      SetOutputFilter DEFLATE
    </Location>
    <Location /perl/>
      SetOutputFilter DEFLATE
      SetHandler perl-script
      PerlResponseHandler ModPerl::Registry
      PerlOptions +ParseHeaders
      Options +ExecCGI
    </Location>

    <Location /mwf/>
      SetOutputFilter DEFLATE
      Options +ExecCGI
      SetHandler modperl
      PerlResponseHandler ModPerl::RegistryBB
      PerlOptions -GlobalRequest -SetupEnv -ParseHeaders
    </Location>
</VirtualHost>


and my startup.pl is :
# http://perl.apache.org/docs/2.0/user/config/config.html

use Apache2 ();

    use lib qw(/data/www/aboc/lib /data/www/aboc/perl/mwf);

    use ModPerl::Util (); #for CORE::GLOBAL::exit

    use Apache::RequestRec ();
    use Apache::RequestIO ();
    use Apache::RequestUtil ();

    use Apache::ServerRec ();
    use Apache::ServerUtil ();
    use Apache::Connection ();
    use Apache::Log ();

    use APR::Table ();

    use ModPerl::Registry ();

    use Apache::Const -compile => ':common';
    use APR::Const -compile => ':common';

1;



Any suggestions?  apache says :
Server: Apache/2.0.50 (Unix) mod_perl/1.99_16 Perl/v5.8.5
which should satisfy all mwf's requirements?

Carl





--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Perrin Harkins wrote:
>> http://www.mwforum.org/
>
> I'm pleased to see this is still being maintained and is up-to-date for
> mp2.  I looked at it once before, but was worried I wouldn't be able to
> customize the appearance of it because it doesn't use templates.  It
> looks like there are still no templates.  Do you have an alternate
> approach for modifying the look and feel?

Since version 2.0 all styling is CSS-based, and you can install multiple
user-selectable stylesheets. You can also include header/footer HTML via
plugins.

For real templates that would allow structural changes I would have to
rewrite much of the code, and there wasn't enough demand for that. Wouldn't
help performance either.

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Carl Brewer wrote:
> I've played with installing this today, I'm seeing
> the following in my error logs :
>
> [Thu Sep 02 13:52:41 2004] [error] Can't locate object method
> "cleanup_register" via package "APR::Pool" at
> /data/www/aboc/perl/mwf/MwfMain.pm line 250.\n

Add "use APR::Pool ();" to your startup.pl, I'll add the missing line to my
code in the next version.

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Howdy, Randy.

You wrote 1 sept 2004, 19:24:42:

RK> Are you using libapreq2 to handle the file upload?
RK> Or something else?

Sorry Randy I'm using my own script to parse form
data but it was thoroughly debugged in the old
system and used to work fine. Though I must admit
some strange behaviour - all files used to get
extra \r\n symbols, so I was forced to double
chop() the buffer before inserting it into
database. That worked for all types of files
equally.

RK> Does this problem arise for clients both on Unix and
RK> Windows? Is it browser-specific?

Alas, all my clients are windows based - never had
a chance to check Unix client's behaviour.

RK> Do you know at what stage the corruption in the .doc
RK> file occurs (eg, on upload, storing it in the database,
RK> or on download)?

Inspection of buffer content after the FORM
parsing shows that extra \r\n appear both in the
beginning and at the end of the file so I presume
the upload process is to blame.

RK> Do you know why the extra \r\n occur?

If I knew that I suppose I could find solution
easily.

RK> Normally these are an
RK> issue only with text files, in going between Unix and
RK> Windows - one might think that for binary files no such
RK> mangling need be done (as long as all appropriate handling
RK> of the files at all stages is done in binary mode, if
RK> applicable).

Text files constitute no problem - no one notices
presence of these \r\n symbols.

RK> If you don't chop(), is there a difference
RK> between how .doc and other binary (eg, .zip) files are
RK> handled?

If I don't chop (except for original double chop)
all binaries (zip, rar, pdf, jpg et al) are served
unchanged, only doc files acquire extra \r\n.

So, for time being I applied temporary solution
just to tame my clients. I inserted in my script
the lines 'if ($type='application/msword') {...}
just to cut out both leading and trailing \r\n's.
And it works!!

But I'm curious to find the source of the problem.
Plans: to use libapreq though I lack tutorial
texts concerning Apache::Request and mod_perl as a
whole.



--
Regards,
  Alex                          mailto:alobo@...



--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html