X-Git-Url: http://www.privoxy.org/gitweb/?a=blobdiff_plain;ds=sidebyside;f=doc%2Fwebserver%2Ffaq%2Ftrouble.html;h=310ae020565a44b265d16a366998f92414f26219;hb=4985684a0376e6a84c5f542c7324617259092575;hp=7eaed90bfda6098fdb0286c00df1a4b080e37200;hpb=7a99a61ab1a3ce0401821aedcd06eba19a698b2a;p=privoxy.git diff --git a/doc/webserver/faq/trouble.html b/doc/webserver/faq/trouble.html index 7eaed90b..310ae020 100644 --- a/doc/webserver/faq/trouble.html +++ b/doc/webserver/faq/trouble.html @@ -1,143 +1,92 @@ -
Privoxy Frequently Asked - Questions | +Privoxy Frequently Asked Questions | ||||
---|---|---|---|---|---|
Prev | - +Prev | - - | Next | +Next |
There are several possibilities:
-Privoxy is not running. - Solution: verify that Privoxy is - installed correctly, has not crashed, and is indeed running. Turn - on Privoxy's logging, and look at - the logs to see what they say.
+Privoxy is not running. Solution: verify that Privoxy is installed correctly, has not crashed, and is indeed running. Turn on + Privoxy's logging, and look at the logs to see what they say.
Or your browser is configured for a different port than what - Privoxy is using. Solution: verify - that Privoxy and your browser are - set to the same port (listen-address).
+Or your browser is configured for a different port than what Privoxy is + using. Solution: verify that Privoxy and your browser are set to the same + port (listen-address).
Or if using a forwarding rule, you have a configuration problem - or a problem with a host in the forwarding chain. Solution: - temporarily alter your configuration and take the forwarders out of - the equation.
+Or if using a forwarding rule, you have a configuration problem or a problem with a host in the forwarding + chain. Solution: temporarily alter your configuration and take the forwarders out of the equation.
Or you have a firewall that is interfering and blocking you. - Solution: try disabling or removing the firewall as a simple - test.
+Or you have a firewall that is interfering and blocking you. Solution: try disabling or removing the + firewall as a simple test.
More than likely this is a problem with your TCP/IP networking. - ZoneAlarm has been reported to cause this symptom -- even if not - running! The solution is to either fight the ZA configuration, or - uninstall ZoneAlarm, and then find something better behaved in its - place. Other personal firewall type products may cause similar type +
More than likely this is a problem with your TCP/IP networking. ZoneAlarm has been reported to cause this + symptom -- even if not running! The solution is to either fight the ZA configuration, or uninstall ZoneAlarm, and + then find something better behaved in its place. Other personal firewall type products may cause similar type problems if not configured correctly.
If the ad had been displayed before you added its URL, it will - probably be held in the browser's cache for some time, so it will be - displayed without the need for any request to the server, and - Privoxy will not be involved. Flush - the browser's caches, and then try again.
- -If this doesn't help, you probably have an error in the rule you - applied. Try pasting the full URL of the offending ad into http://config.privoxy.org/show-url-info and see if it really - matches your new rule. Blocking ads is like blocking spam: a lot of - tinkering is required to stay ahead of the game. And remember you need - to block the URL of the ad in question, which may be entirely different - from the site URL itself. Most ads are hosted on different servers than - the main site itself. If you right-click on the ad, you should be able - to get all the relevant information you need. Alternately, you can find - the correct URL by looking at Privoxy's logs (you may need to enable logging in - the main config file if its disabled).
- -Below is a slightly modified real-life log snippet that originates - with one requested URL: www.example.com (name - of site was changed for this example, the number of requests is real). - You can see in this the complexity of what goes into making up this one - "page". There are eight different domains - involved here, with thirty two separate URLs requested in all, making - up all manner of images, Shockwave Flash, JavaScript, CSS stylesheets, - scripts, and other related content. Some of this content is obviously - "good" or "bad", - but not all. Many of the more questionable looking requests, are going - to outside domains that seem to be identifying themselves with - suspicious looking names, making our job a little easier. Privoxy has "crunched" - (meaning caught and BLOCKED) quite a few items in this example, but - perhaps missed a few as well.
- +If the ad had been displayed before you added its URL, it will probably be held in the browser's cache for + some time, so it will be displayed without the need for any request to the server, and Privoxy will not be involved. Flush the browser's caches, and then try again.
+If this doesn't help, you probably have an error in the rule you applied. Try pasting the full URL of the + offending ad into http://config.privoxy.org/show-url-info and see if it really matches your new rule. Blocking ads is + like blocking spam: a lot of tinkering is required to stay ahead of the game. And remember you need to block the + URL of the ad in question, which may be entirely different from the site URL itself. Most ads are hosted on + different servers than the main site itself. If you right-click on the ad, you should be able to get all the + relevant information you need. Alternately, you can find the correct URL by looking at Privoxy's logs (you may need to enable logging in the main config file if its disabled).
+Below is a slightly modified real-life log snippet that originates with one requested URL: www.example.com (name of site was changed for this example, the number of requests is real). You + can see in this the complexity of what goes into making up this one "page". There are + eight different domains involved here, with thirty two separate URLs requested in all, making up all manner of + images, Shockwave Flash, JavaScript, CSS stylesheets, scripts, and other related content. Some of this content is + obviously "good" or "bad", but not all. Many of the more + questionable looking requests, are going to outside domains that seem to be identifying themselves with + suspicious looking names, making our job a little easier. Privoxy has + "crunched" (meaning caught and BLOCKED) quite a few items in this example, but perhaps + missed a few as well.
- -Request: www.example.com/ +Request: www.example.com/ Request: www.example.com/favicon.ico Request: img.example.com/main.css Request: img.example.com/sr.js @@ -147,8 +96,8 @@ Request: img.example.com/pb.png Request: www.google-analytics.com/urchin.js crunch! (Blocked) Request: www.advertising-department.com/ats/switch.ps.php?26856 crunch! (Blocked) Request: img.example.com/p.gif -Request: www.popuptraffic.com/assign.php?l=example&mode=behind crunch! (Blocked) -Request: www.popuptraffic.com/scripts/popup.php?hid=5c3cf&tmpl=PBa.tmpl crunch! (Blocked) +Request: www.popuptraffic.com/assign.php?l=example&mode=behind crunch! (Blocked) +Request: www.popuptraffic.com/scripts/popup.php?hid=5c3cf&tmpl=PBa.tmpl crunch! (Blocked) Request: www.popuptraffic.com/assign.php?l=example crunch! (Blocked) Request: www.lik-sang.com/Banners/best_sellers/best_sellers.css Request: www.adtrak.net/adx.js crunch! (Blocked) @@ -157,630 +106,409 @@ Request: img.example.com/example.jpg Request: img.example.com/mt.png Request: img.example.com/mm.png Request: img.example.com/mb.png -Request: www.popuptraffic.com/scripts/popup.php?hid=a71b91fa5&tmpl=Ua.tmp crunch! (Blocked) +Request: www.popuptraffic.com/scripts/popup.php?hid=a71b91fa5&tmpl=Ua.tmp crunch! (Blocked) Request: www.example.com/tracker.js Request: www.lik-sang.com/Banners/best_sellers/lsi_head.gif -Request: www.adtrak.net/adjs.php?n=020548130&what=zone:61 crunch! (Blocked) -Request: www.adtrak.net/adjs.php?n=463594413&what=zone:58&source=Ua crunch! (Blocked) +Request: www.adtrak.net/adjs.php?n=020548130&what=zone:61 crunch! (Blocked) +Request: www.adtrak.net/adjs.php?n=463594413&what=zone:58&source=Ua crunch! (Blocked) Request: www.lik-sang.com/Banners/best_sellers/bottomani.swf -Request: mmm.elitemediagroup.net/install.php?allowpop=no&popupmincook=0&allowsp2=1 crunch! (Blocked) -Request: www.example.com/tracker.js?screen=1400x1050&win=962x693 -Request: www.adtrak.net/adlog.php?bannerid=1309&clientid=439&zoneid=61 crunch! (Blocked) -Request: 66.70.21.80/scripts/click.php?hid=5c3cf599a9efd0320d26&si +Request: mmm.elitemediagroup.net/install.php?allowpop=no&popupmincook=0&allowsp2=1 crunch! (Blocked) +Request: www.example.com/tracker.js?screen=1400x1050&win=962x693 +Request: www.adtrak.net/adlog.php?bannerid=1309&clientid=439&zoneid=61 crunch! (Blocked) +Request: 66.70.21.80/scripts/click.php?hid=5c3cf599a9efd0320d26&si Request: 66.70.21.80/img/pixel.gif -Request: www.adtrak.net/adlog.php?bannerid=1309&clientid=439&zoneid=58&source=Ua&block=86400 crunch! (Blocked) -Request: 66.70.21.80/scripts/click.php?hid=a71b9f6504b0c5681fa5&si=Ua -+Request: www.adtrak.net/adlog.php?bannerid=1309&clientid=439&zoneid=58&source=Ua&block=86400 crunch! (Blocked) +Request: 66.70.21.80/scripts/click.php?hid=a71b9f6504b0c5681fa5&si=Ua |
Despite 12 out of 32 requests being blocked, the page looked, and - seemed to behave perfectly "normal" (minus - some ads, of course).
+Despite 12 out of 32 requests being blocked, the page looked, and seemed to behave perfectly "normal" (minus some ads, of course).
First verify that it is indeed a Privoxy problem, by toggling off Privoxy through http://config.privoxy.org/toggle (the toggle feature may - need to be enabled in the main config), and - then shift-reloading the problem page (i.e. holding down the shift key - while clicking reload. Alternatively, flush your browser's disk and - memory caches).
- -If the problem went away, we know we have a configuration related - problem. Now go to http://config.privoxy.org/show-url-info and paste the - full URL of the page in question into the prompt. See which actions are - being applied to the URL, and which matches in which actions files are - responsible for that. It might be helpful also to look at your logs for - this site too, to see what else might be happening (note: logging may - need to be enabled in the main config file). Many sites are complex and - require a number of related pages to help present their content. Look - at what else might be used by the page in question, and what of that - might be required. Now, armed with this information, go to - http://config.privoxy.org/show-status and select the +
First verify that it is indeed a Privoxy problem, by toggling off + Privoxy through http://config.privoxy.org/toggle (the toggle feature may need to be enabled in the main config), and then shift-reloading the problem page (i.e. holding down the shift key while + clicking reload. Alternatively, flush your browser's disk and memory caches).
+If the problem went away, we know we have a configuration related problem. Now go to http://config.privoxy.org/show-url-info and paste the + full URL of the page in question into the prompt. See which actions are being applied to the URL, and which + matches in which actions files are responsible for that. It might be helpful also to look at your logs for this + site too, to see what else might be happening (note: logging may need to be enabled in the main config file). + Many sites are complex and require a number of related pages to help present their content. Look at what else + might be used by the page in question, and what of that might be required. Now, armed with this information, go to http://config.privoxy.org/show-status and select the appropriate actions files for editing.
- -You can now either look for a section which disables the actions - that you suspect to cause the problem and add a pattern for your site - there, or make up a completely new section for your site. In any case, - the recommended way is to disable only the prime suspect, reload the - problem page, and only if the problem persists, disable more and more - actions until you have identified the culprit. You may or may not want - to turn the other actions on again. Remember to flush your browser's - caches in between any such changes!
- -Alternately, if you are comfortable with a text editor, you can - accomplish the same thing by editing the appropriate actions file. - Probably the easiest way to deal with such problems when editing by - hand is to add your site to a { fragile } - section in user.action, which is an alias - that turns off most "dangerous" actions, but - is also likely to turn off more actions then needed, and thus lower - your privacy and protection more than necessary,
- -Troubleshooting actions is discussed in more detail in the User Manual - appendix, Troubleshooting: the Anatomy of an Action. There is also - an actions tutorial with general configuration information and - examples.
- -As a last resort, you can always see if your browser has a setting - that will bypass the proxy setting for selective sites. Modern browsers - can do this.
+You can now either look for a section which disables the actions that you suspect to cause the problem and add + a pattern for your site there, or make up a completely new section for your site. In any case, the recommended + way is to disable only the prime suspect, reload the problem page, and only if the problem persists, disable more + and more actions until you have identified the culprit. You may or may not want to turn the other actions on + again. Remember to flush your browser's caches in between any such changes!
+Alternately, if you are comfortable with a text editor, you can accomplish the same thing by editing the + appropriate actions file. Probably the easiest way to deal with such problems when editing by hand is to add your + site to a { fragile } section in user.action, which is an + alias that turns off most "dangerous" actions, but is also likely to turn off more + actions then needed, and thus lower your privacy and protection more than necessary,
+Troubleshooting actions is discussed in more detail in the User Manual appendix, Troubleshooting: the Anatomy of an Action. There is also an actions tutorial with general configuration + information and examples.
+As a last resort, you can always see if your browser has a setting that will bypass the proxy setting for + selective sites. Modern browsers can do this.
This is a quirk that affects the installation of Privoxy, in conjunction with Internet Explorer and - Internet Connection Sharing on Windows 2000 and Windows XP. The - symptoms may appear to be corrupted or invalid DUN settings, or - passwords.
- -When setting up an NT based Windows system with Privoxy you may find that things do not seem to be - doing what you expect. When you set your system up you will probably - have set up Internet Connection Sharing (ICS) with Dial up Networking - (DUN) when logged in with administrator privileges. You will probably - have made this DUN connection available to other accounts that you may - have set-up on your system. E.g. Mum or Dad sets up the system and - makes accounts suitably configured for the kids.
- -When setting up Privoxy in this - environment you will have to alter the proxy set-up of Internet - Explorer (IE) for the specific DUN connection on which you wish to use - Privoxy. When you do this the ICS DUN - set-up becomes user specific. In this instance you will see no - difference if you change the DUN connection under the account used to - set-up the connection. However when you do this from another user you - will notice that the DUN connection changes to make available to "Me - only". You will also find that you have to store the password under - each different user!
- -The reason for this is that each user's set-up for IE is user - specific. Each set-up DUN connection and each LAN connection in IE - store the settings for each user individually. As such this enforces - individual configurations rather than common ones. Hence the first time - you use a DUN connection after re-booting your system it may not - perform as you expect, and prompt you for the password. Just set and - save the password again and all should be OK.
- +This is a quirk that affects the installation of Privoxy, in conjunction with + Internet Explorer and Internet Connection Sharing on Windows 2000 and Windows XP. The symptoms may appear to be + corrupted or invalid DUN settings, or passwords.
+When setting up an NT based Windows system with Privoxy you may find that + things do not seem to be doing what you expect. When you set your system up you will probably have set up + Internet Connection Sharing (ICS) with Dial up Networking (DUN) when logged in with administrator privileges. You + will probably have made this DUN connection available to other accounts that you may have set-up on your system. + E.g. Mum or Dad sets up the system and makes accounts suitably configured for the kids.
+When setting up Privoxy in this environment you will have to alter the proxy + set-up of Internet Explorer (IE) for the specific DUN connection on which you wish to use Privoxy. When you do this the ICS DUN set-up becomes user specific. In this instance you + will see no difference if you change the DUN connection under the account used to set-up the connection. However + when you do this from another user you will notice that the DUN connection changes to make available to "Me + only". You will also find that you have to store the password under each different user!
+The reason for this is that each user's set-up for IE is user specific. Each set-up DUN connection and each + LAN connection in IE store the settings for each user individually. As such this enforces individual + configurations rather than common ones. Hence the first time you use a DUN connection after re-booting your + system it may not perform as you expect, and prompt you for the password. Just set and save the password again + and all should be OK.
[Thanks to Ray Griffith for this submission.]
Privoxy cannot act as a proxy for - FTP traffic, so do not configure your browser to use Privoxy as an FTP proxy. The same is true for - any protocol other than HTTP - or HTTPS (SSL).
- -Most browsers understand FTP as well as HTTP. If you connect to a - site, with a URL like ftp://ftp.example.com, - your browser is making an FTP connection, and not a HTTP connection. So - while your browser may speak FTP, Privoxy does not, and cannot proxy such +
Privoxy cannot act as a proxy for FTP traffic, so do not configure your + browser to use Privoxy as an FTP proxy. The same is true for any protocol other than HTTP or HTTPS (SSL).
+Most browsers understand FTP as well as HTTP. If you connect to a site, with a URL like ftp://ftp.example.com, your browser is making an FTP connection, and not a HTTP connection. So + while your browser may speak FTP, Privoxy does not, and cannot proxy such traffic.
- -To complicate matters, some systems may have a generic "proxy" setting, which will enable various protocols, - including both - HTTP and FTP proxying! So it is possible to accidentally enable FTP - proxying in these cases. And of course, if this happens, Privoxy will indeed cause problems since it does - not know FTP. Newer version will give a sane error message if a FTP - connection is attempted. Just disable the FTP setting and all will be +
To complicate matters, some systems may have a generic "proxy" setting, which will + enable various protocols, including both HTTP and FTP + proxying! So it is possible to accidentally enable FTP proxying in these cases. And of course, if this happens, + Privoxy will indeed cause problems since it does not know FTP. Newer version + will give a sane error message if a FTP connection is attempted. Just disable the FTP setting and all will be well again.
- -Will Privoxy ever proxy FTP - traffic? Unlikely. There just is not much reason, and the work to make - this happen is more than it may seem.
+Will Privoxy ever proxy FTP traffic? Unlikely. There just is not much reason, + and the work to make this happen is more than it may seem.
Microsoft Internet Explorer (in versions like 5.1) respects - system-wide network settings. In order to change the HTTP proxy, open - System Preferences, and click on the Network icon. In the settings pane - that comes up, click on the Proxies tab. Ensure the "Web Proxy (HTTP)" - checkbox is checked and enter 127.0.0.1 in the - entry field. Enter 8118 in the Port field. The - next time you start IE, it should reflect these values.
+Microsoft Internet Explorer (in versions like 5.1) respects system-wide network settings. In order to change + the HTTP proxy, open System Preferences, and click on the Network icon. In the settings pane that comes up, click + on the Proxies tab. Ensure the "Web Proxy (HTTP)" checkbox is checked and enter 127.0.0.1 in the entry field. Enter 8118 in the Port field. The next time + you start IE, it should reflect these values.
Note: This ONLY applies to privoxy 3.0.6 and earlier.
- -Just dragging the Privoxy folder to - the trash is not enough to delete it. Privoxy supplies an uninstall.command file that takes care of these - details. Open the trash, drag the uninstall.command file out of the trash and - double-click on it. You will be prompted for confirmation and the - administration password.
- -The trash may still appear full after this command; emptying the - trash from the desktop should make it appear empty again.
+Just dragging the Privoxy folder to the trash is not enough to delete it. + Privoxy supplies an uninstall.command file that + takes care of these details. Open the trash, drag the uninstall.command file out + of the trash and double-click on it. You will be prompted for confirmation and the administration password.
+The trash may still appear full after this command; emptying the trash from the desktop should make it appear + empty again.
We believe this is due to an IPv6-related bug in Mac OS X, but don't - fully understand the issue yet. In any case, changing the proxy setting - to 127.0.0.1 instead of 5.9. In Mac OS X Panther (10.3), images often fail to + load and/or I experience random delays in page loading. I'm using localhost as my + browser's proxy setting. +
We believe this is due to an IPv6-related bug in Mac OS X, but don't fully understand the issue yet. In any + case, changing the proxy setting to 127.0.0.1 instead of localhost works around the problem.
The upgrade process to Mac OS X Mavericks (10.9) from an earlier - version of OS X deletes all user accounts that are either not part of - OS X itself or are not interactive user accounts (ones you log in - with). Since, for the sake of security, Privoxy runs as a non-privileged user that is - created by its installer (_privoxy), it can no longer start up once - that account gets deleted. The solution is to perform a complete - uninstall using the supplied uninstall.command script (either back up your - configuration files or select to not have the uninstaller remove them - when it prompts you) and then reinstall Privoxy using the installer package and merge in - your configuration.
+The upgrade process to Mac OS X Mavericks (10.9) from an earlier version of OS X deletes all user accounts + that are either not part of OS X itself or are not interactive user accounts (ones you log in with). Since, for + the sake of security, Privoxy runs as a non-privileged user that is created by + its installer (_privoxy), it can no longer start up once that account gets deleted. The solution is to perform a + complete uninstall using the supplied uninstall.command script (either back up + your configuration files or select to not have the uninstaller remove them when it prompts you) and then + reinstall Privoxy using the installer package and merge in your + configuration.
Chances are that the site suffers from a bug in PHP, which results in empty pages being sent - if the client explicitly requests an uncompressed page, like - Privoxy does. This bug has been fixed - in PHP 4.2.3.
- -To find out if this is in fact the source of the problem, try adding - the site to a -prevent-compression section in - user.action:
- -
- - # Make exceptions for ill-behaved sites: - # - {-prevent-compression} - .example.com -- |
-
If that works, you may also want to report the problem to the site's - webmasters, telling them to use zlib.output_compression instead of - ob_gzhandler in their PHP applications (workaround) or upgrade to PHP - 4.2.3 or later (fix).
+Privoxy tries to get the hostname of the system its running on from the IP + address of the system interface it is bound to (from the config file listen-address setting). If the system cannot supply this information, + Privoxy logs this condition.
+Typically, this would be considered a minor system configuration error. It is not a fatal error to + Privoxy however, but may result in a much slower response from Privoxy on some platforms due to DNS timeouts.
+This can be caused by a problem with the local hosts file. If this file has been + changed from the original, try reverting it to see if that helps. Make sure whatever name(s) are used for the + local system, that they resolve both ways.
+You should also be able to work around the problem with the hostname option.
Privoxy tries to get the hostname - of the system its running on from the IP address of the system - interface it is bound to (from the config - file listen-address setting). If the system cannot - supply this information, Privoxy logs - this condition.
- -Typically, this would be considered a minor system configuration - error. It is not a fatal error to Privoxy however, but may result in a much slower - response from Privoxy on some - platforms due to DNS timeouts.
- -This can be caused by a problem with the local hosts file. If this file has been changed from the - original, try reverting it to see if that helps. Make sure whatever - name(s) are used for the local system, that they resolve both ways.
- -You should also be able to work around the problem with the hostname - option.
+Port 8118 is Privoxy's default TCP "listening" + port. Typically this message would mean that there is already one instance of Privoxy running, and your system is actually trying to start a second Privoxy on the same port, which will not work. (You can have multiple instances but they + must be assigned different ports.) How and why this might happen varies from platform to platform, but you need + to check your installation and start-up procedures.
Port 8118 is Privoxy's default TCP - "listening" port. Typically this message - would mean that there is already one instance of Privoxy running, and your system is actually - trying to start a second Privoxy on - the same port, which will not work. (You can have multiple instances - but they must be assigned different ports.) How and why this might - happen varies from platform to platform, but you need to check your - installation and start-up procedures.
+This may be the result of an overly aggressive filter. The filters that are enabled in the default + configuration aren't expected to cause problems like this. If you enabled the "demoronizer" filter, please try temporarily disabling it.
+If that doesn't help, temporarily disable all filters to see if another filter could be the culprit. If the + problem disappears, enable the filters one by one, until the problem reappears and the offending filter is + found.
+Once the problem-causing filter is known, it can be fixed or disabled.
+Upgrading Privoxy, or going to the most recent default.action file available from git might be worth a try, too.
This may be the result of an overly aggressive filter. The filters - that are enabled in the default configuration aren't expected to cause - problems like this. If you enabled the "demoronizer" filter, please try temporarily disabling - it.
- -If that doesn't help, temporarily disable all filters to see if - another filter could be the culprit. If the problem disappears, enable - the filters one by one, until the problem reappears and the offending - filter is found.
- -Once the problem-causing filter is known, it can be fixed or - disabled.
- -Upgrading Privoxy, or going to the - most recent default.action file available - from SourceForge might be worth a try, too.
+This may also be caused by an (overly aggressive filter in conjunction + with a web server that is misreporting the content type. By default binary files are exempted from Privoxy's filtering (unless the web server by mistake says the file is something else).
This may also be caused by an (overly aggressive filter in conjunction - with a web server that is misreporting the content type. By default - binary files are exempted from Privoxy's filtering (unless the web server by - mistake says the file is something else).
+The original demoronizer was a Perl script that cleaned up HTML pages which were created with certain + Microsoft products. MS has used proprietary extensions to standardized font encodings (ISO 8859-1), which has + caused problems for pages that are viewed with non-Microsoft products (and are expecting to see a standard set of + fonts). The demoronizer corrected these errors so the pages displayed correctly. Privoxy borrowed from this script, introducing a filter based on the original demoronizer, + which in turn could correct these errors on the fly.
+But this is only needed in some situations, and will cause serious problems in some other situations.
+If you are using Microsoft products, you do not need it. If you need to view pages with UTF-8 characters (such + as Cyrillic or Chinese), then it will cause corruption of the fonts, and thus should not be on.
+On the other hand, if you use non-Microsoft products, and you occasionally notice weird characters on pages, + you might want to try it.
The original demoronizer was a Perl script that cleaned up HTML - pages which were created with certain Microsoft products. MS has used - proprietary extensions to standardized font encodings (ISO 8859-1), - which has caused problems for pages that are viewed with non-Microsoft - products (and are expecting to see a standard set of fonts). The - demoronizer corrected these errors so the pages displayed correctly. - Privoxy borrowed from this script, - introducing a filter based on the original demoronizer, which in turn - could correct these errors on the fly.
- -But this is only needed in some situations, and will cause serious - problems in some other situations.
- -If you are using Microsoft products, you do not need it. If you need - to view pages with UTF-8 characters (such as Cyrillic or Chinese), then - it will cause corruption of the fonts, and thus should not be on.
- -On the other hand, if you use non-Microsoft products, and you - occasionally notice weird characters on pages, you might want to try - it.
-Privoxy is attempting to disable - malicious Javascript in this case, with the unsolicited-popups filter. Privoxy cannot tell very well "good" code snippets from "bad" code snippets.
- -If you see this in HTML source, and the page displays without - problems, then this is good, and likely some pop-up window was - disabled. If you see this where it is causing a problem, such as a - downloaded program source code file, then you should set an exception - for this site or page such that the integrity of the page stays in tact - by disabling all filtering.
+Privoxy is attempting to disable malicious Javascript in this case, with the unsolicited-popups filter. Privoxy cannot tell very well + "good" code snippets from "bad" code snippets.
+If you see this in HTML source, and the page displays without problems, then this is good, and likely some + pop-up window was disabled. If you see this where it is causing a problem, such as a downloaded program source + code file, then you should set an exception for this site or page such that the integrity of the page stays in + tact by disabling all filtering.
There are potentially several factors here. First of all, the DNS
- resolution is done by the underlying operating system -- not
- Privoxy itself. Privoxy merely initiates the process and hands it
- off, and then later reports whatever the outcome was and tries to give
- a coherent message if there seems to be a problem. In some cases, this
- might otherwise be mitigated by the browser itself which might try some
- work-arounds and alternate approaches (e.g adding 5.17. I am getting too many DNS errors like "404 No Such Domain". Why can't Privoxy do this better?
+ There are potentially several factors here. First of all, the DNS resolution is done by the underlying
+ operating system -- not Privoxy itself. Privoxy
+ merely initiates the process and hands it off, and then later reports whatever the outcome was and tries to give
+ a coherent message if there seems to be a problem. In some cases, this might otherwise be mitigated by the
+ browser itself which might try some work-arounds and alternate approaches (e.g adding "www." to the URL). In other cases, if Privoxy is being
- chained with another proxy, this could complicate the issue, and cause
- undue delays and timeouts. In the case of a "socks4a" proxy, the socks server handles all the DNS.
- Privoxy would just be the "messenger" which is reporting whatever problem occurred
- downstream, and not the root cause of the error. In any case, versions newer than 3.0.3 include various improvements
- to help Privoxy better handle these
- cases. In other cases, if Privoxy is being chained with another proxy, this could
+ complicate the issue, and cause undue delays and timeouts. In the case of a "socks4a"
+ proxy, the socks server handles all the DNS. Privoxy would just be the
+ "messenger" which is reporting whatever problem occurred downstream, and not the root
+ cause of the error. In any case, versions newer than 3.0.3 include various improvements to help Privoxy better handle these cases.
This is probably a manifestation of the "100% - cpu" problem that occurs on pages containing many (thousands - upon thousands) of blank lines. The blank lines are in the raw HTML - source of the page, and the browser just ignores them. But the pattern - matching in Privoxy's page filtering - mechanism is trying to match against absurdly long strings and this - becomes very CPU-intensive, taking a long, long time to complete.
- -Until a better solution comes along, disable filtering on these - pages, particularly the js-annoyances and - unsolicited-popups filters. If you run into - this problem with a recent Privoxy - version, please send a problem report.
+This is probably a manifestation of the "100% cpu" problem that occurs on pages + containing many (thousands upon thousands) of blank lines. The blank lines are in the raw HTML source of the + page, and the browser just ignores them. But the pattern matching in Privoxy's + page filtering mechanism is trying to match against absurdly long strings and this becomes very CPU-intensive, + taking a long, long time to complete.
+Until a better solution comes along, disable filtering on these pages, particularly the js-annoyances and unsolicited-popups filters. If you run into this + problem with a recent Privoxy version, please send a problem report.
This should not happen, and for the overwhelming number of users - world-wide, it does not happen. I would suspect some inadvertent - interaction of software components such as anti-virus software, spyware - protectors, personal firewalls or similar components. Try disabling (or - uninstalling) these one at a time and see if that helps. Either way, if - you are using a recent Privoxy - version, please report the problem.
+This should not happen, and for the overwhelming number of users world-wide, it does not happen. I would + suspect some inadvertent interaction of software components such as anti-virus software, spyware protectors, + personal firewalls or similar components. Try disabling (or uninstalling) these one at a time and see if that + helps. Either way, if you are using a recent Privoxy version, please report the + problem.
It's probably due to compression. It is a common practice for web - servers to send their content "compressed" - in order to speed things up, and then let the browser "uncompress" them. When compiled with zlib support - Privoxy can decompress content before - filtering, otherwise you may want to enable prevent-compression.
- -As of Privoxy 3.0.9, zlib support - is enabled in the default builds.
+It's probably due to compression. It is a common practice for web servers to send their content "compressed" in order to speed things up, and then let the browser "uncompress" them. When compiled with zlib support Privoxy can + decompress content before filtering, otherwise you may want to enable prevent-compression.
+As of Privoxy 3.0.9, zlib support is enabled in the default builds.
Probably the browser is requesting ads through HTTPS and - Privoxy is blocking the requests. - Privoxy's error messages are delivered unencrypted and while it's - obvious for the browser that the HTTPS request is already blocked by - the proxy, some warn about unauthenticated content anyway.
- -To work around the problem you can redirect those requests to an - invalid local address instead of blocking them. While the redirects - aren't encrypted either, many browsers don't care. They simply follow - the redirect, fail to reach a server and display an error message - instead of the ad.
- -To do that, enable logging to figure out which requests get blocked - by Privoxy and add the hosts (no path - patterns) to a section like this:
- +Probably the browser is requesting ads through HTTPS and Privoxy is blocking + the requests. Privoxy's error messages are delivered unencrypted and while it's obvious for the browser that the + HTTPS request is already blocked by the proxy, some warn about unauthenticated content anyway.
+To work around the problem you can redirect those requests to an invalid local address instead of blocking + them. While the redirects aren't encrypted either, many browsers don't care. They simply follow the redirect, + fail to reach a server and display an error message instead of the ad.
+To do that, enable logging to figure out which requests get blocked by Privoxy and add the hosts (no path patterns) to a section like this:
- -{+redirect{http://127.0.0.1:0/} -block -limit-connect} -.ivwbox.de:443/ -+ {+redirect{http://127.0.0.1:0/} -block -limit-connect} +.ivwbox.de:443/ |
Additionally you have to configure your browser to contact - "127.0.0.1:0" directly (instead of through - Privoxy).
- -To add a proxy exception in Mozilla - Firefox open the "Preferences", click - the "Settings" button located on the - "Network" tab in the "Advanced" section, and add "127.0.0.1:0" in the "No Proxy - for:" field.
+Additionally you have to configure your browser to contact "127.0.0.1:0" directly + (instead of through Privoxy).
+To add a proxy exception in Mozilla Firefox open the "Preferences", click the "Settings" button located on the "Network" tab in the "Advanced" section, and add "127.0.0.1:0" in the "No Proxy for:" field.
+You can also prevent the problem by enabling https-inspection in which case Privoxy's error messages are delivered encrypted.
Please report the problem to the creator of your selinux - policies.
- -The problem is that some selinux policy writers aren't familiar with - the application they are trying to "secure" - and thus create policies that make no sense.
- -In Privoxy's case the problem - usually is that the policy only allows outgoing connections for certain - destination ports (e.g. 80 and 443). While this may cover the standard - ports, websites occasionally use other ports as well. This isn't a - security problem and therefore Privoxy's default configuration doesn't block - these requests.
- -If you really want to block these ports (and don't be able to load - websites that don't use standard ports), you should configure Privoxy - to block these ports as well, so it doesn't trigger the selinux - warnings.
+Please report the problem to the creator of your selinux policies.
+The problem is that some selinux policy writers aren't familiar with the application they are trying to + "secure" and thus create policies that make no sense.
+In Privoxy's case the problem usually is that the policy only allows outgoing + connections for certain destination ports (e.g. 80 and 443). While this may cover the standard ports, websites + occasionally use other ports as well. This isn't a security problem and therefore Privoxy's default configuration doesn't block these requests.
+If you really want to block these ports (and don't be able to load websites that don't use standard ports), + you should configure Privoxy to block these ports as well, so it doesn't trigger the selinux warnings.
Probably you unintentionally compiled Privoxy without threading support in which case - requests have to be serialized and only one can be served at the same - time.
- -Check your "USE" flags and make sure they - include "threads". If they don't, add the - flag and rebuild Privoxy.
- -If you compiled Privoxy with - threading support (on POSIX-based systems), the "Conditional #defines" section on http://config.privoxy.org/show-status will list "FEATURE_PTHREAD" as "enabled".
+Probably you unintentionally compiled Privoxy without threading support in + which case requests have to be serialized and only one can be served at the same time.
+Check your "USE" flags and make sure they include "threads". If they don't, add the flag and rebuild Privoxy.
+If you compiled Privoxy with threading support (on POSIX-based systems), the + "Conditional #defines" section on http://config.privoxy.org/show-status will list "FEATURE_PTHREAD" as + "enabled".
+Privoxy marks sockets as tainted when it can't use them to serve additional + requests. This does not necessarily mean that something went wrong and information about tainted sockets is only + logged if connection debugging is enabled (debug 2).
+For example server sockets that were used for CONNECT requests (which are used to tunnel https:// requests) + are considered tainted once the client closed its connection to Privoxy. + Technically Privoxy could keep the connection to the server open, but the server + would not accept requests that do not belong to the previous TLS/SSL session (and the client may even have + terminated the session).
+Server sockets are also marked tainted when a client requests a resource, but closes the connection before + Privoxy has completely received (and forwarded) the resource to the client. In + this case the server would (probably) accept additional requests, but Privoxy + could not get the response without completely reading the leftovers from the previous response.
+These are just two examples, there are currently a bit more than 25 scenarios in which a socket is considered + tainted.
+While sockets can also be marked tainted as a result of a technical problem that may be worth fixing, the + problem will be explicitly logged as error.
+This can happen if your custom filters require more memory than Privoxy is + allowed to use. Usually the problem is that the operating system enforces a stack size limit that isn't + sufficient.
+Unless the problem occurs with the filters available in the default configuration, this is not considered a + Privoxy bug.
+To prevent the crashes you can rewrite your filter to use less resources, increase the relevant memory limit + or recompile pcre to use less stack space. For details please see the pcrestack man page and the documentation of + your operating system.
Your userid probably isn't allowed to edit the file. On Windows you can use the windows equivalent of + sudo:
+
+ runas /user:administrator "notepad \privoxy\config.txt"+ |
+
or fix the file permissions:
+
+ C:\Privoxy>icacls config.txt +config.txt BUILTIN\Administrators:(I)(F) + NT AUTHORITY\SYSTEM:(I)(F) + BUILTIN\Users:(I)(RX) + NT AUTHORITY\Authenticated Users:(I)(M) -+ |
+
or try to point-n-click your way through adjusting the file permissions in windows explorer.