Re: [PATCH] reply_from_cache and reply_to_cache

On 15/10/2013 2:24 p.m., Eliezer Croitoru wrote:
> Couple notes in between the lines.
>
> On 10/15/2013 04:06 AM, Alex Rousskov wrote:
>>
>>> >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

I assume by "early" you mean a backwards compatible "cache deny foo" lines?

What I was thinking for these was the above config is parsed into the
two sequences:

  cache store-miss allow foo
  cache store-miss deny foo # converted from "cache early deny foo"

  cache send-hit allow foo
  cache send-hit deny foo # converted from "cache early deny foo"

We only have two lookup points: pre-cache and post-reply. This is no
more or less confusing than when any other independent access control is
interleaved - say your reply_from_cache / reply_to_cache list in that
same above order. It comes down to clear documentation and clear
backward compatibility support. Which we can easily do for this one.

The "no_cache" directive changed its semantics slighty when becomming
"cache" - used to mean imply the Cache-Control:no-cache directive
received from client. If it had that original meaning still it would
today have quite different behaviour than what it does now -
invalidating content would not happen for a start.

Another idea is whether to add a name= parameter to the cache_dir and
have "cache X allow/deny ..." rules per storage area. To go a little
further than min/max object sizes.

> If I do not know squid it looks a bit bettr that ^^ way.
> But since I know squid.. the next paragraph describe a bit what I think:
>>
>> 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"
>
> A small question about the "send_hit" is it means like "send to client
> a HIT" ??

That is the intention. Send client *if* it is a HIT. Thus only relevant
on HIT responses.

I think store_miss and send_hit are the best out of those above.

The naming of HIT directive is a bit tricky, but the above is no more or
less ambiguous than reply_from_cache.
Perhapse "lookup" or "find", "seek" , "search" somethign along those
lines? instead of send-hit or reply_from.

    cache_lookup allow/deny has a nice clear semantic to it.

    cache_store_miss

Even cache_write / cache_read are somewhat close to the intended behaviour.

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

Sure and I agree it needs to be in there with the current style of
things. It just needs to be at the front of the directive name as part
of that per-component style to keep it inline with the others.

> +1 ^^
>
>>
>>
>> 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.

Hmm, yes. We are probably better reserving the "hit" part of the naming
for that type of thing. eg "cache_force_hit" to pretend the client sent
"Cache-Control:only-if-cached" directive. But beyond avoiding the word
for now thats out of scope here.

Amos
Received on Tue Oct 15 2013 - 03:28:25 MDT