--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"\r
+ "http://www.w3.org/TR/REC-html40/loose.dtd">\r
+<html>\r
+<head>\r
+<title>The ProxyDispatcherFilter administration guide.</title>\r
+</head>\r
+<body bgcolor="#FFFFFF">\r
+\r
+<p><a href="../../../../WWW" target="_top_"><img\r
+src="../../../Icons/WWW/w3c_home" alt="W3C" border="0" height="48"\r
+width="72"></a> <a href="../../../Jigsaw" target="_top_"><img\r
+src="../../../Icons/jigsaw" alt="Jigsaw" border="0" height="49"\r
+width="212"></a>\r
+ \r
+ \r
+<hr noshade size="1">\r
+\r
+<h1>ProxyDispatcher</h1>\r
+\r
+The ProxyDispatcher is a filter that allows some rule to be applied to some\r
+given request before the HTTP client side API emits out a request. The set of\r
+rules can be extended in <b>Java</b>, check <a href="#rules">below</a> for the\r
+currently defined rules.\r
+\r
+<p><b>Warning</b>: When configuring that filter along with <b>Jigsaw</b>'s\r
+proxy module, you will need to manually edit <b>Jigsaw</b>'s property file\r
+(usually found at <tt>config/http-server.props</tt>, otherwise, you know what\r
+we are talking about).</p>\r
+\r
+<h3><a name="rules"></a>ProxyDispatcher Rules</h3>\r
+\r
+The basic syntax for the ProxyDispatcher <i>rule file</i> is captured by the\r
+following BNF:\r
+<pre>rule-file := (record)*\r
+record := comment | rule\r
+comment := '#' <any chars up to EOL>\r
+rule := rule-lhs SPACES rule-rhs\r
+rule-lhs := token | default\r
+default := 'default'\r
+rule-rhs := forbid | direct | proxy | authorization | proxyauth\r
+forbid := 'forbid'\r
+direct := 'direct'\r
+proxy := 'proxy' SPACES url\r
+authorization := 'authorization' SPACES user SPACES password\r
+proxyauth := 'proxyauth' SPACES user SPACES password SPACES url\r
+user := token\r
+password := token\r
+EOL := '\r' | '\r\n' | 'n'\r
+SPACES := (' '|'\t')+</pre>\r
+\r
+A sample ProxyDispatcher rule file looks like:\r
+<pre># Sample ProxyDispatcher rule file\r
+# --------------------------------\r
+\r
+# Make all access to US through us.proxy.com\r
+edu proxy http://us.proxy.com:8080/\r
+org proxy http://us.proxy.com:8080/\r
+\r
+# Accesses to french site are direct (no proxy)\r
+fr direct\r
+\r
+# Accesses to 18.59.*.* network are direct\r
+18.59 direct\r
+\r
+# Accesses to the protected site gets decorated with auth infos:\r
+www.protected.com authorization joe-user joe-password\r
+\r
+# Forbid accesses to some sites\r
+\r
+www.evilsite.com forbid\r
+\r
+# Access this site through myproxy.com with proxy authentication\r
+www.somesite.org proxyauth joe-user joe-password http://myproxy.com:8008/\r
+\r
+# force all other request to go through world.proxy.org\r
+DEFAULT proxy http://world.proxy.org:8080/</pre>\r
+\r
+The rule matching algorithm matches the host name part of urls, or the numeric\r
+part, if the address is numeric, no name resolution. The matching algorithm\r
+tries to find the best match, starting with the most significant part of the\r
+URL (in www.foo.com, com is the most significant part, in 18.23.0.22, 18 is\r
+the most significant part) and then walking toward the best match, hence host\r
+names are implicitly "terminated" by * if you will. In the above\r
+example, any access to <tt>www.foo.fr/x/y</tt> would be handled by:\r
+<ol>\r
+<li>\r
+Reverting the host name components: <tt>fr foo www</tt>\r
+</li>\r
+<li>\r
+Looking for a match on fr (found)\r
+</li>\r
+<li>\r
+Looking for a match on <tt>fr </tt>foo (not found)\r
+</li>\r
+</ol>\r
+\r
+In that case the rule found at step 2 is the most specific, and gets applied.\r
+\r
+<p>This examples is self explanatory, and illustrates all the rules currently\r
+handled by the filter. When used in conjunction with the <a\r
+href="org.w3c.www.protocol.http.icp.ICPFilter.html">ICP filter</a>, you can\r
+get a very powerful caching hierarchy.</p>\r
+\r
+<p>Note also that the underlying implementation of the rule matching algorithm\r
+allows a large number of rules which can lead to a big static routing\r
+table.</p>\r
+\r
+<p></p>\r
+<hr noshade size="1">\r
+\r
+\r
+<h2>Properties</h2>\r
+\r
+The ProxyDispatcher defines the following properties:\r
+<ul>\r
+<li>\r
+<a\r
+href="#w3c.www.protocol.http.proxy.rules">org.w3c.www.protocol.http.proxy.rules</a>\r
+</li>\r
+<li>\r
+<a\r
+href="#w3c.www.protocol.http.proxy.debug">org.w3c.www.protocol.http.proxy.debug</a>\r
+</li>\r
+</ul>\r
+<hr noshade size="1">\r
+\r
+\r
+<a\r
+name="w3c.www.protocol.http.proxy.rules"></a><tt>org.w3c.www.protocol.http.proxy.rules</tt>\r
+<dl>\r
+<dt><i>semantics</i></dt>\r
+<dd>\r
+The location of the rules for the ProxyDispatcher filter. The <i>rule file</i>\r
+expresses a rule to be applied when fetching a document, see the <a\r
+href="#rules">rule syntax</a> for more informations.\r
+</dd>\r
+<dt><i>type</i></dt>\r
+<dd>\r
+This property can be either a full URL or a filename.\r
+</dd>\r
+<dt><i>default value</i></dt>\r
+<dd>\r
+This property has no default value, and <b>must</b> be set for the filter to\r
+be activated.\r
+</dd>\r
+</dl>\r
+<hr noshade size="1">\r
+\r
+\r
+<a\r
+name="w3c.www.protocol.http.proxy.debug"></a><tt>org.w3c.www.protocol.http.proxy.debug</tt>\r
+<dl>\r
+<dt><i>semantics</i></dt>\r
+<dd>\r
+Should the filter emit debugging traces ? When set to <b>true</b> this will\r
+make the filter tells which rule it applies on which fetched URL.\r
+</dd>\r
+<dt><i>type</i></dt>\r
+<dd>\r
+A boolean property\r
+</dd>\r
+<dt><i>default value</i></dt>\r
+<dd>\r
+This property defaults to <b>false</b>.\r
+</dd>\r
+</dl>\r
+<hr noshade size="1">\r
+\r
+\r
+<p><i><a href="mailto:ylafon@w3.org">ylafon</a></i> <br>\r
+<i>$Id: w3c.www.protocol.http.proxy.ProxyDispatcher.html,v 1.4 1997/09/22\r
+09:02:23 ylafon Exp $</i></p>\r
+</body>\r
+</html>\r
projects / Benchmarks_CSolver.git / blobdiff