Re: announcing freenginx.org

[Maxim Dounin]

Hello!

On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote:

> Maxim Dounin писал 2024-02-16 02:24:
> > Hello!
> > 
> > Андрей, я тебе, как и многим другим, всемерно благодарен за
> > поддержку в 2019 и после (эта история, кстати, всё ещё
> > продолжается).  Но, честно говоря, согласен с Геной - какая угодно
> > бумага этих людей бы не остановила.
> 
> Подавателей претензий - может, и не остановила бы, но сильно осложнила бы им
> юридическое оформление претензии.

Записали бы подписавшего бумагу в сообщники, не вижу проблем.  Ты 
же читал иск, который они подали в США?  Там примерно весь Рамблер 
состоял из co-conspirator'ов, и компания смогла обнаружить это 
только в 2019 году.

> Я хорошо помню как вздрогнул полковник, старший следственной группы, когда
> уже после завершения допроса, при разъяснении им что же там наговорил, я
> вспомнил и сказал что в 2011 году читал в прессе что Рамблер высказывался об
> отсутствии претензий к Игорю по nginx. "Вот вам компьютер с интернет,
> найдите плиз, это очень важно" - сразу сказал он.
> 
> Сходу ничего не нашлось; искомое обнаружил Юрий Синодов примерно через
> неделю; плюс я ещё подтащил, через своего адвоката Тимофея Мусатова,
> любопытных материалов из числа первоисточников, имевшихся у следствия, - и
> до следственной группы, похоже, стало доходить что Рамблер их "немножечко
> попользовал".

Насколько я понимаю, доходить до них начало, когда они осознали 
масштаб поднявшегося в прессе шума.  Юридическая сторона вопроса 
им была, скажем так, понятна с самого начала.

[...]

> Примерно в середине марта 2020 года началось явное, наблюдаемое извне,
> отползание следаков от "дела nginx". Что закончилось ЕМНИП в мае вынесением
> постановления о закрытии дела с феерической формулировкой "... в связи с
> отсутствием факта преступления".
> 
> Макс, проверь плиз правильно ли я помню формулировку - у тебя такой документ
> должен быть; мне, увы, такой бумаги не досталось из-за гибели Тимофея
> Мусатова в конце апреля...

Нет, у меня нет, я в Российском деле не фигурировал (к счастью), и 
только отдельно потом давал показания со стороны защиты.

Игорь писал (на сайте висит, собственно), что дело "прекращено за 
отсутствием события преступления".  Это одна из основных 
"оправдательных" формулировок, означающая, что факт преступления 
не подтвердился ("когда не было самого факта, о котором сообщалось 
в компетентный орган, или событие было ошибочно воспринято как 
преступное").

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Maxim Dounin]

Hello!

On Thu, Feb 15, 2024 at 11:20:07PM +0300, Andrey Kopeyko wrote:

> Gena Makhomed писал 2024-02-15 22:20:
> > 
> > Насколько я понимаю, у Максима расчет на то, что F5 не позволит
> > никому постороннему зарегистрировать торговую марку freenginx,
> > и при этом сама F5 не будет выдвигать никаких претензий проекту
> > freenginx, потому что этот проект является полностью свободным
> > и полностью некоммерческим.
> 
> Это ровно та же ошибка, которую в 2011 году совершил Игорь Сысоев -
> увольняясь из Рамблера,
> он удовлетворился словами рулей что "никаких претензий к нему по поводу
> nginx у них нет"
> (в webarchive есть интервью PR-щика Рамблера помершему уже изданию с этими
> словами, ссылка у меня в ФБ заначена)
> и не удосужился закрепить это отсутствие претензий на бумаге.
> 
> Результат такой беспечности налицо - многие (и из этого листа тоже)
> запомнили 12.12.2019 как день плотного общения со следователями СК.
> 
> Мне лично очень не понравилось, как я провёл тот день.
> Да и последующие 4 месяца оказались для меня излишне дорогими. Но как
> адвокат - Тимофей Мусатов был очень хорош.

Андрей, я тебе, как и многим другим, всемерно благодарен за 
поддержку в 2019 и после (эта история, кстати, всё ещё 
продолжается).  Но, честно говоря, согласен с Геной - какая угодно 
бумага этих людей бы не остановила.

> Макс,
> 
> на наступай плиз на эти грабли ещё раз.
> 
> Либо получи от F5 письменный "отказ от претензий" (не берусь даже оценить
> насколько это реально...)
> 
> Либо готовься всё время дрожать как осиновый лист.

Если вдруг у компании F5 возникнут претензии к названию - ну, в 
крайнем случае переименую проект, не велика беда.  Других рисков 
тут не просматривается при всём желании.

> Единственное что в этой ситуации лично меня радует - я не вижу никаких
> оснований для привлечения своей персоны как свидетеля по возможному "делу
> freenginx" :-)
> Тьфу-тьфу-тьфу.

Да ты, однако, оптимист! :))

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Maxim Dounin]

Hello!

On Thu, Feb 15, 2024 at 10:17:57AM +0300, Andrey Kopeyko wrote:

> Gena Makhomed писал 2024-02-15 04:17:
> > On 14.02.2024 19:59, Maxim Dounin wrote:
> > 
> > > Подобный подход можно понять: они владеют проектом, и могут с ним
> > > делать всё, что считают нужным, включая подобные маркетинговые
> > > акции.  Это, однако, противоречит нашемоу соглашению.  И, что более
> > > важно, я больше не имею возможности как-либо контролировать
> > > изменения, которые вносят в nginx в F5, и не могу рассматривать
> > > nginx как открытый и свободный проект, разрабатываемый для общего
> > > блага.
> > > 
> > > Так что, начиная с сегодняшнего дня, я больше не участвую в
> > > разработке nginx'а в рамках F5.  Вместо этого я запускаю
> > > альтернативный проект, управлять которым будут разработчики, а не
> > > корпоративные структуры:
> > > 
> > > http://freenginx.org/
> > > 
> > > Цель проекта - обеспечить разработку nginx'а, свободную от
> > > произвольного корпоративного вмешательства.  Помощь и участие
> > > приветствуются.  Надеюсь, проект будет полезен для всех.
> > 
> > Максим, тут есть одна очень большая проблема.
> > 
> > Владельцем торговой марки NGINX является компания F5 NETWORKS, INC.
> > https://trademarks.justia.com/853/12/nginx-85312802.html
> > 
> > Своего разрешения на использование своей торговой марки NGINX
> > F5 NETWORKS, INC. Вам не давала, и скорее всего, что никгда не даст.
> 
> Максим,
> 
> Геннадий беспокоится обоснованно, и соображения написал все очень верные.
> 
> Если хочешь, могу попробовать организовать тебе консультацию по "доменам,
> IP, ТМ и судебном опыте вокруг этого всего" у специалистов Ру-Центра. За
> последние 25 лет они на этом не одну собачью стаю съели, и по буржуйским
> доменам тоже.

Спасибо, я пока рассчитываю на отсутствие проблем в этом вопросе, 
смотри ответ Геннадию.  Если возникнут - будем решать их по мере 
поступления.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Maxim Dounin]

Hello!

On Thu, Feb 15, 2024 at 03:17:04AM +0200, Gena Makhomed wrote:

> On 14.02.2024 19:59, Maxim Dounin wrote:
> 
> > Подобный подход можно понять: они владеют проектом, и могут с ним
> > делать всё, что считают нужным, включая подобные маркетинговые
> > акции.  Это, однако, противоречит нашемоу соглашению.  И, что более
> > важно, я больше не имею возможности как-либо контролировать
> > изменения, которые вносят в nginx в F5, и не могу рассматривать
> > nginx как открытый и свободный проект, разрабатываемый для общего
> > блага.
> > 
> > Так что, начиная с сегодняшнего дня, я больше не участвую в
> > разработке nginx'а в рамках F5.  Вместо этого я запускаю
> > альтернативный проект, управлять которым будут разработчики, а не
> > корпоративные структуры:
> > 
> > http://freenginx.org/
> > 
> > Цель проекта - обеспечить разработку nginx'а, свободную от
> > произвольного корпоративного вмешательства.  Помощь и участие
> > приветствуются.  Надеюсь, проект будет полезен для всех.
> 
> Максим, тут есть одна очень большая проблема.
> 
> Владельцем торговой марки NGINX является компания F5 NETWORKS, INC.
> https://trademarks.justia.com/853/12/nginx-85312802.html
> 
> Своего разрешения на использование своей торговой марки NGINX
> F5 NETWORKS, INC. Вам не давала, и скорее всего, что никгда не даст.
> 
> А вот дальнейшее развитие событий предусмотреть совсем не трудно.
> Они будут преследовать Вас в судебном порядке за trademark infringement

Спасибо за ссылки.  Тут есть несколько факторов:

Во-первых, название freenginx - хорошо отражает суть проекта.  
Поэтому оно и было выбрано.

Во-вторых, я, конечно, не юрист, но freenginx и NGINX - это два 
разных названия, и вероятность успешных претензий я оцениваю как 
небольшую.  Кроме того, неявное разрешение на использование 
торговой марки подразумевается лицензией.

Ну и в-третьих, если всё-таки компания F5 решит играть в эти игры, 
то это хорошо продемонстрирует их отношение к свободному 
программному обеспечению.  Я не думаю, что это случиться, скорее 
рассчитываю, что компания одумается и будет поддерживать проект, 
ибо это в первую очередь в их собственных интересах, но поживём - 
увидим.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Maxim Dounin]

Hello!

On Wed, Feb 14, 2024 at 09:32:54PM +0300, izor...@gmail.com wrote:

> Добрый вечер, Максим.
> 
> Печально всё это слышать...
> Будет развиваться как очередной форк Nginx или каким-то другим 
> способом будет вестись разработка?

С учётом деталей - скорее, форк остался у F5.  Развиваться будет 
мной и теми, кто решит присоединиться.

[...]

> > Так что, начиная с сегодняшнего дня, я больше не участвую в
> > разработке nginx'а в рамках F5.  Вместо этого я запускаю
> > альтернативный проект, управлять которым будут разработчики, а не
> > корпоративные структуры:
> 
> > http://freenginx.org/
> 
> Какая помощь приветствуется не из области программирования?)

Не из области программирования - в первую очередь тестировать и 
репортить проблемы.

> Нет ли желания продвижения в сети Fediverse (микро-блог, аналог
> Twitter)?
> Нет ли в планах поднять какой-нибудь небольшой форум?

Нет, и опять же нет.  Продвижение особого смысла не имеет, проект 
строго некоммерческий и не предполагает каких-либо коммерческих 
перспектив.  Что до форумов, то это совершенно не мой формат 
общения.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

announcing freenginx.org

[Maxim Dounin]

Hello!

Как вы, вероятно, знаете, компания F5 закрыла офис в Москве в 2022
году, и с тех пор я не работают в F5.  Однако после закрытия офиса
мы достигли соглашения, что я сохраняю свою роль в разработке
nginx'а как волонтёр.  И почти два года я занимался тем, что
развивал nginx, делая его лучше для всех.

К сожалению, кто-то из нетехнического менеджмента F5 недавно решил,
что знает лучше, как следует управлять открытыми проектами.  В
частности, кто-то решил, что не следует руководствоваться
security-политикой, используемой nginx'ом в течении многих лет, а
равно не следует учитывать мнение разработчиков.

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

Так что, начиная с сегодняшнего дня, я больше не участвую в
разработке nginx'а в рамках F5.  Вместо этого я запускаю
альтернативный проект, управлять которым будут разработчики, а не
корпоративные структуры:

http://freenginx.org/

Цель проекта - обеспечить разработку nginx'а, свободную от
произвольного корпоративного вмешательства.  Помощь и участие
приветствуются.  Надеюсь, проект будет полезен для всех.


-- 
Maxim Dounin
http://freenginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Тест nginx -- сколько сообщений в log syslog без потерь?

[Maxim Dounin]

Hello!

On Mon, Feb 05, 2024 at 09:56:54PM +0200, Gena Makhomed wrote:

[...]

