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
Received on Sat Oct 12 2013 - 02:55:55 MDT
This archive was generated by hypermail 2.2.0 : Tue Oct 15 2013 - 12:00:12 MDT