Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1
Randy Kobes wrote: On Tue, 1 Apr 2008, Philippe M. Chiasson wrote: The mod_perl 2.0.4 release candidate 1 "Works with Perl 5.10" is ready. It can be downloaded here: http://www.apache.org/~gozer/mp2/mod_perl-2.0.4-rc1.tar.gz MD5: 1f0a941e8b5f26b6102126ae67ddbb43 SHA1: 8b2ceede3c783b9b2cc9e0fe63a095b0e4a1f000 Please give it a spin in your favorite configuration and report any problems. Especially needed against Perl-5.10 on Windows. Tested on - linux: perl-5.8.7, Apache/2.0.55 preform - all tests pass - Win32: perl-5.10.0 (ActivePerl 1002), Apache/2.2.8 - 'nmake test' crashes on t/modules/apache_status, but this test passes when run individually, and also passes when all the t/modules/* tests are run (as well as some random combinations of earlier tests). I need to run t/SMOKE to narrow down the combination that fails. This is something relatively recent from svn. However, I won't be able to get to this for a week or so, and don't want to hold this release up, so +1. I don't get any crash at all in my dev-env - passes all tests. I compiled my ActivePerl (with default compile settings - this was due to the suspicions we had with 1.34-RC3) and was too lazy to put the standard binary dist back in place... C:\mod_perl-2.0.4-rc1>perl -V Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE - DNO_STRICT -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC -DPERL_I MPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX', optimize='-MD -Zi -DNDEBUG -O1', cppflags='-DWIN32' ccversion='12.00.8168', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksi ze=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -libpath:"c: \perl\lib\CORE" -machine:x86' libpth=\lib libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32 .lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_ 32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comd lg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl510.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf - libpath:"c:\perl\lib\CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PL_OP_SLAB_ALLOC USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_SITECUSTOMIZE Locally applied patches: ActivePerl Build 1002 32809 Load 'loadable object' with non-default file extension 32728 64-bit fix for Time::Local Built under MSWin32 Compiled at Feb 29 2008 13:42:32 @INC: C:/Perl/site/lib C:/Perl/lib . C:\mod_perl-2.0.4-rc1>
Re: [RELEASE CANDIDATE] mod_perl-1.31 RC4
Randy Kobes wrote: On Wed, 2 Apr 2008, Issac Goldstand wrote: Philippe M. Chiasson wrote: The mod_perl 1.31 release candidate 4 "Works with Perl 5.10" is ready. It can be downloaded here: [ ... ] win32 vc6 FAIL Sorry folks, still segfaulting. Backtrace below: I also get this crash on startup on Win32: perl-5.10.0 (ActivePerl 1002), Apache/1.3.34 However, given that - it works with perl-5.8 (ActivePerl 822), where all tests pass - most likely mod_perl-2 is used by most Windows users by now - as Steve Hay found, it's something to do with the particular compile-time settings used by ActivePerl - this looks like it may take some time to track down I again don't want to hold this up, unless there's a strong objection, so take this as a +1; we could put a note in the README saying that it doesn't work yet on perl-5.10 ActivePerl. If someone could whip it up fast, maybe detect AP-1002 in Makefile.PL and abort?
Re: Reload/Graceful Restart Apache
On Tue, Apr 1, 2008 at 5:48 PM, xyon <[EMAIL PROTECTED]> wrote: > Hello all, > > I've got a modperl app that changes some apache configs (via text > files), but need to tell Apache to re-read its configuration files for > the changes to take effect. What might be the best way of going about > such an operation? > > Here is some info about my install: > > # cat /etc/redhat-release && rpm -qa httpd mod_perl > CentOS release 4.6 (Final) > httpd-2.0.59-1.el4s1.10.el4.centos > mod_perl-2.0.3-1.el4s1.3 If you are doing this by hand, you will always want to stop and then start the server, not restart. Sean
Re: Reload/Graceful Restart Apache
On Tue, Apr 1, 2008 at 5:59 PM, xyon <[EMAIL PROTECTED]> wrote: > When you mean by hand, you mean something like: > > `/usr/sbin/httpd -k $action` > > Where $action could be "stop" and then "start"? I don't think this is > possible, I get permission denied on the socket: > > (13)Permission denied: make_sock: could not bind to address [::]:443 > no listening sockets available, shutting down > Unable to open logs This needs to be done as a root or admin user, I believe. Sean
Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1
> uname -a
SunOS XXX 5.10 Generic_127111-10 sun4u sparc SUNW,Sun-Fire-V240
> /usr/local/bin/perl -V
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
Platform:
osname=solaris, osvers=2.10, archname=sun4-solaris
uname='sunos XXX 5.10 generic_127111-10 sun4u sparc sunw,sun-fire-v240 '
config_args='-Dcc=gcc -B/usr/ccs/bin/ -Uuselargefiles -Uusemymalloc
-Dlocincpth=/usr/local/include /opt/sfw/include /usr/sfw/include
-Dloclibpth=/usr/local/lib /opt/sfw/lib /usr/sfw/lib /usr/lib /usr/ccs/lib'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=undef, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc -B/usr/ccs/bin/', ccflags ='-fno-strict-aliasing -pipe
-I/usr/local/include -I/opt/sfw/include -I/usr/sfw/include
-DPERL_USE_SAFE_PUTENV',
optimize='-O3',
cppflags='-fno-strict-aliasing -pipe -I/usr/local/include
-I/opt/sfw/include -I/usr/sfw/include'
ccversion='', gccversion='3.4.6', gccosandvers='solaris2.10'
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=4
alignbytes=8, prototype=define
Linker and Libraries:
ld='gcc -B/usr/ccs/bin/', ldflags =' -L/usr/local/lib -L/opt/sfw/lib
-L/usr/sfw/lib -L/usr/lib -L/usr/ccs/lib'
libpth=/usr/local/lib /opt/sfw/lib /usr/sfw/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=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib -L/opt/sfw/lib
-L/usr/sfw/lib -L/usr/lib -L/usr/ccs/lib'
Characteristics of this binary (from libperl):
Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP
PERL_USE_SAFE_PUTENV USE_PERLIO
Built under solaris
Compiled at Apr 3 2008 14:10:20
@INC:
/usr/local/lib/perl5/5.10.0/sun4-solaris
/usr/local/lib/perl5/5.10.0
/usr/local/lib/perl5/site_perl/5.10.0/sun4-solaris
/usr/local/lib/perl5/site_perl/5.10.0
/usr/local/lib/perl5/site_perl/5.8.8
/usr/local/lib/perl5/site_perl
> gmaek test
All tests successful, 8 tests and 13 subtests skipped.
Files=238, Tests=2559, 238 wallclock secs (180.48 cusr + 31.92 csys = 212.40
CPU)
[warning] root mode: restoring the original files ownership
[warning] server localhost:8529 shutdown
cd ModPerl-Registry && make test
/usr/local/bin/perl -I../blib/arch -I../blib/lib \
t/TEST -clean
APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER=
APACHE_TEST_APXS= \
/usr/local/bin/perl -I../blib/arch -I../blib/lib \
t/TEST -bugreport -verbose=0
[warning] root mode: changing the files ownership to 'nobody' (60001:60001)
[warning] testing whether 'nobody' is able to -rwx
/opt/local/src/mod_perl-2.0.4-rc1/ModPerl-Registry/t
"/usr/local/bin/perl"
-Mlib=/opt/local/src/mod_perl-2.0.4-rc1/ModPerl-Registry/t/../../Apache-Test/lib
-MApache::TestRun -e 'eval { Apache::TestRun::run_root_fs_test(60001, 60001,
q[/opt/local/src/mod_perl-2.0.4-rc1/ModPerl-Registry/t]) }';
[warning] result: OK
[warning] the client side drops 'root' permissions and becomes 'nobody'
/usr/local/httpd-2.2.8+mod_perl-2.0.4-rc1/bin/httpd -d
/opt/local/src/mod_perl-2.0.4-rc1/ModPerl-Registry/t -f
/opt/local/src/mod_perl-2.0.4-rc1/ModPerl-Registry/t/conf/httpd.conf -D APACHE2
using Apache/2.2.8 (prefork MPM)
waiting 90 seconds for server to start:
waiting 90 seconds for server to start: ok (waited 3 secs)
server localhost:8529 started
t/206ok
t/304ok
t/404ok
t/500ok
t/bad_scriptsok
t/basic..ok
t/bin_resp...ok
t/cgiok
t/closureok
t/dirindex...ok
t/fatalstobrowserskipped
all skipped: fatalsToBrowser known not to work, CGI version 99.99 or
higher is required
t/flush..ok
t/ithreads...skipped
all skipped: perl 5.8.1 or higher w/ithreads enabled is required
t/np
ModPerl::MM or ExtUtils::MakeMaker or what?
Hi,
I am a bit confused about what MakeMaker is best to use with mp2 modules.
There is the good old ExtUtils::MakeMaker that is mentioned in
http://perl.apache.org/docs/general/testing/testing.html. How I got there I
don't remember but I have used in all my modules ModPerl::MM. Is that right?
Or should I rather port them to use the former?
I am asking because I have had FAIL reports from CPAN testers that don't
install ModPerl::MM. The way around these reports is using
BEGIN {
eval {
require ModPerl::MM;
require Apache::TestMM;
};
if( $@ ) {
warn $@;
exit 0;
}
Apache::TestMM->import( qw(test clean) );
}
instead of
use ModPerl::MM ();
use Apache::TestMM qw(test clean);
This way no Makefile is written and the automatic test suite is happy.
Torsten
Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1
On Wed, Apr 02, 2008 at 03:15:19PM +0100, Joe Orton wrote: > On Tue, Apr 01, 2008 at 11:26:43PM -0700, Philippe M. Chiasson wrote: > > The mod_perl 2.0.4 release candidate 1 "Works with Perl 5.10" is ready. It > > can be downloaded here: > > > > http://www.apache.org/~gozer/mp2/mod_perl-2.0.4-rc1.tar.gz > > > > MD5: 1f0a941e8b5f26b6102126ae67ddbb43 > > SHA1: 8b2ceede3c783b9b2cc9e0fe63a095b0e4a1f000 > > > > Please give it a spin in your favorite configuration and report > > any problems. Especially needed against Perl-5.10 on Windows. > > v5.8.8 on Fedora 8/x86_64, testing against httpd 2.2.9-dev got: > > t/modules/include_subreq.t11 100.00% 1 > 3 tests and 1 subtest skipped. > Failed 1/238 test scripts, 99.58% okay. 1/2683 subtests failed, 99.96% okay. Sorry, false alarm, this was because I had some local debugging patches applied to mod_include.It works fine with 2.2.8 and 2.2.9-dev. +1 for release; tested on: 2.2.9-dev, v5.8.8, prefork, Fedora 8, x86_64 2.2.8, v5.10.0, prefork, Fedora 9/Raw Hide, i386 joe
Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1
On Thu, 3 Apr 2008, Issac Goldstand wrote: Randy Kobes wrote: On Tue, 1 Apr 2008, Philippe M. Chiasson wrote: The mod_perl 2.0.4 release candidate 1 "Works with Perl 5.10" is ready. It can be downloaded here: - linux: perl-5.8.7, Apache/2.0.55 preform - all tests pass - Win32: perl-5.10.0 (ActivePerl 1002), Apache/2.2.8 - 'nmake test' crashes on t/modules/apache_status, but this test passes when run individually, and also passes when all the t/modules/* tests are run (as well as some random combinations of earlier tests). I don't get any crash at all in my dev-env - passes all tests. Thanks very much for reporting that - it sounds like my problem might have something to do with my particular system (although we seem to have compatible ActivePerls). I'll track that down, but this reinforces my earlier comment about not holding up the release because of this problem. -- best regards, Randy
share objects
hi I have installed static mp2 with apache 2.0.63 (forker). I am using perl bind (Sleepycat::DBXML) from dbxml; then I create an object (reference to Sleepycat::DBXML) in startup.pl because i want to share it. After some test (stress it) for my application I saw some error in error.log; the problem is that reference to object created in startup.pl was lost then the question is ... is possible to share objects? I know I can share data between processes, but what I also shared objects? thanks in advance
Re: share objects
On Thu, Apr 3, 2008 at 11:32 PM, Felipe de Jesús Molina Bravo
<[EMAIL PROTECTED]> wrote:
> hi
>
> I have installed static mp2 with apache 2.0.63 (forker). I am using perl
> bind (Sleepycat::DBXML) from dbxml; then I create an object (reference to
> Sleepycat::DBXML) in startup.pl because i want to share it. After some test
> (stress it) for my application I saw some error in error.log; the problem is
> that reference to object created in startup.pl was lost
>
> then the question is ... is possible to share objects?
>
If your object has its own package name space, you can share it
between multi-processes.
But if you state this in startup.pl,
my $obj = Sleepycat::DBXML->new();
this $obj can't be shared among multi-processes. Because it doesn't
have its package name space.
So,you'd better write a package to encap that object, like:
package MyPKG;
use strict;
use Sleepycat::DBXML;
our $obj = Sleepycat::DBXML->new;
sub initobj { $obj }
1;
And put 'use MyPKG' in the startup.pl.
then in your scripts you can access this object by saying 'our $obj'
or via the method of 'my $obj = MyPKG->initobj'.
Good luck.
Re: ModPerl::MM or ExtUtils::MakeMaker or what?
Torsten Foertsch wrote:
Hi,
I am a bit confused about what MakeMaker is best to use with mp2 modules.
There is the good old ExtUtils::MakeMaker that is mentioned in
http://perl.apache.org/docs/general/testing/testing.html. How I got there I
don't remember but I have used in all my modules ModPerl::MM. Is that right?
Or should I rather port them to use the former?
ModPerl::MM is the way to go. I suspect you can get away with
ExtUtils::MakeMaker as log as you're not using XS, but I honestly can't
recall what additional magic ModPerl::MM adds. it could be substantial :)
I am asking because I have had FAIL reports from CPAN testers that don't
install ModPerl::MM. The way around these reports is using
BEGIN {
eval {
require ModPerl::MM;
require Apache::TestMM;
};
if( $@ ) {
warn $@;
exit 0;
}
Apache::TestMM->import( qw(test clean) );
}
instead of
use ModPerl::MM ();
use Apache::TestMM qw(test clean);
This way no Makefile is written and the automatic test suite is happy.
yeah, that's the way you'll need to do it... if you care about those
reports :)
you can probably assume that if the user has ModPerl::MM that
Apache-Test is available.
--Geoff
Re: share objects
On Thu, Apr 3, 2008 at 11:32 AM, Felipe de Jesús Molina Bravo <[EMAIL PROTECTED]> wrote: > I know I can share data between processes, but what I also shared objects? It depends on what you mean by share. You can create a simple perl object in startup.pl and access it from all processes later, but if you change it in one process, the change will not be seen in the others. With objects that contain open sockets, file handles, or XS structures, you usually can't share them at all. This is why you can't open a DBI connection in startup and use it from your child processes. I don't know Sleepycat::DBXML, but it sounds like something that would use file handles. Try creating your object in a PerlInitHandler instead, which runs in the child process when it is first created. - Perrin
Re: share objects
2008/4/3, Jeff Pang <[EMAIL PROTECTED]>:
>
> On Thu, Apr 3, 2008 at 11:32 PM, Felipe de Jesús Molina Bravo
> <[EMAIL PROTECTED]> wrote:
> > hi
> >
> > I have installed static mp2 with apache 2.0.63 (forker). I am using
> perl
> > bind (Sleepycat::DBXML) from dbxml; then I create an object (reference
> to
> > Sleepycat::DBXML) in startup.pl because i want to share it. After some
> test
> > (stress it) for my application I saw some error in error.log; the
> problem is
> > that reference to object created in startup.pl was lost
> >
> > then the question is ... is possible to share objects?
> >
>
>
> If your object has its own package name space, you can share it
> between multi-processes.
> But if you state this in startup.pl,
>
> my $obj = Sleepycat::DBXML->new();
>
> this $obj can't be shared among multi-processes. Because it doesn't
> have its package name space.
>
> So,you'd better write a package to encap that object, like:
>
> package MyPKG;
> use strict;
> use Sleepycat::DBXML;
>
> our $obj = Sleepycat::DBXML->new;
> sub initobj { $obj }
>
> 1;
>
> And put 'use MyPKG' in the startup.pl.
> then in your scripts you can access this object by saying 'our $obj'
> or via the method of 'my $obj = MyPKG->initobj'.
>
> Good luck.
>
thanks a lot
My problem was solved ... The problem was that I had the buildup of the
object (new) within "sub initobj () "
regards
Re: share objects
2008/4/3, Perrin Harkins <[EMAIL PROTECTED]>: > > On Thu, Apr 3, 2008 at 11:32 AM, Felipe de Jesús Molina Bravo > <[EMAIL PROTECTED]> wrote: > > > I know I can share data between processes, but what I also shared > objects? > > > It depends on what you mean by share. You can create a simple perl > object in startup.pl and access it from all processes later, but if > you change it in one process, the change will not be seen in the > others. With objects that contain open sockets, file handles, or XS > structures, you usually can't share them at all. Is when they can be shared? and if my file handle is open of "ro" it can share between process? This is why you > can't open a DBI connection in startup and use it from your child > processes. > > I don't know Sleepycat::DBXML, but it sounds like something that would > use file handles. Try creating your object in a PerlInitHandler > instead, which runs in the child process when it is first created. - Perrin > Thanks ... best regards felipe
Re: share objects
On Thu, Apr 3, 2008 at 1:33 PM, Felipe de Jesús Molina Bravo <[EMAIL PROTECTED]> wrote: > > It depends on what you mean by share. You can create a simple perl > > object in startup.pl and access it from all processes later, but if > > you change it in one process, the change will not be seen in the > > others. With objects that contain open sockets, file handles, or XS > > structures, you usually can't share them at all. > > Is when they can be shared? and if my file handle is open of "ro" it > can share between process? It can be done, but it's tricky. When you try to use one file handle from multiple process it gets confused about the location in the file. If you really need to do it, read about shared file handles in Programming Perl or your favorite Unix reference. - Perrin
Re: share objects
2008/4/3, Perrin Harkins <[EMAIL PROTECTED]>: > > On Thu, Apr 3, 2008 at 1:33 PM, Felipe de Jesús Molina Bravo > <[EMAIL PROTECTED]> wrote: > > > It depends on what you mean by share. You can create a simple perl > > > object in startup.pl and access it from all processes later, but if > > > you change it in one process, the change will not be seen in the > > > others. With objects that contain open sockets, file handles, or XS > > > structures, you usually can't share them at all. > > > > Is when they can be shared? and if my file handle is open of "ro" > it > > can share between process? > > > It can be done, but it's tricky. When you try to use one file handle > from multiple process it gets confused about the location in the file. > If you really need to do it, read about shared file handles in > Programming Perl or your favorite Unix reference. > > > - Perrin > ok ...thanks a lot regards felipe
Re: ModPerl::MM or ExtUtils::MakeMaker or what?
Geoffrey Young wrote:
Torsten Foertsch wrote:
Hi,
I am a bit confused about what MakeMaker is best to use with mp2 modules.
There is the good old ExtUtils::MakeMaker that is mentioned in
http://perl.apache.org/docs/general/testing/testing.html. How I got there I
don't remember but I have used in all my modules ModPerl::MM. Is that right?
Or should I rather port them to use the former?
ModPerl::MM is the way to go. I suspect you can get away with
ExtUtils::MakeMaker as log as you're not using XS, but I honestly can't
recall what additional magic ModPerl::MM adds. it could be substantial :)
Yes, unless you are using C/XS code that uses Apache/APR/mod_perl APIs, it
doesn't matter. Under the hood, it basically makes sure to propagate the
right values thru to MakeMaker:
CCFLAGS
LIBS
INC
OPTIMIZE
LDDLFLAGS
TYPEMAPS
OTHERLDFLAGS
I am asking because I have had FAIL reports from CPAN testers that don't
install ModPerl::MM.
You mean people who install mod_perl 2 and *not* ModPerl::MM ?? Otherwise,
I would think breaking out on the presence of mod_perl2.pm is good enough, no?
The way around these reports is using
BEGIN {
eval {
require ModPerl::MM;
require Apache::TestMM;
};
if( $@ ) {
warn $@;
exit 0;
}
Apache::TestMM->import( qw(test clean) );
}
instead of
use ModPerl::MM ();
use Apache::TestMM qw(test clean);
This way no Makefile is written and the automatic test suite is happy.
yeah, that's the way you'll need to do it... if you care about those
reports :)
you can probably assume that if the user has ModPerl::MM that
Apache-Test is available.
Wouldn't that be a bogus assumption? Better off to assume mod_perl2.pm means
ModPerl::MM is installed.
--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
signature.asc
Description: OpenPGP digital signature
Re: APR::Socket SSL
Mike Cardwell wrote:
Hi,
I'm writing a PerlProcessConnectionHandler. It starts:
sub handler {
my $c = shift;
my $sock = $c->client_socket;
$sock is an instance of APR::Socket. The problem is that the connection
is using SSL and I need to be able to read/write the unencrypted socket
stream. If $sock was an instance of IO::Socket I could just do a
IO::Socket::SSL->start_SSL( $sock ) to handle SSL negotiation and to get
access to the unencrypted stream, but how do I do it with APR::Socket?
You can't, not that way. If there was a way to get at the underlying
native socket, you could break all filtering. What you need to do here instead,
is to leave the SSL processing to mod_ssl, and stack yourself on top of it
somehow.
I don't see any other way around this.
Also, and I'm guessing this is a big no. Is it possible to have a
PerlProcessConnectionHandler that reads the first few bytes from the
socket then decides that it doesn't want to continue so puts them back
on the stack and then hands off to the next phase for "normal" processing?
That, you can do with ease. You'd write an input filter, pop enough data
out of the input brigade until you can figure out what you want to do, and if
you want to pass it all thru, you reinsert what you read back in the brigade,
remove yourself completely from the filter chain, and pass it up.
That's should be fairly easy.
--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
signature.asc
Description: OpenPGP digital signature
