Commit d48345f3 authored by Rainer Jung's avatar Rainer Jung
Browse files

Update transformations. 


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@1004814 13f79535-47bb-0310-9956-ffa450edef68
parent 280dde64

docs/manual/mod/mod_proxy.html.en

+140 −13
Changes for docs/manual/mod/mod_proxy.html.en: 140 added lines, 13 removed lines.
Original line number Diff line number Diff line
@@ -95,6 +95,7 @@ 
<li><img alt="" src="../images/down.gif" /> <a href="#forwardreverse">Forward Proxies and Reverse 

       Proxies/Gateways</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#examples">Basic Examples</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#workers">Workers</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#access">Controlling access to your proxy</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#startup">Slow Startup</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#intranet">Intranet Proxy</a></li>
@@ -168,6 +169,11 @@ 
    <p>In addition, if you wish to have caching enabled, consult

    the documentation from <code class="module"><a href="../mod/mod_cache.html">mod_cache</a></code>.</p>



    <div class="example"><h3>Reverse Proxy</h3><p><code>

    ProxyPass /foo http://foo.example.com/bar<br />

    ProxyPassReverse /foo http://foo.example.com/bar

    </code></p></div>



    <div class="example"><h3>Forward Proxy</h3><p><code>

    ProxyRequests On<br />

    ProxyVia On<br />
@@ -181,19 +187,122 @@ 
    &lt;/Proxy&gt;

    </code></p></div>



    <div class="example"><h3>Reverse Proxy</h3><p><code>

    ProxyRequests Off<br />

    <br />

    &lt;Proxy *&gt;<br />

    </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>

<div class="section">

