On Mon, 28 Sep 2009 17:57:02 -0700, George Herbert <george.herbert@xxxxxxxxx> wrote: > On Mon, Sep 28, 2009 at 5:24 PM, Chris Hostetter > <hossman_squid@xxxxxxxxx> wrote: >> >> : The DNS way would indeed be nice. It's not possible in current Squid >> : however, if anyone is able to sponsor some work it might be doable. >> >> If i can demonstrate enough advantages in getting peering to work i might >> just be able to convince someone to think about doing that ... but that >> also assumes i can get the operations team adament enough to protest >> having a hack where they need to run a "config_generator" script on >> every box whenever a cluster changes (because a script like that would be >> fairly straight forward to write as a one off, it's just harder to >> implement as a general purpose feature in squid) >> >> : With Squid-2.7 you can use the 'include' directive to split the >> squid.conf >> : apart and contain the unique per-machine parts in a separate file to >> the >> : shared parts. >> >> yeah, i'm already familiar with inlcude, but either way i need a >> per-machine snippetto get arround the "sibling to self" problem *and* a >> way to reconfig when the snippet changes (because of the cluster changing >> problem) >> >> -Hoss > > > What would be really nice is a command line option and a bit of code > in the cache peer setup that recognizes own IP and ignores the entry, > to make this problem just all go away... > > I should code that up, but not early tonight... If you do I'm happy to mentor the patch through submission and auditing. Also related is the Via: and X-Forwarded-For header behavior. Using HTCP between the peers instead of ICP causes the full HTTP headers to be sent as part of the sibling cache query. That allows peers to respond 'not me' or something if they see their unique_hostname or visible_hostname in the Via: header. Or their own IP in the X-Forwarded-For header. I'm not sure what the current Squid behavior is on that though, I think it has a good chance at being there. Amos
