Re: [PATCH] reply_from_cache and reply_to_cache

On 15/10/2013 5:09 p.m., Alex Rousskov wrote:
> 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.

It does not solve the issue of using reply details in the ACLs though.
That is the most important goal here.

> 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)

How do you see 1 and 2 on that list being different?

The old cache directive makes no decision about whether the stores are
involved or not. It just determines between converting a HIT into a MISS
and (wrongly) causes invalidation of any stored content.

We need to change that decision point to being a decision whether store
is not-involved or is-involved.
  * If the store is not-involved no HIT is possibe, but also
invalidation and revalidation does not take place on already stored content.
  * if the store is involved, it may HIT, revalidate or invalidate
stored content

NP: this decision may be made irrelevant by HTTP protocol settings from
the client. Forced is-involved by CC:only-if-cached. Forced not-involved
by CC:no-cache.

The 3rd decision point, which is the only completely new one here to
make a local store behave as if CC:no-store was received from the server.
* if the store writing is denied CC:no-store makes no statement about
existing content (invalidation does not have to happen).
* if the store write is allowed, then existing content gets
invalidated/revalidated as per HTTP normal requirements.

NP: we have been talking in terms of HIT/MISS so far, but for the MISS
checks we also need to consider REFRESH/revalidate backend requests.
** In the event that Squid is performing a REFRESH to the server do we
want the store-write denial case to prevent updating of the cached
content? or to treat that somehow different?

Overall I am inclined to scope these ACL acess checks in terms of
read/write access to the store rather than HIT/MISS on stored contents.
Doing so makes the criteria much more simple:
* First decision point is simply whether to involve store lookups
yes/no. This can only be made on request details (current "cache"
decision point with new semantics)
* Second decision point being whether to write any new information found
(regardless of MISS/REFRESH states) back to cache. This can be made
after receiving reply.

Amos
Received on Tue Oct 15 2013 - 04:42:53 MDT