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

From: Alfredo Rezinovsky <alfredo_at_fing.uncu.edu.ar>
Date: Tue, 08 Oct 2013 11:34:47 -0300

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 - 14:34:58 MDT

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