Appendix

14.4. Anatomy of an Action14.4. Troubleshooting: Anatomy of an Action

The way the Bookmarklets section on a quick and easy way to do this (be sure to flush caches afterward!). Looking at the - logs is a good idea too.

config file settings, and may need to be + turned "on".)

Another easy troubleshooting step to try is if you have done any + customization of your installation, revert back to the installed + defaults and see if that helps. There are times the developers get complaints + about one thing or another, and the problem is more related to a customized + configuration issue.

"+filter" action) from - the default.filter file since this is handled very + one of the filter files since this is handled very differently and not so easy to trap! It also will not tell you about any other URLs that may be embedded within the URL you are testing. For instance, images such as ads are expressed as URLs within the raw page source of HTML pages. So @@ -1406,7 +1429,8 @@ HREF="http://google.com" TARGET="_top" >google.com, - and look at it one section at a time:

Matches for http://google.com: +> Matches for http://www.google.com: In file: default.action [ Edit ] -{-add-header - -block - -crunch-outgoing-cookies - -crunch-incoming-cookies - +deanimate-gifs{last} - -downgrade-http-version - +fast-redirects - -filter{popups} - -filter{fun} - -filter{shockwave-flash} - -filter{crude-parental} - +filter{html-annoyances} - +filter{js-annoyances} - +filter{content-cookies} - +filter{webbugs} - +filter{refresh-tags} - +filter{nimda} - +filter{banners-by-size} - +hide-forwarded-for-headers - +hide-from-header{block} - +hide-referer{forge} - -hide-user-agent - -handle-as-image - -kill-popups - -limit-connect - +prevent-compression - -send-vanilla-wafer - -send-wafer - +session-cookies-only - +set-image-blocker{pattern} } + {+change-x-forwarded-for{block} + +deanimate-gifs {last} + +fast-redirects {check-decoded-url} + +filter {refresh-tags} + +filter {img-reorder} + +filter {banners-by-size} + +filter {webbugs} + +filter {jumping-windows} + +filter {ie-exploits} + +hide-from-header {block} + +hide-referrer {forge} + +session-cookies-only + +set-image-blocker {pattern} / - + { -session-cookies-only } .google.com @@ -1477,7 +1484,7 @@ CLASS="GUIBUTTON" >

This tells us how we have defined our +> This is telling us how we have defined our "actions", and - which ones match for our example, "google.com". The first listing - is any matches for the standard.action file. No hits at - all here on . + Displayed is all the actions that are available to us. Remember, + the + sign denotes "standard". Then next is "on". - + denotes "default", or - our "off". So some are "on" here, but many + are "off". Each example we try may provide a slightly different + end result, depending on our configuration directives.

The first listing + is for our default.action file. The large, multi-line listing, - is how the actions are set to match for all URLs, i.e. our default settings. - If you look at your file. The large, multi-line + listing, is how the actions are set to match for all URLs, i.e. our default + settings. If you look at your "actions" file, this would be the section - just below the file, this would be the + section just below the "aliases" section near the top. This will apply to - all URLs as signified by the single forward slash at the end of the listing - -- section near the top. This + will apply to all URLs as signified by the single forward slash at the end + of the listing -- "/"" / ".

But we can define additional actions that would be exceptions to these general - rules, and then list specific URLs (or patterns) that these exceptions would - apply to. Last match wins. Just below this then are two explicit matches for - But we have defined additional actions that would be exceptions to these general + rules, and then we list specific URLs (or patterns) that these exceptions + would apply to. Last match wins. Just below this then are two explicit + matches for ".google.com". The first is negating our previous cookie setting, - which was for . The first is negating our previous + cookie setting, which was for "+session-cookies-only" - (i.e. not persistent). So we will allow persistent cookies for google. The - second turns off any - any "www.google.com". So, apparently, we have these two actions - defined somewhere in the lower part of our or "mail.google.com". But it would not + match "www.google.de"! So, apparently, we have these two actions + defined as exceptions to the general rules at the top somewhere in the lower + part of our default.action - file, and file, and + "google.com" is referenced somewhere in these latter - sections.

