ICAP stalls large HTTP transactions (#414)

Calling virginBodySending.plan() has nothing to do with ICAP trailers
support. These (expensive!) plans are necessary if and only if we may
echo the virgin message back to Squid.

Since 6fbd6e, ICAP code always planned to echo the virgin body, even
when no echoing was needed. Echoing requires buffering the virgin
message body, so these plans stalled responses with bodies exceeding
~65K buffer capacity when, for example, the ICAP server did not respond
until getting the entire request body.

diff --git a/src/adaptation/icap/ModXact.cc b/src/adaptation/icap/ModXact.cc
index 78a374013148d8d7c6db417881d5b331ca01e605..b9895981b7bbcb18429ca830b0e93be52d4f1261 100644 (file)
--- a/src/adaptation/icap/ModXact.cc
+++ b/src/adaptation/icap/ModXact.cc
@@ -1542,11 +1542,8 @@ void Adaptation::Icap::ModXact::makeAllowHeader(MemBuf &buf)
     const bool allow204 = allow204in || allow204out;
     const bool allow206 = allow206in || allow206out;
 
-    if (!allow204 && !allow206 && !allowTrailers)
-        return; // nothing to do
-
-    if (virginBody.expected()) // if there is a virgin body, plan to send it
-        virginBodySending.plan();
+    if ((allow204 || allow206) && virginBody.expected())
+        virginBodySending.plan(); // if there is a virgin body, plan to send it
 
     // writing Preview:...   means we will honor 204 inside preview
     // writing Allow/204     means we will honor 204 outside preview