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

 On Thu, 5 May 2011 00:00:37 +0000, Jenny Lee wrote:
>> >> 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.
>
> I don't understand this. Isn't the source IP provided by TCP/IP
> stack?

 It is, then squid copies it into local TCP connection details, then
 from there into transaction details, then from there into HTTP requests
 details. Then something goes wrong, then HTTP request details are passed
 to ACLs for testing request_header_access has no IP.

 (I know far too many copies, but cleanup to avoid them is what sucks
 away my dev time.)

>
> Squid is not doing anything extra to find it. It is already being
> provided by the connection. If it is not available when going through
> a peer, then it must be squid's problem.
>
>
>> 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 will file a bug. But unfortunately each bug I post takes 6 months
> to fix. This is on 3.2.0.7 and all 3.2.0's we have used.

 At least the others get a chance to see bugs and it does not die with
 my memory.

 (only 6 months? feel sorry for Steve and Dave:
 http://bugs.squid-cache.org/show_bug.cgi?id=7)

 Amos
Received on Thu May 05 2011 - 00:37:50 MDT