You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/08/01 19:55:15 UTC
Re: ModPerl::Registry: Software caused connection abort
Dan Wilga wrote:
[...]
> I have written to the Apache Developers' list, but the only suggestion I
> got was that the initial "Connection reset by peer" error is to be
> expected, but that mod_perl probably shouldn't be generating the pair of
> "[error]" level log messages.
>
> I don't entirely buy this, since there was a behavior change when only
> Apache was upgraded (I kept the same mod_perl version when this started
> happening.) It also only happens when SSL is added to the mix.
>
> However, if you do agree that mod_perl needs to be more tolerant of this
> particular condition then, in my opinion, not only should the error not
> be logged with the "[error]" severity, but the ErrorDocument 500 should
> also not be called.
Thanks for the detailed report, Dan. I'm not 100% sure it's a good idea
to always ignore connection reset errors, since it may come in a
different context (e.g. a registry script doing its own socket IO). But
please give a try to this patch. I haven't tested it.
Index: ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
===================================================================
RCS file:
/home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v
retrieving revision 1.50
diff -u -r1.50 RegistryCooker.pm
--- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 27 Jun 2004
21:26:45 -0000 1.50
+++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 1 Aug 2004 17:52:00 -0000
@@ -42,6 +42,7 @@
use File::Basename;
use Apache::Const -compile => qw(:common &OPT_EXECCGI);
+use APR::Const -compile => qw(ECONNABORTED);
use ModPerl::Const -compile => 'EXIT';
unless (defined $ModPerl::Registry::MarkLine) {
@@ -724,9 +725,14 @@
# ModPerl::Util::exit() throws an exception object whose rc is
# ModPerl::EXIT
# (see modperl_perl_exit() and modperl_errsv() C functions)
- if ($@ && !(ref $@ eq 'APR::Error' && $@ == ModPerl::EXIT)) {
- $self->log_error($@);
- return Apache::SERVER_ERROR;
+ if ($@) {
+ if ($@ == APR::ECONNABORTED) {
+ # silently ignore client connection abort
+ }
+ elsif (!(ref $@ eq 'APR::Error' && $@ == ModPerl::EXIT)) {
+ $self->log_error($@);
+ return Apache::SERVER_ERROR;
+ }
}
return Apache::OK;
}
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Re: ModPerl::Registry: Software caused connection abort
Posted by Stas Bekman <st...@stason.org>.
Dan Wilga wrote:
> At 12:02 PM -0700 8/2/04, Stas Bekman wrote:
>
>>> Upon sending the response. The original error message happens in my
>>> code when I try to "print" the HTTP header.
>>
>>
>> Yeah, that's what I thought. I suppose we could handle that internally
>> then. But I want to have a failing test first. It should work with
>> LWP, just as you see in LWP. Not sure how to arrange that with LWP.
>> Ideas? We need to start the request and then kill it. I suppose we
>> could do an alarm handler, but with 5.8.0 safe signals things, I'm not
>> sure it will actually work. Can you give it a try?
>
>
> I'm using LWP::UserAgent::timeout (which essentially uses alarm), and am
> not having any luck reproducing the problem yet. The timeout does
> happen, but apparently LWP drops the connection in a different way from
> IE, because the error doesn't occur. I'm even using SSL to test this.
>
> I also tried setting the user agent string of the request to match what
> IE sends, and this made no difference. I'm beginning to wonder if maybe
> I need to sniff the packets.
What about using a code abort alarm?
eval {
local $SIG{ALRM} = sub { warn "LWP killed\n" };
alarm 5;
LWP::UserAgent->new->....
alarm 0;
};
now arrange that the response handler will send a few bytes (don't
forget $r->rflush), then sleep for let's say 5 secs and then will try to
print a few more bytes. Time things in a way so that LWP is aborted
after the first bytes were received, but not after the second print has
happened.
>> Are you by chance using a proxy server?
>
>
> Nope. Good thought, though.
OK, in mp1 you could catch the aborted connection state as long as you
didn't use mod_proxy.
http://perl.apache.org/docs/1.0/guide/debug.html#Handling_the__User_pressed_Stop_button__case
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Re: ModPerl::Registry: Software caused connection abort
Posted by Stas Bekman <st...@stason.org>.
Jeff Finn wrote:
> Ok; I have generated a semi-self-contained Apache-test that will produce
> this error.
>
> This only happens on an SSL-enabled server
>
> I was't able to get the alarm block working, but we can work around that
> by starting the test, sleeping for a minute or so, and then in another
> shell getting the url and ctrl-c'ing before the transfer completes.
>
> in one shell
> # make test TEST_VERBOSE=1
>
> once the server starts, in another shell:
> # curl -o /tmp/curl.out https://127.0.0.1:8530/handler
For some reason that doesn't work for me, I get:
curl -o /tmp/curl.out https://localhost:8530/handler
curl: (60) SSL certificate problem, verify that the CA cert is OK
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). The default
bundle is named curl-ca-bundle.crt; you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
If I use -k, and abort curl in the middle I get:
[Mon Aug 09 00:38:55 2004] [info] (32)Broken pipe: core_output_filter:
writing data to the network.
which is related, but not what you get. In my case I always get the core
output filter reports about the broken pipe.
The components I'm using:
[Mon Aug 09 00:44:01 2004] [notice] Apache/2.0.51-dev (Unix)
mod_perl/1.99_15-dev Perl/v5.8.5 mod_ssl/2.0.51-dev OpenSSL/0.9.7c DAV/2
configured -- resuming normal operations
Any difference if you eval $r->print in the response handler in the tar
ball you've supplied?
use APR::Error;
use APR::Const -compile => qw(ECONNABORTED);
...
foreach (1..(2**20)) {
eval { $r->print('01234567890abcdef') };
if ($@) {
if ($@ == APR::ECONNABORTED) {
# silently ignore client connection abort
}
else die $@;
}
}
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
RE: ModPerl::Registry: Software caused connection abort
Posted by Jeff Finn <js...@yahoo.com>.
Ok; I have generated a semi-self-contained Apache-test that will produce
this error.
This only happens on an SSL-enabled server
I was't able to get the alarm block working, but we can work around that
by starting the test, sleeping for a minute or so, and then in another
shell getting the url and ctrl-c'ing before the transfer completes.
in one shell
# make test TEST_VERBOSE=1
once the server starts, in another shell:
# curl -o /tmp/curl.out https://127.0.0.1:8530/handler
here's the apache test file
Jeff
-----Original Message-----
From: Stas Bekman [mailto:stas@stason.org]
Sent: Wednesday, August 04, 2004 11:45 PM
To: Jeff Finn
Cc: modperl@perl.apache.org
Subject: Re: ModPerl::Registry: Software caused connection abort
Jeff Finn wrote:
> I'm joining this thread a little late, but I just noticed I have a similar
> problem to this with Apache 2.0.49/50 and mp1.99_14.
>
> I have the server set up for responses to pass thru a filter:
>
> PerlOutputFilterHandler Apache::FileProtector::output
>
> When I use curl to access the server and hit ctrl-c during the data xfer,
> I get a message in the error log:
>
> [Wed Aug 04 22:17:34 2004] [error] [client 192.168.123.32] Software caused
> connection abort at /usr/webstoreit/perl/Apache/FileProtector.pm line
61.\n
> Software caused connection abort.
>
> I didn't notice this behavior with previous versions of Apache 2.
>
> i'm not sure how to go about working around this problem, does
> anyone have some suggestions?
Yes, they should be internal to mod_perl. Give us a self contained
Apache-Test test that we can reproduce the problem with and we will find
some good solution for it. Please use:
http://apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz
As suggested before you should be able to emulate Ctrl-C with alarm
block. Please make it as simple as possible. Thanks.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Re: ModPerl::Registry: Software caused connection abort
Posted by Stas Bekman <st...@stason.org>.
Jeff Finn wrote:
> I'm joining this thread a little late, but I just noticed I have a similar
> problem to this with Apache 2.0.49/50 and mp1.99_14.
>
> I have the server set up for responses to pass thru a filter:
>
> PerlOutputFilterHandler Apache::FileProtector::output
>
> When I use curl to access the server and hit ctrl-c during the data xfer,
> I get a message in the error log:
>
> [Wed Aug 04 22:17:34 2004] [error] [client 192.168.123.32] Software caused
> connection abort at /usr/webstoreit/perl/Apache/FileProtector.pm line 61.\n
> Software caused connection abort.
>
> I didn't notice this behavior with previous versions of Apache 2.
>
> i'm not sure how to go about working around this problem, does
> anyone have some suggestions?
Yes, they should be internal to mod_perl. Give us a self contained
Apache-Test test that we can reproduce the problem with and we will find
some good solution for it. Please use:
http://apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz
As suggested before you should be able to emulate Ctrl-C with alarm
block. Please make it as simple as possible. Thanks.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
RE: ModPerl::Registry: Software caused connection abort
Posted by Jeff Finn <js...@yahoo.com>.
I'm joining this thread a little late, but I just noticed I have a similar
problem to this with Apache 2.0.49/50 and mp1.99_14.
I have the server set up for responses to pass thru a filter:
PerlOutputFilterHandler Apache::FileProtector::output
When I use curl to access the server and hit ctrl-c during the data xfer,
I get a message in the error log:
[Wed Aug 04 22:17:34 2004] [error] [client 192.168.123.32] Software caused
connection abort at /usr/webstoreit/perl/Apache/FileProtector.pm line 61.\n
Software caused connection abort.
I didn't notice this behavior with previous versions of Apache 2.
i'm not sure how to go about working around this problem, does
anyone have some suggestions?
Thanks
Jeff
-----Original Message-----
From: Nick Phillips [mailto:Nick.Phillips@stonebow.otago.ac.nz]
Sent: Wednesday, August 04, 2004 5:21 PM
To: modperl@perl.apache.org
Subject: Re: ModPerl::Registry: Software caused connection abort
On 03/08/2004, at 7:40 AM, Dan Wilga wrote:
> At 12:02 PM -0700 8/2/04, Stas Bekman wrote:
>>> Upon sending the response. The original error message happens in my
>>> code when I try to "print" the HTTP header.
>>
>> Yeah, that's what I thought. I suppose we could handle that
>> internally then. But I want to have a failing test first. It should
>> work with LWP, just as you see in LWP. Not sure how to arrange that
>> with LWP. Ideas? We need to start the request and then kill it. I
>> suppose we could do an alarm handler, but with 5.8.0 safe signals
>> things, I'm not sure it will actually work. Can you give it a try?
>
> I'm using LWP::UserAgent::timeout (which essentially uses alarm), and
> am not having any luck reproducing the problem yet. The timeout does
> happen, but apparently LWP drops the connection in a different way
> from IE, because the error doesn't occur. I'm even using SSL to test
> this.
I seem to recall a known IE bug with the way it drops connections when
using
SSL. Maybe google for "ssl-unclean-shutdown" together with "MSIE"? I
think it
also suffers when keepalive is used, in that sometimes it will send
incorrect
content-length headers with POST requests.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phillips@stonebow.otago.ac.nz
# these statements are my own, not those of the University of Otago
--
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
--
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
Re: ModPerl::Registry: Software caused connection abort
Posted by Nick Phillips <Ni...@stonebow.otago.ac.nz>.
On 03/08/2004, at 7:40 AM, Dan Wilga wrote:
> At 12:02 PM -0700 8/2/04, Stas Bekman wrote:
>>> Upon sending the response. The original error message happens in my
>>> code when I try to "print" the HTTP header.
>>
>> Yeah, that's what I thought. I suppose we could handle that
>> internally then. But I want to have a failing test first. It should
>> work with LWP, just as you see in LWP. Not sure how to arrange that
>> with LWP. Ideas? We need to start the request and then kill it. I
>> suppose we could do an alarm handler, but with 5.8.0 safe signals
>> things, I'm not sure it will actually work. Can you give it a try?
>
> I'm using LWP::UserAgent::timeout (which essentially uses alarm), and
> am not having any luck reproducing the problem yet. The timeout does
> happen, but apparently LWP drops the connection in a different way
> from IE, because the error doesn't occur. I'm even using SSL to test
> this.
I seem to recall a known IE bug with the way it drops connections when
using
SSL. Maybe google for "ssl-unclean-shutdown" together with "MSIE"? I
think it
also suffers when keepalive is used, in that sometimes it will send
incorrect
content-length headers with POST requests.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phillips@stonebow.otago.ac.nz
# these statements are my own, not those of the University of Otago
--
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
Re: ModPerl::Registry: Software caused connection abort
Posted by Dan Wilga <dw...@MtHolyoke.edu>.
At 12:02 PM -0700 8/2/04, Stas Bekman wrote:
>>Upon sending the response. The original error message happens in my
>>code when I try to "print" the HTTP header.
>
>Yeah, that's what I thought. I suppose we could handle that
>internally then. But I want to have a failing test first. It should
>work with LWP, just as you see in LWP. Not sure how to arrange that
>with LWP. Ideas? We need to start the request and then kill it. I
>suppose we could do an alarm handler, but with 5.8.0 safe signals
>things, I'm not sure it will actually work. Can you give it a try?
I'm using LWP::UserAgent::timeout (which essentially uses alarm), and
am not having any luck reproducing the problem yet. The timeout does
happen, but apparently LWP drops the connection in a different way
from IE, because the error doesn't occur. I'm even using SSL to test
this.
I also tried setting the user agent string of the request to match
what IE sends, and this made no difference. I'm beginning to wonder
if maybe I need to sniff the packets.
>Are you by chance using a proxy server?
Nope. Good thought, though.
--
Dan Wilga dwilga@mtholyoke.edu
Web Technology Specialist http://www.mtholyoke.edu
Mount Holyoke College Tel: 413-538-3027
South Hadley, MA 01075 "Who left the cake out in the rain?"
--
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
Re: ModPerl::Registry: Software caused connection abort
Posted by Stas Bekman <st...@stason.org>.
Dan Wilga wrote:
> At 11:35 AM -0700 8/2/04, Stas Bekman wrote:
>
>> To start with I want to have a short test case that I can reproduce
>> the problem with. Too bad you had it happening only over SSL. We need
>> to check the Apache source to see, who else sends APR__ECONNABORTED
>> and hopefully have a simpler test.
>
>
> I'm not sure I could come up with a test case, even if it wasn't an
> SSL-only thing. It also seems to depend on the browser being IE, so it's
> likely that LWP couldn't be used to reproduce the problem. Let me give
> it a try, though. If I come up with a test case, I'll send it along.
>
>> do you know if you were hitting it on the reading of the request or
>> sending the response?
>
>
> Upon sending the response. The original error message happens in my code
> when I try to "print" the HTTP header.
Yeah, that's what I thought. I suppose we could handle that internally
then. But I want to have a failing test first. It should work with LWP,
just as you see in LWP. Not sure how to arrange that with LWP. Ideas? We
need to start the request and then kill it. I suppose we could do an
alarm handler, but with 5.8.0 safe signals things, I'm not sure it will
actually work. Can you give it a try?
> This is somewhat unrelated: I was also playing around last week with
> some replacement "print" code to test
> $RequestRec->connection()->aborted() to see if the connection has been
> dropped before printing, but it doesn't seem to work. I always get a
> false return from that function in this case. I didn't look to see what
> method that function is using to detect the abort, but it doesn't work
> in this situation.
Are you by chance using a proxy server?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Re: ModPerl::Registry: Software caused connection abort
Posted by Dan Wilga <dw...@MtHolyoke.edu>.
At 11:35 AM -0700 8/2/04, Stas Bekman wrote:
>To start with I want to have a short test case that I can reproduce
>the problem with. Too bad you had it happening only over SSL. We
>need to check the Apache source to see, who else sends
>APR__ECONNABORTED and hopefully have a simpler test.
I'm not sure I could come up with a test case, even if it wasn't an
SSL-only thing. It also seems to depend on the browser being IE, so
it's likely that LWP couldn't be used to reproduce the problem. Let
me give it a try, though. If I come up with a test case, I'll send it
along.
>do you know if you were hitting it on the reading of the request or
>sending the response?
Upon sending the response. The original error message happens in my
code when I try to "print" the HTTP header.
This is somewhat unrelated: I was also playing around last week with
some replacement "print" code to test
$RequestRec->connection()->aborted() to see if the connection has
been dropped before printing, but it doesn't seem to work. I always
get a false return from that function in this case. I didn't look to
see what method that function is using to detect the abort, but it
doesn't work in this situation.
--
Dan Wilga dwilga@mtholyoke.edu
Web Technology Specialist http://www.mtholyoke.edu
Mount Holyoke College Tel: 413-538-3027
South Hadley, MA 01075 "Who left the cake out in the rain?"
--
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
Re: ModPerl::Registry: Software caused connection abort
Posted by Stas Bekman <st...@stason.org>.
Dan Wilga wrote:
> At 10:55 AM -0700 8/1/04, Stas Bekman wrote:
>
>> --- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 27 Jun 2004
>> 21:26:45 -0000 1.50
>> +++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 1 Aug 2004
>> 17:52:00 -0000
>> @@ -42,6 +42,7 @@
>> use File::Basename;
>>
>> use Apache::Const -compile => qw(:common &OPT_EXECCGI);
>> +use APR::Const -compile => qw(ECONNABORTED);
>> use ModPerl::Const -compile => 'EXIT';
>>
>> unless (defined $ModPerl::Registry::MarkLine) {
>> @@ -724,9 +725,14 @@
>> # ModPerl::Util::exit() throws an exception object whose rc is
>> # ModPerl::EXIT
>> # (see modperl_perl_exit() and modperl_errsv() C functions)
>> - if ($@ && !(ref $@ eq 'APR::Error' && $@ == ModPerl::EXIT)) {
>> - $self->log_error($@);
>> - return Apache::SERVER_ERROR;
>> + if ($@) {
>> + if ($@ == APR::ECONNABORTED) {
>> + # silently ignore client connection abort
>> + }
>> + elsif (!(ref $@ eq 'APR::Error' && $@ == ModPerl::EXIT)) {
>> + $self->log_error($@);
>> + return Apache::SERVER_ERROR;
>> + }
>> }
>> return Apache::OK;
>> }
>
>
> Not quite--now I get this:
>
> [Mon Aug 02 13:59:29 2004] [error] [client [ip address]] Argument
> "Software caused connection abort at [script path]" isn't numeric in
> numeric eq (==) at
> /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/ModPerl/RegistryCooker.pm
> line 723, <IN> line 20.\n, referer: [referring page]
>
> I guess the problem is that, unlike $!, $@ doesn't have a numeric
> component. I tried changing this to:
>
> + if ($@) {
> + if ($@ eq APR::ECONNABORTED) {
> + # silently ignore client connection abort
>
> but that didn't help. Now it says, "APR::Error: Can't handle 'eq' at
> /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/APR/Error.pm line 39,
> <IN> line 20.\n".
>
> Next idea? :-)
Ah, OK, APR::Error exception has got stringified already when it reached
that code. Well, really the fix shouldn't be there. This is going to hit
any modperl handlers, not only registry. So we should have a better
solution.
In mod_perl 1, many API calls were silently failing, so those broken
connection failures were silent. In mp2, it's the other way around - no
failure go unnoticed, unless you code it to be so.
Are you sure you want to ignore those things? I suppose that should be
the case.
To start with I want to have a short test case that I can reproduce the
problem with. Too bad you had it happening only over SSL. We need to
check the Apache source to see, who else sends APR__ECONNABORTED and
hopefully have a simpler test. do you know if you were hitting it on the
reading of the request or sending the response?
Add the following:
use APR::Error;
$SIG{__DIE__} = \&APR::Error::confess;
in your startup.pl, so now the trace will show you which line in the
code it has failed in.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Re: ModPerl::Registry: Software caused connection abort
Posted by Dan Wilga <dw...@MtHolyoke.edu>.
At 10:55 AM -0700 8/1/04, Stas Bekman wrote:
>--- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 27 Jun 2004
>21:26:45 -0000 1.50
>+++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 1 Aug 2004
>17:52:00 -0000
>@@ -42,6 +42,7 @@
> use File::Basename;
>
> use Apache::Const -compile => qw(:common &OPT_EXECCGI);
>+use APR::Const -compile => qw(ECONNABORTED);
> use ModPerl::Const -compile => 'EXIT';
>
> unless (defined $ModPerl::Registry::MarkLine) {
>@@ -724,9 +725,14 @@
> # ModPerl::Util::exit() throws an exception object whose rc is
> # ModPerl::EXIT
> # (see modperl_perl_exit() and modperl_errsv() C functions)
>- if ($@ && !(ref $@ eq 'APR::Error' && $@ == ModPerl::EXIT)) {
>- $self->log_error($@);
>- return Apache::SERVER_ERROR;
>+ if ($@) {
>+ if ($@ == APR::ECONNABORTED) {
>+ # silently ignore client connection abort
>+ }
>+ elsif (!(ref $@ eq 'APR::Error' && $@ == ModPerl::EXIT)) {
>+ $self->log_error($@);
>+ return Apache::SERVER_ERROR;
>+ }
> }
> return Apache::OK;
> }
Not quite--now I get this:
[Mon Aug 02 13:59:29 2004] [error] [client [ip address]] Argument
"Software caused connection abort at [script path]" isn't numeric in
numeric eq (==) at
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux/ModPerl/RegistryCooker.pm
line 723, <IN> line 20.\n, referer: [referring page]
I guess the problem is that, unlike $!, $@ doesn't have a numeric
component. I tried changing this to:
+ if ($@) {
+ if ($@ eq APR::ECONNABORTED) {
+ # silently ignore client connection abort
but that didn't help. Now it says, "APR::Error: Can't handle 'eq' at
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux/APR/Error.pm line 39,
<IN> line 20.\n".
Next idea? :-)
--
Dan Wilga dwilga@mtholyoke.edu
Web Technology Specialist http://www.mtholyoke.edu
Mount Holyoke College Tel: 413-538-3027
South Hadley, MA 01075 "Who left the cake out in the rain?"
--
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