ob hunt, but a few lessons in netiquette are in
order here.
JMH> At this point, I wouldn't even have afforded you the courtesy of a reply
JMH> if I had been in Laurie Roth's shoes..
JMH>
JMH> Perhaps a little more tact and diplomacy will help you in your quest
JMH> for e
)
{
$r->connection->remote_ip($ip);
}
return Apache::OK;
}
How would I achieve the same functionality without making remote_ip
read/write? How are you guys using post 1.99_15 in production and are
still able to get the original client IP to the back-end? Curious minds
wanna know
d server should log the client's IP address in the server logs.
2) All the mod_perl scripts on the back-end server should be able to
see the client's IP address without taking any extra steps.
Regards,
--
Haroon Rafique
<[EMAIL PROTECTED]>
--
Report problems: http://perl.apach
ed interested in client1, then I would pick the following:
$r->connection->remote_ip(client1)
I hope that explains my situation and reasoning.
Regards,
--
Haroon Rafique
<[EMAIL PROTECTED]>
--
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
DBI::DEBUG > 1;
-Apache->push_handlers("PerlCleanupHandler", \&cleanup);
+if( MP2 ) {
+Apache->server->push_handlers("PerlCleanupHandler", \&cleanup);
+} else {
+Apache->push_handlers("PerlCleanupHandler",
ndlers("PerlCleanupHandler", \&cleanup);
+Apache->server->push_handlers("PerlCleanupHandler", \&cleanup);
# make sure, that the rollback is called only once for every
# request, even if the script calls connect more than once
$
l maintain the client's original IP in the
logs.
On second thought, this looks more and more like an apache issue.
--
Haroon Rafique
<[EMAIL PROTECTED]>
On Today at 4:15pm, HR=>Haroon Rafique <[EMAIL PROTECTED]> wrote:
HR> To secure the back-end, direct access to the back-end directly is
HR> prohibited. The back-end config has the following directive to only
HR> allow proxied requests to come through:
HR>
HR>
HR>
3 Feb 2003 22:56:19 - 1.6
+++ t/conf/extra.conf.in1 Oct 2003 17:22:57 -
@@ -23,3 +23,5 @@
PerlModule Doesnt::Exist
+ScriptSock logs/cgisock
+SetEnv TMPDIR /tmp
--
Haroon Rafique
<[EMAIL PROTECTED]>
Index: ModPerl-Reg
nf file.
Perhaps, a kludge like:
SetEnv TMPDIR logs
would suffice. I believe CGI.pm cleans up after itself anyway.
SB>
SB> > +ScriptSock logs/cgisock
SB>
SB> We don't use mod_cgi in the mod_perl test suite. It's just a left-over
SB> from testing. Does thi
config.pm (another generated file). Finally, the
following section appears in the generated file t/conf/httpd.conf:
LoadModule cgid_module "/etc/apache2/modules/mod_cgid.so"
Should (and more importantly how do) we attempt to keep cgid out of the
conf files?
SB>
SB> [...
b/perl5/5.8.2/i686-linux
/usr/lib/perl5/5.8.2
/usr/local/lib/site_perl
/usr/lib/perl5/site_perl/5.8.1/i686-linux
/usr/lib/perl5/site_perl/5.8.1
/usr/lib/perl5/site_perl/5.8.0/i686-linux
/usr/lib/perl5/site_perl/5.8.0
.
3. This is the core dump trace: (if you get a core dump):
[CORE TRACE COMES HERE]
This report was generated by t/REPORT on Mon Nov 10 15:57:47 2003 GMT.
-8<-- End Bug Report --8<--
--
Haroon Rafique
<[EMAIL PROTECTED]>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
12 matches
Mail list logo
