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?
-- StephenReceived on Wed Dec 11 2013 - 11:12:41 MST
This archive was generated by hypermail 2.2.0 : Thu Dec 12 2013 - 12:00:04 MST