Re: [squid-users] Question about refresh_pattern and TCP_MEM_HIT

From: Silamael <Silamael_at_coronamundi.de>
Date: Wed, 19 Sep 2012 08:51:40 +0200

On 09/19/2012 02:12 AM, Amos Jeffries wrote:
> On 19/09/2012 9:10 a.m., Eliezer Croitoru wrote:
>> On 9/18/2012 6:01 PM, Silamael wrote:
>>> refresh_pattern foo.example.org 0 0% 0
>>> refresh_pattern . 0 20% 14400
>>>
>>> Now, if i fetch something from foo.example.org i get a
>>> TCP_CLIENT_REFRESH_MISS/200
>>> The following request for the same url is shown in the squid.log with
>>> TCP_MEM_HIT/200.
>>> If i understand this correctly the TCP_MEM_HIT means that squid did not
>>> reload the requested url but served the request with the object still in
>>> memory, isn't it?
>>> If so, I'm wondering why this url is kept in the memory cache. The
>>> refresh_pattern above should prevent this case and force squid to reload
>>> the asked object every time.
>>>
>>> So, what's the explanation for this behaviour?
>>>
>>> Thanks in advance!
>> The refresh_pattern is regex which might just not match all your request.
>> if you do not want to cache you dont change the refresh_pattern to
>> 0... but use the:
>> cache deny acl
>
> refresh_pattern is *only* a set of default values to apply in absence of
> cache-control and expiry headers from the server for Squid to use to
> determine staleness on followup requests.
>
> This is why the default (/cgi-bin/|\?) pattern with all zeros is
> recommended for use on dynamic content. It defaults to not caching
> *unless* the server provides proper caching headers. In which case it is
> safe to cache.
>
> I would say from that description that your requested resource response
> contains all the required HTTP/1.1 headers to permit and specify both
> cacheing and expiry limitations on the tested URL.
>
> Amos

Ok, so if a response contains valid headers concerning caching, these
are taken instead of using the matching refresh_pattern? So, if i want
some URLs being served completely without caching, i have to use cache
deny, right?

-- Matthias
Received on Wed Sep 19 2012 - 06:51:50 MDT

This archive was generated by hypermail 2.2.0 : Wed Sep 19 2012 - 12:00:04 MDT