X-Git-Url: http://www.privoxy.org/gitweb/?p=privoxy.git;a=blobdiff_plain;f=doc%2Fwebserver%2Fuser-manual%2Fconfig.html;h=5cad65b767b7b00502457d2d1143b20a64bd0b2f;hp=9c4ba598236b6f83ef864c22b69dbd3ec549b509;hb=42c361793c45b0d5fc0c116707ca12b2f60f4c52;hpb=6d810395712f0337682205c4ea304009c86c128f diff --git a/doc/webserver/user-manual/config.html b/doc/webserver/user-manual/config.html index 9c4ba598..5cad65b7 100644 --- a/doc/webserver/user-manual/config.html +++ b/doc/webserver/user-manual/config.html @@ -2,37 +2,27 @@ Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-- Privoxy 3.0.18 User Manual + Privoxy 3.0.26 User Manual | ||
---|---|---|
- http://www.privoxy.org/https://www.privoxy.org/version/user-manual/ will be used, where version is the Privoxy version. @@ -525,7 +515,66 @@ Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
+ A directory where Privoxy can create temporary files. +
++ Path name +
++ unset +
++ No temporary files are created, external filters don't + work. +
++ To execute external + filters, Privoxy + has to create temporary files. This directive specifies the + directory the temporary files should be written to. +
++ It should be a directory only Privoxy (and trusted users) can + access. +
+Actions files contain all the per site and per URL configuration for ad blocking, cookie management, privacy - considerations, etc. There is no point in using Privoxy without at least one - actions file. -
-- Note that since Privoxy 3.0.7, the complete filename, - including the ".action" - extension has to be specified. The syntax change was - necessary to be consistent with the other file options and - to allow previously forbidden characters. + considerations, etc.
@@ -675,7 +715,7 @@ Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">For most troubleshooting purposes, you will have to change that, please refer to the debugging section for details.
-- Your logfile will grow indefinitely, and you will probably - want to periodically remove it. On Unix systems, you can do - this with a cron job (see "man - cron"). For Red Hat based Linux distributions, a logrotate script has been included. -
Any log files must be writable by whatever user Privoxy is being run as (on Unix, default user id is "privoxy").
++ To prevent the logfile from growing indefinitely, it is + recommended to periodically rotate or shorten it. Many + operating systems support log rotation out of the box, some + require additional software to do it. For details, please + refer to the documentation for your operating system. +
- Privoxy used to ship with - the debug levels recommended above enabled by default, but - due to privacy concerns 3.0.7 and later are configured to - only log fatal errors. -
If you are used to the more verbose settings, simply enable the debug lines below again. @@ -1088,7 +1123,8 @@ Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
- None + 1 or + 0
- Unset + 0
- If you configure Privoxyto - be reachable from the network, consider using Privoxy + to be reachable from the network, consider using access control lists (ACL's, see below), and/or a firewall.
@@ -1323,13 +1359,6 @@ Transitional//EN""http://www.w3.org/TR/html4/loose.dtd"> and enable-remote-toggle -- With the exception noted above, listening on multiple - addresses is currently not supported by Privoxy directly. It can be done on - most operating systems by letting a packet filter redirect - request for certain addresses to Privoxy, though. -
- The windows version will only display the toggle icon in - the system tray if this option is present. -
+ Whether or not proxy authentication through Privoxy should work. +
++ 0 or 1 +
++ 0 +
++ Proxy authentication headers are removed. +
++ Privoxy itself does not support proxy authentication, but + can allow clients to authenticate against Privoxy's parent + proxy. +
++ By default Privoxy (3.0.21 and later) don't do that and + remove Proxy-Authorization headers in requests and + Proxy-Authenticate headers in responses to make it harder + for malicious sites to trick inexperienced users into + providing login information. +
++ If this option is enabled the headers are forwarded. +
++ Enabling this option is not recommended if there is no parent + proxy that requires authentication or if the local network + between Privoxy and the parent proxy isn't trustworthy. If + proxy authentication is only required for some requests, it + is recommended to use a client header filter to remove the + authentication headers for requests where they aren't + needed. +
++ forward-socks5t works like vanilla + forward-socks5 but lets Privoxy additionally use + Tor-specific SOCKS extensions. Currently the only supported + SOCKS extension is optimistic data which can reduce the + latency for the first request made on a newly created + connection. +
socks_proxy and http_parent can be a @@ -2377,12 +2484,19 @@ Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
- forward-socks5 / 127.0.0.1:9050 . + forward-socks5t / 127.0.0.1:9050 .
+ Note that if you got Tor through one of the bundles, you + may have to change the port from 9050 to 9150 (or even + another one). For details, please check the documentation + on the Tor + website. +
The public Tor network can't be used to reach your local network, if you need to @@ -2683,6 +2797,10 @@ Transitional//EN""http://www.w3.org/TR/html4/loose.dtd"> outgoing HTTP connections into Privoxy.
++ Note that intercepting encrypted connections (HTTPS) isn't + supported. +
Make sure that Privoxy's own requests aren't redirected as well. Additionally take @@ -2693,6 +2811,12 @@ Transitional//EN""http://www.w3.org/TR/html4/loose.dtd"> by the outside or an attacker has access to the pages you visit.
++ If you are running Privoxy as intercepting proxy without + being able to intercept all client requests you may want to + adjust the CGI templates to make sure they don't reference + content from config.privoxy.org. +
+ Whether or not pipelined requests should be served. +
++ 0 or 1. +
++ None +
++ If Privoxy receives more than one request at once, it + terminates the client connection after serving the first + one. +
++ Privoxy currently doesn't + pipeline outgoing requests, thus allowing pipelining on the + client connection is not guaranteed to improve the + performance. +
++ By default Privoxy tries + to discourage clients from pipelining by discarding + aggressively pipelined requests, which forces the client to + resend them through a new connection. +
++ This option lets Privoxy + tolerate pipelining. Whether or not that improves + performance mainly depends on the client configuration. +
++ If you are seeing problems with pages not properly loading, + disabling this option could work around the problem. +
++ tolerate-pipelining 1 +
+- None + 128
+ One most POSIX-compliant systems Privoxy can't properly deal with more + than FD_SETSIZE file descriptors at the same time and has + to reject connections if the limit is reached. This will + likely change in a future version, but currently this limit + can't be increased without recompiling Privoxy with a different FD_SETSIZE + limit. +
- This is a work-around for Firefox bug 492459: " Websites are no longer rendered if SSL requests - for JavaScripts are blocked by a proxy. " ("Websites are no longer + rendered if SSL requests for JavaScripts are blocked by a + proxy." (https://bugzilla.mozilla.org/show_bug.cgi?id=492459) - As the bug has been fixed for quite some time this option - should no longer be needed and will be removed in a future - release. Please speak up if you have a reason why the - option should be kept around. + "_top">https://bugzilla.mozilla.org/show_bug.cgi?id=492459), + the bug has been fixed for quite some time, but this + directive is also useful to make it harder for websites to + detect whether or not resources are being blocked.
+ The order in which client headers are sorted before + forwarding them. +
++ Client header names delimited by + spaces or tabs +
++ None +
++ By default Privoxy leaves + the client headers in the order they were sent by the + client. Headers are modified in-place, new headers are + added at the end of the already existing headers. +
++ The header order can be used to fingerprint client requests + independently of other headers like the User-Agent. +
++ This directive allows to sort the headers differently to + better mimic a different User-Agent. Client headers will be + emitted in the order given, headers whose name isn't + explicitly specified are added at the end. +
++ Note that sorting headers in an uncommon way will make + fingerprinting actually easier. Encrypted headers are not + affected by this directive. +
++ The name of a tag that will always be set for clients that + requested it through the webinterface. +
++ Tag name followed by a + description that will be shown in the webinterface +
++ None +
++ Warning + | +
+ + This is an experimental feature. The syntax is + likely to change in future versions. + + |
+
+ Client-specific tags allow Privoxy admins to create + different profiles and let the users chose which one they + want without impacting other users. +
++ One use case is allowing users to circumvent certain blocks + without having to allow them to circumvent all blocks. This + is not possible with the enable-remote-toggle + feature because it would bluntly disable all blocks for + all users and also affect other actions like filters. It + also is set globally which renders it useless in most + multi-user setups. +
++ After a client-specific tag has been defined with the + client-specific-tag directive, action sections can be + activated based on the tag by using a CLIENT-TAG pattern. The CLIENT-TAG pattern is + evaluated at the same priority as URL patterns, as a result + the last matching pattern wins. Tags that are created based + on client or server headers are evaluated later on and can + overrule CLIENT-TAG and URL patterns! +
++ The tag is set for all requests that come from clients that + requested it to be set. Note that "clients" are + differentiated by IP address, if the IP address changes the + tag has to be requested again. +
++ Clients can request tags to be set by using the CGI + interface http://config.privoxy.org/client-tags. + The specific tag description is only used on the web page + and should be phrased in away that the user understand the + effect of the tag. +
++
+
++ # Define a couple of tags, the described effect requires action sections + # that are enabled based on CLIENT-TAG patterns. + client-specific-tag circumvent-blocks Overrule blocks but do not affect other actions + disable-content-filters Disable content-filters but do not affect other actions + ++ |
+
+ How long a temporarily enabled tag remains enabled. +
++ Time in seconds. +
++ 60 +
++ Warning + | +
+ + This is an experimental feature. The syntax is + likely to change in future versions. + + |
+
+ In case of some tags users may not want to enable them + permanently, but only for a short amount of time, for + example to circumvent a block that is the result of an + overly-broad URL pattern. +
++ The CGI interface http://config.privoxy.org/client-tags therefore + provides a "enable this tag temporarily" option. If it is + used, the tag will be set until the client-tag-lifetime is + over. +
++
+
++ # Increase the time to life for temporarily enabled tags to 3 minutes + client-tag-lifetime 180 + ++ |
+
+ Whether or not Privoxy should use IP addresses specified + with the X-Forwarded-For header +
++ 0 or one +
++ 0 +
++ Warning + | +
+ + This is an experimental feature. The syntax is + likely to change in future versions. + + |
+
+ If clients reach Privoxy through another proxy, for example + a load balancer, Privoxy can't tell the client's IP address + from the connection. If multiple clients use the same + proxy, they will share the same client tag settings which + is usually not desired. +
++ This option lets Privoxy use the X-Forwarded-For header + value as client IP address. If the proxy sets the header, + multiple clients using the same proxy do not share the same + client tag settings. +
++ This option should only be enabled if Privoxy can only be + reached through a proxy and if the proxy can be trusted to + set the header correctly. It is recommended that ACL are + used to make sure only trusted systems can reach Privoxy. +
++ If access to Privoxy isn't limited to trusted systems, this + option would allow malicious clients to change the client + tags for other clients or increase Privoxy's memory + requirements by registering lots of client tag settings for + clients that don't exist. +
++
+
++ # Allow systems that can reach Privoxy to provide the client + # IP address with a X-Forwarded-For header. + trust-x-forwarded-for 1 + |