Re: HTTPD-CGI Connection lost
Denys Vlasenko <vda.linux <at> googlemail.com>
2009-07-02 10:31:49 GMT
On Wed, Jul 1, 2009 at 1:44 PM, Kjetil Oftedal<oftedal <at> gmail.com> wrote:
> I am working on a CGI-program that is going to be run using the busybox
> As far as I can see from the httpd-source the following scenario isn't
> The webapplication uses comet/the client connection hangs open until an
> happens in the CGI-program. If the client connection is closed remotely
> the CGI-program is blocking/waiting/working the CGI-program is never
> of this by the httpd, not even killed, and may run indefinitly.
Yes. I don't know what the valid behavior would be. Should we:
(a) close CGI input fd (httpd->CGI) on the httpd's end?
(b) close CGI output fd (CGI->httpd) on the httpd's end?
(c) send a signal to CGI (which one)?
(d) do nothing?
If we detect an error _writing_ to network,
httpd exits, and thus CGI will see write errors next time
it tries to write something.
If we detect _read_ error from a network (which we do only
if there is a POSTDATA to read), then we just stop trying
to read from network. httpd does not exit, but closes
the httpd->CGI fd. CGI can detect it if it tries to read
> Can someone confirm that this is correct?
It might be. Someone needs to google for standard practice on this.
What does apache do?