[web-devel] questions about ResponseEnumerator

[Michael Snoyman]

On Thu, Oct 6, 2011 at 10:39 AM, Gregory Collins
<greg at gregorycollins.net> wrote:
> On Thu, Oct 6, 2011 at 9:16 AM, Michael Snoyman <michael at snoyman.com> wrote:
>> On Thu, Oct 6, 2011 at 3:52 AM, Kazu Yamamoto <kazu at 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/d2b6c66abef939bb1396d576e7541b711a6db67b
>>>
>>> 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.