<h2><a name="workers" id="workers">Workers</a></h2>

      <p>The proxy manages the configuration of origin servers and their

      communication parameters in objects called <dfn>workers</dfn>.

      There are two built-in workers, the default forward proxy worker and the

      default reverse proxy worker. Additional workers can be configured

      explicitly.</p>



      <p>The two default workers have a fixed configuration

      and will be used if no other worker matches the request.

      They do not use HTTP Keep-Alive or connection pooling.

      The TCP connections to the origin server will instead be

      opened and closed for each request.</p>



      <p>Explicitly configured workers are identified by their URL.

      They are usually created and configured using

      <code class="directive"><a href="#proxypass">ProxyPass</a></code> or

      <code class="directive"><a href="#proxypassmatch">ProxyPassMatch</a></code> when used

      for a reverse proxy:</p>



      <div class="example"><p><code>

          ProxyPass /example http://backend.example.com connectiontimeout=5 timeout=30

      </code></p></div>



      <p>This will create a worker associated with the origin server URL

      <code>http://backend.example.com</code> and using the given timeout

      values. When used in a forward proxy, workers are usually defined

      via the <code class="directive"><a href="#proxyset">ProxySet</a></code> directive:</p>



      <div class="example"><p><code>

          ProxySet http://backend.example.com connectiontimeout=5 timeout=30

      </code></p></div>



      <p>or alternatively using <code class="directive"><a href="#proxy">Proxy</a></code>

      and <code class="directive"><a href="#proxyset">ProxySet</a></code>:</p>



      <div class="example"><p><code>

        &lt;Proxy http://backend.example.com&gt;<br />

        <span class="indent">

      Order deny,allow<br />

      Allow from all<br />

          ProxySet connectiontimeout=5 timeout=30

        </span>

    &lt;/Proxy&gt;<br />

    <br />

    ProxyPass /foo http://foo.example.com/bar<br />

    ProxyPassReverse /foo http://foo.example.com/bar

        &lt;/Proxy&gt;

      </code></p></div>



      <p>Using explicitly configured workers in the forward mode is

      not very common, because forward proxies usually communicate with many

      different origin servers. Creating explicit workers for some of the

      origin servers can still be useful, if they are used very often.

      Explicitly configured workers have no concept of forward or reverse

      proxying by themselves. They encapsulate a common concept of

      communication with origin servers. A worker created by

      <code class="directive"><a href="#proxypass">ProxyPass</a></code> for use in a

      reverse proxy will be also used for forward proxy requests whenever

      the URL to the origin server matches the worker URL and vice versa.</p>



      <p>The URL identifying a direct worker is the URL of its

      origin server including any path components given:</p>



      <div class="example"><p><code>

          ProxyPass /examples http://backend.example.com/examples<br />

          ProxyPass /docs http://backend.example.com/docs

      </code></p></div>



      <p>This example defines two different workers, each using a separate

      connection pool and configuration.</p>



      <div class="warning"><h3>Worker Sharing</h3>

        <p>Worker sharing happens if the worker URLs overlap, which occurs when

        the URL of some worker is a leading substring of the URL of another

        worker defined later in the configuration file. In the following example</p>



        <div class="example"><p><code>

            ProxyPass /apps http://backend.example.com/ timeout=60<br />

            ProxyPass /examples http://backend.example.com/examples timeout=10

        </code></p></div>



        <p>the second worker isn't actually created. Instead the first

        worker is used. The benefit is, that there is only one connection pool,

        so connections are more often reused. Note that all configuration attributes

        given explicitly for the later worker and some configuration defaults will

        overwrite the configuration given for the first worker. This will be logged

        as a warning. In the above example the resulting timeout value

        for the URL <code>/apps</code> will be <code>10</code> instead

        of <code>60</code>!</p>



        <p>If you want to avoid worker sharing, sort your worker definitions

        by URL length, starting with the longest worker URLs. If you want to maximize

        worker sharing use the reverse sort order. See also the related warning about

        ordering <code class="directive"><a href="#proxypass">ProxyPass</a></code> directives.</p>



      </div> 



      <p>Explicitly configured workers come in two flavors:

      <dfn>direct workers</dfn> and <dfn>(load) balancer workers</dfn>.

      They support many important configuration attributes which are

      described below in the <code class="directive"><a href="#proxypass">ProxyPass</a></code>

      directive. The same attributes can also be set using

      <code class="directive"><a href="#proxyset">ProxySet</a></code>.</p>



      <p>The set of options available for a direct worker

      depends on the protocol, which is specified in the origin server URL.

      Available protocols include <code>ajp</code>,

      <code>ftp</code>, <code>http</code> and <code>scgi</code>.</p>



      <p>Balancer workers are virtual workers that use direct workers known

      as their members to actually handle the requests. Each balancer can

      have multiple members. When it handles a request, it chooses a member

      based on the configured load balancing algorithm.</p>



      <p>A balancer worker is created if its worker URL uses

      <code>balancer</code> as the protocol scheme.

      The balancer URL uniquely identifies the balancer worker.

      Members are added to a balancer using

      <code class="directive"><a href="#balancermember">BalancerMember</a></code>.</p>



    </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>

<div class="section">

<h2><a name="access" id="access">Controlling access to your proxy</a></h2>
@@ -534,6 +643,10 @@ directly</td></tr> 
    </code></p></div>





<h3>See also</h3>

<ul>

<li><code class="directive"><a href="#proxymatch">&lt;ProxyMatch&gt;</a></code></li>

</ul>

</div>

<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>

<div class="directive-section"><h2><a name="ProxyBadHeader" id="ProxyBadHeader">ProxyBadHeader</a> <a name="proxybadheader" id="proxybadheader">Directive</a></h2>
@@ -698,6 +811,10 @@ proxied resources</td></tr> 
    identical to the <code class="directive"><a href="#proxy">&lt;Proxy&gt;</a></code> directive, except it matches URLs

    using <a class="glossarylink" href="../glossary.html#regex" title="see glossary">regular expressions</a>.</p>



<h3>See also</h3>

<ul>

<li><code class="directive"><a href="#proxy">&lt;Proxy&gt;</a></code></li>

</ul>

</div>

<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>

