copy from xml/en/docs/http/ngx_http_upstream_module.xml
copy to xml/en/docs/http/ngx_http_upstream_hc_module.xml
--- a/xml/en/docs/http/ngx_http_upstream_module.xml
+++ b/xml/en/docs/http/ngx_http_upstream_hc_module.xml
@@ -1,27 +1,30 @@
 <?xml version="1.0"?>
 
 <!--
-  Copyright (C) Igor Sysoev
   Copyright (C) Nginx, Inc.
   -->
 
 <!DOCTYPE module SYSTEM "../../../../dtd/module.dtd">
 
-<module name="Module ngx_http_upstream_module"
-        link="/en/docs/http/ngx_http_upstream_module.html"
+<module name="Module ngx_http_upstream_hc_module"
+        link="/en/docs/http/ngx_http_upstream_hc_module.html"
         lang="en"
-        rev="59">
+        rev="1">
 
 <section id="summary">
 
 <para>
-The <literal>ngx_http_upstream_module</literal> module
-is used to define groups of servers that can be referenced
-by the <link doc="ngx_http_proxy_module.xml" id="proxy_pass"/>,
-<link doc="ngx_http_fastcgi_module.xml" id="fastcgi_pass"/>,
-<link doc="ngx_http_uwsgi_module.xml" id="uwsgi_pass"/>,
-<link doc="ngx_http_scgi_module.xml" id="scgi_pass"/>, and
-<link doc="ngx_http_memcached_module.xml" id="memcached_pass"/> directives.
+The <literal>ngx_http_upstream_hc_module</literal> module
+allows enabling periodic health checks of the servers in a
+<link doc="ngx_http_upstream_module.xml" id="upstream">group</link>
+referenced in the surrounding location.
+</para>
+
+<para>
+<note>
+This module is available as part of our
+<commercial_version>commercial subscription</commercial_version>.
+</note>
 </para>
 
 </section>
@@ -31,38 +34,12 @@ by the <link doc="ngx_http_proxy_module.
 
 <para>
 <example>
