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

> I'm a little confused by this scenario and your statement "It would be
> nice if the crawler identified itself".
> Is it spoofing an agent name identical that on your OFFICE machines?
> Even the absence of a U-A header is identification in a way.
 
That was just an example. In its simplest form:
DO NOT MODIFY UA OF SRC ACL OFFICE Machines
Change UA of everything else to a fixed value.
 
 

> AFAIK it *should* only require that config you have. If we can figure
> out whats going wrong the bug can be fixed.
 
I have submitted close to 20 bugs over teh years (not all are from this email) and all of them are fixed over time. I am positive this issue does not arise because of my config.
 
HALF-BAKED:
acl OFFICE src 1.1.1.1
request_header_access User-Agent allow OFFICE
request_header_access User-Agent deny all
request-header_replace User-Agent BOGUS AGENT

[DIRECT works as expected for OFFICE -- no modifications. However, UA for OFFICE is replaced as soon as the connection is forwarded to a peer]
 
 
HALF-BAKED:
acl OFFICE src 1.1.1.1
cache_peer 2.2.2.2 parent 22222 0 proxy-only no-query name=PEER2
acl PEER2 peername PEER2
request_header_access User-Agent allow PEER2 OFFICE
request_header_access User-Agent deny PEER2 !OFFICE
request_header_access User-Agent deny all
request-header_replace User-Agent BOGUS AGENT
[all and every combination of ALLOW/DENY/PEER2/OFFICE... does not work]
 
 
WORKS WHEN GOING THROUGH A PEER:
request_header_access User-Agent allow PEER2
request_header_access User-Agent deny all
request-header_replace User-Agent BOGUS AGENT
 
 
It seems to me that ACL SRC is NEVER checked when going to a Peer.
 
WHAT I WANT TO DO:
acl OFFICE src 1.1.1.1
request_header_access User-Agent allow OFFICE
request_header_access User-Agent deny all
request-header_replace User-Agent BOGUS AGENT
 

[OFFICE UA should not be modified whehter going direct or through a peer]
 
Thanks,
 
Jenny
 
PS: Running 3.2.0.7 on production and works good and reliably. The UA issue above is present on both 3.2.0.1 and 3.2.0.7.
Received on Mon Apr 25 2011 - 17:27:35 MDT