On 04/12/2013 11:15, Stephen Borrill wrote: > On 03/12/2013 02:25, Amos Jeffries wrote: >> On 3/12/2013 11:45 a.m., Brett Lymn wrote: >>> On Mon, Dec 02, 2013 at 11:53:40AM +0000, Stephen Borrill wrote: >>>> On Sun, 1 Dec 2013, Amos Jeffries wrote: >>>>> On 30/11/2013 5:03 a.m., Stephen Borrill wrote: >>>>>> I've found a problem with selecting a parent cache if the request is an >>>>>> IP address. Tested with various versions including 3.3.10. Example >>>>>> config fragment is below: >>>>>> >>>>>> cache_peer 192.168.1.143 parent 3128 0 no-query no-digest default >>>>>> name=prox1 >>>>>> cache_peer 192.168.1.144 parent 3128 0 no-query no-digest name=prox2 >>>>>> never_direct allow all >>>>>> acl domlist dstdomain -n .bbc.co.uk >>>>> >>>>> "-n" means do not use DNS when evaluating the dstdomain against a >>>>> raw_IP. One guess what requesting http://123.234.123.234/ does? >>>> >>>> -n was added later in an attempt to get it working. The problem still >>>> occurs without -n. >>>> >>> >>> Could it be bug 3848? >>> >> >> Its more likely the text string "123.234.123.234" does not match the >> domain name pattern .*(bbc\.co\.uk)$ nor does it have a PTR reverse-DNS >> record that resolves to any domain name that could match even if the -n >> option was not there to prevent PTR lookup. > > I don't see why this breaks the parent selection rules though. > > Yes, this looks like bug 3848 (thanks Brett!), except that following on > Amos' mail, I've checked and found that it makes no difference whether a > PTR record is present or not. > > Going back to the original config (which is a distilled version for > testing based on our production system which is exhibiting the problem). > If I comment out the top two cache_peer_access lines (the ones that > reference domlist), then the request succeeds. > > acl domlist dstdomain .bbc.co.uk > cache_peer_access prox1 deny domlist > cache_peer_access prox2 allow domlist > cache_peer_access prox1 allow all > cache_peer_access prox2 deny all > > If the domlist acl has exactly the IP address being requested in it, > then the request succeeds. In the absence of this bug being fixed, is there a workaround besides remove all except for one cache_peer? -- Stephen
