Search squid archive

RE: Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux