This file is an archived copy of a Proxomitron file.

The information on this page is no longer correct - the page is available for archival (historical) purposes only. Many thanks to Ian MacPhedran.
The Proxomitron - Universal Web Filter

The Proxomitron FAQ page

What's new in Naoko 4.3

* Added $ASK(AllowList, DenyList, Prompt msg, item to add [,alternate match])

  $ASK() automates the process of asking the user if a particular
  item should be filtered at a given site. Although you can do the
  same thing with combinations of some of the other new commands,
  ASK wraps it up neatly in one small package.

* Added a NOAPPEND option to blockfiles. Blockfiles with this flag set
  will not have new items added to the file itself when ASK or ADDLST
  is called. The items will still be blocked, but only for the current
  session or until the list is reloaded (whichever comes first).

  It might be useful in cases where you only want to block something
  temporarily, and I admit it's a bit of a hack. It may not stay
  around too long if I get a better idea. ;-)

* Added $DTM(format) command.  This can be use to insert date, time 
  and connection information into any replacement text. It uses a
  simple format string to control the display and can be useful for
  adding dates to a page, or including information for use with $LOG
  or other similar commands.

* Added persistent connection support to local connections as well
  as remote. For best results make sure your browser is set to use
  HTTP/1.1 through the proxy and has pipelining enabled (if it's an
  option). Also I recommend about 6-8 simultaneous connections. With
  this, Proxomitron now supports nearly all of HTTP/1.1's optional
  features.  

  For this to work Proxomitron must make heavy use of "chunked"
  encoding since we can't know the size of a filtered item ahead of
  time.  This shouldn't be a problem, but it's possible some browsers
  may not expect so many items to be "chunked" - especially images.
  In testing Mozilla seems to have some random problems with chunked
  encoding if pipelining is enabled, but the flaw doesn't seem to be
  in Proxomitron's handling of things (Pipelining support in Mozilla
  is new and may still be a bit buggy). Opera, which also heavily
  pipelines, seem ok.

  HTTP/1.0 persistence is also supported. However, since Proxomitron
  frequently makes changes to an item's content-length and HTTP/1.0
  does not allow for chunked encoding, fewer requests may be able
  to persist if your filtering. 

  Local persistence can be turned off if necessary and it's keep-alive
  time adjusted under the HTTP tab of the Config dialog. By default 
  local connections are killed after 10 seconds of inactivity. That
  should be fine in most cases since new local connections are fairly
  fast to create, but you may wish to increase this - especially if
  you're using Proxomitron remotely over a LAN.

* Added new character hashing to matching routines.  This can greatly
  speed up OR separated lists where the initial item in each OR section
  is not a wildcard.  For example...

    (one|two|(three|four|five)|six)    is hashable while...
    (one|*two|(three|four|five)|six)   isn't, and neither is...
    ([to]ne|two|(three|four|five)|six) 

  Actually though each set of parens (...) has its own hash, so 
  in each case above the "(three|four|five)" is still hashed each
  time.  Also mixing in AND or ANDAND is usually ok too...

    (one|two|(three|four|five)|six)*(end)&&*whatever*
    (one|two|((three|four|five)*&*whatever*)|six) 

  This also means a complex match like (from the banner blaster)...

    <(a\s*</a>|i(nput*>|layer*</ilayer>|frame*</iframe>))

  is pretty much just as fast written like...

    <a\s*</a>|<input*>|<ilayer*</ilayer>|<iframe*</iframe>

  but it's good deal easier to read.  Still, the hashing speeds up both 
  examples. Using it is pretty much transparent (hopefully).  Keep in
  mind leading wildcards are always slower and should be avoided if
  possible (particularly in web filter bounds checks). 
  
* Added $LOG(), $ALERT(), and $CONFIRM() matching commands.  These
  allow you to send a message to the user.  $ALERT() just pops up a
  message box with whatever text you provide.  $CONFIRM pops up a 
  Yes/No dialog box with the message. If the user clicks "No", this
  will be treated as a non-match in the filter the command is called
  from. $LOG() sends the message to the log window (if it's open).
  Note that the first letter in a log window message determines the
  color used to display it...

    R=Red W=White w=Gray B=Blue G=Green Y=Yellow V=Violet C=Cyan

  All commands take a single string of text and will have replacement
  expansion done before display. They can be used in either the
  matching or replacement section of any type of filter. 

* Added $ADDLST(ListName, Text of line to add) command.  This lets you
  add items to a blocklist from a filter.  The item to add will have 
  replacement expansion done to the input beforehand, so it may include
  text captured by the filter.  Because of this, you'll need to double-
  escape stuff like "\1" if you want to place the wildcard itself (and
  not it's value) in a blocklist. Just add an extra backslash like
  so: "\\1", "\\h", "\\p".

* Added $ADDLSTBOX(ListName, Title, Text to add) command. This is very
  much like $ADDLST() but prompts the user with the standard "add to 
  blockfile" dialog normally called from the systray menu.  The "Title"
  portion is optional, but any text entered here will be shown on the
  dialog's title bar.  The command matches true if an item is added or
  false if the user cancels.

* Added $WESC() command. This will escape any wildcards in the given
  input string (after first doing replacement expansion). Useful for 
  making sure anything added to a blocklist from an unknown source
  (like a URL) will be matched literally so characters like "+","&"
  "?", etc. won't cause inadvertent matching errors. It can be used
  in the replacement section of a match or in the input of any,
  command, like $ADDLST(), that performs replacement expansion on its
  input.

* Added $LOCK() and $UNLOCK() commands. These are useful for synch-
  ronizing a filter's action across simultaneously loading pages. 
  Only one filter can be "locked" at any given time. if any other filter
  then calls lock, it will wait until the first completes before being
  processed.  You can use this to group a series of related actions in a
  filter.

* Rigged the "profile" in the matching test window to abort if it's
  taking too long.  Normally it does 1000 iterations, but on a 
  very complex match or if matching a lot of text, this can take some
  time to complete.  Now it'll stop beforehand if it takes over
  6 seconds. The results are adjusted to reflect the actual number
  of iterations finished so should still be fairly accurate.

  Note that due to this extra checking, test times may be slightly
  slower than in the previous versions of Proxomitron. Don't worry,
  the filters themselves aren't slower though.  

* Fixed \h matching too small of a string in some cases.

* Fixed a potential bug in the $RDIR() command

* Made replacement text buffer grow dynamically. This should prevent
  problems some people where having when certain combinations of
  filters with large byte limits were used with multi-match enabled. 

* Moved the "Edit Blockfile" option to it's own spot on the systray
  menu - should make it easier to use.

* Removed a "Last-Modified" header hack I used to get around a silly
  cache problem IE used to have. If the last-modified date hadn't changed
  IE would use the old cached version of a page even if the server sent
  it a completely new version. Thankfully this has been fixed for several
  version now. 


Return to main index