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