On Wed, 02 Mar 2011 16:11:55 +0200, Leon Volfson wrote:
Hi,
I have a few squid servers in front of web servers (accelerator
setup).
Since the website is very dynamic, I had to turn off the client
refresh action:
refresh_pattern -i ^http://www.website.com 14400 80% 43200
ignore-reload
but then I got the problem: some files that have a 7 days caching
time - I have no way of refreshing them if I modify the file on the
webserver.
NP: The safe way to save on traffic while obeying the standard is
"reload-into-ims". Which converts a full force-reload into an efficient
revalidation.
If the server app fails to perform revalidation then one of efficiency
or reliability are screwed.
Client refresh is not that commonly used by modern software. You should
not need this unless you still have a large IE5/IE6 visitor base or are
receiving peer-relayed requests from squid-2.5/2.6 peers.
To make it clearer, I have some .js or .css file which has a max-age
of 7 days. It's cached by squid and everything's great.
After a day I modify the file, but the squid keeps serving the old
version.
What are the possible solutions in these situations (besides
shortening the max-age)?
For this refresh_pattern to have any effect the Cache-Control: and
Expires: headers must be missing or unusable from the reply object squid
receives from the server. max-age control being too high with no
last-modified header makes more sense as the core problem.
Making those .js and .css non-dynamic would go a great way towards
stability and let the server present last-modified headers and correct
IMS handling. Otherwise implement some of it yourself in the scripts
which server them up.
Is there any way to have another refresh_pattern rule based on my
local IP (acl)?
No. refresh_pattern is a URL-staleness estimate calculation. The only
relevant things are the URL and some HTTP headers.
You could work around this using squid-3.1 with the public http_port
having "ignore-cc" to disable client specs (instead of the overly broad
refresh pattern) and do admin requests with reload through a separate
forward-proxy port.
Amos
