Re: [PATCH] reply_from_cache and reply_to_cache

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.
Received on Tue Oct 15 2013 - 01:06:07 MDT