On 10/11/2013 08:55 PM, Amos Jeffries wrote: > On 12/10/2013 11:38 a.m., Alex Rousskov wrote: > >> 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.
> 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. We could do that, but I doubt that the advantages of that approach outweigh its drawbacks: Since each option is applied independently from others, it may only confuse folks that are used to our usual "first matching ACL rule wins" approach: cache store-miss allow foo cache send-hit allow foo cache early deny foo The last rule actually wins here, but the above configuration seems to imply the opposite to folks used to looking at Squid ACLs. I know we cannot use the "first matching rule wins" approach for some existing directives, but are you sure this approach works better for the two new directives we are discussing here? Also, the "scope" keywords (store-miss and send-hit) do not blend well with "cache" IMHO because of the overlap between "store" and "cache" as well as between "hit" and "cache". The advantage of your proposal is that it groups all directives under a common "cache" prefix, but it feels like that is not enough to justify this complexity and the "cache" prefix itself is already used in squid.conf for other things anyway (the "cache" term is too overloaded in Squid context). I am happy to rename * "reply_to_cache" to ("store_miss" or "cache_miss") or "miss_caching" * "reply_from_cache" to ("send_hit") or "hit_sending" if you think any of those name pairs are better. FWIW, the primary reason I used "cache" was to show similarity or connection with the existing "cache" option. The primary reason I used "reply" is to stress that these new directive can work with responses, unlike the old "cache". Reply_from_cache works pretty good IMO, but I certainly do _not_ consider "reply_to_cache" a good name on its own! BTW, I foresee us eventually supporting a new "force" action with these new options that will force Squid to cache something or serve a hit despite HTTP rules saying otherwise, but that is way outside this project scope. Cheers, Alex.