-upstream <emphasis>backend</emphasis> {
-    server backend1.example.com       weight=5;
-    server backend2.example.com:8080;
-    server unix:/tmp/backend3;
-
-    server backup1.example.com:8080   backup;
-    server backup2.example.com:8080   backup;
-}
-
-server {
-    location / {
-        proxy_pass http://<emphasis>backend</emphasis>;
-    }
-}
-</example>
-</para>
-
-<para>
-Dynamically configurable group,
-available as part of our
-<commercial_version>commercial subscription</commercial_version>:
-<example>
-resolver 10.0.0.1;
-
-upstream <emphasis>dynamic</emphasis> {
+upstream dynamic {
     zone upstream_dynamic 64k;
 
     server backend1.example.com      weight=5;
     server backend2.example.com:8080 fail_timeout=5s slow_start=30s;
     server 192.0.2.1                 max_fails=3;
-    server backend3.example.com      resolve;
-    server backend4.example.com      service=http resolve;
 
     server backup1.example.com:8080  backup;
     server backup2.example.com:8080  backup;
@@ -70,7 +47,7 @@ upstream <emphasis>dynamic</emphasis> {
 
 server {
     location / {
-        proxy_pass http://<emphasis>dynamic</emphasis>;
+        proxy_pass http://dynamic;
         health_check;
     }
 }
@@ -82,665 +59,6 @@ server {
 
 <section id="directives" name="Directives">
 
-<directive name="upstream">
-<syntax block="yes"><value>name</value></syntax>
-<default/>
-<context>http</context>
-
-<para>
-Defines a group of servers.
-Servers can listen on different ports.
-In addition, servers listening on TCP and UNIX-domain sockets
-can be mixed.
-</para>
-
-<para>
-Example:
-<example>
-upstream backend {
-    server backend1.example.com weight=5;
-    server 127.0.0.1:8080       max_fails=3 fail_timeout=30s;
-    server unix:/tmp/backend3;
-
-    server backup1.example.com  backup;
-}
-</example>
-</para>
-
-<para>
-By default, requests are distributed between the servers using a
-weighted round-robin balancing method.
-In the above example, each 7 requests will be distributed as follows:
-5 requests go to <literal>backend1.example.com</literal>
-and one request to each of the second and third servers.
-If an error occurs during communication with a server, the request will
-be passed to the next server, and so on until all of the functioning
-servers will be tried.
-If a successful response could not be obtained from any of the servers,
-the client will receive the result of the communication with the last server.
-</para>
-
-</directive>
-
-
-<directive name="server">
-<syntax><value>address</value> [<value>parameters</value>]</syntax>
-<default/>
-<context>upstream</context>
-
-<para>
-Defines the <value>address</value> and other <value>parameters</value>
-of a server.
-The address can be specified as a domain name or IP address,
-with an optional port, or as a UNIX-domain socket path
-specified after the “<literal>unix:</literal>” prefix.
-If a port is not specified, the port 80 is used.
-A domain name that resolves to several IP addresses defines
-multiple servers at once.
-</para>
-
-<para>
-The following parameters can be defined:
-<list type="tag">
-
-<tag-name id="weight">
-<literal>weight</literal>=<value>number</value>
-</tag-name>
-<tag-desc>
-sets the weight of the server, by default, 1.
-</tag-desc>
-
-<tag-name id="max_conns">
-<literal>max_conns</literal>=<value>number</value>
-</tag-name>
-<tag-desc>
-limits the maximum <value>number</value> of simultaneous active
-connections to the proxied server (1.11.5).
-Default value is zero, meaning there is no limit.
-If the server group does not reside in the <link id="zone">shared memory</link>,
-the limitation works per each worker process.
-<note>
-If <link id="keepalive">idle keepalive</link> connections,
-multiple <link doc="../ngx_core_module.xml" id="worker_processes">workers</link>,
-and the <link id="zone">shared memory</link> are enabled,
-the total number of active and idle connections to the proxied server
-may exceed the <literal>max_conns</literal> value.
-</note>
-<note>
-Since version 1.5.9 and prior to version 1.11.5,
-this parameter was available as part of our
-<commercial_version>commercial subscription</commercial_version>.
-</note>
-</tag-desc>
-
-<tag-name id="max_fails">
-<literal>max_fails</literal>=<value>number</value>
-</tag-name>
-<tag-desc>
-sets the number of unsuccessful attempts to communicate with the server
-that should happen in the duration set by the <literal>fail_timeout</literal>
-parameter to consider the server unavailable for a duration also set by the
-<literal>fail_timeout</literal> parameter.
-By default, the number of unsuccessful attempts is set to 1.
-The zero value disables the accounting of attempts.
-What is considered an unsuccessful attempt is defined by the
-<link doc="ngx_http_proxy_module.xml" id="proxy_next_upstream"/>,
-<link doc="ngx_http_fastcgi_module.xml" id="fastcgi_next_upstream"/>,
-<link doc="ngx_http_uwsgi_module.xml" id="uwsgi_next_upstream"/>,
-<link doc="ngx_http_scgi_module.xml" id="scgi_next_upstream"/>, and
-<link doc="ngx_http_memcached_module.xml" id="memcached_next_upstream"/>
-directives.
-</tag-desc>
-
-<tag-name id="fail_timeout">
-<literal>fail_timeout</literal>=<value>time</value>
-</tag-name>
-<tag-desc>
-sets
-<list type="bullet">
-
-<listitem>
-the time during which the specified number of unsuccessful attempts to
-communicate with the server should happen to consider the server unavailable;
-</listitem>
-
-<listitem>
-and the period of time the server will be considered unavailable.
-</listitem>
-
-</list>
-By default, the parameter is set to 10 seconds.
-</tag-desc>
-
-<tag-name id="backup">
-<literal>backup</literal>
-</tag-name>
-<tag-desc>
-marks the server as a backup server.
-It will be passed requests when the primary servers are unavailable.
-</tag-desc>
-
-<tag-name id="down">
-<literal>down</literal>
-</tag-name>
-<tag-desc>
-marks the server as permanently unavailable.
-</tag-desc>
-
-</list>
-</para>
-
-<para>
-Additionally,
-the following parameters are available as part of our
-<commercial_version>commercial subscription</commercial_version>:
-<list type="tag">
-
-<tag-name id="resolve">
-<literal>resolve</literal>
-</tag-name>
-<tag-desc>
-monitors changes of the IP addresses
-that correspond to a domain name of the server,
-and automatically modifies the upstream configuration
-without the need of restarting nginx (1.5.12).
-The server group must reside in the <link id="zone">shared memory</link>.
-<para>
-In order for this parameter to work,
-the <link doc="ngx_http_core_module.xml" id="resolver"/> directive
-must be specified in the
-<link doc="ngx_http_core_module.xml" id="http"/> block.
-Example:
-<example>
-http {
-    resolver 10.0.0.1;
-
-    upstream u {
-        zone ...;
-        ...
-        server example.com resolve;
-    }
-}
-</example>
-</para>
-</tag-desc>
-
-<tag-name id="route">
-<literal>route</literal>=<value>string</value>
-</tag-name>
-<tag-desc>
-sets the server route name.
-</tag-desc>
-
-<tag-name id="service">
-<literal>service</literal>=<value>name</value>
-</tag-name>
-<tag-desc>
-enables resolving of DNS
-<link url="https://tools.ietf.org/html/rfc2782">SRV</link>
-records and sets the service <value>name</value> (1.9.13).
-In order for this parameter to work, it is necessary to specify
-the <link id="resolve"/> parameter for the server
-and specify a hostname without a port number.
-<para>
-If the service name does not contain a dot (“<literal>.</literal>”), then
-the <link url="https://tools.ietf.org/html/rfc2782">RFC</link>-compliant name
-is constructed
-and the TCP protocol is added to the service prefix.
-For example, to look up the
-<literal>_http._tcp.backend.example.com</literal> SRV record,
-it is necessary to specify the directive:
-<example>
-server backend.example.com service=http resolve;
-</example>
-If the service name contains one or more dots, then the name is constructed
-by joining the service prefix and the server name.
-For example, to look up the <literal>_http._tcp.backend.example.com</literal>
-and <literal>server1.backend.example.com</literal> SRV records,
-it is necessary to specify the directives:
-<example>
-server backend.example.com service=_http._tcp resolve;
-server example.com service=server1.backend resolve;
-</example>
-</para>
-
-<para>
-Highest-priority SRV records
-(records with the same lowest-number priority value)
-are resolved as primary servers,
-the rest of SRV records are resolved as backup servers.
-If the <link id="backup"/> parameter is specified for the server,
-high-priority SRV records are resolved as backup servers,
-the rest of SRV records are ignored.
-</para>
-</tag-desc>
-
-<tag-name id="slow_start">
-<literal>slow_start</literal>=<value>time</value>
-</tag-name>
-<tag-desc>
-sets the <value>time</value> during which the server will recover its weight
-from zero to a nominal value, when unhealthy server becomes
-<link id="health_check">healthy</link>,
-or when the server becomes available after a period of time
-it was considered <link id="fail_timeout">unavailable</link>.
-Default value is zero, i.e. slow start is disabled.
-<note>
-The parameter cannot be used along with the
-<link id="hash"/> and <link id="ip_hash"/> load balancing methods.
-</note>
-</tag-desc>
-
-</list>
-</para>
-
-<para>
-<note>
-If there is only a single server in a group, <literal>max_fails</literal>,
-<literal>fail_timeout</literal> and <literal>slow_start</literal> parameters
-are ignored, and such a server will never be considered unavailable.
-</note>
-</para>
-
-</directive>
-
-
-<directive name="zone">
-<syntax><value>name</value> [<value>size</value>]</syntax>
-<default/>
-<context>upstream</context>
-<appeared-in>1.9.0</appeared-in>
-
-<para>
-Defines the <value>name</value> and <value>size</value> of the shared
-memory zone that keeps the group’s configuration and run-time state that are
-shared between worker processes.
-Several groups may share the same zone.
-In this case, it is enough to specify the <value>size</value> only once.
-</para>
-
-<para>
-Additionally,
-as part of our <commercial_version>commercial subscription</commercial_version>,
-such groups allow changing the group membership
-or modifying the settings of a particular server
-without the need of restarting nginx.
-The configuration is accessible via a special location
-handled by
-<link doc="ngx_http_upstream_conf_module.xml" id="upstream_conf"/>.
-</para>
-
-</directive>
-
-
-<directive name="state">
-<syntax><value>file</value></syntax>
-<default/>
-<context>upstream</context>
-<appeared-in>1.9.7</appeared-in>
-
-<para>
-Specifies a <value>file</value> that keeps the state
-of the dynamically configurable group.
-</para>
-
-<para>
-Examples:
-<example>
-state /var/lib/nginx/state/servers.conf; # path for Linux
-state /var/db/nginx/state/servers.conf;  # path for FreeBSD
-</example>
-</para>
-
-<para>
-The state is currently limited to the list of servers with their parameters.
-The file is read when parsing the configuration and is updated each time
-the upstream configuration is
-<link doc="ngx_http_upstream_conf_module.xml" id="upstream_conf">changed</link>.
-Changing the file content directly should be avoided.
-The directive cannot be used
-along with the <link id="server"/> directive.
-</para>
-
-<para>
-<note>
-Changes made during
-<link doc="../control.xml" id="reconfiguration">configuration reload</link>
-or <link doc="../control.xml" id="upgrade">binary upgrade</link>
-can be lost.
-</note>
-</para>
-
-<para>
-<note>
-This directive is available as part of our
-<commercial_version>commercial subscription</commercial_version>.
-</note>
-</para>
-
-</directive>
-
-
-<directive name="hash">
-<syntax><value>key</value> [<literal>consistent</literal>]</syntax>
-<default/>
-<context>upstream</context>
-<appeared-in>1.7.2</appeared-in>
-
-<para>
-Specifies a load balancing method for a server group
-where the client-server mapping is based on the hashed <value>key</value> value.
-The <value>key</value> can contain text, variables, and their combinations.
-Note that adding or removing a server from the group
-may result in remapping most of the keys to different servers.
-The method is compatible with the
-<link url="http://search.cpan.org/perldoc?Cache%3A%3AMemcached">Cache::Memcached</link>
-Perl library.
-</para>
-
-<para>
-If the <literal>consistent</literal> parameter is specified
-the <link url="http://www.last.fm/user/RJ/journal/2007/04/10/392555/">ketama</link>
-consistent hashing method will be used instead.
-The method ensures that only a few keys
-will be remapped to different servers
-when a server is added to or removed from the group.
-This helps to achieve a higher cache hit ratio for caching servers.
-The method is compatible with the
-<link url="http://search.cpan.org/perldoc?Cache%3A%3AMemcached%3A%3AFast">Cache::Memcached::Fast</link>
-Perl library with the <value>ketama_points</value> parameter set to 160.
-</para>
-
-</directive>
-
-
-<directive name="ip_hash">
-<syntax/>
-<default/>
-<context>upstream</context>
-
-<para>
-Specifies that a group should use a load balancing method where requests
-are distributed between servers based on client IP addresses.
-The first three octets of the client IPv4 address, or the entire IPv6 address,
-are used as a hashing key.
-The method ensures that requests from the same client will always be
-passed to the same server except when this server is unavailable.
-In the latter case client requests will be passed to another server.
-Most probably, it will always be the same server as well.
-<note>
-IPv6 addresses are supported starting from versions 1.3.2 and 1.2.2.
-</note>
-</para>
-
-<para>
-If one of the servers needs to be temporarily removed, it should
-be marked with the <literal>down</literal> parameter in
-order to preserve the current hashing of client IP addresses.
-</para>
-
-<para>
-Example:
-<example>
-upstream backend {
-    ip_hash;
-
-    server backend1.example.com;
-    server backend2.example.com;
-    server backend3.example.com <emphasis>down</emphasis>;
-    server backend4.example.com;
-}
-</example>
-</para>
-
-<para>
-<note>
-Until versions 1.3.1 and 1.2.2, it was not possible to specify a weight for
-servers using the <literal>ip_hash</literal> load balancing method.
-</note>
-</para>
-
-</directive>
-
-
-<directive name="keepalive">
-<syntax><value>connections</value></syntax>
-<default/>
-<context>upstream</context>
-<appeared-in>1.1.4</appeared-in>
-
-<para>
-Activates the cache for connections to upstream servers.
-</para>
-
-<para>
-The <value>connections</value> parameter sets the maximum number of
-idle keepalive connections to upstream servers that are preserved in
-the cache of each worker process.
-When this number is exceeded, the least recently used connections
-are closed.
-<note>
-It should be particularly noted that the <literal>keepalive</literal> directive
-does not limit the total number of connections to upstream servers
-that an nginx worker process can open.
-The <value>connections</value> parameter should be set to a number small enough
-to let upstream servers process new incoming connections as well.
-</note>
-</para>
-
-<para>
-Example configuration of memcached upstream with keepalive connections:
-<example>
-upstream memcached_backend {
-    server 127.0.0.1:11211;
-    server 10.0.0.2:11211;
-
-    keepalive 32;
-}
-
-server {
-    ...
-
-    location /memcached/ {
-        set $memcached_key $uri;
-        memcached_pass memcached_backend;
-    }
-
-}
-</example>
-</para>
-
-<para>
-For HTTP, the <link doc="ngx_http_proxy_module.xml" id="proxy_http_version"/>
-directive should be set to “<literal>1.1</literal>”
-and the <header>Connection</header> header field should be cleared:
-<example>
-upstream http_backend {
-    server 127.0.0.1:8080;
-
-    keepalive 16;
-}
-
-server {
-    ...
-
-    location /http/ {
-        proxy_pass http://http_backend;
-        proxy_http_version 1.1;
-        proxy_set_header Connection "";
-        ...
-    }
-}
-</example>
-</para>
-
-<para>
-<note>
-Alternatively, HTTP/1.0 persistent connections can be used by passing the
-<header>Connection: Keep-Alive</header> header field to an upstream server,
-though this method is not recommended.
-</note>
-</para>
-
-<para>
-For FastCGI servers, it is required to set
-<link doc="ngx_http_fastcgi_module.xml" id="fastcgi_keep_conn"/>
-for keepalive connections to work:
-<example>
-upstream fastcgi_backend {
-    server 127.0.0.1:9000;
-
-    keepalive 8;
-}
-
-server {
-    ...
-
-    location /fastcgi/ {
-        fastcgi_pass fastcgi_backend;
-        fastcgi_keep_conn on;
-        ...
-    }
-}
-</example>
-</para>
-
-<para>
-<note>
-When using load balancer methods other than the default
-round-robin method, it is necessary to activate them before
-the <literal>keepalive</literal> directive.
-</note>
-
-<note>
-SCGI and uwsgi protocols do not have a notion of keepalive connections.
-</note>
-</para>
-
-</directive>
-
-
-<directive name="ntlm">
-<syntax/>
-<default/>
-<context>upstream</context>
-<appeared-in>1.9.2</appeared-in>
-
-<para>
-Allows proxying requests with
-<link url="https://en.wikipedia.org/wiki/Integrated_Windows_Authentication">NTLM
-Authentication</link>.
-The upstream connection is bound to the client connection
-once the client sends a request with the <header>Authorization</header>
-header field value
-starting with “<literal>Negotiate</literal>” or “<literal>NTLM</literal>”.
-Further client requests will be proxied through the same upstream connection,
-keeping the authentication context.
-</para>
-
-<para>
-In order for NTLM authentication to work,
-it is necessary to enable keepalive connections to upstream servers.
-The <link doc="ngx_http_proxy_module.xml" id="proxy_http_version"/>
-directive should be set to “<literal>1.1</literal>”
-and the <header>Connection</header> header field should be cleared:
-<example>
-upstream http_backend {
-    server 127.0.0.1:8080;
-
-    ntlm;
-}
-
-server {
-    ...
-
-    location /http/ {
-        proxy_pass http://http_backend;
-        proxy_http_version 1.1;
-        proxy_set_header Connection "";
-        ...
-    }
-}
-</example>
-</para>
-
-<para>
-<note>
-When using load balancer methods other than the default
-round-robin method, it is necessary to activate them before
-the <literal>ntlm</literal> directive.
-</note>
-</para>
-
-<para>
-<note>
-This directive is available as part of our
-<commercial_version>commercial subscription</commercial_version>.
-</note>
-</para>
-
-</directive>
-
-
-<directive name="least_conn">
-<syntax/>
-<default/>
-<context>upstream</context>
-<appeared-in>1.3.1</appeared-in>
-<appeared-in>1.2.2</appeared-in>
-
-<para>
-Specifies that a group should use a load balancing method where a request
-is passed to the server with the least number of active connections,
-taking into account weights of servers.
-If there are several such servers, they are tried in turn using a
-weighted round-robin balancing method.
-</para>
-
-</directive>
-
-
-<directive name="least_time">
-<syntax>
-    <literal>header</literal> |
-    <literal>last_byte</literal>
-    [<literal>inflight</literal>]</syntax>
-<default/>
-<context>upstream</context>
-<appeared-in>1.7.10</appeared-in>
-
-<para>
-Specifies that a group should use a load balancing method where a request
-is passed to the server with the least average response time and
-least number of active connections, taking into account weights of servers.
-If there are several such servers, they are tried in turn using a
-weighted round-robin balancing method.
-</para>
-
-<para>
-If the <literal>header</literal> parameter is specified,
-time to receive the
-<link id="var_upstream_header_time">response header</link> is used.
-If the <literal>last_byte</literal> parameter is specified,
-time to receive the <link id="var_upstream_response_time">full response</link>
-is used.
-If the <literal>inflight</literal> parameter is specified (1.11.6),
-incomplete requests are also taken into account.
-<note>
-Prior to version 1.11.6, incomplete requests were taken into account by default.
-</note>
-</para>
-
-<para>
-<note>
-This directive is available as part of our
-<commercial_version>commercial subscription</commercial_version>.
-</note>
-</para>
-
-</directive>
-
-
 <directive name="health_check">
 <syntax>[<value>parameters</value>]</syntax>
 <default/>
@@ -748,7 +66,8 @@ This directive is available as part of o
 
 <para>
 Enables periodic health checks of the servers in a
-<link id="upstream">group</link> referenced in the surrounding location.
+<link doc="ngx_http_upstream_module.xml" id="upstream">group</link>
+referenced in the surrounding location.
 </para>
 
 <para>
@@ -823,7 +142,8 @@ By default, the response should have sta
 <tag-desc>
 defines the port used when connecting to a server
 to perform a health check (1.9.7).
-By default, equals the <link id="server"/> port.
+By default, equals the
+<link doc="ngx_http_upstream_module.xml" id="server"/> port.
 </tag-desc>
 
 </list>
@@ -878,7 +198,8 @@ and contain “<literal>Welcome to nginx!</literal>” in the body.
 </para>
 
 <para>
-The server group must reside in the <link id="zone">shared memory</link>.
+The server group must reside in the
+<link doc="ngx_http_upstream_module.xml" id="zone">shared memory</link>.
 </para>
 
 <para>
@@ -894,13 +215,6 @@ when used with health checks.
 </note>
 </para>
 
-<para>
-<note>
-This directive is available as part of our
-<commercial_version>commercial subscription</commercial_version>.
-</note>
-</para>
-
 </directive>
 
 
@@ -1027,390 +341,8 @@ match server_ok {
 
 </para>
 
-<para>
-<note>
-This directive is available as part of our
-<commercial_version>commercial subscription</commercial_version>.
-</note>
-</para>
-
-</directive>
-
-
-<directive name="queue">
-<syntax>
-<value>number</value>
-[<literal>timeout</literal>=<value>time</value>]</syntax>
-<default/>
-<context>upstream</context>
-<appeared-in>1.5.12</appeared-in>
-
-<para>
-If an upstream server cannot be selected immediately
-while processing a request,
-the request will be placed into the queue.
-The directive specifies the maximum number of requests that can be in the queue
-at the same time.
-If the queue is filled up,
-or the server to pass the request to cannot be selected within
-the time period specified in the <literal>timeout</literal> parameter,
-the <http-status code="502" text="Bad Gateway"/>
-error will be returned to the client.
-</para>
-
-<para>
-The default value of the <literal>timeout</literal> parameter is 60 seconds.
-</para>
-
-<para>
-<note>
-When using load balancer methods other than the default
-round-robin method, it is necessary to activate them before
-the <literal>queue</literal> directive.
-</note>
-
-<note>
-This directive is available as part of our
-<commercial_version>commercial subscription</commercial_version>.
-</note>
-</para>
-
-</directive>
-
-
-<directive name="sticky">
-<syntax>
-    <literal>cookie</literal> <value>name</value>
-    [<literal>expires=</literal><value>time</value>]
-    [<literal>domain=</literal><value>domain</value>]
-    [<literal>httponly</literal>]
-    [<literal>secure</literal>]
-    [<literal>path=</literal><value>path</value>]</syntax>
-<syntax>
-    <literal>route</literal> <value>$variable</value> ...</syntax>
-<syntax>
-    <literal>learn</literal>
-    <literal>create=</literal><value>$variable</value>
-    <literal>lookup=</literal><value>$variable</value>
-    <literal>zone=</literal><value>name</value>:<value>size</value>
-    [<literal>timeout=</literal><value>time</value>]</syntax>
-<default/>
-<context>upstream</context>
-<appeared-in>1.5.7</appeared-in>
-
-<para>
-Enables session affinity, which causes requests from the same client to be
-passed to the same server in a group of servers.
-Three methods are available:
-<list type="tag">
-<tag-name id="sticky_cookie"><literal>cookie</literal></tag-name>
-<tag-desc>
-
-<para>
-When the <literal>cookie</literal> method is used, information about the
-designated server is passed in an HTTP cookie generated by nginx:
-<example>
-upstream backend {
-    server backend1.example.com;
-    server backend2.example.com;
-
-    sticky cookie srv_id expires=1h domain=.example.com path=/;
-}
-</example>
-</para>
-
-<para>
-A request that comes from a client not yet bound to a particular server
-is passed to the server selected by the configured balancing method.
-Further requests with this cookie will be passed to the designated server.
-If the designated server cannot process a request, the new server is
-selected as if the client has not been bound yet.
-</para>
-
-<para>
-The first parameter sets the name of the cookie to be set or inspected.
-Additional parameters may be as follows:
-<list type="tag">
-
-<tag-name><literal>expires=</literal><value>time</value></tag-name>
-<tag-desc>
-Sets the <value>time</value> for which a browser should keep the cookie.
-The special value <literal>max</literal> will cause the cookie to expire on
-“<literal>31 Dec 2037 23:55:55 GMT</literal>”.
-If the parameter is not specified, it will cause the cookie to expire at
-the end of a browser session.
-</tag-desc>
-
-<tag-name><literal>domain=</literal><value>domain</value></tag-name>
-<tag-desc>
-Defines the <value>domain</value> for which the cookie is set.
-Parameter value can contain variables (1.11.5).
-</tag-desc>
-
-<tag-name><literal>httponly</literal></tag-name>
-<tag-desc>
-Adds the <literal>HttpOnly</literal> attribute to the cookie (1.7.11).
-</tag-desc>
-
-<tag-name><literal>secure</literal></tag-name>
-<tag-desc>
-Adds the <literal>Secure</literal> attribute to the cookie (1.7.11).
-
-</tag-desc>
-
-<tag-name><literal>path=</literal><value>path</value></tag-name>
-<tag-desc>
-Defines the <value>path</value> for which the cookie is set.
-</tag-desc>
-
-</list>
-If any parameters are omitted, the corresponding cookie fields are not set.
-</para>
-</tag-desc>
-
-<tag-name id="sticky_route"><literal>route</literal></tag-name>
-<tag-desc>
-
-<para>
-When the <literal>route</literal> method is used, proxied server assigns
-client a route on receipt of the first request.
-All subsequent requests from this client will carry routing information
-in a cookie or URI.
-This information is compared with the “<literal>route</literal>” parameter
-of the <link id="server"/> directive to identify the server to which the
-request should be proxied.
-If the “<literal>route</literal>” parameter is not specified, the route name
-will be a hexadecimal representation of the MD5 hash of the IP address and port,
-or of the UNIX-domain socket path.
-If the designated server cannot process a request, the new server is
-selected by the configured balancing method as if there is no routing
-information in the request.
-</para>
-
-<para>
-The parameters of the <literal>route</literal> method specify variables that
-may contain routing information.
-The first non-empty variable is used to find the matching server.
-</para>
-
-<para>
-Example:
-<example>
-map $cookie_jsessionid $route_cookie {
-    ~.+\.(?P&lt;route>\w+)$ $route;
-}
-
-map $request_uri $route_uri {
-    ~jsessionid=.+\.(?P&lt;route>\w+)$ $route;
-}
-
-upstream backend {
-    server backend1.example.com route=a;
-    server backend2.example.com route=b;
-
-    sticky route $route_cookie $route_uri;
-}
-</example>
-Here, the route is taken from the “<literal>JSESSIONID</literal>” cookie
-if present in a request.
-Otherwise, the route from the URI is used.
-</para>
-
-</tag-desc>
-
-<tag-name id="sticky_learn"><literal>learn</literal></tag-name>
-<tag-desc>
-<para>
-When the <literal>learn</literal> method (1.7.1) is used, nginx
-analyzes upstream server responses and learns server-initiated sessions
-usually passed in an HTTP cookie.
-<example>
-upstream backend {
-   server backend1.example.com:8080;
-   server backend2.example.com:8081;
-
-   sticky learn
-          create=$upstream_cookie_examplecookie
-          lookup=$cookie_examplecookie
-          zone=client_sessions:1m;
-}
-</example>
-
-In the example, the upstream server creates a session by setting the
-cookie “<literal>EXAMPLECOOKIE</literal>” in the response.
-Further requests with this cookie will be passed to the same server.
-If the server cannot process the request, the new server is
-selected as if the client has not been bound yet.
-</para>
-
-<para>
-The parameters <literal>create</literal> and <literal>lookup</literal>
-specify variables that indicate how new sessions are created and existing
-sessions are searched, respectively.
-Both parameters may be specified more than once, in which case the first
-non-empty variable is used.
-</para>
-
-<para>
-Sessions are stored in a shared memory zone, whose <value>name</value> and
-<value>size</value> are configured by the <literal>zone</literal> parameter.
-One megabyte zone can store about 8000 sessions on the 64-bit platform.
-The sessions that are not accessed during the time specified by the
-<literal>timeout</literal> parameter get removed from the zone.
-By default, <literal>timeout</literal> is set to 10 minutes.
-</para>
-
-</tag-desc>
-</list>
-</para>
-
-<para>
-<note>
-This directive is available as part of our
-<commercial_version>commercial subscription</commercial_version>.
-</note>
-</para>
-
-</directive>
-
-
-<directive name="sticky_cookie_insert">
-<syntax><value>name</value>
-[<literal>expires=</literal><value>time</value>]
-[<literal>domain=</literal><value>domain</value>]
-[<literal>path=</literal><value>path</value>]</syntax>
-<default/>
-<context>upstream</context>
-
-<para>
-This directive is obsolete since version 1.5.7.
-An equivalent
-<link id="sticky"/> directive with a new syntax should be used instead:
-<note>
-<literal>sticky cookie</literal> <value>name</value>
-[<literal>expires=</literal><value>time</value>]
-[<literal>domain=</literal><value>domain</value>]
-[<literal>path=</literal><value>path</value>];
-</note>
-</para>
-
 </directive>
 
 </section>
 
-
-<section id="variables" name="Embedded Variables">
-
-<para>
-The <literal>ngx_http_upstream_module</literal> module
-supports the following embedded variables:
-<list type="tag">
-
-<tag-name id="var_upstream_addr"><var>$upstream_addr</var></tag-name>
-<tag-desc>
-keeps the IP address and port,
-or the path to the UNIX-domain socket of the upstream server.
-If several servers were contacted during request processing,
-their addresses are separated by commas, e.g.
-“<literal>192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock</literal>”.
-If an internal redirect from one server group to another happens,
-initiated by
-<header>X-Accel-Redirect</header> or
-<link doc="ngx_http_core_module.xml" id="error_page"/>,
-then the server addresses from different groups are separated by colons, e.g.
-“<literal>192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80</literal>”.
-</tag-desc>
-
-<tag-name id="var_upstream_bytes_received"><var>$upstream_bytes_received</var></tag-name>
-<tag-desc>
-number of bytes received from an upstream server (1.11.4).
-Values from several connections
-are separated by commas and colons like addresses in the
-<link id="var_upstream_addr">$upstream_addr</link> variable.
-</tag-desc>
-
-<tag-name id="var_upstream_cache_status"><var>$upstream_cache_status</var>
-</tag-name>
-<tag-desc>
-keeps the status of accessing a response cache (0.8.3).
-The status can be either “<literal>MISS</literal>”,
-“<literal>BYPASS</literal>”, “<literal>EXPIRED</literal>”,
-“<literal>STALE</literal>”, “<literal>UPDATING</literal>”,
-“<literal>REVALIDATED</literal>”, or “<literal>HIT</literal>”.
-</tag-desc>
-
-<tag-name id="var_upstream_connect_time"><var>$upstream_connect_time</var>
-</tag-name>
-<tag-desc>
-keeps time spent on establishing a connection with the upstream server (1.9.1);
-the time is kept in seconds with millisecond resolution.
-In case of SSL, includes time spent on handshake.
-Times of several connections
-are separated by commas and colons like addresses in the
-<link id="var_upstream_addr">$upstream_addr</link> variable.
-</tag-desc>
-
-<tag-name id="var_upstream_cookie_"><var>$upstream_cookie_</var><value>name</value>
-</tag-name>
-<tag-desc>
-cookie with the specified <value>name</value> sent by the upstream server
-in the <header>Set-Cookie</header> response header field (1.7.1).
-Only the cookies from the response of the last server are saved.
-</tag-desc>
-
-<tag-name id="var_upstream_header_time"><var>$upstream_header_time</var>
-</tag-name>
-<tag-desc>
-keeps time
-spent on receiving the response header from the upstream server (1.7.10);
-the time is kept in seconds with millisecond resolution.
-Times of several responses
-are separated by commas and colons like addresses in the
-<link id="var_upstream_addr">$upstream_addr</link> variable.
-</tag-desc>
-
-<tag-name id="var_upstream_http_"><var>$upstream_http_</var><value>name</value></tag-name>
-<tag-desc>
-keep server response header fields.
-For example, the <header>Server</header> response header field
-is available through the <var>$upstream_http_server</var> variable.
-The rules of converting header field names to variable names are the same
-as for the variables that start with the
-“<link doc="ngx_http_core_module.xml" id="var_http_">$http_</link>” prefix.
-Only the header fields from the response of the last server are saved.
-</tag-desc>
-
-<tag-name id="var_upstream_response_length"><var>$upstream_response_length</var>
-</tag-name>
-<tag-desc>
-keeps the length of the response obtained from the upstream server (0.7.27);
-the length is kept in bytes.
-Lengths of several responses
-are separated by commas and colons like addresses in the
-<link id="var_upstream_addr">$upstream_addr</link> variable.
-</tag-desc>
-
-<tag-name id="var_upstream_response_time"><var>$upstream_response_time</var>
-</tag-name>
-<tag-desc>
-keeps time spent on receiving the response from the upstream server;
-the time is kept in seconds with millisecond resolution.
-Times of several responses
-are separated by commas and colons like addresses in the
-<link id="var_upstream_addr">$upstream_addr</link> variable.
-</tag-desc>
-
-<tag-name id="var_upstream_status"><var>$upstream_status</var></tag-name>
-<tag-desc>
-keeps status code of the response obtained from the upstream server.
-Status codes of several responses
-are separated by commas and colons like addresses in the
-<link id="var_upstream_addr">$upstream_addr</link> variable.
-</tag-desc>
-
-</list>
-</para>
-
-</section>
-
 </module>