чт, 23 янв. 2020 г. в 00:16, Evgeniy Berdnikov <b...@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