RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
> Dear Jenny and Amos, > > I thought it worth mentioning that I too am having troubles with the > ACL processing of the "request_header_access User-Agent" configuration > directive. It seems like Jenny's issue is the same one I am seeing. > > Using a "src" ACL in the directive doesn't work when you have a cache > peer. The ACL is only ever checked to see if the IP address > 255.255.255.255 exists in the list. > > I know this was only reported recently, but I wanted to know if there > was a fix in the works or if Amos is still waiting for a fix to be > submitted. > > Thanks and Best Regards, > > Sean Butler I hired developer time for private patch. Seems to be working now. Will get you the patch once all is ready. Jenny
RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
Hello Amos, > To: squid-users@squid-cache.org > Date: Thu, 9 Jun 2011 13:02:49 +1200 > From: squ...@treenet.co.nz > Subject: Re: FW: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work > properly with aclnames? > > On Wed, 8 Jun 2011 17:01:39 +, Jenny Lee wrote: > > I just realized that "Cookie" headers are also not obeyed when going > > through peers. > > > > Everything works going direct, but nothing works if you are using any > > peers. > > > > I surely cannot be the only person out of all squid users that is > > bitten by this anomaly. > > > > Jenny > > > > Possibly not. Although most of the "anonymous" crowd just put "all" ACL > by instinct and leave it at that. Yes but this is not a server for 1 person. I block cookies, but I want to allow my OFFICE to pass cookies through. It seems like nothing except "all" works on this HEADER_ACCESS lines. Anything else has empty value and fails. 2011/06/08 22:50:26.271 kid1| ACLList::matches: checking all 2011/06/08 22:50:26.271 kid1| ACL::checklistMatches: checking 'all' 2011/06/08 22:50:26.271 kid1| aclIpAddrNetworkCompare: compare: [::]/[::] ([::]) vs [::]-[::]/[::] 2011/06/08 22:50:26.271 kid1| aclIpMatchIp: '[::]' found 2011/06/08 22:50:26.271 kid1| ACL::ChecklistMatches: result for 'all' is 1 2011/06/08 22:50:26.271 kid1| ACLList::matches: result is true 2011/06/08 22:50:26.271 kid1| aclmatchAclList: 0x7fff4e4885d0 returning true (AND list satisfied) > Did you check if 3.2.0.8 for the myportname problem? I browsed through Changelog for 3.2.0.8 but did not see any of my bugs addressed. I did not have myportname issue. > On the Cookie: header. Is the content coming from the peer cached? > Cookies are erased on cached HITs. httpSendRequest is not sending cookies to peers if "allow all" is not specified. Caching is disabled, proxy-only peers. Thanks. Jenny
RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
On Thu, 5 May 2011 00:00:37 +, Jenny Lee wrote: >> kid1| ACLChecklist::preCheck: 0x7504abc0 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: >> [::]/[:::::::ff00] ([::]) vs >> 2.2.2.0-[::]/[:::::::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
RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
> >> kid1| ACLChecklist::preCheck: 0x7504abc0 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: > >> [::]/[:::::::ff00] ([::]) vs > >> 2.2.2.0-[::]/[:::::::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? 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. Thanks. Jenny
RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
On Wed, 4 May 2011 20:40:33 +, Jenny Lee wrote: No difference whatever is done. PEER1, !PEER1, !PEER2... No peer... Seperate lines... SRC IP is never available, so it always fails. PEER is available though, I can make it work with using just PEER1. Going direct works also as expected. Thanks. Jenny kid1| ACLChecklist::preCheck: 0x7504abc0 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: [::]/[:::::::ff00] ([::]) vs 2.2.2.0-[::]/[:::::::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. kid1| ACL::ChecklistMatches: result for 'OFFICE_IP' is 0 kid1| ACLList::matches: result is false kid1| aclmatchAclList: 0x7504abc0 returning false (AND list entry failed to match) Is there an update on this? Shall I file a bug? 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 am going on about this matter since November-2010. Yes, you do seem to be the only one really interested in this :(. Your triage so far has been great and will help someone experiment to find the cause, but still falls just short of that code legwork and patching to fix it. Amos
RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
> No difference whatever is done. PEER1, !PEER1, !PEER2... No peer... Seperate > lines... > > SRC IP is never available, so it always fails. PEER is available though, I > can make it work with using just PEER1. Going direct works also as expected. > > Thanks. > > Jenny > > > kid1| ACLChecklist::preCheck: 0x7504abc0 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: > [::]/[:::::::ff00] ([::]) vs > 2.2.2.0-[::]/[:::::::ff00] > kid1| aclIpMatchIp: '[::]' NOT found > kid1| ACL::ChecklistMatches: result for 'OFFICE_IP' is 0 > kid1| ACLList::matches: result is false > kid1| aclmatchAclList: 0x7504abc0 returning false (AND list entry failed > to match) Is there an update on this? Shall I file a bug? I am going on about this matter since November-2010. Thanks Jenny
RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
> > 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. No difference whatever is done. PEER1, !PEER1, !PEER2... No peer... Seperate lines... SRC IP is never available, so it always fails. PEER is available though, I can make it work with using just PEER1. Going direct works also as expected. Thanks. Jenny kid1| ACLChecklist::preCheck: 0x7504abc0 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: [::]/[:::::::ff00] ([::]) vs 2.2.2.0-[::]/[:::::::ff00] kid1| aclIpMatchIp: '[::]' NOT found kid1| ACL::ChecklistMatches: result for 'OFFICE_IP' is 0 kid1| ACLList::matches: result is false kid1| aclmatchAclList: 0x7504abc0 returning false (AND list entry failed to match)
Re: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
On 26/04/11 05:27, Jenny Lee wrote: 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 2 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
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 2 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.
Re: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
On 21/04/11 13:04, Jenny Lee wrote: I have 3.2.0.1 and unfortunately this does not work either. I will check on 3.2.0.7 (would that make a difference?). May do. I don't recall changing anything there directly but the passing around of request details has been fixed in a few places earlier which may affect it. Also, do you have this part which I forgot to add? cache_peer name=X Yes I do, Amos. Here what I am trying to do is to brand our connections. Suppose we have a crawler. It would be nice if the crawler identified itself as such. On the other hand, I do not want to modify the UA of our OFFICE users. They should be passed as is. 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. I thought this would be relatively easy to accomplish in squid, after all it is very able and comes with the whole shabang and the kitchen sink, but unfortunately i have had no success so far. AFAIK it *should* only require that config you have. If we can figure out whats going wrong the bug can be fixed. 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
RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
> > I have 3.2.0.1 and unfortunately this does not work either. I will check on > > 3.2.0.7 (would that make a difference?). > > May do. I don't recall changing anything there directly but the passing > around of request details has been fixed in a few places earlier which > may affect it. > > Also, do you have this part which I forgot to add? > cache_peer name=X Yes I do, Amos. > > Furthermore, it would be nice to able to select UA like: > > > > request_header_replace User-Agent OFFICE Mozilla > > request_header_replace User-Agent HOME IE > > Well... > > request_header_access User-Agent deny OFFICE Mozilla > request_header_replace User-Agent HOME IE > > ... should also be working if a "browser" type ACL is used to check the > User-Agent field for "Mozilla". Actually, I am trying to fix a UA for source IPs. For example: If the connection is from OFFICE, set the UA to Mozilla. If the connection is from HOME, set the UA to Internet Explorer. > P.S.: Nice for some maybe, but which of the 3.5 million or more browser > U-A strings do you suggest we hard-code into Squid for faking like this? It should be left to hte user the way it is now. Here what I am trying to do is to brand our connections. Suppose we have a crawler. It would be nice if the crawler identified itself as such. On the other hand, I do not want to modify the UA of our OFFICE users. They should be passed as is. I thought this would be relatively easy to accomplish in squid, after all it is very able and comes with the whole shabang and the kitchen sink, but unfortunately i have had no success so far. Jenny
Re: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
On 21/04/11 05:56, Jenny Lee wrote: Reality after looking at the code: Mangling is done after peer selection right at the last milli-second before sending the headers down the wire. It is done on all HTTP requests including CONNECT tunnels when they are relayed. Peering info *is* available. But "src" ACL does not check for that property. If you have 3.1 I think you want to add a "peername" ACL like so: acl peerX peername X request_header_access User-Agent allow OFFICE !peerX ... I have 3.2.0.1 and unfortunately this does not work either. I will check on 3.2.0.7 (would that make a difference?). May do. I don't recall changing anything there directly but the passing around of request details has been fixed in a few places earlier which may affect it. Also, do you have this part which I forgot to add? cache_peer name=X Furthermore, it would be nice to able to select UA like: request_header_replace User-Agent OFFICE Mozilla request_header_replace User-Agent HOME IE Well... request_header_access User-Agent deny OFFICE Mozilla request_header_replace User-Agent HOME IE ... should also be working if a "browser" type ACL is used to check the User-Agent field for "Mozilla". P.S.: Nice for some maybe, but which of the 3.5 million or more browser U-A strings do you suggest we hard-code into Squid for faking like this? No, we picked to leave it optional and open for future browsers and tools to be developed. Especially since it is a standard violation to actually do any U-A changes. There are good reasons for *some* of those sites behaviour and each piece of the U-A has significant meanings. 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
RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
> Reality after looking at the code: > Mangling is done after peer selection right at the last milli-second > before sending the headers down the wire. It is done on all HTTP > requests including CONNECT tunnels when they are relayed. > > Peering info *is* available. But "src" ACL does not check for that > property. > > If you have 3.1 I think you want to add a "peername" ACL like so: > > acl peerX peername X > request_header_access User-Agent allow OFFICE !peerX > ... I have 3.2.0.1 and unfortunately this does not work either. I will check on 3.2.0.7 (would that make a difference?). Furthermore, it would be nice to able to select UA like: request_header_replace User-Agent OFFICE Mozilla request_header_replace User-Agent HOME IE Many sites require teh UA to come from known browsers. We tried randomizing UA but many things broke on destination sites. Thanks Jenny
Re: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
On 19/04/11 17:53, Jenny Lee wrote: To: squid-users@squid-cache.org Date: Tue, 19 Apr 2011 14:36:31 +1200 From: squ...@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 +, 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". So it was, topping of the month so far. :( Regardless, it doesn't work as expected when there is a peer forwarding. With a slightly clearer head :) the idea I was working off was that OFFICE / "src" will have the same result whether it is going down a peer or direct. Reality after looking at the code: Mangling is done after peer selection right at the last milli-second before sending the headers down the wire. It is done on all HTTP requests including CONNECT tunnels when they are relayed. Peering info *is* available. But "src" ACL does not check for that property. If you have 3.1 I think you want to add a "peername" ACL like so: acl peerX peername X request_header_access User-Agent allow OFFICE !peerX ... Oh and "header_replace" is now "request_header_replace" in 3.1.12 or later. Is there any debug options I must use and watch out for? There is not "must" involved, but if you want to want them... debug_options 11,6 The relevant line starts with "httpSendRequest: FD" followed by the full HTTP request headers passed on. 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
RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
> To: squid-users@squid-cache.org > Date: Tue, 19 Apr 2011 14:36:31 +1200 > From: squ...@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 +, 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
RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
On Mon, 18 Apr 2011 19:15:53 +, 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
RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
> > 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. Jenny
RE: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
Hello Amos, > 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
Re: [squid-users] Why doesn't REQUEST_HEADER_ACCESS work properly with aclnames?
On Tue, 5 Apr 2011 18:26:45 +, Jenny Lee wrote: Hello Squid Folks, Here is an excerpt from squid.conf.documented: # TAG: request_header_access # Usage: request_header_access header_name allow|deny [!]aclname ... This seems to work only as: request_header_access User-Agent deny all Why can't I do: request_header_access User-Agent deny all !OFFICE That second means: request_header_access User-Agent deny !OFFICE request_header_access User-Agent allow all aka request_header_access User-Agent allow OFFICE request_header_access User-Agent deny all or request_header_access User-Agent allow OFFICE1 request_header_access User-Agent allow OFFICE2 request_header_access User-Agent deny all It just does not allow OFFICE through without modification on (header_replace User-Agent). This is driving me crazy. I cannot modify user-agents of our executives. What is the definition of OFFICE ? request_header_access are fast ACL which will not wait for unavailable details to be fetched. Amos
