Minor docs update

README.md

@@ -21,7 +21,7 @@ Right now Gixy can find:
   * [[ssrf] Server Side Request Forgery](https://github.com/yandex/gixy/blob/master/docs/en/plugins/ssrf.md)
   * [[http_splitting] HTTP Splitting](https://github.com/yandex/gixy/blob/master/docs/en/plugins/httpsplitting.md)
   * [[origins] Problems with referrer/origin validation](https://github.com/yandex/gixy/blob/master/docs/en/plugins/origins.md)
-  * [[add_header_redefinition] Redefining of upstream response headers with directive "add_header"](https://github.com/yandex/gixy/blob/master/docs/en/plugins/addheaderredefinition.md)
+  * [[add_header_redefinition] Redefining of response headers by  "add_header" directive](https://github.com/yandex/gixy/blob/master/docs/en/plugins/addheaderredefinition.md)
   * [[host_spoofing] Request's Host header forgery](https://github.com/yandex/gixy/blob/master/docs/en/plugins/hostspoofing.md)
   * [[valid_referers] none in valid_referers](https://github.com/yandex/gixy/blob/master/docs/en/plugins/validreferers.md)
   * [[add_header_multiline] Multiline response headers](https://github.com/yandex/gixy/blob/master/docs/en/plugins/addheadermultiline.md)

docs/en/plugins/addheaderredefinition.md

@@ -1,10 +1,10 @@
-# [add_header_redefinition] Redefining of upstream response headers with directive "add_header"
+# [add_header_redefinition] Redefining of response headers by  "add_header" directive
 
-Unfortunately, many people consider the use of `add_header` directive for headers redefining a good practice.
-This approach is flawed, which is discussed in Nginx [docs](http://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header):
-> There could be several add_header directives. These directives are inherited from the previous level if and only if there are no add_header directives defined on the current level.
+Unfortunately, many people doesn't know how the inheritance of directives works. Most often this leads to misuse of the `add_header` directive while trying to add a new response header on the nested level.
+This feature is mentioned in Nginx [docs](http://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header):
+> There could be several `add_header` directives. These directives are inherited from the previous level if and only if there are no `add_header` directives defined on the current level.
 
-The logic is quite simple: if you set headers at one level (for example, in `server` section) and then at a lower level (let's say `location`) you set some other headers, then the first group won't apply.
+The logic is quite simple: if you set headers at one level (for example, in `server` section) and then at a lower level (let's say `location`) you set some other headers, then the first headers will discarded.
 
 It's easy to check:
   - Configuration:

docs/ru/plugins/addheaderredefinition.md

@@ -2,9 +2,9 @@
 
 К сожалению, многие считают что с помощью директивы `add_header` можно произвольно доопределять заголовки ответа.
 Это не так, о чем сказано в [документации](http://nginx.org/ru/docs/http/ngx_http_headers_module.html#add_header) к Nginx:
-> Директив add_header может быть несколько. Директивы наследуются с предыдущего уровня при условии, что на данном уровне не описаны свои директивы add_header.
+> Директив `add_header` может быть несколько. Директивы наследуются с предыдущего уровня при условии, что на данном уровне не описаны свои директивы `add_header`.
 
-Суть крайне проста - если у вас устанавливаются заголовки на одном уровне (например, в серверной секции), а уровнем ниже (например, в локейшене) устанавливаются какие-либо еще, то первый не будет применен.
+К слову, так работает наследование большинства директив в nginx'е. Если вы задаёте что-то на каком-то уровне конфигурации (например, в локейшене), то наследования с предыдущих уровней (например, с http секции) - не будет.
 
 В этом довольно легко убедится:
   - Конфигурация: