Hello,
I think we need to be clear about what "vulnerability" means here.
If you don't like the word vulnerability, sorry for that. But the following DOS is possible. A bad guy can open massive HTTP connections to Warp and send partial bodies and keep the connections. The connections will not time out. If the limit of open-file reaches, Warp cannot accept a new connections from a good guy. If my understanding is correct, this happens not only for CGI but also for other services.
From Warp's perspective, there is no need to defend against the application: if an application wants to spend five hours responding to a request, that's the application's prerogative. I understand that in the CGI case, you want to prevent something like that from happening, but that's beyond Warp's purview. The question is can we expose enough primitives to make it possible for you to implement this at the Mighttpd level.
Yes, applications are our friends. What I pointed out is that a bud guy can spend five hours. And during that, applicatons cannot spend even one second to do their service.
So from that perspective, I'm not sure if 96311d would really be considered a vulnerability in Warp. Isn't your patch making it impossible for an application to run in unbounded time? It might make more sense to add a specific timeout each time the CGI app is called (possibly via timeout[1]) to ensure it responds appropriately. But if I'm not mistaken, this isn't even necessary in the CGI case, as the Response value will be returned by your code and will not be affected by the response time of the CGI app itself.
The patch is just in a "proof of concept" level. We probably should prepare an option to let applications control time out by themselves. Warp should be secure by default. And an application should be able to open the door to the self-responsibility world if it wishes. --Kazu