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
