X-Git-Url: http://www.privoxy.org/gitweb/?p=privoxy.git;a=blobdiff_plain;f=doc%2Fwebserver%2Fuser-manual%2Factions-file.html;h=f78109e2f4808806fada3d9ad0e7b242a4a976bc;hp=ce06322d8bf277142005344c36d5be20eea44057;hb=7d0d8bdd53947864c64d968062ca132b65f2e162;hpb=abd789ae2b66c396bf6899a82268c6849ab5ed22 diff --git a/doc/webserver/user-manual/actions-file.html b/doc/webserver/user-manual/actions-file.html index ce06322d..f78109e2 100644 --- a/doc/webserver/user-manual/actions-file.html +++ b/doc/webserver/user-manual/actions-file.html @@ -6,7 +6,7 @@
Privoxy 3.0.20 User Manual | +Privoxy 3.0.26 User Manual | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
Warning | +
+ This is an experimental feature. The syntax is likely to + change in future versions. + |
+
Client tag patterns are not set based on HTTP headers but based on + the client's IP address. Users can enable them themselves, but the + Privoxy admin controls which tags are available and what their effect + is.
+ +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 + CLIENT-TAG 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!
+ +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.
+ +Clients can request tags to be set by using the CGI interface + http://config.privoxy.org/client-tags.
+ +Example:
+ +
+ +# If the admin defined the client-specific-tag circumvent-blocks, +# and the request comes from a client that previously requested +# the tag to be set, overrule all previous +block actions that +# are enabled based on URL to CLIENT-TAG patterns. +{-block} +CLIENT-TAG:^circumvent-blocks$ + +# This section is not overruled because it's located after +# the previous one. +{+block{Nobody is supposed to request this.}} +example.org/blocked-example-page ++ |
+
-+add-header{X-User-Tracking: sucks} +# Add a DNT ("Do not track") header to all requests, +# event to those that already have one. +# +# This is just an example, not a recommendation. +# +# There is no reason to believe that user-tracking websites care +# about the DNT header and depending on the User-Agent, adding the +# header may make user-tracking easier. +{+add-header{DNT: 1}} +/
Parameterized.
+Multi-value.
Parameterized.
+Multi-value.
Modify content using a programming language of your + choice.
+All instances of text-based type, most notably HTML and + JavaScript, to which this action applies, can be filtered + on-the-fly through the specified external filter. By default + plain text documents are exempted from filtering, because web + servers often use the text/plain MIME + type for all files whose type they don't know.)
+Multi-value.
+The name of an external content filter, as defined in the + filter file. External filters + can be defined in one or more files as defined by the + filterfile option in the + config file.
+ +When used in its negative form, and without parameters, + all + filtering with external filters is completely disabled.
+External filters are scripts or programs that can modify the + content in case common filters aren't powerful + enough. With the exception that this action doesn't use + pcrs-based filters, the notes in the filter + section apply.
+ +Warning | +
+ Currently external filters are executed with + Privoxy's privileges. + Only use external filters you understand and trust. + |
+
This feature is experimental, the syntax may + change in the future.
+
+ ++external-filter{fancy-filter} ++ |
+
Parameterized.
+Multi-value.
-+filter{js-events} # Kill all JS event bindings and timers (Radically destructive! Only for extra nasty sites). ++filter{js-events} # Kill JavaScript event bindings and timers (Radically destructive! Only for extra nasty sites).
-+filter{refresh-tags} # Kill automatic refresh tags (for dial-on-demand setups). ++filter{refresh-tags} # Kill automatic refresh tags if refresh time is larger than 9 seconds.
-+filter{unsolicited-popups} # Disable only unsolicited pop-up windows. Useful if your browser lacks this ability. ++filter{unsolicited-popups} # Disable only unsolicited pop-up windows.
-+filter{all-popups} # Kill all popups in JavaScript and HTML. Useful if your browser lacks this ability. ++filter{all-popups} # Kill all popups in JavaScript and HTML.
+ ++filter{iframes} # Removes all detected iframes. Should only be enabled for individual sites. ++ |
+
Multi-value.
+Parameterized.
"forward-webserver + 127.0.0.1:80" to use the HTTP server listening at + 127.0.0.1 port 80 without adjusting the request + headers.
+ +This makes it more convenient to use Privoxy to make + existing websites available as onion services as well.
+ +Many websites serve content with hardcoded URLs and + can't be easily adjusted to change the domain based on the + one used by the client.
+ +Putting Privoxy between Tor and the webserver (or an + stunnel that forwards to the webserver) allows to rewrite + headers and content to make client and server happy at the + same time.
+ +Using Privoxy for webservers that are only reachable + through onion addresses and whose location is supposed to + be secret is not recommended and should not be necessary + anyway.
+If the ports are missing or invalid, default values will be used. This might change in the future and you shouldn't rely on it. Otherwise incorrect syntax causes - Privoxy to exit.
+ Privoxy to exit. Due to design limitations, invalid + parameter syntax isn't detected until the action is + used the first time.-# Always use direct connections for requests previously tagged as +# Use an ssh tunnel for requests previously tagged as # "User-Agent: fetch libfetch/2.0" and make sure # resuming downloads continues to work. +# # This way you can continue to use Tor for your normal browsing, # without overloading the Tor network with your FreeBSD ports updates # or downloads of bigger files like ISOs. +# # Note that HTTP headers are easy to fake and therefore their # values are as (un)trustworthy as your clients and users. -{+forward-override{forward .} \ +{+forward-override{forward-socks5 10.0.0.2:2222 .} \ -hide-if-modified-since \ -overwrite-last-modified \ } @@ -2771,7 +3011,7 @@ TAG:^User-Agent: fetch libfetch/2\.0$8.5.18. handle-as-empty-document
+ "HANDLE-AS-EMPTY-DOCUMENT">8.5.19. handle-as-empty-document@@ -2849,7 +3089,7 @@ example.org/.*\.js$
8.5.19. handle-as-image
+ "HANDLE-AS-IMAGE">8.5.20. handle-as-image@@ -2938,7 +3178,7 @@ nasty-banner-server.example.com/junk.cgi\?output=trash
8.5.20. hide-accept-language
+ "HIDE-ACCEPT-LANGUAGE">8.5.21. hide-accept-language@@ -3018,7 +3258,7 @@ nasty-banner-server.example.com/junk.cgi\?output=trash
8.5.21. hide-content-disposition
+ "HIDE-CONTENT-DISPOSITION">8.5.22. hide-content-disposition@@ -3104,7 +3344,7 @@ nasty-banner-server.example.com/junk.cgi\?output=trash
8.5.22. hide-if-modified-since
+ "HIDE-IF-MODIFIED-SINCE">8.5.23. hide-if-modified-since@@ -3191,7 +3431,7 @@ nasty-banner-server.example.com/junk.cgi\?output=trash
8.5.23. hide-from-header
+ "HIDE-FROM-HEADER">8.5.24. hide-from-header@@ -3266,7 +3506,7 @@ nasty-banner-server.example.com/junk.cgi\?output=trash
-8.5.24. +
8.5.25. hide-referrer
@@ -3386,7 +3626,7 @@ nasty-banner-server.example.com/junk.cgi\?output=trash8.5.25. hide-user-agent
+ "HIDE-USER-AGENT">8.5.26. hide-user-agent@@ -3475,7 +3715,7 @@ nasty-banner-server.example.com/junk.cgi\?output=trash
Limit the lifetime of HTTP cookies to a couple of minutes or + hours.
+Overwrites the expires field in Set-Cookie server headers if + it's above the specified limit.
+Parameterized.
+The lifetime limit in minutes, or 0.
+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.
+ +Cookies with a lifetime below the limit are not modified. + The lifetime of session cookies is set to the specified + limit.
+ +The effect of this action depends on the server.
+ +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.
+ +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.
+ +If the parameter is "0", this + action behaves like session-cookies-only.
+