Hello!

On Fri, Jul 17, 2020 at 04:23:02PM -0400, nkatsy wrote:

> Хм, неожиданно. Но так и есть.
> В server был другой add_header.
> Не логичнее ли было бы наследовать, с http, то что не оговоренно в server?

Именно так и делается - если директивы add_header не оговорены в
секции server, то они наследуются. Если оговорены - не
наследуются.

Вы же, судя по всему, под "не оговорено" понимаете попытки по
каким-то правилам "склеить" директивы add_header с уровня http и
директивы add_header с уровня server. Так не логичнее как минимум
по двум причинам:

1. С точки зрения кода проще и логичнее наследовать значение или
массив значений целиком, а не пытаться "склеить" комбинацию из
разных массивов. Тем более, что завтра окажется, что нужен и
"add_header Set-Cookie foo=1;" с уровня http, и "add_header
Set-Cookie bar=2;" с уровня server, а вот "add_header Set-Cookie
bazz=1;" с уровня http - не нужен, и как их правильно "склеивать"
совершенно непонятно.

2. Чтобы наследовать, надо уметь это наследование отменять.
Сейчас наследование отменяется просто по факту наличия
соответствующей директивы. В схеме же со "склеиванием"
понадобится вводить отдельную сущность для отмены наследования с
предыдущего уровня.

Поэтому приблизительно все директивы в nginx'е работают по одной и
той же простой схеме: если директива задана на текущем уровне, то
она не наследуется, если не задана - то наследуется. Исключения -
отдельные директивы, которые вообще не наследуются.

Из неочевидных плюсов: такая схема, в частности, в своё время
позволила ввести возможность использования нескольких директив
error_log на одном уровне без каких-либо проблем совместимости
конфигураций.

Кроме того, я бы тут ещё упомянул вопрос масштабируемости
конфигурации. Игорь подробно рассказывал об этом тут:

https://youtu.be/jf3wIN-FwW4

Текущая схема минимизирует как число мест, в которые надо
смотреть, чтобы понять конфигурацию (скажем, если на уровне
locationn есть директива add_header - можно быть уверенным, что
соответствующие директивы с других уровней на заголовки не
повлияют), так и возможные последствия от изменения конфигурации.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru