Re: Re: Наследование fastcgi_param

[Amanda Sproule]

>>Очень странная это feature, она больше похожа на bug
>>Есть ли шансы, что этот bug будет исправлен в nginx?


Я об этом же, и nginx игнорирует предыдущие fastcgi_param если в локейшене
переопределить новый fastcgi_param.

И поэтому в моём случае PHP-FPM отвечал пустым ответом, так как ему
передавался только fastcgi_param SCRIPT_FILENAME /www/info.php;
А минимальный набор fastcgi_param:

fastcgi_param  REQUEST_METHOD     $request_method;

fastcgi_param SCRIPT_FILENAME /www/info.php;

как я и указал в топике.

И передачу этих параметров легко можно просмотреть в phpinfo(), что и
подтвердило мою мысль. И никак такое поведение нельзя назвать механизмом
наследования.


>>Например, "аналогичная" по своей сути директива proxy_set_header

>>переопределяет существующее значение, а не добавляет еще один header.

И в ней такие же проблемы (фичи) недавно столкнулся када на уровне http
прописал параметры от модуля http_realip_module.

В локейшене где происходил proxy_pass прописал proxy_set_header и модуль
realip уже не передавал свои заголовки (в логах светился не айпи клиента, а
самого сервера).

И опять таки про proxy_set_header в документации написано

"""
Директивы наследуются с предыдущего уровня при условии, что на данном
уровне не описаны свои директивы proxy_set_header. По умолчанию
переопределяются только два поля:

proxy_set_header Host       $proxy_host;
proxy_set_header Connection close;

"""

Спасибо. Хотелось бы услышть мнение разработчиков.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150625/71116b00/attachment.html>