On 12/10/2013 11:38 a.m., Alex Rousskov wrote:
Hello,The attached patch adds reply_from_cache and reply_to_cache squid.conf directives to control caching of responses using response info. The reply_from_cache directive can prevent serving of HITs while reply_to_cache can prevent storage of MISSes. The two can be combined or used independently. As you know, the existing "cache" directive does both at the same time. However, the "cache" directive is checked before Squid has access to the response and, hence, could not use response-based ACLs such as http_status. Response-based ACLs may be essential when fine-tuning caching. Squid Bug 3937 (StoreID can lead to 302 infinite loop) is a good use case. The patch also updates old "cache" directive documentation to provide more information, to help folks distinguish the three related directives, and to polish for clarity.
I have been considering way to make the "cache" directive the top level of a set of the caching configuration. Similar to how auth_param is the tope level of most auth scheme options.
Would you be able to make "cache" directive accept two alternative parameter alongside allow/deny as the first field and then process the rest of the line according to that field?
I would suggest "store-miss" and "send-hit" for those parameters.
Caution: reply_from_cache is one more case that can trigger bug 3480 segfaults.
+1 on the patch in that bug report. Amos
