+# forwarded-connect-retries is mainly interesting for socks4a
+# connections, where Privoxy can't detect why the connections
+# failed. The connection might have failed because of a DNS timeout
+# in which case a retry makes sense, but it might also have failed
+# because the server doesn't exist or isn't reachable. In this
+# case the retry will just delay the appearance of Privoxy's
+# error message.
+#
+# Note that in the context of this option, "forwarded connections"
+# includes all connections that Privoxy forwards through other
+# proxies. This option is not limited to the HTTP CONNECT method.
+#
+# Only use this option, if you are getting lots of
+# forwarding-related error messages 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.
+#
+# Examples:
+#
+# forwarded-connect-retries 1
+#
+forwarded-connect-retries 0
+#
+#
+# 6. MISCELLANEOUS
+# =================
+#
+# 6.1. accept-intercepted-requests
+# =================================
+#
+# Specifies:
+#
+# Whether intercepted requests should be treated as valid.
+#
+# Type of value:
+#
+# 0 or 1
+#
+# Default value:
+#
+# 0
+#
+# Effect if unset:
+#
+# Only proxy requests are accepted, intercepted requests are
+# treated as invalid.
+#
+# Notes:
+#
+# If you don't trust your clients and want to force them to use
+# Privoxy, enable this option and configure your packet filter
+# to redirect outgoing HTTP connections into Privoxy.
+#
+# Make sure that Privoxy's own requests aren't redirected as well.
+# Additionally take care that Privoxy can't intentionally connect
+# to itself, otherwise you could run into redirection loops if
+# Privoxy's listening port is reachable by the outside or an
+# attacker has access to the pages you visit.
+#
+# Examples:
+#
+# accept-intercepted-requests 1
+#
+accept-intercepted-requests 0
+#
+#
+# 6.2. allow-cgi-request-crunching
+# =================================
+#
+# Specifies:
+#
+# Whether requests to Privoxy's CGI pages can be blocked or
+# redirected.
+#
+# Type of value:
+#
+# 0 or 1
+#
+# Default value:
+#
+# 0
+#
+# Effect if unset:
+#
+# Privoxy ignores block and redirect actions for its CGI pages.
+#
+# Notes:
+#
+# By default Privoxy ignores block or redirect actions for
+# its CGI pages. Intercepting these requests can be useful in
+# multi-user setups to implement fine-grained access control,
+# but it can also render the complete web interface useless and
+# make debugging problems painful if done without care.
+#
+# Don't enable this option unless you're sure that you really
+# need it.
+#
+# Examples:
+#
+# allow-cgi-request-crunching 1
+#
+allow-cgi-request-crunching 0
+#
+#
+# 6.3. split-large-forms
+# =======================
+#
+# Specifies:
+#
+# Whether the CGI interface should stay compatible with broken
+# HTTP clients.
+#
+# Type of value:
+#
+# 0 or 1
+#
+# Default value:
+#
+# 0
+#
+# Effect if unset:
+#
+# The CGI form generate long GET URLs.
+#
+# Notes:
+#
+# Privoxy's CGI forms can lead to rather long URLs. This isn't
+# a problem as far as the HTTP standard is concerned, but it can
+# confuse clients with arbitrary URL length limitations.
+#
+# Enabling split-large-forms causes Privoxy to divide big forms
+# into smaller ones to keep the URL length down. It makes editing
+# a lot less convenient and you can no longer submit all changes
+# at once, but at least it works around this browser bug.
+#
+# If you don't notice any editing problems, there is no reason
+# to enable this option, but if one of the submit buttons appears
+# to be broken, you should give it a try.
+#
+# Examples:
+#
+# split-large-forms 1
+#
+split-large-forms 0
+#
+#
+# 6.4. keep-alive-timeout
+# ========================
+#
+# Specifies:
+#
+# Number of seconds after which an open connection will no longer
+# be reused.
+#
+# Type of value:
+#
+# Time in seconds.
+#
+# Default value:
+#
+# None
+#
+# Effect if unset:
+#
+# Connections are not kept alive.
+#
+# Notes:
+#
+# This option allows clients to keep the connection to Privoxy
+# alive. If the server supports it, Privoxy will keep the
+# connection to the server alive as well. Under certain
+# circumstances this may result in speed-ups.
+#
+# By default, Privoxy 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
+#
+#
+# 6.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
+# Privoxy tries to reuse a connection that already has been closed
+# on the server side, or is closed while Privoxy 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, Privoxy 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
+#
+#
+# 6.6. 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.
+#
+# Notes:
+#
+# Note that reusing connections doesn't necessary cause
+# speedups. There are also a few privacy implications you should
+# be aware of.
+#
+# 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 Privoxy 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 Privoxy 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 Privoxy 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.
+#
+# Examples:
+#
+# connection-sharing 1
+#
+#connection-sharing 1
+#
+#
+# 6.7. socket-timeout
+# ====================
+#
+# Specifies:
+#
+# Number of seconds after which a socket times out if no data
+# is received.
+#
+# Type of value:
+#
+# Time in seconds.
+#
+# Default value:
+#
+# None
+#
+# Effect if unset:
+#
+# A default value of 300 seconds is used.
+#
+# Notes:
+#
+# For SOCKS requests the timeout currently doesn't start until
+# the SOCKS server accepted the request. This will be fixed in
+# the next release.
+#
+# Examples:
+#
+# socket-timeout 300
+#
+socket-timeout 300
+#
+#
+# 6.8. 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:
+#
+# Privoxy 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, Privoxy 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 Privoxy would require under heavy load.
+#
+# Configuring Privoxy 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 Privoxy isn't the only
+# application running on the system, you may actually want to
+# limit the resources used by Privoxy.
+#
+# If Privoxy 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 Privoxy.
+#
+# 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