8.1. Finding the Right Mix

8.2. How to Edit

8.4.1. The Domain Pattern

matches any domain that ENDS in - matches any domain with first-level domain .example.comcom + and second-level domain example. + For example www.example.com, + example.com and foo.bar.baz.example.com. + Note that it wouldn't match if the second-level domain was another-example.

www. +> (It also matches the domain + www but most of the time that doesn't matter.)

8.4.2. The Path Pattern

If the request URL gets changed, Privoxy will detect that and use the new + one. This can be used to rewrite the request destination behind the client's + back, for example to specify a Tor exit relay for certain requests. +

Please refer to the filter file chapter"If-Modified-Since:" makes - sure it isn't used as a cookie replacement, but you will run into - caching problems if the random range is too high. + it less likely that the server can use the time as a cookie replacement, + but you will run into caching problems if the random range is too high.

It is a good idea to only use a small negative value and let @@ -4948,7 +4977,8 @@ CLASS="LITERAL" HREF="actions-file.html#CRUNCH-IF-NONE-MATCH" >crunch-if-none-match. +>, + otherwise it's more or less pointless.

# Let the browser revalidate without being tracked across sessions
-{ +hide-if-modified-since{-60} \
+># Let the browser revalidate but make tracking based on the time less likely.
+{+hide-if-modified-since{-60} \
  +overwrite-last-modified{randomize} \
  +crunch-if-none-match}
 /

Typical use:

Improve privacy by not embedding the source of the request in the HTTP headers.

Improve privacy by not forwarding the source of the request in the HTTP headers.

Effect:

Deletes any existing "X-Forwarded-for:" HTTP header from client requests, - and prevents adding a new one. +> HTTP header from client requests.
Notes:
It is safe to leave this on. +> It is safe and recommended to leave this on.
"conditional-forge" to forge the header if the host has changed.
"block" to delete the header unconditionally.
Always blocking the referrer, or using a custom one, can lead to failures on servers that check the referrer before they answer any - requests, in an attempt to prevent their valuable content from being + requests, in an attempt to prevent their content from being embedded or linked to elsewhere.
Typical use:
Conceal your type of browser and client operating system
Try to conceal your type of browser and client operating system
Effect:
the right thing to do: good web sites work browser-independently). -
Typical use:
To protect against the MS buffer over-run in JPEG processing
Try to protect against a MS buffer over-run in JPEG processing
Effect:
Note that the described exploit is only one of many, - using this action does not mean that you no longer - have to patch the client. +> Note that the exploit mentioned is several years old + and it's unlikely that your client is still vulnerable + against it. This action may be removed in one of the + next releases.
This action is most appropriate for browsers that don't have any controls for unwanted pop-ups. Not recommended for general usage.
This action doesn't work very reliable and may be removed in future releases. +
Example usage:
URLs) through proxies. It works very simply: the proxy connects to the server on the specified port, and then short-circuits its connections to the client and to the remote server. - This can be a big security hole, since CONNECT-enabled proxies can be - abused as TCP relays very easily. + This means CONNECT-enabled proxies can be used as TCP relays very easily.

8.5.39. Summary
8.7.1. default.action
8.7.2. user.action