Hi Amos,
thanks for answering.
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.
this is not done to save on traffic, but to not kill the web server with
all the requests.
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.
Just so we're on the same page - this one's not a refresh_pattern, we're
setting the headers in the file itself/web server. By the way, the web
server is IIS 7.5 and the file is .ashx(for js and css). The squid
version is 2.7.9
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.
I'm not sure I understand this one. Can you explain a bit better?
No. refresh_pattern is a URL-staleness estimate calculation. The only
relevant things are the URL and some HTTP headers.
Regarding URL. It would be much, much easier if the following would work:
www.example.com/ResourceHandler.ashx?v=11030111&fileSet=JS_FW&type=text/javascript
this is the file. Now shouldn't changing the URL, i.e. the number in the
middle, make squid go to the web server?
Because, what we see now is that squid doesn't care about the change and
just continues serving the old version as long as it's fresh.
I guess this started when I put in the refresh_pattern with
ignore-reload, but I'm not sure about it.
Thanks,
Lenny.
