[BFilter-users] Re: Signal handler request

[gypsy <gy...@is...>]

Joseph Artsimovich wrote: 
> > OK.  I have neither need nor desire for GUI.
> So, should I implement rereading the config in the master process and ignore
> the problem of running backends not catching the changes?
I don't know.  

Probably it is more trouble than it is worth.  Some of the issues:
  Running backends
  Signal USR1 is already in use
  Typographical errors in config
  Assigning a port already in use 
  Once correctly set up, config should never need to be changed
  Other potential problems I haven't yet thought of yet

So let us idiots manually kill and restart bfilter if we change its
config.  At least for now.

> > > > I am confused by "next-hop".  What is its purpose/what does it do?
> > > > Could we please have comments in ~config and/or docs on sourceforge?
> > >
> > > Hop is basically a way from one proxy (or a client or a sever) to
> > > another.
> >
> > Erm.  I think you left out a critical phrase or word in the above line.
> >
> > My setup works with next-hop commented and the following 3 lines
> > properly configured, but I STILL have no clue what next-hop is for <g>.
> ; next-hop http proxy
> is just a comment.  Well, I guess only people who've read the HTTP standard
> have an idea of what hops have to do with proxies, so I should replace it
> with something like "http proxy to forward to".
If I understand you correctly, "next-hop http proxy" is a comment, not a
directive.  If that is the case, then just remove that text entirely. 
The rest of the [forwarding] section is self documenting, so it does not
need that text.  Having it there, expecially where it is, confused me.
 
> Compiling bfilter with gcc 3.x is not a good idea anyway.  It will make it
> several times slower, while gcc-2.95.3 build actually outperforms icc 7.
Comment:  This is going to cause you problems in the future.
 
> > > > Q:  Does rules.local override or supplement rules?  IOW, if rules.local
> > > > is empty, does rules still apply?
> > >
> > > It supplements them.  Here is what it does exactly:
> > > 1. Read a rule block from rules.local.
> > > 2. Fill the absent parameters with defaults from rules.local (normally
> > > there are no defaults there, unless you want to override global
> > > defaults). 3. If rules contains a block with the same pattern, use this
> > > block to fill the parameters which are still absent.
> > > 4. Fill the absent parameters with defaults from rules.
> > > 5. Fill the absent parameters with the hardcoded defaults.
> >
> > Beautiful.  Please put this just as you wrote it in the top of
> > rules.local.
> Actually it's not how bfilter works, it's just a way to think about it.  The
> 3rd step is especially incorrect.  The real implementation is too complex to
> describe, but its main feature is that the performance is nearly constant
> with any number of rules.
Don't be so picky!  The above description is what the user needs to know
(even if it is not 100% accurate) so PLEASE put it in rules.local.  

If you wish, you can include some wording that lets the user know that
is is an oversimplification, but I doubt that such a disclaimer is
necessary.
 
> > Here's what I found, and it should be in the docs somewhere:  Empty the
> > browser's cache before you complain about things that bfilter misses ;)
> Since most of the pages these days are dynamic (and thus ignore
> If-Modified-Since header), clearing the cache is not needed in most cases.
> Restarting the browser is a must however.
> I think I'll write a small FAQ and put it to the site.
A FAQ is very desirable.  Please do that.

I did restart the browser.  It is not enough.  Clear the cache AND
restart.

Short story not really pertinent to this discussion:
/start/
What happened to me is that I set up Netscape to proxy bfilter and then
immediately went to www.zdnet.com - where all was fine (I NEVER go there
because of all the banner ads, so nothing was in Netscape's cache).  I
closed Netscape.  Later on, I went to check my Yahoo mail, and the ads
appeared!  I was upset so I reconfigured /etc/bfilter/config to next hop
to privoxy, but bfilter ignored the change.  So I tried 'killall -USR1
bfilter' hoping it would cause bfilter to reread config.  Instead,
bfilter terminated.  
Set up like this
  BFILTER -> PRIVOXY -> APACHE
the ads disappeared.  Set up like this
  BFILTER -> APACHE
the ads returned.

I then started this thread, asking for USR1, an explanation of the role
of rules.local, and for a conversion of privoxy rules to bfilter. 
Because of your excellent explanation of rules plus asking if privoxy
rules were really necessary, it eventually occurred to me to kill the
cache.  Now all is well.
/end/

Thanks for all your help and time.

gypsy