Hopefully the final rebuilt for 3.0.16 stable ...
[privoxy.git] / doc / webserver / user-manual / config.html
index 2562be5..6e27789 100644 (file)
@@ -7,7 +7,7 @@
 NAME="GENERATOR"
 CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
 REL="HOME"
-TITLE="Privoxy 3.0.13 User Manual"
+TITLE="Privoxy 3.0.16 User Manual"
 HREF="index.html"><LINK
 REL="PREVIOUS"
 TITLE="Privoxy Configuration"
@@ -42,7 +42,7 @@ CELLSPACING="0"
 ><TH
 COLSPAN="3"
 ALIGN="center"
->Privoxy 3.0.13 User Manual</TH
+>Privoxy 3.0.16 User Manual</TH
 ></TR
 ><TR
 ><TD
@@ -137,7 +137,9 @@ CLASS="APPLICATION"
 >Privoxy</SPAN
 >'s
  operation that are not location dependent (i.e. they apply universally, no matter
- where you may be surfing).</P
+ where you may be surfing). Like the filter and action files, the config file is
+ a plain text file and can be modified with a text editor like emacs, vim or
+ notepad.exe.</P
 ><DIV
 CLASS="SECT2"
 ><H2
@@ -1695,12 +1697,7 @@ CLASS="APPLICATION"
 HREF="config.html#ACLS"
 >access control lists</A
 > (ACL's, see below), and/or
-    a firewall. If the hostname is localhost, <SPAN
-CLASS="APPLICATION"
->Privoxy</SPAN
->
-    will explicitly try to bind to an IPv4 address. For other hostnames it depends
-    on the operating system which IP version will be used.
+    a firewall.
    </P
 ><P
 >    If you open <SPAN
@@ -3570,6 +3567,10 @@ CLASS="QUOTE"
     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.
    </P
+><P
+>    Due to a bug, this option currently also causes Privoxy to
+    retry in case of certain problems with direct connections.
+   </P
 ></DD
 ><DT
 >Examples:</DT
@@ -3581,13 +3582,22 @@ CLASS="QUOTE"
 ></DL
 ></DIV
 ></DIV
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="MISC"
+>7.6. Miscellaneous</A
+></H2
 ><DIV
 CLASS="SECT3"
 ><H4
 CLASS="SECT3"
 ><A
 NAME="ACCEPT-INTERCEPTED-REQUESTS"
->7.5.5. accept-intercepted-requests</A
+>7.6.1. accept-intercepted-requests</A
 ></H4
 ><P
 ></P
@@ -3681,7 +3691,7 @@ CLASS="SECT3"
 CLASS="SECT3"
 ><A
 NAME="ALLOW-CGI-REQUEST-CRUNCHING"
->7.5.6. allow-cgi-request-crunching</A
+>7.6.2. allow-cgi-request-crunching</A
 ></H4
 ><P
 ></P
@@ -3764,7 +3774,7 @@ CLASS="SECT3"
 CLASS="SECT3"
 ><A
 NAME="SPLIT-LARGE-FORMS"
->7.5.7. split-large-forms</A
+>7.6.3. split-large-forms</A
 ></H4
 ><P
 ></P
@@ -3853,7 +3863,7 @@ CLASS="SECT3"
 CLASS="SECT3"
 ><A
 NAME="KEEP-ALIVE-TIMEOUT"
->7.5.8. keep-alive-timeout</A
+>7.6.4. keep-alive-timeout</A
 ></H4
 ><P
 ></P
@@ -3889,13 +3899,169 @@ CLASS="REPLACEABLE"
 >Effect if unset:</DT
 ><DD
 ><P
->    Connections are not reused.
+>    Connections are not kept alive.
+   </P
+></DD
+><DT
+>Notes:</DT
+><DD
+><P
+>    This option allows clients to keep the connection to <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+>
+    alive. If the server supports it, <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> will keep
+    the connection to the server alive as well. Under certain
+    circumstances this may result in speed-ups.
+   </P
+><P
+>    By default, <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> 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 <A
+HREF="#CONNECTION-SHARING"
+TARGET="_top"
+>connection-sharing</A
+> option.
+   </P
+><P
+>    This option has no effect if <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+>
+    has been compiled without keep-alive support.
+   </P
+><P
+>    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 <SPAN
+CLASS="QUOTE"
+>"grabbing"</SPAN
+> all the
+    connections the browser allows, which means connections to
+    other websites can't be opened until the connections currently
+    in use time out.
+   </P
+><P
+>    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.
+   </P
+></DD
+><DT
+>Examples:</DT
+><DD
+><P
+>    keep-alive-timeout 300
+   </P
+></DD
+></DL
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><H4
+CLASS="SECT3"
+><A
+NAME="DEFAULT-SERVER-TIMEOUT"
+>7.6.5. default-server-timeout</A
+></H4
+><P
+></P
+><DIV
+CLASS="VARIABLELIST"
+><DL
+><DT
+>Specifies:</DT
+><DD
+><P
+>    Assumed server-side keep-alive timeout if not specified by the server.
+   </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
+>None</P
+></DD
+><DT
+>Effect if unset:</DT
+><DD
+><P
+>    Connections for which the server didn't specify the keep-alive
+    timeout are not reused.
    </P
 ></DD
 ><DT
 >Notes:</DT
 ><DD
 ><P
+>    Enabling this option significantly increases the number of connections
+    that are reused, provided the <A
+HREF="#KEEP-ALIVE-TIMEOUT"
+TARGET="_top"
+>keep-alive-timeout</A
+> option
+    is also enabled.
+   </P
+><P
+>    While it also increases the number of connections problems
+    when <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> tries to reuse a connection that already has
+    been closed on the server side, or is closed while <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+>
+    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, <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> will simply
+    close the connection and the client is supposed to retry the
+    request without bothering the user.
+   </P
+><P
+>    Enabling this option is therefore only recommended if the
+    <A
+HREF="#CONNECTION-SHARING"
+TARGET="_top"
+>connection-sharing</A
+> option
+    is disabled.
+   </P
+><P
+>    It is an error to specify a value larger than the <A
+HREF="#KEEP-ALIVE-TIMEOUT"
+TARGET="_top"
+>keep-alive-timeout</A
+> value.
+   </P
+><P
 >    This option has no effect if <SPAN
 CLASS="APPLICATION"
 >Privoxy</SPAN
@@ -3904,6 +4070,73 @@ CLASS="APPLICATION"
    </P
 ></DD
 ><DT
+>Examples:</DT
+><DD
+><P
+>    default-server-timeout 60
+   </P
+></DD
+></DL
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><H4
+CLASS="SECT3"
+><A
+NAME="CONNECTION-SHARING"
+>7.6.6. connection-sharing</A
+></H4
+><P
+></P
+><DIV
+CLASS="VARIABLELIST"
+><DL
+><DT
+>Specifies:</DT
+><DD
+><P
+>    Whether or not outgoing connections that have been kept alive
+    should be shared between different incoming connections.
+   </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
+>None</P
+></DD
+><DT
+>Effect if unset:</DT
+><DD
+><P
+>    Connections are not shared.
+   </P
+></DD
+><DT
+>Notes:</DT
+><DD
+><P
+>    This option has no effect if <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+>
+    has been compiled without keep-alive support, or if it's disabled.
+   </P
+></DD
+><DT
 >Notes:</DT
 ><DD
 ><P
@@ -3911,29 +4144,58 @@ CLASS="APPLICATION"
     There are also a few privacy implications you should be aware of.
    </P
 ><P
->    Outgoing connections are shared between clients (if there are more
-    than one) and closing the client that initiated the outgoing connection
-    does not affect the connection between <SPAN
+>    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 <SPAN
 CLASS="APPLICATION"
 >Privoxy</SPAN
-> 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 <SPAN
+>
+    and the server unless the client's request hasn't been completed yet.
+   </P
+><P
+>    If the outgoing connection  is idle, it will not be closed until either
+    <SPAN
 CLASS="APPLICATION"
 >Privoxy's</SPAN
->
-    or the server's timeout is reached. While it's open, the server knows
-    that the system running <SPAN
+> or the server's timeout is reached.
+    While it's open, the server knows that the system running <SPAN
 CLASS="APPLICATION"
 >Privoxy</SPAN
-> is still there.
+> is still
+    there.
+   </P
+><P
+>    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.
+   </P
+><P
+>    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 <SPAN
+CLASS="APPLICATION"
+>Privoxy</SPAN
+> to keep outgoing connections alive even if the client
+    itself doesn't support it.
+   </P
+><P
+>    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.
+   </P
+><P
+>    This option should only be used by experienced users who
+    understand the risks and can weight them against the benefits.
    </P
 ></DD
 ><DT
 >Examples:</DT
 ><DD
 ><P
->    keep-alive-timeout 300
+>    connection-sharing 1
    </P
 ></DD
 ></DL
@@ -3945,7 +4207,7 @@ CLASS="SECT3"
 CLASS="SECT3"
 ><A
 NAME="SOCKET-TIMEOUT"
->7.5.9. socket-timeout</A
+>7.6.7. socket-timeout</A
 ></H4
 ><P
 ></P
@@ -4004,6 +4266,202 @@ CLASS="REPLACEABLE"
 ></DL
 ></DIV
 ></DIV
+><DIV
+CLASS="SECT3"
+><H4
+CLASS="SECT3"
+><A
+NAME="MAX-CLIENT-CONNECTIONS"
+>7.6.8. 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
+>None</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
+></DD
+><DT
+>Examples:</DT
+><DD
+><P
+>    max-client-connections 256
+   </P
+></DD
+></DL
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><H4
+CLASS="SECT3"
+><A
+NAME="HANDLE-AS-EMPTY-DOC-RETURNS-OK"
+>7.6.9. handle-as-empty-doc-returns-ok</A
+></H4
+><P
+></P
+><DIV
+CLASS="VARIABLELIST"
+><DL
+><DT
+>Note:</DT
+><DD
+><P
+>    This is 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
+>)
+   </P
+></DD
+><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
+></DL
+></DIV
+></DIV
 ></DIV
 ><DIV
 CLASS="SECT2"
@@ -4011,7 +4469,7 @@ CLASS="SECT2"
 CLASS="SECT2"
 ><A
 NAME="WINDOWS-GUI"
->7.6. Windows GUI Options</A
+>7.7. Windows GUI Options</A
 ></H2
 ><P
 > <SPAN
@@ -4363,4 +4821,4 @@ VALIGN="top"
 ></DIV
 ></BODY
 ></HTML
->
+>
\ No newline at end of file