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
