junkbuster.1

一个不错的服务代理器

.TH JUNKBUSTER 1 "http://www.junkbusters.com/ht/en/ijb2.0man.html"
.SH NAME
\fBjunkbuster\fP
- The
Internet Junkbuster
Proxy
\s-2(TM)\s+2
.SH SYNOPSIS
\fBjunkbuster\fP
\fI\&configfile\fP
(Version 2.0 onwards)
.br
\fBjunkbstr.exe\fP
\fI\&configfile\fP
(Windows)
.br
\fBjunkbuster\fP
[-a]
[-y]
[-s]
[-c]
[-v]
.br
[-u user_agent]
[-r referer]
[-t from]
.br
[-b blockfile]
[-j jarfile]
[-l logfile]
.br
[-w NAME=VALUE]
[-x Header_text]
.br
[-h [bind_host_address][:bind_port]]
.br
[-f forward_host[:port]]
[-d N]
.br
[-g gw_protocol[:[gw_host][:gw_port]]]
.br
(Version 1.4 and earlier)
.SH DESCRIPTION
\fBjunkbuster\fP
is an instrumentable proxy that filters the 
\s-2HTTP\s0
stream between
web servers and browsers.
Its main purpose is to enhance privacy.
.P
Versions before 2.0 used command-line options;
Versions from 2.0 onward use a configuration file.
The following descriptions of the options first give the older
command-line usage, then the new configfile line.
.P
In Versions 2.0.1 upwards on Windows,
a start-up message is printed and the configuration is read from the file
\fC\&junkbstr.ini\fP
if it exists and no argument was given.
.P
All files except the configfile
are checked for changes before each page is fetched,
so they may edited without restarting the proxy.
.SS OPTIONS
.TP
.\" anchor: o_b blockfile
\fI-b blockfile\fP (Old) blockfile \fIblockfile\fP (New)
Block\" ijbfaq.html#blocking
requests to
\s-2URL\s0s
matching any pattern given in the lines of the
\fI\&blockfile\fP.
The
\fBjunkbuster\fP
instead returns status 202, indicating that the request has been accepted
(though not completed),
and a
message identifying itself\" ijbfaq.html#show
(though the browser may
display only a broken image icon).
(Versions before 2.0 returned an error 403 (Forbidden).)
The syntax of a pattern is
\fB\&[domain][:port][/path]\fP
(the
\fB\&http://\fP
or
\fB\&https://\fP
protocol part is omitted).
To decide if a pattern matches a target, the domains are compared first,
then the paths. 
.P
To compare the domains,
the pattern domain and the target
domain specified in the
\s-2URL\s0
are each broken into their components.
(Components are separated by the
\fC\&.\fP
(period) character.)
Next each of the target components
is compared with the corresponding pattern component: last with last,
next-to-last with next-to-last, and so on.
(This is called
\fIright-anchored\fP
matching.)
If all of the pattern components find their match in the target,
then the domains are considered a match.
Case is irrelevant when comparing domain components.
.P
A successfully
matching pattern can be an anchored substring of a target, but
not vice versa.
Thus if a pattern doesn't specify a domain,
it matches all domains.
.\" anchor: wildcard
Furthermore, when comparing two components,
the components must either match in their entirety or up to a wildcard
\fC\&* \fP
(star character) in the pattern.  The wildcard feature
implements only a "prefix" match capability ("abc*" vs. "abcdefg"),
not suffix matching ("*efg" vs. "abcdefg") or
infix matching ("abc*efg" vs. "abcdefg").
The feature is restricted to the domain component;
it is unrelated to the optional
regular expression
feature in the path
(described below).\" ijbman.html#regex
.P
If a numeric port
is specified in the pattern domain, then the target port must
match as well.  The default port in a target is port 80.
.P
If the domain and port match,
then the target
\s-2URL\s0
path is checked for
a match against the path in the pattern.
Paths are compared with a simple case-sensitive
left-anchored substring comparison.
Once again, the pattern can be an
anchored substring of the target, but not vice versa.
A path of
\fC\&/\fP
(slash) would match all paths.  Wildcards are not considered in
path comparisons.
.P
For example, the target
\s-2URL\s0
.br
.ti +0.25i
\fB\&the.yellow-brick-road.com/TinMan/has_no_brain\fP
.br
would be matched (and blocked) by the following patterns
.br
.ti +0.25i
\fB\&yellow-brick-road.com\fP
.br
and
.br
.ti +0.25i
\fB\&Yellow*.COM\fP
.br
and
.br
.ti +0.25i
\fB\&/TinM\fP
.br
but not
.br
.ti +0.25i
\fB\&follow.the.yellow-brick-road.com\fP
.br
or
.br
.ti +0.25i
\fB\&/tinman\fP
.br
.P
Comments in a blockfile start with a
\fB\&#\fP
(hash) character and end at a new line.
Blank lines are also ignored.
.P
Lines beginning with a
\fC\&~\fP
(tilde) character are taken to be
exceptions:\" ijbfaq.html#exceptions
a
\s-2URL\s0
blocked by previous patterns that matches the rest of
the line is let through. (The last match wins.)
.P
Patterns
may contain
\s-2POSIX\s0
regular expressions\" ijbfaq.html#regex
provided the
\fBjunkbuster\fP
was compiled with this option
(the default in Version 2.0 on).
The idiom
\fC\&/*.*/ad\fP
can then be used
to match any
\s-2URL\s0
containing
\fC\&/ad\fP
(such as
\fC\&http://nomatterwhere.com/images/advert/g3487.gif\fP
for example).
These expressions
don't work\" ijbman.html#substring
in the domain part.
.P
In version 1.3 and later
the blockfile and cookiefile are checked for changes before each request.
.TP
.\" anchor: o_w wafer
\fI-w NAME=VALUE\fP (Old) wafer \fINAME=VALUE\fP (New)
Specifies a pair to be sent as a cookie with every request
to the server.\" ijbfaq.html#wafers
(Such boring cookies are called
\fI\&wafers\fP.)
This option may be called more than once to generate multiple wafers.
The original
Netscape specification
prohibited
semi-colons, commas and white space;
these characters will be
\s-2URL\s0-encoded
if used in wafers.
The Path and Domain attributes are not currently supported.
.TP
.\" anchor: o_c cookiefile
\fI-c cookiefile\fP (Old) cookiefile \fIcookiefile\fP (New)
Enforce the cookie management policy specified in the
\fI\&cookiefile.\fP
.\" anchor: java
If this option is not used all cookies are silently crunched,
so that users who never want cookies aren't bothered by browsers
asking whether each cookie should be accepted.
However, cookies can
still get through\" ijbfaq.html#breakthrough
via
JavaScript\" links.html#javascript
and
\s-2SSL\s0,
so alerts should be left on.
.P
In Version 1.2 and later
this option must be followed by a
filename\" ijbfaq.html#crumble
containing instructions on which sites are allowed to
receive and set cookies.
.\" anchor: drop
By default cookies are dropped in both the browser's request
and the server's response, unless the
\s-2URL\s0
requested matches an entry in the
\fI\&cookiefile\fP.
The matching algorithm is the same as for the blockfile.
A leading
\fC\&>\fP
character allows
server-bound\" ijbfaq.html#directional
cookies only;
a
\fC\&<\fP
allows only browser-bound cookies;
a
\fC\&~\fP
character stops cookies in
both directions.\" ijbfaq.html#crumble
Thus a cookiefile containing a single line with the two characters
\fC\&>*\fP
will pass on all cookies to servers but not give any new ones to the browser.
.TP
.\" anchor: o_j jarfile
\fI-j jarfile\fP (Old) jarfile \fIjarfile\fP (New)
All Set-cookie attempts by the server are
logged\" ijbfaq.html#jar
to
\fI\&jarfile\fP.
If no wafer is specified,
one containing a
canned notice\" ijbfaq.html#notice
(the 
\fI\&vanilla wafer\fP)
is added as an alert to the server
unless the
suppress-vanilla-wafer\" ijbman.html#suppress-vanilla-wafer
option is invoked.
.TP
.\" anchor: o_v suppress-vanilla-wafer
\fI-v\fP (Old) suppress-vanilla-wafer \fI\fP (New)
Suppress the vanilla wafer.
.TP
.\" anchor: o_t from
\fI-t from\fP (Old) from \fIfrom\fP (New)
If the browser
discloses an email address\" ijbfaq.html#from
in the
\fB\&FROM\fP
header (most don't),
replace it with
\fI\&from.\fP
If
\fI\&from\fP
is set to
\fB\&.\fP
(the period character)
the
\fB\&FROM\fP
is passed to the server unchanged.
The default is to delete the
\fB\&FROM\fP
header.
.TP
.\" anchor: o_r referer
\fI-r referer\fP (Old) referer \fIreferer\fP (New)
Whenever the browser discloses the
\s-2URL\s0
that
led to\" ijbfaq.html#referer
the current request,
replace it with
\fI\&referer.\fP
If
\fI\&referer\fP
is set to
\fB\&.\fP
(period)
the 
\s-2URL\s0
is passed to the server unchanged.
In 
Version 1.4
and later, if referer is set to 
\fB\&@\fP
(at) the
\s-2URL\s0
is sent in cases where the cookiefile
specifies that a cookie would be sent.
(No way to send bogus referers selectively is provided.)
The default is to delete Referer.
.P
Version 2.0 also accepts the spelling
\fC\&referrer\fP,
which most dictionaries consider correct.
.TP
.\" anchor: o_u user-agent
\fI-u user-agent\fP (Old) user-agent \fIuser-agent\fP (New)
Information disclosed by the browser
about itself\" ijbfaq.html#agent
is replaced with the value
\fI\&user-agent.\fP
If
\fI\&user-agent\fP
is set to
\fB\&.\fP
(period)
the
\fB\&User-Agent\fP
header is passed to the server unchanged,
along with any
\fB\&UA\fP
headers produced by
\s-2MS-IE\s0
(which would otherwise be deleted).
In 
Version 1.4
and later, if
\fI\&user-agent\fP
is set to
\fB\&@\fP
(at) these headers are sent unchanged in cases where the cookiefile
specifies that a cookie would be sent,
otherwise only default
\fB\&User-Agent\fP
header is sent.
That default
is Mozilla/3.0 (Netscape)
with an unremarkable
Macintosh\" ijbfaq.html#infer
configuration.
If used with a browser less advanced than Mozilla/3.0 or IE-3, the default
may encourage pages containing extensions that confuse the browser.
.TP
.\" anchor: o_h listen-address
\fI-h [host][:port]\fP (Old) listen-address \fI[host][:port]\fP (New)
If
\fI\&host\fP
is specified,
bind the
\fBjunkbuster\fP
to that
\s-2IP\s0
address.
If a
\fI\&port\fP
is specified, use it.
The default
port
is 8000;
the default host is
\fC\&localhost\fP.
Before Version 2.0.2,
the default was to bind to all 
\s-2IP\s0
addresses
(\fB\&INADDR_ANY\fP);
but this has been restricted to
\fB\&localhost\fP
to avoid unintended security breaches.
(To open the proxy to all, use the line
.br
.ti +0.25i
\fB\&listen-address :8000\fP
.br
in the configuration file.)
.TP
.\" anchor: o_f forwardfile
\fI-f forward_host[:port]\fP (Old) forwardfile \fIforwardfile\fP (New)
Version 1.X required all
\s-2HTTP\s0
requests from the client to be forwarded to the same destination.
Version 2.0 takes its routing specification from a
\fI\&forwardfile\fP,