Menu
▾
▴
#32 Filtering won't activate
I'm running Privoxy 2.9.14 for Windows (XP) from the downloaded
binary (I don't have a compiler.), and everything seems to work great
except the filtering.
The following:
+filter{html-
annoyances} \
+filter{content-cookies} \
+filter{js-
annoyances} \
+filter{no-popups} \
+filter{webbugs}
\
+filter{nimda} \
+filter{banners-by-size} \
are all set up
in the "default.actions" file to operate on all URLs, but I have been able
to test that at least "html-annoyances", "js-annoyances", and "no-
popups" are not functioning on a number of places. I am assuming
that the other filters are not working too. There are no error
messages, or log entries that mention filtering. There is a
"default.filter" reference ("filterfile default.filter") on a line in
"config.txt", and it is in the same directory.
I do have a
user.action file, but it doesn't touch filtering. - just a few items in the
"+block" section (and ".swf" added to the imagelist).
Any
suggestions?
TIA.
Logged In: YES
user_id=322640
This is likely to go nowhere unless someone can duplicate
this. So a few URLs would be good in order to:
a) verify the behavior (and still exists in devel version)
b) determine if it is a privoxy bug
c) or just some clever new way for site designers to annoy
users that the developers have not run across yet.
Jon or OES, do filter crunches get logged? If so, would it
be worthwhile to show as 'action crunch' or 'filter crunch'?
Logged In: NO
Here is an example of filtering not working straight from the default.filter
file:
# Kill OnUnload popups. Yummy. Test:
http://www.zdnet.com/zdsubs/yahoo/tree/yfs.html
I still get
popup!
I've also noticed that pages seem to load piecemeal even
though I thought that when filtering was on they were buffered, filtered and
"fed" to the browser all at once.
Just to be difficult, I have also noticed
oddities in the {-block} operation. I have:
/.*?ads?[0-9]?/
in the
{+block} section but:
/(down)?loads?/
/download/
in
the {-block} section. If I try the URL:
http://home.t-
online.de/home/CloneCD/download/
I get the "Request
Blocked" Privoxy page. If I
add:
/home/CloneCD/download/
to the {-block} section (or
anything more specific) I get through just fine. If I reduce it
to:
/CloneCD/download/
I again get the "Request Blocked
Privoxy page!
Is this weird or what??
Any comments?
Logged In: YES
user_id=322640
Do you get the popup just accessing that page, or filling in
the form? Here I don't get it just accessing the page (with
either Mozilla or NS) on Linux, but it does not look like
because Privoxy has done anything. What browser, IE?
Try this in your -block
/(.*/)?((up|down)lo|thre)ads/
As to the matching problem, for paths I believe you either
have to match the full path (meaning the part after the
domain), or use wildcards in there, so the pattern will expand.
www.some.com /path/to/downloads/here/
^ ^
domain part path part
So in this example just '/downloads/' would only match if it
were immediately after www.some.com. Something like
'/.*/downloads/' would match if there was always something
between the domain part and the word 'downloads' in the path
part. Then '/(.*/)?downloads/' takes care of both
situations. The '?' makes the () part of it conditional. You
should treat the domain and path as separate concepts when
matching (yes, this is somewhat confusing).
Logged In: NO
The popup only occurs on unload (i.e. when closing the window or going to
another webpage). I believe both NS and Mozilla have the ability to stop (all)
popups. Not that it should make any difference, but I'm using Opera
6.
I should mention that even though I forgot to paste the line in my
reply message, the following:
s/(<body
.*)onunload(.*>)/$1never$2/iU
IS in the default.filter file to kill these
popups. (I haven't removed it.)
--
Thanks for the matching help! I
didn't realize that the path matching had to start from root. I thought the
pattern could exist anywhere in the path.
Logged In: YES
user_id=322640
But that page uses:
function checkforpopup() {
if(staying=='false'){
open('yfs2.html','newwindow','width=350,height=455');
}
}
At least AFAICT with limited js knowledge. I don't see a
'onunload' on that page.
That being said, I sitll don't get a pop-up following links
at the bottom of the page. Probably is not privoxy though.
As to Mozilla's pop-up blocking, I've tried it, and it
caused me grief, so it is off. It is all or none, and breaks
some sites without every giving a hint as to why. Good idea,
but needs some flexibility and some easy way to turn off per
site.
OK, I take that first part back. I didn't dig deep enough.
Further down I see:
<body never="checkforpopup();" vlink="#ff0033"
link="#ff0033"><form
action="http://www.neodata.com/ITPS2.cgi" method=post
name="theform">
See the 'never'? So back to why filtering isn't working for
you.
I don't think 2.9.14 supported multiple actionsfiles (like
user.action). That is just in cvs devel version AFAIK. So
what is your actionsfile definition in config.txt? Please
try just a stock config.txt, and see what happens. Remember
to flush caches.
Logged In: NO
Well, that was it, I was trying to use two ".action" files. There is mention of
setting up multiple action files in the texts somewhere, but it doesn't point
out that it isn't functioning in the current "shipping" version.
My
user.action was working in that anything I added to it was blocked, but I
didn't have any mention of filtering (which must be turned off by default).
Thanks, and sorry for the trouble
Logged In: YES
user_id=322640
Hey, no problem.
Actually, the confusion is part the developers fault.
We started doing odd/even versions for development version
(cvs), and public releases. Since 2.9.14, there have not
been many big changes, but one is the configuration issue,
you ran into. The other thing is we have always published
docs on the website that were more or less in sync with the
current release. There was also some major work on the docs
to improve them overall during this time span. Publishing
these was a mistake, since it is leading to confusion, and
2.9.15 (cvs version), is not available publicly. And this
where those doc versions come from.
That being said, part of the rationale for having those docs
on the website is to 'show off' the latest features, and we
thought most people would read the docs that should be
installed locally, if they were already using privoxy.
Note to team: we need to address this.