Re: Forwarding loops with squid 2.0 RELEASE

Niall Doherty wrote:

> That's what I thought too - but apparently there are some cases
> where this is desired behaviour. I really can't think of any
> though. Anyone got such a situation ? or can even think of one ?

No. Requests from siblings should NEVER be forwarded, its
part of the definition of a sibling. This functionality
is in progress (proper false hit detection and recovery).

There are however a small but important exception:
how to handle cache-initiated refreshes? Is this a false
hit or not? I regard it as a false hits for now.

Chart of when it may be interesting to query other caches:

          From peer of type
--------+------+--------+--------+---------+--------+
        | User | ChildA | ChildB | Sibling | Parent |
--------+------+--------+--------+---------+--------+
ChildA | Yes | Yes | Yes | No | No |
--------+------+--------+--------+---------+--------+
ChildB | Yes | Yes | No * | No | No |
--------+------+--------+--------+---------+--------+
Sibling | Yes | Yes | No * | No | No |
--------+------+--------+--------+---------+--------+
Parent | Yes | Yes | Yes | No | No |
--------+------+--------+--------+---------+--------+
To peer
of type

* depends on which caches the first cache queries.
Generally the next cache should not query any cache the
first one has already queried.

Description of cache types:
User End user browser or cache
ChildA Has configured us as parent, we them as sibling.
         does NOT ask other siblings before us.
ChildB Has configured us as parent, we them as sibling.
         DOES ask other siblings before us.
Sibling Sibling or Sibling<->Sibling
Parent Our parent. At the parent we may be any of User,
         ChildA or ChildB depending on our and parents
         configuration.

End user caches are untrusted caches (one-way peering
agreement) using us as a parent.

---
Henrik Nordström
Spare time Squid hacker