Re: [squid-users] negative_ttl

On Mon, 21 Sep 2009 17:12:44 -0800, Chris Robertson <crobertson_at_gci.net>
wrote:
> Quin Guin wrote:
>> Hi,
>>
>> I am seeing a behavior with the negative_ttl option and I would like to
>> get confirmation on its behavior.
>>
>>
>> I am using 2.7.Stable6
>>
>> I am having an issue with a content provider that is setting the
>> max_age=604800 on 503 error pages and so their 503 error pages are
>> getting cached for the length expire time.
>
> If it's just 503's you are having trouble with...
>
> acl HTTPStatus503 http_status 503
> cache deny HTTPStatus503
>
> ...will deny caching of any response with a 503 code. Fine tune it with
> an additional dstdomain acl as needed.
>
>> I know that the content provider should correct this and I have
>> communicated that to them several times but it gets fixed and then it
>> gets set again..ugh!! So everyone saying SQUID has a bug or broke..

Set again? (a) you mean the provider is undoing their max-age fix? or (b)
that the pages coming out of squid have it set that way despite the
provider being correctly set at the time?

(b) is a Squid problem, probably resolved by purging the relevant URLs from
cache after the provider fix happens. 2.7 does not contain bug #7 so should
self-correct when that week is over.

(a) does seem to be a issue somewhere between the provider web Server and
Squid. It may be the provider themselves, or a cache between you two.

/personal opinion::
Specifying that temporary (possibly from only a single request) network
failures should be reported to all visitors for a week after they occur is
very excessive. IMHO the caching timeouts of 5xx should be in the order of
minutes, 4xx possibly hours. Not days or weeks for either.

>>
>> I have set the "negative_ttl 0" in hopes that the negatively cached
pages
>> doesn't get cached at all not even for the default 5 min. This works for
>> pages that don't have max_age values or very low ones.. I just want to
>> confirm that this is the expected behavior for negative_ttl.

This will not impact on your problem, but....

... you should have that anyway. Setting it to zero disables Squids forced
minimum caching time, leaving squid to follow the correct RFC-compliant
behavior. Which is defined by the 4xx/5xx reply Expires: and Cache-Control:
headers received, or to discard immediately if they send none.

I thought 2.7 had the correct max-age handling. I suspect there may be
another header or CC: value sent which impacts on the caching. 2.7.STABLE7
has a fix for re-prioritizing the stale-* CC: value, and Expires: header
being present has priority over max-age.

Chris Robertsons solution will get you around the problem providers
headers.

>>
>> If so I think my next course of action in the 2.7 build line is to use
>> and acl with deny on http status values? If anyone has done this and
>> would like to share what they did or can point me to some docs or
>> something similar I would appreciate that.
>>
>>
>> I know 3.1 have the ability to do what I need but I am not ready to roll
>> that out to production yet.
>>
>> Thanks,
>>
>> Quinguin
>>
>
> Chris

Amos
Received on Tue Sep 22 2009 - 03:18:52 MDT