httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: cgi - sigpipe, etc.
Date Sat, 08 Feb 1997 08:00:11 GMT
Not AFAIK.  This is ugly.  If you start a CGI that outputs data forever,
then abort the client, the script will keep going until you hit a timeout.  

send_fd_length is braindead because it doesn't check the return code from
bwrite so it keeps writing even though no more output is ever going to
happen because the connection is dead dead dead.  I just took a quick
look, but my suggested solution would be to change send_fd_length to abort
if it gets a "bad" error from bcwrite (not necessarily just any error,
though) and mod_cgi should probably check the send_fd return code and send
a SIGPIPE to the CGI if there was an error.

This breaks backward compatability.  Some people are relying on the fact
that their CGIs will keep running regardless, eg. for things like form
submissions that take a while to process but are stored somewhere.  

Urp.  But the child can't just block SIGPIPE, since it will get a SIGKILL
when the buffer is cleaned up... Urp.  send a SIGPIPE and then wait on the
child like we do for nph?

Ideas?

On Fri, 7 Feb 1997, sameer wrote:

> 
> 	It was my understanding that CGIs received a SIGPIPE inherited
> from the parent httpd process when the client breaks of the
> connection. That understanding turns out to have been incorrect.
> 
> 	Can the CGI detect at all when the client breaks the
> connection?
> 
> -- 
> Sameer Parekh					Voice:   510-986-8770
> President					FAX:     510-986-8777
> C2Net
> http://www.c2.net/				sameer@c2.net
> 


Mime
View raw message