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

On 26/04/11 05:27, Jenny Lee wrote:
>
<snip>
>
> 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.

Okay, this is going to need a cache.log trace for "debug_options 28,9"
to see what is being tested where.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.12
   Beta testers wanted for 3.2.0.7 and 3.1.12.1