<div class="directive-section"><h2><a name="ProxyMaxForwards" id="ProxyMaxForwards">ProxyMaxForwards</a> <a name="proxymaxforwards" id="proxymaxforwards">Directive</a></h2>
@@ -783,9 +900,19 @@ through</td></tr> 
    <code>backend.example.com</code> <em>except</em> requests made to

    <code>/mirror/foo/i</code>.</p>



    <div class="note"><h3>Note</h3>

      <p>Order is important: exclusions must come <em>before</em> the

      general <code class="directive">ProxyPass</code> directive.</p>

    <div class="warning"><h3>Ordering ProxyPass Directives</h3>

      <p>The configured <code class="directive"><a href="#proxypass">ProxyPass</a></code>

      and <code class="directive"><a href="#proxypassmatch">ProxyPassMatch</a></code>

      rules are checked in the order of configuration. The first rule that

      matches wins. So usually you should sort conflicting

      <code class="directive"><a href="#proxypass">ProxyPass</a></code> rules starting with the

      longest URLs first. Otherwise later rules for longer URLS will be hidden

      by any earlier rule which uses a leading substring of the URL. Note that

      there is some relation with worker sharing.</p>



      <p>For the same reasons exclusions must come <em>before</em> the

      general <code class="directive">ProxyPass</code> directives.</p>



    </div> 



    <p>As of Apache 2.1, the ability to use pooled connections to a backend

docs/manual/mod/mod_proxy.xml.ja

+1 −1
Changes for docs/manual/mod/mod_proxy.xml.ja: 1 added line, 1 removed line.
Original line number Diff line number Diff line 
<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">

<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>

<!-- English Revision: 421100:910322 (outdated) -->

<!-- English Revision: 421100:1004805 (outdated) -->



<!--

 Licensed to the Apache Software Foundation (ASF) under one or more

docs/manual/mod/mod_proxy_balancer.html.en

+143 −7
Changes for docs/manual/mod/mod_proxy_balancer.html.en: 143 added lines, 7 removed lines.
Original line number Diff line number Diff line
@@ -51,12 +51,15 @@ 
<h3>Topics</h3>

<ul id="topics">

<li><img alt="" src="../images/down.gif" /> <a href="#scheduler">Load balancer scheduler algorithm</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#example">Example of a balancer configuration</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#stickyness">Load balancer stickyness</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#example">Examples of a balancer configuration</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#requests">Request Counting Algorithm</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#traffic">Weighted Traffic Counting Algorithm</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#busyness">Pending Request Counting Algorithm</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#environment">Exported Environment Variables</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#enable">Enabling Balancer Manager Support</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#balancer_manager">Enabling Balancer Manager Support</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#stickyness_implementation">Details on load balancer stickyness</a></li>

<li><img alt="" src="../images/down.gif" /> <a href="#stickyness_troubleshooting">Troubleshooting load balancer stickyness</a></li>

</ul><h3>See also</h3>

<ul class="seealso">

<li><code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code></li>
@@ -70,10 +73,26 @@ 
    Counting. These are controlled via the <code>lbmethod</code> value of

    the Balancer definition. See the <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code> 

    directive for more information.</p>



</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>

<div class="section">

<h2><a name="example" id="example">Example of a balancer configuration</a></h2>

<h2><a name="stickyness" id="stickyness">Load balancer stickyness</a></h2>

    

    <p>The balancer supports stickyness. When a request is proxied

    to some back-end, then all following requests from the same user

    should be proxied to the same back-end. Many load balancers implement

    this feature via a table that maps client IP addresses to back-ends.

    This approach is transparent to clients and back-ends, but suffers

    from some problems: unequal load distribution if clients are themselves

    hidden behind proxies, stickyness errors when a client uses a dynamic

    IP address that changes during a session and loss of stickyness, if the

    mapping table overflows.</p>

    <p>The module <code class="module"><a href="../mod/mod_proxy_balancer.html">mod_proxy_balancer</a></code> implements stickyness

    on top of two alternative means: cookies and URL encoding. Providing the

    cookie can be either done by the back-end or by the Apache web server

    itself. The URL encoding is usually done on the back-end.</p>

</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>

<div class="section">

<h2><a name="example" id="example">Examples of a balancer configuration</a></h2>

    

    <p>Before we dive into the technical details, here's an example of

    how you might use <code class="module"><a href="../mod/mod_proxy_balancer.html">mod_proxy_balancer</a></code> to provide
