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

Вот именно предельно просты, в нджинксе наследование дефолтовое. В ООП с
наследованием жёстко связано и переопределение, а в нджинксе его нет.
Сам по себе 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@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru