+<sect3 renderas="sect4" id="max-client-connections"><title>max-client-connections</title>
+<variablelist>
+ <varlistentry>
+ <term>Specifies:</term>
+ <listitem>
+ <para>
+ Maximum number of client connections that will be served.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Type of value:</term>
+ <listitem>
+ <para>
+ <replaceable>Positive number.</replaceable>
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Default value:</term>
+ <listitem>
+ <para>128</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Effect if unset:</term>
+ <listitem>
+ <para>
+ Connections are served until a resource limit is reached.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Notes:</term>
+ <listitem>
+ <para>
+ &my-app; creates one thread (or process) for every incoming client
+ connection that isn't rejected based on the access control settings.
+ </para>
+ <para>
+ 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.
+ </para>
+ <para>
+ 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;.
+ </para>
+ <para>
+ 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;.
+ </para>
+ <para>
+ Obviously using this option only makes sense if you choose a limit
+ below the one enforced by the operating system.
+ </para>
+ <para>
+ One most POSIX-compliant systems &my-app; 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 &my-app; with a different FD_SETSIZE limit.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Examples:</term>
+ <listitem>
+ <para>
+ max-client-connections 256
+ </para>
+ </listitem>
+ </varlistentry>
+</variablelist>
+<![%config-file;[<literallayout>@@#max-client-connections 256</literallayout>]]>
+</sect3>
+
+
+<sect3 renderas="sect4" id="handle-as-empty-doc-returns-ok"><title>handle-as-empty-doc-returns-ok</title>
+<variablelist>
+ <varlistentry>
+ <term>Specifies:</term>
+ <listitem>
+ <para>
+ The status code Privoxy returns for pages blocked with
+ <!-- URL will only end up in the user manual so the relative link should work. -->
+ <literal><ulink url="actions-file.html#HANDLE-AS-EMPTY-DOCUMENT">+handle-as-empty-document</ulink></literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Type of value:</term>
+ <listitem>
+ <para>
+ <replaceable>0 or 1</replaceable>
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Default value:</term>
+ <listitem>
+ <para>0</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Effect if unset:</term>
+ <listitem>
+ <para>
+ Privoxy returns a status 403(forbidden) for all blocked pages.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Effect if set:</term>
+ <listitem>
+ <para>
+ Privoxy returns a status 200(OK) for pages blocked with +handle-as-empty-document
+ and a status 403(Forbidden) for all other blocked pages.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Notes:</term>
+ <listitem>
+ <para>
+ This is a work-around for Firefox bug 492459:
+ <quote>
+ Websites are no longer rendered if SSL requests for JavaScripts are blocked by a proxy.
+ </quote>
+ (<ulink url="https://bugzilla.mozilla.org/show_bug.cgi?id=492459"
+ >https://bugzilla.mozilla.org/show_bug.cgi?id=492459</ulink>)
+ 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.
+ </para>
+ </listitem>
+ </varlistentry>
+</variablelist>
+<![%config-file;[<literallayout>@@#handle-as-empty-doc-returns-ok 1</literallayout>]]>
+</sect3>
+
+
+<sect3 renderas="sect4" id="enable-compression"><title>enable-compression</title>
+<variablelist>
+ <varlistentry>
+ <term>Specifies:</term>
+ <listitem>
+ <para>
+ Whether or not buffered content is compressed before delivery.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Type of value:</term>
+ <listitem>
+ <para>
+ <replaceable>0 or 1</replaceable>
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Default value:</term>
+ <listitem>
+ <para>0</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Effect if unset:</term>
+ <listitem>
+ <para>
+ Privoxy does not compress buffered content.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Effect if set:</term>
+ <listitem>
+ <para>
+ Privoxy compresses buffered content before delivering it to the client,
+ provided the client supports it.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Notes:</term>
+ <listitem>
+ <para>
+ This directive is only supported if Privoxy has been compiled with
+ FEATURE_COMPRESSION, which should not to be confused with FEATURE_ZLIB.
+ </para>
+ <para>
+ Compressing buffered content is mainly useful if Privoxy and the
+ client are running on different systems. If they are running on the
+ same system, enabling compression is likely to slow things down.
+ If you didn't measure otherwise, you should assume that it does
+ and keep this option disabled.
+ </para>
+ <para>
+ Privoxy will not compress buffered content below a certain length.
+ </para>
+ </listitem>
+ </varlistentry>
+</variablelist>
+<![%config-file;[<literallayout>@@#enable-compression 1</literallayout>]]>
+</sect3>
+
+
+<sect3 renderas="sect4" id="compression-level"><title>compression-level</title>
+<variablelist>
+ <varlistentry>
+ <term>Specifies:</term>
+ <listitem>
+ <para>
+ The compression level that is passed to the zlib library when compressing buffered content.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Type of value:</term>
+ <listitem>
+ <para>
+ <replaceable>Positive number ranging from 0 to 9.</replaceable>
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Default value:</term>
+ <listitem>
+ <para>1</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Notes:</term>
+ <listitem>
+ <para>
+ Compressing the data more takes usually longer than compressing
+ it less or not compressing it at all. Which level is best depends
+ on the connection between Privoxy and the client. If you can't
+ be bothered to benchmark it for yourself, you should stick with
+ the default and keep compression disabled.
+ </para>
+ <para>
+ If compression is disabled, the compression level is irrelevant.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Examples:</term>
+ <listitem>
+ <para>
+ <screen>
+ # Best speed (compared to the other levels)
+ compression-level 1
+ # Best compression
+ compression-level 9
+ # No compression. Only useful for testing as the added header
+ # slightly increases the amount of data that has to be sent.
+ # If your benchmark shows that using this compression level
+ # is superior to using no compression at all, the benchmark
+ # is likely to be flawed.
+ compression-level 0
+ </screen>
+ </para>
+ </listitem>
+ </varlistentry>
+</variablelist>
+<![%config-file;[<literallayout>@@#compression-level 1</literallayout>]]>
+</sect3>
+
+
+<sect3 renderas="sect4" id="client-header-order"><title>client-header-order</title>
+<variablelist>
+ <varlistentry>
+ <term>Specifies:</term>
+ <listitem>
+ <para>
+ The order in which client headers are sorted before forwarding them.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Type of value:</term>
+ <listitem>
+ <para>
+ <replaceable>Client header names delimited by spaces or tabs</replaceable>
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Default value:</term>
+ <listitem>
+ <para>None</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Notes:</term>
+ <listitem>
+ <para>
+ By default &my-app; 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.
+ </para>
+ <para>
+ The header order can be used to fingerprint client requests
+ independently of other headers like the User-Agent.
+ </para>
+ <para>
+ 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.
+ </para>
+ <para>
+ Note that sorting headers in an uncommon way will make fingerprinting
+ actually easier. Encrypted headers are not affected by this directive.
+ </para>
+ </listitem>
+ </varlistentry>
+</variablelist>
+<![%config-file;[<literallayout>@@#client-header-order Host \
+ User-Agent \
+ Accept \
+ Accept-Language \
+ Accept-Encoding \
+ Proxy-Connection \
+ Referer \
+ Cookie \
+ DNT \
+ If-Modified-Since \
+ Cache-Control \
+ Content-Length \
+ Content-Type
+</literallayout>]]>
+</sect3>
+
+