X-Git-Url: http://www.privoxy.org/gitweb/?p=privoxy.git;a=blobdiff_plain;f=doc%2Fwebserver%2Fuser-manual%2Fconfig.html;h=7adee4c9993f178168f41592ab16b26d0dc135c6;hp=7967f84c9bb68cee1e119ef58306ce2781fc28d3;hb=3db7a58b2bbed7b6356b2a0600e93ec4f2846499;hpb=322389db65561716cdc35949eea8ae911f8a0aa8 diff --git a/doc/webserver/user-manual/config.html b/doc/webserver/user-manual/config.html index 7967f84c..7adee4c9 100644 --- a/doc/webserver/user-manual/config.html +++ b/doc/webserver/user-manual/config.html @@ -7,7 +7,7 @@ NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.79">
Bind to 127.0.0.1 (localhost), port 8118. This is suitable and recommended for - home users who run Bind to 127.0.0.1 (IPv4 localhost), port 8118. This is suitable and + recommended for home users who run Privoxy on the same machine as - their browser. +> on + the same machine as their browser.
IPv6 addresses containing colons have to be quoted by brackets. +
If you leave out the IP address, Privoxy will - bind to all interfaces (addresses) on your machine and may become reachable + bind to all IPv4 interfaces (addresses) on your machine and may become reachable from the Internet. In that case, consider using access control lists +
Suppose you are running Privoxy on an + IPv6-capable machine and you want it to listen on the IPv6 address + of the loopback device: +
listen-address [::1]:8118 |
If your system implements + RFC 3493, then + src_addr and dst_addr can be IPv6 addresses delimeted by + brackets, port can be a number + or a service name, and + src_masklen and + dst_masklen can be a number + from 0 to 128. +
If no port is specified, + any port will match. If no src_masklen or + src_masklen is given, the complete IP + address has to match (i.e. 32 bits for IPv4 and 128 bits for IPv6). +
Some systems allow IPv4 clients to connect to IPv6 server sockets. + Then the client's IPv4 address will be translated by the system into + IPv6 address space with special prefix ::ffff:0:0/96 (so called IPv4 + mapped IPv6 address). Privoxy can handle it + and maps such ACL addresses automatically. +
Denying access to particular sites by ACL may have undesired side effects if the site in question is hosted on a machine which also hosts other sites (most sites are). @@ -2507,6 +2622,44 @@ CLASS="SCREEN" > +
Allow access from the IPv4 network 192.0.2.0/24 even if listening on + an IPv6 wild card address (not supported on all platforms): +
permit-access 192.0.2.0/24 |
This is equivalent to the following line even if listening on an + IPv4 address (not supported on all platforms): +
permit-access [::ffff:192.0.2.0]/120 |
http_parent can be a + numerical IPv6 address (if + RFC 3493 is + implemented). To prevent clashes with the port delimiter, the whole IP + address has to be put into brackets. On the other hand a target_pattern containing an IPv6 address + has to be put into angle brackets (normal brackets are reserved for + regular expressions already). +
Multiple lines are OK, they are checked in sequence, and the last match wins.
+Parent proxy specified by an IPv6 address: +
foward / [2001:DB8::1]:8000 |
Suppose your parent proxy doesn't support IPv6: +
forward / parent-proxy.example.org:8000 + forward ipv6-server.example.org . + forward <[2-3][0-9a-f][0-9a-f][0-9a-f]:*> . |
socks_proxy and + http_parent can be a + numerical IPv6 address (if + RFC 3493 is + implemented). To prevent clashes with the port delimiter, the whole IP + address has to be put into brackets. On the other hand a target_pattern containing an IPv6 address + has to be put into angle brackets (normal brackets are reserved for + regular expressions already). +
If forward-socks4a / 127.0.0.1:9050 .
forward-socks5 / 127.0.0.1:9050 .
Due to a bug, this option currently also causes Privoxy to + retry in case of certain problems with direct connections. +
Connections are not reused. +> Connections are not kept alive.
This option has no effect if This option allows clients to keep the connection to Privoxy - has been compiled without keep-alive support. + alive. If the server supports it, Privoxy will keep + the connection to the server alive as well. Under certain + circumstances this may result in speed-ups.
Note that reusing connections doesn't necessary cause speedups. - There are also a few privacy implications you should be aware of. +> By default, Privoxy 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 connection-sharing option.
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 This option has no effect if Privoxy 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 Privoxy's - or the server's timeout is reached. While it's open, the server knows - that the system running Privoxy is still there. + has been compiled without keep-alive support. +
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 "grabbing" all the + connections the browser allows, which means connections to + other websites can't be opened until the connections currently + in use time out. +
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.
Number of seconds after which a socket times out if - no data is received. +> Assumed server-side keep-alive timeout if not specified by the server.
A default value of 300 seconds is used. +> Connections for which the server didn't specify the keep-alive + timeout are not reused.
For SOCKS requests the timeout currently doesn't start until - the SOCKS server accepted the request. This will be fixed in - the next release. +> Enabling this option significantly increases the number of connections + that are reused, provided the keep-alive-timeout option + is also enabled. +
While it also increases the number of connections problems + when Privoxy tries to reuse a connection that already has + been closed on the server side, or is closed while Privoxy + 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, Privoxy will simply + close the connection and the client is supposed to retry the + request without bothering the user. +
Enabling this option is therefore only recommended if the + connection-sharing option + is disabled. +
It is an error to specify a value larger than the keep-alive-timeout value. +
This option has no effect if Privoxy + has been compiled without keep-alive support.
socket-timeout 300 +> default-server-timeout 60
Whether or not outgoing connections that have been kept alive + should be shared between different incoming connections. +
0 or 1 +
None
Connections are not shared. +
This option has no effect if Privoxy + has been compiled without keep-alive support, or if it's disabled. +
Note that reusing connections doesn't necessary cause speedups. + There are also a few privacy implications you should be aware of. +
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 Privoxy + 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 + Privoxy's or the server's timeout is reached. + While it's open, the server knows that the system running Privoxy is still + there. +
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. +
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 Privoxy to keep outgoing connections alive even if the client + itself doesn't support it. +
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. +
This option should only be used by experienced users who + understand the risks and can weight them against the benefits. +
connection-sharing 1 +
Number of seconds after which a socket times out if + no data is received. +
Time in seconds. +
None
A default value of 300 seconds is used. +
For SOCKS requests the timeout currently doesn't start until + the SOCKS server accepted the request. This will be fixed in + the next release. +
socket-timeout 300 +
Maximum number of client connections that will be served. +
Positive number. +
None
Connections are served until a resource limit is reached. +
Privoxy creates one thread (or process) for every incoming client + connection that isn't rejected based on the access control settings. +
If the system is powerful enough, Privoxy 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 Privoxy would + require under heavy load. +
Configuring Privoxy 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 Privoxy isn't the only application running on the system, + you may actually want to limit the resources used by Privoxy. +
If Privoxy 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 Privoxy. +
Obviously using this option only makes sense if you choose a limit + below the one enforced by the operating system. +
max-client-connections 256 +
This is a work-around for Firefox bug 492459: + " Websites are no longer rendered if SSL requests for JavaScripts are blocked by a proxy. + " + (https://bugzilla.mozilla.org/show_bug.cgi?id=492459) +
The status code Privoxy returns for pages blocked with + + +handle-as-empty-document. +
0 or 1 +
0
Privoxy returns a status 403(forbidden) for all blocked pages. +
Privoxy returns a status 200(OK) for pages blocked with +handle-as-empty-document + and a status 403(Forbidden) for all other blocked pages. +