If the ad had been displayed before you added its URL, it will @@ -244,7 +244,7 @@ Request: 66.70.21.80/scripts/click.php?hid=a71b9f6504b0c5681fa5&si=Ua
This is a quirk that effects the installation of 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 @@ -361,40 +361,24 @@ Request: 66.70.21.80/scripts/click.php?hid=a71b9f6504b0c5681fa5&si=Ua
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).
+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.
This is caused by the "demoronizer" - filter. You should either upgrade Privoxy, or at least upgrade to the most recent - default.action file available from SourceForge. Or you can simply disable the demoronizer - filter.
+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 the "demoronizer" filter, in conjunction with a web server - that is misreporting the content type. Binary files are exempted from - Privoxy's filtering (unless the web - server by mistake says the file is something else). Either upgrade - Privoxy, or go to the most recent - default.action file available from SourceForge.
+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).
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 + ressources, 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.
+