Re: [squid-users] refresh_pattern based on acl

On 04/03/11 02:10, Leon Volfson wrote:
> 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?

Making the .ccs and .js static files which are just picked up and duped
out unchanged by the ResourceHandler.ashx. (called server-side caching)

With some logic in ResourceHandler.ashx to detect If-* HTTP headers and
reply with 304 whenever possible instead of dumping the object out. The
most common being If-Match and If-Modified-Since (abbrev. IMS).

Both of these reduce back-end CPU consuption and raise the load it can
handle. 304 results allow proxies to dynamically adjust their caching
periods per-URL. So while each IMS request may in fact use the same CPU
etc resources as any full fetch the result of sending 304 back causes
less total fetches from the proxy.

>>
>> 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?

Squid does consider them different ... unless you have some store-URL
re-writing going on to prevent it.

Also, squid-2 shipped with defaults which prevented query-string URLs
caching. Check that those have been removed as per:
   http://wiki.squid-cache.org/ConfigExamples/DynamicContent

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

I don't think so. Those URL changes would make refresh_pattern consider
them two different objects even if it was used.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.11
   Beta testers wanted for 3.2.0.5