On Thu, Oct 6, 2011 at 9:16 AM, Michael Snoyman <michael@snoyman.com> wrote:
On Thu, Oct 6, 2011 at 3:52 AM, Kazu Yamamoto <kazu@iij.ad.jp> wrote:
Hello Michael,
I think we could make that functionality optional, based on an extra setting parameter. Would this just be boolean, or is more sophisticated control required?
What I want to do is to prevent a bad guy abusing CGI. So, I guess that boolean is enough.
Alright, here's a first stab[1]. What do you think?
Michael
[1] https://github.com/yesodweb/wai/commit/d2b6c66abef939bb1396d576e7541b711a6db...
Mighttpd executes a sub process and creates a pair of pipes for CGI. If timeout happens, it seems to me that there is no way to kill the sub process and close the pipes with this scheme.
I would like to register a house-keeping action to Wrap's timer.
So it sounds like instead of the solution we just put in, we should just expose the ability to use Warp's timeout code directly. This shouldn't be a problem:
* Expose the Timeout module (maybe in its own package, could be useful to others) * Add an extra settingsTimeoutManager :: IO Manager. That way you can create the manager in Mighttpd and then reuse it in Warp.
Would this address the issue?
It would, but it'd be a Law of Demeter violation. In Snap we give you an IO action "_snapSetTimeout :: Int -> IO ()", that gets handed to you as hidden state in the Snap monad. {*} I don't think it's necessary to expose the TimeoutManager to applications at all, and it might get you into trouble later if you decide you need to change the interface. BTW: is timeout handling specified in WAI, or not? IMO you almost can't write a stable web application without thinking about the timeout issue, and I think that interface probably belongs in WAI if it isn't there already. G {*} Note: you could make the parameter "Maybe Int" to allow the user to disable the timer, but I chose not to -- disabling the timer is a bad idea. You can still set an effectively infinite timeout using "maxBound", but at least then you feel guilty for doing something stupid. -- Gregory Collins <greg@gregorycollins.net>