The following reply was made to PR mod_cgi/2127; it has been noted by GNATS.
From: Dean Gaudet <[EMAIL PROTECTED]> To: Ray Zimmerman <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: mod_cgi/2127: Impossible to detect browser disconnect from CGI Date: Fri, 24 Apr 1998 12:15:56 -0700 (PDT) nph also means that the server isn't HTTP/1.1 compliant; and therefore it is broken. On Fri, 24 Apr 1998, Ray Zimmerman wrote: > You say it's non-trivial to fix. There is a patch available (for 1.2.4) on > the cgiAbort page at: > > http://wwwtest.gdb.org/browser/abort/cgiAbort.html > > Is there a problem with this fix? 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. But if you read the documentation: The solution to this problem is for CGI scripts to write data periodically to the client browser's socket while a query is taking place. It turns out that CGI scripts do not write their output directly to a client browser's socket, but instead write (via a Unix pipe) to another process that buffers the output and sends it along to the client browser (there is a special class of scripts called "nph-scripts" that do write directly to the client, but that's another story). If a web server line buffers the output from a CGI script, when a single newline is written, it will be passed directly to the client browser. 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. Notice that this patch only works for text/* content_types... and furthermore requires modification of the CGI -- not of apache. Dean
