+ [70]http://www.perldoc.com/perl5.6/pod/perlre.html
+ _________________________________________________________________
+
+8.2. Privoxy's Internal Pages
+
+ Since Privoxy proxies each requested web page, it is easy for Privoxy
+ to trap certain URLs. In this way, we can talk directly to Privoxy,
+ and see how it is configured, see how our rules are being applied,
+ change these rules and other configuration options, and even turn
+ Privoxy's filtering off, all with a web browser.
+
+ The URLs listed below are the special ones that allow direct access to
+ Privoxy. Of course, Privoxy must be running to access these. If not,
+ you will get a friendly error message. Internet access is not
+ necessary either.
+
+ * Privoxy main page:
+
+ [71]http://ijbswa.sourceforge.net/config/
+ Alternately, this may be reached at [72]http://i.j.b/, but this
+ variation may not work as reliably as the above in some
+ configurations.
+ * Show information about the current configuration:
+
+ [73]http://ijbswa.sourceforge.net/config/show-status
+ * Show the source code version numbers:
+
+ [74]http://ijbswa.sourceforge.net/config/show-version
+ * Show the client's request headers:
+
+ [75]http://ijbswa.sourceforge.net/config/show-request
+ * Show which actions apply to a URL and why:
+
+ [76]http://ijbswa.sourceforge.net/config/show-url-info
+ * Toggle Privoxy on or off:
+
+ [77]http://ijbswa.sourceforge.net/config/toggle
+ Short cuts. Turn off, then on:
+
+ [78]http://ijbswa.sourceforge.net/config/toggle?set=disable
+
+ [79]http://ijbswa.sourceforge.net/config/toggle?set=enable
+ * Edit the actions list file:
+
+ [80]http://ijbswa.sourceforge.net/config/edit-actions
+
+ These may be bookmarked for quick reference.
+ _________________________________________________________________
+
+8.3. Anatomy of an Action
+
+ The way Privoxy applies "actions" to any given URL can be complex, and
+ not always so easy to understand what is happening. And sometimes we
+ need to be able to see just what Privoxy is doing. Especially, if
+ something Privoxy is doing is causing us a problem inadvertantly. It
+ can be a little daunting to look at the actions files themselves,
+ since they tend to be filled with "regular expressions" whose
+ consequences are not always so obvious. Privoxy provides the
+ [81]http://ijbswa.sourceforge.net/config/show-url-info page that can
+ show us very specifically how actions are being applied to any given
+ URL. This is a big help for troubleshooting.
+
+ First, enter one URL (or partial URL) at the prompt, and then Privoxy
+ will tell us how current configuration will handle it. This will not
+ help with filtering effects from the default.filter! 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 you will only get info
+ for the actual URL that is pasted into the prompt area -- not any
+ sub-URLs. If you want to know about embedded URLs like ads, you will
+ have to dig those out of the HTML source. Use your browser's "View
+ Page Source" option for this.
+
+ Let's look at an example, [82]google.com, one section at a time:
+
+ System default actions:
+
+ { -add-header -block -deanimate-gifs -downgrade -fast-redirects -filter
+ -hide-forwarded -hide-from -hide-referer -hide-user-agent -image
+ -image-blocker -limit-connect -no-compression -no-cookies-keep
+ -no-cookies-read -no-cookies-set -no-popups -vanilla-wafer -wafer }
+
+
+ This is the top section, and only tells us of the compiled in
+ defaults. This is basically what Privoxy would do if there were not
+ any "actions" defined, i.e. it does nothing. Every action is disabled.
+ This is not particularly informative for our purposes here. OK, next
+ section:
+
+ Matches for http://google.com:
+
+ { -add-header -block +deanimate-gifs -downgrade +fast-redirects
+ +filter{html-annoyances} +filter{js-annoyances} +filter{no-popups}
+ +filter{webbugs} +filter{nimda} +filter{banners-by-size} +filter{hal}
+ +filter{fun} +hide-forwarded +hide-from{block} +hide-referer{forge}
+ -hide-user-agent -image +image-blocker{blank} +no-compression
+ +no-cookies-keep -no-cookies-read -no-cookies-set +no-popups
+ -vanilla-wafer -wafer }
+ /
+
+ { -no-cookies-keep -no-cookies-read -no-cookies-set }
+ .google.com
+
+ { -fast-redirects }
+ .google.com
+
+
+ This is much more informative, and tells us how we have defined our
+ "actions", and which ones match for our example, "google.com". The
+ first grouping shows our default settings, which would apply to all
+ URLs. If you look at your "actions" file, this would be the section
+ just below the "aliases" section near the top. This applies to all
+ URLs as signified by the single forward slash -- "/".
+
+ These are the default actions we have enabled. But we can define
+ additional actions that would be exceptions to these general rules,
+ and then list specific URLs that these exceptions would apply to. Last
+ match wins. Just below this then are two explict matches for
+ ".google.com". The first is negating our various cookie blocking
+ actions (i.e. we will allow cookies here). The second is allowing
+ "fast-redirects". Note that there is a leading dot here --
+ ".google.com". This will match any hosts and sub-domains, in the
+ google.com domain also, such as "www.google.com". So, apparently, we
+ have these actions defined somewhere in the lower part of our actions
+ file, and "google.com" is referenced in these sections.
+
+ And now we pull it altogether in the bottom section and summarize how
+ Privoxy is appying all its "actions" to "google.com":
+
+ Final results:
+
+ -add-header -block -deanimate-gifs -downgrade -fast-redirects
+ +filter{html-annoyances} +filter{js-annoyances} +filter{no-popups}
+ +filter{webbugs} +filter{nimda} +filter{banners-by-size} +filter{hal}
+ +filter{fun} +hide-forwarded +hide-from{block} +hide-referer{forge}
+ -hide-user-agent -image +image-blocker{blank} -limit-connect +no-compression
+ -no-cookies-keep -no-cookies-read -no-cookies-set +no-popups -vanilla-wafer
+ -wafer
+
+
+ Now another example, "ad.doubleclick.net":
+
+ { +block +image }
+ .ad.doubleclick.net
+
+ { +block +image }
+ ad*.
+
+ { +block +image }
+ .doubleclick.net
+
+
+ We'll just show the interesting part here, the explicit matches. It is
+ matched three different times. Each as an "+block +image", which is
+ the expanded form of one of our aliases that had been defined as:
+ "+imageblock". ("Aliases" are defined in the first section of the
+ actions file and typically used to combine more than one action.)
+
+ Any one of these would have done the trick and blocked this as an
+ unwanted image. This is unnecessarily redundant since the last case
+ effectively would also cover the first. No point in taking chances
+ with these guys though ;-) Note that if you want an ad or obnoxious
+ URL to be invisible, it should be defined as "ad.doubleclick.net" is
+ done here -- as both a "+block" and an "+image". The custom alias
+ "+imageblock" does this for us.
+
+ One last example. Let's try "http://www.rhapsodyk.net/adsl/HOWTO/".
+ This one is giving us problems. We are getting a blank page. Hmmm...
+
+ Matches for http://www.rhapsodyk.net/adsl/HOWTO/:
+
+ { -add-header -block +deanimate-gifs -downgrade +fast-redirects
+ +filter{html-annoyances} +filter{js-annoyances} +filter{no-popups}
+ +filter{webbugs} +filter{nimda} +filter{banners-by-size} +filter{hal}
+ +filter{fun} +hide-forwarded +hide-from{block} +hide-referer{forge}
+ -hide-user-agent -image +image-blocker{blank} +no-compression
+ +no-cookies-keep -no-cookies-read -no-cookies-set +no-popups
+ -vanilla-wafer -wafer }
+ /
+
+ { +block +image }
+ /ads
+
+
+ Ooops, the "/adsl/" 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 explictly does not block (-block) pages with
+ "adsl". There are various ways to handle such exceptions. Example:
+
+ { -block }
+ /adsl
+
+
+ Now the page displays ;-)