Re: [squid-users] http 302 status and storeid: infinite loop problem

From: Eliezer Croitoru <eliezer_at_ngtech.co.il>
Date: Wed, 09 Oct 2013 00:32:51 +0300

On 10/08/2013 10:45 PM, Nikolai Gorchilov wrote:
> That's why it is necessary to have an acl clause that prevents Squid
> from caching a page based on contents of the response headers,
> especially status code.
Hey,

Or just let server admins put the right headers for the right objects..
A simple header can mean that the response in not cachable..
ho and by the way YT videos are cachable by defalut... no need to force
too much refresh_patterns..

Eliezer

>
> On Tue, Oct 8, 2013 at 5:34 PM, Alfredo Rezinovsky
> <alfredo_at_fing.uncu.edu.ar> wrote:
>> El 08/10/13 11:18, Niki Gorchilov escribió:
>>
>>> Hi there.
>>>
>>> Started playing with Squid 3.4.0.2 store_id feature (thanks Eliezer for
>>> the implementation) and discovered an unresolvable issue, due to the
>>> caching of 302 results (I know it's happening when only Expires header
>>> is present, but anyway).
>>>
>>> Imagine the following scenario (that happens quite often): an CDN node
>>> currently offline for maintenance, redirecting all the traffic to
>>> another node with 302 Moved Temporary response.
>>>
>>> As the first node's url has been normalized by the store_id helper,
>>> the response gets cached under the squid.internal url.
>>>
>>> Now, when Squid follows the redirect to the new CDN node, the store_id
>>> helper returns the same normalized url (as intended :-), so the cached
>>> 302 result pops up again, forcing squid to reconnect this same node...
>>> Boom! Infinite loop
>>>
>>> Any suggestions how to avoid this loop? Tried playing with http_status
>>> acl but discovered it's not applicable in this scenario (as discussed
>>> by Amos and Eliezer more than a year ago).
>>>
>>> Without a method to disable caching of 30x results from squid.conf
>>> store_id feature is not usable, IMHO!
>>>
>>> Best,
>>> Niki
>>
>> You can avoid caching addng a header using ICAP
>>
>> I managed to fix this purging the resource as fast as I can. With a log
>> monitor. A very bad solution.
>>
>> The whole store system has a problem. The store decision, including the
>> store id can't use response headers.
Received on Tue Oct 08 2013 - 21:33:01 MDT

This archive was generated by hypermail 2.2.0 : Wed Oct 09 2013 - 12:00:05 MDT