+-------------------------------------------------------------------------------
+
+15.2. Privoxy's Internal Pages
+
+Since Privoxy proxies each requested web page, it is easy for Privoxy to trap
+certain special 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:
+
+ http://config.privoxy.org/
+
+ Alternately, this may be reached at http://p.p/, but this variation may not
+ work as reliably as the above in some configurations.
+
+ * Show information about the current configuration, including viewing and
+ editing of actions files:
+
+ http://config.privoxy.org/show-status
+
+ * Show the source code version numbers:
+
+ http://config.privoxy.org/show-version
+
+ * Show the browser's request headers:
+
+ http://config.privoxy.org/show-request
+
+ * Show which actions apply to a URL and why:
+
+ http://config.privoxy.org/show-url-info
+
+ * Toggle Privoxy on or off. In this case, "Privoxy" continues to run, but
+ only as a pass-through proxy, with no actions taking place:
+
+ http://config.privoxy.org/toggle
+
+ Short cuts. Turn off, then on:
+
+ http://config.privoxy.org/toggle?set=disable
+
+ http://config.privoxy.org/toggle?set=enable
+
+These may be bookmarked for quick reference. See next.
+
+-------------------------------------------------------------------------------
+
+15.2.1. Bookmarklets
+
+Below are some "bookmarklets" to allow you to easily access a "mini" version of
+some of Privoxy's special pages. They are designed for MS Internet Explorer,
+but should work equally well in Netscape, Mozilla, and other browsers which
+support JavaScript. They are designed to run directly from your bookmarks - not
+by clicking the links below (although that should work for testing).
+
+To save them, right-click the link and choose "Add to Favorites" (IE) or "Add
+Bookmark" (Netscape). You will get a warning that the bookmark "may not be
+safe" - just click OK. Then you can run the Bookmarklet directly from your
+favorites/bookmarks. For even faster access, you can put them on the "Links"
+bar (IE) or the "Personal Toolbar" (Netscape), and run them with a single
+click.
+
+ * Privoxy - Enable
+
+ * Privoxy - Disable
+
+ * Privoxy - Toggle Privoxy (Toggles between enabled and disabled)
+
+ * Privoxy- View Status
+
+ * Privoxy - Submit Filter Feedback
+
+Credit: The site which gave me the general idea for these bookmarklets is
+www.bookmarklets.com. They have more information about bookmarklets.
+
+-------------------------------------------------------------------------------
+
+15.3. Chain of Events
+
+Let's take a quick look at the basic sequence of events when a web page is
+requested by your browser and Privoxy is on duty:
+
+ * First, your web browser requests a web page. The browser knows to send the
+ request to Privoxy, which will in turn, relay the request to the remote web
+ server after passing the following tests:
+
+ * Privoxy traps any request for its own internal CGI pages (e.g http://p.p/)
+ and sends the CGI page back to the browser.
+
+ * Next, Privoxy checks to see if the URL matches any "+block" patterns. If
+ so, the URL is then blocked, and the remote web server will not be
+ contacted. "+handle-as-image" is then checked and if it does not match, an
+ HTML "BLOCKED" page is sent back. Otherwise, if it does match, an image is
+ returned. The type of image depends on the setting of "+set-image-blocker"
+ (blank, checkerboard pattern, or an HTTP redirect to an image elsewhere).
+
+ * Untrusted URLs are blocked. If URLs are being added to the trust file, then
+ that is done.
+
+ * If the URL pattern matches the "+fast-redirects" action, it is then
+ processed. Unwanted parts of the requested URL are stripped.
+
+ * Now the rest of the client browser's request headers are processed. If any
+ of these match any of the relevant actions (e.g. "+hide-user-agent", etc.),
+ headers are suppressed or forged as determined by these actions and their
+ parameters.
+
+ * Now the web server starts sending its response back (i.e. typically a web
+ page and related data).
+
+ * First, the server headers are read and processed to determine, among other
+ things, the MIME type (document type) and encoding. The headers are then
+ filtered as deterimed by the "+prevent-setting-cookies",
+ "+session-cookies-only", and "+downgrade-http-version" actions.
+
+ * If the "+kill-popups" action applies, and it is an HTML or JavaScript
+ document, the popup-code in the response is filtered on-the-fly as it is
+ received.
+
+ * If a "+filter" or "+deanimate-gifs" action applies (and the document type
+ fits the action), the rest of the page is read into memory (up to a
+ configurable limit). Then the filter rules (from default.filter) are
+ processed against the buffered content. Filters are applied in the order
+ they are specified in the default.filter file. Animated GIFs, if present,
+ are reduced to either the first or last frame, depending on the action
+ setting.The entire page, which is now filtered, is then sent by Privoxy
+ back to your browser.
+
+ If neither "+filter" or "+deanimate-gifs" matches, then Privoxy passes the
+ raw data through to the client browser as it becomes available.
+
+ * As the browser receives the now (probably filtered) page content, it reads
+ and then requests any URLs that may be embedded within the page source,
+ e.g. ad images, stylesheets, JavaScript, other HTML documents (e.g.
+ frames), sounds, etc. For each of these objects, the browser issues a new
+ request. And each such request is in turn processed as above. Note that a
+ complex web page may have many such embedded URLs.
+
+-------------------------------------------------------------------------------
+
+15.4. Anatomy of an Action
+
+The way Privoxy applies "actions" and "filters" 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 inadvertently. It can be a little
+daunting to look at the actions and filters files themselves, since they tend
+to be filled with "regular expressions" whose consequences are not always so
+obvious.
+
+One quick test to see if Privoxy is causing a problem or not, is to disable it
+temporarily. This should be the first troubleshooting step. See the
+Bookmarklets section on a quick and easy way to do this (be sure to flush
+caches afterward!).
+
+Privoxy also provides the http://config.privoxy.org/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 the current configuration will handle it. This will not help with
+filtering effects (i.e. the "+filter" action) from the default.filter file
+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 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. Or right click on the ad,
+and grab the URL.
+
+Let's try an example, google.com, and look at it one section at a time:
+
+ Matches for http://google.com:
+
+--- File standard ---
+(no matches in this file)
+
+--- File default ---
+
+{ -add-header -block +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 +set-image-blocker{pattern} -limit-connect
+ +prevent-compression +session-cookies-only -prevent-reading-cookies
+ -prevent-setting-cookies -kill-popups -send-vanilla-wafer -send-wafer }
+/
+
+ { -session-cookies-only }
+ .google.com
+
+ { -fast-redirects }
+ .google.com
+
+--- File user ---
+(no matches in this file)
+
+This tells 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 "standard". Then next is "default", or 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 "actions"
+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 -- "/".
+
+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
+".google.com". 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 "+fast-redirects" action, allowing
+this to take place unmolested. 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 two
+actions defined somewhere in the lower part of our default.action file, and
+"google.com" is referenced somewhere in these latter sections.
+
+Then, for our user.action file, we again have no hits.
+
+And finally we pull it all together in the bottom section and summarize how
+Privoxy is applying all its "actions" to "google.com":
+
+ Final results:
+ -add-header -block +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 +set-image-blocker{pattern} -limit-connect
+ +prevent-compression -session-cookies-only -prevent-reading-cookies
+ -prevent-setting-cookies -kill-popups -send-vanilla-wafer -send-wafer
+
+Notice the only difference here to the previous listing, is to "fast-redirects"
+and "session-cookies-only".
+
+Now another example, "ad.doubleclick.net":
+
+ { +block +handle-as-image }
+ .ad.doubleclick.net
+
+ { +block +handle-as-image }
+ 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 "+block +handle-as-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
+"+handle-as-image". The custom alias "+imageblock" just simplifies the process
+and make it more readable.
+
+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-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 +hide-from-header{block}
+ +hide-referer{forge} -hide-user-agent -handle-as-image +set-image-blocker{blank}
+ +prevent-compression +session-cookies-only -prevent-setting-cookies
+ -prevent-reading-cookies +kill-popups -send-vanilla-wafer -send-wafer }
+ /
+
+ { +block +handle-as-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
+explicitly does not block ("{-block}") paths with "adsl". There are various
+ways to handle such exceptions. Example:
+
+ { -block }
+ /adsl
+
+Now the page displays ;-) Be sure to flush your browser's caches when making
+such changes. Or, try using Shift+Reload.
+
+But now what about a situation where we get no explicit matches like we did
+with:
+
+ { +block +handle-as-image }
+ /ads
+
+That actually was very telling 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 "{+filter}" actions. Try adding the URL for the site
+to one of aliases that turn off "+filter":
+
+ {shop}
+ .quietpc.com
+ .worldpay.com # for quietpc.com
+ .jungle.com
+ .scan.co.uk
+ .forbes.com
+
+"{shop}" is an "alias" that expands to "{ -filter -session-cookies-only }". Or
+you could do your own exception to negate filtering:
+
+ {-filter}
+ .forbes.com
+
+This would probably be most appropriately put in user.action, for local site
+exceptions.
+
+"{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.