X-Git-Url: http://www.privoxy.org/gitweb/?p=privoxy.git;a=blobdiff_plain;f=doc%2Fwebserver%2Fuser-manual%2Fappendix.html;h=c5508209139c751eff31ccac7b21909c87a18860;hp=f1cb35b9a4183aa82d217acac7e11acd45abeb04;hb=65690f437fa5f89034b8e788f10eba449a5312e5;hpb=37e01aa0ee434c20c270b669587a4419279a9c7e diff --git a/doc/webserver/user-manual/appendix.html b/doc/webserver/user-manual/appendix.html index f1cb35b9..c5508209 100644 --- a/doc/webserver/user-manual/appendix.html +++ b/doc/webserver/user-manual/appendix.html @@ -3,25 +3,21 @@ Appendix - - + + - + - +
-

14.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.

+

14.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.

-

14.3. Chain of - Events

-

Let's take a quick look at how some of Privoxy's core features are triggered, and the - ensuing sequence of events when a web page is requested by your - browser:

+

14.3. Chain of Events

+

Let's take a quick look at how some of Privoxy's core features are triggered, + and the ensuing sequence of events when a web page is requested by your browser:

-

NOTE: This is somewhat of a simplistic overview of what happens with - each URL request. For the sake of brevity and simplicity, we have - focused on Privoxy's core features - only.

+

NOTE: This is somewhat of a simplistic overview of what happens with each URL request. For the sake of brevity + and simplicity, we have focused on Privoxy's core features only.

-

14.4. - Troubleshooting: 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 (be sure to flush caches afterward!). - Looking at the logs is a good idea too. (Note that both the toggle - feature and logging are enabled via 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.

-

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 +

14.4. Troubleshooting: 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 (be sure to flush caches afterward!). Looking at + the logs is a good idea too. (Note that both the toggle feature and logging are enabled via 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.

+

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 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 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 in a sample - configuration (your real configuration may vary):

+

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 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 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 in a sample configuration (your real configuration may vary):

 Matches for http://www.google.com:
 
- In file: default.action [ View ] [ Edit ]
+ In file: default.action [ View ] [ Edit ]
 
  {+change-x-forwarded-for{block}
  +deanimate-gifs {last}
@@ -536,68 +394,48 @@
  { -fast-redirects }
  .google.com
 
-In file: user.action [ View ] [ Edit ]
+In file: user.action [ View ] [ Edit ]
 (no matches in this file)
-

This is telling us how we have defined our "actions", - and which ones match for our test case, "google.com". Displayed is all the actions that are - available to us. Remember, the + sign denotes - "on". - denotes - "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 "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 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 - "+session-cookies-only" (i.e. not persistent). So we - will allow persistent cookies for google, at least that is how it is in - this example. 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" 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 "google.com" is referenced somewhere in - these latter sections.

-

Then, for our user.action 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 Privoxy is applying all - its "actions" to This is telling us how we have defined our "actions", and which ones match for our test case, "google.com". + Displayed is all the actions that are available to us. Remember, the + sign denotes + "on". - denotes "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 "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 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 "+session-cookies-only" (i.e. not persistent). So we will allow persistent cookies for google, + at least that is how it is in this example. 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" 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 "google.com" is + referenced somewhere in these latter sections.

+

Then, for our user.action 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 Privoxy is applying all its "actions" to "google.com":

-
- Final results:
+            
 Final results:
 
  -add-header
  -block
@@ -654,22 +492,18 @@ In file: user.action [ View ] 
+ +set-image-blocker {pattern}
-

Notice the only difference here to the previous listing, is to - "fast-redirects" and "session-cookies-only", which are activated specifically - for this site in our configuration, and thus show in the "Final Results".

-

Now another example, "ad.doubleclick.net":

+

Notice the only difference here to the previous listing, is to "fast-redirects" and + "session-cookies-only", which are activated specifically for this site in our + configuration, and thus show in the "Final Results".

+

Now another example, "ad.doubleclick.net":

-
- { +block{Domains starts with "ad"} }
+            
 { +block{Domains starts with "ad"} }
   ad*.
 
  { +block{Domain contains "ad"} }
@@ -680,39 +514,27 @@ In file: user.action [ View ] 
         
-

We'll just show the interesting part here - the explicit matches. It - is matched three different times. Two "+block{}" sections, and a "+block{} - +handle-as-image", which is the expanded form of one of our - aliases that had been defined as: "+block-as-image". ("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 "+block-as-image" just - simplifies the process and make it more readable.

-

One last example. Let's try "http://www.example.net/adsl/HOWTO/". This one is giving - us problems. We are getting a blank page. Hmmm ...

+

We'll just show the interesting part here - the explicit matches. It is matched three different times. Two + "+block{}" sections, and a "+block{} +handle-as-image", + which is the expanded form of one of our aliases that had been defined as: "+block-as-image". ("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 + "+block-as-image" just simplifies the process and make it + more readable.

+

One last example. Let's try "http://www.example.net/adsl/HOWTO/". This one is + giving us problems. We are getting a blank page. Hmmm ...

-
+            
 Matches for http://www.example.net/adsl/HOWTO/:
 
- Matches for http://www.example.net/adsl/HOWTO/:
-
- In file: default.action [ View ] [ Edit ]
+ In file: default.action [ View ] [ Edit ]
 
  {-add-header
   -block
@@ -775,61 +597,45 @@ In file: user.action [ View ] 
         
-

Ooops, the "/adsl/" is matching - "/ads" 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 un blocks ( "{-block}") - paths with "adsl" in them (remember, last - match in the configuration wins). There are various ways to handle such - exceptions. Example:

+

Ooops, the "/adsl/" is matching "/ads" 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 un blocks ( "{-block}") paths with "adsl" + in them (remember, last match in the configuration wins). There are various ways to handle such exceptions. + Example:

-
- { -block }
+            
 { -block }
   /adsl
-

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 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+Reload.

-

But now what about a situation where we get no explicit matches like - we did with:

+

But now what about a situation where we get no explicit matches like we did with:

-
-
- { +block{Path starts with "ads".} +handle-as-image }
+            
 { +block{Path starts with "ads".} +handle-as-image }
  /ads
-

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 of 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":

+

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 of 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":

-
- { shop }
+            
 { shop }
  .quietpc.com
  .worldpay.com   # for quietpc.com
  .jungle.com
@@ -838,16 +644,13 @@ In file: user.action [ View ] 
         
-

"{ shop }" is an - "alias" that expands to "{ -filter -session-cookies-only - }". Or you could do your own exception to negate - filtering:

+

"{ shop }" is an "alias" that + expands to "{ -filter -session-cookies-only }". Or you could + do your own exception to negate filtering:

-
- { -filter }
+            
 { -filter }
  # Disable ALL filter actions for sites in this section
  .forbes.com
  developer.ibm.com
@@ -855,51 +658,39 @@ In file: user.action [ View ] 
         
-

This would turn off all filtering for these sites. This is best put - in user.action, for local site exceptions. - Note that when a simple domain pattern is used by itself (without the - subsequent path portion), all sub-pages within that domain are included - automatically in the scope of the action.

-

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).

-

"{ 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.

+

This would turn off all filtering for these sites. This is best put in user.action, + for local site exceptions. Note that when a simple domain pattern is used by itself (without the subsequent path + portion), all sub-pages within that domain are included automatically in the scope of the action.

+

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).

+

"{ 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 }
+            
 { 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. ".com"). This will effectively match any TLD with - google in it, such as Remember to flush caches! Note that the mail.google reference lacks the TLD portion (e.g. ".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.

+

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.