# HG changeset patch # User Yaroslav Zhuravlev # Date 1490898404 -10800 # Node ID 88477c5d275108b76f8350b70211434e6371ac16 # Parent dbf6f05f0808011b01e1ee81e3142647c0621981 Moved "health_check" and "match" to ngx_http_upstream_hc_module. diff -r dbf6f05f0808 -r 88477c5d2751 xml/en/GNUmakefile --- a/xml/en/GNUmakefile Wed Mar 29 22:55:20 2017 +0300 +++ b/xml/en/GNUmakefile Thu Mar 30 21:26:44 2017 +0300 @@ -86,6 +86,7 @@ http/ngx_http_sub_module \ http/ngx_http_upstream_module \ http/ngx_http_upstream_conf_module \ + http/ngx_http_upstream_hc_module \ http/ngx_http_userid_module \ http/ngx_http_uwsgi_module \ http/ngx_http_v2_module \ diff -r dbf6f05f0808 -r 88477c5d2751 xml/en/docs/http/ngx_http_status_module.xml --- a/xml/en/docs/http/ngx_http_status_module.xml Wed Mar 29 22:55:20 2017 +0300 +++ b/xml/en/docs/http/ngx_http_status_module.xml Thu Mar 30 21:26:44 2017 +0300 @@ -9,7 +9,7 @@ + rev="15">
@@ -562,7 +562,7 @@ checks The total number of -health check +health check requests made. @@ -581,7 +581,7 @@ Boolean indicating if the last health check request was successful and passed -tests. +tests. diff -r dbf6f05f0808 -r 88477c5d2751 xml/en/docs/http/ngx_http_upstream_hc_module.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/en/docs/http/ngx_http_upstream_hc_module.xml Thu Mar 30 21:26:44 2017 +0300 @@ -0,0 +1,348 @@ + + + + + + + + +
+ + +The ngx_http_upstream_hc_module module +allows enabling periodic health checks of the servers in a +group +referenced in the surrounding location. + + + + +This module is available as part of our +commercial subscription. + + + +
+ + +
+ + + +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 backup1.example.com:8080 backup; + server backup2.example.com:8080 backup; +} + +server { + location / { + proxy_pass http://dynamic; + health_check; + } +} + + + +
+ + +
+ + +[parameters] + +location + + +Enables periodic health checks of the servers in a +group +referenced in the surrounding location. + + + +The following optional parameters are supported: + + + +interval=time + + +sets the interval between two consecutive health checks, +by default, 5 seconds. + + + +jitter=time + + +sets the time within which +each health check will be randomly delayed, +by default, there is no delay. + + + +fails=number + + +sets the number of consecutive failed health checks of a particular server +after which this server will be considered unhealthy, +by default, 1. + + + +passes=number + + +sets the number of consecutive passed health checks of a particular server +after which the server will be considered healthy, +by default, 1. + + + +uri=uri + + +defines the URI used in health check requests, +by default, “/”. + + + +mandatory + + +sets the initial “checking” state for a server +until the first health check is completed (1.11.7). +If the parameter is not specified, +the server will be initially considered healthy. + + + +match=name + + +specifies the match block configuring the tests that a +response should pass in order for a health check to pass. +By default, the response should have status code 2xx or 3xx. + + + +port=number + + +defines the port used when connecting to a server +to perform a health check (1.9.7). +By default, equals the + port. + + + + + + +For example, + +location / { + proxy_pass http://backend; + health_check; +} + +will send “/” requests to each +server in the backend group every five seconds. +If any communication error or timeout occurs, or a +proxied server responds with the status code other than +2xx or 3xx, the health check will fail, and the server will +be considered unhealthy. +Client requests are not passed to unhealthy servers +and servers in the “checking” state. + + + +Health checks can be configured to test the status code of a response, +presence of certain header fields and their values, +and the body contents. +Tests are configured separately using the directive +and referenced in the match parameter. +For example: + +http { + server { + ... + location / { + proxy_pass http://backend; + health_check match=welcome; + } + } + + match welcome { + status 200; + header Content-Type = text/html; + body ~ "Welcome to nginx!"; + } +} + +This configuration shows that in order for a health check to pass, the response +to a health check request should succeed, +have status 200, content type “text/html”, +and contain “Welcome to nginx!” in the body. + + + +The server group must reside in the +shared memory. + + + +If several health checks are defined for the same group of servers, +a single failure of any check will make the corresponding server be +considered unhealthy. + + + + +Please note that most of the variables will have empty values +when used with health checks. + + + + + + + +name + +http + + +Defines the named test set used to verify responses to health check requests. + + + +The following items can be tested in a response: + + +status 200; +status is 200 + +status ! 500; +status is not 500 + +status 200 204; +status is 200 or 204 + +status ! 301 302; +status is neither 301 nor 302 + +status 200-399; +status is in the range from 200 to 399 + +status ! 400-599; +status is not in the range from 400 to 599 + +status 301-303 307; +status is either 301, 302, 303, or 307 + + + + + +header Content-Type = text/html; + +header contains
Content-Type
+with value text/html +
+ +header Content-Type != text/html; + +header contains
Content-Type
+with value other than text/html +
+ +header Connection ~ close; + +header contains
Connection
+with value matching regular expression close +
+ +header Connection !~ close; + +header contains
Connection
+with value not matching regular expression close +
+ +header Host; +header contains
Host
+ +header ! X-Accel-Redirect; +header lacks
X-Accel-Redirect
+ +
+ + + +body ~ "Welcome to nginx!"; + +body matches regular expression “Welcome to nginx!” + + +body !~ "Welcome to nginx!"; + +body does not match regular expression “Welcome to nginx!” + + + +
+ + +If several tests are specified, +the response matches only if it matches all tests. + +Only the first 256k of the response body are examined. + + + + +Examples: + +# status is 200, content type is "text/html", +# and body contains "Welcome to nginx!" +match welcome { + status 200; + header Content-Type = text/html; + body ~ "Welcome to nginx!"; +} + + + +# status is not one of 301, 302, 303, or 307, and header does not have "Refresh:" +match not_redirect { + status ! 301-303 307; + header ! Refresh; +} + + + +# status ok and not in maintenance mode +match server_ok { + status 200-399; + body !~ "maintenance mode"; +} + + + + +
+ +
+ +
diff -r dbf6f05f0808 -r 88477c5d2751 xml/en/docs/http/ngx_http_upstream_module.xml --- a/xml/en/docs/http/ngx_http_upstream_module.xml Wed Mar 29 22:55:20 2017 +0300 +++ b/xml/en/docs/http/ngx_http_upstream_module.xml Thu Mar 30 21:26:44 2017 +0300 @@ -10,7 +10,7 @@ + rev="60">
@@ -49,7 +49,8 @@ -Dynamically configurable group, +Dynamically configurable group with +periodic health checks is available as part of our commercial subscription: @@ -321,7 +322,7 @@ sets the time during which the server will recover its weight from zero to a nominal value, when unhealthy server becomes -healthy, +healthy, or when the server becomes available after a period of time it was considered unavailable. Default value is zero, i.e. slow start is disabled. @@ -741,302 +742,6 @@ - -[parameters] - -location - - -Enables periodic health checks of the servers in a -group referenced in the surrounding location. - - - -The following optional parameters are supported: - - - -interval=time - - -sets the interval between two consecutive health checks, -by default, 5 seconds. - - - -jitter=time - - -sets the time within which -each health check will be randomly delayed, -by default, there is no delay. - - - -fails=number - - -sets the number of consecutive failed health checks of a particular server -after which this server will be considered unhealthy, -by default, 1. - - - -passes=number - - -sets the number of consecutive passed health checks of a particular server -after which the server will be considered healthy, -by default, 1. - - - -uri=uri - - -defines the URI used in health check requests, -by default, “/”. - - - -mandatory - - -sets the initial “checking” state for a server -until the first health check is completed (1.11.7). -If the parameter is not specified, -the server will be initially considered healthy. - - - -match=name - - -specifies the match block configuring the tests that a -response should pass in order for a health check to pass. -By default, the response should have status code 2xx or 3xx. - - - -port=number - - -defines the port used when connecting to a server -to perform a health check (1.9.7). -By default, equals the port. - - - - - - -For example, - -location / { - proxy_pass http://backend; - health_check; -} - -will send “/” requests to each -server in the backend group every five seconds. -If any communication error or timeout occurs, or a -proxied server responds with the status code other than -2xx or 3xx, the health check will fail, and the server will -be considered unhealthy. -Client requests are not passed to unhealthy servers -and servers in the “checking” state. - - - -Health checks can be configured to test the status code of a response, -presence of certain header fields and their values, -and the body contents. -Tests are configured separately using the directive -and referenced in the match parameter. -For example: - -http { - server { - ... - location / { - proxy_pass http://backend; - health_check match=welcome; - } - } - - match welcome { - status 200; - header Content-Type = text/html; - body ~ "Welcome to nginx!"; - } -} - -This configuration shows that in order for a health check to pass, the response -to a health check request should succeed, -have status 200, content type “text/html”, -and contain “Welcome to nginx!” in the body. - - - -The server group must reside in the shared memory. - - - -If several health checks are defined for the same group of servers, -a single failure of any check will make the corresponding server be -considered unhealthy. - - - - -Please note that most of the variables will have empty values -when used with health checks. - - - - - -This directive is available as part of our -commercial subscription. - - - - - - - -name - -http - - -Defines the named test set used to verify responses to health check requests. - - - -The following items can be tested in a response: - - -status 200; -status is 200 - -status ! 500; -status is not 500 - -status 200 204; -status is 200 or 204 - -status ! 301 302; -status is neither 301 nor 302 - -status 200-399; -status is in the range from 200 to 399 - -status ! 400-599; -status is not in the range from 400 to 599 - -status 301-303 307; -status is either 301, 302, 303, or 307 - - - - - -header Content-Type = text/html; - -header contains
Content-Type
-with value text/html -
- -header Content-Type != text/html; - -header contains
Content-Type
-with value other than text/html -
- -header Connection ~ close; - -header contains
Connection
-with value matching regular expression close -
- -header Connection !~ close; - -header contains
Connection
-with value not matching regular expression close -
- -header Host; -header contains
Host
- -header ! X-Accel-Redirect; -header lacks
X-Accel-Redirect
- -
- - - -body ~ "Welcome to nginx!"; - -body matches regular expression “Welcome to nginx!” - - -body !~ "Welcome to nginx!"; - -body does not match regular expression “Welcome to nginx!” - - - -
- - -If several tests are specified, -the response matches only if it matches all tests. - -Only the first 256k of the response body are examined. - - - - -Examples: - -# status is 200, content type is "text/html", -# and body contains "Welcome to nginx!" -match welcome { - status 200; - header Content-Type = text/html; - body ~ "Welcome to nginx!"; -} - - - -# status is not one of 301, 302, 303, or 307, and header does not have "Refresh:" -match not_redirect { - status ! 301-303 307; - header ! Refresh; -} - - - -# status ok and not in maintenance mode -match server_ok { - status 200-399; - body !~ "maintenance mode"; -} - - - - - - -This directive is available as part of our -commercial subscription. - - - -
- - number diff -r dbf6f05f0808 -r 88477c5d2751 xml/en/docs/index.xml --- a/xml/en/docs/index.xml Wed Mar 29 22:55:20 2017 +0300 +++ b/xml/en/docs/index.xml Thu Mar 30 21:26:44 2017 +0300 @@ -8,7 +8,7 @@
@@ -445,6 +445,11 @@ + +ngx_http_upstream_hc_module + + + ngx_http_userid_module diff -r dbf6f05f0808 -r 88477c5d2751 xml/ru/GNUmakefile --- a/xml/ru/GNUmakefile Wed Mar 29 22:55:20 2017 +0300 +++ b/xml/ru/GNUmakefile Thu Mar 30 21:26:44 2017 +0300 @@ -75,6 +75,7 @@ http/ngx_http_sub_module \ http/ngx_http_upstream_module \ http/ngx_http_upstream_conf_module \ + http/ngx_http_upstream_hc_module \ http/ngx_http_userid_module \ http/ngx_http_uwsgi_module \ http/ngx_http_v2_module \ diff -r dbf6f05f0808 -r 88477c5d2751 xml/ru/docs/http/ngx_http_status_module.xml --- a/xml/ru/docs/http/ngx_http_status_module.xml Wed Mar 29 22:55:20 2017 +0300 +++ b/xml/ru/docs/http/ngx_http_status_module.xml Thu Mar 30 21:26:44 2017 +0300 @@ -9,7 +9,7 @@ + rev="15">
@@ -564,7 +564,7 @@ checks Суммарное число запросов -проверки +проверки работоспособности. @@ -583,7 +583,7 @@ Логическое значение, означающее, была ли последняя проверка работоспособности удачной и удовлетворял ли ответ заданным -тестам. +тестам. diff -r dbf6f05f0808 -r 88477c5d2751 xml/ru/docs/http/ngx_http_upstream_hc_module.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/ru/docs/http/ngx_http_upstream_hc_module.xml Thu Mar 30 21:26:44 2017 +0300 @@ -0,0 +1,350 @@ + + + + + + + + +
+ + +Модуль ngx_http_upstream_hc_module +позволяет активировать периодические проверки работоспособности серверов в +группе, +указанной в содержащем location. + + + + +Модуль доступен как часть +коммерческой подписки. + + + +
+ + +
+ + + +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 backup1.example.com:8080 backup; + server backup2.example.com:8080 backup; +} + +server { + location / { + proxy_pass http://dynamic; + health_check; + } +} + + + +
+ + +
+ + +[параметры] + +location + + +Активирует периодические проверки работоспособности серверов в +группе, +указанной в содержащем location. + + + +Могут быть заданы следующие необязательные параметры: + + + +interval=время + + +задаёт интервал между двумя последовательными проверками, +по умолчанию 5 секунд. + + + +jitter=время + + +задаёт время, в пределах которого +случайным образом задерживается каждая проверка, +по умолчанию задержки нет. + + + +fails=число + + +задаёт число последовательных неуспешных проверок для определённого сервера, +после которых сервер будет считаться неработоспособным, +по умолчанию 1. + + + +passes=число + + +задаёт число последовательных успешных проверок для определённого сервера, +после которых сервер будет считаться работоспособным, +по умолчанию 1. + + + +uri=uri + + +задаёт URI, используемый в запросах, проверяющих работоспособность, +по умолчанию “/”. + + + +mandatory + + +устанавливает исходное состояние “checking” для сервера +до завершения первой проверки работоспособности (1.11.7). +Если параметр не указан, +то исходно сервер будет считаться работоспособным. + + + +match=имя + + +указывает на блок match с условиями, которым должен +удовлетворять ответ, чтобы результат проверки считался успешным. +По умолчанию код ответа должен быть 2xx или 3xx. + + + +port=число + + +задаёт порт, используемый при подключении к серверу +для проверки его работоспособности (1.9.7). +По умолчанию совпадает с портом +сервера. + + + + + + +В примере + +location / { + proxy_pass http://backend; + health_check; +} + +каждому серверу группы backend +с интервалом в 5 секунд посылаются запросы “/”. +Если происходит ошибка или таймаут при работе с сервером, или +код ответа проксируемого сервера не равен +2xx или 3xx, проверка считается неуспешной и сервер +признаётся неработоспособным. +На неработоспособные серверы и серверы в состоянии “checking” +клиентские запросы передаваться не будут. + + + +Проверки работоспособности могут тестировать код ответа, +наличие или отсутствие определённых полей заголовка и их значений, +а также содержимое тела ответа. +Тесты настраиваются отдельно при помощи директивы +и указываются в параметре match. +Например: + +http { + server { + ... + location / { + proxy_pass http://backend; + health_check match=welcome; + } + } + + match welcome { + status 200; + header Content-Type = text/html; + body ~ "Welcome to nginx!"; + } +} + +В такой конфигурации успешный ответ на проверочный запрос +должен иметь код 200, тип содержимого “text/html” +и “Welcome to nginx!” в теле ответа. + + + +Группа должна находиться в +зоне разделяемой памяти. + + + +Если для группы задано несколько проверок, +то при любой неуспешной проверке соответствующий сервер будет +считаться неработоспособным. + + + + +Обратите внимание, что при использовании проверок +большинство переменных имеют пустые значения. + + + + + + + +имя + +http + + +Задаёт именованный набор тестов для анализа ответов +на запросы проверки работоспособности. + + + +В ответе могут быть протестированы следующие объекты: + + +status 200; +код ответа равен 200 + +status ! 500; +код ответа не равен 500 + +status 200 204; +код ответа равен 200 или 204 + +status ! 301 302; +код ответа не равен ни 301, ни 302 + +status 200-399; +код ответа находится в диапазоне от 200 до 399 + +status ! 400-599; +код ответа находится вне диапазона от 400 до 599 + +status 301-303 307; +код ответа равен 301, 302, 303 или 307 + + + + + +header Content-Type = text/html; + +заголовок содержит
Content-Type
+со значением text/html +
+ +header Content-Type != text/html; + +заголовок содержит
Content-Type
+со значением, отличным от text/html +
+ +header Connection ~ close; + +заголовок содержит
Connection
+со значением, совпадающим с регулярным выражением close +
+ +header Connection !~ close; + +заголовок содержит
Connection
+со значением, не совпадающим с регулярным выражением close +
+ +header Host; +заголовок содержит
Host
+ +header ! X-Accel-Redirect; +заголовок не содержит
X-Accel-Redirect
+ +
+ + + +body ~ "Welcome to nginx!"; + +тело ответа совпадает с регулярным выражением +“Welcome to nginx!” + + +body !~ "Welcome to nginx!"; + +тело ответа не совпадает с регулярным выражением +“Welcome to nginx!” + + + +
+ + +Если задано несколько тестов, +то ответ должен удовлетворять всем тестам. + +Проверяются только первые 256 Кбайт тела ответа. + + + + +Примеры: + +# код ответа 200, тип содержимого "text/html" +# и тело ответа содержит "Welcome to nginx!" +match welcome { + status 200; + header Content-Type = text/html; + body ~ "Welcome to nginx!"; +} + + + +# код ответа не равен 301, 302, 303 и 307 и заголовок не содержит "Refresh:" +match not_redirect { + status ! 301-303 307; + header ! Refresh; +} + + + +# код ответа успешный и сервер не в сервисном режиме +match server_ok { + status 200-399; + body !~ "maintenance mode"; +} + + + + +
+ +
+ +
diff -r dbf6f05f0808 -r 88477c5d2751 xml/ru/docs/http/ngx_http_upstream_module.xml --- a/xml/ru/docs/http/ngx_http_upstream_module.xml Wed Mar 29 22:55:20 2017 +0300 +++ b/xml/ru/docs/http/ngx_http_upstream_module.xml Thu Mar 30 21:26:44 2017 +0300 @@ -10,7 +10,7 @@ + rev="60">
@@ -50,7 +50,9 @@ -Динамически настраиваемая группа, +Динамически настраиваемая группа +с периодическими +проверками работоспособности доступна как часть коммерческой подписки: @@ -324,7 +326,7 @@ задаёт время, в течение которого вес сервера восстановится от нуля до своего номинального значения в ситуации, когда неработоспособный (unhealthy) сервер вновь становится работоспособным -(healthy) +(healthy) или когда сервер становится доступным по прошествии времени, в течение которого он считался недоступным. Значение по умолчанию равно нулю и означает, что медленный старт выключен. @@ -748,304 +750,6 @@ - -[параметры] - -location - - -Активирует периодические проверки работоспособности серверов в -группе, указанной в содержащем location. - - - -Могут быть заданы следующие необязательные параметры: - - - -interval=время - - -задаёт интервал между двумя последовательными проверками, -по умолчанию 5 секунд. - - - -jitter=время - - -задаёт время, в пределах которого -случайным образом задерживается каждая проверка, -по умолчанию задержки нет. - - - -fails=число - - -задаёт число последовательных неуспешных проверок для определённого сервера, -после которых сервер будет считаться неработоспособным, -по умолчанию 1. - - - -passes=число - - -задаёт число последовательных успешных проверок для определённого сервера, -после которых сервер будет считаться работоспособным, -по умолчанию 1. - - - -uri=uri - - -задаёт URI, используемый в запросах, проверяющих работоспособность, -по умолчанию “/”. - - - -mandatory - - -устанавливает исходное состояние “checking” для сервера -до завершения первой проверки работоспособности (1.11.7). -Если параметр не указан, -то исходно сервер будет считаться работоспособным. - - - -match=имя - - -указывает на блок match с условиями, которым должен -удовлетворять ответ, чтобы результат проверки считался успешным. -По умолчанию код ответа должен быть 2xx или 3xx. - - - -port=число - - -задаёт порт, используемый при подключении к серверу -для проверки его работоспособности (1.9.7). -По умолчанию совпадает с портом сервера. - - - - - - -В примере - -location / { - proxy_pass http://backend; - health_check; -} - -каждому серверу группы backend -с интервалом в 5 секунд посылаются запросы “/”. -Если происходит ошибка или таймаут при работе с сервером, или -код ответа проксируемого сервера не равен -2xx или 3xx, проверка считается неуспешной и сервер -признаётся неработоспособным. -На неработоспособные серверы и серверы в состоянии “checking” -клиентские запросы передаваться не будут. - - - -Проверки работоспособности могут тестировать код ответа, -наличие или отсутствие определённых полей заголовка и их значений, -а также содержимое тела ответа. -Тесты настраиваются отдельно при помощи директивы -и указываются в параметре match. -Например: - -http { - server { - ... - location / { - proxy_pass http://backend; - health_check match=welcome; - } - } - - match welcome { - status 200; - header Content-Type = text/html; - body ~ "Welcome to nginx!"; - } -} - -В такой конфигурации успешный ответ на проверочный запрос -должен иметь код 200, тип содержимого “text/html” -и “Welcome to nginx!” в теле ответа. - - - -Группа должна находиться в зоне разделяемой памяти. - - - -Если для группы задано несколько проверок, -то при любой неуспешной проверке соответствующий сервер будет -считаться неработоспособным. - - - - -Обратите внимание, что при использовании проверок -большинство переменных имеют пустые значения. - - - - - -Эта директива доступна как часть -коммерческой подписки. - - - - - - - -имя - -http - - -Задаёт именованный набор тестов для анализа ответов -на запросы проверки работоспособности. - - - -В ответе могут быть протестированы следующие объекты: - - -status 200; -код ответа равен 200 - -status ! 500; -код ответа не равен 500 - -status 200 204; -код ответа равен 200 или 204 - -status ! 301 302; -код ответа не равен ни 301, ни 302 - -status 200-399; -код ответа находится в диапазоне от 200 до 399 - -status ! 400-599; -код ответа находится вне диапазона от 400 до 599 - -status 301-303 307; -код ответа равен 301, 302, 303 или 307 - - - - - -header Content-Type = text/html; - -заголовок содержит
Content-Type
-со значением text/html -
- -header Content-Type != text/html; - -заголовок содержит
Content-Type
-со значением, отличным от text/html -
- -header Connection ~ close; - -заголовок содержит
Connection
-со значением, совпадающим с регулярным выражением close -
- -header Connection !~ close; - -заголовок содержит
Connection
-со значением, не совпадающим с регулярным выражением close -
- -header Host; -заголовок содержит
Host
- -header ! X-Accel-Redirect; -заголовок не содержит
X-Accel-Redirect
- -
- - - -body ~ "Welcome to nginx!"; - -тело ответа совпадает с регулярным выражением -“Welcome to nginx!” - - -body !~ "Welcome to nginx!"; - -тело ответа не совпадает с регулярным выражением -“Welcome to nginx!” - - - -
- - -Если задано несколько тестов, -то ответ должен удовлетворять всем тестам. - -Проверяются только первые 256 Кбайт тела ответа. - - - - -Примеры: - -# код ответа 200, тип содержимого "text/html" -# и тело ответа содержит "Welcome to nginx!" -match welcome { - status 200; - header Content-Type = text/html; - body ~ "Welcome to nginx!"; -} - - - -# код ответа не равен 301, 302, 303 и 307 и заголовок не содержит "Refresh:" -match not_redirect { - status ! 301-303 307; - header ! Refresh; -} - - - -# код ответа успешный и сервер не в сервисном режиме -match server_ok { - status 200-399; - body !~ "maintenance mode"; -} - - - - - - -Эта директива доступна как часть -коммерческой подписки. - - - -
- - число diff -r dbf6f05f0808 -r 88477c5d2751 xml/ru/docs/index.xml --- a/xml/ru/docs/index.xml Wed Mar 29 22:55:20 2017 +0300 +++ b/xml/ru/docs/index.xml Thu Mar 30 21:26:44 2017 +0300 @@ -8,7 +8,7 @@
@@ -445,6 +445,11 @@ + +ngx_http_upstream_hc_module + + + ngx_http_userid_module