> Потому что если программа, которая читает данные из unix socket`а
> отвалится - тогда произойдет переполенение буфера и nginx тогда
> заблокируется на операции записи в unix socket, и как следствие
> этого - перестанет выполнять свою основную функцию - перестанет
> отвечать на запросы клиентов по http / https протоколу.

Нет, если в сокет syslog'а не получается писать - nginx [логгирует 
ошибку в error log и] дропает сообщение.  Я об этом, собственно, 
писал в начале треда - судя по всему, исходная проблема была 
именно в том, что syslog-сервер не успевал выгребать сообщения, и 
они осыпались на пол.

(А если вернуться к основам, то в syslog через стандартную 
библиотеку nginx не пишет именно потому, что там запись в сокет в 
случае чего блокируется, и так, конечно, жить нельзя.)

[...]

> Так же не понятно, в чем для Вас проблема переименовать
> log-файл и отправить сигнал USR1 мастер-процессу nginx,
> для того, чтобы он переоткрыл log-файл и продолжил запись.
> 
> Особенно, если учесть, что директива https://nginx.org/r/access_log
> имеет дополнительные параметры [buffer=size] [flush=time] [if=condition]

+1

Нет никаких проблем вращать файловые логи в nginx'е, переоткрытие 
логов по USR1 - дешёвая и быстрая операция.

При этом запись в файловые логи, во-первых, куда эффективнее 
записи в syslog, в силу отсутствия лишних context switch'ей, а 
во-вторых, позволяет дополнительно и существенно снизить затраты 
за счёт буферизации и даже gzip-сжатия на лету.

Если на выходе всё равно файлы - совершенно непонятно, зачем 
нужна вся эта запись в python-скрипты, изображающие из себя 
syslog-сервера.

[...]

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginxQuic: скорость загрузки при активации kTLS

[Maxim Dounin]

Hello!

On Sun, Feb 04, 2024 at 10:03:56AM +0300, izor...@gmail.com wrote:

> Добрый день, Максим.
> 
> Сегодня увидел, что разработчики избавились от буферов приёма и
> создали новый способ разгрузки для протокола HTTP/2:
> https://github.com/icing/blog/blob/main/curl-h2-perf-evolution.md
> https://github.com/curl/curl/pull/12828
> 
> Реализации аналогичного варианты в Nginx как-то поможет для ускорения
> работы с протоколом HTTP/2?

Это какая-то внутренняя история curl'а про борьбу с неэффективным 
демультиплексингом, к nginx'у не имеет отношения примерно 
никакого, да и в самом curl'е относится только к случаю получения 
нескольких файлов одновременно по одному соединению.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Тест nginx -- сколько сообщений в log syslog без потерь?

[Maxim Dounin]

Hello!

On Thu, Jan 18, 2024 at 07:15:10PM +0300, Anatoliy Melnik via nginx-ru wrote:

> Слив в 1 Syslog с 3-х nginx -ов, до суммарно 150тыс/сек все 
> сходится (3х50), расхождение +- 0.1% , на 200 тыс (3х67тыс) 
> расхождение достигает 4-7% (в syslog-е на 4-7% меньше, чем сумма 
> по бекэндам)

Сравнивать с суммой по бэкендам как минимум некорректно без учёта 
возможной работы proxy_next_upstream и внутренних перенаправлений, 
не говоря уже о подзапросах.

Если хочется сравнивать с бэкендами, то надо либо как-то 
убеждаться, что каждый запрос порождает только один запрос к 
бэкенду (proxy_next_upstream off, keepalive к бэкендам не 
используется, подзапросов нет), либо учитывать все попытки в 
$upstream_addr и $upstream_status (опять же в предположении 
отсутствия подзапросов).

> Результат не зависит от использования UDP или unixSocket (на 
> локальном сервере).
> Не зависит от того, локальный это syslog или на соседнем сервере 
> (для UDP).
> 
> Ситуация повторяется как минимум на 2-х версиях nginx
> nginx version: nginx/1.18.0
> И
> nginx version: nginx/1.24.0
> 
> Замена syslog сервера на самописную версию, единственная задача 
> которой из unixSocket блок данных записать в файл дает такие же 
> результаты количественные.
> 
> Возможно я плохо искал методы тюнинга unixSocket, к сожалению не 
> нашел. 

Тюнинг стандартный: setsockopt(SO_RCVBUF), как и для любых 
сокетов.

Если в syslog-сервере ручки не вынесено, то в системе можно 
настроить с помощью соответствующих sysctl'ей - 
net.inet.udp.recvspace и net.local.dgram.recvspace для FreeBSD, 
net.core.rmem_default (а при необходимости net.ipv4.udp_mem и 
net.ipv4.udp_rmem_min) на Linux.

Для локальных сокетов на Linux'е, судя по всему, нужно ещё крутить 
net.unix.max_dgram_qlen.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Тест nginx -- сколько сообщений в log syslog без потерь?

[Maxim Dounin]

Hello!

On Wed, Jan 17, 2024 at 02:49:30PM +0300, Anatoliy Melnik via nginx-ru wrote:

> Здравствуйте.  Есть nginx-ы, несколько разных версий. Проксируют 
> запросы к бекэндам.  Логи льются в syslog (слив в файлы напрямую 
> из nginx не желателен).  По косвенным методам контроля вылезла 
> проблема: До примерно 50 тыс/сек сообщений статистика прокси и 
> бекэндов сходится, а вот начиная примерно с 50тыс/сек начинаются 
> расхождения. nginx->syslog фиксирует меньше событий, чем сумма 
> по бекэндам.  Чем выше интенсивность запросов, тем больше 
> расходятся данные.  Сначала грешил на syslog, но детальные 
> разборы полетов говорят, что скорее всего проблема в nginx.  У 
> кого-то что-то такое наблюдалось или нет?  При сливе логов с 2-х 
> nginx-ов в один syslog все хорошо до примерно 100тыс/сек, т.е. 
> скорее всего syslog не виноват.  Кто-то с таким сталкивался? 

Запись логов в syslog - не гарантирует доставку всех сообщений.  
Если syslog-сервер не справляется или есть проблемы с сетью между 
nginx'ом и syslog-сервером - сообщения будут просто осыпаться на 
пол. (Где-то тут должна быть шутка про UDP, но она потерялась.)

Если хочется улучшить ситуацию - я бы начал с тюнинга буферов 
сокета syslog-сервера.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: fastcgi/proxy cache disk read size

[Maxim Dounin]

Hello!

On Wed, Jan 17, 2024 at 10:43:10AM +0700, Алексей wrote:

> Я все таки попробовал и количество READ запросов по NFS упало вдвое.
> Средний размер дискового чтения увеличился где то на 20% и на столько
> же уменьшилось количество IO на диске.
> 
> Однако, при таком большом размере fastcgi_buffer_size при рестарте
> nginxа, на сколько я понимаю, cache loader фактически загрузит все
> файлы целиком для заполнения key_zone.

Размер fastcgi_buffer_size влияет на размер чтения заголовков из 
файла кэша, если в зоне разделяемой памяти информации о размере 
заголовков нет.  Соответственно после перезапуска nginx'а при 
первом обращении к соответствующему файлу в кэше заголовки будут 
читать с буфером размером fastcgi_buffer_size, а при последующих 
обращениях nginx уже будет знать размер заголовков в файле кэша и 
будет читать только их.

Что до cache loader'а, то он вообще сейчас не читает файлы кэша, 
только составляет их список (до nginx 1.1.0 было по другому, но 
с тех пор прошло уже больше 10 лет).

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: fastcgi/proxy cache disk read size

[Maxim Dounin]

Hello!

On Tue, Jan 16, 2024 at 12:43:47PM +0700, Алексей wrote:

> Благодарю за подробный ответ. Не знал, что кэш файлы читаются в два этапа.
> Что если выставить fastcgi_buffer_size 512k? Весь файл читается в этот
> буфер тогда?

Нет, nginx отслеживает размер заголовков в элементах кэша и хранит 
эту информацию в keys_zone.  Соответственно при чтении заголовков 
читаются только данные заголовков.

Так сделано, потому как данные тела в общем случае могут быть 
вообще не нужны (или нужны не целиком, или не нужны в 
пользовательской памяти): для HEAD-запросов, для запросов с 
If-Modified-Since, на которые nginx вернёт 304, и так далее.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Патч ETags в NixOS

[Maxim Dounin]

Hello!

On Sat, Jan 13, 2024 at 06:01:26PM +0300, izor...@gmail.com wrote:

> Добрый день, Максим.
> 
> Вы писали 13 января 2024 г., 16:21:12:
> 
> > Именно об этом и тикет, да.  Мне тоже вариант с файлами кажется 
> > более интересным - с extended-атрибутами, возможно, код будет чуть 
> > проще и, вероятно, быстрее, в силу меньшего количества необходимых 
> > системных вызовов, но там сразу возникает масса проблем как с 
> > портабельностью, так и с хранением/синхронизацией (e.g., в том же 
> > nix store они могут просто не работать).
> 
> Имеется в виду синхронизация дополнительных файлов между основным
> и кэширующим сервером? Мне кажется, что если основной сервер
> предоставит необходимый ETags, тогда синхронизация не потребуется.

Имеется в виду, что если файловое хранилище копируется и/или 
синхронизируется между серверами, с помощью какого-нибудь scp или 
rsync, или просто перекладывается в соседнюю папку с помощью cp, 
то забыть необходимые флаги для копирования extended-атрибутов - 
куда проще, чем забыть скопировать дополнительные файлы.

В случае полноценного HTTP-кэширования, понятно, никаких проблем 
не будет, так как ETag, полученный от исходного сервера, будет 
сохранён вместе с заголовками ответа.  (Ну а в случае proxy_store, 
где заголовки не сохраняются, проблемы с будут с любыми кастомными 
ETag'ами.)

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: fastcgi/proxy cache disk read size

[Maxim Dounin]

Hello!

On Mon, Jan 15, 2024 at 09:00:09AM +0700, Алексей wrote:

> Приветствую.
> 
> Использую fastcgi proxy с кэшом, расположенном на NFS шаре. Кэшируемые
> файлы размером около 250К.

Традиционно отмечу, что раздавать данные nginx'ом с NFS (а тем 
более держать там кэш) - не лучшая идея.  Если что-либо случится с 
сетью до NFS-сервера и/или NFS-сервером - nginx просто 
заблокируется, пытаясь читать данные с NFS, и не будет обслуживать 
вообще никакие запросы.  Ну и любая операция с NFS-сервером - это 
опять же заблокированный nginx, то есть даже когда всё хорошо - 
любые задержки операций на NFS-сервере будут приводить к 
увеличению latency для всех запросов.  Лучше размещать nginx 
непосредственно там, где диски, не вводя дополнительных точке 
отказа.

> Вывод команды mountstats показывает, что операции READ получают в
> среднем 54К байт, а операции WRITE отправляют в среднем 220К байт.
> 
> Получается, что когда nginx пишет файлы, то делает это за один вызов
> write, а когда читает, то за несколько вызовов read. Можно ли сделать
> так, чтобы файлы читались за один вызов read.
> 
> Это важно в связи с тем что используются HDD диски и каждый IO
> приводит к перемещению головки.

При чтении кэша файлы читаются в два этапа:

- Сначала отдельной операцией чтения читается заголовок, в котором 
  хранятся метаданные и заголовок ответа.

- Потом тело ответа отдаётся точно так же, как и любой статический 
  файл.

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

Управления желаемым поведением системы есть ручка read_ahead 
(http://nginx.org/r/read_ahead), но полноценно работать она будет 
только на FreeBSD, где есть fcntl(F_READAHEAD), а на линуксе 
выльется в posix_fadvise(POSIX_FADV_SEQUENTIAL) - что, конечно, 
полезно, но в любом случае потребует дополнительного тюнинга 
собственно системы.

Кроме того, можно постараться улучшить работу с телом ответа 
внутри nginx'а.  Если используется sendfile(), то тут особо ничего 
не сделаешь, ибо в этом случае работой с файлами занимается 
система.  Но если sendfile() не используется (или из-за SSL, или 
просто выключен в конфиге nginx'а), то nginx читает файлы с 
помощью output_buffers (http://nginx.org/r/output_buffers).  
Соответственно для того, чтобы операции чтения были большие - 
нужно использовать буфера соответствующего размера.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Патч ETags в NixOS

[Maxim Dounin]

Hello!

On Sat, Jan 13, 2024 at 10:34:08AM +0300, izor...@gmail.com wrote:

> Добрый день, Максим.
> 
> Вы писали 13 января 2024 г., 3:28:36:
> 
> > Hello!
> 
> > Hash-сумма файла в качестве ETag - в целом отличное решение, 
> > проблема тут ровно одна: её нужно как-то получить, ибо системный 
> > вызов fstat() никаких hash-сумм почему-то не возвращает.  Считать 
> > на лету - очевидно, плохой вариант для нагруженного сервера, так 
> > как файл придётся на каждый запрос читать дважды.  А получать 
> > hash-сумму откуда-то ещё, скажем из внешнего файла или 
> > extended-атрибутов - выглядит в лучшем случае дополнительной фичей 
> > (смотри https://trac.nginx.org/nginx/ticket/2351 например).
> 
> Теоретически можно было бы сделать предварительное сканирование
> файлов и генерация хэш сумм при старте в фоновом режиме, для тех
> файлов, которыее расположены только в /nix/store или любой другой
> директории, указанной пользователем. А результаты сохранить в кеш.
> 
> Если генерировать хэш-сумму на лету, то зачем надо генерировать её
> каждый раз при повторном запросе? Можно же в кэше результат сохранить.
> Да и это надо делать только для тех файлов, которые имеют нулевую дату.
> А файлы в /nix/store меняются не часто, только при обновлении ОС.

Всё это предполагает какой-то кэш, который надо как-то отдельно 
делать и конфигурировать, и выглядит в лучшем случае 
дополнительной фичей.

> Вариант с файлами хэш-сумм выглядит более оптимальным. При генерации
> файлов в /nix/store можно дополнительно добавить возможность генерации
> хэш-суммы для каждого файла, который требуется для работы сайта. Таким
> же способом в некоторых приложениях организована генерация статических
> файлов в gzip и brotli форматы.

Именно об этом и тикет, да.  Мне тоже вариант с файлами кажется 
более интересным - с extended-атрибутами, возможно, код будет чуть 
проще и, вероятно, быстрее, в силу меньшего количества необходимых 
системных вызовов, но там сразу возникает масса проблем как с 
портабельностью, так и с хранением/синхронизацией (e.g., в том же 
nix store они могут просто не работать).

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Патч ETags в NixOS

[Maxim Dounin]

Hello!

On Fri, Jan 12, 2024 at 10:35:38PM +0300, izor...@gmail.com wrote:

> Вы писали 9 января 2024 г., 5:26:08:
> 
> > Что до nix store, то кажется, что возвращение размера в ETag также 
> > должно проблему решить.
> 
> В том то и дело, что размер не всегда меняется.

Дата модификации и размер - на практике достаточная комбинация для 
отслеживания версий файлов и их различных представлений, по 
крайней мере в рамках тех представлений файлов, которые умеет 
возвращать nginx (исходный файл и его gzip-версия).

В nix store, в силу отказа от времени, время надо на что-то заменять, 
как минимум в ситуациях, когда полных путь, включающих store hash, 
не фигурирует в URL'е.  Но это ортогональный вопрос (и скорее 
вопрос к самой концепции, которая получилась не очень совместимой 
с HTTP).

> > Теоретически, наверное, можно пытаться в ETag вставлять какой-то 
> > идентификатор представления, то если для gzip_static добавлять в 
> > ETag что-нибудь вроде "...-gz".  Но при наличии размера в том же 
> > ETag'е смысла в этом исчезающие мало.
> 
> А вариант добавить вычисления простой хэш суммы при условии, что дата
> равно нулю - размер файла + хэш сумма.
> Теоретически на остальное не должно повлиять.

Hash-сумма файла в качестве ETag - в целом отличное решение, 
проблема тут ровно одна: её нужно как-то получить, ибо системный 
вызов fstat() никаких hash-сумм почему-то не возвращает.  Считать 
на лету - очевидно, плохой вариант для нагруженного сервера, так 
как файл придётся на каждый запрос читать дважды.  А получать 
hash-сумму откуда-то ещё, скажем из внешнего файла или 
extended-атрибутов - выглядит в лучшем случае дополнительной фичей 
(смотри https://trac.nginx.org/nginx/ticket/2351 например).

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Патч ETags в NixOS

[Maxim Dounin]

Hello!

On Sun, Jan 07, 2024 at 09:57:45AM +0300, izor...@gmail.com wrote:

> Обнаружилась ещё одна ошибка с текущим вариантом патча:
> https://github.com/NixOS/nixpkgs/pull/278380
> 
> Некорректно кэшируются файлы, которые предварительно сжаты в формат
> gzip и/или brotli форматы.
> 
> Может получится найти какое-то альтернативный вариант решения генерации
> Etags для файлов, которые имеют фиксированную дату? 
> 
> Сейчас, Etags генерируется на основе размера файла + даты изменения.

ETag на основе размера файла и даты модификации файла - кажется 
вполне достаточным для уникальности в рамках требований к strong 
entity tags.  Тем более, что даже при совпадении ETag'ов между 
различными представлениями одного ресурса - сломаться что-либо 
может скорее теоретически, если вдруг меняются правила выбора 
представлений (e.g., включают или выключают gzip_static, а клиент 
в это время пытается делать range-запрос и комбинировать его с 
ранее полученными от другой конфигурации ответами).

Что либо менять в nginx'е я тут смысла не вижу, ETag сейчас 
содержит достаточно информации, чтобы проблем не возникало.

Что до nix store, то кажется, что возвращение размера в ETag также 
должно проблему решить.

> Поможет ли добавление ещё одного параметра, например полного пути к
> файлу? Получится такой вариант:
> размер файла + дата изменения + полный путь к файлу

Полный путь к файлу в ETag точно не имеет смысла.  Более того, его 
там быть точно не должно: если вдруг ресурс обслуживается двумя 
разными origin-серверами, это приведёт к требованию совпадения 
путей к файлу на этих серверах, а при их несовпадении - 
соответственно к полным ответам вместе 304, то есть сломает 
кэширование там, где оно сейчас работает.

Теоретически, наверное, можно пытаться в ETag вставлять какой-то 
идентификатор представления, то если для gzip_static добавлять в 
ETag что-нибудь вроде "...-gz".  Но при наличии размера в том же 
ETag'е смысла в этом исчезающие мало.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx: HTTP/2 и kTLS

[Maxim Dounin]

Hello!

On Sun, Jan 07, 2024 at 10:39:00AM +0300, izor...@gmail.com wrote:

> Доброе утро.
> 
> При использовании kTLS и sendfile наблюдается просадка производительности
> при отдаче статических файлов, например при видео-стриминге. Одним из
> вариантов решения является перенести статический файлы на другой хост и
> использовать там только протоколы HTTP/1.1 и/или HTTP/3. Либо усложнять
> логику работы в блоке location.
> 
> Не все сервисы позволяют выводить статику на отдельный хост, либо могут
> иметь сложную конфигурацию nginx. Например web-сервис Peertube имеет
> множество блоков location и использует различные условия if:
> https://github.com/Chocobozzz/PeerTube/blob/develop/support/nginx/peertube
> 
> Обычному пользователю будет сложнее с этим разобраться и добавить
> дополнительные блоки для исключения работы протокола HTTP/2 через kTLS.
> Вполне легко можно запутаться и нарушить логику работы сайта.
> 
> Хотелось бы иметь более простой и универсальный способ отключения
> обработки протокола HTTP/2 через kTLS.
> 
> Предполагаю, что перед передачей шифрования ядру системы сейчас nginx
> проверяет наличие ssl и параметра sendfile. Можно ли добавить дополнительное
> условие, которое проверяет дополнительный параметр, который указывает
> какой протокол исключить из обработки шифрования ядром?
> 
> По итогу получится примерно такой вариант конфигурации:
>   server {
> listen 0.0.0.0:443 quic reuseport ;
> listen 0.0.0.0:443 ssl reuseport ;
> http2 on;
> http3 on;
> ssl_conf_command Options KTLS;
> disable_ktls_for_protocol http2;
> ...
> 
> Мне кажется, что такой вариант эффективнее, чем добавлять условие if с
> rewrite и дополнительный блок location.

Как я уже писал ранее,

1. Дело не в kTLS, kTLS работает для HTTP/2 точно так же, как и 
для HTTP/1.x.  Просто в отсутствии акселераторов - kTLS сам по 
себе не даёт примерно ничего.  Дело в sendfile(), который при 
включённом kTLS начинает работать в том числе для HTTP/2, но для 
HTTP/2 он работает плохо из-за фрейминга.

2. Смысла в таком решении примерно ноль, потому что типичный 
браузер всё равно соединится по HTTP/2 (или по HTTP/3).  То есть с 
тем же успехом можно просто выключить sendfile (и/или kTLS), 
результат не будет отличаться.

Если хочется, чтобы было быстро - надо выносить (большую) статику в 
отдельный домен, где разрешать только HTTP/1.x, и соответственно 
включать sendfile и kTLS.

Впрочем, насколько быстро - это отдельный вопрос.  Скорее всего на 
линуксе примерно те же результаты можно получить, просто подняв 
размер output_buffers (http://nginx.org/r/output_buffers).

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginxQuic: скорость загрузки при активации kTLS

[Maxim Dounin]

Hello!

On Sat, Jan 06, 2024 at 08:20:59PM +0300, izor...@gmail.com wrote:

> Добрый вечер, Илья.
> 
> Да, он влияет как и на HTTP/1.1 и на HTTP/2 протоколы. Ещё бы добавить опцию, 
> например, disable_ktls_for_protocol.
> В итоге получится примерно такой вариант:
>   server {
>     listen 0.0.0.0:443 quic reuseport ;
>     listen 0.0.0.0:443 ssl reuseport ;
>     http2 on;
>     http3 on;
>     ssl_conf_command Options KTLS;
>     disable_ktls_for_protocol http2;
>  
> По итогу при активации kTLS не будет просадки в производительности для HTTP/2 
> протокола, т.к. обработкой
> шифрованием будет заниматься сам процесс nginx :)

Просадка производительности, которую вы наблюдаете для HTTP/2 при 
включённом kTLS - не собственно из-за kTLS, а из-за того, что у 
вас включён sendfile, и при включённом kTLS становится возможным 
его использование.  А в случае HTTP/2 это выливается в большое 
количество syscall'ов из-за HTTP/2-фрейминга.

Если очень хочется получить включённый sendfile и kTLS в случае 
HTTP/1.x, и выключенный в случае HTTP/2, то можно сделать как-то 
так (слегка адаптировано из 
https://mailman.nginx.org/pipermail/nginx-devel/2022-September/NSHDCLL2TY3Q536CO5MAKXSC3HCIMUNF.html):

server {
listen 443 ssl;

http2 on;

location / {
if ($server_protocol != 'HTTP/2.0') {
rewrite ^(.*) /sendfile$1 last;
}

sendfile off;
}

location /sendfile/ {
alias html/;
sendfile on;
}
}

Но смысла в этом не очень много, так как при включённом HTTP/2 
рассчитывать на клиентов, которые придут по HTTP/1.x, не имеет 
особого смысла, таких клиентов будет исчезающе мало.  Если хочется 
получить высокую производительность при скачивании больших файлов, 
и при этом использовать HTTP/2 (и/или HTTP/3), то имеет смысл 
заводить отдельный виртуальный сервер, в котором разрешать только 
HTTP/1.x (а также sendfile и kTLS), и раздавать файлы с него.

Для HTTP/3 не работают ни kTLS, ни sendfile, соответственно 
влияния на производительность HTTP/3 от включения kTLS не будет.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Простой способ массового переноса http2 из listen в отдельную директиву

[Maxim Dounin]

Hello!

On Thu, Dec 28, 2023 at 11:21:55AM +0300, Evgeniy Berdnikov wrote:

> On Thu, Dec 28, 2023 at 10:07:41AM +0200, Иван wrote:
> > nginx: [warn] the "listen ... http2" directive is deprecated, use the
> > "http2" directive instead in /etc/nginx/sites-enabled/...:152
> > 
> > 
> > Надо http2 из параметра директивы listen перенести в отдельную
> > 
> > http2 on;
> > 
> > 
> > У меня несколько десятков блоков server. В некоторых http2 нужен, в
> > некоторых (listen 80) нет. Есть какие-нибудь идеи как конвертацию сделать
> > массово?
> 
>  Это конкурс на лучший однострочник в кружке юного программиста?
> 
>  perl -i~ -pe 'if(m/listen\s+/ && s/\s+http2//) {print "http2 on;\n"}' *.conf

Предостерегу от подобных решений: в общем случае это не даст 
идентичный конфиг, так как из чего-то вроде:

   server { listen 443 ssl http2; server_name foo; ... }
   server { listen 443; server_name bar; ... }

где HTTP/2 работает в обоих блоках server, получится конфигурация 
вида:

   server { listen 443 ssl; http2 on; server_name foo; ... }
   server { listen 443; server_name bar; ... }

где во втором блоке server HTTP/2 выключен.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Простой способ массового переноса http2 из listen в отдельную директиву

[Maxim Dounin]

Hello!

On Thu, Dec 28, 2023 at 10:07:41AM +0200, Иван wrote:

> Здравствуйте!
> 
> Я про
> 
> nginx: [warn] the "listen ... http2" directive is deprecated, use the 
> "http2" directive instead in /etc/nginx/sites-enabled/...:152
> 
> 
> Надо http2 из параметра директивы listen перенести в отдельную
> 
> http2 on;
> 
> 
> У меня несколько десятков блоков server. В некоторых http2 нужен, в 
> некоторых (listen 80) нет. Есть какие-нибудь идеи как конвертацию 
> сделать массово?

Исходная идея была в том, что теперь http2 можно включить в том 
числе для "listen 80", соединения по HTTP/2 детектируются 
автоматически.  Соответственно можно просто включить http2 на 
уровне http{} и забыть.

Или наоборот, включить http2 только в тех блоках сервер, где 
хочется иметь HTTP/2 включённым, а в остальных не включать.

Подробнее в коммит-логе тут:

https://hg.nginx.org/nginx/rev/08ef02ad5c54

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 421 Misdirected Request via pass_proxy

[Maxim Dounin]

Hello!

On Sun, Nov 26, 2023 at 10:34:34AM +0300, Eugene Prokopiev wrote:

> Здравствуйте!
> 
> Не получается спроксировать repo.clojars.org:
> 
> location /clojars {
> proxy_pass https://repo.clojars.org;
> }
> 
> curl -v http://localhost/clojars/
> ...
> < HTTP/1.1 421 Misdirected Request
> ...
> <
> Requested host does not match any Subject Alternative Names (SANs) on
> TLS certificate
> [f38588ca7dc3f37ec048583198230295986084302bfd4d5c2d944911bd377a95] in
> use with this connection.
> 
> Visit 
> https://docs.fastly.com/en/guides/common-400-errors#error-421-misdirected-request
> for more information.
> * Connection #0 to host localhost left intact
> 
> Нагуглил в этой же рассылке волшебную директиву proxy_ssl_server_name
> on - но получается совсем странная вещь - на localhost/clojars/ мне
> уже отдают 200, но в теле совсем не тот html, что на оригинальном
> repo.clojars.org
> 
> Как это может быть и чего еще может не хватать?

У вас в конфиге написано:

proxy_pass https://repo.clojars.org;

То есть проксирование без изменения URI (note: после имени хоста в 
proxy_pass ничего нет).  Соответственно запрос к 
http://localhost/clojars/ будет возвращать то, что в норме 
возвращают по адресу https://repo.clojars.org/clojars/.

Вероятно, вы вместо этого хотели получить то, что в корне 
repo.clojars.org.  Правильная конфигурация для этого будет 
какая-то такая:

location /clojars/ {
proxy_pass https://repo.clojars.org/;
proxy_ssl_server_name on;
}

То есть:

- proxy_ssl_server_name, так как Fastly, судя по всему, всегда 
  хочет SNI, в то время как nginx по умолчанию SNI не посылает 
  (см. http://nginx.org/r/proxy_ssl_server_name/ru);

- "location /clojars/" (note: "/" в конце), чтобы в него не 
  попадали запросы вроде /clojars-foobar, а только запросы к 
  /clojars/<что-то> (а запросы к /clojars перенаправлялись на 
  /clojars/, подробнее см. http://nginx.org/r/location/ru);

- и "proxy_pass https://repo.clojars.org/;; (note: "/" в конце),
  чтобы nginx при проксировании менял URI запроса, заменяя 
  "/clojars/" на "/" (см. http://nginx.org/r/proxy_pass/ru).

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Патч ETags в NixOS

[Maxim Dounin]

Hello!

On Tue, Nov 21, 2023 at 09:53:16PM +0300, izor...@gmail.com wrote:

> Да, этот патч, забыл указать ссылку.
> Проверил без патча и добавлением строки `add_header Last-Modified "";`
> В ответе генерируется ETag: "1-4e", "1-75" и т.д. Если после изменения
> содержимого файла без изменения размера, то при запросе отдаётся файл
> из кеша, т.к. при этом ETag не изменяется. А если размер файла меняется,
> кеш обновляется.
> Вариант с использованием хеадера Last-Modified не подходит, может надо
> как-то учитывать путь к файлу для генерации ETag.

Если размера для идентификации версии файла недостаточно, то 
ожидаемо нужны другие идентификаторы.  В классических файловых 
системах таким идентификатором выступает время модификации файла.

В /nix/store, как я понимаю, идея состоит в том, что время 
модификации не нужно, потому что файлы в рамках конкретного пути 
не меняются.  Решением, целиком повторяющим эту идею, будет 
использование полного пути из /nix/store в URI, тогда всё будет 
работать так, как ожидают создатели /nix/store.

Если же хочется выкинуть из URI полный путь, то наверное имеет 
смысл думать в сторону возможности установки ETag'а из переменных
(сейчас его можно поменять в ответе клиенту, но это происходит 
после проверок If-Modified-Since / If-None-Match, и выставленное 
значение не используется самим nginx'ом).  Тогда можно будет 
поставить и использовать произвольный ETag, основываясь, например, 
на переменной $realpath_root - то есть сделать штатными средствами 
примерно то же, что пытались накостылить авторы соответствующего 
патча в NixOS.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Mime-types: обновление

[Maxim Dounin]

Hello!

On Mon, Nov 20, 2023 at 08:06:33AM +0300, izor...@gmail.com wrote:

> Да, сложнее чем я думал...
> Как минимум, я бы хотел куда-нибудь включить этот минимальный список
> MIME-типов, чтобы корректно работало GZIP сжатие:
> https://github.com/NixOS/nixpkgs/blob/3f21a22b5aafefa1845dec6f4a378a8f53d8681c/nixos/modules/services/web-servers/nginx/default.nix#L35-L68
> Некоторых из них нету в пакете mailpcap, поэтому иногда возникают
> проблемы.

Gzip-сжатие работает корректно независимо от того, какие именно 
типы файлов сказано жать.  Самое плохо, что может случиться от 
отсутствия MIME-типов - gzip-сжатие для этих файлов будет 
выключено, и соответственно общая эффективность сжатия упадёт.

Имеет смысл обсуждать ситуации, когда среди ответов есть заметный 
процент файлов какого-либо типа, который можно (и хотелось бы) 
жать, и в то же время nginx не умеет распознавать MIME-тип для 
этих файлов по расширению.  То есть типичному web-сайту приходится 
и конфигурировать gzip_types, и в добавок прописывать MIME-типы 
через types.

На вскидку я в списке по ссылке вижу следующие типы, которых 
(или аналогов для соответствующих расширений) нет в mime.types 
nginx'а:

application/ld+json
application/manifest+json
application/rdf+xml
application/x-web-app-manifest+json
application/xliff+xml
font/collection
font/otf
font/ttf
text/cache-manifest
text/calendar
text/csv
text/markdown
text/vcard
text/vnd.rim.location.xloc

В целом кажется, что для типичного web-сайта доля ответов с 
файлами таких типов должна быть около нуля, и соответственно с 
точки зрения gzip-сжатия полезность добавления этих типов примерно 
такая же.

Возможно, из этого списка стоит добавить 
application/manifest+json, text/csv и text/markdown, но скорее из 
общих соображений.

> Засада с javascript... Не явных проблем с заменой application/xml
> на text/xml случаем нету?

Сейчас в nginx'е используется text/xml, и каких-либо причин менять 
тип не прослеживается.

В то же время, базовые вопросы при изменении, если вдруг его 
делать, ровно такие же: подобное изменение может потребовать 
изменения конфигов, и соответственно должно быть явно 
документировано, а равно соответствующих изменений в коде, если 
тип где-то используется в коде (text/xml - используется).

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Патч ETags в NixOS

[Maxim Dounin]

Hello!

On Sun, Nov 19, 2023 at 04:15:42PM +0300, izor...@gmail.com wrote:

> Здравствуйте.
> 
> В NixOS используется патч ETags для корректного определения изменения
> файла, расположенного в папке /nix/store. В этой папке все файлы имеют
> временную метку установленную в 0. Поэтому без использования этого
> патча файлы в кэше перестают обновляться. Возможно ли добавить этот
> патч в Upstream?
> Подробнее:
> https://github.com/NixOS/nixpkgs/blob/master/doc/packages/nginx.section.md
> 
> Либо добавить дополнительный параметр, в котором можно указать папки
> для которых используется только механизм ETags.

Если я правильно понимаю, речь про вот этот патч:

https://github.com/NixOS/nixpkgs/blob/nixos-23.05/pkgs/servers/http/nginx/nix-etag-1.15.4.patch

Патч выглядит, скажем так, непригодным для включения куда-либо.

Если для задачи достаточно не выдавать пользователю Last-Modified, 
а выдавать только ETag (этого, вероятно, будет достаточно как 
минимум если в URI виден полный путь из /nix/store, включающий 
hash, а также в остальных случаях, если на размер можно полагаться для 
идентификации файлов), то просто убрать Last-Modified из ответов 
можно стандартным механизмом add_header 
(http://nginx.org/r/add_header):

add_header Last-Modified "";

Соответственно у ответов будет только ETag, сформированный 
nginx'ом из даты модификации файла (0 в случае /nix/store) и 
размера файла.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Mime-types: обновление

[Maxim Dounin]

Hello!

On Sun, Nov 19, 2023 at 09:20:50AM +0300, izor...@gmail.com wrote:

> Там достаточно много изменений. У многих расширений изменён MIME-тип.
> Добавлены MIME-типы которые хорошо поддаются сжатию. Всё это по
> отдельности будет сложно описать. Может получится обойтись
> несколькими коммитами?

Каждое изменение и дополнение подлежит обсуждению, а в случае 
изменений - это ещё и потенциально проблемы совместимости и 
необходимость сопутствующих изменений в коде, а равно большие 
сомнения в их целесообразности.

Скажем, про application/javascript vs. text/javascript можно 
почитать тут и далее по ссылкам:

https://trac.nginx.org/nginx/ticket/1407

Там и само изменение сомнительно, и вызовет необходимость 
изменения конфигов (скажем, если application/javascript 
используется в gzip_types, то есть это явно нужно будет 
документировать в CHANGES), и в добавок в коде нужно менять два 
места, где сейчас выдаётся application/javascript, и в стандарте 
QPACK для HTTP/3 используется application/javascript.

Пытаться подобные изменения протащить "пачкой" - можно, но не 
имеет смысла, ибо к успеху точно не приведёт.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Mime-types: обновление

[Maxim Dounin]

Hello!

On Sat, Nov 18, 2023 at 05:56:17PM +0300, izor...@gmail.com wrote:

> Здравствуйте, Максим.
> Сделал минимальный вариант файла mime-types с комментариями, чтобы можно
> было проще ориентироваться откуда взяты расширения.
> https://pastebin.com/sig1HARN

Боюсь, так это не работает.  Если хочется что-то добавить к 
существующему списку типов в mime.types, то стоит по каждому 
предлагаемому к добавлению MIME-типу расписать, что это, и зачем 
это нужно в mime.types для типичного web-сайта.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Mime-types: обновление

[Maxim Dounin]

Hello!

On Fri, Nov 17, 2023 at 10:01:25AM +0300, izor...@gmail.com wrote:

> Здравствуйте.
> Планируется ли обновление и расширенная поддержка mime типов?
> На данный момент обычно приходится использовать файл mime.types
> из приложения mailcap, но он в последнее время редко обновляется.
> Если необходимо, то могу попробовать обновить файл и отправить патч.
> На данный момент количество mime типов насчитывает около 1000-1200
> штук.

Задачи сделать так, чтобы файл mime.types в поставке содержал все 
возможные MIME-типы - не ставится.  Однако мы стараемся 
поддерживать его так, чтобы имеющихся в нём MIME-типов хватало для 
типичных web-сайтов.  Если чего-то не хватает - можно предлагать 
тут или в Trac.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: cache loader atime

[Maxim Dounin]

Hello!

On Sun, Nov 12, 2023 at 07:46:40AM +0700, Алексей wrote:

>  При перезагрузке nginx теряется LRU информация кэша.
> 
> Возможно ли сделать так, чтобы cache loader обращал внимание на atime
> файлов и использовал эти данные для формирования LRU информации?

Теоретически - наверное, можно попробовать такое 
напрограммировать.

На практике - во-первых, подозреваю в таком режиме проблемы с 
производительностью для больших кэшей (сортировать миллионы 
элементов кэша при его загрузке, чтобы получить LRU, банально 
ресурсоёмко).  Во-вторых, полезность atime, кажется, под большим 
вопросом - даже если atime есть (в нагруженных конфигурациях его 
часто просто отключают), примерно любых операций с сервером может 
оказаться достаточно, чтобы все элементы кэша подлежали удалению 
сразу после запуска nginx'а, скажем, при inactive=10m (по 
умолчанию).

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

[nginx-ru-announce] nginx-1.25.3

[Maxim Dounin]

Изменения в nginx 1.25.3  24.10.2023

*) Изменение: улучшено детектирование некорректного поведения клиентов
   при использовании HTTP/2.

*) Добавление: уменьшение времени запуска при использовании большого
   количества location'ов.
   Спасибо Yusuke Nojima.

*) Исправление: при использовании HTTP/2 без SSL в рабочем процессе мог
   произойти segmentation fault; ошибка появилась в 1.25.1.

*) Исправление: строка "Status" в заголовке ответа бэкенда с пустой
   поясняющей фразой обрабатывалась некорректно.

*) Исправление: утечки памяти во время переконфигурации при
   использовании библиотеки PCRE2.
   Спасибо ZhenZhong Wu.

*) Исправления и улучшения в HTTP/3.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru-announce mailing list
nginx-ru-announce@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru-announce

nginx-1.25.3

[Maxim Dounin]

Изменения в nginx 1.25.3  24.10.2023

*) Изменение: улучшено детектирование некорректного поведения клиентов
   при использовании HTTP/2.

*) Добавление: уменьшение времени запуска при использовании большого
   количества location'ов.
   Спасибо Yusuke Nojima.

*) Исправление: при использовании HTTP/2 без SSL в рабочем процессе мог
   произойти segmentation fault; ошибка появилась в 1.25.1.

*) Исправление: строка "Status" в заголовке ответа бэкенда с пустой
   поясняющей фразой обрабатывалась некорректно.

*) Исправление: утечки памяти во время переконфигурации при
   использовании библиотеки PCRE2.
   Спасибо ZhenZhong Wu.

*) Исправления и улучшения в HTTP/3.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Что происходит при превышении keys_zone?

[Maxim Dounin]

Hello!

On Fri, Aug 25, 2023 at 12:51:23PM +0300, Иван wrote:

> Здравствуйте!
> 
> Что происходит при превышении размера keys_zone, например, в директиве 
> proxy_cache_path ? Пишется ли ошибка в логи и, если да, то на каком 
> уровне логирования?
> 
> В моей памяти почему-то отложилось, что nginx не должен лимитировать 
> количество файлов в кеше по этому параметру, а при превышении его должен 
> сыпать ошибками в логи. Однако на практике мы сейчас, похоже, наблюдаем, 
> что из-за того, что неверно посчитали keys_zone (указали 100m для кэша с 
> более чем миллионом файлов, кеш не использовался на полную: не 
> заполнялся даже близко к max_size, а в логах тишина.

Начиная с версии 1.9.13 nginx автоматически следит за количеством 
элементов в keys_zone:

*) Добавление: теперь cache manager следит за количеством элементов в
   кэше и старается не допускать переполнений зоны разделяемой памяти.

Теоретически alert "could not allocate node in cache keys zone..." 
получить всё ещё можно (если cache manager не уследит за 
заполненностью keys_zone, и удаление самого старого элемента кэша 
тоже не поможет), но на практике это маловероятно.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

[nginx-ru-announce] nginx-1.25.2

[Maxim Dounin]

Изменения в nginx 1.25.2  15.08.2023

*) Добавление: path MTU discovery при использовании HTTP/3.

*) Добавление: поддержка шифра TLS_AES_128_CCM_SHA256 при использовании
   HTTP/3.

*) Изменение: теперь при загрузке конфигурации OpenSSL nginx использует
   appname "nginx".

*) Изменение: теперь nginx не пытается загружать конфигурацию OpenSSL,
   если для сборки OpenSSL использовался параметр --with-openssl и
   переменная окружения OPENSSL_CONF не установлена.

*) Исправление: в переменной $body_bytes_sent при использовании HTTP/3.

*) Исправление: в HTTP/3.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru-announce mailing list
nginx-ru-announce@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru-announce

nginx-1.25.2

[Maxim Dounin]

Изменения в nginx 1.25.2  15.08.2023

*) Добавление: path MTU discovery при использовании HTTP/3.

*) Добавление: поддержка шифра TLS_AES_128_CCM_SHA256 при использовании
   HTTP/3.

*) Изменение: теперь при загрузке конфигурации OpenSSL nginx использует
   appname "nginx".

*) Изменение: теперь nginx не пытается загружать конфигурацию OpenSSL,
   если для сборки OpenSSL использовался параметр --with-openssl и
   переменная окружения OPENSSL_CONF не установлена.

*) Исправление: в переменной $body_bytes_sent при использовании HTTP/3.

*) Исправление: в HTTP/3.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Наследование директив proxy_hide_header и proxy_pass_header

[Maxim Dounin]

Hello!

On Mon, Jul 24, 2023 at 06:42:14PM +0300, Gena Makhomed wrote:

> Здравствуйте, All!
> 
> Наследование директив proxy_hide_header и proxy_pass_header
> не работает ожидаемым образом, nginx 1.25.1
> конфиг:
> 
> http {
> 
>  proxy_pass_header Content-Disposition;
> 
>  server {
> 
>  server_name sentry.example.com;
> 
>  location / {
>  proxy_hide_header Content-Disposition;
>  proxy_pass http://172.17.110.100:9000;
>  }
>  }
> }
> 
> Директива proxy_hide_header не работает в такой конфигурации,
> - заголовок Content-Disposition присутствует в ответе сервера.
> 
> Если закомментировать директиву proxy_pass_header
>   на уровне http - только после этого начинает нормально
> работать директива proxy_hide_header на уровне location.
> 
> Это ошибка в коде nginx, что наследование не работает ожидаемым образом,
> или это ошибка в документации к nginx, что это явно не оговорено,
> или же это ошибка в моем понимании документации nginx?

Насколько я вижу, каких-либо специальных условий наследования для 
proxy_pass_header и proxy_hide_header в документации не указано.  
Соответственно, по общему правилу это два разных списка и они 
наследуются независимо:

- список заголовков, которые нужно спрятать, определяется 
  директивами proxy_hide_header; список наследуется с предыдущего 
  уровня, если на текущем уровне не определены директивы 
  proxy_hide_header.

- список спрятанных заголовков, которые тем не менее нужно 
  передать клиенту, определяется директивами proxy_pass_header;
  список наследуется с предыдущего уровня, если на текущем уровне 
  не определены директивы proxy_pass_header.

Наблюдаемое поведение, насколько я вижу, ожидаемому соответствует: 
в случае наличия заголовка в списке proxy_pass_header он 
передаётся клиенту, в случае отсутствия (и наличия в списке 
proxy_hide_header) - не передаётся.

> Задача у меня такая - надо включить заголовок Content-Disposition
> для всех сайтов, за исключением одного сайта - sentry self-hosted,
> для того чтобы обойти баг, который присутствует в браузере Safari.
> 
> Если я что-то делаю неправильно - как правильно решить эту задачу?
> 
> Подробнее об этом баге в браузере Safari и о workaround, для него:
> 
> https://github.com/getsentry/self-hosted/issues/2285#issuecomment-1647664859

Заголовок Content-Disposition отсутствует в proxy_hide_header по 
умолчанию, так что для решения данной задачи будет достаточно 
указать "proxy_hide_header Content-Disposition;" в конфигурации 
проксирования для Sentry.  Как, собственно, и предлагают по 
ссылке.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Уязвимость конфигураций Nginx с некорректными настройками блока alias

[Maxim Dounin]

Hello!

On Thu, Jul 13, 2023 at 05:30:54AM +0300, Gena Makhomed wrote:

> Здравствуйте, All!
> 
> https://www.opennet.ru/opennews/art.shtml?num=59383
> Уязвимость конфигураций Nginx с некорректными настройками блока alias
> 
> Это было сделано для максимизации производительности работы nginx,
> и в данный момент эту проблему в коде nginx уже нельзя исправить
> по причине обратной совместимости - потому что могут прекратить
> работать те конфигурации, которые работают у пользователей сейчас?

Location'ы в nginx'е используют префиксный матчинг, и при 
использовании location'ов без завершающего слэша - в 
соответствующий location подпадает не только запросы в конкретный 
каталог, но и все другие запросы, начинающиеся на заданный префикс.

Судя по всему, многие этого не понимают, и пытаются указывать в 
конфигурации не префиксы, а названия каталогов/файлов - что 
приводит к проблемам (как в сочетании с директивой alias, так и, 
строго говоря, и вообще без неё, см. примеры по ссылке ниже).

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

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

Подробнее я на днях писал об этом тут:

https://mailman.nginx.org/pipermail/nginx-devel/2023-July/YSJ5EIRYFWXIEZKKC6OXW76XIPMDTW6A.html

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

[nginx-ru-announce] nginx-1.25.1

[Maxim Dounin]

Изменения в nginx 1.25.1  13.06.2023

*) Добавление: директива http2, позволяющая включать HTTP/2 в отдельных
   блоках server; параметр http2 директивы listen объявлен устаревшим.

*) Изменение: поддержка HTTP/2 server push упразднена.

*) Изменение: устаревшая директива ssl больше не поддерживается.

*) Исправление: в HTTP/3 при использовании OpenSSL.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru-announce mailing list
nginx-ru-announce@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru-announce

nginx-1.25.1

[Maxim Dounin]

Изменения в nginx 1.25.1  13.06.2023

*) Добавление: директива http2, позволяющая включать HTTP/2 в отдельных
   блоках server; параметр http2 директивы listen объявлен устаревшим.

*) Изменение: поддержка HTTP/2 server push упразднена.

*) Изменение: устаревшая директива ssl больше не поддерживается.

*) Исправление: в HTTP/3 при использовании OpenSSL.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: новая версия модуля ngx_http_realip_module

[Maxim Dounin]

Hello!

On Mon, Jun 12, 2023 at 02:31:04AM +0300, Gena Makhomed wrote:

> On 09.06.2023 9:29, Maxim Dounin wrote:
> 
> >> (1) client ==> vps_server ==> main_server
> >>
> >> (2) client ==> cloudflare => vps_server ==> main_server
> 
> > Если у вас в обоих случаях vps_server проксирует всё через stream
> > с proxy_protocol, то на принимающей стороне вам в любом случае
> > надо сначала достать реальный адрес клиента из proxy_protocol.
> > А уже потом смотреть в заголовки (или не смотреть, если на
> > vps_server пришли не с IP-адресов Cloudflare).
> > 
> > То есть, фактически, для корректной работы такой схемы - нужен
> > "real_ip_recursive on;" (http://nginx.org/r/real_ip_recursive)
> > и заголовок со списком нужных адресов.
> > 
> > Сейчас из коробки такое можно сделать дополнительным
> > проксированием с установкой заголовка.  Для стандартного заголовка
> > X-Forwarded-For, благо Cloudflare его ставит, конфигурация будет
> > выглядеть как-то так:
> > 
> > server {
> >  listen 8080 proxy_protocol;
> > 
> >  set_real_ip_from ;
> >  real_ip_header proxy_protocol;
> > 
> >  location / {
> >  proxy_pass http://127.0.0.1:8081;
> >  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> >  }
> > }
> > 
> > server {
> >  listen 8081;
> >  
> >  set_real_ip_from 127.0.0.1;
> >  set_real_ip_from ;
> > 
> >  real_ip_header X-Forwarded-For;
> >  real_ip_recursive on;
> > 
> >  ...
> > }
> 
> Это будет работать только в том случае, если система защиты от DDoS
> указывает IP адрес клиента в заголовке X-Forwarded-For. Если же какая-то
> экзотическая система защиты от DDoS будет указывать реальный IP клиента
> в каком-то другом заголовке, например, только в загловке X-Real-IP -
> тогда этот метод работать не будет, потому что в nginx есть переменная
> $proxy_add_x_forwarded_for но в nginx нет перменной $proxy_add_x_real_ip
> 
> Что же нам делать в том случае, если какая-то система защиты от DDoS
> передает реальный IP клиента в заголовке отличном от X-Forwarded-For ?

Если нужно работать с нестандартными заголовками - это можно 
сделать с помощью модуля map, благо сейчас его возможностей с 
лихвой хватает для реализации логики, аналогичной работе 
переменной $proxy_add_x_forwarded_for.

Не говоря уже о том, что, по большому счёту, в данной конкретной 
задаче полная логика $proxy_add_x_forwarded_for не важна, и вполне 
можно обойтись безусловным добавлением адреса через запятую:

proxy_set_header X-Real-IP "$http_x_real_ip, $remote_addr";

В вырожденном случае пустого $http_x_real_ip будет лишняя запятая 
в начале, но на работоспособность это не влияет.

> >> Или существует какой-то еще лучший вариант решения этой задачи?
> > 
> > Я периодически думаю о том, чтобы научить модуль realip брать
> > список IP-адресов не из заголовка, а непосредственно из
> > переменной.  Тогда необходимость в дополнительном проксировании в
> > подобных странных конфигурациях отпадёт.
> 
> Каким же образом тут можно будет обойтись без двойного проксирования,
> если необходимо будет сначала указывать real_ip_header proxy_protocol;
> чтобы узнать реальный IP сервера cloudflare, который подключился к VPS,
> и при этом - несколько директив real_ip_header нельзя указывать в одном
> контексте. А если указать одну директиву real_ip_header одновременно
> и в контексте server и одну в контексте location, то согласно правил
> наследования директив в nginx - директива real_ip_header в контексте
> location будет выполняться, а директива real_ip_header в контексте
> server выполняться не будет, и всегда будет просто проигнорирована.
> 
> Максим, можете пояснить в чем тут моя ошибка и что я не так понял?

Идея состоит в том, что вместо указания названия заголовка в 
директиве real_ip_header - указать непосредственно адреса.  Тогда 
вместо

real_ip_header proxy_protocol;

можно будет написать что-то вроде:

real_ip_address $proxy_protocol_addr;

А для последующего рекурсивного поиска в заголовке X-Forwarded-For 
(если он получен с доверенного адреса), соответственно, будет 
достаточно написать:

real_ip_address "$http_x_forwarded_for, $proxy_protocol_addr";

И, соответственно, полная конфигурация будет выглядеть как:

server {
listen 8080 proxy_protocol;
 
set_real_ip_from ;
set_real_ip_from ;

real_ip_address "$http_x_forwarded_for, $proxy_protocol_addr";
real_ip_recursive on;

...
}

То есть ровно то, что в примере выше делается с помощью 
дополнительного проксирования - в такой схеме будет сделано с 
помощью установки

Re: множественные директивы real_ip_header

[Maxim Dounin]

Hello!

On Sun, Jun 04, 2023 at 09:40:17PM +0300, Gena Makhomed wrote:

> Здравствуйте, All!
> 
> Есть такая конфигурация:
> 
> (1) client ==> vps_server ==> main_server
> 
> (2) client ==> cloudflare => vps_server ==> main_server
> 
> vps_server слушает на 80 и 443 портах и через модуль stream проксирует
> запроcы на main_server через tcp, передавая на main_server информацию
> о реальном IP клинта через proxy_protocol. Все SSL сертификаты
> и конфигурации сайтов хранятся при этом только на main_server.
> 
> В первом случае для получения реального IP клиента - в блоке
> server надо прописать:
> 
> set_real_ip_from 11.22.33.44;  # IP адрес vps_server
> real_ip_header proxy_protocol;
> 
> Во втором случае для получения реального IP клиента - в блоке
> server надо прописать:
> 
> set_real_ip_from 173.245.48.0/20;
> ...
> set_real_ip_from 2c0f:f248::/32;
> real_ip_header CF-Connecting-IP;

Если у вас в обоих случаях vps_server проксирует всё через stream 
с proxy_protocol, то на принимающей стороне вам в любом случае 
надо сначала достать реальный адрес клиента из proxy_protocol.  А 
уже потом смотреть в заголовки (или не смотреть, если на 
vps_server пришли не с IP-адресов Cloudflare).

То есть, фактически, для корректной работы такой схемы - нужен 
"real_ip_recursive on;" (http://nginx.org/r/real_ip_recursive) и 
заголовок со списком нужных адресов.

Сейчас из коробки такое можно сделать дополнительным 
проксированием с установкой заголовка.  Для стандартного заголовка 
X-Forwarded-For, благо Cloudflare его ставит, конфигурация будет 
выглядеть как-то так:

server {
listen 8080 proxy_protocol;
   
set_real_ip_from ;
real_ip_header proxy_protocol;

location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

server {
listen 8081;

set_real_ip_from 127.0.0.1;
set_real_ip_from ;

real_ip_header X-Forwarded-For;
real_ip_recursive on;

...
}

[...]

> Или существует какой-то еще лучший вариант решения этой задачи?

Я периодически думаю о том, чтобы научить модуль realip брать 
список IP-адресов не из заголовка, а непосредственно из 
переменной.  Тогда необходимость в дополнительном проксировании в 
подобных странных конфигурациях отпадёт.

Но в целом это выглядит как достаточно маргинальный use case, 
IMHO, и доступное сейчас решение с дополнительным проксированием 
ему плюс-минус адекватно.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

[nginx-ru-announce] nginx-1.25.0

[Maxim Dounin]

Изменения в nginx 1.25.0  23.05.2023

*) Добавление: экспериментальная поддержка HTTP/3.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru-announce mailing list
nginx-ru-announce@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru-announce

nginx-1.25.0

[Maxim Dounin]

Изменения в nginx 1.25.0  23.05.2023

*) Добавление: экспериментальная поддержка HTTP/3.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

[nginx-ru-announce] nginx-1.24.0

[Maxim Dounin]

Изменения в nginx 1.24.0  11.04.2023

*) Стабильная ветка 1.24.x.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru-announce mailing list
nginx-ru-announce@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru-announce

nginx-1.24.0

[Maxim Dounin]

Изменения в nginx 1.24.0  11.04.2023

*) Стабильная ветка 1.24.x.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

[nginx-ru-announce] nginx-1.23.4

[Maxim Dounin]

Изменения в nginx 1.23.4  28.03.2023

*) Изменение: теперь протокол TLSv1.3 разрешён по умолчанию.

*) Изменение: теперь nginx выдаёт предупреждение при переопределении
   параметров listen-сокета, задающих используемые протоколы.

*) Изменение: теперь, если клиент использует pipelining, nginx закрывает
   соединения с ожиданием дополнительных данных (lingering close).

*) Добавление: поддержка byte ranges для ответов модуля
   ngx_http_gzip_static_module.

*) Исправление: диапазоны портов в директиве listen не работали; ошибка
   появилась в 1.23.3.
   Спасибо Валентину Бартеневу.

*) Исправление: для обработки запроса мог быть выбран неверный location,
   если в конфигурации использовался префиксный location длиннее 255
   символов.

*) Исправление: не-ASCII символы в именах файлов на Windows не
   поддерживались модулями ngx_http_autoindex_module и
   ngx_http_dav_module, а также директивой include.

*) Изменение: уровень логгирования ошибок SSL "data length too long",
   "length too short", "bad legacy version", "no shared signature
   algorithms", "bad digest length", "missing sigalgs extension",
   "encrypted length too long", "bad length", "bad key update", "mixed
   handshake and non handshake data", "ccs received early", "data
   between ccs and finished", "packet length too long", "too many warn
   alerts", "record too small", и "got a fin before a ccs" понижен с
   уровня crit до info.

*) Исправление: при использовании HTTP/2 и директивы error_page для
   перенаправления ошибок с кодом 400 могла происходить утечка сокетов.

*) Исправление: сообщения об ошибках записи в syslog не содержали
   информации о том, что ошибки происходили в процессе записи в syslog.
   Спасибо Safar Safarly.

*) Изменение: при использовании zlib-ng в логах появлялись сообщения
   "gzip filter failed to use preallocated memory".

*) Исправление: в почтовом прокси-сервере.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru-announce mailing list
nginx-ru-announce@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru-announce

nginx-1.23.4

[Maxim Dounin]

Изменения в nginx 1.23.4  28.03.2023

*) Изменение: теперь протокол TLSv1.3 разрешён по умолчанию.

*) Изменение: теперь nginx выдаёт предупреждение при переопределении
   параметров listen-сокета, задающих используемые протоколы.

*) Изменение: теперь, если клиент использует pipelining, nginx закрывает
   соединения с ожиданием дополнительных данных (lingering close).

*) Добавление: поддержка byte ranges для ответов модуля
   ngx_http_gzip_static_module.

*) Исправление: диапазоны портов в директиве listen не работали; ошибка
   появилась в 1.23.3.
   Спасибо Валентину Бартеневу.

*) Исправление: для обработки запроса мог быть выбран неверный location,
   если в конфигурации использовался префиксный location длиннее 255
   символов.

*) Исправление: не-ASCII символы в именах файлов на Windows не
   поддерживались модулями ngx_http_autoindex_module и
   ngx_http_dav_module, а также директивой include.

*) Изменение: уровень логгирования ошибок SSL "data length too long",
   "length too short", "bad legacy version", "no shared signature
   algorithms", "bad digest length", "missing sigalgs extension",
   "encrypted length too long", "bad length", "bad key update", "mixed
   handshake and non handshake data", "ccs received early", "data
   between ccs and finished", "packet length too long", "too many warn
   alerts", "record too small", и "got a fin before a ccs" понижен с
   уровня crit до info.

*) Исправление: при использовании HTTP/2 и директивы error_page для
   перенаправления ошибок с кодом 400 могла происходить утечка сокетов.

*) Исправление: сообщения об ошибках записи в syslog не содержали
   информации о том, что ошибки происходили в процессе записи в syslog.
   Спасибо Safar Safarly.

*) Изменение: при использовании zlib-ng в логах появлялись сообщения
   "gzip filter failed to use preallocated memory".

*) Исправление: в почтовом прокси-сервере.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [proposal] SERVER_NAME в fastcgi_params

[Maxim Dounin]

Hello!

On Mon, Mar 13, 2023 at 10:50:37AM +0300, Nikolay Shaplov wrote:

> В письме от понедельник, 13 марта 2023 г. 10:46:51 MSK пользователь Maksim 
> Kulik написал:
> > Мне кажется, что в RFC речь идет скорее про разные блоки server {}, т.к.
> > речь явно про several virtual hosts, а не про several server names. То есть
> > веб-сервер вполне корректно по RFC выбирает блок server {} по имени хоста и
> > используется главное имя этого блока далее в работе.
> > Вы в своем примере имеете один виртуал хост и N имен (алиасов, если хотите)
> > в нем, где N может быть бесконечным в случае дефолтного хоста. Ваш сервер и
> > выбирает этот самый хост по имени, которое видит в заголовке.
> Правильно. И то имя которое совпало должно попасть в переменную окружения 
> SERVER_NAME
> 
> Ну даже если не читать сам текст RFC (а там по-моему предельно ясно все 
> написано), из соображений общий логики, почему в SERVER_NAME попадает первый 
> из алиасов, а не тот на который пришли??? В этом нет вообще никакой логики.

Потому что первое из имён, указанных в директиве server_name - 
каноническое.  Это, кстати, явно описано в документации 
(https://nginx.org/ru/docs/http/ngx_http_core_module.html#server_name):

: Первое имя становится основным именем сервера.

Разделение на каноническое имя и алиасы - оно ещё из Apache, где 
имя сервера указывается отдельно, директивой ServerName, а алиасы, 
соответственно, директивой ServerAlias.  В nginx'е всех отличий в 
этом плане - алиасы задаются с помощью той же директивы 
server_name.

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

Скажем, мы можем хотеть во всех перенаправлениях / ссылках / 
текстах использовать каноническое имя, чтобы пользователь получал 
одно и то же, независимо от того, по какому конкретно имени он 
пришёл.  Например, это может быть важно, чтобы тексты 
сгенерированных страниц всегда совпадали, и их можно было 
кэшировать для всех пользователей.  Или просто из эстетических 
соображений.

Или наоборот, можем хотеть, чтобы пользователю всегда возвращались 
ссылки ровно с тем именем, на которое он пришёл, потому что для 
разных пользователей сайт может быть доступен под разными именами.

Что именно нужно в конкретной конфигурации - это решение того, кто 
пишет конфигурацию nginx'а.  В некоторых случаях оно явно вынесено 
в отдельные директивы (см. упоминавшуюся ранее 
server_name_in_redirect), в случае же CGI-like бэкендов оно 
делается неявно с помощью задания переменной SERVER_NAME.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [proposal] SERVER_NAME в fastcgi_params

[Maxim Dounin]

Hello!

On Mon, Mar 13, 2023 at 10:33:36AM +0300, Nikolay Shaplov wrote:

> В письме от понедельник, 13 марта 2023 г. 10:27:10 MSK пользователь Maxim 
> Dounin написал:
> > Hello!
> > 
> > On Mon, Mar 13, 2023 at 09:20:49AM +0300, Nikolay Shaplov wrote:
> > > В письме от понедельник, 13 марта 2023 г. 09:17:17 MSK пользователь Dmitry
> > > 
> > > Ivanov написал:
> > > > Вы писали 5 марта 2023 г., 18:41:17:
> > > > > При этом в самом конфиге сайта server_name не указан, сервер
> > > > > обслуживает
> > > > > все доменные имена (фильтрация по имени осуществляется на фронтэнде).
> > > > 
> > > > Видимо, надо потыкать в RFC разработчиков фронта и забыть о "проблеме"
> > > 
> > > Не достаточно. Если перечислить все обслуживаемые доменные имена в
> > > server_name, то в SERVER_NAME при подключении дефолтного fastcgi_params
> > > попадает первое из них, а не то, на которое пришли. Что явно противоречит
> > > RFC. Я вроде об этом уже писал выше по треду.
> > 
> > Не противоречит, на бэкенд отправляется каноническое имя
> > виртуального сервера.  
> 
>A deployed server can have more than one possible value for this
>variable, where several HTTP virtual hosts share the same IP address.
>In that case, the server would use the contents of the request's Host
>header field to select the correct virtual host.
> 
> Но как? Английским по белому написано ", the server would use the 
> contents 
> of the request's Host header field to select the correct virtual host"

Так nginx и использует "request's Host header field to select the 
correct virtual host" (на самом деле там сложнее, подробнее в 
стандартах HTTP).  И в соответствии с этим - ставит SERVER_NAME в 
каноническое значение имени выбранного виртуального сервера.

Нормативного требования использовать значение заголовка Host в 
переменной SERVER_NAME - в RFC 3875 нет.  (И, в общем-то, быть не 
может, потому что такое требование противоречило бы нормативным 
требованиям стандарта HTTP, см. выше про "там сложнее".)

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [proposal] SERVER_NAME в fastcgi_params

[Maxim Dounin]

Hello!

On Mon, Mar 13, 2023 at 09:20:49AM +0300, Nikolay Shaplov wrote:

> В письме от понедельник, 13 марта 2023 г. 09:17:17 MSK пользователь Dmitry 
> Ivanov написал:
> 
> > Вы писали 5 марта 2023 г., 18:41:17:
> > > При этом в самом конфиге сайта server_name не указан, сервер обслуживает
> > > все доменные имена (фильтрация по имени осуществляется на фронтэнде).
> > 
> > Видимо, надо потыкать в RFC разработчиков фронта и забыть о "проблеме"
> 
> Не достаточно. Если перечислить все обслуживаемые доменные имена в 
> server_name, то в SERVER_NAME при подключении дефолтного fastcgi_params 
> попадает первое из них, а не то, на которое пришли. Что явно противоречит 
> RFC. 
> Я вроде об этом уже писал выше по треду.

Не противоречит, на бэкенд отправляется каноническое имя 
виртуального сервера.  Хотите, чтобы было по другому - 
сконфигурируйте по другому и/или явно опишите виртуальные сервера, 
в разных блоках server{}.

Подробнее про текущее поведение я писал тут:

https://mailman.nginx.org/pipermail/nginx-ru/2023-March/USR4N4KMUMDT2KKUV4J5RJVBOZTSNCFF.html

Если остались какие-то вопросы - спрашивайте.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [proposal] SERVER_NAME в fastcgi_params

[Maxim Dounin]

Hello!

On Mon, Mar 06, 2023 at 05:17:34PM +0300, Evgeniy Berdnikov wrote:

> On Mon, Mar 06, 2023 at 02:22:25PM +0300, Andrey Kopeyko wrote:
> > On Mon, 6 Mar 2023, Nikolay Shaplov wrote:
> > > Я бы с этим всем согласился, приняв на веру, если бы в RFC не было бы
> > > написано:
> > > 
> > > The SERVER_NAME variable MUST be set to the name of the server host
> > > to which the client request is directed.
> > 
> > Вот это самое правило вы и нарушаете, в описанной вами конфигурации, - но
> > раз вам так надо и вы понимаете что вы делаете, то пускай.
> 
>  Товарищ, наверное, хотел сказать, что составитель дефолтной конфигурации
>  не заметил некоторые проблемы, с которыми могут столнуться пользователи.
>  И что если вместо $server_name написать $host, то вероятность возникновения
>  этих проблем будет несколько ниже. С чем трудно не согласиться.
> 
>  Как всегда, ждём, какие аргументы придумают авторы, чтобы ничего не менять. 
> :)

Да вообще легко :))

Дефолтная конфигурация, по историческим причинам, заточена на 
конфигурации, где server_name задан: это было поведением по 
умолчанию до nginx версии 0.8.48.

Подобная конфигурация в целом предполагает, что запрашиваемое 
клиентом имя может использовать для выбора блока server{}, но в 
дальнейшем не используется: для всех остальных действий 
используется каноническое имя сервера.  Например, все 
перенаправления возвращаются с использованием канонического имени 
сервера (см. server_name_in_redirect).

Очевидно, что в подобной конфигурации SERVER_NAME, передаваемый в 
CGI-like бэкенды, тоже должен отражать каноническое имя сервера, 
то есть $server_name.  Замена его на $host приведёт к 
использованию в CGI-like бэкендах некорректного имени, 
использование которого не предполагается конфигурацией.  Более 
того, если речь идёт про сервер по умолчанию для данного 
слушающего сокета - то имя окажется полностью под контролем 
клиента, что может привести уже к проблемам безопасности, если на 
бэкенде что-либо завязано на проверку этого имени.

Суммируя вышеизложенное: замена $server_name на $host 
гарантировано сломает конфигурации, полагающиеся на существующее 
поведение с передачей на CGI-like бэкенды канонического имени 
сервера, и для корректной работы таких конфигураций потребуется 
менять $host на $server_name обратно.

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

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [proposal] SERVER_NAME в fastcgi_params

[Maxim Dounin]

Hello!

On Mon, Mar 06, 2023 at 02:22:25PM +0300, Andrey Kopeyko wrote:

> On Mon, 6 Mar 2023, Nikolay Shaplov wrote:
> 
> > В письме от понедельник, 6 марта 2023 г. 13:59:30 MSK пользователь Andrey 
> > Kopeyko написал:
> >> к "нарушению RFC" приводит ваша конкретная конфигурация - когда вы
> >> обрабатываете множество имён в дефолтном сервере, для которого вы _не
> >> задаёте_ server_name.
> >> 
> >> Вот корень всех бед.
> >> 
> >> И именно поэтому дефолтное поведение менять не следует.
> >
> > Я бы с этим всем согласился, приняв на веру, если бы в RFC не было бы 
> > написано:
> >
> > The SERVER_NAME variable MUST be set to the name of the server host
> > to which the client request is directed.
> 
> Вот это самое правило вы и нарушаете, в описанной вами конфигурации, - но раз 
> вам так надо и вы понимаете что вы делаете, то пускай.
> 
> Обходной хак вам подсказали - использовать $http_host, и быть готовым что там 
> тоже может быть пусто.

Я скромно замечу, что использовать переменную $http_host для чего 
либо, кроме проверки собственно заголовка Host - не стоит.  
Этот заголовок может отсутствовать вообще или не совпадать с тем 
хостом, которому обращался клиент.  Конфигурация с $http_host - 
это почти всегда как минимум глюки в краевых случаях, а как 
максимум - "дыра в безопасности".

Как уже было верно отмечено в этом треде, если нужна переменная, 
отражающая запрошенный клиентом хост, то следует использовать 
переменную $host.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx stream module, dynamic upstream

[Maxim Dounin]

Hello!

On Thu, Jan 12, 2023 at 04:37:40PM +0300, Sergey K wrote:

> В документации сказано, что можно использовать upstream с переменными
> (stream module).
> 
> 
> proxy_pass $upstream;
> В этом случае имя сервера ищется среди описанных групп серверов и если не
> найдено, то определяется с помощью resolver’а.
> 
> 
> Однако, в случае изменения айпи адреса для postgres.local  nginx не видит
> изменений и продолжает обращаться к старому айпи адресу апстрима.
> 
> nginx/1.18.0
> 
> 
>   upstream postgres {
> server postgres.local:5432;
>   }
> 
>   map stream $upstream {
> default postgres;
>   }
> 
>   server {
> listen 5432;
> 
> access_log  /var/log/nginx/stream.access.log  proxy buffer=32k
> flush=10s;
> 
> proxy_pass $upstream;
> resolver 10.0.0.2 valid=30s;
>   }
> 
> 
> похоже на баг либо я делаю что-то не верно?

У вас имя сервера, указанного в proxy_pass, ищется среди описанных 
групп серверов, и оно найдено - в конфигурации есть upstream с 
именем "postgres".  Соответственно resolver не используется.

Что до имени сервера, указанного в группе серверов "postgres", а 
именно "postgres.local", то это имя по общим правилам 
преобразуется в IP-адреса при загрузке конфигурации.

Если хочется, чтобы nginx разнимался преобразованием имени в 
IP-адреса при каждом обращении, то не надо описывать upstream, а 
следует просто указать имя сервера с использованием переменных, 
как-то так:

   map stream $upstream { default "postgres.local:5432"; }

   server {
   ...
   proxy_pass $upstream;
   resolver 10.0.0.2 valid=30s;
   }

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Максимальная длина ключа proxy_cache_key

[Maxim Dounin]

Hello!

On Thu, Dec 22, 2022 at 03:45:54PM +0200, Иван wrote:

> Подскажите, пожалуйста, какая максимальная длина значения ключа 
> *_cache_key ? Хотим сделать
> 
> proxy_cache_key $cookie_somecookie ,
> 
> где длина somecookie может быть до килобайта. Допустимо ли это и не 
> будет ли каких-то внезапных спецэффектов?

На длину ключа нет ограничений, но стоит помнить, что он полностью 
хранится в заголовке кэша, а тот в свою очередь должен влезать в 
proxy_buffer_size.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

[nginx-ru-announce] nginx-1.23.3

[Maxim Dounin]

Изменения в nginx 1.23.3  13.12.2022

*) Исправление: при чтении заголовка протокола PROXY версии 2,
   содержащего большое количество TLV, могла возникать ошибка.

*) Исправление: при использовании SSI для обработки подзапросов,
   созданных другими модулями, в рабочем процессе мог произойти
   segmentation fault.
   Спасибо Ciel Zhao.

*) Изменение: теперь, если при преобразовании в адреса имени хоста,
   указанного в директиве listen, возвращается несколько адресов, nginx
   игнорирует дубликаты среди этих адресов.

*) Исправление: nginx мог нагружать процессор при небуферизированном
   проксировании, если использовались SSL-соединения с бэкендами.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru-announce mailing list
nginx-ru-announce@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru-announce

nginx-1.23.3

[Maxim Dounin]

Изменения в nginx 1.23.3  13.12.2022

*) Исправление: при чтении заголовка протокола PROXY версии 2,
   содержащего большое количество TLV, могла возникать ошибка.

*) Исправление: при использовании SSI для обработки подзапросов,
   созданных другими модулями, в рабочем процессе мог произойти
   segmentation fault.
   Спасибо Ciel Zhao.

*) Изменение: теперь, если при преобразовании в адреса имени хоста,
   указанного в директиве listen, возвращается несколько адресов, nginx
   игнорирует дубликаты среди этих адресов.

*) Исправление: nginx мог нагружать процессор при небуферизированном
   проксировании, если использовались SSL-соединения с бэкендами.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Статический анализ nginx

[Maxim Dounin]

Hello!

On Tue, Nov 22, 2022 at 01:49:22PM +, Korobov Vladimir via nginx-ru wrote:

> Статический анализ исходного кода выявил некоторые непонятные для меня места.
> ngx_http_proxy_module.c: строка 1489
> 
> while (*(uintptr_t *) le.ip) {
> 
> lcode = *(ngx_http_script_len_code_pt *) le.ip;
> (void) lcode();

[...]

> code = *(ngx_http_script_code_pt *) e.ip;
> code((ngx_http_script_engine_t *) );

[...]

> }
> 
> В этой строке e.ip не проверяется на валидность перед 
> использованием, хотя в этом файле это всегда делается перед 
> использованием. Помогите понять почему?

Тут e.ip используется после проверки le.ip в начале цикла.  Если 
вдруг e.ip окажется NULL - это означает, что коды в 
headers->lengths и headers->values рассинхронизированы, и всё 
происходящее не имеет смысла.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: gzip proxy

[Maxim Dounin]

Hello!

On Thu, Nov 17, 2022 at 10:48:52AM +0300, MihaKot wrote:

> Столкнулся с проблемой, и не могу понять где косяк.
> 
> есть сервер proxy (gate)
> есть сервер приложения (client)
> 
> почему то не срабатывает  сжатие. т.е. пользаку отдается не сжатый контент.
> 
> конфиг на клиенте
> 
> gzip on; # Enable Gzip compressed.
> 
> gzip_http_version  1.1;

[...]

> конфиг на gate
> 
> server {
> listen *:443 ssl http2;
> index index.html;
> server_name *.ru;
> client_max_body_size 0;
> 
> ssl_certificate /etc/nginx/ssl/***.ru/cert.pem;
> ssl_certificate_key /etc/nginx/ssl/.ru/key.pem;
> 
> include conf.d/ssl.conf;
> include conf.d/headers.conf;
> #include conf.d/_gzip.conf;
> 
> location / {
> proxy_pass http://cluster_host;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $remote_addr;
> port_in_redirect off;
> proxy_connect_timeout 120;
> }

По умолчанию при проксировании используется HTTP/1.0 
(http://nginx.org/r/proxy_http_version), при этом сжатие ответов у 
вас включено только для HTTP/1.1.  Соответственно в вашей 
конфигурации бэкенд будет всегда отдавать несжатые ответы.

Нужно либо на бэкенде включить сжатие для HTTP/1.0 (что может быть 
не очень хорошей идеей), либо переключить проксирование на 
HTTP/1.1, либо сжимать ответы на фронтенде.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Первый выпуск Angie, форка Nginx от разработчиков, ушедших из компании F5

[Maxim Dounin]

Hello!

On Thu, Nov 03, 2022 at 05:05:57PM +0200, Gena Makhomed wrote:

> Максим, можете рассказать, что Вы думаете по этому поводу?

Лицензия позволяет, если ребята хотят делать форк - никто не может 
им этого запретить.  Успехов им.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: ssl_protocols / ssl_conf_command - nginx bug or nginx documentation bug ?

[Maxim Dounin]

Hello!

On Tue, Oct 25, 2022 at 07:47:15AM +0300, Gena Makhomed wrote:

> On 25.10.2022 7:28, Maxim Dounin wrote:
> 
> >> https://github.com/mozilla/ssl-config-generator/issues/124#issuecomment-1288224600
> 
> > Полной конфигурации там не приведено, так что остаётся только
> > гадать, но судя по всему это очередной пользователь, который
> > пытается задавать разные ssl_protocols в name-based виртуальных
> > серверах.  Так работать не будет, потому что OpenSSL фиксирует
> > протокол раньше, чем становится известно имя.  При этом в разных
> > IP-based (или port-based) виртуальных серверах вполне можно
> > использовать различные ssl_protocols.
> 
> Понятно, спасибо.
> 
> Может быть имеет смысл научить nginx, чтобы он выдавал варнинг
> в момент чтения конфигурации, если пользователь будет пытаться
> задавать разные ssl_protocols в name-based виртуальных серверах?

В общем случае неизвестно, является ли виртуальный сервер 
name-based или IP/port-based.  Не говоря уже о случаях, когда 
сервер и такой, и такой одновременно.  И не говоря уже о том, что 
всё это вообще говоря особенность реализации OpenSSL, а как оно 
работает в той SSL-библиотеке, что у пользователя - мы не знаем.

> Или вообще, просто если встречается директива "ssl_protocols"
> и "ssl_conf_command" in non-default server{} blocks,
> even if SNI is used.

А ssl_conf_command вообще тут ни коим боком: мы не знаем, что 
именно с помощью неё пытаются сделать, и не знаем, как оно будет 
(или не будет) работать в каких случаях.  В документации явно 
сделано предупреждение о возможных непредсказуемых последствиях, 
остальное - зона ответственности того, кто писал конфигурацию.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: ssl_protocols / ssl_conf_command - nginx bug or nginx documentation bug ?

[Maxim Dounin]

Hello!

On Tue, Oct 25, 2022 at 06:41:56AM +0300, Gena Makhomed wrote:

> У некоторых пользователей nginx возникли затруднения:
> 
> https://github.com/mozilla/ssl-config-generator/issues/124#issuecomment-1288224600
> 
> Только не понятно, это ошибка в самом nginx или ошибка в документации к 
> nginx.
> 
> Максим, можете ответить этому пользователю на github, в чем там дело?
> У меня английский такой, что пишу с ошибками, кроме того, я не уверен,
> что сам правильно понимаю, в чем именно состоит проблема этого пользователя.

Полной конфигурации там не приведено, так что остаётся только 
гадать, но судя по всему это очередной пользователь, который 
пытается задавать разные ssl_protocols в name-based виртуальных 
серверах.  Так работать не будет, потому что OpenSSL фиксирует 
протокол раньше, чем становится известно имя.  При этом в разных 
IP-based (или port-based) виртуальных серверах вполне можно 
использовать различные ssl_protocols.

Подробнее об этом есть тут:

https://trac.nginx.org/nginx/ticket/676
https://mailman.nginx.org/pipermail/nginx/2014-November/045738.html

Этот и другие нюансы применения конфигурации для name-based 
виртуальных серверов документированы тут:

http://nginx.org/en/docs/http/server_names.html#virtual_server_selection

Что до TLSv1.3 Ciphersuites, то их OpenSSL, судя по всему, тоже 
выбирает сразу при установлении соединения, и соответственно 
задавать их в name-based виртуальных серверах бессмысленно, надо 
задавать в сервере по умолчанию.  Это, впрочем, уже вообще не про 
nginx, если человек лезет в настройки OpenSSL напрямую, минуя 
nginx, он сам кузнец своего счастья.

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

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Работа location с алиасом

[Maxim Dounin]

Hello!

On Mon, Oct 24, 2022 at 09:46:51AM +0300, izor...@gmail.com wrote:

> Вариант с использованием префиксной строки будет быстрее обрабатываться
> nginx-ом, по сравнение с использованием регулярных выражений? Не смотря
> на увеличение итогового объёма конфигурационного файла?
> ```
> root /var/www;
> 
> location / {
>   try_files $uri =404;
> }
> 
> location /test/ {
>   try_files $uri =404;
>   alias /var/test/;
> }
> 
> location /custom/ {
>   try_files $uri =404;
>   alias /var/test/;
> }
> ```

Основное тут не скорость, а простота поддержки.  Скажем, если вы в 
данный конфиг добавите что-нибудь вроде

location /test/images/ {
alias /var/test/images/
expires max;
}

то в случае префиксных строк всё будет работать так, как должно, 
то есть для файлов в /test/images/ будут возвращаться 
соответствующие заголовки Expires и Cache-Control.

А в случае регулярных выражений просто ничего не произойдёт, и 
запросы продолжат обрабатываться в location'е, заданном 
регулярным выражением.  И чтобы это понять, придётся внимательно 
прочитать весь конфиг.

Подробнее об этом и других случаях у Игоря в докладе, 
"Масштабируемая конфигурация nginx":

https://youtu.be/jf3wIN-FwW4
https://highload.guide/blog/scalable-configuration-nginx.html

Скорость, впрочем, тут тоже будет больше.  Кроме разве что совсем 
вырожденных случаев, когда одним регулярным выражением заменяются 
тысячи префиксных location'ов, и начинает сильно влиять объём 
конфигурации в памяти.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Работа location с алиасом

[Maxim Dounin]

Hello!

On Sun, Oct 23, 2022 at 08:19:58PM +0300, izor...@gmail.com wrote:

> Здравствуйте.
> 
> Сейчас столкнулся с непонятной ошибкой.
> 
> Тестовый пример:
> ```
> root /var/www;
> 
> location / {
>   try_files $uri =404;
> }
> 
> location /test/ {
>   try_files $uri =404;
>   alias /var/test/;
> }
> ```
> 
> Проверяю доступность тестового файла через curl:
> ```
> curl --head -k https://example.com/test/example.txt
> HTTP/2 200
> ...
> ```
> 
> Файл доступен. Лог отладки:
> ```
> ...
> *302 test location: "/"
> *302 test location: "test/"
> *302 using configuration "/test/"
> ...
> *302 http script var: "/test/example.txt"
> *302 trying to use file: "example.txt" "/var/test/example.txt"
> *302 try file uri: "/test/example.txt"
> ...
> *302 http filename: "/var/test/example.txt"
> ...
> *302 http2 output header: ":status: 200"
> ...
> ```
> 
> Меняю location `test` на такой вариант:
> ```
> location ~ ^/(test|custom)/ {
>   try_files $uri =404;
>   alias /var/test/;
> }
> ```
> 
> Теперь файл не доступен. По идее должно работать... Лог отладки:
> ```
> ...
> *303 test location: "/"
> *303 test location: ~ "^/(test|custom)/"
> *303 using configuration "^/(test|custom)/"
> ...
> *303 http script copy: "/var/test/"
> *303 http script var: "/test/example.txt"
> *303 trying to use file: "/test/example.txt" "/var/test//test/example.txt"
> *303 trying to use file: "=404" "/var/test/=404"
> *303 http finalize request: 404, "/test/example.txt?" a:1, c:1
> *303 http special response: 404, "/test/example.txt?"
> ...
> *303 http2 output header: ":status: 404"
> ...
> ```
> 
> Так и должно работать?
> Только вот если убрать параметр `alias /var/test/;`, то `location /test/` и 
> `location ~ ^/(test|custom)/` работают одинаково.

Директива "alias" заменяет совпавшую часть location'а на заданный 
путь.  Если же location задан регулярным выражением, то "совпавшей 
части" как таковой нет, и это работает так (цитата по 
http://nginx.org/r/alias/ru):

: Если alias используется внутри location’а, заданного регулярным 
: выражением, то регулярное выражение должно содержать выделения, а 
: сам alias — ссылки на эти выделения (0.7.40), например:
: 
: location ~ ^/users/(.+\.(?:gif|jpe?g|png))$ {
:     alias /data/w3/images/$1;
: }

То есть всё работает ровно так, как должно/документировано. 

Безусловно, в конкретном примере оно работает не очень ожидаемо 
для пользователя.  Но, скажем так, это не единственный пример, 
когда location'ы, заданные регулярными выражениями, работают не 
очень ожидаемо для пользователя.  Лучше использовать location'ы, 
заданные префиксной строкой, Игорь даже как-то доклад об этом 
делал.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

[nginx-ru-announce] nginx-1.23.2

[Maxim Dounin]

Изменения в nginx 1.23.2  19.10.2022

*) Безопасность: обработка специально созданного mp4-файла модулем
   ngx_http_mp4_module могла приводить к падению рабочего процесса,
   отправке клиенту части содержимого памяти рабочего процесса, а также
   потенциально могла иметь другие последствия (CVE-2022-41741,
   CVE-2022-41742).

*) Добавление: переменные "$proxy_protocol_tlv_...".

*) Добавление: ключи шифрования TLS session tickets теперь автоматически
   меняются при использовании разделяемой памяти в ssl_session_cache.

*) Изменение: уровень логгирования ошибок SSL "bad record type" понижен
   с уровня crit до info.
   Спасибо Murilo Andrade.

*) Изменение: теперь при использовании разделяемой памяти в
   ssl_session_cache сообщения "could not allocate new session"
   логгируются на уровне warn вместо alert и не чаще одного раза в
   секунду.

*) Исправление: nginx/Windows не собирался с OpenSSL 3.0.x.

*) Исправление: в логгировании ошибок протокола PROXY.
   Спасибо Сергею Брестеру.

*) Изменение: при использовании TLSv1.3 с OpenSSL разделяемая память из
   ssl_session_cache расходовалась в том числе на сессии, использующие
   TLS session tickets.

*) Изменение: таймаут, заданный с помощью директивы ssl_session_timeout,
   не работал при использовании TLSv1.3 с OpenSSL или BoringSSL.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru-announce mailing list -- nginx-ru-announce@nginx.org
To unsubscribe send an email to nginx-ru-announce-le...@nginx.org

[nginx-ru-announce] nginx security advisory (CVE-2022-41741, CVE-2022-41742)

[Maxim Dounin]

Hello!

В модуле ngx_http_mp4_module были обнаружены две проблемы, которые
позволяют с помощью специально созданного mp4-файла вызвать 
падение рабочего процесса, отправку клиенту части содержимого памяти
рабочего процесса, а также потенциально могут иметь другие последствия
(CVE-2022-41741, CVE-2022-41742).

Проблемам подвержен nginx, если он собран с модулем ngx_http_mp4_module
(по умолчанию не собирается) и директива mp4 используется в
конфигурационном файле.  При этом атака возможна только в случае, если
атакующий имеет возможность обеспечить обработку специально созданного
mp4-файла с помощью модуля ngx_http_mp4_module.

Проблемам подвержен nginx 1.1.3+, 1.0.7+.
Проблемы исправлены в 1.23.2, 1.22.1.

Патч, исправляющий проблемы, доступен тут:

http://nginx.org/download/patch.2022.mp4.txt


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru-announce mailing list -- nginx-ru-announce@nginx.org
To unsubscribe send an email to nginx-ru-announce-le...@nginx.org

[nginx-ru-announce] nginx-1.22.1

[Maxim Dounin]

Изменения в nginx 1.22.1  19.10.2022

*) Безопасность: обработка специально созданного mp4-файла модулем
   ngx_http_mp4_module могла приводить к падению рабочего процесса,
   отправке клиенту части содержимого памяти рабочего процесса, а также
   потенциально могла иметь другие последствия (CVE-2022-41741,
   CVE-2022-41742).


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru-announce mailing list -- nginx-ru-announce@nginx.org
To unsubscribe send an email to nginx-ru-announce-le...@nginx.org

nginx security advisory (CVE-2022-41741, CVE-2022-41742)

[Maxim Dounin]

Hello!

В модуле ngx_http_mp4_module были обнаружены две проблемы, которые
позволяют с помощью специально созданного mp4-файла вызвать 
падение рабочего процесса, отправку клиенту части содержимого памяти
рабочего процесса, а также потенциально могут иметь другие последствия
(CVE-2022-41741, CVE-2022-41742).

Проблемам подвержен nginx, если он собран с модулем ngx_http_mp4_module
(по умолчанию не собирается) и директива mp4 используется в
конфигурационном файле.  При этом атака возможна только в случае, если
атакующий имеет возможность обеспечить обработку специально созданного
mp4-файла с помощью модуля ngx_http_mp4_module.

Проблемам подвержен nginx 1.1.3+, 1.0.7+.
Проблемы исправлены в 1.23.2, 1.22.1.

Патч, исправляющий проблемы, доступен тут:

http://nginx.org/download/patch.2022.mp4.txt


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

nginx-1.22.1

[Maxim Dounin]

Изменения в nginx 1.22.1  19.10.2022

*) Безопасность: обработка специально созданного mp4-файла модулем
   ngx_http_mp4_module могла приводить к падению рабочего процесса,
   отправке клиенту части содержимого памяти рабочего процесса, а также
   потенциально могла иметь другие последствия (CVE-2022-41741,
   CVE-2022-41742).


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

nginx-1.23.2

[Maxim Dounin]

Изменения в nginx 1.23.2  19.10.2022

*) Безопасность: обработка специально созданного mp4-файла модулем
   ngx_http_mp4_module могла приводить к падению рабочего процесса,
   отправке клиенту части содержимого памяти рабочего процесса, а также
   потенциально могла иметь другие последствия (CVE-2022-41741,
   CVE-2022-41742).

*) Добавление: переменные "$proxy_protocol_tlv_...".

*) Добавление: ключи шифрования TLS session tickets теперь автоматически
   меняются при использовании разделяемой памяти в ssl_session_cache.

*) Изменение: уровень логгирования ошибок SSL "bad record type" понижен
   с уровня crit до info.
   Спасибо Murilo Andrade.

*) Изменение: теперь при использовании разделяемой памяти в
   ssl_session_cache сообщения "could not allocate new session"
   логгируются на уровне warn вместо alert и не чаще одного раза в
   секунду.

*) Исправление: nginx/Windows не собирался с OpenSSL 3.0.x.

*) Исправление: в логгировании ошибок протокола PROXY.
   Спасибо Сергею Брестеру.

*) Изменение: при использовании TLSv1.3 с OpenSSL разделяемая память из
   ssl_session_cache расходовалась в том числе на сессии, использующие
   TLS session tickets.

*) Изменение: таймаут, заданный с помощью директивы ssl_session_timeout,
   не работал при использовании TLSv1.3 с OpenSSL или BoringSSL.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Не понятна логика работы hash consistent

[Maxim Dounin]

Hello!

On Thu, Oct 13, 2022 at 11:52:42AM +0300, Александр Кунич via nginx-ru wrote:

[...]

> А подскажите ещё пожалуйста, строится ли отдельный круг ketama для 
> серверов с меткой backup? Т.е. если в конфигурации будет указано 
> несколько серверов с меткой backup, то запросы, приходящие на эти 
> сервера будут тоже консистентными?

Формально backup-сервера вообще не поддерживаются при 
использовании методов балансировки hash, ip_hash и random, см. 
тут:

http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#backup

И если сначала задать метод балансировки, а потом уже описывать 
сервера, то использовать флаг "backup" nginx не разрешит.

Если же сервера уже описаны к тому моменту, как задан метод 
балансировки, и соответственно известно, что backup-сервера не 
поддерживаются, в текущей реализации nginx такое пропускает.  При 
этом, опять же в текущей реализации, при hash-балансировке nginx 
пытается делать до 20 попыток перехэширования для выбора сервера, 
и если за эти 20 попыток он не смог найти работающий сервер - то 
nginx переключается в режим round-robin-балансировки для выбора 
хоть какого-то сервера из оставшихся (если хотя бы что-то 
осталось).  И уже в этом режиме срабатывают backup-сервера, если 
они вдруг были заданы.

Соответственно, если вы задали backup-сервера при 
hash-балансировке, то они будут использоваться только в рамках 
перехода к round-robin-балансировке при невозможности выбрать 
сервер с помощью hash-балансировки, и для выбора из 
backup-серверов будет использоваться round-robin-балансировка.  Но 
по хорошему так делать не надо, это особенность реализации, а не 
гарантированное поведение.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Исправления срабатываний статического анализатора.

[Maxim Dounin]

Hello!

On Tue, Oct 04, 2022 at 11:33:14PM +0700, Eugene Grosbein wrote:

> 04.10.2022 20:11, Evgeniy Berdnikov пишет:
> > On Tue, Oct 04, 2022 at 12:00:57PM +, Korobov Vladimir via nginx-ru 
> > wrote:
> >>После проверки исходного кода статическим анализатором (Svace
> >>https://www.ispras.ru/technologies/svace/) выделено несколько 
> >> потенциально
> >>опасных мест, закрывающихся приложенным патчем.
> > 
> >  Тупое выбрасывание кусков кода при проверке указателя на NULL не только
> >  не решает проблему, но создаёт более опасную ситуацию, когда код приложения
> >  может работать неверно, но ничего об этом не сообщать, так что поймать баг
> >  станет очень трудно. Лучше сегфолт в в точно локализованном месте, чем
> >  глюки непонятно где и непонятно отчего.
> > 
> >  При потенциальной возможности зануления указателя следует ловить и
> >  обрабатывать такое исключение. В противном случае нет смысла в проверке.
> >  Задача же не в ублажении тупых анализаторов, а в правильной работе кода.
> 
> Как пользователь разнообразного софта, могу доложить, что сегфолт очень 
> фиговая обработка исключений.
> Проверка указателя на NULL перед разадресацией в том случае, когда нельзя 
> гарантировать что он не NULL,
> практически всегда благо. Другой вопрос, что потом делать, если вдруг: молча 
> восстановиться и ехать дальше,
> или не молча, а с сообщением в лог, или выдать даже stack trace и выйти. Но 
> что угодно лучше сырого сегфолта.

Так о том и речь, что в данном случае есть, потенциально, два 
варианта:

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

- Статический анализатор не прав, и в рассматриваемых местах 
  появление нулевых указателей невозможно (ну, кроме случая memory 
  corruption).  Тогда добавлять проверки с игнорированием кода опять 
  же неправильно: они ничего не будут делать в штатном режиме, а в 
  случае memory corruption - ещё и увеличивают шанс получить code 
  execution вместо segmentation fault.  То есть патч опять же 
  плохой.

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

Вообще, по моему опыту - в большинстве случаев статические 
анализаторы, даже лучшие, приносят мусор.  Но иногда случается и 
что-нибудь полезное, поэтому жалобы какого-нибудь Coverity - 
регулярно отсматриваются.  Но надо понимать, что анализ жалоб 
какого-либо статического анализатора - это кропотливый труда, а не 
взять и заткнуть тупыми проверками всё, на что оно вдруг решило 
пожаловаться по каким-то своим внутренним причинам.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Не понятна логика работы hash consistent

[Maxim Dounin]

Hello!

On Mon, Oct 03, 2022 at 10:30:17AM +0300, Александр Кунич via nginx-ru wrote:

> Здравствуйте.
> 
> Подскажите пожалуйста, это у меня не работает консистентное хеширование 
> или я не верно понимаю алгоритм его работы.
> 
> У меня в системе апстримы в конфигурации ниже являются кеширующими 
> прокси. Недавно понадобилось перераспределить часть нагрузки между ними 
> и понял, что веса работают не так, как я ожидал.
> 
> Опишу по порядку. С пол года конфигурация была такой. Кеш на прокси 
> апстримах прогрелся до 95% попаданий.
> 
> upstream upstream_meed {
>      server  192.168.1.1:8080 max_fails=3 fail_timeout=30s;
>      server  192.168.1.2:8080 backup max_fails=3 fail_timeout=30s;
>      server  192.168.1.3:8080 max_fails=3 fail_timeout=30s;
>      hash $request_uri consistent;
>      keepalive 128;
> }
> 
> Затем понадобилось часть нагрузки перенести на 192.168.1.2. Снял метку 
> backup  с 192.168.1.2 , готовился к тому, что попадания в кеш на 
> 192.168.1.1 и 192.168.1.3 снизятся, но этого не произошло. Просто 
> нагрузка на 192.168.1.2 существенно выросла. Тут первый вопрос - почему? 
> Т.е. как ketama должен обрабатывать метку backup?

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

Для consistent-хэширования добавление нового сервера означает, что 
часть нагрузки с существующих серверов будет перенесена на 
добавленный.  Больше никаких изменений не будет.  Соответственно 
то, что процент попаданий в кэш на ранее использовавшихся серверах 
не поменялся - это вполне нормально, так как исключены ситуации, 
когда запрос ранее попадал на 192.168.1.1, а теперь стал попадать 
на 192.168.1.3 (или наоборот).

При этом часть кэша на 192.168.1.1 и 192.168.1.3 стала не нужна 
(так как соответствующие запросы уехали на 192.168.1.2), но на 
процент попаданий в кэш оставшихся запросов это влиять никак не 
должно.

> Далее потребовалось перераспределить ещё немного нагрузку и вот тут 
> выявилось самое интересное.
> 
> upstream upstream_meed {
>      server  192.168.1.1:8080 weight=13 max_fails=3 fail_timeout=30s;
>      server  192.168.1.2:8080 weight=7 max_fails=3 fail_timeout=30s;
>      server  192.168.1.3:8080 weight=10 max_fails=3 fail_timeout=30s;
>      hash $request_uri consistent;
>      keepalive 128;
> }
> 
> В этой конфигурации ожидалось, что 192.168.1.3 останется на прежнем 
> месте круга хеширования кетама и промахов кеша у него не добавится. Но 
> оказалось вовсе не так. Промахи добавились везде и существенно. Далее я 
> попробовал у всех серверов выставить последовательно одинаковые веса. 
> Сначала всем weight=1 - попадания в кеш восстановились, затем всем 
> выставил weight=10 - попадания с 95% упали почти до 50%.
> 
> До этого я полагал, что в алгоритме хеширования кетама играет роль 
> пропорциональность весов и порядковое место сервера в списке. Согласно 
> этого понимания, две приведённые ниже конфигурации должны быть 
> равнозначны в плане попаданий кеш.
> 
> upstream upstream_meed {
>      server  192.168.1.1:8080 weight=1 max_fails=3 fail_timeout=30s;
>      server  192.168.1.2:8080 weight=1 max_fails=3 fail_timeout=30s;
>      server  192.168.1.3:8080 weight=1 max_fails=3 fail_timeout=30s;
>      hash $request_uri consistent;
>      keepalive 128;
> }
> 
> upstream upstream_meed {
>      server  192.168.1.1:8080 weight=10 max_fails=3 fail_timeout=30s;
>      server  192.168.1.2:8080 weight=10 max_fails=3 fail_timeout=30s;
>      server  192.168.1.3:8080 weight=10 max_fails=3 fail_timeout=30s;
>      hash $request_uri consistent;
>      keepalive 128;
> }
> 
> На практике у меня это не работает. С весом 10 попадания сильно 
> уменьшаются. Это я что-то не так понимаю или у меня не работает ketama ?

При consistent-хэшировании вес реализован с помощью добавления 
дополнительных точек для данного сервера.  То есть, фактически, 
увеличение веса сервера с 1 до 2 эквивалентно добавлению ещё 
одного сервера.  Соответственно изменение весов трёх серверов с 1 
на 10 эквивалентно добавлению 27 новых серверов, и ожидаемо 
приводит к сильной ребалансировке существующих запросов между 
серверами.

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

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Два разных сертификата на хост

[Maxim Dounin]

Hello!

On Mon, Sep 26, 2022 at 06:48:16PM -0400, oradba25 wrote:

> Добрый день
> 
> В документации есть фраза, что "Начиная с версии 1.11.0 эта директива
> [ssl_certificate] может быть указана несколько раз для загрузки сертификатов
> разных типов, например RSA и ECDSA"
> 
> Вопрос -- можно ли использовать при этом цепочки разных ЦА, например
> GlobalSign и МинЦифры
> 
> Для чего, понятно, в связи с текущими событиями плавно перейти на Российские
> сертификаты
> 
> Или это можно сделать каким-либо другим способом не дублируя конфигурацию в
> разных виртуальных серверах?

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

Для выбора между "российскими сертификатами" и нормальными на 
сервере нужно знать, примет ли клиент "российский сертификат", или 
же доверяет только тем корневым CA, наличия которых можно ожидать 
в стандартных браузерах.  Такой информации в рамках установления 
SSL-соединения на сервере просто нет.  Соответственно выбор придётся 
делать на основе отдельного имени сервера, если вы хотите выбор.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Пустой coredump ��ля сигнал�� 11

[Maxim Dounin]

Hello!

On Fri, Sep 23, 2022 at 10:39:11AM +0400, Dmytro Lavryk wrote:

> В наше время, к сожалению, "необходимый минимум" определяется не 
> техническими деталями, а заклинаниями "SEO-шников", "менеджеров 
> по продвижению" и прочих магов.

Мне кажется, вы некорректно используете слова.  Подобные 
требования стоит называть нетехническими требованиями вашего 
руководства, а не "необходимым минимумом".

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

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Пустой coredump ��ля сигнал�� 11

[Maxim Dounin]

Hello!

On Thu, Sep 22, 2022 at 11:17:34PM +0400, Dmytro Lavryk wrote:

> У меня лично, что падает. Я не настолько силен, чтобы с 
> корефайлами разобраться :( Просто странности - что с идентичными 
> сборками (в плане сторонних модулей) на одних серверах воркеры 
> падают периодически, а на других работают без проблем. Я как раз 
> изначально и пытался понять в чем именно проблема, но собирал 
> совершенно идентичные (в плане сторонних модулей и версий) а 
> разница все равно есть.
> 
> Лично я все же грешу на бротли, т.к. из общения с мейнтейнером 
> порта выяснили, что при обновлении, после которого это все 
> начало проявляться,  менялся исключительно бротли модуль. Но 
> выключить бротли не могу. Тестовых нет, а  на рабочих наличие 
> бротли в наше время это необходимый минимум.

Отсутствие segfault'ов - это необходимый минимум.  Если у вас со 
сторонними модулями сыпятся segfault'ы - нужно либо выключить 
сторонние модули, либо разобраться и устранить эти segfault'ы.

Самый правильный способ, чтобы разобраться, если вы не умеете 
читать код и смотреть stack backtrace'ы - это выключить все 
сторонние модули, убедиться в отсутствии проблемы, потом включать 
их по одному и/или дихотомией, и тем самым определить модуль, 
вызывающий проблему.  И дальше уже разбираться с конкретным 
модулем, либо самостоятельно, либо жалуясь разработчикам 
этого модуля.

Тут, впрочем, скорее всего всё равно придётся учиться как минимум 
включать запись core-файлов (в этом треде хватает подробностей), а 
также выучить команду "gdb /path/to/nginx /path/to/core" и 
"backtrace" в нём.

Что касается Brotli, то там, насколько я понимаю, в реальной 
жизни примерно одно преимущество: он чуть быстрее, чем gzip, при 
сравнимом уровне сжатия, и чуть лучше жмёт при том же потреблении 
процессора[1].  И с памятью, как я понимаю, при этом хуже, чем у 
gzip.  Даже в условиях идеальной работы библиотеки и модуля - ну 
такое, на "необходимый минимум" не тянет.

[1] 
https://paulcalvano.com/2018-07-25-brotli-compression-how-much-will-it-reduce-your-content/

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Пустой coredump ��ля сигнал�� 11

[Maxim Dounin]

Hello!

On Thu, Sep 22, 2022 at 09:12:58AM +0400, Dmytro Lavryk wrote:

> Здравствуйте. 
> Если можно - отпишите по результатам, если что получится. Имею 
> несколько таких серверов. Bug отписывал  - менйтейнер ничего 
> понять не может.
> Диагноз такой - по версию nginx/1.18.0 (включительно) проблема 
> не проявляется. В следующей, после этой версии в портах поменяли 
> сборку brotli на гугловскую.
> После этой версии проблема проявляется в случайном порядке - на 
> одних серверах проблема есть, на других нету. С чем связано - я 
> лично понять не могу - разные версии ОС, и одинаковые... Но с 
> обновлениями проблема не уходит, т.е. если на определенном 
> сервере проявилась - то так дальше с версиями и "шагает".

А у вас в чём именно проблема - в том, что nginx со сторонними 
модулями падает, или в том, что при падениях не получается 
сохранять core-файлы?

Базовый рецепт для лечения падений со сторонними модулями, если 
что, простой: убрать сторонние модули.  Ну и дальше уже можно 
смотреть, что именно вызывает падения.  И смотреть в те самые 
core-файлы, опять же.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Пустой coredump ��ля сигнал�� 11

[Maxim Dounin]

Hello!

On Thu, Sep 22, 2022 at 03:00:09PM +0400, Dmytro Lavryk wrote:

> Я ошибся. "Writing" наоборот подскакивает в моменты падений.

Подскакивающий в моменты падений "Writing" - это нормально и 
собственно следствие падений.  Каждый упавший рабочий процесс 
"оставляет" в статистике свои значения на момент падения, и при 
падениях все метрики будут расти.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Пустой coredump для сигнала 11

[Maxim Dounin]

Hello!

On Wed, Sep 21, 2022 at 07:27:11PM -0400, edo888 wrote:

> Спасибо за ответ. Вы правильно отметили, я сам добавил "(core not dumped)"
> во время отладки.
> 
> У меня больше 100 ГБ места. В сообщениях у меня только это:
> kernel: pid NNN (nginx), jid 0, uid 80: exited on signal 11
> 
> Не знаю, что мне еще сделать.

Если при этом core-файл создаётся, но каких-либо сообщений об 
ошибках записи дампа нет - то стоит ещё раз посмотреть на лимит 
RLIMIT_CORE.  Судя по kern/kern_sig.c и kern/imgact_elf.c - 
превышение (ненулевого) лимита это примерно единственный случай, 
когда файл будет создан, но ничего не будет записано и при этом не 
будет ошибок.

Проверьте размеры рабочих процессов, и поднимите лимит 
worker_rlimit_core до значения, перекрывающего размеры рабочих 
процессов с запасом.  Ну и не забудьте перезагрузить конфигурацию 
и/или перезапустить nginx.  (Just in case, текущие лимиты рабочих 
процессов можно посмотреть или поменять с помощью команды
"limits -P ").

И лучше после этого протестировать работу дампа явно руками, 
послав что-нибудь вроде сигнала 6 (abort) одному из рабочих 
процессов.  При реальном падении размер рабочего процесса 
непосредственно перед падением может резко вырасти, скажем, если у 
вас там какой-нибудь код, который сначала выделяет много памяти, и 
только потом падает.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Пустой coredump для сигнала 11

[Maxim Dounin]

Hello!

On Wed, Sep 21, 2022 at 02:31:42PM -0400, edo888 wrote:

> Здравствуйте,
> 
> Очень редко у меня в журнале ошибок появляется "worker process NNN exited on
> signal 11 (core not dumped)"
> 
> Я пытаюсь создать дамп, но что бы я ни делал, он не создается или его размер
> равен 0.
> 
> Я использую FreeBSD, и первое, что я попытался сделать, это разрешить nginx
> создавать дампы, но независимо от того, насколько большой я установил
> worker_rlimit_core, дампы не создаются. Я проверил исходный код и вижу
> следующее:
> 
> /usr/include/sys/signal.h:
> #define SIGSEGV 11 /* segmentation violation */
> 
> /usr/include/sys/wait.h:
> #define WCOREFLAG 0200
> #define _W_INT(i) (i)
> #define WCOREDUMP(x) (_W_INT(x) & WCOREFLAG)
> 
> nginx/src/os/unix/ngx_process.c:
> ngx_log_error(NGX_LOG_ALERT, ngx_cycle->log, 0, "%s %P exited on signal
> %d%s", process, pid, WTERMSIG(status), WCOREDUMP(status) ? " (core dumped)"
> : " (core not dumped)");

В nginx'е такого кода нет, там вместо "(core not dumped)" стоит 
пустая строка.  Это вы сами правили для наглядности, или где-то 
взяли версию со сторонними патчами?  Если второе - то лучше взять 
из портов или с nginx.org версию без сторонних изменений.

> Это означает, что WCOREDUMP(11) равен 0 и дамп создаваться не будет. Так что
> не знаю, что мне делать.
> 
> Я также попытался включить дампы ядра через ОС, установив sysctl
> kern.sugid_coredump=1 и sysctl kern.corefile=/home/coredump/%N.core.%P, а
> для ulimit установлено значение unlimited. После этого я вижу, что дампы
> имеют размер 0.
> 
> Можете подсказать, как включить дампы для сигнала 11?

Убедиться, что стоит kern.sugid_coredump, стоит kern.corefile, рабочий 
процесс nginx'а имеет права на запись в указанный в kern.corefile 
каталог, и на соответствующем диске хватает места.

Если файл создаётся, но при этом нулевого размера - скорее всего 
дело в отсутствии места на диске.  Где-то в /var/log/messages 
система будет плакать как-то так:

Sep 22 01:33:34 vm-bsd kernel: pid 10513 (nginx), uid 65534 inumber 429133 on 
/: filesystem full
Sep 22 01:33:34 vm-bsd kernel: Failed to write core file for process nginx 
(error 28)
Sep 22 01:33:34 vm-bsd kernel: pid 10513 (nginx), jid 0, uid 65534: exited on 
signal 6

Успехов в разборках, если что - приходите с вопросами, FreeBSD тут 
многие знают хорошо.  Но лучше напрямую в mailing list, а не через 
гейт на форуме.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: как передать cache-control заголовок от апстрима в браузер

[Maxim Dounin]

Hello!

On Wed, Sep 21, 2022 at 11:09:18AM +0300, VovansystemS wrote:

> nginx используется как кеширующий реверс-прокси, апстрим с Апачем
> выставляет заголовок:
> Cache-Control: public, max-age=0, must-revalidate
> 
> Nginx руководствуется этим заголовком для того, чтобы определить каким
> образом кешировать ответ апстрима, но посетителю Nginx отдаёт ответ с
> заголовком:
> Cache-Control: no-cache,no-store
> 
> Необходимо сделать так, чтобы заголовок "Cache-Control: public,
> max-age=0, must-revalidate" получал посетитель (браузер). Как лучше
> всего этого добиться?

Убрать конфигурацию, которая прячет исходный заголовок 
Cache-Control (proxy_hide_header?) и добавляет вместо него 
"no-cache,no-store"?

По умолчанию nginx отдаёт клиенту ровно тот заголовок 
Cache-Control, какой получил от бэкенда.  Чтобы вернуть что-то 
другое - нужно это явно сконфигурировать.  Причём получить "no-store" с 
помощью простых стандартных механизмов, как то директива expires, 
не получится.  То есть либо у вас это должно быть явно в конфиге 
nginx'а, либо такой заголовок всё-таки возвращает бэкенд.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: игрорировать некорректные заголовки для upstream

[Maxim Dounin]

Hello!

On Tue, Sep 20, 2022 at 08:51:30PM +0300, Igor Savenko wrote:

> Сама проблема в том, что nginx да, ругается в логе, но при этом он еще и
> отдает 502 ошибку. Поэтому просто искали способ хотя бы игнорировать
> некорректные заголовки, но пропускать ответ бекэнда клиенту

Сообщение в логе как раз о том, что nginx не может получить ответ 
от бэкенда, так как тот возвращает мусор вместо заголовков ответа 
и получить ответ nginx в результате не может.  Соответственно 
клиенту и возвращается ошибка.

Как уже сказано ранее, править это надо на бэкенде.  В качестве 
временного workaround'а можно попробовать grpc_pass.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: игрорировать некорректные заголовки для upstream

[Maxim Dounin]

Hello!

On Tue, Sep 20, 2022 at 07:35:32PM +0300, Igor Savenko wrote:

> Добрый день! Странная ситуация, апстримом для nginx является лайтспид, и
> вот этот лайтспид на http2 отдает нормальные заголовки ответа, а для
> http/1.1 некорректные, например, вот это выводит curl:
> curl -s -v --http1.1 -o /dev/null https://domain.com/images/12345.png
> --resolve domain.com:443:1.2.3.4
> ...
> > GET /images/12345.png HTTP/1.1
> > Host: domain.com
> > User-Agent: curl/7.74.0
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Connection: Keep-Alive
> < Keep-Alive: timeout=5, max=100
> expires: Thu, 20 Oct 2022 15:48:24 GMTc
> < content-type: image/png
> < last-modified: Tue, 08 Feb 2022 17:03:26 GMT
> < accept-ranges: bytes
> < content-length: 847
> < date: Tue, 20 Sep 2022 15:48:24 GMT
> < server: LiteSpeed
> 
> Обратите внимание на начало заголовка expires, он не начинается с <
> символа, следовательно, или в начале этого, или в конце предыдущего
> заголовка приезжает некорректный символ. Насколько я знаю, nginx не
> поддерживает http/2 для общения с апстримом. Отсюда вопрос. Есть дешевый
> способ заставить nginx игнорировать некорректные произвольные заголовки
> (полностью заголовок, а не только название) от апстрима, а не только
> заранее определенные, как в директиве proxy_ignore_headers
> <http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_headers>
>  ?

Судя по выводу curl'а, между предыдущим заголовком и expires 
вместо CRLF или LF стоит просто CR.  В логах nginx'а при этом 
должна быть какая-то такая ошибка:

2022/09/20 12:59:16 [error] 2866#100147: *1 upstream sent invalid header: 
"X-Foo: foo\x0d..." while reading response header from upstream...

Лечить это надо на бэкенде, подобных вольностей в обращении с 
протоколом nginx не допускает и до какой-либо обработки заголовков 
и/или их игнорирования тут дело не дойдёт, всё сломается при попытке 
парсинга заголовков ответа.

Если в краткосрочной перспективе с бэкендом сделать ничего нельзя, 
то в качестве временного workaround'а можно попробовать 
проксировать по HTTP/2 через grpc_pass.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: msec в заголовке

[Maxim Dounin]

Hello!

On Fri, Sep 16, 2022 at 06:18:53AM -0400, opan wrote:

> Проксируя запросы на fastcgi-бекенд, передаем в одном из заголовков $msec.
> При этом приложение, сравнивая время, полученное в заголовке, и настоящее
> для него, дает аномальный дифф - до 40мс внутри локалки, а иногда и
> отрицательное, до -5мс.
> 
> Внутри локальной сети пакеты бегают быстро - от 1 до 7мс, resolver_timeout
> не задан, ntp на сервере с nginx и бекенде синхронизирован (разница с
> ntp-сервером на каждом из серверов в пределах 1мс).
> 
> Пытаемся разобраться и возник вопрос, какое время в таком случае (при
> прокидывании в заголовке) показывает $msec? Момент получения запроса от
> клиента , момент коннекшна к бекенду, момент соединения с бекендом или еще
> какое-то?

Как уже ответил Сергей, время - на момент формирования заголовков 
запроса к бэкенду, то есть после получения клиентского запроса, но 
до попыток установления соединения с бэкендом (и до резолвинга, но 
в вашем случае его вроде как быть не должно).

Но тут ещё важно учитывать, что время в nginx'е обновляется только 
в начале каждой итерации цикла обработки событий, в момент 
получения из ядра очередной порции событий.  Соответственно если 
какой-то из обрабатываемых в той же итерации запросов пошёл, 
например, на диск - он может легко задержать обработку миллисекунд 
на десять (ибо seek time), а если таких запросов будет два - то и 
на все двадцать, и так далее.  То же относится и к другим 
блокирующимся операциям.

Всё это может давать достаточно большую положительную разницу с 
текущим временем в приложении, даже если собственно установление 
соединения и отправка конкретного запроса произошла быстро.  
Откуда в вашем случае отрицательная разница - вопрос, вероятно, к 
приложению.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Отсутствует запрос в access логе

[Maxim Dounin]

Hello!

On Tue, Sep 13, 2022 at 01:07:29PM +0300, Igor Savenko wrote:

> Большое спасибо! Да, включен http/2 и на прокси, и на application сервере.
> Но если бы имела место ситуация с закрытием соединения, то прокси должен
> был бы ругаться в логах первым, а у прокси в error.log все чисто. На
> application сервере включен rate limit, и я где-то читал, что в старых
> версиях nginx мог отдавать в логе нули если запросы попали под
> rate-лимитирование. Воспроизвести, однако, пока не удалось -- ожидаемо
> отдавался код 503.

Судя по пустому значению $request - заголовки запроса ещё не 
получены от клиента, соответственно до application-сервера такой 
запрос точно ещё не дошёл.  Смотреть имеет смысл только и 
исключительно на proxy, с которого access-лог.

Если в error.log на proxy-сервере при этом всё чисто, то я бы 
начал с проверки установленного уровня логгирования ошибок.  
Обсуждаемые сообщения должны быть на уровне info, то есть они 
достаточно низкоуровневые.  Вероятнее всего уровень логгирования 
установлен выше, и сообщения на уровне info туда просто не 
попадают.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Отсутствует запрос в access логе

[Maxim Dounin]

Hello!

On Mon, Sep 12, 2022 at 07:40:16PM +0300, Igor Savenko wrote:

> Прокси-сервер, с которого строчка лога
> log_format  main  '$remote_addr - $remote_user [$time_local] "$request"
> '
>   '$status $body_bytes_sent $host "$http_referer" '
>   '"$http_user_agent"';
> 
> access_log  /var/log/nginx/access.log  main;
> 
> Application-server, который за прокси-сервером:
> 
> access_log /var/log/nginx/access.log combined buffer=4k flush=5m;

HTTP/2 включён?

Такое может быть, если клиент начинает присылать заголовки запроса 
в нескольких фреймах по HTTP/2-соединению, но не досылает их, а 
шлёт какой-то мусор или просто закрывает соединение.

В логе ошибок при этом будет что-то вроде "client sent 
inappropriate frame while CONTINUATION was expected while 
processing HTTP/2 connection" или "client prematurely closed 
connection while processing HTTP/2 connection" на уровне info.

[...]

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Отсутствует запрос в access логе

[Maxim Dounin]

Hello!

On Mon, Sep 12, 2022 at 04:28:24PM +0300, Igor Savenko wrote:

> Добрый день. Nginx в качестве прокси сервера, в логе наблюдается вот такие
> странные записи:
> 1.2.3.4 - - [08/Sep/2022:23:10:33 +0300] "-" 000 0 domain.org "
> https://domain.org/; "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36" ,
> то есть request path, status code и body size по нулям (ip адрес запроса и
> домен/реферер заменены на нейтральные, они никакой смысловой нагрузки не
> несут). Проксирование на nginx 1.19 + php-fpm, вот такая конфигурация, но
> имеем то, что имеем. Есть мысли, как такое может получиться?

Какой при этом log_format в конфиге?

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Пользовательская переменная между секциями server

[Maxim Dounin]

Hello!

On Fri, Sep 09, 2022 at 03:46:26AM -0400, sunrules wrote:

> Попробовал map, к сожалению, все тоже самое. В основную секцию server, в
> которой определяется server_name, пользовательская переменная передает
> нужное значение, что получаем из map, но если эту переменную прописать в
> секцию server, где описываются бэкенды, то результат - пустое значение.
> Причем, если в map определить значение глобальной переменной, а не той
> строчкой с регуляркой, то тогда в секцию бэкенда значение передается, то
> есть все это работает, но с какими-то странностями. 
> Версия Nginx 1.13, такую используем по определенным причинам.
> Ради эксперимента хочу проверить это в более новой версии Nginx.
> Если есть у кого-нибудь мысли, почему такое поведение, буду признателен.

Переменные - это свойство _запроса_.  Если вы запрос куда-то 
проксируете, пусть даже на тот же самый nginx, они на проксируемый 
сервер магически не попадут, там будет новый запрос и новые 
переменные.

Если хотите что-то передать на проксируемый сервер - делайте это 
явно.  Один из наиболее простых способов - добавить в запрос на 
проксируемый сервер специальный заголовок с помощью директивы 
proxy_set_header, а потом, соответственно, на проксируемом сервере 
получить значение этого заголовка с помощью переменной $http_*.  
То есть в вашем случае как-то так:

   proxy_set_header X-Site-Release $site_release;

и далее на проксиремом сервере:

   proxy_pass http://$http_x_site_release.site.back1.example.org/;

Подробнее тут:

http://nginx.org/r/proxy_set_header/ru
http://nginx.org/r/$http_/ru

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: set $no cache 0 не работает.

[Maxim Dounin]

Hello!

On Wed, Aug 03, 2022 at 10:24:13AM -0400, milov wrote:

> Есть код
> 
> set $no_cache 0;
> 
> if ($request_method = POST){set $no_cache 1;}
> if ($http_host ~* success.html$){set $no_cache 1;}
> if ($remote_addr ~* ^(192.168.0*)$){set $no_cache 1;}
> 
> # Не берется из кеша
> fastcgi_cache_bypass $no_cache;
> 
> # Не сохраняется в кеш
> fastcgi_no_cache $no_cache;
> 
> Ни один if не срабатывает, т.е. сохраняет в кеш и берёт из кеша. Куда
> смотреть, копать?

А должны?

Первый if не имеет смысла, т.к. POST-запросы не кэшируются по 
умолчанию (см. http://nginx.org/r/fastcgi_cache_methods/ru).  Его 
явно можно просто выкинуть.

Второй if не имеет смысла, так как в переменной $http_host 
содержится заголовок запроса Host, и там указывается только 
доменное имя и порт (если этот заголовок вообще присутствует в 
запросе), так что вряд ли он содержит что-либо похожее на 
"success.html$".  Возможно, имелась в виду переменная $uri (хотя 
лучше, конечно, для подобных вещей делать отдельный location без 
кэширования).

Третий if не имеет смысла, так как написанному регулярному 
выражению (начало строки, "192", любой символ, "168", любой 
символ, любое количество символов "0", конец строки) не может 
соответствовать IP-адрес.  Правильно что-нибудь вроде 
"^192\.168\.0".  Ну или можно заменить на geo 
(http://nginx.org/r/geo/ru), но для одной сети непринципиально.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Error log question

[Maxim Dounin]

Hello!

On Tue, Jul 26, 2022 at 07:46:50PM +0500, Илья Шипицин wrote:

> вт, 26 июл. 2022 г. в 19:33, Gena Makhomed :
> 
> > On 26.07.2022 16:59, Maxim Dounin wrote:
> >
> > >>>> >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not
> > allocate
> > >>>> >> new session in SSL session shared cache "le_nginx_SSL" while SSL
> > >>>> >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
> >
> > [...]
> >
> > >> Если не будет в логах ошибок - каким образом тогда пользователь
> > >> сможет понять, что размер кэша для сессий SSL слишком маленький?
> >
> > > Точно так же, как и сейчас - по статистике повторного
> > > использования сессий, других способов нет.  Обсуждаемое сообщение
> > > об ошибке возникает тогда и только тогда, когда не удаётся
> > > выделить память после удаления одной из старых сессий.  Такое
> > > может происходить, например, если удалённая сессия заметно
> > > отличается по размеру от создаваемой, и попадает в другой диапазон
> > > выделений slab-аллокатора.
> >
> > А каким образом эту статистику повторного использования сессий
> > можно получить? Для этого надо писать в лог значение переменной
> > $ssl_session_reused потом скриптом вычислять процент запросов,
> >
> 
> и да, и нет. действительно, сессию можно логировать, но это не значит, что
> сессия была использована.
> сессии это устаревший механизм, сейчас 100% современных браузеров
> используют tls tickets

Когда я последний раз проверял (полгода назад в рамках ticket 
#1892, https://trac.nginx.org/nginx/ticket/1892) - в тикеты не 
умел Safari.

Возможно, имеет смысл таки добраться до ticket #927 
(https://trac.nginx.org/nginx/ticket/927), и сделать, чтобы reuse 
сессий через тикеты можно было легко отличить от такового через 
кэш сессий.  Сейчас использование тикетов от кэша сессий 
отличается по отсутствию $ssl_session_id после первого хендшейка - 
что в принципе позволяет их отличать, но делать это, скажем так, 
неудобно.

[...]

> из того, с чем реально сталкивались - ротация тикетов и сессий. есть два
> пограничных подхода
> 
> а) никогда не делать релоад. (сессии вечные, безопасники несчастны)
> б) иногда делать релоад. сессии ротируются, но по вам со всей дури
> прилетает cpu storm на полных хендшейках
> 
> как-то управляемо ротировать сессии, без привязки к релоаду, было бы
> идеально

Проблема не в "сессии вечные", проблема, о которой любят плакаться 
безопасники - это то, что ключ шифрования тикетов меняется только 
при релоаде.  Соответственно если кто-нибудь сможет получить этот 
ключ - он сможет расшифровать записанный трафик после последнего 
релоада.  Ключ - симметричный ключ на 256-бит, то есть 
единственная реальная возможность его получить - это доступ к 
оперативной памяти работающего сервера.

Если это действительно проблема, то сейчас есть два работающих 
варианта её решения, не приводящих к увеличению числа полных 
хендшейков:

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

- Использовать несколько ключей для шифрования тикетов, заданных 
  через директиву ssl_session_ticket_key, и периодически их 
  вращать (добавлять новый и убирать самый старый).  В этом случае 
  ключи для шифрования тикетов обновляются с любой удобной частотой, 
  а количество полных хендшейков не увеличивается (так как для 
  шифрования новых тикетов используется первый ключ, и старые ключи 
  становятся не нужны после истечения ssl_session_timeout с того 
  момента, как ключ перестал быть первым).

В планах - сделать-таки автоматическое вращение ключей в памяти, 
но пока этого нет.  В частности потому, что модель угроз, в 
которой это важно - выглядит немного оторванной от реальности.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Error log question

[Maxim Dounin]

Hello!

On Tue, Jul 26, 2022 at 02:54:36PM +0300, Gena Makhomed wrote:

> On 26.07.2022 0:34, Maxim Dounin wrote:
> 
> >>   >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not allocate
> >>   >> new session in SSL session shared cache "le_nginx_SSL" while SSL
> >>   >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
> >>   >
> >>   > This error indicate that nginx wasn't able to allocate new session
> >>   > in the SSL session cache defined by the "ssl_session_cache"
> >>   > directive, and removing an old session didn't help.  This
> >>   > basically indicate that the SSL session cache is too small, and it
> >>   > would be a good idea to either configure a larger cache or reduce
> >>   > ssl_session_timeout.  The logging level is probably a bit too
> >>   > scary, see https://trac.nginx.org/nginx/ticket/621 for details.
> >>
> >> Максим, Вы говорите, что "The message is probably a bit too scary
> >> (while the situation itself is mostly harmless)".
> >>
> >> Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет.
> >>
> >> Разве не проще один раз пофиксить эту проблему в исходниках nginx,
> >> чем постоянно рассказывать пользователям в списках рассылки о том,
> >> что "The logging level is probably a bit too scary"?
> >>
> >> Если просто поменять [alert] на [warn] - ничего ведь не сломается?
> >> Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно.
> > 
> > По конкретному тикету есть несколько моментов:
> > 
> > - Перед тем, как менять уровень логгирования - надо как минимум
> >проверить, что в случае невозможности выделения памяти для сессии
> >действительно ничего не ломается.
> > 
> > - А ещё неплохо бы сесть и внимательно посмотреть, не имеет ли
> >смысла изменить логику удаления старых сессий в случае нехватки
> >памяти, чтобы ошибок не возникало.  Или даже переделать логику
> >выделения памяти под сессии, дабы минимизировать вероятность
> >неуспеха.  Или прикрутить логику, аналогичную реализованной для
> >памяти под элементы кэша (http://hg.nginx.org/nginx/rev/c9d680b00744).
> 
> Если не будет в логах ошибок - каким образом тогда пользователь
> сможет понять, что размер кэша для сессий SSL слишком маленький?

Точно так же, как и сейчас - по статистике повторного 
использования сессий, других способов нет.  Обсуждаемое сообщение 
об ошибке возникает тогда и только тогда, когда не удаётся 
выделить память после удаления одной из старых сессий.  Такое 
может происходить, например, если удалённая сессия заметно 
отличается по размеру от создаваемой, и попадает в другой диапазон 
выделений slab-аллокатора.

[...]

> Этот список рассылки, nginx-ru наверное не очень подходит
> для обсуждения NGINX Amplify Agent и NGINX Amplify?

Совершенно не подходит.  Впрочем, не уверен, что подходящее место 
вообще существует.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Error log question

[Maxim Dounin]

Hello!

On Mon, Jul 25, 2022 at 11:05:56AM +0300, Gena Makhomed wrote:

> On 24.07.2022 1:15, Maxim Dounin wrote:
> 
>  >> My nginx error log is being filled with errors which I believe are being
>  >> surfaced from OpenSSL. The log entries number in the hundreds of
>  >> thousands per day and I understand they are most likely due to
>  >> conditions beyond my control. Examples of the log entries are:
> 
> [...]
> 
>  >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not allocate
>  >> new session in SSL session shared cache "le_nginx_SSL" while SSL
>  >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
>  >
>  > This error indicate that nginx wasn't able to allocate new session
>  > in the SSL session cache defined by the "ssl_session_cache"
>  > directive, and removing an old session didn't help.  This
>  > basically indicate that the SSL session cache is too small, and it
>  > would be a good idea to either configure a larger cache or reduce
>  > ssl_session_timeout.  The logging level is probably a bit too
>  > scary, see https://trac.nginx.org/nginx/ticket/621 for details.
> 
> Максим, Вы говорите, что "The message is probably a bit too scary
> (while the situation itself is mostly harmless)".
> 
> Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет.
> 
> Разве не проще один раз пофиксить эту проблему в исходниках nginx,
> чем постоянно рассказывать пользователям в списках рассылки о том,
> что "The logging level is probably a bit too scary"?
> 
> Если просто поменять [alert] на [warn] - ничего ведь не сломается?
> Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно.

По конкретному тикету есть несколько моментов:

- Перед тем, как менять уровень логгирования - надо как минимум 
  проверить, что в случае невозможности выделения памяти для сессии 
  действительно ничего не ломается.

- А ещё неплохо бы сесть и внимательно посмотреть, не имеет ли 
  смысла изменить логику удаления старых сессий в случае нехватки 
  памяти, чтобы ошибок не возникало.  Или даже переделать логику 
  выделения памяти под сессии, дабы минимизировать вероятность 
  неуспеха.  Или прикрутить логику, аналогичную реализованной для 
  памяти под элементы кэша (http://hg.nginx.org/nginx/rev/c9d680b00744).

Всё это требует времени, которое конечно.

Кроме того, "постоянно рассказывать" - на моей памяти примерно 
первый раз за прошедшие с момента появления этого тикета 8 лет.  
То есть проблемы, фактически, нет.

> Сейчас в nginx trac открыто 263 тикета
> https://trac.nginx.org/nginx/report/1
> разве не было бы логично уменьшить их количество
> до минимально возможного числа, в идеале - до нуля?

Было бы логично, конечно.  Лично я регулярно занимаюсь тем, что 
уменьшаю количество открытых тикетов.  Открытых тикетов про 
проблемы в коде сейчас - 70 штук, большую часть просто так не 
закрыть.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Поменять дефолтную $scheme с http на https

[Maxim Dounin]

Hello!

On Sat, Jul 23, 2022 at 10:36:14AM +0300, Slawa Olhovchenkov wrote:

> On Sat, Jul 23, 2022 at 04:11:01AM +0400, Sergey Kandaurov wrote:
> 
> > On Fri, Jul 22, 2022 at 06:57:53PM +0300, Slawa Olhovchenkov wrote:
> > > On Fri, Jul 22, 2022 at 08:47:12PM +0500, Илья Шипицин wrote:
> > > 
> > > > а что показывает в хедере Location, если сделать "return 301 /path" ?
> > > > там абсолютный адрес со схемой или относительный ?
> > > 
> > > абсолютный со схемой
> > 
> > Используйте директиву absolute_redirect для относительных редиректов.
> 
> я же прямо пишу в конфиге директива return 301 /path
> и менять эти (и другие аналогичные места) я не хочу.

А не надо ничего менять.  Использование "absolute_redirect off;" в 
конфиге - выключает преобразование относительных перенаправлений в 
абсолютные, и "return 301 /path;" будет возвращать "Location: /path", 
без каких-либо попыток добавить схему и имя сайта.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: OCSP Must Staple

[Maxim Dounin]

Hello!

On Thu, Jul 21, 2022 at 04:12:37PM +0500, Илья Шипицин wrote:

> чт, 21 июл. 2022 г. в 16:04, Gena Makhomed :
> 
> > On 21.07.2022 13:42, Илья Шипицин wrote:
> >
> > > как-то в подобной ситуации включать MUST Staple - ну такое. страшновато.
> >
> > Это подробно обсуждалось в 2018 году в этом списке рассылки:
> >
> >
> > https://mailman.nginx.org/pipermail/nginx-ru/2018-September/thread.html#61447
> >
> > Наиболее интересные сообщения из этого треда:
> >
> > https://mailman.nginx.org/pipermail/nginx-ru/2018-September/061496.html
> >
> > https://mailman.nginx.org/pipermail/nginx-ru/2018-September/061506.html
> >
> > https://mailman.nginx.org/pipermail/nginx-ru/2018-September/061509.html
> >
> > Если кратко, то суть в том, что OCSP Must Staple включать не нужно.
> >
> 
>  что в зависимости от экспрессивности может быть кем-то сформулировано
> как "OCSP поломан в nginx"
> технология неоднозначная, соглашусь

Безотносительно неоднозначности технологии, повторю ещё раз то, 
что написал:

"что явно показывает непонимание разницы между OCSP Stapling и
требованиями OCSP Must Staple"

OCSP Stapling - это технология, которую nginx поддерживает и 
использование которой можно включить с помощью директивы 
ssl_stapling.  OCSP Must Staple - это _другая_ технология, которая 
основывается на OCSP Stapling'е и предполагает дополнительные 
требования к его работе.  Реализация OCSP Stapling в nginx'е 
далека от тех требований, которые предполагает OCSP Must Staple, и 
поддержку OCSP Must Staple никто никогда не заявлял.

Формулировка же "поломан", вне зависимости от экспрессивности, 
предполагает непонимание того, что OCSP Stapling и OCSP Must 
Staple - это разные технологии.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: certbot

[Maxim Dounin]

Hello!

On Wed, Jul 20, 2022 at 07:59:26PM +0300, Dmitry Morozovsky wrote:

> Коллеги, 
> 
> (чуть запоздало)
> 
> On Thu, 7 Jul 2022, Maxim Dounin wrote:
> 
> [snip]
> 
> > И нет, наличие проблемы "авторы считают возможным менять конфиги" 
> > в одном из вариантов использования - не означает, что в других 
> > вариантах использования проблем нет.  Наличие такой проблемы 
> > означает, что авторы не понимают проблему, и что там ещё и где 
> > разложено или будет разложено в будущем - неизвестно.  И лично я 
> > предпочитаю пользоваться тем, что работает, и рекомендовать его 
> > же.
> 
> вот шесть лет назад Пит Уэмм довольно подробно расписал как и что (с тех пор 
> скриптовать стало проще и, что ли, "повторяемее")
> 
> https://blog.crashed.org/letsencrypt-in-freebsd-org/

Я, конечно, дико извиняюсь, но всерьёз воспринимать написанное не 
могу: начиная от утверждений про "servers require a full restart 
to re-load the certificates if the filename is unchanged", что 
применительно к nginx'у совершенно точно неправда, и заканчивая 
утверждениями про "nginx is broken" в части ocsp-must-staple, что 
явно показывает непонимание разницы между OCSP Stapling и 
требованиями OCSP Must Staple.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

[nginx-ru-announce] nginx-1.23.1

[Maxim Dounin]

Изменения в nginx 1.23.1  19.07.2022

*) Добавление: оптимизация использования памяти в конфигурациях с
   SSL-проксированием.

*) Добавление: теперь с помощью параметра "ipv4=off" директивы
   "resolver" можно запретить поиск IPv4-адресов при преобразовании имён
   в адреса.

*) Изменение: уровень логгирования ошибок SSL "bad key share", "bad
   extension", "bad cipher" и "bad ecpoint" понижен с уровня crit до
   info.

*) Исправление: при возврате диапазонов nginx не удалял строку заголовка
   "Content-Range", если она присутствовала в исходном ответе бэкенда.

*) Исправление: проксированный ответ мог быть отправлен не полностью при
   переконфигурации на Linux; ошибка появилась в 1.17.5.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru-announce mailing list -- nginx-ru-announce@nginx.org
To unsubscribe send an email to nginx-ru-announce-le...@nginx.org

nginx-1.23.1

[Maxim Dounin]

Изменения в nginx 1.23.1  19.07.2022

*) Добавление: оптимизация использования памяти в конфигурациях с
   SSL-проксированием.

*) Добавление: теперь с помощью параметра "ipv4=off" директивы
   "resolver" можно запретить поиск IPv4-адресов при преобразовании имён
   в адреса.

*) Изменение: уровень логгирования ошибок SSL "bad key share", "bad
   extension", "bad cipher" и "bad ecpoint" понижен с уровня crit до
   info.

*) Исправление: при возврате диапазонов nginx не удалял строку заголовка
   "Content-Range", если она присутствовала в исходном ответе бэкенда.

*) Исправление: проксированный ответ мог быть отправлен не полностью при
   переконфигурации на Linux; ошибка появилась в 1.17.5.


-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: [warn] a client request body is buffered to a temporary file

[Maxim Dounin]

Hello!

On Tue, Jul 12, 2022 at 08:55:35PM +0300, Gena Makhomed wrote:

> On 12.07.2022 18:40, Maxim Dounin wrote:
> 
> > А что у вас по осям? (c)
> > 
> > В смысле - что в log_format?  Следом за $status обычно идёт
> > $body_bytes_sent, и это размер тела ответа, имеющий приблизительно
> > никакого отношения к размеру тела запроса.
> 
> На том сервере log_format такой:
> 
> log_format frontend '$time_iso8601\t$geoip_country_code\t$remote_addr\t'
>  '$scheme\t$host\t$request_method\t"$request_uri"\t'
>  '$status\t$body_bytes_sent\t"$http_referer"\t'
>  '"$http_user_agent"\t$request_time\t'
>  '$upstream_response_time';
> 
> Очень удобно использовать символ табуляции в качестве разделителя,
> логи тогда без проблем читаются в mc и с помощью grep | less -S

Историческая справка, не имеющая отношения к обсуждаемому вопросу: 
эскейпинг специальных символов в access-логах делался как раз для 
удобного автоматического парсинга tab separated логов.  Hint: 
кавычки вокруг произвольных строковых полей использовать не нужно, 
так как табы экранируются.

[...]

> Вот еще раз все проверил только что:
> 
> # nginx -q -T | grep client_body_buffer_size
>  client_body_buffer_size 16k;
> 
> error.log:
> 
> 2022/07/12 20:23:26 [warn] 2479#2479: *63684 a client request body is 
> buffered to a temporary file /var/cache/nginx/client_temp/000290, 
> client: 111.222.33.44, server: sentry.example.com, request: "POST 
> /api/8/envelope/?sentry_key=xx_version=7 HTTP/2.0", host: 
> "sentry.example.com", referrer: "https://example.com/;
> 
> access.log:
> 
> 2022-07-12T20:23:26+03:00   XX  111.222.33.44   https 
> sentry.example.comPOST 
> "/api/8/envelope/?sentry_key=xx_version=7" 200 41 
>"https://example.com/; "Mozilla/5.0 (Windows NT 10.0; Win64; x64) 
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" 
>0.037   0.002
> 
> Размер контента - всего 41 байт, что гораздо меньше чем 16 килобайт,
> и тем не менее, контент все равно пишется на диск зачем-то.
> Как такое может быть?

Процитирую ещё раз написанное в прошлом письме:

> > В смысле - что в log_format?  Следом за $status обычно идёт
> > $body_bytes_sent, и это размер тела ответа, имеющий приблизительно
> > никакого отношения к размеру тела запроса.

Из приведённой строки лога мы не знаем размер тела запроса, он 
может быть любой.  Видимое значение 41 - это размер ответа, и он 
не имеет к телу запроса примерно никакого отношения.  Судя по 
тому, что тело запроса в буфер не помещается - оно больше 16 
килобайт.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: [warn] a client request body is buffered to a temporary file

[Maxim Dounin]

Hello!

On Tue, Jul 12, 2022 at 02:42:44PM +0300, Gena Makhomed wrote:

> Здравствуйте, All!
> 
> nginx/1.23.0 из официального репозитория nginx.org
> 
> В логах есть такой варнинг:
> 
> 2022/07/12 13:56:37 [warn] 14352#14352: *183 a client request body is 
> buffered to a temporary file /var/cache/nginx/client_temp/11, 
> client: 10.23.154.207, server: sentry.example.com, request: "POST 
> /api/22/envelope/ HTTP/2.0", host: "sentry.example.com"
> 
> Судя по информации из access-лога - размер контента - 41 байт:
> 
> # grep /api/22/envelope/ access.log | grep 13:56:37 | less
> 2022-07-12T13:56:37+03:00   GB  10.23.154.207   https 
> sentry.example.comPOST"/api/22/envelope/" 200 41 
>"-" "sentry.php.laravel/2.9.0"  0.010   0.002
> 
> Если прописать в nginx.conf директиву client_body_buffer_size 32k;
> - тогда варнинг из error.log пропадает, но если вернуть дефолтовое
> значение client_body_buffer_size 16k; - варнинг снова появляется логах.
> 
> Размер контента - всего 41 байт. Как такое может быть?

А что у вас по осям? (c)

В смысле - что в log_format?  Следом за $status обычно идёт 
$body_bytes_sent, и это размер тела ответа, имеющий приблизительно 
никакого отношения к размеру тела запроса.

> client_body_buffer_size - эта переменная задает только статический
> размер буфера, и в nginx сейчас нельзя сделать динамическое выделение
> буфера по необходимости, как это сделано в директиве proxy_buffers ?
> 
> Возможно было бы логичним, для экономии памяти сделать возможность
> задавать client_body_buffer_size по аналогии с proxy_buffers,
> например так:
> 
> client_body_buffer_size 8k;
> client_body_buffers  32 8k;

Возможно так когда-нибудь будет, но пока так нельзя.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking

[Maxim Dounin]

Hello!

On Tue, Jul 12, 2022 at 03:52:16PM +0400, Sergey Kandaurov wrote:

> On Tue, Jul 12, 2022 at 04:23:59AM +0300, Maxim Dounin wrote:
> > Hello!
> > 
> > On Mon, Jul 11, 2022 at 09:06:53PM +0300, Gena Makhomed wrote:
> > 
> > > On 10.07.2022 11:41, Maxim Dounin wrote:
> > > 
> > > >> Как выловить такие ошибки в логе? 
> > > >> я их не вижу, есть ошибки типа warn Но это не то.
> > > 
> > > > Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP
> > > > request to HTTPS port".  Как и другие ошибки в клиентских
> > > > запросах, эти ошибки логгируются на уровне info.
> > > 
> > > nginx/1.23.0 из официального репозитория nginx.org пишет в лог:
> > > 
> > > 2022/07/11 13:14:48 [crit] 67688#67688: *154358 SSL_do_handshake() 
> > > failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad 
> > > key share) while SSL handshaking, client: 192.241.214.22, server: 
> > > 0.0.0.0:443
> > > 
> > > проблема тут https://stackoverflow.com/a/67424645 на стороне клиента,
> > > но в лог информация пишется на уровне [crit] - так и должно быть?
> > 
> > Нет, так не должно быть. Просто это относительно новая ошибка, 
> > добавленная в OpenSSL 1.1.1 / TLSv1.3, и ей пока не прибит 
> > правильный уровень логгирования.  Патч ниже.
> > 
> > Если в логах вылезает что-то ещё - можно и нужно жаловаться.
> > 
> > # HG changeset patch
> > # User Maxim Dounin 
> > # Date 1657587735 -10800
> > #  Tue Jul 12 04:02:15 2022 +0300
> > # Node ID ae4b86fa92e6eb0c1fa13482695218b334f2adc3
> > # Parent  219217ea49a8d648f5cadd046f1b1294ef05693c
> > SSL: logging levels of various errors added in OpenSSL 1.1.1.
> > 
> > Starting with OpenSSL 1.1.1, various additional errors can be reported
> > by OpenSSL in case of client-related issues, most notably during TLSv1.3
> > handshakes.  In particular, SSL_R_BAD_KEY_SHARE ("bad key share"),
> > SSL_R_BAD_EXTENSION ("bad extension"), SSL_R_BAD_CIPHER ("bad cipher"),
> > SSL_R_BAD_ECPOINT ("bad ecpoint").  These are now logged at the "info"
> > level.
> 
> Looks good.
> 
> I managed to repoduce all of the errors except SSL_R_BAD_CIPHER,
> which requires extra effort to implement HRR in order to trigger it.
> Others are easy to trigger.

Pushed to http://mdounin.ru/hg/nginx/.

> If trying to enumerate TLSv1.3-specific client errors, I'd also add these
> I catched with my QUIC tests adjusted to generic TLSv1.3 over TCP:
> 
> boringssl/include/openssl/ssl.h:#define SSL_R_MISSING_KEY_SHARE 258
> boringssl/include/openssl/ssl.h:#define SSL_R_DUPLICATE_KEY_SHARE 264
> - extension is either missing or includes a dublicate group
> 
> OpenSSL has a similar error "no suitable key share" for MISSING_KEY_SHARE.
> I couldn't find an equivalent for DUPLICATE_KEY_SHARE, though.
> 
> boringssl/include/openssl/ssl.h:#define SSL_R_ERROR_PARSING_EXTENSION 149
> boringssl/include/openssl/ssl.h:#define SSL_R_PARSE_TLSEXT 190
> - both enqueued when e.g. receiving QUIC transport params in generic TLSv1.3:
> "SSL: error:1095:SSL 
> routines:OPENSSL_internal:ERROR_PARSING_EXTENSION:extension 57
>   error:10be:SSL routines:OPENSSL_internal:PARSE_TLSEXT) while SSL 
> handshaking"
> 
> PARSE_TLSEXT seems to be a rough replacement for SSL_R_BAD_EXTENSION.

I don't think I see any of these in nginx-related user reports, so 
I would rather postpone these for now.  (Either way, it looks like 
something for a separate patch.)

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking

[Maxim Dounin]

Hello!

On Mon, Jul 11, 2022 at 09:06:53PM +0300, Gena Makhomed wrote:

> On 10.07.2022 11:41, Maxim Dounin wrote:
> 
> >> Как выловить такие ошибки в логе? 
> >> я их не вижу, есть ошибки типа warn Но это не то.
> 
> > Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP
> > request to HTTPS port".  Как и другие ошибки в клиентских
> > запросах, эти ошибки логгируются на уровне info.
> 
> nginx/1.23.0 из официального репозитория nginx.org пишет в лог:
> 
> 2022/07/11 13:14:48 [crit] 67688#67688: *154358 SSL_do_handshake() 
> failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad 
> key share) while SSL handshaking, client: 192.241.214.22, server: 
> 0.0.0.0:443
> 
> проблема тут https://stackoverflow.com/a/67424645 на стороне клиента,
> но в лог информация пишется на уровне [crit] - так и должно быть?

Нет, так не должно быть. Просто это относительно новая ошибка, 
добавленная в OpenSSL 1.1.1 / TLSv1.3, и ей пока не прибит 
правильный уровень логгирования.  Патч ниже.

Если в логах вылезает что-то ещё - можно и нужно жаловаться.

# HG changeset patch
# User Maxim Dounin 
# Date 1657587735 -10800
#  Tue Jul 12 04:02:15 2022 +0300
# Node ID ae4b86fa92e6eb0c1fa13482695218b334f2adc3
# Parent  219217ea49a8d648f5cadd046f1b1294ef05693c
SSL: logging levels of various errors added in OpenSSL 1.1.1.

Starting with OpenSSL 1.1.1, various additional errors can be reported
by OpenSSL in case of client-related issues, most notably during TLSv1.3
handshakes.  In particular, SSL_R_BAD_KEY_SHARE ("bad key share"),
SSL_R_BAD_EXTENSION ("bad extension"), SSL_R_BAD_CIPHER ("bad cipher"),
SSL_R_BAD_ECPOINT ("bad ecpoint").  These are now logged at the "info"
level.

diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c
--- a/src/event/ngx_event_openssl.c
+++ b/src/event/ngx_event_openssl.c
@@ -3343,6 +3343,12 @@ ngx_ssl_connection_error(ngx_connection_
 #ifdef SSL_R_NO_SUITABLE_KEY_SHARE
 || n == SSL_R_NO_SUITABLE_KEY_SHARE  /*  101 */
 #endif
+#ifdef SSL_R_BAD_KEY_SHARE
+|| n == SSL_R_BAD_KEY_SHARE  /*  108 */
+#endif
+#ifdef SSL_R_BAD_EXTENSION
+|| n == SSL_R_BAD_EXTENSION  /*  110 */
+#endif
 #ifdef SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM
 || n == SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM/*  118 */
 #endif
@@ -3357,6 +3363,9 @@ ngx_ssl_connection_error(ngx_connection_
 || n == SSL_R_NO_CIPHERS_PASSED  /*  182 */
 #endif
 || n == SSL_R_NO_CIPHERS_SPECIFIED   /*  183 */
+#ifdef SSL_R_BAD_CIPHER
+|| n == SSL_R_BAD_CIPHER /*  186 */
+#endif
 || n == SSL_R_NO_COMPRESSION_SPECIFIED   /*  187 */
 || n == SSL_R_NO_SHARED_CIPHER   /*  193 */
 || n == SSL_R_RECORD_LENGTH_MISMATCH /*  213 */
@@ -3391,6 +3400,9 @@ ngx_ssl_connection_error(ngx_connection_
 #ifdef SSL_R_APPLICATION_DATA_ON_SHUTDOWN
 || n == SSL_R_APPLICATION_DATA_ON_SHUTDOWN   /*  291 */
 #endif
+#ifdef SSL_R_BAD_ECPOINT
+|| n == SSL_R_BAD_ECPOINT/*  306 */
+#endif
 #ifdef SSL_R_RENEGOTIATE_EXT_TOO_LONG
 || n == SSL_R_RENEGOTIATE_EXT_TOO_LONG   /*  335 */
 || n == SSL_R_RENEGOTIATION_ENCODING_ERR /*  336 */

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: 400 Bad Request The plain HTTP request was sent to HTTPS port

[Maxim Dounin]

Hello!

On Sat, Jul 09, 2022 at 04:46:23AM -0400, milov wrote:

> Как выловить такие ошибки в логе? я их не вижу, есть ошибки типа warn Но это
> не то.

Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP 
request to HTTPS port".  Как и другие ошибки в клиентских 
запросах, эти ошибки логгируются на уровне info.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org