RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?

 On Wed, 4 May 2011 20:40:33 +0000, Jenny Lee wrote:
>> No difference whatever is done. PEER1, !PEER1, !PEER2... No peer...
>> Seperate lines...
>>
>> SRC IP is never available, so it always fails. PEER is available
>> though, I can make it work with using just PEER1. Going direct works
>> also as expected.
>>
>> Thanks.
>>
>> Jenny
>>
>>
>> kid1| ACLChecklist::preCheck: 0x7ffff504abc0 checking
>> 'request_header_access User-Agent allow OFFICE_IP !PEER1'
>> kid1| ACLList::matches: checking OFFICE_IP
>> kid1| ACL::checklistMatches: checking 'OFFICE_IP'
>> kid1| aclIpAddrNetworkCompare: compare:
>> [::]/[ffff:ffff:ffff:ffff:ffff:ffff:ffff:ff00] ([::]) vs
>> 2.2.2.0-[::]/[ffff:ffff:ffff:ffff:ffff:ffff:ffff:ff00]
>> kid1| aclIpMatchIp: '[::]' NOT found

 Aha! so it is the source IP not being known at all.
 request_header_access uses IP from the HTP request details. We need to
 find out if that is NULL or just lacking the client IP and why it got
 that way.

>> kid1| ACL::ChecklistMatches: result for 'OFFICE_IP' is 0
>> kid1| ACLList::matches: result is false
>> kid1| aclmatchAclList: 0x7ffff504abc0 returning false (AND list
>> entry failed to match)
>
> Is there an update on this? Shall I file a bug?

 Yes please if there is not already one on this. If there is please
 'bump' it by mentioning the latest release you have seen it in.

>
> I am going on about this matter since November-2010.

 Yes, you do seem to be the only one really interested in this :(. Your
 triage so far has been great and will help someone experiment to find
 the cause, but still falls just short of that code legwork and patching
 to fix it.

 Amos
Received on Wed May 04 2011 - 23:29:31 MDT