You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by ch...@eehmke.de on 2010/11/03 09:01:07 UTC

Re: [users@httpd] (104)Connection reset by peer: core_output_filter: writing data to the network

Hello all,

the problem is solved. It turned out that the cgi application had a bug that 
caused error messages to be injected into the downloaded file. I guess this 
caused some checksum on length validation check to send a RST ACK package 
back. Why this did not happen with other files I must still debug, but when I 
removed the code that caused the error message inside the file stream, all 
worked fine as it should.
Regards, Chris
 
On Mittwoch 27 Oktober 2010, Chris wrote:
>  Hi Eric,
> 
>  On Wed, 27 Oct 2010 07:23:49 -0400, Eric Covener <co...@gmail.com>
> 
>  wrote:
> > On Wed, Oct 27, 2010 at 6:49 AM, Chris <ch...@eehmke.de> wrote:
> >> I know I am not the first to ask this question, but I really
> >> searched a lot
> >> and got no solution.
> >> 
> >> I have a CGI application written in C++ running on my Apache 2.2.9
> >> server,
> >> hosted on a Debian Lenny system. The application runs fine most of
> >> the time,
> >> only when I do a special download of a simple text file (in CSV
> >> format) the
> >> file is not downloaded and the above message appears in the
> >> error.log. Other
> >> files in the same format download w/o problem.
> >> 
> >> The application itself seems to run fine too, internal tracing
> >> showed me the
> >> file in question is generated correctly. It only might be that the
> >> process
> >> takes one or two seconds longer than usual, because a lot of mysql
> >> queries
> >> have to be executed. But as told before, this works, only the file
> >> never is
> >> downloaded.
> >> 
> >> Now I am at the end of my wits and would ask for hints how to track
> >> down
> >> this issue? I have full control of the server (actually the same
> >> problem
> >> happens when I run the application on localhost, which is a Gentoo
> >> system)
> >> and of the application source code, so I can build test versions
> >> with debug
> >> statements embedded.
> > 
> > If the client is giving up on reading the data due to time, and
> > nothing else is wrong with the headers/body, try either sending the
> > data back periodically  or spawning another thread to trickle back
> > undisplayed data to keep the client interested in hanging around
> > (like
> > the pages you see on travel sites).
> 
>  I forgot to mention, the client is just the Firefox browser. Normally
>  it downloads that files and stores them in the local file system.
> 
>  What kind of "keepalive" data could be used?
> 
> >> Regards, Chris
> >> 
> >> 
> >> ---------------------------------------------------------------------
> >> The official User-To-User support forum of the Apache HTTP Server
> >> Project.
> >> See <URL:http://httpd.apache.org/userslist.html> for more info.
> >> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> >>  "   from the digest: users-digest-unsubscribe@httpd.apache.org
> >> For additional commands, e-mail: users-help@httpd.apache.org
> 
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>    "   from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org