Re: [squid-users] TCP_REFRESH_HIT

When you mention ttl, which setting in particular are you talking about?
Have you setup refresh_patterns?

Against a refresh pattern you set a max age and various other options, to
control how that request is handled.
You can override things such as browser refresh (ignore-reload), if the web
server is setting expires header override with override-expire and you can
also override the last-modified header with override-lastmod.

To check object status, set 'debug_options ALL,1 33,10', then watch your
cache.log you should see requests and it will state if cacheable etc.
You can check request and response headers using a browser add-on, such as
firebug, that way you can see whether the web server is sending
cache-control headers.

bergenpeak_at_comcast.net wrote:
>
>
> Thanks. Right now I have the squid content "ttl" set to 3600. However,
> I think either the client is sending a "Cache control max-age=X" (where
> X is < 3600) or where the origin server is providing the object to squid
> with some cache control or equiv attributes to some value << 3600 which
> is forcing squid to reverify the content hasn't changed. I'm trying to
> determine if the issue is a client setting or origin server setting
> which is (apprently) overriding the squid setting. Wondering what
> knobs/tools exist within squid to see information about whether the
> object is "fresh" or "stale".
>
> Thanks
>
>
> tookers wrote:
>>
>> bergenpeak_at_comcast.net wrote:
>>
>>> Is there a way to look at the object cache in squid and determine the
>>> current "freshness" of the content?
>>>
>>> I've got content in the squid cache where I would expect the content to
>>> be a "TCP_HIT". Looking in the squid access.log, I see the access to
>>> the object being reported as "TCP_REFRESH_HIT". I'm trying to
>>> understand if it's something in the client request or something in how
>>> the original object was served up by the origin server which is causing
>>> squid to re-verify with the origin server that the object hasn't
>>> changed.
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>>
>>
>> Hi there,
>>
>> The Squid docs state that TCP_REFRESH_HIT is when an object is in cache
>> but
>> is STALE, the IMS (if-modified-since) query results in a '304 - not
>> modified'. So the object is cached but has reached the max-age (e.g. 60
>> secs), Squid then checks on the back-end to see if a fresh version of the
>> file exists. It comes back with status 304 because the object in cache,
>> and
>> on the back-end, are the same. If you are seeing lots of TCP_REFRESH_HIT,
>> and the file isn't updated very often, it may be worthwhile increasing
>> the
>> cache time.
>>
>> HTH.
>>
>
>
>

-- 
View this message in context: http://www.nabble.com/TCP_REFRESH_HIT-tp25891878p25894829.html
Sent from the Squid - Users mailing list archive at Nabble.com.