www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r...@cornell.edu (Ray Zimmerman)
Subject Re: mod_cgi/2127: Impossible to detect browser disconnect from CGI
Date Fri, 24 Apr 1998 19:50:00 GMT
The following reply was made to PR mod_cgi/2127; it has been noted by GNATS.

From: rz10@cornell.edu (Ray Zimmerman)
To: Dean Gaudet <dgaudet@arctic.org>
Cc: apbugs@hyperreal.org
Subject: Re: mod_cgi/2127: Impossible to detect browser disconnect from CGI
Date: Fri, 24 Apr 1998 15:43:12 -0400

 At 3:15 PM -0400 4/24/98, Dean Gaudet wrote:
 >nph also means that the server isn't HTTP/1.1 compliant; and therefore it
 >is broken.
 
 OK. So nph is out. I didn't want to go that route anyway.
 
 [snip]
 
 >Yeah, it doesn't work.  Consider the case where the CGI blocks forever but
 >the client disappears.  Consider the case where the client blocks forever
 >but the CGI disappears.  Either way you end up stuck in a read() or a
 >write()  call which won't return; and you can't detect that the other has
 >disappeared.  You either need to fork() another process to watch things;
 >use another thread; or write a select() based loop.
 
 I thought the patch we're talking about just caused Apache (1.2) to flush
 the buffer when it saw a single newline by itself. Apparently, according to
 the cgiAbort docs, that made the browser disconnect detectable from the
 CGI, assuming the CGI printed a single newline once in a while. I'm not
 sure I understand why that "doesn't work".
 
 >But if you read the documentation:
   [snip]
 >You'll discover that we already support this in 1.3.  If you write your CGI
 >to periodically send data then you will discover that your CGI is killed off.
 
 It appears you may not have read the initial bug report closely enough. Did
 you look at the example CGI I included?  It *does* periodically send data
 (and yes Apache *does* pass it on to the client, when it's connected). But
 when the connection is broken, Apache waits 75 seconds to kill off the CGI,
 even though the CGI continues sending data every 5 seconds. It should be
 very easy to try it to verify that Apache does NOT kill the CGI immediately
 even though it does continue sending data.
 
 So it still appears to me that there is nothing a CGI can do to determine
 whether the browser is still connected (with Apache 1.3). It can try
 sending some data, but at best it won't find out until 75 seconds later if
 it's still connected.
 
 Is this true or am I still missing something (sorry for being dense if I am)?
 
 >Notice that this patch only works for text/* content_types... and furthermore
 >requires modification of the CGI -- not of apache.
 
 The patch *is* a modification of Apache 1.2, to make it unbuffer the output
 so that a CGI can print a single newline to detect if the browser is still
 there, right? Apparently, with Apache 1.2 and this patch, it *is* possible
 to detect a browser disconnect immediately. So, my real question is, why
 the 75 second delay with 1.3?
 
 'preciate your time,
 
 	Ray
 
 

Mime
View raw message