Hierarchy Control
Synopsis
Squid offers various mechanisms to control how requests are forwarded. The most important are never_direct, always_direct and hierarchy_stoplist. They interact with each other and with a request's implicit characteristics to determine how a request will eventually be satisfied.
The Steps
The various directives are evaluated in this order:
always_direct
if it matches as allow, go to origin
never_direct
if it matches as allow, go to a parent instead of origin in the cases below
hierarchy_stoplist
if it matches as allow, go to origin
- determine if a request is hierarchic
- if it is, check whether siblings or parents have the object via cache digests or ICP. In case of hit, ask the fastest among those hiting for the object
- go to origin
What makes a request hierarchic
The purpose of cache hierarchy is to maximize the chance of finding objects in siblings, so a set of heuristics is applied to try and determine in advance whether an object is likely to be cacheable. A few objects are not cacheable, and are thus not hierarchic. Those are:
- reload requests
- cache validations with non-Squid ICP peers
requests for HTTP methods other than GET, HEAD or TRACE
- authenticated requests