Re: Soulution maybe? for Re: Connection aborted was ModPerl::Util::exit: (120000) at Carp.pm line 590
André Warnier <[email protected]>
| Newsgroups | gmane.comp.apache.mod-perl |
|---|---|
| Message-ID | <[email protected]> |
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.