--- a/xml/en/docs/http/ngx_http_upstream_module.xml
+++ b/xml/en/docs/http/ngx_http_upstream_module.xml
@@ -11,8 +11,9 @@
 <para>
 The <literal>ngx_http_upstream_module</literal> module
 allows to define groups of servers that can be referenced
-from the <link doc="ngx_http_proxy_module.xml" id="proxy_pass"/> and
-<link doc="ngx_http_fastcgi_module.xml" id="fastcgi_pass"/> directives.
+from the <link doc="ngx_http_proxy_module.xml" id="proxy_pass"/>,
+<link doc="ngx_http_fastcgi_module.xml" id="fastcgi_pass"/>, and
+<link doc="ngx_http_memcached_module.xml" id="memcached_pass"/> directives.
 </para>
 
 </section>
@@ -44,15 +45,147 @@ 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;
+}
+</example>
+</para>
+
+<para>
+By default, requests are distributed between servers using a
+weighted round-robin balancing method.
+In the above example, each 7 requests will be distributed as follows:
+5 requests to <literal>backend1.example.com</literal>
+and one request to each of second and third servers.
+If an error occurs when communicating with the server, a 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 be returned the result of contacting the last server.
+</para>
+
+</directive>
+
+
+<directive name="server">
+<syntax><value>address</value> [<value>parameters</value>]</syntax>
+<default/>
+<context>upstream</context>
+
+<para>
+Defines an <value>address</value> and other <value>parameters</value>
+of the server.
+An address can be specified as a domain name or IP address,
+and an optional port, or as a UNIX-domain socket path
+specified after the “<literal>unix:</literal>” prefix.
+If port is not specified, the port 80 is used.
+A domain name that resolves to several IP addresses essentially defines
+multiple servers.
+</para>
+
+<para>
+The following parameters can be defined:
+<list type="tag">
+
+<tag-name><literal>weight</literal>=<value>number</value></tag-name>
+<tag-desc>
+sets a weight of the server, by default 1.
+</tag-desc>
+
+<tag-name><literal>max_fails</literal>=<value>number</value></tag-name>
+<tag-desc>
+sets a number of unsuccessful attempts to communicate with the server
+during a time set by the <literal>fail_timeout</literal> parameter
+after which it will be considered down for a period of time also set
+by the <literal>fail_timeout</literal> parameter.
+By default, the number of unsuccessful attempts is set to 1.
+A value of zero disables accounting of attempts.
+What is considered to be an unsuccessful attempt is configured by the
+<link doc="ngx_http_proxy_module.xml" id="proxy_next_upstream"/>,
+<link doc="ngx_http_fastcgi_module.xml" id="fastcgi_next_upstream"/>, and
+<link doc="ngx_http_memcached_module.xml" id="memcached_next_upstream"/>
+directives.
+The <literal>http_404</literal> state is not considered
+an unsuccessful attempt.
+</tag-desc>
+
+<tag-name><literal>fail_timeout</literal>=<value>time</value></tag-name>
+<tag-desc>
+sets
+<list type="bullet">
+
+<listitem>
+a time during which the specified number of unsuccessful attempts to
+communicate with the server should happen for the server to be
+considered down;
+</listitem>
+
+<listitem>
+and a period of time the server will be considered down.
+</listitem>
+
+</list>
+By default, timeout is set to 10 seconds.
+</tag-desc>
+
+<tag-name><literal>backup</literal></tag-name>
+<tag-desc>
+marks the server as a backup server.
+It will be passed requests when the primary servers are down.
+</tag-desc>
+
+<tag-name><literal>down</literal></tag-name>
+<tag-desc>
+marks the server as permanently down; used along with
+the <link id="ip_hash"/> directive.
+</tag-desc>
+
+</list>
+</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:8080 backup;
+}
+</example>
+</para>
+
+</directive>
+
+
 <directive name="ip_hash">
 <syntax/>
 <default/>
 <context>upstream</context>
 
 <para>
-Specifies that a group should use a balancing method where requests
+Specifies that a group should use a load balancing method where requests
 are distributed between servers based on client IP addresses.