@@ -87,6 +106,22 @@ 
    &lt;/Proxy&gt;<br />

    ProxyPass /test balancer://mycluster

    </code></p></div>



    <p>Another example of how to provide load balancing with stickyness

    using <code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code>, even if the back-end server does

    not set a suitable session cookie:

    </p>



    <div class="example"><p><code>

    Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/"

           env=BALANCER_ROUTE_CHANGED<br />

    &lt;Proxy balancer://mycluster&gt;<br />

    BalancerMember http://192.168.1.50:80 route=1<br />

    BalancerMember http://192.168.1.51:80 route=2<br />

    ProxySet stickysession=ROUTEID<br />

    &lt;/Proxy&gt;<br />

    ProxyPass /test balancer://mycluster

    </code></p></div>

</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>

<div class="section">

<h2><a name="requests" id="requests">Request Counting Algorithm</a></h2>
@@ -321,8 +356,8 @@ candidate lbstatus -= total factor</code></pre></div> 
    

    <dt><var><a name="balancer_session_sticky" id="balancer_session_sticky">BALANCER_SESSION_STICKY</a></var></dt>

    <dd>

    <p>This is assigned the <var>stickysession</var> value used in the current

    request.  It is the cookie or parameter name used for sticky sessions</p>

    <p>This is assigned the <var>stickysession</var> value used for the current

    request.  It is the name of the cookie or request parameter used for sticky sessions</p>

    </dd>
@@ -366,7 +401,7 @@ candidate lbstatus -= total factor</code></pre></div> 


</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>

<div class="section">

<h2><a name="enable" id="enable">Enabling Balancer Manager Support</a></h2>

<h2><a name="balancer_manager" id="balancer_manager">Enabling Balancer Manager Support</a></h2>

    

    <p>This module <em>requires</em> the service of 

    <code class="module"><a href="../mod/mod_status.html">mod_status</a></code>.
@@ -396,6 +431,107 @@ candidate lbstatus -= total factor</code></pre></div> 
    <p>You can now access load balancer manager by using a Web browser

    to access the page

    <code>http://your.server.name/balancer-manager</code></p>

</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>

<div class="section">

<h2><a name="stickyness_implementation" id="stickyness_implementation">Details on load balancer stickyness</a></h2>

    

    <p>When using cookie based stickyness, you need to configure the

    name of the cookie that contains the information about which back-end

    to use. This is done via the <var>stickysession</var> attribute added

    to either <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code> or

    <code class="directive"><a href="../mod/mod_proxy.html#proxyset">ProxySet</a></code>. The name of

    the cookie is case-sensitive. The balancer extracts the value of the

    cookie and looks for a member worker with <var>route</var> equal

    to that value. The <var>route</var> must also be set in either

    <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code> or

    <code class="directive"><a href="../mod/mod_proxy.html#proxyset">ProxySet</a></code>. The cookie can either

    be set by the back-end, or as shown in the above

    <a href="#example">example</a> by the Apache web server itself.</p>

    <p>Some back-ends use a slightly different form of stickyness cookie,

    for instance Apache Tomcat. Tomcat adds the name of the Tomcat instance

    to the end of its session id cookie, separated with a dot (<code>.</code>)

    from the session id. Thus if the Apache web server finds a dot in the value

    of the stickyness cookie, it only uses the part behind the dot to search

    for the route. In order to let Tomcat know about its instance name, you

    need to set the attribute <code>jvmRoute</code> inside the Tomcat

    configuration file <code>conf/server.xml</code> to the value of the

    <var>route</var> of the worker that connects to the respective Tomcat.

    The name of the session cookie used by Tomcat (and more generally by Java

    web applications based on servlets) is <code>JSESSIONID</code>

    (upper case) but can be configured to something else.</p>

    <p>The second way of implementing stickyness is URL encoding.

    The web server searches for a query parameter in the URL of the request.

    The name of the parameter is specified again using <var>stickysession</var>.

    The value of the parameter is used to lookup a member worker with <var>route</var>

    equal to that value. Since it is not easy to extract and manipulate all

    URL links contained in responses, generally the work of adding the parameters

    to each link is done by the back-end generating the content.

    In some cases it might be feasible doing

    this via the web server using <code class="module"><a href="../mod/mod_substitute.html">mod_substitute</a></code>.

    This can have negative impact on performance though.</p>

    <p>The Java standards implement URL encoding slightly different. They use

    a path info appended to the URL using a semicolon (<code>;</code>)

    as the separator and add the session id behind. As in the cookie case,

    Apache Tomcat can include the configured <code>jvmRoute</code> in this path

    info. To let Apache find this sort of path info, you neet to set

    <code>scolonpathdelim</code> to <code>On</code> in

    <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code> or

    <code class="directive"><a href="../mod/mod_proxy.html#proxyset">ProxySet</a></code>.</p>

    <p>Finally you can support cookies and URL encoding at the same time, by

    configuring the name of the cookie and the name of the URL parameter

    separated by a vertical bar (<code>|</code>) as in the following example:</p>

    <div class="example"><p><code>

    ProxyPass /test balancer://mycluster stickysession=JSESSIONID|jsessionid scolonpathdelim=On

    &lt;Proxy balancer://mycluster&gt;<br />

    BalancerMember http://192.168.1.50:80 route=node1<br />

    BalancerMember http://192.168.1.51:80 route=node2<br />

    &lt;/Proxy&gt;<br />

    </code></p></div>

    <p>If the cookie and the request parameter both provide routing information

    for the same request, the information from the request parameter is used.</p>

