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@xxxxxxxxxxxxxxxx> 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.
