Dave Morgan wrote:
Hi All,
Short summary, original problem
ModPerl::Util::exit: (120000) exit was called at
/usr/share/perl5/CGI/Carp.pm line 590
after hacking out Carp
"Software caused connection abort....." at 3 different places in our
code
The code in question is essentially
print $CGI->header( $header_info_ref );
print $response; #fails here
This was happening a minimum of 150 to 200 times a day. Changed the code to
print $CGI->header( $header_info_ref );
eval{print $response;}; #wrap failure
print STDERR $@ . "\n\n";
This will print blank lines if there was no error. Maybe you should do this :
> print STDERR $@ . "\n\n" if $@;
However, it seems $@ is always empty. So, I no longer have connection
aborted errors
You still have the errors. You just don't see them in the logs anymore.
But that is probably a benefit, because there is nothing much you can do about
them anyway.
Most of the time, they happen because the user has already clicked somewhere else, without
waiting to receive the full answer from the server (or just closed the browser window).
So your application is trying to write data to a socket that is already closed at the
client side.
Because of all the buffering involved, that condition does not immediately reflect all the
way upstream. That's probably why the headers still go out ok (there is room in the
buffers), but the whole response doesn't fit, and that's when the error percolates to your
script and boom.
Now I know I'm easily confused but I don't understand :)
Hope that now you understand a bit more. ;-)
However, as it
does appear
I have fixed the issue I am quite happy. I just wish I knew why it works.
Discovered along the way was do not write anything between the http
header and the
html DOC_TYPE as anything Microsoft based other than IE 10 will not
display css floats properly.
Not to absolve Microsoft of all the inconsistencies in their browsers, but isn't the
DOCTYPE supposed to be the first line of a document, if there is a DOCTYPE ?
If you print anything before, knowing the MS-browser ways, they probably try to "sniff"
the content themselves, no matter what the server sent as headers.
And they probably get it wrong, which means that they probably determine this to be the
wrong version of html, which means that they probably reject tags that shouldn't be in the
<head> according to their wrongly-determined html version's DTD.