</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>

<div class="section">

<h2><a name="stickyness_troubleshooting" id="stickyness_troubleshooting">Troubleshooting load balancer stickyness</a></h2>

    

    <p>If you experience stickyness errors, e.g. users loose their

    application sessions and need to login again, you first want to

    check whether this is because the back-ends are sometimes unavailable

    or whether your configuration is wrong. To find out about possible

    stability problems with the back-ends, check your Apache error log

    for proxy error messages.</p>

    <p>To verify your configuration, first check, whether the stickyness

    is based on a cookie or on URL encoding. Next step would be logging

    the appropriate data in the access log by using an enhanced

    <code class="directive"><a href="../mod/mod_log_config.html#logformat">LogFormat</a></code>.

    The following fields are useful:</p>

    <dl>

    <dt><code>%{MYCOOKIE}C</code></dt>

    <dd>The value contained in the cookie with name <code>MYCOOKIE</code>.

    The name should be the same given in the <var>stickysession</var>

    attribute.</dd>

    <dt><code>%{Set-Cookie}o</code></dt>

    <dd>This logs any cookie set by the back-end. You can track,

    whether the back-end sets the session cookie you expect, and

    to which value it is set.</dd>

    <dt><code>%{BALANCER_SESSION_STICKY}e</code></dt>

    <dd>The name of the cookie or request parameter used

    to lookup the routing information.</dd>

    <dt><code>%{BALANCER_SESSION_ROUTE}e</code></dt>

    <dd>The route information found in the request.</dd>

    <dt><code>%{BALANCER_WORKER_ROUTE}e</code></dt>

    <dd>The route of the worker chosen.</dd>

    <dt><code>%{BALANCER_ROUTE_CHANGED}e</code></dt>

    <dd>Set to <code>1</code> if the route in the request

    is different from the route of the worker, i.e.

    the request couldn't be handled sticky.</dd>

    </dl>

    <p>Common reasons for loss of session are session timeouts,

    which are usually configurable on the back-end server.</p>

    <p>The balancer also logs detailed information about handling

    stickyness to the error log, if the log level is set to

    <code>debug</code> or higher. This is an easy way to

    troubleshoot stickyness problems, but the log volume might

    be to high for production servers under high load.</p>

</div>

</div>

<div class="bottomlang">

docs/manual/mod/mod_proxy_balancer.xml.ja

+1 −1
Changes for docs/manual/mod/mod_proxy_balancer.xml.ja: 1 added line, 1 removed line.
Original line number Diff line number Diff line 
<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">

<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>

<!-- English Revision: 153116:896075 (outdated) -->

<!-- English Revision: 153116:1004808 (outdated) -->



<!--

 Licensed to the Apache Software Foundation (ASF) under one or more