Re: Is it a loop bug or not? Sorry missing part.

On 2/2/2013 6:23 AM, Amos Jeffries wrote:
>>
>
> Ah. Interesting. The pattern is that it is supposed to be just the
> visible_hostname value plus the internal manager path.
How can this even be possible?
If there is a hostname and a visible_hostname this cannot work.
Since the hostname url points towards the port 80 which can be some
internal server listening only on 127.0.0.6/32 or any other.

I kind of remember that it needs the port.

> When you add port it breaks the visible_hostname to URL matching and
> Squid relays it onwards to what it thinks is the origin server.

> You should have the intercept port listened on by Squid firewalled so
> direct connections to it cannot succeed. If you are using DROP to do
> that you will see these timeouts, if you are using REJECT you will get a
> fast fail result. If you don't have it firewalled properly the lopo
> detectino in Squid should kick in.

>
>
> PS. we had a proposal a while back to to visible_hostname matching per
> listening port. But this breaks forwarding loop detection a bit.

I was just wandering about the forwarding loop detection logic since
there are many OS and other stuff.

Also I think that there should be an explicit default rule to disable
access from forward proxy port to the intercept\tproxy ones internally
from squid.
I'm almost sure that iptables needs an INPUT chain ACCEPT after the
redirection which in this specific case wont help.
And I do hope you understood that this loop continues... after I close
original connection which points that the result can be very *bad*(at
least 15 minutes of the same reqeust in a loop..)

I havn't tested on 3.2.6 and compared it to 3.HEAD.

If someone have a compiled 3.HEAD and can test this behavior I think
this can might be a major block for 3.3 stable that need to be fixed.

>
> Amos

Eliezer

-- 
Eliezer Croitoru
http://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il