|
2.2, имя (?), 20:13, 23/04/2019 [^] [^^] [^^^] [ответить]
| +6 +/– |
Да если бы:
$ hg log -r 'tag(release-1.15.0)::tag(release-1.16.0)' -T '{author}\n' | sort | uniq -c | sort -nr
111 Maxim Dounin <mdounin@mdounin.ru>
20 Ruslan Ermilov <ru@nginx.com>
17 Sergey Kandaurov <pluknet@nginx.com>
13 Vladimir Homutov <vl@nginx.com>
13 Roman Arutyunyan <arut@nginx.com>
2 Valentin Bartenev <vbart@nginx.com>
2 Maxim Konovalov <maxim@nginx.com>
2 Gena Makhomed <gmm@csdoc.com>
1 Nova DasSarma <nova@novalinium.com>
1 Nikolay Morozov <n.morozov@securitycode.ru>
1 chronolaw <chronolaw@gmail.com>
1 Chanhun Jeong <chanhun.jeong@navercorp.com>
| |
2.3, Аноним (3), 20:21, 23/04/2019 [^] [^^] [^^^] [ответить]
| –7 +/– |
Ты ещё наверно в Санта-Клауса веришь? Это всё копирасты наклепали и зондов понаставили. А то что тебе это пытаются теперь втюхать и так радостно это поедаешь означает что они всё правильно сделали.
| |
|
3.15, Oleg (??), 22:23, 23/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
Т.е. то, что код выложен в рид онли моде, тебя все еще не устраивает?
| |
|
|
5.35, Аноним (35), 06:33, 25/04/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Не нравится - не пользуйся. Чего вонять то?
Мне вот не нравится расползание рака GPL, который чего не коснись заражает. Еще и захват средств производства которым пытались диктовать условия (да да, мы все еще помним о той случайной "ошибке" с забытыми исключениями в gcc).
Слава богу есть clang который этим не страдает.
| |
|
6.38, Andrey Mitrofanov (?), 13:46, 25/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Не нравится - не пользуйся. Чего вонять то?
Я, видишь ли, не "про код".
А про пропагандистов и пушеров, как ты.
Сделай вид, что не понял, снова?
> Мне вот не
> Слава богу есть
Ну, то есть санта-клаус. Ну, лан.
| |
|
|
|
|
|
1.5, Аноним (5), 20:38, 23/04/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Добавили бы поддержку логических операторов в if, и цены бы не было.
| |
|
2.8, Ключевский (?), 20:48, 23/04/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Игорь всегда говорил, что если ты используешь в конфиге nginx'а if, то значит что-то не так с твоим конфигом и так делать не надо.
| |
|
3.10, Аноним (5), 20:57, 23/04/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Предложи более удобный способ блокировок по заголовкам запроса.
| |
|
|
|
|
7.16, Аноним (16), 22:25, 23/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
Ну началось.. Речь идет о замене if на map, а не о "тут if можно, а тут нельзя".
map позволяет неудобный список регулярок оформить в одной легко читаемой конструкции и сэкономить ресурсы на обработке запроса. Заменой if'у он не является, увы и ах.
| |
|
|
|
4.21, Аноним (21), 03:33, 24/04/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Нормальным способом было бы реализовать if или его аналог не на уровне модуля rewrite, а на уровне http_core_module - так, чтобы они были равноправны с location. Ну или расширить сам location, позволив писать дополнительные условия типа location /foo when ($somevar = 1) { ... }.
Это неоднократно обсуждалось уже много лет назад, вкратце - слишком много надо переделывать.
| |
|
3.29, нах (?), 10:36, 24/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
с конфигом nginx'а определенно что-то не так - тривиальные вещи требуют нетривиальнейших ухищрений, угадать не заглядывая в код, как работают вложенные конструкции - невозможно (половина if'овых проблем от этого) и т д.
зато у нас есть *два* файлика с набором никем и никогда не меняемых настроек для fcgi_proxy - угадайте, почему их два и какой правильный (и почему миллион никем никогда обычно не переопределяемых дефолтов вообще нужно каждый раз include'ом подпихивать в каждый блок с прокси)?
но, поскольку автору оно уже давно неинтересно, он свои дивиденды и так получает, а Максим не революционер, шансов что эту причудливую мешанину заменят вменяемым синтаксисом ровно ноль.
зато, да, давайте завезем в конфиги несколько нескучных язычков, чтоб никому не скучать.
| |
|
4.34, KonstantinB (ok), 22:31, 24/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
If - да, жуткий костыль, для понимания которого надо знать, в какой последовательности работают какие фазы обработки запроса, и что происходит на фазе rewrite. Это, конечно, ужасно. Тут работает правило "внутри if-а пишем только директивы модуля rewrite" - тогда ничего странного не случится.
А с вложенными location-ами надо один раз разобраться с правилами наследования и все становится ясно. Вот хорошая статья на тему: https://blog.martinfjordvald.com/2012/08/understanding-the-nginx-configuration
| |
|
5.39, пох (?), 20:20, 25/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> А с вложенными 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 модулем, автор которого хорошо если вообще его документировал)
| |
|
|
|
|
1.17, Аноним (17), 22:37, 23/04/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –10 +/– |
>Объявлена устаревшей директива "ssl", на смену которой пришёл параметр "ssl"
посоны-то и не в курсе, что сам SSL давно взломан и устарел.
| |
|
2.26, немезидеЦ (?), 08:14, 24/04/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
а посан-то и не в курсе, что ssl это просто название, а реально протоколы какие сам подключишь, хоть SSL разных версий, хоть различных TLS. =))
| |
|
|
2.28, нах (?), 10:29, 24/04/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
это у кого как. У некоторых, вообще-то появился его выключатель.
sysctl net.inet.tcp.always_keepalive
net.inet.tcp.always_keepalive: 1
это стандартная настройка.
| |
|
3.33, Нэээ (?), 20:19, 24/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
В оси он у тебя и так был. А вот в nginx не было как класса
| |
|
4.40, пох (?), 20:22, 25/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> В оси он у тебя и так был. А вот в nginx не было как класса
чтобы его там "не было как класса" - нужно _специально_ открыть сокет и вручную setsockopt'ом выключить этот режим.
| |
|
5.41, Нэээ (?), 23:40, 25/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
Все почти так, только наоборот. Его как надо явно включить через setsockopt. Иначе его нет.
| |
|
6.42, пох (?), 12:14, 26/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
для бестолковых - вам показали настройку, которая в системе из коробки, и которая делает что он - есть, пока явно не попросишь выключить.
| |
|
7.43, Нэээ (?), 08:17, 27/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
Для совсем бестолковых:
Эта настройка sysctl , что привели ранее, отключает или включает в ядре поддержку tcp keepalive на общесистемном уровне.
Но если вы в своем приложении явно не попросили ядро через setsockopt включить для вашего сокета tcp kerpalive, то его просто так там не образуется и не важно что там в sysctl.
Так вот речь в новости о том, что в nginx наконец появилась опция "попросить ядро о tcp kerpalive в сокете к апстриму". Дальше уtcp keepalive в сокете появится или нет в зависимости от того включен ли он на общесистемном уровне.
| |
|
|
|
|
|
|
1.32, rihad (ok), 16:57, 24/04/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Жаль что модуль brotli так и не начали строить по умолчанию на FreeBSD. Только из-за этого приходится из портов ставить, а не из пакетов.
| |
|
|
3.37, rihad (ok), 13:32, 25/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Будь мужиком, собери свой пакет!
Простите, уже вырос с того возраста ) Сейчас нужен только достаточный результат с минимальными усилиями.
| |
|
|
|