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

[Amanda Sproule]

>>Правила наследования предельно просты: директивы наследуются с
предыдущего уровня
>>только если не заданы на текущем.  Это позволяет делать конфигурацию
явной, простой,
>>понятной с одного взгляда, избегая всевозможных сложных мерджей и
сайд-эффектов.

Вот именно предельно просты, в нджинксе наследование дефолтовое. В ООП с
наследованием жёстко связано и переопределение, а в нджинксе его нет.
Сам по себе 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. учитывая это всё, никаких конфликтов при слиянии
быть не может и так и есть, просто наследование работает не так как хочется.

>>Эти правила были выработаны на горьком опыте.  По сравнению с этим,
проблему
>>непонимания можно исправить, для этого нужно почитать документацию и
ознакомиться с правилами.

На чьём горьком опыты ? на опыте разработчиков, которые хотят видеть
продукт таким каким самим хочется, или опыте пользователей которые его
используют ?
Читать документацию ? - прочитал и привёл отрывок из неё, и там явно
описано, и то что там описано не сходится с понятием наследования, и
логично было бы пересмотреть механизм наследования многозначных параметров.

Спасибо.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150626/f0058efa/attachment-0001.html>