is referenced somewhere in these latter sections. Then, for our user.action file, we again have no hits. file, we again have no hits. + So there is nothing google-specific that we might have added to our own, local + configuration. If there was, those actions would over-rule any actions from + previously processed files, such as default.action. + user.action typically has the last word. This is the + best place to put hard and fast exceptions, And finally we pull it all together in the bottom section and summarize how Final results: - -add-header - -block - -crunch-outgoing-cookies - -crunch-incoming-cookies - +deanimate-gifs{last} - -downgrade-http-version - -fast-redirects - -filter{popups} - -filter{fun} - -filter{shockwave-flash} - -filter{crude-parental} - +filter{html-annoyances} - +filter{js-annoyances} - +filter{content-cookies} - +filter{webbugs} - +filter{refresh-tags} - +filter{nimda} - +filter{banners-by-size} - +hide-forwarded-for-headers - +hide-from-header{block} - +hide-referer{forge} - -hide-user-agent - -handle-as-image - -kill-popups - -limit-connect - +prevent-compression - -send-vanilla-wafer - -send-wafer - -session-cookies-only - +set-image-blocker{pattern} and "session-cookies-only", + which are activated specifically for this site in our configuration, + and thus show in the "Final Results". Now another example, { +block +handle-as-image } - .ad.doubleclick.net - - { +block +handle-as-image } +> { +block{Domains starts with "ad"} } ad*. - { +block +handle-as-image } - .doubleclick.net We'll just show the interesting part here, the explicit matches. It is - matched three different times. Each as an We'll just show the interesting part here - the explicit matches. It is + matched three different times. Two "+block +handle-as-image""+block{}" sections, + and a "+block{} +handle-as-image", which is the expanded form of one of our aliases that had been defined as: "+imageblock""+block-as-image". ("+block""+block{}" . The custom alias "+imageblock" just simplifies the process and make - it more readable. "+block-as-image" just + simplifies the process and make it more readable. One last example. Let's try "http://www.rhapsodyk.net/adsl/HOWTO/""http://www.example.net/adsl/HOWTO/". This one is giving us problems. We are getting a blank page. Hmmm ... Matches for http://www.rhapsodyk.net/adsl/HOWTO/: +> Matches for http://www.example.net/adsl/HOWTO/: In file: default.action {-add-header - -block - -crunch-incoming-cookies - -crunch-outgoing-cookies + -block + +change-x-forwarded-for{block} + -client-header-filter{hide-tor-exit-notation} + -content-type-overwrite + -crunch-client-header + -crunch-if-none-match + -crunch-incoming-cookies + -crunch-outgoing-cookies + -crunch-server-header +deanimate-gifs -downgrade-http-version - +fast-redirects - +filter{html-annoyances} - +filter{js-annoyances} - +filter{kill-popups} - +filter{webbugs} - +filter{nimda} - +filter{banners-by-size} - +filter{hal} - +filter{fun} - +hide-forwarded-for-headers + +fast-redirects {check-decoded-url} + -filter {js-events} + -filter {content-cookies} + -filter {all-popups} + -filter {banners-by-link} + -filter {tiny-textforms} + -filter {frameset-borders} + -filter {demoronizer} + -filter {shockwave-flash} + -filter {quicktime-kioskmode} + -filter {fun} + -filter {crude-parental} + -filter {site-specifics} + -filter {js-annoyances} + -filter {html-annoyances} + +filter {refresh-tags} + -filter {unsolicited-popups} + +filter {img-reorder} + +filter {banners-by-size} + +filter {webbugs} + +filter {jumping-windows} + +filter {ie-exploits} + -filter {google} + -filter {yahoo} + -filter {msn} + -filter {blogspot} + -filter {no-ping} + -force-text-mode + -handle-as-empty-document + -handle-as-image + -hide-accept-language + -hide-content-disposition +hide-from-header{block} +hide-referer{forge} -hide-user-agent - -handle-as-image - +kill-popups + -overwrite-last-modified +prevent-compression - -send-vanilla-wafer - -send-wafer + -redirect + -server-header-filter{xml-to-html} + -server-header-filter{html-to-xml} +session-cookies-only +set-image-blocker{blank} } / - { +block +handle-as-image } + { +block{Path contains "ads".} +handle-as-image } /ads is matching "/ads"! But - we did not want this at all! Now we see why we get the blank page. We could - now add a new action below this that explicitly does in our + configuration! But we did not want this at all! Now we see why we get the + blank page. It is actually triggering two different actions here, and + the effects are aggregated so that the URL is blocked, and Privoxy is told + to treat the block as if it were an image. But this is, of course, all wrong. + We could now add a new action below this (or better in our own + user.action file) that explicitly + notun - block ( blocks ( + "{-block}") paths with ) paths with + "adsl". There are - various ways to handle such exceptions. Example: in them (remember, last match in the configuration + wins). There are various ways to handle such exceptions. Example: Now the page displays ;-) Be sure to flush your browser's caches when - making such changes. Or, try using Now the page displays ;-) + Remember to flush your browser's caches when making these kinds of changes to + your configuration to insure that you get a freshly delivered page! Or, try + using Shift+ReloadShift+Reload. But now what about a situation where we get no explicit matches like @@ -1835,25 +1957,36 @@ WIDTH="100%" > { +block +handle-as-image } +> { +block{Path starts with "ads".} +handle-as-image } /ads That actually was very telling and pointed us quickly to where the problem +> That actually was very helpful and pointed us quickly to where the problem was. If you don't get this kind of match, then it means one of the default - rules in the first section is causing the problem. This would require some - guesswork, and maybe a little trial and error to isolate the offending rule. - One likely cause would be one of the default.action is causing + the problem. This would require some guesswork, and maybe a little trial and + error to isolate the offending rule. One likely cause would be one of the + "{+filter}" actions. These - tend to be harder to troubleshoot. Try adding the URL for the site to one of - aliases that turn off "+filter" actions. + These tend to be harder to troubleshoot. + Try adding the URL for the site to one of aliases that turn off + "+filter": {shop} +> { shop } .quietpc.com .worldpay.com # for quietpc.com .jungle.com @@ -1877,14 +2010,20 @@ CLASS="SCREEN" > "{shop}""{ shop }" is an "alias" that expands to "{ -filter -session-cookies-only }""{ -filter -session-cookies-only }". Or you could do your own exception to negate filtering: {-filter} - .forbes.com { -filter } + # Disable ALL filter actions for sites in this section + .forbes.com + developer.ibm.com + localhost This would turn off all filtering for that site. This would probably be most - appropriately put in This would turn off all filtering for these sites. This is best + put in user.action, for local site - exceptions. Images that are inexplicably being blocked, may well be hitting the - "+filter{banners-by-size}" rule, which assumes - that images of certain sizes are ad banners (works well most of the time - since these tend to be standardized). + rule, which assumes + that images of certain sizes are ad banners (works well + most of the time since these tend to be standardized). "{ fragile }" is an alias that disables most + actions that are the most likely to cause trouble. This can be used as a + last resort for problem sites. { fragile } + # Handle with care: easy to break + mail.google. + mybank.example.com Remember to flush caches! Note that the + mail.google reference lacks the TLD portion (e.g. + "{fragile}" is an alias that disables most actions. This can be - used as a last resort for problem sites. Remember to flush caches! If this - still does not work, you will have to go through the remaining actions one by - one to find which one(s) is causing the problem.".com"). This will effectively match any TLD with + google in it, such as mail.google.de., + just as an example. + If this still does not work, you will have to go through the remaining + actions one by one to find which one(s) is causing the problem.

14.2. Privoxy's Internal Pages14.2. Privoxy's Internal Pages