Bug 3626: Forwarding loops on intercepted traffic

Changes to interception handling in 3.2 series (namely the preference
for using ORIGINAL_DST) have increased the chances that misconfigured
network systems involving Squid will hit forwarding loops.

Two instances are currently known:
 * passing forward-proxy traffic to a interception port.
 * NAT performed on a separate box.

This enacts an old TODO by removing the loop detection bypass for
intercepted traffic and accelerated traffic. Now we always check for
loops regardless of how the request was received.

NOTE: accel mode was only included due to the TODO.
      If problems are found there it can be re-instated.

diff --git a/src/client_side_reply.cc b/src/client_side_reply.cc
index cfccd658215d6186bc5b95fc13910e66a68455d3..ad9a8a6945a1dd4e0069b5a7335b480bb66fca5c 100644 (file)
--- a/src/client_side_reply.cc
+++ b/src/client_side_reply.cc
@@ -652,9 +652,8 @@ clientReplyContext::processMiss()
         return;
     }
 
-    /// Deny loops for accelerator and interceptor. TODO: deny in all modes?
-    if (r->flags.loopdetect &&
-            (http->flags.accel || http->flags.intercepted)) {
+    /// Deny loops for accelerator and interceptor
+    if (r->flags.loopdetect) {
         http->al->http.code = HTTP_FORBIDDEN;
         err = clientBuildError(ERR_ACCESS_DENIED, HTTP_FORBIDDEN, NULL, http->getConn()->clientConnection->remote, http->request);
         createStoreEntry(r->method, request_flags());