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

[Amanda Sproule]

>>И возьмём упомянутые 400 location. Вы хотите задать десяток
proxy_set_header на уровне server и дополнить в некоторых location - тут
слияние выглядит привлекательным. Сейчас приходиться копировать все опции в
те location. В случае добавления новых - просматривать весь конфиг и
добавлять в нескольких местах. Будет слияние - не нужно копировать. А если
теперь в некоторых location нужно будет оставить всего несколько опций
proxy_set_header и другие с уровня server в них убрать? Они
переопределяются пустой строкой, но каждый раз когда на уровне server нужно
добавить ещё один заголовок, то опять же придётся смотреть и добавлять
переопределения. Уровень сложности поддержки не меньше, но возможность
сказать "сделай именно вот так и никак не иначе" отсутствует из-за длинных
цепочек слияний.

Всё зависит от того на сколько разрознена конфигурация в локейшенах. Если
каждый из локейшенов определяет для себя сугубо строгие параметры, то о
вынесении на уровень сервера и речи быть не может.

Наследование (мердж) избавляет от копирования всего этого, и в частности,
если исходить из конкретного случая c fastcgi_param практика показывает
необходимости обобщения и вынесения, в отдельных случаях это
переопределение какого-то из параметров.

разве не красиво выглядит когда так ?

server {

    .........
    .........

    include fastcgi_params;

    location /info {
         fastcgi_param SCRIPT_FILENAME /www/info.php;
         fastcgi_pass 127.0.0.1:9000;
    }

   location /info2 {
         try_files $uri =404;
         fastcgi_pass 127.0.0.1:9000;
    }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150627/b0c8aa48/attachment.html>