Forward bumped server connection-close signal to the bumped client.

Technically, the two connections can be maintained independently, but since we
are pretending to be a dumb tunnel to the origin server, it is useful to have
the client close when the server does because it reduces both the number of
persistent connection races (zero replies on the server side that force us to
re-connect and re-forward the failed request) and the possibility that we will
reconnect to the wrong HTTPS server without client knowing.

diff --git a/src/client_side_reply.cc b/src/client_side_reply.cc
index 288f2b58a57b69ed9dbb1e7719d276b7c9fa0299..014becef4c9f31f283d88c9cb9cf408b87310ed1 100644 (file)
--- a/src/client_side_reply.cc
+++ b/src/client_side_reply.cc
@@ -1475,6 +1475,10 @@ clientReplyContext::buildReplyHeader()
     } else if (fdUsageHigh()&& !request->flags.must_keepalive) {
         debugs(88, 3, "clientBuildReplyHeader: Not many unused FDs, can't keep-alive");
         request->flags.proxy_keepalive = 0;
+    } else if (request->flags.sslBumped && !reply->persistent()) {
+        // We do not really have to close, but we pretend we are a tunnel.
+        debugs(88, 3, "clientBuildReplyHeader: bumped reply forces close");
+        request->flags.proxy_keepalive = 0;
     }
 
     // Decide if we send chunked reply