On 11.07.2024 18:51, Roman Arutyunyan wrote:

Отличие в том, что в http есть дефолтные хендлеры, а в stream их нет т.к. 
семантика более общая.

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

В общем, наверное надо как-то улучшить, но хорошего способа пока не вижу. Будем 
иметь в виду, спасибо.

В итоге перенесли проверку в рантайм:
https://hg.nginx.org/nginx/rev/072ca4906154
Теперь ssl_reject_handshake ведет себя одинаково в http и stream.
Спасибо за репорт.

Роман, спасибо за фикс, но я предполагал другой вариант решения,
чтобы директива ssl_reject_handshake on; кроме того, что она делает
сейчас, еще и "под капотом", незаметно для пользователя добавляла бы
свой фиктивный дефолтный хендлер в блок server, чтобы не надо было бы
переносить проверку корректности конфигурации nginx в рантайм.

Я не вижу большой проблемы в том что проверка перенесена в рантайм,
Как минимум, это может быть полезным в процессе разработки и тестирования.
Ну и нагружать ssl_reject_handshake тоже не хочется.

Но ведь изначально вы говорили, что "Переносить ошибку в рантайм
тоже не хочется", значит есть в этом варианте какие-то недостатки?

Если проверка в рантайме - то в процессе тестирования конфигурации
эту ошибку - "no handler for server" - обнаружить будет невозможно?

Проверка конфигурации "nginx -t" будет успешной, а ошибка будет уже
после того, как эта конфигурация, якобы "не содержащая ошибок" будет
применена и ошибка начнет возникать в процессе обработки запросов?

В процессе разработки и тестирования - это может быть и будет удобно,
но в процессе эксплуатации - это совсем неудобно, потому что хотелось
бы иметь возможность обнаруживать ошибки в конфигурации еще на стадии
выполнения "nginx -t", а не когда уже произошла замена конфигруации.

А то, что ssl_reject_handshake нагружена дополнительным кодом -
этого никто бы из пользователей nginx не заметил, и поведение
nginx было бы полностью одинаковым и для http и stream -
и ошибки "no handler for server" можно было бы обнаруживать
еще в процессе тестирования конфигурации, а не в рантайме.

Разве не так?

В чем же тогда преимущество того, что проверка перенесена в рантайм?

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

Не понятно, почему именно такой вариант решения этой проблемы
вы считаете наиболее целесообразным и наиболее оптимальным.


--
Best regards,
 Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Ответить