@@ -346,6 +346,28 @@ parseRequest' port (firstLine:otherLines) remoteHost' src = do
346346
347347 -- Make sure that we don't connect to the source after the
348348 -- isolate conduit closes.
349+ --
350+ -- Here's the issue: we fuse our buffered request body with
351+ -- an isolate conduit which ensures no more than X bytes
352+ -- are read. Suppose we read all X bytes, and then we call
353+ -- requestBody again. What happens?
354+ --
355+ -- Previously, we would try to read one more chunk from the
356+ -- buffered source. This is inherent to conduit: we
357+ -- wouldn't know that the isolate Conduit isn't accepting
358+ -- more data until after we've pushed some data to it. This
359+ -- results in hanging, since there's no data available on
360+ -- the wire.
361+ --
362+ -- Instead, we add a wrapper that checks if the request
363+ -- body has already been depleted before making that first
364+ -- pull.
365+ --
366+ -- Possible optimization: do away with the Conduit
367+ -- entirely. However, this may be less efficient overall,
368+ -- as we'd now have to check the BufferedSource status on
369+ -- each call. Worth looking into.
370+
349371 wrap src' = C.Source
350372 { C.sourcePull = do
351373 len <- liftIO $ I.readIORef lenRef