The ProxyDispatcher is a filter that allows some rule to be applied to some given request before the HTTP client side API emits out a request. The set of rules can be extended in Java, check below for the currently defined rules.
Warning: When configuring that filter along with Jigsaw's proxy
module, you will need to manually edit Jigsaw's property file (usually
config/http-server.props, otherwise, you know what
we are talking about).
The basic syntax for the ProxyDispatcher rule file is captured by the following BNF:
rule-file := (record)* record := comment | rule comment := '#' <any chars up to EOL> rule := rule-lhs SPACES rule-rhs rule-lhs := token | default default := 'default' rule-rhs := forbid | direct | proxy | authorization forbid := 'forbid' direct := 'direct' proxy := 'proxy' SPACES url authorization := 'authorization' SPACES user SPACES password user := token password := token EOL := '\r' | '\r\n' | 'n' SPACES := (' '|'\t')+
A sample ProxyDispatcher rule file looks like:
# Sample ProxyDispatcher rule file # -------------------------------- # Make all access to US through us.proxy.com edu proxy http://us.proxy.com:8080/ org proxy http://us.proxy.com:8080/ # Accesses to french site are direct (no proxy) fr direct # Accesses to 18.59.*.* network are direct 18.59 direct # Accesses to the protected site gets decorated with auth infos: www.protected.com authorization joe-user joe-password # Forbid accesses to some sites www.evilsite.com forbid # force all other request to go through world.proxy.org DEFAULT proxy http://world.proxy.org:8080/
The rule matching algorithm matches the host name part of urls, or the
numeric part, if the address is numeric, no name resolution.
The matching algorithm tries to find the best match, starting with the most
significant part of the URL (in www.foo.com, com is the most significant part,
in 188.8.131.52, 18 is the most significant part) and then walking toward the
best match, hence host names are implicitly "terminated" by * if you will.
In the above example, any
www.foo.fr/x/y would be handled by:
fr foo www
frfoo (not found)
In that case the rule found at step 2 is the most specific, and gets applied.
This examples is self explanatory, and illustrates all the rules currently handled by the filter. When used in conjunction with the ICP filter, you can get a very powerful caching hierarchy.
Note also that the underlying implementation of the rule matching algorithm allows a large number of rules which can lead to a big static routing table.
The ProxyDispatcher defines the following properties:
$Id: w3c.www.protocol.http.proxy.ProxyDispatcher.html,v 1.4 1997/09/22 09:02:23 ylafon Exp $