-A class C network containing the client IP address is used as a hashing key.
+The first three octets of the client IPv4 address
+are used as a hashing key.
 The method ensures that requests of the same client will always be
 passed to the same server except when this server is considered down
 in which case client requests will be passed to another server and
@@ -82,7 +215,7 @@ upstream backend {
 <para>
 <note>
 Until version 1.3.1 it was not possible to specify a weight for
-servers using the <literal>ip_hash</literal> balancing method.
+servers using the <literal>ip_hash</literal> load balancing method.
 </note>
 </para>
 
@@ -196,13 +329,13 @@ server {
 
 <para>
 <note>
-When using load balancer modules other than the default
+When using load balancer methods other than the default
 round-robin, it is necessary to activate them before
 the <literal>keepalive</literal> directive.
 </note>
 
 <note>
-SCGI and uwsgi protocols do not define keepalive connections.
+SCGI and uwsgi protocols do not have a notion of keepalive connections.
 </note>
 </para>
 
@@ -216,133 +349,11 @@ SCGI and uwsgi protocols do not define k
 <appeared-in>1.3.1</appeared-in>
 
 <para>
-Specifies that a group should use a balancing method where a request
+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 a
-weighted round-robin fashion.
-</para>
-
-</directive>
-
-
-<directive name="server">
-<syntax><value>name</value> [<value>parameters</value>]</syntax>
-<default/>
-<context>upstream</context>
-
-<para>
-Sets a <value>name</value> and other <value>parameters</value> of the server.
-A <value>name</value> can be a domain name, an address, a port, or a
-path of the UNIX-domain socket.
-If a domain name resolves to several addresses, all of them are used.
-<list type="tag">
-
-<tag-name><literal>weight</literal>=<value>number</value></tag-name>
-<tag-desc>
-sets a weight of the server, by default 1.
-</tag-desc>
-
-<tag-name><literal>max_fails</literal>=<value>number</value></tag-name>
-<tag-desc>
-sets a number of unsuccessful attempts to communicate with the server
-during a time set by the <literal>fail_timeout</literal> parameter
-after which it will be considered down for a period of time also set
-by the <literal>fail_timeout</literal> parameter.
-By default, the number of unsuccessful attempts is set to 1.
-A value of zero disables accounting of attempts.
-What is considered to be an unsuccessful attempt is configured by the
-<link doc="ngx_http_proxy_module.xml" id="proxy_next_upstream"/>
-and <link doc="ngx_http_fastcgi_module.xml" id="fastcgi_next_upstream"/>
-directives.
-The <literal>http_404</literal> state is not considered
-an unsuccessful attempt.
-</tag-desc>
-
-<tag-name><literal>fail_timeout</literal>=<value>time</value></tag-name>
-<tag-desc>
-sets
-<list type="bullet">
-
-<listitem>
-a time during which the specified number of unsuccessful attempts to
-communicate with the server should happen for the server to be
-considered down;
-</listitem>
-
-<listitem>
-and a period of time the server will be considered down.
-</listitem>
-
-</list>
-By default, timeout is set to 10 seconds.
-</tag-desc>
-
-<tag-name><literal>backup</literal></tag-name>
-<tag-desc>
-marks the server as a backup server.
-It will be passed requests when the primary servers are down.
-</tag-desc>
-
-<tag-name><literal>down</literal></tag-name>
-<tag-desc>
-marks the server as permanently down; used along with
-the <link id="ip_hash"/> directive.
-</tag-desc>
-
-</list>
-</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:8080 backup;
-}
-</example>
-</para>
-
-</directive>
-
-
-<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 used simultaneously.
-</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;
-}
-</example>
-</para>
-
-<para>
-Requests are distributed between servers in a
-weighted round-robin fashion.
-In the above example, each 7 requests will be distributed as follows:
-5 requests to <literal>backend1.example.com</literal>
-and one request to each of second and third servers.
-If an error occurs when communicating with the server, a 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 be returned the result of contacting the last server.
+If there are several such servers, they are tried using a
+weighted round-robin balancing method.
 </para>
 
 </directive>