From nginx на kinetiksoft.com Wed Jun 1 17:12:16 2016 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Wed, 01 Jun 2016 20:12:16 +0300 Subject: =?UTF-8?B?0JXRgdGC0Ywg0LvQuCDRgdC80YvRgdC7INC40YHQv9C+0LvRjNC30L7QstCw0YI=?= =?UTF-8?B?0Ywg0YfRgtC+LdGC0L4g0LrRgNC+0LzQtSBodHRwLzEuMSwg0L/RgNC4INGB?= =?UTF-8?B?0L7QtdC00LjQvdC10L3QuNC4INGBINCx0Y3QutGN0L3QtNC+0Lw/?= Message-ID: <3483762.izEbVjV09Z@cybernote> Здравствуйте! Прочитал целиком тред "proxy http version 2; без SSL, для мультиплексирование запросов к бекенду" и немного запутался в поиске ответа на сабжевый вопрос. Конкретный пример. У нас видеостриминговый сервис, состоящий из эджей, к которым коннектятся клиенты. Эджи проксируют трафик на ориджены, которые занимаются только тем, что в свою очередь проксируются трафик на ориджины нулевого уровня, на которых собственно лежит отдаваемый видео-контент. Везде SSL. Сейчас с SPDY (еще пока используем nginx-1.8.1). Возможно SPDY\http2 лишний и стоит его отключить везде, кроме связки клиент->эдж? С уважением, Иван Прокудин. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на kinetiksoft.com Wed Jun 1 17:50:34 2016 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Wed, 01 Jun 2016 20:50:34 +0300 Subject: =?UTF-8?B?RmlyZWZveCDQv9C+0LLRgtC+0YDQvdC+INC40YHQv9C70L7Qu9GM0LfRg9C10YIg?= =?UTF-8?B?0YHQvtC10LTQuNC90LXQvdC40LUgSVB2NiDQvdCwINC+0YHQvdC+0LLQsNC9?= =?UTF-8?B?0LjQuCBJUHY0LiDQmtCw0Log0YEg0Y3RgtC40Lwg0LbQuNGC0Yw/?= Message-ID: <5511204.WWaG6CCJ7j@cybernote> Здравствуйте! Я прошу прощения за осознанный оффтопик. Но, к сожалению, я вряд ли где еще найду столько людей понимающих как работает SPDY и HTTP/2, чем тут. К тому же проблема косвенно затрагивает конфигурирование nginx и, когда IPv6 станет более массовым с проблемой столкнется, мне кажется, большинство присутствующих. Некоторое время назад я обнаружил и зарепортил следующий баг: https://bugzilla.mozilla.org/show_bug.cgi?id=1190136 Выглядело это как будто, обращаясь к одному виртуалхосту, я получаю контент другого. Конкретно понимание проблемы пришло тут https://bugzilla.mozilla.org/show_bug.cgi?id=1190136#c22 . Как вопроизвести, описано тут https://bugzilla.mozilla.org/show_bug.cgi?id=1190136#c19 Если кратко, то при использовании SPDY\HTTP/2 (для краткости SPDY) Firefox, начиная с вот этого коммита (https://hg.mozilla.org/mozilla-central/rev/5d7317e09ea1) принимает решение о повторном использовании соединения с виртуалхостом по протоколу IPv6 на основании совпадения адреса в A-записи при условии использования обоими wildcard-сертификата валидного для обоих виртуалхостов. То есть У нас есть домен example.com и сертификат *.example.com. На сервере и на клиентах должен быть функционирующий IPv6 (я на клиентах использую туннельного брокера). 1) Заводим два субдомена (например aaa.example.com и bbb.example.com), указывающих на одинаковый ipv4 адрес (A-запись) и разные ipv6 адреса (AAAA- запись) 2) В заводим два виртуальных хоста, можно на одном сервере, можно на разных. Главное, чтоб у них использовались субдомены из п.1, сертификат *.example.com, и IPv6 адреса соотвествовали AAAA-записям из п.1. IPv4 адреса тут не важны. 3) Пытаемся загрузить https://a.example.com. Файрфокс присылает запрос на правильный IPv6 адрес, проставляя правильное поле Host в запросе. 4) Пытаемся загрузиться https://b.example.com, файрфокс будет повторно использовать соединение из п.3, основываясь на том, что оба субдомена имеют одну и ту же A-запись. И пошлет запрос на IPv6 адрес первого домена, передав в заголовке Host адрес второго домена. Разработчик, отвественный за эту часть броузера сказал, что это не баг и чинить он его не будет. Посоветовав использовать разные сертификаты для разных субдоменов (а не wildcard) или пользоваться http-ответом с кодом 451. Однако я с этим в корне не согласен, более того, считаю, что такое поведение открывает уязвимость, которую я описал тут: https://bugzilla.mozilla.org/show_bug.cgi?id=1190136#c22 Но технической квалификации и политического веса в мире броузеров и серверов мне не хватает. Так же мало кто используется ipv6 на клиенте, поэтому массовка еще набралась. Что я хочу, написав, это письмо здесь? 1) Оцените, пожалуйста, насколько я прав. Может быть все не так, как мне кажется? Дальше только, если я прав. 2) Помогите найти аргументы для убеждения разработчиков ФФ, что этот баг надо исправлять. Если кто готов отписаться там, я открою обратно этот баг. 3) Может быть как-то можно сконфигурировать nginx, чтобы решить эту проблему, кроме использования раздельных сертификатов для поддоменов? Ибо раздельные сертификаты - не всегда возможно. Спасибо за помощь. С уважением, Иван Прокудин. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Jun 1 17:59:28 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 1 Jun 2016 20:59:28 +0300 Subject: =?UTF-8?B?UmU6INCV0YHRgtGMINC70Lgg0YHQvNGL0YHQuyDQuNGB0L/QvtC70YzQt9C+0LI=?= =?UTF-8?B?0LDRgtGMINGH0YLQvi3RgtC+INC60YDQvtC80LUgaHR0cC8xLjEsINC/0YA=?= =?UTF-8?B?0Lgg0YHQvtC10LTQuNC90LXQvdC40Lgg0YEg0LHRjdC60Y3QvdC00L7QvD8=?= In-Reply-To: <3483762.izEbVjV09Z@cybernote> References: <3483762.izEbVjV09Z@cybernote> Message-ID: <20160601175927.GF36620@mdounin.ru> Hello! On Wed, Jun 01, 2016 at 08:12:16PM +0300, Иван wrote: > Здравствуйте! > > Прочитал целиком тред "proxy http version 2; без SSL, для мультиплексирование > запросов к бекенду" и немного запутался в поиске ответа на сабжевый вопрос. > > Конкретный пример. У нас видеостриминговый сервис, состоящий из эджей, к > которым коннектятся клиенты. Эджи проксируют трафик на ориджены, которые > занимаются только тем, что в свою очередь проксируются трафик на ориджины > нулевого уровня, на которых собственно лежит отдаваемый видео-контент. > > Везде SSL. Сейчас с SPDY (еще пока используем nginx-1.8.1). Возможно SPDY\http2 > лишний и стоит его отключить везде, кроме связки клиент->эдж? Совершенно верно, SPDY / http2 тут не нужен. Но отключать его не обязательно - он и так не используется, к бекендам nginx всегда ходит по HTTP/1.0 или HTTP/1.1. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Wed Jun 1 19:15:24 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 1 Jun 2016 22:15:24 +0300 Subject: =?UTF-8?B?UmU6IEZpcmVmb3gg0L/QvtCy0YLQvtGA0L3QviDQuNGB0L/Qu9C+0LvRjNC30YM=?= =?UTF-8?B?0LXRgiDRgdC+0LXQtNC40L3QtdC90LjQtSBJUHY2INC90LAg0L7RgdC90L4=?= =?UTF-8?B?0LLQsNC90LjQuCBJUHY0LiDQmtCw0Log0YEg0Y3RgtC40Lwg0LbQuNGC0Yw/?= In-Reply-To: <5511204.WWaG6CCJ7j@cybernote> References: <5511204.WWaG6CCJ7j@cybernote> Message-ID: <20160601191524.GG36620@mdounin.ru> Hello! On Wed, Jun 01, 2016 at 08:50:34PM +0300, Иван wrote: > Здравствуйте! > > Я прошу прощения за осознанный оффтопик. Но, к сожалению, я вряд ли где еще > найду столько людей понимающих как работает SPDY и HTTP/2, чем тут. К тому же > проблема косвенно затрагивает конфигурирование nginx и, когда IPv6 станет более > массовым с проблемой столкнется, мне кажется, большинство присутствующих. > > Некоторое время назад я обнаружил и зарепортил следующий баг: > https://bugzilla.mozilla.org/show_bug.cgi?id=1190136 > > Выглядело это как будто, обращаясь к одному виртуалхосту, я получаю контент > другого. > > Конкретно понимание проблемы пришло тут > https://bugzilla.mozilla.org/show_bug.cgi?id=1190136#c22 . > > Как вопроизвести, описано тут > https://bugzilla.mozilla.org/show_bug.cgi?id=1190136#c19 Т.е. проблема в том, что Firefox пытается делать connection reuse для всех IP-адресов двух хостов, если у этих хостов хотя бы один общий IP-адреса? Это выглядит как нарушение стандарта. RFC 7540 говорит нам, что reuse возможен только в том случае, если хост резолвится в тот же IP-адрес, к которому установлено существующее соединение (https://tools.ietf.org/html/rfc7540#section-9.1.1): A connection can be reused as long as the origin server is authoritative (Section 10.1). For TCP connections without TLS, this depends on the host having resolved to the same IP address. В вашем же случае случае хост не резолвится в тот IP-адрес, к которому установлено соединение. Соответственно, reuse такого соединения - недопустим. [...] > Разработчик, отвественный за эту часть броузера сказал, что это не баг и чинить он > его не будет. Посоветовав использовать разные сертификаты для разных > субдоменов (а не wildcard) или пользоваться http-ответом с кодом 451. Вероятно, имелся в виду код 421. Но получилось особенно смешно. > Однако я с этим в корне не согласен, более того, считаю, что такое поведение > открывает уязвимость, которую я описал тут: > https://bugzilla.mozilla.org/show_bug.cgi?id=1190136#c22 > Но технической квалификации и политического веса в мире броузеров и серверов > мне не хватает. Так же мало кто используется ipv6 на клиенте, поэтому массовка еще > набралась. Уязвимости тут как таковой нет: без SSL/TLS Firefox не умеет HTTP/2, а для connection reuse в случае TLS нужно ещё, чтобы был представлен корректный сертификат, покрывающий оба доменных имени. > Что я хочу, написав, это письмо здесь? > 1) Оцените, пожалуйста, насколько я прав. Может быть все не так, как мне кажется? > Дальше только, если я прав. Мы тут вообще считаем, что connection reuse - это очень плохая фича. В SPDY её в своё время совсем выпилили, т.к. жить с этим - невозможно. Но, видимо, у кого-то в Гугле что-то чешется и покоя не даёт, так что в HTTP/2 её засунули обратно, к сожалению. Самое простое решение - не использовать HTTP/2. В данном конкретном случае - это явно баг Firefox'а, т.к. в соответствии со спецификацией HTTP/2 он не имеет права для запросов к хосту повтороно использовать соединение к IP-адресу, в который данный хост не резолвится. > 2) Помогите найти аргументы для убеждения разработчиков ФФ, что этот баг надо > исправлять. Если кто готов отписаться там, я открою обратно этот баг. См. аргументы выше. На лицо явное нарушение стандарта. > 3) Может быть как-то можно сконфигурировать nginx, чтобы решить эту проблему, > кроме использования раздельных сертификатов для поддоменов? Ибо раздельные > сертификаты - не всегда возможно. Если я правильно понимаю конфигурацию, она какая-то такая: server { listen 192.0.2.1:443 ssl http2; listen [2001:db8::1]:443 ssl http2; server_name one.example.com; } server { listen 192.0.2.1:443 ssl http2; listen [2001:db8::2]:443 ssl http2; server_name two.example.com; } и соответственно для IPv4 используются виртуальные сервера, а для IPv6 - адреса различаются, и соответственно каждый сервер является сервером по умолчанию для своего IPv6-адреса. Совсем тривиальное решение: настроить nginx так, чтобы все сервера были виртуальными и выбирались по имени. Проще всего - на wildcard-адресах, т.е. как-то так: server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name one.example.com; } server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name two.example.com; } Если физически машины, отвечающие за разные IPv6-адреса, разные, или по каким-то ещё причинам уравнивать адреса не хочется, то то можно возвращать 421 Misdirected Request, если пытаются запросить неизвестное имя, как-то так: server { listen [2001:db8::1]:443 ssl http2 default_server; listen [2001:db8::2]:443 ssl http2 default_server; return 421; } Для Firefox'а этого должно быть достаточно, чтобы переоткрыть соединение. Нюанс: в результате теряется возможность обрабатывать на этих адресах запросы без имени, т.е. от совсем старых клиентов, которые ещё HTTP/1.0 или ранее и к тому же не умеют заголовок Host. Их, впрочем, почти не осталось, из доживших до наших времён я такой, пожалуй, могу назвать только один: openssl ocsp. Впрочем, для IPv4-адресов такие запросы всё равно в рассматриваемой конфигурации работать не будут. -- Maxim Dounin http://nginx.org/ From nginx на kinetiksoft.com Wed Jun 1 20:10:36 2016 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Wed, 01 Jun 2016 23:10:36 +0300 Subject: =?UTF-8?B?UmU6IEZpcmVmb3gg0L/QvtCy0YLQvtGA0L3QviDQuNGB0L/Qu9C+0LvRjNC30YM=?= =?UTF-8?B?0LXRgiDRgdC+0LXQtNC40L3QtdC90LjQtSBJUHY2INC90LAg0L7RgdC90L4=?= =?UTF-8?B?0LLQsNC90LjQuCBJUHY0LiDQmtCw0Log0YEg0Y3RgtC40Lwg0LbQuNGC0Yw/?= In-Reply-To: <20160601191524.GG36620@mdounin.ru> References: <5511204.WWaG6CCJ7j@cybernote> <20160601191524.GG36620@mdounin.ru> Message-ID: <2800703.PeX2ve6YMN@cybernote> Здравствуйте! В письме от 1 июня 2016 22:15:24 пользователь Maxim Dounin написал: > > Т.е. проблема в том, что Firefox пытается делать connection reuse > для всех IP-адресов двух хостов, если у этих хостов хотя бы один > общий IP-адреса? > Да. Если у хостов общий IPv4, то FF делает reuse и для IPv6, который в свою очередь может различаться. Как по моему это против всякой логики, но вот некоторые трактуют RFC именно так (см. ниже). > Это выглядит как нарушение стандарта. RFC 7540 говорит нам, что > reuse возможен только в том случае, если хост резолвится в тот же > IP-адрес, к которому установлено существующее соединение > (https://tools.ietf.org/html/rfc7540#section-9.1.1): > > A connection can be reused as long as the origin server > is authoritative (Section 10.1). For TCP connections without TLS, > this depends on the host having resolved to the same IP address. > Ну насколько я понял логику Patrick McManus (разработчика, который не хочет это править), он понимает этот абзац как "если хост резолвится в одинаковый IP адрес (в одной из версий IP), то можно делать reuse (во всех остальных версиях)". > > > Однако я с этим в корне не согласен, более того, считаю, что такое > > поведение открывает уязвимость, которую я описал тут: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1190136#c22 > > Но технической квалификации и политического веса в мире броузеров и > > серверов мне не хватает. Так же мало кто используется ipv6 на клиенте, > > поэтому массовка еще набралась. > > Уязвимости тут как таковой нет: без SSL/TLS Firefox не умеет > HTTP/2, а для connection reuse в случае TLS нужно ещё, чтобы был > представлен корректный сертификат, покрывающий оба доменных имени. Ну значит уязвимость теоретическая. Если по какой-то причине будет возможен HTTP/2 без SSL/TLS, то можно будет использовать эту уязвимость. > В данном конкретном случае - это явно баг Firefox'а, т.к. в > соответствии со спецификацией HTTP/2 он не имеет права для > запросов к хосту повтороно использовать соединение к IP-адресу, в > который данный хост не резолвится. > > > 2) Помогите найти аргументы для убеждения разработчиков ФФ, что этот баг > > надо исправлять. Если кто готов отписаться там, я открою обратно этот > > баг. > См. аргументы выше. На лицо явное нарушение стандарта. > Если б всё было так просто, поверьте, я бы не отнимал Ваше время. > server { > listen [2001:db8::1]:443 ssl http2 default_server; > listen [2001:db8::2]:443 ssl http2 default_server; > return 421; > } > > Для Firefox'а этого должно быть достаточно, чтобы переоткрыть > соединение. > Спасибо. Это похоже то, что нужно. Нужно ли для этого обновляться до 1.11.0 или Change: the "421 Misdirected Request" response now used when rejecting requests to a virtual server different from one negotiated during an SSL handshake; this improves interoperability with some HTTP/2 clients when using client certificates. не про это? С уважением, Иван Прокудин. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Jun 1 21:25:25 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 2 Jun 2016 00:25:25 +0300 Subject: =?UTF-8?B?UmU6IEZpcmVmb3gg0L/QvtCy0YLQvtGA0L3QviDQuNGB0L/Qu9C+0LvRjNC30YM=?= =?UTF-8?B?0LXRgiDRgdC+0LXQtNC40L3QtdC90LjQtSBJUHY2INC90LAg0L7RgdC90L4=?= =?UTF-8?B?0LLQsNC90LjQuCBJUHY0LiDQmtCw0Log0YEg0Y3RgtC40Lwg0LbQuNGC0Yw/?= In-Reply-To: <2800703.PeX2ve6YMN@cybernote> References: <5511204.WWaG6CCJ7j@cybernote> <20160601191524.GG36620@mdounin.ru> <2800703.PeX2ve6YMN@cybernote> Message-ID: <20160601212525.GH36620@mdounin.ru> Hello! On Wed, Jun 01, 2016 at 11:10:36PM +0300, Иван wrote: > В письме от 1 июня 2016 22:15:24 пользователь Maxim Dounin написал: > > > Т.е. проблема в том, что Firefox пытается делать connection reuse > > для всех IP-адресов двух хостов, если у этих хостов хотя бы один > > общий IP-адреса? > > Да. Если у хостов общий IPv4, то FF делает reuse и для IPv6, который в свою > очередь может различаться. Как по моему это против всякой логики, но вот > некоторые трактуют RFC именно так (см. ниже). Отмечу, что стоит редуцировать ту же задачу для двух IPv4 адресов (точнее, трёх: один общий и два уникальных), и дальше обсуждать уже её. Присутствие IPv6, насколько я понимаю, не важно, и только затрудняет понимание проблемы. > > Это выглядит как нарушение стандарта. RFC 7540 говорит нам, что > > reuse возможен только в том случае, если хост резолвится в тот же > > IP-адрес, к которому установлено существующее соединение > > (https://tools.ietf.org/html/rfc7540#section-9.1.1): > > > > A connection can be reused as long as the origin server > > is authoritative (Section 10.1). For TCP connections without TLS, > > this depends on the host having resolved to the same IP address. > > > > Ну насколько я понял логику Patrick McManus (разработчика, который не хочет это > править), он понимает этот абзац как "если хост резолвится в одинаковый IP адрес > (в одной из версий IP), то можно делать reuse (во всех остальных версиях)". Сказано - "a connection". Т.е. host резолвится в тот же IP-адрес, к которому установлено существующее соединение. Понимать это можно как угодно, но любое другое понимание не соответствует тому, что написано. > > > Однако я с этим в корне не согласен, более того, считаю, что такое > > > поведение открывает уязвимость, которую я описал тут: > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1190136#c22 > > > Но технической квалификации и политического веса в мире броузеров и > > > серверов мне не хватает. Так же мало кто используется ipv6 на клиенте, > > > поэтому массовка еще набралась. > > > > Уязвимости тут как таковой нет: без SSL/TLS Firefox не умеет > > HTTP/2, а для connection reuse в случае TLS нужно ещё, чтобы был > > представлен корректный сертификат, покрывающий оба доменных имени. > > Ну значит уязвимость теоретическая. Если по какой-то причине будет возможен > HTTP/2 без SSL/TLS, то можно будет использовать эту уязвимость. Безусловно. И это лишний раз подтверждает, что вышеозначенное "понимание" неверно. [...] > > > 2) Помогите найти аргументы для убеждения разработчиков ФФ, что этот баг > > > надо исправлять. Если кто готов отписаться там, я открою обратно этот > > > баг. > > См. аргументы выше. На лицо явное нарушение стандарта. > > > > Если б всё было так просто, поверьте, я бы не отнимал Ваше время. Зачистую вопрос состоит лишь в том, чтобы ткнуть пальцем в нужное место стандарта, при этом грамотно и кратко сформулировать проблему. > > server { > > listen [2001:db8::1]:443 ssl http2 default_server; > > listen [2001:db8::2]:443 ssl http2 default_server; > > return 421; > > } > > > > Для Firefox'а этого должно быть достаточно, чтобы переоткрыть > > соединение. > > > > Спасибо. Это похоже то, что нужно. Нужно ли для этого обновляться до 1.11.0 или > > Change: the "421 Misdirected Request" response now used when > rejecting requests to a virtual server different from one negotiated > during an SSL handshake; this improves interoperability with some > HTTP/2 clients when using client certificates. > > не про это? Обновляться не обязательно - вернуть руками можно в любой версии. При этом к коду ответа и не будет прилагаться красивого сообщения об ошибке, но это не особо важно, т.к. это ошибка предназначена для автоматической обработки браузером, а не для демонстрации пользователям. Процитированное изменение - оно тоже про борьбу с connection reuse, но в части использования клиентских сертификатов (http://trac.nginx.org/nginx/ticket/848). -- Maxim Dounin http://nginx.org/ From bdmalex на mail.ru Thu Jun 2 03:39:21 2016 From: bdmalex на mail.ru (bdmalex на mail.ru) Date: Thu, 2 Jun 2016 06:39:21 +0300 Subject: =?UTF-8?Q?=E2=9C=88_that=27s_so_exciting?= Message-ID: <00002cdc3011$885d1e5e$1151fb92$@mail.ru> Hello, I've got something exciting for you, you'll definitely love it, take a look Cheers, bdmalex на mail.ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From skobolo на gmail.com Thu Jun 2 15:49:25 2016 From: skobolo на gmail.com (Stepan Karamyshev) Date: Thu, 2 Jun 2016 18:49:25 +0300 Subject: =?UTF-8?B?0KDQsNC30YDQtdGI0LXQvdC90YvQuSDQtNC40LDQv9Cw0LfQvtC9IGh0dHAt0L4=?= =?UTF-8?B?0YLQstC10YLQvtCyICjQuNC70LggItCy0YHQtdCz0LTQsCAyMDAiKQ==?= Message-ID: Добрый день! Понимаю, что вопрос странный, но тем не менее… Есть proxy-pass, который иногда возвращает код ответа >600. Возможно ли передать полученное тело ответа клиенту с http-code=200? PS: При попытке переписать код через error_page nginx вполне валидно ругается на http-code выше 599. From medvedev.yp на gmail.com Thu Jun 2 15:56:38 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Thu, 2 Jun 2016 18:56:38 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9GA0LXRiNC10L3QvdGL0Lkg0LTQuNCw0L/QsNC30L7QvSBodHRw?= =?UTF-8?B?LdC+0YLQstC10YLQvtCyICjQuNC70LggItCy0YHQtdCz0LTQsCAyMDAiKQ==?= In-Reply-To: References: Message-ID: В документации есть пример http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page 2 июня 2016 г. 18:49 пользователь "Stepan Karamyshev" написал: Добрый день! Понимаю, что вопрос странный, но тем не менее… Есть proxy-pass, который иногда возвращает код ответа >600. Возможно ли передать полученное тело ответа клиенту с http-code=200? PS: При попытке переписать код через error_page nginx вполне валидно ругается на http-code выше 599. _______________________________________________ nginx-ru mailing list nginx-ru на nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From skobolo на gmail.com Thu Jun 2 16:08:37 2016 From: skobolo на gmail.com (SK) Date: Thu, 2 Jun 2016 19:08:37 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9GA0LXRiNC10L3QvdGL0Lkg0LTQuNCw0L/QsNC30L7QvSBodHRw?= =?UTF-8?B?LdC+0YLQstC10YLQvtCyICjQuNC70LggItCy0YHQtdCz0LTQsCAyMDAiKQ==?= In-Reply-To: References: Message-ID: error_page 600 -- невалиден по стандарту и не проходит проверку конфига. > 2 июня 2016 г., в 18:56, Yuriy Medvedev написал(а): > > В документации есть пример > http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page > > 2 июня 2016 г. 18:49 пользователь "Stepan Karamyshev" написал: > Добрый день! > Понимаю, что вопрос странный, но тем не менее… > > Есть proxy-pass, который иногда возвращает код ответа >600. > Возможно ли передать полученное тело ответа клиенту с http-code=200? > > PS: При попытке переписать код через error_page nginx вполне валидно ругается на http-code выше 599. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From medvedev.yp на gmail.com Thu Jun 2 16:25:00 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Thu, 2 Jun 2016 19:25:00 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9GA0LXRiNC10L3QvdGL0Lkg0LTQuNCw0L/QsNC30L7QvSBodHRw?= =?UTF-8?B?LdC+0YLQstC10YLQvtCyICjQuNC70LggItCy0YHQtdCz0LTQsCAyMDAiKQ==?= In-Reply-To: References: Message-ID: if ($status = "600") но if зло 2 июня 2016 г. 19:08 пользователь "SK" написал: > error_page 600 -- невалиден по стандарту и не проходит проверку конфига. > > 2 июня 2016 г., в 18:56, Yuriy Medvedev > написал(а): > > В документации есть пример > http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page > 2 июня 2016 г. 18:49 пользователь "Stepan Karamyshev" > написал: > > Добрый день! > Понимаю, что вопрос странный, но тем не менее… > > Есть proxy-pass, который иногда возвращает код ответа >600. > Возможно ли передать полученное тело ответа клиенту с http-code=200? > > PS: При попытке переписать код через error_page nginx вполне валидно > ругается на http-code выше 599. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From skobolo на gmail.com Thu Jun 2 16:33:28 2016 From: skobolo на gmail.com (SK) Date: Thu, 2 Jun 2016 19:33:28 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9GA0LXRiNC10L3QvdGL0Lkg0LTQuNCw0L/QsNC30L7QvSBodHRw?= =?UTF-8?B?LdC+0YLQstC10YLQvtCyICjQuNC70LggItCy0YHQtdCz0LTQsCAyMDAiKQ==?= In-Reply-To: References: Message-ID: if ок, но что в then? Return прекращает обработку запроса :-( > 2 июня 2016 г., в 19:25, Yuriy Medvedev написал(а): > > if ($status = "600") но if зло > > 2 июня 2016 г. 19:08 пользователь "SK" написал: >> error_page 600 -- невалиден по стандарту и не проходит проверку конфига. >> >>> 2 июня 2016 г., в 18:56, Yuriy Medvedev написал(а): >>> >>> В документации есть пример >>> http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page >>> >>> 2 июня 2016 г. 18:49 пользователь "Stepan Karamyshev" написал: >>> Добрый день! >>> Понимаю, что вопрос странный, но тем не менее… >>> >>> Есть proxy-pass, который иногда возвращает код ответа >600. >>> Возможно ли передать полученное тело ответа клиенту с http-code=200? >>> >>> PS: При попытке переписать код через error_page nginx вполне валидно ругается на http-code выше 599. >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на kinetiksoft.com Thu Jun 2 16:55:18 2016 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Thu, 02 Jun 2016 19:55:18 +0300 Subject: =?UTF-8?B?UmU6IEZpcmVmb3gg0L/QvtCy0YLQvtGA0L3QviDQuNGB0L/Qu9C+0LvRjNC30YM=?= =?UTF-8?B?0LXRgiDRgdC+0LXQtNC40L3QtdC90LjQtSBJUHY2INC90LAg0L7RgdC90L4=?= =?UTF-8?B?0LLQsNC90LjQuCBJUHY0LiDQmtCw0Log0YEg0Y3RgtC40Lwg0LbQuNGC0Yw/?= In-Reply-To: <20160601212525.GH36620@mdounin.ru> References: <5511204.WWaG6CCJ7j@cybernote> <2800703.PeX2ve6YMN@cybernote> <20160601212525.GH36620@mdounin.ru> Message-ID: <2062007.oOJF4t3NXu@cybernote> В письме от 2 июня 2016 00:25:25 пользователь Maxim Dounin написал: > > [...] > > > > > 2) Помогите найти аргументы для убеждения разработчиков ФФ, что этот > > > > баг > > > > надо исправлять. Если кто готов отписаться там, я открою обратно этот > > > > баг. > > > > > > См. аргументы выше. На лицо явное нарушение стандарта. > > > > Если б всё было так просто, поверьте, я бы не отнимал Ваше время. > > Зачистую вопрос состоит лишь в том, чтобы ткнуть пальцем в нужное > место стандарта, при этом грамотно и кратко сформулировать > проблему. > Здравствуйте! Будет ли слишком нагло попросить Вас сформулировать проблему грамотно и кратко? Желательно на английском, ну или я сам переведу. В идеале я буду искренне благодарен любым разумным комментаториям в баге по приведенной ранее ссылке. С уважением, Иван Прокудин. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Jun 2 18:37:52 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 2 Jun 2016 23:37:52 +0500 Subject: =?UTF-8?B?NTAwLdGPINC+0YjQuNCx0LrQsCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LA=?= =?UTF-8?B?0L3QuNC4INC60LXRiNCw?= Message-ID: Добрый день! используем кеш около 4-х лет. сегодня случилась 500-я ошибка с вот такой записью в логе 2016/06/02 14:50:07 [alert] 89233#0: could not allocate node in cache keys zone "static" насколько я вижу по коду, это приводит к 500-му статусу. какая логика была заложена в это поведение ? казалось бы, не получилось сохранить объект в кеше, не беда, отдаем как есть. и, собственно, в чем была наша ошибка конфигурации кеша, почему оно не вытеснило старые элементы? кеш вот такой proxy_cache_path /var/tmp/nginx/cache levels=2 keys_zone=static:5m inactive=210m max_size=500m; proxy_cache_key "$scheme$http_host$request_uri$is_args$args"; nginx-1.9.15 Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Jun 1 19:25:20 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Wed, 01 Jun 2016 15:25:20 -0400 Subject: =?UTF-8?B?UmU6INCV0YHRgtGMINC70Lgg0YHQvNGL0YHQuyDQuNGB0L/QvtC70YzQt9C+0LI=?= =?UTF-8?B?0LDRgtGMINGH0YLQvi3RgtC+INC60YDQvtC80LUgaHR0cC8xLjEsINC/0YA=?= =?UTF-8?B?0Lgg0YHQvtC10LTQuNC90LXQvdC40Lgg0YEg0LHRjdC60Y3QvdC00L7QvD8=?= In-Reply-To: <3483762.izEbVjV09Z@cybernote> References: <3483762.izEbVjV09Z@cybernote> Message-ID: <450f7920ea3cd3b3e72453881f5bc859.NginxMailingListRussian@forum.nginx.org> > Везде SSL. Сейчас с SPDY (еще пока используем nginx-1.8.1). Возможно > SPDY\http2 > лишний и стоит его отключить везде, кроме связки клиент->эдж? Для видеостриминга, лучше использовать много соединений, HTPP/1.1 хорошо подходит и ничего более ненужно. Мультиплексирования, полезно там где между запросом и ответом есть временные простои, которые занимают больше времени чем получение и передача данных по сокету, чтобы сокет не простаивал в пустую, протоколы с мультиплексированием загружают сокет другими запросами, в результате сокет постоянно передает запросы и получает ответы, в произвольном порядке. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267298,267303#msg-267303 From nginx-forum на forum.nginx.org Thu Jun 2 10:43:08 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Thu, 02 Jun 2016 06:43:08 -0400 Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3QuNC80LDQvdC40LUg0LrQsNC6INGA0LDQsdC+0YLQsNC1?= =?UTF-8?B?0YIgZmFpbCB0aW1lb3V0INC90LAg0YHQsNC80L7QvCDQtNC10LvQtQ==?= In-Reply-To: <1748660.c7j2Yax1dJ@vbart-laptop> References: <1748660.c7j2Yax1dJ@vbart-laptop> Message-ID: <83cfb4337d0234fe42bedb298b4dafbb.NginxMailingListRussian@forum.nginx.org> ммм, ничего себе, получается каждый worker ничего не знает о состоянии общих ресурсов. Спасибо. Кстати, разобрался. Оказывается все из-за стороннего hash модуля, для round-robin 1.4.2 и round-robin + hash 1.10 - все работает нормально. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267237,267311#msg-267311 From nginx-forum на forum.nginx.org Fri Jun 3 07:51:00 2016 From: nginx-forum на forum.nginx.org (materkov) Date: Fri, 03 Jun 2016 03:51:00 -0400 Subject: Nginx + X-Accel-Redirect Message-ID: <18a98a90eca741f5724e465f0976953c.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Пытаюсь настроить X-Accel-Redirect. Вот такой конфиг: location /api { proxy_pass http://127.0.0.1:8000; } location @tornado { internal; proxy_set_header X-foo1 $upstream_http_myheader; proxy_set_header X-foo2 $upstream_status; proxy_pass http://127.0.0.1:8888; } Вот такой код в первом апстриме (Django): def app_hyper_report(request): r = api.Response() r['myheader'] = 10 r['X-Accel-Redirect'] = '@tornado' return r То есть здесь идет переадресация через X-Accel-Redirect на второй апстрим. При этом, нужно передать во второй апстрим некоторые параметры. Пытаюсь это сделать через headers. Столкнулся с проблемой: почему-то не работает передача headers через $upstream_http_myheader (в то время как $upstream_status срабатывает нормально). В чем здесь может быть проблема? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267345,267345#msg-267345 From vbart на nginx.com Fri Jun 3 19:12:49 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 03 Jun 2016 22:12:49 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3QuNC80LDQvdC40LUg0LrQsNC6INGA0LDQsdC+0YLQsNC1?= =?UTF-8?B?0YIgZmFpbCB0aW1lb3V0INC90LAg0YHQsNC80L7QvCDQtNC10LvQtQ==?= In-Reply-To: <83cfb4337d0234fe42bedb298b4dafbb.NginxMailingListRussian@forum.nginx.org> References: <1748660.c7j2Yax1dJ@vbart-laptop> <83cfb4337d0234fe42bedb298b4dafbb.NginxMailingListRussian@forum.nginx.org> Message-ID: <69764354.AzI0o6cIxF@vbart-workstation> On Thursday 02 June 2016 06:43:08 Vadim Osipov wrote: > ммм, ничего себе, получается каждый worker ничего не знает о состоянии общих > ресурсов. Спасибо. > Кстати, разобрался. Оказывается все из-за стороннего hash модуля, для > round-robin 1.4.2 и round-robin + hash 1.10 - все работает нормально. > [..] Чтобы их сделать "общими" есть специальная директива: http://nginx.org/r/zone/ru -- Валентин Бартенев From vbart на nginx.com Fri Jun 3 20:46:26 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 03 Jun 2016 23:46:26 +0300 Subject: =?UTF-8?B?UmU6INCV0YHRgtGMINC70Lgg0YHQvNGL0YHQuyDQuNGB0L/QvtC70YzQt9C+0LI=?= =?UTF-8?B?0LDRgtGMINGH0YLQvi3RgtC+INC60YDQvtC80LUgaHR0cC8xLjEsINC/0YA=?= =?UTF-8?B?0Lgg0YHQvtC10LTQuNC90LXQvdC40Lgg0YEg0LHRjdC60Y3QvdC00L7QvD8=?= In-Reply-To: <450f7920ea3cd3b3e72453881f5bc859.NginxMailingListRussian@forum.nginx.org> References: <3483762.izEbVjV09Z@cybernote> <450f7920ea3cd3b3e72453881f5bc859.NginxMailingListRussian@forum.nginx.org> Message-ID: <1683559.YZV2FIVyTq@vbart-laptop> On Wednesday 01 June 2016 15:25:20 S.A.N wrote: > > Везде SSL. Сейчас с SPDY (еще пока используем nginx-1.8.1). Возможно > > SPDY\http2 > > лишний и стоит его отключить везде, кроме связки клиент->эдж? > > Для видеостриминга, лучше использовать много соединений, HTPP/1.1 хорошо > подходит и ничего более ненужно. > > Мультиплексирования, полезно там где между запросом и ответом есть временные > простои, которые занимают больше времени чем получение и передача данных по > сокету, чтобы сокет не простаивал в пустую, протоколы с мультиплексированием > загружают сокет другими запросами, в результате сокет постоянно передает > запросы и получает ответы, в произвольном порядке. > [..] Можете расшифровать выражение "сокет не простаивал в пустую"? Чем грозит сокет, который простаивает впустую? Что по вашему такой сокет потребляет: ресурсы процессора, электричество, солярку, деньги? -- Валентин Бартенев From nginx на mva.name Fri Jun 3 21:49:22 2016 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Sat, 04 Jun 2016 04:49:22 +0700 Subject: =?UTF-8?B?UmU6INCV0YHRgtGMINC70Lgg0YHQvNGL0YHQuyDQuNGB0L/QvtC70YzQt9C+0LI=?= =?UTF-8?B?0LDRgtGMINGH0YLQvi3RgtC+INC60YDQvtC80LUgaHR0cC8xLjEsINC/0YA=?= =?UTF-8?B?0Lgg0YHQvtC10LTQuNC90LXQvdC40Lgg0YEg0LHRjdC60Y3QvdC00L7QvD8=?= In-Reply-To: <1683559.YZV2FIVyTq@vbart-laptop> References: <3483762.izEbVjV09Z@cybernote> <450f7920ea3cd3b3e72453881f5bc859.NginxMailingListRussian@forum.nginx.org> <1683559.YZV2FIVyTq@vbart-laptop> Message-ID: <2562225.8kr2a8oCDZ@note> > Можете расшифровать выражение "сокет не простаивал в пустую"? Чем грозит > сокет, который простаивает впустую? Что по вашему такой сокет потребляет: > ресурсы процессора, электричество, солярку, деньги? Как насчёт единички в пулле worker_connections? ;) -- wbr, mva From mdounin на mdounin.ru Sat Jun 4 12:36:19 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sat, 4 Jun 2016 15:36:19 +0300 Subject: Nginx + X-Accel-Redirect In-Reply-To: <18a98a90eca741f5724e465f0976953c.NginxMailingListRussian@forum.nginx.org> References: <18a98a90eca741f5724e465f0976953c.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160604123619.GR36620@mdounin.ru> Hello! On Fri, Jun 03, 2016 at 03:51:00AM -0400, materkov wrote: > Здравствуйте! > > Пытаюсь настроить X-Accel-Redirect. > Вот такой конфиг: > > location /api { > proxy_pass http://127.0.0.1:8000; > } > > location @tornado { > internal; Just a side note: директива "internal" в именованных location'ах не нужна, иначе как в результате перенаправления в такой location в любом случае не попасть. > proxy_set_header X-foo1 $upstream_http_myheader; > proxy_set_header X-foo2 $upstream_status; > proxy_pass http://127.0.0.1:8888; > } > > Вот такой код в первом апстриме (Django): > > def app_hyper_report(request): > r = api.Response() > r['myheader'] = 10 > r['X-Accel-Redirect'] = '@tornado' > return r > > То есть здесь идет переадресация через X-Accel-Redirect на второй апстрим. > При этом, нужно передать во второй апстрим некоторые параметры. Пытаюсь это > сделать через headers. Столкнулся с проблемой: почему-то не работает > передача headers через $upstream_http_myheader (в то время как > $upstream_status срабатывает нормально). > > В чем здесь может быть проблема? Проблема в том, что в момент выполнения proxy_set_header уже началась работа новым upstream'ом, и значения переменных $upstream_http_* и $upstream_status - пустые. Решается сохранением нужных значений в промежуточные переменные с помощью set, как-то так: location @tornado { set $saved_myheader $upstream_http_myheader; set $saved_status $upstream_status; proxy_set_header X-foo1 $saved_myheader; proxy_set_header X-foo2 $saved_status; proxy_pass http://127.0.0.1:8888; } -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Sat Jun 4 13:51:11 2016 From: nginx-forum на forum.nginx.org (materkov) Date: Sat, 04 Jun 2016 09:51:11 -0400 Subject: Nginx + X-Accel-Redirect In-Reply-To: <20160604123619.GR36620@mdounin.ru> References: <20160604123619.GR36620@mdounin.ru> Message-ID: <2d052c68d05a4749519fe9f766d3729f.NginxMailingListRussian@forum.nginx.org> Спасибо, такой вариант сработал. Максим, хотел бы в догонку задать вопрос не совсем связанный с предыдущим вопросом, но связанный с X-Accel-Redirect. На каком-то из форумов (возможно что здесь же, не помню точно) вы кому-то ответили, что только при переадресации на named location, запрос сохраняется неизменным (POST запрос остается POST запросом вместе с телом). А вот при переадресации на обычную location POST запросы становятся GET. С чем связано такое поведение? А именно, хочу понять, не является ли штука с named location каким-то "хаком", не очень желательным и который может исчезнуть в новых версиях. Вообще, X-Accel-Redirect придумана для раздачи статики. Я использую ее для того чтобы разгрузить основной бекенд от запросов, в которых совершаются длительные HTTP-запросы к внешним ресурсам (длительных - это примерно секунд по 30). Поэтому возникла такая задача. Не является ли вообще такой подход bad design, или все-таки неверный инструмент для решения такой задачи? Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Fri, Jun 03, 2016 at 03:51:00AM -0400, materkov wrote: > > > Здравствуйте! > > > > Пытаюсь настроить X-Accel-Redirect. > > Вот такой конфиг: > > > > location /api { > > proxy_pass http://127.0.0.1:8000; > > } > > > > location @tornado { > > internal; > > Just a side note: директива "internal" в именованных location'ах > не нужна, иначе как в результате перенаправления в такой location > в любом случае не попасть. > > > proxy_set_header X-foo1 $upstream_http_myheader; > > proxy_set_header X-foo2 $upstream_status; > > proxy_pass http://127.0.0.1:8888; > > } > > > > Вот такой код в первом апстриме (Django): > > > > def app_hyper_report(request): > > r = api.Response() > > r['myheader'] = 10 > > r['X-Accel-Redirect'] = '@tornado' > > return r > > > > То есть здесь идет переадресация через X-Accel-Redirect на второй > апстрим. > > При этом, нужно передать во второй апстрим некоторые параметры. > Пытаюсь это > > сделать через headers. Столкнулся с проблемой: почему-то не работает > > передача headers через $upstream_http_myheader (в то время как > > $upstream_status срабатывает нормально). > > > > В чем здесь может быть проблема? > > Проблема в том, что в момент выполнения proxy_set_header уже > началась работа новым upstream'ом, и значения переменных > $upstream_http_* и $upstream_status - пустые. > > Решается сохранением нужных значений в промежуточные переменные с > помощью set, как-то так: > > location @tornado { > set $saved_myheader $upstream_http_myheader; > set $saved_status $upstream_status; > proxy_set_header X-foo1 $saved_myheader; > proxy_set_header X-foo2 $saved_status; > proxy_pass http://127.0.0.1:8888; > } > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267345,267372#msg-267372 From nginx-forum на forum.nginx.org Fri Jun 3 23:26:38 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Fri, 03 Jun 2016 19:26:38 -0400 Subject: =?UTF-8?B?UmU6INCV0YHRgtGMINC70Lgg0YHQvNGL0YHQuyDQuNGB0L/QvtC70YzQt9C+0LI=?= =?UTF-8?B?0LDRgtGMINGH0YLQvi3RgtC+INC60YDQvtC80LUgaHR0cC8xLjEsINC/0YA=?= =?UTF-8?B?0Lgg0YHQvtC10LTQuNC90LXQvdC40Lgg0YEg0LHRjdC60Y3QvdC00L7QvD8=?= In-Reply-To: <1683559.YZV2FIVyTq@vbart-laptop> References: <1683559.YZV2FIVyTq@vbart-laptop> Message-ID: <70a7b128a859052965e2b230c629c8d3.NginxMailingListRussian@forum.nginx.org> > Можете расшифровать выражение "сокет не простаивал в пустую"? Чем > грозит > сокет, который простаивает впустую? Что по вашему такой сокет > потребляет: > ресурсы процессора, электричество, солярку, деньги? Сокет который простаивает в пустую (ждет ответа на запрос) потребляет память приложения, мы используем libev. Один сокет требует, создания одного WatcherObject и одного HandlerMethod, это не много, но они 70% времени ничего не делают, потому что время выполнения запроса в десятки раз превышает время передачи данных по локальному сокету. Это не важно когда запросов не много, но когда частота запросов высокая, открывать новые соединения, на каждый запрос это расточительно и глупо. Зачем открывать новое соединения, если в бекенд приложении уже и так есть 100 busy сокетов, которые ничего не делают, потому что ждут ответа на предыдущий запрос, это по сути blocking mode сокета, но созданный на уровне HTTP/1.х, хотя сокет non-blocking mode. Мультиплексирование убирает понятие socket busy, бекенд приложению будет достаточно иметь в десятки раз меньше открытых сокетов (в десятки раз меньше WatcherObject и HandlerMethod), я уже приводил пример в другой теме, повторю его снова: 1 запрос выполняется за 100ms Если послать 30 последовательных запросов в 1 соединение мы получим 30 ответов за 3000ms Если послать 30 запросов в 30 разных соединениях мы получим 30 ответов за 100ms Если послать 30 асинхронных запросов в 1 соединение мы получим 30 ответов за 100ms В первом варианте, 1 сокет находится в режиме busy 3000ms В втором варианте, 30 сокетов находится в режиме busy 100ms В третьем варианте, 1 сокет находится в режиме busy ~0ms Вопрос какой из трех вариантов более эффективно использует ресурсы? Мультиплексирование - нужно всем бекенд приложениям, у которых есть временное окно между запросом и ответом, чем больше это временное окно, тем больше позитив эффекта от мультиплексирование. Сокеты - это как нефть, её много, но ресурс ограничен Мультиплексирование - это как сланцевая нефть, она дает возможность использовать ту нефть, которая ранее считались не пригодная к использованию. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267298,267369#msg-267369 From nginx-forum на forum.nginx.org Fri Jun 3 22:30:24 2016 From: nginx-forum на forum.nginx.org (Steven3009) Date: Fri, 03 Jun 2016 18:30:24 -0400 Subject: =?UTF-8?B?0JLQsNC70LjQtNCw0YbQuNGPINC60Y3RiNCwINC90LAgTmdpbng=?= Message-ID: <49f356a8150841a89b9b630a4c0618b3.NginxMailingListRussian@forum.nginx.org> Всем привет, Сделал кэширование ресурсов на Nginx. Кэширование есть, а валидации, если к примеру поменялся стиль без нажатия на F5 нет. ЧАСТЬ КОНФИГА server { listen 80; server_name 111.111.111.111 sitename.ru; etag on; if_modified_since exact; location ~* ^.+\.(jpg|jpeg|gif|css|png|js|ico|pdf)$ { root /storage/www; expires 30d; add_header Cache-Control 'public'; } fastcgi_pass unix://var/run/php-fpm/php5-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /storage/www$fastcgi_script_name; fastcgi_pass_header Last-Modified; include fastcgi_params; fastcgi_read_timeout 240s; fastcgi_send_timeout 240s; fastcgi_intercept_errors on; } Проверка http://last-modified.com/ru/if-modified-since.html заголовка показывает Сайт ....css/stylesheet.css отдал время последней модификации, но не отреагировал на If-Modified-Since Посоветуйте, пожалуйста, что делать? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267368,267368#msg-267368 From nginx-forum на forum.nginx.org Sat Jun 4 14:34:53 2016 From: nginx-forum на forum.nginx.org (Steven3009) Date: Sat, 04 Jun 2016 10:34:53 -0400 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: <49f356a8150841a89b9b630a4c0618b3.NginxMailingListRussian@forum.nginx.org> References: <49f356a8150841a89b9b630a4c0618b3.NginxMailingListRussian@forum.nginx.org> Message-ID: <5eaa50fe01aa93d729ea01ab1644f5ff.NginxMailingListRussian@forum.nginx.org> Одну часть проблемы я решил, насчет ответа 304. "expires 7d; if_modified_since before;" Но проблема с тем, что статика не обновляется в браузере при загрузке страниц - остается. Пример: я изменил СSS, залил на сервер. Естественно, у файла другой Last_modified и Etag, но сколько я бы не перемещался по сайте, браузер не хочет обновлять стиль. Стиль или другая статика обновляется лишь по нажатию F5. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267368,267373#msg-267373 From annulen на yandex.ru Sat Jun 4 14:40:42 2016 From: annulen на yandex.ru (Konstantin Tokarev) Date: Sat, 04 Jun 2016 17:40:42 +0300 Subject: =?UTF-8?B?UmU6INCV0YHRgtGMINC70Lgg0YHQvNGL0YHQuyDQuNGB0L/QvtC70YzQt9C+0LI=?= =?UTF-8?B?0LDRgtGMINGH0YLQvi3RgtC+INC60YDQvtC80LUgaHR0cC8xLjEsINC/0YA=?= =?UTF-8?B?0Lgg0YHQvtC10LTQuNC90LXQvdC40Lgg0YEg0LHRjdC60Y3QvdC00L7QvD8=?= In-Reply-To: <70a7b128a859052965e2b230c629c8d3.NginxMailingListRussian@forum.nginx.org> References: <1683559.YZV2FIVyTq@vbart-laptop> <70a7b128a859052965e2b230c629c8d3.NginxMailingListRussian@forum.nginx.org> Message-ID: <2490401465051242@web26o.yandex.ru> 04.06.2016, 17:30, "S.A.N" : >>  Можете расшифровать выражение "сокет не простаивал в пустую"? Чем >>  грозит >>  сокет, который простаивает впустую? Что по вашему такой сокет >>  потребляет: >>  ресурсы процессора, электричество, солярку, деньги? > > Сокет который простаивает в пустую (ждет ответа на запрос) потребляет память > приложения, мы используем libev. > Один сокет требует, создания одного WatcherObject и одного HandlerMethod, Хэндлер должен быть один для всех однотипных операций > это не много, но они 70% времени ничего не делают, потому что время > выполнения запроса в десятки раз превышает время передачи данных по > локальному сокету. > > Это не важно когда запросов не много, но когда частота запросов высокая, > открывать новые соединения, на каждый запрос это расточительно и глупо. > > Зачем открывать новое соединения, если в бекенд приложении уже и так есть > 100 busy сокетов, которые ничего не делают, потому что ждут ответа на > предыдущий запрос, это по сути blocking mode сокета, но созданный на уровне > HTTP/1.х, хотя сокет non-blocking mode. > > Мультиплексирование убирает понятие socket busy, бекенд приложению будет > достаточно иметь в десятки раз меньше открытых сокетов (в десятки раз меньше > WatcherObject и HandlerMethod) ... зато придется выполнять работу, которую более эфеективно делает ядро (разбирать, какому логическому соединению принадлжеат пакеты) Тогда уж лучше на UDP переходить :) >, я уже приводил пример в другой теме, повторю > его снова: > > 1 запрос выполняется за 100ms > > Если послать 30 последовательных запросов в 1 соединение мы получим 30 > ответов за 3000ms > Если послать 30 запросов в 30 разных соединениях мы получим 30 ответов за > 100ms > Если послать 30 асинхронных запросов в 1 соединение мы получим 30 ответов за > 100ms > > В первом варианте, 1 сокет находится в режиме busy 3000ms > В втором варианте, 30 сокетов находится в режиме busy 100ms > В третьем варианте, 1 сокет находится в режиме busy ~0ms > > Вопрос какой из трех вариантов более эффективно использует ресурсы? > > Мультиплексирование - нужно всем бекенд приложениям, у которых есть > временное окно между запросом и ответом, чем больше это временное окно, тем > больше позитив эффекта от мультиплексирование. > > Сокеты - это как нефть, её много, но ресурс ограничен > Мультиплексирование - это как сланцевая нефть, она дает возможность > использовать ту нефть, которая ранее считались не пригодная к использованию. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267298,267369#msg-267369 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From andrey на kopeyko.ru Sat Jun 4 15:12:49 2016 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Sat, 4 Jun 2016 18:12:49 +0300 (MSK) Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: <5eaa50fe01aa93d729ea01ab1644f5ff.NginxMailingListRussian@forum.nginx.org> References: <49f356a8150841a89b9b630a4c0618b3.NginxMailingListRussian@forum.nginx.org> <5eaa50fe01aa93d729ea01ab1644f5ff.NginxMailingListRussian@forum.nginx.org> Message-ID: On Sat, 4 Jun 2016, Steven3009 wrote: Добрый день, Steven! > Но проблема с тем, что статика не обновляется в браузере при загрузке > страниц - остается. > Пример: я изменил СSS, залил на сервер. Естественно, у файла другой > Last_modified и Etag, но сколько я бы не перемещался по сайте, браузер не > хочет обновлять стиль. Чудес не бывает. Выкладывайте новый стиль под новым именем, и обновляйте ссылки на него - и настанет вам счастье. -- Best regards, Andrey Kopeyko From nginx-forum на forum.nginx.org Sat Jun 4 17:01:30 2016 From: nginx-forum на forum.nginx.org (Steven3009) Date: Sat, 04 Jun 2016 13:01:30 -0400 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: References: Message-ID: Я так не думаю. Зачем тогда Etag и Last-Modified? Думаю, я что-то упускаю. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267368,267376#msg-267376 From chipitsine на gmail.com Sat Jun 4 17:16:08 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 4 Jun 2016 22:16:08 +0500 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: References: Message-ID: ETag и Last-Modified - для так называемого "ленивого" кеширования. это ситуация, когда вы не знаете, насколько долго можно кешировать ваши ответы, и не сообщаете браузеру Cache-Control: max-age=NNN в этом случае браузер кеширует ответ, и при повторном запросе браузер валидирует при помощи If-Modified-Since/If-None-Match, можно ли использовать то, что он закешировал количество запросов не уменьшается, уменьшается трафик ответа сервера (за счет того, что у 304 нет тела) но браузеру все равно придется делать запросы, он не сможет начать рендерить страницу, пока не убедится, что закешированные стили можно использовать при более грамотной настройке кеша вы выставляете заголовки ответа Cache-Control: max-age=NNN и браузер не будет валидировать, можно ли использовать то, что в кеше, а будет рендерить страницу сразу же 2016-06-04 22:01 GMT+05:00 Steven3009 : > Я так не думаю. Зачем тогда Etag и Last-Modified? > Думаю, я что-то упускаю. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267368,267376#msg-267376 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sat Jun 4 17:54:41 2016 From: nginx-forum на forum.nginx.org (Steven3009) Date: Sat, 04 Jun 2016 13:54:41 -0400 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: References: Message-ID: Илья Шипицин Wrote: ------------------------------------------------------- > ETag и Last-Modified - для так называемого "ленивого" кеширования. > > это ситуация, когда вы не знаете, насколько долго можно кешировать > ваши > ответы, и не сообщаете браузеру Cache-Control: max-age=NNN > > в этом случае браузер кеширует ответ, и при повторном запросе браузер > валидирует при помощи If-Modified-Since/If-None-Match, можно ли > использовать то, что он закешировал > > количество запросов не уменьшается, уменьшается трафик ответа сервера > (за > счет того, что у 304 нет тела) > > но браузеру все равно придется делать запросы, он не сможет начать > рендерить страницу, пока не убедится, что закешированные стили можно > использовать > > при более грамотной настройке кеша вы выставляете заголовки ответа > Cache-Control: max-age=NNN и браузер не будет валидировать, можно ли > использовать то, что в кеше, а будет рендерить страницу сразу же Гугл рекомендует использовать ETag или Last-Modified как раз для определения, можно ил использовать кэш или нет "Эти заголовки позволяют браузеру эффективно обновлять кешированные ресурсы, отправляя запросы GET каждый раз, когда пользователь явным образом перезагружает страницу. Условные запросы GET не возвращают полный ответ, если ресурс не изменился на сервере, и таким образом обеспечивают меньшую задержку, чем полные запросы. " Вопрос как раз в том, что при загрузке страницы/повторной загрузки страницы - измененные статические элементы не обновляются. Обновление происходит только по F5/обновить. Вы хотите сказать, что я ничего не упускаю и так и должно работать? И если у меня изменится стиль или картинка, то пользователь если не нажмет Ф5 или не почистит кэш, не получит обновлений, пока не закончится срок действия кэша? 2016 год... > 2016-06-04 22:01 GMT+05:00 Steven3009 : > > > Я так не думаю. Зачем тогда Etag и Last-Modified? > > Думаю, я что-то упускаю. > > > > Posted at Nginx Forum: > > https://forum.nginx.org/read.php?21,267368,267376#msg-267376 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267368,267378#msg-267378 From chipitsine на gmail.com Sat Jun 4 18:04:45 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 4 Jun 2016 23:04:45 +0500 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: References: Message-ID: посмотрите в сторону asset management, это способ объединения нескольких однотипных статических ресурсов в общий файл с уникальным именем, который можно кешировать вечно, примеры подобных инструментов https://webpack.github.io/ https://github.com/jetheredge/SquishIt (список можно продолжать и продолжать) 4 июня 2016 г., 22:54 пользователь Steven3009 написал: > Илья Шипицин Wrote: > ------------------------------------------------------- > > ETag и Last-Modified - для так называемого "ленивого" кеширования. > > > > это ситуация, когда вы не знаете, насколько долго можно кешировать > > ваши > > ответы, и не сообщаете браузеру Cache-Control: max-age=NNN > > > > в этом случае браузер кеширует ответ, и при повторном запросе браузер > > валидирует при помощи If-Modified-Since/If-None-Match, можно ли > > использовать то, что он закешировал > > > > количество запросов не уменьшается, уменьшается трафик ответа сервера > > (за > > счет того, что у 304 нет тела) > > > > но браузеру все равно придется делать запросы, он не сможет начать > > рендерить страницу, пока не убедится, что закешированные стили можно > > использовать > > > > при более грамотной настройке кеша вы выставляете заголовки ответа > > Cache-Control: max-age=NNN и браузер не будет валидировать, можно ли > > использовать то, что в кеше, а будет рендерить страницу сразу же > > Гугл рекомендует использовать ETag или Last-Modified как раз для > определения, можно ил использовать кэш или нет > "Эти заголовки позволяют браузеру эффективно обновлять кешированные > ресурсы, > отправляя запросы GET каждый раз, когда пользователь явным образом > перезагружает страницу. Условные запросы GET не возвращают полный ответ, > если ресурс не изменился на сервере, и таким образом обеспечивают меньшую > задержку, чем полные запросы. " > > Вопрос как раз в том, что при загрузке страницы/повторной загрузки страницы > - измененные статические элементы не обновляются. Обновление происходит > только по F5/обновить. > > Вы хотите сказать, что я ничего не упускаю и так и должно работать? И если > у > меня изменится стиль или картинка, то пользователь если не нажмет Ф5 или не > почистит кэш, не получит обновлений, пока не закончится срок действия кэша? > 2016 год... > > > > > 2016-06-04 22:01 GMT+05:00 Steven3009 : > > > > > Я так не думаю. Зачем тогда Etag и Last-Modified? > > > Думаю, я что-то упускаю. > > > > > > Posted at Nginx Forum: > > > https://forum.nginx.org/read.php?21,267368,267376#msg-267376 > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru на nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267368,267378#msg-267378 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From annulen на yandex.ru Sat Jun 4 18:13:26 2016 From: annulen на yandex.ru (Konstantin Tokarev) Date: Sat, 04 Jun 2016 21:13:26 +0300 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: References: Message-ID: <1116151465064006@web25h.yandex.ru> 04.06.2016, 20:55, "Steven3009" : > Илья Шипицин Wrote: > Вы хотите сказать, что я ничего не упускаю и так и должно работать? И если у > меня изменится стиль или картинка, то пользователь если не нажмет Ф5 или не > почистит кэш, не получит обновлений, пока не закончится срок действия кэша? Именно так, в этом и заключается смысл срока действия кэша. Для часто изменямых ресурсов или ресурсов, для которых важна оперативность изменений, он должен быть маленьким или вообще нулевым. -- Regards, Konstantin From nginx-forum на forum.nginx.org Sat Jun 4 20:15:38 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Sat, 04 Jun 2016 16:15:38 -0400 Subject: =?UTF-8?B?UmU6INCV0YHRgtGMINC70Lgg0YHQvNGL0YHQuyDQuNGB0L/QvtC70YzQt9C+0LI=?= =?UTF-8?B?0LDRgtGMINGH0YLQvi3RgtC+INC60YDQvtC80LUgaHR0cC8xLjEsINC/0YA=?= =?UTF-8?B?0Lgg0YHQvtC10LTQuNC90LXQvdC40Lgg0YEg0LHRjdC60Y3QvdC00L7QvD8=?= In-Reply-To: <2490401465051242@web26o.yandex.ru> References: <2490401465051242@web26o.yandex.ru> Message-ID: > Хэндлер должен быть один для всех однотипных операций Да, это детали конкретной реализации, там нужно контекст передать, по этому создается новый интсанст хендлера. Если перечислять все кроме WatcherObject и HandlerMethod, тогда нужно начинать с того что accept socket создает новый fd в процессе, а дальше ещё много аллокаций с сокетом найдется в коде бекенд приложения :) > ... зато придется выполнять работу, которую более эфеективно делает > ядро (разбирать, какому логическому соединению принадлжеат пакеты) Никакой особой работы выполнять не придется, просто в ответе (Response) нужно будет передавать id запроса (Request), это все делается на уровне фрейморка бекенд приложения. Уверен request->id будет меньше потреблять памяти, чем отдельное соединения, которое требует, +1 fd в процессе, +1 WatcherObject, -1 fd лимита OS... > Тогда уж лучше на UDP переходить :) Я только за! Что вы думаете про ещё один експерементал протокол гугла - QUICK? Он на udp, и возможно он лучше подходит для общения Nginx с бекендами... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267298,267382#msg-267382 From bgx на protva.ru Sat Jun 4 21:16:06 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Sun, 5 Jun 2016 00:16:06 +0300 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: References: Message-ID: <20160604211606.GC2573@sie.protva.ru> On Sat, Jun 04, 2016 at 01:54:41PM -0400, Steven3009 wrote: > Вопрос как раз в том, что при загрузке страницы/повторной загрузки страницы > - измененные статические элементы не обновляются. Обновление происходит > только по F5/обновить. > > Вы хотите сказать, что я ничего не упускаю и так и должно работать? И если у > меня изменится стиль или картинка, то пользователь если не нажмет Ф5 или не > почистит кэш, не получит обновлений, пока не закончится срок действия кэша? > 2016 год... Вы какой алгоритм обновления кэша держите у себя в голове? Изложите его. Хотя бы для себя, чтобы понимать о чём спрашиваете. Слова "Ф5" и "обновить" ничего не говорят о том, какой запрос (с какими заголовками и какими значениями) посылает браузер и что отвечает сервер. Поэтому это всё рассуждения о чёрном ящике. -- Eugene Berdnikov From vbart на nginx.com Sat Jun 4 22:54:38 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sun, 05 Jun 2016 01:54:38 +0300 Subject: =?UTF-8?B?UmU6INCV0YHRgtGMINC70Lgg0YHQvNGL0YHQuyDQuNGB0L/QvtC70YzQt9C+0LI=?= =?UTF-8?B?0LDRgtGMINGH0YLQvi3RgtC+INC60YDQvtC80LUgaHR0cC8xLjEsINC/0YA=?= =?UTF-8?B?0Lgg0YHQvtC10LTQuNC90LXQvdC40Lgg0YEg0LHRjdC60Y3QvdC00L7QvD8=?= In-Reply-To: <70a7b128a859052965e2b230c629c8d3.NginxMailingListRussian@forum.nginx.org> References: <1683559.YZV2FIVyTq@vbart-laptop> <70a7b128a859052965e2b230c629c8d3.NginxMailingListRussian@forum.nginx.org> Message-ID: <2036434.R0XMoeFGSr@vbart-laptop> On Friday 03 June 2016 19:26:38 S.A.N wrote: > > Можете расшифровать выражение "сокет не простаивал в пустую"? Чем > > грозит > > сокет, который простаивает впустую? Что по вашему такой сокет > > потребляет: > > ресурсы процессора, электричество, солярку, деньги? > > Сокет который простаивает в пустую (ждет ответа на запрос) потребляет память > приложения, мы используем libev. > Один сокет требует, создания одного WatcherObject и одного HandlerMethod, > это не много, но они 70% времени ничего не делают, потому что время > выполнения запроса в десятки раз превышает время передачи данных по > локальному сокету. Т.е. вся проблем состоит в том, что вы это так неэффективно запрограммировали ваше приложение, а мультиплексирование служит лишь поводом изменить его логику работы на более эффективную? Почему бы просто не изменить её? > > Это не важно когда запросов не много, но когда частота запросов высокая, > открывать новые соединения, на каждый запрос это расточительно и глупо. > Расточительно конкретно в вашем приложении? > Зачем открывать новое соединения, если в бекенд приложении уже и так есть > 100 busy сокетов, которые ничего не делают, потому что ждут ответа на > предыдущий запрос, это по сути blocking mode сокета, но созданный на уровне > HTTP/1.х, хотя сокет non-blocking mode. Ничего не делать и ждать ответа - это несколько разные вещи, не нужно их приравнивать. > > Мультиплексирование убирает понятие socket busy, бекенд приложению будет > достаточно иметь в десятки раз меньше открытых сокетов (в десятки раз меньше > WatcherObject и HandlerMethod), я уже приводил пример в другой теме, повторю > его снова: Почему бы не решить проблему с "WatcherObject и HandlerMethod", а не пытаться выдавать проблему конкретного неудачного подхода за проблему протокола? В использовании нескольких сокетов, по одному на запрос, нет ровным счетом ничего плохого. Вы пытаетесь доказать, что сокеты плохи, описывая, как работает ваше приложение. Но может быть дело не в сокетах, а в том, что ваше приложение использует ресурсы неэффективно? Любое мультиплексирование нескольких соединений внутри другого соединения является усложнением, а усложнение приводит к трате большего числа ресурсов. От того, что вы замените TCP сокеты на виртуальные сокеты внутри одного мультиплексированного соединения, вы просто замените одни идентификаторы на другие. И у вас точно также будут "простаивать" те самые виртуальные идентификаторы и все ресурсы, что с ними связаны, и расходовать память. Каким образом замена одних id на другие id что-то меняет? > > 1 запрос выполняется за 100ms > > Если послать 30 последовательных запросов в 1 соединение мы получим 30 > ответов за 3000ms > Если послать 30 запросов в 30 разных соединениях мы получим 30 ответов за > 100ms > Если послать 30 асинхронных запросов в 1 соединение мы получим 30 ответов за > 100ms > > В первом варианте, 1 сокет находится в режиме busy 3000ms > В втором варианте, 30 сокетов находится в режиме busy 100ms > В третьем варианте, 1 сокет находится в режиме busy ~0ms Интересная математика, т.е. в третьем варианте у вас 30 запросов приложение отработало за 0ms, при том, что по вашему же условию 1 запрос выполняется 100ms? > Вопрос какой из трех вариантов более эффективно использует ресурсы? Вариант номер 1 и 2. Поскольку третий вариант требует более сложного протокола и логики работы, что требует большего числа ресурсов. Вы забываете, что у вас в третьем варианте будет 1 TCP сокет и 30 виртуальных сокетов внутри этого самого мультиплексированного соединения. Протоколу FastCGI, который умеет мультиплекирование, уже много-много лет. Как вы думаете, почему за все это время никто это самое мультиплексирование в нем не использует? Ответ прост - потому что это сложно и неэффективно. С HTTP/2 в upstream та же история, это сложно и неэффективно. > > Мультиплексирование - нужно всем бекенд приложениям, у которых есть > временное окно между запросом и ответом, чем больше это временное окно, тем > больше позитив эффекта от мультиплексирование. > > Сокеты - это как нефть, её много, но ресурс ограничен > Мультиплексирование - это как сланцевая нефть, она дает возможность > использовать ту нефть, которая ранее считались не пригодная к использованию. > Сокеты - это котятки, каждый раз когда рождается новый, ну вы понимаете... -- Валентин Бартенев From nginx-forum на forum.nginx.org Sun Jun 5 01:44:42 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Sat, 04 Jun 2016 21:44:42 -0400 Subject: =?UTF-8?B?UmU6INCV0YHRgtGMINC70Lgg0YHQvNGL0YHQuyDQuNGB0L/QvtC70YzQt9C+0LI=?= =?UTF-8?B?0LDRgtGMINGH0YLQvi3RgtC+INC60YDQvtC80LUgaHR0cC8xLjEsINC/0YA=?= =?UTF-8?B?0Lgg0YHQvtC10LTQuNC90LXQvdC40Lgg0YEg0LHRjdC60Y3QvdC00L7QvD8=?= In-Reply-To: <2036434.R0XMoeFGSr@vbart-laptop> References: <2036434.R0XMoeFGSr@vbart-laptop> Message-ID: <10c1923482baf5aa8632fc59fa6e29a0.NginxMailingListRussian@forum.nginx.org> > > 1 запрос выполняется за 100ms > > > > Если послать 30 последовательных запросов в 1 соединение мы получим > 30 > > ответов за 3000ms > > Если послать 30 запросов в 30 разных соединениях мы получим 30 > ответов за > > 100ms > > Если послать 30 асинхронных запросов в 1 соединение мы получим 30 > ответов за > > 100ms > > > > В первом варианте, 1 сокет находится в режиме busy 3000ms > > В втором варианте, 30 сокетов находится в режиме busy 100ms > > В третьем варианте, 1 сокет находится в режиме busy ~0ms > > Интересная математика, т.е. в третьем варианте у вас 30 запросов > приложение отработало за 0ms, при том, что по вашему же условию 1 > запрос выполняется 100ms? Нет, в третьем варианте, 30 запросов отработают за 100ms, это же указанно чуть выше. Но сокет в третьем варианте, будет занят 0ms, это означает что на протяжении этих 100ms, вы можете продолжать отправлять новые запросы в этот же сокет, не дожидаясь ответов на предыдущие 30 запросов, т.е. сокет всегда готов принимать новые запросы. Это очень упрощает алгоритм отправки новых запросов, вы постоянно говорите про сложности которые создает мультиплексирования, но я вижу, что он дает только плюсы и упрощения алгоритмов. > Вы забываете, что у вас в третьем варианте будет 1 TCP сокет и 30 > виртуальных > сокетов внутри этого самого мультиплексированного соединения. 30 виртуальных сокетов - это 30 объектов Request/Respons в которых есть свой id и указатель на свой сокет. Сейчас без мультиплексирования эти 30 объектов тоже создаются, но без id. Так что ничего особо сложного в коде бекенд приложений делать не придется. Возможно для низкоуровневых бекенд приложений это большие сложности, но для приложений на Go, Python, Node.js, PHP демоны, это не добавит особых сложностей. > Протоколу FastCGI, который умеет мультиплекирование, уже много-много > лет. > Как вы думаете, почему за все это время никто это самое > мультиплексирование > в нем не использует? Ответ прост - потому что это сложно и > неэффективно. Нет, ответ ещё проще, 80% сайтов работает на РНР, который "умирает" после выполнения запроса и в процессе работы весь его I/O с блокировкой. Использовать мультиплексирования в PHP-FPM это так же бессмысленно как использовать антикрыло в грузовиках, по этому его там никто не использует, но это совсем не значит что мультиплексирование не эффективная технология, люди которые создавали FastCGI просто опережали свое время. Я понимаю что мой юзкейс (запросы между бекендами через Nginx) редкость для других пользователей Nginx, но только там я увидел как быстро улетает 1024 fd на простых задачах без особых нагрузок. Жить конечно можно, мы увеличили лимиты fd, создали пулы keep-alive, но есть ощущения что нет смысла тратить столько fd. Реализовать мультиплексирование на бекенде не сложно, но жаль нельзя проверить на тестах, чтобы убедится так ли это или нет. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267298,267387#msg-267387 From nginx-forum на forum.nginx.org Sun Jun 5 05:36:15 2016 From: nginx-forum на forum.nginx.org (windos321) Date: Sun, 05 Jun 2016 01:36:15 -0400 Subject: =?UTF-8?B?cmV1c2Vwb3J0INC4INGC0L7RgNC80L7Qt9Cw?= Message-ID: <671ed31b4cc1c3c29234ad7a6abcf5a9.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Ситуация такая: по специфике моего проекта, у каждого сайта выделенный IP адрес. Если я указываю всем (135) сайтам reuseport - обновление конфигурации nginx service reload и nginx -t длится очень долго, если этой опции нету, вышеприведенные команды выполняются моментально. Вопрос: Для каждого из 135 IP явно указано reuseport. Может есть способ указать reuseport не для каждого ip, а для подсети или всего nginx в целом? Как при использовании reuseport вернуть быстрое обновление конфигурации на лету? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267388,267388#msg-267388 From chipitsine на gmail.com Sun Jun 5 06:51:00 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 5 Jun 2016 11:51:00 +0500 Subject: =?UTF-8?B?0LDQvdCw0LvQuNC3INC60L7QtNCwIG5naW54LTEuMTEuMSDRgdGC0LDRgtC40Yc=?= =?UTF-8?B?0LXRgdC60LjQvCDQsNC90LDQu9C40LfQsNGC0L7RgNC+0LwgY2xhbmc=?= Message-ID: Привет! сделал вот так ./configure scan-build make нашлось несколько потенциальных "Dereference of null pointer" отчет тут http://chipitsine.github.io/nginx-1.11.1-clang/ насколько они могут стать реальными, пока не смотрел. Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Jun 5 09:06:10 2016 From: nginx-forum на forum.nginx.org (Steven3009) Date: Sun, 05 Jun 2016 05:06:10 -0400 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: References: Message-ID: > > примеры подобных инструментов > > https://webpack.github.io/ > https://github.com/jetheredge/SquishIt > > (список можно продолжать и продолжать) > Спасибо, интересно. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267368,267390#msg-267390 From nginx-forum на forum.nginx.org Sun Jun 5 09:17:17 2016 From: nginx-forum на forum.nginx.org (Steven3009) Date: Sun, 05 Jun 2016 05:17:17 -0400 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: <1116151465064006@web25h.yandex.ru> References: <1116151465064006@web25h.yandex.ru> Message-ID: > Именно так, в этом и заключается смысл срока действия кэша. Для часто > изменямых ресурсов > или ресурсов, для которых важна оперативность изменений, он должен > быть маленьким или > вообще нулевым. Это все понятно. Только в случае отсутствия валидации до конца срока действия, пока пользователь на совершит команду GET или почистит кэш, команда expires max кажется совсем не логичной. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267368,267391#msg-267391 From nginx-forum на forum.nginx.org Sun Jun 5 09:23:50 2016 From: nginx-forum на forum.nginx.org (Steven3009) Date: Sun, 05 Jun 2016 05:23:50 -0400 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: <20160604211606.GC2573@sie.protva.ru> References: <20160604211606.GC2573@sie.protva.ru> Message-ID: > Слова "Ф5" и "обновить" ничего не говорят о том, какой запрос (с > какими > заголовками и какими значениями) посылает браузер и что отвечает > сервер. > Поэтому это всё рассуждения о чёрном ящике. Если вы не знаете, что делает кнопка F5 или функция обновить в браузере, то думаю вам не стоит отвечать на мой пост. :) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267368,267392#msg-267392 From exelib на gmail.com Sun Jun 5 10:10:21 2016 From: exelib на gmail.com (Anton Bessonov) Date: Sun, 05 Jun 2016 12:10:21 +0200 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: References: <20160604211606.GC2573@sie.protva.ru> Message-ID: <5753FA8D.9080102@gmail.com> Вы не разбираетесь в том, что пишите. Потому и возникают вопросы, типа что вы делаете и чего вы хотите добиться. Кстати, что делает ф5 вы тоже не знаете, если отвечаете такую ерунду. Используйте webpack, expire max и версионирование ресурсов. Остальное придёт с опытом. On 05.06.2016 11:23, Steven3009 wrote: >> Слова "Ф5" и "обновить" ничего не говорят о том, какой запрос (с >> какими >> заголовками и какими значениями) посылает браузер и что отвечает >> сервер. >> Поэтому это всё рассуждения о чёрном ящике. > Если вы не знаете, что делает кнопка F5 или функция обновить в браузере, то > думаю вам не стоит отвечать на мой пост. :) > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267368,267392#msg-267392 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Certified Prince2:2009 Project Manager Professional Scrum Expert Oracle Certified Expert, Enterprise JavaBeans Developer Oracle Certified Professional, Java SE 6 Programmer Now that's a test of the character of an organization. Of the organizations that are attempting to implement Scrum probably, 30% - 35% will successfully implement it. - Ken Schwaber From nginx-forum на forum.nginx.org Sun Jun 5 13:20:32 2016 From: nginx-forum на forum.nginx.org (Steven3009) Date: Sun, 05 Jun 2016 09:20:32 -0400 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: <5753FA8D.9080102@gmail.com> References: <5753FA8D.9080102@gmail.com> Message-ID: <18d7ae409e291d47fe8eeeaaf93d26c9.NginxMailingListRussian@forum.nginx.org> Anton Bessonov Wrote: ------------------------------------------------------- > Вы не разбираетесь в том, что пишите. Потому и возникают вопросы, типа > > что вы делаете и чего вы хотите добиться. Кстати, что делает ф5 вы > тоже > не знаете, если отвечаете такую ерунду. > Если бы я разбирался в кэшировании, то наверное бы сюда не писал, верно? Плохо, что далеко не все, кто отвечают, сами в нем разбираются... :)))) За совет спасибо, смотрел в этом направлении, но хотелось проще. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267368,267397#msg-267397 From maxim на nginx.com Sun Jun 5 14:29:56 2016 From: maxim на nginx.com (Maxim Konovalov) Date: Sun, 5 Jun 2016 17:29:56 +0300 Subject: =?UTF-8?B?UmU6INCw0L3QsNC70LjQtyDQutC+0LTQsCBuZ2lueC0xLjExLjEg0YHRgtCw0YI=?= =?UTF-8?B?0LjRh9C10YHQutC40Lwg0LDQvdCw0LvQuNC30LDRgtC+0YDQvtC8IGNsYW5n?= In-Reply-To: References: Message-ID: <78ed0ce7-d495-b9f3-9fe8-afb06916a330@nginx.com> On 6/5/16 9:51 AM, Илья Шипицин wrote: > Привет! > > сделал вот так > > ./configure > scan-build make > > > нашлось несколько потенциальных "Dereference of null pointer" > отчет тут http://chipitsine.github.io/nginx-1.11.1-clang/ > > насколько они могут стать реальными, пока не смотрел. > Спасибо. Мы похожий анализ делаем регулярно в автоматическом режиме. + https://scan.coverity.com/projects/nginx?tab=overview -- Maxim Konovalov From pavel2000 на ngs.ru Sun Jun 5 14:35:11 2016 From: pavel2000 на ngs.ru (Pavel V.) Date: Sun, 5 Jun 2016 21:35:11 +0700 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: <18d7ae409e291d47fe8eeeaaf93d26c9.NginxMailingListRussian@forum.nginx.org> References: <5753FA8D.9080102@gmail.com> <18d7ae409e291d47fe8eeeaaf93d26c9.NginxMailingListRussian@forum.nginx.org> Message-ID: <15368079.20160605213511@ngs.ru> Здравствуйте, Steven3009. Вы писали 5 июня 2016 г., 20:20:32: > Если бы я разбирался в кэшировании, то наверное бы сюда не писал, верно? > Плохо, что далеко не все, кто отвечают, сами в нем разбираются... :)))) Извините, но как вы определяете, кто разбрается, а кто нет, если вы сами не разбираетесь? Вам слишком многое _кажется_. -- С уважением, Pavel mailto:pavel2000 на ngs.ru From nginx-forum на forum.nginx.org Sun Jun 5 17:32:22 2016 From: nginx-forum на forum.nginx.org (Steven3009) Date: Sun, 05 Jun 2016 13:32:22 -0400 Subject: =?UTF-8?B?UmU6INCS0LDQu9C40LTQsNGG0LjRjyDQutGN0YjQsCDQvdCwIE5naW54?= In-Reply-To: <15368079.20160605213511@ngs.ru> References: <15368079.20160605213511@ngs.ru> Message-ID: <4eec31a37101bb59c0eee125420bff31.NginxMailingListRussian@forum.nginx.org> > Извините, но как вы определяете, кто разбрается, а кто нет, если вы > сами не > разбираетесь? > Вам слишком многое _кажется_. http://pbs.twimg.com/media/BiEBJFqCQAA3CiW.jpg Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267368,267402#msg-267402 From nginx-forum на forum.nginx.org Sun Jun 5 18:38:36 2016 From: nginx-forum на forum.nginx.org (nitsik) Date: Sun, 05 Jun 2016 14:38:36 -0400 Subject: =?UTF-8?B?0JrQsNC6INC80L3QvtCz0L7Qv9C+0YLQvtGH0L3QviDQvtGC0LTQsNGC0Ywg0YM=?= =?UTF-8?B?0LTQsNC70LXQvdC90YvQuSDRhNCw0LnQuyDRh9C10YDQtdC3IG5naW54Pw==?= Message-ID: <1acbab216541d3afbf5ba280b43b2723.NginxMailingListRussian@forum.nginx.org> Часть конфига nginx: #my download internal redirect location ~* ^/internal_redirect/ { internal; access_log /var/log/internal_redirect.access.log; error_log /var/log/internal_redirect.error.log; resolver 8.8.8.8; proxy_buffering off; proxy_set_header Content-Length ""; proxy_set_header Cookie ""; proxy_hide_header x-amz-request-id; proxy_hide_header x-amz-meta-uid; proxy_hide_header x-amz-id-2; proxy_hide_header x-amz-meta-mode; proxy_hide_header x-amz-meta-mtime; proxy_hide_header x-amz-meta-gid; proxy_hide_header x-amz-version-id; proxy_hide_header accept-ranges; proxy_method GET; proxy_pass_request_body off; proxy_max_temp_file_size 0; set $download_url http://$arg_url; proxy_pass $download_url; } Когда использую в php header("X-Accel-Redirect: /internal_redirect/?url=site.ru/path_to_file.mp3"); закачка работает, но однопоточно, почему так? Причем с этим же конфигом на другом сервере многопоточное скачивание работает. Только на другом серваке ispmanager и debian 7 x64, а на текущем vestacp и debian 8 x64 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267403,267403#msg-267403 From nginx-forum на forum.nginx.org Mon Jun 6 06:32:52 2016 From: nginx-forum на forum.nginx.org (rba) Date: Mon, 06 Jun 2016 02:32:52 -0400 Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIHJlaW5pdCAoQVBJLCDQodC4KQ==?= In-Reply-To: <79c25e522e491eccbbf364c901166bc1.NginxMailingListRussian@forum.nginx.org> References: <79c25e522e491eccbbf364c901166bc1.NginxMailingListRussian@forum.nginx.org> Message-ID: Вообщем, сам спросил сам ответил :) Нужно переписывать через повторный вызов access handler, для чего в его теле... r->phase_handler--; return NGX_OK; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267216,267407#msg-267407 From bgx на protva.ru Mon Jun 6 08:08:30 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Mon, 6 Jun 2016 11:08:30 +0300 Subject: =?UTF-8?B?UmU6IHJldXNlcG9ydCDQuCDRgtC+0YDQvNC+0LfQsA==?= In-Reply-To: <671ed31b4cc1c3c29234ad7a6abcf5a9.NginxMailingListRussian@forum.nginx.org> References: <671ed31b4cc1c3c29234ad7a6abcf5a9.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160606080830.GA30823@protva.ru> On Sun, Jun 05, 2016 at 01:36:15AM -0400, windos321 wrote: > по специфике моего проекта, у каждого сайта выделенный IP адрес. > Если я указываю всем (135) сайтам reuseport - обновление конфигурации nginx > service reload и nginx -t длится очень долго, если этой опции нету, > вышеприведенные команды выполняются моментально. Посмотрите, на каких системных вызовах происходит ожидание. В линуксе, например, можно взять выдачу "strace -T nginx -t". -- Eugene Berdnikov From mdounin на mdounin.ru Mon Jun 6 13:24:39 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 6 Jun 2016 16:24:39 +0300 Subject: Nginx + X-Accel-Redirect In-Reply-To: <2d052c68d05a4749519fe9f766d3729f.NginxMailingListRussian@forum.nginx.org> References: <20160604123619.GR36620@mdounin.ru> <2d052c68d05a4749519fe9f766d3729f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160606132439.GW36620@mdounin.ru> Hello! On Sat, Jun 04, 2016 at 09:51:11AM -0400, materkov wrote: > Максим, хотел бы в догонку задать вопрос не совсем связанный с предыдущим > вопросом, но связанный с X-Accel-Redirect. На каком-то из форумов (возможно > что здесь же, не помню точно) вы кому-то ответили, что только при > переадресации на named location, запрос сохраняется неизменным (POST запрос > остается POST запросом вместе с телом). А вот при переадресации на обычную > location POST запросы становятся GET. С чем связано такое поведение? А > именно, хочу понять, не является ли штука с named location каким-то "хаком", > не очень желательным и который может исчезнуть в новых версиях. Преобразование POST в GET при обычном перенаправлении связано с тем, что обычное пренаправление штатно делается для того, чтобы вернуть пользователю другой ресурс, доступный по другому адресу методом GET. E.g., когда error_page делает перенаправление на страницу /errors/404.html - к ней надо обращаться методом GET, и другие методы тут неуместны. Что касается именованных location'ов, то они в своё время были придуманы как раз для того, чтобы избежать всех преобразований запроса, и передать обработку к другой конфигурации, но без прочих изменений. В частности, без изменений URI и метода запроса. Отвечая на исходный вопрос: нет, такое поведение именованных location'ов - это не хак, так и было задумано. > Вообще, X-Accel-Redirect придумана для раздачи статики. Я использую ее для > того чтобы разгрузить основной бекенд от запросов, в которых совершаются > длительные HTTP-запросы к внешним ресурсам (длительных - это примерно секунд > по 30). Поэтому возникла такая задача. Не является ли вообще такой подход > bad design, или все-таки неверный инструмент для решения такой задачи? Не вижу каких-либо проблем с таким подходом, по крайней мере со стороны nginx'а. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue Jun 7 19:12:57 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 7 Jun 2016 22:12:57 +0300 Subject: =?UTF-8?B?UmU6IDUwMC3RjyDQvtGI0LjQsdC60LAg0L/RgNC4INC40YHQv9C+0LvRjNC30L4=?= =?UTF-8?B?0LLQsNC90LjQuCDQutC10YjQsA==?= In-Reply-To: References: Message-ID: <20160607191257.GE36620@mdounin.ru> Hello! On Thu, Jun 02, 2016 at 11:37:52PM +0500, Илья Шипицин wrote: > Добрый день! > > используем кеш около 4-х лет. > > сегодня случилась 500-я ошибка с вот такой записью в логе > > 2016/06/02 14:50:07 [alert] 89233#0: could not allocate node in cache keys > zone "static" > > насколько я вижу по коду, это приводит к 500-му статусу. > > какая логика была заложена в это поведение ? казалось бы, не получилось > сохранить объект в кеше, не беда, отдаем как есть. "Не получилось" - редкое событие, в большинстве случаев связанное с фатальными проблемами. Разделять фатальные и нефатальеные проблемы, и соответственно по разному их обрабатывать - можно, но пока такой необходимости приминительно к заканчивающемуся в месту в зоне разделяемой памяти - не возникало. > и, собственно, в чем была наша ошибка конфигурации кеша, почему оно не > вытеснило старые элементы? > > кеш вот такой > > proxy_cache_path /var/tmp/nginx/cache levels=2 keys_zone=static:5m > inactive=210m max_size=500m; > proxy_cache_key "$scheme$http_host$request_uri$is_args$args"; Сконфигурированная зона разделяемой памяти - 5 мегабайт, т.е. где-то 40 тысяч элементов. Такой размер зоны будет достаточен, если выполняется одно из следующих условий: - Средний размер элемента в кеше превышает 10 килобайт (т.к. max_size = 500 мегабайт); - В кеш сладывается меньше 3 элементов в секунду (т.к. inactive = 210 минут). В остальных случаях будет зона разделяемой памяти будет переполняться и будет работать механизм экстренного вытеснения старых элементов. После вытеснения - делается попытка выделить память под элемент ещё раз. Нюанс состит в том, что свежеосвобождённую память может сразу же занять другой рабочий процесс. Вероятно, именно это и произошло в описанном случае. В nginx 1.9.13+ cache manager, помимо inactive/max_size, умеет ещё и следить за количеством элементов кеша. Однако эта логика включается только когда переполнение уже случилось, так что полностью от проблем - не избавляет. Лучше всего конфигурить кеш так, чтобы зона не переполнялась и необходимости в экстренном вытеснении старых элементов - не возникало. -- Maxim Dounin http://nginx.org/ From chipitsine на gmail.com Tue Jun 7 19:28:41 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 8 Jun 2016 00:28:41 +0500 Subject: =?UTF-8?B?UmU6IDUwMC3RjyDQvtGI0LjQsdC60LAg0L/RgNC4INC40YHQv9C+0LvRjNC30L4=?= =?UTF-8?B?0LLQsNC90LjQuCDQutC10YjQsA==?= In-Reply-To: <20160607191257.GE36620@mdounin.ru> References: <20160607191257.GE36620@mdounin.ru> Message-ID: я на досуге поизучал это место кода, тоже пришел к мнению, что закончилась область shared memory (диагностика могла бы быть более развернутая в логе). я пока склоняюсь к мнению, что это не должно быть фатальным, ну не смогли положить в кеш, чего горевать то. каких-то серьезных аргументов за то, что в этом случае надо фейлить, пока не придумал. 8 июня 2016 г., 0:12 пользователь Maxim Dounin написал: > Hello! > > On Thu, Jun 02, 2016 at 11:37:52PM +0500, Илья Шипицин wrote: > > > Добрый день! > > > > используем кеш около 4-х лет. > > > > сегодня случилась 500-я ошибка с вот такой записью в логе > > > > 2016/06/02 14:50:07 [alert] 89233#0: could not allocate node in cache > keys > > zone "static" > > > > насколько я вижу по коду, это приводит к 500-му статусу. > > > > какая логика была заложена в это поведение ? казалось бы, не получилось > > сохранить объект в кеше, не беда, отдаем как есть. > > "Не получилось" - редкое событие, в большинстве случаев связанное > с фатальными проблемами. Разделять фатальные и нефатальеные > проблемы, и соответственно по разному их обрабатывать - можно, но > пока такой необходимости приминительно к заканчивающемуся в месту > в зоне разделяемой памяти - не возникало. > > > и, собственно, в чем была наша ошибка конфигурации кеша, почему оно не > > вытеснило старые элементы? > > > > кеш вот такой > > > > proxy_cache_path /var/tmp/nginx/cache levels=2 keys_zone=static:5m > > inactive=210m max_size=500m; > > proxy_cache_key "$scheme$http_host$request_uri$is_args$args"; > > Сконфигурированная зона разделяемой памяти - 5 мегабайт, т.е. > где-то 40 тысяч элементов. Такой размер зоны будет достаточен, > если выполняется одно из следующих условий: > > - Средний размер элемента в кеше превышает 10 килобайт (т.к. > max_size = 500 мегабайт); > > - В кеш сладывается меньше 3 элементов в секунду (т.к. inactive = > 210 минут). > > В остальных случаях будет зона разделяемой памяти будет > переполняться и будет работать механизм экстренного вытеснения > старых элементов. После вытеснения - делается попытка выделить > память под элемент ещё раз. Нюанс состит в том, что > свежеосвобождённую память может сразу же занять другой рабочий > процесс. Вероятно, именно это и произошло в описанном случае. > > В nginx 1.9.13+ cache manager, помимо inactive/max_size, умеет ещё > и следить за количеством элементов кеша. Однако эта логика > включается только когда переполнение уже случилось, так что > полностью от проблем - не избавляет. > > Лучше всего конфигурить кеш так, чтобы зона не переполнялась и > необходимости в экстренном вытеснении старых элементов - не > возникало. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Tue Jun 7 19:38:20 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 7 Jun 2016 22:38:20 +0300 Subject: =?UTF-8?B?UmU6IDUwMC3RjyDQvtGI0LjQsdC60LAg0L/RgNC4INC40YHQv9C+0LvRjNC30L4=?= =?UTF-8?B?0LLQsNC90LjQuCDQutC10YjQsA==?= In-Reply-To: References: <20160607191257.GE36620@mdounin.ru> Message-ID: <20160607193820.GF36620@mdounin.ru> Hello! On Wed, Jun 08, 2016 at 12:28:41AM +0500, Илья Шипицин wrote: > я на досуге поизучал это место кода, тоже пришел к мнению, что закончилась > область shared memory (диагностика могла бы быть более развернутая в логе). Куда уж развёрнутей - даже конкретная зона указана, в которой место кончилось. > я пока склоняюсь к мнению, что это не должно быть фатальным, ну не смогли > положить в кеш, чего горевать то. каких-то серьезных аргументов за то, что > в этом случае надо фейлить, пока не придумал. Аргумент ровно один: делать это нефатальным - сложнее, чем фатальным. И при этом соответствующая ситуация в норме возникать просто не должна. -- Maxim Dounin http://nginx.org/ From chipitsine на gmail.com Tue Jun 7 19:52:14 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 8 Jun 2016 00:52:14 +0500 Subject: =?UTF-8?B?UmU6IDUwMC3RjyDQvtGI0LjQsdC60LAg0L/RgNC4INC40YHQv9C+0LvRjNC30L4=?= =?UTF-8?B?0LLQsNC90LjQuCDQutC10YjQsA==?= In-Reply-To: <20160607193820.GF36620@mdounin.ru> References: <20160607191257.GE36620@mdounin.ru> <20160607193820.GF36620@mdounin.ru> Message-ID: 8 июня 2016 г., 0:38 пользователь Maxim Dounin написал: > Hello! > > On Wed, Jun 08, 2016 at 12:28:41AM +0500, Илья Шипицин wrote: > > > я на досуге поизучал это место кода, тоже пришел к мнению, что > закончилась > > область shared memory (диагностика могла бы быть более развернутая в > логе). > > Куда уж развёрнутей - даже конкретная зона указана, в которой > место кончилось. > все таки не совсем, зона же с вытеснением, т.е. "закончиться" она вроде как не должна. в смысле, понятно, при каких условиях это может произойти, но это не из разряда "куда уж развернутей". > > > я пока склоняюсь к мнению, что это не должно быть фатальным, ну не смогли > > положить в кеш, чего горевать то. каких-то серьезных аргументов за то, > что > > в этом случае надо фейлить, пока не придумал. > > Аргумент ровно один: делать это нефатальным - сложнее, чем > фатальным. И при этом соответствующая ситуация в норме возникать > просто не должна. > посмотрим. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Jun 8 18:57:14 2016 From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?= =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=) Date: Wed, 08 Jun 2016 14:57:14 -0400 Subject: nginx 1.11 + fast-cgi cache + map + ssi Message-ID: <684d5f96d9c207b204bbc7d568c0a3c7.NginxMailingListRussian@forum.nginx.org> Всем добрый вечер. Использую на сайте кеширование fast-cgi запросов отдельных страниц. Страницы, которые нужно кешировать отдают X-accel-expires. Также для некоторых страниц нужен был другой fastcgi_cache_key в зависимости от $request_uri. До версии 1.11 конфиг выглядел примерно так: location ~ \.php$ { set $fastcgi_cache_key $request_method|$host|$uri|$request_uri|$cookie_currency|$cookie_show_mode; if ($request_uri ~ ^/objekti/.+){ set $fastcgi_cache_key $request_method|$host|$uri|$request_uri|$cookie_currency|$http_x_requested_with; } if ($request_uri ~ ^/xml/yml.php){ set $fastcgi_cache_key $request_method|$host|$uri|$arg_type|$arg_nosim; } ......... fastcgi_cache_key $fastcgi_cache_key; ......... fastcgi_pass php-fpm; } И это работает. С версии 1.11 map начал понимать несколько переменных в качестве результата. Т.о. сделал такую секцию: map $request_uri $fastcgi_cache_key { default $request_method|$host|$uri|$request_uri|$cookie_currency|$cookie_show_mode; ~^/objekti/.+ $request_method|$host|$uri|$request_uri|$cookie_currency|$http_x_requested_with; ~^/xml/yml.php $request_method|$host|$uri|$arg_type|$arg_nosim; } Убрал set и if из php-локейшена и получил "subrequests cycle while processing" в логах везде, где использую ssi. Вывел обе переменные - они равны. Заранее благодарен Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267467,267467#msg-267467 From ilya на jermakyan.ru Thu Jun 9 10:00:20 2016 From: ilya на jermakyan.ru (Ilya Jermakyan) Date: Thu, 9 Jun 2016 13:00:20 +0300 Subject: =?UTF-8?B?RndkOiDQvdC1INC/0L7Qu9GD0YfQsNC10YLRgdGPIHJld3JpdGUg0YHRgtGA0L4=?= =?UTF-8?B?0LrQuCDRgSDQv9Cw0YDQsNC80LXRgtGA0LDQvNC4?= In-Reply-To: <85b15c9b-ec6d-0862-348b-a9ec9ff1ba1e@jermakyan.ru> References: <85b15c9b-ec6d-0862-348b-a9ec9ff1ba1e@jermakyan.ru> Message-ID: <991230cb-b8d6-00dd-208b-0869becbb0ea@jermakyan.ru> Добрый день в конфиге nginx (ver 1.8.1) имеется 2 секции location: location / { ... } location /?product_id=1&mobile=0 { ... rewrite ... } Нужно добиться чтобы при входе на сайт https://mysite.ru открывалась главная страница, но если зайти https://mysite.ru/?product_id=1&mobile=0 происходил переход на внешний ресурс. Прочитал вот тут http://nginx.org/ru/docs/http/request_processing.html Что location’ы всех типов сопоставляются только с URI-частью строки запроса без аргументов а мне нужно как раз сопоставить аргументы и сделать rewrite при конкретных аргументах. Реально ли это сделать? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alex.hha на gmail.com Thu Jun 9 10:28:45 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 9 Jun 2016 13:28:45 +0300 Subject: =?UTF-8?B?UmU6INC90LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8gcmV3cml0ZSDRgdGC0YDQvtC6?= =?UTF-8?B?0Lgg0YEg0L/QsNGA0LDQvNC10YLRgNCw0LzQuA==?= In-Reply-To: <991230cb-b8d6-00dd-208b-0869becbb0ea@jermakyan.ru> References: <85b15c9b-ec6d-0862-348b-a9ec9ff1ba1e@jermakyan.ru> <991230cb-b8d6-00dd-208b-0869becbb0ea@jermakyan.ru> Message-ID: "Следует иметь в виду, что location’ы всех типов сопоставляются только с URI-частью строки запроса без аргументов." 2016-06-09 13:00 GMT+03:00 Ilya Jermakyan : > > > > > > > > > Добрый день > > в конфиге nginx (ver 1.8.1) имеется 2 секции location: > > location / { > > ... > > } > > location /?product_id=1&mobile=0 { > > ... > rewrite ... > } > > Нужно добиться чтобы при входе на сайт https://mysite.ru открывалась > главная страница, но если зайти > https://mysite.ru/?product_id=1&mobile=0 происходил переход на внешний > ресурс. > Прочитал вот тут http://nginx.org/ru/docs/http/request_processing.html > Что location’ы всех типов сопоставляются только с URI-частью строки > запроса без аргументов > а мне нужно как раз сопоставить аргументы и сделать rewrite при конкретных > аргументах. Реально ли это сделать? > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From rogat1y на gmail.com Thu Jun 9 10:31:08 2016 From: rogat1y на gmail.com (Maxim Kozlov) Date: Thu, 9 Jun 2016 13:31:08 +0300 Subject: =?UTF-8?B?UmU6INC90LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8gcmV3cml0ZSDRgdGC0YDQvtC6?= =?UTF-8?B?0Lgg0YEg0L/QsNGA0LDQvNC10YLRgNCw0LzQuA==?= In-Reply-To: <991230cb-b8d6-00dd-208b-0869becbb0ea@jermakyan.ru> References: <85b15c9b-ec6d-0862-348b-a9ec9ff1ba1e@jermakyan.ru> <991230cb-b8d6-00dd-208b-0869becbb0ea@jermakyan.ru> Message-ID: Смотрите в сторону map и переменной переменных $arg_ http://nginx.org/ru/docs/http/ngx_http_core_module.html#var_arg_ ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alex.hha на gmail.com Thu Jun 9 10:40:28 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 9 Jun 2016 13:40:28 +0300 Subject: =?UTF-8?B?ZmFzdGNnaSDQuCDQvdC10YHQutC+0LvRjNC60L4gZG9jdW1lbnQgcm9vdA==?= Message-ID: Привет всем, столкнулся с казалось бы тривиальной задачей, для одного location надо задать root отличный от того, что задан на уровне server server { root /vhosts/example.com/public_html/web/; location ~/api/.*\.php { root /vhosts/dev-designer/public_html/api; add_header X-DEBUG "LOC-API-PHP" always; error_page 406 = @fastcgi; return 406; } location ~/api/ { add_header X-DEBUG "API" always; root /vhosts/example.com/public_html/api; } location ~ \.php$ { error_page 406 = @fastcgi; return 406; } location @fastcgi { add_header X-DEBUG "FAST-CGI" always; fastcgi_pass unix:/run/php/php5.6-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; ... } } но в таком случае, запрос попадает в @fastcgi, но при этом root у него остается дефолтный. При этом если я коментирую *error_page/return* в *~/api/.*\.php*, то я вижу что запрос попадает в этот location и root у него меняется, но почему то с учетом return root остается с уровня server Гугл предлагает такой вариант http://serverfault.com/questions/317641/nginx-multiple-document-roots-with-fastcgi хотелось бы узнать, это единственно верный способ решения данной задачи (использование вложенных локейшенов)? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на mva.name Thu Jun 9 10:55:40 2016 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Thu, 09 Jun 2016 17:55:40 +0700 Subject: =?UTF-8?B?Kl9pbnRlcmNlcHRfZXJyb3JzINGC0L7Qu9GM0LrQviDQtNC70Y8g0L7Qv9GA0LU=?= =?UTF-8?B?0LTQtdC70ZHQvdC90YvRhSDQutC+0LTQvtCy?= Message-ID: <3804417.E5snpS18qY@note> Всем привет! Я тут уже не в первый раз сталкиваюсь что у веб-приложений могут быть свои обработчики, например, 404 (иногда и 403, а иногда даже и 503) ошибки, при этом остальные коды (особенно пятисотые) оно не обрабатывает и отдаются "пустые" дефолтные вместо тех, которые указаны у NgX в error_page. В связи с этим захотелось как-нибудь накостылять возможность указывать на какие коды отдавать страницу ошибки, которую вернул бекенд, а на какие - error_page. У кого-нибудь есть идеи, как нарисовать подобное в конфиге? У меня пока как-то не очень получается :) -- wbr, mva From ilya на jermakyan.ru Thu Jun 9 10:57:54 2016 From: ilya на jermakyan.ru (Ilya Jermakyan) Date: Thu, 9 Jun 2016 13:57:54 +0300 Subject: =?UTF-8?B?UmU6INC90LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8gcmV3cml0ZSDRgdGC0YDQvtC6?= =?UTF-8?B?0Lgg0YEg0L/QsNGA0LDQvNC10YLRgNCw0LzQuA==?= In-Reply-To: References: <85b15c9b-ec6d-0862-348b-a9ec9ff1ba1e@jermakyan.ru> <991230cb-b8d6-00dd-208b-0869becbb0ea@jermakyan.ru> Message-ID: <3a5e0178-eb83-42e4-8f12-1a35c7d2b45a@jermakyan.ru> Сделал в итоге вот так: location / { .... if ($query_string = 'product_id=1&mobile=0') { rewrite ^(.*)$ https://yandex.ru? last; .... } Но все равно всем спасибо за ответы. :) 09.06.2016 13:31, Maxim Kozlov пишет: > Смотрите в сторону map и переменной переменных $arg_ > http://nginx.org/ru/docs/http/ngx_http_core_module.html#var_arg_ > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Thu Jun 9 11:02:18 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 09 Jun 2016 14:02:18 +0300 Subject: =?UTF-8?B?UmU6INC90LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8gcmV3cml0ZSDRgdGC0YDQvtC6?= =?UTF-8?B?0Lgg0YEg0L/QsNGA0LDQvNC10YLRgNCw0LzQuA==?= In-Reply-To: <3a5e0178-eb83-42e4-8f12-1a35c7d2b45a@jermakyan.ru> References: <85b15c9b-ec6d-0862-348b-a9ec9ff1ba1e@jermakyan.ru> <3a5e0178-eb83-42e4-8f12-1a35c7d2b45a@jermakyan.ru> Message-ID: <1904111.LHR2gx22ys@vbart-workstation> On Thursday 09 June 2016 13:57:54 Ilya Jermakyan wrote: > Сделал в итоге вот так: > > location / { > .... > if ($query_string = 'product_id=1&mobile=0') { > rewrite ^(.*)$ https://yandex.ru? last; > > .... > > } > > > Но все равно всем спасибо за ответы. :) > > [..] На всякий случай: /?product_id=1&mobile=0 /?mobile=0&product_id=1 идентичные запросы. -- Валентин Бартенев From mdounin на mdounin.ru Thu Jun 9 11:02:47 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 9 Jun 2016 14:02:47 +0300 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kg0Lgg0L3QtdGB0LrQvtC70YzQutC+IGRvY3VtZW50IHJvb3Q=?= In-Reply-To: References: Message-ID: <20160609110247.GK36620@mdounin.ru> Hello! On Thu, Jun 09, 2016 at 01:40:28PM +0300, Alex Domoradov wrote: > Привет всем, > > столкнулся с казалось бы тривиальной задачей, для одного location надо > задать root отличный от того, что задан на уровне server > > server { > > root /vhosts/example.com/public_html/web/; > > location ~/api/.*\.php { > root /vhosts/dev-designer/public_html/api; > add_header X-DEBUG "LOC-API-PHP" always; > error_page 406 = @fastcgi; > return 406; > } > > location ~/api/ { > add_header X-DEBUG "API" always; > root /vhosts/example.com/public_html/api; > } > > location ~ \.php$ { > error_page 406 = @fastcgi; > return 406; > } > > location @fastcgi { > add_header X-DEBUG "FAST-CGI" always; > > fastcgi_pass unix:/run/php/php5.6-fpm.sock; > fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; > ... > } > } > > но в таком случае, запрос попадает в @fastcgi, но при этом root у него > остается дефолтный. При этом если я коментирую *error_page/return* в > *~/api/.*\.php*, то я вижу что запрос попадает в этот location и root у > него меняется, но почему то с учетом return root остается с уровня server Потому что то, какая конфигурация была задана в location'е, в котором запрос обрабатывался ранее, не влияет на то, как он будет обрабатываться после перенаправления в другой location. Конфигурация для обработки запроса задаётся полностью в конкретном location'е. Наследование конфигурации - только на этапе её парсинга с предыдущих уровней, не более того. > Гугл предлагает такой вариант > > http://serverfault.com/questions/317641/nginx-multiple-document-roots-with-fastcgi > > хотелось бы узнать, это единственно верный способ решения данной задачи > (использование вложенных локейшенов)? Нет, не единственный. В вашем случае проще всего будет завести ещё один именованный location для обработки fastcgi, в котором и указать нужный root: location ~/api/.*\.php { root /vhosts/dev-designer/public_html/api; add_header X-DEBUG "LOC-API-PHP" always; error_page 406 = @fastcgi_api; return 406; } location @fastcgi_api { root /vhosts/dev-designer/public_html/api; fastcgi_pass ... ... } -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Thu Jun 9 11:09:16 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 9 Jun 2016 14:09:16 +0300 Subject: =?UTF-8?B?UmU6ICpfaW50ZXJjZXB0X2Vycm9ycyDRgtC+0LvRjNC60L4g0LTQu9GPINC+0L8=?= =?UTF-8?B?0YDQtdC00LXQu9GR0L3QvdGL0YUg0LrQvtC00L7Qsg==?= In-Reply-To: <3804417.E5snpS18qY@note> References: <3804417.E5snpS18qY@note> Message-ID: <20160609110916.GL36620@mdounin.ru> Hello! On Thu, Jun 09, 2016 at 05:55:40PM +0700, Vadim A. Misbakh-Soloviov wrote: > Всем привет! > > Я тут уже не в первый раз сталкиваюсь что у веб-приложений могут быть свои > обработчики, например, 404 (иногда и 403, а иногда даже и 503) ошибки, при > этом остальные коды (особенно пятисотые) оно не обрабатывает и отдаются > "пустые" дефолтные вместо тех, которые указаны у NgX в error_page. > В связи с этим захотелось как-нибудь накостылять возможность указывать на > какие коды отдавать страницу ошибки, которую вернул бекенд, а на какие - > error_page. > > У кого-нибудь есть идеи, как нарисовать подобное в конфиге? > У меня пока как-то не очень получается :) Перехватываются только те коды, для которых явно задана обработка с помощью директивы error_page. Соответственно если обработку не задавать в конкретном location'е (читай: задать в location'е явно обработку для тех ошибок, которые перехватывать надо, и не задавать для тех, которые не надо) - то и перехватываться они не будут. -- Maxim Dounin http://nginx.org/ From alex.hha на gmail.com Thu Jun 9 11:22:21 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 9 Jun 2016 14:22:21 +0300 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kg0Lgg0L3QtdGB0LrQvtC70YzQutC+IGRvY3VtZW50IHJvb3Q=?= In-Reply-To: <20160609110247.GK36620@mdounin.ru> References: <20160609110247.GK36620@mdounin.ru> Message-ID: Понял, еще один момент. А если мне надо получить такое поведение http://example.com/api/test.php -> /vhosts/ example.com/public_html/api/web/test.php как будет более правильно реализовать такое поведение? Сейчас реализовал через set, но что то подсказывает, что это велосипед location ~/api/(.*\.php$) { set $file_path "$1"; error_page 406 = @fastcgi-api; return 406; } location @fastcgi-api { root /vhosts/example.com/public_html; fastcgi_param SCRIPT_FILENAME $document_root/api/web/$file_path; } 2016-06-09 14:02 GMT+03:00 Maxim Dounin : > Hello! > > On Thu, Jun 09, 2016 at 01:40:28PM +0300, Alex Domoradov wrote: > > > Привет всем, > > > > столкнулся с казалось бы тривиальной задачей, для одного location надо > > задать root отличный от того, что задан на уровне server > > > > server { > > > > root /vhosts/example.com/public_html/web/; > > > > location ~/api/.*\.php { > > root /vhosts/dev-designer/public_html/api; > > add_header X-DEBUG "LOC-API-PHP" always; > > error_page 406 = @fastcgi; > > return 406; > > } > > > > location ~/api/ { > > add_header X-DEBUG "API" always; > > root /vhosts/example.com/public_html/api; > > } > > > > location ~ \.php$ { > > error_page 406 = @fastcgi; > > return 406; > > } > > > > location @fastcgi { > > add_header X-DEBUG "FAST-CGI" always; > > > > fastcgi_pass unix:/run/php/php5.6-fpm.sock; > > fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; > > ... > > } > > } > > > > но в таком случае, запрос попадает в @fastcgi, но при этом root у него > > остается дефолтный. При этом если я коментирую *error_page/return* в > > *~/api/.*\.php*, то я вижу что запрос попадает в этот location и root у > > него меняется, но почему то с учетом return root остается с уровня server > > Потому что то, какая конфигурация была задана в location'е, в > котором запрос обрабатывался ранее, не влияет на то, как он будет > обрабатываться после перенаправления в другой location. > > Конфигурация для обработки запроса задаётся полностью в конкретном > location'е. Наследование конфигурации - только на этапе её > парсинга с предыдущих уровней, не более того. > > > Гугл предлагает такой вариант > > > > > http://serverfault.com/questions/317641/nginx-multiple-document-roots-with-fastcgi > > > > хотелось бы узнать, это единственно верный способ решения данной задачи > > (использование вложенных локейшенов)? > > Нет, не единственный. В вашем случае проще всего будет завести > ещё один именованный location для обработки fastcgi, в котором и > указать нужный root: > > location ~/api/.*\.php { > root /vhosts/dev-designer/public_html/api; > add_header X-DEBUG "LOC-API-PHP" always; > error_page 406 = @fastcgi_api; > return 406; > } > > location @fastcgi_api { > root /vhosts/dev-designer/public_html/api; > fastcgi_pass ... > ... > } > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на mva.name Thu Jun 9 12:00:07 2016 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Thu, 09 Jun 2016 19:00:07 +0700 Subject: =?UTF-8?B?UmU6ICpfaW50ZXJjZXB0X2Vycm9ycyDRgtC+0LvRjNC60L4g0LTQu9GPINC+0L8=?= =?UTF-8?B?0YDQtdC00LXQu9GR0L3QvdGL0YUg0LrQvtC00L7Qsg==?= In-Reply-To: <20160609110916.GL36620@mdounin.ru> References: <3804417.E5snpS18qY@note> <20160609110916.GL36620@mdounin.ru> Message-ID: <2102597.nyRrLzyGZc@note> > задать в location'е явно > обработку для тех ошибок, которые перехватывать надо, и не > задавать для тех, которые не надо А коллизий с заданными уровнем выше, например, не будет? -- wbr, mva From mdounin на mdounin.ru Thu Jun 9 12:22:51 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 9 Jun 2016 15:22:51 +0300 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kg0Lgg0L3QtdGB0LrQvtC70YzQutC+IGRvY3VtZW50IHJvb3Q=?= In-Reply-To: References: <20160609110247.GK36620@mdounin.ru> Message-ID: <20160609122251.GN36620@mdounin.ru> Hello! On Thu, Jun 09, 2016 at 02:22:21PM +0300, Alex Domoradov wrote: > Понял, еще один момент. А если мне надо получить такое поведение > > http://example.com/api/test.php -> /vhosts/ > example.com/public_html/api/web/test.php > > как будет более правильно реализовать такое поведение? Сейчас реализовал > через set, но что то подсказывает, что это велосипед > > location ~/api/(.*\.php$) { > set $file_path "$1"; > error_page 406 = @fastcgi-api; > return 406; > } > > location @fastcgi-api { > root /vhosts/example.com/public_html; > fastcgi_param SCRIPT_FILENAME $document_root/api/web/$file_path; > } Проще всего сделать как-то так: location ~ /api/(.*\.php)$ { alias /vhosts/example.com/public_html/api/web/$1; fastcgi_pass ... include fastcgi.conf; } (Где fastcgi.conf - стандартный конфиг из дистрибутива, устанавливающий SCRIPT_FILENAME в $document_root$fastcgi_script_name.) Или, если на самом деле любые запросы к /api/ должны смотреть в public_html/api/web/, как-то так: location /api/ { alias /vhosts/example.com/public_html/api/web/; location ~ \.php$ { fastcgi_pass ... include fastcgi.conf; } } Отмечу также, что смысла в error_page/return/именованых location'ах в конфиге как он показан - нет. Если смысл на самом деле есть - то можно и через set передать нужное. Отдельный вопрос: зачем все эти танцы, и не проще ли на файловой системе всё хранить в приличном виде, или как минимум сделать правильную структуру симлинками. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Thu Jun 9 12:27:56 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 9 Jun 2016 15:27:56 +0300 Subject: =?UTF-8?B?UmU6ICpfaW50ZXJjZXB0X2Vycm9ycyDRgtC+0LvRjNC60L4g0LTQu9GPINC+0L8=?= =?UTF-8?B?0YDQtdC00LXQu9GR0L3QvdGL0YUg0LrQvtC00L7Qsg==?= In-Reply-To: <2102597.nyRrLzyGZc@note> References: <3804417.E5snpS18qY@note> <20160609110916.GL36620@mdounin.ru> <2102597.nyRrLzyGZc@note> Message-ID: <20160609122755.GO36620@mdounin.ru> Hello! On Thu, Jun 09, 2016 at 07:00:07PM +0700, Vadim A. Misbakh-Soloviov wrote: > > задать в location'е явно > > обработку для тех ошибок, которые перехватывать надо, и не > > задавать для тех, которые не надо > > А коллизий с заданными уровнем выше, например, не будет? http://nginx.org/r/error_page/ru: : Директивы error_page наследуются с предыдущего уровня при : условии, что на данном уровне не заданы свои директивы : error_page. Если директива задаётся на текущем уровне, то значения, заданные на предыдущем уровне, не наследуются. Это общее правило, оно действует для всех директив, и такой подход полностью исключает какие-либо коллизии. -- Maxim Dounin http://nginx.org/ From alex.hha на gmail.com Thu Jun 9 12:47:30 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 9 Jun 2016 15:47:30 +0300 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kg0Lgg0L3QtdGB0LrQvtC70YzQutC+IGRvY3VtZW50IHJvb3Q=?= In-Reply-To: <20160609122251.GN36620@mdounin.ru> References: <20160609110247.GK36620@mdounin.ru> <20160609122251.GN36620@mdounin.ru> Message-ID: В таком случае location ~ /api/(.*\.php)$ { alias /vhosts/example.com/public_html/api/web/$1; fastcgi_pass ... include fastcgi.conf; } при обращении к /api/i.php файл он ищет в public_html/api/web/i.php/api/i.php 2016-06-09 15:22 GMT+03:00 Maxim Dounin : > Hello! > > On Thu, Jun 09, 2016 at 02:22:21PM +0300, Alex Domoradov wrote: > > > Понял, еще один момент. А если мне надо получить такое поведение > > > > http://example.com/api/test.php -> /vhosts/ > > example.com/public_html/api/web/test.php > > > > как будет более правильно реализовать такое поведение? Сейчас реализовал > > через set, но что то подсказывает, что это велосипед > > > > location ~/api/(.*\.php$) { > > set $file_path "$1"; > > error_page 406 = @fastcgi-api; > > return 406; > > } > > > > location @fastcgi-api { > > root /vhosts/example.com/public_html; > > fastcgi_param SCRIPT_FILENAME $document_root/api/web/$file_path; > > } > > Проще всего сделать как-то так: > > location ~ /api/(.*\.php)$ { > alias /vhosts/example.com/public_html/api/web/$1; > fastcgi_pass ... > include fastcgi.conf; > } > > (Где fastcgi.conf - стандартный конфиг из дистрибутива, > устанавливающий SCRIPT_FILENAME в $document_root$fastcgi_script_name.) > > Или, если на самом деле любые запросы к /api/ должны смотреть в > public_html/api/web/, как-то так: > > location /api/ { > alias /vhosts/example.com/public_html/api/web/; > > location ~ \.php$ { > fastcgi_pass ... > include fastcgi.conf; > } > } > > Отмечу также, что смысла в error_page/return/именованых > location'ах в конфиге как он показан - нет. Если смысл на самом > деле есть - то можно и через set передать нужное. > > Отдельный вопрос: зачем все эти танцы, и не проще ли на > файловой системе всё хранить в приличном виде, или как минимум > сделать правильную структуру симлинками. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Jun 9 13:25:02 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 9 Jun 2016 16:25:02 +0300 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kg0Lgg0L3QtdGB0LrQvtC70YzQutC+IGRvY3VtZW50IHJvb3Q=?= In-Reply-To: References: <20160609110247.GK36620@mdounin.ru> <20160609122251.GN36620@mdounin.ru> Message-ID: <20160609132502.GR36620@mdounin.ru> Hello! On Thu, Jun 09, 2016 at 03:47:30PM +0300, Alex Domoradov wrote: > В таком случае > > location ~ /api/(.*\.php)$ { > alias /vhosts/example.com/public_html/api/web/$1; > fastcgi_pass ... > include fastcgi.conf; > } > > при обращении к /api/i.php файл он ищет в > public_html/api/web/i.php/api/i.php Да, ошибся, в этом случае надо SCRIPT_FILENAME ставить в $request_filename, стандартный fastcgi.conf работать не будет. Наиболее простой и логичный конфиг получается, если alias задан для префиксного location'а, как уже было предложено ранее. -- Maxim Dounin http://nginx.org/ From nginx на mva.name Thu Jun 9 14:05:19 2016 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Thu, 09 Jun 2016 21:05:19 +0700 Subject: =?UTF-8?B?UmU6ICpfaW50ZXJjZXB0X2Vycm9ycyDRgtC+0LvRjNC60L4g0LTQu9GPINC+0L8=?= =?UTF-8?B?0YDQtdC00LXQu9GR0L3QvdGL0YUg0LrQvtC00L7Qsg==?= In-Reply-To: <20160609122755.GO36620@mdounin.ru> References: <3804417.E5snpS18qY@note> <2102597.nyRrLzyGZc@note> <20160609122755.GO36620@mdounin.ru> Message-ID: <3196481.0Xj3keoak5@note> > Если директива задаётся на текущем уровне, то значения, заданные > на предыдущем уровне, не наследуются. Это общее правило, оно > действует для всех директив, и такой подход полностью исключает > какие-либо коллизии. Ну ок, спасибо, понял :) А то как-то неочевидно (фраза казалась двусмысленной) из формулировки в доках было при предыдущих прочтениях :) -- wbr, mva From dmitry.sinina на onat.edu.ua Thu Jun 9 14:14:02 2016 From: dmitry.sinina на onat.edu.ua (Dmitry Sinina) Date: Thu, 9 Jun 2016 17:14:02 +0300 Subject: =?UTF-8?B?UmU6IEZpcmVmb3gg0L/QvtCy0YLQvtGA0L3QviDQuNGB0L/Qu9C+0LvRjNC30YM=?= =?UTF-8?B?0LXRgiDRgdC+0LXQtNC40L3QtdC90LjQtSBJUHY2INC90LAg0L7RgdC90L4=?= =?UTF-8?B?0LLQsNC90LjQuCBJUHY0LiDQmtCw0Log0YEg0Y3RgtC40Lwg0LbQuNGC0Yw/?= In-Reply-To: <2062007.oOJF4t3NXu@cybernote> References: <5511204.WWaG6CCJ7j@cybernote> <2800703.PeX2ve6YMN@cybernote> <20160601212525.GH36620@mdounin.ru> <2062007.oOJF4t3NXu@cybernote> Message-ID: > Здравствуйте! > Будет ли слишком нагло попросить Вас сформулировать проблему грамотно и кратко? Желательно на английском, ну или я сам переведу. В идеале я буду искренне благодарен любым разумным комментаториям в баге по приведенной ранее ссылке. > С уважением, Иван Прокудин. > продолжение тут https://groups.google.com/forum/#!topic/mozilla.dev.tech.network/YKGxDv99nMU From alex.hha на gmail.com Thu Jun 9 16:08:42 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 9 Jun 2016 19:08:42 +0300 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kg0Lgg0L3QtdGB0LrQvtC70YzQutC+IGRvY3VtZW50IHJvb3Q=?= In-Reply-To: <20160609132502.GR36620@mdounin.ru> References: <20160609110247.GK36620@mdounin.ru> <20160609122251.GN36620@mdounin.ru> <20160609132502.GR36620@mdounin.ru> Message-ID: МБ опять, что упускаю, но с таким конфигом location /api/ { alias /vhosts/example.com/public_html/api/web/; location ~ \.php$ { fastcgi_pass ... include fastcgi.conf; } } файл /api/i.php оно ищет в public_html/web/api/i.html вместо public_html/api/web/i.html, т.е. такое ощущение, что root берется из блока server 2016-06-09 16:25 GMT+03:00 Maxim Dounin : > Hello! > > On Thu, Jun 09, 2016 at 03:47:30PM +0300, Alex Domoradov wrote: > > > В таком случае > > > > location ~ /api/(.*\.php)$ { > > alias /vhosts/example.com/public_html/api/web/$1; > > fastcgi_pass ... > > include fastcgi.conf; > > } > > > > при обращении к /api/i.php файл он ищет в > > public_html/api/web/i.php/api/i.php > > Да, ошибся, в этом случае надо SCRIPT_FILENAME ставить в > $request_filename, стандартный fastcgi.conf работать не будет. > > Наиболее простой и логичный конфиг получается, если alias задан > для префиксного location'а, как уже было предложено ранее. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Jun 9 18:47:25 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 9 Jun 2016 21:47:25 +0300 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kg0Lgg0L3QtdGB0LrQvtC70YzQutC+IGRvY3VtZW50IHJvb3Q=?= In-Reply-To: References: <20160609110247.GK36620@mdounin.ru> <20160609122251.GN36620@mdounin.ru> <20160609132502.GR36620@mdounin.ru> Message-ID: <20160609184725.GS36620@mdounin.ru> Hello! On Thu, Jun 09, 2016 at 07:08:42PM +0300, Alex Domoradov wrote: > МБ опять, что упускаю, но с таким конфигом > > location /api/ { > alias /vhosts/example.com/public_html/api/web/; > > location ~ \.php$ { > fastcgi_pass ... > include fastcgi.conf; > } > } > файл /api/i.php оно ищет в public_html/web/api/i.html вместо > public_html/api/web/i.html, т.е. такое ощущение, что root берется из блока > server Такого быть не должно, по крайней мере в современных версиях (до 1.9.4/1.8.1 при использовании alias и вложенных regexp-location'ов могло быть что угодно). Но таки я опять ошибся, тут тоже нужен будет $request_filename. -- Maxim Dounin http://nginx.org/ From alex.hha на gmail.com Thu Jun 9 20:44:44 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 9 Jun 2016 23:44:44 +0300 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kg0Lgg0L3QtdGB0LrQvtC70YzQutC+IGRvY3VtZW50IHJvb3Q=?= In-Reply-To: <20160609184725.GS36620@mdounin.ru> References: <20160609110247.GK36620@mdounin.ru> <20160609122251.GN36620@mdounin.ru> <20160609132502.GR36620@mdounin.ru> <20160609184725.GS36620@mdounin.ru> Message-ID: # nginx -v nginx version: nginx/1.11.0 Ubuntu 14.04. с php и $request_filename трюк работает fastcgi_param SCRIPT_FILENAME $request_filename; а вот просто html файл не находит. А ищет тут - public_html/web/api/test.html 2016-06-09 21:47 GMT+03:00 Maxim Dounin : > Hello! > > On Thu, Jun 09, 2016 at 07:08:42PM +0300, Alex Domoradov wrote: > > > МБ опять, что упускаю, но с таким конфигом > > > > location /api/ { > > alias /vhosts/example.com/public_html/api/web/; > > > > location ~ \.php$ { > > fastcgi_pass ... > > include fastcgi.conf; > > } > > } > > файл /api/i.php оно ищет в public_html/web/api/i.html вместо > > public_html/api/web/i.html, т.е. такое ощущение, что root берется из > блока > > server > > Такого быть не должно, по крайней мере в современных версиях (до > 1.9.4/1.8.1 при использовании alias и вложенных regexp-location'ов > могло быть что угодно). > > Но таки я опять ошибся, тут тоже нужен будет $request_filename. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Jun 9 20:57:20 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 9 Jun 2016 23:57:20 +0300 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kg0Lgg0L3QtdGB0LrQvtC70YzQutC+IGRvY3VtZW50IHJvb3Q=?= In-Reply-To: References: <20160609110247.GK36620@mdounin.ru> <20160609122251.GN36620@mdounin.ru> <20160609132502.GR36620@mdounin.ru> <20160609184725.GS36620@mdounin.ru> Message-ID: <20160609205719.GY36620@mdounin.ru> Hello! On Thu, Jun 09, 2016 at 11:44:44PM +0300, Alex Domoradov wrote: > # nginx -v > nginx version: nginx/1.11.0 > > Ubuntu 14.04. > > с php и $request_filename трюк работает > > fastcgi_param SCRIPT_FILENAME $request_filename; > > а вот просто html файл не находит. А ищет тут - public_html/web/api/test.html Такое обычно бывает, если на верхнем уровне описан regex location для обработки статических файлов, что-нибудь вроде location ~ \.(jpg|gif|html)$ { expires 1m; } Возможные решения: 1. Добавить модификатор "^~" к location /api/, дабы запретить дальнейший поиск регулярных выражений. 2. Изолировать этот regex location внутри префиксного, e.g. location / { ... location ~ \.(jpg|gif|html)$ { expires 1m; } } Подробнее про то, как работают location'ы, можно почитать в документации, http://nginx.org/r/location/ru. Вообще с location'ами, заданными регулярными выражениями, стоит быть осторожным и по возможности избегать и/или изолировать. Неаккуратность легко приводит к конфигам, которые невозможно поддерживать. -- Maxim Dounin http://nginx.org/ From rh на nobrend.ru Thu Jun 9 21:06:36 2016 From: rh на nobrend.ru (-HaRius-) Date: Fri, 10 Jun 2016 00:06:36 +0300 Subject: great article Message-ID: <0000a8e1aa41$05be05a4$4c24823c$@nobrend.ru> Hello, I've read a nice and informative article about some stuff you may really like, you can find more info here Best, -HaRius- -------------- next part -------------- An HTML attachment was scrubbed... URL: From server_inc на list.ru Fri Jun 10 05:31:53 2016 From: server_inc на list.ru (=?UTF-8?B?0KHRgtCw0L3QuNGB0LvQsNCy?=) Date: Thu, 9 Jun 2016 22:31:53 -0700 Subject: nginx + lua broken Message-ID: <575A50C9.5030507@list.ru> Здравствуйте, Подскажите пожалуйста чего это не работает: > # nginx -t > nginx: [emerg] unknown directive "content_by_lua" in > /usr/local/etc/nginx/virtual/kagdila.rooty.name.conf:51 > nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed Nginx был собран с lua: > # nginx -V > nginx version: nginx/1.10.1 > built with OpenSSL 1.0.2h 3 May 2016 > TLS SNI support enabled > configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I > /usr/local/include' --with-ld-opt='-L /usr/local/lib' > --conf-path=/usr/local/etc/nginx/nginx.conf > --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid > --error-log-path=/var/log/nginx-error.log --user=www --group=www > --modules-path=/usr/local/libexec/nginx --with-file-aio --with-ipv6 > --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp > --http-log-path=/var/log/nginx-access.log --with-http_addition_module > --with-http_auth_request_module --with-http_dav_module > --with-http_flv_module --with-http_gzip_static_module > --with-http_gunzip_module --with-http_mp4_module > --with-http_random_index_module --with-http_realip_module > --with-http_secure_link_module --with-http_slice_module > --with-http_stub_status_module --with-http_sub_module > --add-module=/usr/ports/www/nginx/work/ngx_devel_kit-0.2.19 > --add-dynamic-module=/usr/ports/www/nginx/work/lua-nginx-module-0.10.5 > --with-pcre --with-http_v2_module --with-stream=dynamic > --with-stream_ssl_module --with-threads --with-http_ssl_module > # pkg info nginx | grep -i lua > LUA : on > libluajit-5.1.so.2 From vovansystems на gmail.com Fri Jun 10 05:40:07 2016 From: vovansystems на gmail.com (VovansystemS) Date: Fri, 10 Jun 2016 08:40:07 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qs9C00LAg0LvRg9GH0YjQtSDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?= =?UTF-8?B?0YwgbXVsdGlfYWNjZXB0IG9u?= In-Reply-To: References: Message-ID: > подскажите пожалуйста, в каких случаях нужно включать multi_accept on > и как именно он работает? anyone? может быть кто-то использует в production - опишите пожалуйста для чего и в чём выигрыш и какой у вас тип нагрузки? P.S. я спрашиваю, потому что в интернетах во многих конфигах для хайлоада советуют включать, но нигде не объясняют почему - очень хочется разобраться с этой директивой From medvedev.yp на gmail.com Fri Jun 10 05:48:36 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Fri, 10 Jun 2016 08:48:36 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qs9C00LAg0LvRg9GH0YjQtSDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?= =?UTF-8?B?0YwgbXVsdGlfYWNjZXB0IG9u?= In-Reply-To: References: Message-ID: При включенном multi_accept, nginx будет пытаться обработать все новые входящие соединения http://nginx.org/ru/docs/ngx_core_module.html#multi_accept 10 июня 2016 г., 8:40 пользователь VovansystemS написал: > > подскажите пожалуйста, в каких случаях нужно включать multi_accept on > > и как именно он работает? > anyone? может быть кто-то использует в production - опишите пожалуйста > для чего и в чём выигрыш и какой у вас тип нагрузки? > > P.S. я спрашиваю, потому что в интернетах во многих конфигах для > хайлоада советуют включать, но нигде не объясняют почему - очень > хочется разобраться с этой директивой > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From medvedev.yp на gmail.com Fri Jun 10 05:51:19 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Fri, 10 Jun 2016 08:51:19 +0300 Subject: nginx + lua broken In-Reply-To: <575A50C9.5030507@list.ru> References: <575A50C9.5030507@list.ru> Message-ID: Hi, а модуль lua на месте? 10 июня 2016 г. 8:32 пользователь "Станислав" написал: > Здравствуйте, > > Подскажите пожалуйста чего это не работает: > >> # nginx -t >> nginx: [emerg] unknown directive "content_by_lua" in >> /usr/local/etc/nginx/virtual/kagdila.rooty.name.conf:51 >> nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed >> > > Nginx был собран с lua: > > # nginx -V >> nginx version: nginx/1.10.1 >> built with OpenSSL 1.0.2h 3 May 2016 >> TLS SNI support enabled >> configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I >> /usr/local/include' --with-ld-opt='-L /usr/local/lib' >> --conf-path=/usr/local/etc/nginx/nginx.conf >> --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid >> --error-log-path=/var/log/nginx-error.log --user=www --group=www >> --modules-path=/usr/local/libexec/nginx --with-file-aio --with-ipv6 >> --http-client-body-temp-path=/var/tmp/nginx/client_body_temp >> --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp >> --http-proxy-temp-path=/var/tmp/nginx/proxy_temp >> --http-scgi-temp-path=/var/tmp/nginx/scgi_temp >> --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp >> --http-log-path=/var/log/nginx-access.log --with-http_addition_module >> --with-http_auth_request_module --with-http_dav_module >> --with-http_flv_module --with-http_gzip_static_module >> --with-http_gunzip_module --with-http_mp4_module >> --with-http_random_index_module --with-http_realip_module >> --with-http_secure_link_module --with-http_slice_module >> --with-http_stub_status_module --with-http_sub_module >> --add-module=/usr/ports/www/nginx/work/ngx_devel_kit-0.2.19 >> --add-dynamic-module=/usr/ports/www/nginx/work/lua-nginx-module-0.10.5 >> --with-pcre --with-http_v2_module --with-stream=dynamic >> --with-stream_ssl_module --with-threads --with-http_ssl_module >> > > # pkg info nginx | grep -i lua >> LUA : on >> libluajit-5.1.so.2 >> > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vovansystems на gmail.com Fri Jun 10 06:08:52 2016 From: vovansystems на gmail.com (VovansystemS) Date: Fri, 10 Jun 2016 09:08:52 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qs9C00LAg0LvRg9GH0YjQtSDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?= =?UTF-8?B?0YwgbXVsdGlfYWNjZXB0IG9u?= In-Reply-To: References: Message-ID: > При включенном multi_accept, nginx будет пытаться обработать все новые > входящие соединения > http://nginx.org/ru/docs/ngx_core_module.html#multi_accept да, спасибо, я это читал и искал пояснения в рассылке, но к пониманию работы директивы меня это не приблизило. (предыдущее письмо с тем, что я нашёл тут http://mailman.nginx.org/pipermail/nginx-ru/2016-May/058283.html ) From server_inc на list.ru Fri Jun 10 06:17:30 2016 From: server_inc на list.ru (=?UTF-8?B?0KHRgtCw0L3QuNGB0LvQsNCy?=) Date: Thu, 9 Jun 2016 23:17:30 -0700 Subject: nginx + lua broken In-Reply-To: References: <575A50C9.5030507@list.ru> Message-ID: <575A5B7A.1000402@list.ru> Такое есть: > # ls -la /usr/local/libexec/nginx/ngx_http_lua_module.so > -r-xr-xr-x 1 root wheel 336032 10 июн 07:59 > /usr/local/libexec/nginx/ngx_http_lua_module.so # pkg info -l luajit-2.0.4 luajit-2.0.4: /usr/local/bin/luajit /usr/local/bin/luajit-2.0.4 /usr/local/include/luajit-2.0/lauxlib.h /usr/local/include/luajit-2.0/lua.h /usr/local/include/luajit-2.0/lua.hpp /usr/local/include/luajit-2.0/luaconf.h /usr/local/include/luajit-2.0/luajit.h /usr/local/include/luajit-2.0/lualib.h /usr/local/lib/libluajit-5.1.a /usr/local/lib/libluajit-5.1.so /usr/local/lib/libluajit-5.1.so.2 /usr/local/lib/libluajit-5.1.so.2.0.4 /usr/local/libdata/pkgconfig/luajit.pc /usr/local/man/man1/luajit.1.gz /usr/local/share/luajit-2.0.4/jit/bc.lua /usr/local/share/luajit-2.0.4/jit/bcsave.lua /usr/local/share/luajit-2.0.4/jit/dis_arm.lua /usr/local/share/luajit-2.0.4/jit/dis_mips.lua /usr/local/share/luajit-2.0.4/jit/dis_mipsel.lua /usr/local/share/luajit-2.0.4/jit/dis_ppc.lua /usr/local/share/luajit-2.0.4/jit/dis_x64.lua /usr/local/share/luajit-2.0.4/jit/dis_x86.lua /usr/local/share/luajit-2.0.4/jit/dump.lua /usr/local/share/luajit-2.0.4/jit/v.lua /usr/local/share/luajit-2.0.4/jit/vmdef.lua # nginx pkg info -l nginx nginx-1.10.1,2: /usr/local/etc/nginx/fastcgi_params-dist /usr/local/etc/nginx/koi-utf /usr/local/etc/nginx/koi-win /usr/local/etc/nginx/mime.types-dist /usr/local/etc/nginx/nginx.conf-dist /usr/local/etc/nginx/scgi_params-dist /usr/local/etc/nginx/uwsgi_params-dist /usr/local/etc/nginx/win-utf /usr/local/etc/rc.d/nginx /usr/local/libexec/nginx/ngx_http_lua_module.so /usr/local/libexec/nginx/ngx_stream_module.so /usr/local/man/man8/nginx.8.gz /usr/local/sbin/nginx /usr/local/share/licenses/nginx-1.10.1,2/BSD2CLAUSE /usr/local/share/licenses/nginx-1.10.1,2/LICENSE /usr/local/share/licenses/nginx-1.10.1,2/catalog.mk /usr/local/www/nginx-dist/50x.html /usr/local/www/nginx-dist/EXAMPLE_DIRECTORY-DONT_ADD_OR_TOUCH_ANYTHING /usr/local/www/nginx-dist/index.html По сути я собрал nginx из портов с опцией LUA на чистой FreeBSD 10.3. На предыдущей машинке работало > Hi, а модуль lua на месте? > > 10 июня 2016 г. 8:32 пользователь "Станислав" > написал: > > Здравствуйте, > > Подскажите пожалуйста чего это не работает: > > # nginx -t > nginx: [emerg] unknown directive "content_by_lua" in > /usr/local/etc/nginx/virtual/kagdila.rooty.name.conf:51 > nginx: configuration file /usr/local/etc/nginx/nginx.conf test > failed > > > Nginx был собран с lua: > > # nginx -V > nginx version: nginx/1.10.1 > built with OpenSSL 1.0.2h 3 May 2016 > TLS SNI support enabled > configure arguments: --prefix=/usr/local/etc/nginx > --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L > /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf > --sbin-path=/usr/local/sbin/nginx > --pid-path=/var/run/nginx.pid > --error-log-path=/var/log/nginx-error.log --user=www > --group=www --modules-path=/usr/local/libexec/nginx > --with-file-aio --with-ipv6 > --http-client-body-temp-path=/var/tmp/nginx/client_body_temp > --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp > --http-proxy-temp-path=/var/tmp/nginx/proxy_temp > --http-scgi-temp-path=/var/tmp/nginx/scgi_temp > --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp > --http-log-path=/var/log/nginx-access.log > --with-http_addition_module --with-http_auth_request_module > --with-http_dav_module --with-http_flv_module > --with-http_gzip_static_module --with-http_gunzip_module > --with-http_mp4_module --with-http_random_index_module > --with-http_realip_module --with-http_secure_link_module > --with-http_slice_module --with-http_stub_status_module > --with-http_sub_module > --add-module=/usr/ports/www/nginx/work/ngx_devel_kit-0.2.19 > --add-dynamic-module=/usr/ports/www/nginx/work/lua-nginx-module-0.10.5 > --with-pcre --with-http_v2_module --with-stream=dynamic > --with-stream_ssl_module --with-threads --with-http_ssl_module > > > # pkg info nginx | grep -i lua > LUA : on > libluajit-5.1.so.2 > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx на mva.name Fri Jun 10 06:32:14 2016 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 10 Jun 2016 13:32:14 +0700 Subject: nginx + lua broken In-Reply-To: <575A50C9.5030507@list.ru> References: <575A50C9.5030507@list.ru> Message-ID: <2192893.8JHdbAXY26@note> В письме от четверг, 9 июня 2016 г. 22:31:53 TSK пользователь Станислав написал: > --add-dynamic-module=/usr/ports/www/nginx/work/lua-nginx-module-0.10.5 Потому что динамические модули нужно ещё и "загружать" в конфиге. До объявления server{} блоков в которых они используются :) -- wbr, mva From server_inc на list.ru Fri Jun 10 06:44:39 2016 From: server_inc на list.ru (=?UTF-8?B?0KHRgtCw0L3QuNGB0LvQsNCy?=) Date: Thu, 9 Jun 2016 23:44:39 -0700 Subject: nginx + lua broken In-Reply-To: <2192893.8JHdbAXY26@note> References: <575A50C9.5030507@list.ru> <2192893.8JHdbAXY26@note> Message-ID: <575A61D7.4030005@list.ru> Спасибо! Я - динозавр как-то пропустил эту тему с динамическими модулями. Работает :) > В письме от четверг, 9 июня 2016 г. 22:31:53 TSK пользователь Станислав > написал: >> --add-dynamic-module=/usr/ports/www/nginx/work/lua-nginx-module-0.10.5 > Потому что динамические модули нужно ещё и "загружать" в конфиге. До > объявления server{} блоков в которых они используются :) > From medvedev.yp на gmail.com Fri Jun 10 06:54:23 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Fri, 10 Jun 2016 09:54:23 +0300 Subject: nginx + lua broken In-Reply-To: <2192893.8JHdbAXY26@note> References: <575A50C9.5030507@list.ru> <2192893.8JHdbAXY26@note> Message-ID: И странно что такой путь до модуля /usr/ports/www/nginx/work/lua-nginx-module-0.10.5 У меня на 10 freebsd модули живут в /usr/local/libexec/nginx/, nginx установлен из портов 10 июня 2016 г., 9:32 пользователь Vadim A. Misbakh-Soloviov написал: > В письме от четверг, 9 июня 2016 г. 22:31:53 TSK пользователь Станислав > написал: > > --add-dynamic-module=/usr/ports/www/nginx/work/lua-nginx-module-0.10.5 > Потому что динамические модули нужно ещё и "загружать" в конфиге. До > объявления server{} блоков в которых они используются :) > > -- > wbr, > mva > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From medvedev.yp на gmail.com Fri Jun 10 07:06:39 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Fri, 10 Jun 2016 10:06:39 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qs9C00LAg0LvRg9GH0YjQtSDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?= =?UTF-8?B?0YwgbXVsdGlfYWNjZXB0IG9u?= In-Reply-To: References: Message-ID: Если вы включаете multi accept, nginx попытается обработать максимальное количество входящий соединений. Если значение worker_connections мало то быстро исчерпается лимит. Если директива выключена , то есть установлено значение off, то один процесс будет принимать одно соединение. При использовании multi accept необходимо так же тюнить worker_connections. При высокой нагрузке на веб сервер есть вероятность получить очереди входящих соединений 10 июня 2016 г., 9:08 пользователь VovansystemS написал: > > При включенном multi_accept, nginx будет пытаться обработать все новые > > входящие соединения > > http://nginx.org/ru/docs/ngx_core_module.html#multi_accept > да, спасибо, я это читал и искал пояснения в рассылке, но к пониманию > работы директивы меня это не приблизило. > > (предыдущее письмо с тем, что я нашёл тут > http://mailman.nginx.org/pipermail/nginx-ru/2016-May/058283.html ) > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vovansystems на gmail.com Fri Jun 10 11:04:49 2016 From: vovansystems на gmail.com (VovansystemS) Date: Fri, 10 Jun 2016 14:04:49 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qs9C00LAg0LvRg9GH0YjQtSDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?= =?UTF-8?B?0YwgbXVsdGlfYWNjZXB0IG9u?= In-Reply-To: References: Message-ID: > Если директива выключена , то есть установлено > значение off, то один процесс будет принимать одно соединение. > Если вы включаете multi accept, nginx попытается обработать максимальное > количество входящий соединений. Если значение worker_connections мало то > быстро исчерпается лимит. а какой смысл в том, что один процесс (worker) принимает сразу несколько соединений? ведь воркер однопоточен и будет обрабатывать их по-очереди. почему это иногда может быть лучше, чем поведение по-умолчанию "принять одно соединение, выполнить необходимую работу, принять следующее соединение"? почему иногда может быть эффективным принимать несколько соединений воркером за один вызов event loop? https://assets.wp.nginx.com/wp-content/uploads/2015/06/NGINX-Event-Loop2-e1434744201287.png From vbart на nginx.com Fri Jun 10 12:58:07 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 10 Jun 2016 15:58:07 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qs9C00LAg0LvRg9GH0YjQtSDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?= =?UTF-8?B?0YwgbXVsdGlfYWNjZXB0IG9u?= In-Reply-To: References: Message-ID: <2865802.1x1pgH5Mja@vbart-workstation> On Thursday 26 May 2016 21:48:11 VovansystemS wrote: > Добрый вечер, > > подскажите пожалуйста, в каких случаях нужно включать multi_accept on > и как именно он работает? > > документацию читал http://nginx.org/r/multi_accept/ru > из того, что мне удалось нагуглить, ничто не проясняет ситуацию для меня: > [..] Когда multi_accept выключен, то получая событие на listen-сокете рабочий процесс accept-ит и обрабатывает одно соединение, а затем снова уходит в ядро за событиями. Когда multi_accept включен, то по событию на listen-сокете рабочий процесс в цикле пытается accept-ить и обрабатывать соединения до тех пор, пока не получит EAGAIN. Если поступающих соединений очень много, то второй вариант работы может оказаться чуть оптимальнее, за счет того, что рабочий процесс для получения каждого соединение не ходит за событием в ядро. Если соединений мало, то будет много лишних вызовов accept() с EAGAIN. Кроме того, во втором подходе есть вероятность получить дисбаланс по количеству принятых соединений в случае, когда они поступают неравномерно и SO_REUSEPORT выключен. Произойти это может если рабочий процесс, который вошел в цикл accept-а новых соединений, заберет их все себе. В целом, скорее всего эффект от этой директивы неизмеримо мал, и трогать её значение не имеет смысла, за исключением экспериментов с какими-то искусственными бенчмарками. -- Валентин Бартенев From nginx-forum на forum.nginx.org Fri Jun 10 14:10:33 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Fri, 10 Jun 2016 10:10:33 -0400 Subject: =?UTF-8?B?UmU6INC60L7Qs9C00LAg0LvRg9GH0YjQtSDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?= =?UTF-8?B?0YwgbXVsdGkgYWNjZXB0IG9u?= In-Reply-To: References: Message-ID: <080fd92ef266983a41f4368d6a9f9d32.NginxMailingListRussian@forum.nginx.org> > Я не понимаю что мы выигрываем от принятия сразу нескольких > соединений за одну итерацию event loop'а. Я в таких случаях провожу нагрузочные эксперименты, чтобы понять что мы выигрываем, в данном случаи разница будет на уровне погрешности, но возможно вам стоит попробовать чтобы знать точно. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267183,267528#msg-267528 From vovansystems на gmail.com Fri Jun 10 14:16:51 2016 From: vovansystems на gmail.com (VovansystemS) Date: Fri, 10 Jun 2016 17:16:51 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qs9C00LAg0LvRg9GH0YjQtSDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?= =?UTF-8?B?0YwgbXVsdGlfYWNjZXB0IG9u?= In-Reply-To: <2865802.1x1pgH5Mja@vbart-workstation> References: <2865802.1x1pgH5Mja@vbart-workstation> Message-ID: > [..] > Если поступающих соединений очень много, то второй вариант работы может > оказаться чуть оптимальнее, за счет того, что рабочий процесс для получения > каждого соединение не ходит за событием в ядро. > [..] теперь понятно! Валентин, большое спасибо за подробное разъяснение From sargaskn на gmail.com Fri Jun 10 15:52:35 2016 From: sargaskn на gmail.com (Sargas) Date: Fri, 10 Jun 2016 18:52:35 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qs9C00LAg0LvRg9GH0YjQtSDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?= =?UTF-8?B?0YwgbXVsdGlfYWNjZXB0IG9u?= In-Reply-To: References: <2865802.1x1pgH5Mja@vbart-workstation> Message-ID: Валентин, а скажите, пожалуйста почему будет много лишних вызовов accept() с EAGAIN если соединений мало? Это будет только на Linux или на FreeBSD так же? На FreeBSD есть accept filter, соответственно если он включен в системе и в конфиге nginx, то система знает сколько соединений прошли фильтр и готовы для accept. Правильно ли я понимаю что рабочему процессу остается обработать известное кол-во соединений и не делать много лишних accept c EAGAIN в этом случае? 10 июня 2016 г., 17:16 пользователь VovansystemS написал: > > [..] > > Если поступающих соединений очень много, то второй вариант работы может > > оказаться чуть оптимальнее, за счет того, что рабочий процесс для > получения > > каждого соединение не ходит за событием в ядро. > > [..] > > теперь понятно! > > Валентин, большое спасибо за подробное разъяснение > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Fri Jun 10 17:11:30 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 10 Jun 2016 20:11:30 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qs9C00LAg0LvRg9GH0YjQtSDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?= =?UTF-8?B?0YwgbXVsdGlfYWNjZXB0IG9u?= In-Reply-To: References: Message-ID: <5109919.PzkQEIcTxo@vbart-workstation> On Friday 10 June 2016 18:52:35 Sargas wrote: > Валентин, а скажите, пожалуйста почему будет много лишних вызовов accept() > с EAGAIN если соединений мало? Потому что в этом режиме, как я уже писал, nginx в цикле зовет accept() до тех пор, пока не получит EAGAIN. Таким образом на каждое событие на listen-сокете мы имеем минимум один вызов accept() с EAGAIN. Если рабочему процессу удастся принять 5 соединений, то это будет 5 успешных accept()-ов и один неуспешный, а если всего одно, то пропорция 1 к 1. > Это будет только на Linux или на FreeBSD так же? На FreeBSD директива ни на что не влияет. Там kqueue сообщает о количестве пришедших соединений в событии и ровно столько раз nginx позовет accept(). > > На FreeBSD есть accept filter, соответственно если он включен в системе и в > конфиге nginx, то система знает сколько соединений прошли фильтр и готовы > для accept. Правильно ли я понимаю что рабочему процессу остается > обработать известное кол-во соединений и не делать много лишних accept c > EAGAIN в этом случае? Accept filter тут не причем. Как я уже описал выше, kqueue сам по себе сообщает сколько соединений пришло в сокет (независимо от того, используется ли accept filter или нет), в то время, как epoll сообщает только о факте наличия новых соединений, но не их количество. Про accept filter Игорь писал очень давно: http://sysoev.ru/freebsd/accept-filters.html В Linux аналогичной цели (уменьшение числа переключений контекста) может служить опция TCP_DEFER_ACCEPT. -- Валентин Бартенев From sargaskn на gmail.com Fri Jun 10 17:28:30 2016 From: sargaskn на gmail.com (Sargas) Date: Fri, 10 Jun 2016 20:28:30 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qs9C00LAg0LvRg9GH0YjQtSDQuNGB0L/QvtC70YzQt9C+0LLQsNGC?= =?UTF-8?B?0YwgbXVsdGlfYWNjZXB0IG9u?= In-Reply-To: <5109919.PzkQEIcTxo@vbart-workstation> References: <5109919.PzkQEIcTxo@vbart-workstation> Message-ID: Благодарю. 10 июня 2016 г., 20:11 пользователь Валентин Бартенев написал: > On Friday 10 June 2016 18:52:35 Sargas wrote: > > Валентин, а скажите, пожалуйста почему будет много лишних вызовов > accept() > > с EAGAIN если соединений мало? > > Потому что в этом режиме, как я уже писал, nginx в цикле зовет accept() до > тех пор, пока не получит EAGAIN. > > Таким образом на каждое событие на listen-сокете мы имеем минимум один > вызов > accept() с EAGAIN. > > Если рабочему процессу удастся принять 5 соединений, то это будет 5 > успешных > accept()-ов и один неуспешный, а если всего одно, то пропорция 1 к 1. > > > > Это будет только на Linux или на FreeBSD так же? > > На FreeBSD директива ни на что не влияет. Там kqueue сообщает о количестве > пришедших соединений в событии и ровно столько раз nginx позовет accept(). > > > > > > На FreeBSD есть accept filter, соответственно если он включен в системе > и в > > конфиге nginx, то система знает сколько соединений прошли фильтр и готовы > > для accept. Правильно ли я понимаю что рабочему процессу остается > > обработать известное кол-во соединений и не делать много лишних accept c > > EAGAIN в этом случае? > > Accept filter тут не причем. Как я уже описал выше, kqueue сам по себе > сообщает > сколько соединений пришло в сокет (независимо от того, используется ли > accept > filter или нет), в то время, как epoll сообщает только о факте наличия > новых > соединений, но не их количество. > > Про accept filter Игорь писал очень давно: > http://sysoev.ru/freebsd/accept-filters.html > > В Linux аналогичной цели (уменьшение числа переключений контекста) может > служить > опция TCP_DEFER_ACCEPT. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sejo412 на gmail.com Sat Jun 11 17:13:08 2016 From: sejo412 на gmail.com (Paul Sin) Date: Sat, 11 Jun 2016 20:13:08 +0300 Subject: =?UTF-8?B?UmU6INC90LUg0L/QvtC70YPRh9Cw0LXRgtGB0Y8gcmV3cml0ZSDRgdGC0YDQvtC6?= =?UTF-8?B?0Lgg0YEg0L/QsNGA0LDQvNC10YLRgNCw0LzQuA==?= In-Reply-To: <1904111.LHR2gx22ys@vbart-workstation> References: <85b15c9b-ec6d-0862-348b-a9ec9ff1ba1e@jermakyan.ru> <3a5e0178-eb83-42e4-8f12-1a35c7d2b45a@jermakyan.ru> <1904111.LHR2gx22ys@vbart-workstation> Message-ID: лучше что-то типа: map "$arg_product_id;$arg_mobile" $do_rewrite { "1;0" 1; default 0; } if ($do_rewrite = "1") { rewrite....} 9 июня 2016 г., 14:02 пользователь Валентин Бартенев написал: > On Thursday 09 June 2016 13:57:54 Ilya Jermakyan wrote: > > Сделал в итоге вот так: > > > > location / { > > .... > > if ($query_string = 'product_id=1&mobile=0') { > > rewrite ^(.*)$ https://yandex.ru? last; > > > > .... > > > > } > > > > > > Но все равно всем спасибо за ответы. :) > > > > > [..] > > На всякий случай: > > /?product_id=1&mobile=0 > /?mobile=0&product_id=1 > > идентичные запросы. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- best reguards Paul Sin ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sejo412 на gmail.com Sat Jun 11 17:28:41 2016 From: sejo412 на gmail.com (Paul Sin) Date: Sat, 11 Jun 2016 20:28:41 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9GA0LXRiNC10L3QvdGL0Lkg0LTQuNCw0L/QsNC30L7QvSBodHRw?= =?UTF-8?B?LdC+0YLQstC10YLQvtCyICjQuNC70LggItCy0YHQtdCz0LTQsCAyMDAiKQ==?= In-Reply-To: References: Message-ID: эта музыка будет вечна, пока не все придерживаются rfc Fielding, et al. Standards Track [Page 39] RFC 2616 HTTP/1.1 June 1999 The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit: - 1xx: Informational - Request received, continuing process - 2xx: Success - The action was successfully received, understood, and accepted - 3xx: Redirection - Further action must be taken in order to complete the request - 4xx: Client Error - The request contains bad syntax or cannot be fulfilled - 5xx: Server Error - The server failed to fulfill an apparently valid request Таки как решили вопрос в итоге? 2 июня 2016 г., 19:33 пользователь SK написал: > if ок, но что в then? > Return прекращает обработку запроса :-( > > 2 июня 2016 г., в 19:25, Yuriy Medvedev > написал(а): > > if ($status = "600") но if зло > 2 июня 2016 г. 19:08 пользователь "SK" написал: > >> error_page 600 -- невалиден по стандарту и не проходит проверку конфига. >> >> 2 июня 2016 г., в 18:56, Yuriy Medvedev >> написал(а): >> >> В документации есть пример >> http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page >> 2 июня 2016 г. 18:49 пользователь "Stepan Karamyshev" >> написал: >> >> Добрый день! >> Понимаю, что вопрос странный, но тем не менее… >> >> Есть proxy-pass, который иногда возвращает код ответа >600. >> Возможно ли передать полученное тело ответа клиенту с http-code=200? >> >> PS: При попытке переписать код через error_page nginx вполне валидно >> ругается на http-code выше 599. >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- best reguards Paul Sin ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sejo412 на gmail.com Sat Jun 11 17:55:48 2016 From: sejo412 на gmail.com (Paul Sin) Date: Sat, 11 Jun 2016 20:55:48 +0300 Subject: =?UTF-8?B?UmU6INCh0L7Qv9C+0YHRgtCw0LLQu9C10L3QuNC1ICRxdWVyeV9zdHJpbmcg0YE=?= =?UTF-8?B?0L4g0YHRgtGA0L7QutC+0Lkg0YHQvtC00LXRgNC20LDRidC10LkgIiQi?= In-Reply-To: <1127021463435343@web29m.yandex.ru> References: <3468051463352432@web26g.yandex.ru> <1579652.XXvDYMCNEz@cybernote> <321951463399172@web14h.yandex.ru> <5905225.MMWHYz8ha5@cybernote> <128681463410488@web3j.yandex.ru> <1127021463435343@web29m.yandex.ru> Message-ID: >> судя по документации map можно применять только в контексте http, а хотелось бы в контексте server, а лучше location непонятна ваша боль. значения переменных вычисляются в момент доступа к ним. к этим переменным можно обратиться и на уровне сервера и на уровне локейшена. 17 мая 2016 г., 0:49 пользователь Sergey V. Sokolov написал: > Суть с map понятна, спасибо за ликбез, хорошая конструкция. Есть один > ньюанс, судя по документации map можно применять только в контексте http, а > хотелось бы в контексте server, а лучше location :( > > 16.05.2016, 17:57, "Sergey V. Sokolov" : > > Мне НЕ нужна проверка по отдельным переменным $query_string, нужно > проверка сопоставления со всей строкой $query_string. > > 16.05.2016, 15:20, "Иван" : > > Вы хотите анализировать именно $query_string или конкретные переменные из > нее? > > > > Для приведенного Вами примера с p= работает моя конструкция. Если надо > сравнивать p с несколькими подстроками, то будет > > > > map $arg_p $block { > > 'anyqwery$' 1; > > 'otherqwery' 1; > > 'some$otherqwery' 1; > > } > > > > if ($block) { > > return 403; > > } > > > > Если таких p не одна, а, например, есть еще q, то будет как-то так > > > > map $arg_p $pblock { > > default 0; > > 'anyqwery$' 1; > > 'otherqwery' 1; > > 'some$otherqwery' 1; > > } > > map $arg_q $qblock { > > default 0; > > '2qwery$' 1; > > 'newotherqwery' 1; > > '3some$otherqwery$' 1; > > } > > > > map $pblock$qblock $block { > > default 1; > > 00 0; > > } > > > > if ($block) { > > return 403; > > } > > > > Если же переменных p,q много, то можно сделать регэкспом по всей > $query_string: > > > > map $query_string $block { > > default 0; > > ~'p=anyqwery$' 1; #если $query_string содержит "p=anyqwery$" или > "zap=anyqwery$otherqwery", будет отлуп > > ~'otherqwery' 1; > > ~'$$$' 1; > > } > > > > if ($block) { > > return 403; > > } > > > > Прочитайте документацию на map: http://nginx.org/r/map/ru. > > > > В письме от 16 мая 2016 14:46:12 пользователь Sergey V. Sokolov написал: > > > Мне нужно для одного из location заблокировать порядка 10-20 > query_string, а > > > остальные пропустить. Так вот, query_string может содержать символ $ и > > > нужно это учесть. > > > 16.05.2016, 14:07, "Иван" : > > > Мне кажется, что нет, не правильно понимаете. Опишите конкретнее, что > хотите > > > получить, пожалуйста. > > > > > > В письме от 16 мая 2016 14:05:52 пользователь Sergey V. Sokolov написал: > > > > Я правильно понимаю, что на каждую такую операцию сравнения, будет две > > > > директивы в конфиге map и if? Получается в две операции. Короче можно? > > > > 16.05.2016, 02:57, "Иван" : > > > > > > > > В письме от 16 мая 2016 01:47:12 пользователь Sergey V. Sokolov > написал: > > > > > $query_string > > > > > > > > > > > > Здравствуйте! > > > > > > > > Наиболее правильно > > > > map $arg_p $block { > > > > 'anyqwery$' 1; > > > > } > > > > > > > > if ($block) { > > > > return 403; > > > > } > > > > > > > > С уважением, Иван. > > > > , > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru на nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > > > > > > > -- > > > > С уважением, Сергей Соколов > > > > Заместитель директора > > > > Zavolga.Net (ООО "Горизонт"), г. Ярославль > > > > Тел.: +7 4852 333-402 > > > > Сайт: http://zavolga.net > > > > > > > > Руководитель проекта > > > > Региональный Интернет Дневник > > > > Сайт: http://dnevnik76.ru > > > > > > > > Руководитель проекта > > > > Ярославский Internet Exchange (YAR-IX) > > > > Сайт: http://yar-ix.net > > > > > > > > nic-hdl: SVS141-RIPE > > > > X-NCC-RegID: ru.gorizont > > > > > > > > > > > > > , > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru на nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > > > -- > > > С уважением, Сергей Соколов > > > Заместитель директора > > > Zavolga.Net (ООО "Горизонт"), г. Ярославль > > > Тел.: +7 4852 333-402 > > > Сайт: http://zavolga.net > > > > > > Руководитель проекта > > > Региональный Интернет Дневник > > > Сайт: http://dnevnik76.ru > > > > > > Руководитель проекта > > > Ярославский Internet Exchange (YAR-IX) > > > Сайт: http://yar-ix.net > > > > > > nic-hdl: SVS141-RIPE > > > X-NCC-RegID: ru.gorizont > > > > > > , > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > С уважением, Сергей Соколов > Заместитель директора > Zavolga.Net (ООО "Горизонт"), г. Ярославль > Тел.: +7 4852 333-402 > Сайт: http://zavolga.net > > Руководитель проекта > Региональный Интернет Дневник > Сайт: http://dnevnik76.ru > > Руководитель проекта > Ярославский Internet Exchange (YAR-IX) > Сайт: http://yar-ix.net > > nic-hdl: SVS141-RIPE > X-NCC-RegID: ru.gorizont > > , > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > С уважением, Сергей Соколов > Заместитель директора > Zavolga.Net (ООО "Горизонт"), г. Ярославль > Тел.: +7 4852 333-402 > Сайт: http://zavolga.net > > Руководитель проекта > Региональный Интернет Дневник > Сайт: http://dnevnik76.ru > > Руководитель проекта > Ярославский Internet Exchange (YAR-IX) > Сайт: http://yar-ix.net > > nic-hdl: SVS141-RIPE > X-NCC-RegID: ru.gorizont > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- best reguards Paul Sin ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From skobolo на gmail.com Sat Jun 11 18:14:19 2016 From: skobolo на gmail.com (Stepan Karamyshev) Date: Sat, 11 Jun 2016 21:14:19 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9GA0LXRiNC10L3QvdGL0Lkg0LTQuNCw0L/QsNC30L7QvSBodHRw?= =?UTF-8?B?LdC+0YLQstC10YLQvtCyICjQuNC70LggItCy0YHQtdCz0LTQsCAyMDAiKQ==?= In-Reply-To: References: Message-ID: В итоге, решение на nginx не найдено , в рамках решения задачи подставлены костыли. > 11 июня 2016 г., в 20:28, Paul Sin написал(а): > > эта музыка будет вечна, пока не все придерживаются rfc > Fielding, et al. Standards Track [Page 39] > > RFC 2616 HTTP/1.1 June 1999 > > > The first digit of the Status-Code defines the class of response. The > last two digits do not have any categorization role. There are 5 > values for the first digit: > > - 1xx: Informational - Request received, continuing process > > - 2xx: Success - The action was successfully received, > understood, and accepted > > - 3xx: Redirection - Further action must be taken in order to > complete the request > > - 4xx: Client Error - The request contains bad syntax or cannot > be fulfilled > > - 5xx: Server Error - The server failed to fulfill an apparently > valid request > Таки как решили вопрос в итоге? > > 2 июня 2016 г., 19:33 пользователь SK > написал: > if ок, но что в then? > Return прекращает обработку запроса :-( > > 2 июня 2016 г., в 19:25, Yuriy Medvedev > написал(а): > >> if ($status = "600") но if зло >> >> 2 июня 2016 г. 19:08 пользователь "SK" > написал: >> error_page 600 -- невалиден по стандарту и не проходит проверку конфига. >> >> 2 июня 2016 г., в 18:56, Yuriy Medvedev > написал(а): >> >>> В документации есть пример >>> http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page >>> 2 июня 2016 г. 18:49 пользователь "Stepan Karamyshev" > написал: >>> Добрый день! >>> Понимаю, что вопрос странный, но тем не менее… >>> >>> Есть proxy-pass, который иногда возвращает код ответа >600. >>> Возможно ли передать полученное тело ответа клиенту с http-code=200? >>> >>> PS: При попытке переписать код через error_page nginx вполне валидно ругается на http-code выше 599. >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > > best reguards > Paul Sin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Jun 14 11:04:50 2016 From: nginx-forum на forum.nginx.org (izlom) Date: Tue, 14 Jun 2016 07:04:50 -0400 Subject: =?UTF-8?B?0JjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LUgUGVybCDQstC80LXRgdGC0LUg0YEg?= =?UTF-8?B?cHJveHk=?= Message-ID: <6bed715c852a90d087fa80751a979226.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Имею два location - корневой и тест. В обоих указан перл но в корневом еще и бекенд. Проблема в том, что перл работает только при запросе GET /test, а при запросе GET / перл не обрабатывается. location / { perl hello::test; proxy_pass http://$backend; } location /test { perl hello::test; } Как вызывать perl приоритетнее proxy? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267557,267557#msg-267557 From onokonem на gmail.com Tue Jun 14 12:43:57 2016 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 14 Jun 2016 15:43:57 +0300 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1IFBlcmwg0LLQvNC10YHRgtC1?= =?UTF-8?B?INGBIHByb3h5?= In-Reply-To: <6bed715c852a90d087fa80751a979226.NginxMailingListRussian@forum.nginx.org> References: <6bed715c852a90d087fa80751a979226.NginxMailingListRussian@forum.nginx.org> Message-ID: > Как вызывать perl приоритетнее proxy? закомментировать proxy? вы чего хотите-то вообще? From mdounin на mdounin.ru Tue Jun 14 13:17:03 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 14 Jun 2016 16:17:03 +0300 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1IFBlcmwg0LLQvNC10YHRgtC1?= =?UTF-8?B?INGBIHByb3h5?= In-Reply-To: <6bed715c852a90d087fa80751a979226.NginxMailingListRussian@forum.nginx.org> References: <6bed715c852a90d087fa80751a979226.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160614131702.GB36620@mdounin.ru> Hello! On Tue, Jun 14, 2016 at 07:04:50AM -0400, izlom wrote: > Здравствуйте! > > Имею два location - корневой и тест. В обоих указан перл но в корневом еще > и бекенд. Проблема в том, что перл работает только при запросе GET /test, а > при запросе GET / перл не обрабатывается. > > > location / { > perl hello::test; > proxy_pass http://$backend; > } > > > location /test { > perl hello::test; > } > > Как вызывать perl приоритетнее proxy? Безусловный обработчик может быть только один. Если указано больше одного, как в случае "location /" выше, будет работать тот, который указан последним, т.к. просто переустановит обработку на себя. Если вы хотите, чтобы отрабатывал код на Perl, а потом по каким-то условиям срабатывало проксирование - стоит подумать об альтернативных враиантах записи того, что вы хотите сделать: - использовать perl_set и строить дальнейшую обработку в зависимости от результата вычисления переменной; - при необходимости в коде на Perl делать перенаправление с помощью $r->internal_redirect(). Подробнее в документации тут: http://nginx.org/ru/docs/http/ngx_http_perl_module.html#perl_set http://nginx.org/ru/docs/http/ngx_http_perl_module.html#methods -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Tue Jun 14 13:48:21 2016 From: nginx-forum на forum.nginx.org (yvgorshkov) Date: Tue, 14 Jun 2016 09:48:21 -0400 Subject: =?UTF-8?B?0JTQvtC/0LjRgdGL0LLQsNGC0YwgR0VULdC/0LDRgNCw0LzQtdGC0YA=?= Message-ID: Здарвствуйте! Дано: nginx, php5-fpm Как составить конфигурацию nginx, чтобы при запросах site.ru/ru/, site.ru/en/ дописывать к запросу GET-параметр site.ru/?lang=ru, site.ru/?lang=en... site.ru/another.php?lang=en... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267566,267566#msg-267566 From sejo412 на gmail.com Tue Jun 14 18:42:59 2016 From: sejo412 на gmail.com (Paul Sin) Date: Tue, 14 Jun 2016 21:42:59 +0300 Subject: =?UTF-8?B?UmU6INCU0L7Qv9C40YHRi9Cy0LDRgtGMIEdFVC3Qv9Cw0YDQsNC80LXRgtGA?= In-Reply-To: References: Message-ID: если я правильно понял условие, то примерно так: rewirite ^/(en|ru)/$ /?lang=$1? last; http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#rewrite Вот это что имеется ввиду: "... site.ru/another.php?lang=en..."? 14 июня 2016 г., 16:48 пользователь yvgorshkov написал: > Здарвствуйте! > Дано: nginx, php5-fpm > Как составить конфигурацию nginx, чтобы при запросах site.ru/ru/, > site.ru/en/ дописывать к запросу GET-параметр site.ru/?lang=ru, > site.ru/?lang=en... site.ru/another.php?lang=en... > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267566,267566#msg-267566 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- best reguards Paul Sin ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Jun 15 07:21:54 2016 From: nginx-forum на forum.nginx.org (izlom) Date: Wed, 15 Jun 2016 03:21:54 -0400 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1IFBlcmwg0LLQvNC10YHRgtC1?= =?UTF-8?B?INGBIHByb3h5?= In-Reply-To: <20160614131702.GB36620@mdounin.ru> References: <20160614131702.GB36620@mdounin.ru> Message-ID: <3b319be6ead01978f460b573ebd60315.NginxMailingListRussian@forum.nginx.org> >> - при необходимости в коде на Perl делать перенаправление с помощью $r->internal_redirect(). Вот за эту подсказку большое спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267557,267586#msg-267586 From nginx-forum на forum.nginx.org Thu Jun 16 09:14:47 2016 From: nginx-forum на forum.nginx.org (ingtar) Date: Thu, 16 Jun 2016 05:14:47 -0400 Subject: =?UTF-8?Q?try_files_=D0=B8_2_rewrite?= Message-ID: Доброго дня! Возник вопрос, возможно ли воплотить такую схему работы: Есть локейшен, с которого отдаются файлы после rewrite. Файлы могут быть в двух разных папках на сервере, нужно отдать со второй папки, если в первой 404. Вроде эту магию может сделать try_files. Нашлась статья про каскадные проверки, но выглядит чуть монструозно http://linuxplayer.org/2013/06/nginx-try-files-on-multiple-named-location-or-server Возможно ли делать например такую штуку с одним правилом rewrite в основном локейшене и если 404 - то идем в other_location: location /images/ { root /var/local/images/ rewrite '^/avatar/256x256/([0-9]*)(\d{2})(\d{2})(\d{2})\.(jpg|png)' /avatars/$4/$3/$2/$1$2$3$4_256x256.$5 break; try_files $uri @other_location; } location @other_location { root /var/local/images/ rewrite '^/avatar/256x256/([0-9]*)(\d{2})(\d{2})(\d{2})\.(jpg|png)' /avatars/new_avatar/$4/$3/$2/$1$2$3$4_256x256.$5 break; } Или в other_location следует делать rewrite уже измененного uri в первом локейшене? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267623,267623#msg-267623 From voron на amhost.net Thu Jun 16 10:37:52 2016 From: voron на amhost.net (Alex Vorona) Date: Thu, 16 Jun 2016 13:37:52 +0300 Subject: =?UTF-8?Q?Re=3A_try_files_=D0=B8_2_rewrite?= In-Reply-To: References: Message-ID: 16.06.16 12:14, ingtar пишет: > Доброго дня! > Возник вопрос, возможно ли воплотить такую схему работы: > Есть локейшен, с которого отдаются файлы после rewrite. > Файлы могут быть в двух разных папках на сервере, нужно отдать со второй > папки, если в первой 404. > Вроде эту магию может сделать try_files. > Нашлась статья про каскадные проверки, но выглядит чуть монструозно > http://linuxplayer.org/2013/06/nginx-try-files-on-multiple-named-location-or-server > > Возможно ли делать например такую штуку с одним правилом rewrite в основном > локейшене и если 404 - то идем в other_location: [...] А вариант с одним regexp location с [named] captures и try_files с 2-мя нужными параметрами и без rewrite вы пробовали? From simplebox66 на gmail.com Thu Jun 16 12:05:01 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Thu, 16 Jun 2016 15:05:01 +0300 Subject: =?UTF-8?B?0L3QtdC60L7RgtC+0YDRi9C1INC30LDQv9GA0L7RgdGLINC00LXRgNC20LDRgiA=?= =?UTF-8?B?0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH0L0=?= =?UTF-8?B?0L7RgdGC0Lg=?= Message-ID: Всем привет. Коллеги есть проблема которую сам пока разгадать не могу. Прошу помощи. Есть nginx, за ним httpd. Делаю wget или curl на www.example.com/test/request (за этим урлом стоит php процесс) Обычно все обрабатывается нормально, но в некоторых случаях curl и wget повисают, после долгой паузы получаю Запрос HTTP послан, ожидается ответ... Ошибка чтения (Время ожидания > соединения истекло) в заголовках. > Повтор. После чего происходит автоматически новая попытка. Соединение постоянно открыто. Может так висеть днями. strace nginx процесса на котором весит соединение выдает > --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL, si_value={int=0, > ptr=0x100000000}} --- > rt_sigreturn() = -1 EINTR (Interrupted system > call) > epoll_wait(36, 27293b0, 512, 500) = -1 EINTR (Interrupted system > call) strace wget показывает > select(4, [3], NULL, NULL, {275, 67022} Помогите разобраться кто виноват в этой связке. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Thu Jun 16 12:15:41 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 16 Jun 2016 15:15:41 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: References: Message-ID: <20160616121541.GH8895@protva.ru> On Thu, Jun 16, 2016 at 03:05:01PM +0300, Иван Мишин wrote: > Запрос HTTP послан, ожидается ответ... Ошибка чтения (Время ожидания > > соединения истекло) в заголовках. > > Повтор. > > После чего происходит автоматически новая попытка. Соединение постоянно > открыто. Может так висеть днями. ... > strace nginx процесса на котором весит соединение выдает > > > --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL, si_value={int=0, > > ptr=0x100000000}} --- > > rt_sigreturn() = -1 EINTR (Interrupted system > > call) > > epoll_wait(36, 27293b0, 512, 500) = -1 EINTR (Interrupted system > > call) А в логе что? > strace wget показывает > > > select(4, [3], NULL, NULL, {275, 67022} > > > Помогите разобраться кто виноват в этой связке. Сравните дампы трафика на стороне клиента и на стороне сервера. -- Eugene Berdnikov From chipitsine на gmail.com Thu Jun 16 12:32:56 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 16 Jun 2016 17:32:56 +0500 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: References: Message-ID: а между nginx и httpd фаирвол ? 16 июня 2016 г., 17:05 пользователь Иван Мишин написал: > Всем привет. > Коллеги есть проблема которую сам пока разгадать не могу. Прошу помощи. > Есть nginx, за ним httpd. > > Делаю wget или curl на www.example.com/test/request (за этим урлом стоит > php процесс) > Обычно все обрабатывается нормально, но в некоторых случаях curl и wget > повисают, после долгой паузы получаю > > Запрос HTTP послан, ожидается ответ... Ошибка чтения (Время ожидания >> соединения истекло) в заголовках. >> Повтор. > > После чего происходит автоматически новая попытка. Соединение постоянно > открыто. Может так висеть днями. > > strace nginx процесса на котором весит соединение выдает > >> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL, si_value={int=0, >> ptr=0x100000000}} --- >> rt_sigreturn() = -1 EINTR (Interrupted system >> call) >> epoll_wait(36, 27293b0, 512, 500) = -1 EINTR (Interrupted system >> call) > > > strace wget показывает > >> select(4, [3], NULL, NULL, {275, 67022} > > > Помогите разобраться кто виноват в этой связке. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From simplebox66 на gmail.com Thu Jun 16 13:10:05 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Thu, 16 Jun 2016 16:10:05 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: References: Message-ID: Нет, файрвола нет. nginx и httpd крутятся на одном сервере. 16 июня 2016 г., 15:32 пользователь Илья Шипицин написал: > а между nginx и httpd фаирвол ? > > 16 июня 2016 г., 17:05 пользователь Иван Мишин > написал: > >> Всем привет. >> Коллеги есть проблема которую сам пока разгадать не могу. Прошу помощи. >> Есть nginx, за ним httpd. >> >> Делаю wget или curl на www.example.com/test/request (за этим урлом стоит >> php процесс) >> Обычно все обрабатывается нормально, но в некоторых случаях curl и wget >> повисают, после долгой паузы получаю >> >> Запрос HTTP послан, ожидается ответ... Ошибка чтения (Время ожидания >>> соединения истекло) в заголовках. >>> Повтор. >> >> После чего происходит автоматически новая попытка. Соединение постоянно >> открыто. Может так висеть днями. >> >> strace nginx процесса на котором весит соединение выдает >> >>> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL, si_value={int=0, >>> ptr=0x100000000}} --- >>> rt_sigreturn() = -1 EINTR (Interrupted system >>> call) >>> epoll_wait(36, 27293b0, 512, 500) = -1 EINTR (Interrupted system >>> call) >> >> >> strace wget показывает >> >>> select(4, [3], NULL, NULL, {275, 67022} >> >> >> Помогите разобраться кто виноват в этой связке. >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From leave на nixkid.com Thu Jun 16 13:32:37 2016 From: leave на nixkid.com (Pavel Mihaduk) Date: Thu, 16 Jun 2016 16:32:37 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: References: Message-ID: <1C15DA41-A15F-4A8B-8BC8-5DBC1E22A3C3@nixkid.com> Готово. Только на wgshop почему-то 504 :) > On 16 июня 2016 г., at 16:10, Иван Мишин wrote: > > Нет, файрвола нет. nginx и httpd крутятся на одном сервере. > > 16 июня 2016 г., 15:32 пользователь Илья Шипицин > написал: > а между nginx и httpd фаирвол ? > > 16 июня 2016 г., 17:05 пользователь Иван Мишин > написал: > Всем привет. > Коллеги есть проблема которую сам пока разгадать не могу. Прошу помощи. > Есть nginx, за ним httpd. > > Делаю wget или curl на www.example.com/test/request (за этим урлом стоит php процесс) > Обычно все обрабатывается нормально, но в некоторых случаях curl и wget повисают, после долгой паузы получаю > > Запрос HTTP послан, ожидается ответ... Ошибка чтения (Время ожидания соединения истекло) в заголовках. > Повтор. > После чего происходит автоматически новая попытка. Соединение постоянно открыто. Может так висеть днями. > > strace nginx процесса на котором весит соединение выдает > --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL, si_value={int=0, ptr=0x100000000}} --- > rt_sigreturn() = -1 EINTR (Interrupted system call) > epoll_wait(36, 27293b0, 512, 500) = -1 EINTR (Interrupted system call) > > strace wget показывает > select(4, [3], NULL, NULL, {275, 67022} > > Помогите разобраться кто виноват в этой связке. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From leave на nixkid.com Thu Jun 16 13:39:59 2016 From: leave на nixkid.com (Pavel Mihaduk) Date: Thu, 16 Jun 2016 16:39:59 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: <1C15DA41-A15F-4A8B-8BC8-5DBC1E22A3C3@nixkid.com> References: <1C15DA41-A15F-4A8B-8BC8-5DBC1E22A3C3@nixkid.com> Message-ID: <5ECE6D08-4136-4126-B221-88F45B1A394B@nixkid.com> Ой, прошу прощения, перепутал ящики > On 16 июня 2016 г., at 16:32, Pavel Mihaduk wrote: > > Готово. Только на wgshop почему-то 504 :) > >> On 16 июня 2016 г., at 16:10, Иван Мишин > wrote: >> >> Нет, файрвола нет. nginx и httpd крутятся на одном сервере. >> >> 16 июня 2016 г., 15:32 пользователь Илья Шипицин > написал: >> а между nginx и httpd фаирвол ? >> >> 16 июня 2016 г., 17:05 пользователь Иван Мишин > написал: >> Всем привет. >> Коллеги есть проблема которую сам пока разгадать не могу. Прошу помощи. >> Есть nginx, за ним httpd. >> >> Делаю wget или curl на www.example.com/test/request (за этим урлом стоит php процесс) >> Обычно все обрабатывается нормально, но в некоторых случаях curl и wget повисают, после долгой паузы получаю >> >> Запрос HTTP послан, ожидается ответ... Ошибка чтения (Время ожидания соединения истекло) в заголовках. >> Повтор. >> После чего происходит автоматически новая попытка. Соединение постоянно открыто. Может так висеть днями. >> >> strace nginx процесса на котором весит соединение выдает >> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL, si_value={int=0, ptr=0x100000000}} --- >> rt_sigreturn() = -1 EINTR (Interrupted system call) >> epoll_wait(36, 27293b0, 512, 500) = -1 EINTR (Interrupted system call) >> >> strace wget показывает >> select(4, [3], NULL, NULL, {275, 67022} >> >> Помогите разобраться кто виноват в этой связке. >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu Jun 16 13:49:42 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 16 Jun 2016 18:49:42 +0500 Subject: =?UTF-8?B?0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUg0L3QsCBodHRwcw==?= Message-ID: Привет! есть сервер на win2012r2, он настроен с поддержкой SNI. он может принять соединение на https://computer.domain, но категорически отказывается принимать соединения на https://ip-адрес я убился уже, не могу заставить при проксировании передавать имя. оно ресолвится и в результате 2016/06/16 18:44:22 [error] 55328#0: *703668639 peer closed connection in SSL handshake (54: Connection reset by peer) while SSL handshaking to upstream, client: 46.17.201.71, server: XXX, request: "GET /adfs/portal/updatepassword HTTP/2.0", upstream: " https://X.X.X.X:443/adfs/portal/updatepassword", host: "XXX" можно как-то сделать, чтобы апстрим не ресолвился? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Thu Jun 16 13:56:56 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 16 Jun 2016 16:56:56 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC90LAgaHR0cHM=?= In-Reply-To: References: Message-ID: <2255655.JTAFCIIVUt@vbart-workstation> On Thursday 16 June 2016 18:49:42 Илья Шипицин wrote: > Привет! > > есть сервер на win2012r2, он настроен с поддержкой SNI. > он может принять соединение на https://computer.domain, но категорически > отказывается принимать соединения на https://ip-адрес > > > я убился уже, не могу заставить при проксировании передавать имя. оно > ресолвится и в результате Есть такая директива: http://nginx.org/r/proxy_ssl_server_name/ru По умолчанию nginx не использует SNI в соединениях с апстримом, и ничего не передает. -- Валентин Бартенев From chipitsine на gmail.com Thu Jun 16 14:00:47 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 16 Jun 2016 19:00:47 +0500 Subject: =?UTF-8?B?UmU6INC/0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC90LAgaHR0cHM=?= In-Reply-To: <2255655.JTAFCIIVUt@vbart-workstation> References: <2255655.JTAFCIIVUt@vbart-workstation> Message-ID: да, только что нашел эту директиву. а почему она по дефолту off ? кажется, что с "on" она меньше поломает 16 июня 2016 г., 18:56 пользователь Валентин Бартенев написал: > On Thursday 16 June 2016 18:49:42 Илья Шипицин wrote: > > Привет! > > > > есть сервер на win2012r2, он настроен с поддержкой SNI. > > он может принять соединение на https://computer.domain, но категорически > > отказывается принимать соединения на https://ip-адрес > > > > > > > я убился уже, не могу заставить при проксировании передавать имя. оно > > ресолвится и в результате > > Есть такая директива: > http://nginx.org/r/proxy_ssl_server_name/ru > > По умолчанию nginx не использует SNI в соединениях с апстримом, > и ничего не передает. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Jun 16 14:01:51 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 16 Jun 2016 17:01:51 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC90LAgaHR0cHM=?= In-Reply-To: References: Message-ID: <20160616140151.GS36620@mdounin.ru> Hello! On Thu, Jun 16, 2016 at 06:49:42PM +0500, Илья Шипицин wrote: > Привет! > > есть сервер на win2012r2, он настроен с поддержкой SNI. > он может принять соединение на https://computer.domain, но категорически > отказывается принимать соединения на https://ip-адрес > > > я убился уже, не могу заставить при проксировании передавать имя. оно > ресолвится и в результате > > 2016/06/16 18:44:22 [error] 55328#0: *703668639 peer closed connection in > SSL handshake (54: Connection reset by peer) while SSL handshaking to > upstream, client: 46.17.201.71, server: XXX, request: "GET > /adfs/portal/updatepassword HTTP/2.0", upstream: " > https://X.X.X.X:443/adfs/portal/updatepassword", host: "XXX" > > > можно как-то сделать, чтобы апстрим не ресолвился? Если нужно, чтобы при соединении к бекенду nginx использовал Server Name Indication, aka SNI - надо включить proxy_ssl_server_name. Имя берётся из proxy_pass, если нужно нестандартное - можно задать с помощью диреткивы proxy_ssl_name. Соответственно если нужно, чтобы nginx всегда шёл к заданному ip-адресу, но при этом указывал имя "computer.domain", есть два варианта: - Определить upstream computer.domain с нужным IP-адресом, как-то так: upstream computer.domain { server 10.0.0.2:443; } proxy_pass https://computer.domain; proxy_ssl_server_name on; - Написать IP-адрес явно в proxy_pass, и переопределить имя где надо: proxy_pass https://10.0.0.2; proxy_ssl_server_name on; proxy_ssl_name computer.domain; proxy_set_header Host computer.domain; -- Maxim Dounin http://nginx.org/ From chipitsine на gmail.com Thu Jun 16 14:07:23 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 16 Jun 2016 19:07:23 +0500 Subject: =?UTF-8?B?UmU6INC/0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC90LAgaHR0cHM=?= In-Reply-To: <20160616140151.GS36620@mdounin.ru> References: <20160616140151.GS36620@mdounin.ru> Message-ID: у proxy_ssl_name очень хорошее значение по умолчанию. не совсем понятно, чем плохо "proxy_pass https://computer.domain" по идее, все нужные параметры тут уже есть, в чем логика, чтобы еще раз их описать? 16 июня 2016 г., 19:01 пользователь Maxim Dounin написал: > Hello! > > On Thu, Jun 16, 2016 at 06:49:42PM +0500, Илья Шипицин wrote: > > > Привет! > > > > есть сервер на win2012r2, он настроен с поддержкой SNI. > > он может принять соединение на https://computer.domain, но категорически > > отказывается принимать соединения на https://ip-адрес > > > > > > > я убился уже, не могу заставить при проксировании передавать имя. оно > > ресолвится и в результате > > > > 2016/06/16 18:44:22 [error] 55328#0: *703668639 peer closed connection in > > SSL handshake (54: Connection reset by peer) while SSL handshaking to > > upstream, client: 46.17.201.71, server: XXX, request: "GET > > /adfs/portal/updatepassword HTTP/2.0", upstream: " > > https://X.X.X.X:443/adfs/portal/updatepassword", host: "XXX" > > > > > > можно как-то сделать, чтобы апстрим не ресолвился? > > Если нужно, чтобы при соединении к бекенду nginx использовал > Server Name Indication, aka SNI - надо включить > proxy_ssl_server_name. Имя берётся из proxy_pass, если нужно > нестандартное - можно задать с помощью диреткивы proxy_ssl_name. > > Соответственно если нужно, чтобы nginx всегда шёл к заданному > ip-адресу, но при этом указывал имя "computer.domain", есть два > варианта: > > - Определить upstream computer.domain с нужным IP-адресом, как-то > так: > > upstream computer.domain { > server 10.0.0.2:443; > } > > proxy_pass https://computer.domain; > proxy_ssl_server_name on; > > - Написать IP-адрес явно в proxy_pass, и переопределить имя где > надо: > > proxy_pass https://10.0.0.2; > proxy_ssl_server_name on; > proxy_ssl_name computer.domain; > proxy_set_header Host computer.domain; > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Thu Jun 16 14:07:59 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 16 Jun 2016 17:07:59 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC90LAgaHR0cHM=?= In-Reply-To: References: <2255655.JTAFCIIVUt@vbart-workstation> Message-ID: <2080213.NqN4vmrlm2@vbart-workstation> On Thursday 16 June 2016 19:00:47 Илья Шипицин wrote: > да, только что нашел эту директиву. > а почему она по дефолту off ? > > кажется, что с "on" она меньше поломает > [..] До версии 1.7.0 поддержки SNI на бекенды не было вовсе и её включение может поломать некоторые конфигурации. Также оно плохо дружит с keepalive. -- Валентин Бартенев From mdounin на mdounin.ru Thu Jun 16 14:13:39 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 16 Jun 2016 17:13:39 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC90LAgaHR0cHM=?= In-Reply-To: References: <20160616140151.GS36620@mdounin.ru> Message-ID: <20160616141339.GT36620@mdounin.ru> Hello! On Thu, Jun 16, 2016 at 07:07:23PM +0500, Илья Шипицин wrote: > у proxy_ssl_name очень хорошее значение по умолчанию. > > не совсем понятно, чем плохо "proxy_pass https://computer.domain" > по идее, все нужные параметры тут уже есть, в чем логика, чтобы еще раз их > описать? Я понял вопрос так, что хочется использовать IP-адрес вместо имени в proxy_pass, чтобы не зависеть от DNS, и от этого возникают проблемы. Если использование имени в конфиге устраивает - ничего дополнительно описывать не нужно, достаточно включить proxy_ssl_server_name. -- Maxim Dounin http://nginx.org/ From simplebox66 на gmail.com Fri Jun 17 07:48:00 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 17 Jun 2016 10:48:00 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: <5ECE6D08-4136-4126-B221-88F45B1A394B@nixkid.com> References: <1C15DA41-A15F-4A8B-8BC8-5DBC1E22A3C3@nixkid.com> <5ECE6D08-4136-4126-B221-88F45B1A394B@nixkid.com> Message-ID: > > А в логе что? В логе пусто. По окончанию "виселицы" появлейтся лог запроса с 500 ответом > Сравните дампы трафика на стороне клиента и на стороне сервера. Аномалий на первый взгляд не заметил 16 июня 2016 г., 16:39 пользователь Pavel Mihaduk написал: > Ой, прошу прощения, перепутал ящики > > On 16 июня 2016 г., at 16:32, Pavel Mihaduk wrote: > > Готово. Только на wgshop почему-то 504 :) > > On 16 июня 2016 г., at 16:10, Иван Мишин wrote: > > Нет, файрвола нет. nginx и httpd крутятся на одном сервере. > > 16 июня 2016 г., 15:32 пользователь Илья Шипицин > написал: > >> а между nginx и httpd фаирвол ? >> >> 16 июня 2016 г., 17:05 пользователь Иван Мишин >> написал: >> >>> Всем привет. >>> Коллеги есть проблема которую сам пока разгадать не могу. Прошу помощи. >>> Есть nginx, за ним httpd. >>> >>> Делаю wget или curl на www.example.com/test/request (за этим урлом >>> стоит php процесс) >>> Обычно все обрабатывается нормально, но в некоторых случаях curl и wget >>> повисают, после долгой паузы получаю >>> >>> Запрос HTTP послан, ожидается ответ... Ошибка чтения (Время ожидания >>>> соединения истекло) в заголовках. >>>> Повтор. >>> >>> После чего происходит автоматически новая попытка. Соединение постоянно >>> открыто. Может так висеть днями. >>> >>> strace nginx процесса на котором весит соединение выдает >>> >>>> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL, si_value={int=0, >>>> ptr=0x100000000}} --- >>>> rt_sigreturn() = -1 EINTR (Interrupted system >>>> call) >>>> epoll_wait(36, 27293b0, 512, 500) = -1 EINTR (Interrupted system >>>> call) >>> >>> >>> strace wget показывает >>> >>>> select(4, [3], NULL, NULL, {275, 67022} >>> >>> >>> Помогите разобраться кто виноват в этой связке. >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Fri Jun 17 08:08:20 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 17 Jun 2016 11:08:20 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: References: <1C15DA41-A15F-4A8B-8BC8-5DBC1E22A3C3@nixkid.com> <5ECE6D08-4136-4126-B221-88F45B1A394B@nixkid.com> Message-ID: <20160617080820.GI8895@protva.ru> On Fri, Jun 17, 2016 at 10:48:00AM +0300, Иван Мишин wrote: > > > > А в логе что? > > В логе пусто. По окончанию "виселицы" появлейтся лог запроса с 500 ответом То есть запросов к серверу нет? С кем же клиент тогда устанавливает соединения в цикле, перед тем как сообщает "Запрос HTTP послан, ожидается ответ"? > > Сравните дампы трафика на стороне клиента и на стороне сервера. > > Аномалий на первый взгляд не заметил Как можно "не заметить аномалий", если клиент не получает ответ? :) Вы не заметили, что пакеты не доходят от клиента к серверу, или что пакеты от сервера к клиенту пропадают? Отчего происходит таймаут? -- Eugene Berdnikov From simplebox66 на gmail.com Fri Jun 17 08:26:03 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 17 Jun 2016 11:26:03 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: <20160617080820.GI8895@protva.ru> References: <1C15DA41-A15F-4A8B-8BC8-5DBC1E22A3C3@nixkid.com> <5ECE6D08-4136-4126-B221-88F45B1A394B@nixkid.com> <20160617080820.GI8895@protva.ru> Message-ID: > > То есть запросов к серверу нет? С кем же клиент тогда устанавливает > соединения в цикле, перед тем как сообщает "Запрос HTTP послан, > ожидается ответ"? Я же написал, что по завершению висяка появляется 500 ответ в логе. Nginx то логирует уже после обработки запроса, вот и нет ничего в логах в момент зависания, после того как зависание проходит в лог идет запись. Из того что я заметил пакеты не пропадают. клиент отправил запрос , сервер его получил. а дальше тишина.... затем через время клиент делает вторую попытку , сервер опять отправляет и тишина, после нескольких попыток, сервер отвечает кодом 500 клиент это принимает и отваливается. 17 июня 2016 г., 11:08 пользователь Evgeniy Berdnikov написал: > On Fri, Jun 17, 2016 at 10:48:00AM +0300, Иван Мишин wrote: > > > > > > А в логе что? > > > > В логе пусто. По окончанию "виселицы" появлейтся лог запроса с 500 > ответом > > То есть запросов к серверу нет? С кем же клиент тогда устанавливает > соединения в цикле, перед тем как сообщает "Запрос HTTP послан, > ожидается ответ"? > > > > Сравните дампы трафика на стороне клиента и на стороне сервера. > > > > Аномалий на первый взгляд не заметил > > Как можно "не заметить аномалий", если клиент не получает ответ? :) > > Вы не заметили, что пакеты не доходят от клиента к серверу, или что > пакеты от сервера к клиенту пропадают? Отчего происходит таймаут? > -- > Eugene Berdnikov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Fri Jun 17 08:47:18 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 17 Jun 2016 11:47:18 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: References: <1C15DA41-A15F-4A8B-8BC8-5DBC1E22A3C3@nixkid.com> <5ECE6D08-4136-4126-B221-88F45B1A394B@nixkid.com> <20160617080820.GI8895@protva.ru> Message-ID: <20160617084658.GA3362@protva.ru> On Fri, Jun 17, 2016 at 11:26:03AM +0300, Иван Мишин wrote: > > > > То есть запросов к серверу нет? С кем же клиент тогда устанавливает > > соединения в цикле, перед тем как сообщает "Запрос HTTP послан, > > ожидается ответ"? > > Я же написал, что по завершению висяка появляется 500 ответ в логе. Nginx > то логирует уже после обработки запроса, вот и нет ничего в логах в момент > зависания, после того как зависание проходит в лог идет запись. > > Из того что я заметил пакеты не пропадают. клиент отправил запрос , сервер > его получил. а дальше тишина.... затем через время клиент делает вторую > попытку , сервер опять отправляет и тишина, после нескольких попыток, > сервер отвечает кодом 500 клиент это принимает и отваливается. Что значит "сервер опять отправляет" -- что он отправляет? Почему оно не доходит до клиента? Сначала написано что сервер принял запрос "и тишина". Ниже что он что-то отправляет. Так что же делает сервер, приняв запрос? Берите strace и смотрите, если коннекции принимает сервер. Если нет, ищите кто их принимает вместо сервера. Если сервер что-то отвечает, ищите где по пути к клиенту пропал ответ. -- Eugene Berdnikov From medvedev.yp на gmail.com Fri Jun 17 08:50:09 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Fri, 17 Jun 2016 11:50:09 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: <20160617084658.GA3362@protva.ru> References: <1C15DA41-A15F-4A8B-8BC8-5DBC1E22A3C3@nixkid.com> <5ECE6D08-4136-4126-B221-88F45B1A394B@nixkid.com> <20160617080820.GI8895@protva.ru> <20160617084658.GA3362@protva.ru> Message-ID: Tcpdump что показывает? 17 июня 2016 г., 11:47 пользователь Evgeniy Berdnikov написал: > On Fri, Jun 17, 2016 at 11:26:03AM +0300, Иван Мишин wrote: > > > > > > То есть запросов к серверу нет? С кем же клиент тогда устанавливает > > > соединения в цикле, перед тем как сообщает "Запрос HTTP послан, > > > ожидается ответ"? > > > > Я же написал, что по завершению висяка появляется 500 ответ в логе. > Nginx > > то логирует уже после обработки запроса, вот и нет ничего в логах в > момент > > зависания, после того как зависание проходит в лог идет запись. > > > > Из того что я заметил пакеты не пропадают. клиент отправил запрос , > сервер > > его получил. а дальше тишина.... затем через время клиент делает вторую > > попытку , сервер опять отправляет и тишина, после нескольких попыток, > > сервер отвечает кодом 500 клиент это принимает и отваливается. > > Что значит "сервер опять отправляет" -- что он отправляет? Почему оно > не доходит до клиента? > > Сначала написано что сервер принял запрос "и тишина". Ниже что он > что-то отправляет. Так что же делает сервер, приняв запрос? > Берите strace и смотрите, если коннекции принимает сервер. > Если нет, ищите кто их принимает вместо сервера. > Если сервер что-то отвечает, ищите где по пути к клиенту пропал ответ. > -- > Eugene Berdnikov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Fri Jun 17 12:09:29 2016 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 17 Jun 2016 15:09:29 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: References: <1C15DA41-A15F-4A8B-8BC8-5DBC1E22A3C3@nixkid.com> <5ECE6D08-4136-4126-B221-88F45B1A394B@nixkid.com> <20160617080820.GI8895@protva.ru> Message-ID: <6be01d1e-02ea-7bd7-eef3-267801ba82bb@csdoc.com> On 17.06.2016 11:26, Иван Мишин wrote: > по завершению висяка появляется 500 ответ в логе nginx -V сторонние модули присутствуют? воспроизводится ли этот глюк без сторонних модулей? -- Best regards, Gena From simplebox66 на gmail.com Fri Jun 17 13:39:00 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 17 Jun 2016 16:39:00 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: <6be01d1e-02ea-7bd7-eef3-267801ba82bb@csdoc.com> References: <1C15DA41-A15F-4A8B-8BC8-5DBC1E22A3C3@nixkid.com> <5ECE6D08-4136-4126-B221-88F45B1A394B@nixkid.com> <20160617080820.GI8895@protva.ru> <6be01d1e-02ea-7bd7-eef3-267801ba82bb@csdoc.com> Message-ID: nginx -V nginx version: nginx/1.10.1 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) built with OpenSSL 1.0.1e-fips 11 Feb 2013 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic --add-dynamic-module=njs-1c50334fbea6/nginx --with-threads --with-stream --with-stream_ssl_module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' сторонние модули присутствуют? Сторонних модулей нет, nginx поставлен из офф репа nginx. Сначала написано что сервер принял запрос "и тишина". Ниже что он > что-то отправляет. Так что же делает сервер, приняв запрос? Опечатался, в случае висяка сервер всегда принимает и молчит далее. Берите strace и смотрите, если коннекции принимает сервер. Однозначно могу сказать что коннект принимает сервер. Tcpdump что показывает? Показывает то что я описал выше. Ничего полезного > оттуда выловить не удалось. > 17 июня 2016 г., 15:09 пользователь Gena Makhomed написал: > On 17.06.2016 11:26, Иван Мишин wrote: > > > по завершению висяка появляется 500 ответ в логе > > nginx -V > > сторонние модули присутствуют? > > воспроизводится ли этот глюк без сторонних модулей? > > -- > Best regards, > Gena > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Fri Jun 17 14:42:26 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 17 Jun 2016 17:42:26 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: References: <1C15DA41-A15F-4A8B-8BC8-5DBC1E22A3C3@nixkid.com> <5ECE6D08-4136-4126-B221-88F45B1A394B@nixkid.com> <20160617080820.GI8895@protva.ru> <6be01d1e-02ea-7bd7-eef3-267801ba82bb@csdoc.com> Message-ID: <20160617144226.GD15786@sie.protva.ru> On Fri, Jun 17, 2016 at 04:39:00PM +0300, Иван Мишин wrote: > Сначала написано что сервер принял запрос "и тишина". Ниже что он > > что-то отправляет. Так что же делает сервер, приняв запрос? > > > Опечатался, в случае висяка сервер всегда принимает и молчит далее. Откуда такой вывод? Вы же в логах сервера ничего не видите. > Берите strace и смотрите, если коннекции принимает сервер. > > Однозначно могу сказать что коннект принимает сервер. А этот вывод откуда? Вы же strace не смотрели. -- Eugene Berdnikov From medvedev.yp на gmail.com Fri Jun 17 14:44:44 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Fri, 17 Jun 2016 17:44:44 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: <20160617144226.GD15786@sie.protva.ru> References: <1C15DA41-A15F-4A8B-8BC8-5DBC1E22A3C3@nixkid.com> <5ECE6D08-4136-4126-B221-88F45B1A394B@nixkid.com> <20160617080820.GI8895@protva.ru> <6be01d1e-02ea-7bd7-eef3-267801ba82bb@csdoc.com> <20160617144226.GD15786@sie.protva.ru> Message-ID: Не может tcpdump не показывать проблемы! Дебаг в nginx включите 17 июня 2016 г., 17:42 пользователь Evgeniy Berdnikov написал: > On Fri, Jun 17, 2016 at 04:39:00PM +0300, Иван Мишин wrote: > > Сначала написано что сервер принял запрос "и тишина". Ниже что он > > > что-то отправляет. Так что же делает сервер, приняв запрос? > > > > > > Опечатался, в случае висяка сервер всегда принимает и молчит далее. > > Откуда такой вывод? Вы же в логах сервера ничего не видите. > > > Берите strace и смотрите, если коннекции принимает сервер. > > > > Однозначно могу сказать что коннект принимает сервер. > > А этот вывод откуда? Вы же strace не смотрели. > -- > Eugene Berdnikov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Fri Jun 17 16:25:14 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 17 Jun 2016 19:25:14 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: References: <20160617080820.GI8895@protva.ru> Message-ID: <1665731.kpQRDR438y@vbart-workstation> On Friday 17 June 2016 11:26:03 Иван Мишин wrote: > > > > То есть запросов к серверу нет? С кем же клиент тогда устанавливает > > соединения в цикле, перед тем как сообщает "Запрос HTTP послан, > > ожидается ответ"? > > Я же написал, что по завершению висяка появляется 500 ответ в логе. Nginx > то логирует уже после обработки запроса, вот и нет ничего в логах в момент > зависания, после того как зависание проходит в лог идет запись. > > Из того что я заметил пакеты не пропадают. клиент отправил запрос , сервер > его получил. а дальше тишина.... затем через время клиент делает вторую > попытку , сервер опять отправляет и тишина, после нескольких попыток, > сервер отвечает кодом 500 клиент это принимает и отваливается. > [..] Если я правильно понял все прочитанное в этой теме, то ваш php скрипт на который nginx проксирует этот запрос, через какое-то время возвращает 500-ую ошибку, которую nginx благополучно отдает клиенту. -- Валентин Бартенев From nginx на kinetiksoft.com Sat Jun 18 21:52:25 2016 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Sun, 19 Jun 2016 00:52:25 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC90LAgaHR0cHM=?= In-Reply-To: <2080213.NqN4vmrlm2@vbart-workstation> References: <2080213.NqN4vmrlm2@vbart-workstation> Message-ID: <1775279.htrBrasXLf@cybernote> Здравствуйте! В письме от 16 июня 2016 17:07:59 пользователь Валентин Бартенев написал: > On Thursday 16 June 2016 19:00:47 Илья Шипицин wrote: > > [..] > > До версии 1.7.0 поддержки SNI на бекенды не было вовсе > и её включение может поломать некоторые конфигурации. > > Также оно плохо дружит с keepalive. > Можно с этого места поподробнее, пожалуйста. Используем proxy_ssl_server_name on вместе с keepalive повсеместно. Каких проблем ожидать? С уважением, Иван. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Sat Jun 18 22:11:21 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sun, 19 Jun 2016 01:11:21 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC90LAgaHR0cHM=?= In-Reply-To: <1775279.htrBrasXLf@cybernote> References: <2080213.NqN4vmrlm2@vbart-workstation> <1775279.htrBrasXLf@cybernote> Message-ID: <2012547.0FUUj3nVTi@vbart-laptop> On Sunday 19 June 2016 00:52:25 Иван wrote: > Здравствуйте! > > В письме от 16 июня 2016 17:07:59 пользователь Валентин Бартенев написал: > > On Thursday 16 June 2016 19:00:47 Илья Шипицин wrote: > > > > [..] > > > > До версии 1.7.0 поддержки SNI на бекенды не было вовсе > > и её включение может поломать некоторые конфигурации. > > > > Также оно плохо дружит с keepalive. > > > > Можно с этого места поподробнее, пожалуйста. Используем > proxy_ssl_server_name on > вместе с keepalive повсеместно. Каких проблем ожидать? > При выборе keepalive соединения, в которое будет отправлен запрос, SNI не учитывается. Если у вас для разных запросов требуются разные имена в SNI, то запрос может попасть в соединение, которое было установлено с неверным для данного запроса именем. -- Валентин Бартенев From simplebox66 на gmail.com Mon Jun 20 12:39:47 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 20 Jun 2016 15:39:47 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: <1665731.kpQRDR438y@vbart-workstation> References: <20160617080820.GI8895@protva.ru> <1665731.kpQRDR438y@vbart-workstation> Message-ID: да, но кто заставляет поддерживать соединение по несколько часов? keepalive стоит 32 Допустим у скрипта php съехала крыша, и он работает сутки, но почему вся цепочка curl-nginx-httpd целые сутки ждет пока отработает скрипт. В моем понятии должно быть ответ на подобие 504 и этот ответ курл должен получить не через сутки а куда как быстрее 17 июня 2016 г., 19:25 пользователь Валентин Бартенев написал: > On Friday 17 June 2016 11:26:03 Иван Мишин wrote: > > > > > > То есть запросов к серверу нет? С кем же клиент тогда устанавливает > > > соединения в цикле, перед тем как сообщает "Запрос HTTP послан, > > > ожидается ответ"? > > > > Я же написал, что по завершению висяка появляется 500 ответ в логе. > Nginx > > то логирует уже после обработки запроса, вот и нет ничего в логах в > момент > > зависания, после того как зависание проходит в лог идет запись. > > > > Из того что я заметил пакеты не пропадают. клиент отправил запрос , > сервер > > его получил. а дальше тишина.... затем через время клиент делает вторую > > попытку , сервер опять отправляет и тишина, после нескольких попыток, > > сервер отвечает кодом 500 клиент это принимает и отваливается. > > > [..] > > Если я правильно понял все прочитанное в этой теме, то ваш php скрипт > на который nginx проксирует этот запрос, через какое-то время возвращает > 500-ую ошибку, которую nginx благополучно отдает клиенту. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Mon Jun 20 14:32:32 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 20 Jun 2016 17:32:32 +0300 Subject: =?UTF-8?B?UmU6INC90LXQutC+0YLQvtGA0YvQtSDQt9Cw0L/RgNC+0YHRiyDQtNC10YDQttCw?= =?UTF-8?B?0YIg0YHQvtC10LTQuNC90LXQvdC40LUg0LTQviDQsdC10YHQutC+0L3QtdGH?= =?UTF-8?B?0L3QvtGB0YLQuA==?= In-Reply-To: References: <1665731.kpQRDR438y@vbart-workstation> Message-ID: <2729102.IoFtgmDToX@vbart-workstation> On Monday 20 June 2016 15:39:47 Иван Мишин wrote: > да, но кто заставляет поддерживать соединение по несколько часов? keepalive > стоит 32 > Допустим у скрипта php съехала крыша, и он работает сутки, но почему вся > цепочка curl-nginx-httpd целые сутки ждет пока отработает скрипт. В моем > понятии должно быть ответ на подобие 504 и этот ответ курл должен получить > не через сутки а куда как быстрее > [..] А настройки таймаутов в nginx какие? Опять же, сколько я мог понять из прочитанного, проблема не в том, что кто-то кого-то ждет, а в том, что curl у вас бесконечно посылает запрос снова и снова. -- Валентин Бартенев From a.vasilishin на kpi.ua Wed Jun 22 08:50:52 2016 From: a.vasilishin на kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Wed, 22 Jun 2016 11:50:52 +0300 Subject: =?UTF-8?B?0JPQtNC1INCx0YDQsNGC0Ywg0LTQuNC90LDQvNC40YfQtdGB0LrQuNC1INC80L4=?= =?UTF-8?B?0LTRg9C70Lg/?= Message-ID: Устанавливаю самый обычный нгинкс с репозитория deb http://nginx.org/packages/mainline/debian/ wheezy nginx # nginx -V nginx version: nginx/1.11.1 built by gcc 4.7.2 (Debian 4.7.2-5) built with OpenSSL 1.0.1e 11 Feb 2013 (running with OpenSSL 1.0.1t 3 May 2016) TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic --add-dynamic-module=debian/extra/njs-1c50334fbea6/nginx --with-threads --with-stream --with-stream_ssl_module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,--as-needed' и вот # ls -la /usr/lib/nginx/modules total 8 drwxr-xr-x 2 root root 4096 Apr 19 20:27 . drwxr-xr-x 3 root root 4096 Apr 27 10:34 .. пусто, ни одного модуля. Где их брать? From vbart на nginx.com Wed Jun 22 08:57:45 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 22 Jun 2016 11:57:45 +0300 Subject: =?UTF-8?B?UmU6INCT0LTQtSDQsdGA0LDRgtGMINC00LjQvdCw0LzQuNGH0LXRgdC60LjQtSA=?= =?UTF-8?B?0LzQvtC00YPQu9C4Pw==?= In-Reply-To: References: Message-ID: <12022666.7MQyuzLXXW@vbart-laptop> On Wednesday 22 June 2016 11:50:52 Андрей Василишин wrote: > Устанавливаю самый обычный нгинкс с репозитория > deb http://nginx.org/packages/mainline/debian/ wheezy nginx > > > # nginx -V > nginx version: nginx/1.11.1 > built by gcc 4.7.2 (Debian 4.7.2-5) > built with OpenSSL 1.0.1e 11 Feb 2013 (running with OpenSSL 1.0.1t 3 > May 2016) > TLS SNI support enabled > configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf > --error-log-path=/var/log/nginx/error.log > --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid > --lock-path=/var/run/nginx.lock > --http-client-body-temp-path=/var/cache/nginx/client_temp > --http-proxy-temp-path=/var/cache/nginx/proxy_temp > --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp > --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp > --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx > --group=nginx --with-http_ssl_module --with-http_realip_module > --with-http_addition_module --with-http_sub_module > --with-http_dav_module --with-http_flv_module --with-http_mp4_module > --with-http_gunzip_module --with-http_gzip_static_module > --with-http_random_index_module --with-http_secure_link_module > --with-http_stub_status_module --with-http_auth_request_module > --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic > --with-http_geoip_module=dynamic --with-http_perl_module=dynamic > --add-dynamic-module=debian/extra/njs-1c50334fbea6/nginx --with-threads > --with-stream --with-stream_ssl_module --with-http_slice_module > --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 > --with-http_v2_module --with-cc-opt='-g -O2 -fstack-protector > --param=ssp-buffer-size=4 -Wformat -Werror=format-security > -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,--as-needed' > > > и вот > # ls -la /usr/lib/nginx/modules > total 8 > drwxr-xr-x 2 root root 4096 Apr 19 20:27 . > drwxr-xr-x 3 root root 4096 Apr 27 10:34 .. > > пусто, ни одного модуля. Где их брать? > http://nginx.org/ru/linux_packages.html#dynmodules | В настоящее время следующие модули собираются как динамические | и поставляются в виде отдельных пакетов: | | nginx-module-geoip | nginx-module-image-filter | nginx-module-njs | nginx-module-perl | nginx-module-xslt -- Валентин Бартенев From nginx-forum на forum.nginx.org Wed Jun 22 09:04:10 2016 From: nginx-forum на forum.nginx.org (misha_shar53) Date: Wed, 22 Jun 2016 05:04:10 -0400 Subject: 403 Forbidden Message-ID: Система SUSE 42.1 из репозитариев установлен NGINX. Есть HTML файл который я пытаюсь открыть через NGINX. http://localhost/htm/Term/term.html В ответ получаю такое сообщение. 403 Forbidden На файл все права разрешены. Он находится в моем домашнем каталоге. Почему запрещен доступ к этому файлу у NGINX? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267759,267759#msg-267759 From kulmaks на gmail.com Wed Jun 22 09:24:15 2016 From: kulmaks на gmail.com (Maksim Kulik) Date: Wed, 22 Jun 2016 12:24:15 +0300 Subject: 403 Forbidden In-Reply-To: References: Message-ID: Selinux включен? 22 июня 2016 г., 12:04 пользователь misha_shar53 < nginx-forum на forum.nginx.org> написал: > Система SUSE 42.1 из репозитариев установлен NGINX. Есть HTML файл который > я > пытаюсь открыть через NGINX. > http://localhost/htm/Term/term.html > В ответ получаю такое сообщение. 403 Forbidden > На файл все права разрешены. Он находится в моем домашнем каталоге. > Почему запрещен доступ к этому файлу у NGINX? > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Jun 22 09:44:40 2016 From: nginx-forum на forum.nginx.org (misha_shar53) Date: Wed, 22 Jun 2016 05:44:40 -0400 Subject: 403 Forbidden In-Reply-To: References: Message-ID: <25f571e0c5a9f9e2cafc49df0a5aa196.NginxMailingListRussian@forum.nginx.org> Что такое Selinux? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,119063,267762#msg-267762 From basil на vpm.net.ua Wed Jun 22 09:52:38 2016 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Wed, 22 Jun 2016 12:52:38 +0300 Subject: 403 Forbidden In-Reply-To: <25f571e0c5a9f9e2cafc49df0a5aa196.NginxMailingListRussian@forum.nginx.org> References: <25f571e0c5a9f9e2cafc49df0a5aa196.NginxMailingListRussian@forum.nginx.org> Message-ID: 22 июня 2016 г., 12:44 пользователь misha_shar53 < nginx-forum на forum.nginx.org> написал: > Что такое Selinux? > Что такое гугль ? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From medvedev.yp на gmail.com Wed Jun 22 09:55:35 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Wed, 22 Jun 2016 12:55:35 +0300 Subject: =?UTF-8?B?UmU6INCT0LTQtSDQsdGA0LDRgtGMINC00LjQvdCw0LzQuNGH0LXRgdC60LjQtSA=?= =?UTF-8?B?0LzQvtC00YPQu9C4Pw==?= In-Reply-To: <12022666.7MQyuzLXXW@vbart-laptop> References: <12022666.7MQyuzLXXW@vbart-laptop> Message-ID: apt-cache search nginx 22 июня 2016 г. 11:56 AM пользователь "Валентин Бартенев" написал: > On Wednesday 22 June 2016 11:50:52 Андрей Василишин wrote: > > Устанавливаю самый обычный нгинкс с репозитория > > deb http://nginx.org/packages/mainline/debian/ wheezy nginx > > > > > > # nginx -V > > nginx version: nginx/1.11.1 > > built by gcc 4.7.2 (Debian 4.7.2-5) > > built with OpenSSL 1.0.1e 11 Feb 2013 (running with OpenSSL 1.0.1t 3 > > May 2016) > > TLS SNI support enabled > > configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > > --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf > > --error-log-path=/var/log/nginx/error.log > > --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid > > --lock-path=/var/run/nginx.lock > > --http-client-body-temp-path=/var/cache/nginx/client_temp > > --http-proxy-temp-path=/var/cache/nginx/proxy_temp > > --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp > > --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp > > --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx > > --group=nginx --with-http_ssl_module --with-http_realip_module > > --with-http_addition_module --with-http_sub_module > > --with-http_dav_module --with-http_flv_module --with-http_mp4_module > > --with-http_gunzip_module --with-http_gzip_static_module > > --with-http_random_index_module --with-http_secure_link_module > > --with-http_stub_status_module --with-http_auth_request_module > > --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic > > --with-http_geoip_module=dynamic --with-http_perl_module=dynamic > > --add-dynamic-module=debian/extra/njs-1c50334fbea6/nginx --with-threads > > --with-stream --with-stream_ssl_module --with-http_slice_module > > --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 > > --with-http_v2_module --with-cc-opt='-g -O2 -fstack-protector > > --param=ssp-buffer-size=4 -Wformat -Werror=format-security > > -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,--as-needed' > > > > > > и вот > > # ls -la /usr/lib/nginx/modules > > total 8 > > drwxr-xr-x 2 root root 4096 Apr 19 20:27 . > > drwxr-xr-x 3 root root 4096 Apr 27 10:34 .. > > > > пусто, ни одного модуля. Где их брать? > > > > http://nginx.org/ru/linux_packages.html#dynmodules > > | В настоящее время следующие модули собираются как динамические > | и поставляются в виде отдельных пакетов: > | > | nginx-module-geoip > | nginx-module-image-filter > | nginx-module-njs > | nginx-module-perl > | nginx-module-xslt > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From a.vasilishin на kpi.ua Wed Jun 22 10:08:14 2016 From: a.vasilishin на kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Wed, 22 Jun 2016 13:08:14 +0300 Subject: =?UTF-8?B?UmU6INCT0LTQtSDQsdGA0LDRgtGMINC00LjQvdCw0LzQuNGH0LXRgdC60LjQtSA=?= =?UTF-8?B?0LzQvtC00YPQu9C4Pw==?= In-Reply-To: <12022666.7MQyuzLXXW@vbart-laptop> References: <12022666.7MQyuzLXXW@vbart-laptop> Message-ID: <68c07a90-3b42-9081-6b43-b75d06b93f2b@kpi.ua> > http://nginx.org/ru/linux_packages.html#dynmodules > > | В настоящее время следующие модули собираются как динамические > | и поставляются в виде отдельных пакетов: > | > | nginx-module-geoip > | nginx-module-image-filter > | nginx-module-njs > | nginx-module-perl > | nginx-module-xslt Спасибо From chipitsine на gmail.com Thu Jun 23 13:33:46 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 23 Jun 2016 18:33:46 +0500 Subject: continuous integration ? Message-ID: Добрый день! заранее извиняюсь, что для иллюстрации привожу болезненную тему lua-nginx-module (холивара относительно качества модуля не планирую) недавно добавили проекты на Travis-CI: https://travis-ci.org/openresty/ у nginx есть все предпосылки для развертывания CI-фермы (напр, https://github.com/nginx/nginx-tests), не думали в эту сторону ? комьюнити неплохо драйвится, когда видят результаты тестирования своих pull request-ов. Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Jun 23 14:53:27 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 23 Jun 2016 17:53:27 +0300 Subject: continuous integration ? In-Reply-To: References: Message-ID: <20160623145327.GO30781@mdounin.ru> Hello! On Thu, Jun 23, 2016 at 06:33:46PM +0500, Илья Шипицин wrote: > Добрый день! > > заранее извиняюсь, что для иллюстрации привожу болезненную тему > lua-nginx-module (холивара относительно качества модуля не планирую) > > недавно добавили проекты на Travis-CI: > > https://travis-ci.org/openresty/ > > у nginx есть все предпосылки для развертывания CI-фермы (напр, > https://github.com/nginx/nginx-tests), не думали в эту сторону ? > > комьюнити неплохо драйвится, когда видят результаты тестирования своих pull > request-ов. У нас развёрнут buildbot внутри уже лет 5 как. О pull request'а же речи не идёт, т.к. для разработки мы не используем git/github, а общаемся в почте. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Wed Jun 29 10:05:28 2016 From: nginx-forum на forum.nginx.org (tirael) Date: Wed, 29 Jun 2016 06:05:28 -0400 Subject: proxy_cache Message-ID: <1fc695dc132da3563943b9b65d0d0965.NginxMailingListRussian@forum.nginx.org> Доброго дня! Имеется nginx(frontend) apache (backend) делаю кэширование на nginx для ускорения работы сайта ибо сейчас ttfb от 2 сек и выше. вот мои конфиги nginx.conf user www-data; worker_processes auto; timer_resolution 100ms; worker_priority -5; error_log /var/log/nginx/error.log; #error_log off; pid /var/run/nginx.pid; events { # accept_mutex on; # accept_mutex_delay 500ms; # worker_aio_requests 32 use epoll; worker_connections 2048; multi_accept on; } http { # Подключение mimetypes include /etc/nginx/mime.types; # Подключение прокси include /etc/nginx/proxy_params; # Не показывать информацию о сервере server_tokens off; # Логи доступа access_log /var/log/nginx/access.log; #access_log off; # Протокол отдачи статики sendfile on; tcp_nodelay on; tcp_nopush on; # Подключение других настроек include /etc/nginx/conf.d/*.conf; # Подключение виртуальных хостов include /etc/nginx/sites-enabled/multiblender.ru; } proxy_param.conf # Базовые настройки proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Защита от killapache.pl proxy_set_header Range ""; proxy_set_header Request-Range ""; # Размер буферов proxy_buffers 32 8k; # 256K * 4096 = ~1G proxy_buffering on; proxy_ignore_client_abort off; proxy_intercept_errors off; proxy_read_timeout 320s; core_module.conf chunked_transfer_encoding on; client_body_buffer_size 32k; # стандартный буфер для обычных POST client_max_body_size 64m; # максимальный буфер для больших файлов не больше чем у PHP client_body_in_file_only off; #client_body_in_single_buffer off; client_header_buffer_size 1k; # Маленький входной буфер large_client_header_buffers 4 8k; # Максимальный буфер равен входному буферу apache и PHP #client_header_timeout 60s; client_body_timeout 10; client_header_timeout 10; default_type application/octet-stream; #directio off; #disable_symlinks off; #if_modified_since exact; ignore_invalid_headers on; underscores_in_headers on; keepalive_disable msie6; keepalive_requests 100; keepalive_timeout 30; # таймаут при передаче клиентам send_timeout 2; reset_timedout_connection on; # Ограничение скорости!!! #limit_rate 0; #limit_rate_after 0; # Интересное кеширование информации о мелких файлах open_file_cache max=4096 inactive=20s; open_file_cache_valid 40s; open_file_cache_min_uses 2; open_file_cache_errors on; gzip_module.conf gzip on; gzip_buffers 32 8k; gzip_comp_level 1; gzip_disable msie6; gzip_min_length 20; gzip_http_version 1.1; gzip_proxied off; gzip_types text/plain application/xml application/x-javascript application/javascript text/javascript text/xml ext/javascript text/css text/json application/vnd.ms-excel application/vnd.ms-powerpoint application/msword; gzip_vary off; site_enable proxy_cache_path /var/nginx/cache levels=1:2 keys_zone=cache:10m inactive=60m; proxy_set_header Accept-Encoding ""; #proxy_temp_path /var/nginx/proxy 1 2; proxy_ignore_headers Expires Cache-Control; proxy_cache_use_stale error timeout invalid_header http_502; proxy_cache_bypass $cookie_session; proxy_no_cache $cookie_session; proxy_ignore_headers Set-Cookie; server { listen 80; server_name multiblender.ru www.multiblender.ru; log_format cache_status '[$time_local] "$request" $upstream_cache_status'; access_log /var/log/cache.log cache_status; access_log /var/log/nginx-access.log; error_log /var/log/nginx-error.log; root /var/www/html/; index index.php index.html index.htm; tcp_nodelay on; tcp_nopush on; location / { sub_filter_once off; sub_filter '="aaa' '="bbb'; proxy_cache cache; proxy_ignore_headers Expires; proxy_ignore_headers Cache-Control; proxy_cache_valid any 30m; proxy_cache_valid 404 502 503 1m; proxy_cache_key $host$uri$request_uri$is_args$args; proxy_cache_bypass $cookie_pass_hash; proxy_no_cache $cookie_pass_hash; add_header X-Cache-Status $upstream_cache_status; proxy_pass http://127.0.0.1:8080/; } location ~* ^.+\.(html|xhtml|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|tar|wav|bmp|rtf|js|wmv|avi|cur|swf|mp3|wma|htc|cur|7z)$ { root /var/www/html; expires 3d; add_header Cache-Control "public"; } open_file_cache max=10000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; # Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac). location ~ /\. { deny all; access_log off; log_not_found off; } # location ~ \.(jpg|jpeg|gif|png|ico|css|bmp|swf|js|mov|avi|mp4|mpeg4) { # root /var/www/html; # } location ~ /.ht { deny all; } } На данный момент файлики кэша создаются в директории. В логах такая фигня [29/Jun/2016:10:03:55 +0000] "GET /mojka-kuppersberg-modena-15b-sand HTTP/1.1" MISS [29/Jun/2016:10:03:57 +0000] "GET /vstraivaemaja-bytovaja-tehnika/duhovye-shkafy/proizvoditel:beko,bosch,electrolux,indesit,zanussi,neff,hotpoint-ariston,samsung/sklad:in/tsvet:seryj,chernyj/duhovka:elektricheskaja-nezavisimaja,gazovaja-nezavisimaja/ HTTP/1.1" MISS [29/Jun/2016:10:04:09 +0000] "GET /varochnaya-poverhnost-gorenje-g6n4zbb HTTP/1.1" MISS [29/Jun/2016:10:04:27 +0000] "GET /varochnaya-panel-neff-t43d49n2 HTTP/1.1" MISS [29/Jun/2016:09:50:42 +0000] "GET /image/cache/data/mx/zadacha/p26103_346693_stiralnaya_mashina_samsung_wf8590nmw9-250x250.jpg HTTP/1.1" - [29/Jun/2016:09:50:42 +0000] "GET /image/cache/data/mx/zadacha/p52000_4324919_stiralnaya_mashina_samsung_wf60f1r0f2w-250x250.jpg HTTP/1.1" - [29/Jun/2016:09:50:42 +0000] "GET /image/cache/data/mx/zadacha/p52116_4355360_morozilnik_kraft_xf_300a-250x250.jpg HTTP/1.1" - [29/Jun/2016:09:50:42 +0000] "GET /catalog/view/theme/lexus_happycook/stylesheet/sliderlayer/assets/btn-slide.png HTTP/1.1" - Тоесть ничего не кэшируется, помогите кто шарит хорошо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267948,267948#msg-267948 From alex.hha на gmail.com Wed Jun 29 10:27:03 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Wed, 29 Jun 2016 13:27:03 +0300 Subject: proxy_cache In-Reply-To: <1fc695dc132da3563943b9b65d0d0965.NginxMailingListRussian@forum.nginx.org> References: <1fc695dc132da3563943b9b65d0d0965.NginxMailingListRussian@forum.nginx.org> Message-ID: А что прилетает в X-Cache-Status? И что собственно надо кешировать? P.S. немного странная регулярка ^.+\.(html|xhtml|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|tar|wav|bmp|rtf|js|wmv|avi|cur|swf|mp3|wma|htc|cur|7z)$ { ... } можно просто location ~ \.(html|xhtml|jpg ... htc|cur|7z)$ { ... } On Wed, Jun 29, 2016 at 1:05 PM, tirael wrote: > Доброго дня! > Имеется nginx(frontend) apache (backend) > делаю кэширование на nginx для ускорения работы сайта ибо сейчас ttfb от 2 > сек и выше. > вот мои конфиги > > nginx.conf > user www-data; > worker_processes auto; > timer_resolution 100ms; > worker_priority -5; > > error_log /var/log/nginx/error.log; > #error_log off; > > pid /var/run/nginx.pid; > > events { > # accept_mutex on; > # accept_mutex_delay 500ms; > # worker_aio_requests 32 > use epoll; > worker_connections 2048; > multi_accept on; > } > > http { > # Подключение mimetypes > include /etc/nginx/mime.types; > > # Подключение прокси > include /etc/nginx/proxy_params; > > # Не показывать информацию о сервере > server_tokens off; > > # Логи доступа > access_log /var/log/nginx/access.log; > #access_log off; > > # Протокол отдачи статики > sendfile on; > > tcp_nodelay on; > tcp_nopush on; > > # Подключение других настроек > include /etc/nginx/conf.d/*.conf; > > # Подключение виртуальных хостов > include /etc/nginx/sites-enabled/multiblender.ru; > } > > proxy_param.conf > > > # Базовые настройки > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > # Защита от killapache.pl > proxy_set_header Range ""; > proxy_set_header Request-Range ""; > > # Размер буферов > proxy_buffers 32 8k; # 256K * 4096 = ~1G > proxy_buffering on; > > > proxy_ignore_client_abort off; > proxy_intercept_errors off; > proxy_read_timeout 320s; > > core_module.conf > > > chunked_transfer_encoding on; > client_body_buffer_size 32k; # стандартный буфер для обычных > POST > client_max_body_size 64m; # максимальный буфер для больших > файлов не больше чем у PHP > client_body_in_file_only off; > #client_body_in_single_buffer off; > client_header_buffer_size 1k; # Маленький входной буфер > large_client_header_buffers 4 8k; # Максимальный буфер равен входному > буферу apache и PHP > #client_header_timeout 60s; > client_body_timeout 10; > client_header_timeout 10; > > default_type application/octet-stream; > > #directio off; > #disable_symlinks off; > #if_modified_since exact; > ignore_invalid_headers on; > underscores_in_headers on; > > keepalive_disable msie6; > keepalive_requests 100; > keepalive_timeout 30; > > # таймаут при передаче клиентам > send_timeout 2; > reset_timedout_connection on; > > # Ограничение скорости!!! > #limit_rate 0; > #limit_rate_after 0; > > # Интересное кеширование информации о мелких файлах > open_file_cache max=4096 inactive=20s; > open_file_cache_valid 40s; > open_file_cache_min_uses 2; > open_file_cache_errors on; > > > gzip_module.conf > > > gzip on; > gzip_buffers 32 8k; > gzip_comp_level 1; > gzip_disable msie6; > gzip_min_length 20; > gzip_http_version 1.1; > gzip_proxied off; > gzip_types text/plain application/xml application/x-javascript > application/javascript text/javascript text/xml ext/javascript text/css > text/json application/vnd.ms-excel application/vnd.ms-powerpoint > application/msword; > gzip_vary off; > > > site_enable > > proxy_cache_path /var/nginx/cache levels=1:2 keys_zone=cache:10m > inactive=60m; > proxy_set_header Accept-Encoding ""; > #proxy_temp_path /var/nginx/proxy 1 2; > > proxy_ignore_headers Expires Cache-Control; > proxy_cache_use_stale error timeout invalid_header http_502; > proxy_cache_bypass $cookie_session; > proxy_no_cache $cookie_session; > > proxy_ignore_headers Set-Cookie; > server { > listen 80; > server_name multiblender.ru www.multiblender.ru; > log_format cache_status '[$time_local] "$request" $upstream_cache_status'; > access_log /var/log/cache.log cache_status; > > access_log /var/log/nginx-access.log; > error_log /var/log/nginx-error.log; > > root /var/www/html/; > index index.php index.html index.htm; > > tcp_nodelay on; > tcp_nopush on; > > location / { > sub_filter_once off; > sub_filter '="aaa' '="bbb'; > proxy_cache cache; > proxy_ignore_headers Expires; > proxy_ignore_headers Cache-Control; > proxy_cache_valid any 30m; > > proxy_cache_valid 404 502 503 1m; > proxy_cache_key $host$uri$request_uri$is_args$args; > proxy_cache_bypass $cookie_pass_hash; > proxy_no_cache $cookie_pass_hash; > add_header X-Cache-Status $upstream_cache_status; > > proxy_pass http://127.0.0.1:8080/; > > } > > location ~* > > ^.+\.(html|xhtml|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|tar|wav|bmp|rtf|js|wmv|avi|cur|swf|mp3|wma|htc|cur|7z)$ > { > root /var/www/html; > expires 3d; > add_header Cache-Control "public"; > } > > open_file_cache max=10000 inactive=20s; > open_file_cache_valid 30s; > open_file_cache_min_uses 2; > open_file_cache_errors on; > > > # Deny all attempts to access hidden files such as .htaccess, .htpasswd, > .DS_Store (Mac). > location ~ /\. { > deny all; > access_log off; > log_not_found off; > } > > # location ~ \.(jpg|jpeg|gif|png|ico|css|bmp|swf|js|mov|avi|mp4|mpeg4) { > # root /var/www/html; > # } > > location ~ /.ht { > deny all; > } > } > > > > > На данный момент файлики кэша создаются в директории. > > В логах такая фигня > > > [29/Jun/2016:10:03:55 +0000] "GET /mojka-kuppersberg-modena-15b-sand > HTTP/1.1" MISS > [29/Jun/2016:10:03:57 +0000] "GET > > /vstraivaemaja-bytovaja-tehnika/duhovye-shkafy/proizvoditel:beko,bosch,electrolux,indesit,zanussi,neff,hotpoint-ariston,samsung/sklad:in/tsvet:seryj,chernyj/duhovka:elektricheskaja-nezavisimaja,gazovaja-nezavisimaja/ > HTTP/1.1" MISS > [29/Jun/2016:10:04:09 +0000] "GET /varochnaya-poverhnost-gorenje-g6n4zbb > HTTP/1.1" MISS > [29/Jun/2016:10:04:27 +0000] "GET /varochnaya-panel-neff-t43d49n2 HTTP/1.1" > MISS > > [29/Jun/2016:09:50:42 +0000] "GET > > /image/cache/data/mx/zadacha/p26103_346693_stiralnaya_mashina_samsung_wf8590nmw9-250x250.jpg > HTTP/1.1" - > [29/Jun/2016:09:50:42 +0000] "GET > > /image/cache/data/mx/zadacha/p52000_4324919_stiralnaya_mashina_samsung_wf60f1r0f2w-250x250.jpg > HTTP/1.1" - > [29/Jun/2016:09:50:42 +0000] "GET > > /image/cache/data/mx/zadacha/p52116_4355360_morozilnik_kraft_xf_300a-250x250.jpg > HTTP/1.1" - > [29/Jun/2016:09:50:42 +0000] "GET > > /catalog/view/theme/lexus_happycook/stylesheet/sliderlayer/assets/btn-slide.png > HTTP/1.1" - > > Тоесть ничего не кэшируется, помогите кто шарит хорошо. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267948,267948#msg-267948 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From exelib на gmail.com Wed Jun 29 19:50:49 2016 From: exelib на gmail.com (Anton Bessonov) Date: Wed, 29 Jun 2016 21:50:49 +0200 Subject: 403 Forbidden In-Reply-To: <25f571e0c5a9f9e2cafc49df0a5aa196.NginxMailingListRussian@forum.nginx.org> References: <25f571e0c5a9f9e2cafc49df0a5aa196.NginxMailingListRussian@forum.nginx.org> Message-ID: <57742699.4000203@gmail.com> On 22.06.2016 11:44, misha_shar53 wrote: > Что такое Selinux? http://lmgtfy.com/?q=%D0%A7%D1%82%D0%BE+%D1%82%D0%B0%D0%BA%D0%BE%D0%B5+Selinux%3F&l=1 -- Certified Prince2:2009 Project Manager Professional Scrum Expert Oracle Certified Expert, Enterprise JavaBeans Developer Oracle Certified Professional, Java SE 6 Programmer Now that's a test of the character of an organization. Of the organizations that are attempting to implement Scrum probably, 30% - 35% will successfully implement it. - Ken Schwaber From nginx-forum на forum.nginx.org Thu Jun 30 06:50:28 2016 From: nginx-forum на forum.nginx.org (manimi) Date: Thu, 30 Jun 2016 02:50:28 -0400 Subject: =?UTF-8?B?UmU6INC30L3QsNC6INCy0L7Qv9GA0L7RgdCwINC90LUg0L7QsdGA0LDQsdCw0YI=?= =?UTF-8?B?0YvQstCw0LXRgtGB0Y8g0LIgcmVnZXhw?= In-Reply-To: <4AD5D749.6000908@gmail.com> References: <4AD5D749.6000908@gmail.com> Message-ID: Sergej Kandyla Wrote: ------------------------------------------------------- > На сервере есть ссылки на некоторую динамику, которые нужно > профильтровать. > ссылки примерно такого харакетера > > http://mydomain.com/dsfdasf/sfasdf/file.php?EXAMPLE_3=2 > http://mydomain.com/dsfdasf/sfasdf/file.php&EXAMPLE_=1 > > сделал отдельный локейшн, удовлетворяющий данному запросу. > > server_name mydomain.com > location ~ ^.*(EXAMPLE_).*$ { > rewrite ^ http://mydomain.com redirect; > } > > если в запросе содержится знак вопроса '?' > то данный регексп не обрабатывается. > > пробовал также экранировать знак вопроса '\?' - не помогло. > пробовал как через location, так и непосредственно в реврайте указать > такой регексп. > > В чем может быть ошибка? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,13622,267962#msg-267962 From sejo412 на gmail.com Thu Jun 30 18:09:26 2016 From: sejo412 на gmail.com (Paul Sin) Date: Thu, 30 Jun 2016 21:09:26 +0300 Subject: =?UTF-8?B?UmU6INC30L3QsNC6INCy0L7Qv9GA0L7RgdCwINC90LUg0L7QsdGA0LDQsdCw0YI=?= =?UTF-8?B?0YvQstCw0LXRgtGB0Y8g0LIgcmVnZXhw?= In-Reply-To: References: <4AD5D749.6000908@gmail.com> Message-ID: Это не локейшен, а аргумент запроса. http://nginx.org/ru/docs/http/ngx_http_core_module.html#variables 30 июня 2016 г., 9:50 пользователь manimi написал: > Sergej Kandyla Wrote: > ------------------------------------------------------- > > На сервере есть ссылки на некоторую динамику, которые нужно > > профильтровать. > > ссылки примерно такого харакетера > > > > http://mydomain.com/dsfdasf/sfasdf/file.php?EXAMPLE_3=2 > > http://mydomain.com/dsfdasf/sfasdf/file.php&EXAMPLE_=1 > > > > сделал отдельный локейшн, удовлетворяющий данному запросу. > > > > server_name mydomain.com > > location ~ ^.*(EXAMPLE_).*$ { > > rewrite ^ http://mydomain.com redirect; > > } > > > > если в запросе содержится знак вопроса '?' > > то данный регексп не обрабатывается. > > > > пробовал также экранировать знак вопроса '\?' - не помогло. > > пробовал как через location, так и непосредственно в реврайте указать > > такой регексп. > > > > В чем может быть ошибка? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,13622,267962#msg-267962 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- best reguards Paul Sin ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sejo412 на gmail.com Thu Jun 30 18:30:42 2016 From: sejo412 на gmail.com (Paul Sin) Date: Thu, 30 Jun 2016 21:30:42 +0300 Subject: proxy_cache In-Reply-To: <1fc695dc132da3563943b9b65d0d0965.NginxMailingListRussian@forum.nginx.org> References: <1fc695dc132da3563943b9b65d0d0965.NginxMailingListRussian@forum.nginx.org> Message-ID: А что вас смущает в логах? если первый раз отдается контент с бэка (повторяющихся запросов в логе вы не привели), естественно его нет в кэше (то, что попадает в локейшен / и улетает на бэк) 2016-06-29 13:05 GMT+03:00 tirael : > Доброго дня! > Имеется nginx(frontend) apache (backend) > делаю кэширование на nginx для ускорения работы сайта ибо сейчас ttfb от 2 > сек и выше. > вот мои конфиги > > nginx.conf > user www-data; > worker_processes auto; > timer_resolution 100ms; > worker_priority -5; > > error_log /var/log/nginx/error.log; > #error_log off; > > pid /var/run/nginx.pid; > > events { > # accept_mutex on; > # accept_mutex_delay 500ms; > # worker_aio_requests 32 > use epoll; > worker_connections 2048; > multi_accept on; > } > > http { > # Подключение mimetypes > include /etc/nginx/mime.types; > > # Подключение прокси > include /etc/nginx/proxy_params; > > # Не показывать информацию о сервере > server_tokens off; > > # Логи доступа > access_log /var/log/nginx/access.log; > #access_log off; > > # Протокол отдачи статики > sendfile on; > > tcp_nodelay on; > tcp_nopush on; > > # Подключение других настроек > include /etc/nginx/conf.d/*.conf; > > # Подключение виртуальных хостов > include /etc/nginx/sites-enabled/multiblender.ru; > } > > proxy_param.conf > > > # Базовые настройки > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > # Защита от killapache.pl > proxy_set_header Range ""; > proxy_set_header Request-Range ""; > > # Размер буферов > proxy_buffers 32 8k; # 256K * 4096 = ~1G > proxy_buffering on; > > > proxy_ignore_client_abort off; > proxy_intercept_errors off; > proxy_read_timeout 320s; > > core_module.conf > > > chunked_transfer_encoding on; > client_body_buffer_size 32k; # стандартный буфер для обычных > POST > client_max_body_size 64m; # максимальный буфер для больших > файлов не больше чем у PHP > client_body_in_file_only off; > #client_body_in_single_buffer off; > client_header_buffer_size 1k; # Маленький входной буфер > large_client_header_buffers 4 8k; # Максимальный буфер равен входному > буферу apache и PHP > #client_header_timeout 60s; > client_body_timeout 10; > client_header_timeout 10; > > default_type application/octet-stream; > > #directio off; > #disable_symlinks off; > #if_modified_since exact; > ignore_invalid_headers on; > underscores_in_headers on; > > keepalive_disable msie6; > keepalive_requests 100; > keepalive_timeout 30; > > # таймаут при передаче клиентам > send_timeout 2; > reset_timedout_connection on; > > # Ограничение скорости!!! > #limit_rate 0; > #limit_rate_after 0; > > # Интересное кеширование информации о мелких файлах > open_file_cache max=4096 inactive=20s; > open_file_cache_valid 40s; > open_file_cache_min_uses 2; > open_file_cache_errors on; > > > gzip_module.conf > > > gzip on; > gzip_buffers 32 8k; > gzip_comp_level 1; > gzip_disable msie6; > gzip_min_length 20; > gzip_http_version 1.1; > gzip_proxied off; > gzip_types text/plain application/xml application/x-javascript > application/javascript text/javascript text/xml ext/javascript text/css > text/json application/vnd.ms-excel application/vnd.ms-powerpoint > application/msword; > gzip_vary off; > > > site_enable > > proxy_cache_path /var/nginx/cache levels=1:2 keys_zone=cache:10m > inactive=60m; > proxy_set_header Accept-Encoding ""; > #proxy_temp_path /var/nginx/proxy 1 2; > > proxy_ignore_headers Expires Cache-Control; > proxy_cache_use_stale error timeout invalid_header http_502; > proxy_cache_bypass $cookie_session; > proxy_no_cache $cookie_session; > > proxy_ignore_headers Set-Cookie; > server { > listen 80; > server_name multiblender.ru www.multiblender.ru; > log_format cache_status '[$time_local] "$request" $upstream_cache_status'; > access_log /var/log/cache.log cache_status; > > access_log /var/log/nginx-access.log; > error_log /var/log/nginx-error.log; > > root /var/www/html/; > index index.php index.html index.htm; > > tcp_nodelay on; > tcp_nopush on; > > location / { > sub_filter_once off; > sub_filter '="aaa' '="bbb'; > proxy_cache cache; > proxy_ignore_headers Expires; > proxy_ignore_headers Cache-Control; > proxy_cache_valid any 30m; > > proxy_cache_valid 404 502 503 1m; > proxy_cache_key $host$uri$request_uri$is_args$args; > proxy_cache_bypass $cookie_pass_hash; > proxy_no_cache $cookie_pass_hash; > add_header X-Cache-Status $upstream_cache_status; > > proxy_pass http://127.0.0.1:8080/; > > } > > location ~* > > ^.+\.(html|xhtml|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|tar|wav|bmp|rtf|js|wmv|avi|cur|swf|mp3|wma|htc|cur|7z)$ > { > root /var/www/html; > expires 3d; > add_header Cache-Control "public"; > } > > open_file_cache max=10000 inactive=20s; > open_file_cache_valid 30s; > open_file_cache_min_uses 2; > open_file_cache_errors on; > > > # Deny all attempts to access hidden files such as .htaccess, .htpasswd, > .DS_Store (Mac). > location ~ /\. { > deny all; > access_log off; > log_not_found off; > } > > # location ~ \.(jpg|jpeg|gif|png|ico|css|bmp|swf|js|mov|avi|mp4|mpeg4) { > # root /var/www/html; > # } > > location ~ /.ht { > deny all; > } > } > > > > > На данный момент файлики кэша создаются в директории. > > В логах такая фигня > > > [29/Jun/2016:10:03:55 +0000] "GET /mojka-kuppersberg-modena-15b-sand > HTTP/1.1" MISS > [29/Jun/2016:10:03:57 +0000] "GET > > /vstraivaemaja-bytovaja-tehnika/duhovye-shkafy/proizvoditel:beko,bosch,electrolux,indesit,zanussi,neff,hotpoint-ariston,samsung/sklad:in/tsvet:seryj,chernyj/duhovka:elektricheskaja-nezavisimaja,gazovaja-nezavisimaja/ > HTTP/1.1" MISS > [29/Jun/2016:10:04:09 +0000] "GET /varochnaya-poverhnost-gorenje-g6n4zbb > HTTP/1.1" MISS > [29/Jun/2016:10:04:27 +0000] "GET /varochnaya-panel-neff-t43d49n2 HTTP/1.1" > MISS > > [29/Jun/2016:09:50:42 +0000] "GET > > /image/cache/data/mx/zadacha/p26103_346693_stiralnaya_mashina_samsung_wf8590nmw9-250x250.jpg > HTTP/1.1" - > [29/Jun/2016:09:50:42 +0000] "GET > > /image/cache/data/mx/zadacha/p52000_4324919_stiralnaya_mashina_samsung_wf60f1r0f2w-250x250.jpg > HTTP/1.1" - > [29/Jun/2016:09:50:42 +0000] "GET > > /image/cache/data/mx/zadacha/p52116_4355360_morozilnik_kraft_xf_300a-250x250.jpg > HTTP/1.1" - > [29/Jun/2016:09:50:42 +0000] "GET > > /catalog/view/theme/lexus_happycook/stylesheet/sliderlayer/assets/btn-slide.png > HTTP/1.1" - > > Тоесть ничего не кэшируется, помогите кто шарит хорошо. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267948,267948#msg-267948 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- best reguards Paul Sin ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: