Re: [RFC] Breaking forwarding loops

On 01/11/2011 07:13 PM, Amos Jeffries wrote:
> On 12/01/11 13:53, Alex Rousskov wrote:
>> On 01/07/2011 06:04 PM, Amos Jeffries wrote:
>>
>>> Note that a great many hostnames are "localhost" or
>>> "localhost.localdomain" or "localhost.local" due to certain distros
>>> hard-coding "localhost" into their packages.
>>>
>>> We also use "localhost" as a backup when the gethostname() call fails to
>>> provide anything with rDNS. (IMO that hard rDNS requirement is a bit
>>> naive)
>>
>> Good point!
>>
>> On 01/11/2011 01:16 AM, Henrik Nordström wrote:
>>> A proposal is to always return an error if Via indicates
>>> that we have already processed this request twice
>>> (on third time the same request is received). This will break actual
>>> loops, while keeping sibling loops silent.
>>
>> Sounds like a good approach to me. I would even take it a few steps
>> further to address Amos concern using the same technique. How about this
>> plan:
>>
>> If we have detected a forwarding loop and our name appeared N times,
>> then respond with an error provided at least one of the conditions below
>> is true:
>>
>> 1) N> 2 and our name is not localhost or similar.
>> 2) N> 10.
>>
>> No checks for the port mode or transaction flags (intercepted,
>> accelerated, etc.).
>>
>> In addition to the above, do a startup check for the name and warn the
>> user if our name is localhost or similar.
>
> I've done a quick search and failed to find the patch I made for this
> (bug 2654). Please go ahead with just the warning anyway, I'll resolve
> any conflict when I get back into the bug fix.
>
>
> As for the >10. why 10 and not 1000? or 5?

> Consider: what is the use case for allowing a request through the same
> Squid three times?

The use case is a request going (without any loops!) through several
independent proxies, each auto-configured to be "localhost", triggering
a false loop detection.

I am fine with N>2 for all cases if others think that is sufficient.

Thank you,

Alex.

> the only valid one as Henrik said was peer loops by accident. Due to us
> not checking if the source IP matches the peer IP. This is resolved on
> loop #2 by not passing to peers if we have already looped. So breaking
> on 3 makes a strong case.
>
> Amos
Received on Wed Jan 12 2011 - 04:37:01 MST