+>None</P
+></DD
+><DT
+>Effect if unset:</DT
+><DD
+><P
+> A default value of 300 seconds is used.
+ </P
+></DD
+><DT
+>Notes:</DT
+><DD
+><P
+> The default is quite high and you probably want to reduce it.
+ If you aren't using an occasionally slow proxy like Tor, reducing
+ it to a few seconds should be fine.
+ </P
+></DD
+><DT
+>Examples:</DT
+><DD
+><P
+> socket-timeout 300
+ </P
+></DD
+></DL
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><H4
+CLASS="SECT3"
+><A
+NAME="MAX-CLIENT-CONNECTIONS"
+>7.6.9. max-client-connections</A
+></H4
+><P
+></P
+><DIV
+CLASS="VARIABLELIST"
+><DL
+><DT
+>Specifies:</DT
+><DD
+><P
+> Maximum number of client connections that will be served.
+ </P
+></DD
+><DT
+>Type of value:</DT
+><DD
+><P
+> <TT
+CLASS="REPLACEABLE"
+><I
+>Positive number.</I
+></TT
+>
+ </P
+></DD
+><DT
+>Default value:</DT
+><DD
+><P
+>128</P
+></DD
+><DT
+>Effect if unset:</DT
+><DD
+><P
+> Connections are served until a resource limit is reached.
+ </P
+></DD
+><DT
+>Notes:</DT
+><DD
+><P
+> <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> creates one thread (or process) for every incoming client
+ connection that isn't rejected based on the access control settings.
+ </P
+><P
+> If the system is powerful enough, <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> 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 <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> would
+ require under heavy load.
+ </P
+><P
+> Configuring <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> 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 <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> isn't the only application running on the system,
+ you may actually want to limit the resources used by <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+>.
+ </P
+><P
+> If <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> 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 <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+>.
+ </P
+><P
+> Obviously using this option only makes sense if you choose a limit
+ below the one enforced by the operating system.
+ </P
+><P
+> One most POSIX-compliant systems <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> 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 <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> with a different FD_SETSIZE limit.
+ </P
+></DD
+><DT
+>Examples:</DT
+><DD
+><P
+> max-client-connections 256
+ </P
+></DD
+></DL
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><H4
+CLASS="SECT3"
+><A
+NAME="LISTEN-BACKLOG"
+>7.6.10. listen-backlog</A
+></H4
+><P
+></P
+><DIV
+CLASS="VARIABLELIST"
+><DL
+><DT
+>Specifies:</DT
+><DD
+><P
+> Connection queue length requested from the operating system.
+ </P
+></DD
+><DT
+>Type of value:</DT
+><DD
+><P
+> <TT
+CLASS="REPLACEABLE"
+><I
+>Number.</I
+></TT
+>
+ </P
+></DD
+><DT
+>Default value:</DT
+><DD
+><P
+>128</P
+></DD
+><DT
+>Effect if unset:</DT
+><DD
+><P
+> A connection queue length of 128 is requested from the operating system.
+ </P
+></DD
+><DT
+>Notes:</DT
+><DD
+><P
+> Under high load incoming connection may queue up before Privoxy
+ gets around to serve them. The queue length is limitted by the
+ operating system. Once the queue is full, additional connections
+ are dropped before Privoxy can accept and serve them.
+ </P
+><P
+> Increasing the queue length allows Privoxy to accept more
+ incomming connections that arrive roughly at the same time.
+ </P
+><P
+> Note that Privoxy can only request a certain queue length,
+ whether or not the requested length is actually used depends
+ on the operating system which may use a different length instead.
+ </P
+><P
+> On many operating systems a limit of -1 can be specified to
+ instruct the operating system to use the maximum queue length
+ allowed. Check the listen man page to see if your platform allows this.
+ </P
+><P
+> On some platforms you can use "netstat -Lan -p tcp" to see the effective
+ queue length.
+ </P
+><P
+> Effectively using a value above 128 usually requires changing
+ the system configuration as well. On FreeBSD-based system the
+ limit is controlled by the kern.ipc.soacceptqueue sysctl.
+ </P
+></DD
+><DT
+>Examples:</DT
+><DD
+><P
+> listen-backlog 4096
+ </P
+></DD
+></DL
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><H4
+CLASS="SECT3"
+><A
+NAME="ENABLE-ACCEPT-FILTER"
+>7.6.11. enable-accept-filter</A
+></H4
+><P
+></P
+><DIV
+CLASS="VARIABLELIST"
+><DL
+><DT
+>Specifies:</DT
+><DD
+><P
+> Whether or not Privoxy should use an accept filter
+ </P
+></DD
+><DT
+>Type of value:</DT
+><DD
+><P
+> <TT
+CLASS="REPLACEABLE"
+><I
+>0 or 1</I
+></TT
+>
+ </P
+></DD
+><DT
+>Default value:</DT
+><DD
+><P
+>0</P
+></DD
+><DT
+>Effect if unset:</DT
+><DD
+><P
+> No accept filter is enabled.
+ </P
+></DD
+><DT
+>Notes:</DT
+><DD
+><P
+> Accept filters reduce the number of context switches by not
+ passing sockets for new connections to Privoxy until a complete
+ HTTP request is available.
+ </P
+><P
+> As a result, Privoxy can process the whole request right away
+ without having to wait for additional data first.
+ </P
+><P
+> For this option to work, Privoxy has to be compiled with
+ FEATURE_ACCEPT_FILTER and the operating system has to support
+ it (which may require loading a kernel module).
+ </P
+><P
+> Currently accept filters are only supported on FreeBSD-based
+ systems. Check the
+ <A
+HREF="https://www.freebsd.org/cgi/man.cgi?query=accf_http"
+TARGET="_top"
+>accf_http(9)
+ man page</A
+>
+ to learn how to enable the support in the operating system.
+ </P
+></DD
+><DT
+>Examples:</DT
+><DD
+><P
+> enable-accept-filter 1
+ </P
+></DD
+></DL
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><H4
+CLASS="SECT3"
+><A
+NAME="HANDLE-AS-EMPTY-DOC-RETURNS-OK"
+>7.6.12. handle-as-empty-doc-returns-ok</A
+></H4
+><P
+></P
+><DIV
+CLASS="VARIABLELIST"
+><DL
+><DT
+>Specifies:</DT
+><DD
+><P
+> The status code Privoxy returns for pages blocked with
+
+ <TT
+CLASS="LITERAL"
+><A
+HREF="actions-file.html#HANDLE-AS-EMPTY-DOCUMENT"
+TARGET="_top"
+>+handle-as-empty-document</A
+></TT
+>.
+ </P
+></DD
+><DT
+>Type of value:</DT
+><DD
+><P
+> <TT
+CLASS="REPLACEABLE"
+><I
+>0 or 1</I
+></TT
+>
+ </P
+></DD
+><DT
+>Default value:</DT
+><DD
+><P
+>0</P
+></DD
+><DT
+>Effect if unset:</DT
+><DD
+><P
+> Privoxy returns a status 403(forbidden) for all blocked pages.
+ </P
+></DD
+><DT
+>Effect if set:</DT
+><DD
+><P
+> Privoxy returns a status 200(OK) for pages blocked with +handle-as-empty-document
+ and a status 403(Forbidden) for all other blocked pages.
+ </P
+></DD
+><DT
+>Notes:</DT
+><DD
+><P
+> This directive was added as a work-around for Firefox bug 492459:
+ <SPAN
+CLASS="QUOTE"
+>"Websites are no longer rendered if SSL requests for JavaScripts are blocked by a proxy."</SPAN
+>
+ (<A
+HREF="https://bugzilla.mozilla.org/show_bug.cgi?id=492459"
+TARGET="_top"
+> https://bugzilla.mozilla.org/show_bug.cgi?id=492459</A
+>),
+ 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.
+ </P
+></DD
+></DL
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><H4
+CLASS="SECT3"
+><A
+NAME="ENABLE-COMPRESSION"
+>7.6.13. enable-compression</A
+></H4
+><P
+></P
+><DIV
+CLASS="VARIABLELIST"
+><DL
+><DT
+>Specifies:</DT
+><DD
+><P
+> Whether or not buffered content is compressed before delivery.
+ </P
+></DD
+><DT
+>Type of value:</DT
+><DD
+><P
+> <TT
+CLASS="REPLACEABLE"
+><I
+>0 or 1</I
+></TT
+>
+ </P
+></DD
+><DT
+>Default value:</DT
+><DD
+><P
+>0</P
+></DD
+><DT
+>Effect if unset:</DT
+><DD
+><P
+> Privoxy does not compress buffered content.
+ </P
+></DD
+><DT
+>Effect if set:</DT
+><DD
+><P
+> Privoxy compresses buffered content before delivering it to the client,
+ provided the client supports it.
+ </P
+></DD
+><DT
+>Notes:</DT
+><DD
+><P
+> This directive is only supported if Privoxy has been compiled with
+ FEATURE_COMPRESSION, which should not to be confused with FEATURE_ZLIB.
+ </P
+><P
+> 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.
+ </P
+><P
+> Privoxy will not compress buffered content below a certain length.
+ </P
+></DD
+></DL
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><H4
+CLASS="SECT3"
+><A
+NAME="COMPRESSION-LEVEL"
+>7.6.14. compression-level</A
+></H4
+><P
+></P
+><DIV
+CLASS="VARIABLELIST"
+><DL
+><DT
+>Specifies:</DT
+><DD
+><P
+> The compression level that is passed to the zlib library when compressing buffered content.
+ </P
+></DD
+><DT
+>Type of value:</DT
+><DD
+><P
+> <TT
+CLASS="REPLACEABLE"
+><I
+>Positive number ranging from 0 to 9.</I
+></TT
+>
+ </P
+></DD
+><DT
+>Default value:</DT
+><DD
+><P
+>1</P
+></DD
+><DT
+>Notes:</DT
+><DD
+><P
+> 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.
+ </P
+><P
+> If compression is disabled, the compression level is irrelevant.
+ </P
+></DD
+><DT
+>Examples:</DT
+><DD
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="90%"
+><TR
+><TD
+><PRE
+CLASS="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</PRE
+></TD
+></TR
+></TABLE
+></DD
+></DL
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><H4
+CLASS="SECT3"
+><A
+NAME="CLIENT-HEADER-ORDER"
+>7.6.15. client-header-order</A
+></H4
+><P
+></P
+><DIV
+CLASS="VARIABLELIST"
+><DL
+><DT
+>Specifies:</DT
+><DD
+><P
+> The order in which client headers are sorted before forwarding them.
+ </P
+></DD
+><DT
+>Type of value:</DT
+><DD
+><P
+> <TT
+CLASS="REPLACEABLE"
+><I
+>Client header names delimited by spaces or tabs</I
+></TT
+>
+ </P
+></DD
+><DT
+>Default value:</DT
+><DD
+><P
+>None</P
+></DD
+><DT
+>Notes:</DT
+><DD
+><P
+> By default <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> 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.
+ </P
+><P
+> The header order can be used to fingerprint client requests
+ independently of other headers like the User-Agent.
+ </P
+><P
+> 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.
+ </P
+><P
+> Note that sorting headers in an uncommon way will make fingerprinting
+ actually easier. Encrypted headers are not affected by this directive.
+ </P
+></DD
+></DL
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><H4
+CLASS="SECT3"
+><A
+NAME="CLIENT-SPECIFIC-TAG"
+>7.6.16. client-specific-tag</A
+></H4
+><P
+></P
+><DIV
+CLASS="VARIABLELIST"
+><DL
+><DT
+>Specifies:</DT
+><DD
+><P
+> The name of a tag that will always be set for clients that
+ requested it through the webinterface.
+ </P
+></DD
+><DT
+>Type of value:</DT
+><DD
+><P
+> <TT
+CLASS="REPLACEABLE"
+><I
+>Tag name followed by a description that will be shown in the webinterface</I
+></TT
+>
+ </P
+></DD
+><DT
+>Default value:</DT
+><DD
+><P
+>None</P
+></DD
+><DT
+>Notes:</DT
+><DD
+><DIV
+CLASS="WARNING"
+><P
+></P
+><TABLE
+CLASS="WARNING"
+BORDER="1"
+WIDTH="90%"
+><TR
+><TD
+ALIGN="CENTER"
+><B
+>Warning</B
+></TD
+></TR
+><TR
+><TD
+ALIGN="LEFT"
+><P
+> This is an experimental feature. The syntax is likely to change
+ in future versions.
+ </P
+></TD
+></TR
+></TABLE
+></DIV
+><P
+> Client-specific tags allow Privoxy admins to create different
+ profiles and let the users chose which one they want without
+ impacting other users.
+ </P
+><P
+> 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
+ <A
+HREF="config.html#ENABLE-REMOTE-TOGGLE"
+>enable-remote-toggle feature</A
+>
+ 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.
+ </P
+><P
+> 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
+ <A
+HREF="actions-file.html#CLIENT-TAG-PATTERN"
+TARGET="_top"
+>CLIENT-TAG</A
+> 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!
+ </P
+><P
+> 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.
+ </P
+><P
+> Clients can request tags to be set by using the CGI interface <A
+HREF="http://config.privoxy.org/client-tags"
+TARGET="_top"
+>http://config.privoxy.org/client-tags</A
+>.
+ 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.
+ </P
+></DD
+><DT
+>Examples:</DT
+><DD
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="90%"
+><TR
+><TD
+><PRE
+CLASS="SCREEN"
+> # 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</PRE
+></TD
+></TR
+></TABLE
+></DD
+></DL
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><H4
+CLASS="SECT3"
+><A
+NAME="CLIENT-TAG-LIFETIME"
+>7.6.17. client-tag-lifetime</A
+></H4
+><P
+></P
+><DIV
+CLASS="VARIABLELIST"
+><DL
+><DT
+>Specifies:</DT
+><DD
+><P
+> How long a temporarily enabled tag remains enabled.
+ </P
+></DD
+><DT
+>Type of value:</DT
+><DD
+><P
+> <TT
+CLASS="REPLACEABLE"
+><I
+>Time in seconds.</I
+></TT
+>
+ </P
+></DD
+><DT
+>Default value:</DT
+><DD
+><P
+>60</P