From gmm at csdoc.com Mon Jun 1 08:19:50 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 01 Jun 2015 11:19:50 +0300 Subject: =?UTF-8?B?UmU6IFdvcmRQcmVzcyArIE5naW54INGI0LjRhNGA0L7QstCw0L3QvdCw0Y8g0LA=?= =?UTF-8?B?0LTQvNC40L3QutCwINC/0YDQvtCx0LvQtdC80LAgPw==?= In-Reply-To: References: Message-ID: <556C15A6.1050501@csdoc.com> On 01.06.2015 2:07, AntonioNemcd wrote: > Есть подозрение что где-то идет редирект на уровне скриптов, только пока не > нашел где. > Проблема давняя, уже должны был кто-то найти решение! Решение тоже очень давнее - прочитать документацию: https://codex.wordpress.org/Administration_Over_SSL -- Best regards, Gena From nginx-forum at nginx.us Mon Jun 1 11:19:16 2015 From: nginx-forum at nginx.us (AntonioNemcd) Date: Mon, 01 Jun 2015 07:19:16 -0400 Subject: =?UTF-8?B?UmU6IFdvcmRQcmVzcyArIE5naW54INGI0LjRhNGA0L7QstCw0L3QvdCw0Y8g0LA=?= =?UTF-8?B?0LTQvNC40L3QutCwINC/0YDQvtCx0LvQtdC80LAgPw==?= In-Reply-To: <556C15A6.1050501@csdoc.com> References: <556C15A6.1050501@csdoc.com> Message-ID: Спасибо, уже нашел решение, да, там его можно встретить, но среди кучи инфы как-то пропустил, пришлось перерыть код Wordpress Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251401,259294#msg-259294 From mdounin at mdounin.ru Mon Jun 1 12:42:33 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 1 Jun 2015 15:42:33 +0300 Subject: the http output chain is empty bug In-Reply-To: <6d66e024745972e43471862c3c1222e8.NginxMailingListRussian@forum.nginx.org> References: <3166049.EYtkHFoGR9@note> <19dff07fce58d3c6b26b95c940e53d4d.NginxMailingListRussian@forum.nginx.org> <73335e88a4bcb2c6a054028e72803c6f.NginxMailingListRussian@forum.nginx.org> <6d66e024745972e43471862c3c1222e8.NginxMailingListRussian@forum.nginx.org> Message-ID: <20150601124233.GM26357@mdounin.ru> Hello! On Thu, May 28, 2015 at 04:17:31PM -0400, tester123 wrote: > УРА, РЕБЯТА!!! Не прошло и десяти лет, как кто-то наконец-то соизволил > исправить эту багу. Я бы переформулировал: вы, видимо, неконец-то соизволили обновиться. Вам это предлагали сделать сразу, но вы почему-то сопротивлялись. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Mon Jun 1 16:19:39 2015 From: nginx-forum at nginx.us (AlexsnderS) Date: Mon, 01 Jun 2015 12:19:39 -0400 Subject: =?UTF-8?B?0L/RgNC+0LLQtdGA0LrQsCDRhNCw0LnQu9CwINC/0L7RgdC70LUg0LjQt9C80LU=?= =?UTF-8?B?0L3QtdC90LjRjyDQsNC00YDQtdGB0LA=?= Message-ID: Здравствуйте! Задача в следующем: Поймать по регулярке адрес, по регулярке его превратить в путь к файлу. Если файл есть на диске, то отдать его клиенту, если нет, то передать запрос в index.php #перехватываю запрос location = ^/news.*\.jpg$ { #превращаю запрос в путь к файлу rewrite ^/news/[\w\-_]+/([\w\-_]+)\-(\d+x\d+x[p|i])-(\d+)\.jpg$ /data/cache/news/$3/$1-$2\.jpg break; #проверяю есть ли он на диске, если нет, то отдаю в index.php } location = ^/data/cache/news/.* { try_files $uri /index.php; } Например алгоритм такой: 1. Получаю запрос: /news/test/test-100x100xp-10.jpg 2. Сработал location 3. Этот запрос преобразовался в /data/cache/news/10/test-100x100xp.jpg 4. Проверка файла на наличие на диске 4.1 Файл есть - отдаем клиенту 4.2 Файла нет - отдаем обработку в index.php Испробовал кучу вариантов, но так толком ничего и не добился. Помогите, пожалуйста. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259310,259310#msg-259310 From chipitsine at gmail.com Mon Jun 1 17:41:39 2015 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 1 Jun 2015 22:41:39 +0500 Subject: =?UTF-8?B?UmU6INC/0YDQvtCy0LXRgNC60LAg0YTQsNC50LvQsCDQv9C+0YHQu9C1INC40Lc=?= =?UTF-8?B?0LzQtdC90LXQvdC40Y8g0LDQtNGA0LXRgdCw?= In-Reply-To: References: Message-ID: root /data/cache; location / { try_files $uri $uri/ @fallback; index index.php index.html index.htm; } location ~ \.php$ { try_files $uri @fallback; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; } location @fallback { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root/index.php; include fastcgi_params; } 1 июня 2015 г., 21:19 пользователь AlexsnderS написал: > Здравствуйте! > > Задача в следующем: > Поймать по регулярке адрес, по регулярке его превратить в путь к файлу. Если > файл есть на диске, то отдать его клиенту, если нет, то передать запрос в > index.php > > #перехватываю запрос > location = ^/news.*\.jpg$ { > #превращаю запрос в путь к файлу > rewrite ^/news/[\w\-_]+/([\w\-_]+)\-(\d+x\d+x[p|i])-(\d+)\.jpg$ > /data/cache/news/$3/$1-$2\.jpg break; > #проверяю есть ли он на диске, если нет, то отдаю в index.php > } > > location = ^/data/cache/news/.* { > try_files $uri /index.php; > } > > Например алгоритм такой: > 1. Получаю запрос: /news/test/test-100x100xp-10.jpg > 2. Сработал location > 3. Этот запрос преобразовался в /data/cache/news/10/test-100x100xp.jpg > 4. Проверка файла на наличие на диске > 4.1 Файл есть - отдаем клиенту > 4.2 Файла нет - отдаем обработку в index.php > > Испробовал кучу вариантов, но так толком ничего и не добился. Помогите, > пожалуйста. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259310,259310#msg-259310 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From juriy.foboss at gmail.com Tue Jun 2 06:39:15 2015 From: juriy.foboss at gmail.com (Juriy Strashnov) Date: Tue, 2 Jun 2015 09:39:15 +0300 Subject: =?UTF-8?B?0JrQsNC6INGA0LDRgdC/0LDQutC+0LLQsNGC0YwgWklQJ9C+0LLQsNC90L3Ri9C5?= =?UTF-8?B?INC30LDQv9GA0L7RgSDQv9C10YDQtdC0INC/0LXRgNC10LTQsNGH0LXQuSA=?= =?UTF-8?B?0L3QsCBiYWNrZW5kPw==?= Message-ID: Коллеги, подскажите: возможно ли настроить nginx таким образом, чтобы он принимал body http запроса в формате zip (НЕ GZIP!!!), распаковывал его и уже в распакованном виде передавал в обработку на backend (proxy_pass)? -- Best regards, Juriy Strashnov Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mva at mva.name Tue Jun 2 07:08:02 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 02 Jun 2015 13:08:02 +0600 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0YHQv9Cw0LrQvtCy0LDRgtGMIFpJUCfQvtCy0LDQvdC9?= =?UTF-8?B?0YvQuSDQt9Cw0L/RgNC+0YEg0L/QtdGA0LXQtCDQv9C10YDQtdC00LDRh9C1?= =?UTF-8?B?0Lkg0L3QsCBiYWNrZW5kPw==?= In-Reply-To: References: Message-ID: <21410768.1J7srzxyGA@note> В письме от Вт, 2 июня 2015 09:39:15 пользователь Juriy Strashnov написал: > Коллеги, подскажите: > > возможно ли настроить nginx таким образом, чтобы он принимал body http > запроса в формате zip (НЕ GZIP!!!), распаковывал его и уже в распакованном > виде передавал в обработку на backend (proxy_pass)? > разве что используя встроенный перл или Lua-модуль // кстати, интересно, включат ли его в коробочную поставку когда-нибудь?.. :Р -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From myc at cname.me Tue Jun 2 08:06:40 2015 From: myc at cname.me (Eugene Mychlo) Date: Tue, 2 Jun 2015 11:06:40 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0YHQv9Cw0LrQvtCy0LDRgtGMIFpJUCfQvtCy0LDQvdC9?= =?UTF-8?B?0YvQuSDQt9Cw0L/RgNC+0YEg0L/QtdGA0LXQtCDQv9C10YDQtdC00LDRh9C1?= =?UTF-8?B?0Lkg0L3QsCBiYWNrZW5kPw==?= In-Reply-To: <21410768.1J7srzxyGA@note> References: <21410768.1J7srzxyGA@note> Message-ID: <849E69EF-F20C-4CAF-ACD1-72AF1D28759E@cname.me> Думаю, не раньше чем появится DSO в nginx. ;) > 2 июня 2015 г., в 10:08, Vadim A. Misbakh-Soloviov написал(а): > > В письме от Вт, 2 июня 2015 09:39:15 пользователь Juriy Strashnov написал: >> Коллеги, подскажите: >> >> возможно ли настроить nginx таким образом, чтобы он принимал body http >> запроса в формате zip (НЕ GZIP!!!), распаковывал его и уже в распакованном >> виде передавал в обработку на backend (proxy_pass)? >> > > разве что используя встроенный перл или Lua-модуль > > // кстати, интересно, включат ли его в коробочную поставку когда-нибудь?.. :Р > > -- > Best regards, > mva > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Tue Jun 2 08:35:41 2015 From: nginx-forum at nginx.us (s.ivanov) Date: Tue, 02 Jun 2015 04:35:41 -0400 Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0L3Ri9C1INCy0YvRgNCw0LbQtdC90LjRjyDQsiBs?= =?UTF-8?B?b2NhdGlvbg==?= In-Reply-To: References: Message-ID: <3e5727540cb968b54dedeeb79dd185db.NginxMailingListRussian@forum.nginx.org> Иван Мишин Wrote: ------------------------------------------------------- > > > > Предложенный вами синтаксис location/ пришлось сократить, иначе при > > проверке > > конфигурации возникала ошибка: > > nginx: [emerg] named location "@nameloc" can be on the server level > only > > > Будьте внимательнее! > В ошибке явно же написано что именованные локейшн @nameloc должен > быть на > уровне директивы server. В моем варианте именно так и есть, скорее > всего вы > опечатались когда пробовали мой вариант. > > Сам не так давно сталкивался с похожей задачей, поэтому мой конфиг > 100% > рабочий ибо опробован. > > 14 апреля 2015 г., 16:59 пользователь s.ivanov > написал: > > > С таким вариантом получаем 403 Forbidden на URL любого типа, > разрешённые и > > нет ? проксирования не происходит, не срабатывает правило. > > Пробовал и так: > > > > location /Mydll.dll { > > if ($query_string ~ al= ) { > > proxy_pass http://192.168.0.2:3000; > > } > > deny all; > > } > > > > и так: > > proxy_pass http://192.168.0.2:3000$1; > > > > и так: > > proxy_pass http://192.168.0.2:3000/$1$is_args$args;; > > > > > > Предложенный вами синтаксис location/ пришлось сократить, иначе при > > проверке > > конфигурации возникала ошибка: > > nginx: [emerg] named location "@nameloc" can be on the server level > only > > > > Возможно, столь сложные конструкции регулярных выражений (разрешить > всё > > кроме) не поддерживаются в nginx в принципе? > > > > Posted at Nginx Forum: > > http://forum.nginx.org/read.php?21,17244,258029#msg-258029 > > > > _______________________________________________ > > 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 Коллега, я рано обрадовался - запросы к http://site.ru/Mydll.dll?al= приводят к переадресации, а должны завершаться 403-ей... Т.е.: http://site.ru/Mydll.dll - 403, ok http://site.ru/Mydll.dll? - 403, ok http://site.ru/Mydll.dll?a - 403, ok http://site.ru/Mydll.dll?al - 403, ok http://site.ru/Mydll.dll?al= - пустой al без указания кода, переадресация на @nameloc, не ok :( Очевидно, надо на что-то изменить "~ al=" в location /Mydll.dll { if ($query_string ~ al= ) { return 418; } ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,17244,259335#msg-259335 From chipitsine at gmail.com Tue Jun 2 11:34:04 2015 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 2 Jun 2015 16:34:04 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0YHQv9Cw0LrQvtCy0LDRgtGMIFpJUCfQvtCy0LDQvdC9?= =?UTF-8?B?0YvQuSDQt9Cw0L/RgNC+0YEg0L/QtdGA0LXQtCDQv9C10YDQtdC00LDRh9C1?= =?UTF-8?B?0Lkg0L3QsCBiYWNrZW5kPw==?= In-Reply-To: <21410768.1J7srzxyGA@note> References: <21410768.1J7srzxyGA@note> Message-ID: Lua есть в сборке nginx plus: http://nginx.com/products/releases/ уже очень давно 2 июня 2015 г., 12:08 пользователь Vadim A. Misbakh-Soloviov написал: > В письме от Вт, 2 июня 2015 09:39:15 пользователь Juriy Strashnov написал: >> Коллеги, подскажите: >> >> возможно ли настроить nginx таким образом, чтобы он принимал body http >> запроса в формате zip (НЕ GZIP!!!), распаковывал его и уже в распакованном >> виде передавал в обработку на backend (proxy_pass)? >> > > разве что используя встроенный перл или Lua-модуль > > // кстати, интересно, включат ли его в коробочную поставку когда-нибудь?.. :Р > > -- > Best regards, > mva > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Tue Jun 2 11:54:26 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 02 Jun 2015 14:54:26 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0YHQv9Cw0LrQvtCy0LDRgtGMIFpJUCfQvtCy0LDQvdC9?= =?UTF-8?B?0YvQuSDQt9Cw0L/RgNC+0YEg0L/QtdGA0LXQtCDQv9C10YDQtdC00LDRh9C1?= =?UTF-8?B?0Lkg0L3QsCBiYWNrZW5kPw==?= In-Reply-To: <849E69EF-F20C-4CAF-ACD1-72AF1D28759E@cname.me> References: <21410768.1J7srzxyGA@note> <849E69EF-F20C-4CAF-ACD1-72AF1D28759E@cname.me> Message-ID: <1952833.qXMNCrzLiS@vbart-workstation> On Tuesday 02 June 2015 11:06:40 Eugene Mychlo wrote: > Думаю, не раньше чем появится DSO в nginx. ;) > Уже скоро, в 1.9.x: http://trac.nginx.org/nginx/roadmap -- Валентин Бартенев > > > 2 июня 2015 г., в 10:08, Vadim A. Misbakh-Soloviov написал(а): > > > > В письме от Вт, 2 июня 2015 09:39:15 пользователь Juriy Strashnov написал: > >> Коллеги, подскажите: > >> > >> возможно ли настроить nginx таким образом, чтобы он принимал body http > >> запроса в формате zip (НЕ GZIP!!!), распаковывал его и уже в распакованном > >> виде передавал в обработку на backend (proxy_pass)? > >> > > > > разве что используя встроенный перл или Lua-модуль > > > > // кстати, интересно, включат ли его в коробочную поставку когда-нибудь?.. :Р > > > From mva at mva.name Tue Jun 2 12:04:11 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 02 Jun 2015 18:04:11 +0600 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0YHQv9Cw0LrQvtCy0LDRgtGMIFpJUCfQvtCy0LDQvdC9?= =?UTF-8?B?0YvQuSDQt9Cw0L/RgNC+0YEg0L/QtdGA0LXQtCDQv9C10YDQtdC00LDRh9C1?= =?UTF-8?B?0Lkg0L3QsCBiYWNrZW5kPw==?= In-Reply-To: References: <21410768.1J7srzxyGA@note> Message-ID: <2432166.0tnsQhcpd9@note> Так то плюс. И по вполне очевидным причинам блобистости :) А я про перенос апстрима, например :) // хотя, для этого, наверное, потребуется чтобы agentzh перешёл из клаудфлари на работу в ngx inc. // а ещё меня беспокоит судьба ngx_postgres. А на самом деле всё потому, что это те модули, поломку которых при периодическом ломании API между мажорными версиями я замечаю больше всего :) В письме от Вт, 2 июня 2015 16:34:04 пользователь Илья Шипицин написал: > Lua есть в сборке nginx plus: http://nginx.com/products/releases/ > уже очень давно > > 2 июня 2015 г., 12:08 пользователь Vadim A. Misbakh-Soloviov > написал: > > > В письме от Вт, 2 июня 2015 09:39:15 пользователь Juriy Strashnov > > написал: > > > >> Коллеги, подскажите: > >> > >> > >> > >> возможно ли настроить nginx таким образом, чтобы он принимал body http > >> запроса в формате zip (НЕ GZIP!!!), распаковывал его и уже в > >> распакованном > >> виде передавал в обработку на backend (proxy_pass)? > >> > >> > > > > > > > > разве что используя встроенный перл или Lua-модуль > > > > > > > > // кстати, интересно, включат ли его в коробочную поставку когда-нибудь?.. > > :Р > > > > > > > -- > > Best regards, > > mva > > > > > > > > _______________________________________________ > > 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 -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nginx-forum at nginx.us Tue Jun 2 15:16:54 2015 From: nginx-forum at nginx.us (AlexsnderS) Date: Tue, 02 Jun 2015 11:16:54 -0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtCy0LXRgNC60LAg0YTQsNC50LvQsCDQv9C+0YHQu9C1INC40Lc=?= =?UTF-8?B?0LzQtdC90LXQvdC40Y8g0LDQtNGA0LXRgdCw?= In-Reply-To: References: Message-ID: <7677ad26a643480674726bbb256ba3c0.NginxMailingListRussian@forum.nginx.org> Спасибо за ответ. Так не заработало, но получилось следующим образом: location ~ /news/[\w\-_]+/([\w\-_]+)\-(\d+x\d+x[i|p])\-(\d+)\.jpg$ { rewrite /news/[\w\-_]+/([\w\-_]+)\-(\d+x\d+x[i|p])\-(\d+)\.jpg$ /data/cache/news/$3/$1-$2.jpg; try_files $uri /$yii_bootstrap; } location ~ /news/[\w\-_]+/([\w\-_]+)-(\d+)\.jpg$ { rewrite /news/[\w\-_]+/([\w\-_]+)-(\d+)\.jpg$ /data/files/news/$2/$1.jpg; try_files $uri /$yii_bootstrap; } Данный пример для Yii. Может кому-то пригодится. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259310,259345#msg-259345 From nginx-forum at nginx.us Tue Jun 2 20:59:53 2015 From: nginx-forum at nginx.us (S.A.N) Date: Tue, 02 Jun 2015 16:59:53 -0400 Subject: fastcgi_param REQUEST_SCHEME $scheme Message-ID: <593b24356c94d972e902298e1c48f730.NginxMailingListRussian@forum.nginx.org> РНР скрипты которые работали под Apache, получали перемененную окружения REQUEST_SCHEME, в fastcgi_params этот параметр не назначается, я прописал fastcgi_param REQUEST_SCHEME $scheme. Вопрос, не нарушил ли я спецификацию FastCGI, если нет, тогда почему этот параметр не указан в fastcgi_params из коробки? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259351,259351#msg-259351 From mdounin at mdounin.ru Wed Jun 3 02:41:06 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 3 Jun 2015 05:41:06 +0300 Subject: fastcgi_param REQUEST_SCHEME $scheme In-Reply-To: <593b24356c94d972e902298e1c48f730.NginxMailingListRussian@forum.nginx.org> References: <593b24356c94d972e902298e1c48f730.NginxMailingListRussian@forum.nginx.org> Message-ID: <20150603024106.GF26357@mdounin.ru> Hello! On Tue, Jun 02, 2015 at 04:59:53PM -0400, S.A.N wrote: > РНР скрипты которые работали под Apache, получали перемененную окружения > REQUEST_SCHEME, в fastcgi_params этот параметр не назначается, я прописал > fastcgi_param REQUEST_SCHEME $scheme. > > Вопрос, не нарушил ли я спецификацию FastCGI, если нет, тогда почему этот > параметр не указан в fastcgi_params из коробки? Параметр REQUEST_SCHEME не предусматривается спецификацией CGI (и соответственно FastCGI), и в общем случае может содержать произвольное значение. В Apache 2.3.11+ через него передают схему запроса. Больше, судя по всему, это решение нигде не работает: http://stackoverflow.com/questions/18008135/is-serverrequest-scheme-reliable Однако в целом мне такой подход кажется куда более правильным, чем неочевидные проверки параметра HTTPS (который тоже ни разу не стандартный), и наверное добавить в fastcgi_params по умолчанию стоит. Патч: # HG changeset patch # User Maxim Dounin # Date 1433298498 -10800 # Wed Jun 03 05:28:18 2015 +0300 # Node ID dbe6d01361b01c7e3b2a80f40492a180d242abcb # Parent 0a096e2e51fcbb536007d94bf3edfc308e214f56 Added REQUEST_SCHEME parameter. The REQUEST_SCHEME parameter was introduced in Apache 2.3.11 and seems to be used by some scripts now. It looks more logical than previously used HTTPS. diff --git a/conf/fastcgi.conf b/conf/fastcgi.conf --- a/conf/fastcgi.conf +++ b/conf/fastcgi.conf @@ -11,6 +11,7 @@ fastcgi_param DOCUMENT_URI $docum fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param HTTPS $https if_not_empty; +fastcgi_param REQUEST_SCHEME $scheme; fastcgi_param GATEWAY_INTERFACE CGI/1.1; fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; diff --git a/conf/fastcgi_params b/conf/fastcgi_params --- a/conf/fastcgi_params +++ b/conf/fastcgi_params @@ -10,6 +10,7 @@ fastcgi_param DOCUMENT_URI $docum fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param HTTPS $https if_not_empty; +fastcgi_param REQUEST_SCHEME $scheme; fastcgi_param GATEWAY_INTERFACE CGI/1.1; fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; diff --git a/conf/scgi_params b/conf/scgi_params --- a/conf/scgi_params +++ b/conf/scgi_params @@ -9,6 +9,7 @@ scgi_param DOCUMENT_ROOT $document scgi_param SCGI 1; scgi_param SERVER_PROTOCOL $server_protocol; scgi_param HTTPS $https if_not_empty; +scgi_param REQUEST_SCHEME $scheme; scgi_param REMOTE_ADDR $remote_addr; scgi_param REMOTE_PORT $remote_port; diff --git a/conf/uwsgi_params b/conf/uwsgi_params --- a/conf/uwsgi_params +++ b/conf/uwsgi_params @@ -9,6 +9,7 @@ uwsgi_param PATH_INFO $documen uwsgi_param DOCUMENT_ROOT $document_root; uwsgi_param SERVER_PROTOCOL $server_protocol; uwsgi_param HTTPS $https if_not_empty; +uwsgi_param REQUEST_SCHEME $scheme; uwsgi_param REMOTE_ADDR $remote_addr; uwsgi_param REMOTE_PORT $remote_port; -- Maxim Dounin http://nginx.org/ From juriy.foboss at gmail.com Wed Jun 3 08:57:40 2015 From: juriy.foboss at gmail.com (Juriy Strashnov) Date: Wed, 3 Jun 2015 11:57:40 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0YHQv9Cw0LrQvtCy0LDRgtGMIFpJUCfQvtCy0LDQvdC9?= =?UTF-8?B?0YvQuSDQt9Cw0L/RgNC+0YEg0L/QtdGA0LXQtCDQv9C10YDQtdC00LDRh9C1?= =?UTF-8?B?0Lkg0L3QsCBiYWNrZW5kPw==?= In-Reply-To: <21410768.1J7srzxyGA@note> References: <21410768.1J7srzxyGA@note> Message-ID: Ясно. Спасибо большое! 2015-06-02 10:08 GMT+03:00 Vadim A. Misbakh-Soloviov : > В письме от Вт, 2 июня 2015 09:39:15 пользователь Juriy Strashnov написал: > > Коллеги, подскажите: > > > > возможно ли настроить nginx таким образом, чтобы он принимал body http > > запроса в формате zip (НЕ GZIP!!!), распаковывал его и уже в > распакованном > > виде передавал в обработку на backend (proxy_pass)? > > > > разве что используя встроенный перл или Lua-модуль > > // кстати, интересно, включат ли его в коробочную поставку когда-нибудь?.. > :Р > > -- > Best regards, > mva > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Juriy Strashnov Mob. +7 (953) 742-1550 E-mail: j.strashnov at me.com Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed Jun 3 10:43:30 2015 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 03 Jun 2015 06:43:30 -0400 Subject: fastcgi_param REQUEST_SCHEME $scheme In-Reply-To: <20150603024106.GF26357@mdounin.ru> References: <20150603024106.GF26357@mdounin.ru> Message-ID: <8f31174ce767b5cbc340a128e35f4a63.NginxMailingListRussian@forum.nginx.org> > Однако в целом мне такой подход кажется куда более правильным, чем > неочевидные проверки параметра HTTPS (который тоже ни разу не > стандартный), и наверное добавить в fastcgi_params по умолчанию > стоит. Ок, спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259351,259359#msg-259359 From dan at onliner.by Wed Jun 3 13:57:24 2015 From: dan at onliner.by (Daniil) Date: Wed, 3 Jun 2015 16:57:24 +0300 Subject: =?UTF-8?B?0J/QvtCy0LXQtNC10L3QuNC1IHRyeV9maWxlcyDQsiDQt9Cw0LLQuNGB0LjQvNC+?= =?UTF-8?B?0YHRgtC4INC+0YIgYWNjZXNzX2xvZw==?= Message-ID: Здравствуйте, Есть следующий конфиг: # например GET /apple/iphone/info location ~ .+/info$ { index index.php; try_files $uri $uri/ @php; access_log bad_guys.log if=$is_bad_guy; } location @php {...} Переменная $is_bad_guy вычисляется через цепочку map и может принимать значение 0 или 1. Если $is_bad_guy = 0, то локация срабатывает как надо и try_files переходит на @php если не найдены файлы в root каталоги. Но, если $is_bad_guy = 1 (срабатывает access_log), то сервер возвращает 404, в логе ошибок появляется сообщение "File not found" и обработка не доходит до @php. В чем здесь может быть ошибка? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Jun 3 14:27:32 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 3 Jun 2015 17:27:32 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QstC10LTQtdC90LjQtSB0cnlfZmlsZXMg0LIg0LfQsNCy0LjRgdC4?= =?UTF-8?B?0LzQvtGB0YLQuCDQvtGCIGFjY2Vzc19sb2c=?= In-Reply-To: References: Message-ID: <20150603142732.GJ26357@mdounin.ru> Hello! On Wed, Jun 03, 2015 at 04:57:24PM +0300, Daniil wrote: > Здравствуйте, > > Есть следующий конфиг: > > # например GET /apple/iphone/info > location ~ .+/info$ { > index index.php; > try_files $uri $uri/ @php; > access_log bad_guys.log if=$is_bad_guy; > } > > location @php {...} > > > Переменная $is_bad_guy вычисляется через цепочку map и может принимать > значение 0 или 1. > > Если $is_bad_guy = 0, то локация срабатывает как надо и try_files переходит > на @php если не найдены файлы в root каталоги. > > Но, если $is_bad_guy = 1 (срабатывает access_log), то сервер возвращает > 404, в логе ошибок появляется сообщение "File not found" и обработка не > доходит до @php. > > В чем здесь может быть ошибка? Ошибка где-то ещё, смотрите внимательно на конфиг целиком. Например, к похожему эффекту может привести использование директивы if модуля rewrite в данном location'е, см. http://wiki.nginx.org/IfIsEvil. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Thu Jun 4 17:04:19 2015 From: nginx-forum at nginx.us (waltersfun) Date: Thu, 04 Jun 2015 13:04:19 -0400 Subject: =?UTF-8?B?0YHQstC+0LHQvtC00L3QvtC1INC/0YDQvtGB0YLRgNCw0L3RgdGC0LLQvg==?= Message-ID: <2efd6f77a85435ff4b6478022200a1b2.NginxMailingListRussian@forum.nginx.org> Здравствуйте, отправили меня к вам отсюда http://searchengines.guru/showthread.php?t=898497&page=7, сказали что с nginx мне сюда стучатся нужно...Буду благодарен всем откликнувшимся за любую помощь... В топике проблема описана сполна, но в двух словах как я понял nginx криво настроен и постоянно создает\удаляет огромное количество файлов, что приводит к "съеданию" всего свободного пространства.... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259382,259382#msg-259382 From nginx-forum at nginx.us Thu Jun 4 18:26:59 2015 From: nginx-forum at nginx.us (EuroHoster) Date: Thu, 04 Jun 2015 14:26:59 -0400 Subject: =?UTF-8?B?UmU6INGB0LLQvtCx0L7QtNC90L7QtSDQv9GA0L7RgdGC0YDQsNC90YHRgtCy0L4=?= In-Reply-To: <2efd6f77a85435ff4b6478022200a1b2.NginxMailingListRussian@forum.nginx.org> References: <2efd6f77a85435ff4b6478022200a1b2.NginxMailingListRussian@forum.nginx.org> Message-ID: <2fb3408f7c84b9ed134b3b2e7f3a773e.NginxMailingListRussian@forum.nginx.org> На SE zzzit вывод сделал неверный. Вы само показывали что у вас там всего 3 тыс файлов. Так что ищите дальше. Тем более что при рестарте nginx файлы не удаляются. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259382,259385#msg-259385 From nginx-forum at nginx.us Fri Jun 5 05:40:59 2015 From: nginx-forum at nginx.us (EuroHoster) Date: Fri, 05 Jun 2015 01:40:59 -0400 Subject: =?UTF-8?B?UmU6INGB0LLQvtCx0L7QtNC90L7QtSDQv9GA0L7RgdGC0YDQsNC90YHRgtCy0L4=?= In-Reply-To: <2efd6f77a85435ff4b6478022200a1b2.NginxMailingListRussian@forum.nginx.org> References: <2efd6f77a85435ff4b6478022200a1b2.NginxMailingListRussian@forum.nginx.org> Message-ID: <368e3a84d65c11800374f465dfbf85d1.NginxMailingListRussian@forum.nginx.org> Конфиг лучше весь выложите. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259382,259393#msg-259393 From tetsio.nainn at gmail.com Fri Jun 5 06:02:51 2015 From: tetsio.nainn at gmail.com (=?UTF-8?B?0Jwu0JAuINCc0L7RhdC90LDRh9C10LLRgdC60LjQuQ==?=) Date: Fri, 5 Jun 2015 15:02:51 +0900 Subject: =?UTF-8?B?UmU6INGB0LLQvtCx0L7QtNC90L7QtSDQv9GA0L7RgdGC0YDQsNC90YHRgtCy0L4=?= In-Reply-To: <368e3a84d65c11800374f465dfbf85d1.NginxMailingListRussian@forum.nginx.org> References: <2efd6f77a85435ff4b6478022200a1b2.NginxMailingListRussian@forum.nginx.org> <368e3a84d65c11800374f465dfbf85d1.NginxMailingListRussian@forum.nginx.org> Message-ID: Вроде действительно похоже, что файлы не закрываются перед удалением. Из-за этого система не "освобождает" место на диске. Только после перезагрузки.Кстати, у Вас какая версия nginx? не 0.1?) 2015-06-05 14:40 GMT+09:00 EuroHoster : > Конфиг лучше весь выложите. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,259382,259393#msg-259393 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- С ув. М.А. Мохначевский Отдел системного администрирования Группа компаний "Синет" к.т. (4112)219711 доб. 927 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Jun 5 09:37:49 2015 From: nginx-forum at nginx.us (anutonja) Date: Fri, 05 Jun 2015 05:37:49 -0400 Subject: =?UTF-8?B?0YDQsNC90LTQvtC80L3Ri9C1INC30L3QsNGH0LXQvdC40Y8gc3R1YiBzdGF0dXM=?= Message-ID: Добрый день! Стокнулись с каким-то аномальным поведением модуля stub_status (http://nginx.org/en/docs/http/ngx_http_stub_status_module.html). Вместо суммы коннектов он начал выдават значения то больше, то меньше: http://pastebin.com/E3A9v9EP Графики сразу поломались: http://inft.ly/jkWPQBy Видно, что это случилось одномоментно, но каких-либо изменений в конфигурации/в проекте в это время не было. Наблюдается сразу на всех наших 12 http серверах. Есть у кого-нибудь идеи? Спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259401,259401#msg-259401 From mdounin at mdounin.ru Fri Jun 5 13:47:57 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 5 Jun 2015 16:47:57 +0300 Subject: =?UTF-8?B?UmU6INGA0LDQvdC00L7QvNC90YvQtSDQt9C90LDRh9C10L3QuNGPIHN0dWIgc3Rh?= =?UTF-8?B?dHVz?= In-Reply-To: References: Message-ID: <20150605134756.GU26357@mdounin.ru> Hello! On Fri, Jun 05, 2015 at 05:37:49AM -0400, anutonja wrote: > Добрый день! > > Стокнулись с каким-то аномальным поведением модуля stub_status > (http://nginx.org/en/docs/http/ngx_http_stub_status_module.html). > > Вместо суммы коннектов он начал выдават значения то больше, то меньше: > http://pastebin.com/E3A9v9EP > > Графики сразу поломались: http://inft.ly/jkWPQBy Видно, что это случилось > одномоментно, но каких-либо изменений в конфигурации/в проекте в это время > не было. > > Наблюдается сразу на всех наших 12 http серверах. Есть у кого-нибудь идеи? Судя по всему у вас не завершена процедура обновления nginx'а и одновременно работают два nginx'а. Следут довести процедуру до конца и завершить старый nginx, послав QUIT старому мастеру. Подробности тут: http://nginx.org/ru/docs/control.html#upgrade -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Mon Jun 8 08:40:10 2015 From: nginx-forum at nginx.us (windos32) Date: Mon, 08 Jun 2015 04:40:10 -0400 Subject: =?UTF-8?B?0YHQv9C10YbRjdGE0LjRh9C10YHQutCw0Y8g0L/RgNC+0LHQu9C10LzQsCDRgSBy?= =?UTF-8?B?ZXVzZXBvcnQ=?= Message-ID: <01a42a590eb9b0c03c32aadb8a618109.NginxMailingListRussian@forum.nginx.org> Здравствуйте, у меня возникла спецэфическая проблема с reuseport. Я проксирую nginx`ом около 100 сайтов, каждый сайт имеет свою пару в listen ip:port, решил воспользоваться новой функцией reuseport, но при установке новой опции на половину сайтов, service nginx restart перестаёт работать, выдаёт ошибку [emerg] socket() ip:port failed (24: Too many open files). Я полагаю дело в том, что мастер процессу не хватает дескрипторов чтобы запуститься, т.к его показатели soft limit 1024, hard limit 4096. Как увеличить лимиты местер процесса или есть какой то другой способ обойти это? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259426,259426#msg-259426 From mdounin at mdounin.ru Mon Jun 8 15:15:25 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 8 Jun 2015 18:15:25 +0300 Subject: =?UTF-8?B?UmU6INGB0L/QtdGG0Y3RhNC40YfQtdGB0LrQsNGPINC/0YDQvtCx0LvQtdC80LAg?= =?UTF-8?B?0YEgcmV1c2Vwb3J0?= In-Reply-To: <01a42a590eb9b0c03c32aadb8a618109.NginxMailingListRussian@forum.nginx.org> References: <01a42a590eb9b0c03c32aadb8a618109.NginxMailingListRussian@forum.nginx.org> Message-ID: <20150608151525.GC26357@mdounin.ru> Hello! On Mon, Jun 08, 2015 at 04:40:10AM -0400, windos32 wrote: > Здравствуйте, у меня возникла спецэфическая проблема с reuseport. > Я проксирую nginx`ом около 100 сайтов, каждый сайт имеет свою пару в listen > ip:port, решил воспользоваться новой функцией reuseport, > но при установке новой опции на половину сайтов, service nginx restart Если у вас много listen-сокетов - то reuseport скорее не нужен, чем наоборот. Один из основных use case'ов для использования reuseport - это как раз ситуация, когда на одном сокете наблюдается большой поток входящих соединений, что вызывает lock contention в ядре на очереди соединений. > перестаёт работать, выдаёт ошибку [emerg] socket() ip:port failed (24: Too > many open files). Я полагаю дело в том, что мастер процессу не хватает > дескрипторов чтобы запуститься, т.к его показатели soft limit 1024, hard > limit 4096. Как увеличить лимиты местер процесса или есть какой то другой > способ обойти это? Где-то тут, например, есть рекомендации: http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/ -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Mon Jun 8 16:59:32 2015 From: nginx-forum at nginx.us (windos32) Date: Mon, 08 Jun 2015 12:59:32 -0400 Subject: =?UTF-8?B?UmU6INGB0L/QtdGG0Y3RhNC40YfQtdGB0LrQsNGPINC/0YDQvtCx0LvQtdC80LAg?= =?UTF-8?B?0YEgcmV1c2Vwb3J0?= In-Reply-To: <20150608151525.GC26357@mdounin.ru> References: <20150608151525.GC26357@mdounin.ru> Message-ID: Спасибо. Имеет ли смысл на самых посещаемых listen-сокетах (100к в сутки) использовать reuseport, а на остальных нет? По поводу лимита мастер процесса, все эти рекомендации я давно сделал, вот что выдает команда su - nginx -c 'ulimit -aHS' -s '/bin/bash' su - nginx -c 'ulimit -aHS' -s '/bin/bash' core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 95565 max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 10240 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 4096 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Но команда for pid in `pidof nginx`; do echo "$(< /proc/$pid/cmdline)"; egrep 'files|Limit' /proc/$pid/limits; echo "Currently open files: $(ls -1 /proc/$pid/fd | wc -l)"; echo; done выдает nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf Limit Soft Limit Hard Limit Units Max open files 1024 4096 files Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259426,259433#msg-259433 From mdounin at mdounin.ru Mon Jun 8 19:05:46 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 8 Jun 2015 22:05:46 +0300 Subject: =?UTF-8?B?UmU6INGB0L/QtdGG0Y3RhNC40YfQtdGB0LrQsNGPINC/0YDQvtCx0LvQtdC80LAg?= =?UTF-8?B?0YEgcmV1c2Vwb3J0?= In-Reply-To: References: <20150608151525.GC26357@mdounin.ru> Message-ID: <20150608190546.GH26357@mdounin.ru> Hello! On Mon, Jun 08, 2015 at 12:59:32PM -0400, windos32 wrote: > Спасибо. > Имеет ли смысл на самых посещаемых listen-сокетах (100к в сутки) > использовать reuseport, а на остальных нет? Если вы считаете соединения за сутки, то ответ нет. Разница в производительности начинает быть заметной при десятках тысяч соединений в секунду. > По поводу лимита мастер процесса, все эти рекомендации я давно сделал, вот > что выдает команда su - nginx -c 'ulimit -aHS' -s '/bin/bash' Основной процесс обычно работает под рутом, так что лимиты пользователя nginx на нём вряд ли скажутся. Впрочем, даже если скажутся, то по прежнему остаётся проблема: лимит должен кто-то поставить. Обычно это делает PAM из /etc/security/limits.conf, но для демонов он (опять же обычно) не учавствует в процессе. Проще всего - явно звать ulimit в init-скрипте nginx'а. -- Maxim Dounin http://nginx.org/ From eugene.peregudov at gmail.com Tue Jun 9 08:13:32 2015 From: eugene.peregudov at gmail.com (Eugene Peregudov) Date: Tue, 9 Jun 2015 14:13:32 +0600 Subject: =?UTF-8?B?0J7QsdGA0LDQsdC+0YLQutCwIHNzbF9zdGFwbGluZyDQv9GA0Lgg0L3QtdC00L4=?= =?UTF-8?B?0YHRgtGD0L/QvdC+0YHRgtC4IG9jc3At0YDQtdGB0L/QvtC90LTQtdGA0LA=?= Message-ID: Добрый день! Установлен nginx-frontend, терминирующий ssl\tls с настроенным ssl_stapling: # SSL secure session ssl_session_timeout 5m; ssl_session_cache shared:SSL:50m; # SSL cipher suite settings ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+ ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_dhparam /etc/pki/tls/private/dhparam.pem; # OCSP Stapling ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/pki/tls/private/trust-ca-chain-globalsign.pem; resolver x.x.x.x; Недавно словил глюк (или особенность) работы ssl_stapling. В вышеописанной конфигурации nginx должен самостоятельно опрашивать ocsp-респондер УЦ (в частности у меня OCSP - URI: http://ocsp2.globalsign.com/gsorganizationvalsha2g2) и прикреплять ocsp-ответы к tls-сессии (чтобы клиент не тратил время на самостоятельное обращение к ocsp-респондеру). Однако, при длительной недоступности связи с ocsp-ренспондером некоторые внутренние клиенты с браузеров Firefox (и только c них) ловят ошибку "OCSP-ответ содержит устаревшую информацию. (Код ошибки: sec_error_ocsp_old_response)", что наводит на мысль о том, что возможно nginx отдает клиентам устаревший ocsp-ответ (последний сохраненный на момент доступности ocsp-респондера УЦ). Если nginx перезапустить, то в свежеустановленной tls-сессии ocsp-ответ уже не прикрепляется (OCSP response: no response sent) и Firefox ресурс успешно открывает. Очевидным решением является конечно же отключение проверки ocsp по умолчанию в настройках FF. Однако хотелось бы уточнить из первых рук: - кеширует ли nginx ocsp-ответы? - если кеширует, то должен ли просто отдавать последний сохраненный у себя ocsp-ответ или все же проверять время и не посылать протухший ocsp-ответ? Версия mainline из официального репозитория: nginx version: nginx/1.9.1 built by gcc 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC) built with OpenSSL 1.0.1e-fips 11 Feb 2013 TLS SNI support enabled -- ------------------------------------ With best regards, Eugene Peregudov Mailto: eugene.peregudov at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Jun 9 08:53:24 2015 From: nginx-forum at nginx.us (windos32) Date: Tue, 09 Jun 2015 04:53:24 -0400 Subject: =?UTF-8?B?UmU6INGB0L/QtdGG0Y3RhNC40YfQtdGB0LrQsNGPINC/0YDQvtCx0LvQtdC80LAg?= =?UTF-8?B?0YEgcmV1c2Vwb3J0?= In-Reply-To: <20150608190546.GH26357@mdounin.ru> References: <20150608190546.GH26357@mdounin.ru> Message-ID: <1bd7fb356e8da7f068e2c84715624829.NginxMailingListRussian@forum.nginx.org> Дело в том что в limits.conf и для root и для nginx лимит файлов очень большой стоит, явно не 4096 который упорно продолжает выдавать мастер процесс. Пробовал сделать service nginx restart ulimit -n 60000, результата не получил. Подскажите пожалуйста куда именно в init прописать эти ulimit -n 60000 строки? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259426,259468#msg-259468 From nginx-forum at nginx.us Tue Jun 9 09:14:10 2015 From: nginx-forum at nginx.us (windos32) Date: Tue, 09 Jun 2015 05:14:10 -0400 Subject: =?UTF-8?B?UmU6INGB0L/QtdGG0Y3RhNC40YfQtdGB0LrQsNGPINC/0YDQvtCx0LvQtdC80LAg?= =?UTF-8?B?0YEgcmV1c2Vwb3J0?= In-Reply-To: <1bd7fb356e8da7f068e2c84715624829.NginxMailingListRussian@forum.nginx.org> References: <20150608190546.GH26357@mdounin.ru> <1bd7fb356e8da7f068e2c84715624829.NginxMailingListRussian@forum.nginx.org> Message-ID: <3bbc2d3991ad2e49479f918a649fab87.NginxMailingListRussian@forum.nginx.org> Пробовал даже ради эксперемента в nginx.conf добавить пользователя root вместо nginx, всё равно 4096 лимит мастер процесса. версия ОС centos 7.1 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259426,259469#msg-259469 From mdounin at mdounin.ru Tue Jun 9 13:05:54 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 9 Jun 2015 16:05:54 +0300 Subject: =?UTF-8?B?UmU6INGB0L/QtdGG0Y3RhNC40YfQtdGB0LrQsNGPINC/0YDQvtCx0LvQtdC80LAg?= =?UTF-8?B?0YEgcmV1c2Vwb3J0?= In-Reply-To: <1bd7fb356e8da7f068e2c84715624829.NginxMailingListRussian@forum.nginx.org> References: <20150608190546.GH26357@mdounin.ru> <1bd7fb356e8da7f068e2c84715624829.NginxMailingListRussian@forum.nginx.org> Message-ID: <20150609130554.GL26357@mdounin.ru> Hello! On Tue, Jun 09, 2015 at 04:53:24AM -0400, windos32 wrote: > Дело в том что в limits.conf и для root и для nginx лимит файлов очень > большой стоит, явно не 4096 который упорно продолжает выдавать мастер > процесс. Наблюдаемые 1024/4096 - это ограничение по-умолчанию из ядра. Подробно о том, откуда могут появляться limit'ы, рассказывается, например, тут: http://serverfault.com/questions/356962/where-are-the-default-ulimit-values-set-linux-centos/485277#485277 В вашем случае речь явно не идёт о том, что pam_limits пытался что-то поставить. Что ожидаемо - по умолчанию он работает только для внешних логинов, и наверное это правильно. Хотя и не очень удобно с точки зрения установки лимитов. > Пробовал сделать service nginx restart ulimit -n 60000, результата > не получил. Подскажите пожалуйста куда именно в init прописать эти ulimit -n > 60000 строки? Надёжнее всего - в init-скрипт nginx'а, обычно /etc/init.d/nginx. Если вам просто проверить один раз - то можно банально руками поставить перед (пере)запуском - "ulimit -n 65535 && service nginx restart". -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Tue Jun 9 13:10:30 2015 From: nginx-forum at nginx.us (S.A.N) Date: Tue, 09 Jun 2015 09:10:30 -0400 Subject: =?UTF-8?B?JGFyZ3MgLSDRgdC00LXQu9Cw0YLRjCDQvdC+0YDQvNCw0LvQuNC30L7QstCw0L0=?= =?UTF-8?B?0L3Ri9C8?= Message-ID: <76929acd157e2f2d8fd6716ff8aca2f5.NginxMailingListRussian@forum.nginx.org> Есть нормализованная переменная $uri, но нет нормализованной $args, но она реально нужна, попробую объяснить. Наш ключ к кешу и REQUEST_URI к бекенду = $uri$is_args$args, нормализованный $uri очень удобен, но не нормализованный $args создает проблемы - дубликаты в кеше и флуд на бекенд. Например в наших логах, есть такие запросы: /?id=1&id=100 /?id=2&id=100 /?id=3&id=100 Как видите, перемененная id указанна два раза, в РНР будет значения $_GET["id"] = 100, эти запросы генерят боты, возможно это оплаченный HTTP флуд, все эти запросы идут на бекенд, отрабатывается бизнес логика по id=100, кеш пухнет, бекенд нагружен флудом. Сейчас мы на бекенде нормализуем QUERY_STRING и делаем редирект, но правильней если бы ответ брался из кеша Nginx, для этого нужно чтобы в ключе кеша был нормализованный $args. Кроме ботов, есть ещё много случаев, например разный способ юрл кодировки /?q=мир+май /?q=мир%20;май /?q=мир май // UTF-8 Разная последовательность одинаковых параметров: /?sort=desc&filter=price /?filter=price&sort=desc /?filter=price&sort=desc& Это все уменьшает эффективность кеша. Будет очень полезно если $args станет нормализованным, а в $query_string оставить первоначальное значения, тогда каждый сможет использовать то что ему нужно. Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259474,259474#msg-259474 From nginx-forum at nginx.us Tue Jun 9 13:25:30 2015 From: nginx-forum at nginx.us (windos32) Date: Tue, 09 Jun 2015 09:25:30 -0400 Subject: =?UTF-8?B?UmU6INGB0L/QtdGG0Y3RhNC40YfQtdGB0LrQsNGPINC/0YDQvtCx0LvQtdC80LAg?= =?UTF-8?B?0YEgcmV1c2Vwb3J0?= In-Reply-To: <20150609130554.GL26357@mdounin.ru> References: <20150609130554.GL26357@mdounin.ru> Message-ID: <53245dec880f5ce7c7eca4cd72a4357e.NginxMailingListRussian@forum.nginx.org> Вообщем нашёл как сделать, редактирование init совсем не помогало. Дело в особенности centos 7, для тех кому интересно, решение limit for master process nginx в centos 7: открываем файл /usr/lib/systemd/system/nginx.service добавляем сразу под [Service] строку LimitNOFILE=60000, сохраняем. выполняем systemctl daemon-reload, затем service nginx restart. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259426,259475#msg-259475 From dovg at dovg.ru Tue Jun 9 13:27:39 2015 From: dovg at dovg.ru (Evgeny Kokovikhin) Date: Tue, 9 Jun 2015 16:27:39 +0300 Subject: =?UTF-8?B?UmU6ICRhcmdzIC0g0YHQtNC10LvQsNGC0Ywg0L3QvtGA0LzQsNC70LjQt9C+0LI=?= =?UTF-8?B?0LDQvdC90YvQvA==?= In-Reply-To: <76929acd157e2f2d8fd6716ff8aca2f5.NginxMailingListRussian@forum.nginx.org> References: <76929acd157e2f2d8fd6716ff8aca2f5.NginxMailingListRussian@forum.nginx.org> Message-ID: > Например в наших логах, есть такие запросы: > /?id=1&id=100 > /?id=2&id=100 > /?id=3&id=100 > > Как видите, перемененная id указанна два раза, в РНР будет значения > $_GET["id"] = 100, эти запросы генерят боты, возможно это оплаченный HTTP > флуд, все эти запросы идут на бекенд, отрабатывается бизнес логика по > id=100, кеш пухнет, бекенд нагружен флудом. > Это разные запросы. Кроме php есть же и другие языки. Например в java и RoR массивы передаются в GET именно так как вы написали. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Jun 9 13:36:24 2015 From: nginx-forum at nginx.us (S.A.N) Date: Tue, 09 Jun 2015 09:36:24 -0400 Subject: =?UTF-8?B?UmU6ICRhcmdzIC0g0YHQtNC10LvQsNGC0Ywg0L3QvtGA0LzQsNC70LjQt9C+0LI=?= =?UTF-8?B?0LDQvdC90YvQvA==?= In-Reply-To: References: Message-ID: <734b1c9c04a389f0010fd62039722978.NginxMailingListRussian@forum.nginx.org> > Это разные запросы. Кроме php есть же и другие языки. Например в java > и RoR > массивы передаются в GET именно так как вы написали. В java и RoR, чтобы передать масив id, нужно писать id=1&id=100? Жаль конечно, в РНР масивы передаются в другом формате id[]=1&id[]=100 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259474,259477#msg-259477 From mdounin at mdounin.ru Tue Jun 9 13:52:11 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 9 Jun 2015 16:52:11 +0300 Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBzc2xfc3RhcGxpbmcg0L/RgNC4INC90LU=?= =?UTF-8?B?0LTQvtGB0YLRg9C/0L3QvtGB0YLQuCBvY3NwLdGA0LXRgdC/0L7QvdC00LU=?= =?UTF-8?B?0YDQsA==?= In-Reply-To: References: Message-ID: <20150609135211.GN26357@mdounin.ru> Hello! On Tue, Jun 09, 2015 at 02:13:32PM +0600, Eugene Peregudov wrote: > Добрый день! > > Установлен nginx-frontend, терминирующий ssl\tls с настроенным ssl_stapling: > > # SSL secure session > ssl_session_timeout 5m; > ssl_session_cache shared:SSL:50m; > > # SSL cipher suite settings > ssl_ciphers > 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+ > ssl_protocols TLSv1 TLSv1.1 TLSv1.2; > ssl_prefer_server_ciphers on; > ssl_dhparam /etc/pki/tls/private/dhparam.pem; > > # OCSP Stapling > ssl_stapling on; > ssl_stapling_verify on; > ssl_trusted_certificate /etc/pki/tls/private/trust-ca-chain-globalsign.pem; > resolver x.x.x.x; > > Недавно словил глюк (или особенность) работы ssl_stapling. > > В вышеописанной конфигурации nginx должен самостоятельно опрашивать > ocsp-респондер УЦ (в частности у меня OCSP - URI: > http://ocsp2.globalsign.com/gsorganizationvalsha2g2) и прикреплять > ocsp-ответы к tls-сессии (чтобы клиент не тратил время на самостоятельное > обращение к ocsp-респондеру). > > Однако, при длительной недоступности связи с ocsp-ренспондером некоторые > внутренние клиенты с браузеров Firefox (и только c них) ловят ошибку > "OCSP-ответ содержит устаревшую информацию. (Код ошибки: > sec_error_ocsp_old_response)", что наводит на мысль о том, что возможно > nginx отдает клиентам устаревший ocsp-ответ (последний сохраненный на > момент доступности ocsp-респондера УЦ). Если nginx перезапустить, то в > свежеустановленной tls-сессии ocsp-ответ уже не прикрепляется (OCSP > response: no response sent) и Firefox ресурс успешно открывает. > > Очевидным решением является конечно же отключение проверки ocsp по > умолчанию в настройках FF. > Однако хотелось бы уточнить из первых рук: > - кеширует ли nginx ocsp-ответы? Да, и по другому не умеет. > - если кеширует, то должен ли просто отдавать последний сохраненный у себя > ocsp-ответ или все же проверять время и не посылать протухший ocsp-ответ? С теоретической точки зрения - разницы нет. Браузер так или иначе ответ проверит, и если он ему не понравится - может банально проигнорировать. Зачем Firefox поступает иначе (и в RFC 6066 написано иначе) - тайна сия великая есть, смысла в этом не видно, а проблемы очевидны. У нас есть тикет про это: http://trac.nginx.org/nginx/ticket/425 И буквально на днях в nginx-devel@ пробегали патчи: http://mailman.nginx.org/pipermail/nginx-devel/2015-June/007001.html Если есть желание потестировать - буду благодарен. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Wed Jun 10 09:22:56 2015 From: nginx-forum at nginx.us (dant4z) Date: Wed, 10 Jun 2015 05:22:56 -0400 Subject: =?UTF-8?B?0J7RgtC80LXQvdCwIGVycm9yIHBhZ2U=?= Message-ID: <6dc1d7d811fe46dfcfa0bd20a2e1c252.NginxMailingListRussian@forum.nginx.org> Всем добра! Есть ли возможность отменить унаследованную директиву error_page с уровня server (вернуться к поведению по умолчанию) в одном конкретном location? В этом location бэкенд возвращает код 403 и нужно отдать тело, которое он прислал, а не заменять его на заглушку. В других же надо оставить заглушку. Очень неудобно было бы прописывать для всех, кроме одного, location одно и тоже. Заранее спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259483,259483#msg-259483 From nginx-forum at nginx.us Wed Jun 10 10:02:42 2015 From: nginx-forum at nginx.us (warzoni) Date: Wed, 10 Jun 2015 06:02:42 -0400 Subject: =?UTF-8?B?JHNlbnQgaHR0cCAuLi4g0L3QtSAg0YDQsNCx0L7RgtCw0LXRgi4=?= Message-ID: <54e9c43750d52bde3639c73a384008ee.NginxMailingListRussian@forum.nginx.org> Здравствуйте помогите с проблемой, нам надо перехватить свой header - и передать в управления if Вроде как есть переменная $sent_http - Но почему она не работает ? Делали так. ($sent_http_ignore_mobile_redirect) { set $block 0; } Но мы получаем ошибку. хотя описания есть $sent_http http://wiki.nginx.org/HttpCoreModule#.24sent_http Что мы делаем не так ? p.s Спасибо заранее. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259487,259487#msg-259487 From onokonem at gmail.com Wed Jun 10 10:27:10 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 10 Jun 2015 13:27:10 +0300 Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: <54e9c43750d52bde3639c73a384008ee.NginxMailingListRussian@forum.nginx.org> References: <54e9c43750d52bde3639c73a384008ee.NginxMailingListRussian@forum.nginx.org> Message-ID: 2015-06-10 13:02 GMT+03:00 warzoni : > Здравствуйте помогите с проблемой, нам надо перехватить свой header - и > передать в управления if > > Вроде как есть переменная $sent_http - Но почему она не работает ? $sent_http_имяпроизвольное поле заголовка ответа; последняя часть имени переменной соответствует имени поля, приведённому к нижнему регистру, с заменой символов тире на символы подчёркивания ответа, карл... if обрабатывает заголовки запроса. From igor at sysoev.ru Wed Jun 10 10:58:34 2015 From: igor at sysoev.ru (Igor Sysoev) Date: Wed, 10 Jun 2015 13:58:34 +0300 Subject: =?UTF-8?B?UmU6INCe0YLQvNC10L3QsCBlcnJvciBwYWdl?= In-Reply-To: <6dc1d7d811fe46dfcfa0bd20a2e1c252.NginxMailingListRussian@forum.nginx.org> References: <6dc1d7d811fe46dfcfa0bd20a2e1c252.NginxMailingListRussian@forum.nginx.org> Message-ID: On 10 Jun 2015, at 12:22, dant4z wrote: > Есть ли возможность отменить унаследованную директиву error_page с уровня > server (вернуться к поведению по умолчанию) в одном конкретном location? В > этом location бэкенд возвращает код 403 и нужно отдать тело, которое он > прислал, а не заменять его на заглушку. В других же надо оставить заглушку. > Очень неудобно было бы прописывать для всех, кроме одного, location одно и > тоже. http://nginx.org/ru/docs/http/ngx_http_core_module.html#error_page Директивы error_page наследуются с предыдущего уровня при условии, что на данном уровне не заданы свои директивы error_page. -- Igor Sysoev http://nginx.com From nginx-forum at nginx.us Wed Jun 10 11:39:37 2015 From: nginx-forum at nginx.us (warzoni) Date: Wed, 10 Jun 2015 07:39:37 -0400 Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: References: Message-ID: <9f559f44ad115039d24595c4e0ca3cbc.NginxMailingListRussian@forum.nginx.org> Спасибо за ответ ! Если можете помогите советом, как увидеть кастомный заголовок ответа сервера "респонсе хедер" в нгинксе - и передать в управления if реврайта.. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259491,259495#msg-259495 From wangsamp at gmail.com Wed Jun 10 11:46:58 2015 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Wed, 10 Jun 2015 14:46:58 +0300 (EEST) Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: <9f559f44ad115039d24595c4e0ca3cbc.NginxMailingListRussian@forum.nginx.org> References: <9f559f44ad115039d24595c4e0ca3cbc.NginxMailingListRussian@forum.nginx.org> Message-ID: Today Jun 10, 2015 at 07:39 warzoni wrote: > Спасибо за ответ ! Если можете помогите советом, как увидеть кастомный > заголовок ответа сервера "респонсе хедер" в нгинксе - и передать в > управления if реврайта.. В rewrite - никак - эта фаза работает ДО отправки запроса к backend. -- WNGS-RIPE From nginx-forum at nginx.us Wed Jun 10 11:58:59 2015 From: nginx-forum at nginx.us (dant4z) Date: Wed, 10 Jun 2015 07:58:59 -0400 Subject: =?UTF-8?B?UmU6INCe0YLQvNC10L3QsCBlcnJvciBwYWdl?= In-Reply-To: References: Message-ID: <865764c480f0c4aa37f785af6f8ef506.NginxMailingListRussian@forum.nginx.org> Igor Sysoev Wrote: ------------------------------------------------------- > On 10 Jun 2015, at 12:22, dant4z wrote: > > > Есть ли возможность отменить унаследованную директиву error_page с > уровня > > server (вернуться к поведению по умолчанию) в одном конкретном > location? В > > этом location бэкенд возвращает код 403 и нужно отдать тело, которое > он > > прислал, а не заменять его на заглушку. В других же надо оставить > заглушку. > > Очень неудобно было бы прописывать для всех, кроме одного, location > одно и > > тоже. > > http://nginx.org/ru/docs/http/ngx_http_core_module.html#error_page > > Директивы error_page наследуются с предыдущего уровня при условии, что > на > данном уровне не заданы свои директивы error_page. Да, в документации я видел, что могу переопределить ее. Но как мне переопределить ее, чтобы вернуть поведение по умолчанию? Переопределить я могу лишь перенаправив запрос или подменив ответ. А как сохранить ответ бэкенда? есть или такая возможность? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259494,259497#msg-259497 From nginx-forum at nginx.us Wed Jun 10 12:02:47 2015 From: nginx-forum at nginx.us (warzoni) Date: Wed, 10 Jun 2015 08:02:47 -0400 Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: References: Message-ID: <894d0a87fc18f02b1ccd5827d8bf49e8.NginxMailingListRussian@forum.nginx.org> хорошо понимаю, но а как-же управления кешем работает X-Accel-, с php nginx понимает и управляет кешем , мы так-же хотим передать с странице что-либо и сказать nginx что это не мобильный сайт и посылать на нормальную версию сайта, это разве не возможно ? может есть идеи ? буду рад любому совету. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259491,259498#msg-259498 From wangsamp at gmail.com Wed Jun 10 12:07:10 2015 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Wed, 10 Jun 2015 15:07:10 +0300 (EEST) Subject: =?UTF-8?B?UmU6INCe0YLQvNC10L3QsCBlcnJvciBwYWdl?= In-Reply-To: <865764c480f0c4aa37f785af6f8ef506.NginxMailingListRussian@forum.nginx.org> References: <865764c480f0c4aa37f785af6f8ef506.NginxMailingListRussian@forum.nginx.org> Message-ID: Today Jun 10, 2015 at 07:58 dant4z wrote: > Да, в документации я видел, что могу переопределить ее. Но как мне > переопределить ее, чтобы вернуть поведение по умолчанию? Переопределить я > могу лишь перенаправив запрос или подменив ответ. А как сохранить ответ > бэкенда? есть или такая возможность? Не сохранить ответ, а отключить перехват. Для этого есть proxy_intercept_errors, fastcgi_intercept_errors и т.д. -- WNGS-RIPE From nginx-forum at nginx.us Wed Jun 10 12:19:47 2015 From: nginx-forum at nginx.us (anutonja) Date: Wed, 10 Jun 2015 08:19:47 -0400 Subject: =?UTF-8?B?UmU6INGA0LDQvdC00L7QvNC90YvQtSDQt9C90LDRh9C10L3QuNGPIHN0dWIgc3Rh?= =?UTF-8?B?dHVz?= In-Reply-To: <20150605134756.GU26357@mdounin.ru> References: <20150605134756.GU26357@mdounin.ru> Message-ID: >Судя по всему у вас не завершена процедура обновления nginx'а и одновременно работают два nginx'а. Везде проверила- только 1 мастер: http://inft.ly/pDB2s4p а значения всё также гуляют.. >Hello! > >On Fri, Jun 05, 2015 at 05:37:49AM -0400, anutonja wrote: > >> Добрый день! >> >> Стокнулись с каким-то аномальным поведением модуля stub_status >> (http://nginx.org/en/docs/http/ngx_http_stub_status_module.html). >> >> Вместо суммы коннектов он начал выдават значения то больше, то меньше: >> http://pastebin.com/E3A9v9EP >> >> Графики сразу поломались: http://inft.ly/jkWPQBy Видно, что это случилось >> одномоментно, но каких-либо изменений в конфигурации/в проекте в это время >> не было. >> >> Наблюдается сразу на всех наших 12 http серверах. Есть у кого-нибудь идеи? > >Судя по всему у вас не завершена процедура обновления nginx'а и >одновременно работают два nginx'а. Следут довести процедуру до >конца и завершить старый nginx, послав QUIT старому мастеру. >Подробности тут: > >http://nginx.org/ru/docs/control.html#upgrade > >-- >Maxim Dounin >http://nginx.org/ > >_______________________________________________ >nginx-ru mailing list >nginx-ru at nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259404,259500#msg-259500 From nginx-forum at nginx.us Wed Jun 10 12:20:21 2015 From: nginx-forum at nginx.us (dant4z) Date: Wed, 10 Jun 2015 08:20:21 -0400 Subject: =?UTF-8?B?UmU6INCe0YLQvNC10L3QsCBlcnJvciBwYWdl?= In-Reply-To: References: Message-ID: <08120becb5fc19a7b94973200cc997e1.NginxMailingListRussian@forum.nginx.org> Oleksandr V. Typlyns'kyi Wrote: ------------------------------------------------------- > Today Jun 10, 2015 at 07:58 dant4z wrote: > > > Да, в документации я видел, что могу переопределить ее. Но как мне > > переопределить ее, чтобы вернуть поведение по умолчанию? > Переопределить я > > могу лишь перенаправив запрос или подменив ответ. А как сохранить > ответ > > бэкенда? есть или такая возможность? > > Не сохранить ответ, а отключить перехват. > Для этого есть proxy_intercept_errors, fastcgi_intercept_errors и > т.д. Точно, подошло, спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259494,259501#msg-259501 From onokonem at gmail.com Wed Jun 10 12:21:15 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 10 Jun 2015 15:21:15 +0300 Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: <894d0a87fc18f02b1ccd5827d8bf49e8.NginxMailingListRussian@forum.nginx.org> References: <894d0a87fc18f02b1ccd5827d8bf49e8.NginxMailingListRussian@forum.nginx.org> Message-ID: > сказать nginx что это не мобильный сайт и посылать на нормальную версию > сайта, это разве не возможно ? может есть идеи ? буду рад любому совету можно отвечать с бекенда специальным кодом, 418, к примеру а в nginx организовать отдельную обработку для таких "ошибок" From nginx-forum at nginx.us Wed Jun 10 12:24:38 2015 From: nginx-forum at nginx.us (warzoni) Date: Wed, 10 Jun 2015 08:24:38 -0400 Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: References: Message-ID: <1a85b1e598ce1133d47e7f53776e8d7d.NginxMailingListRussian@forum.nginx.org> Огромное спасибо и как это мы упустили.. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259491,259503#msg-259503 From wangsamp at gmail.com Wed Jun 10 12:24:40 2015 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Wed, 10 Jun 2015 15:24:40 +0300 (EEST) Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: <894d0a87fc18f02b1ccd5827d8bf49e8.NginxMailingListRussian@forum.nginx.org> References: <894d0a87fc18f02b1ccd5827d8bf49e8.NginxMailingListRussian@forum.nginx.org> Message-ID: Today Jun 10, 2015 at 08:02 warzoni wrote: > хорошо понимаю, но а как-же управления кешем работает X-Accel-, с php nginx > понимает и управляет кешем , мы так-же хотим передать с странице что-либо и Определение брать-ли ответ из кеша работает до запроса к бэкенду и есть только то, что пришло в запросе от клиента. Сохранение в кеш идёт после получения ответа и тут уже есть заголовки ответа. Специальные заголовки - это специальные заголовки. Не нужно мешать в одну кучу коней и людей. > сказать nginx что это не мобильный сайт и посылать на нормальную версию > сайта, это разве не возможно ? может есть идеи ? буду рад любому совету. Мобильный или нет важно не серверу, а клиенту. Вот пусть код и отдаёт редирект клиенту (код ответа 302). -- WNGS-RIPE From nginx-forum at nginx.us Wed Jun 10 12:48:03 2015 From: nginx-forum at nginx.us (warzoni) Date: Wed, 10 Jun 2015 08:48:03 -0400 Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: References: Message-ID: Прошу извинить я поспешил с выводом. опишу более подробно. У нас есть мобильная версия основного сайта, который использует кеш нгинкса. Определением мобильников и редиректами туда занимается нгинкс. Необходимо сделать механизм, с помощью которого можно сообщить нгинксу о том, что мобильной версии конкретной страницы нету, и редирект совершать не нужно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259491,259506#msg-259506 From nginx-forum at nginx.us Wed Jun 10 14:01:50 2015 From: nginx-forum at nginx.us (warzoni) Date: Wed, 10 Jun 2015 10:01:50 -0400 Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: References: Message-ID: Ув. Я вас прошу помогите, ну нам необходимо что бы nginx прочитал наши данные для выполнения механизма. дайте совет.. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259491,259509#msg-259509 From nginx-forum at nginx.us Wed Jun 10 14:03:54 2015 From: nginx-forum at nginx.us (warzoni) Date: Wed, 10 Jun 2015 10:03:54 -0400 Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: References: Message-ID: Прошу извинить я поспешил с выводом. опишу более подробно. У нас есть мобильная версия основного сайта, который использует кеш нгинкса. Определением мобильников и редиректами туда занимается нгинкс. Необходимо сделать механизм, с помощью которого можно сообщить нгинксу о том, что мобильной версии конкретной страницы нету, и редирект совершать не нужно. warzoni Wrote: ------------------------------------------------------- > Ув. Я вас прошу помогите, ну нам необходимо что бы nginx прочитал наши > данные для выполнения механизма. дайте совет.. Извините за офф топики. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259491,259510#msg-259510 From mdounin at mdounin.ru Wed Jun 10 14:50:56 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 10 Jun 2015 17:50:56 +0300 Subject: =?UTF-8?B?UmU6INGA0LDQvdC00L7QvNC90YvQtSDQt9C90LDRh9C10L3QuNGPIHN0dWIgc3Rh?= =?UTF-8?B?dHVz?= In-Reply-To: References: <20150605134756.GU26357@mdounin.ru> Message-ID: <20150610145056.GB26357@mdounin.ru> Hello! On Wed, Jun 10, 2015 at 08:19:47AM -0400, anutonja wrote: > >Судя по всему у вас не завершена процедура обновления nginx'а и > одновременно работают два nginx'а. > > Везде проверила- только 1 мастер: http://inft.ly/pDB2s4p а значения всё > также гуляют.. Если серверов более одного - имеет смысл для начала убедиться, что ваши запросы попадают в правильный блок server{}, а не проксируются на другие сервера. Проще всего это сделать, добавив в нужный блок server{} специальный location с "return 200 passed;" или аналогичным образом. -- Maxim Dounin http://nginx.org/ From wangsamp at gmail.com Wed Jun 10 17:13:12 2015 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Wed, 10 Jun 2015 20:13:12 +0300 (EEST) Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: References: Message-ID: Today Jun 10, 2015 at 08:48 warzoni wrote: > Прошу извинить я поспешил с выводом. опишу более подробно. > > У нас есть мобильная версия основного сайта, который использует кеш нгинкса. > Определением мобильников и редиректами туда занимается нгинкс. Необходимо > сделать механизм, с помощью которого можно сообщить нгинксу о том, что > мобильной версии конкретной страницы нету, и редирект совершать не нужно. Если редирект делает nginx правилами rewrite, то работает это до каких-либо запросов к бэкэнду. Если множество таких страниц заранее известно, то нужно учесть эти URI в правилах редиректа. Если же нет, то вывод, думаю, очевиден - делать перенаправление в коде, который отлично знает про версии страниц. Пройти мимо кеша для мобильных клиентов поможет cache_bypass. Если кешируете и редиректы, то аналогичные переменные нужны в no_cache или как часть cache_key. Переменные задавать по условиям для редиректов через map или if+set. -- WNGS-RIPE From nginx-forum at nginx.us Thu Jun 11 08:32:23 2015 From: nginx-forum at nginx.us (warzoni) Date: Thu, 11 Jun 2015 04:32:23 -0400 Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: References: Message-ID: <961e40201d4c29104ff72443b9dc5f41.NginxMailingListRussian@forum.nginx.org> Oleksandr V. Typlyns'kyi Wrote: ------------------------------------------------------- > Today Jun 10, 2015 at 08:48 warzoni wrote: > > > Прошу извинить я поспешил с выводом. опишу более подробно. > > > > У нас есть мобильная версия основного сайта, который использует кеш > нгинкса. > > Определением мобильников и редиректами туда занимается нгинкс. > Необходимо > > сделать механизм, с помощью которого можно сообщить нгинксу о том, > что > > мобильной версии конкретной страницы нету, и редирект совершать не > нужно. > > Если редирект делает nginx правилами rewrite, то работает это до > каких-либо запросов к бэкэнду. Если множество таких страниц заранее > известно, то нужно учесть эти URI в правилах редиректа. Если же нет, > то > вывод, думаю, очевиден - делать перенаправление в коде, который > отлично > знает про версии страниц. > Пройти мимо кеша для мобильных клиентов поможет cache_bypass. > Если кешируете и редиректы, то аналогичные переменные нужны в > no_cache > или как часть cache_key. > Переменные задавать по условиям для редиректов через map или if+set. > > -- > WNGS-RIPE > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Да это понятно, но у нас интересная ситуация, сайт основной сидит в кеше nginx, а когда нам надо сделать что бы мобильный пользователь смотрел полную страницу сайта, а не мобильную, то миханизм даже если мы установим в пхп просмотра полной версии не срабатывает. Так как сайт в кеше и пока он не очистится код не сработает. и пользователь будет редиректится на мобильную версию по правилам nginx. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259491,259528#msg-259528 From juriy.foboss at gmail.com Thu Jun 11 09:26:36 2015 From: juriy.foboss at gmail.com (Juriy Strashnov) Date: Thu, 11 Jun 2015 12:26:36 +0300 Subject: =?UTF-8?B?0J/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgU1NUUA==?= Message-ID: Коллеги, добрый день! Подскажите, есть ли в Nginx возможность проксировать SSTP-трафик? http://blogs.technet.com/b/rrasblog/archive/2007/03/07/configuring-sstp-in-a-reverse-proxy-scenario.aspx -- Best regards, Juriy Strashnov E-mail: j.strashnov at me.com Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sytar.alex at gmail.com Thu Jun 11 11:28:11 2015 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Thu, 11 Jun 2015 14:28:11 +0300 Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: <961e40201d4c29104ff72443b9dc5f41.NginxMailingListRussian@forum.nginx.org> References: <961e40201d4c29104ff72443b9dc5f41.NginxMailingListRussian@forum.nginx.org> Message-ID: 11 июня 2015 г., 11:32 пользователь warzoni написал: > Так как сайт в кеше и пока он не > очистится код не сработает > Можно ведь один кеш для полной версии иметь, и один для мобильной -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Jun 11 13:43:55 2015 From: nginx-forum at nginx.us (warzoni) Date: Thu, 11 Jun 2015 09:43:55 -0400 Subject: =?UTF-8?B?UmU6ICRzZW50IGh0dHAgLi4uINC90LUg0YDQsNCx0L7RgtCw0LXRgi4=?= In-Reply-To: References: Message-ID: <42fe3593cf1ad424aba26ec930df2c0f.NginxMailingListRussian@forum.nginx.org> Aleksandr Sytar Wrote: ------------------------------------------------------- > 11 июня 2015 г., 11:32 пользователь warzoni > написал: > > > Так как сайт в кеше и пока он не > > очистится код не сработает > > > > Можно ведь один кеш для полной версии иметь, и один для мобильной > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Вы немного выше почитайте, проблема не в том сколько сайтов, а в том как передать управления отделенной странице полной версии сайта, мобильному пользователю. У нас есть на полной версии сайта страницы которые мы хотим показать как не мобильные и вот это мы не можем сделать так как у нас выше стоит кеш. А нам очень надо что-бы страничка полной версии сайта показывалась как полная. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259491,259541#msg-259541 From nginx-forum at nginx.us Thu Jun 11 14:41:09 2015 From: nginx-forum at nginx.us (BieZax) Date: Thu, 11 Jun 2015 10:41:09 -0400 Subject: =?UTF-8?B?0JLQvtC/0YDQvtGBINC/0L4g0L/RgNC+0LjQt9Cy0L7QtNC40YLQtdC70YzQvdC+?= =?UTF-8?B?0YHRgtC4Lg==?= Message-ID: Добрый день! Решил погонять nginx yandex-tank'ом. Для теста использовал файл - 2кб. Голый nginx упирается в ~30000rps, если использовать перенаправление на себя же через localhost, то это значение падает до 13000rps. OS - freebsd. Вопрос скорее теоретический, нормально ли такое поведение, и какие параметры nginx/freebsd могут повлиять в лучшую сторону? В логах никаких проблем не наблюдается. Ниже привожу конфигурацию для наглядности. server { listen 80; server_name fe.ru; location / { proxy_pass http://127.0.0.1:8020; proxy_redirect http://$host:8020/ $scheme://$host:$server_port/; } } server { listen 127.0.0.1:8020; real_ip_header X-Forwarded-For; set_real_ip_from 127.0.0.1; server_name fe.ru; location / { alias /www/htdocs/test/; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259544,259544#msg-259544 From vbart at nginx.com Thu Jun 11 14:49:59 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 11 Jun 2015 17:49:59 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: References: Message-ID: <2133642.4IRYz5dyhW@vbart-workstation> On Thursday 11 June 2015 10:41:09 BieZax wrote: > Добрый день! Решил погонять nginx yandex-tank'ом. Для теста > использовал файл - 2кб. Голый nginx упирается в ~30000rps, если > использовать перенаправление на себя же через localhost, то это > значение падает до 13000rps. OS - freebsd. Вопрос скорее теоретический, > нормально ли такое поведение, и какие параметры nginx/freebsd могут > повлиять в лучшую сторону? [..] Всё это не в вакууме работает же. Если вы на RaspberryPi запускаете, например, то может быть это и есть предел. Смотрите во что упирается. Ссылки по теме: http://habrahabr.ru/post/259403/ http://www.youtube.com/watch?v=eLW_NSuwYU0 -- Валентин Бартенев From citrin at citrin.ru Thu Jun 11 15:22:35 2015 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Thu, 11 Jun 2015 18:22:35 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: References: Message-ID: <5579A7BB.8050909@citrin.ru> On 06/11/15 17:41, BieZax wrote: > В логах никаких проблем не наблюдается по умолчанию error_log пишется на уровне error, лучше увеличить до notice или warn > Голый nginx упирается в ~30000rps, если > использовать перенаправление на себя же через localhost, то это > значение падает до 13000rps 1. показывает ли top 100% загрузку CPU во время теста? 2. общие советы по поводу sysctl: kern.ipc.soacceptqueue=5000 (или больше) net.inet.ip.portrange.randomized=0 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 net.inet.tcp.fast_finwait2_recycle=1 Число воркеров можно для начала поставить в два раза меньше числа ядер и посмотреть как будет расти результаты при увеличении числа воркреров. From mva at mva.name Thu Jun 11 16:07:59 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Thu, 11 Jun 2015 22:07:59 +0600 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: References: Message-ID: <3078581.Cd7NuB2Ipi@note> В письме от Чт, 11 июня 2015 10:41:09 пользователь BieZax написал: > server { > listen 80; > server_name fe.ru; > location / { > proxy_pass http://127.0.0.1:8020; > proxy_redirect http://$host:8020/ $scheme://$host:$server_port/; > } > } > server { > listen 127.0.0.1:8020; > real_ip_header X-Forwarded-For; > set_real_ip_from 127.0.0.1; > server_name fe.ru; > location / { > alias /www/htdocs/test/; > } > } > Я бы ещё поинтересовался о том, чего же вы хотите от NginX в данной конкретной конфигурации и как представляете себе его роль в этом всём. -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From postmaster at softsearch.ru Thu Jun 11 19:20:27 2015 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 11 Jun 2015 22:20:27 +0300 Subject: =?UTF-8?B?UmVbMl06INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LU=?= =?UTF-8?B?0LvRjNC90L7RgdGC0Lgu?= In-Reply-To: <5579A7BB.8050909@citrin.ru> References: <5579A7BB.8050909@citrin.ru> Message-ID: <935844995.20150611222027@softsearch.ru> Здравствуйте, Anton. > 2. общие советы по поводу sysctl: > kern.ipc.soacceptqueue=5000 (или больше) Это в десятой Фре появилось? И что значит? -- С уважением, Михаил mailto:postmaster at softsearch.ru From pluknet at nginx.com Thu Jun 11 19:38:08 2015 From: pluknet at nginx.com (Sergey Kandaurov) Date: Thu, 11 Jun 2015 15:38:08 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: <935844995.20150611222027@softsearch.ru> References: <5579A7BB.8050909@citrin.ru> <935844995.20150611222027@softsearch.ru> Message-ID: On Jun 11, 2015, at 3:20 PM, Михаил Монашёв wrote: > Здравствуйте, Anton. > >> 2. общие советы по поводу sysctl: > >> kern.ipc.soacceptqueue=5000 (или больше) > > Это в десятой Фре появилось? И что значит? > Более другое название somaxconn. -- Sergey Kandaurov From a.vasilishin at kpi.ua Thu Jun 11 19:42:44 2015 From: a.vasilishin at kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Thu, 11 Jun 2015 22:42:44 +0300 Subject: 414 Request-URI Too Large Message-ID: <5579E4B4.9090209@kpi.ua> Всем привет! Есть такая проблема, задолбали школоддосеры. которы LOIC'ом штурмуют сайт запросами вида http://site.com/?blahblah, так как аргументы в / не предусматривается никак обрабатывать, создал конструкцию вида if ($args) { return 444; } В целом локейшн выглядит так: location = / { if ($request_method = POST) { return 405; } if ($args) { return 444; } try_files $uri $uri/ /index.php?q=$uri&$args; index index.php index.htm index.html; } В хроме отрабатывает нормально, в одном ФФ нормально, в другом получаю сабж, как и в Опере. Почему так? # nginx -V nginx version: nginx/1.2.4 configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-file-aio --with-http_flv_module --with-http_geoip_module --with-http_mp4_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --without-http_scgi_module --without-http_split_clients_module --without-http_ssi_module --without-http_userid_module --without-http_uwsgi_module From mva at mva.name Thu Jun 11 19:51:05 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 12 Jun 2015 01:51:05 +0600 Subject: 414 Request-URI Too Large In-Reply-To: <5579E4B4.9090209@kpi.ua> References: <5579E4B4.9090209@kpi.ua> Message-ID: <4294814.n4kidRT50q@note> В письме от Чт, 11 июня 2015 22:42:44 пользователь Андрей Василишин написал: > В хроме отрабатывает нормально, в одном ФФ нормально, в другом получаю > сабж, как и в Опере. > Почему так? > отрабатывает Что именно "отрабатывает" и в каких условиях? Слово "отрабатывает" не говорит совсем ничего о том, что подразумевалось в этом месте рассказа. // А вообще, в любом случае, я, вот, дропаю их точно таким же способом вот уже года три как, если не больше, и у меня, как-то, всё работает... Причём, даже: nginx version: nginx/1.9.1 built with OpenSSL 1.0.1m 19 Mar 2015 TLS SNI support enabled configure arguments: --prefix=/usr --conf-path=/etc/nginx/nginx.conf --error- log-path=/var/log/nginx/error.log --pid-path=/run/nginx.pid --lock- path=/run/lock/nginx.lock --with-cc-opt=-I/usr/include --with-ld-opt=- L/usr/lib64 --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --with-ipv6 --with-pcre --with-pcre-jit --without-http_upstream_zone_module -- with-http_addition_module --with-http_auth_request_module --with- http_dav_module --with-http_degradation_module --with-http_flv_module --with- http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module -- with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_realip_module --with- http_secure_link_module --with-http_spdy_module --with-http_stub_status_module --with-http_sub_module --with-http_xslt_module --with-http_realip_module -- add-module=ext/ngx_devel_kit-0.2.19 --add-module=ext/set-misc-nginx- module-0.28 --add-module=ext/echo-nginx-module-0.57 --add-module=ext/memc- nginx-module-0.15 --add-module=ext/lua-nginx- module-5b35451cd103bda49873af54d9448587203d51bf --add-module=ext/lua-upstream- nginx-module-0.02 --add-module=ext/replace-filter-nginx-module-0.01rc5 --add- module=ext/encrypted-session-nginx-module-0.03 --add-module=ext/headers-more- nginx-module-0.26 --add-module=ext/srcache-nginx-module-0.29 --add- module=ext/rds-json-nginx-module-0.13 --add-module=ext/rds-csv-nginx- module-0.05 --add- module=ext/ngx_postgres-49855a037607c89426b59f54ae2d3049dc5d1c74 --add- module=ext/ngx_coolkit-0.2rc2 --add-module=ext/ngx_pagespeed-1.9.32.3-beta -- add-module=ext/ruby22/passenger-release-5.0.9 --add-module=ext/nginx-push- stream-module-0.5.1 --add-module=ext/ngx_ctpp2-0.5 --add- module=ext/ngx_supervisord-1.4 --add-module=ext/xss-nginx-module-0.04 --add- module=ext/array-var-nginx-module-0.03 --add-module=ext/form-input-nginx- module-0.10 --add-module=ext/iconv-nginx-module-0.10 --add-module=ext/ngx- fancyindex-0.3.5 --add-module=ext/nginx-upload-progress-module-0.9.1 --add- module=ext/ngx_cache_purge-2.3 --add-module=ext/nginx-ey-balancer-0.0.9 --add- module=ext/ngx_slowfs_cache-1.10 --add-module=ext/ngx_metrics-0.1.1 --add- module=ext/naxsi-0.54rc3/naxsi_src --add-module=ext/nginx-dav-ext-module-0.0.3 --add-module=ext/nginx-audio-track-for-hls-module-1e8f2208e243971427154392b855fd973bfedbed --add- module=ext/ngx_http_auth_pam_module-1.4 --add-module=ext/nginx-rtmp- module-1.1.7 --add-module=ext/nginx-goodies-nginx-sticky-module-ng- bd312d586752 --add-module=ext/nginx_ajp_module- bf6cd93f2098b59260de8d494f0f4b1f11a84627 --with-http_ssl_module --with- google_perftools_module --add-module=ext/mod_rrd_graph-0.2.0 --with-mail -- with-mail_ssl_module --without-stream_upstream_hash_module --without- stream_upstream_least_conn_module --without-stream_upstream_zone_module -- with-stream --with-stream_ssl_module --user=nginx --group=nginx -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From a.vasilishin at kpi.ua Thu Jun 11 19:58:22 2015 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, 11 Jun 2015 22:58:22 +0300 Subject: 414 Request-URI Too Large In-Reply-To: <4294814.n4kidRT50q@note> References: <5579E4B4.9090209@kpi.ua> <4294814.n4kidRT50q@note> Message-ID: <5579E85E.8030302@kpi.ua> 11.06.2015 22:51, Vadim A. Misbakh-Soloviov пишет: > Что именно "отрабатывает" и в каких условиях? Слово "отрабатывает" не говорит > совсем ничего о том, что подразумевалось в этом месте рассказа. отрабатывает, это означает отдает 444, я извиняюсь, если ввел в заблуждение, в Хроме пишет, к примеру: "Данные не получены ERR_EMPTY_RESPONSE" From mva at mva.name Thu Jun 11 20:10:26 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 12 Jun 2015 02:10:26 +0600 Subject: 414 Request-URI Too Large In-Reply-To: <5579E85E.8030302@kpi.ua> References: <5579E4B4.9090209@kpi.ua> <4294814.n4kidRT50q@note> <5579E85E.8030302@kpi.ua> Message-ID: <3613470.s9qFq9kB7y@note> > отрабатывает, это означает отдает 444, я извиняюсь, если ввел в > заблуждение, в Хроме пишет, к примеру: "Данные не получены > ERR_EMPTY_RESPONSE" А, собственно, URI можно увидеть? :) Потому что у меня на рандомных тестах в Fx всё прекрасно работает (можете на домене моего ящика проверить). Но у меня есть подозрение, что вы пробовали URI длиной более 255 символов, вот и отшивало (хотя за это отвечает другая директива) :) -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From a.vasilishin at kpi.ua Thu Jun 11 20:12:34 2015 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, 11 Jun 2015 23:12:34 +0300 Subject: 414 Request-URI Too Large In-Reply-To: <3613470.s9qFq9kB7y@note> References: <5579E4B4.9090209@kpi.ua> <4294814.n4kidRT50q@note> <5579E85E.8030302@kpi.ua> <3613470.s9qFq9kB7y@note> Message-ID: <5579EBB2.8050609@kpi.ua> 11.06.2015 23:10, Vadim A. Misbakh-Soloviov пишет: >> отрабатывает, это означает отдает 444, я извиняюсь, если ввел в >> заблуждение, в Хроме пишет, к примеру: "Данные не получены >> ERR_EMPTY_RESPONSE" > > А, собственно, URI можно увидеть? :) > Потому что у меня на рандомных тестах в Fx всё прекрасно работает (можете на > домене моего ящика проверить). Но у меня есть подозрение, что вы пробовали URI > длиной более 255 символов, вот и отшивало (хотя за это отвечает другая > директива) :) Я его привел в старпосте, нет там 255 символов, потом оно размножается до http://site.com/?blahblah?blahblah?blahblah?blahblah?blahblah?blahblah?blahblah?blahblah... From mva at mva.name Thu Jun 11 20:25:04 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 12 Jun 2015 02:25:04 +0600 Subject: 414 Request-URI Too Large In-Reply-To: <5579EBB2.8050609@kpi.ua> References: <5579E4B4.9090209@kpi.ua> <3613470.s9qFq9kB7y@note> <5579EBB2.8050609@kpi.ua> Message-ID: <3877067.pdbyZgmjPI@note> > http://site.com/?blahblah?blahblah?blahblah?blahblah?blahblah?blahblah?blahb > lah?blahblah... Ну, видимо, либо что-то с лисьими настрояками в about:config, либо есть какие- то другие правила/локейшны кромк описаных в стартпосте. Потому что у меня, как я уже сказал, при проверке на моём домене (см поле From у письма) ? редиректов не возникает. Просто срезается и всё. Fx 38.0.1. В about:config я ковырялся, но исключительно с целью повышения приватности. Как-то так. // попробуйте и вы свой request_uri на соём сайте. Будут ли редиректы? -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nginx-forum at nginx.us Fri Jun 12 10:55:44 2015 From: nginx-forum at nginx.us (iks) Date: Fri, 12 Jun 2015 06:55:44 -0400 Subject: =?UTF-8?B?cmVxdWVzdCB1cmkg0L7QsdGA0LDQsdC+0YLQutCwINC00LjRgNC10LrRgtC+0YA=?= =?UTF-8?B?0LjQuQ==?= Message-ID: Задача простая вроде, но что-то на ней споткнулся. Нужно в зависимости от запрашиваемой директории в URI перенаприть запрос на определеный порт. Пробую такую схему, она не отрабатывает. set $port 8000; # порт по умолчанию set $request_url $request_uri; if ( $request_uri ~ ^/economy(.*)$ ) { set $port 8001; } P.S. Если ручками менять порт по умолчанию то все работает. Проверка вроде ошибками не выскакивает, но и порт не меняет, то-есть похоже не принимается данный аргумент. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259582,259582#msg-259582 From dmitriy at lyalyuev.info Fri Jun 12 11:37:08 2015 From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev) Date: Fri, 12 Jun 2015 14:37:08 +0300 Subject: =?UTF-8?B?UmU6IHJlcXVlc3QgdXJpINC+0LHRgNCw0LHQvtGC0LrQsCDQtNC40YDQtdC60YI=?= =?UTF-8?B?0L7RgNC40Lk=?= In-Reply-To: References: Message-ID: <557AC464.4060809@lyalyuev.info> А почему не локейшенами? 12.06.2015 13:55, iks пишет: > Задача простая вроде, но что-то на ней споткнулся. > Нужно в зависимости от запрашиваемой директории в URI перенаприть запрос на > определеный порт. Пробую такую схему, она не отрабатывает. > > set $port 8000; # порт по умолчанию > set $request_url $request_uri; > if ( $request_uri ~ ^/economy(.*)$ ) { set $port 8001; } > > P.S. Если ручками менять порт по умолчанию то все работает. Проверка вроде > ошибками не выскакивает, но и порт не меняет, то-есть похоже не принимается > данный аргумент. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259582,259582#msg-259582 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Dmitriy Lyalyuev DevOps +380665322962 https://dmitriy.lyalyuev.info From nginx-forum at nginx.us Fri Jun 12 11:55:08 2015 From: nginx-forum at nginx.us (iks) Date: Fri, 12 Jun 2015 07:55:08 -0400 Subject: =?UTF-8?B?UmU6IHJlcXVlc3QgdXJpINC+0LHRgNCw0LHQvtGC0LrQsCDQtNC40YDQtdC60YI=?= =?UTF-8?B?0L7RgNC40Lk=?= In-Reply-To: <557AC464.4060809@lyalyuev.info> References: <557AC464.4060809@lyalyuev.info> Message-ID: <6ca9d157c872f67ad258bff0bd03b4f5.NginxMailingListRussian@forum.nginx.org> Dmitriy Lyalyuev есть там свои ньюансы, далее. Нужно именно проверкой uri на соотвествие запрашиваемой директории менять порт. Далее эта директория удаляется из запроса строкой. rewrite ^(.*)/(economy|dir|dir1|dir2|dir3)(.*) $1$2 last; и как вы понимаете уже location не котируется. Короче это связка на Node-JS сделана, если менять порт то все отрабатывается нормально на несколько запущеных серверов Node/ Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259583,259584#msg-259584 From nginx-forum at nginx.us Fri Jun 12 12:02:37 2015 From: nginx-forum at nginx.us (iks) Date: Fri, 12 Jun 2015 08:02:37 -0400 Subject: =?UTF-8?B?UmU6IHJlcXVlc3QgdXJpINC+0LHRgNCw0LHQvtGC0LrQsCDQtNC40YDQtdC60YI=?= =?UTF-8?B?0L7RgNC40Lk=?= In-Reply-To: <6ca9d157c872f67ad258bff0bd03b4f5.NginxMailingListRussian@forum.nginx.org> References: <557AC464.4060809@lyalyuev.info> <6ca9d157c872f67ad258bff0bd03b4f5.NginxMailingListRussian@forum.nginx.org> Message-ID: <8e1e52e32a0fcf494d057113622a1404.NginxMailingListRussian@forum.nginx.org> Точнее rewrite ^(.*)/(economy|dir|dir1|dir2|dir3)(.*) $1$3 last; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259583,259585#msg-259585 From dmitriy at lyalyuev.info Fri Jun 12 12:05:13 2015 From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev) Date: Fri, 12 Jun 2015 15:05:13 +0300 Subject: =?UTF-8?B?UmU6IHJlcXVlc3QgdXJpINC+0LHRgNCw0LHQvtGC0LrQsCDQtNC40YDQtdC60YI=?= =?UTF-8?B?0L7RgNC40Lk=?= In-Reply-To: <8e1e52e32a0fcf494d057113622a1404.NginxMailingListRussian@forum.nginx.org> References: <557AC464.4060809@lyalyuev.info> <6ca9d157c872f67ad258bff0bd03b4f5.NginxMailingListRussian@forum.nginx.org> <8e1e52e32a0fcf494d057113622a1404.NginxMailingListRussian@forum.nginx.org> Message-ID: <557ACAF9.60901@lyalyuev.info> Все равно не понимаю, почему не использовать локейшены, а внутри уже делать рерайты как угодно. 12.06.2015 15:02, iks пишет: > Точнее rewrite ^(.*)/(economy|dir|dir1|dir2|dir3)(.*) $1$3 last; > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259583,259585#msg-259585 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Dmitriy Lyalyuev DevOps +380665322962 https://dmitriy.lyalyuev.info From nginx-forum at nginx.us Fri Jun 12 13:10:15 2015 From: nginx-forum at nginx.us (iks) Date: Fri, 12 Jun 2015 09:10:15 -0400 Subject: =?UTF-8?B?UmU6IHJlcXVlc3QgdXJpINC+0LHRgNCw0LHQvtGC0LrQsCDQtNC40YDQtdC60YI=?= =?UTF-8?B?0L7RgNC40Lk=?= In-Reply-To: <557ACAF9.60901@lyalyuev.info> References: <557ACAF9.60901@lyalyuev.info> Message-ID: <3e1d1d2acd91c8800f7a01a4d7ae2ea3.NginxMailingListRussian@forum.nginx.org> Показываю файл полностью. И толку там от этих server { server_name node.site.ru www.node.site.ru; listen *:80; disable_symlinks if_not_owner from=$root_path; index index.htm index.html index.shtml index.php index.phtml; set $root_path /home/user/public_html/site.ru; set $port_uri 8000; if ( $request_uri ~ ^(.*)/economy(.*)$ ) { set $port_uri 8001; set $root_path /home/user/public_html/site.ru/economy; } if ( $request_uri ~ ^(.*)/dir(.*)$ ) { set $port_uri 8002; set $root_path /home/user/public_html/site.ru/dir; } if ( $request_uri ~ ^(.*)/dir1(.*)$ ) { set $port_uri 8003; set $root_path /home/user/public_html/site.ru/dir1; } rewrite ^(.*)/(economy|dir|dir1)(.*) $1$3 last; location ~* ^.+\.(html|htm|jpg|jpeg|gif|png|svg|js|css|mp3|mp4|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { root $root_path; access_log /home/iks/logs/httpd-logs/node.rusdeb.ru.access.log; error_page 404 = @fallback; } location / { proxy_pass http://127.0.0.1:$port_uri; proxy_redirect http://127.0.0.1:$port_uri/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } location @fallback { proxy_pass http://127.0.0.1:$port_uri; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } } этот поддомен полностью отрабатывает Node. Пробовал через location, запросы к серверу идут, но не грузится socket.io/socket.io.js, а без него клиент не может установить связь. Поэтому и оптимальный вариант поменять порт и директорию ROOT, а остальной конфиг оставлять без изменений Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259583,259587#msg-259587 From dmitriy at lyalyuev.info Fri Jun 12 13:30:47 2015 From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev) Date: Fri, 12 Jun 2015 16:30:47 +0300 Subject: =?UTF-8?B?UmU6IHJlcXVlc3QgdXJpINC+0LHRgNCw0LHQvtGC0LrQsCDQtNC40YDQtdC60YI=?= =?UTF-8?B?0L7RgNC40Lk=?= In-Reply-To: <3e1d1d2acd91c8800f7a01a4d7ae2ea3.NginxMailingListRussian@forum.nginx.org> References: <557ACAF9.60901@lyalyuev.info> <3e1d1d2acd91c8800f7a01a4d7ae2ea3.NginxMailingListRussian@forum.nginx.org> Message-ID: <557ADF07.8060302@lyalyuev.info> У меня нет проектов на node.js и проверить ваш конфиг я не могу, но что-то типа: location / { location ~ ^(.*)/economy { proxy_pass http://127.0.0.1:8000; ... } location ~ ^(.*)/dir1 { proxy_pass http://127.0.0.1:8001; ... } } Это вполне должно работать. Вызывать на каждый запрос if не имеет смысла - http://wiki.nginx.org/IfIsEvil Если что-то не работает или работает не так, как вы того ожидаете - стоит включить debug лог и посмотреть почему все идет не так. 12.06.2015 16:10, iks пишет: > Показываю файл полностью. И толку там от этих > > > server { > server_name node.site.ru www.node.site.ru; > listen *:80; > disable_symlinks if_not_owner from=$root_path; > index index.htm index.html index.shtml index.php index.phtml; > set $root_path /home/user/public_html/site.ru; > set $port_uri 8000; > > if ( $request_uri ~ ^(.*)/economy(.*)$ ) { > set $port_uri 8001; > set $root_path /home/user/public_html/site.ru/economy; > } > if ( $request_uri ~ ^(.*)/dir(.*)$ ) { > set $port_uri 8002; > set $root_path /home/user/public_html/site.ru/dir; > } > if ( $request_uri ~ ^(.*)/dir1(.*)$ ) { > set $port_uri 8003; > set $root_path /home/user/public_html/site.ru/dir1; > } > rewrite ^(.*)/(economy|dir|dir1)(.*) $1$3 last; > > location ~* > ^.+\.(html|htm|jpg|jpeg|gif|png|svg|js|css|mp3|mp4|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ > { > root $root_path; > access_log /home/iks/logs/httpd-logs/node.rusdeb.ru.access.log; > error_page 404 = @fallback; > } > location / { > proxy_pass http://127.0.0.1:$port_uri; > proxy_redirect http://127.0.0.1:$port_uri/ /; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Forwarded-Proto $scheme; > proxy_set_header X-Real-IP $remote_addr; > } > location @fallback { > proxy_pass http://127.0.0.1:$port_uri; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Forwarded-Proto $scheme; > proxy_set_header X-Real-IP $remote_addr; > } > } > > этот поддомен полностью отрабатывает Node. Пробовал через location, запросы > к серверу идут, но не грузится socket.io/socket.io.js, а без него клиент не > может установить связь. Поэтому и оптимальный вариант поменять порт и > директорию ROOT, а остальной конфиг оставлять без изменений > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259583,259587#msg-259587 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Dmitriy Lyalyuev DevOps +380665322962 https://dmitriy.lyalyuev.info From nginx-forum at nginx.us Sat Jun 13 13:54:39 2015 From: nginx-forum at nginx.us (iks) Date: Sat, 13 Jun 2015 09:54:39 -0400 Subject: =?UTF-8?B?UmU6IHJlcXVlc3QgdXJpINC+0LHRgNCw0LHQvtGC0LrQsCDQtNC40YDQtdC60YI=?= =?UTF-8?B?0L7RgNC40Lk=?= In-Reply-To: <557ADF07.8060302@lyalyuev.info> References: <557ADF07.8060302@lyalyuev.info> Message-ID: <62467564ac65b422e8b52f528681e9a1.NginxMailingListRussian@forum.nginx.org> Не помогало это через location. Решил проблему переноса нужной информации в аргумент, теперь вот так нормально меняет порт и директорию ROOT. server { server_name node.site.ru www.node.site.ru; listen *:80; disable_symlinks if_not_owner from=$root_path; index index.htm index.html index.shtml index.php index.phtml; set $root_path /home/user/public_html/site.ru; set $port_path 8000; if ( $args ~* (.*)server=dir ) { set $port_path 8001; set $root_path /home/user/public_html/site.ru/dir; } if ( $args ~* (.*)server=dir1 ) { set $port_path 8002; set $root_path /home/user/public_html/site.ru/dir1; } rewrite ^(.*)/(dir|dir1)(.*) $1$3 last; location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { root $root_path; access_log /home/iks/logs/httpd-logs/node.rusdeb.ru.access.log; error_page 404 = @fallback; } location / { proxy_pass http://127.0.0.1:$port_path; proxy_redirect http://127.0.0.1:$port_path/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } location @fallback { proxy_pass http://127.0.0.1:$port_path; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } } Вполне подойдет для обработки несколько запущеных серверов Node.js через один поддомен. P.S. Можно похоже и с обрабрткой директории запроса, но пробовал через $uri и $request_uri ни чего не выходило, может другую переменую нужно обрабатывать. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259583,259595#msg-259595 From mva at mva.name Sat Jun 13 14:49:01 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Sat, 13 Jun 2015 20:49:01 +0600 Subject: =?UTF-8?B?UmU6IHJlcXVlc3QgdXJpINC+0LHRgNCw0LHQvtGC0LrQsCDQtNC40YDQtdC60YI=?= =?UTF-8?B?0L7RgNC40Lk=?= In-Reply-To: <62467564ac65b422e8b52f528681e9a1.NginxMailingListRussian@forum.nginx.org> References: <557ADF07.8060302@lyalyuev.info> <62467564ac65b422e8b52f528681e9a1.NginxMailingListRussian@forum.nginx.org> Message-ID: <1984933.STyB1ucQzX@note> > Вполне подойдет для обработки несколько запущеных серверов Node.js через > один поддомен. Одно, вот, не пойму. Почему вы, всё-таки, не использовали upstream и переизобретали его с помощью KnV-философии... :) > P.S. Можно похоже и с обрабрткой директории запроса, но пробовал через $uri > и $request_uri ни чего не выходило, может другую переменую нужно > обрабатывать. -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From simplebox66 at gmail.com Mon Jun 15 06:52:25 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 15 Jun 2015 09:52:25 +0300 Subject: =?UTF-8?B?0J3QtSDRg9C00LDQu9GP0LXRgtGB0Y8g0YHRgtCw0YDRi9C5INC60LXRiA==?= Message-ID: Всем привет! В моем конфиге есть директива proxy_cache_path /tmp/ram/ levels=1:2 keys_zone=level-1:20m max_size=3990m inactive=440m; proxy_cache_key ранее был умолчательным, потом я его поменял на proxy_cache_key $server_name$request_uri; После смены ключей кеширования кеш не чистил, полагал что старый кеш со временем сам умрет. Исходя из директив выше, кеш должен удаляться если в течении 440 минут никто его не дергал. Но прошло уже более 5 дней, а файлик со старым кешем не уходит head -n13 /tmp/cache/c/96/19101c5f678dfab8591226 ▒▒vU▒▒▒▒▒▒▒▒▒▒vUTC-?▒ KEY: $scheme$proxy_host$request_uri; HTTP/1.1 200 OK Server: nginx Date: Tue, 09 Jun 2015 06:41:10 GMT Content-Type: application/x-tar Content-Length: 1045453824 Connection: close Expires: 0 Cache-Control: must-revalidate, post-check=0, pre-check=0 Pragma: public Content-Disposition: attachment; filename=all_docs_2606.tar Вот еще кусок вывода команды stat по файлу /tmp/cache/c/96/19101c5f678dfab8591226 Access: 2015-06-15 09:12:53.199138168 +0300 Modify: 2015-06-09 09:41:35.365299256 +0300 Change: 2015-06-09 09:41:35.365299256 +0300 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simplebox66 at gmail.com Mon Jun 15 13:12:41 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 15 Jun 2015 16:12:41 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YPQtNCw0LvRj9C10YLRgdGPINGB0YLQsNGA0YvQuSDQutC10Yg=?= In-Reply-To: References: Message-ID: я так понимаю объяснения у данного казуса отсутствуют? 15 июня 2015 г., 9:52 пользователь Иван Мишин написал: > Всем привет! > > В моем конфиге есть директива > proxy_cache_path /tmp/ram/ levels=1:2 keys_zone=level-1:20m > max_size=3990m inactive=440m; > > proxy_cache_key ранее был умолчательным, потом я его поменял > на proxy_cache_key $server_name$request_uri; > > После смены ключей кеширования кеш не чистил, полагал что старый кеш со > временем сам умрет. > Исходя из директив выше, кеш должен удаляться если в течении 440 минут > никто его не дергал. Но прошло уже более 5 дней, а файлик со старым кешем > не уходит > > head -n13 /tmp/cache/c/96/19101c5f678dfab8591226 > ▒▒vU▒▒▒▒▒▒▒▒▒▒vUTC-?▒ > KEY: $scheme$proxy_host$request_uri; > HTTP/1.1 200 OK > Server: nginx > Date: Tue, 09 Jun 2015 06:41:10 GMT > Content-Type: application/x-tar > Content-Length: 1045453824 > Connection: close > Expires: 0 > Cache-Control: must-revalidate, post-check=0, pre-check=0 > Pragma: public > Content-Disposition: attachment; filename=all_docs_2606.tar > > Вот еще кусок вывода команды stat по файлу > /tmp/cache/c/96/19101c5f678dfab8591226 > > Access: 2015-06-15 09:12:53.199138168 +0300 > Modify: 2015-06-09 09:41:35.365299256 +0300 > Change: 2015-06-09 09:41:35.365299256 +0300 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Mon Jun 15 14:18:11 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 15 Jun 2015 17:18:11 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YPQtNCw0LvRj9C10YLRgdGPINGB0YLQsNGA0YvQuSDQutC10Yg=?= In-Reply-To: References: Message-ID: <20150615141811.GL26357@mdounin.ru> Hello! On Mon, Jun 15, 2015 at 04:12:41PM +0300, Иван Мишин wrote: > я так понимаю объяснения у данного казуса отсутствуют? Совершенно верно понимаете. Ваше сообщение содержит недостаточно информации, чтобы объяснить данный казус. Вероятнее всего, причина в том, что файл кеша продлжает использоваться - хотя вы и полагаете, что он использоваться не должен. Проверяйте конфиг внимательно. -- Maxim Dounin http://nginx.org/ From simplebox66 at gmail.com Mon Jun 15 14:52:01 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 15 Jun 2015 17:52:01 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YPQtNCw0LvRj9C10YLRgdGPINGB0YLQsNGA0YvQuSDQutC10Yg=?= In-Reply-To: <20150615141811.GL26357@mdounin.ru> References: <20150615141811.GL26357@mdounin.ru> Message-ID: Какой информации не хватает? Не понятно как файл кеша со старыми ключами продолжает использоваться если ключи кеша уже 6 дней как новые? Да и в моих выкладках видно что файл последний раз использовался 9ого числа, а сегодня 15ое. 15 июня 2015 г., 17:18 пользователь Maxim Dounin написал: > Hello! > > On Mon, Jun 15, 2015 at 04:12:41PM +0300, Иван Мишин wrote: > > > я так понимаю объяснения у данного казуса отсутствуют? > > Совершенно верно понимаете. Ваше сообщение содержит недостаточно > информации, чтобы объяснить данный казус. Вероятнее всего, > причина в том, что файл кеша продлжает использоваться - хотя вы и > полагаете, что он использоваться не должен. Проверяйте конфиг > внимательно. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > 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 Mon Jun 15 15:01:53 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 15 Jun 2015 18:01:53 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YPQtNCw0LvRj9C10YLRgdGPINGB0YLQsNGA0YvQuSDQutC10Yg=?= In-Reply-To: References: <20150615141811.GL26357@mdounin.ru> Message-ID: <20150615150153.GO26357@mdounin.ru> Hello! On Mon, Jun 15, 2015 at 05:52:01PM +0300, Иван Мишин wrote: > Какой информации не хватает? > Не понятно как файл кеша со старыми ключами продолжает использоваться если > ключи кеша уже 6 дней как новые? > Да и в моих выкладках видно что файл последний раз использовался 9ого > числа, а сегодня 15ое. А, нет, прошу прощения, ошибся: информации хватает. Ваш кеш смотрит в /tmp/ram/, а файл вы пытаетесь смотреть в /tmp/cache/. Это полностью объясняет наблюдаемый эффект - вы переместили кеш в другой каталог, и теперь за файлы по старому пути отвечаете только вы. Если они не нужны - сотрите их. -- Maxim Dounin http://nginx.org/ From simplebox66 at gmail.com Mon Jun 15 15:13:42 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 15 Jun 2015 18:13:42 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YPQtNCw0LvRj9C10YLRgdGPINGB0YLQsNGA0YvQuSDQutC10Yg=?= In-Reply-To: <20150615150153.GO26357@mdounin.ru> References: <20150615141811.GL26357@mdounin.ru> <20150615150153.GO26357@mdounin.ru> Message-ID: Максим, я опечатался при постановке вопроса. На самом деле в конфиге тоже /tmp/cache. То есть путь хранения кеша не менлся, менялись только ключи. 15 июня 2015 г., 18:01 пользователь Maxim Dounin написал: > Hello! > > On Mon, Jun 15, 2015 at 05:52:01PM +0300, Иван Мишин wrote: > > > Какой информации не хватает? > > Не понятно как файл кеша со старыми ключами продолжает использоваться > если > > ключи кеша уже 6 дней как новые? > > Да и в моих выкладках видно что файл последний раз использовался 9ого > > числа, а сегодня 15ое. > > А, нет, прошу прощения, ошибся: информации хватает. > > Ваш кеш смотрит в /tmp/ram/, а файл вы пытаетесь смотреть в > /tmp/cache/. Это полностью объясняет наблюдаемый эффект - вы > переместили кеш в другой каталог, и теперь за файлы по старому > пути отвечаете только вы. Если они не нужны - сотрите их. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > 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 Mon Jun 15 15:48:04 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 15 Jun 2015 18:48:04 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0YPQtNCw0LvRj9C10YLRgdGPINGB0YLQsNGA0YvQuSDQutC10Yg=?= In-Reply-To: References: <20150615141811.GL26357@mdounin.ru> <20150615150153.GO26357@mdounin.ru> Message-ID: <20150615154804.GQ26357@mdounin.ru> Hello! On Mon, Jun 15, 2015 at 06:13:42PM +0300, Иван Мишин wrote: > Максим, я опечатался при постановке вопроса. На самом деле в конфиге > тоже /tmp/cache. > То есть путь хранения кеша не менлся, менялись только ключи. Значит, проблема где-то ещё. Например, вы могли опечататься в постановке вопроса более одного раза, и, например, опечатались также в inactive, и там не 440 минут, а 440 месяцев. Или, как уже было предположено, на самом деле кеш используется (в каком-либо другом server'е/location'е, или просто конфиг на самом деле не перегружен), а stat ничего не показывает из-за того, что файловая система смотирована с noatime. Или вы просто смотрите на файл, который положили в каталог кеша руками - приведённое имя файла из 22 символов как бы намекает, должно быть 32. Вариантов масса, какой из них правильный - предстоит определить вам. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Tue Jun 16 07:25:53 2015 From: nginx-forum at nginx.us (patjomkin) Date: Tue, 16 Jun 2015 03:25:53 -0400 Subject: Page with ssl doesn't open from safari Message-ID: <4b7a726299eea70f685ef625a5f48432.NginxMailingListRussian@forum.nginx.org> Добрый день Куплен UCC ssl сертификат у godaddy для 5 доменных имён. Один из сайтов (располагается на отдельном сервере) не открывается из safari "Safari can't open the page https://sendy.mysite.com because the server unexpectedly dropped the connection. This sometimes occurs when the server is busy. Wait for a few minutes, and then try again." В тоже время он нормально открывается из всех остальных браузеров. В самом логе nginx (nginx 1.8.0, ubuntu 14.04): 2015/06/15 09:48:27 [debug] 15611#0: *6 SSL NPN advertised 2015/06/15 09:48:27 [debug] 15611#0: *6 SSL_do_handshake: -1 2015/06/15 09:48:27 [debug] 15611#0: *6 SSL_get_error: 2 2015/06/15 09:48:27 [debug] 15611#0: *6 reusable connection: 0 2015/06/15 09:48:27 [debug] 15611#0: *6 SSL handshake handler: 0 2015/06/15 09:48:30 [debug] 29320#0: *7 SSL_do_handshake: -1 2015/06/15 09:48:30 [debug] 29320#0: *7 SSL_get_error: 2 2015/06/15 09:48:30 [debug] 29320#0: *7 reusable connection: 0 2015/06/15 09:48:31 [debug] 29320#0: *7 SSL handshake handler: 0 2015/06/15 09:48:33 [debug] 29322#0: *8 SSL_do_handshake: -1 2015/06/15 09:48:33 [debug] 29322#0: *8 SSL_get_error: 2 2015/06/15 09:48:33 [debug] 29322#0: *8 reusable connection: 0 2015/06/15 09:48:33 [debug] 29322#0: *8 SSL handshake handler: 0 Конфиг: server { listen 80; server_name sendy.mysite.com; location / { rewrite ^(.*) https://sendy.mysite.com$1 permanent; } } server { listen 443; server_name sendy.vaksmanlaw.com; ssl on; ssl_certificate /etc/nginx/ssl/www.mysite2.com.crt; ssl_certificate_key /etc/nginx/ssl/www.mysite2.com.key; index index.php index.html; root /home/ubuntu/sendy; access_log /var/log/nginx/sendy.access.log; error_log /var/log/nginx/sendy.error.log debug; proxy_buffers 8 32k; proxy_buffer_size 64k; fastcgi_buffers 16 16k; fastcgi_buffer_size 32k; location = / { index index.php; } location / { if (!-f $request_filename){ rewrite ^/([a-zA-Z0-9-]+)$ /$1.php last;} } location /l/ { rewrite ^/l/([a-zA-Z0-9/]+)$ /l.php?i=$1 last; } location /t/ { rewrite ^/t/([a-zA-Z0-9/]+)$ /t.php?i=$1 last; } location /w/ { rewrite ^/w/([a-zA-Z0-9/]+)$ /w.php?i=$1 last; } location /unsubscribe/ { rewrite ^/unsubscribe/(.*)$ /unsubscribe.php?i=$1 last; } location /subscribe/ { rewrite ^/subscribe/(.*)$ /subscribe.php?i=$1 last; } location ~* \.(ico|css|js|gif|jpe?g|png)(\?[0-9]+)?$ { expires max; log_not_found off; } location ~ \.php { fastcgi_index index.php; include fastcgi_params; keepalive_timeout 0; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/var/run/php5-fpm.sock; } } Все остальные сайты/домены располагаются на другом сервере с тем же ucc сертификатом, открываются в сафари без проблем. В чем может быть проблема? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259638,259638#msg-259638 From redmine24 at gmail.com Tue Jun 16 10:06:07 2015 From: redmine24 at gmail.com (=?UTF-8?B?0JTQuNC80LAg0KDQtdC00LzQsNC50L0=?=) Date: Tue, 16 Jun 2015 13:06:07 +0300 Subject: Page with ssl doesn't open from safari In-Reply-To: <4b7a726299eea70f685ef625a5f48432.NginxMailingListRussian@forum.nginx.org> References: <4b7a726299eea70f685ef625a5f48432.NginxMailingListRussian@forum.nginx.org> Message-ID: Воспользуйтесь сервисом https://www.ssllabs.com/ssltest/ - может помочь найти причину. 2015-06-16 10:25 GMT+03:00 patjomkin : > Добрый день > > Куплен UCC ssl сертификат у godaddy для 5 доменных имён. > > Один из сайтов (располагается на отдельном сервере) не открывается из > safari > "Safari can't open the page https://sendy.mysite.com because the server > unexpectedly dropped the connection. This sometimes occurs when the server > is busy. Wait for a few minutes, and then try again." В тоже время он > нормально открывается из всех остальных браузеров. > > > В самом логе nginx (nginx 1.8.0, ubuntu 14.04): > > 2015/06/15 09:48:27 [debug] 15611#0: *6 SSL NPN advertised > 2015/06/15 09:48:27 [debug] 15611#0: *6 SSL_do_handshake: -1 > 2015/06/15 09:48:27 [debug] 15611#0: *6 SSL_get_error: 2 > 2015/06/15 09:48:27 [debug] 15611#0: *6 reusable connection: 0 > 2015/06/15 09:48:27 [debug] 15611#0: *6 SSL handshake handler: 0 > 2015/06/15 09:48:30 [debug] 29320#0: *7 SSL_do_handshake: -1 > 2015/06/15 09:48:30 [debug] 29320#0: *7 SSL_get_error: 2 > 2015/06/15 09:48:30 [debug] 29320#0: *7 reusable connection: 0 > 2015/06/15 09:48:31 [debug] 29320#0: *7 SSL handshake handler: 0 > 2015/06/15 09:48:33 [debug] 29322#0: *8 SSL_do_handshake: -1 > 2015/06/15 09:48:33 [debug] 29322#0: *8 SSL_get_error: 2 > 2015/06/15 09:48:33 [debug] 29322#0: *8 reusable connection: 0 > 2015/06/15 09:48:33 [debug] 29322#0: *8 SSL handshake handler: 0 > > Конфиг: > > server { > listen 80; > server_name sendy.mysite.com; > > location / { > rewrite ^(.*) https://sendy.mysite.com$1 permanent; > } > } > > > server > { > listen 443; > server_name sendy.vaksmanlaw.com; > > ssl on; > ssl_certificate /etc/nginx/ssl/www.mysite2.com.crt; > ssl_certificate_key /etc/nginx/ssl/www.mysite2.com.key; > > index index.php index.html; > root /home/ubuntu/sendy; > access_log /var/log/nginx/sendy.access.log; > error_log /var/log/nginx/sendy.error.log debug; > proxy_buffers 8 32k; > proxy_buffer_size 64k; > fastcgi_buffers 16 16k; > fastcgi_buffer_size 32k; > > location = / { > index index.php; } > > location / { > if (!-f $request_filename){ > rewrite ^/([a-zA-Z0-9-]+)$ /$1.php last;} > } > > location /l/ { > rewrite ^/l/([a-zA-Z0-9/]+)$ /l.php?i=$1 last; } > > location /t/ { > rewrite ^/t/([a-zA-Z0-9/]+)$ /t.php?i=$1 last; } > > location /w/ { > rewrite ^/w/([a-zA-Z0-9/]+)$ /w.php?i=$1 last; } > > location /unsubscribe/ { > rewrite ^/unsubscribe/(.*)$ /unsubscribe.php?i=$1 last; } > > location /subscribe/ { > rewrite ^/subscribe/(.*)$ /subscribe.php?i=$1 last; } > > location ~* \.(ico|css|js|gif|jpe?g|png)(\?[0-9]+)?$ { > expires max; > log_not_found off; } > > location ~ \.php { > fastcgi_index index.php; > include fastcgi_params; > keepalive_timeout 0; > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > fastcgi_pass unix:/var/run/php5-fpm.sock; } > } > > Все остальные сайты/домены располагаются на другом сервере с тем же ucc > сертификатом, открываются в сафари без проблем. > > В чем может быть проблема? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,259638,259638#msg-259638 > > _______________________________________________ > 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 Tue Jun 16 10:40:27 2015 From: nginx-forum at nginx.us (iDem) Date: Tue, 16 Jun 2015 06:40:27 -0400 Subject: =?UTF-8?B?cGhwTXlBZG1pbiDRh9C10YDQtdC3IGh0dHBzLCDQvdC10YIg0LjQt9C+0LHRgNCw?= =?UTF-8?B?0LbQtdC90LjQuSwg0L3QtSDQv9C+0LTQs9GA0YPQttCw0Y7RgtGB0Y8g0YE=?= =?UTF-8?B?0YLQuNC70Lg=?= Message-ID: Здравствуйте, прошу помощи. VPS изначально настроен под Bitrix, все работает. Понадобилось установить phpMyAdmin, поставил, если по http захожу то все ок, но если по https, то не подгружаются картинки, стили и скрипты, вернее не подгружаются статические файлы у которых ссылки прописаны вот так: "href="./themes/pmahomme/jquery/jquery-ui-1.11.2.css"", если ссылки прописаны таким образом "href="phpmyadmin.css.php?nocache=4301249977ltr" то все работает. Подскажите в чем проблема? Часть кода из моего файла: server { listen 192.168.18.183:80; server_name www.site.ru; rewrite ^ http://site.ru$request_uri? permanent; #301 redirect } server { listen 192.168.18.183:80; server_name site.ru; charset UTF-8; rewrite ^(/phpmyadmin/.*)$ /phpMyAdmin/ permanent; location ~* ^/phpMyAdmin { rewrite ^(/phpMyAdmin/.*)$ https://$host$1 permanent; root /usr/share/phpMyAdmin; index index.php index.html index.htm; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header Host $host; proxy_pass https://127.0.0.1:8888; } proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host:80; set $proxyserver "http://127.0.0.1:8888"; set $docroot "/home/bitrix/www"; index index.php; root /home/bitrix/www; # Redirect to ssl if need if (-f /home/bitrix/www/.htsecure) { rewrite ^(.*)$ https://$host$1 permanent; } # Include parameters common to all websites include bx/conf/bitrix.conf; # Include server monitoring locations include bx/server_monitor.conf; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259643,259643#msg-259643 From nginx-forum at nginx.us Tue Jun 16 11:03:56 2015 From: nginx-forum at nginx.us (patjomkin) Date: Tue, 16 Jun 2015 07:03:56 -0400 Subject: Page with ssl doesn't open from safari In-Reply-To: References: Message-ID: <271b33307af39e93761cfd32fd6f5fd5.NginxMailingListRussian@forum.nginx.org> Запустил тест https://www.ssllabs.com/ssltest/. В итоге настораживает только "This site works only in browsers with SNI support." но новые версии safari поддерживают sni, т.е. проблема быстрее всего не в этом. Поправьте пожалуйста, если я заблуждаюсь Полный лог (может для кого-нибудь он будет более информативным, чем для меня): Visit our documentation page for more information, configuration guides, and books. Known issues are documented here. This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B. MORE INFO ? This site works only in browsers with SNI support. Authentication Server Key and Certificate #1 Common names www.mysite1.com Alternative names www.mysite1.com mysite1.com sendy.mysite2.com www.mysite3.com www.mysite4.com www.mysite5.com Prefix handling Not required for subdomains Valid from Mon, 11 May 2015 11:35:39 UTC Valid until Thu, 11 May 2017 07:22:38 UTC (expires in 1 year and 10 months) Key RSA 2048 bits (e 65537) Weak key (Debian) No Issuer Go Daddy Secure Certificate Authority - G2 Signature algorithm SHA256withRSA Extended Validation No Certificate Transparency No Revocation information CRL, OCSP Revocation status Good (not revoked) Trusted Yes Additional Certificates (if supplied) Certificates provided 4 (4849 bytes) Chain issues Contains anchor #2 Subject Go Daddy Secure Certificate Authority - G2 Fingerprint: 27ac9369faf25207bb2627cefaccbe4ef9c319b8 Valid until Sat, 03 May 2031 07:00:00 UTC (expires in 15 years and 10 months) Key RSA 2048 bits (e 65537) Issuer Go Daddy Root Certificate Authority - G2 Signature algorithm SHA256withRSA #3 Subject Go Daddy Root Certificate Authority - G2 Fingerprint: 340b2880f446fcc04e59ed33f52b3d08d6242964 Valid until Fri, 30 May 2031 07:00:00 UTC (expires in 15 years and 11 months) Key RSA 2048 bits (e 65537) Issuer The Go Daddy Group / Go Daddy Class 2 Certification Authority Signature algorithm SHA256withRSA #4 Subject The Go Daddy Group / Go Daddy Class 2 Certification Authority In trust store Fingerprint: 2796bae63f1801e277261ba0d77770028f20eee4 Valid until Thu, 29 Jun 2034 17:06:20 UTC (expires in 19 years) Key RSA 2048 bits (e 3) Issuer The Go Daddy Group / Go Daddy Class 2 Certification Authority Self-signed Signature algorithm SHA1withRSA Weak, but no impact on root certificate Certification Paths Path #1: Trusted 1 Sent by server www.mysite1.com Fingerprint: b724f66443d14479640ea332fa3d92221625c2ca RSA 2048 bits (e 65537) / SHA256withRSA 2 Sent by server Go Daddy Secure Certificate Authority - G2 Fingerprint: 27ac9369faf25207bb2627cefaccbe4ef9c319b8 RSA 2048 bits (e 65537) / SHA256withRSA 3 In trust store Go Daddy Root Certificate Authority - G2 Self-signed Fingerprint: 47beabc922eae80e78783462a79f45c254fde68b RSA 2048 bits (e 65537) / SHA256withRSA Path #2: Trusted 1 Sent by server www.mysite1.com Fingerprint: b724f66443d14479640ea332fa3d92221625c2ca RSA 2048 bits (e 65537) / SHA256withRSA 2 Sent by server Go Daddy Secure Certificate Authority - G2 Fingerprint: 27ac9369faf25207bb2627cefaccbe4ef9c319b8 RSA 2048 bits (e 65537) / SHA256withRSA 3 Sent by server Go Daddy Root Certificate Authority - G2 Fingerprint: 340b2880f446fcc04e59ed33f52b3d08d6242964 RSA 2048 bits (e 65537) / SHA256withRSA 4 Sent by server In trust store The Go Daddy Group / Go Daddy Class 2 Certification Authority Self-signed Fingerprint: 2796bae63f1801e277261ba0d77770028f20eee4 RSA 2048 bits (e 3) / SHA1withRSA Weak or insecure signature, but no impact on root certificate Configuration Protocols TLS 1.2 Yes TLS 1.1 Yes TLS 1.0 Yes SSL 3 No SSL 2 No Cipher Suites (SSL 3+ suites in server-preferred order; deprecated and SSL 2 suites always at the end) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH 256 bits (eq. 3072 bits RSA) FS 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA) FS 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) FS 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 1024 bits (p: 128, g: 1, Ys: 128) FS WEAK 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 1024 bits (p: 128, g: 1, Ys: 128) FS WEAK 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits (p: 128, g: 1, Ys: 128) FS WEAK 256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88) DH 1024 bits (p: 128, g: 1, Ys: 128) FS WEAK 256 TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256 TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) 256 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 256 bits (eq. 3072 bits RSA) FS 112 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 1024 bits (p: 128, g: 1, Ys: 128) FS WEAK 112 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH 256 bits (eq. 3072 bits RSA) FS 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits RSA) FS 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) FS 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 1024 bits (p: 128, g: 1, Ys: 128) FS WEAK 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 1024 bits (p: 128, g: 1, Ys: 128) FS WEAK 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits (p: 128, g: 1, Ys: 128) FS WEAK 128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45) DH 1024 bits (p: 128, g: 1, Ys: 128) FS WEAK 128 TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) 128 Handshake Simulation Android 2.3.7 No SNI 2 Incorrect certificate because this client doesn't support SNI Fail2 Android 4.0.4 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 Android 4.1.1 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 Android 4.2.2 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 Android 4.3 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) FS 256 Android 5.0.0 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 Baidu Jan 2015 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 BingPreview Jan 2015 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) FS 256 Chrome 42 / OS X R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 Firefox 31.3.0 ESR / Win 7 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 Firefox 37 / OS X R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 Googlebot Feb 2015 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 IE 6 / XP No FS 1 No SNI 2 Protocol or cipher suite mismatch Fail3 IE 7 / Vista TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 IE 8 / XP No FS 1 No SNI 2 Incorrect certificate because this client doesn't support SNI Fail2 IE 8-10 / Win 7 R TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 IE 11 / Win 7 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) FS 256 IE 11 / Win 8.1 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) FS 256 IE Mobile 10 / Win Phone 8.0 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 IE Mobile 11 / Win Phone 8.1 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) FS 256 Java 6u45 No SNI 2 Incorrect certificate because this client doesn't support SNI Fail2 Java 7u25 TLS 1.0 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) FS 112 Java 8u31 TLS 1.2 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) FS 112 OpenSSL 0.9.8y TLS 1.0 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) FS 256 OpenSSL 1.0.1l R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) FS 256 OpenSSL 1.0.2 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) FS 256 Safari 5.1.9 / OS X 10.6.8 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 Safari 6 / iOS 6.0.1 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) FS 256 Safari 6.0.4 / OS X 10.8.4 R TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256 Safari 7 / iOS 7.1 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) FS 256 Safari 7 / OS X 10.9 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) FS 256 Safari 8 / iOS 8.1.2 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) FS 256 Safari 8 / OS X 10.10 R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) FS 256 Yahoo Slurp Jan 2015 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) FS 256 YandexBot Jan 2015 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) FS 256 (1) Clients that do not support Forward Secrecy (FS) are excluded when determining support for it. (2) No support for virtual SSL hosting (SNI). Connects to the default site if the server uses SNI. (3) Only first connection attempt simulated. Browsers tend to retry with a lower protocol version. (R) Denotes a reference browser or client, with which we expect better effective security. (All) We use defaults, but some platforms do not use their best protocols and features (e.g., Java 6 & 7, older IE). Protocol Details Secure Renegotiation Supported Secure Client-Initiated Renegotiation No Insecure Client-Initiated Renegotiation No BEAST attack Not mitigated server-side (more info) TLS 1.0: 0xc014 POODLE (SSLv3) No, SSL 3 not supported (more info) POODLE (TLS) No (more info) Downgrade attack prevention No, TLS_FALLBACK_SCSV not supported (more info) TLS compression No RC4 No Heartbeat (extension) Yes Heartbleed (vulnerability) No (more info) OpenSSL CCS vuln. (CVE-2014-0224) No (more info) Forward Secrecy Yes (with most browsers) ROBUST (more info) Next Protocol Negotiation (NPN) Yes http/1.1 Session resumption (caching) No (IDs assigned but not accepted) Session resumption (tickets) Yes OCSP stapling No Strict Transport Security (HSTS) No Public Key Pinning (HPKP) No Long handshake intolerance No TLS extension intolerance No TLS version intolerance No Incorrect SNI alerts - Uses common DH prime Yes Replace with custom DH parameters if possible (more info) SSL 2 handshake compatibility Yes Miscellaneous Test date Tue, 16 Jun 2015 10:54:02 UTC Test duration 98.530 seconds HTTP status code 200 HTTP server signature nginx/1.8.0 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259638,259646#msg-259646 From nginx-forum at nginx.us Tue Jun 16 12:23:46 2015 From: nginx-forum at nginx.us (patjomkin) Date: Tue, 16 Jun 2015 08:23:46 -0400 Subject: Page with ssl doesn't open from safari In-Reply-To: <271b33307af39e93761cfd32fd6f5fd5.NginxMailingListRussian@forum.nginx.org> References: <271b33307af39e93761cfd32fd6f5fd5.NginxMailingListRussian@forum.nginx.org> Message-ID: <1c101b28c7fdc9674e7e5cf042694d69.NginxMailingListRussian@forum.nginx.org> Спасибо большое Дмитрий, кажется проблему временно решил, добавил в конфиг nginx listen 443 default_server ssl; (ранее было просто listen 443;) Т.е. получается что сафари не поддерживает SNI (This site works only in browsers with SNI support.). Это правильное решение или просто костыль, и стоит сделать как-то по-другому? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259638,259649#msg-259649 From annulen at yandex.ru Tue Jun 16 12:57:29 2015 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 16 Jun 2015 15:57:29 +0300 Subject: Page with ssl doesn't open from safari In-Reply-To: <1c101b28c7fdc9674e7e5cf042694d69.NginxMailingListRussian@forum.nginx.org> References: <271b33307af39e93761cfd32fd6f5fd5.NginxMailingListRussian@forum.nginx.org> <1c101b28c7fdc9674e7e5cf042694d69.NginxMailingListRussian@forum.nginx.org> Message-ID: <951571434459449@web28h.yandex.ru> 16.06.2015, 15:23, "patjomkin" : > Спасибо большое Дмитрий, > кажется проблему временно решил, добавил в конфиг nginx > listen 443 default_server ssl; (ранее было просто listen 443;) > Т.е. получается что сафари не поддерживает SNI (This site works only in > browsers with SNI support.). Согласно Википедии, Safari этим страдает только на Windows XP https://en.wikipedia.org/wiki/Server_Name_Indication#Client_side > Это правильное решение или просто костыль, и стоит сделать как-то > по-другому? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259638,259649#msg-259649 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From nginx-forum at nginx.us Tue Jun 16 13:02:15 2015 From: nginx-forum at nginx.us (BieZax) Date: Tue, 16 Jun 2015 09:02:15 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: <5579A7BB.8050909@citrin.ru> References: <5579A7BB.8050909@citrin.ru> Message-ID: <2b1927b07bb46be5853ed6a22f8664aa.NginxMailingListRussian@forum.nginx.org> Нет, загрузка по CPU минимальна, по i/o тоже, по сети прилетает около 600 мегабит в секунду . В качестве стенда два xeona E5620 с 64Гб памяти. Пока не нашел, куда оно упирается. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259544,259653#msg-259653 From nginx-forum at nginx.us Tue Jun 16 13:08:29 2015 From: nginx-forum at nginx.us (BieZax) Date: Tue, 16 Jun 2015 09:08:29 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: <3078581.Cd7NuB2Ipi@note> References: <3078581.Cd7NuB2Ipi@note> Message-ID: mva Wrote: ------------------------------------------------------- > В письме от Чт, 11 июня 2015 10:41:09 пользователь BieZax написал: > > server { > > listen 80; > > server_name fe.ru; > > location / { > > proxy_pass http://127.0.0.1:8020; > > proxy_redirect http://$host:8020/ $scheme://$host:$server_port/; > > } > > } > > server { > > listen 127.0.0.1:8020; > > real_ip_header X-Forwarded-For; > > set_real_ip_from 127.0.0.1; > > server_name fe.ru; > > location / { > > alias /www/htdocs/test/; > > } > > } > > > > Я бы ещё поинтересовался о том, чего же вы хотите от NginX в данной > конкретной > конфигурации и как представляете себе его роль в этом всём. > > -- > Best regards, > mva > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Использую такую конфигурацию во многих случаях, в частности nginx->apache+mod_sec->nginx(в таком случае waf является отдельной сущностью, и может работать хоть на другой машине) Или, например, в случае с upstream, когда нужно переписать хэдер host для каждого из серверов. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259544,259654#msg-259654 From nginx-forum at nginx.us Tue Jun 16 13:34:29 2015 From: nginx-forum at nginx.us (patjomkin) Date: Tue, 16 Jun 2015 09:34:29 -0400 Subject: Page with ssl doesn't open from safari In-Reply-To: <951571434459449@web28h.yandex.ru> References: <951571434459449@web28h.yandex.ru> Message-ID: Konstantin Tokarev Wrote: ------------------------------------------------------- > 16.06.2015, 15:23, "patjomkin" : > > Спасибо большое Дмитрий, > > кажется проблему временно решил, добавил в конфиг nginx > > listen 443 default_server ssl; (ранее было просто listen 443;) > > Т.е. получается что сафари не поддерживает SNI (This site works only > in > > browsers with SNI support.). > > > Согласно Википедии, Safari этим страдает только на Windows XP > > https://en.wikipedia.org/wiki/Server_Name_Indication#Client_side > > > > > Это правильное решение или просто костыль, и стоит сделать как-то > > по-другому? > > > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,259638,259649#msg-259649 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > -- > Regards, > Konstantin > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Да, поэтому этот вариант сразу даже не рассматривался. Но учитывая, что это решение помогло, и то, что у меня за первый час ввода ssl для этого сайта прилетело больше 50 репортов о ошибке с MAC устройств, можно слегка усомниться. Хотя, может просто совпало и реальная причина пока не найдена. Сейчас вопрос в том, правильно ли я сделал, добавив параметры "default_server ssl" в конфиг. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259638,259656#msg-259656 From onokonem at gmail.com Tue Jun 16 14:12:37 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Tue, 16 Jun 2015 17:12:37 +0300 Subject: Page with ssl doesn't open from safari In-Reply-To: References: <951571434459449@web28h.yandex.ru> Message-ID: > Сейчас вопрос в том, правильно ли я сделал, добавив параметры > "default_server ssl" в конфиг. ssl - правильно. default_server - не будет иметь эффекта. From nginx-forum at nginx.us Tue Jun 16 14:55:23 2015 From: nginx-forum at nginx.us (iDem) Date: Tue, 16 Jun 2015 10:55:23 -0400 Subject: =?UTF-8?B?UmU6IHBocE15QWRtaW4g0YfQtdGA0LXQtyBodHRwcywg0L3QtdGCINC40LfQvtCx?= =?UTF-8?B?0YDQsNC20LXQvdC40LksINC90LUg0L/QvtC00LPRgNGD0LbQsNGO0YLRgdGP?= =?UTF-8?B?INGB0YLQuNC70Lg=?= In-Reply-To: References: Message-ID: <173d9346b17a23c8262d8f31840e76c3.NginxMailingListRussian@forum.nginx.org> В логах такая вот ошибка: 2015/06/16 17:52:47 [error] 20016#0: *17 open() "/home/bitrix/www/phpMyAdmin/themes/original/img/logo_right.png" failed (2: No such file or directory), client: 178.248.69.58, server: _, request: "GET /phpMyAdmin/themes/original/img/logo_right.png HTTP/1.1", host: "site.ru", referrer: "https://site.ru/phpMyAdmin/phpmyadmin.css.php?nocache=5735254046ltr" Не пойму почему путь по которому открывается файл находиться в папке битрикса, а не в /usr/share... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259643,259659#msg-259659 From mdounin at mdounin.ru Tue Jun 16 15:27:12 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 16 Jun 2015 18:27:12 +0300 Subject: nginx-1.9.2 Message-ID: <20150616152712.GZ26357@mdounin.ru> Изменения в nginx 1.9.2 16.06.2015 *) Добавление: параметр backlog директивы listen в почтовом прокси-сервере и модуле stream. *) Добавление: директивы allow и deny в модуле stream. *) Добавление: директива proxy_bind в модуле stream. *) Добавление: директива proxy_protocol в модуле stream. *) Добавление: ключ -T. *) Добавление: параметр REQUEST_SCHEME добавлен в стандартные конфигурационные файлы fastcgi.conf, fastcgi_params, scgi_params и uwsgi_params. *) Исправление: параметр reuseport директивы listen в модуле stream не работал. *) Исправление: OCSP stapling в некоторых случаях мог вернуть устаревший OCSP-ответ. -- Maxim Dounin http://nginx.org/ From mva at mva.name Tue Jun 16 15:30:32 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 16 Jun 2015 21:30:32 +0600 Subject: nginx-1.9.2 In-Reply-To: <20150616152712.GZ26357@mdounin.ru> References: <20150616152712.GZ26357@mdounin.ru> Message-ID: <2396120.ZumS0qFaMZ@note> В письме от Вт, 16 июня 2015 18:27:12 пользователь Maxim Dounin написал: > *) Добавление: директивы allow и deny в модуле stream. > > *) Добавление: директива proxy_bind в модуле stream. > > *) Добавление: директива proxy_protocol в модуле stream. Спасибо! ;) Прям, как будто юзерскую рассылку читали :) // хотя, надо глянуть кто коммитил код. Может, и вправду читали :) -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From maxim at nginx.com Tue Jun 16 15:36:23 2015 From: maxim at nginx.com (Maxim Konovalov) Date: Tue, 16 Jun 2015 18:36:23 +0300 Subject: nginx-1.9.2 In-Reply-To: <2396120.ZumS0qFaMZ@note> References: <20150616152712.GZ26357@mdounin.ru> <2396120.ZumS0qFaMZ@note> Message-ID: <55804277.5090004@nginx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/16/15 6:30 PM, Vadim A. Misbakh-Soloviov wrote: > В письме от Вт, 16 июня 2015 18:27:12 пользователь Maxim Dounin > написал: >> *) Добавление: директивы allow и deny в модуле stream. >> >> *) Добавление: директива proxy_bind в модуле stream. >> >> *) Добавление: директива proxy_protocol в модуле stream. > > Спасибо! ;) > > Прям, как будто юзерскую рассылку читали :) > > // хотя, надо глянуть кто коммитил код. Может, и вправду читали > :) > У нас только писатели, читателей нет. Кроме шуток, эти вещи были в плане еще до релиза tcp балансировщика. - -- Maxim Konovalov http://nginx.com -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlWAQncACgkQ7PDpCywXIIMlewCfXJIXT6IhPA03mLrD48HfRtBp w7YAoKAU9ZZiQq2+y/osc1ygQZAhTQKK =2czm -----END PGP SIGNATURE----- From nginx-forum at nginx.us Tue Jun 16 23:53:32 2015 From: nginx-forum at nginx.us (cilrill) Date: Tue, 16 Jun 2015 19:53:32 -0400 Subject: =?UTF-8?B?cmVzaXplIGltYWdlINC60LDQuiDQt9Cw0LTQsNGC0Ywg0L/QtdGA0LXQvNC10L0=?= =?UTF-8?B?0L3Rg9GOLCDQtdGB0LvQuCDQtdC1INC90LXRgiDQsiDQsNGA0LPRg9C80LU=?= =?UTF-8?B?0L3RgtCw0YU=?= Message-ID: Добрый день. Хочу ресайзить картинки, используя ссылки вида hostname/img.png?s=100&q=20 где hostname/img.png - путь к оригинальной картинке а два аргумента s и q - ширина и качество преобразованной картинки работает следующая конфигурация. location ~ ^/(.*\.(?:jpg|gif|png))$ { alias /home/$host/$1; image_filter resize $arg_s -; image_filter_jpeg_quality $arg_q; access_log /var/log/nginx/access.img.log; } но как обрабатывать ссылки вида hostname/img.png?s=100 без указания явно аргумента отвечающего за качество картинки? пытался вставить проверку вида location ~ ^/(.*\.(?:jpg|gif|png))$ { alias /home/$host/$1; if ( $arg_q = "") { set $arg_q 75; } image_filter resize $arg_s -; image_filter_jpeg_quality $arg_q; access_log /var/log/nginx/access.img.log; } при попадании в location - ругается, что используется необъявленная переменная arg_q и все рушится. пытался задать переменную вне location - set $arg_q 75; image_filter_jpeg_quality после этого в локейшене выполняется с параметром 75, даже если в аргументах передавал другое значение. подскажите плз как исправить ситуацию? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259674,259674#msg-259674 From mdounin at mdounin.ru Wed Jun 17 02:36:39 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 17 Jun 2015 05:36:39 +0300 Subject: =?UTF-8?B?UmU6IHJlc2l6ZSBpbWFnZSDQutCw0Log0LfQsNC00LDRgtGMINC/0LXRgNC10Lw=?= =?UTF-8?B?0LXQvdC90YPRjiwg0LXRgdC70Lgg0LXQtSDQvdC10YIg0LIg0LDRgNCz0YM=?= =?UTF-8?B?0LzQtdC90YLQsNGF?= In-Reply-To: References: Message-ID: <20150617023639.GH26357@mdounin.ru> Hello! On Tue, Jun 16, 2015 at 07:53:32PM -0400, cilrill wrote: [...] > пытался вставить проверку вида > > > location ~ ^/(.*\.(?:jpg|gif|png))$ { > alias /home/$host/$1; > if ( $arg_q = "") { > set $arg_q 75; > } > image_filter resize $arg_s -; > image_filter_jpeg_quality $arg_q; > access_log /var/log/nginx/access.img.log; > } > > при попадании в location - ругается, что используется необъявленная > переменная arg_q и все рушится. > пытался задать переменную вне location - > > set $arg_q 75; > > image_filter_jpeg_quality после этого в локейшене выполняется с параметром > 75, даже если в аргументах передавал другое значение. > > подскажите плз как исправить ситуацию? Не надо пытаться установить переменную $arg_q, от этого будут сплошные проблемы и никакого счастья. Правильно как-то так: set $q 75; if ($arg_q) { set $q $arg_q; } image_filter_jpeg_quality $q; Или даже так: map $arg_q $q { default 75; ~[0-9]+ $arg_q; } image_filter_jpeg_quality $q; -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Wed Jun 17 06:03:30 2015 From: nginx-forum at nginx.us (cilrill) Date: Wed, 17 Jun 2015 02:03:30 -0400 Subject: =?UTF-8?B?UmU6IHJlc2l6ZSBpbWFnZSDQutCw0Log0LfQsNC00LDRgtGMINC/0LXRgNC10Lw=?= =?UTF-8?B?0LXQvdC90YPRjiwg0LXRgdC70Lgg0LXQtSDQvdC10YIg0LIg0LDRgNCz0YM=?= =?UTF-8?B?0LzQtdC90YLQsNGF?= In-Reply-To: <20150617023639.GH26357@mdounin.ru> References: <20150617023639.GH26357@mdounin.ru> Message-ID: <99e8ff601d8438403c5c549cd3432a36.NginxMailingListRussian@forum.nginx.org> спасибо. вылезла не понятная мне проблема ( завел переменные с проверкой server { listen 80; server_name static.vhost static.vhost2; location ~ ^/(.*\.(?:jpg|gif|png))$ { alias /home/$host$uri; set $q 75; if ($arg_q) { set $q $arg_q; } if ($arg_s) { set $s $arg_s; } image_filter resize $s -; image_filter_jpeg_quality $q; access_log /var/log/nginx/access.img.log; error_page 415 = @images; } location @images { root /home/$host; } } развалилось ) в дебаге вот такое 2015/06/17 05:06:27 [debug] 818#0: *105 content phase: 22 2015/06/17 05:06:27 [debug] 818#0: *105 http script copy: "/home/" 2015/06/17 05:06:27 [debug] 818#0: *105 http script var: "static.vhost" 2015/06/17 05:06:27 [debug] 818#0: *105 http script var: "/bg.png" 2015/06/17 05:06:27 [debug] 818#0: *105 http filename: "/home/static.vhost/bg.png1.1 Host" 2015/06/17 05:06:27 [debug] 818#0: *105 add cleanup: 00000000010BE2C0 2015/06/17 05:06:27 [error] 818#0: *105 open() "/home/stati" failed (2: No such file or directory), client: 172.17.42.1, server: static.vhost, request: "GET /bg.png?s=280&q=20 HTTP/1.1", host: "static.vhost" 2015/06/17 05:06:27 [debug] 818#0: *105 http finalize request: 404, "/bg.png?s=280&q=20" a:1, c:1 2015/06/17 05:06:27 [debug] 818#0: *105 http special response: 404, "/bg.png?s=280&q=20" 2015/06/17 05:06:27 [debug] 818#0: *105 http set discard body 2015/06/17 05:06:27 [debug] 818#0: *105 uploadprogress error-tracker error: 404 2015/06/17 05:06:27 [debug] 818#0: *105 uploadprogress error-tracker not tracking in this location 2015/06/17 05:06:27 [debug] 818#0: *105 http output filter "/bg.png?s=280&q=20" 2015/06/17 05:06:27 [debug] 818#0: *105 http copy filter: "/bg.png?s=280&q=20" 2015/06/17 05:06:27 [debug] 818#0: *105 image filter 2015/06/17 05:06:27 [debug] 818#0: *105 image filter: " References: <173d9346b17a23c8262d8f31840e76c3.NginxMailingListRussian@forum.nginx.org> Message-ID: <010bcf22f8d580f1aadfd0a6dcb53b77.NginxMailingListRussian@forum.nginx.org> Проблему решил, для SSL был отдельный конфиг который я не замечал... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259643,259677#msg-259677 From alexander.moskalenko at gmail.com Wed Jun 17 09:13:45 2015 From: alexander.moskalenko at gmail.com (Alexander Moskalenko) Date: Wed, 17 Jun 2015 12:13:45 +0300 Subject: signal 11 on 1.8.0 SSL shared cache + Safari Message-ID: Приветствую, Проблема только в Safari при использовании ssl_session_cache shared:SSL:10m; если установить в builtin либо вообще выключить то все работает в Safari при этом 'connection closed' 2015/06/17 11:01:46 [alert] 24556#0: worker process 24995 exited on signal 11 # nginx -V nginx version: nginx/1.8.0 built by gcc 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC) built with OpenSSL 1.0.1e-fips 11 Feb 2013 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_spdy_module --with-cc-opt='-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' Конфиг: server { listen 80; listen 443 ssl spdy; server_name ; add_header Access-Control-Allow-Origin *; ssl_session_timeout 5m; ssl_session_cache shared:SSL:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_buffer_size 8k; ssl_ciphers 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS'; ssl_prefer_server_ciphers on; proxy_set_header SSL $https; ssl_certificate ssl/.pem; ssl_certificate_key ssl/.key; error_page 405 = $uri; location / { client_max_body_size 800m; proxy_pass http://upstream; proxy_set_header Host $http_host; proxy_buffering off; proxy_read_timeout 10m; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Jun 17 13:05:37 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 17 Jun 2015 16:05:37 +0300 Subject: =?UTF-8?B?UmU6IHJlc2l6ZSBpbWFnZSDQutCw0Log0LfQsNC00LDRgtGMINC/0LXRgNC10Lw=?= =?UTF-8?B?0LXQvdC90YPRjiwg0LXRgdC70Lgg0LXQtSDQvdC10YIg0LIg0LDRgNCz0YM=?= =?UTF-8?B?0LzQtdC90YLQsNGF?= In-Reply-To: <99e8ff601d8438403c5c549cd3432a36.NginxMailingListRussian@forum.nginx.org> References: <20150617023639.GH26357@mdounin.ru> <99e8ff601d8438403c5c549cd3432a36.NginxMailingListRussian@forum.nginx.org> Message-ID: <20150617130537.GK26357@mdounin.ru> Hello! On Wed, Jun 17, 2015 at 02:03:30AM -0400, cilrill wrote: > спасибо. > > вылезла не понятная мне проблема ( > завел переменные с проверкой > > server { > listen 80; > server_name static.vhost static.vhost2; > > location ~ ^/(.*\.(?:jpg|gif|png))$ { > alias /home/$host$uri; > set $q 75; > if ($arg_q) { > set $q $arg_q; > } > if ($arg_s) { > set $s $arg_s; > } > image_filter resize $s -; > image_filter_jpeg_quality $q; > access_log /var/log/nginx/access.img.log; > error_page 415 = @images; > } > > location @images { > root /home/$host; > } > } > > развалилось ) > > в дебаге вот такое > > 2015/06/17 05:06:27 [debug] 818#0: *105 content phase: 22 > 2015/06/17 05:06:27 [debug] 818#0: *105 http script copy: "/home/" > 2015/06/17 05:06:27 [debug] 818#0: *105 http script var: "static.vhost" > 2015/06/17 05:06:27 [debug] 818#0: *105 http script var: "/bg.png" > 2015/06/17 05:06:27 [debug] 818#0: *105 http filename: > "/home/static.vhost/bg.png1.1 > Host" Что показывает nginx -v? Выглядит, как проблема, исправленная в nginx 1.7.1: *) Bugfix: the "alias" directive used inside a location given by a regular expression worked incorrectly if the "if" or "limit_except" directives were used. Отмечу, что сейчас имеет смысл пользоваться 1.8.0 или 1.9.2, более старые версии - исключительно на свой страх и риск. [...] > я не правильно пути для alias формирую? Вообще тут нет смысла использовать alias, достаточно сказать root /home/$host; Остальное nginx сделает сам, и более корректно, чем при использовании alias'а (не говоря уже про более эффективно). -- Maxim Dounin http://nginx.org/ From mdounin at mdounin.ru Wed Jun 17 13:13:14 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 17 Jun 2015 16:13:14 +0300 Subject: signal 11 on 1.8.0 SSL shared cache + Safari In-Reply-To: References: Message-ID: <20150617131314.GL26357@mdounin.ru> Hello! On Wed, Jun 17, 2015 at 12:13:45PM +0300, Alexander Moskalenko wrote: > Приветствую, > > Проблема только в Safari при использовании > ssl_session_cache shared:SSL:10m; > > если установить в builtin либо вообще выключить то все работает > > в Safari при этом 'connection closed' > > 2015/06/17 11:01:46 [alert] 24556#0: worker process 24995 exited on signal 11 [...] > ssl_session_timeout 5m; > ssl_session_cache shared:SSL:10m; Судя по всему, используется разный session кеш в разных виртуальных серверах. Так работать не будет, нужно сконфигурировать одинаковы кеш (проще всего - на уровне http{}). Подробности можно почитать в этом тикете: http://trac.nginx.org/nginx/ticket/235 -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Wed Jun 17 13:19:53 2015 From: nginx-forum at nginx.us (billgx) Date: Wed, 17 Jun 2015 09:19:53 -0400 Subject: $bytes_sent is never written before you finished downloading Message-ID: nginx according to my configuration writes $bytes_sent to the log file. If i was downloading a file within 5 hours, i would see it in the log after i finished. How to know any information about $bytes_sent before i finished? For example every minute or every other chunk. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259691,259691#msg-259691 From nginx-forum at nginx.us Wed Jun 17 13:25:20 2015 From: nginx-forum at nginx.us (billgx) Date: Wed, 17 Jun 2015 09:25:20 -0400 Subject: $bytes_sent is never written before you finished downloading In-Reply-To: References: Message-ID: <0b9a87fedc99739350e9a18d2bd88d10.NginxMailingListRussian@forum.nginx.org> Промахнулся форумом. Раз уж удалить нельзя, то поясню вопрос: $bytes_sent пишутся в лог только после оканчания скачивания. Даже если я качал файл 5 часов, то увижу я в логе это после окончания. Хотелось бы писать в лог каждую минуту или через несколько chunkов Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259691,259692#msg-259692 From nginx-forum at nginx.us Wed Jun 17 14:59:59 2015 From: nginx-forum at nginx.us (BieZax) Date: Wed, 17 Jun 2015 10:59:59 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: <5579A7BB.8050909@citrin.ru> References: <5579A7BB.8050909@citrin.ru> Message-ID: <5966ec8dd961b9c9dcb1bbd599b0bf6a.NginxMailingListRussian@forum.nginx.org> Поэксперементировал еще немного, но пока не получается понять, где затык. Конфиг nginx: user www www; worker_processes auto; worker_rlimit_nofile 200000; error_log /var/log/nginx/nginx-error_log warn; events { worker_connections 8192; use kqueue; multi_accept on; } http { access_log off; include mime.types; include win-utf; default_type application/octet-stream; log_format inc '$host;$remote_addr;$status;$upstream_response_time;$upstream_addr;$upstream_status;$http_x_forwarded_for;$time_local;$request;$http_user_agent'; sendfile on; tcp_nopush on; tcp_nodelay on; sendfile_max_chunk 32m; reset_timedout_connection on; client_header_buffer_size 16k; large_client_header_buffers 4 8k; client_max_body_size 5m; client_body_buffer_size 128k; variables_hash_max_size 1024; server_names_hash_bucket_size 256; keepalive_timeout 15; client_body_timeout 10s; client_header_timeout 10s; lingering_time 10s; send_timeout 10s; #gzip gzip on; gzip_min_length 2048; gzip_comp_level 4; gzip_http_version 1.0; gzip_proxied any; gzip_buffers 32 64k; gzip_types text/plain text/xml text/css text/javascript application/xml application/x-javascript application/atom+xml application/xaml+xml application/rtf application/json; gzip_vary off; open_file_cache max=30000 inactive=60s; open_file_cache_valid 60s; open_file_cache_min_uses 2; open_file_cache_errors on; #Proxy proxy_buffers 512 8k; proxy_buffer_size 64k; output_buffers 32 512k; proxy_send_timeout 180; proxy_read_timeout 180; } Sysctl: security.bsd.see_other_uids=0 kern.ipc.maxsockets=204800 kern.ipc.nmbclusters=262144 kern.ipc.shm_use_phys=1 kern.ipc.somaxconn=4096 kern.maxfiles=204800 kern.maxfilesperproc=200000 kern.maxvnodes=256000 kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 kern.sync_on_panic=1 net.inet.icmp.bmcastecho=0 net.inet.icmp.drop_redirect=1 net.inet.icmp.maskrepl=0 net.inet.ip.intr_queue_maxlen=256 net.inet.ip.maxfragpackets=1024 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 net.inet.ip.portrange.randomized=0 net.inet.ip.redirect=0 net.inet.ip.sourceroute=0 net.inet.ip.accept_sourceroute=0 net.inet.tcp.blackhole=2 net.inet.tcp.drop_synfin=1 net.inet.tcp.fast_finwait2_recycle=1 net.inet.tcp.finwait2_timeout=3000 net.inet.tcp.hostcache.expire=1200 net.inet.tcp.keepinit=5000 net.inet.tcp.maxtcptw=65536 net.inet.tcp.msl=5000 net.inet.tcp.recvbuf_auto=0 net.inet.tcp.recvspace=65536 net.inet.tcp.sendbuf_auto=0 net.inet.tcp.sendspace=131072 net.inet.tcp.syncookies=1 net.inet.tcp.tso=0 net.inet.udp.blackhole=1 net.inet.udp.recvspace=32768 net.isr.direct=1 net.route.netisr_maxqlen=1024 vfs.ufs.dirhash_maxmem=100000000 loader.conf: kern.ipc.nmbclusters=0 net.inet.tcp.reass.maxsegments=2048 vm.pmap.shpgperproc=400 hw.em.rxd=4096 hw.em.txd=4096 hw.em.rx_int_delay=100 hw.em.tx_int_delay=100 hw.em.rx_abs_int_delay=1000 hw.em.tx_abs_int_delay=1000 dev.em.rx_processing_limit=-1 net.inet.tcp.hostcache.hashsize=4096 net.inet.tcp.hostcache.bucketlimit=100 net.inet.tcp.hostcache.cachelimit=65536 net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=100 net.inet.tcp.syncache.cachelimit=65536 net.inet.tcp.tcbhashsize=4096 net.isr.defaultqlimit=4096 net.isr.bindthreads=1 net.isr.maxthreads=8 net.link.ifqmaxlen=1024 Сократил размер файла до 1 Кб LA ~5 при 16 ядрах IO в порядке, загрузка сети около 130 мегабит/c Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259544,259693#msg-259693 From vbart at nginx.com Wed Jun 17 15:07:18 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 17 Jun 2015 18:07:18 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: <5966ec8dd961b9c9dcb1bbd599b0bf6a.NginxMailingListRussian@forum.nginx.org> References: <5579A7BB.8050909@citrin.ru> <5966ec8dd961b9c9dcb1bbd599b0bf6a.NginxMailingListRussian@forum.nginx.org> Message-ID: <1640454.LY6FGzoTIK@vbart-workstation> On Wednesday 17 June 2015 10:59:59 BieZax wrote: > Поэксперементировал еще немного, но пока не получается понять, где > затык. Конфиг nginx: [..] > > Сократил размер файла до 1 Кб > LA ~5 при 16 ядрах > IO в порядке, загрузка сети около 130 мегабит/c > А на клиенте? Упираться вполне может клиент, таким образом вы будете тестировать не производительность nginx, а производительность клиента. -- Валентин Бартенев From nginx-forum at nginx.us Wed Jun 17 19:44:02 2015 From: nginx-forum at nginx.us (xpwy) Date: Wed, 17 Jun 2015 15:44:02 -0400 Subject: =?UTF-8?B?0JzQsNC60YHQuNC80LDQu9GM0L3QvtC1INC60L7Quy3QstC+INCy0LjRgNGC0YM=?= =?UTF-8?B?0LDQu9GM0L3Ri9GFINGB0LXRgNCy0LXRgNC+0LI=?= Message-ID: <84c3472a68ef586fd15a6b2b30ff2c7e.NginxMailingListRussian@forum.nginx.org> Всем добрый вечер. Интересует ответ на следующий вопрос: есть какое-то ограничение на кол-во виртуальных серверов (блок server) внутри http блока? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259698,259698#msg-259698 From mva at mva.name Wed Jun 17 19:54:32 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Thu, 18 Jun 2015 01:54:32 +0600 Subject: =?UTF-8?B?UmU6INCc0LDQutGB0LjQvNCw0LvRjNC90L7QtSDQutC+0Lst0LLQviDQstC40YA=?= =?UTF-8?B?0YLRg9Cw0LvRjNC90YvRhSDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <84c3472a68ef586fd15a6b2b30ff2c7e.NginxMailingListRussian@forum.nginx.org> References: <84c3472a68ef586fd15a6b2b30ff2c7e.NginxMailingListRussian@forum.nginx.org> Message-ID: <13535065.ODbH0kjHtd@note> В письме от Ср, 17 июня 2015 15:44:02 пользователь xpwy написал: > Всем добрый вечер. Интересует ответ на следующий вопрос: есть какое-то > ограничение на кол-во виртуальных серверов (блок server) внутри http блока? Нету. // Поэтому задавайте, пожалуйста, истинный вопрос, который вас интересует, а не метавопрос, который вы ДУМАЕТЕ поможет вам решить ваш вопрос :) -- Best regards, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nginx-forum at nginx.us Wed Jun 17 19:59:27 2015 From: nginx-forum at nginx.us (cilrill) Date: Wed, 17 Jun 2015 15:59:27 -0400 Subject: =?UTF-8?B?UmU6IHJlc2l6ZSBpbWFnZSDQutCw0Log0LfQsNC00LDRgtGMINC/0LXRgNC10Lw=?= =?UTF-8?B?0LXQvdC90YPRjiwg0LXRgdC70Lgg0LXQtSDQvdC10YIg0LIg0LDRgNCz0YM=?= =?UTF-8?B?0LzQtdC90YLQsNGF?= In-Reply-To: <20150617130537.GK26357@mdounin.ru> References: <20150617130537.GK26357@mdounin.ru> Message-ID: <46335296074081b072f91407f0b4b43d.NginxMailingListRussian@forum.nginx.org> спасибо. root /home/$host; помогло, теперь все работает как задуманно. установлен пакет nginx-extras из репозитория debian 8 nginx -v nginx version: nginx/1.6.2 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259674,259700#msg-259700 From nginx-forum at nginx.us Wed Jun 17 20:03:43 2015 From: nginx-forum at nginx.us (xpwy) Date: Wed, 17 Jun 2015 16:03:43 -0400 Subject: =?UTF-8?B?UmU6INCc0LDQutGB0LjQvNCw0LvRjNC90L7QtSDQutC+0Lst0LLQviDQstC40YA=?= =?UTF-8?B?0YLRg9Cw0LvRjNC90YvRhSDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <13535065.ODbH0kjHtd@note> References: <13535065.ODbH0kjHtd@note> Message-ID: <0fabb356497e89994acce4f313779147.NginxMailingListRussian@forum.nginx.org> mva Wrote: ------------------------------------------------------- > В письме от Ср, 17 июня 2015 15:44:02 пользователь xpwy написал: > > Всем добрый вечер. Интересует ответ на следующий вопрос: есть > какое-то > > ограничение на кол-во виртуальных серверов (блок server) внутри http > блока? > > Нету. > > // Поэтому задавайте, пожалуйста, истинный вопрос, который вас > интересует, а > не метавопрос, который вы ДУМАЕТЕ поможет вам решить ваш вопрос :) > > -- > Best regards, > mva > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Спасибо за ответ :) Просто нигде не видел упоминания об этом, стало интересно. И вы правы, истинный вопрос есть, задам его новой темой. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259698,259701#msg-259701 From nginx-forum at nginx.us Wed Jun 17 20:06:35 2015 From: nginx-forum at nginx.us (xpwy) Date: Wed, 17 Jun 2015 16:06:35 -0400 Subject: =?UTF-8?B?0J/QtdGA0LXQvtC00LjRh9C10YHQutC4INC/0YDQvtC/0LDQtNCw0LXRgiBwaWQg?= =?UTF-8?B?0YTQsNC50Ls=?= Message-ID: Всем добрый вечер. Переодически возникает ошибка, что pid файл не найден, поэтому невозможно произвести перезагрузку nginx. С чем это может быть связано? Может ли сам nginx удалять его О_О? И вообще, в какую сторону копать для истины? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259702,259702#msg-259702 From sytar.alex at gmail.com Wed Jun 17 20:18:27 2015 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Wed, 17 Jun 2015 23:18:27 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L7QtNC40YfQtdGB0LrQuCDQv9GA0L7Qv9Cw0LTQsNC10YIg?= =?UTF-8?B?cGlkINGE0LDQudC7?= In-Reply-To: References: Message-ID: 17 июня 2015 г., 23:06 пользователь xpwy написал: > Всем добрый вечер. > > Переодически возникает ошибка, что pid файл не найден, поэтому невозможно > произвести перезагрузку nginx. С чем это может быть связано? Может ли сам > nginx удалять его О_О? И вообще, в какую сторону копать для истины? > nginx пидами не управляет, смотрите скрипт запуска. Чтобы nginx обновил конфигурацию вовсе не обязательно иметь pid master-процесса, достаточно сказать nginx -s reload > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,259702,259702#msg-259702 > > _______________________________________________ > 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 Wed Jun 17 20:27:54 2015 From: nginx-forum at nginx.us (xpwy) Date: Wed, 17 Jun 2015 16:27:54 -0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L7QtNC40YfQtdGB0LrQuCDQv9GA0L7Qv9Cw0LTQsNC10YIg?= =?UTF-8?B?cGlkINGE0LDQudC7?= In-Reply-To: References: Message-ID: Aleksandr Sytar Wrote: ------------------------------------------------------- > 17 июня 2015 г., 23:06 пользователь xpwy > написал: > > > Всем добрый вечер. > > > > Переодически возникает ошибка, что pid файл не найден, поэтому > невозможно > > произвести перезагрузку nginx. С чем это может быть связано? Может > ли сам > > nginx удалять его О_О? И вообще, в какую сторону копать для истины? > > > > nginx пидами не управляет, смотрите скрипт запуска. Чтобы nginx > обновил > конфигурацию вовсе не обязательно иметь pid master-процесса, > достаточно > сказать nginx -s reload > > > > > Posted at Nginx Forum: > > http://forum.nginx.org/read.php?21,259702,259702#msg-259702 > > > > _______________________________________________ > > 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. Производится какое-нибудь обновление конфигурационного файла, после nginx -s reload, и бывает частенько так, что появляется ошибка: nginx: [error] invalid PID number "" in "/usr/local/nginx/logs/nginx.pid" Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259702,259704#msg-259704 From sytar.alex at gmail.com Wed Jun 17 21:03:45 2015 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Thu, 18 Jun 2015 00:03:45 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L7QtNC40YfQtdGB0LrQuCDQv9GA0L7Qv9Cw0LTQsNC10YIg?= =?UTF-8?B?cGlkINGE0LDQudC7?= In-Reply-To: References: Message-ID: 17 июня 2015 г., 23:27 пользователь xpwy написал: > Aleksandr Sytar Wrote: > ------------------------------------------------------- > > 17 июня 2015 г., 23:06 пользователь xpwy > > написал: > > > > > Всем добрый вечер. > > > > > > Переодически возникает ошибка, что pid файл не найден, поэтому > > невозможно > > > произвести перезагрузку nginx. С чем это может быть связано? Может > > ли сам > > > nginx удалять его О_О? И вообще, в какую сторону копать для истины? > > > > > > > nginx пидами не управляет, смотрите скрипт запуска. Чтобы nginx > > обновил > > конфигурацию вовсе не обязательно иметь pid master-процесса, > > достаточно > > сказать nginx -s reload > > > > > > > > Posted at Nginx Forum: > > > http://forum.nginx.org/read.php?21,259702,259702#msg-259702 > > > > > > _______________________________________________ > > > 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. Производится какое-нибудь > обновление конфигурационного файла, после nginx -s reload, и бывает > частенько так, что появляется ошибка: nginx: [error] invalid PID number "" > in "/usr/local/nginx/logs/nginx.pid" > > Слово logs намекает что pid лежит в папке вместе с логами, на которую, скорее всего натравлен logrotate -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmm at csdoc.com Wed Jun 17 21:07:31 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 18 Jun 2015 00:07:31 +0300 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L7QtNC40YfQtdGB0LrQuCDQv9GA0L7Qv9Cw0LTQsNC10YIg?= =?UTF-8?B?cGlkINGE0LDQudC7?= In-Reply-To: References: Message-ID: <5581E193.1080602@csdoc.com> On 17.06.2015 23:06, xpwy wrote: > Переодически возникает ошибка, что pid файл не найден, > поэтому невозможно произвести перезагрузку nginx. какая версия nginx ? что показывает nginx -V ? > С чем это может быть связано?Может ли сам nginx удалять его О_О? теоретически может, он это делает как минимум в двух случаях: 1) в ngx_master_process_exit перед завершением работы мастера 2) в ngx_init_cycle есть ngx_delete_pidfile(old_cycle); > И вообще, в какую сторону копать для истины? например, с помощью http://man7.org/linux/man-pages/man1/inotifywait.1.html посмотреть когда и какие операции происходят с pid-файлом. если в функцию ngx_delete_pidfile добавить отладочную печать об успешном удалении pid-файла - тогда можно будет понять, кто именно его удалил, nginx или кто-то еще. -- Best regards, Gena From nginx-forum at nginx.us Thu Jun 18 06:55:10 2015 From: nginx-forum at nginx.us (kronk) Date: Thu, 18 Jun 2015 02:55:10 -0400 Subject: =?UTF-8?B?UmU6INCc0LDQutGB0LjQvNCw0LvRjNC90L7QtSDQutC+0Lst0LLQviDQstC40YA=?= =?UTF-8?B?0YLRg9Cw0LvRjNC90YvRhSDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <84c3472a68ef586fd15a6b2b30ff2c7e.NginxMailingListRussian@forum.nginx.org> References: <84c3472a68ef586fd15a6b2b30ff2c7e.NginxMailingListRussian@forum.nginx.org> Message-ID: <1b7bac898307301fdf77a37bea91e3d1.NginxMailingListRussian@forum.nginx.org> Для виртуальных серверов лучше всего создать отдельную папку, а не создавать в основном конфиге. Добавь в основной конфиг ngin.conf строку include /usr/local/etc/nginx/vhosts/*.conf; предварительно создав папку vhosts например и потом в этой папке создавай файлы с отдельными сайтами. Я так делаю и не засоряю основной конфиг. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259698,259708#msg-259708 From nginx-forum at nginx.us Thu Jun 18 08:27:17 2015 From: nginx-forum at nginx.us (xpwy) Date: Thu, 18 Jun 2015 04:27:17 -0400 Subject: =?UTF-8?B?UmU6INCc0LDQutGB0LjQvNCw0LvRjNC90L7QtSDQutC+0Lst0LLQviDQstC40YA=?= =?UTF-8?B?0YLRg9Cw0LvRjNC90YvRhSDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <1b7bac898307301fdf77a37bea91e3d1.NginxMailingListRussian@forum.nginx.org> References: <84c3472a68ef586fd15a6b2b30ff2c7e.NginxMailingListRussian@forum.nginx.org> <1b7bac898307301fdf77a37bea91e3d1.NginxMailingListRussian@forum.nginx.org> Message-ID: <59e93cd0aaaf08c03449c502ee9fde00.NginxMailingListRussian@forum.nginx.org> kronk Wrote: ------------------------------------------------------- > Для виртуальных серверов лучше всего создать отдельную папку, а не > создавать в основном конфиге. > Добавь в основной конфиг ngin.conf строку include > /usr/local/etc/nginx/vhosts/*.conf; предварительно создав папку vhosts > например и потом в этой папке создавай файлы с отдельными сайтами. Я > так делаю и не засоряю основной конфиг. Еще лучше делать через линки. Т.е. в одной папке лежит сам файл конфига, а в другой папке линк на него. В nginx.conf указываешь include на папку с линками. Удобно отключать и включать домены при приксировании. Просто я не сильно знаком с архитектурой nginx, и не в курсе как именно он хранит каждый блок server. Были такие догадки: если все блоки server сливаются в одну переменную, а потом парсятся, то лимит был бы ~4гб под все конфи. Но как мне уже дали понять, никаких ограничей нет. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259698,259710#msg-259710 From alexander.moskalenko at gmail.com Thu Jun 18 08:35:33 2015 From: alexander.moskalenko at gmail.com (Alexander Moskalenko) Date: Thu, 18 Jun 2015 11:35:33 +0300 Subject: signal 11 on 1.8.0 SSL shared cache + Safari In-Reply-To: <20150617131314.GL26357@mdounin.ru> References: <20150617131314.GL26357@mdounin.ru> Message-ID: Максим, Данная директива описана только один раз и подключается во все сервера через include. 2015-06-17 16:13 GMT+03:00 Maxim Dounin : > Hello! > > On Wed, Jun 17, 2015 at 12:13:45PM +0300, Alexander Moskalenko wrote: > > > Приветствую, > > > > Проблема только в Safari при использовании > > ssl_session_cache shared:SSL:10m; > > > > если установить в builtin либо вообще выключить то все работает > > > > в Safari при этом 'connection closed' > > > > 2015/06/17 11:01:46 [alert] 24556#0: worker process 24995 exited on > signal 11 > > [...] > > > ssl_session_timeout 5m; > > ssl_session_cache shared:SSL:10m; > > Судя по всему, используется разный session кеш в разных > виртуальных серверах. Так работать не будет, нужно > сконфигурировать одинаковы кеш (проще всего - на уровне http{}). > > Подробности можно почитать в этом тикете: > > http://trac.nginx.org/nginx/ticket/235 > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > 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 Jun 18 08:54:30 2015 From: nginx-forum at nginx.us (xpwy) Date: Thu, 18 Jun 2015 04:54:30 -0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L7QtNC40YfQtdGB0LrQuCDQv9GA0L7Qv9Cw0LTQsNC10YIg?= =?UTF-8?B?cGlkINGE0LDQudC7?= In-Reply-To: References: Message-ID: <294a951907435ff2afe26536dd508828.NginxMailingListRussian@forum.nginx.org> А это идея, заметил, что в этой папке лежат access и error лог, хотя в кофиге нет указаний на эту папку. Все логи серверов хранятся в папке /var/log/nginx. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259702,259712#msg-259712 From nginx-forum at nginx.us Thu Jun 18 09:35:25 2015 From: nginx-forum at nginx.us (BieZax) Date: Thu, 18 Jun 2015 05:35:25 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: <1640454.LY6FGzoTIK@vbart-workstation> References: <1640454.LY6FGzoTIK@vbart-workstation> Message-ID: <75e246dda48ff637fa4917081771adf4.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Wednesday 17 June 2015 10:59:59 BieZax wrote: > > Поэксперементировал еще немного, но пока не получается понять, > где > > затык. Конфиг nginx: > [..] > > > > Сократил размер файла до 1 Кб > > LA ~5 при 16 ядрах > > IO в порядке, загрузка сети около 130 мегабит/c > > > > А на клиенте? Упираться вполне может клиент, таким образом вы будете > тестировать > не производительность nginx, а производительность клиента. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Без внутреннего перенаправления пролетает 30000rps, с перенаправлением ~13 тыс. Логично предположить ,что клиент тут не при делах. Из интересного: кол-во подключений всегда около 30к, может во фряхе(9.3) какой-то лимит по соединениям, о котором я не знаю? На линуксе проблема не повторяется. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259544,259713#msg-259713 From nginx-forum at nginx.us Thu Jun 18 11:12:46 2015 From: nginx-forum at nginx.us (kronk) Date: Thu, 18 Jun 2015 07:12:46 -0400 Subject: =?UTF-8?B?UmU6INCc0LDQutGB0LjQvNCw0LvRjNC90L7QtSDQutC+0Lst0LLQviDQstC40YA=?= =?UTF-8?B?0YLRg9Cw0LvRjNC90YvRhSDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <59e93cd0aaaf08c03449c502ee9fde00.NginxMailingListRussian@forum.nginx.org> References: <84c3472a68ef586fd15a6b2b30ff2c7e.NginxMailingListRussian@forum.nginx.org> <1b7bac898307301fdf77a37bea91e3d1.NginxMailingListRussian@forum.nginx.org> <59e93cd0aaaf08c03449c502ee9fde00.NginxMailingListRussian@forum.nginx.org> Message-ID: Согласен, линками удобнее всего, просто привязываешь все свои сайты к одной папке и всего делов. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259698,259721#msg-259721 From vbart at nginx.com Thu Jun 18 12:01:00 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 18 Jun 2015 15:01 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: <75e246dda48ff637fa4917081771adf4.NginxMailingListRussian@forum.nginx.org> References: <1640454.LY6FGzoTIK@vbart-workstation> <75e246dda48ff637fa4917081771adf4.NginxMailingListRussian@forum.nginx.org> Message-ID: <2389905.xafVf4NkLn@vbart-workstation> On Thursday 18 June 2015 05:35:25 BieZax wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > On Wednesday 17 June 2015 10:59:59 BieZax wrote: > > > Поэксперементировал еще немного, но пока не получается понять, > > где > > > затык. Конфиг nginx: > > [..] > > > > > > Сократил размер файла до 1 Кб > > > LA ~5 при 16 ядрах > > > IO в порядке, загрузка сети около 130 мегабит/c > > > > > > > А на клиенте? Упираться вполне может клиент, таким образом вы будете > > тестировать > > не производительность nginx, а производительность клиента. > > > > -- > > Валентин Бартенев > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Без внутреннего перенаправления пролетает 30000rps, с перенаправлением > ~13 тыс. Логично предположить ,что клиент тут не при делах. Из > интересного: кол-во подключений всегда около 30к, может во > фряхе(9.3) какой-то лимит по соединениям, о котором я не знаю? На линуксе > проблема не повторяется. > Из этого нельзя такого предположить. Это может просто говорить о том, что клиент находится в зависимости от задержек при обработке ответов и не пытается нагружать сервер максимальным количеством запросов. Так, для сравнения, у меня только 4 ядра и далеко не серверных, на 1кб файле: Running 5m test @ http://127.0.0.1:8888/1k.html 4 threads and 10000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 782.79ms 1.07s 4.95s 81.36% Req/Sec 86.61k 19.39k 223.51k 80.68% 103239033 requests in 5.00m, 121.34GB read Requests/sec: 344017.77 Transfer/sec: 414.02MB Как видите, с вашими 30000rps на 16 ядрах едва ли вы можете упираться в nginx. Это либо сеть, либо клиент, либо что-то еще в системе. -- Валентин Бартенев From nginx-forum at nginx.us Thu Jun 18 16:05:45 2015 From: nginx-forum at nginx.us (BieZax) Date: Thu, 18 Jun 2015 12:05:45 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: <2389905.xafVf4NkLn@vbart-workstation> References: <2389905.xafVf4NkLn@vbart-workstation> Message-ID: <854ac501f9bf4af202ef99541a9758a3.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Thursday 18 June 2015 05:35:25 BieZax wrote: > > Валентин Бартенев Wrote: > > ------------------------------------------------------- > > > On Wednesday 17 June 2015 10:59:59 BieZax wrote: > > > > Поэксперементировал еще немного, но пока не получается > понять, > > > где > > > > затык. Конфиг nginx: > > > [..] > > > > > > > > Сократил размер файла до 1 Кб > > > > LA ~5 при 16 ядрах > > > > IO в порядке, загрузка сети около 130 мегабит/c > > > > > > > > > > А на клиенте? Упираться вполне может клиент, таким образом вы > будете > > > тестировать > > > не производительность nginx, а производительность клиента. > > > > > > -- > > > Валентин Бартенев > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > Без внутреннего перенаправления пролетает 30000rps, с > перенаправлением > > ~13 тыс. Логично предположить ,что клиент тут не при делах. > Из > > интересного: кол-во подключений всегда около 30к, может во > > фряхе(9.3) какой-то лимит по соединениям, о котором я не знаю? На > линуксе > > проблема не повторяется. > > > > Из этого нельзя такого предположить. Это может просто говорить о том, > что > клиент находится в зависимости от задержек при обработке ответов и не > пытается > нагружать сервер максимальным количеством запросов. > > Так, для сравнения, у меня только 4 ядра и далеко не серверных, на 1кб > файле: > > Running 5m test @ http://127.0.0.1:8888/1k.html > 4 threads and 10000 connections > Thread Stats Avg Stdev Max +/- Stdev > Latency 782.79ms 1.07s 4.95s 81.36% > Req/Sec 86.61k 19.39k 223.51k 80.68% > 103239033 requests in 5.00m, 121.34GB read > Requests/sec: 344017.77 > Transfer/sec: 414.02MB > > Как видите, с вашими 30000rps на 16 ядрах едва ли вы можете упираться > в nginx. > > Это либо сеть, либо клиент, либо что-то еще в системе. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru То, что нжинкс не причем, это понятно, т.к. на линуксе с тем же конфигом все замечательно работает. Потестил еще wrk, вот результат :( Без перенаправления Running 5m test @ http://192.168.1.1/index.html 16 threads and 30000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 739.14ms 334.20ms 2.00s 81.32% Req/Sec 1.79k 365.07 16.54k 79.40% 8476672 requests in 5.00m, 16.70GB read Socket errors: connect 1771, read 2975, write 636, timeout 423212 Requests/sec: 28246.05 Transfer/sec: 56.98MB С перенаправлением: Running 5m test @ http://192.168.1.1/index.html 16 threads and 30000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 146.66ms 238.77ms 2.00s 90.72% Req/Sec 598.93 169.07 3.39k 71.40% 2845012 requests in 5.00m, 3.39GB read Socket errors: connect 1197, read 1546, write 6297, timeout 1435215 Non-2xx or 3xx responses: 2845012 Requests/sec: 9480.29 Transfer/sec: 11.56MB Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259544,259731#msg-259731 From vbart at nginx.com Thu Jun 18 16:24:25 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 18 Jun 2015 19:24:25 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: <854ac501f9bf4af202ef99541a9758a3.NginxMailingListRussian@forum.nginx.org> References: <2389905.xafVf4NkLn@vbart-workstation> <854ac501f9bf4af202ef99541a9758a3.NginxMailingListRussian@forum.nginx.org> Message-ID: <2397902.sf7c0zERSv@vbart-workstation> On Thursday 18 June 2015 12:05:45 BieZax wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > On Thursday 18 June 2015 05:35:25 BieZax wrote: > > > Валентин Бартенев Wrote: > > > ------------------------------------------------------- > > > > On Wednesday 17 June 2015 10:59:59 BieZax wrote: > > > > > Поэксперементировал еще немного, но пока не получается > > понять, > > > > где > > > > > затык. Конфиг nginx: > > > > [..] > > > > > > > > > > Сократил размер файла до 1 Кб > > > > > LA ~5 при 16 ядрах > > > > > IO в порядке, загрузка сети около 130 мегабит/c > > > > > > > > > > > > > А на клиенте? Упираться вполне может клиент, таким образом вы > > будете > > > > тестировать > > > > не производительность nginx, а производительность клиента. > > > > > > > > -- > > > > Валентин Бартенев > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru at nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > Без внутреннего перенаправления пролетает 30000rps, с > > перенаправлением > > > ~13 тыс. Логично предположить ,что клиент тут не при делах. > > Из > > > интересного: кол-во подключений всегда около 30к, может во > > > фряхе(9.3) какой-то лимит по соединениям, о котором я не знаю? На > > линуксе > > > проблема не повторяется. > > > > > > > Из этого нельзя такого предположить. Это может просто говорить о том, > > что > > клиент находится в зависимости от задержек при обработке ответов и не > > пытается > > нагружать сервер максимальным количеством запросов. > > > > Так, для сравнения, у меня только 4 ядра и далеко не серверных, на 1кб > > файле: > > > > Running 5m test @ http://127.0.0.1:8888/1k.html > > 4 threads and 10000 connections > > Thread Stats Avg Stdev Max +/- Stdev > > Latency 782.79ms 1.07s 4.95s 81.36% > > Req/Sec 86.61k 19.39k 223.51k 80.68% > > 103239033 requests in 5.00m, 121.34GB read > > Requests/sec: 344017.77 > > Transfer/sec: 414.02MB > > > > Как видите, с вашими 30000rps на 16 ядрах едва ли вы можете упираться > > в nginx. > > > > Это либо сеть, либо клиент, либо что-то еще в системе. > > > > -- > > Валентин Бартенев > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > То, что нжинкс не причем, это понятно, т.к. на линуксе с тем же > конфигом все замечательно работает. > Потестил еще wrk, вот результат :( > > Без перенаправления > Running 5m test @ http://192.168.1.1/index.html > 16 threads and 30000 connections > Thread Stats Avg Stdev Max +/- Stdev > Latency 739.14ms 334.20ms 2.00s 81.32% > Req/Sec 1.79k 365.07 16.54k 79.40% > 8476672 requests in 5.00m, 16.70GB read > Socket errors: connect 1771, read 2975, write 636, timeout 423212 > Requests/sec: 28246.05 > Transfer/sec: 56.98MB > > С перенаправлением: > Running 5m test @ http://192.168.1.1/index.html > 16 threads and 30000 connections > Thread Stats Avg Stdev Max +/- Stdev > Latency 146.66ms 238.77ms 2.00s 90.72% > Req/Sec 598.93 169.07 3.39k 71.40% > 2845012 requests in 5.00m, 3.39GB read > Socket errors: connect 1197, read 1546, write 6297, timeout 1435215 > Non-2xx or 3xx responses: 2845012 > Requests/sec: 9480.29 > Transfer/sec: 11.56MB > Обратите внимание на количество ошибок, о которых сообщает wrk в ваших результатах. Явно что-то не так с настройками. А во втором случае еще и "Non-2xx or 3xx responses". -- Валентин Бартенев From mdounin at mdounin.ru Thu Jun 18 16:56:13 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 18 Jun 2015 19:56:13 +0300 Subject: signal 11 on 1.8.0 SSL shared cache + Safari In-Reply-To: References: <20150617131314.GL26357@mdounin.ru> Message-ID: <20150618165613.GS26357@mdounin.ru> Hello! On Thu, Jun 18, 2015 at 11:35:33AM +0300, Alexander Moskalenko wrote: > Максим, > > Данная директива описана только один раз и подключается во все сервера > через include. Ну вот если вы случайно пропустили сервер по умолчанию - такое поведение и будет наблюдаться. Впрочем, никто не мешает пойти по полному пути и для начала получить корку и посмотреть бектрейс, подробности тут: http://wiki.nginx.org/Debugging -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Thu Jun 18 20:36:50 2015 From: nginx-forum at nginx.us (ksimute) Date: Thu, 18 Jun 2015 16:36:50 -0400 Subject: Page with ssl doesn't open from safari In-Reply-To: <1c101b28c7fdc9674e7e5cf042694d69.NginxMailingListRussian@forum.nginx.org> References: <271b33307af39e93761cfd32fd6f5fd5.NginxMailingListRussian@forum.nginx.org> <1c101b28c7fdc9674e7e5cf042694d69.NginxMailingListRussian@forum.nginx.org> Message-ID: похоже это баг http://trac.nginx.org/nginx/ticket/235 у меня в версии 1.4.5 воспроизводится. посмотрель tail -f /var/log/nginx/errors.log | grep signal выяснил, что при запросе на https из сафари 2015/06/18 23:07:06 [alert] 1487#0: worker process 1493 exited on signal 11 2015/06/18 23:07:07 [alert] 1487#0: worker process 1514 exited on signal 11 2015/06/18 23:07:07 [alert] 1487#0: worker process 1491 exited on signal 11 Попробуйте выставить ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; и убрать default_server мне помогло. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259638,259744#msg-259744 From simplebox66 at gmail.com Fri Jun 19 10:12:52 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 19 Jun 2015 13:12:52 +0300 Subject: =?UTF-8?B?0L/RgNC+0LHQu9C10LzQsCDRgSByZXdyaXRl?= Message-ID: Добрый день! Есть вот такой локейшн -------------- next part -------------- An HTML attachment was scrubbed... URL: From simplebox66 at gmail.com Fri Jun 19 10:17:46 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 19 Jun 2015 13:17:46 +0300 Subject: =?UTF-8?B?0L/RgNC+0LHQu9C10LzQsCDRgSByZXdyaXRl?= Message-ID: ДОбрый день! Есть вот такой локейшн location @delete_handler { internal; open_file_cache off; if (-d $webdav_root/$uri) { # Add trailing slash to dirs. rewrite ^(.*[^/])$ $1/; } root $webdav_root; dav_methods DELETE; } По смыслу if должен дописывать слеш в конец запроса. Логи: 2015/07/20 13:14:52 [notice] 12620#0: *10967 "^(.*[^/])$" matches "/Family/test", client: 192.168.200.94, server: 192.168.200.92, request: "DELETE /Family/test HTTP/1.1", host: "192.168.200.92" 2015/07/20 13:14:52 [notice] 12620#0: *10967 rewritten data: "/Family/test/", args: "", client: 192.168.200.94, server: 192.168.200.92, request: "DELETE /Family/test HTTP/1.1", host: "192.168.200.92" ==> /var/log/nginx/webdav2_access.log <== 192.168.200.92 192.168.200.94 - [20/Jul/2015:13:14:52 +0300] "DELETE /Family/test HTTP/1.1" 598 "-" 0 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" "-" 0.000 "-" NGINX-CACHE-- "-" ==> /var/log/nginx/error.log <== 2015/07/20 13:14:52 [info] 12620#0: *10967 client 192.168.200.94 closed keepalive connection Соответственно в еррор логе видно что произошло совпадение ^(.*[^/])$" matches "/Family/test" и поэтому имел место рерайт rewritten data: "/Family/test/", но почему в access логах "DELETE /Family/test HTTP/1.1" слеш в конец не добавился? как решить проблему добавления слеша в конец? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Mon Jun 22 12:25:33 2015 From: nginx-forum at nginx.us (BieZax) Date: Mon, 22 Jun 2015 08:25:33 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: <2397902.sf7c0zERSv@vbart-workstation> References: <2397902.sf7c0zERSv@vbart-workstation> Message-ID: Валентин Бартенев Wrote: ------------------------------------------------------- > On Thursday 18 June 2015 12:05:45 BieZax wrote: > > Валентин Бартенев Wrote: > > ------------------------------------------------------- > > > On Thursday 18 June 2015 05:35:25 BieZax wrote: > > > > Валентин Бартенев Wrote: > > > > ------------------------------------------------------- > > > > > On Wednesday 17 June 2015 10:59:59 BieZax wrote: > > > > > > Поэксперементировал еще немного, но пока не получается > > > понять, > > > > > где > > > > > > затык. Конфиг nginx: > > > > > [..] > > > > > > > > > > > > Сократил размер файла до 1 Кб > > > > > > LA ~5 при 16 ядрах > > > > > > IO в порядке, загрузка сети около 130 мегабит/c > > > > > > > > > > > > > > > > А на клиенте? Упираться вполне может клиент, таким образом вы > > > будете > > > > > тестировать > > > > > не производительность nginx, а производительность клиента. > > > > > > > > > > -- > > > > > Валентин Бартенев > > > > > _______________________________________________ > > > > > nginx-ru mailing list > > > > > nginx-ru at nginx.org > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > Без внутреннего перенаправления пролетает 30000rps, с > > > перенаправлением > > > > ~13 тыс. Логично предположить ,что клиент тут не при > делах. > > > Из > > > > интересного: кол-во подключений всегда около 30к, может > во > > > > фряхе(9.3) какой-то лимит по соединениям, о котором я не знаю? > На > > > линуксе > > > > проблема не повторяется. > > > > > > > > > > Из этого нельзя такого предположить. Это может просто говорить о > том, > > > что > > > клиент находится в зависимости от задержек при обработке ответов и > не > > > пытается > > > нагружать сервер максимальным количеством запросов. > > > > > > Так, для сравнения, у меня только 4 ядра и далеко не серверных, на > 1кб > > > файле: > > > > > > Running 5m test @ http://127.0.0.1:8888/1k.html > > > 4 threads and 10000 connections > > > Thread Stats Avg Stdev Max +/- Stdev > > > Latency 782.79ms 1.07s 4.95s 81.36% > > > Req/Sec 86.61k 19.39k 223.51k 80.68% > > > 103239033 requests in 5.00m, 121.34GB read > > > Requests/sec: 344017.77 > > > Transfer/sec: 414.02MB > > > > > > Как видите, с вашими 30000rps на 16 ядрах едва ли вы можете > упираться > > > в nginx. > > > > > > Это либо сеть, либо клиент, либо что-то еще в системе. > > > > > > -- > > > Валентин Бартенев > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > То, что нжинкс не причем, это понятно, т.к. на линуксе с тем же > > конфигом все замечательно работает. > > Потестил еще wrk, вот результат :( > > > > Без перенаправления > > Running 5m test @ http://192.168.1.1/index.html > > 16 threads and 30000 connections > > Thread Stats Avg Stdev Max +/- Stdev > > Latency 739.14ms 334.20ms 2.00s 81.32% > > Req/Sec 1.79k 365.07 16.54k 79.40% > > 8476672 requests in 5.00m, 16.70GB read > > Socket errors: connect 1771, read 2975, write 636, timeout 423212 > > Requests/sec: 28246.05 > > Transfer/sec: 56.98MB > > > > С перенаправлением: > > Running 5m test @ http://192.168.1.1/index.html > > 16 threads and 30000 connections > > Thread Stats Avg Stdev Max +/- Stdev > > Latency 146.66ms 238.77ms 2.00s 90.72% > > Req/Sec 598.93 169.07 3.39k 71.40% > > 2845012 requests in 5.00m, 3.39GB read > > Socket errors: connect 1197, read 1546, write 6297, timeout > 1435215 > > Non-2xx or 3xx responses: 2845012 > > Requests/sec: 9480.29 > > Transfer/sec: 11.56MB > > > > > Обратите внимание на количество ошибок, о которых сообщает wrk в ваших > результатах. > > Явно что-то не так с настройками. А во втором случае еще и "Non-2xx > or 3xx responses". > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Потестировал с линукса на фрю и с фри на линукс (железо идентичное), с еренаправлением внутри: Фря-линукс : wrk -d 1m -t 16 -c 30000 http://192.168.1.2/index.html Running 1m test @ http://192.168.1.2/index.html 16 threads and 30000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 310.94ms 416.12ms 2.00s 84.95% Req/Sec 1.80k 1.12k 10.38k 67.54% 1713774 requests in 1.00m, 2.07GB read Socket errors: connect 0, read 755, write 30669, timeout 191934 Non-2xx or 3xx responses: 37920 Requests/sec: 28519.58 Transfer/sec: 35.28MB При этом нагрузка на сервер весьма ощутимая по процу. с линукса на фрю: ./wrk -d 1m -t 16 -c 30000 http://192.168.1.1/index.html Running 1m test @ http://192.168.1.1/index.html 16 threads and 30000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 167.12ms 314.70ms 2.00s 88.50% Req/Sec 1.18k 517.39 11.84k 81.42% 1097293 requests in 1.00m, 2.10GB read Socket errors: connect 1188, read 5508, write 3308, timeout 338681 Non-2xx or 3xx responses: 103609 Requests/sec: 18257.50 Transfer/sec: 35.74MB Затык не понятно где. Non-2xx or 3xx responses: 103609 - bad gw при запрросе через 127.0.0.1. Бэклог пустой. Есть идеи почему фря так сильно проигрывает при прочих равных ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259544,259785#msg-259785 From vbart at nginx.com Mon Jun 22 12:53:43 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 22 Jun 2015 15:53:43 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: References: <2397902.sf7c0zERSv@vbart-workstation> Message-ID: <30534274.WAGjBHbr2W@vbart-workstation> On Monday 22 June 2015 08:25:33 BieZax wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > On Thursday 18 June 2015 12:05:45 BieZax wrote: > > > Валентин Бартенев Wrote: > > > ------------------------------------------------------- > > > > On Thursday 18 June 2015 05:35:25 BieZax wrote: > > > > > Валентин Бартенев Wrote: > > > > > ------------------------------------------------------- > > > > > > On Wednesday 17 June 2015 10:59:59 BieZax wrote: > > > > > > > Поэксперементировал еще немного, но пока не получается понять, > > > > > > > где затык. Конфиг nginx: > > > > > > [..] > > > > > > > > > > > > > > Сократил размер файла до 1 Кб > > > > > > > LA ~5 при 16 ядрах > > > > > > > IO в порядке, загрузка сети около 130 мегабит/c > > > > > > > > > > > > > > > > > > > А на клиенте? Упираться вполне может клиент, таким образом вы будете > > > > > > тестировать не производительность nginx, а производительность клиента. > > > > > > > > > > > > -- > > > > > > Валентин Бартенев > > > > > > _______________________________________________ > > > > > > nginx-ru mailing list > > > > > > nginx-ru at nginx.org > > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > Без внутреннего перенаправления пролетает 30000rps, с перенаправлением > > > > > ~13 тыс. Логично предположить ,что клиент тут не при делах. > > > > > Из интересного: кол-во подключений всегда около 30к, может во > > > > > фряхе(9.3) какой-то лимит по соединениям, о котором я не знаю? На линуксе > > > > > проблема не повторяется. > > > > > > > > > > > > > Из этого нельзя такого предположить. Это может просто говорить отом, > > > > что клиент находится в зависимости от задержек при обработке ответов и не > > > > пытается нагружать сервер максимальным количеством запросов. > > > > > > > > Так, для сравнения, у меня только 4 ядра и далеко не серверных, на 1кб > > > > файле: > > > > > > > > Running 5m test @ http://127.0.0.1:8888/1k.html > > > > 4 threads and 10000 connections > > > > Thread Stats Avg Stdev Max +/- Stdev > > > > Latency 782.79ms 1.07s 4.95s 81.36% > > > > Req/Sec 86.61k 19.39k 223.51k 80.68% > > > > 103239033 requests in 5.00m, 121.34GB read > > > > Requests/sec: 344017.77 > > > > Transfer/sec: 414.02MB > > > > > > > > Как видите, с вашими 30000rps на 16 ядрах едва ли вы можете упираться > > > > в nginx. > > > > > > > > Это либо сеть, либо клиент, либо что-то еще в системе. > > > > > > > > -- > > > > Валентин Бартенев > > > > _______________________________________________ > > > > nginx-ru mailing list > > > > nginx-ru at nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > То, что нжинкс не причем, это понятно, т.к. на линуксе с тем же > > > конфигом все замечательно работает. > > > Потестил еще wrk, вот результат :( > > > > > > Без перенаправления > > > Running 5m test @ http://192.168.1.1/index.html > > > 16 threads and 30000 connections > > > Thread Stats Avg Stdev Max +/- Stdev > > > Latency 739.14ms 334.20ms 2.00s 81.32% > > > Req/Sec 1.79k 365.07 16.54k 79.40% > > > 8476672 requests in 5.00m, 16.70GB read > > > Socket errors: connect 1771, read 2975, write 636, timeout 423212 > > > Requests/sec: 28246.05 > > > Transfer/sec: 56.98MB > > > > > > С перенаправлением: > > > Running 5m test @ http://192.168.1.1/index.html > > > 16 threads and 30000 connections > > > Thread Stats Avg Stdev Max +/- Stdev > > > Latency 146.66ms 238.77ms 2.00s 90.72% > > > Req/Sec 598.93 169.07 3.39k 71.40% > > > 2845012 requests in 5.00m, 3.39GB read > > > Socket errors: connect 1197, read 1546, write 6297, timeout 1435215 > > > Non-2xx or 3xx responses: 2845012 > > > Requests/sec: 9480.29 > > > Transfer/sec: 11.56MB > > > > > > > > > Обратите внимание на количество ошибок, о которых сообщает wrk в ваших > > результатах. > > > > Явно что-то не так с настройками. А во втором случае еще и "Non-2xx > > or 3xx responses". > > > > -- > > Валентин Бартенев > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Потестировал с линукса на фрю и с фри на линукс (железо идентичное), > с еренаправлением внутри: > > Фря-линукс : > wrk -d 1m -t 16 -c 30000 http://192.168.1.2/index.html > Running 1m test @ http://192.168.1.2/index.html > 16 threads and 30000 connections > Thread Stats Avg Stdev Max +/- Stdev > Latency 310.94ms 416.12ms 2.00s 84.95% > Req/Sec 1.80k 1.12k 10.38k 67.54% > 1713774 requests in 1.00m, 2.07GB read > Socket errors: connect 0, read 755, write 30669, timeout 191934 > Non-2xx or 3xx responses: 37920 > Requests/sec: 28519.58 > Transfer/sec: 35.28MB > При этом нагрузка на сервер весьма ощутимая по процу. > > с линукса на фрю: > ./wrk -d 1m -t 16 -c 30000 http://192.168.1.1/index.html > Running 1m test @ http://192.168.1.1/index.html > 16 threads and 30000 connections > Thread Stats Avg Stdev Max +/- Stdev > Latency 167.12ms 314.70ms 2.00s 88.50% > Req/Sec 1.18k 517.39 11.84k 81.42% > 1097293 requests in 1.00m, 2.10GB read > Socket errors: connect 1188, read 5508, write 3308, timeout 338681 > Non-2xx or 3xx responses: 103609 > Requests/sec: 18257.50 > Transfer/sec: 35.74MB > Затык не понятно где. > > Non-2xx or 3xx responses: 103609 - bad gw при запрросе через > 127.0.0.1. > Бэклог пустой. > > > Есть идеи почему фря так сильно проигрывает при прочих равных ? > Пока не донастраиваете обе системы до того, чтобы не было ошибок - нельзя утверждать, что что-то чему-то проигрывает. У вас еще размеры ответов похоже разные. В первом случае: 1713774 requests in 1.00m, 2.07GB read Во втором: 1097293 requests in 1.00m, 2.10GB read Как так получилось, что запросов в полтора раза меньше, а прочитано было даже больше? Transfer/sec примерно одинаковый. -- Валентин Бартенев From nginx-forum at nginx.us Mon Jun 22 16:25:18 2015 From: nginx-forum at nginx.us (neomaq) Date: Mon, 22 Jun 2015 12:25:18 -0400 Subject: =?UTF-8?B?0L7RiNC40LHQvtGH0L3Ri9C5IHJlZGlyZWN0INC90LAgZGVmYXVsdCBzZXJ2ZXIg?= =?UTF-8?B?bmFtZSDQv9GA0Lgg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC4INC9?= =?UTF-8?B?0LAgaHR0cHM=?= Message-ID: Здравствуйте, прошу помощи: имеется следующая конфигурация server { listen 80; server_name example.com www.example.com pda.example.com wap.example.com; return 301 https://$server_name$request_uri; } наблюдается проблема, при редиректе на https nginx использует первое дефаулт имя, указанное в server_name вместо имени, которое прислал клиент в url т.е. при входе на pda.example.com:80 он перенаправляется на https://example.com а должен на https://pda.example.com что я делаю не так? как исправить? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259788,259788#msg-259788 From spuzirev at gmail.com Mon Jun 22 16:29:23 2015 From: spuzirev at gmail.com (=?UTF-8?B?0KHQtdGA0LPQtdC5INCf0YPQt9GL0YDRkdCy?=) Date: Mon, 22 Jun 2015 19:29:23 +0300 Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0L7Rh9C90YvQuSByZWRpcmVjdCDQvdCwIGRlZmF1bHQgc2Vy?= =?UTF-8?B?dmVyIG5hbWUg0L/RgNC4INC/0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90Lg=?= =?UTF-8?B?0Lgg0L3QsCBodHRwcw==?= In-Reply-To: References: Message-ID: Используйте переменную $host. цитата из документации: $host в порядке приоритета: имя хоста из строки запроса, или имя хоста из поля ?Host? заголовка запроса, или имя сервера, соответствующего запросу server { listen 80; server_name example.com www.example.com pda.example.com wap.example.com; return 301 https://$host$request_uri; } 22 июня 2015 г., 19:25 пользователь neomaq написал: > Здравствуйте, > > > прошу помощи: > > имеется следующая конфигурация > > server { > listen 80; > server_name example.com www.example.com pda.example.com > wap.example.com; > return 301 https://$server_name$request_uri; > } > > > наблюдается проблема, при редиректе на https nginx использует первое > дефаулт имя, указанное в server_name > вместо имени, которое прислал клиент в url > > т.е. при входе на pda.example.com:80 > он перенаправляется на https://example.com а должен на > https://pda.example.com > > что я делаю не так? как исправить? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,259788,259788#msg-259788 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Сергей Пузырёв тел.: +7-916-980-70-45 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-ru at sadok.spb.ru Mon Jun 22 16:51:42 2015 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Mon, 22 Jun 2015 19:51:42 +0300 Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0L7Rh9C90YvQuSByZWRpcmVjdCDQvdCwIGRlZmF1bHQgc2Vy?= =?UTF-8?B?dmVyIG5hbWUg0L/RgNC4INC/0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90Lg=?= =?UTF-8?B?0Lgg0L3QsCBodHRwcw==?= In-Reply-To: References: Message-ID: <1686654085.20150622195142@sadok.spb.ru> Здравствуйте, neomaq. Вы писали 22 июня 2015 г., 19:25:18: > что я делаю не так? как исправить? location / { rewrite ^ https://$host$request_uri permanent; } -- С уважением, Dmitry nginx-ru at sadok.spb.ru From nginx-forum at nginx.us Mon Jun 22 17:05:25 2015 From: nginx-forum at nginx.us (neomaq) Date: Mon, 22 Jun 2015 13:05:25 -0400 Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0L7Rh9C90YvQuSByZWRpcmVjdCDQvdCwIGRlZmF1bHQgc2Vy?= =?UTF-8?B?dmVyIG5hbWUg0L/RgNC4INC/0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90Lg=?= =?UTF-8?B?0Lgg0L3QsCBodHRwcw==?= In-Reply-To: References: Message-ID: спасибо! помогло Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259789,259791#msg-259791 From simplebox66 at gmail.com Tue Jun 23 10:05:52 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Tue, 23 Jun 2015 13:05:52 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: References: Message-ID: Может это фича nginx ? 2015-06-19 13:17 GMT+03:00 Иван Мишин : > ДОбрый день! > > Есть вот такой локейшн > location @delete_handler { > internal; > > open_file_cache off; > if (-d $webdav_root/$uri) { # Add trailing slash to dirs. > rewrite ^(.*[^/])$ $1/; > } > root $webdav_root; > dav_methods DELETE; > } > > По смыслу if должен дописывать слеш в конец запроса. > > Логи: > 2015/07/20 13:14:52 [notice] 12620#0: *10967 "^(.*[^/])$" matches > "/Family/test", client: 192.168.200.94, server: 192.168.200.92, request: > "DELETE /Family/test HTTP/1.1", host: "192.168.200.92" > 2015/07/20 13:14:52 [notice] 12620#0: *10967 rewritten data: > "/Family/test/", args: "", client: 192.168.200.94, server: 192.168.200.92, > request: "DELETE /Family/test HTTP/1.1", host: "192.168.200.92" > > ==> /var/log/nginx/webdav2_access.log <== > 192.168.200.92 192.168.200.94 - [20/Jul/2015:13:14:52 +0300] "DELETE > /Family/test HTTP/1.1" 598 "-" 0 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) > libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 > libssh2/1.4.2" "-" 0.000 "-" NGINX-CACHE-- "-" > > ==> /var/log/nginx/error.log <== > 2015/07/20 13:14:52 [info] 12620#0: *10967 client 192.168.200.94 closed > keepalive connection > > > Соответственно в еррор логе видно что произошло совпадение ^(.*[^/])$" > matches "/Family/test" и поэтому имел место рерайт rewritten data: > "/Family/test/", но почему в access логах "DELETE /Family/test HTTP/1.1" > слеш в конец не добавился? > как решить проблему добавления слеша в конец? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Jun 23 12:29:13 2015 From: nginx-forum at nginx.us (S.A.N) Date: Tue, 23 Jun 2015 08:29:13 -0400 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: References: Message-ID: > как решить проблему добавления слеша в конец? Офтоп - никогда не понимал, зачем бороться со слешами в конце uri, их можно использовать на бекенде в алгоритмах роутинга. Например в наших роутингах слеш в конце означает что uri адресуется к множеству сущностней (аля папка), отсутствия слеша в конце означает что в uri должен быть id который адресуется только к одной сущности, это очень удобно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259754,259803#msg-259803 From nginx-forum at nginx.us Tue Jun 23 13:05:23 2015 From: nginx-forum at nginx.us (BieZax) Date: Tue, 23 Jun 2015 09:05:23 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: <30534274.WAGjBHbr2W@vbart-workstation> References: <30534274.WAGjBHbr2W@vbart-workstation> Message-ID: <1bc7b4aa8f93f02744761e936f30c5aa.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Monday 22 June 2015 08:25:33 BieZax wrote: > > Валентин Бартенев Wrote: > > ------------------------------------------------------- > > > On Thursday 18 June 2015 12:05:45 BieZax wrote: > > > > Валентин Бартенев Wrote: > > > > ------------------------------------------------------- > > > > > On Thursday 18 June 2015 05:35:25 BieZax wrote: > > > > > > Валентин Бартенев Wrote: > > > > > > ------------------------------------------------------- > > > > > > > On Wednesday 17 June 2015 10:59:59 BieZax wrote: > > > > > > > > Поэксперементировал еще немного, но пока не > получается понять, > > > > > > > > где затык. Конфиг nginx: > > > > > > > [..] > > > > > > > > > > > > > > > > Сократил размер файла до 1 Кб > > > > > > > > LA ~5 при 16 ядрах > > > > > > > > IO в порядке, загрузка сети около 130 мегабит/c > > > > > > > > > > > > > > > > > > > > > > А на клиенте? Упираться вполне может клиент, таким > образом вы будете > > > > > > > тестировать не производительность nginx, а > производительность клиента. > > > > > > > > > > > > > > -- > > > > > > > Валентин Бартенев > > > > > > > _______________________________________________ > > > > > > > nginx-ru mailing list > > > > > > > nginx-ru at nginx.org > > > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > > > > > Без внутреннего перенаправления пролетает 30000rps, с > перенаправлением > > > > > > ~13 тыс. Логично предположить ,что клиент тут не при > делах. > > > > > > Из интересного: кол-во подключений всегда около 30к, > может во > > > > > > фряхе(9.3) какой-то лимит по соединениям, о котором я не > знаю? На линуксе > > > > > > проблема не повторяется. > > > > > > > > > > > > > > > > Из этого нельзя такого предположить. Это может просто > говорить отом, > > > > > что клиент находится в зависимости от задержек при обработке > ответов и не > > > > > пытается нагружать сервер максимальным количеством запросов. > > > > > > > > > > Так, для сравнения, у меня только 4 ядра и далеко не > серверных, на 1кб > > > > > файле: > > > > > > > > > > Running 5m test @ http://127.0.0.1:8888/1k.html > > > > > 4 threads and 10000 connections > > > > > Thread Stats Avg Stdev Max +/- Stdev > > > > > Latency 782.79ms 1.07s 4.95s 81.36% > > > > > Req/Sec 86.61k 19.39k 223.51k 80.68% > > > > > 103239033 requests in 5.00m, 121.34GB read > > > > > Requests/sec: 344017.77 > > > > > Transfer/sec: 414.02MB > > > > > > > > > > Как видите, с вашими 30000rps на 16 ядрах едва ли вы можете > упираться > > > > > в nginx. > > > > > > > > > > Это либо сеть, либо клиент, либо что-то еще в системе. > > > > > > > > > > -- > > > > > Валентин Бартенев > > > > > _______________________________________________ > > > > > nginx-ru mailing list > > > > > nginx-ru at nginx.org > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > То, что нжинкс не причем, это понятно, т.к. на линуксе с тем > же > > > > конфигом все замечательно работает. > > > > Потестил еще wrk, вот результат :( > > > > > > > > Без перенаправления > > > > Running 5m test @ http://192.168.1.1/index.html > > > > 16 threads and 30000 connections > > > > Thread Stats Avg Stdev Max +/- Stdev > > > > Latency 739.14ms 334.20ms 2.00s 81.32% > > > > Req/Sec 1.79k 365.07 16.54k 79.40% > > > > 8476672 requests in 5.00m, 16.70GB read > > > > Socket errors: connect 1771, read 2975, write 636, timeout > 423212 > > > > Requests/sec: 28246.05 > > > > Transfer/sec: 56.98MB > > > > > > > > С перенаправлением: > > > > Running 5m test @ http://192.168.1.1/index.html > > > > 16 threads and 30000 connections > > > > Thread Stats Avg Stdev Max +/- Stdev > > > > Latency 146.66ms 238.77ms 2.00s 90.72% > > > > Req/Sec 598.93 169.07 3.39k 71.40% > > > > 2845012 requests in 5.00m, 3.39GB read > > > > Socket errors: connect 1197, read 1546, write 6297, timeout > 1435215 > > > > Non-2xx or 3xx responses: 2845012 > > > > Requests/sec: 9480.29 > > > > Transfer/sec: 11.56MB > > > > > > > > > > > > > Обратите внимание на количество ошибок, о которых сообщает wrk в > ваших > > > результатах. > > > > > > Явно что-то не так с настройками. А во втором случае еще и > "Non-2xx > > > or 3xx responses". > > > > > > -- > > > Валентин Бартенев > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru at nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > Потестировал с линукса на фрю и с фри на линукс (железо > идентичное), > > с еренаправлением внутри: > > > > Фря-линукс : > > wrk -d 1m -t 16 -c 30000 http://192.168.1.2/index.html > > Running 1m test @ http://192.168.1.2/index.html > > 16 threads and 30000 connections > > Thread Stats Avg Stdev Max +/- Stdev > > Latency 310.94ms 416.12ms 2.00s 84.95% > > Req/Sec 1.80k 1.12k 10.38k 67.54% > > 1713774 requests in 1.00m, 2.07GB read > > Socket errors: connect 0, read 755, write 30669, timeout 191934 > > Non-2xx or 3xx responses: 37920 > > Requests/sec: 28519.58 > > Transfer/sec: 35.28MB > > При этом нагрузка на сервер весьма ощутимая по процу. > > > > с линукса на фрю: > > ./wrk -d 1m -t 16 -c 30000 http://192.168.1.1/index.html > > Running 1m test @ http://192.168.1.1/index.html > > 16 threads and 30000 connections > > Thread Stats Avg Stdev Max +/- Stdev > > Latency 167.12ms 314.70ms 2.00s 88.50% > > Req/Sec 1.18k 517.39 11.84k 81.42% > > 1097293 requests in 1.00m, 2.10GB read > > Socket errors: connect 1188, read 5508, write 3308, timeout 338681 > > Non-2xx or 3xx responses: 103609 > > Requests/sec: 18257.50 > > Transfer/sec: 35.74MB > > Затык не понятно где. > > > > Non-2xx or 3xx responses: 103609 - bad gw при запрросе через > > 127.0.0.1. > > Бэклог пустой. > > > > > > Есть идеи почему фря так сильно проигрывает при прочих равных ? > > > > Пока не донастраиваете обе системы до того, чтобы не было ошибок - > нельзя > утверждать, что что-то чему-то проигрывает. > > У вас еще размеры ответов похоже разные. В первом случае: > 1713774 requests in 1.00m, 2.07GB read > > Во втором: > 1097293 requests in 1.00m, 2.10GB read > > Как так получилось, что запросов в полтора раза меньше, а прочитано > было > даже больше? > > Transfer/sec примерно одинаковый. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru После того, как кол-во ответов перестает упираться в сеть, то обьем забираемого файла практически не влияет на результат, но я на обоих машинах сделал одинаковый. Вот новые тесты, уменьшил кол-во запросов, что практически избавило от ошибок Линукс-фря 3000 соединений на поток: Running 1m test @ http://192.168.1.1/index.html 16 threads and 3000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 111.67ms 137.60ms 1.22s 65.17% Req/Sec 0.93k 437.05 2.86k 65.48% 883290 requests in 1.00m, 1.24GB read Socket errors: connect 0, read 0, write 0, timeout 24550 Non-2xx or 3xx responses: 1303 Requests/sec: 14710.81 Transfer/sec: 21.20MB Линукс-фря 1500 на поток: Running 1m test @ http://192.168.1.1/index.html 16 threads and 1500 connections Thread Stats Avg Stdev Max +/- Stdev Latency 16.88ms 45.15ms 1.22s 94.82% Req/Sec 1.17k 352.80 3.07k 69.14% 1115425 requests in 1.00m, 1.57GB read Socket errors: connect 0, read 0, write 0, timeout 23235 Non-2xx or 3xx responses: 522 Requests/sec: 18580.66 Transfer/sec: 26.80MB Фря-линукс 4000 соеднений на поток: Running 1m test @ http://192.168.1.2/index.html 16 threads and 4000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 202.53ms 308.46ms 1.86s 81.94% Req/Sec 3.08k 721.48 10.06k 84.02% 2938683 requests in 1.00m, 3.61GB read Socket errors: connect 0, read 0, write 1145, timeout 10874 Non-2xx or 3xx responses: 119 Requests/sec: 48927.38 Transfer/sec: 61.53MB фря-линукс 3000 соединений на поток: Running 1m test @ http://192.168.1.2/index.html 16 threads and 3000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 208.17ms 314.20ms 1.85s 81.23% Req/Sec 3.11k 798.86 11.95k 88.11% 2967047 requests in 1.00m, 3.64GB read Socket errors: connect 0, read 0, write 596, timeout 6941 Non-2xx or 3xx responses: 5 Requests/sec: 49402.03 Transfer/sec: 62.13MB Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259544,259805#msg-259805 From vbart at nginx.com Tue Jun 23 13:37:05 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 23 Jun 2015 16:37:05 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: <1bc7b4aa8f93f02744761e936f30c5aa.NginxMailingListRussian@forum.nginx.org> References: <30534274.WAGjBHbr2W@vbart-workstation> <1bc7b4aa8f93f02744761e936f30c5aa.NginxMailingListRussian@forum.nginx.org> Message-ID: <1689165.Dxy8lY3gXI@vbart-workstation> On Tuesday 23 June 2015 09:05:23 BieZax wrote: [..] > После того, как кол-во ответов перестает упираться в сеть, то обьем > забираемого файла практически не влияет на результат, но я на обоих > машинах сделал одинаковый. > Вот новые тесты, уменьшил кол-во запросов, что практически избавило от > ошибок [..] Ошибок по прежнему очень много. Их быть не должно вообще, а max latency по несколько секунд говорят о том, что у вас соединения подолгу висят не по'accept'ченые, по видимому исчерпав лимиты. Какие значения на linux у: net.core.somaxconn net.core.netdev_max_backlog net.ipv4.tcp_max_syn_backlog net.ipv4.ip_local_port_range net.ipv4.tcp_fin_timeout net.ipv4.tcp_tw_reuse ? -- Валентин Бартенев From nginx-forum at nginx.us Tue Jun 23 15:33:12 2015 From: nginx-forum at nginx.us (BieZax) Date: Tue, 23 Jun 2015 11:33:12 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM?= =?UTF-8?B?0L3QvtGB0YLQuC4=?= In-Reply-To: <1689165.Dxy8lY3gXI@vbart-workstation> References: <1689165.Dxy8lY3gXI@vbart-workstation> Message-ID: <5b675f5fe8b52b8464240877319e7766.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Tuesday 23 June 2015 09:05:23 BieZax wrote: > [..] > > После того, как кол-во ответов перестает упираться в сеть, то > обьем > > забираемого файла практически не влияет на результат, но я на > обоих > > машинах сделал одинаковый. > > Вот новые тесты, уменьшил кол-во запросов, что практически > избавило от > > ошибок > [..] > > Ошибок по прежнему очень много. Их быть не должно вообще, а max > latency > по несколько секунд говорят о том, что у вас соединения подолгу висят > не > по'accept'ченые, по видимому исчерпав лимиты. > > Какие значения на linux у: > > net.core.somaxconn > net.core.netdev_max_backlog > net.ipv4.tcp_max_syn_backlog > net.ipv4.ip_local_port_range > net.ipv4.tcp_fin_timeout > net.ipv4.tcp_tw_reuse > > > ? > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru net.core.somaxconn = 128 net.core.netdev_max_backlog = 1000 net.ipv4.tcp_max_syn_backlog = 131072 net.ipv4.ip_local_port_range = 32768 61000 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_tw_reuse = 0 Но к линуксу у меня претензий нет, я его почти не тюнил: все, что в sysctl net.ipv4.tcp_max_tw_buckets = 65536 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 0 net.ipv4.tcp_max_syn_backlog = 131072 net.ipv4.tcp_syn_retries = 3 net.ipv4.tcp_synack_retries = 3 net.ipv4.tcp_retries1 = 3 net.ipv4.tcp_retries2 = 8 net.ipv4.tcp_rmem = 16384 174760 349520 net.ipv4.tcp_wmem = 16384 131072 262144 net.ipv4.tcp_mem = 262144 524288 1048576 net.ipv4.tcp_max_orphans = 65536 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_low_latency = 1 net.ipv4.tcp_syncookies = 0 Вопрос про про фряху, что с ней может быть не так? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259544,259813#msg-259813 From paranoidchaos at gmail.com Tue Jun 23 16:56:30 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Tue, 23 Jun 2015 21:56:30 +0500 Subject: =?UTF-8?B?0J3QsNGB0LvQtdC00L7QstCw0L3QuNC1IGZhc3RjZ2lfcGFyYW0=?= Message-ID: Здравствуйте. # uname -a FreeBSD test 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # nginx -v nginx version: nginx/1.8.0 # php -v 5.6.10 Имеется такая тестовая конфигураци. server { .... .... root /www; index index.html index.php; include fastcgi_params; fastcgi_index index.php; location /info { fastcgi_param SCRIPT_FILENAME /www/info.php; fastcgi_pass 127.0.0.1:9000; } ..... ...... } Проблема в том, что в локейшене /info не наследуются fastcgi_param (все), указанный в контексте server, если происходит переопределение одного fastcgi_param параметра внутри локейшена. PHP-FPM возвращает код статуса 200 и пустой ответ. Экспериментальным путём выяснил, что минимальные необходимые параметры передаваемые PHP-FPM следующие: location /info { fastcgi_param REQUEST_METHOD $request_method; fastcgi_param SCRIPT_FILENAME /www/info.php; fastcgi_pass 127.0.0.1:9000; } В этом случае PHP-FPM обрабатывает скрипт /www/info.php, но nginx не передал все остальные fastcgi_param из файла fastcgi_params, которые должны были быть унаследованы. В документации описан момент """ Директивы наследуются с предыдущего уровня при условии, что на данном уровне не описаны свои директивы fastcgi_param. """ выходит если я переопределяю (устанавливаю) какой-либо fastcgi_param параметр, то наследования fastcgi_params вовсе отменяется? Для чего тогда это наследование? Почему нельзя наследовать с верхнего уровня и иметь возможность переопределить какой-либо параметр? Спасибо. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Jun 23 17:19:46 2015 From: nginx-forum at nginx.us (AterCattus) Date: Tue, 23 Jun 2015 13:19:46 -0400 Subject: =?UTF-8?B?0JLQvtC30LzQvtC20L3QvtGB0YLRjCDRgdC+0LHRgNCw0YLRjCDRgdC+0LLRgNC1?= =?UTF-8?B?0LzQtdC90L3Rg9GOINCy0LXRgNGB0LjRjiBuZ2lueCDQuCBvcGVuc3NsINGB?= =?UTF-8?B?INC/0L7QtNC00LXRgNC20LrQvtC5IHNzbCByZW5lZ290aWF0aW9u?= Message-ID: <523a1d5ef7599024696ed63b85916c46.NginxMailingListRussian@forum.nginx.org> Всем привет. Возникла необходимость взаимодействия с сервером, использующего ssl renegotiation. А в качестве промежуточного звена отлично подошел бы nginx с его proxy_pass и proxy_ssl_certificate* + proxy_ssl_trusted_certificate. Но соответствующий функционал убран еще в 0.8.23. Можно ли как-то достучаться до такого сервера из nginx? Правка event/ngx_event_openssl.c не помогает - nginx перестает ругаться на "SSL renegotiation disabled", но все-равно запрос не проходит. Да, я понимаю, что не просто так это было убрано, но внешний сервер работает только так. Вопрос безопасности оставляю вне данного вопроса. Запросы (с той же машины, где собирается и работает nginx) к этому серверу такого вида проходят успешно: openssl s_client -connect foohost:443 -CAfile mcert.crt -servername foohost -key my.key -cert my.crt Заранее спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259815,259815#msg-259815 From simplebox66 at gmail.com Wed Jun 24 08:16:47 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 24 Jun 2015 11:16:47 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: References: Message-ID: В моем случае бекенда нет. Nginx используется как вебдав сервер. Соответственно чтобы средствами винды можно было удалять или переименовывать папку на веб сервер должен падать запрос вида DELETE /Family/test/ HTTP/1.1, но проклятая винда шлет DELETE /Family/test HTTP/1.1 то есть без слеша на конце. Казалась бы простой кейс, дописать рерайтом в конец слеш и нет проблем. Но приведенная выше конструкция судя по access логам этого не делает, а так же сильно настараживает то что судя по error логам рерайт то срабатывает, вот только слеша в конце запроса так и не появляется. 23 июня 2015 г., 15:29 пользователь S.A.N написал: > > как решить проблему добавления слеша в конец? > > Офтоп - никогда не понимал, зачем бороться со слешами в конце uri, их можно > использовать на бекенде в алгоритмах роутинга. > Например в наших роутингах слеш в конце означает что uri адресуется к > множеству сущностней (аля папка), отсутствия слеша в конце означает что в > uri должен быть id который адресуется только к одной сущности, это очень > удобно. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,259754,259803#msg-259803 > > _______________________________________________ > 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 alstpostbox at gmail.com Wed Jun 24 08:49:48 2015 From: alstpostbox at gmail.com (Andrey Istochkin) Date: Wed, 24 Jun 2015 11:49:48 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: References: Message-ID: В access-логе при стандартном log_format фигурирует переменная $request (первоначальная строка запроса целиком). Чтобы увидеть uri запроса после прохождения rewrite-фазы, попробуйте в log_format добавить переменную $uri . 24 июня 2015 г., 11:16 пользователь Иван Мишин написал: > В моем случае бекенда нет. Nginx используется как вебдав сервер. > Соответственно чтобы средствами винды можно было удалять или > переименовывать папку на веб сервер должен падать запрос вида DELETE > /Family/test/ HTTP/1.1, но проклятая винда шлет DELETE /Family/test > HTTP/1.1 то есть без слеша на конце. Казалась бы простой кейс, дописать > рерайтом в конец слеш и нет проблем. Но приведенная выше конструкция судя > по access логам этого не делает, а так же сильно настараживает то что судя > по error логам рерайт то срабатывает, вот только слеша в конце запроса так > и не появляется. > > 23 июня 2015 г., 15:29 пользователь S.A.N написал: > > > как решить проблему добавления слеша в конец? >> >> Офтоп - никогда не понимал, зачем бороться со слешами в конце uri, их >> можно >> использовать на бекенде в алгоритмах роутинга. >> Например в наших роутингах слеш в конце означает что uri адресуется к >> множеству сущностней (аля папка), отсутствия слеша в конце означает что в >> uri должен быть id который адресуется только к одной сущности, это очень >> удобно. >> >> Posted at Nginx Forum: >> http://forum.nginx.org/read.php?21,259754,259803#msg-259803 >> >> _______________________________________________ >> 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 simplebox66 at gmail.com Wed Jun 24 09:32:07 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 24 Jun 2015 12:32:07 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: References: Message-ID: Андрей, спасибо. Теперь убедился что rewrite действительно происходит. А значит после выполнения if ( т.е. выполнения rewrite) должны вступить в действие остальные директивы из location @delete_handler. Вот только удаление каталога не происходит 24 июня 2015 г., 11:49 пользователь Andrey Istochkin написал: > В access-логе при стандартном log_format фигурирует переменная $request > (первоначальная > строка запроса целиком). Чтобы увидеть uri запроса после прохождения > rewrite-фазы, попробуйте в log_format добавить переменную $uri > . > > 24 июня 2015 г., 11:16 пользователь Иван Мишин > написал: > > В моем случае бекенда нет. Nginx используется как вебдав сервер. >> Соответственно чтобы средствами винды можно было удалять или >> переименовывать папку на веб сервер должен падать запрос вида DELETE >> /Family/test/ HTTP/1.1, но проклятая винда шлет DELETE /Family/test >> HTTP/1.1 то есть без слеша на конце. Казалась бы простой кейс, дописать >> рерайтом в конец слеш и нет проблем. Но приведенная выше конструкция судя >> по access логам этого не делает, а так же сильно настараживает то что судя >> по error логам рерайт то срабатывает, вот только слеша в конце запроса так >> и не появляется. >> >> 23 июня 2015 г., 15:29 пользователь S.A.N написал: >> >> > как решить проблему добавления слеша в конец? >>> >>> Офтоп - никогда не понимал, зачем бороться со слешами в конце uri, их >>> можно >>> использовать на бекенде в алгоритмах роутинга. >>> Например в наших роутингах слеш в конце означает что uri адресуется к >>> множеству сущностней (аля папка), отсутствия слеша в конце означает что в >>> uri должен быть id который адресуется только к одной сущности, это очень >>> удобно. >>> >>> Posted at Nginx Forum: >>> http://forum.nginx.org/read.php?21,259754,259803#msg-259803 >>> >>> _______________________________________________ >>> 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-ru at sadok.spb.ru Wed Jun 24 12:32:38 2015 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Wed, 24 Jun 2015 15:32:38 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: References: Message-ID: <347082536.20150624153238@sadok.spb.ru> Здравствуйте, Иван. Вы писали 24 июня 2015 г., 12:32:07: > Андрей, спасибо. Теперь убедился что rewrite действительно > происходит. А значит после выполнения if ( т.е. выполнения rewrite) > должны вступить в действие остальные директивы из location > @delete_handler. Вот только удаление каталога не происходит Снять уже наконец дамп с 2-х сторон и посмотреть о чем действительно разговаривают клиент с сервером? -- С уважением, Dmitry nginx-ru at sadok.spb.ru From simplebox66 at gmail.com Wed Jun 24 12:51:38 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 24 Jun 2015 15:51:38 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: <347082536.20150624153238@sadok.spb.ru> References: <347082536.20150624153238@sadok.spb.ru> Message-ID: > > Снять уже наконец дамп с 2-х сторон и посмотреть о чем действительно > разговаривают клиент с сервером? Дамп снимал. Ничего там интересного не увидел. На всякий случай прикрепляю результаты дампа к письму 24 июня 2015 г., 15:32 пользователь Dmitry Ivanov написал: > Здравствуйте, Иван. > > Вы писали 24 июня 2015 г., 12:32:07: > > > Андрей, спасибо. Теперь убедился что rewrite действительно > > происходит. А значит после выполнения if ( т.е. выполнения rewrite) > > должны вступить в действие остальные директивы из location > > @delete_handler. Вот только удаление каталога не происходит > > Снять уже наконец дамп с 2-х сторон и посмотреть о чем действительно > разговаривают клиент с сервером? > > -- > С уважением, > Dmitry nginx-ru at sadok.spb.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: -------------- next part -------------- tcpdump -A -nn -vv port 80 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 15:48:29.763986 IP (tos 0x0, ttl 64, id 43013, offset 0, flags [DF], proto TCP (6), length 234) 192.168.200.94.54669 > 192.168.200.92.80: Flags [P.], cksum 0xa7db (correct), seq 127457382:127457564, ack 2000031034, win 501, options [nop,nop,TS val 12642405 ecr 12528186], length 182 :..............^...\...P...fw6 ...e..*:PROPFIND /Family/ HTTP/1.1 User-Agent: davfs2/1.4.7 neon/0.29.3 Connection: TE TE: trailers Host: 192.168.200.92 Depth: 1 Content-Length: 286 Content-Type: application/xml 15:48:29.764021 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.94.54669: Flags [R], cksum 0x4386 (correct), seq 2000031034, win 0, length 0 :....P...C.....\...^.P..w6 15:48:29.764040 IP (tos 0x0, ttl 64, id 43014, offset 0, flags [DF], proto TCP (6), length 338) 192.168.200.94.54669 > 192.168.200.92.80: Flags [P.], cksum 0xe3ca (correct), seq 182:468, ack 1, win 501, options [nop,nop,TS val 12642405 ecr 12528186], length 286 :..............^...\...P....w6 ...e..*: 15:48:29.764046 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.94.54669: Flags [R], cksum 0x4386 (correct), seq 2000031034, win 0, length 0 :....P...C.....\...^.P..w6 15:48:29.764056 IP (tos 0x0, ttl 64, id 43015, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.94.54669 > 192.168.200.92.80: Flags [F.], cksum 0x127b (correct), seq 468, ack 1, win 501, options [nop,nop,TS val 12642405 ecr 12528186], length 0 :.....{........^...\...P...:w6 ...e..*: 15:48:29.764062 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.94.54669: Flags [R], cksum 0x4386 (correct), seq 2000031034, win 0, length 0 :....P...C.....\...^.P..w6 15:48:29.764075 IP (tos 0x0, ttl 64, id 4056, offset 0, flags [DF], proto TCP (6), length 60) 192.168.200.94.54670 > 192.168.200.92.80: Flags [S], cksum 0xdf1f (correct), seq 1997137853, win 14600, options [mss 1460,sackOK,TS val 12642405 ecr 0,nop,wscale 7], length 0 E..<.. at .@......^...\...Pw ........9............ ...e........ 15:48:29.764108 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.200.92.80 > 192.168.200.94.54670: Flags [S.], cksum 0x48f0 (correct), seq 3361946056, ack 1997137854, win 14480, options [mss 1460,sackOK,TS val 12620714 ecr 12642405,nop,wscale 7], length 0 E..<.. at .@.(....\...^.P...c9.w ....8.H.......... .......e.... 15:48:29.764159 IP (tos 0x0, ttl 64, id 4057, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.94.54670 > 192.168.200.92.80: Flags [.], cksum 0xafd9 (correct), seq 1, ack 1, win 115, options [nop,nop,TS val 12642405 ecr 12620714], length 0 E..4.. at .@......^...\...Pw ...c9....s....... ...e.... 15:48:29.764201 IP (tos 0x0, ttl 64, id 4058, offset 0, flags [DF], proto TCP (6), length 234) 192.168.200.94.54670 > 192.168.200.92.80: Flags [P.], cksum 0x4365 (correct), seq 1:183, ack 1, win 115, options [nop,nop,TS val 12642405 ecr 12620714], length 182 E..... at .@..(...^...\...Pw ...c9....sCe..... ...e....PROPFIND /Family/ HTTP/1.1 User-Agent: davfs2/1.4.7 neon/0.29.3 Connection: TE TE: trailers Host: 192.168.200.92 Depth: 1 Content-Length: 286 Content-Type: application/xml 15:48:29.764211 IP (tos 0x0, ttl 64, id 43619, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.92.80 > 192.168.200.94.54670: Flags [.], cksum 0xaf1c (correct), seq 1, ack 183, win 122, options [nop,nop,TS val 12620714 ecr 12642405], length 0 E..4.c at .@.~T...\...^.P...c9.w .t...z....... .......e 15:48:29.764225 IP (tos 0x0, ttl 64, id 4059, offset 0, flags [DF], proto TCP (6), length 338) 192.168.200.94.54670 > 192.168.200.92.80: Flags [P.], cksum 0x7f54 (correct), seq 183:469, ack 1, win 115, options [nop,nop,TS val 12642405 ecr 12620714], length 286 E..R.. at .@......^...\...Pw .t.c9....s.T..... ...e.... 15:48:29.764229 IP (tos 0x0, ttl 64, id 43620, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.92.80 > 192.168.200.94.54670: Flags [.], cksum 0xadf6 (correct), seq 1, ack 469, win 130, options [nop,nop,TS val 12620714 ecr 12642405], length 0 E..4.d at .@.~S...\...^.P...c9.w ............. .......e 15:48:29.764747 IP (tos 0x0, ttl 64, id 43621, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.200.92.80 > 192.168.200.94.54670: Flags [.], cksum 0x17db (incorrect -> 0x4cfa), seq 1:1449, ack 469, win 130, options [nop,nop,TS val 12620715 ecr 12642405], length 1448 E....e at .@.x....\...^.P...c9.w ............. .......eHTTP/1.1 207 Multi-Status Server: nginx Date: Sat, 25 Jul 2015 12:48:29 GMT Transfer-Encoding: chunked Connection: keep-alive Keep-Alive: timeout=30 47 1ef /Family/ 2015-07-25T12:46:27Z 204800 Sat, 25 Jul 2015 12:46:27 GMT HTTP/1.1 200 OK 1f5 /Family/test 2015-07-25T10:58:14Z test 4096 Sat, 25 Jul 2015 10:58:14 GMT HTTP/1.1 200 OK 1f9 /Family/test_2 2015-07-25T12:46:27Z test_2 192.168.200.94.54670: Flags [P.], cksum 0x131a (incorrect -> 0x2d91), seq 1449:1680, ack 469, win 130, options [nop,nop,TS val 12620715 ecr 12642405], length 231 E....f at .@.}j...\...^.P...c?qw ............. .......egth>4096 Sat, 25 Jul 2015 12:46:27 GMT 15:48:29.764814 IP (tos 0x0, ttl 64, id 4060, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.94.54670 > 192.168.200.92.80: Flags [.], cksum 0xa845 (correct), seq 469, ack 1449, win 137, options [nop,nop,TS val 12642406 ecr 12620715], length 0 E..4.. at .@......^...\...Pw ...c?q.....E..... ...f.... 15:48:29.764825 IP (tos 0x0, ttl 64, id 4061, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.94.54670 > 192.168.200.92.80: Flags [.], cksum 0xa747 (correct), seq 469, ack 1680, win 160, options [nop,nop,TS val 12642406 ecr 12620715], length 0 E..4.. at .@......^...\...Pw ...c at X.....G..... ...f.... 15:48:29.764832 IP (tos 0x0, ttl 64, id 43623, offset 0, flags [DF], proto TCP (6), length 157) 192.168.200.92.80 > 192.168.200.94.54670: Flags [P.], cksum 0x129c (incorrect -> 0xe07b), seq 1680:1785, ack 469, win 130, options [nop,nop,TS val 12620715 ecr 12642406], length 105 E....g at .@.}....\...^.P...c at Xw ............. .......f HTTP/1.1 200 OK 11 0 15:48:29.764901 IP (tos 0x0, ttl 64, id 4062, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.94.54670 > 192.168.200.92.80: Flags [.], cksum 0xa6de (correct), seq 469, ack 1785, win 160, options [nop,nop,TS val 12642406 ecr 12620715], length 0 E..4.. at .@......^...\...Pw ...c at ............ ...f.... 15:48:29.765208 IP (tos 0x0, ttl 64, id 4063, offset 0, flags [DF], proto TCP (6), length 241) 192.168.200.94.54670 > 192.168.200.92.80: Flags [P.], cksum 0xe337 (correct), seq 469:658, ack 1785, win 160, options [nop,nop,TS val 12642406 ecr 12620715], length 189 E..... at .@......^...\...Pw ...c at ......7..... ...f....PROPFIND /Family/test_2/ HTTP/1.1 User-Agent: davfs2/1.4.7 neon/0.29.3 Connection: TE TE: trailers Host: 192.168.200.92 Depth: 1 Content-Length: 286 Content-Type: application/xml 15:48:29.765224 IP (tos 0x0, ttl 64, id 4064, offset 0, flags [DF], proto TCP (6), length 338) 192.168.200.94.54670 > 192.168.200.92.80: Flags [P.], cksum 0x7652 (correct), seq 658:944, ack 1785, win 160, options [nop,nop,TS val 12642406 ecr 12620715], length 286 E..R.. at .@......^...\...Pw .O.c at .....vR..... ...f.... 15:48:29.765244 IP (tos 0x0, ttl 64, id 43624, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.92.80 > 192.168.200.94.54670: Flags [.], cksum 0xa510 (correct), seq 1785, ack 944, win 147, options [nop,nop,TS val 12620715 ecr 12642406], length 0 E..4.h at .@.~O...\...^.P...c at .w .m........... .......f 15:48:29.765365 IP (tos 0x0, ttl 64, id 43625, offset 0, flags [DF], proto TCP (6), length 821) 192.168.200.92.80 > 192.168.200.94.54670: Flags [P.], cksum 0x1534 (incorrect -> 0x00fd), seq 1785:2554, ack 944, win 147, options [nop,nop,TS val 12620716 ecr 12642406], length 769 E..5.i at .@.{M...\...^.P...c at .w .m.....4..... .......fHTTP/1.1 207 Multi-Status Server: nginx Date: Sat, 25 Jul 2015 12:48:29 GMT Transfer-Encoding: chunked Connection: keep-alive Keep-Alive: timeout=30 47 1f4 /Family/test_2/ 2015-07-25T12:46:27Z 4096 Sat, 25 Jul 2015 12:46:27 GMT HTTP/1.1 200 OK 11 0 15:48:29.765861 IP (tos 0x0, ttl 64, id 4065, offset 0, flags [DF], proto TCP (6), length 177) 192.168.200.94.54670 > 192.168.200.92.80: Flags [P.], cksum 0x84e2 (correct), seq 944:1069, ack 2554, win 182, options [nop,nop,TS val 12642407 ecr 12620716], length 125 E..... at .@..Z...^...\...Pw .m.cC............ ...g....DELETE /Family/test_2/ HTTP/1.1 User-Agent: davfs2/1.4.7 neon/0.29.3 Connection: TE TE: trailers Host: 192.168.200.92 15:48:29.766131 IP (tos 0x0, ttl 64, id 43626, offset 0, flags [DF], proto TCP (6), length 179) 192.168.200.92.80 > 192.168.200.94.54670: Flags [P.], cksum 0x12b2 (incorrect -> 0x01cb), seq 2554:2681, ack 1069, win 147, options [nop,nop,TS val 12620716 ecr 12642407], length 127 E....j at .@.}....\...^.P...cC.w ............. .......gHTTP/1.1 204 No Content Server: nginx Date: Sat, 25 Jul 2015 12:48:29 GMT Connection: keep-alive Keep-Alive: timeout=30 15:48:29.805744 IP (tos 0x0, ttl 64, id 4066, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.94.54670 > 192.168.200.92.80: Flags [.], cksum 0xa0c6 (correct), seq 1069, ack 2681, win 182, options [nop,nop,TS val 12642447 ecr 12620716], length 0 E..4.. at .@......^...\...Pw ...cDA........... ........ ^C 26 packets captured 26 packets received by filter 0 packets dropped by kernel -------------- next part -------------- tcpdump -A -nn -vv port 80 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 15:47:34.728143 IP (tos 0x2,ECT(0), ttl 128, id 13348, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.81.49292 > 192.168.200.92.80: Flags [SEW], cksum 0x0f2e (correct), seq 2201151763, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 E..44$@........Q...\...P.2........ ................. 15:47:34.728219 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.92.80 > 192.168.200.81.49292: Flags [S.E], cksum 0x274f (correct), seq 1424980567, ack 2201151764, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 E..4.. at .@.(....\...Q.P..T.zW.2...R9.'O.............. 15:47:34.728412 IP (tos 0x0, ttl 128, id 13349, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49292 > 192.168.200.92.80: Flags [.], cksum 0x9964 (correct), seq 1, ack 1, win 2053, length 0 E..(4%@........Q...\...P.2..T.zXP....d........ 15:47:34.728525 IP (tos 0x2,ECT(0), ttl 128, id 13350, offset 0, flags [DF], proto TCP (6), length 207) 192.168.200.81.49292 > 192.168.200.92.80: Flags [P.], cksum 0xd62f (correct), seq 1:168, ack 1, win 2053, length 167 E...4&@........Q...\...P.2..T.zXP..../..PROPFIND /Family HTTP/1.1 Connection: Keep-Alive User-Agent: Microsoft-WebDAV-MiniRedir/6.3.9600 Depth: 1 translate: f Content-Length: 0 Host: 192.168.200.92 15:47:34.728544 IP (tos 0x0, ttl 64, id 50935, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49292: Flags [.], cksum 0xa047 (correct), seq 1, ack 168, win 123, length 0 E..(.. at .@.a....\...Q.P..T.zX.2..P..{.G.. 15:47:34.728810 IP (tos 0x2,ECT(0), ttl 64, id 50936, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.200.92.80 > 192.168.200.81.49292: Flags [.], cksum 0x17ce (incorrect -> 0xe37c), seq 1:1461, ack 168, win 123, length 1460 E..... at .@.\"...\...Q.P..T.zX.2..P..{....HTTP/1.1 207 Multi-Status Server: nginx Date: Sat, 25 Jul 2015 12:47:34 GMT Transfer-Encoding: chunked Connection: keep-alive Keep-Alive: timeout=30 47 1f4 /Family 2015-07-25T12:46:27Z Family 204800 Sat, 25 Jul 2015 12:46:27 GMT HTTP/1.1 200 OK 1f5 /Family/test 2015-07-25T10:58:14Z test 4096 Sat, 25 Jul 2015 10:58:14 GMT HTTP/1.1 200 OK 1f9 /Family/test_2 2015-07-25T12:46:27Z test_2 409 15:47:34.728864 IP (tos 0x2,ECT(0), ttl 64, id 50937, offset 0, flags [DF], proto TCP (6), length 245) 192.168.200.92.80 > 192.168.200.81.49292: Flags [P.], cksum 0x12e7 (incorrect -> 0x38bf), seq 1461:1666, ack 168, win 123, length 205 E..... at .@.a....\...Q.P..T....2..P..{....6 Sat, 25 Jul 2015 12:46:27 GMT 15:47:34.728939 IP (tos 0x0, ttl 128, id 13351, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49292 > 192.168.200.92.80: Flags [.], cksum 0x923c (correct), seq 168, ack 1666, win 2053, length 0 E..(4'@........Q...\...P.2..T...P....<........ 15:47:34.728951 IP (tos 0x2,ECT(0), ttl 64, id 50938, offset 0, flags [DF], proto TCP (6), length 164) 192.168.200.92.80 > 192.168.200.81.49292: Flags [P.], cksum 0x1296 (incorrect -> 0xe2f2), seq 1666:1790, ack 168, win 123, length 124 E..... at .@.aX...\...Q.P..T....2..P..{.... HTTP/1.1 200 OK 11 0 15:47:34.738639 IP (tos 0x2,ECT(0), ttl 128, id 13352, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.81.49293 > 192.168.200.92.80: Flags [SEW], cksum 0x9dd3 (correct), seq 770355125, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 E..44(@........Q...\...P-......... ................. 15:47:34.738690 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.92.80 > 192.168.200.81.49293: Flags [S.E], cksum 0xccc0 (correct), seq 1007647851, ack 770355126, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 E..4.. at .@.(....\...Q.P..<.|k-....R9................. 15:47:34.738861 IP (tos 0x0, ttl 128, id 13353, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49293 > 192.168.200.92.80: Flags [.], cksum 0x45db (correct), seq 1, ack 1, win 256, length 0 E..(4)@........Q...\...P-...<.|lP...E......... 15:47:34.738949 IP (tos 0x2,ECT(0), ttl 128, id 13354, offset 0, flags [DF], proto TCP (6), length 224) 192.168.200.81.49293 > 192.168.200.92.80: Flags [P.], cksum 0x5735 (correct), seq 1:185, ack 1, win 256, length 184 E...4*@........Q...\...P-...<.|lP...W5..PROPFIND /Family/test/desktop.ini HTTP/1.1 Connection: Keep-Alive User-Agent: Microsoft-WebDAV-MiniRedir/6.3.9600 Depth: 0 translate: f Content-Length: 0 Host: 192.168.200.92 15:47:34.738972 IP (tos 0x0, ttl 64, id 49365, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49293: Flags [.], cksum 0x45a8 (correct), seq 1, ack 185, win 123, length 0 E..(.. at .@.g....\...Q.P..<.|l-..nP..{E... 15:47:34.739217 IP (tos 0x2,ECT(0), ttl 64, id 49366, offset 0, flags [DF], proto TCP (6), length 374) 192.168.200.92.80 > 192.168.200.81.49293: Flags [P.], cksum 0x1368 (incorrect -> 0xe4a1), seq 1:335, ack 185, win 123, length 334 E..v.. at .@.f....\...Q.P..<.|l-..nP..{.h..HTTP/1.1 404 Not Found Server: nginx Date: Sat, 25 Jul 2015 12:47:34 GMT Content-Type: text/html Content-Length: 162 Connection: keep-alive Keep-Alive: timeout=30 404 Not Found

404 Not Found

nginx
15:47:34.744127 IP (tos 0x0, ttl 128, id 13355, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49292 > 192.168.200.92.80: Flags [.], cksum 0x91c1 (correct), seq 168, ack 1790, win 2052, length 0 E..(4+ at ........Q...\...P.2..T..UP............. 15:47:34.791120 IP (tos 0x0, ttl 128, id 13359, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49293 > 192.168.200.92.80: Flags [.], cksum 0x43d6 (correct), seq 185, ack 335, win 255, length 0 E..(4/@........Q...\...P-..n<.}.P...C......... 15:47:36.378017 IP (tos 0x2,ECT(0), ttl 128, id 13377, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.81.49294 > 192.168.200.92.80: Flags [SEW], cksum 0xf9f0 (correct), seq 4113009753, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 E..44A at ........Q...\...P.'.Y...... ................. 15:47:36.378065 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.92.80 > 192.168.200.81.49294: Flags [S.E], cksum 0xbd08 (correct), seq 1347998711, ack 4113009754, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 E..4.. at .@.(....\...Q.P..PX...'.Z.R9................. 15:47:36.378215 IP (tos 0x0, ttl 128, id 13378, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49294 > 192.168.200.92.80: Flags [.], cksum 0x2f1e (correct), seq 1, ack 1, win 2053, length 0 E..(4B at ........Q...\...P.'.ZPX..P.../......... 15:47:36.378403 IP (tos 0x2,ECT(0), ttl 128, id 13379, offset 0, flags [DF], proto TCP (6), length 212) 192.168.200.81.49294 > 192.168.200.92.80: Flags [P.], cksum 0xce90 (correct), seq 1:173, ack 1, win 2053, length 172 E...4C at ........Q...\...P.'.ZPX..P.......PROPFIND /Family/test HTTP/1.1 Connection: Keep-Alive User-Agent: Microsoft-WebDAV-MiniRedir/6.3.9600 Depth: 1 translate: f Content-Length: 0 Host: 192.168.200.92 15:47:36.378427 IP (tos 0x0, ttl 64, id 4312, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49294: Flags [.], cksum 0x35fc (correct), seq 1, ack 173, win 123, length 0 E..(.. at .@......\...Q.P..PX...'..P..{5... 15:47:36.378716 IP (tos 0x2,ECT(0), ttl 64, id 4313, offset 0, flags [DF], proto TCP (6), length 810) 192.168.200.92.80 > 192.168.200.81.49294: Flags [P.], cksum 0x151c (incorrect -> 0x1968), seq 1:771, ack 173, win 123, length 770 E..*.. at .@......\...Q.P..PX...'..P..{....HTTP/1.1 207 Multi-Status Server: nginx Date: Sat, 25 Jul 2015 12:47:36 GMT Transfer-Encoding: chunked Connection: keep-alive Keep-Alive: timeout=30 47 1f5 /Family/test 2015-07-25T10:58:14Z test 4096 Sat, 25 Jul 2015 10:58:14 GMT HTTP/1.1 200 OK 11 0 15:47:36.384761 IP (tos 0x0, ttl 128, id 13380, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49294 > 192.168.200.92.80: Flags [.], cksum 0x2b73 (correct), seq 173, ack 771, win 2050, length 0 E..(4D at ........Q...\...P.'..PX..P...+s........ 15:47:36.390116 IP (tos 0x2,ECT(0), ttl 128, id 13381, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.81.49295 > 192.168.200.92.80: Flags [SEW], cksum 0x5111 (correct), seq 3869852598, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 E..44E at ....}...Q...\...P..C....... .Q............... 15:47:36.390158 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.92.80 > 192.168.200.81.49295: Flags [S.E], cksum 0x05e2 (correct), seq 3758183061, ack 3869852599, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 E..4.. at .@.(....\...Q.P....R...C..R9................. 15:47:36.390321 IP (tos 0x0, ttl 128, id 13382, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49295 > 192.168.200.92.80: Flags [.], cksum 0x77f7 (correct), seq 1, ack 1, win 2053, length 0 E..(4F at ........Q...\...P..C...R.P...w......... 15:47:36.390392 IP (tos 0x2,ECT(0), ttl 128, id 13383, offset 0, flags [DF], proto TCP (6), length 212) 192.168.200.81.49295 > 192.168.200.92.80: Flags [P.], cksum 0x176a (correct), seq 1:173, ack 1, win 2053, length 172 E...4G at ........Q...\...P..C...R.P....j..PROPFIND /Family/test HTTP/1.1 Connection: Keep-Alive User-Agent: Microsoft-WebDAV-MiniRedir/6.3.9600 Depth: 1 translate: f Content-Length: 0 Host: 192.168.200.92 15:47:36.390403 IP (tos 0x0, ttl 64, id 37306, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49295: Flags [.], cksum 0x7ed5 (correct), seq 1, ack 173, win 123, length 0 E..(.. at .@......\...Q.P....R...DcP..{~... 15:47:36.390649 IP (tos 0x2,ECT(0), ttl 64, id 37307, offset 0, flags [DF], proto TCP (6), length 810) 192.168.200.92.80 > 192.168.200.81.49295: Flags [P.], cksum 0x151c (incorrect -> 0x6241), seq 1:771, ack 173, win 123, length 770 E..*.. at .@......\...Q.P....R...DcP..{....HTTP/1.1 207 Multi-Status Server: nginx Date: Sat, 25 Jul 2015 12:47:36 GMT Transfer-Encoding: chunked Connection: keep-alive Keep-Alive: timeout=30 47 1f5 /Family/test 2015-07-25T10:58:14Z test 4096 Sat, 25 Jul 2015 10:58:14 GMT HTTP/1.1 200 OK 11 0 15:47:36.395325 IP (tos 0x2,ECT(0), ttl 128, id 13384, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.81.49296 > 192.168.200.92.80: Flags [SEW], cksum 0x2f0d (correct), seq 3644355370, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 ...............Q...\...P.8s*...... ./ 15:47:36.395372 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.92.80 > 192.168.200.81.49296: Flags [S.E], cksum 0x0859 (correct), seq 3958252077, ack 3644355371, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 E..4.. at .@.(....\...Q.P...."-.8s+.R9..Y.............. 15:47:36.395532 IP (tos 0x0, ttl 128, id 13385, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49296 > 192.168.200.92.80: Flags [.], cksum 0x8173 (correct), seq 1, ack 1, win 256, length 0 E..(4I at ........Q...\...P.8s+..".P....s........ 15:47:36.395615 IP (tos 0x2,ECT(0), ttl 128, id 13386, offset 0, flags [DF], proto TCP (6), length 181) 192.168.200.81.49296 > 192.168.200.92.80: Flags [P.], cksum 0xa5da (correct), seq 1:142, ack 1, win 256, length 141 E...4J at ........Q...\...P.8s+..".P.......DELETE /Family/test HTTP/1.1 Connection: Keep-Alive User-Agent: Microsoft-WebDAV-MiniRedir/6.3.9600 translate: f Host: 192.168.200.92 15:47:36.395626 IP (tos 0x0, ttl 64, id 57628, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49296: Flags [.], cksum 0x816b (correct), seq 1, ack 142, win 123, length 0 E..(.. at .@.G....\...Q.P...."..8s.P..{.k.. 15:47:36.395803 IP (tos 0x2,ECT(0), ttl 64, id 57629, offset 0, flags [DF], proto TCP (6), length 176) 192.168.200.92.80 > 192.168.200.81.49296: Flags [P.], cksum 0x12a2 (incorrect -> 0xd843), seq 1:137, ack 142, win 123, length 136 E..... at .@.G)...\...Q.P...."..8s.P..{....HTTP/1.1 598 Server: nginx Date: Sat, 25 Jul 2015 12:47:36 GMT Content-Length: 0 Connection: keep-alive Keep-Alive: timeout=30 15:47:36.400346 IP (tos 0x0, ttl 128, id 13387, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49295 > 192.168.200.92.80: Flags [.], cksum 0x744c (correct), seq 173, ack 771, win 2050, length 0 E..(4K at ........Q...\...P..Dc..U.P...tL........ 15:47:36.447366 IP (tos 0x0, ttl 128, id 13391, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49296 > 192.168.200.92.80: Flags [.], cksum 0x805e (correct), seq 142, ack 137, win 256, length 0 E..(4O at ........Q...\...P.8s...".P....^........ 15:47:37.235568 IP (tos 0x0, ttl 64, id 56848, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49288: Flags [F.], cksum 0x17ab (correct), seq 2142933616, ack 3343575903, win 123, length 0 E..(.. at .@.J....\...Q.P.....p.J._P..{.... 15:47:37.235675 IP (tos 0x0, ttl 64, id 16004, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49289: Flags [F.], cksum 0x7966 (correct), seq 3416617270, ack 2466616119, win 123, length 0 E..(>. at .@..L...\...Q.P....q6...7P..{yf.. 15:47:37.235722 IP (tos 0x0, ttl 64, id 30846, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49290: Flags [F.], cksum 0xb607 (correct), seq 234631188, ack 3546682624, win 123, length 0 .0..f..P..{....\...Q.P.. 15:47:37.235754 IP (tos 0x0, ttl 64, id 8834, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49291: Flags [F.], cksum 0xea98 (correct), seq 811496776, ack 931861683, win 123, length 0 E..(". at .@..O...\...Q.P..0^uH7...P..{.... 15:47:37.236227 IP (tos 0x0, ttl 128, id 13396, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49291 > 192.168.200.92.80: Flags [F.], cksum 0xe30f (correct), seq 1, ack 1, win 2051, length 0 E..(4T at ....|...Q...\...P7...0^uIP............. From nginx-ru at sadok.spb.ru Wed Jun 24 13:28:30 2015 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Wed, 24 Jun 2015 16:28:30 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: References: <347082536.20150624153238@sadok.spb.ru> Message-ID: <1547899175.20150624162830@sadok.spb.ru> Здравствуйте, Иван. Вы писали 24 июня 2015 г., 15:51:38: > Дамп снимал. Ничего там интересного не увидел. На всякий случай > прикрепляю результаты дампа к письму Хм. На DELETE прилетает от nginx HTTP/1.1 598 https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#598 Может у вас там (как пишет вики) прокся некая чудит? И повторюсь: дамп нужен с обоих сторон. -- С уважением, Dmitry nginx-ru at sadok.spb.ru From simplebox66 at gmail.com Wed Jun 24 14:45:41 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 24 Jun 2015 17:45:41 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: <1547899175.20150624162830@sadok.spb.ru> References: <347082536.20150624153238@sadok.spb.ru> <1547899175.20150624162830@sadok.spb.ru> Message-ID: прокси нет. 598 , с помощью него я попадаю в именованный локейшн приведенный выше. Приведу тогда полный конфиг для ясности. А так же дамп с обоих сторон 24 июня 2015 г., 16:28 пользователь Dmitry Ivanov написал: > Здравствуйте, Иван. > > Вы писали 24 июня 2015 г., 15:51:38: > > > Дамп снимал. Ничего там интересного не увидел. На всякий случай > > прикрепляю результаты дампа к письму > > Хм. На DELETE прилетает от nginx HTTP/1.1 598 > > https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#598 > > Может у вас там (как пишет вики) прокся некая чудит? > > И повторюсь: дамп нужен с обоих сторон. > > -- > С уважением, > Dmitry nginx-ru at sadok.spb.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: -------------- next part -------------- set $webdav_root "/etc/nginx/davdir"; location ^~ /Family { root $webdav_root; error_page 599 = @propfind_handler; error_page 598 = @delete_handler; chunked_transfer_encoding on; open_file_cache off; client_max_body_size 50m; if ($request_method = PROPFIND) { return 599; } if ($request_method = PROPPATCH) { add_header Content-Type 'text/xml'; return 207 'HTTP/1.1 200 OK'; } if ($request_method = MKCOL) { rewrite ^(.*[^/])$ $1/; } if ($request_method = DELETE) { return 598; } dav_methods PUT MKCOL COPY MOVE; dav_ext_methods OPTIONS; create_full_put_path on; min_delete_depth 0; dav_access user:rw group:rw all:rw; autoindex on; autoindex_exact_size on; autoindex_localtime on; } location @propfind_handler { internal; open_file_cache off; if (!-e $webdav_root/$uri) { return 404; } root $webdav_root; dav_ext_methods PROPFIND; } location @delete_handler { internal; open_file_cache off; if (-d $webdav_root/$uri) { rewrite ^(.*[^/])$ $1/; } root $webdav_root; dav_methods DELETE; } location / { if ($request_method = OPTIONS) { add_header Allow 'OPTIONS, GET, HEAD, POST, PUT, MKCOL, DELETE, PROPFIND, PROPPATCH'; add_header DAV '1, 2'; return 200; } } } -------------- next part -------------- 192.168.200.81.49733 > 192.168.200.92.80: Flags [P.], cksum 0xaed4 (correct), seq 1:142, ack 1, win 2053, length 141 E...1i at ........Q...\.E.PN."G.|((P.......DELETE /Family/test HTTP/1.1 Connection: Keep-Alive User-Agent: Microsoft-WebDAV-MiniRedir/6.3.9600 translate: f Host: 192.168.200.92 17:42:49.932001 IP (tos 0x0, ttl 64, id 26906, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49733: Flags [.], cksum 0x916a (correct), seq 1, ack 142, win 123, length 0 E..(i. at .@......\...Q.P.E.|((N.".P..{.j.. 17:42:49.932125 IP (tos 0x2,ECT(0), ttl 64, id 26907, offset 0, flags [DF], proto TCP (6), length 176) 192.168.200.92.80 > 192.168.200.81.49733: Flags [P.], cksum 0x12a2 (incorrect -> 0xe346), seq 1:137, ack 142, win 123, length 136 E...i. at .@..+...\...Q.P.E.|((N.".P..{....HTTP/1.1 598 Server: nginx Date: Sat, 25 Jul 2015 14:42:49 GMT Content-Length: 0 Connection: keep-alive Keep-Alive: timeout=30 17:42:49.935035 IP (tos 0x0, ttl 128, id 12651, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49732 > 192.168.200.92.80: Flags [.], cksum 0xc4fe (correct), seq 173, ack 771, win 2050, length 0 E..(1k at ....e...Q...\.D.P..qZ..L.P............. 17:42:49.938587 IP (tos 0x0, ttl 128, id 12652, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49733 > 192.168.200.92.80: Flags [.], cksum 0x8959 (correct), seq 142, ack 137, win 2052, length 0 E..(1l at ....d...Q...\.E.PN."..|(.P....Y........ 17:42:49.955169 IP (tos 0x2,ECT(0), ttl 128, id 12654, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.81.49734 > 192.168.200.92.80: Flags [SEW], cksum 0x1901 (correct), seq 1684208726, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 E..41n at ....T...Q...\.F.Pdb.V...... ................. 17:42:49.955214 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.200.92.80 > 192.168.200.81.49734: Flags [S.E], cksum 0x88cb (correct), seq 2426005251, ack 1684208727, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 E..4.. at .@.(....\...Q.P.F....db.W.R9................. 17:42:49.955345 IP (tos 0x0, ttl 128, id 12655, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49734 > 192.168.200.92.80: Flags [.], cksum 0xfae0 (correct), seq 1, ack 1, win 2053, length 0 E..(1o at ....a...Q...\.F.Pdb.W....P............. 17:42:49.955465 IP (tos 0x2,ECT(0), ttl 128, id 12656, offset 0, flags [DF], proto TCP (6), length 219) 192.168.200.81.49734 > 192.168.200.92.80: Flags [P.], cksum 0x2b12 (correct), seq 1:180, ack 1, win 2053, length 179 E...1p at ........Q...\.F.Pdb.W....P...+...PROPFIND /Family/desktop.ini HTTP/1.1 Connection: Keep-Alive User-Agent: Microsoft-WebDAV-MiniRedir/6.3.9600 Depth: 0 translate: f Content-Length: 0 Host: 192.168.200.92 17:42:49.955478 IP (tos 0x0, ttl 64, id 42573, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49734: Flags [.], cksum 0x01b8 (correct), seq 1, ack 180, win 123, length 0 E..(.M at .@......\...Q.P.F....db. P..{.... 17:42:49.955599 IP (tos 0x2,ECT(0), ttl 64, id 42574, offset 0, flags [DF], proto TCP (6), length 374) 192.168.200.92.80 > 192.168.200.81.49734: Flags [P.], cksum 0x1368 (incorrect -> 0xa4aa), seq 1:335, ack 180, win 123, length 334 E..v.N at .@..2...\...Q.P.F....db. P..{.h..HTTP/1.1 404 Not Found Server: nginx Date: Sat, 25 Jul 2015 14:42:49 GMT Content-Type: text/html Content-Length: 162 Connection: keep-alive Keep-Alive: timeout=30 404 Not Found

404 Not Found

nginx
17:42:49.966292 IP (tos 0x0, ttl 128, id 12657, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49734 > 192.168.200.92.80: Flags [.], cksum 0xf8e1 (correct), seq 180, ack 335, win 2051, length 0 E..(1q at ...._...Q...\.F.Pdb. ...RP............. 17:42:53.035780 IP (tos 0x0, ttl 64, id 56557, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49722: Flags [F.], cksum 0xad06 (correct), seq 2414414714, ack 931683036, win 123, length 0 E..(.. at .@.K....\...Q.P.:...z7.Z.P..{.... 17:42:53.036077 IP (tos 0x0, ttl 128, id 12700, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49722 > 192.168.200.92.80: Flags [.], cksum 0xa57d (correct), seq 1, ack 1, win 2052, length 0 E..(1. at ....4...Q...\.:.P7.Z....{P....}........ 17:42:53.036142 IP (tos 0x0, ttl 128, id 12701, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49722 > 192.168.200.92.80: Flags [F.], cksum 0xa57c (correct), seq 1, ack 1, win 2052, length 0 E..(1. at ....3...Q...\.:.P7.Z....{P....|........ 17:42:53.036157 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49722: Flags [.], cksum 0xad05 (correct), seq 1, ack 2, win 123, length 0 E..(.. at .@.(....\...Q.P.:...{7.Z.P..{.... 17:42:54.535807 IP (tos 0x0, ttl 64, id 14063, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49723: Flags [F.], cksum 0x25f3 (correct), seq 810019316, ack 2634218907, win 123, length 0 E..(6. at .@......\...Q.P.;0G......P..{%... 17:42:54.535875 IP (tos 0x0, ttl 64, id 6550, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.92.80 > 192.168.200.81.49724: Flags [F.], cksum 0x0dad (correct), seq 1605028135, ack 1598375176, win 123, length 0 ...(.. at .@..;...\...Q.P.<_..'_EE.P..{ 17:42:54.536172 IP (tos 0x0, ttl 128, id 12706, offset 0, flags [DF], proto TCP (6), length 40) 192.168.200.81.49723 > 192.168.200.92.80: Flags [.], cksum 0x1e6b (correct), seq 1, ack 1, win 2051, length 0 -------------- next part -------------- 17:39:39.372492 IP (tos 0x2,ECT(0), ttl 128, id 12649, offset 0, flags [DF], pro to: TCP (6), length: 181, bad cksum 0 (->b6d8)!) 192.168.200.81.49733 > 192.168. 200.92.80: P 1:142(141) ack 1 win 2053 E...1i at ........Q...\.E.PN."G.|((P.......DELETE /Family/test HTTP/1.1 Connection: 17:39:39.372605 IP (tos 0x0, ttl 64, id 26906, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.200.92.80 > 192.168.200.81.49733: ., cksum 0x916a (cor rect), 1:1(0) ack 142 win 123 E..(i. at .@......\...Q.P.E.|((N.".P..{.j........ 17:39:39.372741 IP (tos 0x2,ECT(0), ttl 64, id 26907, offset 0, flags [DF], pro to: TCP (6), length: 176) 192.168.200.92.80 > 192.168.200.81.49733: P 1:137(136) ack 142 win 123 E...i. at .@..+...\...Q.P.E.|((N.".P..{.F..HTTP/1.1 598 Server: nginx Date: Sat, 2 17:39:39.375547 IP (tos 0x0, ttl 128, id 12651, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->b765)!) 192.168.200.81.49732 > 192.168.200.92.8 0: ., cksum 0x121a (incorrect (-> 0xc4fe), 173:173(0) ack 771 win 2050 E..(1k at ........Q...\.D.P..qZ..L.P....... 17:39:39.375560 IP (tos 0x0, ttl 128, id 12652, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->b764)!) 192.168.200.81.49733 > 192.168.200.92.8 0: ., cksum 0x121a (incorrect (-> 0x8959), 142:142(0) ack 137 win 2052 E..(1l at ........Q...\.E.PN."..|(.P....... 17:39:39.395658 IP (tos 0x2,ECT(0), ttl 128, id 12654, offset 0, flags [DF], pro to: TCP (6), length: 52, bad cksum 0 (->b754)!) 192.168.200.81.49734 > 192.168.2 00.92.80: SWE, cksum 0x1226 (incorrect (-> 0x1901), 1684208726:1684208726(0) win 8192 E..41n at ........Q...\.F.Pdb.V...... ..&.............. 17:39:39.395833 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6) , length: 52) 192.168.200.92.80 > 192.168.200.81.49734: SE, cksum 0x88cb (correc t), 2426005251:2426005251(0) ack 1684208727 win 14600 E..4.. at .@.(....\...Q.P.F....db.W.R9................. 17:39:39.395885 IP (tos 0x0, ttl 128, id 12655, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->b761)!) 192.168.200.81.49734 > 192.168.200.92.8 0: ., cksum 0x121a (incorrect (-> 0xfae0), 1:1(0) ack 1 win 2053 E..(1o at ........Q...\.F.Pdb.W....P....... 17:39:39.395992 IP (tos 0x2,ECT(0), ttl 128, id 12656, offset 0, flags [DF], pro to: TCP (6), length: 219, bad cksum 0 (->b6ab)!) 192.168.200.81.49734 > 192.168. 200.92.80: P 1:180(179) ack 1 win 2053 E...1p at ........Q...\.F.Pdb.W....P.......PROPFIND /Family/desktop.ini HTTP/1.1 Con 17:39:39.396087 IP (tos 0x0, ttl 64, id 42573, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.200.92.80 > 192.168.200.81.49734: ., cksum 0x01b8 (cor rect), 1:1(0) ack 180 win 123 E..(.M at .@......\...Q.P.F....db. P..{.......... 17:39:39.396201 IP (tos 0x2,ECT(0), ttl 64, id 42574, offset 0, flags [DF], pro to: TCP (6), length: 374) 192.168.200.92.80 > 192.168.200.81.49734: P 1:335(334) ack 180 win 123 E..v.N at .@..2...\...Q.P.F....db. P..{....HTTP/1.1 404 Not Found Server: nginx Dat 17:39:39.406797 IP (tos 0x0, ttl 128, id 12657, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->b75f)!) 192.168.200.81.49734 > 192.168.200.92.8 0: ., cksum 0x121a (incorrect (-> 0xf8e1), 180:180(0) ack 335 win 2051 E..(1q at ........Q...\.F.Pdb. ...RP....... 17:39:42.476443 IP (tos 0x0, ttl 64, id 56557, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.200.92.80 > 192.168.200.81.49722: F, cksum 0xad06 (cor rect), 2414414714:2414414714(0) ack 931683036 win 123 E..(.. at .@.K....\...Q.P.:...z7.Z.P..{.......... 17:39:42.476510 IP (tos 0x0, ttl 128, id 12700, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->b734)!) 192.168.200.81.49722 > 192.168.200.92.8 0: ., cksum 0x121a (incorrect (-> 0xa57d), 1:1(0) ack 1 win 2052 E..(1. at ........Q...\.:.P7.Z....{P....... 17:39:42.476654 IP (tos 0x0, ttl 128, id 12701, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->b733)!) 192.168.200.81.49722 > 192.168.200.92.8 0: F, cksum 0x121a (incorrect (-> 0xa57c), 1:1(0) ack 1 win 2052 E..(1. at ........Q...\.:.P7.Z....{P....... 17:39:42.476757 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6) , length: 40) 192.168.200.92.80 > 192.168.200.81.49722: ., cksum 0xad05 (correct ), 1:1(0) ack 2 win 123 E..(.. at .@.(....\...Q.P.:...{7.Z.P..{.......... 17:39:43.976475 IP (tos 0x0, ttl 64, id 14063, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.200.92.80 > 192.168.200.81.49723: F, cksum 0x25f3 (cor rect), 810019316:810019316(0) ack 2634218907 win 123 E..(6. at .@......\...Q.P.;0G......P..{%......... 17:39:43.976477 IP (tos 0x0, ttl 64, id 6550, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.200.92.80 > 192.168.200.81.49724: F, cksum 0x0dad (corr ect), 1605028135:1605028135(0) ack 1598375176 win 123 ...........;...\...Q.P.<_..'_EE.P..{ 17:39:43.976549 IP (tos 0x0, ttl 128, id 12706, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->b72e)!) 192.168.200.81.49723 > 192.168.200.92.8 0: ., cksum 0x121a (incorrect (-> 0x1e6b), 1:1(0) ack 1 win 2051 E..(1. at ........Q...\.;.P....0G..P....... 17:39:43.976601 IP (tos 0x0, ttl 128, id 12707, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->b72d)!) 192.168.200.81.49723 > 192.168.200.92.8 0: F, cksum 0x121a (incorrect (-> 0x1e6a), 1:1(0) ack 1 win 2051 E..(1. at ........Q...\.;.P....0G..P....... 17:39:43.976629 IP (tos 0x0, ttl 128, id 12708, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->b72c)!) 192.168.200.81.49724 > 192.168.200.92.8 0: ., cksum 0x121a (incorrect (-> 0x0625), 1:1(0) ack 1 win 2051 E..(1. at ........Q...\.<.P_EE._..(P....... 17:39:43.976693 IP (tos 0x0, ttl 128, id 12709, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->b72b)!) 192.168.200.81.49724 > 192.168.200.92.8 0: F, cksum 0x121a (incorrect (-> 0x0624), 1:1(0) ack 1 win 2051 E..(1. at ........Q...\.<.P_EE._..(P....... 17:39:43.976822 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6) , length: 40) 192.168.200.92.80 > 192.168.200.81.49723: ., cksum 0x25f2 (correct ), 1:1(0) ack 2 win 123 E..(.. at .@.(....\...Q.P.;0G......P..{%......... 17:39:43.976824 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6) , length: 40) 192.168.200.92.80 > 192.168.200.81.49724: ., cksum 0x0dac (correct ), 1:1(0) ack 2 win 123 ..........(....\...Q.P.<_..(_EE P..{ From nginx-ru at sadok.spb.ru Wed Jun 24 15:02:24 2015 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Wed, 24 Jun 2015 18:02:24 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: References: <347082536.20150624153238@sadok.spb.ru> <1547899175.20150624162830@sadok.spb.ru> Message-ID: <1575306367.20150624180224@sadok.spb.ru> Здравствуйте, Иван. Вы писали 24 июня 2015 г., 17:45:41: > прокси нет. 598 , с помощью него я попадаю в именованный локейшн приведенный выше. > Приведу тогда полный конфиг для ясности. А так же дамп с обоих сторон вы уверены, что виндовый клиент 598 отрабатывает правильно? -- С уважением, Dmitry nginx-ru at sadok.spb.ru From nginx-ru at sadok.spb.ru Wed Jun 24 15:06:59 2015 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Wed, 24 Jun 2015 18:06:59 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: References: <347082536.20150624153238@sadok.spb.ru> <1547899175.20150624162830@sadok.spb.ru> Message-ID: <43089532.20150624180659@sadok.spb.ru> Здравствуйте, Иван. Вы писали 24 июня 2015 г., 17:45:41: > прокси нет. 598 , с помощью него я попадаю в именованный локейшн приведенный выше. > Приведу тогда полный конфиг для ясности. А так же дамп с обоих сторон дополню про 598. "Правильно", т.е. так, как вам хочется. Я наблюдал всяческое игнорирование со стороны всторенного виндового WebDAV всеразличных редиректов по 30x и т.д. Разруливать приходилось на уровне типа if PROPFIND then но это не на nginx было, а на Netcaler. -- С уважением, Dmitry nginx-ru at sadok.spb.ru From simplebox66 at gmail.com Wed Jun 24 15:10:57 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 24 Jun 2015 18:10:57 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: <1575306367.20150624180224@sadok.spb.ru> References: <347082536.20150624153238@sadok.spb.ru> <1547899175.20150624162830@sadok.spb.ru> <1575306367.20150624180224@sadok.spb.ru> Message-ID: не уверен, но 599 отрабатывает точно правильно потому что метод PROPFIND работает без вопросов. В качестве экспиремента поменял местами 599 и 598 в итоге PROPFIND как работал так и работает а DELETE каталогов как не работал так и не работает. 24 июня 2015 г., 18:02 пользователь Dmitry Ivanov написал: > Здравствуйте, Иван. > > Вы писали 24 июня 2015 г., 17:45:41: > > > прокси нет. 598 , с помощью него я попадаю в именованный локейшн > приведенный выше. > > Приведу тогда полный конфиг для ясности. А так же дамп с обоих сторон > > вы уверены, что виндовый клиент 598 отрабатывает правильно? > > > -- > С уважением, > Dmitry nginx-ru at sadok.spb.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 simplebox66 at gmail.com Wed Jun 24 15:12:26 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 24 Jun 2015 18:12:26 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: References: <347082536.20150624153238@sadok.spb.ru> <1547899175.20150624162830@sadok.spb.ru> <1575306367.20150624180224@sadok.spb.ru> Message-ID: > > Я наблюдал > всяческое игнорирование со стороны всторенного виндового WebDAV > всеразличных редиректов по 30x и т.д. ОК, как я могу проверить игнорит винда 598 или нет? 24 июня 2015 г., 18:10 пользователь Иван Мишин написал: > не уверен, но 599 отрабатывает точно правильно потому что метод PROPFIND > работает без вопросов. В качестве экспиремента поменял местами 599 и 598 в > итоге PROPFIND как работал так и работает а DELETE каталогов как не работал > так и не работает. > > 24 июня 2015 г., 18:02 пользователь Dmitry Ivanov > написал: > > Здравствуйте, Иван. >> >> Вы писали 24 июня 2015 г., 17:45:41: >> >> > прокси нет. 598 , с помощью него я попадаю в именованный локейшн >> приведенный выше. >> > Приведу тогда полный конфиг для ясности. А так же дамп с обоих сторон >> >> вы уверены, что виндовый клиент 598 отрабатывает правильно? >> >> >> -- >> С уважением, >> Dmitry nginx-ru at sadok.spb.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 onokonem at gmail.com Wed Jun 24 15:15:07 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 24 Jun 2015 18:15:07 +0300 Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: References: <347082536.20150624153238@sadok.spb.ru> <1547899175.20150624162830@sadok.spb.ru> <1575306367.20150624180224@sadok.spb.ru> Message-ID: > прокси нет. 598 , с помощью него я попадаю в именованный локейшн приведенный > выше. в этом случае до винды этот код дойти не должен. если доходит - вы плохо настроили error From simplebox66 at gmail.com Wed Jun 24 15:17:23 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 24 Jun 2015 18:17:23 +0300 Subject: =?UTF-8?B?UmVbMl06INC/0YDQvtCx0LvQtdC80LAg0YEgcmV3cml0ZQ==?= In-Reply-To: References: Message-ID: <1435159043.583020149@f244.i.mail.ru> Даниель, можно подробнее пожалуйста про этот момент -- Отправлено из Mail.Ru для Android среда, 24 июня 2015г., 19:15 +04:00 от Daniel Podolsky : >> прокси нет. 598 , с помощью него я попадаю в именованный локейшн приведенный >> выше. >в этом случае до винды этот код дойти не должен. если доходит - вы >плохо настроили error >_______________________________________________ >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 gmm at csdoc.com Wed Jun 24 15:34:01 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Wed, 24 Jun 2015 18:34:01 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: References: Message-ID: <558ACDE9.5060006@csdoc.com> On 23.06.2015 19:56, Amanda Sproule wrote: > server { > .... > .... > > root /www; > index index.html index.php; > > include fastcgi_params; > fastcgi_index index.php; > > location /info { > fastcgi_param SCRIPT_FILENAME /www/info.php; > fastcgi_pass 127.0.0.1:9000 ; > } > > ..... > ...... > } > > Проблема в том, что в локейшене /info не наследуются fastcgi_param > (все), указанный в контексте server, если происходит переопределение > одного fastcgi_param параметра внутри локейшена. http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_param These directives are inherited from the previous level if and only if there are no fastcgi_param directives defined on the current level. > выходит если я переопределяю (устанавливаю) какой-либо fastcgi_param > параметр, то наследования fastcgi_params вовсе отменяется? Для чего > тогда это наследование? Почему нельзя наследовать с верхнего уровня и > иметь возможность переопределить какой-либо параметр? Подробный ответ на эти вопросы здесь: https://events.yandex.ru/lib/talks/2392/ Масштабируемая конфигурация nginx (RUS) https://www.youtube.com/watch?v=YWRYbLKsS0I Scaleable NGINX Configuration (ENG) http://www.slideshare.net/profyclub_ru/nginx-nginx Масштабируемая конфигурация nginx (слайды) -- Best regards, Gena From onokonem at gmail.com Wed Jun 24 15:55:11 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Wed, 24 Jun 2015 18:55:11 +0300 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQv9GA0L7QsdC70LXQvNCwINGBIHJld3JpdGU=?= In-Reply-To: <1435159043.583020149@f244.i.mail.ru> References: <1435159043.583020149@f244.i.mail.ru> Message-ID: > Даниель, можно подробнее пожалуйста про этот момент про какой? про переход в именованный локейшн? или про то, что код, который для этого используется, наружу отдаваться не должен? From andrey at kopeyko.ru Wed Jun 24 16:07:49 2015 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Wed, 24 Jun 2015 19:07:49 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: References: Message-ID: <558AD5D5.4020107@kopeyko.ru> 23.06.2015 19:56, Amanda Sproule пишет: > Здравствуйте. Добрый вечер! > Имеется такая тестовая конфигураци. > > server { > .... > root /www; > index index.html index.php; > > include fastcgi_params; > fastcgi_index index.php; > > location /info { > fastcgi_param SCRIPT_FILENAME /www/info.php; > fastcgi_pass 127.0.0.1:9000 ; > } > ...... > } > > Проблема в том, что в локейшене /info не наследуются fastcgi_param > (все), указанный в контексте server, если происходит переопределение > одного fastcgi_param параметра внутри локейшена. PHP-FPM возвращает код > В документации описан момент > """ > Директивы наследуются с предыдущего уровня при условии, что на данном > уровне не описаны свои директивы |fastcgi_param|. > """ > > выходит если я переопределяю (устанавливаю) какой-либо fastcgi_param > параметр, то наследования fastcgi_params вовсе отменяется? Ну да. Сделайте вот так server { .... include fastcgi_params; fastcgi_index index.php; location /info { fastcgi_param SCRIPT_FILENAME /www/info.php; include fastcgi_params; fastcgi_pass 127.0.0.1:9000 ; } } и наступит счастье. > -- Best regards, Andrey Kopeyko From gmm at csdoc.com Wed Jun 24 16:46:25 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Wed, 24 Jun 2015 19:46:25 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: <558AD5D5.4020107@kopeyko.ru> References: <558AD5D5.4020107@kopeyko.ru> Message-ID: <558ADEE1.5090600@csdoc.com> On 24.06.2015 19:07, Andrey Kopeyko wrote: > Сделайте вот так > > server { > .... > include fastcgi_params; > fastcgi_index index.php; > > location /info { > fastcgi_param SCRIPT_FILENAME /www/info.php; > include fastcgi_params; > fastcgi_pass 127.0.0.1:9000 ; > } > } > > и наступит счастье. счастье не наступит. если сделать так - тогда можно будет наступить на грабли, если вдруг понадобится переопределить какой-либо еще параметр кроме SCRIPT_FILENAME, например, HTTPS. чтобы полное счастье наступило, лучше делать всегда так, что include fastcgi_params; будет первой строкой в блоке, fastcgi_pass - последней, а между ними - директивы fastcgi_param. -- Best regards, Gena From vbart at nginx.com Wed Jun 24 16:57:43 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 24 Jun 2015 19:57:43 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: <558ADEE1.5090600@csdoc.com> References: <558AD5D5.4020107@kopeyko.ru> <558ADEE1.5090600@csdoc.com> Message-ID: <3235222.lfrYlOb2WZ@vbart-workstation> On Wednesday 24 June 2015 19:46:25 Gena Makhomed wrote: > On 24.06.2015 19:07, Andrey Kopeyko wrote: > > > Сделайте вот так > > > > server { > > .... > > include fastcgi_params; > > fastcgi_index index.php; > > > > location /info { > > fastcgi_param SCRIPT_FILENAME /www/info.php; > > include fastcgi_params; > > fastcgi_pass 127.0.0.1:9000 ; > > } > > } > > > > и наступит счастье. > > счастье не наступит. если сделать так - тогда можно будет > наступить на грабли, если вдруг понадобится переопределить > какой-либо еще параметр кроме SCRIPT_FILENAME, например, HTTPS. > > чтобы полное счастье наступило, лучше делать всегда так, > что include fastcgi_params; будет первой строкой > в блоке, fastcgi_pass - последней, а между ними - > директивы fastcgi_param. > > Это не поможет. Разве что только некоторые реализации FastCGI берут только последнее значение параметра, но передаваться всегда будут оба. И нет никак гарантий, как это будет обработано. Правильный способ - не выносить в fastcgi_params параметры, которые требуется часто переопределять. А если все же требуется переопределить какой-то из параметров, то лучше скопировать их все. Расположение fastcgi_pass вообще ни на что не влияет. -- Валентин Бартенев From gmm at csdoc.com Wed Jun 24 17:58:42 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Wed, 24 Jun 2015 20:58:42 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: <3235222.lfrYlOb2WZ@vbart-workstation> References: <558AD5D5.4020107@kopeyko.ru> <558ADEE1.5090600@csdoc.com> <3235222.lfrYlOb2WZ@vbart-workstation> Message-ID: <558AEFD2.2020309@csdoc.com> On 24.06.2015 19:57, Валентин Бартенев wrote: >>> location /info { >>> fastcgi_param SCRIPT_FILENAME /www/info.php; >>> include fastcgi_params; >>> fastcgi_pass 127.0.0.1:9000 ; >>> } >> чтобы полное счастье наступило, лучше делать всегда так, >> что include fastcgi_params; будет первой строкой >> в блоке, fastcgi_pass - последней, а между ними - >> директивы fastcgi_param. > Это не поможет. Разве что только некоторые реализации FastCGI > берут только последнее значение параметра, но передаваться всегда > будут оба. И нет никак гарантий, как это будет обработано. По крайней мере, php-fpm обрабатывает только последний параметр, как и ожидалось, и вряд ли это уже изменится в новых версиях PHP. А зачем такое странное поведение fastcgi_param было реализовано? - https://en.wikipedia.org/wiki/Principle_of_least_astonishment Например, "аналогичная" по своей сути директива proxy_set_header переопределяет существующее значение, а не добавляет еще один header. Тем более, что в протоколе CGI, на котором основан протокол FastCGI эти параметры передаются скрипту в виде переменных окружения, и там даже теоретически невозможно сделать несколько значений всегда будет использовано только последнее значение параметра. Очень странная это feature, она больше похожа на bug Есть ли шансы, что этот bug будет исправлен в nginx? -- Best regards, Gena From paranoidchaos at gmail.com Wed Jun 24 21:04:33 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Thu, 25 Jun 2015 02:04:33 +0500 Subject: =?UTF-8?B?UmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFzdGNnaV9wYXJhbQ==?= Message-ID: >>Очень странная это feature, она больше похожа на bug >>Есть ли шансы, что этот bug будет исправлен в nginx? Я об этом же, и nginx игнорирует предыдущие fastcgi_param если в локейшене переопределить новый fastcgi_param. И поэтому в моём случае PHP-FPM отвечал пустым ответом, так как ему передавался только fastcgi_param SCRIPT_FILENAME /www/info.php; А минимальный набор fastcgi_param: fastcgi_param REQUEST_METHOD $request_method; fastcgi_param SCRIPT_FILENAME /www/info.php; как я и указал в топике. И передачу этих параметров легко можно просмотреть в phpinfo(), что и подтвердило мою мысль. И никак такое поведение нельзя назвать механизмом наследования. >>Например, "аналогичная" по своей сути директива proxy_set_header >>переопределяет существующее значение, а не добавляет еще один header. И в ней такие же проблемы (фичи) недавно столкнулся када на уровне http прописал параметры от модуля http_realip_module. В локейшене где происходил proxy_pass прописал proxy_set_header и модуль realip уже не передавал свои заголовки (в логах светился не айпи клиента, а самого сервера). И опять таки про proxy_set_header в документации написано """ Директивы наследуются с предыдущего уровня при условии, что на данном уровне не описаны свои директивы proxy_set_header. По умолчанию переопределяются только два поля: proxy_set_header Host $proxy_host; proxy_set_header Connection close; """ Спасибо. Хотелось бы услышть мнение разработчиков. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simplebox66 at gmail.com Thu Jun 25 06:28:42 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Thu, 25 Jun 2015 09:28:42 +0300 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQv9GA0L7QsdC70LXQvNCwINGBIHJld3JpdGU=?= In-Reply-To: References: <1435159043.583020149@f244.i.mail.ru> Message-ID: > > в этом случае до винды этот код дойти не должен. если доходит - вы > плохо настроили error Ну судя по tcpdump на стороне винды, 598 код все же доходит до нее. про какой? про переход в именованный локейшн? или про то, что код, > который для этого используется, наружу отдаваться не должен? И про то и про другое, если не затруднит. ВО-первых, PROPFIND метод работает, при том что он организован в моем конфиге тем же способом что и метод DELETE с той лишь разницей что PROPFIND через 599 код работает, а DELETE через 598. Но я так понимаю что-это различие не на что не влияет ибо пробовал менять коды местами и...вот цитата моих слов по этому поводу: > 599 отрабатывает точно правильно потому что метод PROPFIND работает без > вопросов. В качестве экспиремента поменял местами 599 и 598 в > итоге PROPFIND как работал так и работает а DELETE каталогов как не работал > так и не работает. ВО-вторых, мне казалось что если с клиента ( в данном случае с винды) ушел запрос DELETE на nginx и nginx то nginx его должен отработать и каталог удалить, и не важно что он ответит клиент, потому что для клиента этот ответ будет чисто информационным т.е. не будет влиять на результат выполнения первого запроса (запроса на DELETE). 24 июня 2015 г., 18:55 пользователь Daniel Podolsky написал: > > Даниель, можно подробнее пожалуйста про этот момент > про какой? про переход в именованный локейшн? или про то, что код, > который для этого используется, наружу отдаваться не должен? > _______________________________________________ > 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 Jun 25 08:23:50 2015 From: nginx-forum at nginx.us (anstrem) Date: Thu, 25 Jun 2015 04:23:50 -0400 Subject: =?UTF-8?B?0KHQu9C+0LbQvdCw0Y8g0LfQsNC80LXQvdCwIFVSTCDQsiBuZ2lueCA/?= Message-ID: <41aa5d122153d633e6fef6052083757a.NginxMailingListRussian@forum.nginx.org> Подскажите как решить задачку с подменой URL в nginx, если это конечно возможно: Нужно вместо страницы http://site.ru/page?filter=&fd13=105 переадресовать пользователя на страницу: http://site.ru/page/subpage Но показать ему при этом содержимое из: http://site.ru/page?filter=&fd13=105&code=m Если в общем случае, то это будет звучать как: 1) если URL заканчивается параметром "?filter=&fd13=105", то надо в адресной строке заменить этот параметр на "/subpage" 2) и далее следом если URL заканчивается на /subpage, то надо показать данные c URL что было вызвано, но в котором заменено "/subpage" на "?filter=&fd13=105&code=m" Ну и чтобы при этом зацикливания не произошло, хотя вроде и не должно... Если просто напрямую вызовут URL заканчивающийся на /subpage, то естественно тоже чтобы 2-ое правило отработало. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259885,259885#msg-259885 From alstpostbox at gmail.com Thu Jun 25 08:49:31 2015 From: alstpostbox at gmail.com (Andrey Istochkin) Date: Thu, 25 Jun 2015 11:49:31 +0300 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQv9GA0L7QsdC70LXQvNCwINGBIHJld3JpdGU=?= In-Reply-To: References: <1435159043.583020149@f244.i.mail.ru> Message-ID: Попробуйте в @delete_handler в rewrite добавить 'break'. Так как в access_логе фигурирует 598, то похоже на то, что @delete_handler отрабатывает, отрабатывает rewrite, после чего запрос уходит снова в 'location ^~ /Family', опять отрабатывает 'return 598', но так как recursive_error_pages по-умолчанию выключена, error_page на этот раз не срабатывает, и клиент получает 598. 25 июня 2015 г., 9:28 пользователь Иван Мишин написал: > в этом случае до винды этот код дойти не должен. если доходит - вы >> плохо настроили error > > > Ну судя по tcpdump на стороне винды, 598 код все же доходит до нее. > > про какой? про переход в именованный локейшн? или про то, что код, >> который для этого используется, наружу отдаваться не должен? > > > И про то и про другое, если не затруднит. > ВО-первых, PROPFIND метод работает, при том что он организован в моем > конфиге тем же способом что и метод DELETE с той лишь разницей что PROPFIND > через 599 код работает, а DELETE через 598. Но я так понимаю что-это > различие не на что не влияет ибо пробовал менять коды местами и...вот > цитата моих слов по этому поводу: > >> 599 отрабатывает точно правильно потому что метод PROPFIND работает без >> вопросов. В качестве экспиремента поменял местами 599 и 598 в >> итоге PROPFIND как работал так и работает а DELETE каталогов как не работал >> так и не работает. > > > ВО-вторых, мне казалось что если с клиента ( в данном случае с винды) ушел > запрос DELETE на nginx и nginx то nginx его должен отработать и каталог > удалить, и не важно что он ответит клиент, потому что для клиента этот > ответ будет чисто информационным т.е. не будет влиять на результат > выполнения первого запроса (запроса на DELETE). > > > 24 июня 2015 г., 18:55 пользователь Daniel Podolsky > написал: > > > Даниель, можно подробнее пожалуйста про этот момент >> про какой? про переход в именованный локейшн? или про то, что код, >> который для этого используется, наружу отдаваться не должен? >> _______________________________________________ >> 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 simplebox66 at gmail.com Thu Jun 25 11:54:28 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Thu, 25 Jun 2015 14:54:28 +0300 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQv9GA0L7QsdC70LXQvNCwINGBIHJld3JpdGU=?= In-Reply-To: References: <1435159043.583020149@f244.i.mail.ru> Message-ID: Андрей, спасибо, помогло. Добавил break и каталоги удаляются без проблем. Но есть еще один вопрос, касающийся метода MOVE, то есть перемещение каталогов. К письму прикрепляю логи. Проблема конкретно тут: 2015/07/26 14:48:08 [error] 6735#0: *61 both URI "/Family/Новая папка/" and "Destination" URI " http://192.168.200.92/Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0%20%282%29/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0" should be either collections or non-collections, client: 192.168.200.81, server: 192.168.200.92, request: "MOVE /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0 HTTP/1.1", host: "192.168.200.92" Винда не понимает сама где каталоги, а где просто файлы. То есть в случае метода MOVE я с помощью rewrite дописываю в конце слеш, а вот как дописать слеш к тому каталогу в который я перемещаю первый каталог не понятно. Если к методу PROPFIND дописать if (-d $webdav_root/$uri) { rewrite ^(.*[^/])$ $1/ break; } то в логах просто все зацикливается и все. Может у вас есть какие-то мысля по этому поводу? 25 июня 2015 г., 11:49 пользователь Andrey Istochkin написал: > Попробуйте в @delete_handler в rewrite добавить 'break'. Так как в > access_логе фигурирует 598, то похоже на то, что @delete_handler > отрабатывает, отрабатывает rewrite, после чего запрос уходит снова в > 'location ^~ /Family', опять отрабатывает 'return 598', но так как > recursive_error_pages по-умолчанию выключена, error_page на этот раз не > срабатывает, и клиент получает 598. > > 25 июня 2015 г., 9:28 пользователь Иван Мишин > написал: > > в этом случае до винды этот код дойти не должен. если доходит - вы >>> плохо настроили error >> >> >> Ну судя по tcpdump на стороне винды, 598 код все же доходит до нее. >> >> про какой? про переход в именованный локейшн? или про то, что код, >>> который для этого используется, наружу отдаваться не должен? >> >> >> И про то и про другое, если не затруднит. >> ВО-первых, PROPFIND метод работает, при том что он организован в моем >> конфиге тем же способом что и метод DELETE с той лишь разницей что PROPFIND >> через 599 код работает, а DELETE через 598. Но я так понимаю что-это >> различие не на что не влияет ибо пробовал менять коды местами и...вот >> цитата моих слов по этому поводу: >> >>> 599 отрабатывает точно правильно потому что метод PROPFIND работает без >>> вопросов. В качестве экспиремента поменял местами 599 и 598 в >>> итоге PROPFIND как работал так и работает а DELETE каталогов как не работал >>> так и не работает. >> >> >> ВО-вторых, мне казалось что если с клиента ( в данном случае с винды) >> ушел запрос DELETE на nginx и nginx то nginx его должен отработать и >> каталог удалить, и не важно что он ответит клиент, потому что для клиента >> этот ответ будет чисто информационным т.е. не будет влиять на результат >> выполнения первого запроса (запроса на DELETE). >> >> >> 24 июня 2015 г., 18:55 пользователь Daniel Podolsky >> написал: >> >> > Даниель, можно подробнее пожалуйста про этот момент >>> про какой? про переход в именованный локейшн? или про то, что код, >>> который для этого используется, наружу отдаваться не должен? >>> _______________________________________________ >>> 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: -------------- next part -------------- ==> /var/log/nginx/webdav2_access.log <== 192.168.200.92 192.168.200.81 - [26/Jul/2015:14:48:06 +0300] "PROPFIND /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0%20(2)/desktop.ini HTTP/1.1" ="/Family/\xD0\x9D\xD0\xBE\xD0\xB2\xD0\xB0\xD1\x8F \xD0\xBF\xD0\xB0\xD0\xBF\xD0\xBA\xD0\xB0 (2)/desktop.ini"= 404 "text/html" 162 "-" "Microsoft-WebDAV-MiniRedir/6.3.9600" "-" 0.000 "-" NGINX-CACHE-- "-" 192.168.200.92 192.168.200.81 - [26/Jul/2015:14:48:08 +0300] "PROPFIND /Family HTTP/1.1" ="/Family"= 207 "-" 3340 "-" "Microsoft-WebDAV-MiniRedir/6.3.9600" "-" 0.000 "-" NGINX-CACHE-- "-" 192.168.200.92 192.168.200.81 - [26/Jul/2015:14:48:08 +0300] "PROPFIND /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0 HTTP/1.1" ="/Family/\xD0\x9D\xD0\xBE\xD0\xB2\xD0\xB0\xD1\x8F \xD0\xBF\xD0\xB0\xD0\xBF\xD0\xBA\xD0\xB0"= 207 "-" 731 "-" "Microsoft-WebDAV-MiniRedir/6.3.9600" "-" 0.000 "-" NGINX-CACHE-- "-" ==> /var/log/nginx/error.log <== 2015/07/26 14:48:08 [notice] 6735#0: *61 "^(.*[^/])$" matches "/Family/Новая папка", client: 192.168.200.81, server: 192.168.200.92, request: "MOVE /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0 HTTP/1.1", host: "192.168.200.92" 2015/07/26 14:48:08 [notice] 6735#0: *61 rewritten data: "/Family/Новая папка/", args: "", client: 192.168.200.81, server: 192.168.200.92, request: "MOVE /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0 HTTP/1.1", host: "192.168.200.92" 2015/07/26 14:48:08 [error] 6735#0: *61 both URI "/Family/Новая папка/" and "Destination" URI "http://192.168.200.92/Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0%20%282%29/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0" should be either collections or non-collections, client: 192.168.200.81, server: 192.168.200.92, request: "MOVE /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0 HTTP/1.1", host: "192.168.200.92" ==> /var/log/nginx/webdav2_access.log <== 192.168.200.92 192.168.200.81 - [26/Jul/2015:14:48:08 +0300] "MOVE /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0 HTTP/1.1" ="/Family/\xD0\x9D\xD0\xBE\xD0\xB2\xD0\xB0\xD1\x8F \xD0\xBF\xD0\xB0\xD0\xBF\xD0\xBA\xD0\xB0/"= 409 "text/html" 160 "-" "Microsoft-WebDAV-MiniRedir/6.3.9600" "-" 0.000 "-" NGINX-CACHE-- "-" 192.168.200.92 192.168.200.81 - [26/Jul/2015:14:48:08 +0300] "PROPFIND /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0 HTTP/1.1" ="/Family/\xD0\x9D\xD0\xBE\xD0\xB2\xD0\xB0\xD1\x8F \xD0\xBF\xD0\xB0\xD0\xBF\xD0\xBA\xD0\xB0"= 207 "-" 731 "-" "Microsoft-WebDAV-MiniRedir/6.3.9600" "-" 0.000 "-" NGINX-CACHE-- "-" 192.168.200.92 192.168.200.81 - [26/Jul/2015:14:48:08 +0300] "PROPFIND /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0/desktop.ini HTTP/1.1" ="/Family/\xD0\x9D\xD0\xBE\xD0\xB2\xD0\xB0\xD1\x8F \xD0\xBF\xD0\xB0\xD0\xBF\xD0\xBA\xD0\xB0/desktop.ini"= 404 "text/html" 162 "-" "Microsoft-WebDAV-MiniRedir/6.3.9600" "-" 0.000 "-" NGINX-CACHE-- "-" From nginx-forum at nginx.us Thu Jun 25 21:32:37 2015 From: nginx-forum at nginx.us (S.A.N) Date: Thu, 25 Jun 2015 17:32:37 -0400 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpIHBhcmFt?= In-Reply-To: <558AEFD2.2020309@csdoc.com> References: <558AEFD2.2020309@csdoc.com> Message-ID: <7d02630d0ea8119cbac739821efd8af6.NginxMailingListRussian@forum.nginx.org> Почитал статью про thread pools в Nginx, появилась надежда что когда-то появится Nginx модуль РНР, который будет обрабатывать запросы к РНР скриптам внутри процеса Nginx (без блокировки, каждый скрипт использует свободный thread из пула), тогда про отличия FastCGI и http_proxy можно будет забыть. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259814,259893#msg-259893 From vbart at nginx.com Fri Jun 26 13:32:10 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 26 Jun 2015 16:32:10 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpIHBhcmFt?= In-Reply-To: <7d02630d0ea8119cbac739821efd8af6.NginxMailingListRussian@forum.nginx.org> References: <558AEFD2.2020309@csdoc.com> <7d02630d0ea8119cbac739821efd8af6.NginxMailingListRussian@forum.nginx.org> Message-ID: <2171005.e3plqiHlfx@vbart-workstation> On Thursday 25 June 2015 17:32:37 S.A.N wrote: > Почитал статью про thread pools в Nginx, появилась надежда что когда-то > появится Nginx модуль РНР, который будет обрабатывать запросы к РНР скриптам > внутри процеса Nginx (без блокировки, каждый скрипт использует свободный > thread из пула), тогда про отличия FastCGI и http_proxy можно будет забыть. > Начать тут нужно с того, что php не thread safe и может безопасно исполняться только в отдельных процессах. Пулы потоков ему ни чем не помогут. Проще забыть про php, как про страшный сон. ;) -- Валентин Бартенев From kulmaks at gmail.com Fri Jun 26 13:43:15 2015 From: kulmaks at gmail.com (Maksim Kulik) Date: Fri, 26 Jun 2015 16:43:15 +0300 Subject: sendfile (/path/to/file) returned busy again while sending response to client Message-ID: Здравствуйте! Стал замечать в логах много ошибок типа: sendfile (/path/to/file) returned busy again while sending response to client На уровне http есть настройки: sendfile on; aio on; tcp_nopush on; tcp_nodelay on; postpone_output 0; OS: FreeBSD 9.2, nginx 1.9.2 Чем это все грозит и надо ли по этому поводу что-то делать? Может имеет смысл отключить sendfile? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Fri Jun 26 13:47:52 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 26 Jun 2015 16:47:52 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: References: Message-ID: <8158104.hsOHloIE1N@vbart-workstation> On Thursday 25 June 2015 02:04:33 Amanda Sproule wrote: > >>Очень странная это feature, она больше похожа на bug > >>Есть ли шансы, что этот bug будет исправлен в nginx? > > > Я об этом же, и nginx игнорирует предыдущие fastcgi_param если в локейшене > переопределить новый fastcgi_param. > > И поэтому в моём случае PHP-FPM отвечал пустым ответом, так как ему > передавался только fastcgi_param SCRIPT_FILENAME /www/info.php; > А минимальный набор fastcgi_param: > > fastcgi_param REQUEST_METHOD $request_method; > > fastcgi_param SCRIPT_FILENAME /www/info.php; > > как я и указал в топике. > > И передачу этих параметров легко можно просмотреть в phpinfo(), что и > подтвердило мою мысль. И никак такое поведение нельзя назвать механизмом > наследования. > > > >>Например, "аналогичная" по своей сути директива proxy_set_header > > >>переопределяет существующее значение, а не добавляет еще один header. > > И в ней такие же проблемы (фичи) недавно столкнулся када на уровне http > прописал параметры от модуля http_realip_module. > > В локейшене где происходил proxy_pass прописал proxy_set_header и модуль > realip уже не передавал свои заголовки (в логах светился не айпи клиента, а > самого сервера). > > И опять таки про proxy_set_header в документации написано > > """ > Директивы наследуются с предыдущего уровня при условии, что на данном > уровне не описаны свои директивы proxy_set_header. По умолчанию > переопределяются только два поля: > > proxy_set_header Host $proxy_host; > proxy_set_header Connection close; > > """ > > Спасибо. Хотелось бы услышть мнение разработчиков. > Мнение было изложено много раз, стоит сходить все же по ссылкам, что были приведены в первом же сообщении: http://mailman.nginx.org/pipermail/nginx-ru/2015-June/056217.html Проблема она в головах. Правила наследования предельно просты: директивы наследуются с предыдущего уровня только если не заданы на текущем. Это позволяет делать конфигурацию явной, простой, понятной с одного взгляда, избегая всевозможных сложных мерджей и сайд-эффектов. Когда у вас понаследовалось все с множества уровней и непонятно, какая же в итоге конфигурация применяется, пока не пробежишься по всем конфигам внимательно и не отследишь все значения на всех уровнях. В итоге такое невозможно поддерживать, когда конфигурация разрастается до огромных объемов. Эти правила были выработаны на горьком опыте. По сравнению с этим, проблему непонимания можно исправить, для этого нужно почитать документацию и ознакомиться с правилами. -- Валентин Бартенев From nginx-forum at nginx.us Fri Jun 26 13:50:49 2015 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 26 Jun 2015 09:50:49 -0400 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpIHBhcmFt?= In-Reply-To: <2171005.e3plqiHlfx@vbart-workstation> References: <2171005.e3plqiHlfx@vbart-workstation> Message-ID: > Начать тут нужно с того, что php не thread safe и может безопасно > исполняться > только в отдельных процессах. Пулы потоков ему ни чем не помогут. В РНР есть модификация - ZTS (Zend Thread Safety), но там тоже конечно не все так хорошо. > Проще забыть про php, как про страшный сон. ;) Мы не ищем простых путей ) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259814,259903#msg-259903 From vbart at nginx.com Fri Jun 26 13:52:27 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 26 Jun 2015 16:52:27 +0300 Subject: sendfile (/path/to/file) returned busy again while sending response to client In-Reply-To: References: Message-ID: <2355834.DgYtA2vaBl@vbart-workstation> On Friday 26 June 2015 16:43:15 Maksim Kulik wrote: > Здравствуйте! > Стал замечать в логах много ошибок типа: > sendfile (/path/to/file) returned busy again while sending response to > client > > На уровне http есть настройки: > sendfile on; > aio on; > tcp_nopush on; > tcp_nodelay on; > postpone_output 0; > > OS: FreeBSD 9.2, nginx 1.9.2 > > Чем это все грозит и надо ли по этому поводу что-то делать? Может имеет > смысл отключить sendfile? > А какой у вас объем оперативной памяти приходится на кэш странниц и какой объем данных раздаете? Предупреждения указывают на то, что закешированные с помощью aio операции данные вымываются из кэша до того, как рабочий процесс успевает позвать sendfile(). -- Валентин Бартенев From kulmaks at gmail.com Fri Jun 26 14:09:28 2015 From: kulmaks at gmail.com (Maksim Kulik) Date: Fri, 26 Jun 2015 17:09:28 +0300 Subject: sendfile (/path/to/file) returned busy again while sending response to client In-Reply-To: <2355834.DgYtA2vaBl@vbart-workstation> References: <2355834.DgYtA2vaBl@vbart-workstation> Message-ID: Объем всех сайтов - около 80 Гб, процентов 70 из этих данных потенциально раздаются. Общий объем памяти на сервере - 12 Гб. Под памятью на кэш страниц вы подразумеваете кэш страниц файловой системы? Если да, то он колеблется в районе 2 Гб, файловая система - ZFS. Если данные успевают вымываться и это происходит часто, может имеет смысл отключить aio? Или есть еще какие-нибудь рекомендации? Насколько я понимаю, время ответа сервера при такой ошибке возрастает? Это предупреждение появилось в новых версиях nginx или это связано с ростом нагрузки? Объем памяти в ближайшее время увеличить вряд ли получится, объем данных уменьшить - тоже. 26 июня 2015 г., 16:52 пользователь Валентин Бартенев написал: > On Friday 26 June 2015 16:43:15 Maksim Kulik wrote: > > Здравствуйте! > > Стал замечать в логах много ошибок типа: > > sendfile (/path/to/file) returned busy again while sending response to > > client > > > > На уровне http есть настройки: > > sendfile on; > > aio on; > > tcp_nopush on; > > tcp_nodelay on; > > postpone_output 0; > > > > OS: FreeBSD 9.2, nginx 1.9.2 > > > > Чем это все грозит и надо ли по этому поводу что-то делать? Может имеет > > смысл отключить sendfile? > > > > А какой у вас объем оперативной памяти приходится на кэш странниц и какой > объем данных раздаете? Предупреждения указывают на то, что закешированные > с помощью aio операции данные вымываются из кэша до того, как рабочий > процесс успевает позвать sendfile(). > > -- > Валентин Бартенев > _______________________________________________ > 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 vbart at nginx.com Fri Jun 26 14:49:10 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 26 Jun 2015 17:49:10 +0300 Subject: sendfile (/path/to/file) returned busy again while sending response to client In-Reply-To: References: <2355834.DgYtA2vaBl@vbart-workstation> Message-ID: <3840621.AaOR52KExB@vbart-workstation> On Friday 26 June 2015 17:09:28 Maksim Kulik wrote: > Объем всех сайтов - около 80 Гб, процентов 70 из этих данных потенциально > раздаются. Общий объем памяти на сервере - 12 Гб. Под памятью на кэш > страниц вы подразумеваете кэш страниц файловой системы? Если да, то он > колеблется в районе 2 Гб, файловая система - ZFS. > Если данные успевают вымываться и это происходит часто, может имеет смысл > отключить aio? Или есть еще какие-нибудь рекомендации? Насколько я понимаю, > время ответа сервера при такой ошибке возрастает? Это предупреждение > появилось в новых версиях nginx или это связано с ростом нагрузки? > > Объем памяти в ближайшее время увеличить вряд ли получится, объем данных > уменьшить - тоже. > Предупреждение было всегда, но раньше sendfile с aio-предзагрузкой включался отдельной опцией: aio sendfile, а начиная с 1.7.11 достаточно aio on. -- Валентин Бартенев From kulmaks at gmail.com Fri Jun 26 15:04:07 2015 From: kulmaks at gmail.com (Maksim Kulik) Date: Fri, 26 Jun 2015 18:04:07 +0300 Subject: sendfile (/path/to/file) returned busy again while sending response to client In-Reply-To: <3840621.AaOR52KExB@vbart-workstation> References: <2355834.DgYtA2vaBl@vbart-workstation> <3840621.AaOR52KExB@vbart-workstation> Message-ID: Понятно. Насколько я понимаю, после этого предупреждения данные вычитываются заново и опять вызывается sendfile? Имеет ли смысл отключить sendfile или aio для снижения нагрузки на диски? 26 июня 2015 г., 17:49 пользователь Валентин Бартенев написал: > > > Предупреждение было всегда, но раньше sendfile с aio-предзагрузкой > включался > отдельной опцией: aio sendfile, а начиная с 1.7.11 достаточно aio on. > > -- > Валентин Бартенев > _______________________________________________ > 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 vbart at nginx.com Fri Jun 26 15:27:29 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 26 Jun 2015 18:27:29 +0300 Subject: sendfile (/path/to/file) returned busy again while sending response to client In-Reply-To: References: <3840621.AaOR52KExB@vbart-workstation> Message-ID: <5056827.sgyUQQbDjM@vbart-workstation> On Friday 26 June 2015 18:04:07 Maksim Kulik wrote: > Понятно. > Насколько я понимаю, после этого предупреждения данные вычитываются заново > и опять вызывается sendfile? Имеет ли смысл отключить sendfile или aio для > снижения нагрузки на диски? > [..] После этого предупреждения sendfile читает в блокирующемся режиме, без aio. Возможно имеет смысл попробовать выключить sendfile. Возможно zfs нуждается в настройке, но по этому вопросу не могу ничего подсказать. -- Валентин Бартенев From maxim at nginx.com Fri Jun 26 15:33:36 2015 From: maxim at nginx.com (Maxim Konovalov) Date: Fri, 26 Jun 2015 18:33:36 +0300 Subject: sendfile (/path/to/file) returned busy again while sending response to client In-Reply-To: References: <2355834.DgYtA2vaBl@vbart-workstation> <3840621.AaOR52KExB@vbart-workstation> Message-ID: <558D70D0.1080101@nginx.com> Максим, On 6/26/15 6:04 PM, Maksim Kulik wrote: > Понятно. > Насколько я понимаю, после этого предупреждения данные вычитываются > заново и опять вызывается sendfile? Имеет ли смысл отключить > sendfile или aio для снижения нагрузки на диски? > sendfile(2) на zfs -- не самое удачное сочетание. Возможно, есть смысл посмотреть доклад Вячеслава Ольховченкова с прошлой ruBSD: https://events.yandex.ru/lib/talks/2694/ -- Maxim Konovalov http://nginx.com From paranoidchaos at gmail.com Fri Jun 26 16:10:37 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Fri, 26 Jun 2015 21:10:37 +0500 Subject: =?UTF-8?B?UmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFzdGNnaV9wYXJhbQ==?= Message-ID: >>Правила наследования предельно просты: директивы наследуются с предыдущего уровня >>только если не заданы на текущем. Это позволяет делать конфигурацию явной, простой, >>понятной с одного взгляда, избегая всевозможных сложных мерджей и сайд-эффектов. Вот именно предельно просты, в нджинксе наследование дефолтовое. В ООП с наследованием жёстко связано и переопределение, а в нджинксе его нет. Сам по себе fastcgi_param это многозначный параметр, и если в каком-то локейшене, грубо говоря, переопределили один из таких параметров это не должно влиять на остальные параметры, и причём тут мерджи ? Локейшен это последняя точка где применяются все правила наследования. В случае с нджинксом он перезатирает все предыдущие и устанавливает новые. Суть многозначеного параметра при этом теряется и никакго мерджа там нет. приведу тупой псевдо пример как логически я это вижу, учитывая сущности наследования. server { # проинклудили fastcgi_parms и получили массив значений fastcgi_params_server_ctx # массив в контексте server { SCRIPT_FILENAME => /www/info.php, REQUEST_METHOD => $request_method, ....... ....... ...... etc } # Определяем локейшен location /info { fastcgi_params_location_ctx // масив в контексте location { SCRIPT_FILENAME => /www/info_overloaded.php, } # В этой точке уже будет порисходить мердж двух массивов, банальный аппенд одного массива в другой с учётом перезаписи значений существующих ключей в родительском массиве (fastcgi_params_server_ctx), несуществующих - добавление. fastcgi_params_location_ctx = fastcgi_params_server_ctx (merge) fastcgi_params_location_ctx { SCRIPT_FILENAME => /www/info_overloaded.php, // переопределился параметр, а остальные остались не тронутыми REQUEST_METHOD => $request_method, ....... ....... ...... etc } fastcgi_pass 127.0.0.1:9000; # Разве сложно смерджить ? разве это не логичное поведение наследования с возможностью расширения или перезаписи? # На данный момент в нджинксе нет понятия наследования конфигурации, только понятие дефолтового значения, или переопределение однозначных параметров (параметров которые в одном и том же контексте должны встречаться один раз). } } >>избегая всевозможных сложных мерджей и сайд-эффектов. какой может быть сайд -эффект от слияния двух массивов ? Локейшен - последняя точка, контексты у всех свои. >>Когда у вас понаследовалось все с множества уровней и непонятно, какая же в итоге >>конфигурация применяется, пока не пробежишься по всем конфигам внимательно и не >>отследишь все значения на всех уровнях. что не понятно ? контексты разные где может быть путаница ? main_ctx -> http_ctx -> server_ctx -> location_ctx { inner_location_ctx } (if ваще нужно удалить к чертям, вот оно и создаёт сайд-эффекты) у каждого параметра есть строгие условия контекста использования. и наследование точно также происходит сверху-вниз. Вы же никогда не опишите location в контексте http. учитывая это всё, никаких конфликтов при слиянии быть не может и так и есть, просто наследование работает не так как хочется. >>Эти правила были выработаны на горьком опыте. По сравнению с этим, проблему >>непонимания можно исправить, для этого нужно почитать документацию и ознакомиться с правилами. На чьём горьком опыты ? на опыте разработчиков, которые хотят видеть продукт таким каким самим хочется, или опыте пользователей которые его используют ? Читать документацию ? - прочитал и привёл отрывок из неё, и там явно описано, и то что там описано не сходится с понятием наследования, и логично было бы пересмотреть механизм наследования многозначных параметров. Спасибо. -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Fri Jun 26 17:06:04 2015 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 26 Jun 2015 20:06:04 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: References: Message-ID: <837381435338364@web20o.yandex.ru> 26.06.2015, 19:10, "Amanda Sproule" : >>>Правила наследования предельно просты: директивы наследуются с предыдущего уровня >>>только если не заданы на текущем.  Это позволяет делать конфигурацию явной, простой, >>>понятной с одного взгляда, избегая всевозможных сложных мерджей и сайд-эффектов. > > Вот именно предельно просты, в нджинксе наследование дефолтовое. В ООП с наследованием жёстко связано и переопределение, а в нджинксе его нет. ООП к конфигурации nginx отношение имеет чуть менее, чем никакое. > Сам по себе fastcgi_param это многозначный параметр, и если в каком-то локейшене, грубо говоря, переопределили один из таких параметров это не должно влиять на остальные параметры, и причём тут мерджи ? Локейшен это последняя точка где применяются  все правила наследования. В случае с нджинксом он перезатирает все предыдущие и устанавливает новые. Суть многозначеного параметра при этом теряется и никакго мерджа там нет. > > приведу тупой псевдо пример как логически я это вижу, учитывая сущности наследования. > > server { > >    # проинклудили fastcgi_parms и получили массив значений >   fastcgi_params_server_ctx # массив в контексте server >   { >         SCRIPT_FILENAME => /www/info.php, >         REQUEST_METHOD => $request_method, >         ....... >         ....... >         ...... etc >   } > >   # Определяем локейшен >   location /info { >       fastcgi_params_location_ctx // масив в контексте location >       { >         SCRIPT_FILENAME => /www/info_overloaded.php, >       } > >       # В этой точке уже будет порисходить мердж двух массивов, банальный аппенд одного массива в другой с учётом перезаписи значений существующих ключей в родительском массиве (fastcgi_params_server_ctx), несуществующих - добавление. > >       fastcgi_params_location_ctx = fastcgi_params_server_ctx (merge) fastcgi_params_location_ctx >       { >           SCRIPT_FILENAME => /www/info_overloaded.php, // переопределился параметр, а остальные остались не тронутыми >         REQUEST_METHOD => $request_method, >         ....... >         ....... >         ...... etc >       } > >       fastcgi_pass 127.0.0.1:9000; > >       # Разве сложно смерджить ? разве это не логичное поведение наследования с возможностью расширения или перезаписи? >       # На данный момент в нджинксе нет понятия наследования конфигурации, только понятие дефолтового значения, или переопределение однозначных параметров (параметров которые в одном и том же контексте должны встречаться один раз). > >   } > } > >>>избегая всевозможных сложных мерджей и сайд-эффектов. > > какой может быть сайд -эффект от слияния двух массивов ? Локейшен - последняя точка, контексты у всех свои. > >>>Когда у вас понаследовалось все с множества уровней и непонятно, какая же в итоге >>>конфигурация применяется, пока не пробежишься по всем конфигам внимательно и не >>>отследишь все значения на всех уровнях. > > что не понятно ? контексты разные где может быть путаница ? > main_ctx -> http_ctx -> server_ctx -> location_ctx { inner_location_ctx } (if ваще нужно удалить к чертям, вот оно и создаёт сайд-эффекты) > > у каждого параметра есть строгие условия контекста использования. и наследование точно также происходит сверху-вниз. Вы же никогда не опишите location в контексте http. учитывая это всё, никаких конфликтов при слиянии быть не может и так и есть, просто наследование работает не так как хочется. > >>>Эти правила были выработаны на горьком опыте.  По сравнению с этим, проблему >>>непонимания можно исправить, для этого нужно почитать документацию и ознакомиться с правилами. > > На чьём горьком опыты ? на опыте разработчиков, которые хотят видеть продукт таким каким самим хочется, или опыте пользователей которые его используют ? > Читать документацию ? - прочитал и привёл отрывок из неё, и там явно описано, и то что там описано не сходится с понятием наследования, и логично было бы пересмотреть механизм наследования многозначных параметров. > > Спасибо. > > , > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From paranoidchaos at gmail.com Fri Jun 26 17:38:05 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Fri, 26 Jun 2015 22:38:05 +0500 Subject: =?UTF-8?B?UmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFzdGNnaV9wYXJhbQ==?= Message-ID: >>ООП к конфигурации nginx отношение имеет чуть менее, чем никакое. утрируете! Оффтоп прошу отложить, отвечайте по сути, если есть аргументы - аргументируйте. Я уже привёл пример логичного поведения наследования конфигурации с уровня выше для многозначных параметров - использовать банальный array merge. Приведите пример сайд-эффекта или невозможности реализации такого поведения наследования в nginx. -------------- next part -------------- An HTML attachment was scrubbed... URL: From for.poige+nginx at gmail.com Fri Jun 26 17:38:36 2015 From: for.poige+nginx at gmail.com (Igor M Podlesny) Date: Sat, 27 Jun 2015 00:38:36 +0700 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= Message-ID: 2015-06-27 0:06 GMT+07:00 Konstantin Tokarev : > ООП к конфигурации nginx отношение имеет чуть менее, чем никакое. > ООП это один из способов организации кода/данных. Один из основных принципов ООП -- "наследование". Конфиги Nginx это тоже один из способов организации данных и задания логики, и им тоже присуще "наследование", как концепция. (Так что если это называть "никаким" отношением, то это ни-"чуть менее", чем глупо). В определённых местах конфигурации Nginx, это наследование _неожиданно_ ломается. Людям это не нравится. Авторы (и, к ним примкнувшие), от проблемы отмахиваются, дескать, она, как и разруха, "в головах". Им бы понимать, что головы бывают разные, и вряд ли их собственная голова хранится в Парижской палате мер и весов в качестве эталона. Впрочем, это было бы вдвойне печально. ;) -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From kulmaks at gmail.com Fri Jun 26 18:16:33 2015 From: kulmaks at gmail.com (Maksim Kulik) Date: Fri, 26 Jun 2015 21:16:33 +0300 Subject: sendfile (/path/to/file) returned busy again while sending response to client In-Reply-To: <558D70D0.1080101@nginx.com> References: <2355834.DgYtA2vaBl@vbart-workstation> <3840621.AaOR52KExB@vbart-workstation> <558D70D0.1080101@nginx.com> Message-ID: Раньше не задумывался о правильность использования sendfile на zfs. Посмотрел доклад, погуглил по данному вопросу и выключил sendfile. Спасибо за помощь! 26 июня 2015 г., 18:33 пользователь Maxim Konovalov написал: > Максим, > > On 6/26/15 6:04 PM, Maksim Kulik wrote: > > Понятно. > > Насколько я понимаю, после этого предупреждения данные вычитываются > > заново и опять вызывается sendfile? Имеет ли смысл отключить > > sendfile или aio для снижения нагрузки на диски? > > > sendfile(2) на zfs -- не самое удачное сочетание. > > Возможно, есть смысл посмотреть доклад Вячеслава Ольховченкова с > прошлой ruBSD: https://events.yandex.ru/lib/talks/2694/ > > -- > Maxim Konovalov > http://nginx.com > > _______________________________________________ > 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 gmm at csdoc.com Fri Jun 26 18:21:05 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 26 Jun 2015 21:21:05 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: References: Message-ID: <558D9811.7040906@csdoc.com> On 26.06.2015 20:38, Igor M Podlesny wrote: > ООП это один из способов организации кода/данных. > Один из основных принципов ООП -- "наследование". Наследование - это не принцип, а механизм. Причем, механизм настолько проблемный, что в Go от него решили полностю отказаться, а в Java рекомендуют им вообще не пользоваться без крайней на то необходимости: https://www.youtube.com/embed/G6LJkWwZGuc?rel=0&start=587&end=1062&autoplay=1 > Конфиги Nginx это тоже один из способов организации данных > и задания логики, и им тоже присуще "наследование", как концепция. А также присущи и все те проблемы, которые есть у наследования в ООП: https://events.yandex.ru/lib/talks/2392/ Масштабируемая конфигурация nginx (RUS) https://www.youtube.com/watch?v=YWRYbLKsS0I Scaleable NGINX Configuration (ENG) http://www.slideshare.net/profyclub_ru/nginx-nginx Масштабируемая конфигурация nginx (слайды) > В определённых местах конфигурации Nginx, > это наследование _неожиданно_ ломается. > Людям это не нравится. Авторы (и, к ним примкнувшие), от проблемы > отмахиваются, дескать, она, как и разруха, "в головах". > Им бы понимать, что головы бывают разные, и вряд ли их собственная > голова хранится в Парижской палате мер и весов в качестве эталона. Используйте Apache, он работает в плане наследования директив конфигурации именно так, как Вы и ожидаете. Или - сделайте свой собственный веб-сервер, который будет полностью соответствовать Вашим ожиданиям и требованиям. Можно даже в виде DSL препроцессора конфигурации для nginx, который будет читать конфиг nginx в Вашем собственном формате (другие правила наследования) и писать его в raw формате nginx. Приходить в список рассылки и рассказывать авторам о том, что они не умеют писать программы - это контрпродуктивно. -- Best regards, Gena From paranoidchaos at gmail.com Fri Jun 26 18:35:17 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Fri, 26 Jun 2015 23:35:17 +0500 Subject: =?UTF-8?B?UmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFzdGNnaV9wYXJhbQ==?= Message-ID: >>Причем, механизм настолько проблемный, что в Go >>от него решили полностю отказаться, а в Java рекомендуют >>им вообще не пользоваться без крайней на то необходимости: Вся проблема наследования в ООП в том, что существуют всякие конструкторы и деструкторы. И наследование в контексте nginx подразумевается не с программерской точки зрения (наследование классов в ООП), а с точки зрения фундаментального понятия - не дублировать (сама природа так устроена - генетическое наследование к примеру :)). Какой сайд-эффект от мерджа двух массивов, от параметров которые на логику поведения самого нджинкса вообще не влияют ? >>Приходить в список рассылки и рассказывать авторам о том, >>что они не умеют писать программы - это контрпродуктивно. Никто не учит никого, список рассылки на то и создавался, чтобы разработчики услышали мнения пользователей. И намерения тех кто здесь пишет в том, чтобы улучшить этот проект, сделать какой-то вклад в улучшение. С такой же упёртостью я бы и в рассылках апача учавствовал бы, если бы он мне не был бы безразличен. Если разработчики или модераторы считают сей топик провокационным, не нужным или ещё хуже холиварным - прошу его немедля удалить. Всем спасибо за дисскуссию. -------------- next part -------------- An HTML attachment was scrubbed... URL: From for.poige+nginx at gmail.com Fri Jun 26 18:41:40 2015 From: for.poige+nginx at gmail.com (Igor M Podlesny) Date: Sat, 27 Jun 2015 01:41:40 +0700 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: <558D9811.7040906@csdoc.com> References: <558D9811.7040906@csdoc.com> Message-ID: 2015-06-27 1:21 GMT+07:00 Gena Makhomed : > Приходить в список рассылки и рассказывать авторам о том, > что они не умеют писать программы - это контрпродуктивно. > Клевета. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmm at csdoc.com Fri Jun 26 19:19:05 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 26 Jun 2015 22:19:05 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: References: Message-ID: <558DA5A9.1060406@csdoc.com> On 26.06.2015 21:35, Amanda Sproule wrote: > Вся проблема наследования в ООП в том, > что существуют всякие конструкторы и деструкторы. Конструкторы - всегда статические и к наследованию они не имеют никакого отношения. Деструкторов, например, в Java - вообще нет. О проблемах вызванных наследованием очень доступно рассказывается в том видео, ссылку на которое я приводил в предыдущем сообщении. > Какой сайд-эффект от мерджа двух массивов, от параметров которые на > логику поведения самого нджинкса вообще не влияют ? На этот вопрос Вам уже ответили несколько раз. > И намерения тех кто здесь пишет в том, чтобы > улучшить этот проект, сделать какой-то вклад в улучшение. Прежде чем что-то пытаться улучшать - имеет смысл сначала понять, почему это было реализовано именно так, а не иначе. > Если разработчики или модераторы считают сей топик провокационным, > не нужным или ещё хуже холиварным - прошу его немедля удалить. Это список рассылки, а не форум. > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Gena From paranoidchaos at gmail.com Fri Jun 26 20:05:00 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Sat, 27 Jun 2015 01:05:00 +0500 Subject: =?UTF-8?B?UmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFzdGNnaV9wYXJhbQ==?= Message-ID: >>Конструкторы - всегда статические и к наследованию они не имеют никакого отношения. Деструкторов, например, в Java - вообще нет. О проблемах вызванных наследованием очень доступно >>рассказывается в том видео, ссылку на которое я приводил в предыдущем сообщении. Опять утрируете, я не хочу начинать разговор об ООП и как оно реализовано в различных языках. А наследование в свою очередь является фундаментальным аспектом ООП. И речь идёт о самой сущности наследования. Сам Игорь в видео говорит об копипасте, и в тоже время реализовано наследование конфигурации которое должно избавить от копипаста - неоднозначность. Сводится всё к тому, что если есть какая-либо строгая иерархия (main_ctx -> http_ctx -> server_ctx -> location_ctx -> (inner_location_ctx)), то и свойственно быть наследованию для избавления от копипаста. И речь идёт о многозначном параметре как fastcgi_param (определённым уровнем выше - parent), который по законам наследования не должен затираться, а сливаться с дочерним контекстом. >>На этот вопрос Вам уже ответили несколько раз. Ни одного аргументированного ответа не увидел, кроме всяких неаргументированных сайд-эффектов. Каких сайд-эффектов от слияния двух массивов (рассматривается fastcgi_param)? >>Прежде чем что-то пытаться улучшать - имеет смысл сначала >>понять, почему это было реализовано именно так, а не иначе. Согласен, приведите аргументы к выше указанному вопросу и на этом закончим разговор. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmm at csdoc.com Fri Jun 26 20:24:41 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 26 Jun 2015 23:24:41 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: References: Message-ID: <558DB509.5060107@csdoc.com> On 26.06.2015 23:05, Amanda Sproule wrote: > А наследование в свою очередь является фундаментальным аспектом ООП. ...и имеет большое количество проблем, поэтому является нежелательным. Кстати, конфиги nginx не являются языком программирования, - так что при чем тут аспекты ООП - совершенно не понятно. > Каких сайд-эффектов от слияния двух массивов > (рассматривается fastcgi_param)? http://mailman.nginx.org/pipermail/nginx-ru/2011-November/044461.html -- Best regards, Gena From for.poige+nginx at gmail.com Fri Jun 26 20:38:39 2015 From: for.poige+nginx at gmail.com (Igor M Podlesny) Date: Sat, 27 Jun 2015 03:38:39 +0700 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: <558DB509.5060107@csdoc.com> References: <558DB509.5060107@csdoc.com> Message-ID: 2015-06-27 3:24 GMT+07:00 Gena Makhomed : > Каких сайд-эффектов от слияния двух массивов >> (рассматривается fastcgi_param)? >> > > http://mailman.nginx.org/pipermail/nginx-ru/2011-November/044461.html Ну так и где там side effect? Там "мне почему-то _кажется_", так что мне даже интересно становится -- как долго ещё будет "казаться", если люди прямо говорят, что поведение кривое, и неожиданное. Вообще, конечно, "DRY -- миф", это "сильно". Прям "в граните отливается". На самом деле, понятно, что пищать в чатиках-форумах-рассылках можно долго, ибо Nginx давно уже приносит прибыль, и эта модель её извлечения хоть лобзиком, хоть квадратно-гнёздами, от бесплатного писка сориентирована давно, и устойчиво. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From paranoidchaos at gmail.com Fri Jun 26 20:43:14 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Sat, 27 Jun 2015 01:43:14 +0500 Subject: =?UTF-8?B?UmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFzdGNnaV9wYXJhbQ==?= Message-ID: >>...и имеет большое количество проблем, поэтому является нежелательным. без коментариев. >>Кстати, конфиги nginx не являются языком программирования, >>- так что при чем тут аспекты ООП - совершенно не понятно. Спасибо КЭП. Я противник всякого программирования в конфиге, и всякого встраивания перла, луа, и еще джаваскрипта )))))))))) через лет 5 нджинкс станет таким же как апач. >>don't repeat yourself / copy and paste programming >>Мне почему-то кажется, что 99% админов, настраивающих >>nginx, не хотят выпиливать лобзиком. Им нужно сделать это по-быстрее, >>затратив минимум мозговых усилий. Я имеено из тех кто выпиливает лобзиком ещё и шкуркой проходится. >>Собственно, это видно уже по началу >>настройки - а давайте-ка всё, чего у нас нет, будет обрабатывать /index.php, >>а сам /index.php будет обрабатывать ~\.php$. Причём лучше, чтобы >>так было для всех сайтов, а то неохота возиться. Причиной сему - дурной пример из документации который так и не выпилили, как и не выпилили слово "наследование". location ~ \.php$ { } Я противник поведения catch-all. Мы говорим, что регулярки не нужны, но в то же время утверждаем, что есть ситуации когда они нужны - неоднозначность ? пс: вся причина этого бардака в том, что разрабы (их не так уж много и можно понять) заняты совсем другими задачами. А чем дальше всё это будет идти тем больше будет неоднозначностей и всяких костылей, а када объем кода дотянет до апаческого, то как и апач он забросится и никто этими мелкими проблемами заниматься не будет. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Jun 26 21:14:29 2015 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 26 Jun 2015 17:14:29 -0400 Subject: =?UTF-8?B?UmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFzdGNnaSBwYXJhbQ==?= In-Reply-To: References: Message-ID: <64193c9f20ffede0001ce9cb7e75e28b.NginxMailingListRussian@forum.nginx.org> > Согласен, приведите аргументы к выше указанному вопросу и на этом > закончим > разговор. Лучший аргументом может быть два примера решения вашей задачи, один с использованием наследования директив, второй вариант -копипаст который предлагают разработчики Nginx. Ваш вариант с наследованием мне и думаю многим очень нравится, он будет выглядит аккуратно без лишних букв, в лучших традициях декларативного программирования, это реально удобно и более логично, не буду судить и спорить почему этого нет в Nginx, попробую объяснить почему это вообще не важно. Любой красивый код компилируется в машинные инструкции, если посмотреть на эти инструкции, вы увидите там куча повторов одних и тех же инструкций там все так тупо и не красиво, просто капец, так вот конфиг Nginx это асамблер, он тупой императивный и без наследования, фишка в том что на конфиг смотреть не надо, сделайте генерацию конфига, на любом удобном для вас языке, тогда вы сможете красиво описывать все ваши алгоритмы, но на выходе будет генерироваться тупой некрасивый конфиг Nginx, все очень просто. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259814,259927#msg-259927 From gmm at csdoc.com Fri Jun 26 21:14:49 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Sat, 27 Jun 2015 00:14:49 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: References: Message-ID: <558DC0C9.2030702@csdoc.com> On 26.06.2015 23:43, Amanda Sproule wrote: >>> Мне почему-то кажется, что 99% админов, настраивающих nginx, >>> не хотят выпиливать лобзиком. Им нужно сделать это по-быстрее, >>> затратив минимум мозговых усилий. > Я имеено из тех кто выпиливает лобзиком ещё и шкуркой проходится. Большинство админов не хотят тратить много времени на отладку и сопровождение конфигурации веб-сервера. > вся причина этого бардака в том, что разрабы (их не так уж много и > можно понять) заняты совсем другими задачами. А чем дальше всё это будет > идти тем больше будет неоднозначностей и всяких костылей, а када объем > кода дотянет до апаческого, то как и апач он забросится и никто этими > мелкими проблемами заниматься не будет. Вот и сделайте свой веб-сервер, который через 10 лет вытеснит nginx, так же как сейчас nginx постепенно вытесняет Apache, lighttpd и т.п. P.S. Один финский студент когда-то создал с нуля свою собственную операционную систему, известную как Linux - при желании все возможно. -- Best regards, Gena From onokonem at gmail.com Fri Jun 26 21:17:08 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Sat, 27 Jun 2015 00:17:08 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: <558DC0C9.2030702@csdoc.com> References: <558DC0C9.2030702@csdoc.com> Message-ID: 2015-06-27 0:14 GMT+03:00 Gena Makhomed : > Один финский студент когда-то создал с нуля свою собственную > операционную систему, известную как Linux - при желании все возможно. только ядро. и получилось оно довольно странное. From paranoidchaos at gmail.com Fri Jun 26 21:45:11 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Sat, 27 Jun 2015 02:45:11 +0500 Subject: =?UTF-8?B?UmU6IFJlOiBSZTog0J3QsNGB0LvQtdC00L7QstCw0L3QuNC1IGZhc3RjZ2kgcGFy?= =?UTF-8?B?YW0=?= Message-ID: >>Лучший аргументом может быть два примера решения вашей задачи, один с использованием наследования директив, второй вариант -копипаст который предлагают разработчики Nginx. Ваш >>вариант с наследованием мне и думаю многим очень нравится, он будет выглядит аккуратно без лишних букв, в лучших традициях декларативного программирования, это реально удобно и >>более логично, не буду судить и спорить почему этого нет в Nginx, попробую объяснить почему это вообще не важно. Во-первых, хочу выразить благодарность за исчерпывающий и развёрнутый ответ. Во-вторых, я некоим образом не собирался никого судить и превращать тему в спор, наоборот мне не безразлично будущее проекта (хоть от меня ничего не зависит). На счёт наследования конфигурации - я сторонник конкретности, раз есть хоть какойто механизм облегчения труда и сопровождения конфига, который то и дело тока будет расти, почему бы и нет ? - почему бы не сделать нормально этот механизм наследования? К примеру таже самая директива include vhosts/*.conf - она судя "копипасту Игорева" вообще не входит ни в какие ворота. С одной стороны 99% все леньтяии, а с другой стороны вот вам лентяям костыль, сваренный в трёх частях. Почему так важны такие мелочи (синтаксический сахар) и почему вариант "копипаст Игорева" не работает объясню на собственном опыте. Мой текущий конфиг щас содержит свыше 400 server locations, и пилить каждый конфиг по методу копипаста не получится (посчитайте сколько времени уйдёт, чтобы проанализировать каждый сайт - выявить все возможные локейшены и прописать их, но по возможности конечно же так и делаю, и лишение этого "синтаксического сахара" в виде банального наследования (слияния) конфигурации убивает всесь тот кайф выпиливанием лобзиком конфига). >>Любой красивый код компилируется в машинные инструкции, если посмотреть на >>эти инструкции, вы увидите там куча повторов одних и тех же инструкций там >>все так тупо и не красиво, просто капец, так вот конфиг Nginx это асамблер, >>он тупой императивный и без наследования, фишка в том что на конфиг смотреть >>не надо, сделайте генерацию конфига, на любом удобном для вас языке, тогда >>вы сможете красиво описывать все ваши алгоритмы, но на выходе будет >>генерироваться тупой некрасивый конфиг Nginx, все очень просто. вот в асм всё именно и красиво ) на счёт генератора, да пилю для себя гуйный конфигуратор. Спасибо. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paranoidchaos at gmail.com Fri Jun 26 21:48:22 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Sat, 27 Jun 2015 02:48:22 +0500 Subject: =?UTF-8?B?UmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFzdGNnaV9wYXJhbQ==?= Message-ID: >>P.S. Один финский студент когда-то создал с нуля свою собственную операционную систему, известную как Linux - при желании все возможно. Походу "синдром Линуса" наступает. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paranoidchaos at gmail.com Fri Jun 26 21:50:54 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Sat, 27 Jun 2015 02:50:54 +0500 Subject: =?UTF-8?B?UmU6IFJlOiBSZTog0J3QsNGB0LvQtdC00L7QstCw0L3QuNC1IGZhc3RjZ2kgcGFy?= =?UTF-8?B?YW0=?= Message-ID: Сорри, чёт гмейл неправильно обрабатывает ссылку mailto, не в ту ветку сообщение прицепилось. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jd at jdwuzhere.ru Fri Jun 26 22:15:29 2015 From: jd at jdwuzhere.ru (jd at jdwuzhere.ru) Date: Sat, 27 Jun 2015 01:15:29 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpIHBhcmFt?= In-Reply-To: References: Message-ID: <6CB1C1E5-2388-448A-AEEC-D67986F990A9@jdwuzhere.ru> Дяденьки, давайте просто пойдем наружу и выпьем, ибо пятница? :) > On 27 июня 2015 г., at 0:50, Amanda Sproule wrote: > > Сорри, чёт гмейл неправильно обрабатывает ссылку mailto, не в ту ветку сообщение прицепилось. > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From onokonem at gmail.com Fri Jun 26 22:19:46 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Sat, 27 Jun 2015 01:19:46 +0300 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpIHBhcmFt?= In-Reply-To: <6CB1C1E5-2388-448A-AEEC-D67986F990A9@jdwuzhere.ru> References: <6CB1C1E5-2388-448A-AEEC-D67986F990A9@jdwuzhere.ru> Message-ID: > Дяденьки, давайте просто пойдем наружу и выпьем, ибо пятница? :) мы уже From paranoidchaos at gmail.com Fri Jun 26 22:21:31 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Sat, 27 Jun 2015 03:21:31 +0500 Subject: =?UTF-8?B?UmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFzdGNnaSBwYXJhbQ==?= Message-ID: >>Дяденьки, давайте просто пойдем наружу и выпьем, ибо пятница? :) У мня уже суббота, и три часа ночи :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From for.poige+nginx at gmail.com Sat Jun 27 05:24:04 2015 From: for.poige+nginx at gmail.com (Igor M Podlesny) Date: Sat, 27 Jun 2015 12:24:04 +0700 Subject: =?UTF-8?B?UmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFzdGNnaSBwYXJhbQ==?= In-Reply-To: <64193c9f20ffede0001ce9cb7e75e28b.NginxMailingListRussian@forum.nginx.org> References: <64193c9f20ffede0001ce9cb7e75e28b.NginxMailingListRussian@forum.nginx.org> Message-ID: 2015-06-27 4:14 GMT+07:00 S.A.N : > Любой красивый код компилируется в машинные инструкции, если посмотреть на > эти инструкции, вы увидите там куча повторов одних и тех же инструкций там > Да, расскажите мне, ога. Я писал в маш. кодах и на асме (можно сказать,что начинал с этого), и могу утверждать, что если у вас там куча повторов, то вы просто не знаете, зачем есть инструкция CALL. И качество кодогенерации компилятора -- важнейшая характеристика, если что. И если там будет "куча повторов одних и тех же инструкций", ваш компилятор выкинут на свалку ещё до того, как вы к нему goto прикрутите. > все так тупо и не красиво, просто капец, так вот конфиг Nginx это асамблер, > он тупой императивный и без наследования, фишка в том что на конфиг > смотреть > А я думал, что конфиг _декларативный_, а из _императивного_ там только if-is-evil. Кто из нас ошибается(?), мне интересно... O_o не надо, сделайте генерацию конфига, на любом удобном для вас языке, тогда > вы сможете красиво описывать все ваши алгоритмы, но на выходе будет > генерироваться тупой некрасивый конфиг Nginx, все очень просто. > "Спасибо, кэп!" (с) Только есть такой пр-цп -- "бритва Оккама", и лишние сущности не радостны. Можно навернуть, только это будет overkill, во многих случаях. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From for.poige+nginx at gmail.com Sat Jun 27 05:33:10 2015 From: for.poige+nginx at gmail.com (Igor M Podlesny) Date: Sat, 27 Jun 2015 12:33:10 +0700 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dpX3BhcmFt?= In-Reply-To: <558DC0C9.2030702@csdoc.com> References: <558DC0C9.2030702@csdoc.com> Message-ID: 2015-06-27 4:14 GMT+07:00 Gena Makhomed : > Большинство админов не хотят тратить много времени > на отладку и сопровождение конфигурации веб-сервера. > Meskimen's Law: "There's Never Time To Do It Right, But There's Always Time To Do It Over" -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangsamp at gmail.com Sat Jun 27 07:39:51 2015 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Sat, 27 Jun 2015 10:39:51 +0300 (EEST) Subject: =?UTF-8?B?UmU6IFJlOiBSZTog0J3QsNGB0LvQtdC00L7QstCw0L3QuNC1IGZhc3RjZ2kgcGFy?= =?UTF-8?B?YW0=?= In-Reply-To: References: Message-ID: Today Jun 27, 2015 at 02:45 Amanda Sproule wrote: > Мой текущий конфиг щас содержит свыше 400 server locations, и пилить каждый > конфиг по методу копипаста не получится (посчитайте сколько времени уйдёт, > чтобы проанализировать каждый сайт - выявить все возможные локейшены и > прописать их, но по возможности конечно же так и делаю, и лишение этого > "синтаксического сахара" в виде банального наследования (слияния) > конфигурации убивает всесь тот кайф выпиливанием лобзиком конфига). Наследование(inheritence) и слияние(merge) всё же разные механизмы. Наличие слияния требует ещё одной опции - очистки предыдущей конфигурации, а то мало-ли какое месиво выйдет. И даже с ней нашлись бы вопрошающие очистки только с определённых уровней. Без слияния же что задал на нужном уровне - именно то и будет работать. Не задал - получишь default или наследование с предыдущего. Вы с JunOS сталкивались? Там тоже есть блоки в конфигурации и наследование, но не слияние. -- WNGS-RIPE From nginx-forum at nginx.us Sat Jun 27 09:12:17 2015 From: nginx-forum at nginx.us (S.A.N) Date: Sat, 27 Jun 2015 05:12:17 -0400 Subject: =?UTF-8?B?UmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFzdGNnaSBwYXJhbQ==?= In-Reply-To: References: Message-ID: <9992bcba14c4e1bddec2d83369019d72.NginxMailingListRussian@forum.nginx.org> > А я думал, что конфиг _декларативный_, а из _императивного_ там > только > if-is-evil. Кто из нас ошибается(?), мне интересно... O_o Если бы конфиг Nginx, был декларативным, вместо директив были бы декларации :), наличия директив делает его императивным. Вы наверно воспринимаете конфиг как скрипт написанный на языке программирования, по этому удивлены почему там нет наследования. Я уже писал, мне нравится наследования, оно не создает проблем, им легко пользуются даже гуманитарии дизайнеры, пишут CSS классы, кстати даже CSS им кажется слишком низкоуровневым и они выдумали less и sass, по этому я предложил выдумать свой компилятор для конфигов Nginx, вы даже сможете там реализовать CALL или goto. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259814,259940#msg-259940 From paranoidchaos at gmail.com Sat Jun 27 09:16:08 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Sat, 27 Jun 2015 14:16:08 +0500 Subject: =?UTF-8?B?UmU6IFJlOiBSZTogUmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dp?= =?UTF-8?B?IHBhcmFt?= Message-ID: >>Наследование(inheritence) и слияние(merge) всё же разные механизмы. не разные >>очистки предыдущей конфигурации, очистка не требуется, так как есть и другие локейшены (дочернии директивы). >>Не задал - получишь default или наследование с предыдущего. Так это и есть слияние пустого локейшен массива с родительским - сути не меняет. Само понятие наследования неправильно трактуется када в дочернем определяется свой массив параметров и он же используется - это ни коим образом нельзя назвать наследованием. И термин слияния (merge) использовался лишь в значении псевдо кода который я приводил, там он требовался, чтобы реализовать сущность наследования параметров предков в дочернем. А как еще на примере двух массивов параметров произвести наследование от одного массива другим ? - думаю догадались - слиянием (merge). -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Jun 27 09:17:07 2015 From: nginx-forum at nginx.us (itcod) Date: Sat, 27 Jun 2015 05:17:07 -0400 Subject: =?UTF-8?B?TmdpbngrTHXQsD0g0J3QtdC80L3QvtC20LrQviDQvtCx0LvQsNGH0L3QviDRgSBX?= =?UTF-8?B?RUJEQVY=?= Message-ID: <7875fe266a403e004a176b23ca8c3c60.NginxMailingListRussian@forum.nginx.org> Добрый день уважаемые! Выставляю на Ваш суд свою поделку. Просьба сильно не пинать:) Конечно ещё сыровата... но я уже кушаю:))) Просто не нашёл аналогичного... может плохо искал.... вот и пришлось покодить немножко. Надеюсь полезная будет:) Сервис "ITCOD-DISK" Облачное хранилище. -- Copyright (c) 2015 by Yura Vdovytchenko (max at itcod.com) -- Copyright (c)itcod 2010-2015 -- version: 15.06.27 -- license: MIT Назначение: Сетевой диск(хранилище) файлов по технологии WEBDAV. С публикацией по http/https и индексный файл с контрольными суммами md5/etc. Предназначен для хранения и публикации NoSQL информационных массивов. Принцип: Сервис-ориентированная архитектура построения. Nginx обеспечивает стандартный протокол WEBDAV over HTTP/HTTPS. Lua-модули itcod обеспечивают расширение функций и сетевые сервисы управления ITCOD-DISK'ом. ITCOD UI WWII обеспечивает WEB-интерфейс между пользователем и сервисами. ОТЛИЧИЕ ОТ АНАЛОГОВ NoLAMP NoLEMP NoSQL SOA На сервере только Nginx + Lua и никаких PHP SQL и т.д. БАЗОВЫЕ КОМПОНЕНТЫ ITCOD-DISK LINUX - операционная система NGINX - http daemod (with WebDAV and Lua) LUA - язык программирования Resty - библиотека Lua add - дополнительные библиотеки (см. require в *.lua) ITCOD Lua Modules & Services - модули SOA ITCOD для операций с хранилищем ITCOD WWII - web-интерфейс для ITCOD-DISK (в разработке) БАЗОВЫЕ КОМПОНЕНТЫ ITCOD Lua Modules & Services auth-dav.lua - авторизатор для HTTP/HTTPS/WEBDAV md5index.lua - расширитель функций autoindex NGINX itcod-user.lua - создание пользовательских юзербоксов на диске WEBDAV itcod-exchange.lua - сервис транспорта файлов между пользователями и дисками itcod-search.lua - REST-сервис авторизованного поиска информации в закрытых пользовательских массивах libs/ - библиотека иконок типов файлов для md5index Подробнее о компанентах см. https://ihome.itcod.com/max/project/ КОНФИГУРАЦИЯ NGINX nginx version: nginx/1.7.11 built by gcc 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-pcre-jit --with-debug --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module --with-http_image_filter_module --with-http_geoip_module --with-http_sub_module --with-http_dav_module --add-module=/usr/src/nginx-dav-ext-module-master --with-http_flv_module --add-module=/usr/src/f4f-hds-master --with-http_mp4_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_stub_status_module --with-http_perl_module --with-mail --with-mail_ssl_module --with-http_auth_request_module --add-module=/usr/src/echo-nginx-module-master --add-module=/usr/src/nginx_md5_filter-master --add-module=/usr/src/ngx_devel_kit-master --add-module=/usr/src/lua-nginx-module-master --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ld-opt=' -Wl,-E,-rpath,/usr/local/lib' КОНФИГУРАЦИЯ ВИРТУАЛЬНОГО WEB-СЕРВЕРА (WEBDAV) Приведена конфигурация nginx работающего на виртуальной машине за проксирующим первичным nginx. Для работы на первичном вам необходимо изменить listen на 80 и 443. А так же не забудьте поправить основные настройки на ваши собственные (имена сервера и т.д.) Файл ihome.conf server { listen 7070; server_name "~^ihome\d+\.itcod\.com$" ihome.virtual.ko ihome.itcod.com ; server_name_in_redirect off; expires epoch; ssl off; #default_type application/octet-stream; set_real_ip_from 10.255.255.7; real_ip_header X-Forwarded-For; real_ip_recursive on; access_log /var/log/nginx/ihome.itcod.com-access.log main; resolver 10.255.255.1 [::1]:5353; charset utf-8; set $dir /opt/home; set $testdir $dir$uri; set $uri_type none; if (-d $testdir) { # такая папка есть set $uri_type dir; rewrite ^(.*)$ $1/; rewrite ^(.*)/+$ $1/; } if (-f $testdir) { # такой файл есть set $uri_type file; } if ($request_method = "MKCOL") { rewrite ^(.*)$ $1/; rewrite ^(.*)/+$ $1/; set $uri_type dir; #клиент webdav создает папку } if ($request_method = "PUT") { set $uri_type file; #передаем только файлы } if ($request_method = "POST") { set $uri_type file; #постим только файлы } set $sadm_passwd .uhtpsw; set $user_passwd .htpasswd; #user:password[crypt(3)/md5/sha1] set $user_permit .htpermit; #user:GET,PUT,....OPTIONS set $user_permit_default GET,PROPFIND,OPTIONS; # Allow merge_slashes on; location / { limit_req zone=itcod burst=200 nodelay; limit_rate 2048k; access_by_lua_file /etc/nginx/lua/auth-dav.lua; dav_methods PUT DELETE MKCOL COPY MOVE; dav_ext_methods PROPFIND OPTIONS; create_full_put_path on; dav_access user:rw group:rw; client_body_temp_path /opt/itcod-dav.tmp/; client_max_body_size 0; autoindex on; root $dir; header_filter_by_lua_file /etc/nginx/lua/itcod-exchange.lua; set $md5index on; #on/off nil=off # вкл/выкл обработчик set $md5index_hash md5; #none/md5/md4/sha1/sha/ripemd160 nil=none # тип выводых хэшей set $md5index_size 50000; #kb nil=unlimit # не считать для файлов более N kb set $md5index_path on; #on/off nil=off # заменять относительный путь ссылок на полный URI set $md5index_nonblank on; #on/off nil=off # заменить множественные пробелы одним set $md5index_type on; #on/off nil=off # добавит в строки описание типа file/directory/etc... set $md5index_ico http://ihome.itcod.com/max/projects/libs/icons16ext/; # путь к библиотека иконок set $md5index_icopref icon-; # префикс имени файла иконки #set $md5index_icosuf -icon; # суфикс имени файла иконки set $md5index_icoext .gif; # расширение файла иконки set $md5index_win _blank; # target window for !winext! files set $md5index_winext htm.html.txt; # file extension for target windows body_filter_by_lua_file /etc/nginx/lua/md5index.lua; # addon обработчик } location ~/\.uht { deny all; } location /search/ { content_by_lua_file /etc/nginx/lua/itcod-search.lua; } location /user/ { content_by_lua_file /etc/nginx/lua/itcod-user.lua; } } ПРИМЕЧАНИЕ Для программистов адекватных perl, проблем определить и загрузить недостающие модули require не составит труда. В случае если у вас, что то не получается пишите тут или на max at itcod.com обязательно помогу. ТЕКУЩИЕ РАБОТЫ Формирование WebUI ITCOD-DISK Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259941,259941#msg-259941 From onokonem at gmail.com Sat Jun 27 09:31:48 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Sat, 27 Jun 2015 12:31:48 +0300 Subject: =?UTF-8?B?UmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFzdGNnaSBwYXJhbQ==?= In-Reply-To: References: <64193c9f20ffede0001ce9cb7e75e28b.NginxMailingListRussian@forum.nginx.org> Message-ID: >> не надо, сделайте генерацию конфига, на любом удобном для вас языке, тогда > Только есть такой пр-цп -- "бритва Оккама", и лишние сущности не радостны. > Можно навернуть, только это будет overkill, во многих случаях. да хрен с ним, с оккамом. я хочу, чтобы мне nginx рассказывал о проблемах в конфиге ссылаясь на ту строчку, которую я написал, а не на появившуюся в результате генерации... From wangsamp at gmail.com Sat Jun 27 11:14:13 2015 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Sat, 27 Jun 2015 14:14:13 +0300 (EEST) Subject: =?UTF-8?B?UmU6IFJlOiBSZTogUmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSBmYXN0Y2dp?= =?UTF-8?B?IHBhcmFt?= In-Reply-To: References: Message-ID: Today Jun 27, 2015 at 14:16 Amanda Sproule wrote: > >>очистки предыдущей конфигурации, > > очистка не требуется, так как есть и другие локейшены (дочернии директивы). Ещё как требуется и тем больше, чем глубже вложенность. В JunOS, например, цепочки правил можно настраивать на уровне блока протокола, для группы пиров в блоке протокола и отдельного пира в группе. В случае слияния как исключить работу правил предыдущих уровней? Сейчас всё четко - задал для пира свои правила и работают только они. И возьмём упомянутые 400 location. Вы хотите задать десяток proxy_set_header на уровне server и дополнить в некоторых location - тут слияние выглядит привлекательным. Сейчас приходиться копировать все опции в те location. В случае добавления новых - просматривать весь конфиг и добавлять в нескольких местах. Будет слияние - не нужно копировать. А если теперь в некоторых location нужно будет оставить всего несколько опций proxy_set_header и другие с уровня server в них убрать? Они переопределяются пустой строкой, но каждый раз когда на уровне server нужно добавить ещё один заголовок, то опять же придётся смотреть и добавлять переопределения. Уровень сложности поддержки не меньше, но возможность сказать "сделай именно вот так и никак не иначе" отсутствует из-за длинных цепочек слияний. > А как еще на примере двух массивов параметров произвести наследование от > одного массива другим ? - думаю догадались - слиянием (merge). Нет наследования массивов. Есть наследование конфигурации по каждой директиве отдельно. Есть директива - она нам и нужна, нету - берём с предыдущего уровня. Никаких витиеватых выпадов с подвывертом и заворотом. -- WNGS-RIPE From paranoidchaos at gmail.com Sat Jun 27 12:48:56 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Sat, 27 Jun 2015 17:48:56 +0500 Subject: =?UTF-8?B?UmU6IFJlOiBSZTogUmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFz?= =?UTF-8?B?dGNnaSBwYXJhbQ==?= Message-ID: >>И возьмём упомянутые 400 location. Вы хотите задать десяток proxy_set_header на уровне server и дополнить в некоторых location - тут слияние выглядит привлекательным. Сейчас приходиться копировать все опции в те location. В случае добавления новых - просматривать весь конфиг и добавлять в нескольких местах. Будет слияние - не нужно копировать. А если теперь в некоторых location нужно будет оставить всего несколько опций proxy_set_header и другие с уровня server в них убрать? Они переопределяются пустой строкой, но каждый раз когда на уровне server нужно добавить ещё один заголовок, то опять же придётся смотреть и добавлять переопределения. Уровень сложности поддержки не меньше, но возможность сказать "сделай именно вот так и никак не иначе" отсутствует из-за длинных цепочек слияний. Всё зависит от того на сколько разрознена конфигурация в локейшенах. Если каждый из локейшенов определяет для себя сугубо строгие параметры, то о вынесении на уровень сервера и речи быть не может. Наследование (мердж) избавляет от копирования всего этого, и в частности, если исходить из конкретного случая c fastcgi_param практика показывает необходимости обобщения и вынесения, в отдельных случаях это переопределение какого-то из параметров. разве не красиво выглядит когда так ? server { ......... ......... include fastcgi_params; location /info { fastcgi_param SCRIPT_FILENAME /www/info.php; fastcgi_pass 127.0.0.1:9000; } location /info2 { try_files $uri =404; fastcgi_pass 127.0.0.1:9000; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From paranoidchaos at gmail.com Sat Jun 27 12:50:13 2015 From: paranoidchaos at gmail.com (Amanda Sproule) Date: Sat, 27 Jun 2015 17:50:13 +0500 Subject: =?UTF-8?B?UmU6IFJlOiBSZTogUmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFz?= =?UTF-8?B?dGNnaSBwYXJhbQ==?= Message-ID: >>И возьмём упомянутые 400 location. поправлю - не локейшенов а server контекстов. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Jun 27 13:01:24 2015 From: nginx-forum at nginx.us (S.A.N) Date: Sat, 27 Jun 2015 09:01:24 -0400 Subject: =?UTF-8?B?UmU6IFJlOiBSZTogUmU6IFJlOiDQndCw0YHQu9C10LTQvtCy0LDQvdC40LUgZmFz?= =?UTF-8?B?dGNnaSBwYXJhbQ==?= In-Reply-To: References: Message-ID: <8e9fd99d17bfb4df41e5c990c6fb428c.NginxMailingListRussian@forum.nginx.org> Amanda Sproule Wrote: ------------------------------------------------------- > >>И возьмём упомянутые 400 location. > > поправлю - не локейшенов а server контекстов. Да, для такого хозяйства нужен менеджер конфигов. Советую ещё вспомнить что Nginx это реверс прокси, он может общаться с бекендом на уровне HTTP заголовков. Nginx кеширования очень хорошо управляется на уровне HTTP заголовков от бекенда, переход (редирект) в именованные локейшины тоже позволяют создавать гибкие алгоритмы без программирования конфигов. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259930,259947#msg-259947 From a at gelun.ru Sun Jun 28 19:10:24 2015 From: a at gelun.ru (Gelun, Artem) Date: Sun, 28 Jun 2015 22:10:24 +0300 Subject: Senfile + Threads + mincore in Linux? Message-ID: Добрый день всем. Возможно, идея/вопрос не новы, но: Сейчас (с версии 1.7.11, если не ошибаюсь) sendfile может быть как блокирующим, так и неблокирующим *основной поток*, вызываясь в отдельном треде. При этом пул тредов фиксирован и если, например, я выделил 10 тредов, которые заняты чтением с диска (заблокированы), то другие "читатели" будут ожидать их даже если данные уже находятся в page cache, что не рационально, имхо. Т.е. мы можем иметь нагрузку, при которой 90% трафика будет отдаваться из PageCache, 10% с диска и эти 10% могут заблокировать кэшированные, "популярные" ответы. Вопрос: можно ли добавить в эту логику вызов mincore (в linux) для того, чтобы определить сколько данных есть в page cache, отправке этого объема данных и, если они отправились (возврат == NGX_OK) вызывать остаток sendfile в треде? Есть ли какие-то потенциальные проблемы за пределами ngx_linux_sendfile_chain.c строк 182-203 внутри #if (NGX_THREADS) ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alstpostbox at gmail.com Mon Jun 29 08:37:56 2015 From: alstpostbox at gmail.com (Andrey Istochkin) Date: Mon, 29 Jun 2015 11:37:56 +0300 Subject: Senfile + Threads + mincore in Linux? In-Reply-To: References: Message-ID: Насколько я понимаю, mincore оперирует адресами из виртуального адресного пространства процесса, а не файловыми дескрипторами. Таким образом, чтобы как-то применить его к файлу, нужно через mmap отображать файл в то самое адресное пространство, что, видимо, не является приемлемым решением. В http://habrahabr.ru/post/260669/ указано, что были попытки по созданию системного вызова fincore(https://lwn.net/Articles/371538/), который работал бы как раз с файловыми дескрипторами, но как-то не срослось. 28 июня 2015 г., 22:10 пользователь Gelun, Artem написал: > Добрый день всем. > > Возможно, идея/вопрос не новы, но: > > Сейчас (с версии 1.7.11, если не ошибаюсь) sendfile может быть как > блокирующим, так и неблокирующим *основной поток*, вызываясь в отдельном > треде. > > При этом пул тредов фиксирован и если, например, я выделил 10 тредов, > которые заняты чтением с диска (заблокированы), то другие "читатели" будут > ожидать их даже если данные уже находятся в page cache, что не рационально, > имхо. Т.е. мы можем иметь нагрузку, при которой 90% трафика будет > отдаваться из PageCache, 10% с диска и эти 10% могут заблокировать > кэшированные, "популярные" ответы. > > Вопрос: можно ли добавить в эту логику вызов mincore (в linux) для того, > чтобы определить сколько данных есть в page cache, отправке этого объема > данных и, если они отправились (возврат == NGX_OK) вызывать остаток > sendfile в треде? Есть ли какие-то потенциальные проблемы за пределами > ngx_linux_sendfile_chain.c строк 182-203 внутри #if (NGX_THREADS) ? > > _______________________________________________ > 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 simplebox66 at gmail.com Mon Jun 29 08:51:27 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 29 Jun 2015 11:51:27 +0300 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQv9GA0L7QsdC70LXQvNCwINGBIHJld3JpdGU=?= In-Reply-To: References: <1435159043.583020149@f244.i.mail.ru> Message-ID: Не ужели нет никаких вариантов дописать слеш в конец того каталога в который перемещается другой каталог? 25 июня 2015 г., 14:54 пользователь Иван Мишин написал: > Андрей, спасибо, помогло. Добавил break и каталоги удаляются без проблем. > Но есть еще один вопрос, касающийся метода MOVE, то есть перемещение > каталогов. > > К письму прикрепляю логи. > Проблема конкретно тут: > 2015/07/26 14:48:08 [error] 6735#0: *61 both URI "/Family/Новая папка/" > and "Destination" URI " > http://192.168.200.92/Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0%20%282%29/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0" > should be either collections or non-collections, client: 192.168.200.81, > server: 192.168.200.92, request: "MOVE > /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0 > HTTP/1.1", host: "192.168.200.92" > > Винда не понимает сама где каталоги, а где просто файлы. > То есть в случае метода MOVE я с помощью rewrite дописываю в конце слеш, а > вот как дописать слеш к тому каталогу в который я перемещаю первый каталог > не понятно. Если к методу PROPFIND дописать > if (-d $webdav_root/$uri) { > rewrite ^(.*[^/])$ $1/ break; > } > то в логах просто все зацикливается и все. Может у вас есть какие-то мысля > по этому поводу? > > 25 июня 2015 г., 11:49 пользователь Andrey Istochkin < > alstpostbox at gmail.com> написал: > > Попробуйте в @delete_handler в rewrite добавить 'break'. Так как в >> access_логе фигурирует 598, то похоже на то, что @delete_handler >> отрабатывает, отрабатывает rewrite, после чего запрос уходит снова в >> 'location ^~ /Family', опять отрабатывает 'return 598', но так как >> recursive_error_pages по-умолчанию выключена, error_page на этот раз не >> срабатывает, и клиент получает 598. >> >> 25 июня 2015 г., 9:28 пользователь Иван Мишин >> написал: >> >> в этом случае до винды этот код дойти не должен. если доходит - вы >>>> плохо настроили error >>> >>> >>> Ну судя по tcpdump на стороне винды, 598 код все же доходит до нее. >>> >>> про какой? про переход в именованный локейшн? или про то, что код, >>>> который для этого используется, наружу отдаваться не должен? >>> >>> >>> И про то и про другое, если не затруднит. >>> ВО-первых, PROPFIND метод работает, при том что он организован в моем >>> конфиге тем же способом что и метод DELETE с той лишь разницей что PROPFIND >>> через 599 код работает, а DELETE через 598. Но я так понимаю что-это >>> различие не на что не влияет ибо пробовал менять коды местами и...вот >>> цитата моих слов по этому поводу: >>> >>>> 599 отрабатывает точно правильно потому что метод PROPFIND работает без >>>> вопросов. В качестве экспиремента поменял местами 599 и 598 в >>>> итоге PROPFIND как работал так и работает а DELETE каталогов как не работал >>>> так и не работает. >>> >>> >>> ВО-вторых, мне казалось что если с клиента ( в данном случае с винды) >>> ушел запрос DELETE на nginx и nginx то nginx его должен отработать и >>> каталог удалить, и не важно что он ответит клиент, потому что для клиента >>> этот ответ будет чисто информационным т.е. не будет влиять на результат >>> выполнения первого запроса (запроса на DELETE). >>> >>> >>> 24 июня 2015 г., 18:55 пользователь Daniel Podolsky >>> написал: >>> >>> > Даниель, можно подробнее пожалуйста про этот момент >>>> про какой? про переход в именованный локейшн? или про то, что код, >>>> который для этого используется, наружу отдаваться не должен? >>>> _______________________________________________ >>>> 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 alstpostbox at gmail.com Mon Jun 29 09:09:58 2015 From: alstpostbox at gmail.com (Andrey Istochkin) Date: Mon, 29 Jun 2015 12:09:58 +0300 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQv9GA0L7QsdC70LXQvNCwINGBIHJld3JpdGU=?= In-Reply-To: References: <1435159043.583020149@f244.i.mail.ru> Message-ID: Дело в том, что 'destination' передается в заголовках запроса, для правки которых встроенных средств, наверное, нет. Можно попробовать посмотреть в сторону http://wiki.nginx.org/HttpHeadersMoreModule или как-то поизголяться с проксированием на самого себя и выставлением в проксированном запросе нужного заголовка. Но как-то это костыльно все очень. 29 июня 2015 г., 11:51 пользователь Иван Мишин написал: > Не ужели нет никаких вариантов дописать слеш в конец того каталога в > который перемещается другой каталог? > > 25 июня 2015 г., 14:54 пользователь Иван Мишин > написал: > > Андрей, спасибо, помогло. Добавил break и каталоги удаляются без проблем. >> Но есть еще один вопрос, касающийся метода MOVE, то есть перемещение >> каталогов. >> >> К письму прикрепляю логи. >> Проблема конкретно тут: >> 2015/07/26 14:48:08 [error] 6735#0: *61 both URI "/Family/Новая папка/" >> and "Destination" URI " >> http://192.168.200.92/Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0%20%282%29/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0" >> should be either collections or non-collections, client: 192.168.200.81, >> server: 192.168.200.92, request: "MOVE >> /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0 >> HTTP/1.1", host: "192.168.200.92" >> >> Винда не понимает сама где каталоги, а где просто файлы. >> То есть в случае метода MOVE я с помощью rewrite дописываю в конце слеш, >> а вот как дописать слеш к тому каталогу в который я перемещаю первый >> каталог не понятно. Если к методу PROPFIND дописать >> if (-d $webdav_root/$uri) { >> rewrite ^(.*[^/])$ $1/ break; >> } >> то в логах просто все зацикливается и все. Может у вас есть какие-то >> мысля по этому поводу? >> >> 25 июня 2015 г., 11:49 пользователь Andrey Istochkin < >> alstpostbox at gmail.com> написал: >> >> Попробуйте в @delete_handler в rewrite добавить 'break'. Так как в >>> access_логе фигурирует 598, то похоже на то, что @delete_handler >>> отрабатывает, отрабатывает rewrite, после чего запрос уходит снова в >>> 'location ^~ /Family', опять отрабатывает 'return 598', но так как >>> recursive_error_pages по-умолчанию выключена, error_page на этот раз не >>> срабатывает, и клиент получает 598. >>> >>> 25 июня 2015 г., 9:28 пользователь Иван Мишин >>> написал: >>> >>> в этом случае до винды этот код дойти не должен. если доходит - вы >>>>> плохо настроили error >>>> >>>> >>>> Ну судя по tcpdump на стороне винды, 598 код все же доходит до нее. >>>> >>>> про какой? про переход в именованный локейшн? или про то, что код, >>>>> который для этого используется, наружу отдаваться не должен? >>>> >>>> >>>> И про то и про другое, если не затруднит. >>>> ВО-первых, PROPFIND метод работает, при том что он организован в моем >>>> конфиге тем же способом что и метод DELETE с той лишь разницей что PROPFIND >>>> через 599 код работает, а DELETE через 598. Но я так понимаю что-это >>>> различие не на что не влияет ибо пробовал менять коды местами и...вот >>>> цитата моих слов по этому поводу: >>>> >>>>> 599 отрабатывает точно правильно потому что метод PROPFIND работает >>>>> без вопросов. В качестве экспиремента поменял местами 599 и 598 в >>>>> итоге PROPFIND как работал так и работает а DELETE каталогов как не работал >>>>> так и не работает. >>>> >>>> >>>> ВО-вторых, мне казалось что если с клиента ( в данном случае с винды) >>>> ушел запрос DELETE на nginx и nginx то nginx его должен отработать и >>>> каталог удалить, и не важно что он ответит клиент, потому что для клиента >>>> этот ответ будет чисто информационным т.е. не будет влиять на результат >>>> выполнения первого запроса (запроса на DELETE). >>>> >>>> >>>> 24 июня 2015 г., 18:55 пользователь Daniel Podolsky >>> > написал: >>>> >>>> > Даниель, можно подробнее пожалуйста про этот момент >>>>> про какой? про переход в именованный локейшн? или про то, что код, >>>>> который для этого используется, наружу отдаваться не должен? >>>>> _______________________________________________ >>>>> 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 for.poige+nginx at gmail.com Mon Jun 29 09:50:42 2015 From: for.poige+nginx at gmail.com (Igor M Podlesny) Date: Mon, 29 Jun 2015 16:50:42 +0700 Subject: Senfile + Threads + mincore in Linux? In-Reply-To: References: Message-ID: 2015-06-29 15:37 GMT+07:00 Andrey Istochkin : > Насколько я понимаю, mincore оперирует адресами из виртуального адресного > пространства процесса, а не файловыми дескрипторами. Таким образом, чтобы > как-то применить его к файлу, нужно через mmap отображать файл в то самое > адресное пространство, что, видимо, не является приемлемым решением. Ну почему же "не является"(?). Я так понимаю, что Varnish, например, "во все поля" этим занимается: https://www.varnish-cache.org/trac/wiki/ArchitectNotes -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From simplebox66 at gmail.com Mon Jun 29 12:57:30 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 29 Jun 2015 15:57:30 +0300 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQv9GA0L7QsdC70LXQvNCwINGBIHJld3JpdGU=?= In-Reply-To: References: <1435159043.583020149@f244.i.mail.ru> Message-ID: > > Дело в том, что 'destination' передается в заголовках запроса, для правки > которых встроенных средств, наверное, нет Да только судя по tcpdump destination то правильный , вот кусочек из дампа: 192.168.200.81.50818 > 192.168.200.92.80: Flags [P.], cksum 0xd386 (correct), seq 1:226, ack 1, win 2053, length 225 E.. |~@...ko...Q...\...P_.G9....P.......MOVE /Family/aa11 HTTP/1.1 Connection: Keep-Alive User-Agent: Microsoft-WebDAV-MiniRedir/6.3.9600 Destination: http://192.168.200.92/Family/bb22/aa11 Overwrite: F translate: f Content-Length: 0 Host: 192.168.200.92 29 июня 2015 г., 12:09 пользователь Andrey Istochkin написал: > Дело в том, что 'destination' передается в заголовках запроса, для правки > которых встроенных средств, наверное, нет. Можно попробовать посмотреть в > сторону http://wiki.nginx.org/HttpHeadersMoreModule или как-то > поизголяться с проксированием на самого себя и выставлением в > проксированном запросе нужного заголовка. Но как-то это костыльно все очень. > > 29 июня 2015 г., 11:51 пользователь Иван Мишин > написал: > > Не ужели нет никаких вариантов дописать слеш в конец того каталога в >> который перемещается другой каталог? >> >> 25 июня 2015 г., 14:54 пользователь Иван Мишин >> написал: >> >> Андрей, спасибо, помогло. Добавил break и каталоги удаляются без проблем. >>> Но есть еще один вопрос, касающийся метода MOVE, то есть перемещение >>> каталогов. >>> >>> К письму прикрепляю логи. >>> Проблема конкретно тут: >>> 2015/07/26 14:48:08 [error] 6735#0: *61 both URI "/Family/Новая папка/" >>> and "Destination" URI " >>> http://192.168.200.92/Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0%20%282%29/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0" >>> should be either collections or non-collections, client: 192.168.200.81, >>> server: 192.168.200.92, request: "MOVE >>> /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0 >>> HTTP/1.1", host: "192.168.200.92" >>> >>> Винда не понимает сама где каталоги, а где просто файлы. >>> То есть в случае метода MOVE я с помощью rewrite дописываю в конце слеш, >>> а вот как дописать слеш к тому каталогу в который я перемещаю первый >>> каталог не понятно. Если к методу PROPFIND дописать >>> if (-d $webdav_root/$uri) { >>> rewrite ^(.*[^/])$ $1/ break; >>> } >>> то в логах просто все зацикливается и все. Может у вас есть какие-то >>> мысля по этому поводу? >>> >>> 25 июня 2015 г., 11:49 пользователь Andrey Istochkin < >>> alstpostbox at gmail.com> написал: >>> >>> Попробуйте в @delete_handler в rewrite добавить 'break'. Так как в >>>> access_логе фигурирует 598, то похоже на то, что @delete_handler >>>> отрабатывает, отрабатывает rewrite, после чего запрос уходит снова в >>>> 'location ^~ /Family', опять отрабатывает 'return 598', но так как >>>> recursive_error_pages по-умолчанию выключена, error_page на этот раз не >>>> срабатывает, и клиент получает 598. >>>> >>>> 25 июня 2015 г., 9:28 пользователь Иван Мишин >>>> написал: >>>> >>>> в этом случае до винды этот код дойти не должен. если доходит - вы >>>>>> плохо настроили error >>>>> >>>>> >>>>> Ну судя по tcpdump на стороне винды, 598 код все же доходит до нее. >>>>> >>>>> про какой? про переход в именованный локейшн? или про то, что код, >>>>>> который для этого используется, наружу отдаваться не должен? >>>>> >>>>> >>>>> И про то и про другое, если не затруднит. >>>>> ВО-первых, PROPFIND метод работает, при том что он организован в моем >>>>> конфиге тем же способом что и метод DELETE с той лишь разницей что PROPFIND >>>>> через 599 код работает, а DELETE через 598. Но я так понимаю что-это >>>>> различие не на что не влияет ибо пробовал менять коды местами и...вот >>>>> цитата моих слов по этому поводу: >>>>> >>>>>> 599 отрабатывает точно правильно потому что метод PROPFIND работает >>>>>> без вопросов. В качестве экспиремента поменял местами 599 и 598 в >>>>>> итоге PROPFIND как работал так и работает а DELETE каталогов как не работал >>>>>> так и не работает. >>>>> >>>>> >>>>> ВО-вторых, мне казалось что если с клиента ( в данном случае с винды) >>>>> ушел запрос DELETE на nginx и nginx то nginx его должен отработать и >>>>> каталог удалить, и не важно что он ответит клиент, потому что для клиента >>>>> этот ответ будет чисто информационным т.е. не будет влиять на результат >>>>> выполнения первого запроса (запроса на DELETE). >>>>> >>>>> >>>>> 24 июня 2015 г., 18:55 пользователь Daniel Podolsky < >>>>> onokonem at gmail.com> написал: >>>>> >>>>> > Даниель, можно подробнее пожалуйста про этот момент >>>>>> про какой? про переход в именованный локейшн? или про то, что код, >>>>>> который для этого используется, наружу отдаваться не должен? >>>>>> _______________________________________________ >>>>>> 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 >> > > > _______________________________________________ > 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 vbart at nginx.com Mon Jun 29 13:18:13 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 29 Jun 2015 16:18:13 +0300 Subject: Senfile + Threads + mincore in Linux? In-Reply-To: References: Message-ID: <16695672.rSZuxMm5c8@vbart-workstation> On Monday 29 June 2015 16:50:42 Igor M Podlesny wrote: > 2015-06-29 15:37 GMT+07:00 Andrey Istochkin : > > > Насколько я понимаю, mincore оперирует адресами из виртуального адресного > > пространства процесса, а не файловыми дескрипторами. Таким образом, чтобы > > как-то применить его к файлу, нужно через mmap отображать файл в то самое > > адресное пространство, что, видимо, не является приемлемым решением. > > > Ну почему же "не является"(?). > > Я так понимаю, что Varnish, например, "во все поля" этим занимается: > > https://www.varnish-cache.org/trac/wiki/ArchitectNotes > Varnish не веб-сервер, а кэш, причем кэш там организован через mmap(). Постоянные mmap() + mincore() + unmap() - получится недешево. -- Валентин Бартенев From for.poige+nginx at gmail.com Mon Jun 29 13:28:08 2015 From: for.poige+nginx at gmail.com (Igor M Podlesny) Date: Mon, 29 Jun 2015 20:28:08 +0700 Subject: Senfile + Threads + mincore in Linux? In-Reply-To: <16695672.rSZuxMm5c8@vbart-workstation> References: <16695672.rSZuxMm5c8@vbart-workstation> Message-ID: 2015-06-29 20:18 GMT+07:00 Валентин Бартенев : > Varnish не веб-сервер, а кэш, причем кэш там организован через mmap(). > Новости! ;-) > Постоянные mmap() + mincore() + unmap() - получится недешево. > Ну так можно ж не постоянно. Зачем постоянно-то? Замэпить и сёрвить. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Mon Jun 29 13:40:59 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 29 Jun 2015 16:40:59 +0300 Subject: Senfile + Threads + mincore in Linux? In-Reply-To: References: <16695672.rSZuxMm5c8@vbart-workstation> Message-ID: <4128081.ajXyKZWqd0@vbart-workstation> On Monday 29 June 2015 20:28:08 Igor M Podlesny wrote: > 2015-06-29 20:18 GMT+07:00 Валентин Бартенев : > > > Varnish не веб-сервер, а кэш, причем кэш там организован через mmap(). > > > > Новости! ;-) > > > > Постоянные mmap() + mincore() + unmap() - получится недешево. > > > > Ну так можно ж не постоянно. Зачем постоянно-то? Замэпить и сёрвить. > У вас же не один файл, так? Пулы потоков и нужны там, где файлов много больше, чем оперативной памяти. Нужно будет mmap() делать минимум на каждый запрос, тысячи mmap()/munmap()-ов в секунду - это большая нагрузка на подсистему памяти. -- Валентин Бартенев From a at gelun.ru Mon Jun 29 14:05:58 2015 From: a at gelun.ru (Gelun, Artem) Date: Mon, 29 Jun 2015 17:05:58 +0300 Subject: Senfile + Threads + mincore in Linux? In-Reply-To: <4128081.ajXyKZWqd0@vbart-workstation> References: <16695672.rSZuxMm5c8@vbart-workstation> <4128081.ajXyKZWqd0@vbart-workstation> Message-ID: Ну у вас ведь файл открывется не при каждом запросе? Вы откываете файл и сохраняете дескриптор в структуре (не помню какой ))) ) что мешает в этой же структуре сохранять указатель на mmap? и unmap делать вместе с закрытием файла (если ранее указатель был проинициализирован, а mmap делать только когда нужно)? 29 июня 2015 г., 16:40 пользователь Валентин Бартенев написал: > On Monday 29 June 2015 20:28:08 Igor M Podlesny wrote: > > 2015-06-29 20:18 GMT+07:00 Валентин Бартенев : > > > > > Varnish не веб-сервер, а кэш, причем кэш там организован через mmap(). > > > > > > > Новости! ;-) > > > > > > > Постоянные mmap() + mincore() + unmap() - получится недешево. > > > > > > > Ну так можно ж не постоянно. Зачем постоянно-то? Замэпить и сёрвить. > > > > У вас же не один файл, так? Пулы потоков и нужны там, где файлов много > больше, > чем оперативной памяти. > > Нужно будет mmap() делать минимум на каждый запрос, тысячи > mmap()/munmap()-ов в > секунду - это большая нагрузка на подсистему памяти. > > -- > Валентин Бартенев > _______________________________________________ > 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 at gelun.ru Mon Jun 29 14:08:49 2015 From: a at gelun.ru (Gelun, Artem) Date: Mon, 29 Jun 2015 17:08:49 +0300 Subject: Senfile + Threads + mincore in Linux? In-Reply-To: References: <16695672.rSZuxMm5c8@vbart-workstation> <4128081.ajXyKZWqd0@vbart-workstation> Message-ID: Объясню насчет "когда нужно" )) Часть файлов отдавать так наверняка нерационально. Если они мелкие, то это многих fopen/mmap, что нехорошо Но если нужно отдать большой файл (например, вынести "большие файлы" в отдельную локацию и там включать/выключать настройкой такую фичу), да еще и дескриптор в кэше держать, а не открывать каждый раз, то кол-во mmap будет не столь значительно, мне кажется? 29 июня 2015 г., 17:05 пользователь Gelun, Artem написал: > Ну у вас ведь файл открывется не при каждом запросе? > Вы откываете файл и сохраняете дескриптор в структуре (не помню какой ))) ) > что мешает в этой же структуре сохранять указатель на mmap? и unmap делать > вместе с закрытием файла (если ранее указатель был проинициализирован, а > mmap делать только когда нужно)? > > > 29 июня 2015 г., 16:40 пользователь Валентин Бартенев > написал: > > On Monday 29 June 2015 20:28:08 Igor M Podlesny wrote: >> > 2015-06-29 20:18 GMT+07:00 Валентин Бартенев : >> > >> > > Varnish не веб-сервер, а кэш, причем кэш там организован через mmap(). >> > > >> > >> > Новости! ;-) >> > >> > >> > > Постоянные mmap() + mincore() + unmap() - получится недешево. >> > > >> > >> > Ну так можно ж не постоянно. Зачем постоянно-то? Замэпить и сёрвить. >> > >> >> У вас же не один файл, так? Пулы потоков и нужны там, где файлов много >> больше, >> чем оперативной памяти. >> >> Нужно будет mmap() делать минимум на каждый запрос, тысячи >> mmap()/munmap()-ов в >> секунду - это большая нагрузка на подсистему памяти. >> >> -- >> Валентин Бартенев >> _______________________________________________ >> 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 vbart at nginx.com Mon Jun 29 14:43:56 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 29 Jun 2015 17:43:56 +0300 Subject: Senfile + Threads + mincore in Linux? In-Reply-To: References: Message-ID: <2436038.nQfxL1yJXx@vbart-workstation> On Monday 29 June 2015 17:08:49 Gelun, Artem wrote: > Объясню насчет "когда нужно" )) > Часть файлов отдавать так наверняка нерационально. Если они мелкие, то это > многих fopen/mmap, что нехорошо > Но если нужно отдать большой файл (например, вынести "большие файлы" в > отдельную локацию и там включать/выключать настройкой такую фичу), да еще и > дескриптор в кэше держать, а не открывать каждый раз, то кол-во mmap будет > не столь значительно, мне кажется? > Файл открывается при каждом запросе, если только не настроен отдельно open_file_cache с которым есть свои проблемы. Добавление туда ещё mmap() принесет приличное количество новой логики в разных местах, при этом далекой от совершенства по двум причинам: 1. mincore() будет пессимизировать наиболее распространенный случай, когда данные все же есть в памяти, поэтому включать его и пулы потоков глобально в большинстве случаев всё равно будет невыгодно. При этом потребуется включать еще и open_file_cache, так что правильная настройка всего этого вместе становится совсем сложной. В итоге таким решением будет пользоваться с умом человек десять. 2. У вас остается race condition между вызовом mincore() и read()/sendfile(). Лучше пинайте разработчиков ядра, чтобы наконец замерджили RWF_NONBLOCK или fincore() патчи. Последний хоть и не лишен второго недостатка, но по крайней мере потребует на порядок меньше нового кода. -- Валентин Бартенев > 29 июня 2015 г., 17:05 пользователь Gelun, Artem написал: > > > Ну у вас ведь файл открывется не при каждом запросе? > > Вы откываете файл и сохраняете дескриптор в структуре (не помню какой ))) ) > > что мешает в этой же структуре сохранять указатель на mmap? и unmap делать > > вместе с закрытием файла (если ранее указатель был проинициализирован, а > > mmap делать только когда нужно)? > > > > > > 29 июня 2015 г., 16:40 пользователь Валентин Бартенев > > написал: > > > > On Monday 29 June 2015 20:28:08 Igor M Podlesny wrote: > >> > 2015-06-29 20:18 GMT+07:00 Валентин Бартенев : > >> > > >> > > Varnish не веб-сервер, а кэш, причем кэш там организован через mmap(). > >> > > > >> > > >> > Новости! ;-) > >> > > >> > > >> > > Постоянные mmap() + mincore() + unmap() - получится недешево. > >> > > > >> > > >> > Ну так можно ж не постоянно. Зачем постоянно-то? Замэпить и сёрвить. > >> > > >> > >> У вас же не один файл, так? Пулы потоков и нужны там, где файлов много > >> больше, > >> чем оперативной памяти. > >> > >> Нужно будет mmap() делать минимум на каждый запрос, тысячи > >> mmap()/munmap()-ов в > >> секунду - это большая нагрузка на подсистему памяти. > >> > >> -- > >> Валентин Бартенев > >> _______________________________________________ > >> nginx-ru mailing list > >> nginx-ru at nginx.org > >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > >> > > > > > From maxim at nginx.com Mon Jun 29 15:00:52 2015 From: maxim at nginx.com (Maxim Konovalov) Date: Mon, 29 Jun 2015 18:00:52 +0300 Subject: Senfile + Threads + mincore in Linux? In-Reply-To: <2436038.nQfxL1yJXx@vbart-workstation> References: <2436038.nQfxL1yJXx@vbart-workstation> Message-ID: <55915DA4.3080802@nginx.com> On 6/29/15 5:43 PM, Валентин Бартенев wrote: [...] > 2. У вас остается race condition между вызовом mincore() и > read()/sendfile(). Вот эта часть важная -- на практике под высокой нагрузкой между этими двумя вызовами данные из кэша VM вымываются и читающий сисколл блокируется. Чтобы закрыть это окно вам нужен mlock(), но не простой, а неблокирующийся. И мы это направление довольно подробно на FreeBSD исследовали. Настолько, что получилось вот это: https://www.freebsd.org/cgi/man.cgi?query=aio_mlock Этот системный вызов в теории позволяет вам самостоятельно управлять механизмом кэширования в памяти, не полагаясь на эвристику ОС. Но натурные испытания показали, что идея не самая удачная. По крайней мере на FreeBSD в конфигурации, когда активный dataset на два и более порядков (XX TB vs XX GB) превосходит размер доступной оперативной памяти, огромное количество mmap/munmap давало столь большой оверхед, что выигрыш от хитрого кэширования с предчтением и удержанием в памяти был неизмеримо мал. Фактически, пришли к выводу, который был более или менее очевиден с самого начала, что кэширование при таком профиле нагрузки не поможет. -- Maxim Konovalov http://nginx.com From for.poige+nginx at gmail.com Mon Jun 29 16:09:31 2015 From: for.poige+nginx at gmail.com (Igor M Podlesny) Date: Mon, 29 Jun 2015 23:09:31 +0700 Subject: Senfile + Threads + mincore in Linux? In-Reply-To: <4128081.ajXyKZWqd0@vbart-workstation> References: <16695672.rSZuxMm5c8@vbart-workstation> <4128081.ajXyKZWqd0@vbart-workstation> Message-ID: 2015-06-29 20:40 GMT+07:00 Валентин Бартенев : > > У вас же не один файл, так? Пулы потоков и нужны там, где файлов много больше, > чем оперативной памяти. > > Нужно будет mmap() делать минимум на каждый запрос, тысячи mmap()/munmap()-ов в > секунду - это большая нагрузка на подсистему памяти. Ну не, я не такой шаблон себе представлял, в связи с этим, а, скорее, что-то вроде: "... A minute after the start the special ?cache loader? process is activated. It loads information about previously cached data stored on file system into a cache zone. The loading is done in iterations. During one iteration no more than loader_files items are loaded (by default, 100). Besides, the duration of one iteration is limited by the loader_threshold parameter (by default, 200 milliseconds). Between iterations, a pause configured by the loader_sleep parameter (by default, 50 milliseconds) is made. ..." -- http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_path -- From kpoxa at kpoxa.net Tue Jun 30 13:27:01 2015 From: kpoxa at kpoxa.net (kpoxa) Date: Tue, 30 Jun 2015 16:27:01 +0300 Subject: =?UTF-8?B?MiDQsNC/0YHRgtGA0LjQvNCwINC/0L4g0L7Rh9C10YDQtdC00LgsINC40LvQuCAy?= =?UTF-8?B?INC40LzQtdC90L7QstCw0L3Ri9GFINC70L7QutC10LnRiNC10L3QsCDQsiB0?= =?UTF-8?B?cnlfZmlsZXMgLSDQutCw0Log0YDQtdGI0LjRgtGMINC30LDQtNCw0YfQutGD?= Message-ID: Добрый день, коллеги. Есть задача сделать так: 1. проверить есть ли файл локально. 2. если нет, то проверить апстрим "горячий кеш", нет ли там файла. 3. Если в горячем кеше нет, то проверить следующий апстрим. Вариант с try_files $url @hot_cache @slow_cache не работает, т.к. 2 именованных локейшена нельзя использовать. Вариант объединить все в один апстрим не очень хорош, т.к. надо проверить сначала все горячие кеши, потом только холодные. Остаётся вариант с error_page 404 = @slow_cache в локейшене горячего кеша. Это единственный/лучший вариант решения подобной задачи? Почему нельзя в try_files сделать возможность использования нескольких именованых локешенов? -- Рустам -------------- next part -------------- An HTML attachment was scrubbed... URL: From simplebox66 at gmail.com Tue Jun 30 13:29:30 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Tue, 30 Jun 2015 16:29:30 +0300 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQv9GA0L7QsdC70LXQvNCwINGBIHJld3JpdGU=?= In-Reply-To: References: <1435159043.583020149@f244.i.mail.ru> Message-ID: > > Дело в том, что 'destination' передается в заголовках запроса, для правки > которых встроенных средств, наверное, нет. Можно попробовать посмотреть в > сторону http://wiki.nginx.org/HttpHeadersMoreModule Андрей, спасибо! Вопрос был решен с помощью этого модуля. 29 июня 2015 г., 15:57 пользователь Иван Мишин написал: > Дело в том, что 'destination' передается в заголовках запроса, для правки >> которых встроенных средств, наверное, нет > > Да только судя по tcpdump destination то правильный , вот кусочек из дампа: > > 192.168.200.81.50818 > 192.168.200.92.80: Flags [P.], cksum 0xd386 > (correct), seq 1:226, ack 1, win 2053, length 225 > E.. |~@...ko...Q...\...P_.G9....P.......MOVE /Family/aa11 HTTP/1.1 > Connection: Keep-Alive > User-Agent: Microsoft-WebDAV-MiniRedir/6.3.9600 > Destination: http://192.168.200.92/Family/bb22/aa11 > Overwrite: F > translate: f > Content-Length: 0 > Host: 192.168.200.92 > > 29 июня 2015 г., 12:09 пользователь Andrey Istochkin < > alstpostbox at gmail.com> написал: > > Дело в том, что 'destination' передается в заголовках запроса, для правки >> которых встроенных средств, наверное, нет. Можно попробовать посмотреть в >> сторону http://wiki.nginx.org/HttpHeadersMoreModule или как-то >> поизголяться с проксированием на самого себя и выставлением в >> проксированном запросе нужного заголовка. Но как-то это костыльно все очень. >> >> 29 июня 2015 г., 11:51 пользователь Иван Мишин >> написал: >> >> Не ужели нет никаких вариантов дописать слеш в конец того каталога в >>> который перемещается другой каталог? >>> >>> 25 июня 2015 г., 14:54 пользователь Иван Мишин >>> написал: >>> >>> Андрей, спасибо, помогло. Добавил break и каталоги удаляются без проблем. >>>> Но есть еще один вопрос, касающийся метода MOVE, то есть перемещение >>>> каталогов. >>>> >>>> К письму прикрепляю логи. >>>> Проблема конкретно тут: >>>> 2015/07/26 14:48:08 [error] 6735#0: *61 both URI "/Family/Новая папка/" >>>> and "Destination" URI " >>>> http://192.168.200.92/Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0%20%282%29/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0" >>>> should be either collections or non-collections, client: 192.168.200.81, >>>> server: 192.168.200.92, request: "MOVE >>>> /Family/%D0%9D%D0%BE%D0%B2%D0%B0%D1%8F%20%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0 >>>> HTTP/1.1", host: "192.168.200.92" >>>> >>>> Винда не понимает сама где каталоги, а где просто файлы. >>>> То есть в случае метода MOVE я с помощью rewrite дописываю в конце >>>> слеш, а вот как дописать слеш к тому каталогу в который я перемещаю первый >>>> каталог не понятно. Если к методу PROPFIND дописать >>>> if (-d $webdav_root/$uri) { >>>> rewrite ^(.*[^/])$ $1/ break; >>>> } >>>> то в логах просто все зацикливается и все. Может у вас есть какие-то >>>> мысля по этому поводу? >>>> >>>> 25 июня 2015 г., 11:49 пользователь Andrey Istochkin < >>>> alstpostbox at gmail.com> написал: >>>> >>>> Попробуйте в @delete_handler в rewrite добавить 'break'. Так как в >>>>> access_логе фигурирует 598, то похоже на то, что @delete_handler >>>>> отрабатывает, отрабатывает rewrite, после чего запрос уходит снова в >>>>> 'location ^~ /Family', опять отрабатывает 'return 598', но так как >>>>> recursive_error_pages по-умолчанию выключена, error_page на этот раз не >>>>> срабатывает, и клиент получает 598. >>>>> >>>>> 25 июня 2015 г., 9:28 пользователь Иван Мишин >>>>> написал: >>>>> >>>>> в этом случае до винды этот код дойти не должен. если доходит - вы >>>>>>> плохо настроили error >>>>>> >>>>>> >>>>>> Ну судя по tcpdump на стороне винды, 598 код все же доходит до нее. >>>>>> >>>>>> про какой? про переход в именованный локейшн? или про то, что код, >>>>>>> который для этого используется, наружу отдаваться не должен? >>>>>> >>>>>> >>>>>> И про то и про другое, если не затруднит. >>>>>> ВО-первых, PROPFIND метод работает, при том что он организован в моем >>>>>> конфиге тем же способом что и метод DELETE с той лишь разницей что PROPFIND >>>>>> через 599 код работает, а DELETE через 598. Но я так понимаю что-это >>>>>> различие не на что не влияет ибо пробовал менять коды местами и...вот >>>>>> цитата моих слов по этому поводу: >>>>>> >>>>>>> 599 отрабатывает точно правильно потому что метод PROPFIND работает >>>>>>> без вопросов. В качестве экспиремента поменял местами 599 и 598 в >>>>>>> итоге PROPFIND как работал так и работает а DELETE каталогов как не работал >>>>>>> так и не работает. >>>>>> >>>>>> >>>>>> ВО-вторых, мне казалось что если с клиента ( в данном случае с винды) >>>>>> ушел запрос DELETE на nginx и nginx то nginx его должен отработать и >>>>>> каталог удалить, и не важно что он ответит клиент, потому что для клиента >>>>>> этот ответ будет чисто информационным т.е. не будет влиять на результат >>>>>> выполнения первого запроса (запроса на DELETE). >>>>>> >>>>>> >>>>>> 24 июня 2015 г., 18:55 пользователь Daniel Podolsky < >>>>>> onokonem at gmail.com> написал: >>>>>> >>>>>> > Даниель, можно подробнее пожалуйста про этот момент >>>>>>> про какой? про переход в именованный локейшн? или про то, что код, >>>>>>> который для этого используется, наружу отдаваться не должен? >>>>>>> _______________________________________________ >>>>>>> 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 >>> >> >> >> _______________________________________________ >> 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 error500 at error500.ru Tue Jun 30 14:00:02 2015 From: error500 at error500.ru (Panfilov Konstantin) Date: Tue, 30 Jun 2015 17:00:02 +0300 Subject: =?UTF-8?B?UmU6IDIg0LDQv9GB0YLRgNC40LzQsCDQv9C+INC+0YfQtdGA0LXQtNC4LCDQuNC7?= =?UTF-8?B?0LggMiDQuNC80LXQvdC+0LLQsNC90YvRhSDQu9C+0LrQtdC50YjQtdC90LAg?= =?UTF-8?B?0LIgdHJ5X2ZpbGVzIC0g0LrQsNC6INGA0LXRiNC40YLRjCDQt9Cw0LTQsNGH?= =?UTF-8?B?0LrRgw==?= In-Reply-To: References: Message-ID: <5592A0E2.8030307@error500.ru> Вообще error_page единственно правильное решение try_files для тех кому быстренько WP поднять надо только не забудьте включить *recursive_error_pages*|on| 30.06.2015 16:27, kpoxa пишет: > > Добрый день, коллеги. > > Есть задача сделать так: > 1. проверить есть ли файл локально. > 2. если нет, то проверить апстрим "горячий кеш", нет ли там файла. > 3. Если в горячем кеше нет, то проверить следующий апстрим. > > Вариант с > try_files $url @hot_cache @slow_cache > не работает, т.к. 2 именованных локейшена нельзя использовать. > > Вариант объединить все в один апстрим не очень хорош, т.к. надо > проверить сначала все горячие кеши, потом только холодные. > > Остаётся вариант с error_page 404 = @slow_cache в локейшене горячего кеша. > > Это единственный/лучший вариант решения подобной задачи? > Почему нельзя в try_files сделать возможность использования нескольких > именованых локешенов? > > -- > Рустам > > > _______________________________________________ > 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 kpoxa at kpoxa.net Tue Jun 30 14:12:44 2015 From: kpoxa at kpoxa.net (kpoxa) Date: Tue, 30 Jun 2015 17:12:44 +0300 Subject: =?UTF-8?B?UmU6IDIg0LDQv9GB0YLRgNC40LzQsCDQv9C+INC+0YfQtdGA0LXQtNC4LCDQuNC7?= =?UTF-8?B?0LggMiDQuNC80LXQvdC+0LLQsNC90YvRhSDQu9C+0LrQtdC50YjQtdC90LAg?= =?UTF-8?B?0LIgdHJ5X2ZpbGVzIC0g0LrQsNC6INGA0LXRiNC40YLRjCDQt9Cw0LTQsNGH?= =?UTF-8?B?0LrRgw==?= In-Reply-To: <5592A0E2.8030307@error500.ru> References: <5592A0E2.8030307@error500.ru> Message-ID: При переборе серверов в апстриме просто их перебирать через proxy_next_upstream http_404 error timeout invalid_header; А тут придется делать это менее интересным способом, через множественные директивы error_page 404 error_page 502 error_page 503 и я не уверен, что все варианты из proxy_next_upstream покрываются таким способом. 30 июня 2015 г., 17:00 пользователь Panfilov Konstantin < error500 at error500.ru> написал: > > Вообще error_page единственно правильное решение > try_files для тех кому быстренько WP поднять надо > > только не забудьте включить *recursive_error_pages* on > > 30.06.2015 16:27, kpoxa пишет: > > Добрый день, коллеги. > > Есть задача сделать так: > 1. проверить есть ли файл локально. > 2. если нет, то проверить апстрим "горячий кеш", нет ли там файла. > 3. Если в горячем кеше нет, то проверить следующий апстрим. > > Вариант с > try_files $url @hot_cache @slow_cache > не работает, т.к. 2 именованных локейшена нельзя использовать. > > Вариант объединить все в один апстрим не очень хорош, т.к. надо проверить > сначала все горячие кеши, потом только холодные. > > Остаётся вариант с error_page 404 = @slow_cache в локейшене горячего кеша. > > Это единственный/лучший вариант решения подобной задачи? > Почему нельзя в try_files сделать возможность использования нескольких > именованых локешенов? > > -- > Рустам > > > _______________________________________________ > nginx-ru mailing listnginx-ru at nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Kpoxa -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue Jun 30 21:29:21 2015 From: nginx-forum at nginx.us (mailo) Date: Tue, 30 Jun 2015 17:29:21 -0400 Subject: =?UTF-8?B?0J3Rg9C20L3QsCDQv9C+0LzQvtGJ0Ywg0L/QviBtYXAgbW9kdWxlIHJlZ3VsYXIg?= =?UTF-8?B?ZXhwcmVzc2lvbg==?= Message-ID: <2ac9166d7f316c85ecacf9b7d5263294.NginxMailingListRussian@forum.nginx.org> Приветствую! нужна помощь по составлению map из регулярки. суть такая есть несколько аргументов , которые могут как присутствовать многократно с разными значениями, так и отсутствовать и находится в разном порядке. Вот пример мой map $args $args_for_cache_key2 { "~(?Parg1=[0-9]+(&arg2=[0-9]+)*(&arg3=[0-9]+)*(&arg4=[0-9]+)*)" $test2; default ""; } Все работает если только в строке значения попадаются именно в заданном порядке. например arg1=50&arg2=23&arg2=22&arg3=907077&arg4=4730 и в KEY в кеш падает вся строка как нужно, если же аргументы идут в хаотичном порядке, например arg1=50&arg3=23&arg2=22&arg3=907077&arg2=4730, тогда уже не работает как надо и в KEY попадает только arg1=50&arg3=23 и все.... Подскажите плиз )), никак не могу побороть это. Спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,260004,260004#msg-260004