Thank you for the quick reply to my question and I have responded to some of your questions below. I also have a question about the acl that Chris sent.
This use http_status which is a 3.x feature and not a 2.7 so I am trying to use the rep_header and I am not having any luck with it. I have examples below and if someone could shed some light on how I can use the "status" values 50x that would be great.
> acl HTTPStatus503 http_status 503
> cache deny HTTPStatus503
acl HTTPStatus503 rep_header Status -i 503
cache deny HTTPStatus503
or
acl HTTPStatus503 rep_header status -i 503
cache deny HTTPStatus503
I have tried both and I have enabled debug and they are not getting hit. So I have tethereal traces to verify the status values contain 503 adn they do. I am using a very simple perl script to generate the 503 for testing and I am only using "Cache-control: max-age=240" so its short lived.
HTTP/1.1 503 Service Temporarily Unavailable
Date: Tue, 22 Sep 2009 12:45:43 GMT
Server: Apache/2.2.3 (Red Hat)
Expires: Tue, 22 Sep 2009 07:49:43 CDT
Cache-control: max-age=240
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Please see below for answers to other questions..
----- Original Message ----
From: Amos Jeffries <squid3@xxxxxxxxxxxxx>
To: squid-users@xxxxxxxxxxxxxxx
Sent: Monday, September 21, 2009 10:18:48 PM
Subject: Re: negative_ttl
On Mon, 21 Sep 2009 17:12:44 -0800, Chris Robertson <crobertson@xxxxxxx>
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?
Ans.. Yes provider is undoing their fixes.. I have not seen the (b) option happen.
(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.
Ans.. Purging does resolve it..yes it does self correct per the age value.
(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.
Ans.. it is between the provider and SQUID then squid reply with what was given but I do think they are using a reverse proxy because I have seen errors come it.
/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.
Ans.. I agree with you 100%.
>>
>> 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
