perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Detection "connection reset by peer" in mod_perl before send a response
Date Sat, 10 Aug 2013 12:44:17 GMT
Lucas wrote:
> Dear all.
> I need to detect that user pressed escape, apache receives it like 
> "connection reset by peer" (I saw it with truss, freebsd strace), before 
> my script will send a response to client.
> I can explain: my script works some time (about 2-3 sec), it gathers 
> some data. Within this period it is possible that user decide to press 
> escape or even to close the page or browser.
> I need to detect it and clean some temporary files, what is normally 
> happen by additional request from script on the page.
> I need your advice how to do it.

First, you need to think about the whole setup between your script and the user's browser,

like this (1 line) :

script <-> perl <-> Apache <-> network <-> firewall/proxy <->
internet <-> internet <-> 
.... <-> firewall/proxy <-> user browser

Any of the "things" between your script and the user's browser has buffers, and may be 
setting up separate TCP connections in-between.  It's not like your script is directly 
connected to the user's browser in any way.
In other words, if the user "walks away" from your page at any time, there is no guarantee

that your Apache server (and even less your script) would get any kind of signal back, 
indicating that the user has done that.

The only time when your script can know that the user "has gone away", is if your script 
tries to write something to the connection at the end of which is the user's browser, and

it gets back an error from Apache/perl saying that there is no connection anymore, and 
that the write could not happen.
And even Apache/perl may not necessarily know that the user has gone away, because they 
may have finished writing to the network, and the response may be somewhere still in a 
buffer somewhere along the way.

So basically, you need to revise the logic of your application so that it does not depend

on any kind of signal coming back from the browser, because there is no guarantee that you

will ever get such a signal back.
That can be complicated, but that is simply how HTTP works, and there is nothing that you

can do to change that.
If you cannot/do not want to do this, then you need to think about another way than HTTP 
to connect your application with the user's browser, such as "websockets" e.g.

View raw message