Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+====== Speed Tweaks ======
+Polipo seems to perform best when it is not tampered with and while it uses the default settings.
+<code>
+## Cache
+# If polipo is not used by more than one person.
+cacheIsShared = false
+## Network
+# Do not perform IPv6 queries. A minor speed-up.
+dnsQueryIPv6 = no
+## Webserver
+# Disables all of polipo's internal webserver features
+# which is a good idea if they are not used or needed.
+disableConfiguration = true
+disableLocalInterface = true
+localDocumentRoot = ""
+disableIndexing = true
+## Privacy
+# Disabling sending hostname or IP to upstream proxies.
+disableVia = true
+# Censors headers, the following do not seem to break anything.
+censoredHeaders = from,accept-language,x-pad,link
+censorReferer = maybe
+## Blocking
+# It will never resolve to anything.
+forbiddenUrl = about:blank
+</code>
+  * Any other additional options seem to make ''polipo'' slower (including setting a chunk size, etc...).
+  * Do //not// enable PMM (Poor-Man's Multiplexing), it //will// break websites.
+  * ''relaxTransparency'', if set to ''true'' //will// break websites.
+====== Ad Blocking ======
+You can retrieve the current list of spam domains from [[:assets:databases:spam|the spam domains page]] and copy the ''domains.txt'' file to ''/etc/polipo/forbidden'' and let polipo filter out most ads.
+Compared to ''dansguardian'', ''squidGuard'', ''privoxy'' and ''tinyproxy'', it appears that ''polipo'' has the most efficient filtering system:
+  * ''dansguardian'' - slow, bulky, weighted system, a general mess that you will have to tweak all the time.
+  * ''squidGuard'' - pretty good, you have to rehash the lists, slower than ''polipo'' in any case.
+  * ''privoxy'' - perceivably slow filtering compared to ''polipo''.
+  * ''tinyproxy'' - will crash the system if the ''/etc/filter'' URL list is sufficiently long.
+====== Suppress Forbidden Output ======
+This hack will suppress any output on ''HTTP 403 Forbidden'' and is useful in combination with a ''forbidden'' file that allows you to specify which domains to block such that an empty document is returned instead of a ghastly error message:
+<code diff>
+--- http.c.orig	2014-03-05 15:23:19.000000000 +0000
++++ http.c	2014-03-05 15:26:34.118668644 +0000
+@@ -855,7 +855,7 @@
+     else
+         htmlMessage[MIN(i, 99)] = '\0';
+-    if(code != 304) {
++    if(code != 304 && code != 403) {
+         body = get_chunk();
+         if(!body) {
+             do_log(L_ERROR, "Couldn't allocate body buffer.\n");
+</code>
+{{:wizardale.png | Oh no, not this shit again!}} The reasoning behind polipo's [[http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/manual/Internal-forbidden-list.html|forbidden]] file is severely flawed. The author claims that the ''forbidden'' file //"specifies the set of URLs that should never be fetched"//. However, ''polipo'' internally manages the ''forbidden'' file as a list of URLs that will return ''HTTP 403'' to the client which is different from what the author claims. The result is that failed outcomes from an authentication procedure (ie: through HTTP) will return the same error code as any other domain from the ''forbidden'' file. This is wrong. Do not use this patch if you authenticate to services that return ''HTTP 403'' on failure or you will get a blank document.