This file belongs into
ijbswa.sourceforge.net:/home/groups/i/ij/ijbswa/htdocs/
- $Id: user-manual.sgml,v 2.148 2012/03/18 15:41:49 fabiankeil Exp $
+ $Id: user-manual.sgml,v 2.153 2012/11/09 10:49:59 fabiankeil Exp $
Copyright (C) 2001-2011 Privoxy Developers http://www.privoxy.org/
See LICENSE.
</subscript>
</pubdate>
-<pubdate>$Id: user-manual.sgml,v 2.148 2012/03/18 15:41:49 fabiankeil Exp $</pubdate>
+<pubdate>$Id: user-manual.sgml,v 2.153 2012/11/09 10:49:59 fabiankeil Exp $</pubdate>
<!--
<para>
<itemizedlist>
+ <listitem>
+ <para>
+ <emphasis>--config-test</emphasis>
+ </para>
+ <para>
+ Exit after loading the configuration files before binding to
+ the listen address. The exit code signals whether or not the
+ configuration files have been successfully loaded.
+ </para>
+ <para>
+ If the exit code is 1, at least one of the configuration files
+ is invalid, if it is 0, all the configuration files have been
+ successfully loaded (but may still contain errors that can
+ currently only be detected at run time).
+ </para>
+ <para>
+ This option doesn't affect the log setting, combination with
+ <emphasis>--no-daemon</emphasis> is recommended if a configured
+ log file shouldn't be used.
+ </para>
+ </listitem>
<listitem>
<para>
<emphasis>--version</emphasis>
and use their output as input.
</para>
<para>
- If the request URL gets changed, &my-app; will detect that and use the new
+ If the request URI gets changed, &my-app; will detect that and use the new
one. This can be used to rewrite the request destination behind the client's
back, for example to specify a Tor exit relay for certain requests.
</para>
</variablelist>
</sect3>
+
+<!-- ~~~~~ New section ~~~~~ -->
+<sect3 renderas="sect4" id="limit-cookie-lifetime">
+<title>limit-cookie-lifetime</title>
+
+<variablelist>
+ <varlistentry>
+ <term>Typical use:</term>
+ <listitem>
+ <para>Limit the lifetime of HTTP cookies to a couple of minutes or hours.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Effect:</term>
+ <listitem>
+ <para>
+ Overwrites the expires field in Set-Cookie server headers if it's above the specified limit.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Type:</term>
+ <!-- Boolean, Parameterized, Multi-value -->
+ <listitem>
+ <para>Parameterized.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Parameter:</term>
+ <listitem>
+ <para>
+ The lifetime limit in minutes, or 0.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Notes:</term>
+ <listitem>
+ <para>
+ This action reduces the lifetime of HTTP cookies coming from the
+ server to the specified number of minutes, starting from the time
+ the cookie passes Privoxy.
+ </para>
+ <para>
+ Cookies with a lifetime below the limit are not modified.
+ The lifetime of session cookies is set to the specified limit.
+ </para>
+ <para>
+ The effect of this action depends on the server.
+ </para>
+ <para>
+ In case of servers which refresh their cookies with each response
+ (or at least frequently), the lifetime limit set by this action
+ is updated as well.
+ Thus, a session associated with the cookie continues to work with
+ this action enabled, as long as a new request is made before the
+ last limit set is reached.
+ </para>
+ <para>
+ However, some servers send their cookies once, with a lifetime of several
+ years (the year 2037 is a popular choice), and do not refresh them
+ until a certain event in the future, for example the user logging out.
+ In this case this action may limit the absolute lifetime of the session,
+ even if requests are made frequently.
+ </para>
+ <para>
+ If the parameter is <quote>0</quote>, this action behaves like
+ <literal><link linkend="session-cookies-only">session-cookies-only</link></literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Example usages:</term>
+ <listitem>
+ <para>
+ <screen>+limit-cookie-lifetime{60}
+ </screen>
+ </para>
+ </listitem>
+ </varlistentry>
+</variablelist>
+</sect3>
+
<!-- ~~~~~ New section ~~~~~ -->
<sect3 renderas="sect4" id="prevent-compression">
<title>prevent-compression</title>
either provided as parameter, or derived by applying a
single pcrs command to the original URL.
</para>
+ <para>
+ The syntax for pcrs commands is documented in the
+ <link linkend="filter-file">filter file</link> section.
+ </para>
<para>
This action will be ignored if you use it together with
<literal><link linkend="block">block</link></literal>.
</varlistentry>
<varlistentry>
- <term><emphasis>refresh tags</emphasis></term>
+ <term><emphasis>refresh-tags</emphasis></term>
<listitem>
<para>
Disable any refresh tags if the interval is greater than nine seconds (so
USA
$Log: user-manual.sgml,v $
+ Revision 2.153 2012/11/09 10:49:59 fabiankeil
+ Document --config-test option
+
+ Revision 2.152 2012/10/29 12:02:55 fabiankeil
+ Clarify that the destination-change detection works for intercepted requests as well
+
+ For some values of "clarify".
+
+ Revision 2.151 2012/10/21 12:31:59 fabiankeil
+ In the redirect{} section, refer pcrs newbies to the 'filter file' section
+
+ Revision 2.150 2012/09/26 15:20:54 fabiankeil
+ Spell 'refresh-tags' correctly
+
+ Reported by Don in #3571927.
+
+ Revision 2.149 2012/04/22 12:15:53 fabiankeil
+ Use another client-header-tagger{} example: disable filtering for range requests
+
Revision 2.148 2012/03/18 15:41:49 fabiankeil
Bump entities to 3.0.20 UNRELEASED
projects / privoxy.git / blobdiff