Re: [PATCH] reply_from_cache and reply_to_cache

From: Eliezer Croitoru <eliezer_at_ngtech.co.il>
Date: Tue, 15 Oct 2013 04:24:51 +0300

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
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" ??

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

Eliezer
>
>
> Cheers,
>
> Alex.
>
Received on Tue Oct 15 2013 - 01:25:02 MDT

This archive was generated by hypermail 2.2.0 : Tue Oct 15 2013 - 12:00:12 MDT