On 09/12/2009, at 17:55, David Muñoz wrote: > A) The user cancels the download. Great, the browser closes the > connection and the server kills my CGI. Great! The app is notofied > when the user cancels the download. > > B) Network failure. The socket between the server and the client > closes but the CGI keeps alive. The app is not notified that the > client is down! > > So, the question is: how would you handle this second scenario? Is > there any way to get Cherokee kill its child CGI processes when the > client conmnection is reset?
Aren't those two scenarios kind of the same for your purpose? I mean, if you use a CGi for sending the file, you know that any of those 'bad things' happened whenever the CGI is killed before you sent the very last piece of the file. <workaround fast nasty="very"> In that case, the problem would be in the last chunk of the file. It might be resting in the server buffer when the client closed the connection, and your CGI logic would understand the file was already sent. What could you do in this case? Try to decrease the odds of it to happen. As I've pointed, it's very nasty; but, you could send all the file but the last byte, then you could wait a second of two (so you are fairly sure the server buffer is empty), and then send the last byte. </workaround> By the way, wouldn't a regular script and the "Hidden Downloads" handler do the same thing in a much cleaner and maintainable way? http://www.cherokee-project.com/doc/modules_handlers_secdownload.html -- Octality http://www.octality.com/ _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
