> The connection to upstream (e.g. httpd) is closed so the client gets a 500 > error.
Hmm, this isn't my experience. Possibly a slowcgi bug? My clients were getting no response, e.g.: curl: (52) Empty reply from server > But the script keeps running. Ah, I see now that the process is left to run now. My CGI read/writes several MB/s lasting longer than the hard coded 120 sec timeout which means my process would immediately get a broken pipe which led me to erroneously believe my process was being terminated by slowcgi. > We were worried that scripts are not prepared when they suddenly get > terminated. To put worry at rest, in the rfc 3875 CGI Version 1.1 section 3.4 Execution: ... "In the event of an error condition, the server can interrupt or terminate script execution at any time and without warning. That could occur, for example, in the event of a transport failure between the server and the client; so the script SHOULD be prepared to handle abnormal termination." > Also as sthen pointed out your MUA mangled the diff. I believe I mangled the diff by copying from my terminal window. > the man page needs better wording. > please use strtonum(3) and use the idiom from the man page example. I will attach the patch. -alfred
slowcgi-t.patch
Description: Binary data
