Table of Contents for

Squid: The Definitive Guide

Synopsis

Every HTTP request that Squid receives is marked as either hierarchical or nonhierarchical. This terminology is somewhat confusing. A request is hierarchical when there is a possibility it could be a cache hit in one of the neighbors. In other words, if the information in the request indicates that the response may be cachable, the request is hierarchical. A request is marked nonhierarchical when Squid thinks there is no chance of getting a hit from a neighbor.

Squid uses the hierarchical flag to decide whether or not it should query neighbors for the request. If the request is hierarchical, Squid may perform ICP/HTCP queries, or use Cache Digests, to locate cache hits in neighbors. Otherwise, Squid may forward the request directly to the origin server or select a parent based on some other technique.

Squid has a few hardcoded rules that determine if a request is hierarchical. For example, only GET requests are hierarchical. Squid never expects cache hits on non-GET requests. Another rule is that requests including authentication information are nonhierarchical. The hierarchy_stoplist directive allows you to customize the algorithm further. The stoplist is simply a list of strings. Squid searches the requested URL for these strings. The string comparison is case-sensitive. In the case of a match, the request becomes nonhierarchical. The default configuration is to search for cgi-bin and ? so that queries and other CGI responses aren’t hierarchical.

Note that the hierarchical flag determines only whether or not Squid queries its neighbor caches. It doesn’t determine which requests must, or must not, be sent to parent caches. The always_direct and never_direct access lists have that responsibility.

hierarchy_stoplist string ...

hierarchy_stoplist cgi-bin ?

hierarchy_stoplist .cgi
hierarchy_stoplist http://www.mysite.org