From 49f1c7f711f8d584c9ef5d323585af97c850d2d6 Mon Sep 17 00:00:00 2001 From: Alex Rousskov Date: Sun, 5 Feb 2012 15:27:05 -0700 Subject: [PATCH] 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. --- src/client_side_reply.cc | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/client_side_reply.cc b/src/client_side_reply.cc index 288f2b58a5..014becef4c 100644 --- 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 -- 2.47.2