Re: [PATCH] reply_from_cache and reply_to_cache

On 10/14/2013 07:06 PM, Alex Rousskov wrote:
> 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?

I forgot to mention that we can also try to do here what we did for
ssl_bump. That is, enlarging the set of actions from the default
allow/deny to allow/deny/ignore-miss/ignore-hit/store-miss/send-hit:

  cache deny foo # same as cache deny foo
  cache send-hit baz # same as reply_from_cache allow baz
  cache ignore-miss bar # same as reply_to_cache deny bar
  ...

I think that might be better than "store-miss allow" and friends because
this scheme follows the traditional "first matching rule wins" approach,
but I am not sure it is better than reply_to/from_cache. The problem
here is that, unlike ssl_bump, these directive(s) have to be checked
multiple times and some of the options do not make sense at some of the
decision points.

Current decision points are:

  * before hit/miss is detected (the current cache directive)
  * when a hit is detected (proposed reply_from_cache)
  * when a miss is being received (proposed reply_to_cache)

We had a rather similar problem with SslBump Peek and Splice project
configuration, and we could not find a simple, elegant solution to it.
The best we came up with, IIRC, was to ignore rules not applicable to
the current decision point. It works well in most cases, but it is
certainly not what I would call "simple".

If we apply the same solution here, we would have:

 - all "ignore-hit" and "send-hit" rules will be skipped both before a
hit is detected and when a miss is being received.

 - all "ignore-miss" and "store-miss" rules will be skipped both before
a hit is detected and when a hit is detected.

 - all "allow" and "deny" rules would be skipped when a hit is detected
and when a miss is being received (providing backward compatibility and
a quick shortcut)

IIRC, this will require serious development/changes in ACL code because
it currently cannot handle multiple deny-like actions, only multiple
allow-like actions.

$0.02,

Alex.
Received on Tue Oct 15 2013 - 04:09:18 MDT