Squid_ The Definitive Guide - Duane Wessels [103]
Send All Requests Through Another Proxy?
You simply need to define a parent and tell Squid it isn't allowed to connect directly to origin servers. For example:
cache_peer parent.host.name parent 3128 0
acl All src 0/0
never_direct allow All
The drawback to this configuration is that Squid can't forward cache misses if the parent goes down. If that happens, your users receive the "cannot forward" error message.
Send All Requests Through Another Proxy Unless It's Down?
Try this configuration:
nonhierarchical_direct off
prefer_direct off
cache_peer parent.host.name parent 3128 0 default no-query
Or, if you'd like to use ICP with the other proxy:
nonhierarchical_direct off
prefer_direct off
cache_peer parent.host.name parent 3128 3130 default
With this configuration, Squid forwards all cache misses to the parent as long as it is alive. Using ICP should cause Squid to detect a dead parent quickly, but at the same time may incorrectly declare the parent dead on occasion.
Make Sure Squid Doesn't Use Neighbors for Some Requests?
Define an ACL to match the special request:
cache_peer parent.host.name parent 3128 0
acl Special dstdomain special.server.name
always_direct allow Special
In this case, cache misses for requests in the special.server.name domain are always sent to the origin server. Other requests may, or may not, go through the parent cache.
Send Some Requests Through a Parent to Bypass Local Filters?
Some ISPs (and other organizations) have upstream providers that force HTTP traffic through a filtering proxy (perhaps with HTTP interception). You might be able to get around their filters if you can use a different proxy beyond their network. Here's how you can send only special requests to the far-away proxy:
cache_peer far-away-parent.host.name parent 3128 0
acl BlockedSites dstdomain www.censored.com
cache_peer_access far-away-parent.host.name allow BlockedSites
never_direct allow BlockedSites
Exercises
Toggle your prefer_direct and/or nonhierarchical_direct settings and look for any changes in the access.log.
Enable netdb and view the netdb cache manager page after Squid has been running for a while.
If using ICP or HTCP, count the percentage of requests that experienced a timeout waiting for replies to arrive.
If you used —enable-cache-digests and have a reasonably full cache, disable the digest_generation directive and note any change in memory usage.
Use your operating system's packet filters to block ICP or HTCP messages to your neighbors. How quickly does Squid change their state from alive to dead, and back again?
Chapter 11. Redirectors
A redirector is an external process that rewrites URIs from client requests. For example, although a user requests the page http://www.example.com/page1.html, a redirector can change the request to something else, such as http://www.example.com/page2.html. Squid fetches the new URI automatically, as though the client originally requested it. If the response is cachable, Squid stores it under the new URI.
The redirector feature allows you to implement a number of interesting things with Squid. Many sites use them for access controls, removing advertisements, local mirrors, or even working around browser bugs.
One of the nice things about using a redirector for access control is that you can send the user to a page that explains exactly why her request is denied. You may also find that a redirector offers more flexibility than Squid's built-in access controls. As you'll see shortly, however, a redirector doesn't have access to the full spectrum of information contained in a client's request.
Many people use a redirector to filter out web page advertisements. In most cases, this involves changing a request for a GIF or JPEG advertisement image into a request for a small, blank image, located on a local server. Thus, the advertisement just "disappears" and doesn't interfere with the page layout.
So