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

[Konstantin Tokarev]

26.06.2015, 19:10, "Amanda Sproule" <paranoidchaos at gmail.com>:
>>>Правила наследования предельно просты: директивы наследуются с предыдущего уровня
>>>только если не заданы на текущем.  Это позволяет делать конфигурацию явной, простой,
>>>понятной с одного взгляда, избегая всевозможных сложных мерджей и сайд-эффектов.
>
> Вот именно предельно просты, в нджинксе наследование дефолтовое. В ООП с наследованием жёстко связано и переопределение, а в нджинксе его нет.


ООП к конфигурации nginx отношение имеет чуть менее, чем никакое.


> Сам по себе fastcgi_param это многозначный параметр, и если в каком-то локейшене, грубо говоря, переопределили один из таких параметров это не должно влиять на остальные параметры, и причём тут мерджи ? Локейшен это последняя точка где применяются  все правила наследования. В случае с нджинксом он перезатирает все предыдущие и устанавливает новые. Суть многозначеного параметра при этом теряется и никакго мерджа там нет.
>
> приведу тупой псевдо пример как логически я это вижу, учитывая сущности наследования.
>
> server {
>
>    # проинклудили fastcgi_parms и получили массив значений
>   fastcgi_params_server_ctx # массив в контексте server
>   {
>         SCRIPT_FILENAME => /www/info.php,
>         REQUEST_METHOD => $request_method,
>         .......
>         .......
>         ...... etc
>   }
>
>   # Определяем локейшен
>   location /info {
>       fastcgi_params_location_ctx // масив в контексте location
>       {
>         SCRIPT_FILENAME => /www/info_overloaded.php,
>       }
>
>       # В этой точке уже будет порисходить мердж двух массивов, банальный аппенд одного массива в другой с учётом перезаписи значений существующих ключей в родительском массиве (fastcgi_params_server_ctx), несуществующих - добавление.
>
>       fastcgi_params_location_ctx = fastcgi_params_server_ctx (merge) fastcgi_params_location_ctx
>       {
>           SCRIPT_FILENAME => /www/info_overloaded.php, // переопределился параметр, а остальные остались не тронутыми
>         REQUEST_METHOD => $request_method,
>         .......
>         .......
>         ...... etc
>       }
>
>       fastcgi_pass 127.0.0.1:9000;
>
>       # Разве сложно смерджить ? разве это не логичное поведение наследования с возможностью расширения или перезаписи?
>       # На данный момент в нджинксе нет понятия наследования конфигурации, только понятие дефолтового значения, или переопределение однозначных параметров (параметров которые в одном и том же контексте должны встречаться один раз).
>
>   }
> }
>
>>>избегая всевозможных сложных мерджей и сайд-эффектов.
>
> какой может быть сайд -эффект от слияния двух массивов ? Локейшен - последняя точка, контексты у всех свои.
>
>>>Когда у вас понаследовалось все с множества уровней и непонятно, какая же в итоге
>>>конфигурация применяется, пока не пробежишься по всем конфигам внимательно и не
>>>отследишь все значения на всех уровнях.
>
> что не понятно ? контексты разные где может быть путаница ?
> main_ctx -> http_ctx -> server_ctx -> location_ctx { inner_location_ctx } (if ваще нужно удалить к чертям, вот оно и создаёт сайд-эффекты)
>
> у каждого параметра есть строгие условия контекста использования. и наследование точно также происходит сверху-вниз. Вы же никогда не опишите location в контексте http. учитывая это всё, никаких конфликтов при слиянии быть не может и так и есть, просто наследование работает не так как хочется.
>
>>>Эти правила были выработаны на горьком опыте.  По сравнению с этим, проблему
>>>непонимания можно исправить, для этого нужно почитать документацию и ознакомиться с правилами.
>
> На чьём горьком опыты ? на опыте разработчиков, которые хотят видеть продукт таким каким самим хочется, или опыте пользователей которые его используют ?
> Читать документацию ? - прочитал и привёл отрывок из неё, и там явно описано, и то что там описано не сходится с понятием наследования, и логично было бы пересмотреть механизм наследования многозначных параметров.
>
> Спасибо.
>
> ,
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


-- 
Regards,
Konstantin