From mdounin at mdounin.ru Sat Sep 1 03:53:43 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 1 Sep 2012 07:53:43 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0LfQu9C40YfQuNGC0YwgU1NMINGB0LXRgNGC0LjRhNC4?= =?UTF-8?B?0LrQsNGC0YssINCy0YvQtNCw0L3QvdGL0LUg0YDQsNC30LvQuNGH0L3Ri9C8?= =?UTF-8?B?0Lgg0L/RgNC+0LzQtdC20YPRgtC+0YfQvdGL0LzQuCDQptChINGB0L7QsdGJ?= =?UTF-8?B?0LjQvCDQutC+0YDQvdC10LLRi9C8INCm0KE/?= In-Reply-To: <37f91392f9e376211181e047da4932e6.NginxMailingListRussian@forum.nginx.org> References: <20110913120601.GA15030@nginx.com> <37f91392f9e376211181e047da4932e6.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120901035343.GG40452@mdounin.ru> Hello! On Mon, Aug 27, 2012 at 05:08:07PM -0400, Maximus43 wrote: > Я все-таки повторюсь со своей проблемой. > Пытался внимательно понять, как и что работает, пришел к следующим выводам: > 1. Директива ssl_client_certificate определяет список доступных CA для > клиента, сертификаты этих CA сервер готов рассматривать для авторизации по > сертификату. Со стороны клиента выглядит как: > --- > Acceptable client certificate CA names > /CN=SubCA1/O=Test JSC/L=Moscow/C=RU > --- > Браузер, получая такой сертификат смотрит все клиентские пары ключей и > выбирает те, которые подписаны указанным сертификатом. > > 2. Директива ssl_certificate содержит ссылку на файл с серверным SSL > сертификатом. Причем если в сертификате верно прописаны AIA caIssuer и > Authority Key Identifier, то клиент может самостоятельно построить цепочку > до корневого сертификата. Возможно добавить промежуточные CA после > серверного сертификата, однако корневой сертификат добавлять туда не стоит, > в этом нет смысла. Корневые сертификаты должны присутствовать у клиента. > > Вроде все должно работать предсказуемо, однако это не так. > > Проблемы начинаются из-за того, что нет разделения механизма проверки > клиентских сертификатов и предоставления клиенту списка принимаемых > сертификатов. Это приводит к тому, что в директиве ssl_client_certificate > ссылка должна указывать на файл, который помимо серверного сертификата > должен ВСЕГДА содержать цепочку сертификатов, включая корневой, иначе > проверка клиентского сертификата завершится неудачно с кодом 20:unable to > get local issuer certificate для отсутствующих сертификатов и 27:certificate > not trusted для всех остальных в цепочке. > Проблема наличия корневого сертификата в списке доступных для клиента в том, > что браузер предлагает использовать все сертификаты всех подчиненных CA, > подписанных корневым сертификатом. Это является потенциальной проблемой > безопасности. И пользователь с сертификатом, подписанным SubCA2, сможет > получить доступ на сайт вместо пользователя с сертификатом, подписанным > SubCA1. > > Есть ли возможность реализовать передачу доступных CA клиенту директивой > ssl_client_certificate в виде существующей функциональности, а вот механизм > проверки клиентских сертификатов сделать независимым от данной директивы? > Вероятно придется определить новый параметр типа > ssl_verify_client_certificate, который будет указывать на файл с цепочками > доверенных сертификатов, включая корневые. Однако проблема безопасности при этом как была, так и остаётся: если вы доверяете корневой CA, и verify depth стоит 2 - то вы доверяете *всем* сертификатам, выпущенным этой CA, до 2-го уровня включительно, т.е. в том числе всем сертификатам выпущенным SubCA1 и SubCA2. Как именно клиент узнает, что вам там можно прислать сертификат, подписанный SubCA2 - не важно, но когда/если узнает - получить доступ сможет без проблем. И даже промежуточных сертификатов при необходимости сможет прислать столько, сколько потребуется. Как мне видится, проблема безопасности тут проистекает из неверной предпосылки, что доверяя CA, мы как-то можем оное доверие ограничить. Это не так, точнее - не совсем так. Если хочется что-то ограничить - надо следом за аутентификацией, которую собственно и обеспечивает проверка сертификата, делать ещё и авторизацию. Сейчас в nginx'е это теоретически можно делать с помощью предоставляемых переменных $ssl_*. Что касается передачи клиентам списка сертификатов, отличного от собстенно списка доверенных сертификатов, то сделать это безусловно можно. И для рассмотренного выше случая даже полезно - клиент будет лучше представлять, какой именно сертификат от него хотят (в терминах RFC 5246 - "to describe ... desired authorization space"). Первый патч вот тут: http://nginx.org/patches/ocsp-stapling/ добавляет директиву ssl_trusted_certificate, которая позволяет расширить список сертификатов, используемых для проверки. При этом клиенту по прежнему передаются имена только тех сертификатов, что указаны в ssl_client_certificate. Но надо понимать, что к каким-либо проблемам безопасности это разделение никакого отношения не имеет, см. выше. Maxim Dounin From mdounin at mdounin.ru Sat Sep 1 09:22:01 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 1 Sep 2012 13:22:01 +0400 Subject: ngx_encode_base64url In-Reply-To: <898673434e3526dac7093fcf1af4f016.NginxMailingListRussian@forum.nginx.org> References: <898673434e3526dac7093fcf1af4f016.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120901092201.GH40452@mdounin.ru> Hello! On Tue, Aug 21, 2012 at 02:50:14PM -0400, theromis1 wrote: > Вопрос предложение навеяное java ( > http://commons.apache.org/codec/apidocs/org/apache/commons/codec/binary/Base64.html#Base64(int, > byte[], boolean) ) > > Есть логика которая добавляет заголовок который потом переходит как часть > урла (с помощью rewrite rules "rewrite ^ http://blah/qwe=$http_my_header;"), > соответственно в нем бинарные данные которые base64 а потом на него делается > urlescape, но поскольку помнится можно делать эти действия urlsafe то можно > все это было бы делать без ескейпинга, тоесть за один проход base64_encode. > > Соответственно можно было бы добавить функцию в ngx_string.c которая делала > бы это все безболезненно. Что кто может сказать по данному вопросу? у меня > нарисовался даже вот такой патч, но это только в первом приближении. Наверное, стоит добавить, особенно с учётом того, что сам nginx для подобных задач как раз base64url использует. Собственно, её нет исключительно потому, что encode'ить base64url пока нигде в коде nginx'а ни разу не понадобилось. Что до патчей, то лучше не пытаться сабмитить их через форум, даже если они явно негодны к коммиту и "в первом приближени". Результат читается с трудом. Настоятельно рекомендуется слать в рассылку напрямую, и лучше в nginx-devel@ (там, правда, на английском). Maxim Dounin From senty at yandex.ru Sat Sep 1 22:10:11 2012 From: senty at yandex.ru (=?koi8-r?B?98nUwczJyiDzxc7U0cvP1w==?=) Date: Sun, 02 Sep 2012 02:10:11 +0400 Subject: nginx rewrite url Message-ID: <661031346537411@web20d.yandex.ru> Доброго времени суток всем! Сайт работает на MODX Evo без вкл. SEO URL. Сейчас сайт переносят на MODX Revolution с SEO URL. Нужно сделать редирект со страниц MODX Evo на страницы MODX Revolution. Обычно я делал это так: rewrite ^/voprosi-prizivnikov-uristam.html$ /faq/jurist/ permanent; все работало. Сейчас же надо сделать так: rewrite ^/index.php?id=28$ /faq/jurist/ permanent; и не работает. Кто знает как сделать подскажите пожалуйста. ------------------------------------------- Виталий Сентяков Веб-мастер дизайн-студии ?BLEND? Сайт: www.blend.bz Моя почта: senty at blend.bz Тел.: +7 (950) 165-61-16 / Skype: senty.pro From server_inc at list.ru Sat Sep 1 22:36:40 2012 From: server_inc at list.ru (=?UTF-8?B?0KHRgtCw0L3QuNGB0LvQsNCy?=) Date: Sun, 02 Sep 2012 01:36:40 +0300 Subject: nginx rewrite url In-Reply-To: <661031346537411@web20d.yandex.ru> References: <661031346537411@web20d.yandex.ru> Message-ID: <50428DF8.4010106@list.ru> 02.09.2012 1:10, Виталий Сентяков пишет: > Доброго времени суток всем! > > [...] > > Сейчас же надо сделать так: > rewrite ^/index.php?id=28$ /faq/jurist/ permanent; > > и не работает. > location = /index.php { if ($arg_id = "28") { rewrite ^ /faq/jurist/ permanent; } } From ne at vbart.ru Sun Sep 2 00:07:54 2012 From: ne at vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 2 Sep 2012 04:07:54 +0400 Subject: nginx rewrite url In-Reply-To: <50428DF8.4010106@list.ru> References: <661031346537411@web20d.yandex.ru> <50428DF8.4010106@list.ru> Message-ID: <201209020407.54757.ne@vbart.ru> On Sunday 02 September 2012 02:36:40 Станислав wrote: > 02.09.2012 1:10, Виталий Сентяков пишет: > > Доброго времени суток всем! > > > > [...] > > > > Сейчас же надо сделать так: > > rewrite ^/index.php?id=28$ /faq/jurist/ permanent; > > > > и не работает. > > location = /index.php { > > if ($arg_id = "28") { > rewrite ^ /faq/jurist/ permanent; > } > > } Только вместо: rewrite ^ /faq/jurist/ permanent; лучше будет: return 301 /faq/jurist/; -- Валентин Бартенев From senty at yandex.ru Sun Sep 2 17:41:57 2012 From: senty at yandex.ru (=?koi8-r?B?98nUwczJyiDzxc7U0cvP1w==?=) Date: Sun, 02 Sep 2012 21:41:57 +0400 Subject: nginx rewrite url In-Reply-To: References: Message-ID: <859691346607717@web10d.yandex.ru> При использовании такого правила: location = /index.php { if ($arg_id = "28") { return 301 /activity/bubble-show.html; } } открывается исходный код php файла. С чем это связано? ------------------------------------------- Виталий Сентяков Веб-мастер дизайн-студии ?BLEND? Сайт: www.blend.bz Моя почта: senty at blend.bz Тел.: +7 (950) 165-61-16 / Skype: senty.pro 02.09.2012, 16:00, "nginx-ru-request at nginx.org" : > Сообщения, предназначенные для списка рассылки nginx-ru, необходимо > отправлять по адресу >         nginx-ru at nginx.org > > Для изменения параметров подписки вы можеже использовать веб-страницу >         http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Для получения информации о том, как пользовать почтовым интерфейсом, > отправьте письмо, в теле или теме которого будет слово 'help', по > адресу: >         nginx-ru-request at nginx.org > > Адрес человека, ответственного за этот список рассылки: >         nginx-ru-owner at nginx.org > > При ответе, пожалуйста, измение тему письма так, чтобы она была более > содержательной чем "Re: Содержание дайджеста списка рассылки > nginx-ru..." > > Today's Topics: > >    1. nginx rewrite url (Виталий Сентяков) >    2. Re: nginx rewrite url (Станислав) >    3. Re: nginx rewrite url (Валентин Бартенев) > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ne at vbart.ru Sun Sep 2 17:54:37 2012 From: ne at vbart.ru (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sun, 2 Sep 2012 21:54:37 +0400 Subject: nginx rewrite url In-Reply-To: <859691346607717@web10d.yandex.ru> References: <859691346607717@web10d.yandex.ru> Message-ID: <201209022154.38013.ne@vbart.ru> On Sunday 02 September 2012 21:41:57 Виталий Сентяков wrote: > При использовании такого правила: > > location = /index.php { > if ($arg_id = "28") { > return 301 /activity/bubble-show.html; > } > } > открывается исходный код php файла. > С чем это связано? > На какой запрос? На запрос /index.php?id=28 - будет редирект. На запрос /index.php без аргументов или с любыми аргументами кроме id=28 будет отдано содержимое страницы. Nginx не знает как обрабатывать PHP и вы ему об этом не сообщили. -- Валентин Бартенев From kapp at yandex-team.ru Mon Sep 3 12:44:10 2012 From: kapp at yandex-team.ru (Alex Kapranoff) Date: Mon, 3 Sep 2012 16:44:10 +0400 Subject: =?UTF-8?B?UmU6IFJlOiDQntCx0YDQsNCx0L7RgtC60LAg0YDQtdC00LjRgNC10LrRgtC+0LIg?= =?UTF-8?B?0LLQvdGD0YLRgNC4?= In-Reply-To: <20120831141545.GB59826@nginx.com> References: <226441346421848@web9d.yandex.ru> <20120831141545.GB59826@nginx.com> Message-ID: <20120903124410.GA19475@kapp.yandex-team.ru> * Igor Sysoev [August 31 2012, 18:15]: > On Fri, Aug 31, 2012 at 06:04:08PM +0400, Alex Kapranoff wrote: > > Привет! > > > > Есть простой прокси. Хотим обрабатывать редиректы от апстримов внутри > > nginx -- так, чтобы они не доходили до браузера. Пусть браузер > > получает только последний ответ в цепочке. Не получается. > > > > Первая мысль для цепочки длинной 1: ловим редиректы с помощью > > error_page в именованый location со вторым proxy_pass внутри. Однако > > до адреса, на который делается редирект, добраться не удаётся. > > > > Подскажете что-нибудь? > > Как-то так: > > resolver 127.0.0.1; > > location / { > ... > proxy_intercept_errors on; > error_page 302 = @redirect; > } > > location @redirect { > set $redirect $http_upstream_location; > proxy_pass $redirect; > } Да, получается, с учётом поправки $http_upstream_ --> $upstream_http_ Спасибо! -- Alexey Kapranov. From public-mail at alekciy.ru Tue Sep 4 06:44:01 2012 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Tue, 4 Sep 2012 10:44:01 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC4INCy0L3QtdGI0L3QuNC1INGE0LDQudC70Ys=?= In-Reply-To: References: Message-ID: Наиболее вероятная ошибка - отсутствие/некорректность Content-Type для отдаваемого JS. 29 августа 2012 г., 18:13 пользователь chapov написал: > Жаль только, что уже не выясню, что тут было то собсна говоря From dan at onliner.by Tue Sep 4 09:29:26 2012 From: dan at onliner.by (Daniil) Date: Tue, 4 Sep 2012 12:29:26 +0300 Subject: =?UTF-8?B?0JzQvdC+0LPQvtGB0YLRgNC+0YfQvdGL0LUg0YDQtdCz0YPQu9GP0YDQvdGL0LUg?= =?UTF-8?B?0LLRi9GA0LDQttC10L3QuNGP?= Message-ID: Здравствуйте, Есть ли возможность в конфигурационном файле составлять многострочные регулярные выражения типа: location ~ ^/ (?\w+)/ (?\w+)/ (?.+)/? $ { ... } И если есть, то как это правильно делается. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kav at karagodov.name Tue Sep 4 09:39:57 2012 From: kav at karagodov.name (Alexey V. Karagodov) Date: Tue, 4 Sep 2012 13:39:57 +0400 Subject: =?UTF-8?B?UmU6INCc0L3QvtCz0L7RgdGC0YDQvtGH0L3Ri9C1INGA0LXQs9GD0LvRj9GA0L0=?= =?UTF-8?B?0YvQtSDQstGL0YDQsNC20LXQvdC40Y8=?= In-Reply-To: References: Message-ID: <66FDFF37-D88A-455E-B76E-8C1A4171F909@karagodov.name> если поискать, то обсуждение многострочности было несколько недель назад не помню только, говорилось ли там про регулярки On 04.09.2012, at 13:29, Daniil wrote: > Здравствуйте, > > Есть ли возможность в конфигурационном файле составлять многострочные регулярные выражения типа: > > location ~ ^/ > (?\w+)/ > (?\w+)/ > (?.+)/? > $ > { > > ... > > } > > И если есть, то как это правильно делается. > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From igor at sysoev.ru Tue Sep 4 09:49:53 2012 From: igor at sysoev.ru (Igor Sysoev) Date: Tue, 4 Sep 2012 13:49:53 +0400 Subject: =?UTF-8?B?UmU6INCc0L3QvtCz0L7RgdGC0YDQvtGH0L3Ri9C1INGA0LXQs9GD0LvRj9GA0L0=?= =?UTF-8?B?0YvQtSDQstGL0YDQsNC20LXQvdC40Y8=?= In-Reply-To: References: Message-ID: <20120904094953.GA2174@nginx.com> On Tue, Sep 04, 2012 at 12:29:26PM +0300, Daniil wrote: > Здравствуйте, > > Есть ли возможность в конфигурационном файле составлять многострочные > регулярные выражения типа: > > location ~ ^/ > (?\w+)/ > (?\w+)/ > (?.+)/? > $ > { > > ... > > } > > И если есть, то как это правильно делается. location ~ "(?x) ^/ (?\w+)/ (?\w+)/ (?\w+)/ $" { -- Igor Sysoev From dan at onliner.by Tue Sep 4 12:22:17 2012 From: dan at onliner.by (=?UTF-8?B?0JTQsNC90LjQuNC7INCR0L7Qu9GB0YPQvQ==?=) Date: Tue, 4 Sep 2012 15:22:17 +0300 Subject: =?UTF-8?B?UkU6INCc0L3QvtCz0L7RgdGC0YDQvtGH0L3Ri9C1INGA0LXQs9GD0LvRj9GA0L0=?= =?UTF-8?B?0YvQtSDQstGL0YDQsNC20LXQvdC40Y8=?= Message-ID: ---Исходное сообщение--- От: Daniil Отпр.: 04.09.2012, 12:29 Кому: nginx-ru at nginx.org Тема: Многострочные регулярные выражения Здравствуйте, Есть ли возможность в конфигурационном файле составлять многострочные регулярные выражения типа: location ~ ^/ (?\w+)/ (?\w+)/ (?.+)/? $ { ... } И если есть, то как это правильно делается. From figasebe at gmail.com Thu Sep 6 12:08:53 2012 From: figasebe at gmail.com (=?KOI8-R?B?7snLz8zByiD6wcrDxdc=?=) Date: Thu, 6 Sep 2012 16:08:53 +0400 Subject: =?UTF-8?B?0JjRgdGF0L7QtNGP0YnQuNC1INGB0L7QtdC00LjQtdC90LXQvdC40Y8g0L7RgiA=?= =?UTF-8?B?0YDQtdCw0LvRjNC90L7Qs9C+IGlwINC60LvQuNC10L3RgtCwLg==?= Message-ID: Здравствуйте. Мне нужно настроить nginx в режиме http forward. Network -> NGINX(Proxy) -> Internet Я использовал такую конфигурацию. server { listen 80; location / { resolver 127.0.0.01; proxy_pass $scheme://$http_host$uri$is_args$args; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; } } Работает. Но сами tcp пакеты уходят от ip самого сервера NGINX. Nginx умеет отправлять исходящие пакеты от ip клиента, а не от ip сервера? Хочу ,чтобы к конечному адресату приходил пакет от реального ip клиента,который послал запрос. Спасибо? -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.vasilishin at kpi.ua Thu Sep 6 12:24:20 2012 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 06 Sep 2012 15:24:20 +0300 Subject: =?UTF-8?B?UmU6INCY0YHRhdC+0LTRj9GJ0LjQtSDRgdC+0LXQtNC40LXQvdC10L3QuNGPINC+?= =?UTF-8?B?0YIg0YDQtdCw0LvRjNC90L7Qs9C+IGlwINC60LvQuNC10L3RgtCwLg==?= In-Reply-To: References: Message-ID: <504895F4.3020603@kpi.ua> 06.09.2012 15:08, Николай Зайцев пишет: > Здравствуйте. > Мне нужно настроить nginx в режиме http forward. > > Network -> NGINX(Proxy) -> Internet > > Я использовал такую конфигурацию. > > server { > listen 80; > > location / { > resolver 127.0.0.01; > proxy_pass $scheme://$http_host$uri$is_args$args; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $remote_addr; > } > } > > Работает. Но сами tcp пакеты уходят от ip самого сервера NGINX. Nginx > умеет отправлять исходящие пакеты от ip клиента, а не от ip сервера? > Хочу ,чтобы к конечному адресату приходил пакет от реального ip > клиента,который послал запрос. > > Спасибо? То что Вы хотите сделать называется IP-спуфинг http://ru.wikipedia.org/wiki/IP-%D1%81%D0%BF%D1%83%D1%84%D0%B8%D0%BD%D0%B3 Самое близкое, что есть у нгинкс это http://wiki.nginx.org/HttpProxyModule#proxy_bind , но насколько я помню оно не поддерживает еще переменные. -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From a.vasilishin at kpi.ua Thu Sep 6 12:33:03 2012 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 06 Sep 2012 15:33:03 +0300 Subject: =?UTF-8?B?UmU6INCY0YHRhdC+0LTRj9GJ0LjQtSDRgdC+0LXQtNC40LXQvdC10L3QuNGPINC+?= =?UTF-8?B?0YIg0YDQtdCw0LvRjNC90L7Qs9C+IGlwINC60LvQuNC10L3RgtCwLg==?= In-Reply-To: References: Message-ID: <504897FF.8010807@kpi.ua> 06.09.2012 15:08, Николай Зайцев пишет: > Хочу ,чтобы к конечному адресату приходил пакет от реального ip > клиента,который послал запрос. > Кстати, зачем Вы это хотите, кроме как "с плохими намерениями" больше ничего в голову не приходит? Даже если и не с плохими, то браузер пользователя, который послал запрос на нгинкс, не примет потом ответ, который напрямую придет с Интернета. Все что Вы таким образом сделаете - банальный DoS. > Спасибо? Странный вопрос -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From figasebe at gmail.com Thu Sep 6 12:44:17 2012 From: figasebe at gmail.com (=?KOI8-R?B?7snLz8zByiD6wcrDxdc=?=) Date: Thu, 6 Sep 2012 16:44:17 +0400 Subject: =?UTF-8?B?UmU6INCY0YHRhdC+0LTRj9GJ0LjQtSDRgdC+0LXQtNC40LXQvdC10L3QuNGPINC+?= =?UTF-8?B?0YIg0YDQtdCw0LvRjNC90L7Qs9C+IGlwINC60LvQuNC10L3RgtCwLg==?= In-Reply-To: <504897FF.8010807@kpi.ua> References: <504897FF.8010807@kpi.ua> Message-ID: Спуфинг тут не причем. Это вообще из другой оперы. Вопрос один. Может ли nginx, отправлять дальше tcp запрос от ip адреса клиента,а не от ip самого сервера. Запрос должен приходить на конечный узел от ip адреса клиента,а не от ip адреса nginx. 6 сентября 2012 г., 16:33 пользователь Андрей Василишин написал: > 06.09.2012 15:08, Николай Зайцев пишет: > > Хочу ,чтобы к конечному адресату приходил пакет от реального ip >> клиента,который послал запрос. >> >> > Кстати, зачем Вы это хотите, кроме как "с плохими намерениями" больше > ничего в голову не приходит? Даже если и не с плохими, то браузер > пользователя, который послал запрос на нгинкс, не примет потом ответ, > который напрямую придет с Интернета. Все что Вы таким образом сделаете - > банальный DoS. > > > Спасибо? >> > > Странный вопрос > > > > > -- > WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE > > ______________________________**_________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/**mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kav at karagodov.name Thu Sep 6 12:46:49 2012 From: kav at karagodov.name (Alexey V. Karagodov) Date: Thu, 6 Sep 2012 16:46:49 +0400 Subject: =?UTF-8?B?UmU6INCY0YHRhdC+0LTRj9GJ0LjQtSDRgdC+0LXQtNC40LXQvdC10L3QuNGPINC+?= =?UTF-8?B?0YIg0YDQtdCw0LvRjNC90L7Qs9C+IGlwINC60LvQuNC10L3RgtCwLg==?= In-Reply-To: References: <504897FF.8010807@kpi.ua> Message-ID: бредятина tcp-proxy? On 06.09.2012, at 16:44, Николай Зайцев wrote: > Спуфинг тут не причем. Это вообще из другой оперы. > Вопрос один. > Может ли nginx, отправлять дальше tcp запрос от ip адреса клиента,а не от ip самого сервера. > Запрос должен приходить на конечный узел от ip адреса клиента,а не от ip адреса nginx. > > > 6 сентября 2012 г., 16:33 пользователь Андрей Василишин написал: > 06.09.2012 15:08, Николай Зайцев пишет: > > Хочу ,чтобы к конечному адресату приходил пакет от реального ip > клиента,который послал запрос. > > > Кстати, зачем Вы это хотите, кроме как "с плохими намерениями" больше ничего в голову не приходит? Даже если и не с плохими, то браузер пользователя, который послал запрос на нгинкс, не примет потом ответ, который напрямую придет с Интернета. Все что Вы таким образом сделаете - банальный DoS. > > > Спасибо? > > Странный вопрос > > > > > -- > WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.vasilishin at kpi.ua Thu Sep 6 12:49:15 2012 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 06 Sep 2012 15:49:15 +0300 Subject: =?UTF-8?B?UmU6INCY0YHRhdC+0LTRj9GJ0LjQtSDRgdC+0LXQtNC40LXQvdC10L3QuNGPINC+?= =?UTF-8?B?0YIg0YDQtdCw0LvRjNC90L7Qs9C+IGlwINC60LvQuNC10L3RgtCwLg==?= In-Reply-To: References: <504897FF.8010807@kpi.ua> Message-ID: <50489BCB.5020204@kpi.ua> 06.09.2012 15:44, Николай Зайцев пишет: > Спуфинг тут не причем. Это вообще из другой оперы. > Вопрос один. > Может ли nginx, отправлять дальше tcp запрос от ip адреса клиента,а не > от ip самого сервера. > Запрос должен приходить на конечный узел от ip адреса клиента,а не от ip > адреса nginx. Не может, разве что c использованием proxy_bind и этого патча http://mailman.nginx.org/pipermail/nginx-devel/2010-August/000419.html Но опять же, не факт что такие пройдут дальше шлюза, который банально может дропать пакеты не из своей сети. -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From figasebe at gmail.com Thu Sep 6 13:08:42 2012 From: figasebe at gmail.com (=?KOI8-R?B?7snLz8zByiD6wcrDxdc=?=) Date: Thu, 6 Sep 2012 17:08:42 +0400 Subject: =?UTF-8?B?UmU6INCY0YHRhdC+0LTRj9GJ0LjQtSDRgdC+0LXQtNC40LXQvdC10L3QuNGPINC+?= =?UTF-8?B?0YIg0YDQtdCw0LvRjNC90L7Qs9C+IGlwINC60LvQuNC10L3RgtCwLg==?= In-Reply-To: <50489BCB.5020204@kpi.ua> References: <504897FF.8010807@kpi.ua> <50489BCB.5020204@kpi.ua> Message-ID: Ну да. Это прокси. Запросы из нашей сети идут, поэтому они уйдут во внешний мир через наш шлюз без проблем. Главное,чтобы tcp пакет из nginx вылетал от source ip клиента. Если я верно понял,то директива proxy_bind позволяет отправлять исходящий пакет с определенного интерфейса. Но это полезно в том случае,если на сервере есть много интерфейсов и нужно определить с какого из них отправлять. 6 сентября 2012 г., 16:49 пользователь Андрей Василишин написал: > 06.09.2012 15:44, Николай Зайцев пишет: > > Спуфинг тут не причем. Это вообще из другой оперы. >> Вопрос один. >> Может ли nginx, отправлять дальше tcp запрос от ip адреса клиента,а не >> от ip самого сервера. >> Запрос должен приходить на конечный узел от ip адреса клиента,а не от ip >> адреса nginx. >> > > Не может, разве что c использованием proxy_bind и этого патча > http://mailman.nginx.org/**pipermail/nginx-devel/2010-**August/000419.html > > Но опять же, не факт что такие пройдут дальше шлюза, который банально > может дропать пакеты не из своей сети. > > > -- > WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE > > ______________________________**_________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/**mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nefer05 at gmail.com Thu Sep 6 13:41:13 2012 From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=) Date: Thu, 6 Sep 2012 17:41:13 +0400 Subject: =?UTF-8?B?UmU6INCY0YHRhdC+0LTRj9GJ0LjQtSDRgdC+0LXQtNC40LXQvdC10L3QuNGPINC+?= =?UTF-8?B?0YIg0YDQtdCw0LvRjNC90L7Qs9C+IGlwINC60LvQuNC10L3RgtCwLg==?= In-Reply-To: References: <504897FF.8010807@kpi.ua> <50489BCB.5020204@kpi.ua> Message-ID: 2012/9/6 Николай Зайцев : > Ну да. Это прокси. Запросы из нашей сети идут, поэтому они уйдут во внешний > мир через наш шлюз без проблем. Главное,чтобы tcp пакет из nginx вылетал от > source ip клиента. Вам уже несколько раз сказали - оно в любом случае работать не будет. И спуфинг - это именно это и есть. From mdounin at mdounin.ru Thu Sep 6 14:17:25 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 6 Sep 2012 18:17:25 +0400 Subject: =?UTF-8?B?UmU6INCY0YHRhdC+0LTRj9GJ0LjQtSDRgdC+0LXQtNC40LXQvdC10L3QuNGPINC+?= =?UTF-8?B?0YIg0YDQtdCw0LvRjNC90L7Qs9C+IGlwINC60LvQuNC10L3RgtCwLg==?= In-Reply-To: References: <504897FF.8010807@kpi.ua> <50489BCB.5020204@kpi.ua> Message-ID: <20120906141725.GF40452@mdounin.ru> Hello! On Thu, Sep 06, 2012 at 05:41:13PM +0400, Роман Москвитин wrote: > 2012/9/6 Николай Зайцев : > > Ну да. Это прокси. Запросы из нашей сети идут, поэтому они уйдут во внешний > > мир через наш шлюз без проблем. Главное,чтобы tcp пакет из nginx вылетал от > > source ip клиента. > > Вам уже несколько раз сказали - оно в любом случае работать не будет. > И спуфинг - это именно это и есть. Почему не будет? Будет - гуглить tproxy, IP_TRANSPARENT, IP_BINDANY. Варианты реализации для nginx'а пару раз пробегали где-то в районе nginx-devel@, но к сожалению никто так и не взялся сделать хоть сколько-нибудь кроссплатформенное решение, пригодное коммита. Maxim Dounin From nefer05 at gmail.com Thu Sep 6 14:37:40 2012 From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=) Date: Thu, 6 Sep 2012 18:37:40 +0400 Subject: =?UTF-8?B?UmU6INCY0YHRhdC+0LTRj9GJ0LjQtSDRgdC+0LXQtNC40LXQvdC10L3QuNGPINC+?= =?UTF-8?B?0YIg0YDQtdCw0LvRjNC90L7Qs9C+IGlwINC60LvQuNC10L3RgtCwLg==?= In-Reply-To: <20120906141725.GF40452@mdounin.ru> References: <504897FF.8010807@kpi.ua> <50489BCB.5020204@kpi.ua> <20120906141725.GF40452@mdounin.ru> Message-ID: > Почему не будет? Будет - гуглить tproxy, IP_TRANSPARENT, > IP_BINDANY. Эм... Призрачный прокси всегда был прокси, который не надо прописывать. ИПшник оно подменяет в стандартной конфигурации. Я прекрасно представляю ситуацию, когда вся эта фигня будет прекрасно работать, но что то мне подсказывает что ТС далек от таких вариантов решения. Поэтому и сказал то что сказал. Это из серии извлечения квадратного корня из отрицательного числа в школьном курсе. Ежели предчувствия меня обманули и ТС таки понимает что просит - тогда ему надо гораздо четче и развернутей формулировать запросы. From senty at yandex.ru Fri Sep 7 17:58:30 2012 From: senty at yandex.ru (=?koi8-r?B?98nUwczJyiDzxc7U0cvP1w==?=) Date: Fri, 07 Sep 2012 21:58:30 +0400 Subject: nginx-ru Digest, Vol 35, Issue 3 In-Reply-To: References: Message-ID: <34411347040710@web3g.yandex.ru> У меня сейчас есть такое правило: if ($arg_id = "8") { return 301 /jobs.html;} В системе управления MODX, которая доступна после добавления к доменному имени manager есть URL: /manager/?a=10&id=8 Для него правило указанное выше тоже срабатывает, как это исправить? ------------------------------------------- Виталий Сентяков Веб-мастер дизайн-студии ?BLEND? Сайт: www.blend.bz Моя почта: senty at blend.bz Тел.: +7 (950) 165-61-16 / Skype: senty.pro 03.09.2012, 16:00, "nginx-ru-request at nginx.org" : > Сообщения, предназначенные для списка рассылки nginx-ru, необходимо > отправлять по адресу >         nginx-ru at nginx.org > > Для изменения параметров подписки вы можеже использовать веб-страницу >         http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Для получения информации о том, как пользовать почтовым интерфейсом, > отправьте письмо, в теле или теме которого будет слово 'help', по > адресу: >         nginx-ru-request at nginx.org > > Адрес человека, ответственного за этот список рассылки: >         nginx-ru-owner at nginx.org > > При ответе, пожалуйста, измение тему письма так, чтобы она была более > содержательной чем "Re: Содержание дайджеста списка рассылки > nginx-ru..." > > , > Today's Topics: > >    1. Re: nginx rewrite url (Виталий Сентяков) >    2. Re: nginx rewrite url (Валентин Бартенев) > > , > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ne at vbart.ru Fri Sep 7 18:57:04 2012 From: ne at vbart.ru (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 7 Sep 2012 22:57:04 +0400 Subject: nginx-ru Digest, Vol 35, Issue 3 In-Reply-To: <34411347040710@web3g.yandex.ru> References: <34411347040710@web3g.yandex.ru> Message-ID: <201209072257.04299.ne@vbart.ru> On Friday 07 September 2012 21:58:30 Виталий Сентяков wrote: > У меня сейчас есть такое правило: > > if ($arg_id = "8") { > return 301 /jobs.html;} > > В системе управления MODX, которая доступна после добавления к доменному > имени manager есть URL: /manager/?a=10&id=8 > > Для него правило указанное выше тоже срабатывает, как это исправить? > if ($args = "id=8") { return 301 /jobs.html; } -- Валентин Бартенев From greyhard at gmail.com Sun Sep 9 10:31:24 2012 From: greyhard at gmail.com (=?KOI8-R?B?5MXOydMg6czYyc7ZyA==?=) Date: Sun, 9 Sep 2012 14:31:24 +0400 Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDQvdCw0L/QuNGB0LDRgtGMIHJlZ2V4cCDQtNC70Y8g?= =?UTF-8?B?0YPQtNCw0LvQtdC90LjRjyDQu9C40YjQvdC40YUg0YHQu9C10YjQtdC5?= Message-ID: Какое то время была ошибка в урлах и яндекс проиндексировал страницы вида /category/subcategory// Теперь пытаюсь убрать такие ссылки 302 редиректом (убрать 2 и более слеша на конце) if ($request_uri ~ "^(.+)/{2,}$"){ rewrite "^(.+)/{2,}$" $1 permanent; } Не выходит if ($request_uri ~ "^(.*)/+$"){ rewrite "^(.*)/+$" $1 permanent; } Обрезает все слеши , так как модификатор + эквивалент {1,} но мне бы хотелось {2,} почему такая запись не работает ? From pavel2000 at ngs.ru Sun Sep 9 17:30:30 2012 From: pavel2000 at ngs.ru (Pavel V.) Date: Mon, 10 Sep 2012 00:30:30 +0700 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0L3QsNC/0LjRgdCw0YLRjCByZWdleHAg0LQ=?= =?UTF-8?B?0LvRjyDRg9C00LDQu9C10L3QuNGPINC70LjRiNC90LjRhSDRgdC70LXRiNC1?= =?UTF-8?B?0Lk=?= In-Reply-To: References: Message-ID: <1211776766.20120910003030@ngs.ru> Здравствуйте, Денис. Вы писали 9 сентября 2012 г., 17:31:24: > Какое то время была ошибка в урлах и яндекс проиндексировал страницы вида > /category/subcategory// > Теперь пытаюсь убрать такие ссылки 302 редиректом (убрать 2 и более > слеша на конце) > if ($request_uri ~ "^(.+)/{2,}$"){ > rewrite "^(.+)/{2,}$" $1 permanent; > } > Не выходит > if ($request_uri ~ "^(.*)/+$"){ > rewrite "^(.*)/+$" $1 permanent; > } А дописать слеш в реврайт - не вариант? Вам надо такой if (протестировано) : if ($request_uri ~ "^(.*)//+$"){ rewrite "^(.*)/+$" $1/ permanent; } Кроме того: http://wiki.nginx.org/IfIsEvil и надо написать как-то так (не проверено) (требуется 0.8.42+) location ~* ^(?.*/)/+$ { return 302 $varname; } http://nginx.org/ru/docs/http/ngx_http_core_module.html#merge_slashes > Обрезает все слеши , так как модификатор + эквивалент {1,} но мне бы > хотелось {2,} почему такая запись не работает ? > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Pavel mailto:pavel2000 at ngs.ru From miptpatriot at gmail.com Mon Sep 10 06:49:45 2012 From: miptpatriot at gmail.com (koka miptpatriot) Date: Mon, 10 Sep 2012 10:49:45 +0400 Subject: =?UTF-8?B?0LTQstC+0LnQvdC+0Lkg0LrRjdGI?= Message-ID: Здравствуйте. На сервере есть небольшой ssd-диск и большой hdd-диск. Хочется чтобы nginx вначале глядел в кэш на ssd, если не найдёт там, то в кэш на hdd, если не найдёт там, то в обращался к апачу. Пока придумал только такой неэлементарный вариант: server { listen 80; location /cache { proxy_cache ssd; proxy_pass http://localhost:81; } } server { listen 81; location /cache { proxy_cache hdd; proxy_pass http://apache; } } Может можно как-то сделать это без поднятия nginx на ещё одном порту? -------------- next part -------------- An HTML attachment was scrubbed... URL: From universite at ukr.net Mon Sep 10 07:08:33 2012 From: universite at ukr.net (Vladislav V. Prodan) Date: Mon, 10 Sep 2012 10:08:33 +0300 Subject: =?UTF-8?B?UmU6INCY0YHRhdC+0LTRj9GJ0LjQtSDRgdC+0LXQtNC40LXQvdC10L3QuNGPINC+?= =?UTF-8?B?0YIg0YDQtdCw0LvRjNC90L7Qs9C+IGlwINC60LvQuNC10L3RgtCwLg==?= In-Reply-To: References: Message-ID: <504D91F1.1010504@ukr.net> 06.09.2012 15:08, Николай Зайцев пишет: > Работает. Но сами tcp пакеты уходят от ip самого сервера NGINX. Nginx > умеет отправлять исходящие пакеты от ip клиента, а не от ip сервера? > Хочу ,чтобы к конечному адресату приходил пакет от реального ip > клиента,который послал запрос. Надо патчить ОС или иметь активное оборудование с поддержкой этой фичи. Не помню название, но родилось это в Yahoo и код есть в паблике. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From slava.kokorin at gmail.com Mon Sep 10 09:23:36 2012 From: slava.kokorin at gmail.com (Slava Kokorin) Date: Mon, 10 Sep 2012 13:23:36 +0400 Subject: =?UTF-8?B?UmU6INC00LLQvtC50L3QvtC5INC60Y3RiA==?= In-Reply-To: References: Message-ID: 10 сентября 2012 г., 10:49 пользователь koka miptpatriot написал: > Здравствуйте. > > На сервере есть небольшой ssd-диск и большой hdd-диск. Хочется чтобы nginx > вначале глядел в кэш на ssd, если не найдёт там, то в кэш на hdd, если не > найдёт там, то в обращался к апачу. > Пока придумал только такой неэлементарный вариант: > > server { > listen 80; > location /cache { > proxy_cache ssd; > proxy_pass http://localhost:81; > } > } > > server { > listen 81; > location /cache { > proxy_cache hdd; > proxy_pass http://apache; > } > } > > Может можно как-то сделать это без поднятия nginx на ещё одном порту? да, удавалось. Конфиг был при этом примерно такой (здесь только один диск с кешем, второй можно прикрутить по аналогии): location / { root /cache; try_files $uri @origin; open_file_cache_errors off; } location @origin { proxy_pass http://origin_IP; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_store on; proxy_store_access user:rw group:rw all:r; proxy_temp_path /cache/temp; ## On same fs where root for fast mv root /cache; } > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Slava From nginx-forum at nginx.us Mon Sep 10 09:53:39 2012 From: nginx-forum at nginx.us (Darwin) Date: Mon, 10 Sep 2012 05:53:39 -0400 Subject: =?UTF-8?B?0J/QtdGA0LXQvdC+0YEg0L/RgNCw0LLQuNC7INGBIEFwYWNoZSDQtNC70Y8gbmdp?= =?UTF-8?B?bng=?= Message-ID: <9eca08a3faa68d36c140c03378938863.NginxMailingListRussian@forum.nginx.org> Привет всем. Помогите пожалуйста правильно конвертировать правила для NGINX, так как со стандартного конверта они не работают =( ### Редиректы с site.ru/category/index.php на site.ru/category/ и др. RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} (.*) index\.php$ RewriteRule ^(.*) index\.php$ $1 [R=301,L] ### Редиректы с index.php на сайт RewriteBase / RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/ RewriteRule ^index\.php$ / [R=301,L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230604,230604#msg-230604 From voron at amhost.net Mon Sep 10 10:03:48 2012 From: voron at amhost.net (Alex Vorona) Date: Mon, 10 Sep 2012 13:03:48 +0300 Subject: =?UTF-8?B?UmU6INC00LLQvtC50L3QvtC5INC60Y3RiA==?= In-Reply-To: References: Message-ID: <504DBB04.2040303@amhost.net> try_files для проверки наличия ответа в proxy_cache использовать вряд ли получится. Да и чем настолько плох вариант с двойным проксированием(например не через tcp, а через unix-сокет), чтобы его не использовать? From a.vasilishin at kpi.ua Mon Sep 10 10:04:14 2012 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Mon, 10 Sep 2012 13:04:14 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QvtGBINC/0YDQsNCy0LjQuyDRgSBBcGFjaGUg0LTQu9GP?= =?UTF-8?B?IG5naW54?= In-Reply-To: <9eca08a3faa68d36c140c03378938863.NginxMailingListRussian@forum.nginx.org> References: <9eca08a3faa68d36c140c03378938863.NginxMailingListRussian@forum.nginx.org> Message-ID: <504DBB1E.3090008@kpi.ua> 10.09.2012 12:53, Darwin пишет: > Привет всем. Помогите пожалуйста правильно конвертировать правила для NGINX, > так как со стандартного конверта они не работают =( > > ### Редиректы с site.ru/category/index.php на site.ru/category/ и др. > RewriteCond %{REQUEST_FILENAME} !-f > RewriteCond %{REQUEST_FILENAME} !-d > RewriteCond %{REQUEST_URI} (.*) index\.php$ > RewriteRule ^(.*) index\.php$ $1 [R=301,L] > > ### Редиректы с index.php на сайт > RewriteBase / > RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/ > RewriteRule ^index\.php$ / [R=301,L] > RewriteCond %{REQUEST_FILENAME} !-f > RewriteCond %{REQUEST_FILENAME} !-d > RewriteRule . /index.php [L] http://nginx.org/en/docs/http/converting_rewrite_rules.html#converting_mongrel_rules к примеру конструкция RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ ./index.php в нгинкс выглядит так: try_files $uri $uri/ /index.php; -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From miptpatriot at gmail.com Mon Sep 10 10:18:58 2012 From: miptpatriot at gmail.com (koka miptpatriot) Date: Mon, 10 Sep 2012 14:18:58 +0400 Subject: =?UTF-8?B?UmU6INC00LLQvtC50L3QvtC5INC60Y3RiA==?= In-Reply-To: References: Message-ID: 10 сентября 2012 г., 13:23 пользователь Slava Kokorin < slava.kokorin at gmail.com> написал: > 10 сентября 2012 г., 10:49 пользователь koka miptpatriot > написал: > > Здравствуйте. > > > > На сервере есть небольшой ssd-диск и большой hdd-диск. Хочется чтобы > nginx > > вначале глядел в кэш на ssd, если не найдёт там, то в кэш на hdd, если не > > найдёт там, то в обращался к апачу. > > Пока придумал только такой неэлементарный вариант: > > > > server { > > listen 80; > > location /cache { > > proxy_cache ssd; > > proxy_pass http://localhost:81; > > } > > } > > > > server { > > listen 81; > > location /cache { > > proxy_cache hdd; > > proxy_pass http://apache; > > } > > } > > > > Может можно как-то сделать это без поднятия nginx на ещё одном порту? > > да, удавалось. Конфиг был при этом примерно такой (здесь только один > диск с кешем, второй можно прикрутить по аналогии): > > location / { > root /cache; > try_files $uri @origin; > open_file_cache_errors off; > } > > location @origin { > proxy_pass http://origin_IP; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > > proxy_store on; > proxy_store_access user:rw group:rw all:r; > > proxy_temp_path /cache/temp; ## On same fs where root > for fast mv > root /cache; > } > > > у proxy_store есть минус в том, что нельзя задать максимальный размер кеша. -------------- next part -------------- An HTML attachment was scrubbed... URL: From miptpatriot at gmail.com Mon Sep 10 10:21:38 2012 From: miptpatriot at gmail.com (koka miptpatriot) Date: Mon, 10 Sep 2012 14:21:38 +0400 Subject: =?UTF-8?B?UmU6INC00LLQvtC50L3QvtC5INC60Y3RiA==?= In-Reply-To: <504DBB04.2040303@amhost.net> References: <504DBB04.2040303@amhost.net> Message-ID: В моей схеме смущает дополнительное соединение и оверхед, связанный с ним. Или вы считаете он будет минимальным? 10 сентября 2012 г., 14:03 пользователь Alex Vorona написал: > try_files для проверки наличия ответа в proxy_cache использовать вряд ли > получится. > Да и чем настолько плох вариант с двойным проксированием(например не через > tcp, а через > unix-сокет), чтобы его не использовать? > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- skype: miptpatriot -------------- next part -------------- An HTML attachment was scrubbed... URL: From voron at amhost.net Mon Sep 10 11:04:35 2012 From: voron at amhost.net (Alex Vorona) Date: Mon, 10 Sep 2012 14:04:35 +0300 Subject: =?UTF-8?B?UmU6INC00LLQvtC50L3QvtC5INC60Y3RiA==?= In-Reply-To: References: <504DBB04.2040303@amhost.net> Message-ID: <504DC943.60805@amhost.net> 10.09.2012 13:21, koka miptpatriot wrote: > В моей схеме смущает дополнительное соединение и оверхед, связанный с ним. > Или вы считаете он будет минимальным? на фоне дисков - скорее всего да. From senty at yandex.ru Mon Sep 10 11:35:37 2012 From: senty at yandex.ru (=?koi8-r?B?98nUwczJyiDzxc7U0cvP1w==?=) Date: Mon, 10 Sep 2012 15:35:37 +0400 Subject: =?UTF-8?B?0J/RgNC40L3Rg9C00LjRgtC10LvRjNC90L7QtSDRgdC60LDRh9C40LLQsNC90Lg=?= =?UTF-8?B?0LUg0YTQsNC50LvQvtCy?= Message-ID: <19981347276937@web17g.yandex.ru> Доброго времени суток! Необходимо принудительно скачать файлы определенного типа xlsx и docx, как это сделать? ------------------------------------------- Виталий Сентяков Веб-мастер дизайн-студии ?BLEND? Сайт: www.blend.bz Моя почта: senty at blend.bz Тел.: +7 (950) 165-61-16 / Skype: senty.pro From a.vasilishin at kpi.ua Mon Sep 10 11:40:07 2012 From: a.vasilishin at kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Mon, 10 Sep 2012 14:40:07 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQuNC90YPQtNC40YLQtdC70YzQvdC+0LUg0YHQutCw0YfQuNCy0LA=?= =?UTF-8?B?0L3QuNC1INGE0LDQudC70L7Qsg==?= In-Reply-To: <19981347276937@web17g.yandex.ru> References: <19981347276937@web17g.yandex.ru> Message-ID: <504DD197.2060605@kpi.ua> 10.09.2012 14:35, Виталий Сентяков пишет: > Доброго времени суток! > > Необходимо принудительно скачать файлы определенного типа xlsx и docx, как это сделать? http://ru.wikipedia.org/wiki/%D0%A4%D0%B8%D0%B7%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%B8%D0%BB%D0%B8_%D0%BF%D1%81%D0%B8%D1%85%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%BF%D1%80%D0%B8%D0%BD%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5 наверное легче всего с помощью паяльника -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From nginx-forum at nginx.us Mon Sep 10 11:44:05 2012 From: nginx-forum at nginx.us (Darwin) Date: Mon, 10 Sep 2012 07:44:05 -0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QvtGBINC/0YDQsNCy0LjQuyDRgSBBcGFjaGUg0LTQu9GP?= =?UTF-8?B?IG5naW54?= In-Reply-To: <504DBB1E.3090008@kpi.ua> References: <504DBB1E.3090008@kpi.ua> Message-ID: <277d279c0db5ef6f5366089cb55b9990.NginxMailingListRussian@forum.nginx.org> Андрей Василишин Wrote: ------------------------------------------------------- > 10.09.2012 12:53, Darwin пишет: > > Привет всем. Помогите пожалуйста правильно конвертировать правила > для NGINX, > > так как со стандартного конверта они не работают =( > > > > ### Редиректы с site.ru/category/index.php на site.ru/category/ и > др. > > RewriteCond %{REQUEST_FILENAME} !-f > > RewriteCond %{REQUEST_FILENAME} !-d > > RewriteCond %{REQUEST_URI} (.*) index\.php$ > > RewriteRule ^(.*) index\.php$ $1 [R=301,L] > > > > ### Редиректы с index.php на сайт > > RewriteBase / > > RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/ > > RewriteRule ^index\.php$ / [R=301,L] > > RewriteCond %{REQUEST_FILENAME} !-f > > RewriteCond %{REQUEST_FILENAME} !-d > > RewriteRule . /index.php [L] > > > http://nginx.org/en/docs/http/converting_rewrite_rules.html#converting > _mongrel_rules > > к примеру конструкция > > RewriteCond %{REQUEST_FILENAME} !-f > RewriteCond %{REQUEST_FILENAME} !-d > RewriteRule ^(.*)$ ./index.php > > в нгинкс выглядит так: > > try_files $uri $uri/ /index.php; > > > -- > WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Трудно что либо понять... ну да ладно, разберемся... А как тогда такой код перевести? RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/ Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230604,230615#msg-230615 From igor at sysoev.ru Mon Sep 10 12:43:39 2012 From: igor at sysoev.ru (Igor Sysoev) Date: Mon, 10 Sep 2012 16:43:39 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QvtGBINC/0YDQsNCy0LjQuyDRgSBBcGFjaGUg0LTQu9GP?= =?UTF-8?B?IG5naW54?= In-Reply-To: <277d279c0db5ef6f5366089cb55b9990.NginxMailingListRussian@forum.nginx.org> References: <504DBB1E.3090008@kpi.ua> <277d279c0db5ef6f5366089cb55b9990.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120910124339.GA7429@nginx.com> On Mon, Sep 10, 2012 at 07:44:05AM -0400, Darwin wrote: > Андрей Василишин Wrote: > ------------------------------------------------------- > > 10.09.2012 12:53, Darwin пишет: > > > Привет всем. Помогите пожалуйста правильно конвертировать правила > > для NGINX, > > > так как со стандартного конверта они не работают =( > > > > > > ### Редиректы с site.ru/category/index.php на site.ru/category/ и > > др. > > > RewriteCond %{REQUEST_FILENAME} !-f > > > RewriteCond %{REQUEST_FILENAME} !-d > > > RewriteCond %{REQUEST_URI} (.*) index\.php$ > > > RewriteRule ^(.*) index\.php$ $1 [R=301,L] > > > > > > ### Редиректы с index.php на сайт > > > RewriteBase / > > > RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/ > > > RewriteRule ^index\.php$ / [R=301,L] > > > RewriteCond %{REQUEST_FILENAME} !-f > > > RewriteCond %{REQUEST_FILENAME} !-d > > > RewriteRule . /index.php [L] > > > > > > http://nginx.org/en/docs/http/converting_rewrite_rules.html#converting > > _mongrel_rules > > > > к примеру конструкция > > > > RewriteCond %{REQUEST_FILENAME} !-f > > RewriteCond %{REQUEST_FILENAME} !-d > > RewriteRule ^(.*)$ ./index.php > > > > в нгинкс выглядит так: > > > > try_files $uri $uri/ /index.php; > > Трудно что либо понять... ну да ладно, разберемся... Понять действительно трудно. Например, что должно делать вот это: RewriteCond %{REQUEST_URI} (.*) index\.php$ при том, что параметров у RewriteCond - два. К чему "index\.php$" Может быть там "(.*)/index\.php$" ? Тогда как-то так: location / { try_files $uri $uri/ @fastcgi; } location ~ "^(?.*/)index\.php$" { internal; error_page 404 =301 http://$host$DIR; fastcgi_pass ... ... } location @fastcgi { fastcgi_pass ... ... } -- Igor Sysoev From nginx-forum at nginx.us Mon Sep 10 17:24:51 2012 From: nginx-forum at nginx.us (flattr) Date: Mon, 10 Sep 2012 13:24:51 -0400 Subject: =?UTF-8?B?0KHQutCw0YfQuNCy0LDQtdGCINGE0LDQudC70Ysg0L/RgNC4INGA0LXQstGA0LA=?= =?UTF-8?B?0LnRgtC1?= Message-ID: Уважаемые знатоки, подскажите, почему nginx+php-fpm при обращении какому-то файлу по реврайту скачивает его, а не выполняет его? Если обращаться к php файлам напрямую, не через реврайт, то все работает чудесно. Мой .conf: server { listen *:80; server_name site.com www.site.com; root /var/www/site.com/web; index index.html index.htm index.php index.cgi index.pl index.xhtml; location /faq { rewrite ^/faq/([_A-Za-z0-9-]+)/?$ /index.php?modules=faq&category=$1 break; } location ~ \.php$ { try_files $uri =404; include /etc/nginx/fastcgi_params; fastcgi_pass 127.0.0.1:9010; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_intercept_errors on; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230629,230629#msg-230629 From ne at vbart.ru Mon Sep 10 17:48:47 2012 From: ne at vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 10 Sep 2012 21:48:47 +0400 Subject: =?UTF-8?B?UmU6INCh0LrQsNGH0LjQstCw0LXRgiDRhNCw0LnQu9GLINC/0YDQuCDRgNC10LI=?= =?UTF-8?B?0YDQsNC50YLQtQ==?= In-Reply-To: References: Message-ID: <201209102148.48012.ne@vbart.ru> On Monday 10 September 2012 21:24:51 flattr wrote: > Уважаемые знатоки, подскажите, почему nginx+php-fpm при обращении какому-то > файлу по реврайту скачивает его, а не выполняет его? Если обращаться к php > файлам напрямую, не через реврайт, то все работает чудесно. [...] > location /faq { > rewrite ^/faq/([_A-Za-z0-9-]+)/?$ /index.php?modules=faq&category=$1 > break; > } > А с какой целью вы break написали? Что написали - то и получили. http://nginx.org/r/rewrite/ru -- Валентин Бартенев From postmaster at softsearch.ru Tue Sep 11 11:48:11 2012 From: postmaster at softsearch.ru (=?Windows-1251?B?zOj14OjrIMzu7eD4uOI=?=) Date: Tue, 11 Sep 2012 15:48:11 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQuNC90YPQtNC40YLQtdC70YzQvdC+0LUg0YHQutCw0YfQuNCy0LA=?= =?UTF-8?B?0L3QuNC1INGE0LDQudC70L7Qsg==?= In-Reply-To: <19981347276937@web17g.yandex.ru> References: <19981347276937@web17g.yandex.ru> Message-ID: <1709812982.20120911154811@softsearch.ru> Здравствуйте, Виталий. > Необходимо принудительно скачать файлы определенного типа xlsx и docx, как это сделать? Выдавать заголовок Content-Disposition: attachment; -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Wed Sep 12 11:06:45 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 12 Sep 2012 15:06:45 +0400 Subject: nginx-1.3.6 Message-ID: <20120912110645.GG40452@mdounin.ru> Изменения в nginx 1.3.6 12.09.2012 *) Добавление: модуль ngx_http_gunzip_filter_module. *) Добавление: директива memcached_gzip_flag. *) Добавление: параметр always директивы gzip_static. *) Исправление: в директиве "limit_req"; ошибка появилась в 1.1.14. Спасибо Charles Chen. *) Исправление: nginx не собирался gcc 4.7 с оптимизацией -O2 если использовался параметр --with-ipv6. Maxim Dounin From postmaster at softsearch.ru Wed Sep 12 12:22:26 2012 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 12 Sep 2012 16:22:26 +0400 Subject: nginx-1.3.6 In-Reply-To: <20120912110645.GG40452@mdounin.ru> References: <20120912110645.GG40452@mdounin.ru> Message-ID: <1509390420.20120912162226@softsearch.ru> Здравствуйте, Maxim. > *) Добавление: модуль ngx_http_gunzip_filter_module. > *) Добавление: директива memcached_gzip_flag. Ура! Теперь можно в мемкешеде хранить сжатые данные и nginx отдаст их правильно. -- С уважением, Михаил mailto:postmaster at softsearch.ru From gmm at csdoc.com Wed Sep 12 12:58:52 2012 From: gmm at csdoc.com (Gena Makhomed) Date: Wed, 12 Sep 2012 15:58:52 +0300 Subject: "always" parameter in "gzip_static" directive Message-ID: <5050870C.9090803@csdoc.com> On 10.09.2012 19:48, in nginx-devel Maxim Dounin wrote: > Gzip static: "always" parameter in "gzip_static" directive. > With "always" gzip static returns gzipped content in all cases, > without checking if client supports it. > It is useful if there are no uncompressed files on disk anyway. если клиент говорит что не понимает compressed ответы и на диске нет uncompressed files - почему в этом случае нельзя отдать uncompressed ответ, пропустив compressed files перед отдачей клиенту через ngx_http_gunzip_filter_module ? так было бы более корректно с точки зрения RFC, (?) потому что обычно, если клиент говорит что не понимает compressed ответ - он его действительно не понимает... тогда вообще не надо было бы добавлять новый параметр "always" к директиве "gzip_static" и nginx всегда работал бы корректно. -- Best regards, Gena From mdounin at mdounin.ru Wed Sep 12 14:02:55 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 12 Sep 2012 18:02:55 +0400 Subject: "always" parameter in "gzip_static" directive In-Reply-To: <5050870C.9090803@csdoc.com> References: <5050870C.9090803@csdoc.com> Message-ID: <20120912140255.GJ40452@mdounin.ru> Hello! On Wed, Sep 12, 2012 at 03:58:52PM +0300, Gena Makhomed wrote: > On 10.09.2012 19:48, in nginx-devel Maxim Dounin wrote: > > > Gzip static: "always" parameter in "gzip_static" directive. > > With "always" gzip static returns gzipped content in all cases, > > without checking if client supports it. > > It is useful if there are no uncompressed files on disk anyway. > > если клиент говорит что не понимает compressed ответы > и на диске нет uncompressed files - почему в этом случае > нельзя отдать uncompressed ответ, пропустив compressed files > перед отдачей клиенту через ngx_http_gunzip_filter_module ? Можно - для этого достаточно включить gunzip. Делать подобное включение автоматическим - это, с моей точки зрения, типичный случай layering violation. > так было бы более корректно с точки зрения RFC, (?) > потому что обычно, если клиент говорит что не понимает > compressed ответ - он его действительно не понимает... > > тогда вообще не надо было бы добавлять новый параметр "always" > к директиве "gzip_static" и nginx всегда работал бы корректно. С точки зрения RFC - заголовок Content-Encoding говорит о encoding'е возвращаемого документа (entity). Возврат разных документов (с разным encoding'ом) в зависимости от того, что клиент указывает в заголовке Accept-Encoding, суть один из возможных вариантов реакции на предпочтения клиентов. Если других вариатов документа нет - никто не машет вернуть документ в том виде, в котором есть. Часто встречающимся примером аналогичного поведения является возврат документа на том языке, на котором он есть, без перевода на один из языков, указанных клиентом в заголовке Accept-Language. Или возврат документов в том формате (и с тем Content-Type), в котором они лежат на сервер, вне зависимости от полученного от клиента заголовка Accept. Подробнее о всём этом с точки зрения RFC можно прочитать собственно в самом RFC 2616: http://tools.ietf.org/html/rfc2616#section-12 Maxim Dounin From marck at rinet.ru Wed Sep 12 17:42:06 2012 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed, 12 Sep 2012 21:42:06 +0400 (MSK) Subject: SSL handshake error Message-ID: Други, что-то мы тупим совокупно с коллегами по работе. Имеется личный кабинет на https://ctl.rinet.ru/ с сертификатом от RapidSSL *Некоторое* количество клиентов с виндой не могут туда прицепиться. openssl s_client показывает дамп сертификата и дальше не идёт. Попытки дебажить приводят к вот таким строкам в debug log: 2012/09/12 21:34:04 [debug] 42238#0: *4798 http check ssl handshake 2012/09/12 21:34:04 [debug] 42238#0: *4798 https ssl handshake: 0x16 2012/09/12 21:34:04 [debug] 42238#0: *4798 SSL_do_handshake: -1 2012/09/12 21:34:04 [debug] 42238#0: *4798 SSL_get_error: 2 И так висит, пока со стороны клиента не прервать. В случае браузера последние строки в дебаге те же. Any hints/links? Заранее спасибо. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck at FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From dan at onliner.by Thu Sep 13 10:48:00 2012 From: dan at onliner.by (Daniil) Date: Thu, 13 Sep 2012 13:48:00 +0300 Subject: =?UTF-8?Q?Allow=2C_deny_=D0=B8_error=5Fpage_403?= Message-ID: Здравствуйте, При проведении технических работ на сайте обычно пользовались следующей конструкцией: allow 1.2.3.0/24; deny all; потом заходили с 1.2.3.0/24 и тестировали. Все остальные посетители в это время видели "403 Forbidden". Затем решили добавить страницу "Сайт временно недоступен. Извините..." При добавлении строк: error_page 403 = @maint; location @maint { proxy_set_header maint.server.com; proxy_pass http://maint.server.com; } nginx все равно возвращает "403 forbidden". Однако, если сделать например так: location @maint { return 302 http://maint.server.com; } то происходит редирект. Скажите, в чем ошибка? Или это особенность реализации директивы deny и error_page? Версия nginx 1.3.6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kav at karagodov.name Thu Sep 13 11:27:31 2012 From: kav at karagodov.name (Alexey V. Karagodov) Date: Thu, 13 Sep 2012 15:27:31 +0400 Subject: =?UTF-8?Q?Re=3A_Allow=2C_deny_=D0=B8_error=5Fpage_403?= In-Reply-To: References: Message-ID: <366538FB-54FC-4FC5-8433-6A9BD702C42F@karagodov.name> у меня работает вот так: www:~ # cat /opt/nginx/conf/include/location/error_page_lite location @error_page_403 { include include/template/no-logging; satisfy any; allow all; root /local/www/vhosts/service/error; try_files /$host/403.html /$host/index.html /403.html /index.html =403; } location @error_page_497 { include include/template/no-logging; root /dev/null; rewrite ^ https://$host$request_uri? permanent; } location @error_page_lite { include include/template/no-logging; root /local/www/vhosts/service/error; try_files /$host/index.html /index.html =404; } www:~ # On 13.09.2012, at 14:48, Daniil wrote: > Здравствуйте, > > При проведении технических работ на сайте обычно пользовались следующей конструкцией: > > allow 1.2.3.0/24; > deny all; > > потом заходили с 1.2.3.0/24 и тестировали. Все остальные посетители в это время видели "403 Forbidden". > Затем решили добавить страницу "Сайт временно недоступен. Извините..." > > При добавлении строк: > > error_page 403 = @maint; > location @maint { > proxy_set_header maint.server.com; > proxy_pass http://maint.server.com; > } > > nginx все равно возвращает "403 forbidden". > > Однако, если сделать например так: > > location @maint { > return 302 http://maint.server.com; > } > > то происходит редирект. > > Скажите, в чем ошибка? Или это особенность реализации директивы deny и error_page? > > Версия nginx 1.3.6 > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at onliner.by Thu Sep 13 11:40:40 2012 From: dan at onliner.by (Daniil) Date: Thu, 13 Sep 2012 14:40:40 +0300 Subject: =?UTF-8?Q?Re=3A_Allow=2C_deny_=D0=B8_error=5Fpage_403?= In-Reply-To: <366538FB-54FC-4FC5-8433-6A9BD702C42F@karagodov.name> References: <366538FB-54FC-4FC5-8433-6A9BD702C42F@karagodov.name> Message-ID: Спасибо! По логике вашего конфига разобрался. Не хватало директивы "allow all". В итоге получился такой сниппет, который можно включить в любой server {...}: allow 1.2.3.0/24; deny all; error_page 403 = @maint; location @maint { allow all; proxy_set_header maint.server.com; proxy_pass http://main.server.com; } 13 сентября 2012 г., 14:27 пользователь Alexey V. Karagodov < kav at karagodov.name> написал: > у меня работает вот так: > > www:~ # cat /opt/nginx/conf/include/location/error_page_lite > location @error_page_403 { > include include/template/no-logging; > satisfy any; > allow all; > root /local/www/vhosts/service/error; > try_files /$host/403.html /$host/index.html /403.html /index.html > =403; > } > location @error_page_497 { > include include/template/no-logging; > root /dev/null; > rewrite ^ https://$host$request_uri? permanent; > } > location @error_page_lite { > include include/template/no-logging; > root /local/www/vhosts/service/error; > try_files /$host/index.html /index.html =404; > } > www:~ # > > > On 13.09.2012, at 14:48, Daniil wrote: > > Здравствуйте, > > При проведении технических работ на сайте обычно пользовались следующей > конструкцией: > > allow 1.2.3.0/24; > deny all; > > потом заходили с 1.2.3.0/24 и тестировали. Все остальные посетители в это > время видели "403 Forbidden". > Затем решили добавить страницу "Сайт временно недоступен. Извините..." > > При добавлении строк: > > error_page 403 = @maint; > location @maint { > proxy_set_header maint.server.com; > proxy_pass http://maint.server.com; > } > > nginx все равно возвращает "403 forbidden". > > Однако, если сделать например так: > > location @maint { > return 302 http://maint.server.com; > } > > то происходит редирект. > > Скажите, в чем ошибка? Или это особенность реализации директивы deny и > error_page? > > Версия nginx 1.3.6 > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- С уважением, Даниил Болсун системный администратор Onliner.by тел/факс. +375 17 2271696 тел. +375 29 7755080 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu Sep 13 13:11:54 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 13 Sep 2012 17:11:54 +0400 Subject: SSL handshake error In-Reply-To: References: Message-ID: <20120913131154.GQ40452@mdounin.ru> Hello! On Wed, Sep 12, 2012 at 09:42:06PM +0400, Dmitry Morozovsky wrote: > Други, > > что-то мы тупим совокупно с коллегами по работе. > > Имеется личный кабинет на https://ctl.rinet.ru/ с сертификатом от RapidSSL > > *Некоторое* количество клиентов с виндой не могут туда прицепиться. > openssl s_client показывает дамп сертификата и дальше не идёт. Не вижу никаких проблем с openssl'ом: $ openssl s_client -connect ctl.rinet.ru:443 ... HEAD / HTTP/1.0 HTTP/1.1 200 OK Server: nginx/1.1.17 Date: Thu, 13 Sep 2012 12:59:15 GMT ... Tested with: OpenSSL 0.9.7e-p1 25 Oct 2004 OpenSSL 1.0.0d 8 Feb 2011 OpenSSL 1.0.1c 10 May 2012 > Попытки дебажить приводят к вот таким строкам в debug log: > > 2012/09/12 21:34:04 [debug] 42238#0: *4798 http check ssl handshake > 2012/09/12 21:34:04 [debug] 42238#0: *4798 https ssl handshake: 0x16 > 2012/09/12 21:34:04 [debug] 42238#0: *4798 SSL_do_handshake: -1 > 2012/09/12 21:34:04 [debug] 42238#0: *4798 SSL_get_error: 2 > > И так висит, пока со стороны клиента не прервать. В случае браузера последние > строки в дебаге те же. > > Any hints/links? > > Заранее спасибо. SSL_get_error: 2 == SSL_ERROR_WANT_READ, ждём данных от клиента. Я бы смотрел на сеть WireShark'ом, он хорошо SSL разбирает. Но может быть проблема совсем банальная, и e.g. большие пакеты местами не пролезают? Maxim Dounin From nginx-forum at nginx.us Thu Sep 13 13:47:04 2012 From: nginx-forum at nginx.us (Vilgelm) Date: Thu, 13 Sep 2012 09:47:04 -0400 Subject: =?UTF-8?B?0KDQsNC30L3Ri9C1IENNUyDRgSDRgNCw0LfQvdGL0LzQuCByZXdyaXRlIHJ1bGVz?= =?UTF-8?B?INCyINC00LjRgNC10LrRgtC+0YDQuNGP0YUg0L7QtNC90L7Qs9C+INC00L4=?= =?UTF-8?B?0LzQtdC90LA=?= Message-ID: <89d2ed2a55e7d8ba7f4b7941dd91184b.NginxMailingListRussian@forum.nginx.org> Доброго времени суток. Есть домен domain.tld. Там установлена Joomla со включенным SEF. В конфиге nginx для SEF предназначены такие строки (это официальная конфигурация Joomla для nginx): location / { try_files $uri $uri/ /index.php?q=$uri&$args; } Есть domain.ltd/livestreet. Там установлена LiveStreet CMS со включенным SEF. В конфиге так: location /livestreet/ { root /путь/до/папки/с/livestreet; if (!-e $request_filename){ rewrite ^(.*)$ /index.php last; } } Если я захожу по адресу domain.ltd/livestreet, то вижу главную страницу движка (т.е. все работает). Однако стоит мне перейти по адресу domain.ltd/livestreet/blogs или подобному, я вижу 404 ошибку Joomla. Т.е. все после livestreet/ обрабатывается правилом для Joomla. Вопрос: как это исправить? Т.е. нужно что бы все, что находится после domain.ltd/livestreet обрабатывалось правилом для livestreet. Понимаю, что изврат, но требуется сделать именно так. Заранее огромное спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230695,230695#msg-230695 From a.vasilishin at kpi.ua Thu Sep 13 13:59:44 2012 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 13 Sep 2012 16:59:44 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQtSBDTVMg0YEg0YDQsNC30L3Ri9C80LggcmV3cml0ZSBy?= =?UTF-8?B?dWxlcyDQsiDQtNC40YDQtdC60YLQvtGA0LjRj9GFINC+0LTQvdC+0LPQviA=?= =?UTF-8?B?0LTQvtC80LXQvdCw?= In-Reply-To: <89d2ed2a55e7d8ba7f4b7941dd91184b.NginxMailingListRussian@forum.nginx.org> References: <89d2ed2a55e7d8ba7f4b7941dd91184b.NginxMailingListRussian@forum.nginx.org> Message-ID: <5051E6D0.9070903@kpi.ua> 13.09.2012 16:47, Vilgelm пишет: > Доброго времени суток. > > Есть домен domain.tld. Там установлена Joomla со включенным SEF. В конфиге > nginx для SEF предназначены такие строки (это официальная конфигурация > Joomla для nginx): > > location / { > try_files $uri $uri/ /index.php?q=$uri&$args; > } > > Есть domain.ltd/livestreet. Там установлена LiveStreet CMS со включенным > SEF. В конфиге так: > > location /livestreet/ { > root /путь/до/папки/с/livestreet; > > if (!-e $request_filename){ > rewrite ^(.*)$ /index.php last; > } > } > > Если я захожу по адресу domain.ltd/livestreet, то вижу главную страницу > движка (т.е. все работает). Однако стоит мне перейти по адресу > domain.ltd/livestreet/blogs или подобному, я вижу 404 ошибку Joomla. Т.е. > все после livestreet/ обрабатывается правилом для Joomla. > > Вопрос: как это исправить? Т.е. нужно что бы все, что находится после > domain.ltd/livestreet обрабатывалось правилом для livestreet. > > Понимаю, что изврат, но требуется сделать именно так. > > Заранее огромное спасибо. > Первое, в документации есть прекрасные примеры http://nginx.org/ru/docs/http/ngx_http_core_module.html#location Второе, для лайстврит правильнее будет location ^~ /livestreet/ { try_files $uri $uri/ /index.php?$args; } -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From nginx-forum at nginx.us Thu Sep 13 14:07:31 2012 From: nginx-forum at nginx.us (Vilgelm) Date: Thu, 13 Sep 2012 10:07:31 -0400 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQtSBDTVMg0YEg0YDQsNC30L3Ri9C80LggcmV3cml0ZSBy?= =?UTF-8?B?dWxlcyDQsiDQtNC40YDQtdC60YLQvtGA0LjRj9GFINC+0LTQvdC+0LPQviA=?= =?UTF-8?B?0LTQvtC80LXQvdCw?= In-Reply-To: <5051E6D0.9070903@kpi.ua> References: <5051E6D0.9070903@kpi.ua> Message-ID: Спасибо! Сейчас, правда, на заходе на главную страницу выдается Start('full_time'); $oRouter=Router::getInstance(); $oRouter->Exec(); $oProfiler->Stop($iTimeId); ?> но это, видимо, уже проблемы с движком. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230695,230699#msg-230699 From marck at rinet.ru Thu Sep 13 14:12:16 2012 From: marck at rinet.ru (Dmitry Morozovsky) Date: Thu, 13 Sep 2012 18:12:16 +0400 (MSK) Subject: SSL handshake error In-Reply-To: <20120913131154.GQ40452@mdounin.ru> References: <20120913131154.GQ40452@mdounin.ru> Message-ID: On Thu, 13 Sep 2012, Maxim Dounin wrote: > > что-то мы тупим совокупно с коллегами по работе. > > > > Имеется личный кабинет на https://ctl.rinet.ru/ с сертификатом от RapidSSL > > > > *Некоторое* количество клиентов с виндой не могут туда прицепиться. > > openssl s_client показывает дамп сертификата и дальше не идёт. > > Не вижу никаких проблем с openssl'ом: Да вот и я ;) > $ openssl s_client -connect ctl.rinet.ru:443 > ... > HEAD / HTTP/1.0 > > HTTP/1.1 200 OK > Server: nginx/1.1.17 > Date: Thu, 13 Sep 2012 12:59:15 GMT > ... > > Tested with: > > OpenSSL 0.9.7e-p1 25 Oct 2004 > OpenSSL 1.0.0d 8 Feb 2011 > OpenSSL 1.0.1c 10 May 2012 Так в том-то и дело, что воспроизвести получается только на развёрнутой копии клиентской винды (openssl/win32 туда поставлен руками). > > Попытки дебажить приводят к вот таким строкам в debug log: > > > > 2012/09/12 21:34:04 [debug] 42238#0: *4798 http check ssl handshake > > 2012/09/12 21:34:04 [debug] 42238#0: *4798 https ssl handshake: 0x16 > > 2012/09/12 21:34:04 [debug] 42238#0: *4798 SSL_do_handshake: -1 > > 2012/09/12 21:34:04 [debug] 42238#0: *4798 SSL_get_error: 2 > > > > И так висит, пока со стороны клиента не прервать. В случае браузера последние > > строки в дебаге те же. > > > > Any hints/links? > > > > Заранее спасибо. > > SSL_get_error: 2 == SSL_ERROR_WANT_READ, ждём данных от клиента. > Я бы смотрел на сеть WireShark'ом, он хорошо SSL разбирает. Но > может быть проблема совсем банальная, и e.g. большие пакеты > местами не пролезают? Местами не пролазят какие-то пакеты, кажется, чуть ли не вне зависимости от размера, tcpdump порой видит tcp ack на один пакет там где должно быть на два. Мистика какая-то. ОК, я получил подтверждение, что мы не совсем идиоты, спасибо, будем копать дальше ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck at FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From a.vasilishin at kpi.ua Thu Sep 13 15:00:28 2012 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 13 Sep 2012 18:00:28 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQtSBDTVMg0YEg0YDQsNC30L3Ri9C80LggcmV3cml0ZSBy?= =?UTF-8?B?dWxlcyDQsiDQtNC40YDQtdC60YLQvtGA0LjRj9GFINC+0LTQvdC+0LPQviA=?= =?UTF-8?B?0LTQvtC80LXQvdCw?= In-Reply-To: References: <5051E6D0.9070903@kpi.ua> Message-ID: <5051F50C.5030601@kpi.ua> 13.09.2012 17:07, Vilgelm пишет: > Спасибо! > > Сейчас, правда, на заходе на главную страницу выдается > Start('full_time'); $oRouter=Router::getInstance(); $oRouter->Exec(); > $oProfiler->Stop($iTimeId); ?> > но это, видимо, уже проблемы с движком. > Это проблема с обработчиком php, надо как-то так: location ^~ /livestreet/ { try_files $uri $uri/ /index.php?$args; location ~ \.php$ { proxy_pass http://backend$request_uri; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From nginx-forum at nginx.us Thu Sep 13 15:16:31 2012 From: nginx-forum at nginx.us (Vilgelm) Date: Thu, 13 Sep 2012 11:16:31 -0400 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQtSBDTVMg0YEg0YDQsNC30L3Ri9C80LggcmV3cml0ZSBy?= =?UTF-8?B?dWxlcyDQsiDQtNC40YDQtdC60YLQvtGA0LjRj9GFINC+0LTQvdC+0LPQviA=?= =?UTF-8?B?0LTQvtC80LXQvdCw?= In-Reply-To: <5051F50C.5030601@kpi.ua> References: <5051F50C.5030601@kpi.ua> Message-ID: Написал так: location ^~ /livestreet/ { try_files $uri $uri/ /index.php?$args; location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /полный/путь/до/каталога/livestreet$fastcgi_script_name; fastcgi_param DOCUMENT_ROOT /полный/путь/до/каталога/livestreet; include fastcgi_params; } } Собственно так Joomla и настроена (а еще vbulletin). Однако в случае с LiveStreet упорно пишет No input file specified. Видимо надо как-то по другому, но как? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230695,230702#msg-230702 From a.vasilishin at kpi.ua Thu Sep 13 15:20:44 2012 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Thu, 13 Sep 2012 18:20:44 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQtSBDTVMg0YEg0YDQsNC30L3Ri9C80LggcmV3cml0ZSBy?= =?UTF-8?B?dWxlcyDQsiDQtNC40YDQtdC60YLQvtGA0LjRj9GFINC+0LTQvdC+0LPQviA=?= =?UTF-8?B?0LTQvtC80LXQvdCw?= In-Reply-To: References: <5051F50C.5030601@kpi.ua> Message-ID: <5051F9CC.30701@kpi.ua> 13.09.2012 18:16, Vilgelm пишет: > Написал так: > > location ^~ /livestreet/ { > try_files $uri $uri/ /index.php?$args; > location ~ \.php$ { > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > fastcgi_param SCRIPT_FILENAME > /полный/путь/до/каталога/livestreet$fastcgi_script_name; - fastcgi_param DOCUMENT_ROOT /полный/путь/до/каталога/livestreet; + fastcgi_param DOCUMENT_ROOT /полный/путь/до/каталога; > include fastcgi_params; > } > } > > Собственно так Joomla и настроена (а еще vbulletin). Однако в случае с > LiveStreet упорно пишет No input file specified. Видимо надо как-то по > другому, но как? Ну, а вообще, раз гадаете на кофейной гуще, так гадайте правильно: http://nginx.org/ru/docs/debugging_log.html -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From nginx-forum at nginx.us Thu Sep 13 15:39:01 2012 From: nginx-forum at nginx.us (Vilgelm) Date: Thu, 13 Sep 2012 11:39:01 -0400 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQtSBDTVMg0YEg0YDQsNC30L3Ri9C80LggcmV3cml0ZSBy?= =?UTF-8?B?dWxlcyDQsiDQtNC40YDQtdC60YLQvtGA0LjRj9GFINC+0LTQvdC+0LPQviA=?= =?UTF-8?B?0LTQvtC80LXQvdCw?= In-Reply-To: References: <5051F50C.5030601@kpi.ua> Message-ID: Разобрался, надо было fastcgi_param SCRIPT_FILENAME /полный/путь/до/каталога$fastcgi_script_name; Огромное спасибо за помощь! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230695,230706#msg-230706 From nginx-forum at nginx.us Thu Sep 13 16:02:01 2012 From: nginx-forum at nginx.us (Vilgelm) Date: Thu, 13 Sep 2012 12:02:01 -0400 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQtSBDTVMg0YEg0YDQsNC30L3Ri9C80LggcmV3cml0ZSBy?= =?UTF-8?B?dWxlcyDQsiDQtNC40YDQtdC60YLQvtGA0LjRj9GFINC+0LTQvdC+0LPQviA=?= =?UTF-8?B?0LTQvtC80LXQvdCw?= In-Reply-To: <5051F9CC.30701@kpi.ua> References: <5051F9CC.30701@kpi.ua> Message-ID: <2d9d329f69c536ac17ac2d7c4037b79a.NginxMailingListRussian@forum.nginx.org> Разобрался, надо было fastcgi_param SCRIPT_FILENAME /полный/путь/до/каталога$fastcgi_script_name; Правда все вернулось к первому шагу, т.е. все, что находится под /livestreet/ перехватывается Joomla. В любом случае огромное спасибо за помощь! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230695,230709#msg-230709 From sergey.kobzar at itcraft.org Thu Sep 13 16:23:18 2012 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Thu, 13 Sep 2012 19:23:18 +0300 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQtSBDTVMg0YEg0YDQsNC30L3Ri9C80LggcmV3cml0ZSBy?= =?UTF-8?B?dWxlcyDQsiDQtNC40YDQtdC60YLQvtGA0LjRj9GFINC+0LTQvdC+0LPQviA=?= =?UTF-8?B?0LTQvtC80LXQvdCw?= In-Reply-To: References: <5051F50C.5030601@kpi.ua> Message-ID: <50520876.40006@itcraft.org> On 09/13/12 18:39, Vilgelm wrote: > Разобрался, надо было > > fastcgi_param SCRIPT_FILENAME /полный/путь/до/каталога$fastcgi_script_name; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; <- так универсальней будет если объявлен коректный $document_root естественно. From nginx-forum at nginx.us Thu Sep 13 21:45:02 2012 From: nginx-forum at nginx.us (Vilgelm) Date: Thu, 13 Sep 2012 17:45:02 -0400 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQtSBDTVMg0YEg0YDQsNC30L3Ri9C80LggcmV3cml0ZSBy?= =?UTF-8?B?dWxlcyDQsiDQtNC40YDQtdC60YLQvtGA0LjRj9GFINC+0LTQvdC+0LPQviA=?= =?UTF-8?B?0LTQvtC80LXQvdCw?= In-Reply-To: <50520876.40006@itcraft.org> References: <50520876.40006@itcraft.org> Message-ID: <621d376129c6a6547796afc43b6fa61f.NginxMailingListRussian@forum.nginx.org> Доброй ночи. Спасибо за ответ. Сейчас конфиг выглядит так, проблема не устранена: server { listen 80; server_name www.domain.ru domain.ru; server_name_in_redirect off; error_log /var/log/nginx/domain.error_log; root /var/www/vhosts/domain/domain.ru/httpdocs; index index.php; # Support Clean (aka Search Engine Friendly) URLs location / { try_files $uri $uri/ /index.php?q=$uri&$args; #rewrite для Joomla } index index.php index.html index.htm default.html default.htm; # deny running scripts inside writable directories location ~* /(images|cache|media|logs|tmp)/.*\.(php|pl|py|jsp|asp|sh|cgi)$ { return 403; error_page 403 /403_error.html; } location ~ .*.php$ { #Обработчик для Joomla root /var/www/vhosts/domain/domain.ru/httpdocs; include /etc/nginx/fastcgi.conf; fastcgi_pass 127.0.0.1:9000; # fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } # caching of files location ~* \.(ico|pdf|flv)$ { expires 1y; } location ~* \.(js|css|png|jpg|jpeg|gif|swf|xml|txt)$ { expires 14d; } location ^~/mir/ { #папка с Livestreet #try_files $uri $uri/ /index.php?q=$uri&$args; #один из вариантов rewrite if (!-e $request_filename) { #rewrite как в примере rewrite ^(/.*)$ /index.php?q=$1 last; break; } #root /var/www/vhosts/domain/domain.ru/mir; #если разкомментировать, не попаду даже на главную страницу Livestreet, будет сразу 404 от Joomla location ~ \.php$ { #Обработчик для Livestreet fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /var/www/vhosts/domain/domain.ru/httpdocs$fastcgi_script_name; fastcgi_param DOCUMENT_ROOT /var/www/vhosts/domain/domain.ru/httpdocs; include fastcgi_params; } } } Не подскажите, в чем может быть проблема? Заранее огромное спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230695,230713#msg-230713 From nginx-forum at nginx.us Fri Sep 14 08:29:21 2012 From: nginx-forum at nginx.us (Serafim) Date: Fri, 14 Sep 2012 04:29:21 -0400 Subject: =?UTF-8?B?0JjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LUg0L/QtdGA0LXQvNC10L3QvdC+0Lkg?= =?UTF-8?B?0LIgcHJveHkgcGFzcw==?= Message-ID: Почему не получается провернуть такой финт: backend возвращает пустой (без тела) ответ с двумя заголовками: X-Accel-Redirect и X-HDS-Server (кастомный, выдумал сам); в nginx'е есть location помеченный как internal; ответ от backend'а с заголовоком X-Accel-Redirect прекрасно переадресуется к данному внутреннему локейшину; в данном локейшине есть такая директива - proxy_pass $http_x_hds_server:8080; и вот тут проблема - данная переменная вместо ожидаемого значения (того, что поместил в данный заголовок backend - адрес сервера) возвращает пустую строку. пустая строка, если я правильно догадываюсь - значение по-умолчанию для несуществующих переменных, в этом случае вопрос звучит так: как правильно передать во внутренний локейшин значение от backend'а так, чтобы это значение можно было использовать в качестве сервера для proxy_pass? p.s. пробовал вместо $http_x_hds_server использовать $sent_http_x_hds_server - тоже самое. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230717,230717#msg-230717 From igor at sysoev.ru Fri Sep 14 08:31:29 2012 From: igor at sysoev.ru (Igor Sysoev) Date: Fri, 14 Sep 2012 12:31:29 +0400 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INC/0LXRgNC10LzQtdC90L0=?= =?UTF-8?B?0L7QuSDQsiBwcm94eSBwYXNz?= In-Reply-To: References: Message-ID: <54B458B4-E717-4A6D-A29E-86E92EE5B36F@sysoev.ru> On Sep 14, 2012, at 12:29 , Serafim wrote: > Почему не получается провернуть такой финт: > > backend возвращает пустой (без тела) ответ с двумя заголовками: > X-Accel-Redirect и X-HDS-Server (кастомный, выдумал сам); > в nginx'е есть location помеченный как internal; > ответ от backend'а с заголовоком X-Accel-Redirect прекрасно переадресуется к > данному внутреннему локейшину; > в данном локейшине есть такая директива - proxy_pass > $http_x_hds_server:8080; > и вот тут проблема - данная переменная вместо ожидаемого значения (того, что > поместил в данный заголовок backend - адрес сервера) возвращает пустую > строку. > > пустая строка, если я правильно догадываюсь - значение по-умолчанию для > несуществующих переменных, в этом случае вопрос звучит так: как правильно > передать во внутренний локейшин значение от backend'а так, чтобы это > значение можно было использовать в качестве сервера для proxy_pass? > > p.s. пробовал вместо $http_x_hds_server использовать $sent_http_x_hds_server > - тоже самое. set $hds_server $upstream_http_x_hds_server; proxy_pass $hds_server; -- Igor Sysoev http://nginx.com/support.html From a.vasilishin at kpi.ua Fri Sep 14 16:41:07 2012 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Fri, 14 Sep 2012 19:41:07 +0300 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INC/0LXRgNC10LzQtdC90L0=?= =?UTF-8?B?0L7QuSDQsiBwcm94eSBwYXNz?= In-Reply-To: References: Message-ID: <50535E23.5060003@kpi.ua> 14.09.2012 11:29, Serafim пишет: > Почему не получается провернуть такой финт: > > backend возвращает пустой (без тела) ответ с двумя заголовками: > X-Accel-Redirect и X-HDS-Server (кастомный, выдумал сам); > в nginx'е есть location помеченный как internal; > ответ от backend'а с заголовоком X-Accel-Redirect прекрасно переадресуется к > данному внутреннему локейшину; > в данном локейшине есть такая директива - proxy_pass > $http_x_hds_server:8080; > и вот тут проблема - данная переменная вместо ожидаемого значения (того, что > поместил в данный заголовок backend - адрес сервера) возвращает пустую > строку. > Как-то так: location /internal { set $hds $http_x_hds_server; proxy_pass $hds:8080; } -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From nginx-forum at nginx.us Fri Sep 14 22:42:22 2012 From: nginx-forum at nginx.us (ruv) Date: Fri, 14 Sep 2012 18:42:22 -0400 Subject: nginx-1.3.1 In-Reply-To: <20120605143109.GY31671@mdounin.ru> References: <20120605143109.GY31671@mdounin.ru> Message-ID: <1983e95ba20686e7abfac5cd22389990.NginxMailingListRussian@forum.nginx.org> День добрый! Замечено, что Nginx стал "съедать" точку в конце любого сегмента пути в URL при передаче запроса к бэкэнду (версия под Windows). Любая подобная модификация запроса ошибочна. Из-за возникшей несовместимости пришлось откатиться на более старую версию. Возможно, это связано со следующим исправлением: > Изменения в nginx 1.3.1 > 05.06.2012 > > *) Безопасность: теперь nginx/Windows игнорирует точку в конце > компонента URI и не разрешает URI, содержащие > последовательность ":$". -- Ruv Posted at Nginx Forum: http://forum.nginx.org/read.php?21,227214,230738#msg-230738 From nginx-forum at nginx.us Sat Sep 15 04:06:35 2012 From: nginx-forum at nginx.us (PbIXTOP) Date: Sat, 15 Sep 2012 00:06:35 -0400 Subject: =?UTF-8?B?UmU6INCg0LDQt9C90YvQtSBDTVMg0YEg0YDQsNC30L3Ri9C80LggcmV3cml0ZSBy?= =?UTF-8?B?dWxlcyDQsiDQtNC40YDQtdC60YLQvtGA0LjRj9GFINC+0LTQvdC+0LPQviA=?= =?UTF-8?B?0LTQvtC80LXQvdCw?= In-Reply-To: References: <5051F50C.5030601@kpi.ua> Message-ID: Vilgelm Wrote: ------------------------------------------------------- > Написал так: > try_files $uri $uri/ /index.php?$args; А разве не надо написать try_files $uri $uri/ /livestreet/index.php?$args; Или такой вариант тоже пробовали? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230695,230742#msg-230742 From karamba66 at ukr.net Sat Sep 15 11:30:21 2012 From: karamba66 at ukr.net (ZZZ) Date: Sat, 15 Sep 2012 14:30:21 +0300 Subject: =?UTF-8?B?bGltaXRfcmVxINGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1?= Message-ID: <505466CD.6040102@ukr.net> Добрый день. Сломал себе всю голову. Хочу сделать общий лимит запросов и лимит запросов от отдельного $arg_id. Сделал такое: http { limit_req_zone $hostname zone=glob:100m rate=5000r/s; limit_req_zone $arg_id zone=id:100m rate=1500r/s; .. server { location{ limit_req zone=glob burst=3 nodelay; limit_req zone=id burst=3 nodelay; но почему-то rate слабо влияет на количество отвергнутых запросов, гораздо радикальнее влияет burst. При burst 0-5 режет много, при >100 режет гораздо меньше чем нужно. limit_req zone=id пробовал убирать, это ничего не меняет. nginx 1.3.6 Спасибо. From ne at vbart.ru Sat Sep 15 12:09:31 2012 From: ne at vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sat, 15 Sep 2012 16:09:31 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0X3JlcSDRgdGC0YDQsNC90L3QvtC1INC/0L7QstC10LTQtdC90Lg=?= =?UTF-8?B?0LU=?= In-Reply-To: <505466CD.6040102@ukr.net> References: <505466CD.6040102@ukr.net> Message-ID: <201209151609.32022.ne@vbart.ru> On Saturday 15 September 2012 15:30:21 ZZZ wrote: > Добрый день. > > Сломал себе всю голову. > Хочу сделать общий лимит запросов и лимит запросов от отдельного $arg_id. > Сделал такое: > > http { > limit_req_zone $hostname zone=glob:100m rate=5000r/s; > limit_req_zone $arg_id zone=id:100m rate=1500r/s; > > .. > server { > location{ > limit_req zone=glob burst=3 nodelay; > limit_req zone=id burst=3 nodelay; > > > но почему-то rate слабо влияет на количество отвергнутых запросов, > гораздо радикальнее влияет burst. При burst 0-5 режет много, при >100 > режет гораздо меньше чем нужно. > limit_req zone=id пробовал убирать, это ничего не меняет. > nginx 1.3.6 > В чем вопрос заключается? Если запросы приходят пачками в интервале гораздо меньшим, чем позволяет указываемый вами rate, то вполне логично, в этом случае от размера корзины будет зависеть их судьба. Постарайтесь описать более детально, что вы делаете, что наблюдаете, что ожидаете, с логами и описанием тестов, которые вы проводили. -- Валентин Бартенев From karamba66 at ukr.net Sat Sep 15 12:27:45 2012 From: karamba66 at ukr.net (ZZZ) Date: Sat, 15 Sep 2012 15:27:45 +0300 Subject: =?UTF-8?B?UmU6IGxpbWl0X3JlcSDRgdGC0YDQsNC90L3QvtC1INC/0L7QstC10LTQtdC90Lg=?= =?UTF-8?B?0LU=?= In-Reply-To: <201209151609.32022.ne@vbart.ru> References: <505466CD.6040102@ukr.net> <201209151609.32022.ne@vbart.ru> Message-ID: <50547441.4020506@ukr.net> > В чем вопрос заключается? Если запросы приходят пачками в интервале гораздо > меньшим, чем позволяет указываемый вами rate, то вполне логично, в этом случае > от размера корзины будет зависеть их судьба. Как я писал, от rate почти ничего не зависит. Я ставил 50000, что в несколько раз выше любого максимума и картина не менялась. А вот изменение burst с 1 до 10 уменьшает количество отброшенных коннектов в 3 раза, хотя эти числа не сопоставимы со средней скоростью поступления запросов и не должны оказывать заметного влияния. По крайней мере мне это кажется странным. Вопрос фактически такой: я чего-то не понимаю и это нормальное поведение или я что-то не так делаю ? From ne at vbart.ru Sat Sep 15 13:15:50 2012 From: ne at vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sat, 15 Sep 2012 17:15:50 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0X3JlcSDRgdGC0YDQsNC90L3QvtC1INC/0L7QstC10LTQtdC90Lg=?= =?UTF-8?B?0LU=?= In-Reply-To: <50547441.4020506@ukr.net> References: <505466CD.6040102@ukr.net> <201209151609.32022.ne@vbart.ru> <50547441.4020506@ukr.net> Message-ID: <201209151715.50585.ne@vbart.ru> On Saturday 15 September 2012 16:27:45 ZZZ wrote: > > В чем вопрос заключается? Если запросы приходят пачками в интервале > > гораздо меньшим, чем позволяет указываемый вами rate, то вполне логично, > > в этом случае от размера корзины будет зависеть их судьба. > > Как я писал, от rate почти ничего не зависит. Я ставил 50000, что в > несколько раз выше любого максимума и картина не менялась. А вот > изменение burst с 1 до 10 уменьшает количество отброшенных коннектов в 3 > раза, хотя эти числа не сопоставимы со средней скоростью поступления > запросов и не должны оказывать заметного влияния. По крайней мере мне > это кажется странным. Вопрос фактически такой: я чего-то не понимаю и > это нормальное поведение или я что-то не так делаю ? > Причем тут средняя скорость поступления запросов? Если посчитать среднее за 100 лет, то подозреваю оно будет около нуля. rate задает не среднюю скорость запросов, а мгновенную. Если у вас всего два запроса поступят с интервалом в 1мс, то в rate < 1000r/s они уже не уложатся. Плюс надо учитывать гранулярность счетчика. Подробнее http://en.wikipedia.org/wiki/Leaky_bucket Ещё раз. Как поступают запросы и сколько их? timer_resolution случайно не выставлен? accept_mutex и multi_accept? -- Валентин Бартенев From karamba66 at ukr.net Sat Sep 15 14:50:38 2012 From: karamba66 at ukr.net (ZZZ) Date: Sat, 15 Sep 2012 17:50:38 +0300 Subject: =?UTF-8?B?UmU6IGxpbWl0X3JlcSDRgdGC0YDQsNC90L3QvtC1INC/0L7QstC10LTQtdC90Lg=?= =?UTF-8?B?0LU=?= In-Reply-To: <201209151715.50585.ne@vbart.ru> References: <505466CD.6040102@ukr.net> <201209151609.32022.ne@vbart.ru> <50547441.4020506@ukr.net> <201209151715.50585.ne@vbart.ru> Message-ID: <505495BE.7020603@ukr.net> Про timer_resolution я действительно не подумал. После выключения всё стало гораздо адекватнее. Спасибо большое. From nginx-forum at nginx.us Sun Sep 16 10:40:28 2012 From: nginx-forum at nginx.us (uradvd85) Date: Sun, 16 Sep 2012 06:40:28 -0400 Subject: =?UTF-8?B?UmU6IEZyZWVCU0QgKyBuZ2lueCArIHBocC1mcG0gLSDQt9Cw0LTQtdGA0LbQutCw?= =?UTF-8?B?INC+0YLQtNCw0YfQuCDQutC+0L3RgtC10L3RgtCwIDEuMi0xLjcg0YHQtdC6?= In-Reply-To: <70ff2fe63466c2705067fac9933447cc.NginxMailingListRussian@forum.nginx.org> References: <70ff2fe63466c2705067fac9933447cc.NginxMailingListRussian@forum.nginx.org> Message-ID: <9ebd4583a0cfbc9c5a825ba69c432c50.NginxMailingListRussian@forum.nginx.org> Tiberiy Wrote: ------------------------------------------------------- > Попорядку. > > 1. Проблему опустили до 0.5 сек - тюнили фрибсд. > 2. Проблема по п.1 уже в канале. > 3. Время отдачи статики такое же 0.5 сек. Как тюнинговали, если несложно отпишите, такая же проблема. Заранее спасибо Posted at Nginx Forum: http://forum.nginx.org/read.php?21,218467,230760#msg-230760 From nginx-forum at nginx.us Sun Sep 16 21:18:25 2012 From: nginx-forum at nginx.us (AndrejAndb) Date: Sun, 16 Sep 2012 17:18:25 -0400 Subject: =?UTF-8?B?0LjQvdCy0LDQu9C40LTQsNGG0LjRjyDQutC10YjQsA==?= Message-ID: <2a465cbb61f59160140c67c6d2aeccb4.NginxMailingListRussian@forum.nginx.org> Озадачился вопросом выборочной инвалидацией кэша. к примеру следующий use case: Есть 2 типа страниц: 1) список статей 2) статья с пользовательскими комментариями страницы генерируются посредством fastcgi и кэшируются что то типа: fastcgi_cache_path /var/cache/nginx levels= keys_zone=pagecache:360m inactive=360m max_size=300m; fastcgi_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; требуется 1) при изменении статьи принудительно инвалидировать кэшированные страницы со списком статей и страницы самой статьи 2) При добавлении комментария инвалидировать страницу статьи - куда был добавлен комментарий И решения которые приходили в голову: 1) Чистить ВЕСЬ кэш всегда - как-то не спортивно, и в случае высоких нагрузок - неприменимо 2) При отдаче с PHP бэкенда, записывать запрашиваемый URL в отдельное хранилище, и при необходимости инвалидировать страницу: выдернуть все необходимые URL (попадающие под нужное условие) из хранилища и удалять все файлы из /var/cache/nginx соответствующие md5($request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri). - Несколько сложно, и такой способ вызывает еще ряд сложностей... 3) При отдаче с PHP бэкенда писать в заголовок ответа Тэги страницы: "X-CACHE-TAGS: entry_id1 entry_id2 entry_id3 entry_list" - список из 3х статей "X-CACHE-TAGS: entry_id1 entry_one" - статья id1 И при необходимости инвалидировать все страницы, где упоминается entry_id1, нужно будет пройтись по всем файлам в кэше, отыскать наличие в заголовке данного тега и удалить его. Идея показалась интересной, но при наличии большого кол-ва файлов в кэше - процесс инвалидации может затянуться. 4) использовать memcache. Вроде бы самый оптимальный вариант, поскольку PHP бэкенд знает куда что пишет - и без проблем сможет инвалидировать... Единственный недостаток: бэкенд не может писать заголовки ответа в такой кэш. Это минус - поскольку усложнит конфиги nginx, но думаю можно смириться. Другой минус - кол-во оперативной памяти под мемкэш куда более ограниченей свободного места на HDD под файловый кэш. И в общем то вопрос: не изобретаю ли я велосипедов? :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230763,230763#msg-230763 From nginx-forum at nginx.us Mon Sep 17 02:02:27 2012 From: nginx-forum at nginx.us (vitroot) Date: Sun, 16 Sep 2012 22:02:27 -0400 Subject: upstream+fail_timeout Message-ID: <416357bd59661d0acaef76607193264f.NginxMailingListRussian@forum.nginx.org> Приветствую! Подскажите, пожалуйста, есть ли вообще какое-либо значение fail_timeout в апстриме, которое выносит из общей корзины одну точку навсегда, а не на несколько секунд/минут/часов/дней и т.п.? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230764,230764#msg-230764 From mdounin at mdounin.ru Mon Sep 17 09:31:31 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 17 Sep 2012 13:31:31 +0400 Subject: upstream+fail_timeout In-Reply-To: <416357bd59661d0acaef76607193264f.NginxMailingListRussian@forum.nginx.org> References: <416357bd59661d0acaef76607193264f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120917093131.GX40452@mdounin.ru> Hello! On Sun, Sep 16, 2012 at 10:02:27PM -0400, vitroot wrote: > Приветствую! > Подскажите, пожалуйста, есть ли вообще какое-либо значение fail_timeout в > апстриме, которое выносит из общей корзины одну точку навсегда, а не на > несколько секунд/минут/часов/дней и т.п.? Нет. Maxim Dounin From sergey.kobzar at itcraft.org Mon Sep 17 10:20:07 2012 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Mon, 17 Sep 2012 13:20:07 +0300 Subject: =?UTF-8?B?UmU6INC40L3QstCw0LvQuNC00LDRhtC40Y8g0LrQtdGI0LA=?= In-Reply-To: <2a465cbb61f59160140c67c6d2aeccb4.NginxMailingListRussian@forum.nginx.org> References: <2a465cbb61f59160140c67c6d2aeccb4.NginxMailingListRussian@forum.nginx.org> Message-ID: <5056F957.8070007@itcraft.org> On 09/17/12 00:18, AndrejAndb wrote: > Озадачился вопросом выборочной инвалидацией кэша. > > к примеру следующий use case: > Есть 2 типа страниц: > 1) список статей > 2) статья с пользовательскими комментариями > страницы генерируются посредством fastcgi и кэшируются что то типа: > fastcgi_cache_path /var/cache/nginx levels= keys_zone=pagecache:360m > inactive=360m max_size=300m; > fastcgi_cache_key > "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; > > требуется > 1) при изменении статьи принудительно инвалидировать кэшированные страницы > со списком статей и страницы самой статьи > 2) При добавлении комментария инвалидировать страницу статьи - куда был > добавлен комментарий > > > И решения которые приходили в голову: > > 1) Чистить ВЕСЬ кэш всегда - как-то не спортивно, и в случае высоких > нагрузок - неприменимо > > 2) При отдаче с PHP бэкенда, записывать запрашиваемый URL в отдельное > хранилище, и при необходимости инвалидировать страницу: выдернуть все > необходимые URL (попадающие под нужное условие) из хранилища и удалять все > файлы из /var/cache/nginx соответствующие > md5($request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri). > - Несколько сложно, и такой способ вызывает еще ряд сложностей... > > 3) При отдаче с PHP бэкенда писать в заголовок ответа Тэги страницы: > "X-CACHE-TAGS: entry_id1 entry_id2 entry_id3 entry_list" - список из 3х > статей > "X-CACHE-TAGS: entry_id1 entry_one" - статья id1 > И при необходимости инвалидировать все страницы, где упоминается entry_id1, > нужно будет пройтись по всем файлам в кэше, отыскать наличие в заголовке > данного тега и удалить его. > Идея показалась интересной, но при наличии большого кол-ва файлов в кэше - > процесс инвалидации может затянуться. > > 4) использовать memcache. > Вроде бы самый оптимальный вариант, поскольку PHP бэкенд знает куда что > пишет - и без проблем сможет инвалидировать... Единственный недостаток: > бэкенд не может писать заголовки ответа в такой кэш. Это минус - поскольку > усложнит конфиги nginx, но думаю можно смириться. Другой минус - кол-во > оперативной памяти под мемкэш куда более ограниченей свободного места на HDD > под файловый кэш. > > И в общем то вопрос: не изобретаю ли я велосипедов? :) 3rdp party module: http://labs.frickle.com/nginx_ngx_cache_purge/ > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230763,230763#msg-230763 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Mon Sep 17 11:15:43 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 17 Sep 2012 15:15:43 +0400 Subject: nginx-1.3.1 In-Reply-To: <1983e95ba20686e7abfac5cd22389990.NginxMailingListRussian@forum.nginx.org> References: <20120605143109.GY31671@mdounin.ru> <1983e95ba20686e7abfac5cd22389990.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120917111543.GZ40452@mdounin.ru> Hello! On Fri, Sep 14, 2012 at 06:42:22PM -0400, ruv wrote: > День добрый! > > Замечено, что Nginx стал "съедать" точку в конце любого сегмента пути в URL > при передаче запроса к бэкэнду (версия под Windows). Любая подобная > модификация запроса ошибочна. Из-за возникшей несовместимости пришлось > откатиться на более старую версию. > > Возможно, это связано со следующим исправлением: > > > Изменения в nginx 1.3.1 > > 05.06.2012 > > > > *) Безопасность: теперь nginx/Windows игнорирует точку в конце > > компонента URI и не разрешает URI, содержащие > > последовательность ":$". Да, это связано именно с этим изменением. Под windows точка в конце любого имени файла/каталога - не значащая, и такие uri нужно либо отвергать, либо нормализовывать. В противном случае имеем возможность обхода ограничений доступа. До 1.3.1 делалось нормализация только для последнего компонента пути, сейчас - для всех. Если нужно проксировать без нормализации uri (в предположении, что бекенд сам справится с этой проблемой, и/или он не на виндах) - должно помочь написание директивы proxy_pass без URI, i.e. proxy_pass http://backend; без "/" в конце. Maxim Dounin From gmm at csdoc.com Mon Sep 17 11:19:25 2012 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 17 Sep 2012 14:19:25 +0300 Subject: Auto detect the number of CPU's and set worker_processes Message-ID: <5057073D.9000007@csdoc.com> On 17.09.2012 12:55, in nginx at nginx.org list Igor Sysoev wrote: > You can configure it via command line: > nginx -g "worker_processes `cat /proc/cpuinfo | grep "processor" | sort -u | wc -l`;" можно еще проще для POSIX-совместимых OS: nginx -g "worker_processes `getconf _NPROCESSORS_ONLN`;" - предлагаю для директивы worker_processes сделать дополнительный вариант значения: auto тогда nginx будет делать количество worker_processes равным количеству ядер в системе. (для windows "auto" == 1) - предлагаю сделать "auto" значением по умолчанию. потому что в большинстве случаев это и будет самая оптимальная настройка. BTW, так же написано и в доке: "Если затрудняетесь в выборе правильного значения, можно начать с установки его равным числу процессорных ядер." -- Best regards, Gena From hell-for-yahoo at umail.ru Mon Sep 17 12:12:18 2012 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Mon, 17 Sep 2012 16:12:18 +0400 Subject: nginx-1.3.1 In-Reply-To: <20120917111543.GZ40452@mdounin.ru> References: <20120605143109.GY31671@mdounin.ru> <1983e95ba20686e7abfac5cd22389990.NginxMailingListRussian@forum.nginx.org> <20120917111543.GZ40452@mdounin.ru> Message-ID: <809197509.20120917161218@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Maxim Dounin! MD> Под windows точка в конце любого имени файла/каталога - не значащая, Да нууу??? С каких пор? [C:\home\Daemon\Documents\_PHP\GalleryClass]$ cmd-cmd /C dir Том в устройстве C имеет метку Max80New-1 Серийный номер тома: 6C9D-C3CC Содержимое папки C:\home\Daemon\Documents\_PHP\GalleryClass 17.09.2012 16:11 . 17.09.2012 16:11 .. 17.09.2012 16:11 arg. 17.09.2012 16:11 ask.. 17.09.2012 16:10 aww... 02.09.2009 07:55 5═136 GalleryClass.php 02.09.2009 07:55 265 index.php 02.09.2009 07:55 209 lib.config.php 3 файлов 5═610 байт 5 папок 7═713═841═152 байт свободно [C:\home\Daemon\Documents\_PHP\GalleryClass]$ -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) понедельник, 17.09.2012, <16:10> From hell-for-yahoo at umail.ru Mon Sep 17 12:13:35 2012 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Mon, 17 Sep 2012 16:13:35 +0400 Subject: upstream+fail_timeout In-Reply-To: <416357bd59661d0acaef76607193264f.NginxMailingListRussian@forum.nginx.org> References: <416357bd59661d0acaef76607193264f.NginxMailingListRussian@forum.nginx.org> Message-ID: <1948110876.20120917161335@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) vitroot! v> Подскажите, пожалуйста, есть ли вообще какое-либо значение fail_timeout в v> апстриме, которое выносит из общей корзины одну точку навсегда, а не на v> несколько секунд/минут/часов/дней и т.п.? Предполагается, что это ваша работа - исключать удалённые апстримы из конфигурации. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) понедельник, 17.09.2012, <16:13> From ne at vbart.ru Mon Sep 17 12:19:08 2012 From: ne at vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 17 Sep 2012 16:19:08 +0400 Subject: Auto detect the number of CPU's and set worker_processes In-Reply-To: <5057073D.9000007@csdoc.com> References: <5057073D.9000007@csdoc.com> Message-ID: <201209171619.08614.ne@vbart.ru> On Monday 17 September 2012 15:19:25 Gena Makhomed wrote: > - предлагаю для директивы worker_processes > сделать дополнительный вариант значения: auto [...] Уже много раз обсуждали. Простого и единого способа получить количество физических ядер в любой системе - не существует. -- Валентин Бартенев From gmm at csdoc.com Mon Sep 17 12:46:38 2012 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 17 Sep 2012 15:46:38 +0300 Subject: Auto detect the number of CPU's and set worker_processes In-Reply-To: <201209171619.08614.ne@vbart.ru> References: <5057073D.9000007@csdoc.com> <201209171619.08614.ne@vbart.ru> Message-ID: <50571BAE.9070700@csdoc.com> On 17.09.2012 15:19, Валентин Бартенев wrote: >> - предлагаю для директивы worker_processes >> сделать дополнительный вариант значения: auto > Уже много раз обсуждали. Простого и единого способа получить количество > физических ядер в любой системе - не существует. на 99.9% используемых систем это можно получить. (Linux, FreeBSD, MacOS X, NetBSD, OpenBSD, Solaris, AIX) а там где нельзя получить - auto может быть равно 1, как и на виндовсе. по крайней мере, чтобы получить размер L2 cache line - тоже не существует простого и единого способа, но тем не менее, nginx это всеравно делает, чтобы настроиться на максимальную производительность в зависимости от процессора. nginx-1.3.6\src\core\ngx_cpuinfo.c /* auto detect the L2 cache line size of modern and widespread CPUs */ с количеством ядер процессора - ведь полностью аналогичная ситуация. P.S. http://stackoverflow.com/questions/150355/programmatically-find-the-number-of-cores-on-a-machine -- Best regards, Gena From igor at sysoev.ru Mon Sep 17 12:59:25 2012 From: igor at sysoev.ru (Igor Sysoev) Date: Mon, 17 Sep 2012 16:59:25 +0400 Subject: Auto detect the number of CPU's and set worker_processes In-Reply-To: <50571BAE.9070700@csdoc.com> References: <5057073D.9000007@csdoc.com> <201209171619.08614.ne@vbart.ru> <50571BAE.9070700@csdoc.com> Message-ID: On Sep 17, 2012, at 16:46 , Gena Makhomed wrote: > On 17.09.2012 15:19, Валентин Бартенев wrote: > >>> - предлагаю для директивы worker_processes >>> сделать дополнительный вариант значения: auto > >> Уже много раз обсуждали. Простого и единого способа получить количество >> физических ядер в любой системе - не существует. > > на 99.9% используемых систем это можно получить. > (Linux, FreeBSD, MacOS X, NetBSD, OpenBSD, Solaris, AIX) > > а там где нельзя получить - auto может быть равно 1, как и на виндовсе. > > по крайней мере, чтобы получить размер L2 cache line > - тоже не существует простого и единого способа, > но тем не менее, nginx это всеравно делает, чтобы настроиться > на максимальную производительность в зависимости от процессора. > > nginx-1.3.6\src\core\ngx_cpuinfo.c > /* auto detect the L2 cache line size of modern and widespread CPUs */ > > с количеством ядер процессора - ведь полностью аналогичная ситуация. > > P.S. > > http://stackoverflow.com/questions/150355/programmatically-find-the-number-of-cores-on-a-machine Проблема не столько в интерфейсе, сколько в том, что эти интерфейсы считают процессором - отдельное ядро или hyper-thread ? -- Igor Sysoev http://nginx.com/support.html From mdounin at mdounin.ru Mon Sep 17 13:04:30 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 17 Sep 2012 17:04:30 +0400 Subject: nginx-1.3.1 In-Reply-To: <809197509.20120917161218@mtu-net.ru> References: <20120605143109.GY31671@mdounin.ru> <1983e95ba20686e7abfac5cd22389990.NginxMailingListRussian@forum.nginx.org> <20120917111543.GZ40452@mdounin.ru> <809197509.20120917161218@mtu-net.ru> Message-ID: <20120917130430.GA40452@mdounin.ru> Hello! On Mon, Sep 17, 2012 at 04:12:18PM +0400, Andrey Repin wrote: > Здравствуйте, Уважаемый(-ая, -ое) Maxim Dounin! > > MD> Под windows точка в конце любого имени файла/каталога - не значащая, > > Да нууу??? С каких пор? Приблизительно с момента появления. http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx : Do not end a file or directory name with a space or a period. : Although the underlying file system may support such names, the : Windows shell and user interface does not. > [C:\home\Daemon\Documents\_PHP\GalleryClass]$ cmd-cmd /C dir > Том в устройстве C имеет метку Max80New-1 > Серийный номер тома: 6C9D-C3CC > > Содержимое папки C:\home\Daemon\Documents\_PHP\GalleryClass > > 17.09.2012 16:11 . > 17.09.2012 16:11 .. > 17.09.2012 16:11 arg. > 17.09.2012 16:11 ask.. > 17.09.2012 16:10 aww... > 02.09.2009 07:55 5═136 GalleryClass.php > 02.09.2009 07:55 265 index.php > 02.09.2009 07:55 209 lib.config.php > 3 файлов 5═610 байт > 5 папок 7═713═841═152 байт свободно > > [C:\home\Daemon\Documents\_PHP\GalleryClass]$ Try this: type c:\home\Daemon\Documents\_PHP\GalleryClass\index.php type c:\home\Daemon\Documents\_PHP\GalleryClass.\index.php Как создать по виндами файлы с точкой в конце, и как их потом удалить - это, безусловно, интересный с теологической точки зрения вопрос, и даже местами с практической (в части удалить), и ему даже отводится целый раздел по ссылке выше. Но, право слово, возможность их создать с помощью прямого обращения к файловой системе - это лишь ещё один способ прострелить себе ногу, не более того. Maxim Dounin From ne at vbart.ru Mon Sep 17 13:12:26 2012 From: ne at vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 17 Sep 2012 17:12:26 +0400 Subject: Auto detect the number of CPU's and set worker_processes In-Reply-To: <50571BAE.9070700@csdoc.com> References: <5057073D.9000007@csdoc.com> <201209171619.08614.ne@vbart.ru> <50571BAE.9070700@csdoc.com> Message-ID: <201209171712.27069.ne@vbart.ru> On Monday 17 September 2012 16:46:38 Gena Makhomed wrote: [...] > http://stackoverflow.com/questions/150355/programmatically-find-the-number- > of-cores-on-a-machine Ни один из описанных там способов не дает гарантированно количества физических ядер в системе, кроме, пожалуй, использование CPUID (что является Intel/AMD specific и добавляет бесконечное количество головной боли). auto, реализованное таким образом, иногда будет принимать значение 1, очень часто 2*cores, а, возможно, в отдельных случаях, вообще непонятно что. В Linux правильным способом будет ходить по /sys/devices/system/cpu/cpuN/topology/ -- Валентин Бартенев From hell-for-yahoo at umail.ru Mon Sep 17 14:01:54 2012 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Mon, 17 Sep 2012 18:01:54 +0400 Subject: nginx-1.3.1 In-Reply-To: <20120917130430.GA40452@mdounin.ru> References: <20120605143109.GY31671@mdounin.ru> <1983e95ba20686e7abfac5cd22389990.NginxMailingListRussian@forum.nginx.org> <20120917111543.GZ40452@mdounin.ru> <809197509.20120917161218@mtu-net.ru> <20120917130430.GA40452@mdounin.ru> Message-ID: <8210527272.20120917180154@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Maxim Dounin! MD> Как создать по виндами файлы с точкой в конце, и как их потом MD> удалить - это, безусловно, интересный с теологической точки зрения MD> вопрос, и даже местами с практической (в части удалить), WinAPI же ж. В частности, именно это я создал (и удалил тоже) FAR'ом. Просто потому, что что-то кем-то делать не рекомендуется, ещё не причина ограничивать меня в выборе средств работы с системой. Если система поддерживает что-то, программа должна ожидать подобного финта от системы, и вести себя подобающим образом, а не ойкать при каждом обращении. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) понедельник, 17.09.2012, <17:58> From nginx-forum at nginx.us Mon Sep 17 15:19:02 2012 From: nginx-forum at nginx.us (ruv) Date: Mon, 17 Sep 2012 11:19:02 -0400 Subject: nginx-1.3.1 In-Reply-To: <20120917111543.GZ40452@mdounin.ru> References: <20120917111543.GZ40452@mdounin.ru> Message-ID: День добрый! > > > *) Безопасность: теперь nginx/Windows игнорирует точку в конце > > > компонента URI и не разрешает URI, содержащие > > > последовательность ":$". > > Да, это связано именно с этим изменением. Под windows точка в > конце любого имени файла/каталога - не значащая, и такие uri нужно > либо отвергать, либо нормализовывать. В противном случае имеем > возможность обхода ограничений доступа. До 1.3.1 делалось > нормализация только для последнего компонента пути, сейчас - для > всех. Дело еще в том, что ведь далеко не каждый URI отображается на файловую систему. Поэтому, я думаю, при передаче бэкенду допустимо проводить нормализацию только если специально указано в конфиге (как например merge_slashes). Понимаю, тут возникает трудность в реализации. В location ведь сейчас сопоставляется нормализованный URI. Может быть тогда эту нормализацию тоже опцией отключать (будет полная аналогия merge_slashes)? > Если нужно проксировать без нормализации uri (в предположении, что > бекенд сам справится с этой проблемой, и/или он не на виндах) - > должно помочь написание директивы proxy_pass без URI, i.e. > > proxy_pass http://backend; > > без "/" в конце. Но, в таком случае не подменяется часть URI запроса, соответствующая location. И тоже получается несовместимость ? придется править код на бэкендах, появится лишняя связаность и зависимость... -- Ruvim Posted at Nginx Forum: http://forum.nginx.org/read.php?21,227214,230787#msg-230787 From mdounin at mdounin.ru Mon Sep 17 16:02:04 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 17 Sep 2012 20:02:04 +0400 Subject: nginx-1.3.1 In-Reply-To: <8210527272.20120917180154@mtu-net.ru> References: <20120605143109.GY31671@mdounin.ru> <1983e95ba20686e7abfac5cd22389990.NginxMailingListRussian@forum.nginx.org> <20120917111543.GZ40452@mdounin.ru> <809197509.20120917161218@mtu-net.ru> <20120917130430.GA40452@mdounin.ru> <8210527272.20120917180154@mtu-net.ru> Message-ID: <20120917160204.GE40452@mdounin.ru> Hello! On Mon, Sep 17, 2012 at 06:01:54PM +0400, Andrey Repin wrote: > Здравствуйте, Уважаемый(-ая, -ое) Maxim Dounin! > > MD> Как создать по виндами файлы с точкой в конце, и как их потом > MD> удалить - это, безусловно, интересный с теологической точки зрения > MD> вопрос, и даже местами с практической (в части удалить), > > WinAPI же ж. > В частности, именно это я создал (и удалил тоже) FAR'ом. Не смотрел, но скорее всего FAR делает через \\?\, который "tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system". См. опять же ранее приведённую ссылку. > Просто потому, что что-то кем-то делать не рекомендуется, ещё не причина > ограничивать меня в выборе средств работы с системой. > Если система поддерживает что-то, программа должна ожидать подобного финта от > системы, и вести себя подобающим образом, а не ойкать при каждом обращении. Именно об этом и речь: система делает нормализацию, и не ожидать этого от системы - наивно. Переключаться для всех операций на \\?\, (не)делая нормализацию самостоятельно - столь же наивно (не говоря уже про количество геморроя и вероятность ошибки), потому как стоящий следом php/whatever ничего про все эти тонкости знать не знает, и радостно отработает. Maxim Dounin From gmm at csdoc.com Mon Sep 17 16:37:45 2012 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 17 Sep 2012 19:37:45 +0300 Subject: Auto detect the number of CPU's and set worker_processes In-Reply-To: References: <5057073D.9000007@csdoc.com> <201209171619.08614.ne@vbart.ru> <50571BAE.9070700@csdoc.com> Message-ID: <505751D9.4070407@csdoc.com> On 17.09.2012 15:59, Igor Sysoev wrote: >>>> - предлагаю для директивы worker_processes >>>> сделать дополнительный вариант значения: auto >> http://stackoverflow.com/questions/150355/programmatically-find-the-number-of-cores-on-a-machine > Проблема не столько в интерфейсе, сколько в том, что эти интерфейсы считают > процессором - отдельное ядро или hyper-thread ? если надо точно определить количество именно физических ядер, для CPU Intel или AMD - это легко можно сделать. для Linux тоже. что сразу покрывает более 80% случаев использования nginx во всем мире. для остальных систем - если не удалось определить, значение auto == 1. всеравно ручной тюнинг всегда будет лучше и точнее, чем автонастройка. worker_processes == количеству физических ядер - просто удобный дефолт. -- Best regards, Gena From gmm at csdoc.com Mon Sep 17 16:38:08 2012 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 17 Sep 2012 19:38:08 +0300 Subject: Auto detect the number of CPU's and set worker_processes In-Reply-To: <201209171712.27069.ne@vbart.ru> References: <5057073D.9000007@csdoc.com> <201209171619.08614.ne@vbart.ru> <50571BAE.9070700@csdoc.com> <201209171712.27069.ne@vbart.ru> Message-ID: <505751F0.1030502@csdoc.com> On 17.09.2012 16:12, Валентин Бартенев wrote: >> http://stackoverflow.com/questions/150355/programmatically-find-the-number- >> of-cores-on-a-machine > Ни один из описанных там способов не дает гарантированно количества физических > ядер в системе, кроме, пожалуй, использование CPUID (что является Intel/AMD > specific и добавляет бесконечное количество головной боли). команда cpuid используется в nginx для определения ngx_cacheline_size. и что-то не заметно там никакого бесконечного количества головной боли. кстати, есть еще такой проект: http://www.open-mpi.org/projects/hwloc/ практически везде где это можно, определяет количество физических ядер. > auto, реализованное таким образом, иногда будет принимать значение 1, очень > часто 2*cores, а, возможно, в отдельных случаях, вообще непонятно что. > В Linux правильным способом будет ходить по > /sys/devices/system/cpu/cpuN/topology/ по крайней мере, для всех CPU Intel / AMD и для всех OS Linux можно точно определить количество физических ядер, а это более 80% случаев. например, aio нормально работает только в FreeBSD - но это ведь не было причиной почему нельзя добавлять такую фичу в nginx. так же и с ядрами. -- Best regards, Gena From igor at sysoev.ru Mon Sep 17 17:13:25 2012 From: igor at sysoev.ru (Igor Sysoev) Date: Mon, 17 Sep 2012 21:13:25 +0400 Subject: Auto detect the number of CPU's and set worker_processes In-Reply-To: <505751D9.4070407@csdoc.com> References: <5057073D.9000007@csdoc.com> <201209171619.08614.ne@vbart.ru> <50571BAE.9070700@csdoc.com> <505751D9.4070407@csdoc.com> Message-ID: <1685122A-E56A-4C48-9D83-CFEF72DE817D@sysoev.ru> On Sep 17, 2012, at 20:37 , Gena Makhomed wrote: > On 17.09.2012 15:59, Igor Sysoev wrote: > >>>>> - предлагаю для директивы worker_processes >>>>> сделать дополнительный вариант значения: auto > >>> http://stackoverflow.com/questions/150355/programmatically-find-the-number-of-cores-on-a-machine > >> Проблема не столько в интерфейсе, сколько в том, что эти интерфейсы считают >> процессором - отдельное ядро или hyper-thread ? > > если надо точно определить количество именно физических ядер, > для CPU Intel или AMD - это легко можно сделать. для Linux тоже. Насколько я понимаю, cpuid возвращает данные о cores/hyper-threads для одного физического процессора, на котором эта cpuid выполняется. А как узнать число физических процесоров ? -- Igor Sysoev http://nginx.com/support.html From mdounin at mdounin.ru Mon Sep 17 17:22:40 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 17 Sep 2012 21:22:40 +0400 Subject: nginx-1.3.1 In-Reply-To: References: <20120917111543.GZ40452@mdounin.ru> Message-ID: <20120917172240.GF40452@mdounin.ru> Hello! On Mon, Sep 17, 2012 at 11:19:02AM -0400, ruv wrote: > День добрый! > > > > > *) Безопасность: теперь nginx/Windows игнорирует точку в конце > > > > компонента URI и не разрешает URI, содержащие > > > > последовательность ":$". > > > > Да, это связано именно с этим изменением. Под windows точка в > > конце любого имени файла/каталога - не значащая, и такие uri нужно > > либо отвергать, либо нормализовывать. В противном случае имеем > > возможность обхода ограничений доступа. До 1.3.1 делалось > > нормализация только для последнего компонента пути, сейчас - для > > всех. > > Дело еще в том, что ведь далеко не каждый URI отображается на файловую > систему. > Поэтому, я думаю, при передаче бэкенду допустимо проводить нормализацию > только если специально указано в конфиге (как например merge_slashes). > Понимаю, тут возникает трудность в реализации. В location ведь сейчас > сопоставляется нормализованный URI. Может быть тогда эту нормализацию тоже > опцией отключать (будет полная аналогия merge_slashes)? Нормализовывать (или отвергать) необходимо по умолчанию, ибо в противном случае конфигурация вида location /admin/ { auth_basic ... } на виндах превращается в фикцию. В частности - при передаче запросов бекенду, т.к. типичный бекенд (читай: php) открыват файлы без каких-либо дополнительных проверок. Сделать нормализацию отключаемой, снабдив надписью "берегись леопарда" (a la merge_slashes), - можно, но не факт, что нужно. Особенно с учётом того, что отключать это можно только для всех виртуальных хостов на паре ip:port разом. > > Если нужно проксировать без нормализации uri (в предположении, что > > бекенд сам справится с этой проблемой, и/или он не на виндах) - > > должно помочь написание директивы proxy_pass без URI, i.e. > > > > proxy_pass http://backend; > > > > без "/" в конце. > > Но, в таком случае не подменяется часть URI запроса, соответствующая > location. И тоже получается несовместимость ? придется править код на > бэкендах, появится лишняя связаность и зависимость... Ну как мнимум два пути решения проблемы очевидны: отказаться от trailing dots или использовать proxy_pass без URI. И я совершенно не уверен, что изобретать третий, притом не безопасный путь - это хорошая идея. Maxim Dounin From ne at vbart.ru Mon Sep 17 17:26:12 2012 From: ne at vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 17 Sep 2012 21:26:12 +0400 Subject: Auto detect the number of CPU's and set worker_processes In-Reply-To: <1685122A-E56A-4C48-9D83-CFEF72DE817D@sysoev.ru> References: <5057073D.9000007@csdoc.com> <505751D9.4070407@csdoc.com> <1685122A-E56A-4C48-9D83-CFEF72DE817D@sysoev.ru> Message-ID: <201209172126.12643.ne@vbart.ru> On Monday 17 September 2012 21:13:25 Igor Sysoev wrote: > On Sep 17, 2012, at 20:37 , Gena Makhomed wrote: > > On 17.09.2012 15:59, Igor Sysoev wrote: > >>>>> - предлагаю для директивы worker_processes > >>>>> сделать дополнительный вариант значения: auto > >>> > >>> http://stackoverflow.com/questions/150355/programmatically-find-the-num > >>> ber-of-cores-on-a-machine > >> > >> Проблема не столько в интерфейсе, сколько в том, что эти интерфейсы > >> считают процессором - отдельное ядро или hyper-thread ? > > > > если надо точно определить количество именно физических ядер, > > для CPU Intel или AMD - это легко можно сделать. для Linux тоже. > > Насколько я понимаю, cpuid возвращает данные о cores/hyper-threads для > одного физического процессора, на котором эта cpuid выполняется. А как > узнать число физических процесоров ? > Из последнего интелевского мануала, который я читал, на современных процессорах с помощью cpuid можно было вынуть всю топологию. -- Валентин Бартенев From gmm at csdoc.com Mon Sep 17 18:58:35 2012 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 17 Sep 2012 21:58:35 +0300 Subject: Auto detect the number of CPU's and set worker_processes In-Reply-To: <1685122A-E56A-4C48-9D83-CFEF72DE817D@sysoev.ru> References: <5057073D.9000007@csdoc.com> <201209171619.08614.ne@vbart.ru> <50571BAE.9070700@csdoc.com> <505751D9.4070407@csdoc.com> <1685122A-E56A-4C48-9D83-CFEF72DE817D@sysoev.ru> Message-ID: <505772DB.8030208@csdoc.com> On 17.09.2012 20:13, Igor Sysoev wrote: >> если надо точно определить количество именно физических ядер, >> для CPU Intel или AMD - это легко можно сделать. для Linux тоже. > Насколько я понимаю, cpuid возвращает данные о cores/hyper-threads для одного > физического процессора, на котором эта cpuid выполняется. А как узнать число > физических процесоров ? я вот попробовал собрать http://svn.open-mpi.org/svn/hwloc/trunk - эта утилита смогла через OS API верно узнать топологию на всех машинах, где я ее проверял. даже внутри Linux-контейнера OpenVZ. так что этот ^^^ метод будет работать при использовании любого типа процессоров (не только х86) на любом из 8 типов поддерживаемых OS: Linux, Solaris, AIX, Darwin / OS X, FreeBSD, OSF/1, HP-UX, Windows поддерживается даже Debian GNU/kFreeBSD, which does not support topology information, and hwloc thus uses an x86-only CPUID-based backend (which could be used for other OSes too). "x86-only CPUID-based backend" - это, я так понимаю, topology-x86.c и этим способом тоже можно узнать количество физических ядер машины. (это я не проверял, у меня сейчас нет под рукой Debian GNU/kFreeBSD) -- Best regards, Gena From postmaster at softsearch.ru Mon Sep 17 19:47:32 2012 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 17 Sep 2012 23:47:32 +0400 Subject: Auto detect the number of CPU's and set worker_processes In-Reply-To: <5057073D.9000007@csdoc.com> References: <5057073D.9000007@csdoc.com> Message-ID: <1558776653.20120917234732@softsearch.ru> Здравствуйте, Gena. > - предлагаю для директивы worker_processes > сделать дополнительный вариант значения: auto Я б себе везде тоже auto поставил за исключением одного сервера. Ибо удобно. Или вообще директиву убрал бы из своих конфигов, ибо дефолты писать нет смысла. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Mon Sep 17 22:17:43 2012 From: nginx-forum at nginx.us (ruv) Date: Mon, 17 Sep 2012 18:17:43 -0400 Subject: nginx-1.3.1 In-Reply-To: <20120917172240.GF40452@mdounin.ru> References: <20120917172240.GF40452@mdounin.ru> Message-ID: <2dafbe601feb7170333ee9185ce7950f.NginxMailingListRussian@forum.nginx.org> Привет! Maxim Dounin Wrote: > Ну как мнимум два пути решения проблемы очевидны: отказаться от > trailing dots или использовать proxy_pass без URI. И я совершенно > не уверен, что изобретать третий, притом не безопасный путь - это > хорошая идея. Согласен. Но таки придется признать, что обратная совместимость частично поломана (в том смысле, что то, что работало ? перестало работать после обновления). Думаю, исправления, которые ломают обратную совместимость, следует как-то особо помечать в CHANGES. Отказаться от trailing dots очень трудно (уже попали в имена и "высечены в камне"; к файловой системе это не имеет отношения). Придется сделать proxy_pass без URI и подправить бэкенды. Кстати, а что там насчет ":$"? Получается, для такого случая и обхода нету? -- Ruvim Posted at Nginx Forum: http://forum.nginx.org/read.php?21,227214,230800#msg-230800 From nginx-forum at nginx.us Tue Sep 18 07:51:15 2012 From: nginx-forum at nginx.us (Shurman) Date: Tue, 18 Sep 2012 03:51:15 -0400 Subject: =?UTF-8?Q?Ranges_=D0=B8_octet-stream?= Message-ID: <096bcb15cc85d75c11fd152cc3a32828.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Пытаемся использовать nginx как кеширующий прокси для отдачи контента. Даже в случае, когда отдаваемые файлы берутся из кеша (специально вставляю заголовок add_header X-Cached $upstream_cache_status;) - для них нет заголовка Accept-Ranges. Хотя для, например, картинок - всё ок. Как заставить nginx поддерживать Ranges для всего контента, отдаваемого из кеша? Вот примеры заголовков: [root at web1 ~]# curl -I "http://localhost/DoDownload?VODNumber=45439&token=12345" HTTP/1.1 200 OK Server: nginx/1.2.3 Date: Tue, 18 Sep 2012 07:41:57 GMT Content-Type: application/octet-stream Content-Length: 117313265 Connection: keep-alive Content-Disposition: attachment; filename=Vytf68413860 Content-Transfer-Encoding: binary X-Cached: HIT А вот картинка: [root at web1 conf.d]# curl -I "http://localhost/tomcat.png" HTTP/1.1 200 OK Server: nginx/1.2.3 Date: Tue, 18 Sep 2012 07:47:29 GMT Content-Type: image/png Content-Length: 5103 Connection: keep-alive ETag: W/"5103-1333205040000" Last-Modified: Sat, 31 Mar 2012 14:44:00 GMT X-Cached: HIT Accept-Ranges: bytes Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230809,230809#msg-230809 From mdounin at mdounin.ru Tue Sep 18 10:18:55 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 18 Sep 2012 14:18:55 +0400 Subject: =?UTF-8?Q?Re=3A_Ranges_=D0=B8_octet-stream?= In-Reply-To: <096bcb15cc85d75c11fd152cc3a32828.NginxMailingListRussian@forum.nginx.org> References: <096bcb15cc85d75c11fd152cc3a32828.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120918101855.GT40452@mdounin.ru> Hello! On Tue, Sep 18, 2012 at 03:51:15AM -0400, Shurman wrote: > Пытаемся использовать nginx как кеширующий прокси для отдачи контента. Даже > в случае, когда отдаваемые файлы берутся из кеша (специально вставляю > заголовок add_header X-Cached $upstream_cache_status;) - для них нет > заголовка Accept-Ranges. Хотя для, например, картинок - всё ок. Как > заставить nginx поддерживать Ranges для всего контента, отдаваемого из > кеша? Чтобы для отдаваемого из кеша ответа поддерживались range-запросы - в закешированном ответе бекенда должен присутствовать заголовок Accept-Ranges. Maxim Dounin From nginx-forum at nginx.us Tue Sep 18 13:15:03 2012 From: nginx-forum at nginx.us (mikhal123) Date: Tue, 18 Sep 2012 09:15:03 -0400 Subject: =?UTF-8?B?bmdpbnggc3RhdHVzOiByZWFkaW5nIDEwMC0yMDAsIHdyaXRpbmcgMS01LiDQmtCw?= =?UTF-8?B?0Log0L/QvtCx0L7RgNC+0YLRjD8=?= Message-ID: <0fd1a6a9466e75a5dcd0147ecbe2cf9c.NginxMailingListRussian@forum.nginx.org> Подскажите, как бороться с тем что большое количество запросов висит в статуcе reading? На сайте немало мелких файлов, поэтому запросов на чтение много. Но проблема почему-то не в отдаче (после соединения отдается практически мгновенно), а в установке самого соединения. Соединение временами по 300-500 мс устанавливается, что совсем не радует. worker_processes менял в промежутке от 8 до 32, но как-то особо не влияет. Сервер не особо загруженный (la < 0.5-0.7), процессор и диск шустрые, оперативной памяти навалом. ---------------------- http://coolsite.ru/nginx-status Active connections: 1319 server accepts handled requests 25124 25124 46243 Reading: 128 Writing: 1 Waiting: 1190 ---------------------- nginx -v nginx version: nginx/1.2.3 ---------------------- cat nginx.conf user www-data; timer_resolution 100ms; worker_priority -5; worker_processes 16; worker_rlimit_nofile 65536; worker_rlimit_sigpending 32768; pid /var/run/nginx.pid; events { worker_connections 8192; use epoll; } http { include /etc/nginx/mime.types; default_type application/octet-stream; server_names_hash_bucket_size 128; log_format main '$remote_addr = $time_local = $request_time = $body_bytes_sent = "$status" = "$request" = "$http_referer" = "$http_user_agent"'; access_log /dev/null; error_log /var/log/nginx/error.log error; client_header_timeout 10; client_body_timeout 15; client_max_body_size 20m; client_header_buffer_size 16k; large_client_header_buffers 8 64k; send_timeout 10; proxy_read_timeout 15s; proxy_connect_timeout 15s; proxy_send_timeout 15s; proxy_buffers 16 64k; proxy_buffer_size 32k; msie_padding on; ignore_invalid_headers on; gzip on; gzip_static on; gzip_vary on; gzip_min_length 2048; gzip_comp_level 5; gzip_buffers 16 8k; gzip_types text/plain text/css text/xml text/javascript application/x-javascript; directio 4m; sendfile on; sendfile_max_chunk 256k; tcp_nopush on; tcp_nodelay on; reset_timedout_connection on; output_buffers 16 512k; postpone_output 1460; keepalive_timeout 30 15; #optimize_server_names off; server_name_in_redirect off; index index.php; open_file_cache max=8192 inactive=600s; open_file_cache_valid 600s; open_file_cache_min_uses 3; open_file_cache_errors on; server_tokens off; client_body_temp_path /var/lib/nginx/body; proxy_temp_path /var/lib/nginx/proxy; fastcgi_temp_path /var/lib/nginx/fastcgi; fastcgi_buffers 8 16k; fastcgi_buffer_size 32k; fastcgi_cache_path /var/lib/nginx/cache levels= keys_zone=main_site_zone:32m inactive=5m max_size=1024m; server { listen 80 default_server sndbuf=512k; server_name coolsite.ru www.coolsite.ru; root /var/www/vhosts/coolsite.ru/httpdocs; index index.php; fastcgi_index index.php; location = /_.gif { empty_gif; expires 30d; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME /var/www/vhosts/coolsite.ru/httpdocs$fastcgi_script_name; include /etc/nginx/fastcgi_params; access_log /var/log/nginx/access.log main; } } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230814,230814#msg-230814 From nginx-forum at nginx.us Tue Sep 18 15:30:07 2012 From: nginx-forum at nginx.us (Shurman) Date: Tue, 18 Sep 2012 11:30:07 -0400 Subject: =?UTF-8?Q?Re=3A_Ranges_=D0=B8_octet-stream?= In-Reply-To: <20120918101855.GT40452@mdounin.ru> References: <20120918101855.GT40452@mdounin.ru> Message-ID: <2134da109e9b2f944bf0068df1cdc308.NginxMailingListRussian@forum.nginx.org> Максим, Спасибо, принудительное добавление заголовка в ответы бэкенда помогло. Хоть бэкенд и не умеет отдавать это дело по частям - но кеш+заголовок делают дело. PS. Также добавил патч, который позволяет отдавать части даже если файла ещё нет в кеше. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230809,230816#msg-230816 From voron at amhost.net Tue Sep 18 17:19:53 2012 From: voron at amhost.net (Alex Vorona) Date: Tue, 18 Sep 2012 20:19:53 +0300 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?0JrQsNC6INC/0L7QsdC+0YDQvtGC0Yw/?= In-Reply-To: <0fd1a6a9466e75a5dcd0147ecbe2cf9c.NginxMailingListRussian@forum.nginx.org> References: <0fd1a6a9466e75a5dcd0147ecbe2cf9c.NginxMailingListRussian@forum.nginx.org> Message-ID: <5058AD39.4060606@amhost.net> 18.09.2012 16:15, mikhal123 wrote: > Подскажите, как бороться с тем что большое количество запросов висит в > статуcе reading? На сайте немало мелких файлов, поэтому запросов на чтение > много. Но проблема почему-то не в отдаче (после соединения отдается > практически мгновенно), а в установке самого соединения. Соединение > временами по 300-500 мс устанавливается, что совсем не радует. > worker_processes менял в промежутке от 8 до 32, но как-то особо не влияет. > > Сервер не особо загруженный (la < 0.5-0.7), процессор и диск шустрые, > оперативной памяти навалом. [...] > server { > listen 80 default_server sndbuf=512k; - listen 80 default_server sndbuf=512k; + listen 80 default_server sndbuf=512k backlog=1024; И в sysctl net.core.somaxconn = 1024 net.ipv4.tcp_max_syn_backlog = 1024 После чего reload nginx. From nginx-forum at nginx.us Tue Sep 18 18:06:08 2012 From: nginx-forum at nginx.us (mikhal123) Date: Tue, 18 Sep 2012 14:06:08 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?0JrQsNC6INC/0L7QsdC+0YDQvtGC0Yw/?= In-Reply-To: <5058AD39.4060606@amhost.net> References: <5058AD39.4060606@amhost.net> Message-ID: <3a7b9517378c3d6865ce19c8196ce088.NginxMailingListRussian@forum.nginx.org> после применения указанных рекомендаций ничего не изменилось Active connections: 1836 server accepts handled requests 87968 87968 160775 Reading: 195 Writing: 3 Waiting: 1638 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230818,230819#msg-230819 From nginx-forum at nginx.us Tue Sep 18 18:27:11 2012 From: nginx-forum at nginx.us (mikhal123) Date: Tue, 18 Sep 2012 14:27:11 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?0JrQsNC6INC/0L7QsdC+0YDQvtGC0Yw/?= In-Reply-To: <3a7b9517378c3d6865ce19c8196ce088.NginxMailingListRussian@forum.nginx.org> References: <5058AD39.4060606@amhost.net> <3a7b9517378c3d6865ce19c8196ce088.NginxMailingListRussian@forum.nginx.org> Message-ID: и я не знаю относится ли это к вопросу, но при error_log info в лог заносятся пачками сообщения вида 2012/09/18 22:08:32 [info] 40545#0: *3946 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40545#0: *3950 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40545#0: *3951 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40545#0: *3952 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40545#0: *3954 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3956 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3957 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3959 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3961 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3962 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3963 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3965 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3966 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3967 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3968 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3969 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3970 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3972 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 2012/09/18 22:08:32 [info] 40550#0: *3977 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 и 2012/09/18 22:08:32 [info] 40559#0: *4497 client prematurely closed connection while reading client request line, client: 89.22.22.11, server: coolsite.ru 2012/09/18 22:08:32 [info] 40558#0: *4603 client prematurely closed connection while reading client request line, client: 89.22.22.11, server: coolsite.ru 2012/09/18 22:08:32 [info] 40559#0: *4490 client prematurely closed connection while reading client request line, client: 89.22.22.11, server: coolsite.ru 2012/09/18 22:08:32 [info] 40559#0: *4494 client prematurely closed connection while reading client request line, client: 89.22.22.11, server: coolsite.ru 2012/09/18 22:08:32 [info] 40558#0: *4598 client prematurely closed connection while reading client request line, client: 89.22.22.11, server: coolsite.ru 2012/09/18 22:08:32 [info] 40559#0: *4493 client prematurely closed connection while reading client request line, client: 89.22.22.11, server: coolsite.ru 2012/09/18 22:08:32 [info] 40559#0: *4491 client prematurely closed connection while reading client request line, client: 89.22.22.11, server: coolsite.ru 2012/09/18 22:08:32 [info] 40559#0: *4489 client prematurely closed connection while reading client request line, client: 89.22.22.11, server: coolsite.ru примечательно что такие сообщения повляются пачками (обратите внимание на время и айпи клиента) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230818,230820#msg-230820 From voron at amhost.net Tue Sep 18 18:58:29 2012 From: voron at amhost.net (Alex Vorona) Date: Tue, 18 Sep 2012 21:58:29 +0300 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?0JrQsNC6INC/0L7QsdC+0YDQvtGC0Yw/?= In-Reply-To: <3a7b9517378c3d6865ce19c8196ce088.NginxMailingListRussian@forum.nginx.org> References: <5058AD39.4060606@amhost.net> <3a7b9517378c3d6865ce19c8196ce088.NginxMailingListRussian@forum.nginx.org> Message-ID: <5058C455.9030805@amhost.net> 18.09.2012 21:06, mikhal123 wrote: > после применения указанных рекомендаций ничего не изменилось Я бы так не сказал > Active connections: 1836 > server accepts handled requests > 87968 87968 160775 > Reading: 195 Writing: 3 Waiting: 1638 А раньше в Reading было 128 18.09.2012 16:15, mikhal123 wrote: >Но проблема почему-то не в отдаче (после соединения отдается >практически мгновенно), а в установке самого соединения. Соединение >временами по 300-500 мс устанавливается, что совсем не радует. Эта проблема должна уйти. From nginx-forum at nginx.us Tue Sep 18 19:24:32 2012 From: nginx-forum at nginx.us (mikhal123) Date: Tue, 18 Sep 2012 15:24:32 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?0JrQsNC6INC/0L7QsdC+0YDQvtGC0Yw/?= In-Reply-To: <5058C455.9030805@amhost.net> References: <5058C455.9030805@amhost.net> Message-ID: <2abbc9727cb6116ad968dd2c45d633ee.NginxMailingListRussian@forum.nginx.org> да не, похоже что все не так просто порыскав в архиве рассылки, нашел интересную беседу о примерно похожих симптомах http://mailman.nginx.org/pipermail/nginx-ru/2009-July/026138.html и действительно, после -client_header_timeout 10; +client_header_timeout 3; -keepalive_timeout 30 15; +keepalive_timeout 15 10; количество загадочных соединений уменьшилось Active connections: 623 server accepts handled requests 7079 7079 13916 Reading: 29 Writing: 1 Waiting: 593 причем по протоколу видно что одни и теже IP с промежутком в пять минут ломятся на сервер и отваливаются по таймауту 2012/09/18 22:08:32 [info] 40550#0: *3977 client timed out (110: Connection timed out) while reading client request line, client: 91.212.217.236, server: 0.0.0.0:80 поэтому тема топика изменяется на - "есть ли какие-нибудь предложения по отлову таких нехороших айпи"? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230818,230823#msg-230823 From ne at vbart.ru Tue Sep 18 20:20:50 2012 From: ne at vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 19 Sep 2012 00:20:50 +0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?INCa0LDQuiDQv9C+0LHQvtGA0L7RgtGMPw==?= In-Reply-To: <2abbc9727cb6116ad968dd2c45d633ee.NginxMailingListRussian@forum.nginx.org> References: <5058C455.9030805@amhost.net> <2abbc9727cb6116ad968dd2c45d633ee.NginxMailingListRussian@forum.nginx.org> Message-ID: <201209190020.50224.ne@vbart.ru> On Tuesday 18 September 2012 23:24:32 mikhal123 wrote: [...] > причем по протоколу видно что одни и теже IP с промежутком в пять минут > ломятся на сервер и отваливаются по таймауту > 2012/09/18 22:08:32 [info] 40550#0: *3977 client timed out (110: Connection > timed out) while reading client request line, client: 91.212.217.236, > server: 0.0.0.0:80 > > > поэтому тема топика изменяется на - "есть ли какие-нибудь предложения по > отлову таких нехороших айпи"? > А если посмотреть по access-логу эти айпишники, шлют они только такие запросы, или хорошие тоже? -- Валентин Бартенев From mdounin at mdounin.ru Tue Sep 18 20:43:13 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 19 Sep 2012 00:43:13 +0400 Subject: nginx-1.3.1 In-Reply-To: <2dafbe601feb7170333ee9185ce7950f.NginxMailingListRussian@forum.nginx.org> References: <20120917172240.GF40452@mdounin.ru> <2dafbe601feb7170333ee9185ce7950f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120918204313.GX40452@mdounin.ru> Hello! On Mon, Sep 17, 2012 at 06:17:43PM -0400, ruv wrote: > Привет! > > Maxim Dounin Wrote: > > Ну как мнимум два пути решения проблемы очевидны: отказаться от > > trailing dots или использовать proxy_pass без URI. И я совершенно > > не уверен, что изобретать третий, притом не безопасный путь - это > > хорошая идея. > > Согласен. Но таки придется признать, что обратная совместимость частично > поломана > (в том смысле, что то, что работало ? перестало работать после обновления). > Думаю, исправления, которые ломают обратную совместимость, следует как-то > особо помечать в CHANGES. Обычно в CHANGES подобные изменения отмечаются как "Change", в данном случае - как "Security", ибо изменение одновременно является исправлением для проблемы безопасности, что важнее. > Отказаться от trailing dots очень трудно (уже попали в имена и "высечены в > камне"; к файловой системе это не имеет отношения). Придется сделать > proxy_pass без URI и подправить бэкенды. > > Кстати, а что там насчет ":$"? Получается, для такого случая и обхода > нету? Да. Впрочем, апач, насколько я понимаю, вообще отвергает все запросы с ":", так что nginx в этом вопросе предельно гуманен. Maxim Dounin From nginx-forum at nginx.us Tue Sep 18 22:26:56 2012 From: nginx-forum at nginx.us (mikhal123) Date: Tue, 18 Sep 2012 18:26:56 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?0JrQsNC6INC/0L7QsdC+0YDQvtGC0Yw/?= In-Reply-To: <201209190020.50224.ne@vbart.ru> References: <201209190020.50224.ne@vbart.ru> Message-ID: <377254fe23be005738e0ff860d67a286.NginxMailingListRussian@forum.nginx.org> VBart Wrote: ------------------------------------------------------- > А если посмотреть по access-логу эти айпишники, шлют они только такие > запросы, > или хорошие тоже? При более детальном разборе стало ясно, что такую активность создают (в том числе) и довольно давно зарегистрированные пользователи сайта. Но я вообще не понимаю логику работы их клиентов (браузеров). Вот допустим на примере 77.223.64.124. Он начинается запрашивать страничку с сервера (причем не в первом по порядку соединении, первые 2-3 устанавливаются и "молчат") 2012/09/19 01:32:58 [debug] 48557#0: *28 accept: 77.223.64.124 fd:30 2012/09/19 01:32:58 [debug] 48557#0: *28 event timer add: 30: 3000:1348003981827 2012/09/19 01:32:58 [debug] 48557#0: *28 epoll add event: fd:30 op:1 ev:80000001 2012/09/19 01:32:58 [debug] 48557#0: *28 post event 00007FA86915C218 2012/09/19 01:32:58 [debug] 48557#0: *28 delete posted event 00007FA86915C218 2012/09/19 01:32:58 [debug] 48557#0: *28 malloc: 00000000006FDB80:1296 2012/09/19 01:32:58 [debug] 48557#0: *28 posix_memalign: 00000000006FE0A0:256 @16 2012/09/19 01:32:58 [debug] 48557#0: *28 malloc: 00000000007F6550:16384 2012/09/19 01:32:58 [debug] 48557#0: *28 posix_memalign: 00000000007B75D0:4096 @16 2012/09/19 01:32:58 [debug] 48557#0: *28 http process request line 2012/09/19 01:32:58 [debug] 48557#0: *28 recv: fd:30 804 of 16384 2012/09/19 01:32:58 [debug] 48557#0: *28 http request line: "GET /some_url.php HTTP/1.1" 2012/09/19 01:32:58 [debug] 48557#0: *28 http uri: "/some_url.php" 2012/09/19 01:32:58 [debug] 48557#0: *28 http args: "" 2012/09/19 01:32:58 [debug] 48557#0: *28 http exten: "php" 2012/09/19 01:32:58 [debug] 48557#0: *28 http process request header line 2012/09/19 01:32:58 [debug] 48557#0: *28 http header: "Host: coolsite.ru" 2012/09/19 01:32:58 [debug] 48557#0: *28 http header: "Connection: keep-alive" 2012/09/19 01:32:58 [debug] 48557#0: *28 http header: "User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1" 2012/09/19 01:32:58 [debug] 48557#0: *28 http header: "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" 2012/09/19 01:32:58 [debug] 48557#0: *28 http header: "Accept-Encoding: gzip,deflate,sdch" 2012/09/19 01:32:58 [debug] 48557#0: *28 http header: "Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4" 2012/09/19 01:32:58 [debug] 48557#0: *28 http header: "Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3" Ну и дальше идет нормальная обработка этого запроса, и клиенту вроде даже что-то отправляется. Одновременно с нормальным запросом он открывает еще тучу соединений и никак их не использует: 2012/09/19 01:32:58 [debug] 48557#0: *31 accept: 77.223.64.124 fd:32 2012/09/19 01:32:58 [debug] 48557#0: *31 event timer add: 32: 3000:1348003981827 2012/09/19 01:32:58 [debug] 48557#0: *31 epoll add event: fd:32 op:1 ev:80000001 2012/09/19 01:32:58 [debug] 48557#0: post event 00007FA86915C010 2012/09/19 01:32:58 [debug] 48557#0: delete posted event 00007FA86915C010 2012/09/19 01:32:58 [debug] 48557#0: accept on 0.0.0.0:80, ready: 0 2012/09/19 01:32:58 [debug] 48557#0: posix_memalign: 00000000006FE2C0:256 @16 2012/09/19 01:32:58 [debug] 48557#0: *32 accept: 77.223.64.124 fd:43 2012/09/19 01:32:58 [debug] 48557#0: *32 event timer add: 43: 3000:1348003981827 2012/09/19 01:32:58 [debug] 48557#0: *32 epoll add event: fd:43 op:1 ev:80000001 2012/09/19 01:32:58 [debug] 48557#0: post event 00007FA86915C010 2012/09/19 01:32:58 [debug] 48557#0: delete posted event 00007FA86915C010 2012/09/19 01:32:58 [debug] 48557#0: accept on 0.0.0.0:80, ready: 0 2012/09/19 01:32:58 [debug] 48557#0: posix_memalign: 00000000006FE3D0:256 @16 2012/09/19 01:32:58 [debug] 48557#0: *33 accept: 77.223.64.124 fd:44 2012/09/19 01:32:58 [debug] 48557#0: *33 event timer add: 44: 3000:1348003981827 2012/09/19 01:32:58 [debug] 48557#0: *33 epoll add event: fd:44 op:1 ev:80000001 2012/09/19 01:32:58 [debug] 48557#0: post event 00007FA86915C010 2012/09/19 01:32:58 [debug] 48557#0: delete posted event 00007FA86915C010 2012/09/19 01:32:58 [debug] 48557#0: accept on 0.0.0.0:80, ready: 0 2012/09/19 01:32:58 [debug] 48557#0: posix_memalign: 00000000006FE4E0:256 @16 2012/09/19 01:32:58 [debug] 48557#0: *34 accept: 77.223.64.124 fd:45 2012/09/19 01:32:58 [debug] 48557#0: *34 event timer add: 45: 3000:1348003981827 2012/09/19 01:32:58 [debug] 48557#0: *34 epoll add event: fd:45 op:1 ev:80000001 2012/09/19 01:32:58 [debug] 48557#0: post event 00007FA86915C010 2012/09/19 01:32:58 [debug] 48557#0: delete posted event 00007FA86915C010 2012/09/19 01:32:58 [debug] 48557#0: accept on 0.0.0.0:80, ready: 0 2012/09/19 01:32:58 [debug] 48557#0: posix_memalign: 00000000006FE5F0:256 @16 2012/09/19 01:32:58 [debug] 48557#0: *35 accept: 77.223.64.124 fd:46 2012/09/19 01:32:58 [debug] 48557#0: *35 event timer add: 46: 3000:1348003981827 2012/09/19 01:32:58 [debug] 48557#0: *35 epoll add event: fd:46 op:1 ev:80000001 2012/09/19 01:32:58 [debug] 48557#0: post event 00007FA86915C010 2012/09/19 01:32:58 [debug] 48557#0: delete posted event 00007FA86915C010 2012/09/19 01:32:58 [debug] 48557#0: accept on 0.0.0.0:80, ready: 0 2012/09/19 01:32:58 [debug] 48557#0: posix_memalign: 00000000006FE700:256 @16 2012/09/19 01:32:58 [debug] 48557#0: *36 accept: 77.223.64.124 fd:47 2012/09/19 01:32:58 [debug] 48557#0: *36 event timer add: 47: 3000:1348003981827 2012/09/19 01:32:58 [debug] 48557#0: *36 epoll add event: fd:47 op:1 ev:80000001 2012/09/19 01:32:58 [debug] 48557#0: post event 00007FA86915C010 2012/09/19 01:32:58 [debug] 48557#0: delete posted event 00007FA86915C010 2012/09/19 01:32:58 [debug] 48557#0: accept on 0.0.0.0:80, ready: 0 2012/09/19 01:32:58 [debug] 48557#0: posix_memalign: 00000000006FE810:256 @16 ну и так далее, еще штук 5-10. затем наступает тишина, и через client_header_timeout (сейчас 3 секунды, раньше 10 секунд) все эти соединения отваливаются по таймауту: 2012/09/19 01:33:01 [info] 48557#0: *24 client timed out (110: Connection timed out) while reading client request line, client: 77.223.64.124, server: 0.0.0.0:80 2012/09/19 01:33:01 [debug] 48557#0: *24 close http connection: 36 2012/09/19 01:33:01 [debug] 48557#0: *24 reusable connection: 0 2012/09/19 01:33:01 [debug] 48557#0: *24 free: 00000000007BA250, unused: 48 2012/09/19 01:33:01 [debug] 48557#0: *25 event timer del: 37: 1348003981827 2012/09/19 01:33:01 [info] 48557#0: *25 client timed out (110: Connection timed out) while reading client request line, client: 77.223.64.124, server: 0.0.0.0:80 2012/09/19 01:33:01 [debug] 48557#0: *25 close http connection: 37 2012/09/19 01:33:01 [debug] 48557#0: *25 reusable connection: 0 2012/09/19 01:33:01 [debug] 48557#0: *25 free: 00000000007BA360, unused: 48 2012/09/19 01:33:01 [debug] 48557#0: *30 event timer del: 42: 1348003981827 2012/09/19 01:33:01 [info] 48557#0: *30 client timed out (110: Connection timed out) while reading client request line, client: 77.223.64.124, server: 0.0.0.0:80 2012/09/19 01:33:01 [debug] 48557#0: *30 close http connection: 42 2012/09/19 01:33:01 [debug] 48557#0: *30 reusable connection: 0 2012/09/19 01:33:01 [debug] 48557#0: *30 free: 00000000007B85E0, unused: 48 2012/09/19 01:33:01 [debug] 48557#0: *31 event timer del: 32: 1348003981827 2012/09/19 01:33:01 [info] 48557#0: *31 client timed out (110: Connection timed out) while reading client request line, client: 77.223.64.124, server: 0.0.0.0:80 2012/09/19 01:33:01 [debug] 48557#0: *31 close http connection: 32 2012/09/19 01:33:01 [debug] 48557#0: *31 reusable connection: 0 2012/09/19 01:33:01 [debug] 48557#0: *31 free: 00000000006FE1B0, unused: 48 2012/09/19 01:33:01 [debug] 48557#0: *32 event timer del: 43: 1348003981827 2012/09/19 01:33:01 [info] 48557#0: *32 client timed out (110: Connection timed out) while reading client request line, client: 77.223.64.124, server: 0.0.0.0:80 2012/09/19 01:33:01 [debug] 48557#0: *32 close http connection: 43 2012/09/19 01:33:01 [debug] 48557#0: *32 reusable connection: 0 2012/09/19 01:33:01 [debug] 48557#0: *32 free: 00000000006FE2C0, unused: 48 2012/09/19 01:33:01 [debug] 48557#0: *33 event timer del: 44: 1348003981827 2012/09/19 01:33:01 [info] 48557#0: *33 client timed out (110: Connection timed out) while reading client request line, client: 77.223.64.124, server: 0.0.0.0:80 2012/09/19 01:33:01 [debug] 48557#0: *33 close http connection: 44 2012/09/19 01:33:01 [debug] 48557#0: *33 reusable connection: 0 2012/09/19 01:33:01 [debug] 48557#0: *33 free: 00000000006FE3D0, unused: 48 2012/09/19 01:33:01 [debug] 48557#0: *34 event timer del: 45: 1348003981827 и так далее, все что было открыто ранее. Как я понимаю, именно эти соединения и влияют на показатель "reading" в nginx_status. Через какое-то время это опять повторяется. Разве при нормальной работе браузеры открывают столько соединений и после этого "молчат" в них? И что это за юзерагент такой - "USER_AGENT: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1"??? В общем ничего не понимаю :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230818,230828#msg-230828 From ne at vbart.ru Tue Sep 18 23:04:54 2012 From: ne at vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 19 Sep 2012 03:04:54 +0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?INCa0LDQuiDQv9C+0LHQvtGA0L7RgtGMPw==?= In-Reply-To: <377254fe23be005738e0ff860d67a286.NginxMailingListRussian@forum.nginx.org> References: <201209190020.50224.ne@vbart.ru> <377254fe23be005738e0ff860d67a286.NginxMailingListRussian@forum.nginx.org> Message-ID: <201209190304.54705.ne@vbart.ru> On Wednesday 19 September 2012 02:26:56 mikhal123 wrote: [...] > Разве при нормальной работе браузеры открывают столько соединений и после > этого "молчат" в них? И что это за юзерагент такой - "USER_AGENT: > Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) > Chrome/21.0.1180.89 Safari/537.1"??? В общем ничего не понимаю :) > Это обычное поведение хрома. Этот браузер ради того, чтобы быть максимально быстрым, не стесняется открывать кучу соединений "про запас" ради экономии времени на хэндшейке, если соединение все-таки понадобиться. -- Валентин Бартенев From infoman1985 at gmail.com Wed Sep 19 03:28:27 2012 From: infoman1985 at gmail.com (=?UTF-8?B?0JTQtdC90LjRgSDQnNC40YHRjtGA0LrQsA==?=) Date: Wed, 19 Sep 2012 06:28:27 +0300 Subject: =?UTF-8?B?0J/QtdGA0LXQtNCw0LLQsNGC0Ywg0YLQtdC70L4g0LfQsNC/0YDQvtGB0LAg0L0=?= =?UTF-8?B?0LDQv9GA0Y/QvNGD0Y4g0LHRjdC60LXQvdC00YMg4oCUINCy0L7Qt9C80L4=?= =?UTF-8?B?0LbQvdC+Pw==?= Message-ID: Задача такая. Есть сервер, на сервере крутятся несколько контейнеров OpenVZ. Frontend-прокси смотрит на заголовок Host HTTP-запроса и решает, какому из контейнеров этот запрос отправить. Конфигурация 1: фронтендом стоит Pound, бэкендом в контейнере крутится nginx с Passenger и upload_progress_module. Всё прекрасно работает, прогресс загрузки отображается, все счастливы. Конфигурация 2: всё то же самое, только для упрощения конфиг-файла, который должен определять, какому контейнеру какой запрос обрабатывать, вместо pound поставили тоже nginx, в котором через map определён список хостов и соотвествующих бэкендов. Не работает. upload_progress упорно показывает state: starting до самой победы. Как я понял, это происходит из-за того, что nginx на фронтнде кэширует запрос сначала в свой внутренний буфер, и только потом отдаёт его бэкенду. Возможно ли как-то отключить такое поведение и пересылать запрос в бэкенд напрямую, или придётся ставить upload_progress на фронтенд и рисковать потерей совместимости с приложениями на других бэкендах, у которых путь /progress может означать нечто совсем иное и стать из-за этого недоступным? From onokonem at gmail.com Wed Sep 19 04:22:28 2012 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 19 Sep 2012 08:22:28 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LTQsNCy0LDRgtGMINGC0LXQu9C+INC30LDQv9GA0L7RgdCw?= =?UTF-8?B?INC90LDQv9GA0Y/QvNGD0Y4g0LHRjdC60LXQvdC00YMgLS0g0LLQvtC30Lw=?= =?UTF-8?B?0L7QttC90L4/?= In-Reply-To: References: Message-ID: > Возможно ли как-то отключить такое поведение и пересылать > запрос в бэкенд напрямую нет, не возможно. From nginx-forum at nginx.us Wed Sep 19 04:56:08 2012 From: nginx-forum at nginx.us (anebilyca) Date: Wed, 19 Sep 2012 00:56:08 -0400 Subject: =?UTF-8?B?MzAxINGA0LXQtNC40YDQtdC60YIg0LTQu9GPINC90LXRgdC60L7Qu9GM0LrQuNGF?= =?UTF-8?B?INGB0YLRgNCw0L3QuNGGINGB0LDQudGC0LA=?= Message-ID: <1b69b43b515ed678aec9a1d1ab18128f.NginxMailingListRussian@forum.nginx.org> Приветствую! Немного о пациенте. Стоит nginx/0.7.65. Необходимо настроить 301 редирект с нескольких страниц сайта на подобные им, но более короткие. Самый первый вопрос, это как точно называется файл, в котором необходимо это всё прописывать? Например, в апаче это .htacces. А здесь? Ну и как я увидел, есть несколько вариантов реализации. Хотелось бы узнать у вас какой применим в моей ситуации и некоторые комментарии по вопросам, которые у меня возникли. И так. 1. Способ. Код: server { listen 80; server_name www.host.ru/1-page; rewrite ^ www.host.ru/2-page$request_uri? permanent; #301 redirect } server { listen 80; server_name .host.ru; ..... основной конфиг ..... } Но здесь у меня вопрос: что это за часть кода Код: server { listen 80; server_name .host.ru; ..... основной конфиг ..... } Куда её вставлять? Сразу после первой части? 2. Способ. Код: server { include redirect.conf; redirect.conf: location = /1-page { return 301 http://host.ru/2-page; } location = /3-page { return 301 http://host.ru/4-page; } } Можно ли употреблять такую структуру, если я буду редиректить на разные страницы, а не на главную, как я видел в одном примере? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230844,230844#msg-230844 From nginx-forum at nginx.us Wed Sep 19 04:56:08 2012 From: nginx-forum at nginx.us (anebilyca) Date: Wed, 19 Sep 2012 00:56:08 -0400 Subject: =?UTF-8?B?MzAxINGA0LXQtNC40YDQtdC60YIg0LTQu9GPINC90LXRgdC60L7Qu9GM0LrQuNGF?= =?UTF-8?B?INGB0YLRgNCw0L3QuNGGINGB0LDQudGC0LA=?= Message-ID: <1b69b43b515ed678aec9a1d1ab18128f.NginxMailingListRussian@forum.nginx.org> Приветствую! Немного о пациенте. Стоит nginx/0.7.65. Необходимо настроить 301 редирект с нескольких страниц сайта на подобные им, но более короткие. Самый первый вопрос, это как точно называется файл, в котором необходимо это всё прописывать? Например, в апаче это .htacces. А здесь? Ну и как я увидел, есть несколько вариантов реализации. Хотелось бы узнать у вас какой применим в моей ситуации и некоторые комментарии по вопросам, которые у меня возникли. И так. 1. Способ. Код: server { listen 80; server_name www.host.ru/1-page; rewrite ^ www.host.ru/2-page$request_uri? permanent; #301 redirect } server { listen 80; server_name .host.ru; ..... основной конфиг ..... } Но здесь у меня вопрос: что это за часть кода Код: server { listen 80; server_name .host.ru; ..... основной конфиг ..... } Куда её вставлять? Сразу после первой части? 2. Способ. Код: server { include redirect.conf; redirect.conf: location = /1-page { return 301 http://host.ru/2-page; } location = /3-page { return 301 http://host.ru/4-page; } } Можно ли употреблять такую структуру, если я буду редиректить на разные страницы, а не на главную, как я видел в одном примере? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230844,230844#msg-230844 From ne at vbart.ru Wed Sep 19 06:39:12 2012 From: ne at vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 19 Sep 2012 10:39:12 +0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LTQsNCy0LDRgtGMINGC0LXQu9C+INC30LDQv9GA0L7RgdCw?= =?UTF-8?B?INC90LDQv9GA0Y/QvNGD0Y4g0LHRjdC60LXQvdC00YMg4oCUINCy0L7Qt9C8?= =?UTF-8?B?0L7QttC90L4/?= In-Reply-To: References: Message-ID: <201209191039.12287.ne@vbart.ru> On Wednesday 19 September 2012 07:28:27 Денис Мисюрка wrote: [...] > Как я понял, это происходит из-за того, что nginx на фронтнде кэширует > запрос сначала в свой внутренний буфер, и только потом отдаёт его > бэкенду. Возможно ли как-то отключить такое поведение и пересылать > запрос в бэкенд напрямую, На текущий момент невозможно. > или придётся ставить upload_progress на фронтенд и рисковать потерей > совместимости с приложениями на других бэкендах, у которых путь > /progress может означать нечто совсем иное и стать из-за этого > недоступным? Укажите такой путь, который с вашим приложением не совпадает. Модуль upload_progress прекрасно конфигурируется на работу по любому пути и любым условиям. Хотя я вообще не понимаю, зачем использовать такие античные методы, когда большинство современных браузеров поддерживают XMLHttpRequest 2. http://caniuse.com/#feat=xhr2 Для IE9 и ниже - можно Flash прикрутить, или просто не отображать прогресс, их пользователи сами себя наказывают. -- Валентин Бартенев From nginx-forum at nginx.us Wed Sep 19 06:43:18 2012 From: nginx-forum at nginx.us (mikhal123) Date: Wed, 19 Sep 2012 02:43:18 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?0JrQsNC6INC/0L7QsdC+0YDQvtGC0Yw/?= In-Reply-To: <201209190304.54705.ne@vbart.ru> References: <201209190304.54705.ne@vbart.ru> Message-ID: <5f357a6ece7dcec927264e89f853f8e2.NginxMailingListRussian@forum.nginx.org> > > Разве при нормальной работе браузеры открывают столько соединений и > после > > этого "молчат" в них? И что это за юзерагент такой - "USER_AGENT: > > Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) > > Chrome/21.0.1180.89 Safari/537.1"??? В общем ничего не понимаю :) > > > > Это обычное поведение хрома. Этот браузер ради того, чтобы быть > максимально > быстрым, не стесняется открывать кучу соединений "про запас" ради > экономии > времени на хэндшейке, если соединение все-таки понадобиться. Какой замечательный браузер - открывать по 15 соединений за раз и использовать только одно из них. Неужели это никого не напрягает, все-таки при большой посещалке по сути получается бесплатный ддос для сервера? Ну и как итог - все это является следствием "нормального" поведения клиентских браузеров посетителей сайта, и с серверной стороны это никак не побороть? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230818,230849#msg-230849 From nginx-forum at nginx.us Wed Sep 19 07:04:37 2012 From: nginx-forum at nginx.us (kron) Date: Wed, 19 Sep 2012 03:04:37 -0400 Subject: =?UTF-8?B?UmU6IDMwMSDRgNC10LTQuNGA0LXQutGCINC00LvRjyDQvdC10YHQutC+0LvRjNC6?= =?UTF-8?B?0LjRhSDRgdGC0YDQsNC90LjRhiDRgdCw0LnRgtCw?= In-Reply-To: <1b69b43b515ed678aec9a1d1ab18128f.NginxMailingListRussian@forum.nginx.org> References: <1b69b43b515ed678aec9a1d1ab18128f.NginxMailingListRussian@forum.nginx.org> Message-ID: <0796c0c0b85aeaf2cdab73385084a4d9.NginxMailingListRussian@forum.nginx.org> server { listen 80; server_name host.ru; location / { return 301 http://www.host.ru; # переадресация на другой адрес } } server { listen 80; server_name www.host.ru; location / { ...основная обработка запросов... } location /1-page { return 301 /2-page; # переадресация на другой локейшн } location /2-page { ...обработка запроса.... } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230844,230850#msg-230850 From ne at vbart.ru Wed Sep 19 07:13:21 2012 From: ne at vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 19 Sep 2012 11:13:21 +0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?INCa0LDQuiDQv9C+0LHQvtGA0L7RgtGMPw==?= In-Reply-To: <5f357a6ece7dcec927264e89f853f8e2.NginxMailingListRussian@forum.nginx.org> References: <201209190304.54705.ne@vbart.ru> <5f357a6ece7dcec927264e89f853f8e2.NginxMailingListRussian@forum.nginx.org> Message-ID: <201209191113.21830.ne@vbart.ru> On Wednesday 19 September 2012 10:43:18 mikhal123 wrote: [...] > Какой замечательный браузер - открывать по 15 соединений за раз и > использовать только одно из них. Неужели это никого не напрягает, все-таки > при большой посещалке по сути получается бесплатный ддос для сервера? Можете написать жалобу в Google. =) Возможно они посочувствуют о том, что у вас меньше серверов, чем у них. Но вообще, я бы не переживал по этому поводу, nginx без проблем может держать и миллион соединений. > Ну и как итог - все это является следствием "нормального" поведения > клиентских браузеров посетителей сайта, и с серверной стороны это никак не > побороть? Стоит посмотреть в сторону accept-фильтров/TCP_DEFER_ACCEPT. http://nginx.org/r/listen/ru -- Валентин Бартенев From nginx-forum at nginx.us Wed Sep 19 07:42:23 2012 From: nginx-forum at nginx.us (mikhal123) Date: Wed, 19 Sep 2012 03:42:23 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?0JrQsNC6INC/0L7QsdC+0YDQvtGC0Yw/?= In-Reply-To: <201209191113.21830.ne@vbart.ru> References: <201209191113.21830.ne@vbart.ru> Message-ID: <2298d605cb31d23b81f15d993f729b37.NginxMailingListRussian@forum.nginx.org> > > Какой замечательный браузер - открывать по 15 соединений за раз и > > использовать только одно из них. Неужели это никого не напрягает, > все-таки > > при большой посещалке по сути получается бесплатный ддос для > сервера? > > Можете написать жалобу в Google. =) Возможно они посочувствуют о том, > что у вас меньше серверов, чем у них. ну тут дело все-таки не в мерянье количеством серверов, а в разумном использовании их ресурсов. к чему засирать сетевуху и сам сетевой стек, когда на загруженных проектах им и так хватает чем заняться? если пофантазировать, то по аналогии с директивой для ботов Crawl-delay можно сделать специально для жадных до соединений браузеров директиву, ограничивающую их апетиты. Правда где ее выдавать, если браузер устанавливает 15 соединений еще до того, как получит данные хотя бы из одного из них - непонятно :) > > Ну и как итог - все это является следствием "нормального" поведения > > клиентских браузеров посетителей сайта, и с серверной стороны это > > никак не побороть? > > Стоит посмотреть в сторону accept-фильтров/TCP_DEFER_ACCEPT. > http://nginx.org/r/listen/ru счастливым обладателям freebsd может быть и стоит, но у меня debian где это не поддерживается... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230818,230854#msg-230854 From ne at vbart.ru Wed Sep 19 08:23:42 2012 From: ne at vbart.ru (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 19 Sep 2012 12:23:42 +0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?INCa0LDQuiDQv9C+0LHQvtGA0L7RgtGMPw==?= In-Reply-To: <2298d605cb31d23b81f15d993f729b37.NginxMailingListRussian@forum.nginx.org> References: <201209191113.21830.ne@vbart.ru> <2298d605cb31d23b81f15d993f729b37.NginxMailingListRussian@forum.nginx.org> Message-ID: <201209191223.42707.ne@vbart.ru> On Wednesday 19 September 2012 11:42:23 mikhal123 wrote: [...] > > > Ну и как итог - все это является следствием "нормального" поведения > > > клиентских браузеров посетителей сайта, и с серверной стороны это > > > никак не побороть? > > > > Стоит посмотреть в сторону accept-фильтров/TCP_DEFER_ACCEPT. > > http://nginx.org/r/listen/ru > > счастливым обладателям freebsd может быть и стоит, но у меня debian где это > не поддерживается... > % uname Linux % man tcp TCP_DEFER_ACCEPT (since Linux 2.4) Allow a listener to be awakened only when data arrives on the socket. Takes an integer value (seconds), this can bound the maximum number of attempts TCP will make to complete the connec? tion. This option should not be used in code intended to be portable. -- Валентин Бартенев From kolomaxes at gmail.com Wed Sep 19 08:39:31 2012 From: kolomaxes at gmail.com (mxs kolo) Date: Wed, 19 Sep 2012 12:39:31 +0400 Subject: =?UTF-8?B?aW1hZ2VfZmlsdGVyX2pwZWdfcXVhbGl0eSDQvdC1INGA0LDQsdC+0YLQsNC10YIg?= =?UTF-8?B?0LHQtdC3INGD0LrQsNC30LDQvdC40Y8gaW1hZ2VfZmlsdGVyIHJvdGF0ZXxy?= =?UTF-8?B?ZXNpemV8Y3JvcA==?= Message-ID: Hi all У меня не получилось сделать так, чтобы модуль ngx_http_image_filter_module просто пережимал jpeg, без вращения его или ресайза. Я пробовал на версиях nginx 1.3.6, 1.3.5, 1.2.3 Возможно что я не прав и я просто не понял как правильно сделать конфиг, вот его кусок: location ~* \.(jpg|jpeg)$ { image_filter_buffer 10M; image_filter_jpeg_quality 75; image_filter_sharpen 25; root /var/www/vhosts/some-domain-here.ru/httpdocs/; } Изображение отдаётся без пережатия. Но если добавить в location строку image_filter rotate 180; то и картинка повернётся и jpg станет меньше по размеру и пошарпится. Но насколько я вижу по исходному коду такая функциональность вообще не предусмотрена без указания image_filter rotate|resize|crop. Дело в том что ngx_http_image_body_filter() не будет работать пока не указан фильтр, а фильтр задаётся только в ngx_http_image_filter() и там нет случая для "только quality" В аттаче есть патч которым я решил эту проблему для себя. Мне пришось добавить новый тип фильтра - quality_only. Мой конфиг теперь выглядит так: location ~* \.(jpg|jpeg)$ { image_filter quality_only; image_filter_buffer 10M; image_filter_jpeg_quality 75; image_filter_sharpen 25; root /var/www/vhosts/some-domain-here.ru/httpdocs/; } Я был -бы очень признателен, если-бы кто-то посмотрел патч на предмет ошибок. b.r. Maxim Kozin -------------- next part -------------- A non-text attachment was scrubbed... Name: ngx_http_image_filter_module_1_3_6.filter_quality_only.patch Type: application/octet-stream Size: 1284 bytes Desc: not available URL: From nginx-forum at nginx.us Wed Sep 19 08:56:10 2012 From: nginx-forum at nginx.us (mikhal123) Date: Wed, 19 Sep 2012 04:56:10 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?0JrQsNC6INC/0L7QsdC+0YDQvtGC0Yw/?= In-Reply-To: <201209191223.42707.ne@vbart.ru> References: <201209191223.42707.ne@vbart.ru> Message-ID: > > > > Ну и как итог - все это является следствием "нормального" > поведения > > > > клиентских браузеров посетителей сайта, и с серверной стороны > это > > > > никак не побороть? > > > > > > Стоит посмотреть в сторону accept-фильтров/TCP_DEFER_ACCEPT. > > > http://nginx.org/r/listen/ru > > > > счастливым обладателям freebsd может быть и стоит, но у меня debian > где это > > не поддерживается... > > > > % uname > Linux > % man tcp > > TCP_DEFER_ACCEPT (since Linux 2.4) > Allow a listener to be awakened only when data arrives > on the > socket. Takes an integer value (seconds), this can > bound the > maximum number of attempts TCP will make to complete the > connec? > tion. This option should not be used in code > intended to be > portable. > если бы все было так просто.... подозреваю, что разработчики хрома считают себя весьма хитрыми людьми и делают против этого какой-то трюк с фиктивной отсылкой данных: +listen 80 default_server backlog=1024 sndbuf=512k deferred; после этого в логах все еще интереснее: 2012/09/19 11:53:22 [debug] 27380#0: *421 accept: 79.164.125.238 fd:85 2012/09/19 11:53:22 [debug] 27380#0: *421 post event 00007FD536406738 2012/09/19 11:53:22 [debug] 27380#0: *421 delete posted event 00007FD536406738 2012/09/19 11:53:22 [debug] 27380#0: *421 malloc: 0000000000830860:1296 2012/09/19 11:53:22 [debug] 27380#0: *421 posix_memalign: 0000000000830D80:256 @16 2012/09/19 11:53:22 [debug] 27380#0: *421 malloc: 0000000000884870:16384 2012/09/19 11:53:22 [debug] 27380#0: *421 posix_memalign: 0000000000830E90:4096 @16 2012/09/19 11:53:22 [debug] 27380#0: *421 http process request line 2012/09/19 11:53:22 [debug] 27380#0: *421 recv: fd:85 -1 of 16384 2012/09/19 11:53:22 [debug] 27380#0: *421 recv() not ready (11: Resource temporarily unavailable) 2012/09/19 11:53:22 [debug] 27380#0: *421 event timer add: 85: 3000:1348041205251 2012/09/19 11:53:22 [debug] 27380#0: *421 epoll add event: fd:85 op:1 ev:80000001 и затем через 3 секунды 2012/09/19 11:53:25 [debug] 27380#0: *421 event timer del: 85: 1348041205251 2012/09/19 11:53:25 [debug] 27380#0: *421 http process request line 2012/09/19 11:53:25 [info] 27380#0: *421 client timed out (110: Connection timed out) while reading client request line, client: 79.164.125.238, server: coolsite.ru 2012/09/19 11:53:25 [debug] 27380#0: *421 http request count:1 blk:0 2012/09/19 11:53:25 [debug] 27380#0: *421 http close request 2012/09/19 11:53:25 [debug] 27380#0: *421 http log handler 2012/09/19 11:53:25 [debug] 27380#0: *421 free: 0000000000830E90, unused: 2208 2012/09/19 11:53:25 [debug] 27380#0: *421 close http connection: 85 2012/09/19 11:53:25 [debug] 27380#0: *421 reusable connection: 0 2012/09/19 11:53:25 [debug] 27380#0: *421 free: 0000000000884870 2012/09/19 11:53:25 [debug] 27380#0: *421 free: 0000000000830860 2012/09/19 11:53:25 [debug] 27380#0: *421 free: 0000000000830750, unused: 0 2012/09/19 11:53:25 [debug] 27380#0: *421 free: 0000000000830D80, unused: 112 то есть как я понимаю запрос шлется не целиком (может вообще 1 байт), затем соединение уходит в состояние ожидания и потом все равно также отваливается только по таймауту. в freebsd accf_http наверное помог бы (и то может они и для него чего-то делают), а в linux получается что все, финита Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230818,230858#msg-230858 From mdounin at mdounin.ru Wed Sep 19 09:08:48 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 19 Sep 2012 13:08:48 +0400 Subject: =?UTF-8?B?UmU6IDMwMSDRgNC10LTQuNGA0LXQutGCINC00LvRjyDQvdC10YHQutC+0LvRjNC6?= =?UTF-8?B?0LjRhSDRgdGC0YDQsNC90LjRhiDRgdCw0LnRgtCw?= In-Reply-To: <1b69b43b515ed678aec9a1d1ab18128f.NginxMailingListRussian@forum.nginx.org> References: <1b69b43b515ed678aec9a1d1ab18128f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120919090848.GC40452@mdounin.ru> Hello! On Wed, Sep 19, 2012 at 12:56:08AM -0400, anebilyca wrote: > Приветствую! > > Немного о пациенте. Стоит nginx/0.7.65. Just a side note: стоит обновится. > Необходимо настроить 301 редирект с нескольких страниц сайта на подобные им, > но более короткие. > > Самый первый вопрос, это как точно называется файл, в котором необходимо это > всё прописывать? Например, в апаче это .htacces. А здесь? А здесь - просто пишем в конфиге. Конфиг можно разбить на несколько файлов с помощью директивы include, но не обязательно (и обычно нежелательно, т.к. затрудняет чтение). Note well: в linux'ах исторически сложилось, что вместо одного конфига nginx.conf по умолчанию используется множество отдельных файлов, включённых в nginx.conf с помощью директивы include. Такой подход более удобен для автоматического конфигурирования, но очень плох для начинающих. Поэтому если сомневаетесь, где что писать - возможно имеет смысл на время отказаться от всех этих sites-available/sites-enabled, и писать конфигурацию полностью в nginx.conf. > Ну и как я увидел, есть несколько вариантов реализации. Хотелось бы узнать у > вас какой применим в моей ситуации и некоторые комментарии по вопросам, > которые у меня возникли. > > И так. > > 1. Способ. > > Код: > server { > listen 80; > server_name www.host.ru/1-page; > rewrite ^ www.host.ru/2-page$request_uri? permanent; #301 redirect > } Это бессмысленная конструкция, в директиве server_name указывается имя сервера, а не конкретной страницы. Подобные конструкции применяются для перенаправления всего сервера целиком (e.g. чтобы добавить/убрать "www."), но не годятся для перенаправления конкретных страниц. http://nginx.org/r/server_name/ru [...] > 2. Способ. > > Код: > server { > include redirect.conf; > > > redirect.conf: > > location = /1-page { return 301 http://host.ru/2-page; } > location = /3-page { return 301 http://host.ru/4-page; } > > } > Можно ли употреблять такую структуру, если я буду редиректить на разные > страницы, а не на главную, как я видел в одном примере? Да, можно. Правда, в 0.7.65 подобная конструкция работать не будет, "return 301 текст" работает начиная с 0.8.42. Нужно либо обновиться, либо использовать location = /1-page { rewrite ^ http://host.ru/2-page permanent; } Maxim Dounin From sb at waeme.net Wed Sep 19 11:17:41 2012 From: sb at waeme.net (Sergey Budnevitch) Date: Wed, 19 Sep 2012 15:17:41 +0400 Subject: Administrivia: envelope sender address and the mailing list Message-ID: <856A247B-CA5A-47B5-991B-EFD79FBA95EF@waeme.net> До недавнего времени письма в рассылку с неподписанных адресов переправлялись администратору, и отправитель оставался в неведении, почему его письмо попало в рассылку с запозданием или не попало вовсе. Так как количество писем, переправляемых администратору, растет со временем (в основном из-за спама), мы добавили дополнительную проверку адреса отправителя на уровне почтового сервера. К сожалению почтовый сервер проверят 'envelope sender' адрес, в то время как Mailman проверяет адрес из поля From:. Чаще всего они совпадают, но, например, Google устанавливает 'envelope sender' адрес в адрес соответствующей учетной записи Google'а, а адрес в поле From: может оставиться произвольным. В этом случае отправитель получит сообщегие о невозможности доставки письма, несмотря на то, что адрес в поле From: был правильным и подписанным на рассылку. В качестве решения проблемы можно подписать второй (envelope sender) адрес на рассылку и через web-интерфейс Mailman'а отключить доставку для данного адреса. From sergey.kobzar at itcraft.org Wed Sep 19 11:39:43 2012 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Wed, 19 Sep 2012 14:39:43 +0300 Subject: Administrivia: envelope sender address and the mailing list In-Reply-To: <856A247B-CA5A-47B5-991B-EFD79FBA95EF@waeme.net> References: <856A247B-CA5A-47B5-991B-EFD79FBA95EF@waeme.net> Message-ID: <5059AEFF.4010208@itcraft.org> On 09/19/12 14:17, Sergey Budnevitch wrote: > До недавнего времени письма в рассылку с неподписанных адресов переправлялись администратору, > и отправитель оставался в неведении, почему его письмо попало в рассылку с запозданием или не > попало вовсе. Так как количество писем, переправляемых администратору, растет со временем (в > основном из-за спама), мы добавили дополнительную проверку адреса отправителя на уровне > почтового сервера. > > К сожалению почтовый сервер проверят 'envelope sender' адрес, в то время как Mailman > проверяет адрес из поля From:. Чаще всего они совпадают, но, например, Google > устанавливает 'envelope sender' адрес в адрес соответствующей учетной записи Google'а, а > адрес в поле From: может оставиться произвольным. В этом случае отправитель получит > сообщегие о невозможности доставки письма, несмотря на то, что адрес в поле From: был > правильным и подписанным на рассылку. > > В качестве решения проблемы можно подписать второй (envelope sender) адрес на рассылку и через > web-интерфейс Mailman'а отключить доставку для данного адреса. Я бы не стал рубить при невозможности проверить отправителя. Более универсальным решение является сделать скоринговую систему и начислять балы каждому письму (не путать с баллами SpamAssasin) и далее в зависимости от начисленных бвллов принимать решение. Привер например тут: http://habrahabr.ru/post/133215/ Половину из написанного в статье следует опустить, но идея должна быть понятна. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From sytar.alex at gmail.com Wed Sep 19 12:01:18 2012 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Wed, 19 Sep 2012 16:01:18 +0400 Subject: =?UTF-8?B?Z2VvIHdoaXRlbGlzdCDQtNC70Y8gbGltaXRfY29ubg==?= Message-ID: Добрый день, Решил для создания белого списка адресов к которым применяется limit_conn использовать geo модуль, как-то так: geo $conn_perserver { default 32; # 32 127.0.0.0.1 -; # no limit } и далее: limit_conn perip $conn_perserver; Однако, на стадии тестирования конфига nginx рапортует: C:\nginx>nginx.exe -t nginx: [emerg] invalid number of connections "$conn_perip" in C:\nginx/conf/ngin x.conf:76 nginx: configuration file C:\nginx/conf/nginx.conf test failed C:\nginx>nginx.exe -V nginx version: nginx/1.2.1 TLS SNI support enabled configure arguments: --with-cc=cl --builddir=objs.msvc8 --with-debug --prefix= - -conf-path=conf/nginx.conf --pid-path=logs/nginx.pid --http-log-path=logs/access .log --error-log-path=logs/error.log --sbin-path=nginx.exe --http-client-body-te mp-path=temp/client_body_temp --http-proxy-temp-path=temp/proxy_temp --http-fast cgi-temp-path=temp/fastcgi_temp --http-scgi-temp-path=temp/scgi_temp --http-uwsg i-temp-path=temp/uwsgi_temp --with-cc-opt=-DFD_SETSIZE=1024 --with-pcre=objs.msv c8/lib/pcre-8.30 --with-zlib=objs.msvc8/lib/zlib-1.2.5 --with-select_module --wi th-http_realip_module --with-http_addition_module --with-http_sub_module --with- http_dav_module --with-http_stub_status_module --with-http_flv_module --with-htt p_mp4_module --with-http_gzip_static_module --with-http_random_index_module --wi th-http_secure_link_module --with-mail --with-openssl=objs.msvc8/lib/openssl-1.0 .1c --with-openssl-opt=enable-tlsext --with-http_ssl_module --with-mail_ssl_modu le --with-ipv6 From ne at vbart.ru Wed Sep 19 13:12:07 2012 From: ne at vbart.ru (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 19 Sep 2012 17:12:07 +0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?INCa0LDQuiDQv9C+0LHQvtGA0L7RgtGMPw==?= In-Reply-To: References: <201209191223.42707.ne@vbart.ru> Message-ID: <201209191712.07473.ne@vbart.ru> On Wednesday 19 September 2012 12:56:10 mikhal123 wrote: [...] > после этого в логах все еще интереснее: > > 2012/09/19 11:53:22 [debug] 27380#0: *421 accept: 79.164.125.238 fd:85 > 2012/09/19 11:53:22 [debug] 27380#0: *421 post event 00007FD536406738 > 2012/09/19 11:53:22 [debug] 27380#0: *421 delete posted event > 00007FD536406738 > 2012/09/19 11:53:22 [debug] 27380#0: *421 malloc: 0000000000830860:1296 > 2012/09/19 11:53:22 [debug] 27380#0: *421 posix_memalign: > 0000000000830D80:256 @16 > 2012/09/19 11:53:22 [debug] 27380#0: *421 malloc: 0000000000884870:16384 > 2012/09/19 11:53:22 [debug] 27380#0: *421 posix_memalign: > 0000000000830E90:4096 @16 > 2012/09/19 11:53:22 [debug] 27380#0: *421 http process request line > 2012/09/19 11:53:22 [debug] 27380#0: *421 recv: fd:85 -1 of 16384 > 2012/09/19 11:53:22 [debug] 27380#0: *421 recv() not ready (11: Resource [...] > то есть как я понимаю запрос шлется не целиком (может вообще 1 байт), затем > соединение уходит в состояние ожидания и потом все равно также отваливается > только по таймауту. в freebsd accf_http наверное помог бы (и то может они и > для него чего-то делают), а в linux получается что все, финита > Из лога видно, что ни одного полезного байта не прислано. А в логе при этом случайно нет записей вида: setsockopt(TCP_DEFER_ACCEPT, ...) for ... failed, ignored ? -- Валентин Бартенев From mdounin at mdounin.ru Wed Sep 19 13:28:54 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 19 Sep 2012 17:28:54 +0400 Subject: =?UTF-8?B?UmU6IGdlbyB3aGl0ZWxpc3Qg0LTQu9GPIGxpbWl0X2Nvbm4=?= In-Reply-To: References: Message-ID: <20120919132854.GF40452@mdounin.ru> Hello! On Wed, Sep 19, 2012 at 04:01:18PM +0400, Aleksandr Sytar wrote: > Добрый день, > > Решил для создания белого списка адресов к которым применяется > limit_conn использовать geo модуль, как-то так: > > geo $conn_perserver { > default 32; # 32 > 127.0.0.0.1 -; # no limit > } > > и далее: > > limit_conn perip $conn_perserver; > > Однако, на стадии тестирования конфига nginx рапортует: > > C:\nginx>nginx.exe -t > nginx: [emerg] invalid number of connections "$conn_perip" in C:\nginx/conf/ngin > x.conf:76 > nginx: configuration file C:\nginx/conf/nginx.conf test failed Так и должно быть, в limit_conn не поддерживаются переменные. Если хочется кого-то не лимитировать, можно для него использовать пустой ключ, как-то так: geo $whitelist { default 0; 127.0.0.1 1; } map $whitelist $limit { 0 $binary_remote_address; 1 ""; } limit_conn_zone $limit zone=perip:10m; limit_conn perip 32; Цитата из http://nginx.org/r/limit_conn_zone/ru: : Ключом является любое непустое значение заданной переменной : (пустые значения не учитываются). Maxim Dounin From nginx-forum at nginx.us Wed Sep 19 14:02:40 2012 From: nginx-forum at nginx.us (mikhal123) Date: Wed, 19 Sep 2012 10:02:40 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?0JrQsNC6INC/0L7QsdC+0YDQvtGC0Yw/?= In-Reply-To: <201209191712.07473.ne@vbart.ru> References: <201209191712.07473.ne@vbart.ru> Message-ID: <46dbec315e168ece10b96170280d2439.NginxMailingListRussian@forum.nginx.org> > > то есть как я понимаю запрос шлется не целиком (может вообще 1 > байт), затем > > соединение уходит в состояние ожидания и потом все равно также > отваливается > > только по таймауту. в freebsd accf_http наверное помог бы (и то > может они и > > для него чего-то делают), а в linux получается что все, финита > > > > Из лога видно, что ни одного полезного байта не прислано. А в логе при > этом > случайно нет записей вида: setsockopt(TCP_DEFER_ACCEPT, ...) for ... > failed, ignored ? > нет там ничего похожего (error.log ведется с момента перезапуска nginx с новыми параметрами) вы предполагаете, несмотря на опцию defer в listen эти пустые соединения все равно доходят до nginx? это можно проверить как-то проверить? может протухла в nginx эта опция :) uname -a Linux 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux nginx -v nginx version: nginx/1.2.3 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230818,230876#msg-230876 From ne at vbart.ru Wed Sep 19 14:59:37 2012 From: ne at vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 19 Sep 2012 18:59:37 +0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?INCa0LDQuiDQv9C+0LHQvtGA0L7RgtGMPw==?= In-Reply-To: <46dbec315e168ece10b96170280d2439.NginxMailingListRussian@forum.nginx.org> References: <201209191712.07473.ne@vbart.ru> <46dbec315e168ece10b96170280d2439.NginxMailingListRussian@forum.nginx.org> Message-ID: <201209191859.37979.ne@vbart.ru> On Wednesday 19 September 2012 18:02:40 mikhal123 wrote: [...] > нет там ничего похожего (error.log ведется с момента перезапуска nginx с > новыми параметрами) > вы предполагаете, несмотря на опцию defer в listen эти пустые соединения > все равно доходят до nginx? это можно проверить как-то проверить? может > протухла в nginx эта опция :) Они в любом случае будут доходить, так он работает. Я понял в чем причина. Вы выставили client_header_timeout в 3 секунды, а deferred accept берет свой таймаут из этой же директивы. В итоге, у вас 3 секунды соединение проводит в ядре, а потом кончается таймаут deferred accept-а и соединение передается nginx-у, и nginx ждет ещё три секунды до таймаута. Выставлять client_header_timeout в столь малое значение вообще была очень плохая идея в любом случае. Так жестко играясь с таймаутами (которые и так по дефолту имеют более-менее оптимальные значения) вы более навредите своим посетителям, чем получите какую-то выгоду. 100 соединений nginx способен держать даже на кофеварке, это не та цифра по которой надо переживать. Рекомендую спилить client_header_timeout из конфига, 60 секунд по дефолту скорее всего будет достаточно чтобы Хром сам отвалился проведя всё время в ядре, и всё, что осталось бы nginx - это отработать закрытие соединения. -- Валентин Бартенев From nginx-forum at nginx.us Wed Sep 19 17:45:49 2012 From: nginx-forum at nginx.us (mikhal123) Date: Wed, 19 Sep 2012 13:45:49 -0400 Subject: =?UTF-8?B?UmU6IG5naW54IHN0YXR1czogcmVhZGluZyAxMDAtMjAwLCB3cml0aW5nIDEtNS4g?= =?UTF-8?B?0JrQsNC6INC/0L7QsdC+0YDQvtGC0Yw/?= In-Reply-To: <201209191859.37979.ne@vbart.ru> References: <201209191859.37979.ne@vbart.ru> Message-ID: > Они в любом случае будут доходить, так он работает. > > Я понял в чем причина. Вы выставили client_header_timeout в 3 секунды, > а > deferred accept берет свой таймаут из этой же директивы. > > В итоге, у вас 3 секунды соединение проводит в ядре, а потом кончается > таймаут > deferred accept-а и соединение передается nginx-у, и nginx ждет ещё > три секунды > до таймаута. > > Выставлять client_header_timeout в столь малое значение вообще была > очень плохая > идея в любом случае. Так жестко играясь с таймаутами (которые и так по > дефолту > имеют более-менее оптимальные значения) вы более навредите своим > посетителям, > чем получите какую-то выгоду. 100 соединений nginx способен держать > даже на > кофеварке, это не та цифра по которой надо переживать. > > Рекомендую спилить client_header_timeout из конфига, 60 секунд по > дефолту скорее > всего будет достаточно чтобы Хром сам отвалился проведя всё время в > ядре, и всё, > что осталось бы nginx - это отработать закрытие соединения. Ну без знания о таких деталях работы nginx сложно догадаться, что уменьшение client_header_timeout приведет к таким проблемам с хромом. Да и, как вспоминается, в инете присутствуют руководства где рекомендуется этот таймаут ставить небольшим. Типа защита от ддоса :) Но теперь все понятно, настройки client_header_timeout 15; listen 80 default_server backlog=1024 sndbuf=512k deferred; практически полностью устраняют проблему Active connections: 2825 server accepts handled requests 507907 507907 1094551 Reading: 11 Writing: 3 Waiting: 2811 Благодарю за помощь Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230818,230883#msg-230883 From igor at sysoev.ru Wed Sep 19 19:20:59 2012 From: igor at sysoev.ru (Igor Sysoev) Date: Wed, 19 Sep 2012 23:20:59 +0400 Subject: Administrivia: envelope sender address and the mailing list In-Reply-To: <5059AEFF.4010208@itcraft.org> References: <856A247B-CA5A-47B5-991B-EFD79FBA95EF@waeme.net> <5059AEFF.4010208@itcraft.org> Message-ID: <20120919192059.GA27511@nginx.com> On Wed, Sep 19, 2012 at 02:39:43PM +0300, Sergey Kobzar wrote: > On 09/19/12 14:17, Sergey Budnevitch wrote: > > До недавнего времени письма в рассылку с неподписанных адресов переправлялись администратору, > > и отправитель оставался в неведении, почему его письмо попало в рассылку с запозданием или не > > попало вовсе. Так как количество писем, переправляемых администратору, растет со временем (в > > основном из-за спама), мы добавили дополнительную проверку адреса отправителя на уровне > > почтового сервера. > > > > К сожалению почтовый сервер проверят 'envelope sender' адрес, в то время как Mailman > > проверяет адрес из поля From:. Чаще всего они совпадают, но, например, Google > > устанавливает 'envelope sender' адрес в адрес соответствующей учетной записи Google'а, а > > адрес в поле From: может оставиться произвольным. В этом случае отправитель получит > > сообщегие о невозможности доставки письма, несмотря на то, что адрес в поле From: был > > правильным и подписанным на рассылку. > > > > В качестве решения проблемы можно подписать второй (envelope sender) адрес на рассылку и через > > web-интерфейс Mailman'а отключить доставку для данного адреса. > > Я бы не стал рубить при невозможности проверить отправителя. Более > универсальным решение является сделать скоринговую систему и начислять > балы каждому письму (не путать с баллами SpamAssasin) и далее в > зависимости от начисленных бвллов принимать решение. > > Привер например тут: http://habrahabr.ru/post/133215/ > > Половину из написанного в статье следует опустить, но идея должна быть > понятна. Практика показывает, что самый надёжный способ избежать спама в списке - принимать почту только от подписавшихся. В список иногда попадает спам, но в основном через форум. Пару раз было от подписчиков, у которых, похоже, сломали ящик на Яху или типа того. Что касается скоринга, то за ним нужно постоянно следить, и работает он, исходя из опыта использования его для моего личного адреса, хуже - спам часто пролезает, и что самое неприятное - полезные письма иногда не проходят скоринг. -- Igor Sysoev From sergey.kobzar at itcraft.org Wed Sep 19 19:59:50 2012 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Wed, 19 Sep 2012 22:59:50 +0300 Subject: Administrivia: envelope sender address and the mailing list In-Reply-To: <20120919192059.GA27511@nginx.com> References: <856A247B-CA5A-47B5-991B-EFD79FBA95EF@waeme.net> <5059AEFF.4010208@itcraft.org> <20120919192059.GA27511@nginx.com> Message-ID: <505A2436.7040306@itcraft.org> On 09/19/12 22:20, Igor Sysoev wrote: >> Я бы не стал рубить при невозможности проверить отправителя. Более >> универсальным решение является сделать скоринговую систему и начислять >> балы каждому письму (не путать с баллами SpamAssasin) и далее в >> зависимости от начисленных бвллов принимать решение. >> >> Привер например тут: http://habrahabr.ru/post/133215/ >> >> Половину из написанного в статье следует опустить, но идея должна быть >> понятна. > > Практика показывает, что самый надёжный способ избежать спама в списке - > принимать почту только от подписавшихся. В список иногда попадает спам, > но в основном через форум. Пару раз было от подписчиков, у которых, похоже, > сломали ящик на Яху или типа того. Да, тут я согласен на 100%. > Что касается скоринга, то за ним нужно постоянно следить, и работает он, > исходя из опыта использования его для моего личного адреса, хуже - спам > часто пролезает, и что самое неприятное - полезные письма иногда не > проходят скоринг. Основное достоинство скоринговой системы - одно письмо не рубится по единичному признаку (хотя и такое конечно возможно). Все зависит от конкретной реализации. У меня "require verify = sender" давно не используется самостоятельно. Слишком много фолс позитивов. From sytar.alex at gmail.com Thu Sep 20 07:34:43 2012 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Thu, 20 Sep 2012 11:34:43 +0400 Subject: =?UTF-8?B?UmU6IGdlbyB3aGl0ZWxpc3Qg0LTQu9GPIGxpbWl0X2Nvbm4=?= In-Reply-To: <20120919132854.GF40452@mdounin.ru> References: <20120919132854.GF40452@mdounin.ru> Message-ID: 19 сентября 2012 г., 17:28 пользователь Maxim Dounin написал: > Hello! > > Если хочется кого-то не лимитировать, можно для него использовать > пустой ключ, как-то так: > > geo $whitelist { > default 0; > 127.0.0.1 1; > } > > map $whitelist $limit { > 0 $binary_remote_address; > 1 ""; > } > > limit_conn_zone $limit zone=perip:10m; > limit_conn perip 32; > Спасибо Максим, так получается From mdounin at mdounin.ru Thu Sep 20 08:12:54 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 20 Sep 2012 12:12:54 +0400 Subject: Administrivia: envelope sender address and the mailing list In-Reply-To: <505A2436.7040306@itcraft.org> References: <856A247B-CA5A-47B5-991B-EFD79FBA95EF@waeme.net> <5059AEFF.4010208@itcraft.org> <20120919192059.GA27511@nginx.com> <505A2436.7040306@itcraft.org> Message-ID: <20120920081254.GO40452@mdounin.ru> Hello! On Wed, Sep 19, 2012 at 10:59:50PM +0300, Sergey Kobzar wrote: [...] > У меня "require verify = sender" давно не используется > самостоятельно. Слишком много фолс позитивов. Речь не идёт о проверке sender'а в классическом смысле (сходить и попытаться отправить письмо, если не смогли - отвергнуть входящее письмо), речь именно о проверке по базе подписчиков списка рассылки. Раньше она делалась по адресу из заголовка From, теперь - по envelope-from адресу на уровне SMTP. Maxim Dounin From sergey.kobzar at itcraft.org Thu Sep 20 08:32:25 2012 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Thu, 20 Sep 2012 11:32:25 +0300 Subject: Administrivia: envelope sender address and the mailing list In-Reply-To: <20120920081254.GO40452@mdounin.ru> References: <856A247B-CA5A-47B5-991B-EFD79FBA95EF@waeme.net> <5059AEFF.4010208@itcraft.org> <20120919192059.GA27511@nginx.com> <505A2436.7040306@itcraft.org> <20120920081254.GO40452@mdounin.ru> Message-ID: <505AD499.40407@itcraft.org> Максим On 09/20/12 11:12, Maxim Dounin wrote: > Hello! > > On Wed, Sep 19, 2012 at 10:59:50PM +0300, Sergey Kobzar wrote: > > [...] > >> У меня "require verify = sender" давно не используется >> самостоятельно. Слишком много фолс позитивов. > > Речь не идёт о проверке sender'а в классическом смысле (сходить и > попытаться отправить письмо, если не смогли - отвергнуть входящее > письмо), речь именно о проверке по базе подписчиков списка > рассылки. Раньше она делалась по адресу из заголовка From, теперь - > по envelope-from адресу на уровне SMTP. Понял - вполне логично. Тогда вообще не вижу проблем. У технически образованных людей подписаться на рассылку не должно вызвать никаких проблем. Те, кто не могу выполнить даже этого, лезть в рассылку незачем IMO. Я подписан на несколько рассылок и, насколько мне известно, только эта отличется такими либеральными правилами. > > Maxim Dounin > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Thu Sep 20 13:42:16 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 20 Sep 2012 17:42:16 +0400 Subject: Administrivia: envelope sender address and the mailing list In-Reply-To: <505AD499.40407@itcraft.org> References: <856A247B-CA5A-47B5-991B-EFD79FBA95EF@waeme.net> <5059AEFF.4010208@itcraft.org> <20120919192059.GA27511@nginx.com> <505A2436.7040306@itcraft.org> <20120920081254.GO40452@mdounin.ru> <505AD499.40407@itcraft.org> Message-ID: <20120920134216.GU40452@mdounin.ru> Hello! On Thu, Sep 20, 2012 at 11:32:25AM +0300, Sergey Kobzar wrote: > Максим > > On 09/20/12 11:12, Maxim Dounin wrote: > >Hello! > > > >On Wed, Sep 19, 2012 at 10:59:50PM +0300, Sergey Kobzar wrote: > > > >[...] > > > >>У меня "require verify = sender" давно не используется > >>самостоятельно. Слишком много фолс позитивов. > > > >Речь не идёт о проверке sender'а в классическом смысле (сходить и > >попытаться отправить письмо, если не смогли - отвергнуть входящее > >письмо), речь именно о проверке по базе подписчиков списка > >рассылки. Раньше она делалась по адресу из заголовка From, теперь - > >по envelope-from адресу на уровне SMTP. > > Понял - вполне логично. > > Тогда вообще не вижу проблем. У технически образованных людей > подписаться на рассылку не должно вызвать никаких проблем. Те, кто > не могу выполнить даже этого, лезть в рассылку незачем IMO. > > Я подписан на несколько рассылок и, насколько мне известно, только > эта отличется такими либеральными правилами. Как показала проверка боем, у небольшого количества людей (использующих gmail для отправки почты, но при этом ставящих в поле from другой адрес) изменение вызвало проблемы (читай: раньше у них всё работало, после изменения - перестало). Именно поэтому Сергей и отправил соответствующее уведомление в список. Maxim Dounin From hell-for-yahoo at umail.ru Thu Sep 20 15:54:50 2012 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Thu, 20 Sep 2012 19:54:50 +0400 Subject: Administrivia: envelope sender address and the mailing list In-Reply-To: <20120920134216.GU40452@mdounin.ru> References: <856A247B-CA5A-47B5-991B-EFD79FBA95EF@waeme.net> <5059AEFF.4010208@itcraft.org> <20120919192059.GA27511@nginx.com> <505A2436.7040306@itcraft.org> <20120920081254.GO40452@mdounin.ru> <505AD499.40407@itcraft.org> <20120920134216.GU40452@mdounin.ru> Message-ID: <1776126041.20120920195450@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Maxim Dounin! MD> Как показала проверка боем, у небольшого количества людей MD> (использующих gmail для отправки почты, но при этом ставящих в MD> поле from другой адрес) изменение вызвало проблемы (читай: раньше MD> у них всё работало, после изменения - перестало). Именно поэтому MD> Сергей и отправил соответствующее уведомление в список. Не только gmail... У меня довольно хитрая система для фильтрации спама с рассылок свёрнута в колечко. Причём "с рассылок" не ограничивается спасмом, приходящим В рассылки. но и спам, собирающий адреса по рассылкам и рассылающий дерьмо директом, режется, причём даже лучше, чем приходящий в рассылки. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) четверг, 20.09.2012, <19:52> From ne at vbart.ru Thu Sep 20 22:40:39 2012 From: ne at vbart.ru (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 21 Sep 2012 02:40:39 +0400 Subject: =?UTF-8?B?UmU6IGltYWdlX2ZpbHRlcl9qcGVnX3F1YWxpdHkgINC90LUg0YDQsNCx0L7RgtCw?= =?UTF-8?B?0LXRgiDQsdC10Lcg0YPQutCw0LfQsNC90LjRjyBpbWFnZV9maWx0ZXIgcm90?= =?UTF-8?B?YXRlfHJlc2l6ZXxjcm9w?= In-Reply-To: References: Message-ID: <201209210240.39895.ne@vbart.ru> On Wednesday 19 September 2012 12:39:31 mxs kolo wrote: [...] > В аттаче есть патч которым я решил эту проблему для себя. > Мне пришось добавить новый тип фильтра - quality_only. > Мой конфиг теперь выглядит так: > location ~* \.(jpg|jpeg)$ { > image_filter quality_only; > image_filter_buffer 10M; > image_filter_jpeg_quality 75; > image_filter_sharpen 25; > root /var/www/vhosts/some-domain-here.ru/httpdocs/; > } quality_only не очень подходящее название для опции image_filter. 1. crop | resize | test - глаголы, означающие действие, производимое над изображением, а quality_only - нет. 2. Судя по тому, что делает патч, текущее название просто не соответствует действительности: к изображению применяется резкость и убирается прозрачность, если заданы соответствующие директивы. Директива же image_filter_jpeg_quality работает только для изображений в формате jpeg, при этом патч не накладывает никаких ограничений на обработку png и gif. Я предлагаю поменять название на более общее, например, "convert" будет неплохо. > Я был -бы очень признателен, если-бы кто-то посмотрел патч на предмет > ошибок. На будущее, просьба делать diff с опцией -p, так он будет лучше читаться. > --- nginx-1.3.6/src/http/modules/ngx_http_image_filter_module.c 2012-04-21 > 23:02:21.000000000 +0400 +++ > nginx-1.3.6.PATCHED/src/http/modules/ngx_http_image_filter_module.c > 2012-09-19 12:32:16.000000000 +0400 @@ -18,6 +18,7 @@ > > #define NGX_HTTP_IMAGE_RESIZE 3 > #define NGX_HTTP_IMAGE_CROP 4 > #define NGX_HTTP_IMAGE_ROTATE 5 > > +#define NGX_HTTP_IMAGE_QUALITY 6 > > #define NGX_HTTP_IMAGE_START 0 > > @@ -507,6 +508,10 @@ > > return ngx_http_image_json(r, rc == NGX_OK ? ctx : NULL); > > } > > + if (conf->filter == NGX_HTTP_IMAGE_QUALITY) { > + return ngx_http_image_resize(r, ctx); > + } > + Style. Множество лишних пробелов в конце строк. > ctx->angle = ngx_http_image_filter_get_value(r, conf->acv, conf->angle); > > if (conf->filter == NGX_HTTP_IMAGE_ROTATE) { > > @@ -813,6 +818,10 @@ > > resize = 0; > > + } else if (conf->filter == NGX_HTTP_IMAGE_QUALITY) { > + > + resize = 0; > + > } else { /* NGX_HTTP_IMAGE_CROP */ > > resize = 0; Та же проблема с пробелами в пустых строках и на конце. Лучше вынести resize = 0; выше, за пределы всей конструкции из if - else. Должно получиться как-то так: resize = 0; if (conf->filter == NGX_HTTP_IMAGE_RESIZE) { ... } else if (conf->filter == NGX_HTTP_IMAGE_CROP) { ... } -- Валентин Бартенев From nginx-forum at nginx.us Fri Sep 21 07:30:53 2012 From: nginx-forum at nginx.us (drook) Date: Fri, 21 Sep 2012 03:30:53 -0400 Subject: =?UTF-8?Q?nginx_=D0=B8_X-Accel-Redirect?= Message-ID: <4be4cf0a76f3b06b8bb49b1b9d625c20.NginxMailingListRussian@forum.nginx.org> Привет. Использую nginx 1.2.1 + php-fpm как fcgi. Подскажите, как мне быть: для интеграции своего сервиса в чужую cdn, когда эта cdn ходит в мой nginx, мне надо показывать ей X-Accel-Redirect в выдаче. Сейчас схема следующая: CDN ---> балансировщик(nginx) ---> бэкенд (nginx+php-fpm). На балансировщике стоит proxy_ignore_headers X-Accel-Redirect, на бэкендe proxy_ignore_headers X-Accel-Redirect и fastcgi_ignore_headers X-Accel-Redirect. Убирание какого-либо заголовка ведет к тому, что тот nginx, у которого убрали этот заголовок, начинает искать файл из заголовка. Мне нужно как-то заголовок, который вставляет в выдачу php, донести до CDN. Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230912,230912#msg-230912 From kaa at zvuki.ru Fri Sep 21 09:40:56 2012 From: kaa at zvuki.ru (Andrey Kopeyko) Date: Fri, 21 Sep 2012 13:40:56 +0400 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_X-Accel-Redirect?= In-Reply-To: <4be4cf0a76f3b06b8bb49b1b9d625c20.NginxMailingListRussian@forum.nginx.org> References: <4be4cf0a76f3b06b8bb49b1b9d625c20.NginxMailingListRussian@forum.nginx.org> Message-ID: <505C3628.6010200@zvuki.ru> 21.09.2012 11:30, drook пишет: > Привет. Добрый день! > Использую nginx 1.2.1 + php-fpm как fcgi. Подскажите, как мне быть: для > интеграции своего сервиса в чужую cdn, когда эта cdn ходит в мой nginx, мне > надо показывать ей X-Accel-Redirect в выдаче. > > Сейчас схема следующая: > > CDN ---> балансировщик(nginx) ---> бэкенд (nginx+php-fpm). > > На балансировщике стоит proxy_ignore_headers X-Accel-Redirect, на бэкендe > proxy_ignore_headers X-Accel-Redirect и fastcgi_ignore_headers > X-Accel-Redirect. Убирание какого-либо заголовка ведет к тому, что тот > nginx, у которого убрали этот заголовок, начинает искать файл из заголовка. > Мне нужно как-то заголовок, который вставляет в выдачу php, донести до CDN. Вам нужно построить отдельный виртуальный сервер, специально для CDN. И настроить его по вкусу. -- Best regards, Andrey Kopeyko From nginx-forum at nginx.us Fri Sep 21 10:37:58 2012 From: nginx-forum at nginx.us (drook) Date: Fri, 21 Sep 2012 06:37:58 -0400 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_X-Accel-Redirect?= In-Reply-To: <505C3628.6010200@zvuki.ru> References: <505C3628.6010200@zvuki.ru> Message-ID: <4e0242219b781fcdb87d83f2e7131a6f.NginxMailingListRussian@forum.nginx.org> Andrey Kopeyko Wrote: ------------------------------------------------------- > Вам нужно построить отдельный виртуальный сервер, специально для CDN. > И > настроить его по вкусу. Что такого мне даст виртуальный сервер чего мне не может дать виртуальный хост в nginx, как сейчас это и сделано ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230912,230915#msg-230915 From kaa at zvuki.ru Fri Sep 21 11:22:51 2012 From: kaa at zvuki.ru (Andrey Kopeyko) Date: Fri, 21 Sep 2012 15:22:51 +0400 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_X-Accel-Redirect?= In-Reply-To: <4e0242219b781fcdb87d83f2e7131a6f.NginxMailingListRussian@forum.nginx.org> References: <505C3628.6010200@zvuki.ru> <4e0242219b781fcdb87d83f2e7131a6f.NginxMailingListRussian@forum.nginx.org> Message-ID: <505C4E0B.4000409@zvuki.ru> 21.09.2012 14:37, drook пишет: > Andrey Kopeyko Wrote: > ------------------------------------------------------- > >> Вам нужно построить отдельный виртуальный сервер, специально для CDN. >> И >> настроить его по вкусу. > > Что такого мне даст виртуальный сервер чего мне не может дать виртуальный > хост в nginx, как сейчас это и сделано ? Мы говорим об одном и том же - это синонимы. Наверное, я неудачно\неполно выразился - я предложил для CDN сделать отдельный виртуальный хост, со своими специфическими настройками. Пользователи туда не ходят. Если будет недостаточно (вы писали о подавлении x-accel-redirect и на nginx-бэкенде) - отдельный виртуальный специфично-настроенный хост сконфигурить и на нём. -- Best regards, Andrey Kopeyko From postmaster at softsearch.ru Fri Sep 21 14:12:23 2012 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 21 Sep 2012 18:12:23 +0400 Subject: =?UTF-8?B?0J3QsNC00L/QuNGB0Lgg0L3QsCDQutCw0YDRgtC40L3QutCw0YU=?= Message-ID: <1656647945.20120921181223@softsearch.ru> Здравствуйте. Есть потребность накладывать на отдаваемые картинки подписи в виде текст или изображений при отдаче их на другие сайты. Т.е. если смотрим картинку на своём сайте, то показывается оригинальная картинка. А если в реферере сторонний сайт, то налету добавляем подпись, если картинка больше, чем x на y пикселей. Сие можно и на бэкенде делать, но раз уж есть image_filter, то логично подобное делать в нём. -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Sat Sep 22 13:25:43 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 22 Sep 2012 17:25:43 +0400 Subject: =?UTF-8?B?UmU6INCd0LDQtNC/0LjRgdC4INC90LAg0LrQsNGA0YLQuNC90LrQsNGF?= In-Reply-To: <1656647945.20120921181223@softsearch.ru> References: <1656647945.20120921181223@softsearch.ru> Message-ID: <20120922132542.GW40452@mdounin.ru> Hello! On Fri, Sep 21, 2012 at 06:12:23PM +0400, Михаил Монашёв wrote: > Здравствуйте. > > Есть потребность накладывать на отдаваемые картинки подписи в виде > текст или изображений при отдаче их на другие сайты. Т.е. если смотрим > картинку на своём сайте, то показывается оригинальная картинка. А если > в реферере сторонний сайт, то налету добавляем подпись, если картинка > больше, чем x на y пикселей. Сие можно и на бэкенде делать, но раз уж > есть image_filter, то логично подобное делать в нём. http://nginx.com/support.html? Maxim Dounin From nginx-forum at nginx.us Sat Sep 22 17:04:30 2012 From: nginx-forum at nginx.us (drook) Date: Sat, 22 Sep 2012 13:04:30 -0400 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_X-Accel-Redirect?= In-Reply-To: <505C4E0B.4000409@zvuki.ru> References: <505C4E0B.4000409@zvuki.ru> Message-ID: <87ae734cd2c5854a10de06afd927eee4.NginxMailingListRussian@forum.nginx.org> Andrey Kopeyko Wrote: ------------------------------------------------------- > Мы говорим об одном и том же - это синонимы. > > Наверное, я неудачно\неполно выразился - я предложил для CDN сделать > отдельный виртуальный хост, со своими специфическими настройками. > Пользователи туда не ходят. Если будет недостаточно (вы писали о > подавлении x-accel-redirect и на nginx-бэкенде) - отдельный > виртуальный > специфично-настроенный хост сконфигурить и на нём. Хорошо, но ведь я и описал как этот вхост работает сейчас, в связке с CDN и балансировщиком. На балансировщике тоже вхост. Все вместе работает не так как мне нужно - либо срезает заголовок, либо ищет файл, и, не найдя его, отдает 404. Оба варианта меня не устраивают: я хочу и чтобы заголовок отдался CDN, и чтобы локальный файл не искался. Что именно у меня неправильно настроено ? Я был бы очень благодарен за объяснение. Евгений. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230912,230941#msg-230941 From postmaster at softsearch.ru Sat Sep 22 17:38:49 2012 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 22 Sep 2012 21:38:49 +0400 Subject: =?UTF-8?B?UmVbMl06INCd0LDQtNC/0LjRgdC4INC90LAg0LrQsNGA0YLQuNC90LrQsNGF?= In-Reply-To: <20120922132542.GW40452@mdounin.ru> References: <1656647945.20120921181223@softsearch.ru> <20120922132542.GW40452@mdounin.ru> Message-ID: <1710636404.20120922213849@softsearch.ru> Здравствуйте, Maxim. >> Есть потребность накладывать на отдаваемые картинки подписи в виде >> текст или изображений при отдаче их на другие сайты. Т.е. если >> смотрим картинку на своём сайте, то показывается оригинальная >> картинка. А если в реферере сторонний сайт, то налету добавляем >> подпись, если картинка больше, чем x на y пикселей. Сие можно и на >> бэкенде делать, но раз уж есть image_filter, то логично подобное >> делать в нём. > http://nginx.com/support.html? Максим, я понимаю, что у вас там туду уже ни в какие ворота не влазит. Думал, мало ли, может ещё кому-то надо и потому тред будет на 2 экрана. А только ты ответил. Значит и не нужна эта фича никому. А ссылочку эту воткните в дефолтную страничку 404 и 502 ошибки. Кому надо, то отключит. А кому лень, тот поможет проекту. -- С уважением, Михаил mailto:postmaster at softsearch.ru From kaa at zvuki.ru Sat Sep 22 18:30:25 2012 From: kaa at zvuki.ru (Andrey Kopeyko) Date: Sat, 22 Sep 2012 22:30:25 +0400 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_X-Accel-Redirect?= In-Reply-To: <87ae734cd2c5854a10de06afd927eee4.NginxMailingListRussian@forum.nginx.org> References: <505C4E0B.4000409@zvuki.ru> <87ae734cd2c5854a10de06afd927eee4.NginxMailingListRussian@forum.nginx.org> Message-ID: <505E03C1.1080709@zvuki.ru> 22.09.2012 21:04, drook пишет: > Andrey Kopeyko Wrote: > ------------------------------------------------------- > >> Мы говорим об одном и том же - это синонимы. >> >> Наверное, я неудачно\неполно выразился - я предложил для CDN сделать >> отдельный виртуальный хост, со своими специфическими настройками. >> Пользователи туда не ходят. Если будет недостаточно (вы писали о >> подавлении x-accel-redirect и на nginx-бэкенде) - отдельный >> виртуальный >> специфично-настроенный хост сконфигурить и на нём. > > Хорошо, но ведь я и описал как этот вхост работает сейчас, в связке с CDN и > балансировщиком. На балансировщике тоже вхост. Все вместе работает не так > как мне нужно - либо срезает заголовок, либо ищет файл, и, не найдя его, > отдает 404. Оба варианта меня не устраивают: я хочу и чтобы заголовок > отдался CDN, и чтобы локальный файл не искался. > > Что именно у меня неправильно настроено ? Не знаю - конфиг вы не показывали. Покажите конфиги обоих nginx'ов. -- Best regards, Andrey Kopeyko From ingvar at westsib.ru Sat Sep 22 20:03:52 2012 From: ingvar at westsib.ru (Igor V. Fatkulin) Date: Sun, 23 Sep 2012 03:03:52 +0700 Subject: =?UTF-8?B?UmU6INCd0LDQtNC/0LjRgdC4INC90LAg0LrQsNGA0YLQuNC90LrQsNGF?= In-Reply-To: <1710636404.20120922213849@softsearch.ru> References: <1656647945.20120921181223@softsearch.ru> <20120922132542.GW40452@mdounin.ru> <1710636404.20120922213849@softsearch.ru> Message-ID: <505E19A8.9090105@westsib.ru> 23.09.2012 0:38, Михаил Монашёв пишет: > Здравствуйте, Maxim. > >>> Есть потребность накладывать на отдаваемые картинки подписи в виде >>> текст или изображений при отдаче их на другие сайты. Т.е. если >>> смотрим картинку на своём сайте, то показывается оригинальная >>> картинка. А если в реферере сторонний сайт, то налету добавляем >>> подпись, если картинка больше, чем x на y пикселей. Сие можно и на >>> бэкенде делать, но раз уж есть image_filter, то логично подобное >>> делать в нём. >> http://nginx.com/support.html? > Максим, я понимаю, что у вас там туду уже ни в какие ворота не влазит. > Думал, мало ли, может ещё кому-то надо и потому тред будет на 2 > экрана. А только ты ответил. Значит и не нужна эта фича никому. > > А ссылочку эту воткните в дефолтную страничку 404 и 502 ошибки. Кому > надо, то отключит. А кому лень, тот поможет проекту. > Собственно не особо вижу необходимость треда на 2 экрана, ибо предложение простое, нужное и, на мой взгляд, обсуждать тут особо нечего. А писать "+1" как-то отучили) Но коль уж пошел об этом разговор, то я бы тоже был крайне рад предложенному нововведению. From nginx-forum at nginx.us Sun Sep 23 02:21:15 2012 From: nginx-forum at nginx.us (Yahook) Date: Sat, 22 Sep 2012 22:21:15 -0400 Subject: =?UTF-8?B?ZnRwOi8vINC4IG5naW54IC0g0LzQvtC20L3QviDQu9C4INC90LDRgdGC0YDQvtC4?= =?UTF-8?B?0YLRjCDQvtGC0LTQsNGH0YMg0LrQvtC90YLQtdC90YLQsD8=?= Message-ID: <6f721b04612f625139009243f6b82984.NginxMailingListRussian@forum.nginx.org> Здравствуйте, Подскажите пожалуйста, можно ли настроить nginx таким образом, чтобы к файлам можно было обратиться по адресу ftp://www.domain.com/file.php (выдать уже результат исполнения, а не текст скрипта) или хотя бы просто вывести в браузер ftp://www.domain.com/file.html? Т.е. я хочу настроить сервер таким образом, чтобы он слушал соответствующие порты и отдавал файлы обычным образом. Т.е. чтобы пользователь, набравший ftp://www.domain.com/file.php вместо http://www.domain.com/file.php получил тот же контент. Может быть есть какие-то модули для nginx, которые позволяют такое сделать? Что-то вроде прокси, я даже не знаю как правильно это выразить. Заранее спасибо за ответы Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230955,230955#msg-230955 From me at kemko.ru Sun Sep 23 07:16:05 2012 From: me at kemko.ru (=?KOI8-R?B?5M3J1NLJyiDhzsTSxcXX?=) Date: Sun, 23 Sep 2012 11:16:05 +0400 Subject: =?UTF-8?B?UmU6IGZ0cDovLyDQuCBuZ2lueCAtINC80L7QttC90L4g0LvQuCDQvdCw0YHRgtGA?= =?UTF-8?B?0L7QuNGC0Ywg0L7RgtC00LDRh9GDINC60L7QvdGC0LXQvdGC0LA/?= In-Reply-To: <6f721b04612f625139009243f6b82984.NginxMailingListRussian@forum.nginx.org> References: <6f721b04612f625139009243f6b82984.NginxMailingListRussian@forum.nginx.org> Message-ID: 23 сентября 2012 г., 6:21 пользователь Yahook написал: > Здравствуйте, > > Подскажите пожалуйста, можно ли настроить nginx таким образом, чтобы к > файлам можно было обратиться по адресу ftp://www.domain.com/file.php (выдать > уже результат исполнения, а не текст скрипта) или хотя бы просто вывести в > браузер ftp://www.domain.com/file.html? > > Т.е. я хочу настроить сервер таким образом, чтобы он слушал соответствующие > порты и отдавал файлы обычным образом. Т.е. чтобы пользователь, набравший > ftp://www.domain.com/file.php вместо http://www.domain.com/file.php получил > тот же контент. > > Может быть есть какие-то модули для nginx, которые позволяют такое сделать? > Что-то вроде прокси, я даже не знаю как правильно это выразить. По http, https, ftp, gopher и другим смешные буковкам в начале браузер решает, по какому протоколу и через какой по умолчанию порт работать с указанным далее сервером. Если URL будет начинаться с ftp://, браузер будет общаться с узлом по протоколу FTP и вряд ли вы сможете его как-то переубедить. From nginx-forum at nginx.us Sun Sep 23 11:52:41 2012 From: nginx-forum at nginx.us (Yahook) Date: Sun, 23 Sep 2012 07:52:41 -0400 Subject: =?UTF-8?B?UmU6IGZ0cDovLyDQuCBuZ2lueCAtINC80L7QttC90L4g0LvQuCDQvdCw0YHRgtGA?= =?UTF-8?B?0L7QuNGC0Ywg0L7RgtC00LDRh9GDINC60L7QvdGC0LXQvdGC0LA/?= In-Reply-To: <6f721b04612f625139009243f6b82984.NginxMailingListRussian@forum.nginx.org> References: <6f721b04612f625139009243f6b82984.NginxMailingListRussian@forum.nginx.org> Message-ID: <7bd32bc27c55a9733ee81033037dd337.NginxMailingListRussian@forum.nginx.org> Мне бы подошло решение, когда на входе будет стоять фтп сервер как frontend, а файлы будут браться с nginx (результат исполнения файлов, если это php). Я понимаю, что по фтп не поддерживается передача параметров и mime type. Т.е. чтобы соответствующий файл запрошенный через фтп запрашивался у nginx и срабатывали мод реврайты и т.д. и затем фтп сервер отдавал его клиенту в исполненном виде. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230955,230957#msg-230957 From boris.t.ru at mail.ru Sun Sep 23 16:16:24 2012 From: boris.t.ru at mail.ru (Talovikov Boris Aleksandrovich) Date: Sun, 23 Sep 2012 22:16:24 +0600 Subject: =?UTF-8?B?UmU6IGZ0cDovLyDQuCBuZ2lueCAtINC80L7QttC90L4g0LvQuCDQvdCw0YHRgtGA?= =?UTF-8?B?0L7QuNGC0Ywg0L7RgtC00LDRh9GDINC60L7QvdGC0LXQvdGC0LA/?= In-Reply-To: <6f721b04612f625139009243f6b82984.NginxMailingListRussian@forum.nginx.org> References: <6f721b04612f625139009243f6b82984.NginxMailingListRussian@forum.nginx.org> Message-ID: <505F35D8.6030603@mail.ru> 23.09.2012 08:21, Yahook пишет: > Здравствуйте, > > Подскажите пожалуйста, можно ли настроить nginx таким образом, чтобы к > файлам можно было обратиться по адресу ftp://www.domain.com/file.php (выдать > уже результат исполнения, а не текст скрипта) или хотя бы просто вывести в > браузер ftp://www.domain.com/file.html? > > Т.е. я хочу настроить сервер таким образом, чтобы он слушал соответствующие > порты и отдавал файлы обычным образом. Т.е. чтобы пользователь, набравший > ftp://www.domain.com/file.php вместо http://www.domain.com/file.php получил > тот же контент. > > Может быть есть какие-то модули для nginx, которые позволяют такое сделать? > Что-то вроде прокси, я даже не знаю как правильно это выразить. > > Заранее спасибо за ответы > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230955,230955#msg-230955 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > autoindex on; ??? http://nginx.org/ru/docs/http/ngx_http_autoindex_module.html#autoindex From greyhard at gmail.com Sun Sep 23 18:04:13 2012 From: greyhard at gmail.com (Ilynikh Denis) Date: Sun, 23 Sep 2012 22:04:13 +0400 Subject: =?UTF-8?B?UmU6IGZ0cDovLyDQuCBuZ2lueCAtINC80L7QttC90L4g0LvQuCDQvdCw0YHRgtGA?= =?UTF-8?B?0L7QuNGC0Ywg0L7RgtC00LDRh9GDINC60L7QvdGC0LXQvdGC0LA/?= In-Reply-To: <7bd32bc27c55a9733ee81033037dd337.NginxMailingListRussian@forum.nginx.org> References: <6f721b04612f625139009243f6b82984.NginxMailingListRussian@forum.nginx.org> <7bd32bc27c55a9733ee81033037dd337.NginxMailingListRussian@forum.nginx.org> Message-ID: видимо придется писать свой фтп сервер, который будет дергать нгинкс. Сохранять ответ во временный файл и уже отдавать его Отправлено с iPhone 23.09.2012, в 15:52, "Yahook" написал(а): > Мне бы подошло решение, когда на входе будет стоять фтп сервер как frontend, > а файлы будут браться с nginx (результат исполнения файлов, если это php). Я > понимаю, что по фтп не поддерживается передача параметров и mime type. > > Т.е. чтобы соответствующий файл запрошенный через фтп запрашивался у nginx и > срабатывали мод реврайты и т.д. и затем фтп сервер отдавал его клиенту в > исполненном виде. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230955,230957#msg-230957 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From noonesshadow at gmail.com Sun Sep 23 18:22:57 2012 From: noonesshadow at gmail.com (Noon es Shadow) Date: Sun, 23 Sep 2012 21:22:57 +0300 Subject: =?UTF-8?B?UmU6IGZ0cDovLyDQuCBuZ2lueCAtINC80L7QttC90L4g0LvQuCDQvdCw0YHRgtGA?= =?UTF-8?B?0L7QuNGC0Ywg0L7RgtC00LDRh9GDINC60L7QvdGC0LXQvdGC0LA/?= In-Reply-To: References: <6f721b04612f625139009243f6b82984.NginxMailingListRussian@forum.nginx.org> <7bd32bc27c55a9733ee81033037dd337.NginxMailingListRussian@forum.nginx.org> Message-ID: ftp + davfs2 + nginx ? 23 сентября 2012 г., 21:04 пользователь Ilynikh Denis написал: > видимо придется писать свой фтп сервер, который будет дергать нгинкс. > Сохранять ответ во временный файл и уже отдавать его > > Отправлено с iPhone > > 23.09.2012, в 15:52, "Yahook" написал(а): > > > Мне бы подошло решение, когда на входе будет стоять фтп сервер как > frontend, > > а файлы будут браться с nginx (результат исполнения файлов, если это > php). Я > > понимаю, что по фтп не поддерживается передача параметров и mime type. > > > > Т.е. чтобы соответствующий файл запрошенный через фтп запрашивался у > nginx и > > срабатывали мод реврайты и т.д. и затем фтп сервер отдавал его клиенту в > > исполненном виде. > > > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,230955,230957#msg-230957 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sun Sep 23 20:03:50 2012 From: nginx-forum at nginx.us (ak84) Date: Sun, 23 Sep 2012 16:03:50 -0400 Subject: nginx & core dump Message-ID: <40283b1ac0230717c195c0d4b9e3c68c.NginxMailingListRussian@forum.nginx.org> Добрый вечер. Есть сервер на FreeBSD 8.2-RELEASE amd64, nginx выступает в роли frontend-сервера, для нескольких доменов, проксирующего запросы к backend-серверам через fastcgi и proxy_pass При включении debug-лога: 2012/09/23 16:32:46 [debug] 16358#0: *369779 close http connection: 257 2012/09/23 16:32:46 [debug] 16358#0: *369779 free: 000000080230B000 2012/09/23 16:32:46 [debug] 16358#0: *369779 free: 0000000801839800 2012/09/23 16:32:46 [debug] 16358#0: *369779 free: 0000000801861400 2012/09/23 16:32:46 [debug] 16358#0: *369779 free: 0000000802333A00, unused: 8 2012/09/23 16:32:46 [debug] 16358#0: *369779 free: 0000000802333D00, unused: 0 2012/09/23 16:32:46 [debug] 16358#0: *369779 free: 0000000802333E00, unused: 208 2012/09/23 16:32:46 [debug] 16358#0: kevent: 258: ft:-2 fl:0020 ff:00000000 d:34080 ud:00000008030E7E90 2012/09/23 16:32:46 [debug] 16358#0: *369701 http run request: "/images/icon.gif?1348318282" 2012/09/23 16:32:46 [debug] 16358#0: *369701 http upstream check client, write event:1, "/images/icon.gif" 2012/09/23 16:32:46 [debug] 16358#0: timer delta: 3 2012/09/23 16:32:46 [debug] 16358#0: posted events 0000000000000000 2012/09/23 16:32:46 [debug] 16358#0: worker cycle 2012/09/23 16:32:46 [debug] 16358#0: accept mutex lock failed: 0 2012/09/23 16:32:46 [debug] 16358#0: kevent timer: 162, changes: 0 2012/09/23 16:32:46 [debug] 16358#0: kevent events: 1 2012/09/23 16:32:46 [debug] 16358#0: kevent: 259: ft:-1 fl:8020 ff:00000000 d:0 ud:0000000803006371 2012/09/23 16:32:46 [debug] 16358#0: *369727 http run request: "/?c=chat&m=save_reply&owner_id=3699228&selected_tab=2&inbox=1&to=1634790" 2012/09/23 16:32:46 [debug] 16358#0: *369727 http read client request body 2012/09/23 16:32:46 [debug] 16358#0: *369727 add cleanup: 00000008031DCA90 2012/09/23 16:32:46 [debug] 16358#0: *369727 hashed path: /var/tmp/nginx/client_body_temp/0000001175 2012/09/23 16:32:46 [debug] 16358#0: *369727 temp fd:257 2012/09/23 16:32:46 [warn] 16358#0: *369727 a client request body is buffered to a temporary file /var/tmp/nginx/client_body_temp/0000001175 while sending request to upst ream, client: client_ip, server: www.test.com, request: "POST /?id=user&owner_id=1&selected_id=2&inbox=1 HTTP/1.1", upstream: "ht tp://backend_ip/?id=user&owner_id=1&selected_id=2&inbox=1", host: "test.com", referrer: "http://test.com/?id=user&owner_id=1&selected_id=2&inbox=1" 2012/09/23 16:32:46 [debug] 16358#0: *369727 write: 257, 00000008022ADEE8, 153, 0 2012/09/23 16:32:46 [debug] 16358#0: *369727 recv: eof:1, avail:0, err:0 2012/09/23 16:32:46 [debug] 16358#0: *369727 http client request body recv 0 2012/09/23 16:32:46 [info] 16358#0: *369727 client closed prematurely connection while sending request to upstream, client: client_ip, server: www.test.com, re quest: "POST /?id=user&owner_id=1&selected_id=2&inbox=1 HTTP/1.1", upstream: "http://backend_ip/?id=user&owner_id=1&selected_id=2&inbox=1", host: "test.com", referrer: "http://test.com/?id=user&owner_id=1&selected_id=2&inbox=1" 2012/09/23 16:32:46 [debug] 16358#0: *369727 http finalize request: 400, "/?id=user&owner_id=1&selected_id=2&inbox=1" a:1, c:1 2012/09/23 16:32:46 [debug] 16358#0: *369727 http terminate request count:1 2012/09/23 16:32:46 [debug] 16358#0: *369727 cleanup http upstream request: "/" 2012/09/23 16:32:46 [debug] 16358#0: *369727 finalize http upstream request: -4 2012/09/23 16:32:46 [debug] 16358#0: *369727 finalize http proxy request 2012/09/23 16:32:46 [debug] 16358#0: *369727 free rr peer 2 0 2012/09/23 16:32:46 [debug] 16358#0: *369727 close http upstream connection: 267 2012/09/23 16:32:46 [debug] 16358#0: *369727 event timer del: 267: 1348403626758 2012/09/23 16:32:46 [debug] 16358#0: *369727 http finalize request: -4, "/?id=user&owner_id=1&selected_id=2&inbox=1" a:1, c:1 2012/09/23 16:32:46 [debug] 16358#0: *369727 set http keepalive handler 2012/09/23 16:32:46 [debug] 16358#0: *369727 http close request 2012/09/23 16:32:46 [debug] 16358#0: *369727 http log handler 2012/09/23 16:32:46 [debug] 16358#0: *369727 run cleanup: 00000008031DCA90 2012/09/23 16:32:46 [debug] 16358#0: *369727 file cleanup: fd:257 2012/09/23 16:32:46 [debug] 16358#0: *369727 free: 00000008022AD000, unused: 3 2012/09/23 16:32:46 [debug] 16358#0: *369727 free: 00000008031DC000, unused: 851 2012/09/23 16:32:46 [debug] 16358#0: *369727 event timer add: 259: 65000:1348403631780 2012/09/23 16:32:46 [debug] 16358#0: *369727 free: 000000080185F600 2012/09/23 16:32:46 [debug] 16358#0: *369727 free: 0000000801838000 2012/09/23 16:32:46 [debug] 16358#0: *369727 hc free: 0000000000000000 0 2012/09/23 16:32:46 [debug] 16358#0: *369727 hc busy: 00000008022CAD90 1 2012/09/23 16:32:46 [debug] 16358#0: *369727 free: 00000008019FA000 2012/09/23 16:32:46 [debug] 16358#0: *369727 tcp_nodelay 2012/09/23 16:32:46 [alert] 16352#0: worker process 16358 exited on signal 10 (core dumped) nginx version: nginx/0.8.54 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 --with-debug --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 --without-http-cache --add-module=/usr/ports/www/nginx/work/ngx_headers_more_module-0.13 --with-http_image_filter_module --with-http_ssl_module --with-http_stub_status_module --with-pcre В логах стало появляться: pid 19220 (nginx), uid 65534: exited on signal 10 (core dumped) Смотри core-файл: #0 0x000000000044ec03 in ngx_http_terminate_request (r=0x801862300, rc=400) at src/http/ngx_http_request.c:2069 2069 src/http/ngx_http_request.c: No such file or directory. in src/http/ngx_http_request.c (gdb) bt #0 0x000000000044ec03 in ngx_http_terminate_request (r=0x801862300, rc=400) at src/http/ngx_http_request.c:2069 #1 0x000000000044e606 in ngx_http_finalize_request (r=0x801862300, rc=400) at src/http/ngx_http_request.c:1903 #2 0x000000000045900b in ngx_http_read_client_request_body_handler (r=0x801862300) at src/http/ngx_http_request_body.c:254 #3 0x000000000044e28e in ngx_http_request_handler (ev=0x803011120) at src/http/ngx_http_request.c:1791 #4 0x0000000000429b84 in ngx_event_process_posted (cycle=0x801842050, posted=0x5cfb20) at src/event/ngx_event_posted.c:39 #5 0x00000000004277dd in ngx_process_events_and_timers (cycle=0x801842050) at src/event/ngx_event.c:272 #6 0x0000000000433f03 in ngx_worker_process_cycle (cycle=0x801842050, data=0x0) at src/os/unix/ngx_process_cycle.c:795 #7 0x00000000004310bd in ngx_spawn_process (cycle=0x801842050, proc=0x433d2e , data=0x0, name=0x4a7271 "worker process", respawn=6) at src/os/unix/ngx_process.c:196 #8 0x0000000000433987 in ngx_reap_children (cycle=0x801842050) at src/os/unix/ngx_process_cycle.c:612 #9 0x0000000000432748 in ngx_master_process_cycle (cycle=0x801842050) at src/os/unix/ngx_process_cycle.c:180 #10 0x0000000000405c81 in main (argc=1, argv=0x7fffffffed68) at src/core/nginx.c:401 (gdb) backtrace #0 0x000000000044ec03 in ngx_http_terminate_request (r=0x801862300, rc=400) at src/http/ngx_http_request.c:2069 #1 0x000000000044e606 in ngx_http_finalize_request (r=0x801862300, rc=400) at src/http/ngx_http_request.c:1903 #2 0x000000000045900b in ngx_http_read_client_request_body_handler (r=0x801862300) at src/http/ngx_http_request_body.c:254 #3 0x000000000044e28e in ngx_http_request_handler (ev=0x803011120) at src/http/ngx_http_request.c:1791 #4 0x0000000000429b84 in ngx_event_process_posted (cycle=0x801842050, posted=0x5cfb20) at src/event/ngx_event_posted.c:39 #5 0x00000000004277dd in ngx_process_events_and_timers (cycle=0x801842050) at src/event/ngx_event.c:272 #6 0x0000000000433f03 in ngx_worker_process_cycle (cycle=0x801842050, data=0x0) at src/os/unix/ngx_process_cycle.c:795 #7 0x00000000004310bd in ngx_spawn_process (cycle=0x801842050, proc=0x433d2e , data=0x0, name=0x4a7271 "worker process", respawn=6) at src/os/unix/ngx_process.c:196 #8 0x0000000000433987 in ngx_reap_children (cycle=0x801842050) at src/os/unix/ngx_process_cycle.c:612 #9 0x0000000000432748 in ngx_master_process_cycle (cycle=0x801842050) at src/os/unix/ngx_process_cycle.c:180 #10 0x0000000000405c81 in main (argc=1, argv=0x7fffffffed68) at src/core/nginx.c:401 (gdb) backtrace full #0 0x000000000044ec03 in ngx_http_terminate_request (r=0x801862300, rc=400) at src/http/ngx_http_request.c:2069 cln = (ngx_http_cleanup_t *) 0x5a5a5a5a5a5a5a5a mr = (ngx_http_request_t *) 0x801862300 e = (ngx_http_ephemeral_t *) 0x801ee1218 #1 0x000000000044e606 in ngx_http_finalize_request (r=0x801862300, rc=400) at src/http/ngx_http_request.c:1903 c = (ngx_connection_t *) 0x801c19790 pr = (ngx_http_request_t *) 0x8031cbe98 clcf = (ngx_http_core_loc_conf_t *) 0x803010240 #2 0x000000000045900b in ngx_http_read_client_request_body_handler (r=0x801862300) at src/http/ngx_http_request_body.c:254 rc = 400 #3 0x000000000044e28e in ngx_http_request_handler (ev=0x803011120) at src/http/ngx_http_request.c:1791 c = (ngx_connection_t *) 0x801c19790 r = (ngx_http_request_t *) 0x801862300 ctx = (ngx_http_log_ctx_t *) 0x801d85ea0 #4 0x0000000000429b84 in ngx_event_process_posted (cycle=0x801842050, posted=0x5cfb20) at src/event/ngx_event_posted.c:39 ev = (ngx_event_t *) 0x803011120 #5 0x00000000004277dd in ngx_process_events_and_timers (cycle=0x801842050) at src/event/ngx_event.c:272 flags = 3 timer = 505 delta = 0 #6 0x0000000000433f03 in ngx_worker_process_cycle (cycle=0x801842050, data=0x0) at src/os/unix/ngx_process_cycle.c:795 i = 1 c = (ngx_connection_t *) 0x7fffffffe9a0 #7 0x00000000004310bd in ngx_spawn_process (cycle=0x801842050, proc=0x433d2e , data=0x0, name=0x4a7271 "worker process", respawn=6) at src/os/unix/ngx_process.c:196 on = 1 pid = 0 s = 6 #8 0x0000000000433987 in ngx_reap_children (cycle=0x801842050) at src/os/unix/ngx_process_cycle.c:612 i = 6 n = 8 live = 1 ch = {command = 2, pid = 19222, slot = 6, fd = -1} ccf = (ngx_core_conf_t *) 0x505f560f #9 0x0000000000432748 in ngx_master_process_cycle (cycle=0x801842050) at src/os/unix/ngx_process_cycle.c:180 title = 0x8023c504c "master process /usr/local/sbin/nginx" p = (u_char *) 0x8023c5070 "" size = 37 i = 1 n = 6 sigio = 0 set = {__bits = {0, 0, 0, 0}} itv = {it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0, tv_usec = 0}} live = 1 delay = 0 ls = (ngx_listening_t *) 0x6 ccf = (ngx_core_conf_t *) 0x801843008 #10 0x0000000000405c81 in main (argc=1, argv=0x7fffffffed68) at src/core/nginx.c:401 ---Type to continue, or q to quit--- i = 48 log = (ngx_log_t *) 0x5cd800 cycle = (ngx_cycle_t *) 0x801842050 init_cycle = {conf_ctx = 0x0, pool = 0x801836800, log = 0x5cd800, new_log = {log_level = 0, file = 0x0, connection = 0, handler = 0, data = 0x0, action = 0x0}, files = 0x0, free_connections = 0x0, free_connection_n = 0, listening = {elts = 0x0, nelts = 0, size = 0, nalloc = 0, pool = 0x0}, pathes = {elts = 0x0, nelts = 0, size = 0, nalloc = 0, pool = 0x0}, open_files = {last = 0x0, part = {elts = 0x0, nelts = 0, next = 0x0}, size = 0, nalloc = 0, pool = 0x0}, shared_memory = { last = 0x0, part = {elts = 0x0, nelts = 0, next = 0x0}, size = 0, nalloc = 0, pool = 0x0}, connection_n = 0, files_n = 0, connections = 0x0, read_events = 0x0, write_events = 0x0, old_cycle = 0x0, conf_file = {len = 31, data = 0x4a36c8 "/usr/local/etc/nginx/nginx.conf"}, conf_param = {len = 0, data = 0x0}, conf_prefix = { len = 21, data = 0x4a36c8 "/usr/local/etc/nginx/nginx.conf"}, prefix = {len = 21, data = 0x4a36b0 "/usr/local/etc/nginx/"}, lock_file = {len = 0, data = 0x0}, hostname = {len = 0, data = 0x0}} ccf = (ngx_core_conf_t *) 0x801843008 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230962,230962#msg-230962 From nginx-forum at nginx.us Sun Sep 23 20:10:27 2012 From: nginx-forum at nginx.us (ak84) Date: Sun, 23 Sep 2012 16:10:27 -0400 Subject: nginx & core dump In-Reply-To: <40283b1ac0230717c195c0d4b9e3c68c.NginxMailingListRussian@forum.nginx.org> References: <40283b1ac0230717c195c0d4b9e3c68c.NginxMailingListRussian@forum.nginx.org> Message-ID: К предидущему сообщению: как победить core dump ? Заметил, что этот core dump возникает на запросах на один конкретный домен ( судя по debug-логам), другие домены в core dump не фигурируют. Спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230962,230963#msg-230963 From mdounin at mdounin.ru Sun Sep 23 21:12:05 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 24 Sep 2012 01:12:05 +0400 Subject: nginx & core dump In-Reply-To: <40283b1ac0230717c195c0d4b9e3c68c.NginxMailingListRussian@forum.nginx.org> References: <40283b1ac0230717c195c0d4b9e3c68c.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120923211205.GY40452@mdounin.ru> Hello! On Sun, Sep 23, 2012 at 04:03:50PM -0400, ak84 wrote: > Есть сервер на FreeBSD 8.2-RELEASE amd64, nginx выступает в роли > frontend-сервера, для нескольких доменов, проксирующего запросы к > backend-серверам через fastcgi и proxy_pass > При включении debug-лога: [...] > nginx version: nginx/0.8.54 > 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 > --with-debug --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 --without-http-cache > --add-module=/usr/ports/www/nginx/work/ngx_headers_more_module-0.13 > --with-http_image_filter_module --with-http_ssl_module > --with-http_stub_status_module --with-pcre > > В логах стало появляться: > pid 19220 (nginx), uid 65534: exited on signal 10 (core dumped) Начните с простого - попробуйте воспроизвести проблему хотя бы со свежей стабильной версией (лучше - current aka devel), и без сторонних модулей. Со времён 0.8.54 прошло уже почти два года, и скорее всего ваша проблема уже исправлена. Но за давностью лет об этом врядли сейчас кто вспомнит. (По трейсу и предоставленным отрывкам дебаг-лога - больше всего похоже на использование proxy_ignore_client_abort, она к подобному могла приводить до 1.1.2. Но без конфига и дополнительного разбирательства утверждать не возьмусь, а заниматься этим ради 0.8.54 - глупо.) Maxim Dounin From hell-for-yahoo at umail.ru Mon Sep 24 03:47:04 2012 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Mon, 24 Sep 2012 07:47:04 +0400 Subject: =?UTF-8?B?UmU6INCd0LDQtNC/0LjRgdC4INC90LAg0LrQsNGA0YLQuNC90LrQsNGF?= In-Reply-To: <1656647945.20120921181223@softsearch.ru> References: <1656647945.20120921181223@softsearch.ru> Message-ID: <183907427.20120924074704@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Михаил Монашёв! ММ> Есть потребность накладывать на отдаваемые картинки подписи в виде ММ> текст или изображений при отдаче их на другие сайты. По каким критериям собираетесь определять "другие сайты"? ММ> Т.е. если смотрим картинку на своём сайте, то показывается оригинальная ММ> картинка. А если в реферере сторонний сайт, Смеётесь? :) Откуда. По-моему, браузеры давно отучились левыми реферерами представляться. Либо твой, либо никакого. ММ> то налету добавляем подпись, если картинка больше, чем x на y пикселей. ММ> Сие можно и на бэкенде делать, но раз уж есть image_filter, то логично ММ> подобное делать в нём. -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) понедельник, 24.09.2012, <07:45> From danila at shtan.ru Mon Sep 24 04:40:18 2012 From: danila at shtan.ru (Danila Shtan) Date: Mon, 24 Sep 2012 10:40:18 +0600 Subject: =?UTF-8?B?UmU6INCd0LDQtNC/0LjRgdC4INC90LAg0LrQsNGA0YLQuNC90LrQsNGF?= In-Reply-To: <183907427.20120924074704@mtu-net.ru> References: <1656647945.20120921181223@softsearch.ru> <183907427.20120924074704@mtu-net.ru> Message-ID: понедельник, 24 сентября 2012 г. пользователь Andrey Repin писал: > Здравствуйте, Уважаемый(-ая, -ое) Михаил Монашёв! > > ММ> Есть потребность накладывать на отдаваемые картинки подписи в виде > ММ> текст или изображений при отдаче их на другие сайты. > > По каким критериям собираетесь определять "другие сайты"? > > ММ> Т.е. если смотрим картинку на своём сайте, то показывается оригинальная > ММ> картинка. А если в реферере сторонний сайт, > > Смеётесь? :) Откуда. По-моему, браузеры давно отучились левыми реферерами > представляться. Либо твой, либо никакого. Посмотрел в свой access_log. Вы браузеры с парсерами не путаете? ТС хочет защититься от хотлинкинга. > ММ> то налету добавляем подпись, если картинка больше, чем x на y пикселей. > ММ> Сие можно и на бэкенде делать, но раз уж есть image_filter, то логично > ММ> подобное делать в нём. > > > -- > С уважением > > Andrey Repin (hell-for-yahoo at umail.ru ) понедельник, > 24.09.2012, <07:45> > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Mon Sep 24 06:15:49 2012 From: nginx-forum at nginx.us (ak84) Date: Mon, 24 Sep 2012 02:15:49 -0400 Subject: nginx & core dump In-Reply-To: <20120923211205.GY40452@mdounin.ru> References: <20120923211205.GY40452@mdounin.ru> Message-ID: <15d76fb6949e757be351b2854e19accb.NginxMailingListRussian@forum.nginx.org> Максим, доюрый день. Спасибо за ответ, попробую с новой стабильной версией из портов. Чтобы не плодить темы: Есть 2-й сервер, на нём установлена: FreeBSD 8.2-RELEASE-p3 amd64 nginx -V nginx version: nginx/1.2.3 ( самая свежая версия из stable ) 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 --with-debug --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 --add-module=/usr/ports/www/nginx/work/agentzh-headers-more-nginx-module-6586984 --with-http_image_filter_module --add-module=/usr/ports/www/nginx/work/yaoweibin-ngx_http_substitutions_filter_module-27a01b3 --with-http_stub_status_module --with-pcre --with-http_ssl_module В dmesg вижу: id 63769 (nginx), uid 80: exited on signal 11 pid 63801 (nginx), uid 80: exited on signal 11 (core dumped) gdb /usr/local/sbin/nginx nginx.core.63801 Loaded symbols for /libexec/ld-elf.so.1 #0 0x000000000040a350 in ngx_hash_find (hash=0x80240a868, key=34394151004, name=0x2
, len=7) at src/core/ngx_hash.c:34 34 src/core/ngx_hash.c: No such file or directory. in src/core/ngx_hash.c (gdb) bt #0 0x000000000040a350 in ngx_hash_find (hash=0x80240a868, key=34394151004, name=0x2
, len=7) at src/core/ngx_hash.c:34 #1 0x000000000049e919 in ngx_http_proxy_create_request (r=0x801f57700) at src/http/modules/ngx_http_proxy_module.c:1040 #2 0x0000000000468b71 in ngx_http_upstream_init_request (r=0x801f57700) at src/http/ngx_http_upstream.c:505 #3 0x0000000000468904 in ngx_http_upstream_init (r=0x801f57700) at src/http/ngx_http_upstream.c:446 #4 0x000000000045ec83 in ngx_http_read_client_request_body (r=0x801f57700, post_handler=0x468820 ) at src/http/ngx_http_request_body.c:59 #5 0x000000000049da4c in ngx_http_proxy_handler (r=0x801f57700) at src/http/modules/ngx_http_proxy_module.c:702 #6 0x000000000044692d in ngx_http_core_content_phase (r=0x801f57700, ph=0x80265da68) at src/http/ngx_http_core_module.c:1396 #7 0x0000000000445462 in ngx_http_core_run_phases (r=0x801f57700) at src/http/ngx_http_core_module.c:877 #8 0x00000000004453dd in ngx_http_handler (r=0x801f57700) at src/http/ngx_http_core_module.c:860 #9 0x0000000000453d74 in ngx_http_process_request (r=0x801f57700) at src/http/ngx_http_request.c:1685 #10 0x0000000000452775 in ngx_http_process_request_headers (rev=0x80266d730) at src/http/ngx_http_request.c:1135 #11 0x0000000000451f06 in ngx_http_process_request_line (rev=0x80266d730) at src/http/ngx_http_request.c:933 #12 0x0000000000451108 in ngx_http_init_request (rev=0x80266d730) at src/http/ngx_http_request.c:519 #13 0x000000000042d3dc in ngx_event_process_posted (cycle=0x801e55050, posted=0x5f0a60) at src/event/ngx_event_posted.c:40 #14 0x000000000042ae85 in ngx_process_events_and_timers (cycle=0x801e55050) at src/event/ngx_event.c:274 #15 0x00000000004381c4 in ngx_worker_process_cycle (cycle=0x801e55050, data=0x0) at src/os/unix/ngx_process_cycle.c:808 #16 0x00000000004351c1 in ngx_spawn_process (cycle=0x801e55050, proc=0x437fd0 , data=0x0, name=0x4c18c9 "worker process", respawn=6) at src/os/unix/ngx_process.c:198 #17 0x0000000000437bf2 in ngx_reap_children (cycle=0x801e55050) at src/os/unix/ngx_process_cycle.c:622 #18 0x0000000000436946 in ngx_master_process_cycle (cycle=0x801e55050) at src/os/unix/ngx_process_cycle.c:181 #19 0x00000000004066d3 in main (argc=1, argv=0x7fffffffed68) at src/core/nginx.c:410 (gdb) bt full #0 0x000000000040a350 in ngx_hash_find (hash=0x80240a868, key=34394151004, name=0x2
, len=7) at src/core/ngx_hash.c:34 i = 0 elt = (ngx_hash_elt_t *) 0x80232e890 #1 0x000000000049e919 in ngx_http_proxy_create_request (r=0x801f57700) at src/http/modules/ngx_http_proxy_module.c:1040 len = 1363 uri_len = 28 loc_len = 0 body_len = 0 escape = 0 b = (ngx_buf_t *) 0x0 method = {len = 4, data = 0x801e49800 "GET /images/auth.jpg HTTP/1.0\r\nX-Real-Remote-Addr"} i = 0 unparsed_uri = 1 cl = (ngx_chain_t *) 0x0 body = (ngx_chain_t *) 0x0 part = (ngx_list_part_t *) 0x8027e2ca8 header = (ngx_table_elt_t *) 0x8027e3050 u = (ngx_http_upstream_t *) 0x8027e33e0 ctx = (ngx_http_proxy_ctx_t *) 0x8027e2df8 code = 0x100000000 e = {ip = 0x802200001 "л_", pos = 0x5fcd28 "(м_", sp = 0x0, buf = {len = 4294960124, data = 0x801e49820 " HTTP/1.0\r\nX-Real-Remote-Addr"}, line = {len = 34391496708, data = 0x2
}, args = 0x989680
, flushed = 0, skip = 0, quote = 0, is_args = 0, log = 0, status = 34401561808, request = 0x0} le = {ip = 0x80232e720 "", pos = 0x0, sp = 0x1, buf = {len = 0, data = 0x800000000
}, line = {len = 1431655766, data = 0x0}, args = 0x0, flushed = 1, skip = 0, quote = 0, is_args = 0, log = 0, status = 34391496707, request = 0x801f57700} plcf = (ngx_http_proxy_loc_conf_t *) 0x80240a6d0 lcode = 0x465e20 #2 0x0000000000468b71 in ngx_http_upstream_init_request (r=0x801f57700) at src/http/ngx_http_upstream.c:505 host = (ngx_str_t *) 0x801ee3000 i = 34401708392 ctx = (ngx_resolver_ctx_t *) 0x7fffffffe520 temp = {next = 0x0, resolver = 0x0, udp_connection = 0x0, ident = 140737488348336, state = 34393362520, type = 2, name = {len = 140737488348432, data = 0x7fffffffed78 "fОЪЪЪ\177"}, naddrs = 97, addrs = 0x78, addr = 4294967273, handler = 0xe, data = 0x0, timeout = 37, quick = 18446744073709551614, recursion = 34414286640, event = 0x7fffffffe520} cln = (ngx_http_cleanup_t *) 0x43ae9a u = (ngx_http_upstream_t *) 0x8027e33e0 clcf = (ngx_http_core_loc_conf_t *) 0x20 uscf = (ngx_http_upstream_srv_conf_t *) 0xfffffffffffffffe uscfp = (ngx_http_upstream_srv_conf_t **) 0x803405730 umcf = (ngx_http_upstream_main_conf_t *) 0x8027e2f98 #3 0x0000000000468904 in ngx_http_upstream_init (r=0x801f57700) at src/http/ngx_http_upstream.c:446 c = (ngx_connection_t *) 0x802806968 #4 0x000000000045ec83 in ngx_http_read_client_request_body (r=0x801f57700, post_handler=0x468820 ) at src/http/ngx_http_request_body.c:59 preread = 34401558528 size = 34401562264 b = (ngx_buf_t *) 0x8027e2000 cl = (ngx_chain_t *) 0x7fffffffe5d0 next = (ngx_chain_t **) 0x40995a tf = (ngx_temp_file_t *) 0x100 rb = (ngx_http_request_body_t *) 0x8027e2f98 clcf = (ngx_http_core_loc_conf_t *) 0x0 #5 0x000000000049da4c in ngx_http_proxy_handler (r=0x801f57700) at src/http/modules/ngx_http_proxy_module.c:702 rc = 34391556392 u = (ngx_http_upstream_t *) 0x8027e33e0 ctx = (ngx_http_proxy_ctx_t *) 0x8027e2df8 plcf = (ngx_http_proxy_loc_conf_t *) 0x80240a6d0 #6 0x000000000044692d in ngx_http_core_content_phase (r=0x801f57700, ph=0x80265da68) at src/http/ngx_http_core_module.c:1396 root = 18446744073709551611 rc = 0 path = {len = 34399967824, data = 0x801f57700 "HTTP"} #7 0x0000000000445462 in ngx_http_core_run_phases (r=0x801f57700) at src/http/ngx_http_core_module.c:877 rc = -2 ph = (ngx_http_phase_handler_t *) 0x80265d978 cmcf = (ngx_http_core_main_conf_t *) 0x801e56810 #8 0x00000000004453dd in ngx_http_handler (r=0x801f57700) at src/http/ngx_http_core_module.c:860 cmcf = (ngx_http_core_main_conf_t *) 0x80266d730 #9 0x0000000000453d74 in ngx_http_process_request (r=0x801f57700) at src/http/ngx_http_request.c:1685 c = (ngx_connection_t *) 0x802806968 #10 0x0000000000452775 in ngx_http_process_request_headers (rev=0x80266d730) at src/http/ngx_http_request.c:1135 p = (u_char *) 0x10
len = 34401558528 n = 369 rc = 0 rv = 0 h = (ngx_table_elt_t *) 0x8027e3020 c = (ngx_connection_t *) 0x802806968 hh = (ngx_http_header_t *) 0x0 r = (ngx_http_request_t *) 0x801f57700 cscf = (ngx_http_core_srv_conf_t *) 0x801e73a50 cmcf = (ngx_http_core_main_conf_t *) 0x801e56810 #11 0x0000000000451f06 in ngx_http_process_request_line (rev=0x80266d730) at src/http/ngx_http_request.c:933 host = (u_char *) 0x8027e2000 "х/~\002\b" n = 1024 rc = 0 rv = 624 c = (ngx_connection_t *) 0x802806968 r = (ngx_http_request_t *) 0x801f57700 cscf = (ngx_http_core_srv_conf_t *) 0x8027e2568 #12 0x0000000000451108 in ngx_http_init_request (rev=0x80266d730) at src/http/ngx_http_request.c:519 tp = (ngx_time_t *) 0x5ee490 i = 0 c = (ngx_connection_t *) 0x802806968 r = (ngx_http_request_t *) 0x801f57700 sin = (struct sockaddr_in *) 0x802279520 port = (ngx_http_port_t *) 0x80265ea90 addr = (ngx_http_in_addr_t *) 0x80265eaa0 ctx = (ngx_http_log_ctx_t *) 0x8022794a0 addr_conf = (ngx_http_addr_conf_t *) 0x80265eaa8 hc = (ngx_http_connection_t *) 0x8022794b8 cscf = (ngx_http_core_srv_conf_t *) 0x801e73a50 clcf = (ngx_http_core_loc_conf_t *) 0x801e73ae8 cmcf = (ngx_http_core_main_conf_t *) 0x801e56810 #13 0x000000000042d3dc in ngx_event_process_posted (cycle=0x801e55050, posted=0x5f0a60) at src/event/ngx_event_posted.c:40 ev = (ngx_event_t *) 0x80266d730 #14 0x000000000042ae85 in ngx_process_events_and_timers (cycle=0x801e55050) at src/event/ngx_event.c:274 flags = 3 timer = 2428 delta = 1 #15 0x00000000004381c4 in ngx_worker_process_cycle (cycle=0x801e55050, data=0x0) at src/os/unix/ngx_process_cycle.c:808 i = 1 c = (ngx_connection_t *) 0x7fffffffe990 #16 0x00000000004351c1 in ngx_spawn_process (cycle=0x801e55050, proc=0x437fd0 , data=0x0, name=0x4c18c9 "worker process", respawn=6) at src/os/unix/ngx_process.c:198 on = 1 pid = 0 s = 6 #17 0x0000000000437bf2 in ngx_reap_children (cycle=0x801e55050) at src/os/unix/ngx_process_cycle.c:622 i = 6 n = 8 ---Type to continue, or q to quit--- live = 1 ch = {command = 2, pid = 63768, slot = 6, fd = -1} ccf = (ngx_core_conf_t *) 0x505f6694 #18 0x0000000000436946 in ngx_master_process_cycle (cycle=0x801e55050) at src/os/unix/ngx_process_cycle.c:181 title = 0x80265ff9c "master process /usr/local/sbin/nginx" p = (u_char *) 0x80265ffc0 "" size = 37 i = 1 n = 6 sigio = 0 set = {__bits = {0, 0, 0, 0}} itv = {it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0, tv_usec = 0}} live = 1 delay = 0 ls = (ngx_listening_t *) 0x6 ccf = (ngx_core_conf_t *) 0x801e56040 #19 0x00000000004066d3 in main (argc=1, argv=0x7fffffffed68) at src/core/nginx.c:410 i = 52 log = (ngx_log_t *) 0x5ee040 cycle = (ngx_cycle_t *) 0x801e55050 init_cycle = {conf_ctx = 0x0, pool = 0x801e49800, log = 0x5ee040, new_log = {log_level = 0, file = 0x0, connection = 0, handler = 0, data = 0x0, action = 0x0}, files = 0x0, free_connections = 0x0, free_connection_n = 0, reusable_connections_queue = {prev = 0x0, next = 0x0}, listening = {elts = 0x0, nelts = 0, size = 0, nalloc = 0, pool = 0x0}, pathes = {elts = 0x0, nelts = 0, size = 0, nalloc = 0, pool = 0x0}, open_files = {last = 0x0, part = {elts = 0x0, nelts = 0, next = 0x0}, size = 0, nalloc = 0, pool = 0x0}, shared_memory = {last = 0x0, part = { elts = 0x0, nelts = 0, next = 0x0}, size = 0, nalloc = 0, pool = 0x0}, connection_n = 0, files_n = 0, connections = 0x0, read_events = 0x0, write_events = 0x0, old_cycle = 0x0, conf_file = { len = 31, data = 0x4bda50 "/usr/local/etc/nginx/nginx.conf"}, conf_param = {len = 0, data = 0x0}, conf_prefix = {len = 21, data = 0x4bda50 "/usr/local/etc/nginx/nginx.conf"}, prefix = {len = 21, data = 0x4bda38 "/usr/local/etc/nginx/"}, lock_file = {len = 0, data = 0x0}, hostname = {len = 0, data = 0x0}} ccf = (ngx_core_conf_t *) 0x801e56040 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230962,230972#msg-230972 From mdounin at mdounin.ru Mon Sep 24 09:03:59 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 24 Sep 2012 13:03:59 +0400 Subject: nginx & core dump In-Reply-To: <15d76fb6949e757be351b2854e19accb.NginxMailingListRussian@forum.nginx.org> References: <20120923211205.GY40452@mdounin.ru> <15d76fb6949e757be351b2854e19accb.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120924090359.GZ40452@mdounin.ru> Hello! On Mon, Sep 24, 2012 at 02:15:49AM -0400, ak84 wrote: > Максим, доюрый день. > Спасибо за ответ, попробую с новой стабильной версией из портов. > > Чтобы не плодить темы: > Есть 2-й сервер, на нём установлена: FreeBSD 8.2-RELEASE-p3 amd64 > nginx -V > nginx version: nginx/1.2.3 ( самая свежая версия из stable ) > 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 > --with-debug --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 > --add-module=/usr/ports/www/nginx/work/agentzh-headers-more-nginx-module-6586984 > --with-http_image_filter_module > --add-module=/usr/ports/www/nginx/work/yaoweibin-ngx_http_substitutions_filter_module-27a01b3 > --with-http_stub_status_module --with-pcre --with-http_ssl_module Повторяю рекомендацию из предыдущего письма: без сторонних модулей. [...] > (gdb) bt > #0 0x000000000040a350 in ngx_hash_find (hash=0x80240a868, key=34394151004, > name=0x2
, len=7) at src/core/ngx_hash.c:34 > #1 0x000000000049e919 in ngx_http_proxy_create_request (r=0x801f57700) at > src/http/modules/ngx_http_proxy_module.c:1040 Это выглядит как результат некорректного изменения заголовков запроса. Скорее всего, проблема вылечится отключением соответствующего стороннего модуля. Maxim Dounin From nginx-forum at nginx.us Mon Sep 24 09:24:07 2012 From: nginx-forum at nginx.us (ak84) Date: Mon, 24 Sep 2012 05:24:07 -0400 Subject: nginx & core dump In-Reply-To: <20120924090359.GZ40452@mdounin.ru> References: <20120924090359.GZ40452@mdounin.ru> Message-ID: <4f9bc4188b839e8282c5ccd389fb901a.NginxMailingListRussian@forum.nginx.org> Максим, какой модуль отключить? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230962,230976#msg-230976 From voron at amhost.net Mon Sep 24 10:28:23 2012 From: voron at amhost.net (Alex Vorona) Date: Mon, 24 Sep 2012 13:28:23 +0300 Subject: nginx & core dump In-Reply-To: <4f9bc4188b839e8282c5ccd389fb901a.NginxMailingListRussian@forum.nginx.org> References: <20120924090359.GZ40452@mdounin.ru> <4f9bc4188b839e8282c5ccd389fb901a.NginxMailingListRussian@forum.nginx.org> Message-ID: <506035C7.9010608@amhost.net> 24.09.2012 12:24, ak84 wrote: > Максим, какой модуль отключить? >--add-module=/usr/ports/www/nginx/work/agentzh-headers-more-nginx-module-6586984 >--add-module=/usr/ports/www/nginx/work/yaoweibin-ngx_http_substitutions_filter_module-27a01b3 Вот этих строчек не должно быть в nginx -V после пересборки без сторонних модулей. From server_inc at list.ru Tue Sep 25 10:22:02 2012 From: server_inc at list.ru (=?KOI8-R?Q?=F3=D4=C1=CE=C9=D3=CC=C1=D7?=) Date: Tue, 25 Sep 2012 13:22:02 +0300 Subject: =?UTF-8?B?UmU6INCd0LDQtNC/0LjRgdC4INC90LAg0LrQsNGA0YLQuNC90LrQsNGF?= In-Reply-To: <183907427.20120924074704@mtu-net.ru> References: <1656647945.20120921181223@softsearch.ru> <183907427.20120924074704@mtu-net.ru> Message-ID: <506185CA.9060905@list.ru> 24.09.2012 6:47, Andrey Repin пишет: > > Смеётесь? :) Откуда. По-моему, браузеры давно отучились левыми реферерами > представляться. Либо твой, либо никакого. Сударь, вы что-то путаете. From nginx-forum at nginx.us Tue Sep 25 13:41:57 2012 From: nginx-forum at nginx.us (o456092@rtrtr.com) Date: Tue, 25 Sep 2012 09:41:57 -0400 Subject: recursive_error_pages limited to a chain of 11? Message-ID: Hi, I have configured NGINX as an HTTP Asset locator, where the assets might found through a series of recursive errors by sequentially a series of different webservers. The problem that "I think" I have ran into, is that NGINX's recursive_error_pages is limited to a depth 11 servers, thus 11 errors 404 or 500 errors- is this a fact? Interesting enough I get a 500 internal server error when I hit this 11th member in the chain. I have tested various scenarios and I always seem to be blocked at the 11th cascading call with a 500 error - I move different servers around in fear that one of them (upstream servers) had a problem, but it was not specific to a server, regardless which asset I was going after http:/srv/file - once it hit 11 in depth. Anyone has any ideas of this limitation - or is there something that could be done? -------------------------------------------------------------- nginx.conf ======== #user nobody; worker_processes 5; pid /var/run/nginx.origin.pid; events { worker_connections 10000; } http { include /etc/nginx.origin/mime.types; default_type application/octet-stream; log_format main '-->$upstream_cache_status<-- | ' '$remote_addr - $remote_user [$time_local] "$request" ' '| Upstream_Address "$upstream_addr" ' '| upstream_response_time $upstream_response_time ' '| msec $msec request_time $request_time ' '| OriginServer $upstream_addr'; log_format cache '***$time_local ' '-->$upstream_cache_status<-- ' 'Cache-Control: $upstream_http_cache_control ' 'Expires: $upstream_http_expires ' '"$request" ($status) ' '"$http_user_agent" '; access_log /var/log/nginx/origin.nas.access.log main; sendfile on; keepalive_timeout 65; server_tokens off; add_header Upstream-Host $upstream_addr; add_header Cache-Status $upstream_cache_status; client_body_buffer_size 512k; proxy_connect_timeout 5; proxy_read_timeout 60; proxy_send_timeout 5; proxy_buffer_size 16k; proxy_buffers 4 64k; proxy_busy_buffers_size 128k; proxy_temp_file_write_size 128k; upstream setA { server 10.10.30.9:10666; } upstream setB { server 10.10.31.79:10666; } upstream setC { server 10.10.72.109:10666; } upstream setD { server 10.10.72.110:10666; } upstream setE { server 10.10.72.201:10666; } upstream setF { server 10.10.72.127:10666; } upstream setG { server 10.10.72.128:10666; } upstream setH { server 10.10.72.137:10666; } upstream setI { server 10.10.31.238:10666; } upstream setJ { server 10.10.72.134:10666; } upstream setK { server 10.10.72.139:10666; } upstream setL { server 10.10.76.110:10666; } upstream setM { server 10.10.72.141:10666; } upstream setN { server 10.10.72.126:10666; } upstream setO { server 10.10.76.103:10666; } upstream setY { server 10.10.73.90:10666; server 10.10.73.91:10666; } upstream setZ { server 10.10.38.88:10666; server 10.10.38.89:10666; } server { listen haproxy-local:10777; server_name localhost; recursive_error_pages on; proxy_cache nginx_cache; proxy_cache_valid 200 304 12h; expires 1d; #SetAHandler location / { access_log /var/log/nginx/origin.handler.a.proxy_access.log main; # THIS IS IMPORTANT! Turn this on so the error_page handlers will follow a chain. # This should ONLY be under "location /". If it's under http{} or server{}, the scope # is too large and we may get an infinite loop. # **************************************************************************************** # THE STATEMENT ABOVE FAILS TO NOTE THAT: # when included under 'location' the chain only allows up to 2 server after the first one # error_page 404 502 503 504 500 = @SetBHandler; proxy_intercept_errors on; #If there is only one server in "server_set_X", # make sure it's not the same server this nginx is deployed on. Otherwise, you'll get a possible infinite loop. #You'll see the error log complain about 'max descriptors'. proxy_pass http://setA; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #This is different from how long it takes to READ it. For that, use proxy_read_timeout proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; # break; } location @SetBHandler { access_log /var/log/nginx/origin.handler.b.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetCHandler; proxy_pass http://setB; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetCHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetDHandler; proxy_pass http://setC; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetDHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetEHandler; proxy_pass http://setD; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetEHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetFHandler; proxy_pass http://setE; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetFHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetGHandler; proxy_pass http://setF; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetGHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetHHandler; proxy_pass http://setG; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetHHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetIHandler; proxy_pass http://setH; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetIHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetJHandler; proxy_pass http://setI; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetJHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetKHandler; proxy_pass http://setJ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetKHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetLHandler; proxy_pass http://setK; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetLHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetMHandler; proxy_pass http://setL; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetMHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetNHandler; proxy_pass http://setM; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetNHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetOHandler; proxy_pass http://setN; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetOHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetYHandler; proxy_pass http://setO; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetYHandler { access_log /var/log/nginx/origin.handler.c.proxy_access.log main; proxy_intercept_errors on; #If 404, check next server set. If last, it should go to error page. error_page 404 502 503 504 500 = @SetZHandler; proxy_pass http://setY; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; } location @SetZHandler { access_log /var/log/nginx/origin.handler.f.proxy_access.log main; #If 404, check next server set. If last, it should go to error page. #error_page 404 502 503 504 /404.html; #error_page 404 /404.html; proxy_pass http://setZ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; #Last proxy, return whatever it gives proxy_intercept_errors off; } # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } location = /404.html { root html; } location = /crossdomain.xml { access_log /var/log/nginx/origin.handler.crossdomain.proxy_access.log main; root html; } } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231038,231038#msg-231038 From mdounin at mdounin.ru Tue Sep 25 14:04:46 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 25 Sep 2012 18:04:46 +0400 Subject: nginx-1.2.4 Message-ID: <20120925140445.GR40452@mdounin.ru> Изменения в nginx 1.2.4 25.09.2012 *) Исправление: в директиве "limit_req"; ошибка появилась в 1.1.14. Спасибо Charles Chen. *) Исправление: nginx не собирался gcc 4.7 с оптимизацией -O2 если использовался параметр --with-ipv6. *) Исправление: в рабочем процессе мог произойти segmentation fault, если в директиве map в качестве значений использовались переменные. *) Исправление: в рабочем процессе мог произойти segmentation fault при использовании директивы geo с параметром ranges, но без параметра default; ошибка появилась в 0.8.43. Спасибо Zhen Chen и Weibin Yao. *) Исправление: в обработке параметра командной строки -p. *) Исправление: в почтовом прокси-сервере. *) Исправление: незначительных потенциальных ошибок. Спасибо Coverity. *) Исправление: nginx/Windows не собирался с Visual Studio 2005 Express. Спасибо HAYASHI Kentaro. -- Maxim Dounin http://nginx.com/support.html From mdounin at mdounin.ru Tue Sep 25 14:27:43 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 25 Sep 2012 18:27:43 +0400 Subject: recursive_error_pages limited to a chain of 11? In-Reply-To: References: Message-ID: <20120925142742.GT40452@mdounin.ru> Hello! On Tue, Sep 25, 2012 at 09:41:57AM -0400, o456092 at rtrtr.com wrote: > Hi, > > I have configured NGINX as an HTTP Asset locator, where the assets might > found through a series of recursive errors by sequentially a series of > different webservers. The problem that "I think" I have ran into, is that > NGINX's recursive_error_pages is limited to a depth 11 servers, thus 11 > errors 404 or 500 errors- is this a fact? Interesting enough I get a 500 > internal server error when I hit this 11th member in the chain. Yes, see http://nginx.org/r/internal: : There is a limit of 10 internal redirects per request to prevent : request processing cycles that can occur in incorrect : configurations. If this limit is reached, the error 500 (Internal : Server Error) is returned. In such cases, the ?rewrite or internal : redirection cycle? message can be seen in the error log. > I have tested various scenarios and I always seem to be blocked at the 11th > cascading call with a 500 error - I move different servers around in fear > that one of them (upstream servers) had a problem, but it was not specific > to a server, regardless which asset I was going after > http:/srv/file - once it hit 11 in depth. > > Anyone has any ideas of this limitation - or is there something that could > be done? If you *reallly* want to do things that way - you may try hacking src/http/ngx_http_request.h to bump NGX_HTTP_MAX_URI_CHANGES define. But I would recommend rethinking your aproach and e.g. use single upstream block (or couple of upstream blocks) with proxy_next_upstream instead. -- Maxim Dounin http://nginx.com/support.html From nginx-forum at nginx.us Tue Sep 25 14:57:23 2012 From: nginx-forum at nginx.us (o456092@rtrtr.com) Date: Tue, 25 Sep 2012 10:57:23 -0400 Subject: recursive_error_pages limited to a chain of 11? In-Reply-To: <20120925142742.GT40452@mdounin.ru> References: <20120925142742.GT40452@mdounin.ru> Message-ID: <1a794d6e5a993dadde2f50a43fd0ba94.NginxMailingListRussian@forum.nginx.org> Hi Maxim, Thanks for pointing this out. You mentioned using: proxy_next_upstream, rather than my current strategy - would you happen to know if this has any limitations? Will this serve the same purpose as the current configuration that I have? Would it perform, better, worse, or the same? Thank you, James. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231038,231046#msg-231046 From nginx-forum at nginx.us Tue Sep 25 15:30:41 2012 From: nginx-forum at nginx.us (o456092@rtrtr.com) Date: Tue, 25 Sep 2012 11:30:41 -0400 Subject: recursive_error_pages limited to a chain of 11? In-Reply-To: <1a794d6e5a993dadde2f50a43fd0ba94.NginxMailingListRussian@forum.nginx.org> References: <20120925142742.GT40452@mdounin.ru> <1a794d6e5a993dadde2f50a43fd0ba94.NginxMailingListRussian@forum.nginx.org> Message-ID: Hi Maxim, I have just tried - and it works - though more questions raise, how is the round-robin working (though, since I am using cache, I am not too concerned) Also, is there a limit to the number of maximum upstream servers within the block - from the documentation I don't see any indicative of having limits - but this is something I wont have to worry for a long time. nginx.conf #user nobody; worker_processes 5; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; pid /var/run/nginx.origin.pid; events { worker_connections 10000; } http { include /etc/nginx.origin/mime.types; default_type application/octet-stream; recursive_error_pages on; log_format main '-->$upstream_cache_status<-- | ' '$remote_addr - $remote_user [$time_local] "$request" ' '| Upstream_Address "$upstream_addr" ' '| upstream_response_time $upstream_response_time ' '| msec $msec request_time $request_time ' '| OriginServer $upstream_addr'; log_format cache '***$time_local ' '-->$upstream_cache_status<-- ' 'Cache-Control: $upstream_http_cache_control ' 'Expires: $upstream_http_expires ' '"$request" ($status) ' '"$http_user_agent" '; #access_log logs/cache.log cache; access_log /var/log/nginx/origin.nas.access.log main; sendfile on; keepalive_timeout 65; # Hide version information server_tokens off; #headers add_header Upstream-Host $upstream_addr; add_header Cache-Status $upstream_cache_status; #Include proxy config client_body_buffer_size 512k; proxy_connect_timeout 5; proxy_read_timeout 60; proxy_send_timeout 5; proxy_buffer_size 16k; proxy_buffers 4 64k; proxy_busy_buffers_size 128k; proxy_temp_file_write_size 128k; proxy_cache_path /etc/nginx.origin/cache/maincache/cache levels=1:2 keys_zone=nginx_cache:500m inactive=30m max_size=120g; proxy_temp_path /etc/nginx.origin/cache/temp; #proxy_cache_key "$host$request_uri$cookie_user"; proxy_cache_key "$request_uri"; proxy_cache_valid 200 302 60m; proxy_cache_valid 404 0s; upstream setA { server 192.168.30.9:10666; server 192.168.31.79:10666; server 192.168.72.109:10666; server 192.168.72.110:10666; server 192.168.72.201:10666; server 192.168.72.127:10666; server 192.168.72.128:10666; server 192.168.72.137:10666; server 192.168.31.238:10666; server 192.168.72.134:10666; server 192.168.72.139:10666; server 192.168.76.110:10666; server 192.168.72.141:10666; server 192.168.72.126:10666; server 192.168.76.103:10666; server 192.168.73.90:10666; server 192.168.73.91:10666; server 192.168.38.88:10666; server 192.168.38.89:10666; } server { listen haproxy-local:10777; server_name localhost; #This setting has to sit here in order to support # more than recursive_error_pages on; # UNCOMMENT BELOW TO ENABLE CACHE #proxy_cache nginx_cache; proxy_cache_valid 200 304 12h; expires 1d; location / { access_log /var/log/nginx/origin.handler.f.proxy_access.log main; #If 404, check next server set. If last, it should go to error page. #error_page 404 502 503 504 /404.html; #error_page 404 /404.html; proxy_pass http://setA; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 60s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504 http_404; proxy_intercept_errors on; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } location = /404.html { root html; } location = /crossdomain.xml { access_log /var/log/nginx/origin.handler.crossdomain.proxy_access.log main; root html; } } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231038,231047#msg-231047 From mdounin at mdounin.ru Tue Sep 25 15:51:55 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 25 Sep 2012 19:51:55 +0400 Subject: recursive_error_pages limited to a chain of 11? In-Reply-To: <1a794d6e5a993dadde2f50a43fd0ba94.NginxMailingListRussian@forum.nginx.org> References: <20120925142742.GT40452@mdounin.ru> <1a794d6e5a993dadde2f50a43fd0ba94.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120925155154.GU40452@mdounin.ru> Hello! On Tue, Sep 25, 2012 at 10:57:23AM -0400, o456092 at rtrtr.com wrote: > Hi Maxim, > > Thanks for pointing this out. > > You mentioned using: proxy_next_upstream, rather than my current strategy > - would you happen to know if this has any limitations? Will this serve the > same purpose as the current configuration that I have? Would it perform, > better, worse, or the same? This depends on what you actually want to do with your configuration. Single upstream block with proxy_next_upstream e.g. won't allow you to define strict order of servers to query, but will use configured balancer (round-robin by default) instead. It might be seen as a limitation in some cases (if you need strict execution order), but an advantage in others (if order doesn't matter but you actually need load distribution). For a use case very very similar to yours proxy_next_upstream http_404; was specifically implemented. It allows to ask servers in an upstream block for a resource, falling back to other server(s) if the resource isn't found. -- Maxim Dounin http://nginx.com/support.html From mdounin at mdounin.ru Tue Sep 25 16:06:03 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 25 Sep 2012 20:06:03 +0400 Subject: recursive_error_pages limited to a chain of 11? In-Reply-To: References: <20120925142742.GT40452@mdounin.ru> <1a794d6e5a993dadde2f50a43fd0ba94.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120925160603.GV40452@mdounin.ru> Hello! On Tue, Sep 25, 2012 at 11:30:41AM -0400, o456092 at rtrtr.com wrote: > Hi Maxim, > > I have just tried - and it works - though more questions raise, how is > the round-robin working (though, since I am using cache, I am not too It's round-robin. If you want know algorithm details - you may dig into sources or e.g. take a look at this commit which explains latest algorithm: http://trac.nginx.org/nginx/changeset/4622/nginx > concerned) Also, is there a limit to the number of maximum upstream servers > within the block - from the documentation I don't see any indicative of > having limits - but this is something I wont have to worry for a long time. Number of servers is more or less unlimited. Maxim Dounin From nginx-forum at nginx.us Tue Sep 25 18:38:15 2012 From: nginx-forum at nginx.us (o456092@rtrtr.com) Date: Tue, 25 Sep 2012 14:38:15 -0400 Subject: recursive_error_pages limited to a chain of 11? In-Reply-To: <20120925160603.GV40452@mdounin.ru> References: <20120925160603.GV40452@mdounin.ru> Message-ID: Hi Maxim, Thank you for all your help and showing an alternative way to resolve the problem. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231038,231052#msg-231052 From nginx-forum at nginx.us Tue Sep 25 21:21:21 2012 From: nginx-forum at nginx.us (o456092@rtrtr.com) Date: Tue, 25 Sep 2012 17:21:21 -0400 Subject: recursive_error_pages limited to a chain of 11? In-Reply-To: <20120925160603.GV40452@mdounin.ru> References: <20120925160603.GV40452@mdounin.ru> Message-ID: Hi Maxim, Thank you for all your help. James. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231038,231057#msg-231057 From igor at sysoev.ru Wed Sep 26 04:33:23 2012 From: igor at sysoev.ru (Igor Sysoev) Date: Wed, 26 Sep 2012 08:33:23 +0400 Subject: =?UTF-8?Q?Re=3A_nginx_=D0=B8_X-Accel-Redirect?= In-Reply-To: <4be4cf0a76f3b06b8bb49b1b9d625c20.NginxMailingListRussian@forum.nginx.org> References: <4be4cf0a76f3b06b8bb49b1b9d625c20.NginxMailingListRussian@forum.nginx.org> Message-ID: <34C0D8FF-4E69-4EDE-AF0B-78F8A0F7BC6B@sysoev.ru> On Sep 21, 2012, at 11:30 , drook wrote: > Привет. > > Использую nginx 1.2.1 + php-fpm как fcgi. Подскажите, как мне быть: для > интеграции своего сервиса в чужую cdn, когда эта cdn ходит в мой nginx, мне > надо показывать ей X-Accel-Redirect в выдаче. > > Сейчас схема следующая: > > CDN ---> балансировщик(nginx) ---> бэкенд (nginx+php-fpm). > > На балансировщике стоит proxy_ignore_headers X-Accel-Redirect, на бэкендe > proxy_ignore_headers X-Accel-Redirect и fastcgi_ignore_headers > X-Accel-Redirect. Убирание какого-либо заголовка ведет к тому, что тот > nginx, у которого убрали этот заголовок, начинает искать файл из заголовка. > Мне нужно как-то заголовок, который вставляет в выдачу php, донести до CDN. proxy_ignore_headers X-Accel-Redirect; proxy_pass_header X-Accel-Redirect; на обоих nginx'ах. При необходимости поменять на fastcgi_ аналоги. -- Igor Sysoev http://nginx.com/support.html From nginx-forum at nginx.us Wed Sep 26 06:13:47 2012 From: nginx-forum at nginx.us (john2do) Date: Wed, 26 Sep 2012 02:13:47 -0400 Subject: nginx+ php-fpm 5.3.10+ + error_log from fastcgi Message-ID: <4b01193885265bf09e579bdb7c3793eb.NginxMailingListRussian@forum.nginx.org> День добрый, был в пхп такой баг https://bugs.php.net/bug.php?id=61045 в фиксинге, разрабы были видимо под действием чего-то доброго и запилили логгинг ошибок следующим образом: --- In our case, the new function sapi_cgi_log_fastcgi() in fpm_main.c will send any messages (PHP and FPM) back to the fastcgi client no matter what the debug level is. --- соответственно при дефолтовых параметрах энжи, и добром уровне ошибок в пхп это всё прилетает обратно на запрос и в какойто момент энжи начинает, справедливо сыпать в лог подобными сообщениями: [error] 2723#0: *257 upstream sent too big header while reading response header from upstream, client: 192.168.204.139, server: foo.dev.local, request: "GET /main.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "foo.dev.local" вылечить конечно можно и хаком аля fastcgi_buffer 16k; fastcgi_buffer_size 32k; но это до поры до времени. можно как-то ошибки, которые таким возвращает пхп логгировать на уровне энжи в еррор-лог? tcpdump соединения это прекрасно показывает: 11:02:14.086504 IP 127.0.0.1.9000 > 127.0.0.1.49675: P 1:4169(4168) ack 1497 win 559 PHP message: [2012-09-26 11:02:13] Notice: Undefined index: .... ... тут еще всякое... а потом собственно и сам ответ с заголовками: ....m..X-Powered-By: PHP/5.3.17 Set-Cookie: ... Content-type: text/html; charset=windows-1251: .... ну и далее тело ответа... nginx/1.2.3 php-fpm 5.3.17 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231069,231069#msg-231069 From nginx-forum at nginx.us Wed Sep 26 08:21:25 2012 From: nginx-forum at nginx.us (=?UTF-8?Q? =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80=20?= =?UTF-8?Q?=D0=A5=D0=BE=D0=B2=D0=B0=D0=BD=D1=81=D0=BA=D0=B8=D0=B9 ?=) Date: Wed, 26 Sep 2012 04:21:25 -0400 Subject: =?UTF-8?B?0JHRg9GE0LXRgNC40LfQsNGG0LjRjyBNLUpQRUcg0L/QvtGC0L7QutCw?= Message-ID: <292cc0728c5f512e867f0e553923ec59.NginxMailingListRussian@forum.nginx.org> Есть приложение, отдающее M-JPEG поток в реальном времени (как multipart/x-mixed-replace). Работает так: если в буфере сокета есть место, начинает писать туда текущий кадр. Соединение медленное - часть кадров пропускается. При прямом соединении работает нормально. Ставлю перед сервером NGINX. Буферизация отключена (и proxy_buffering off, и X-Accel-Buffering: no). Но всё равно несколько сот Кб (до мегабайта, примерно 10 кадров) где-то буферизуются, и образуют неустранимую задержку. Как это объяснить и как поправить? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231072,231072#msg-231072 From ikuchmin at gmail.com Wed Sep 26 08:33:51 2012 From: ikuchmin at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0JrRg9GH0LzQuNC9?=) Date: Wed, 26 Sep 2012 12:33:51 +0400 Subject: =?UTF-8?B?UmU6IGZ0cDovLyDQuCBuZ2lueCAtINC80L7QttC90L4g0LvQuCDQvdCw0YHRgtGA?= =?UTF-8?B?0L7QuNGC0Ywg0L7RgtC00LDRh9GDINC60L7QvdGC0LXQvdGC0LA/?= In-Reply-To: References: <6f721b04612f625139009243f6b82984.NginxMailingListRussian@forum.nginx.org> <7bd32bc27c55a9733ee81033037dd337.NginxMailingListRussian@forum.nginx.org> Message-ID: А FORWARD в iptables не решает вашу проблему? Или нужен именно протокол ftp? 2012/9/23 Noon es Shadow > ftp + davfs2 + nginx ? > > 23 сентября 2012 г., 21:04 пользователь Ilynikh Denis написал: > > видимо придется писать свой фтп сервер, который будет дергать нгинкс. >> Сохранять ответ во временный файл и уже отдавать его >> >> Отправлено с iPhone >> >> 23.09.2012, в 15:52, "Yahook" написал(а): >> >> > Мне бы подошло решение, когда на входе будет стоять фтп сервер как >> frontend, >> > а файлы будут браться с nginx (результат исполнения файлов, если это >> php). Я >> > понимаю, что по фтп не поддерживается передача параметров и mime type. >> > >> > Т.е. чтобы соответствующий файл запрошенный через фтп запрашивался у >> nginx и >> > срабатывали мод реврайты и т.д. и затем фтп сервер отдавал его клиенту в >> > исполненном виде. >> > >> > Posted at Nginx Forum: >> http://forum.nginx.org/read.php?21,230955,230957#msg-230957 >> > >> > _______________________________________________ >> > nginx-ru mailing list >> > nginx-ru at nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Sep 26 08:51:56 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 26 Sep 2012 12:51:56 +0400 Subject: =?UTF-8?B?UmU6INCR0YPRhNC10YDQuNC30LDRhtC40Y8gTS1KUEVHINC/0L7RgtC+0LrQsA==?= In-Reply-To: <292cc0728c5f512e867f0e553923ec59.NginxMailingListRussian@forum.nginx.org> References: <292cc0728c5f512e867f0e553923ec59.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120926085156.GZ40452@mdounin.ru> Hello! On Wed, Sep 26, 2012 at 04:21:25AM -0400, Александр Хованский wrote: > Есть приложение, отдающее M-JPEG поток в реальном времени (как > multipart/x-mixed-replace). Работает так: если в буфере сокета есть место, > начинает писать туда текущий кадр. Соединение медленное - часть кадров > пропускается. > > При прямом соединении работает нормально. > > Ставлю перед сервером NGINX. Буферизация отключена (и proxy_buffering off, и > X-Accel-Buffering: no). Но всё равно несколько сот Кб (до мегабайта, > примерно 10 кадров) где-то буферизуются, и образуют неустранимую задержку. > > Как это объяснить и как поправить? При "proxy_buffering off" внутри nginx'а есть ровно один буфер, используемый для обработки данных, размер его задаётся с помощью директивы proxy_buffer_size. По умолчанию - 4k (http://nginx.org/r/proxy_buffer_size). Кроме того, на пути от бекенда к клиенту при использовании nginx'а добавляется ещё два буфера сокетов - в nginx на приём от бекенда, и на отправку к клиенту (последний можно ставить из nginx'а с помощью параметра sndbuf директивы listen). В зависимости от настроек операционной системы это может быть много. -- Maxim Dounin http://nginx.com/support.html From nginx-forum at nginx.us Wed Sep 26 10:11:48 2012 From: nginx-forum at nginx.us (sx-sqlx) Date: Wed, 26 Sep 2012 06:11:48 -0400 Subject: Nginx & NTLMv2 Message-ID: <1096a8097e038478f4cc36a3f65c6bd4.NginxMailingListRussian@forum.nginx.org> Использую nginx,как бэкенд к IIS 7.На сайте стоит Windows авторизация(дергаются учетки залогиненого пользователя).Nginx стоит в режиме проксирования без тонких настроек.При запросе на него выдается popup окно авторизации,ввожу в него значения,однако оно появляется снова и снова,и так до бесконечности. Конфиг nginx: worker_processes 4; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; server { listen 1.2.3.4:443; server_name MyReverseProxy; access_log /var/log/nginx/ssl-access.log; ssl on; ssl_protocols SSLv3 TLSv1; ssl_certificate /etc/nginx/conf/cert.pem; ssl_certificate_key /etc/nginx/conf/cert.key; location / { proxy_pass https://1.1.1.1/; proxy_redirect off; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_pass_header Set-Cookie; } } } Буду рад помощи в решении этой проблемы. Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231079,231079#msg-231079 From nginx-forum at nginx.us Wed Sep 26 11:34:38 2012 From: nginx-forum at nginx.us (=?UTF-8?Q? =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80=20?= =?UTF-8?Q?=D0=A5=D0=BE=D0=B2=D0=B0=D0=BD=D1=81=D0=BA=D0=B8=D0=B9 ?=) Date: Wed, 26 Sep 2012 07:34:38 -0400 Subject: =?UTF-8?B?UmU6INCR0YPRhNC10YDQuNC30LDRhtC40Y8gTS1KUEVHINC/0L7RgtC+0LrQsA==?= In-Reply-To: <20120926085156.GZ40452@mdounin.ru> References: <20120926085156.GZ40452@mdounin.ru> Message-ID: Про sndbuf у listen не знал. Поставил 4k - теперь только ~200 Кб "утекает". Буфером сокета на прием от бекенда управлять можно? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231072,231084#msg-231084 From nginx-forum at nginx.us Wed Sep 26 13:23:33 2012 From: nginx-forum at nginx.us (actionless) Date: Wed, 26 Sep 2012 09:23:33 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IG5naW54IHByb3h5ICsgcGVybA==?= In-Reply-To: <9824a1eaadd3cdbcae3955e54e280395.NginxMailingListRussian@forum.nginx.org> References: <9824a1eaadd3cdbcae3955e54e280395.NginxMailingListRussian@forum.nginx.org> Message-ID: Откапываю эту тему. Похожая проблема: location ~ /location1 { perl module_name::func; index index.html; root /var/www; } так перл отрабатывает. А в такой ситуации почему-то до перла ничего не доходит: location ~ /location2 { perl module_name::func; proxy_pass http://127.0.0.1:8000; proxy_set_header X-Forwarded-For $remote_addr; proxy_connect_timeout 600; proxy_read_timeout 600; proxy_send_timeout 600; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,32458,231087#msg-231087 From mdounin at mdounin.ru Wed Sep 26 13:37:19 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 26 Sep 2012 17:37:19 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IG5naW54IHByb3h5ICsgcGVybA==?= In-Reply-To: References: <9824a1eaadd3cdbcae3955e54e280395.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120926133719.GC40452@mdounin.ru> Hello! On Wed, Sep 26, 2012 at 09:23:33AM -0400, actionless wrote: > Откапываю эту тему. Похожая проблема: > location ~ /location1 { > perl module_name::func; > index index.html; > root /var/www; > } > так перл отрабатывает. > > А в такой ситуации почему-то до перла ничего не доходит: > location ~ /location2 { > perl module_name::func; > proxy_pass http://127.0.0.1:8000; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_connect_timeout 600; > proxy_read_timeout 600; > proxy_send_timeout 600; > } Потому что perl и proxy_pass - оба безусловные обработчики запроса, и работать будет только кто-то один. (Надо, наверное, в таких ситуациях ругань добавить при разборе конфига.) Если хочется сходить на бекенд, а потому результат обработать перлом - то можно это сделать, например, с помощью модуля eval Валерия Холодкова: http://grid.net.ru/nginx/eval.ru.html Если хочется сначала скормить запрос перлу, а потом в зависимости от результата идти или не идти на бекенд - то можно это сделать, сконфигурировав для хождения на бекенд отдельный location и в perl'е по необходимости используя функцию $r->internal_redirect(): http://nginx.org/ru/docs/http/ngx_http_perl_module.html#methods Maxim Dounin From mdounin at mdounin.ru Wed Sep 26 13:41:05 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 26 Sep 2012 17:41:05 +0400 Subject: Nginx & NTLMv2 In-Reply-To: <1096a8097e038478f4cc36a3f65c6bd4.NginxMailingListRussian@forum.nginx.org> References: <1096a8097e038478f4cc36a3f65c6bd4.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120926134105.GD40452@mdounin.ru> Hello! On Wed, Sep 26, 2012 at 06:11:48AM -0400, sx-sqlx wrote: > Использую nginx,как бэкенд к IIS 7.На сайте стоит Windows > авторизация(дергаются учетки залогиненого пользователя).Nginx стоит в режиме > проксирования без тонких настроек.При запросе на него выдается popup окно > авторизации,ввожу в него значения,однако оно появляется снова и снова,и так > до бесконечности. [...] > Буду рад помощи в решении этой проблемы. > Спасибо. Решение - выключить на IIS авторизацию NTLM, включить HTTP Basic. Авторизация по NTLM не проксируется. http://en.wikipedia.org/wiki/Integrated_Windows_Authentication -- Maxim Dounin http://nginx.com/support.html From nginx-forum at nginx.us Wed Sep 26 13:53:59 2012 From: nginx-forum at nginx.us (actionless) Date: Wed, 26 Sep 2012 09:53:59 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IG5naW54IHByb3h5ICsgcGVybA==?= In-Reply-To: <20120926133719.GC40452@mdounin.ru> References: <20120926133719.GC40452@mdounin.ru> Message-ID: > Если хочется сначала скормить запрос перлу, а потом в зависимости > от результата идти или не идти на бекенд - то можно это сделать, > сконфигурировав для хождения на бекенд отдельный location и в > perl'е по необходимости используя функцию $r->internal_redirect(): > > http://nginx.org/ru/docs/http/ngx_http_perl_module.html#methods Спасибо за быстрый ответ! Мне нужен именно такой вариант, но $r->internal_redirect(): я уже пробовал - тогда нгинкс мне просто отдавал статику из дефолтной папки. Может, я что-то упустил в самом перл-скрипте? use nginx; sub logger { my $r = shift; return OK if $r->header_only; my $ip = $r->remote_addr; #тут код на перле $r->internal_redirect("/proxy"); return OK; # тут пробовал return DECLINED, но результат тот же } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,32458,231091#msg-231091 From nginx-forum at nginx.us Wed Sep 26 14:15:26 2012 From: nginx-forum at nginx.us (actionless) Date: Wed, 26 Sep 2012 10:15:26 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IG5naW54IHByb3h5ICsgcGVybA==?= In-Reply-To: References: <20120926133719.GC40452@mdounin.ru> Message-ID: <531e1b8688cbd2f93d2f9aac12f9b3b5.NginxMailingListRussian@forum.nginx.org> actionless Wrote: ------------------------------------------------------- > $r->internal_redirect("/proxy"); пробовал, кстати, и именованные локейшены ( типа @proxy) ? результат тот же. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,32458,231092#msg-231092 From mdounin at mdounin.ru Wed Sep 26 14:31:46 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 26 Sep 2012 18:31:46 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IG5naW54IHByb3h5ICsgcGVybA==?= In-Reply-To: References: <20120926133719.GC40452@mdounin.ru> Message-ID: <20120926143145.GE40452@mdounin.ru> Hello! On Wed, Sep 26, 2012 at 09:53:59AM -0400, actionless wrote: > > Если хочется сначала скормить запрос перлу, а потом в зависимости > > от результата идти или не идти на бекенд - то можно это сделать, > > сконфигурировав для хождения на бекенд отдельный location и в > > perl'е по необходимости используя функцию $r->internal_redirect(): > > > > http://nginx.org/ru/docs/http/ngx_http_perl_module.html#methods > > Спасибо за быстрый ответ! > Мне нужен именно такой вариант, но $r->internal_redirect(): я уже пробовал - > тогда нгинкс мне просто отдавал статику из дефолтной папки. > > Может, я что-то упустил в самом перл-скрипте? > > use nginx; > sub logger { > my $r = shift; > return OK if $r->header_only; > my $ip = $r->remote_addr; > > #тут код на перле > > $r->internal_redirect("/proxy"); > return OK; # тут пробовал return DECLINED, но результат тот же > } Должно работать, скорее всего вы просто недоконфигурили конфиг в части описания location'ов. Пример: location /perl { perl ' sub { my $r = shift; $r->internal_redirect("/foo"); return OK; } '; } location /foo { return 200 "i'm /foo\n"; } $ fetch -qo - http://localhost:8888/perl i'm /foo -- Maxim Dounin http://nginx.com/support.html From mdounin at mdounin.ru Wed Sep 26 14:33:14 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 26 Sep 2012 18:33:14 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IG5naW54IHByb3h5ICsgcGVybA==?= In-Reply-To: <531e1b8688cbd2f93d2f9aac12f9b3b5.NginxMailingListRussian@forum.nginx.org> References: <20120926133719.GC40452@mdounin.ru> <531e1b8688cbd2f93d2f9aac12f9b3b5.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120926143314.GF40452@mdounin.ru> Hello! On Wed, Sep 26, 2012 at 10:15:26AM -0400, actionless wrote: > actionless Wrote: > ------------------------------------------------------- > > $r->internal_redirect("/proxy"); > > пробовал, кстати, и именованные локейшены ( типа @proxy) ? результат тот же. В именованные location'ы сейчас из перла перейти нельзя. Наверное, надо доделать. -- Maxim Dounin http://nginx.com/support.html From nginx-forum at nginx.us Wed Sep 26 14:44:53 2012 From: nginx-forum at nginx.us (actionless) Date: Wed, 26 Sep 2012 10:44:53 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IG5naW54IHByb3h5ICsgcGVybA==?= In-Reply-To: <20120926143145.GE40452@mdounin.ru> References: <20120926143145.GE40452@mdounin.ru> Message-ID: <7e176286d89bd9a0dbb4852fd5c5336d.NginxMailingListRussian@forum.nginx.org> >>Должно работать, скорее всего вы просто недоконфигурили конфиг в >>части описания location'ов. Пример: >> >>location /perl { >>perl ' Спасибо! Не обратил внимания в своём конфиге на "=" перед именем локейшена. Кстати, обратил внимание, что в локейшены (вне зависимости от того, internal они или нет) перенаправлять теперь стало нормально, а в именованные почему-то нет, но это уже не так важно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,32458,231096#msg-231096 From nginx-forum at nginx.us Wed Sep 26 14:45:57 2012 From: nginx-forum at nginx.us (actionless) Date: Wed, 26 Sep 2012 10:45:57 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IG5naW54IHByb3h5ICsgcGVybA==?= In-Reply-To: <7e176286d89bd9a0dbb4852fd5c5336d.NginxMailingListRussian@forum.nginx.org> References: <20120926143145.GE40452@mdounin.ru> <7e176286d89bd9a0dbb4852fd5c5336d.NginxMailingListRussian@forum.nginx.org> Message-ID: <7d9f1af1157e058bc2c204cb26bfa3e6.NginxMailingListRussian@forum.nginx.org> > Кстати, обратил внимание, что в локейшены (вне зависимости от того, > internal они или нет) перенаправлять теперь стало нормально, а в > именованные почему-то нет, но это уже не так важно. не заметил вашего ответа, Максим, в другой ветке этой темы на этот вопрос, посыпаю голову пеплом. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,32458,231097#msg-231097 From nginx-forum at nginx.us Wed Sep 26 15:10:35 2012 From: nginx-forum at nginx.us (justcyber) Date: Wed, 26 Sep 2012 11:10:35 -0400 Subject: =?UTF-8?B?0J/QvtC00LTQtdC70LrQsCBVc2VyLUFnZW50?= Message-ID: <76f30028bb852b7cc57e3146cb75eab4.NginxMailingListRussian@forum.nginx.org> Есть конструцкия вида: location / { proxy_pass http://127.0.0.2:81; proxy_redirect http://127.0.0.2:81/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; Задача задать определенный User-Agent с которым оно будет ходить к 127.0.0.2:81 Как это можно зделать? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231098,231098#msg-231098 From boris.t.ru at mail.ru Wed Sep 26 15:46:41 2012 From: boris.t.ru at mail.ru (Talovikov Boris Aleksandrovich) Date: Wed, 26 Sep 2012 21:46:41 +0600 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXQu9C60LAgVXNlci1BZ2VudA==?= In-Reply-To: <76f30028bb852b7cc57e3146cb75eab4.NginxMailingListRussian@forum.nginx.org> References: <76f30028bb852b7cc57e3146cb75eab4.NginxMailingListRussian@forum.nginx.org> Message-ID: <50632361.4080609@mail.ru> 26.09.2012 21:10, justcyber пишет: > Есть конструцкия вида: > > > location / { > proxy_pass http://127.0.0.2:81; > proxy_redirect http://127.0.0.2:81/ /; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Real-IP $remote_addr; > > > Задача задать определенный User-Agent с которым оно будет ходить к > 127.0.0.2:81 > Как это можно зделать? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231098,231098#msg-231098 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > proxy_set_header User-Agent Wget ??? From mdounin at mdounin.ru Wed Sep 26 16:19:02 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 26 Sep 2012 20:19:02 +0400 Subject: nginx+ php-fpm 5.3.10+ + error_log from fastcgi In-Reply-To: <4b01193885265bf09e579bdb7c3793eb.NginxMailingListRussian@forum.nginx.org> References: <4b01193885265bf09e579bdb7c3793eb.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120926161902.GI40452@mdounin.ru> Hello! On Wed, Sep 26, 2012 at 02:13:47AM -0400, john2do wrote: > День добрый, > был в пхп такой баг https://bugs.php.net/bug.php?id=61045 > в фиксинге, разрабы были видимо под действием чего-то доброго и запилили > логгинг ошибок следующим образом: > > --- > In our case, the new function sapi_cgi_log_fastcgi() in fpm_main.c will > send any messages (PHP and FPM) back to the fastcgi client no matter what > the > debug level is. > --- Т.е. вообще всё, без фильтрации по маске error_reporting? Звучит интригующе. Новый баг ещё не открыли, нет? > соответственно при дефолтовых параметрах энжи, и добром уровне ошибок в пхп > это всё прилетает обратно на запрос и в какойто момент энжи начинает, > справедливо сыпать в лог подобными сообщениями: > > [error] 2723#0: *257 upstream sent too big header while reading response > header from upstream, client: 192.168.204.139, server: foo.dev.local, > request: "GET /main.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", > host: "foo.dev.local" > > вылечить конечно можно и хаком аля > fastcgi_buffer 16k; > fastcgi_buffer_size 32k; > но это до поры до времени. > > можно как-то ошибки, которые таким возвращает пхп логгировать на уровне энжи > в еррор-лог? Они логгируются на уровне error: 2012/09/26 19:59:09 [error] 19324#0: *9 FastCGI sent in stderr: "sample stderr text" while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET /stderr HTTP/1.0", upstream: "fastcgi://127.0.0.1:8081", host: "localhost" Если, конечно, ребята из php всё сделали правильно. -- Maxim Dounin http://nginx.com/support.html From kav at karagodov.name Wed Sep 26 19:29:47 2012 From: kav at karagodov.name (Alexey V. Karagodov) Date: Wed, 26 Sep 2012 23:29:47 +0400 Subject: =?UTF-8?B?UmU6IGZ0cDovLyDQuCBuZ2lueCAtINC80L7QttC90L4g0LvQuCDQvdCw0YHRgtGA?= =?UTF-8?B?0L7QuNGC0Ywg0L7RgtC00LDRh9GDINC60L7QvdGC0LXQvdGC0LA/?= In-Reply-To: References: <6f721b04612f625139009243f6b82984.NginxMailingListRussian@forum.nginx.org> <7bd32bc27c55a9733ee81033037dd337.NginxMailingListRussian@forum.nginx.org> Message-ID: <54B99E6E-1838-454D-87D0-4AC0B0FB8F40@karagodov.name> судя по запросу, нужно извращение в виде фтп-ту-ввв или наоборот прокси ... "мьсе знает толк ..." блин On 26.09.2012, at 12:33, Илья Кучмин wrote: > А FORWARD в iptables не решает вашу проблему? Или нужен именно протокол ftp? > > 2012/9/23 Noon es Shadow > ftp + davfs2 + nginx ? > > 23 сентября 2012 г., 21:04 пользователь Ilynikh Denis написал: > > видимо придется писать свой фтп сервер, который будет дергать нгинкс. Сохранять ответ во временный файл и уже отдавать его > > Отправлено с iPhone > > 23.09.2012, в 15:52, "Yahook" написал(а): > > > Мне бы подошло решение, когда на входе будет стоять фтп сервер как frontend, > > а файлы будут браться с nginx (результат исполнения файлов, если это php). Я > > понимаю, что по фтп не поддерживается передача параметров и mime type. > > > > Т.е. чтобы соответствующий файл запрошенный через фтп запрашивался у nginx и > > срабатывали мод реврайты и т.д. и затем фтп сервер отдавал его клиенту в > > исполненном виде. > > > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,230955,230957#msg-230957 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Sep 27 04:04:00 2012 From: nginx-forum at nginx.us (john2do) Date: Thu, 27 Sep 2012 00:04:00 -0400 Subject: nginx+ php-fpm 5.3.10+ + error_log from fastcgi In-Reply-To: <20120926161902.GI40452@mdounin.ru> References: <20120926161902.GI40452@mdounin.ru> Message-ID: <4be2cae3a6012ed11056fee5c735996f.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: ------------------------------------------------------- > Т.е. вообще всё, без фильтрации по маске error_reporting? Звучит > интригующе. Новый баг ещё не открыли, нет? по коммитам - похоже на то. поведение в принципе не самое плохое) > Они логгируются на уровне error: > > 2012/09/26 19:59:09 [error] 19324#0: *9 FastCGI sent in stderr: > "sample stderr text" while reading response header from upstream, > client: 127.0.0.1, server: localhost, request: "GET /stderr HTTP/1.0", > upstream: "fastcgi://127.0.0.1:8081", host: "localhost" > > Если, конечно, ребята из php всё сделали правильно. да, словили таки. спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231069,231119#msg-231119 From nginx-forum at nginx.us Thu Sep 27 04:33:12 2012 From: nginx-forum at nginx.us (=?UTF-8?Q? =D0=9A=D0=BE=D0=BD=D1=81=D1=82=D0=B0=D0=BD=D1=82=D0=B8=D0?= =?UTF-8?Q?=BD=20=D0=A1=D1=82=D1=80=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0?= =?UTF-8?Q?=BA=D0=BE=D0=B2 ?=) Date: Thu, 27 Sep 2012 00:33:12 -0400 Subject: =?UTF-8?B?bmdpbngg0LfQsCBuYXQsINGB0LDQvCDQvdC+0LLQuNGH0L7Quiwg0L3QtSDQv9C+?= =?UTF-8?B?0L3QuNC80LDRjg==?= Message-ID: <35b21201b70d07bc68b8a0915ec954ad.NginxMailingListRussian@forum.nginx.org> Для обучения людей через интернет хотим использовать BigBlueButton. Сервер установили, внутри локалки 192.168.0.X всё хорошо. На внешний ip в циске сделали проброс, типа 1.1.1.1:55555 -> 192.168.0.100:80, на 80 порту на внешнем ip у нас другая служба. В директиву server_name прописал внутреннее имя, серый ip и внешнее имя и могу зайти на дефолтную страничку. Но при попытке залогиниться в чат-комнату меня перебрасывает на http://192.168.0.100/blahblahblah и поскольку в интернет серые адреса не транслируются то всё отваливается. Умом понимаю что надо заставить nginx как-то ретранслировать пакетики чтобы он выступал как посредник но как это сделать не понимаю. Почитал пару страниц тем, вроде всё про это же но не совсем, помогите Конфиг nginx такой server { listen 80; server_name bbb.aaa.int 192.168.0.100 bbb; access_log /var/log/nginx/bigbluebutton.access.log; # Handle RTMPT (RTMP Tunneling). Forwards requests # to Red5 on port 5080 location ~ (/open/|/close/|/idle/|/send/) { proxy_pass http://127.0.0.1:5080; proxy_redirect off; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffering off; } # Handle desktop sharing tunneling. Forwards # requests to Red5 on port 5080. location /deskshare { proxy_pass http://127.0.0.1:5080; proxy_redirect default; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; include fastcgi_params; } # BigBlueButton landing page. location / { root /var/www/bigbluebutton-default; index index.html index.htm; expires 1m; } # Include specific rules for record and playback include /etc/bigbluebutton/nginx/*.nginx; #error_page 404 /404.html; # Redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root /var/www/nginx-default; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231120,231120#msg-231120 From onokonem at gmail.com Thu Sep 27 05:50:23 2012 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 27 Sep 2012 09:50:23 +0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LAgbmF0LCDRgdCw0Lwg0L3QvtCy0LjRh9C+0LosINC90LUg?= =?UTF-8?B?0L/QvtC90LjQvNCw0Y4=?= In-Reply-To: <35b21201b70d07bc68b8a0915ec954ad.NginxMailingListRussian@forum.nginx.org> References: <35b21201b70d07bc68b8a0915ec954ad.NginxMailingListRussian@forum.nginx.org> Message-ID: > Умом понимаю что надо заставить nginx > как-то ретранслировать пакетики чтобы он выступал как посредник но как это > сделать не понимаю. проблема не на уровне "пакетиков", а на уровне протокола http. а, может, и выше - если "пробрасывает" не http-редиректом. для начала попробуйте добавить в конфигурацию прокси proxy_redirect http://127.0.0.1:5080/ $scheme://1.1.1.1:55555/; From igor at sysoev.ru Thu Sep 27 07:41:52 2012 From: igor at sysoev.ru (Igor Sysoev) Date: Thu, 27 Sep 2012 11:41:52 +0400 Subject: =?UTF-8?B?UmU6INCR0YPRhNC10YDQuNC30LDRhtC40Y8gTS1KUEVHINC/0L7RgtC+0LrQsA==?= In-Reply-To: References: <20120926085156.GZ40452@mdounin.ru> Message-ID: On Sep 26, 2012, at 15:34 , Александр Хованский wrote: > Про sndbuf у listen не знал. Поставил 4k - теперь только ~200 Кб "утекает". > Буфером сокета на прием от бекенда управлять можно? На уровне nginx'а - нет. -- Igor Sysoev http://nginx.com/support.html From nginx-forum at nginx.us Thu Sep 27 11:01:34 2012 From: nginx-forum at nginx.us (sx-sqlx) Date: Thu, 27 Sep 2012 07:01:34 -0400 Subject: Nginx & NTLMv2 In-Reply-To: <20120926134105.GD40452@mdounin.ru> References: <20120926134105.GD40452@mdounin.ru> Message-ID: <45950a44be2888ab3bfa7962c2959c34.NginxMailingListRussian@forum.nginx.org> А я так не думаю. 1.Есть некий модуль http-gsspi-auth-nginx-module(https://github.com/joekhoobyar/http-gsspi-auth-nginx-module) 2.В windows proxy,например forefront tmg есть такая возможность. 3.Такая же возможность есть у apache(http://www.opennet.ru/openforum/vsluhforumID8/7370.html) >>Решение - выключить на IIS авторизацию NTLM, включить HTTP Basic. Авторизация по NTLM не проксируется. Если бы мне нужна была basic авторизация,я так бы и сделал,но нет. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231079,231138#msg-231138 From mdounin at mdounin.ru Thu Sep 27 11:22:14 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 27 Sep 2012 15:22:14 +0400 Subject: Nginx & NTLMv2 In-Reply-To: <45950a44be2888ab3bfa7962c2959c34.NginxMailingListRussian@forum.nginx.org> References: <20120926134105.GD40452@mdounin.ru> <45950a44be2888ab3bfa7962c2959c34.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120927112213.GP40452@mdounin.ru> Hello! On Thu, Sep 27, 2012 at 07:01:34AM -0400, sx-sqlx wrote: > А я так не думаю. Ссылку на википедию я привлёл, она в свою очередь ссылается на документацию от компании Microsoft, где чёрным по белому написано: : Integrated Windows authentication does not work over HTTP proxy : connections. С технической точки зрения там проблема очень простая: оно требует, чтобы соединение с сервером было постоянным, и относилось к одному конкретному клиенту. И это не то, что обеспечивается при проксировании в рамках протокола HTTP. > 1.Есть некий модуль > http-gsspi-auth-nginx-module(https://github.com/joekhoobyar/http-gsspi-auth-nginx-module) Этот модуль не имеет отношения к проксированию. > 2.В windows proxy,например forefront tmg есть такая возможность. Допускаю, что если очень захотеть, то можно поднять тунель от клиента до бекенда, по которому оно работать будет. Но это не http proxy ни разу. Впрочем, prooflink'а я как-то не вижу, что отдельно смешно с учётом того, что для двух не имеющих отношения к проблеме пунктов вы ссылки привели. :) > 3.Такая же возможность есть у > apache(http://www.opennet.ru/openforum/vsluhforumID8/7370.html) И этот тред - тоже не имеет отношения к проксированию. > > Решение - выключить на IIS авторизацию NTLM, включить HTTP Basic. > > Авторизация по NTLM не проксируется. > > Если бы мне нужна была basic авторизация,я так бы и сделал,но нет. См. выше. Maxim Dounin From nginx-forum at nginx.us Thu Sep 27 15:21:19 2012 From: nginx-forum at nginx.us (sx-sqlx) Date: Thu, 27 Sep 2012 11:21:19 -0400 Subject: Nginx & NTLMv2 In-Reply-To: <20120927112213.GP40452@mdounin.ru> References: <20120927112213.GP40452@mdounin.ru> Message-ID: <1e80d6d620a6c219014fd71311eaeb20.NginxMailingListRussian@forum.nginx.org> Сделал на апаче,все работает. http://dokuwiki.ru/auth/ad Раздел NTLM on Apache (Linux) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231079,231147#msg-231147 From mdounin at mdounin.ru Thu Sep 27 15:57:47 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 27 Sep 2012 19:57:47 +0400 Subject: Nginx & NTLMv2 In-Reply-To: <1e80d6d620a6c219014fd71311eaeb20.NginxMailingListRussian@forum.nginx.org> References: <20120927112213.GP40452@mdounin.ru> <1e80d6d620a6c219014fd71311eaeb20.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120927155747.GU40452@mdounin.ru> Hello! On Thu, Sep 27, 2012 at 11:21:19AM -0400, sx-sqlx wrote: > Сделал на апаче,все работает. > http://dokuwiki.ru/auth/ad > Раздел NTLM on Apache (Linux) Это раздел про то, как сделать NTLM-авторизацию на собственно Apache. Проксирование вы, видимо, просто исключили, выкинув IIS? -- Maxim Dounin http://nginx.com/support.html From panfilov at sports.ru Thu Sep 27 16:32:34 2012 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Thu, 27 Sep 2012 20:32:34 +0400 Subject: =?UTF-8?B?0JLQvtC/0YDQvtGBINC/0L4g0YDQtdCw0LvQuNC30LDRhtC40Lgg0LrQtdGI0Lg=?= =?UTF-8?B?0YDQvtCy0LDQvdC40Y8g0L3QsCBDRE4=?= Message-ID: Доброго времени суток! Не подскажете ли решение на nginx для следующей задачи: необходимо реализовать кэширование на CDN динамических запросов. Сложность в том, что надо как-то понимать с каким ключом (учитывать ли sid) кешировать. Какие-то запросы уникальны для пользователей, какие-то общие. Текущую архитектуру сайта (URL) не переделать, и хочется обойтись без "карты сайта" (какие location уникальны для пользователя, а какие нет). Может есть какое-нибудь универсальное решение, например, на основе заголовков Vary? З.Ы. На CDN и Frontend стоит nginx. -- Панфилов Михаил Старший системный администратор www.sports.ru + 7 903 578 4067 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Sep 27 17:06:21 2012 From: nginx-forum at nginx.us (sx-sqlx) Date: Thu, 27 Sep 2012 13:06:21 -0400 Subject: Nginx & NTLMv2 In-Reply-To: <20120927155747.GU40452@mdounin.ru> References: <20120927155747.GU40452@mdounin.ru> Message-ID: <6200bd34df6be2165bd12e206a0d2c95.NginxMailingListRussian@forum.nginx.org> Не не,все намного проще.Апач поддерживает проксирование запросов с удержанием соединения. Дело было в том,что до этого ни nginx ни apache не понимали Ntlmv2 хэши.с установкой модуля собственно начали. Выложу на всякий случай конфиг апача. DocumentRoot "/var/www/123" ServerName 1.2.3.4:443 ServerAdmin support at mycompany.com DirectoryIndex index.html index.php SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /etc/apache2/ssl/server.crt SSLCertificateKeyFile /etc/apache2/ssl/server.key SSLProxyEngine on RewriteEngine On RewriteRule ^/$ /123 [L,R] RequestHeader set Front-End-Https On ProxyRequests On ProxyPreserveHost On ProxyVia full Order deny,allow Allow from all ProxyPass / https://2.3.4.5/ ProxyPassReverse / https://site.local/ Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231079,231155#msg-231155 From nginx-forum at nginx.us Thu Sep 27 17:08:41 2012 From: nginx-forum at nginx.us (sx-sqlx) Date: Thu, 27 Sep 2012 13:08:41 -0400 Subject: Nginx & NTLMv2 In-Reply-To: <6200bd34df6be2165bd12e206a0d2c95.NginxMailingListRussian@forum.nginx.org> References: <20120927155747.GU40452@mdounin.ru> <6200bd34df6be2165bd12e206a0d2c95.NginxMailingListRussian@forum.nginx.org> Message-ID: <34e0aca1a7c93ade389aba42752baa15.NginxMailingListRussian@forum.nginx.org> и proxy.conf AddDefaultCharset off Order deny,allow Allow from all #Allow from .example.com Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231079,231156#msg-231156 From mdounin at mdounin.ru Thu Sep 27 17:15:38 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 27 Sep 2012 21:15:38 +0400 Subject: Nginx & NTLMv2 In-Reply-To: <6200bd34df6be2165bd12e206a0d2c95.NginxMailingListRussian@forum.nginx.org> References: <20120927155747.GU40452@mdounin.ru> <6200bd34df6be2165bd12e206a0d2c95.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120927171538.GY40452@mdounin.ru> Hello! On Thu, Sep 27, 2012 at 01:06:21PM -0400, sx-sqlx wrote: > Не не,все намного проще.Апач поддерживает проксирование запросов с > удержанием соединения. Он, на самом деле, не поддерживает - см. тут: https://issues.apache.org/bugzilla/show_bug.cgi?id=39673 При некоторых условиях оно может пытаться работать (так же, как e.g. через nginx при использовании upstream keepalive), но это не гарантируется. [...] -- Maxim Dounin http://nginx.com/support.html From nginx-forum at nginx.us Thu Sep 27 21:33:36 2012 From: nginx-forum at nginx.us (abasive) Date: Thu, 27 Sep 2012 17:33:36 -0400 Subject: =?UTF-8?B?0JrQsNC60L7QuSDRhNC+0YDQvNCw0YIg0LLQuNC00LXQviDQuNGB0L/QvtC70Yw=?= =?UTF-8?B?0LfQvtCy0LDRgtGMINC00LvRjyDQvtGC0LTQsNGH0Lgg0YEgbmdpbng=?= Message-ID: <10a8591923877b4ddb512a7e9530a0fe.NginxMailingListRussian@forum.nginx.org> Уважаемые форумчане не подскажете для видеостриминга что лучше использовать mp4 или flv, можно узнать плючсы и минусы этих форматов? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231166,231166#msg-231166 From hell-for-yahoo at umail.ru Thu Sep 27 23:44:00 2012 From: hell-for-yahoo at umail.ru (Andrey Repin) Date: Fri, 28 Sep 2012 03:44:00 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQutC+0Lkg0YTQvtGA0LzQsNGCINCy0LjQtNC10L4g0LjRgdC/0L4=?= =?UTF-8?B?0LvRjNC30L7QstCw0YLRjCDQtNC70Y8g0L7RgtC00LDRh9C4INGBIG5naW54?= In-Reply-To: <10a8591923877b4ddb512a7e9530a0fe.NginxMailingListRussian@forum.nginx.org> References: <10a8591923877b4ddb512a7e9530a0fe.NginxMailingListRussian@forum.nginx.org> Message-ID: <979283609.20120928034400@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) abasive! a> Уважаемые форумчане не подскажете для видеостриминга что лучше использовать a> mp4 или flv, можно узнать плючсы и минусы этих форматов? На сколько я понимаю, тут вопрос больше не в том, что, а в том, для кого... -- С уважением Andrey Repin (hell-for-yahoo at umail.ru) пятница, 28.09.2012, <03:43> From nginx-forum at nginx.us Fri Sep 28 01:21:42 2012 From: nginx-forum at nginx.us (=?UTF-8?Q? =D0=9A=D0=BE=D0=BD=D1=81=D1=82=D0=B0=D0=BD=D1=82=D0=B8=D0?= =?UTF-8?Q?=BD=20=D0=A1=D1=82=D1=80=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0?= =?UTF-8?Q?=BA=D0=BE=D0=B2 ?=) Date: Thu, 27 Sep 2012 21:21:42 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LAgbmF0LCDRgdCw0Lwg0L3QvtCy0LjRh9C+0LosINC90LUg?= =?UTF-8?B?0L/QvtC90LjQvNCw0Y4=?= In-Reply-To: References: Message-ID: А в какой секции, или в обоих? Хотя попробовал оба варианта и всё равно в итоге редиректит на 192.168.... > для начала попробуйте добавить в конфигурацию прокси > proxy_redirect http://127.0.0.1:5080/ $scheme://1.1.1.1:55555/; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231120,231170#msg-231170 From nginx-forum at nginx.us Fri Sep 28 04:13:28 2012 From: nginx-forum at nginx.us (=?UTF-8?Q? =D0=9A=D0=BE=D0=BD=D1=81=D1=82=D0=B0=D0=BD=D1=82=D0=B8=D0?= =?UTF-8?Q?=BD=20=D0=A1=D1=82=D1=80=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0?= =?UTF-8?Q?=BA=D0=BE=D0=B2 ?=) Date: Fri, 28 Sep 2012 00:13:28 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INC30LAgbmF0LCDRgdCw0Lwg0L3QvtCy0LjRh9C+0LosINC90LUg?= =?UTF-8?B?0L/QvtC90LjQvNCw0Y4=?= In-Reply-To: <35b21201b70d07bc68b8a0915ec954ad.NginxMailingListRussian@forum.nginx.org> References: <35b21201b70d07bc68b8a0915ec954ad.NginxMailingListRussian@forum.nginx.org> Message-ID: так, вопросы снимаю, там оказывается в софте ещё куча настроек, и пример подобный нашёл, проблема не в nginx Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231120,231171#msg-231171 From igor at sysoev.ru Fri Sep 28 08:12:22 2012 From: igor at sysoev.ru (Igor Sysoev) Date: Fri, 28 Sep 2012 12:12:22 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INGA0LXQsNC70LjQt9Cw0YbQuNC4INC60LU=?= =?UTF-8?B?0YjQuNGA0L7QstCw0L3QuNGPINC90LAgQ0RO?= In-Reply-To: References: Message-ID: <20120928081222.GA9259@nginx.com> On Thu, Sep 27, 2012 at 08:32:34PM +0400, Михаил Панфилов wrote: > Доброго времени суток! > > Не подскажете ли решение на nginx для следующей задачи: > > необходимо реализовать кэширование на CDN динамических запросов. Сложность > в том, что надо как-то понимать с каким ключом (учитывать ли sid) > кешировать. Какие-то запросы уникальны для пользователей, какие-то общие. > Текущую архитектуру сайта (URL) не переделать, и хочется обойтись без > "карты сайта" (какие location уникальны для пользователя, а какие нет). > Может есть какое-нибудь универсальное решение, например, на основе > заголовков Vary? Для уникальных страниц выдавать бэкендом "Cache-Control: private". > З.Ы. На CDN и Frontend стоит nginx. -- Igor Sysoev http://nginx.com/support.html From nginx-forum at nginx.us Fri Sep 28 08:30:26 2012 From: nginx-forum at nginx.us (sx-sqlx) Date: Fri, 28 Sep 2012 04:30:26 -0400 Subject: Nginx & NTLMv2 In-Reply-To: <20120927171538.GY40452@mdounin.ru> References: <20120927171538.GY40452@mdounin.ru> Message-ID: Дата 2006-05-29 вам не на что не намекает? =) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231079,231176#msg-231176 From uncleandyv at gmail.com Fri Sep 28 08:30:17 2012 From: uncleandyv at gmail.com (Andrey Velikoredchanin) Date: Fri, 28 Sep 2012 12:30:17 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IG5naW54IHByb3h5ICsgcGVybA==?= In-Reply-To: <20120926133719.GC40452@mdounin.ru> References: <9824a1eaadd3cdbcae3955e54e280395.NginxMailingListRussian@forum.nginx.org> <20120926133719.GC40452@mdounin.ru> Message-ID: 26 сентября 2012 г., 17:37 пользователь Maxim Dounin написал: > Потому что perl и proxy_pass - оба безусловные обработчики > запроса, и работать будет только кто-то один. (Надо, наверное, в > таких ситуациях ругань добавить при разборе конфига.) > Интересно. А в старых версиях nginx было не так? Потому, что я отлично помню что именно на proxy_pass у меня работал обработчикх хидеров на perl. -------------- next part -------------- An HTML attachment was scrubbed... URL: From panfilov at sports.ru Fri Sep 28 08:32:37 2012 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Fri, 28 Sep 2012 12:32:37 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INGA0LXQsNC70LjQt9Cw0YbQuNC4INC60LU=?= =?UTF-8?B?0YjQuNGA0L7QstCw0L3QuNGPINC90LAgQ0RO?= In-Reply-To: <20120928081222.GA9259@nginx.com> References: <20120928081222.GA9259@nginx.com> Message-ID: А будет ли при этом ответ кэшироваться для пользователя? Какой при этом нужно использовать ключ кэширования на CDN? 28 сентября 2012 г., 12:12 пользователь Igor Sysoev написал: > On Thu, Sep 27, 2012 at 08:32:34PM +0400, Михаил Панфилов wrote: > > Доброго времени суток! > > > > Не подскажете ли решение на nginx для следующей задачи: > > > > необходимо реализовать кэширование на CDN динамических запросов. > Сложность > > в том, что надо как-то понимать с каким ключом (учитывать ли sid) > > кешировать. Какие-то запросы уникальны для пользователей, какие-то общие. > > Текущую архитектуру сайта (URL) не переделать, и хочется обойтись без > > "карты сайта" (какие location уникальны для пользователя, а какие нет). > > Может есть какое-нибудь универсальное решение, например, на основе > > заголовков Vary? > > Для уникальных страниц выдавать бэкендом "Cache-Control: private". > > > З.Ы. На CDN и Frontend стоит nginx. > > > -- > Igor Sysoev > http://nginx.com/support.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Панфилов Михаил Старший системный администратор www.sports.ru + 7 903 578 4067 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Fri Sep 28 08:42:41 2012 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Fri, 28 Sep 2012 14:42:41 +0600 Subject: Nginx & NTLMv2 In-Reply-To: <45950a44be2888ab3bfa7962c2959c34.NginxMailingListRussian@forum.nginx.org> References: <20120926134105.GD40452@mdounin.ru> <45950a44be2888ab3bfa7962c2959c34.NginxMailingListRussian@forum.nginx.org> Message-ID: то, что вы хотите, называется "session affinity". если посмотреть, как работает NTLM, то на СЕССИЮ выдается один раз WWW-Authenticate в самом начале и дальнейшие запросы осуществляются в предположении, что сессия аутентифицирована. т.е. все запросы от клиента должны попадать на конкретный бекенд в рамках одного и того же tcp-соединения между nginx-ом и бекендом. nginx не так давно начал поддерживать keep-alive до бекенда, но механизм немного другой, выделяется пул соединений и при проксировании запроса выбирается соединение из пула. из коробки "session affinity" есть, пожалуй, только в Forefront TMG. ну или вам на http://nginx.com/support.html :-) 27 сентября 2012 г., 17:01 пользователь sx-sqlx написал: > А я так не думаю. > 1.Есть некий модуль > http-gsspi-auth-nginx-module( > https://github.com/joekhoobyar/http-gsspi-auth-nginx-module) > 2.В windows proxy,например forefront tmg есть такая возможность. > 3.Такая же возможность есть у > apache(http://www.opennet.ru/openforum/vsluhforumID8/7370.html) > > >>Решение - выключить на IIS авторизацию NTLM, включить HTTP Basic. > Авторизация по NTLM не проксируется. > Если бы мне нужна была basic авторизация,я так бы и сделал,но нет. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,231079,231138#msg-231138 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor at sysoev.ru Fri Sep 28 08:56:33 2012 From: igor at sysoev.ru (Igor Sysoev) Date: Fri, 28 Sep 2012 12:56:33 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INGA0LXQsNC70LjQt9Cw0YbQuNC4INC60LU=?= =?UTF-8?B?0YjQuNGA0L7QstCw0L3QuNGPINC90LAgQ0RO?= In-Reply-To: References: <20120928081222.GA9259@nginx.com> Message-ID: <027F2025-A9F5-461C-89D7-0820D8EC3AC7@sysoev.ru> On Sep 28, 2012, at 12:32 , Михаил Панфилов wrote: > А будет ли при этом ответ кэшироваться для пользователя? Да, private разрешает кэширование только клиентом. > Какой при этом нужно использовать ключ кэширования на CDN? Стандартный. nginx будет искать ответы в кэше по ключу, но поскольку ответы с private не будет кэшироваться, то их там и не окажется. -- Igor Sysoev http://nginx.com/support.html > 28 сентября 2012 г., 12:12 пользователь Igor Sysoev написал: > On Thu, Sep 27, 2012 at 08:32:34PM +0400, Михаил Панфилов wrote: > > Доброго времени суток! > > > > Не подскажете ли решение на nginx для следующей задачи: > > > > необходимо реализовать кэширование на CDN динамических запросов. Сложность > > в том, что надо как-то понимать с каким ключом (учитывать ли sid) > > кешировать. Какие-то запросы уникальны для пользователей, какие-то общие. > > Текущую архитектуру сайта (URL) не переделать, и хочется обойтись без > > "карты сайта" (какие location уникальны для пользователя, а какие нет). > > Может есть какое-нибудь универсальное решение, например, на основе > > заголовков Vary? > > Для уникальных страниц выдавать бэкендом "Cache-Control: private". > > > З.Ы. На CDN и Frontend стоит nginx. > > > -- > Igor Sysoev > http://nginx.com/support.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From boris.t.ru at mail.ru Fri Sep 28 10:47:14 2012 From: boris.t.ru at mail.ru (Talovikov Boris Aleksandrovich) Date: Fri, 28 Sep 2012 16:47:14 +0600 Subject: Nginx & NTLMv2 In-Reply-To: References: <20120927171538.GY40452@mdounin.ru> Message-ID: <50658032.70201@mail.ru> 28.09.2012 14:30, sx-sqlx пишет: > Дата 2006-05-29 вам не на что не намекает? =) > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231079,231176#msg-231176 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > А вам статус ничего не говорит? Status: NEW Смотрите статус тикета, а не дату! Это баг до сих пор не решили, либо не хотят, либо некому заниматься, /etc ... From mdounin at mdounin.ru Fri Sep 28 10:49:14 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 28 Sep 2012 14:49:14 +0400 Subject: Nginx & NTLMv2 In-Reply-To: References: <20120927171538.GY40452@mdounin.ru> Message-ID: <20120928104913.GD40452@mdounin.ru> Hello! On Fri, Sep 28, 2012 at 04:30:26AM -0400, sx-sqlx wrote: > Дата 2006-05-29 вам не на что не намекает? =) Намекает - что с тех пор ничего не изменилось, тикет как висел открытым, так и висит. Впрочем, если вас всё устраивает - я рад за вас. Просто имейте ввиду, что работоспособность имеющейся у вас конструкции ни кем и ни чем не гарантируется. -- Maxim Dounin http://nginx.com/support.html From alexey.bobok at gmail.com Fri Sep 28 12:45:54 2012 From: alexey.bobok at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JHQvtCx0L7Qug==?=) Date: Fri, 28 Sep 2012 15:45:54 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQutC+0Lkg0YTQvtGA0LzQsNGCINCy0LjQtNC10L4g0LjRgdC/0L4=?= =?UTF-8?B?0LvRjNC30L7QstCw0YLRjCDQtNC70Y8g0L7RgtC00LDRh9C4INGBIG5naW54?= In-Reply-To: <10a8591923877b4ddb512a7e9530a0fe.NginxMailingListRussian@forum.nginx.org> References: <10a8591923877b4ddb512a7e9530a0fe.NginxMailingListRussian@forum.nginx.org> Message-ID: <-3680248427246475464@unknownmsgid> FLV не будет проигрываться на Apple. MP4 будет проигрываться везде. -- Best regards, Alexey Bobok 28.09.2012, в 0:34, abasive написал(а): > Уважаемые форумчане не подскажете для видеостриминга что лучше использовать > mp4 или flv, можно узнать плючсы и минусы этих форматов? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231166,231166#msg-231166 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx at anes.su Fri Sep 28 14:40:14 2012 From: nginx at anes.su (Anes Mukhametov) Date: Fri, 28 Sep 2012 18:40:14 +0400 Subject: Internal location Message-ID: <42b2a45d21f73f78c24298bf3fd4f591@logol.ru> Здравствуйте! Вопрос по location и internal. Есть сервер centos 5.8 с nginx 0.8.55. Конфигурация: server{ ... location / { #backend - default proxy_pass $scheme://127.0.0.1; } location ~* "/edit(/[a-z0-9]{14})?$" { #special case if ($request_method = GET) { #get - ok proxy_pass $scheme://127.0.0.1; } perl resources::handler; # returns $r->internal_redirect('/internal/edit'); } location /internal/edit { internal; proxy_pass $scheme://127.0.0.1; } Дефолтно все запросы отправляются на бэкенд. Часть запросов в 2-м location отправляются также на бэкенд, часть в handler. Handler всегда осуществляет внутреннее перенаправление в /internal/edit. При внутреннем перенаправлении на бэкенд уходит оригинальный uri (по которому запрос обработался 2-м location). В этой конфигурации проблем нет, бэкенд видит тот uri, который пришел в nginx снаружи. Есть второй сервер с идентичной конфигурацией nginx версии 1.2.4. С такой же конфигуркцией на нем возникает проблема: на бэкенд в 3-м location запрос попадает с uri /internal/edit Поведение двух версий явно различается. В changelogs не нашел причин. Баг? From nginx-forum at nginx.us Fri Sep 28 15:36:49 2012 From: nginx-forum at nginx.us (alexey.radkov) Date: Fri, 28 Sep 2012 11:36:49 -0400 Subject: rewrite / proxy_pass different bahaviour in 1.0 and 1.2 Message-ID: <413173b0a08f31554bfacf78b0a12a07.NginxMailingListRussian@forum.nginx.org> Hi guys. Is the following result of a bug fix in proxy module in 1.2 series? Imagine following config (sorry, i do not know how to format it here): events { worker_connections 1024; } http { upstream ubackend { server localhost:8020; } server { listen 8010; server_name router; location /test.html { rewrite ^ /Internal_test last; } location /Internal_test { internal; proxy_pass http://$arg_a; } } server { listen 8020; server_name backend; location /test.html { echo "In backend"; } } } and following request: curl 'http://localhost:8010/test.html?a=ubackend' Then 1.0 behaviour: In backend 1.2 behaviour: 404 Not Found

404 Not Found


nginx/1.2.3
ngrep traces: 1.0: ##### U 127.0.0.1:36906 -> 127.0.0.1:36906 . ###### T 127.0.0.1:44685 -> 127.0.0.1:8010 [AP] GET /test.html?a=ubackend HTTP/1.1. User-Agent: curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 NSS/3.13.5.0 zlib/1.2.5 libidn/1.24 libssh2/1.4.1. Host: localhost:8010. Accept: */*. . ##### T 127.0.0.1:39418 -> 127.0.0.1:8020 [AP] GET /test.html?a=ubackend HTTP/1.0. Host: ubackend. Connection: close. User-Agent: curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 NSS/3.13.5.0 zlib/1.2.5 libidn/1.24 libssh2/1.4.1. Accept: */*. . ## T 127.0.0.1:8020 -> 127.0.0.1:39418 [AP] HTTP/1.1 200 OK. Server: nginx/1.0.10. Date: Fri, 28 Sep 2012 15:07:55 GMT. Content-Type: text/html. Content-Length: 11. Connection: close. . In backend ##### T 127.0.0.1:8010 -> 127.0.0.1:44685 [AP] HTTP/1.1 200 OK. Server: nginx/1.0.10. Date: Fri, 28 Sep 2012 15:07:55 GMT. Content-Type: text/html. Connection: keep-alive. Content-Length: 11. . In backend 1.2 : # U 127.0.0.1:36906 -> 127.0.0.1:36906 . ###### T 127.0.0.1:44696 -> 127.0.0.1:8010 [AP] GET /test.html?a=ubackend HTTP/1.1. User-Agent: curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 NSS/3.13.5.0 zlib/1.2.5 libidn/1.24 libssh2/1.4.1. Host: localhost:8010. Accept: */*. . ##### T 127.0.0.1:39429 -> 127.0.0.1:8020 [AP] GET /Internal_test?a=ubackend HTTP/1.0. Host: ubackend. Connection: close. User-Agent: curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 NSS/3.13.5.0 zlib/1.2.5 libidn/1.24 libssh2/1.4.1. Accept: */*. . ## T 127.0.0.1:8020 -> 127.0.0.1:39429 [AP] HTTP/1.1 404 Not Found. Server: nginx/1.2.3. Date: Fri, 28 Sep 2012 15:08:51 GMT. Content-Type: text/html. Content-Length: 168. Connection: close. . . 404 Not Found. .

404 Not Found

.
nginx/1.2.3
. . . ##### T 127.0.0.1:8010 -> 127.0.0.1:44696 [AP] HTTP/1.1 404 Not Found. Server: nginx/1.2.3. Date: Fri, 28 Sep 2012 15:08:51 GMT. Content-Type: text/html. Content-Length: 168. Connection: keep-alive. . . 404 Not Found. .

404 Not Found

.
nginx/1.2.3
. . . So the difference is that in 1.0 original URI is not rewritten in HTTP GET header when proxied after rewrite, but in 1.2 it is rewritten to /Internal_test thus giving result 404 Not Found. Do I understand this right that 1.0 behaviour was not correct and just fixed in 1.2? To achieve 1.0 behaviour in 1.2 i can add only 2 lines of code from 1.0. Here is diff: --- ngx_http_proxy_module.c 2012-09-28 19:16:42.416144040 +0400 +++ ngx_http_proxy_module.c.new 2012-09-28 19:16:33.505015157 +0400 @@ -783,10 +783,13 @@ ngx_memcpy(p, url.uri.data, url.uri.len); url.uri.len++; url.uri.data = p - 1; } + + } else { + url.uri = r->unparsed_uri; } ctx->vars.key_start = u->schema; ngx_http_proxy_set_vars(&url, &ctx->vars); Cheers, Alexey. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231218,231218#msg-231218 From n.g.i.n.x.e.r at gmail.com Fri Sep 28 16:24:16 2012 From: n.g.i.n.x.e.r at gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Fri, 28 Sep 2012 20:24:16 +0400 Subject: =?UTF-8?B?0KHRgtCw0YLQuNC60LAg0LggNDA0?= Message-ID: Раньше 404 отдавался скриптом с заголовком 404 Решил сделать статичную страницу, но при таком варианте в заголовке отадется HTTP/1.1 200 OK, а нужно HTTP/1.1 404 Not Found Не пойму как отдать свой заголовк, пробовал в location вставить return 404;, отдает 404 но не мою сейчас такие натсройки error_page 404 /404.html; location /404.html { root $userRoot; } Как отдать свой заголовок 404 в такой ситуации? From igor at sysoev.ru Fri Sep 28 17:01:03 2012 From: igor at sysoev.ru (Igor Sysoev) Date: Fri, 28 Sep 2012 21:01:03 +0400 Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjQutCwINC4IDQwNA==?= In-Reply-To: References: Message-ID: On Sep 28, 2012, at 20:24 , Роман wrote: > Раньше 404 отдавался скриптом с заголовком 404 > > Решил сделать статичную страницу, но при таком варианте в заголовке > отадется HTTP/1.1 200 OK, а нужно HTTP/1.1 404 Not Found > > Не пойму как отдать свой заголовк, пробовал в location вставить return > 404;, отдает 404 но не мою > > сейчас такие натсройки > > error_page 404 /404.html; > > location /404.html { > root $userRoot; > } > > Как отдать свой заголовок 404 в такой ситуации? Если запрашивать /404.html, то будет отдаваться 200. А при /несуществующая_страница - должно отдаваться 404. Вот так хитро всё устроено. А если написать location = /404.html { internal; root ... } то 404 будет всегда. -- Igor Sysoev http://nginx.com/support.html From mdounin at mdounin.ru Fri Sep 28 17:51:15 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 28 Sep 2012 21:51:15 +0400 Subject: Internal location In-Reply-To: <42b2a45d21f73f78c24298bf3fd4f591@logol.ru> References: <42b2a45d21f73f78c24298bf3fd4f591@logol.ru> Message-ID: <20120928175115.GM40452@mdounin.ru> Hello! On Fri, Sep 28, 2012 at 06:40:14PM +0400, Anes Mukhametov wrote: > Здравствуйте! > > Вопрос по location и internal. > > Есть сервер centos 5.8 с nginx 0.8.55. > > Конфигурация: > > server{ > ... > location / { #backend - default > proxy_pass $scheme://127.0.0.1; > } > > location ~* "/edit(/[a-z0-9]{14})?$" { #special case > if ($request_method = GET) { #get - ok > proxy_pass $scheme://127.0.0.1; > } > perl resources::handler; # returns > $r->internal_redirect('/internal/edit'); > } > > location /internal/edit { > internal; > proxy_pass $scheme://127.0.0.1; > } > > Дефолтно все запросы отправляются на бэкенд. Часть запросов в 2-м > location отправляются также на бэкенд, часть в handler. Handler > всегда осуществляет внутреннее перенаправление в /internal/edit. > При внутреннем перенаправлении на бэкенд уходит оригинальный uri (по > которому запрос обработался 2-м location). В этой конфигурации > проблем нет, бэкенд видит тот uri, который пришел в nginx снаружи. > > > Есть второй сервер с идентичной конфигурацией nginx версии 1.2.4. С > такой же конфигуркцией на нем возникает проблема: на бэкенд в 3-м > location запрос попадает с uri /internal/edit > > Поведение двух версий явно различается. В changelogs не нашел > причин. Баг? Нет, это intended change (потому как предыдущее поведение было совершенно неконсистентно). В changelog'е оно скрывается за *) Change: a "proxy_pass" directive without URI part now uses changed URI after redirection with the "error_page" directive. Thanks to Lanshun Zhou. И в вашем случае тут ещё добавляется багфикс из той же версии 1.1.12: *) Bugfix: a "proxy_pass" directive without URI part always used original request URI if variables were used. Решение - использовать именованные location'ы, если хочется сохранять URI, либо явно задавать URI, который хочется передать на бекенд. В вашем случае будет работать как-то так: proxy_pass $scheme://127.0.0.1$request_uri; Ну и надо доделать перл, чтобы понимал именованные location'ы, да. -- Maxim Dounin http://nginx.com/support.html From mdounin at mdounin.ru Fri Sep 28 17:58:32 2012 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 28 Sep 2012 21:58:32 +0400 Subject: rewrite / proxy_pass different bahaviour in 1.0 and 1.2 In-Reply-To: <413173b0a08f31554bfacf78b0a12a07.NginxMailingListRussian@forum.nginx.org> References: <413173b0a08f31554bfacf78b0a12a07.NginxMailingListRussian@forum.nginx.org> Message-ID: <20120928175832.GN40452@mdounin.ru> Hello! On Fri, Sep 28, 2012 at 11:36:49AM -0400, alexey.radkov wrote: > Hi guys. > > > Is the following result of a bug fix in proxy module in 1.2 series? > > Imagine following config (sorry, i do not know how to format it here): [...] > location /test.html { > rewrite ^ /Internal_test last; > } > > location /Internal_test { > internal; > proxy_pass http://$arg_a; > } > } [...] > and following request: > > curl 'http://localhost:8010/test.html?a=ubackend' [...] > So the difference is that in 1.0 original URI is not rewritten in HTTP GET > header when proxied after rewrite, but in 1.2 it is rewritten to > /Internal_test thus giving result 404 Not Found. > > > Do I understand this right that 1.0 behaviour was not correct and just fixed > in 1.2? Yes. This was fixed 1.1.12: *) Bugfix: a "proxy_pass" directive without URI part always used original request URI if variables were used. > To achieve 1.0 behaviour in 1.2 i can add only 2 lines of code from 1.0. You may also use proxy_pass http://$arg_a$request_uri; to get the old behaviour. [...] -- Maxim Dounin http://nginx.com/support.html From panfilov at sports.ru Fri Sep 28 20:42:21 2012 From: panfilov at sports.ru (=?KOI8-R?B?7cnIwcnMIPDBzsbJzM/X?=) Date: Sat, 29 Sep 2012 00:42:21 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INGA0LXQsNC70LjQt9Cw0YbQuNC4INC60LU=?= =?UTF-8?B?0YjQuNGA0L7QstCw0L3QuNGPINC90LAgQ0RO?= In-Reply-To: <027F2025-A9F5-461C-89D7-0820D8EC3AC7@sysoev.ru> References: <20120928081222.GA9259@nginx.com> <027F2025-A9F5-461C-89D7-0820D8EC3AC7@sysoev.ru> Message-ID: Интересная мысль. Но как оно будет работать? Учитывать все куки? Не пойдет, потому что нужно учитывать только куку sid и не учитывать остальные - иначе кэш не будет кэшить. Вот как бы указать что-нибудь в духе Vary: $cookie_sid ? 28 сентября 2012 г., 12:56 пользователь Igor Sysoev написал: > On Sep 28, 2012, at 12:32 , Михаил Панфилов wrote: > > А будет ли при этом ответ кэшироваться для пользователя? > > > Да, private разрешает кэширование только клиентом. > > Какой при этом нужно использовать ключ кэширования на CDN? > > > Стандартный. nginx будет искать ответы в кэше по ключу, но поскольку > ответы с private не будет кэшироваться, то их там и не окажется. > > > -- > Igor Sysoev > http://nginx.com/support.html > > 28 сентября 2012 г., 12:12 пользователь Igor Sysoev написал: > >> On Thu, Sep 27, 2012 at 08:32:34PM +0400, Михаил Панфилов wrote: >> > Доброго времени суток! >> > >> > Не подскажете ли решение на nginx для следующей задачи: >> > >> > необходимо реализовать кэширование на CDN динамических запросов. >> Сложность >> > в том, что надо как-то понимать с каким ключом (учитывать ли sid) >> > кешировать. Какие-то запросы уникальны для пользователей, какие-то >> общие. >> > Текущую архитектуру сайта (URL) не переделать, и хочется обойтись без >> > "карты сайта" (какие location уникальны для пользователя, а какие нет). >> > Может есть какое-нибудь универсальное решение, например, на основе >> > заголовков Vary? >> >> Для уникальных страниц выдавать бэкендом "Cache-Control: private". >> >> > З.Ы. На CDN и Frontend стоит nginx. >> >> >> -- >> Igor Sysoev >> http://nginx.com/support.html > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Панфилов Михаил Старший системный администратор www.sports.ru + 7 903 578 4067 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Sep 29 13:33:00 2012 From: nginx-forum at nginx.us (alexey.radkov) Date: Sat, 29 Sep 2012 09:33:00 -0400 Subject: rewrite / proxy_pass different bahaviour in 1.0 and 1.2 In-Reply-To: <20120928175832.GN40452@mdounin.ru> References: <20120928175832.GN40452@mdounin.ru> Message-ID: <8df30935b77fc6b3dd4af842607c6ee7.NginxMailingListRussian@forum.nginx.org> Maxim, thank you! This "bug" was a "feature" in our own proxy module based upon standard nginx proxy module. When i ported changes in 1.2 into our module i was surprised why some of our rules were not working until i found this change. We cannot use something like proxy_pass http://$arg_a$request_uri; because our directives do not support this. So currently i just reverted those 2 removed lines into our module. May i expect some unwanted side effects from thу removal except those which we are using as "feature"? Cheers, Alexey. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,231218,231247#msg-231247 From n.g.i.n.x.e.r at gmail.com Sat Sep 29 20:10:10 2012 From: n.g.i.n.x.e.r at gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Sun, 30 Sep 2012 00:10:10 +0400 Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjQutCwINC4IDQwNA==?= In-Reply-To: References: Message-ID: Спасибо, теперь передумал схему и решил сделать так нужно выдавать 404ю ссылаясь на директорию /404/ и там уже можно разруливать что отдавать но вот одно но, при такой схеме: error_page 404 /404/; location /404 { internal; root $userRoot; index 404.html; } файл 404.html будет искаться в реальной папке /404/, а хотелось бы его выдавать из корня. 28 сентября 2012 г., 21:01 пользователь Igor Sysoev написал: > On Sep 28, 2012, at 20:24 , Роман wrote: > >> Раньше 404 отдавался скриптом с заголовком 404 >> >> Решил сделать статичную страницу, но при таком варианте в заголовке >> отадется HTTP/1.1 200 OK, а нужно HTTP/1.1 404 Not Found >> >> Не пойму как отдать свой заголовк, пробовал в location вставить return >> 404;, отдает 404 но не мою >> >> сейчас такие натсройки >> >> error_page 404 /404.html; >> >> location /404.html { >> root $userRoot; >> } >> >> Как отдать свой заголовок 404 в такой ситуации? > > Если запрашивать /404.html, то будет отдаваться 200. > А при /несуществующая_страница - должно отдаваться 404. > Вот так хитро всё устроено. > > А если написать > > location = /404.html { > internal; > root ... > } > > то 404 будет всегда. > > > -- > Igor Sysoev > http://nginx.com/support.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From igor at sysoev.ru Sun Sep 30 05:23:17 2012 From: igor at sysoev.ru (Igor Sysoev) Date: Sun, 30 Sep 2012 09:23:17 +0400 Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjQutCwINC4IDQwNA==?= In-Reply-To: References: Message-ID: <9BFE61D9-5EBE-42A7-B84B-8E81F1267A77@sysoev.ru> On Sep 30, 2012, at 0:10 , Роман wrote: > Спасибо, теперь передумал схему и решил сделать так > нужно выдавать 404ю ссылаясь на директорию /404/ > и там уже можно разруливать что отдавать > но вот одно но, при такой схеме: > > error_page 404 /404/; > > location /404 { > internal; > root $userRoot; > index 404.html; > } > > файл 404.html будет искаться в реальной папке /404/, а хотелось бы его > выдавать из корня. Зачем такие сложности ? Чем не устраивает /404.html ? -- Igor Sysoev http://nginx.com/support.html > 28 сентября 2012 г., 21:01 пользователь Igor Sysoev написал: >> On Sep 28, 2012, at 20:24 , Роман wrote: >> >>> Раньше 404 отдавался скриптом с заголовком 404 >>> >>> Решил сделать статичную страницу, но при таком варианте в заголовке >>> отадется HTTP/1.1 200 OK, а нужно HTTP/1.1 404 Not Found >>> >>> Не пойму как отдать свой заголовк, пробовал в location вставить return >>> 404;, отдает 404 но не мою >>> >>> сейчас такие натсройки >>> >>> error_page 404 /404.html; >>> >>> location /404.html { >>> root $userRoot; >>> } >>> >>> Как отдать свой заголовок 404 в такой ситуации? >> >> Если запрашивать /404.html, то будет отдаваться 200. >> А при /несуществующая_страница - должно отдаваться 404. >> Вот так хитро всё устроено. >> >> А если написать >> >> location = /404.html { >> internal; >> root ... >> } >> >> то 404 будет всегда. >> >> >> -- >> Igor Sysoev >> http://nginx.com/support.html >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From n.g.i.n.x.e.r at gmail.com Sun Sep 30 10:52:56 2012 From: n.g.i.n.x.e.r at gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Sun, 30 Sep 2012 14:52:56 +0400 Subject: =?UTF-8?B?UmU6INCh0YLQsNGC0LjQutCwINC4IDQwNA==?= In-Reply-To: <9BFE61D9-5EBE-42A7-B84B-8E81F1267A77@sysoev.ru> References: <9BFE61D9-5EBE-42A7-B84B-8E81F1267A77@sysoev.ru> Message-ID: потому что 404.php динамическая, а 404.html - кеш и если что то в будущем изменится я смогу поменять все в конфиге nginx, а не в скрипте, где указана ссылка на директорию а не на конечный файл А что там в директории скрипту уже будет все равно. 30 сентября 2012 г., 9:23 пользователь Igor Sysoev написал: > On Sep 30, 2012, at 0:10 , Роман wrote: > >> Спасибо, теперь передумал схему и решил сделать так >> нужно выдавать 404ю ссылаясь на директорию /404/ >> и там уже можно разруливать что отдавать >> но вот одно но, при такой схеме: >> >> error_page 404 /404/; >> >> location /404 { >> internal; >> root $userRoot; >> index 404.html; >> } >> >> файл 404.html будет искаться в реальной папке /404/, а хотелось бы его >> выдавать из корня. > > Зачем такие сложности ? Чем не устраивает /404.html ? > > > -- > Igor Sysoev > http://nginx.com/support.html > >> 28 сентября 2012 г., 21:01 пользователь Igor Sysoev написал: >>> On Sep 28, 2012, at 20:24 , Роман wrote: >>> >>>> Раньше 404 отдавался скриптом с заголовком 404 >>>> >>>> Решил сделать статичную страницу, но при таком варианте в заголовке >>>> отадется HTTP/1.1 200 OK, а нужно HTTP/1.1 404 Not Found >>>> >>>> Не пойму как отдать свой заголовк, пробовал в location вставить return >>>> 404;, отдает 404 но не мою >>>> >>>> сейчас такие натсройки >>>> >>>> error_page 404 /404.html; >>>> >>>> location /404.html { >>>> root $userRoot; >>>> } >>>> >>>> Как отдать свой заголовок 404 в такой ситуации? >>> >>> Если запрашивать /404.html, то будет отдаваться 200. >>> А при /несуществующая_страница - должно отдаваться 404. >>> Вот так хитро всё устроено. >>> >>> А если написать >>> >>> location = /404.html { >>> internal; >>> root ... >>> } >>> >>> то 404 будет всегда. >>> >>> >>> -- >>> Igor Sysoev >>> http://nginx.com/support.html >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru