Squid_ The Definitive Guide - Duane Wessels [49]
tcp_outgoing_address
This access list binds server-side TCP connections to specific local IP addresses. See Appendix A.
tcp_outgoing_tos
This access list can set different TOS/Diffserv values in TCP connections to origin servers and neighbors. See Appendix A.
header_access
With this directive, you can configure Squid to remove certain HTTP headers from the requests that it forwards. For example, you might want to automatically filter out Cookie headers in requests sent to certain origin servers, such as doubleclick.net. See Appendix A.
header_replace
This directive allows you to replace, rather than just remove, the contents of HTTP headers. For example, you can set the User-Agent header to a bogus value to keep certain origin servers happy while still protecting your privacy. See Appendix A.
Access Rule Syntax
The syntax for an access control rule is as follows:
access_list allow|deny [!]ACLname ...
For example:
http_access allow MyClients
http_access deny !Safe_Ports
http_access allow GameSites AfterHours
When reading the configuration file, Squid makes only one pass through the access control lines. Thus, you must define the ACL elements (with an acl line) before referencing them in an access list. Furthermore, the order of the access list rules is very important. Incoming requests are checked in the same order that you write them. Placing the most common ACLs early in the list may reduce Squid's CPU usage.
* * *
Tip
For most of the access lists, the meaning of deny and allow are obvious. Some of them, however, aren't so intuitive. In particular, pay close attention when writing always_direct, never_direct, and no_cache rules. In the case of always_direct, an allow rule means that matching requests are forwarded directly to origin servers. An always_direct deny rule means that matching requests aren't forced to go directly to origin servers, but may still do so if, for example, all neighbor caches are unreachable. The no_cache rules are tricky as well. Here, you must use deny for requests that must not be cached.
* * *
How Squid Matches Access Rules
Recall that Squid uses OR logic when searching ACL elements. Any single value in an acl can cause a match.
It's the opposite for access rules, however. For http_access and the other rule sets, Squid uses AND logic. Consider this generic example:
access_list allow ACL1 ACL2 ACL3
For this rule to be a match, the request must match each of ACL1, ACL2, and ACL3. If any of those ACLs don't match the request, Squid stops searching this rule and proceeds to the next. Within a single rule, you can optimize rule searching by putting least-likely-to-match ACLs first. Consider this simple example:
acl A method http
acl B port 8080
http_access deny A B
This http_access rule is somewhat inefficient because the A ACL is more likely to be matched than B. It is better to reverse the order so that, in most cases, Squid only makes one ACL check, instead of two:
http_access deny B A
One mistake people commonly make is to write a rule that can never be true. For example:
acl A src 1.2.3.4
acl B src 5.6.7.8
http_access allow A B
This rule is never going to be true because a source IP address can't be equal to both 1.2.3.4 and 5.6.7.8 at the same time. Most likely, someone who writes a rule like that really means this:
acl A src 1.2.3.4 5.6.7.8
http_access allow A
As with the algorithm for matching the values of an ACL, when Squid finds a matching rule in an access list, the search terminates. If none of the access rules result in a match, the default action is the opposite of the last rule in the list. For example, consider this simple access configuration:
acl Bob ident bob
http_access allow Bob
Now if the user Mary makes a request, she is denied. The last (and only) rule in the list is an allow rule, and it doesn't match the username Mary. Thus, the default action is the opposite of allow, so the request is denied. Similarly, if the last entry is a deny rule, the default action is to allow the request. It is good practice