чт, 23 янв. 2020 г. в 00:16, Evgeniy Berdnikov <bgx@protva.ru>:

> On Wed, Jan 22, 2020 at 08:13:48PM +0300, Maxim Dounin wrote:
> > On Wed, Jan 22, 2020 at 05:04:33AM +0200, Gena Makhomed wrote:
> [...]
> > > И наоборот, если в default_server задано ssl_protocols TLSv1.3;
> > > то в других server`ах директива ssl_protocols TLSv1.2; не работает.
> > >
> > > Это где ошибка - в документации на сайте или в коде nginx 1.17.8?
> >
> > Возможность задания какой-либо директивы в контексте server - не
> > означает, что она будет применяться для всех запросов, попадающих
> > в этот блок server. В случае виртуальных серверов - могут быть
> > нюансы.
> [...]
> > Подробнее можно почитать тут и по ссылкам:
> >
> > https://trac.nginx.org/nginx/ticket/844
> >
> > Соответственно отвечая на заданный вопрос: ошибка - в понимании
> > написанного в документации.
>
> Как человек, наступавший на те же самые грабли, хочу выразить своё
> несогласие с посылом, что тупица здесь читатель. Документация вводит
> в заблуждение, а поведение nginx никак не способствует обходу этой
> ловушки.
>
>
SSL-ная часть nginx обложена граблями примерно полностью.

как вы думаете, в приведенной ниже конфигурации stapling включится ? не
торопитесь с ответом ))

server {
listen 443 ssl http2;
ssl_stapling on;

location / {
proxy_pass http://upstream;
}
}

server {
listen 443 ssl http2 default;
return 404;
}


> Если в доке написано "context: server", то читатель понимает это
> буквально: для заданного server будет действовать указанная директива.
> И поскольку её задача ограничить перечень протоколов, то именно это,
> с точки зрения пользователя, и должно происходить. Потребителю
> не до того, чтобы вспоминать, что бывают name-based виртуалхосты,
> sni-based, ip-based, процессы, нити, пространства имён и прочая лабуда,
> ему не до проблем их сплетения в разных версиях. Потребитель ожидает,
> что ему дадут простой и удобный интерфейс, где все нюансы продуманы,
> а возможность ошибиться и получить не то, что ожидал -- сведена к
> минимуму. Если же интерфейс позволяет сделать бессмысленные или даже
> противоречивые комбинации параметров -- это плохой интерфейс, и его
> следует по возможности выправлять в рантайме, например, предупреждениями
> вида "извините, в этой конфигурации есть разные версии ssl_protocols
> на одном ip-шнике, это работать не будет, см. подробности в <url>".
>
> Ну и в документации капканы тоже желательно упоминать, разумеется.
>
> Вероятно, хотелось сделать интерфейс простым и универсальным, чтобы
> пользователю было легче его освоить. С одной директривой "server".
> Но если идти этим путём, то стыковку разных гаек и болтов по их профилю,
> метрикам и шагам резьбы следует прятать под капот, а потребителю выводить
> такой набор педалей и ручек, чтобы он мог решить задачу "ехать" без
> головной боли и гаданий, где же включился тормоз... IMHO.
> --
> Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru