Re: [web-devel] questions about ResponseEnumerator

On Thu, Oct 6, 2011 at 10:39 AM, Gregory Collins wrote:

On Thu, Oct 6, 2011 at 9:16 AM, Michael Snoyman wrote:

...

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.

Except this was a case where exposing the timeout manager *was* necessary[1]. We already provide users the ability to modify the timeout duration via settingsTimeout, this is for an extra feature: letting the user supply their own manager. It's true that it will cause us trouble if we decide to change things later, but this was already part of the exposed interface, since we allow some fairly low-level tinkering with Warp. (This is necessary for things like wai-handler-devel.)

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.

Timeout handling would be outside the scope of WAI. How would it work there? What does it mean to have timeouts set for FastCGI, or CGI, or testing? I think having a timeout handler in Warp is the correct solution, I don't know what we'd gain by moving it to WAI, much less what that would even mean. Michael [1] Well, Kazu could just implement his own timeout manager and have that running for CGI processes, but that would be a waste.