[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-dev
Subject:    RE: ACL convention for content filtering?
From:       "Robert Collins" <robert.collins () itdomain ! com ! au>
Date:       2001-01-30 1:27:12
Message-ID: EA18B9FA0FE4194AA2B4CDB91F73C0EF7991 () itdomain002 ! itdomain ! net ! au
[Download RAW message or body]

> -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@hem.passagen.se]
> Sent: Tuesday, 30 January 2001 12:11 PM
> To: Joe Cooper
> Cc: Squid Dev; Moez Mahfoudh
> Subject: Re: ACL convention for content filtering?
> 
> 
> I think you need to define a new "acl" concept for this to work. The
> current "acl" concept is only designed for true/false evaulations, not
> active rewrites.

We only need a true false evaluation - to decide whether to apply a
rewrite rule.

> 
> The ACL scheme can be used for screening what to apply the filters to,
> but not the actual data munging.

yes.

> 
> normal "access" rule:
> 
> acl myregexfilter filter_word_regex naughtyword
> filter bleep replace bleep
> filter_access bleep allow myregexfilter
> 
> "acl" based filter rules, like deny_info:
> 
> acl myregexfilter filter_word_regex naughtyword
> filter bleep replace bleep
> filter_content deny myregexfilter
> filter_match myregexfilter bleep
> 
> I'd probably prefer the last approach (filter_content). It 
> can be set up
> to require less computing power (especially if there is many filters),
> but is unfortunately a bit harder to configure..
> 
> Anyway, the main issue here (config syntax) is that ACL processing
> should use lists of acl's to allow short-circuits for common content
> which should not be filtered.

Yes, I've done that and it does that. I'm just in the process of making
it generic and it should be ready for testing.

It follows the outline of my reply to Joe's Mail.

Rob

[prev in list] [next in list] [prev in thread] [next in thread]