After a little bit of additional thinking, I believe in case of store_id rewritten request, we shall ONLY cache response with status code 200. In case of any other response code we have to leave the end-user application to find it's way to recover from it, including requesting the same object from other nodes. On Tue, Oct 8, 2013 at 5:18 PM, Niki Gorchilov <niki@xxxxxxxxxxxxx> wrote: > 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
