-
- <p>To match all requests that are tagged with <span class=
- "QUOTE">"foo"</span> your pattern line should be <span class=
- "QUOTE">"TAG:^foo$"</span>, <span class="QUOTE">"TAG:foo"</span>
- would work as well, but it would also match requests whose tags
- contain <span class="QUOTE">"foo"</span> somewhere. <span class=
- "QUOTE">"TAG: foo"</span> wouldn't work as it requires white
- space.</p>
-
- <p>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.</p>
-
- <p>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.</p>
-
- <p>For example you could tag client requests which use the <tt class=
- "LITERAL">POST</tt> method, then use this tag to activate another
- tagger that adds a tag if cookies are sent, and then use a block
- action based on the cookie tag. This allows the outcome of one
- action, to be input into a subsequent action. However if you'd
- reverse the position of the described taggers, and activated the
- method tagger based on the cookie tagger, no method tags would be
- created. The method tagger would look for the request line, but at
- the time the cookie tag is created, the request line has already been
- parsed.</p>
-
- <p>While this is a limitation you should be aware of, this kind of
- indirection is seldom needed anyway and even the example doesn't make
- too much sense.</p>
+ <p>To match all requests that are tagged with <span class="QUOTE">"foo"</span> your pattern line should be
+ <span class="QUOTE">"TAG:^foo$"</span>, <span class="QUOTE">"TAG:foo"</span> would work as well, but it would
+ also match requests whose tags contain <span class="QUOTE">"foo"</span> somewhere. <span class="QUOTE">"TAG:
+ foo"</span> wouldn't work as it requires white space.</p>
+ <p>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.</p>
+ <p>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.</p>
+ <p>For example you could tag client requests which use the <tt class="LITERAL">POST</tt> method, then use this
+ tag to activate another tagger that adds a tag if cookies are sent, and then use a block action based on the
+ cookie tag. This allows the outcome of one action, to be input into a subsequent action. However if you'd
+ reverse the position of the described taggers, and activated the method tagger based on the cookie tagger, no
+ method tags would be created. The method tagger would look for the request line, but at the time the cookie tag
+ is created, the request line has already been parsed.</p>
+ <p>While this is a limitation you should be aware of, this kind of indirection is seldom needed anyway and even
+ the example doesn't make too much sense.</p>
+ </div>
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEGATIVE-TAG-PATTERNS" id="NEGATIVE-TAG-PATTERNS">8.4.4. The Negative Request Tag
+ Patterns</a></h3>
+ <p>To match requests that do not have a certain request tag, specify a negative tag pattern by prefixing the
+ tag pattern line with either <span class="QUOTE">"NO-REQUEST-TAG:"</span> or <span class=
+ "QUOTE">"NO-RESPONSE-TAG:"</span> instead of <span class="QUOTE">"TAG:"</span>.</p>
+ <p>Negative request tag patterns created with <span class="QUOTE">"NO-REQUEST-TAG:"</span> are checked after
+ all client headers are scanned, the ones created with <span class="QUOTE">"NO-RESPONSE-TAG:"</span> are checked
+ after all server headers are scanned. In both cases all the created tags are considered.</p>
+ </div>
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="CLIENT-TAG-PATTERN" id="CLIENT-TAG-PATTERN">8.4.5. The Client Tag Pattern</a></h3>
+ <div class="WARNING">
+ <table class="WARNING" border="1" width="100%">
+ <tr>
+ <td align="center"><b>Warning</b></td>
+ </tr>
+ <tr>
+ <td align="left">
+ <p>This is an experimental feature. The syntax is likely to change in future versions.</p>
+ </td>
+ </tr>
+ </table>
+ </div>
+ <p>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.</p>
+ <p>After a client-specific tag has been defined with the <a href=
+ "config.html#CLIENT-SPECIFIC-TAG">client-specific-tag</a>, 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!</p>
+ <p>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.</p>
+ <p>Clients can request tags to be set by using the CGI interface <a href=
+ "http://config.privoxy.org/client-tags" target="_top">http://config.privoxy.org/client-tags</a>.</p>
+ <p>Example:</p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+ <pre class="SCREEN"># 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</pre>
+ </td>
+ </tr>
+ </table>