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
