Author Topic: Proxomitron - Coming soon.......  (Read 616 times)


  • Full Member
  • ***
  • Posts: 113
    • ICQ Messenger - 92066376
    • AOL Instant Messenger -
    • Yahoo Instant Messenger -
    • View Profile
    • Email
Proxomitron - Coming soon.......
« on: June 01, 2002, 06:56:00 PM »
For those who don't know, there is a Proxomitron beta release being tested right now which features a few new commands....

I'll post the 'changes.txt' file here for people to read, as im sure some are interested in the possible new features to this already great tool.

Naoko 4.2.2 (Beta Test version, please do not re-distribute yet)

* 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

  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.

  To all beta testers: If you're using IE6 or XP please check this
  version to see if windows update is still having problems. I suspect
  that this just might work-around the problem (though if this is the
  case, it really indicates MS isn't handling connections correctly
  to begin with. It really shouldn't make a difference).

  If using Opera, please check to see if you still are having any
  "half-loaded" image problems.  Again it shouldn't really matter, but
  persistent client connections might avoid the issue. At any rate,
  right or wrong, it's more in line with how most clients seem to
  expect HTTP/1.1 to work.

  Also in general, try and be aware of performance issues - do things
  seem faster or slower than before?  Either is possible depending on
  how a browser deals with HTTP.  Pipelining and persistence are
  designed to reduce the need for multiple connections by making each
  single connection as efficient as possible.  However, it also reduces
  parallelism - meaning one slow request may hold up all the others
  waiting to use that same connection.

  If you suspect a problem, you can use the abort button in Proxomitron
  to kill all connections and start fresh. Also you can add...

    ClientTimeout=(value in seconds)

  to the [Globals] section of Proxomitron's config file to disable the
  local keep-alive support or alter the length of time client connections
  are kept open.  The ClientTimeout is only 3 seconds by default which
  insures the connections are closed pretty quickly after a page has
  finished loading.  This seems like a good trade-off as open connections
  do use memory, and new localhost connections can be made pretty fast.
  Still, you may want to try setting this to several minutes to keep
  the connections open for the next page, but you may not see much of a
  speed benefit unless Proxomitron is running on a different PC over
  a network.

* 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...

  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...


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


  is pretty much just as fast written like...


  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).

  Note this is an extension of a single character test I'd already been
  using in earlier versions, but it takes it much further - allowing
  many more matches to be optimized. While not quite as efficient as the
  blocklist hashes for very large lists, it can eliminate a considerable
  amount of checking within a filter.

  Beta Testers: Please check to see if any match that worked in the
  previous version suddenly isn't matching anymore. It's possible
  the hashing may introduce some new bugs!
* 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

* 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.

|David Gallagher        
|dave at
dave at