Squid_ The Definitive Guide - Duane Wessels [87]
cache_peer Options
The cache_peer directive has quite a few options. I'll describe some of them here, and the others in the sections relating to specific protocols.
proxy-only
This option instructs Squid not to store any responses it receives from the neighbor. This is often useful when you have a cluster and don't want a resource to be stored on more than one cache.
weight= n
This option is specific to ICP/HTCP. See Section 10.6.2.1.
ttl= n
This option is specific to multicast ICP. See Section 10.6.3.
no-query
This option is specific to ICP/HTCP. See Section 10.6.2.1.
default
This option specifies the neighbor as a suitable choice in the absence of other hints. Squid normally prefers to forward a cache miss to a parent that is likely to have a cached copy of the particular resource. Sometimes Squid won't have any clues (e.g., if you disable ICP/HTCP with no-query). In these cases, Squid looks for a parent that has been marked as a default choice.
round-robin
This option is a simple load-sharing technique. It makes sense only when you mark two or more parent caches as round-robin. Squid keeps a counter for each parent. When it needs to forward a cache miss, Squid selects the parent with the lowest counter.
multicast-responder
This option is specific to multicast ICP. See Section 10.6.3.
closest-only
This option is specific to ICP/HTCP. See Section 10.6.2.1.
no-digest
This option is specific to Cache Digests. See Section 10.7.
no-netdb-exchange
This option tells Squid not to request the neighbor's netdb database (see Section 10.5). Note, this refers to the bulk transfer of the RTT measurements, not the inclusion of these measurements in ICP miss replies.
no-delay
This option tells Squid to ignore any delay pools settings for requests to the neighbor. See Appendix C for more information on delay pools.
login= credentials
This option instructs Squid to send HTTP authentication credentials to the neighbor. It has three different formats:
login=user:password
This is the most commonly used form. It causes Squid to add the same username and password in every request going to the neighbor. Your users don't need to enter any authentication information.
login=PASS
Setting the value to PASS causes Squid to pass the user's authentication credentials to the neighbor cache. It works only for HTTP basic authentication. Squid doesn't add or modify any authentication information.
If your Squid is configured to require proxy authentication (i.e., with a proxy_auth ACL), the neighbor cache must use the same username and password database. In other words, you should use the PASS form only for a group of caches owned and operated by a single organization. This feature is dangerous because Squid doesn't remove the authentication credentials from forwarded requests.
login=*:password
With this form, Squid changes the password, but not the username, in requests that it forwards. It allows the neighbor cache to identify individual users, but doesn't expose their passwords. This form is less dangerous than using PASS, but does have some privacy implications.
Use this feature with extreme caution. Even if you ignore the privacy issues, this feature may cause undesirable side effects with upstream proxies. For example, I know of at least one other caching product that only looks at the credentials of the first request on a persistent connection. It apparently assumes (incorrectly) that all requests on a single connection come from the same user.
connect-timeout= n
This option specifies how long Squid should wait when establishing a TCP connection to the neighbor. Without this option, the timeout is taken from the global connect_timeout directive, which has a default value of 120 seconds. By using a lower timeout, Squid gives