[web-devel] questions about ResponseEnumerator

[Kazu Yamamoto ( 山本和彦 )]

Hello Michael,

Sorry for this late response. 

I noticed that if an exception handler is set in a Haskell thread, it
works even if the thread is killed. So, the settingsPauseForApp
approach is enough to me. Michael has alread reverted it but I want it
back.

Before that, I would like to make sure two things:

1) Would you take a look at "cgiApp'" defined in the following?
	https://github.com/kazu-yamamoto/wai-app-file-cgi/blob/master/Network/Wai/Application/Classic/CGI.hs

   Since a sub-process is created, there are two iteratees: The
   original iteratee consumes HTTP request body and passes it to CGI.
   Another iteratee to consumes output from CGI is returned as
   ResponseEnumerator.

   Are the error handlings in "cgiApp'" reasonable from Michael's
   point of view?

2) I noticed that the commit of settingsPauseForApp[1] does not work.

   The timer is paused anyway in serveConnection. Suppose that a nasty
   client specifies Content-Length:, for exapmle, to 10 bytes and
   sends only 5 bytes only and stops. Since the timer is paused and
   there is no chance for an iteratee to resume the timer, the
   connection is not closed by time out.

   I'm sure that this happens in the case of ResponseEnumerator. I
   suspect this happens in the case of ResponseFile and
   ResponseBuilder, too. In other words, a bad guy can make massive
   connections to Warp, which will not be closed by time out.

   I guess pausing in serveConnection is not a good idea.


[1] https://github.com/yesodweb/wai/commit/d2b6c66abef939bb1396d576e7541b711a6db67b

--Kazu

> On Thu, Oct 6, 2011 at 9:34 AM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:
>>>> 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?
>>
>> I think so.
>>
>> --Kazu
>>
> 
> OK, that one's even easier to implement. Please check out the most
> recent commit. I also realized that the Warp module already exports
> all the functions (I think) you need to use the timeout module; let me
> know if something's missing.
> 
> Michael