The following reply was made to PR mod_cgi/2127; it has been noted by GNATS.
From: [EMAIL PROTECTED] (Ray Zimmerman)
To: Dean Gaudet <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
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
