On 11/17/2017 08:27 AM, Vieri wrote: > From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> >> 1. Your "works" and "does not work" setups currently differ in at least >> three variables: user agent name, slash after the user agent name, and >> acl negation in http_access. Find out which single variable is >> responsible for the breakage by eliminating all other differences. >> >> 2. Post two ALL,2 cache.logs, each containing a single transaction, one >> for the "works" case and one for the "does not work" case polished as >> discussed in #1. > I can't really do anything about #1 except maybe leave out the forward slash. > That's because my 2 examples are trying to achieve the opposite. You may be conflating two very different goals: A) Understanding why Squid does X. B) Configuring Squid to do what you want. My response was focused on the former. Once you understand, you can probably accomplish the latter on your own. To understand why two similar setups act differently, I would reduce the number of different variables until you find the variable that explains the difference. Yes, none of the tested reduced setups may do what you want your production Squid to do, but that should not matter for now. You are after understanding. The usual alternative to the above approach is trying random configurations until you think Squid works the way you want it to work. Usually, Squid still does not do what you think it does, but your test cases do not expose the difference. > My goal is to deny all client traffic from browsers that DO NOT have > a specific user-agent string. So this is a negated statement. There is no need to use negation for that. If the goodAgents ACL matches requests with "specific user-agent string", then you can do this: http_access allow goodAgents http_access deny all As you can see, there is no ACL negation or negative ACLs. > Common to both: > > acl allowed_useragent browser MyAllowedUAstring > acl denied_useragent browser MyDeniedUAstring > > # example 1: > http_access deny denied_useragent > http_reply_access deny denied_useragent If you want to block access to the origin server, do not use http_reply_access. Use http_access. > # example 2: > http_access deny !allowed_useragent > http_reply_access deny !allowed_useragent > > Then I run this from the client: > > # curl --insecure --user-agent MyAllowedUAstring https://www.gentoo.org > -> I was expecting to be allowed access since Squid denies "everything that's not" MyAllowedUAstring. Well, at least I should have passed the "deny" line in example 2. > However, I'm being blocked right there. > --------- > CONNECT 89.16.167.134:443 HTTP/1.1 > Host: 89.16.167.134:443 > ---------- > clientAccessCheckDone: The request CONNECT 89.16.167.134:443 is DENIED; last ACL checked: allowed_useragent As you can see, your CONNECT request was denied (because it lacks the User-Agent header). The rest does not matter much (for now), but Squid bumps the connection to serve the error page in response to the first bumped HTTP request (regardless of what that first bumped HTTP request looks like). Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
