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

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.

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 - 19:46:20 MDT