> To: squid-users@xxxxxxxxxxxxxxx > Date: Tue, 19 Apr 2011 14:36:31 +1200 > From: squid3@xxxxxxxxxxxxx > Subject: RE: 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
