On 11/01/11 12:19, Alex Rousskov wrote:
On 01/10/2011 03:02 PM, Henrik Nordström wrote:
fre 2011-01-07 klockan 11:56 -0700 skrev Alex Rousskov:
We hit another flavor of the same bug with Squid 3.2: either the complex
network setup allows loops for forwarding ports or the flags.transparent
test is failing because we do not set that request flag for transparent
ports if certain transparent redirection actions fail.
If someone want to clean this up then they have a +1 from me on making
redirection lookup failures terminal on transparent/intercept ports.
I seem to recall reports that "the proxy was still working fine despite
the lookup errors" so we should be careful not to disable useful
functionality. There is probably more than one way to lookup the
destination, and as long as one way is working, we should probably keep
going.
People say that with a limited view of "working". Same as "its working
perfectly ... except when"
The request Host: header is usually still found and used instead. Thus
for usual traffic the proxy appears to be working. All that happens when
the lookup fails is that the source based security gets broken and the
proxy becomes open to Host: forging attackers.
Does anybody know why the original code did not break all forwarding
loops, including loops for regular forwarding proxies?
it does. It only is a bit harder when interception is used. When
interception is not used it's assumed a loop can be broken by going
direct making it a soft "invisible" error only logged in cache.log
Do you think we should break all loops because it is difficult to be
sure which ones are going to be "fixed" by going direct? The alternative
is to try harder when identifying the situations where a loop can and
should be broken.
I think yes. If we are sure its a loop but not sure of the resolution
break out of the loop. If we have a sure way to resolve it nicer do that
instead.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.10
Beta testers wanted for 3.2.0.4
