-
+
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}}
+/
|
@@ -4077,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
@@ -4513,7 +4590,7 @@ TAG:^image/