| Privoxy User Manual | Privoxy 3.0.4 User Manual|||||||||
|---|---|---|---|---|---|---|---|---|---|
| Prev | 14. Appendix14. Appendix14.1. Regular Expressions14.1. Regular ExpressionsPCRE and - PCRSPCRS libraries. If you are reading this, you probably don't understand what /.*/banners/.* - A simple example
that uses the common combination of in the path
somewhere. A now something a little more complex: /.*/adv((er)?ts?|ertis(ing|ements?))?/ -
We have several literal forward slashes again (".*", so we are matching against any conceivable sub-path, just so
- it matches our expression. The only true literal that must
match our pattern is adv"ing"
- OR "ements?", which would then match
either spelling. /.*/advert[0-9]+\.(gif|jpe?g) - Again
another path statement with forward slashes. Anything in the square brackets
"[]""[ ]" can be matched. This is using "0-9" More reading on Perl Compatible Regular expressions:
http://www.perldoc.com/perl5.6/pod/perlre.htmlhttp://perldoc.perl.org/perlre.html For information on regular expression based substititions and their applications
+> For information on regular expression based substitutions and their applications
in filters, please see the filter file tutorial Since Below are some Privoxy - Submit Actions File FeedbackPrivoxy - Why?
Credit: The site which gave us the general idea for these bookmarklets is
www.bookmarklets.com. They
@@ -1030,8 +1073,8 @@ CLASS="SECT2"
CLASS="SECT2"
>14.3. Chain of Events14.3. Chain of Events Let's take a quick look at the basic sequence of events when a web page is
requested by your browser and Privoxy traps any request for its own internal CGI
- pages (e.g http://p.p/) and sends the CGI page back to the browser.
+ pages (e.g http://p.p/) and sends the CGI page back to the browser.
First, the server headers are read and processed to determine, among other
things, the MIME type (document type) and encoding. The headers are then
- filtered as deterimed by the
+ filtered as determined by the
default.filter) are processed against the buffered
- content. Filters are applied in the order they are specified in the
- default.filter file. Animated GIFs, if present, are
- reduced to either the first or last frame, depending on the action
+> and any other filter files) are
+ processed against the buffered content. Filters are applied in the order
+ they are specified in one of the filter files. Animated GIFs, if present,
+ are reduced to either the first or last frame, depending on the action
setting.The entire page, which is now filtered, is then sent by
As the browser receives the now (probably filtered) page content, it
+> As the browser receives the now (possibly filtered) page content, it
reads and then requests any URLs that may be embedded within the page
source, e.g. ad images, stylesheets, JavaScript, other HTML documents (e.g.
frames), sounds, etc. For each of these objects, the browser issues a new
@@ -1256,8 +1300,8 @@ CLASS="SECT2"
CLASS="SECT2"
>14.4. Anatomy of an Action14.4. Anatomy of an Action The way
to any given URL can be complex, and not always so
easy to understand what is happening. And sometimes we need to be able to
- see just what Privoxythe Bookmarklets section on a quick
- and easy way to do this (be sure to flush caches afterward!). "+filter" action) from
- the default.filter file since this is handled very
+ one of the filter files since this is handled very
differently and not so easy to trap! It also will not tell you about any other
URLs that may be embedded within the URL you are testing. For instance, images
such as ads are expressed as URLs within the raw page source of HTML pages. So
@@ -1351,7 +1396,8 @@ HREF="http://google.com"
TARGET="_top"
>google.com,
- and look at it one section at a time: This tells us how we have defined our
+> This is telling us how we have defined our
"actions", and
- which ones match for our example, "google.com". The first listing
+>.
+ Displayed is all the actions that are available to us. Remember,
+ the + sign denotes "on". -
+ denotes "off". So some are "on" here, but many
+ are "off". Each example we try may provide a slightly different
+ end result, depending on our configuration directives. The first listing
is any matches for the standard.action"+session-cookies-only"
- (i.e. not persistent). So we will allow persistent cookies for google. The
- second turns off any
Then, for our user.action file, we again have no hits. And finally we pull it all together in the bottom section and summarize how
|
Now another example, "+block"
- and an
One last example. Let's try "http://www.rhapsodyk.net/adsl/HOWTO/""http://www.example.net/adsl/HOWTO/".
- This one is giving us problems. We are getting a blank page. Hmmm... This would probably be most appropriately put in This would turn off all filtering for that site. This would probably be most
+ appropriately put in user.action,
- for local site exceptions. Images that are inexplicably being blocked, may well be hitting the
+ "+filter{banners-by-size}" rule, which assumes
+ that images of certain sizes are ad banners (works well most of the time
+ since these tend to be standardized).
Matches for http://www.rhapsodyk.net/adsl/HOWTO/:
+>
Matches for http://www.example.net/adsl/HOWTO/:
- { -add-header -block +deanimate-gifs -downgrade-http-version +fast-redirects
- +filter{html-annoyances} +filter{js-annoyances} +filter{kill-popups}
- +filter{webbugs} +filter{nimda} +filter{banners-by-size} +filter{hal}
- +filter{fun} +hide-forwarded-for-headers +hide-from-header{block}
- +hide-referer{forge} -hide-user-agent -handle-as-image +set-image-blocker{blank}
- +prevent-compression +session-cookies-only -crunch-incoming-cookies
- -crunch-outgoing-cookies +kill-popups -send-vanilla-wafer -send-wafer }
+ In file: default.action [ View ] [ Edit ]
+
+ {-add-header
+ -block
+ -content-type-overwrite
+ -crunch-client-header
+ -crunch-if-none-match
+ -crunch-incoming-cookies
+ -crunch-outgoing-cookies
+ -crunch-server-header
+ +deanimate-gifs
+ -downgrade-http-version
+ +fast-redirects{check-decoded-url}
+ +filter{html-annoyances}
+ +filter{js-annoyances}
+ +filter{kill-popups}
+ +filter{webbugs}
+ +filter{nimda}
+ +filter{banners-by-size}
+ +filter{hal}
+ +filter{fun}
+ -filter-client-headers
+ -filter-server-headers
+ -force-text-mode
+ -handle-as-empty-document
+ -handle-as-image
+ -hide-accept-language
+ -hide-content-disposition
+ +hide-forwarded-for-headers
+ +hide-from-header{block}
+ +hide-referer{forge}
+ -hide-user-agent
+ -inspect-jpegs
+ +kill-popups
+ -overwrite-last-modified
+ +prevent-compression
+ -redirect
+ -send-vanilla-wafer
+ -send-wafer
+ +session-cookies-only
+ +set-image-blocker{blank}
+ -treat-forbidden-connects-like-blocks }
/
{ +block +handle-as-image }
@@ -1643,20 +1861,24 @@ CLASS="QUOTE"
> is matching "/ads"! But
- we did not want this at all! Now we see why we get the blank page. We could
- now add a new action below this that explicitly does in our
+ configuration! But we did not want this at all! Now we see why we get the
+ blank page. We could now add a new action below this that explicitly
+ not
- block (un blocks ("{-block}") paths with ) paths with
+ "adsl". There are
- various ways to handle such exceptions. Example: in them (remember, last match in the configuration wins).
+ There are various ways to handle such exceptions. Example:"{+filter}" actions. Try
- adding the URL for the site to one of aliases that turn off actions. These
+ tend to be harder to troubleshoot. Try adding the URL for the site to one of
+ aliases that turn off "+filter":