X-Git-Url: http://www.privoxy.org/gitweb/?a=blobdiff_plain;f=doc%2Fsource%2Fp-config.sgml;h=bb831aae7a1c7023df2a7d5cc899beb256a7b350;hb=4ce0ab023d56dc9bc4f1ff161150f9c29002f34a;hp=c2fd53a63fa62526364bd94b69e3101abad207c0;hpb=cb55b61769015017aa64c553daecc52b6a070888;p=privoxy.git
diff --git a/doc/source/p-config.sgml b/doc/source/p-config.sgml
index c2fd53a6..bb831aae 100644
--- a/doc/source/p-config.sgml
+++ b/doc/source/p-config.sgml
@@ -3,9 +3,9 @@
Purpose : Used with other docs and files only.
- $Id: p-config.sgml,v 2.47 2009/04/17 11:40:48 fabiankeil Exp $
+ $Id: p-config.sgml,v 2.65 2010/10/30 16:09:31 fabiankeil Exp $
- Copyright (C) 2001-2009 Privoxy Developers http://www.privoxy.org/
+ Copyright (C) 2001-2010 Privoxy Developers http://www.privoxy.org/
See LICENSE.
========================================================================
@@ -81,7 +81,9 @@
The main config file controls all aspects of Privoxy's
operation that are not location dependent (i.e. they apply universally, no matter
- where you may be surfing).
+ where you may be surfing). Like the filter and action files, the config file is
+ a plain text file and can be modified with a text editor like emacs, vim or
+ notepad.exe.
]]>
@@ -95,10 +97,10 @@
Sample Configuration File for Privoxy v&p-version;
- $Id: p-config.sgml,v 2.47 2009/04/17 11:40:48 fabiankeil Exp $
+ $Id: p-config.sgml,v 2.65 2010/10/30 16:09:31 fabiankeil Exp $
-Copyright (C) 2001-2009 Privoxy Developers http://www.privoxy.org/
+Copyright (C) 2001-2010 Privoxy Developers http://www.privoxy.org/
@@ -794,7 +796,7 @@ actionsfile
@@filterfile default.filter]]>
-@@#filterfile user.filter # User customizations]]>
+@@filterfile user.filter # User customizations]]>
@@ -1007,7 +1009,7 @@ actionsfile
debug 2 # show each connection status
debug 4 # show I/O status
debug 8 # show header parsing
- debug 16 # log all data written to the network into the logfile
+ debug 16 # log all data written to the network
debug 32 # debug force feature
debug 64 # debug regular expression filters
debug 128 # debug redirects
@@ -1017,6 +1019,7 @@ actionsfile
debug 2048 # CGI user interface
debug 4096 # Startup banner and warnings.
debug 8192 # Non-fatal errors
+ debug 32768 # log all data read from the network
@@ -1238,9 +1241,7 @@ actionsfile
bind to all IPv4 interfaces (addresses) on your machine and may become reachable
from the Internet. In that case, consider using access control lists (ACL's, see below), and/or
- a firewall. If the hostname is localhost, Privoxy
- will explicitly try to bind to an IPv4 address. For other hostnames it depends
- on the operating system which IP version will be used.
+ a firewall.
If you open Privoxy to untrusted users, you will
@@ -1710,8 +1711,8 @@ ACLs: permit-access and deny-access
IP addresses, only the first one is used.
- Some systems allows IPv4 client to connect to IPv6 server socket.
- Then the client's IPv4 address will be translated by system into
+ Some systems allow IPv4 clients to connect to IPv6 server sockets.
+ Then the client's IPv4 address will be translated by the system into
IPv6 address space with special prefix ::ffff:0:0/96 (so called IPv4
mapped IPv6 address). Privoxy can handle it
and maps such ACL addresses automatically.
@@ -2277,6 +2278,10 @@ forward-socks4, forward-socks4a and forward-socks5
that go away when you try again manually. Start with a small value and check Privoxy's
logfile from time to time, to see how many retries are usually needed.
+
+ Due to a bug, this option currently also causes Privoxy to
+ retry in case of certain problems with direct connections.
+
@@ -2291,6 +2296,11 @@ forward-socks4, forward-socks4a and forward-socks5
@@forwarded-connect-retries 0]]>
+
+
+
+Miscellaneous
+
accept-intercepted-requests
@@ -2507,17 +2517,183 @@ forward-socks4, forward-socks4a and forward-socks5
Effect if unset:
- Connections are not reused.
+ Connections are not kept alive.
Notes:
+
+ This option allows clients to keep the connection to &my-app;
+ alive. If the server supports it, &my-app; will keep
+ the connection to the server alive as well. Under certain
+ circumstances this may result in speed-ups.
+
+
+ By default, &my-app; will close the connection to the server if
+ the client connection gets closed, or if the specified timeout
+ has been reached without a new request coming in. This behaviour
+ can be changed with the connection-sharing option.
+
This option has no effect if Privoxy
has been compiled without keep-alive support.
+
+ Note that a timeout of five seconds as used in the default
+ configuration file significantly decreases the number of
+ connections that will be reused. The value is used because
+ some browsers limit the number of connections they open to
+ a single host and apply the same limit to proxies. This can
+ result in a single website grabbing all the
+ connections the browser allows, which means connections to
+ other websites can't be opened until the connections currently
+ in use time out.
+
+
+ Several users have reported this as a Privoxy bug, so the
+ default value has been reduced. Consider increasing it to
+ 300 seconds or even more if you think your browser can handle
+ it. If your browser appears to be hanging it can't.
+
+
+
+
+ Examples:
+
+
+ keep-alive-timeout 300
+
+
+
+
+@@keep-alive-timeout 5]]>
+
+
+
+default-server-timeout
+
+
+ Specifies:
+
+
+ Assumed server-side keep-alive timeout if not specified by the server.
+
+
+
+
+ Type of value:
+
+
+ Time in seconds.
+
+
+
+
+ Default value:
+
+ None
+
+
+
+ Effect if unset:
+
+
+ Connections for which the server didn't specify the keep-alive
+ timeout are not reused.
+
+
+
+
+ Notes:
+
+
+ Enabling this option significantly increases the number of connections
+ that are reused, provided the keep-alive-timeout option
+ is also enabled.
+
+
+ While it also increases the number of connections problems
+ when &my-app; tries to reuse a connection that already has
+ been closed on the server side, or is closed while &my-app;
+ is trying to reuse it, this should only be a problem if it
+ happens for the first request sent by the client. If it happens
+ for requests on reused client connections, &my-app; will simply
+ close the connection and the client is supposed to retry the
+ request without bothering the user.
+
+
+ Enabling this option is therefore only recommended if the
+ connection-sharing option
+ is disabled.
+
+
+ It is an error to specify a value larger than the keep-alive-timeout value.
+
+
+ This option has no effect if Privoxy
+ has been compiled without keep-alive support.
+
+
+
+
+ Examples:
+
+
+ default-server-timeout 60
+
+
+
+
+@@#default-server-timeout 60]]>
+
+
+
+connection-sharing
+
+
+ Specifies:
+
+
+ Whether or not outgoing connections that have been kept alive
+ should be shared between different incoming connections.
+
+
+
+
+ Type of value:
+
+
+ 0 or 1
+
+
+
+
+ Default value:
+
+ None
+
+
+
+ Effect if unset:
+
+
+ Connections are not shared.
+
+
+
+
+ Notes:
+
+
+ This option has no effect if Privoxy
+ has been compiled without keep-alive support, or if it's disabled.
+
@@ -2528,13 +2704,39 @@ forward-socks4, forward-socks4a and forward-socks5
There are also a few privacy implications you should be aware of.
- Outgoing connections are shared between clients (if there are more
- than one) and closing the client that initiated the outgoing connection
- does not affect the connection between &my-app; and the server unless
- the client's request hasn't been completed yet. If the outgoing connection
- is idle, it will not be closed until either Privoxy's
- or the server's timeout is reached. While it's open, the server knows
- that the system running &my-app; is still there.
+ If this option is effective, outgoing connections are shared between
+ clients (if there are more than one) and closing the browser that initiated
+ the outgoing connection does no longer affect the connection between &my-app;
+ and the server unless the client's request hasn't been completed yet.
+
+
+ If the outgoing connection is idle, it will not be closed until either
+ Privoxy's or the server's timeout is reached.
+ While it's open, the server knows that the system running &my-app; is still
+ there.
+
+
+ If there are more than one client (maybe even belonging to multiple users),
+ they will be able to reuse each others connections. This is potentially
+ dangerous in case of authentication schemes like NTLM where only the
+ connection is authenticated, instead of requiring authentication for
+ each request.
+
+
+ If there is only a single client, and if said client can keep connections
+ alive on its own, enabling this option has next to no effect. If the client
+ doesn't support connection keep-alive, enabling this option may make sense
+ as it allows &my-app; to keep outgoing connections alive even if the client
+ itself doesn't support it.
+
+
+ You should also be aware that enabling this option increases the likelihood
+ of getting the "No server or forwarder data" error message, especially if you
+ are using a slow connection to the Internet.
+
+
+ This option should only be used by experienced users who
+ understand the risks and can weight them against the benefits.
@@ -2542,12 +2744,12 @@ forward-socks4, forward-socks4a and forward-socks5
Examples:
- keep-alive-timeout 300
+ connection-sharing 1
-@@keep-alive-timeout 300]]>
+@@#connection-sharing 1]]>
@@ -2607,6 +2809,148 @@ forward-socks4, forward-socks4a and forward-socks5
+max-client-connections
+
+
+ Specifies:
+
+
+ Maximum number of client connections that will be served.
+
+
+
+
+ Type of value:
+
+
+ Positive number.
+
+
+
+
+ Default value:
+
+ None
+
+
+
+ Effect if unset:
+
+
+ Connections are served until a resource limit is reached.
+
+
+
+
+ Notes:
+
+
+ &my-app; creates one thread (or process) for every incoming client
+ connection that isn't rejected based on the access control settings.
+
+
+ If the system is powerful enough, &my-app; can theoretically deal with
+ several hundred (or thousand) connections at the same time, but some
+ operating systems enforce resource limits by shutting down offending
+ processes and their default limits may be below the ones &my-app; would
+ require under heavy load.
+
+
+ Configuring &my-app; to enforce a connection limit below the thread
+ or process limit used by the operating system makes sure this doesn't
+ happen. Simply increasing the operating system's limit would work too,
+ but if &my-app; isn't the only application running on the system,
+ you may actually want to limit the resources used by &my-app;.
+
+
+ If &my-app; is only used by a single trusted user, limiting the
+ number of client connections is probably unnecessary. If there
+ are multiple possibly untrusted users you probably still want to
+ additionally use a packet filter to limit the maximal number of
+ incoming connections per client. Otherwise a malicious user could
+ intentionally create a high number of connections to prevent other
+ users from using &my-app;.
+
+
+ Obviously using this option only makes sense if you choose a limit
+ below the one enforced by the operating system.
+
+
+
+
+ Examples:
+
+
+ max-client-connections 256
+
+
+
+
+@@#max-client-connections 256]]>
+
+
+
+handle-as-empty-doc-returns-ok
+
+
+ Note:
+
+
+ This is a work-around for Firefox bug 492459:
+
+ Websites are no longer rendered if SSL requests for JavaScripts are blocked by a proxy.
+
+ (https://bugzilla.mozilla.org/show_bug.cgi?id=492459)
+
+
+
+
+ Specifies:
+
+
+ The status code Privoxy returns for pages blocked with
+
+ +handle-as-empty-document.
+
+
+
+
+ Type of value:
+
+
+ 0 or 1
+
+
+
+
+ Default value:
+
+ 0
+
+
+
+ Effect if unset:
+
+
+ Privoxy returns a status 403(forbidden) for all blocked pages.
+
+
+
+
+ Effect if set:
+
+
+ Privoxy returns a status 200(OK) for pages blocked with +handle-as-empty-document
+ and a status 403(Forbidden) for all other blocked pages.
+
+
+
+
+@@handle-as-empty-doc-returns-ok 1]]>
+
+
+