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 541a857f670cbc96cbde6b7d51775623eb4b3fa1..2458bf29a644cc7114eff983595eafa43c9a7bbf 100644 (file)
--- a/src/client_side_reply.cc
+++ b/src/client_side_reply.cc
@@ -630,9 +630,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
+    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());