+ </pre>
+ </td>
+ </tr>
+ </table>
+ </dd>
+ </dl>
+ </div>
+ </div>
+ <div class="SECT3">
+ <h4 class="SECT3"><a name="CLIENT-HEADER-ORDER" id=
+ "CLIENT-HEADER-ORDER">7.6.14. client-header-order</a></h4>
+ <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" id=
+ "CLIENT-SPECIFIC-TAG">7.6.15. client-specific-tag</a></h4>
+ <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">
+ <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" id=
+ "CLIENT-TAG-LIFETIME">7.6.16. client-tag-lifetime</a></h4>
+ <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>
+ </dd>
+ <dt>Notes:</dt>
+ <dd>
+ <div class="WARNING">
+ <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>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.</p>
+ <p>The CGI interface <a href=
+ "http://config.privoxy.org/client-tags" target=
+ "_top">http://config.privoxy.org/client-tags</a> therefore
+ provides a "enable this tag temporarily" option. If it is used,
+ the tag will be set until the client-tag-lifetime is over.</p>
+ </dd>
+ <dt>Examples:</dt>
+ <dd>
+ <table border="0" bgcolor="#E0E0E0" width="90%">
+ <tr>
+ <td>
+ <pre class="SCREEN">
+ # Increase the time to life for temporarily enabled tags to 3 minutes
+ client-tag-lifetime 180
+ </pre>
+ </td>
+ </tr>
+ </table>
+ </dd>
+ </dl>
+ </div>
+ </div>
+ <div class="SECT3">
+ <h4 class="SECT3"><a name="TRUST-X-FORWARDED-FOR" id=
+ "TRUST-X-FORWARDED-FOR">7.6.17. trust-x-forwarded-for</a></h4>
+ <div class="VARIABLELIST">
+ <dl>
+ <dt>Specifies:</dt>
+ <dd>
+ <p>Whether or not Privoxy should use IP addresses specified
+ with the X-Forwarded-For header</p>
+ </dd>
+ <dt>Type of value:</dt>
+ <dd>
+ <p><tt class="REPLACEABLE"><i>0 or one</i></tt></p>
+ </dd>
+ <dt>Default value:</dt>
+ <dd>
+ <p>0</p>
+ </dd>
+ <dt>Notes:</dt>
+ <dd>
+ <div class="WARNING">
+ <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>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.</p>
+ <p>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.</p>
+ <p>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.</p>
+ <p>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.</p>
+ </dd>
+ <dt>Examples:</dt>
+ <dd>
+ <table border="0" bgcolor="#E0E0E0" width="90%">
+ <tr>
+ <td>
+ <pre class="SCREEN">
+ # Allow systems that can reach Privoxy to provide the client
+ # IP address with a X-Forwarded-For header.
+ trust-x-forwarded-for 1
+ </pre>
+ </td>
+ </tr>
+ </table>
+ </dd>
+ </dl>
+ </div>
+ </div>
+ <div class="SECT3">
+ <h4 class="SECT3"><a name="RECEIVE-BUFFER-SIZE" id=
+ "RECEIVE-BUFFER-SIZE">7.6.18. receive-buffer-size</a></h4>
+ <div class="VARIABLELIST">
+ <dl>
+ <dt>Specifies:</dt>
+ <dd>
+ <p>The size of the buffer Privoxy uses to receive data from the
+ server.</p>
+ </dd>
+ <dt>Type of value:</dt>
+ <dd>
+ <p><tt class="REPLACEABLE"><i>Size in bytes</i></tt></p>
+ </dd>
+ <dt>Default value:</dt>
+ <dd>
+ <p>5000</p>
+ </dd>
+ <dt>Notes:</dt>
+ <dd>
+ <p>Increasing the receive-buffer-size increases Privoxy's
+ memory usage but can lower the number of context switches and
+ thereby reduce the cpu usage and potentially increase the
+ throughput.</p>
+ <p>This is mostly relevant for fast network connections and
+ large downloads that don't require filtering.</p>
+ <p>Reducing the buffer size reduces the amount of memory
+ Privoxy needs to handle the request but increases the number of
+ systemcalls and may reduce the throughput.</p>
+ <p>A dtrace command like: <span class="QUOTE">"sudo dtrace -n
+ 'syscall::read:return /execname == "privoxy"/ { @[execname] =
+ llquantize(arg0, 10, 0, 5, 20); @m = max(arg0)}'"</span> can be
+ used to properly tune the receive-buffer-size. On systems
+ without dtrace, strace or truss may be used as less convenient
+ alternatives.</p>
+ <p>If the buffer is too large it will increase Privoxy's memory
+ footprint without any benefit. As the memory is (currently)
+ cleared before using it, a buffer that is too large can
+ actually reduce the throughput.</p>
+ </dd>
+ <dt>Examples:</dt>
+ <dd>
+ <table border="0" bgcolor="#E0E0E0" width="90%">
+ <tr>
+ <td>
+ <pre class="SCREEN">
+ # Increase the receive buffer size
+ receive-buffer-size 32768
+ </pre>