-
+
Privoxy uses "modern" POSIX 1003.2
+ Request Tag Pattern
-
Tag patterns are used to change the applying actions based on the
- request's tags. Tags can be created with either the Request tag patterns are used to change the applying actions based
+ on the request's tags. Tags can be created based on HTTP headers with
+ either the client-header-tagger or
the server-header-tagger
action.
-
Tag patterns have to start with "TAG:",
- so Privoxy can tell them apart from
- URL patterns. Everything after the colon including white space, is
- interpreted as a regular expression with path pattern syntax, except
- that tag patterns aren't left-anchored automatically (Privoxy doesn't silently add a "^", you have to do it yourself if you need it).
+
Request tag patterns have to start with "TAG:", so Privoxy
+ can tell them apart from other patterns. Everything after the colon
+ including white space, is interpreted as a regular expression with
+ path pattern syntax, except that tag patterns aren't left-anchored
+ automatically (Privoxy doesn't
+ silently add a "^", you have to do it
+ yourself if you need it).
To match all requests that are tagged with "foo" your pattern line should be "TAG: foo" wouldn't work as it requires white
space.
-
Sections can contain URL and tag patterns at the same time, but
- tag patterns are checked after the URL patterns and thus always
- overrule them, even if they are located before the URL patterns.
+
Sections can contain URL and request tag patterns at the same
+ time, but request tag patterns are checked after the URL patterns and
+ thus always overrule them, even if they are located before the URL
+ patterns.
-
Once a new tag is added, Privoxy checks right away if it's matched
- by one of the tag patterns and updates the action settings
- accordingly. As a result tags can be used to activate other tagger
- actions, as long as these other taggers look for headers that haven't
- already be parsed.
+
Once a new request tag is added, Privoxy checks right away if it's
+ matched by one of the request tag patterns and updates the action
+ settings accordingly. As a result request tags can be used to
+ activate other tagger actions, as long as these other taggers look
+ for headers that haven't already be parsed.
For example you could tag client requests which use the POST method, then use this tag to activate another
@@ -797,21 +800,86 @@
+ "NEGATIVE-TAG-PATTERNS">8.4.4. The Negative Request Tag
+ Patterns
-
To match requests that do not have a certain tag, specify a
- negative tag pattern by prefixing the tag pattern line with either
+
To match requests that do not have a certain request tag, specify
+ a negative tag pattern by prefixing the tag pattern line with either
"NO-REQUEST-TAG:" or "NO-RESPONSE-TAG:" instead of "TAG:".
-
Negative tag patterns created with Negative request tag patterns created with "NO-REQUEST-TAG:" are checked after all client headers
are scanned, the ones created with "NO-RESPONSE-TAG:" are checked after all server
headers are scanned. In both cases all the created tags are
considered.
+
+
+
+
+
+
+
+ | 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
+
+ |
+
+
+
@@ -996,7 +1064,16 @@
-+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}}
+/
|
@@ -1201,7 +1278,7 @@
Type:
- Parameterized.
+ Multi-value.
Parameter:
@@ -1277,7 +1354,7 @@
Type:
- Parameterized.
+ Multi-value.
Parameter:
@@ -2026,7 +2103,7 @@ problem-host.example.com
Type:
- Parameterized.
+ Multi-value.
Parameter:
@@ -2246,7 +2323,7 @@ problem-host.example.com
Type:
- Parameterized.
+ Multi-value.
Parameter:
@@ -2794,7 +2871,7 @@ problem-host.example.com
Type:
- Multi-value.
+ Parameterized.
Parameter:
@@ -2833,6 +2910,30 @@ problem-host.example.com
"forward-socks5" for socks5
connections (with remote DNS resolution).
+
+
+ "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.
+
@@ -4053,7 +4154,7 @@ nasty-banner-server.example.com/junk.cgi\?output=trash
# Create a short, easy to remember nickname for a favorite site
# (relies on the browser to accept and forward invalid URLs to
Privoxy)
-{ +redirect{http://www.privoxy.org/user-manual/actions-file.html} }
+{ +redirect{https://www.privoxy.org/user-manual/actions-file.html} }
a
# Always use the expanded view for Undeadly.org articles
@@ -4119,7 +4220,7 @@ www.privoxy.org/user-manual/
Type:
- Parameterized.
+ Multi-value.
Parameter:
@@ -4192,7 +4293,7 @@ example.org/instance-that-is-delivered-as-xml-but-is-not
Type:
- Parameterized.
+ Multi-value.
Parameter:
@@ -4489,7 +4590,7 @@ TAG:^image/