Dave Morgan wrote:
-------- Original Message --------

Thank you Andre,

On 31/10/12 01:58 PM, André Warnier wrote:
 > Dave Morgan wrote:
 >> How do I find out where the following call(s) are made from?
 >
 > See http://search.cpan.org/~dom/perl-5.14.3/lib/Carp.pm
> or by including the string -MCarp=verbose in the PERL5OPT environment variable.

 > Exactly what I was looking for

However, the above did not help as the call was to Carp::fatalstobrowser.

You've got me a bit confused now. "fatalstobrowser" is not a part of the "Carp" module, it is part of the CGI::Carp module, which is not the same thing.
(And I should have spotted that from your earlier logs, sorry).

"fatalstobrowser" is not really something you call, it is an option which you ínclude in the use statement for CGI::Carp. It's sole effect, as far as I remember, is to /also/ output to the browser any fatal message that would normally only be sent to the server's error log.

We did find the use statement and removed it. We now get

Software caused connection abort at /home/apache/metapoint/trunk/Utility.pm line 231.


Ok, so now you know at which line of which module this issue happens.

Is that you only issue (this line in the logs) ?

Because if it is, it doesn't necessarily indicate a problem. It can happen just because the user clicks on some other link (or closes the window or the browser), before your server has had time to send it the full answer to the present request. Because of that, there is no more client connection over which Apache can continue to send the response, and the next time your program tries to write something, it triggers this error and message in the log.

This only happens when the client is IE. From searching the net it appears to be something to do with the http header not quite right.

No offense intended, but that sounds iffy to me; unless your $response below is a PDF document, in which case there was something indeed with some versions of the Adobe PDF plugin for IE not behaving correctly with some standard HTTP headers.

The code is quite simple:

print $CGI->header( $header_info_ref );

print $response;  <-- maybe you could add "or something-to-do-in-case-of-error" 
here

Running curl provides the following output

[webadmin@web001 perl]$ curl -v 'http://www.coolplaces.ca/index.pl/Whitehorse' --raw
* About to connect() to www.coolplaces.ca port 80 (#0)
*   Trying 69.90.118.205... connected
* Connected to www.coolplaces.ca (69.90.118.205) port 80 (#0)
 > GET /index.pl/Whitehorse HTTP/1.1
> User-Agent: curl/7.19.7 (i386-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
 > Host: www.coolplaces.ca
 > Accept: */*
 >
< HTTP/1.1 200 OK
< Date: Wed, 14 Nov 2012 17:03:17 GMT
< Server: Apache
< Expires: Tue, 15 Nov 2011 17:03:17 GMT
< Pragma: no-cache
< Set-Cookie: sessionid=jHZgBLBfavSyJcZMIaz; path=/; expires=Mon, 13-May-2013 17:03:17 GMT
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=iso-8859-1
<
55f2
<!-- BEGIN portal_chooser.tt2 -->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> <html xmlns="http://www.w3.org/1999/xhtml"; xmlns:v="urn:schemas-microsoft-com:vml" xml:lang="en" lang="en">

The only thing I can see is a line feed before the chunk size but I do not know if this is the
issue or if so how to remove it. Any ideas?


The above looks like a perfectly valid request/response to me. Do you get an error in the logs when you do this with curl ?

In short, what is your problem ?

Reply via email to