Hey there,
I want to make sure you understand the meaning of a 302 code response:
http://www.ietf.org/rfc/rfc2616
describes what a 302 means..
The main issue is that a service provides a 302 which redirect to itself...
302 responses are fine..
They do make the internet a lot prettier than it was before.
I like it very much when some dl.manager.software.domain.example.com is
doing a small 302 towards local.mirror.manager.software.domain.example.com.
Which basically what Fedora does.
You contact the mirror manager site with a request and it then redirects
you towards the faster(by a small calculation of ASN and other stuff)
mirror.
The main issue is that a 302 redirects towards another resource..
When you force StoreID based only on some parts of the url you probably
will end up getting the mentioned situation.
In order to make it possible there are couple ways to do so.
Internally order squid to not store 302 responses which is not a RFC
friendly story.(squid do try to match them...)
Externally identify the 302 response before the client tries to fetch it
using let say a "crawler" that I have written for this specific task.
Externally read each response headers using ICAP and to invalidate the
caching of this specific object.
Or.. another nice thing: add a range pattern which matches all
ranges=0-X and do not cache them or cache them otherwise.
Another solution is to take a good look on the url which is being
redirected into by the 302 response.
if in the response there is a signature that matches all 302 redirect
responses adding it to the "store_id_access deny acl" would solve this
problem.
I hope the above helps..
I posted somewhere the helper with the crawler code and I think that a
TPROXY helper can be written to do the crawling.
Eliezer
On 10/08/2013 05:34 PM, Alfredo Rezinovsky 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.
