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

From: Jenny Lee <bodycare_5_at_live.com>
Date: Tue, 19 Apr 2011 05:53:44 +0000

> To: squid-users_at_squid-cache.org
> Date: Tue, 19 Apr 2011 14:36:31 +1200
> From: squid3_at_treenet.co.nz
> Subject: RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
>
> On Mon, 18 Apr 2011 19:15:53 +0000, Jenny Lee wrote:
> >> > What is the definition of OFFICE ?
> >> > request_header_access are fast ACL which will not wait for
> >> unavailable
> >> > details to be fetched.
> >>
> >> Ah! proxy_auth :)
> >>
> >> Jenny
> >
> >
> > acl OFFICE src 2.2.2.2
> >
> > request_header_access User-Agent allow OFFICE
> > request_header_access User-Agent deny all
> > header_replace User-Agent BOGUS AGENT
> >
> >
> > This works as expected when going direct.
> >
> > However, if there is a cache_peer, still the UA is replaced.
> > Cache_peer logs show connection is coming with the replaced UA
> > (cache_peer does not modify UA in its config).
> >
> > I must be missing something.
>
> Header mangling is done before forwarding. Regardless of where it is
> forwarded to. So there is no peer information available at that time.
>
> Also, "src" matches the website IP address(es). The public website IPs
> will not change because you have a cache_peer configured.
>
> Amos
 
Hello Amos,
 
You handle 500 users here alone. Must be a tiring day. I am matching my IP with "src".
 
Regardless, it doesn't work as expected when there is a peer forwarding.
 
Is there any debug options I must use and watch out for?

Jenny
                                                
Received on Tue Apr 19 2011 - 05:53:51 MDT

This archive was generated by hypermail 2.2.0 : Wed Apr 20 2011 - 12:00:03 MDT