
On Thu, Oct 6, 2011 at 9:16 AM, Michael Snoyman
On Thu, Oct 6, 2011 at 3:52 AM, Kazu Yamamoto
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