Koozali.org: home of the SME Server

Squid Cache problem

dasx

Squid Cache problem
« on: April 07, 2005, 09:23:23 AM »
I have a problem with squid caching. A client uses a service that connects daily to a local website and downloads .mp3 files. These files change daily however they do not update as the name of each file is the same and squid is caching them so it hands back the same files. I have expanded the squid.conf template to include the following

acl userdomain dstdomain .userdomain.com
no_cache deny userdomain

always direct allow userdomain

However the only way I can get it to work (download correct daily mp3's) is to clear the cache manually.

Any help would be greatly appreciated.

mbachmann

Squid Cache problem
« Reply #1 on: April 07, 2005, 11:50:32 AM »

dasx

Squid Cache problem
« Reply #2 on: April 07, 2005, 12:28:12 PM »
Thanks for the quick response as the domain no_cache is not working (I don't quite understand why) would this be a correct entry??

acl MP3 url_regex .mp3$
no_cache deny MP3

At this stage the PURGE specific url command appears to be the most promising.

Do you think it would be ok to add the purge command to a script and run as a CRON job.

Thanks

cc_skavenger

Squid Cache problem
« Reply #3 on: April 07, 2005, 02:27:13 PM »
You might as well turn off squid.  It would be counter productive to run a purge on squid daily.  Any benefits that squid would provide would be lost daily.  

Just my opinion...

dasx

Squid Cache problem
« Reply #4 on: April 07, 2005, 02:42:25 PM »
cc_skavenger that is exactly what I'm trying to avoid.

Maybe I should clarify. The only thing I don't want to cache are the mp3's required for an internal phone system (Onhold clips). (Bandwidth is a bit tight)The program looks up a list of available updates from the supplier and it then requests the files. The problem is the filename never changes so the cached files are used instead of the new ones.

When I extended squid.conf with

acl userdomain dstdomain .userdomain.com
no_cache deny userdomain

always direct allow userdomain

(userdomain being the domain I want to not cache from)

This doesn't work.

I was hoping I could use something like

acl MP3 url_regex .mp3$
no_cache deny MP3

 to not cache a filetype but I don't know if this is correct.

My reading of the PURGE in  http://www.bmannconsulting.com/node/652 ? Or this: http://www.squid-cache.org/Doc/FAQ/FAQ-7.html
 was that it would clear the cache from that domain only.

Am I on the right track or way off base??

Thanks

Offline CharlieBrady

  • *
  • 6,918
  • +3/-0
Re: Squid Cache problem
« Reply #5 on: April 07, 2005, 04:48:54 PM »
Quote from: "dasx"
I have a problem with squid caching. A client uses a service that connects daily to a local website and downloads .mp3 files. These files change daily however they do not update as the name of each file is the same and squid is caching them so it hands back the same files.


Squid is caching the files because that is what it does. It won't do it if the website serving the files tells it the files will soon change, via a cache-control header. The problem is with the webserver configuration at the remote end, not with squid.

The browser can bypass squid via the correct keyboard+click sequences.

Offline CharlieBrady

  • *
  • 6,918
  • +3/-0
Squid Cache problem
« Reply #6 on: April 07, 2005, 04:53:35 PM »
Quote from: "dasx"

Maybe I should clarify. The only thing I don't want to cache are the mp3's required for an internal phone system (Onhold clips). (Bandwidth is a bit tight)The program looks up a list of available updates from the supplier and it then requests the files.


If the program uses the right request headers ("Pragma: no-cache" IIRC) then squid will ignore the cached copy and fetch files directly from source.

dasx

Squid Cache problem
« Reply #7 on: April 08, 2005, 07:40:09 AM »
Thanks charlie that makes sense.

cc_skavenger

Re: Squid Cache problem
« Reply #8 on: April 08, 2005, 07:45:03 AM »
Quote from: "dasx"
always direct allow userdomain


You didn't type the command like this did you?  

Should be always_direct allow userdomain

Just making sure.  I had done something like this for some domains and a typo caused me many days of headaches.