On Wed, Feb 09, 2011 at 05:54:25PM +1300, Amos Jeffries (squid3_at_treenet.co.nz) wrote:
> You have the general idea of how to prevent things being re-used
> form disk (a disk file will likely still be opened for backing the
> RAM in-transit copy).
>
> There are two problems though:
> 1) each ACL name can only have one type. You need one for
> urlpath_regex and anther one for the rep_mime_type
>
> 2) the rep_mime_type being a *reply* mime type will not match on
> requests when decision is made whether to open a file and store the
> future data directly.
>
> I'm still wondering though why you want to do this? all the media
> types which can be proxied by Squid are potentially cacheable for a
> great bandwidth/speed savings. The non-cacheable ones will get
> discarded anyway.
I am thinking of it like in "iptable terms".
Assume iptable finds a certain type of package and I placed a rule e.g. "-A eth0_input -p tcp --sport 993 -j ACCEPT" the packet is let through without further bothering anything, it is basically handed on and if this is a router, its handed over to the next interface with NO file on disk, not logged ... no trace whatsoever.
So, if I as a system administrator, dont care about media packages (radio) and everyone listens to different radio station anyway
* I like people who smile at work and hum to their music ;-)
* I have ample bandwith
* caching of packages that are not used again is useless
* logging is useless because I am really not interested seeing them in the logs because I can "hear" them anyway ;-)
so all I want squid to just simply accept it without doing anything to it "aka -j ACCEPT", not even logging it.
Hence my question(s).
Jobst
-- Student to Teacher: Sir, what's an oxymoron? .... Teacher to Student: Microsoft security. | |0| | Jobst Schmalenbach, jobst_at_barrett.com.au, General Manager | | |0| Barrett Consulting Group P/L & The Meditation Room P/L |0|0|0| +61 3 9532 7677, POBox 277, Caulfield South, 3162, AustraliaReceived on Wed Feb 09 2011 - 05:18:33 MST
This archive was generated by hypermail 2.2.0 : Wed Feb 09 2011 - 12:00:02 MST