The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз nginx 1.16.0, opennews (??), 23-Апр-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


8. "Релиз nginx 1.16.0"  +3 +/
Сообщение от Ключевский (?), 23-Апр-19, 20:48 
Игорь всегда говорил, что если ты используешь в конфиге nginx'а if, то значит что-то не так с твоим конфигом и так делать не надо.
Ответить | Правка | Наверх | Cообщить модератору

10. "Релиз nginx 1.16.0"  +1 +/
Сообщение от Аноним (5), 23-Апр-19, 20:57 
Предложи более удобный способ блокировок по заголовкам запроса.
Ответить | Правка | Наверх | Cообщить модератору

11. "Релиз nginx 1.16.0"  +2 +/
Сообщение от xXxSPYxXx (ok), 23-Апр-19, 21:07 
map
Ответить | Правка | Наверх | Cообщить модератору

12. "Релиз nginx 1.16.0"  +/
Сообщение от Аноним (6), 23-Апр-19, 21:31 
ииииии потом IF да ?
Ответить | Правка | Наверх | Cообщить модератору

13. "Релиз nginx 1.16.0"  +/
Сообщение от xXxSPYxXx (ok), 23-Апр-19, 21:36 
Там if используется уже в другом контексте, обычно с return, что законно.
Ответить | Правка | Наверх | Cообщить модератору

16. "Релиз nginx 1.16.0"  +/
Сообщение от Аноним (16), 23-Апр-19, 22:25 
Ну началось.. Речь идет о замене if на map, а не о "тут if можно, а тут нельзя".
map позволяет неудобный список регулярок оформить в одной легко читаемой конструкции и сэкономить ресурсы на обработке запроса. Заменой if'у он не является, увы и ах.
Ответить | Правка | Наверх | Cообщить модератору

20. "Релиз nginx 1.16.0"  +1 +/
Сообщение от Аноним (20), 24-Апр-19, 02:21 
А почему Вам Lua не подходит для скриптования?
Ответить | Правка | Наверх | Cообщить модератору

22. "Релиз nginx 1.16.0"  +4 +/
Сообщение от Аноним (22), 24-Апр-19, 05:42 
Там массивы с 1 начинаются. ННЖНО
Ответить | Правка | Наверх | Cообщить модератору

21. "Релиз nginx 1.16.0"  +1 +/
Сообщение от Аноним (21), 24-Апр-19, 03:33 
Нормальным способом было бы реализовать if или его аналог не на уровне модуля rewrite, а на уровне http_core_module - так, чтобы они были равноправны с location. Ну или расширить сам location, позволив писать дополнительные условия типа location /foo when ($somevar = 1) { ... }.

Это неоднократно обсуждалось уже много лет назад, вкратце - слишком много надо переделывать.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

29. "Релиз nginx 1.16.0"  +/
Сообщение от нах (?), 24-Апр-19, 10:36 
с конфигом nginx'а определенно что-то не так - тривиальные вещи требуют нетривиальнейших ухищрений, угадать не заглядывая в код, как работают вложенные конструкции - невозможно (половина if'овых проблем от этого) и т д.

зато у нас есть *два* файлика с набором никем и никогда не меняемых настроек для fcgi_proxy - угадайте, почему их два и какой правильный (и почему миллион никем никогда обычно не переопределяемых дефолтов вообще нужно каждый раз include'ом подпихивать в каждый блок с прокси)?

но, поскольку автору оно уже давно неинтересно, он свои дивиденды и так получает, а Максим не революционер, шансов что эту причудливую мешанину заменят вменяемым синтаксисом ровно ноль.

зато, да, давайте завезем в конфиги несколько нескучных язычков, чтоб никому не скучать.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

34. "Релиз nginx 1.16.0"  +/
Сообщение от KonstantinB (ok), 24-Апр-19, 22:31 
If - да, жуткий костыль, для понимания которого надо знать, в какой последовательности работают какие фазы обработки запроса, и что происходит на фазе rewrite. Это, конечно, ужасно. Тут работает правило "внутри if-а пишем только директивы модуля rewrite" - тогда ничего странного не случится.

А с вложенными location-ами надо один раз разобраться с правилами наследования и все становится ясно. Вот хорошая статья на тему: https://blog.martinfjordvald.com/2012/08/understanding-the-n.../

Ответить | Правка | Наверх | Cообщить модератору

39. "Релиз nginx 1.16.0"  +/
Сообщение от пох (?), 25-Апр-19, 20:20 
> А с вложенными location-ами надо один раз разобраться с правилами наследования и все становится
> ясно

становится ясно что ничего не ясно.
Вот вам из вашего любимого талмуда:

The behaviour of a directive is actually entirely up to the module that defines it. All the normal and array directives will inherit properly if they are allowed in that context. For action directives the story is a bit different. Generally they will not inherit into a nested location but it ultimately depends on how the module wants it to be and it can differ on a directive by directive basis.

То есть как работает конкретная команда - "а вот угадай!"

зачем и для чего была понаделана такая неведомая хня вместо иерархического наследования и возможности явно сбросить "array" если вдруг надо (надо крайне редко) - спросите у автора.

Как и почему нельзя нормально пометить директивы в документации, какая из них array, какая не array. (впрочем, это бы не помогло, поскольку всерьез натыкаешься на новые грабли обычно с 3d party модулем, автор которого хорошо если вообще его документировал)

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру