From postmaster at softsearch.ru Fri May 1 09:58:41 2015 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 1 May 2015 12:58:41 +0300 Subject: nginx-1.9.0 In-Reply-To: <22718843.8ktbYSCAQW@note> References: <20150428154316.GI32429@mdounin.ru> <1719246.uqHqBrdbN3@note> <1987134.Yy55mS7sHN@vbart-laptop> <22718843.8ktbYSCAQW@note> Message-ID: <1219680482.20150501125841@softsearch.ru> Здравствуйте, Vadim. > ``` > map $cond1 $var1 { ... } > geo $var2 { ... } > if ($var1) { deny all; } > if ($var2 ~ "moo") { deny all; } > ``` firewall? -- С уважением, Михаил mailto:postmaster at softsearch.ru From semenukha at gmail.com Fri May 1 17:59:21 2015 From: semenukha at gmail.com (Styopa Semenukha) Date: Fri, 01 May 2015 13:59:21 -0400 Subject: (13: Permission denied) In-Reply-To: <7704724.ur0KseDbm3@note> References: <2270521.iSYunKQvYE@note> <073261e4708c8ec7db79d18cb619622e.NginxMailingListRussian@forum.nginx.org> <7704724.ur0KseDbm3@note> Message-ID: <4209030.sdtuPkIcHi@tornado> On Thursday, April 30, 2015 08:08:51 PM Vadim A. Misbakh-Soloviov wrote: > 1) НЕ СТОИТ делать "sudo su". Для этого есть sudo -s и sudo -i. Пользователь > указывается ключом -u. Совмещать эти команды ? моветон. Золотые слова. Откуда эти плеоназмы вообще пошли? Очень часто вижу у своих юзеров. -- Best regards, Styopa Semenukha. From marck at rinet.ru Fri May 1 18:38:23 2015 From: marck at rinet.ru (Dmitry Morozovsky) Date: Fri, 1 May 2015 21:38:23 +0300 (MSK) Subject: (13: Permission denied) In-Reply-To: <4209030.sdtuPkIcHi@tornado> References: <2270521.iSYunKQvYE@note> <073261e4708c8ec7db79d18cb619622e.NginxMailingListRussian@forum.nginx.org> <7704724.ur0KseDbm3@note> <4209030.sdtuPkIcHi@tornado> Message-ID: On Fri, 1 May 2015, Styopa Semenukha wrote: > On Thursday, April 30, 2015 08:08:51 PM Vadim A. Misbakh-Soloviov wrote: > > 1) НЕ СТОИТ делать "sudo su". Для этого есть sudo -s и sudo -i. Пользователь > > указывается ключом -u. Совмещать эти команды ? моветон. > > Золотые слова. Откуда эти плеоназмы вообще пошли? Очень часто вижу у своих > юзеров. Это от непонимания птого, что происходит с environment. Хотя, действительно, в стандартно настроенных линуксах проще сказать sudo su - чем затачивать дот-файлы... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck at FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From mva at mva.name Fri May 1 19:07:22 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Sat, 02 May 2015 01:07:22 +0600 Subject: (13: Permission denied) In-Reply-To: References: <2270521.iSYunKQvYE@note> <4209030.sdtuPkIcHi@tornado> Message-ID: <1954026.55cvViVtD3@note> > проще сказать > sudo su - 1) зачем тут sudo (точнее, а) какова вообще цель это команды в целом, б) если просто залогиниться по рутом с чистым окружением, то "зачем sudo", а если "не вводить пароль рута (за что уже надо бить по голове), то см. п.2)? ;) 2) чем это будет отличаться от sudo -i? :) > чем затачивать дот-файлы... ИМХО, unrelated. -- 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 konstantin at symbi.org Fri May 1 21:04:53 2015 From: konstantin at symbi.org (Konstantin Baryshnikov) Date: Sat, 2 May 2015 00:04:53 +0300 Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCDQvNC10LbQtNGDIEhUVFAg0Lgg?= =?UTF-8?B?RmFzdENHSSDQsdGN0LrQtdC90LTQsNC80Lg=?= In-Reply-To: <20150430134902.GC32429@mdounin.ru> References: <20150429122127.GV32429@mdounin.ru> <20150430134902.GC32429@mdounin.ru> Message-ID: On Apr 30, 2015, at 4:49 PM, Maxim Dounin wrote: > On Thu, Apr 30, 2015 at 06:06:05AM +0300, Konstantin Baryshnikov wrote: >> On Apr 29, 2015, at 3:21 PM, Maxim Dounin wrote: >> >>> location / { >>> if ($new) { >>> proxy_pass http://new.example.com; >>> } >>> >>> fastcgi_pass old.example.com; >>> } >>> } >> >> Ого, а это теперь работает? >> >> Всегда считал это гарантированным способом отстрелить себе ногу. Что-то изменилось? > > Вот конкретно приведённая конструкция - работает, и без каких-либо > проблем. И, собственно, всегда работала. Но если конфиг будет > чуть сложнее - то нога в опасности, да. Подробнее про опасности > расписано вот тут: > > http://wiki.nginx.org/IfIsEvil Ага, все как было, ясненько, спасибо. Вообще у нас введено правило ?if используем только с директивами rewrite-модуля?, так оно и надежнее, и сумасшедшие запутанные конфигурации нагородить не позволяет. P. S. Лет 5 назад у меня была идея для решения проблемы IfIsEvil попробовать перенести if-ы на уровень location-ов (включая вложенные), вида location /foo/ when ($new) { ... } но почитал исходники и понял, что это не очень просто :-) From nginx-forum at nginx.us Sun May 3 13:14:17 2015 From: nginx-forum at nginx.us (mycopwuk) Date: Sun, 03 May 2015 09:14:17 -0400 Subject: =?UTF-8?B?0YHQsNC50YIg0L/QviDRg9C80L7Qu9GH0LDQvdC40Y4=?= Message-ID: Здравствуйте, я новичок и сайты не мой профиль, не судите строго за глупый вопрос. запустил дома хранилище, сделал конфиг nginx, такой вопрос, у меня сейчас облако открывается по адресу https://мой домен.ru/облако, а хочу чтоб открывалось просто по адресу https://мой домен.ru, сейчас само собой выскакивает сообщение nginxa 403 Forbidden Как сделать это? Спасибо огромное за помощь. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258584,258584#msg-258584 From nginx-forum at nginx.us Mon May 4 13:03:11 2015 From: nginx-forum at nginx.us (WolfTheGrey) Date: Mon, 04 May 2015 09:03:11 -0400 Subject: =?UTF-8?B?0JrRjdGI0LjRgNC+0LLQsNC90LjQtSDQvdCwIHRtcGZz?= Message-ID: <550f65891e290b321fbe6fd37dfeb022.NginxMailingListRussian@forum.nginx.org> Здравствуйте, Помогите, пожалуйста. Пролема с настройками кэширования, которую никак не могу победить - не создаются файлы в кэше. Создан tmpfs раздел на 512 мегабайт, примонтирован в /var/cache/nginx/img/. Временная папка nginx на нём создается без проблем при перезапуске nginx. Права на папку кэша (/var/cache/nginx/) и вложенные 777, владельцем выставлен пользователь, от имени которого запущен nginx www-data:www-data. Права и владелец применялись рекурсивно. Сервер будет раздавать большое количество картинок формата jpg,png - их и нужно кэшировать Стоит связка nginx (1.2.1 из Debian7) + apache + php Конфиг прописан следующий server { listen 80; server_name example.com; access_log /home/example/log/nginx_access.log; error_log /home/example/log/nginx_error.log debug; proxy_ignore_headers "Expires" "Cache-Control" "Set-Cookie"; location / { proxy_pass http://127.0.0.1:81; include /etc/nginx/conf.d/proxy.conf; } location ~* \.(gif|css|ico|bmp|swf|js)$ { root /home/example/public_html/; } location ~* \.(jpg|jpeg|png)$ { root /home/example/public_html/; proxy_cache img; proxy_cache_valid 200 304 1d; proxy_cache_min_uses 1; } } nginx.conf user www-data; worker_processes 4; pid /var/run/nginx.pid; events { worker_connections 768; # multi_accept on; } http { ## # Basic Settings ## client_max_body_size 100m; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; # server_tokens off; # server_names_hash_bucket_size 64; # server_name_in_redirect off; include /etc/nginx/mime.types; default_type application/octet-stream; ## # Logging Settings ## access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; ## # Gzip Settings ## gzip on; gzip_disable "msie6"; # gzip_vary on; # gzip_proxied any; # gzip_comp_level 6; # gzip_buffers 16 8k; # gzip_http_version 1.1; # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; ## # nginx-naxsi config ## # Uncomment it if you installed nginx-naxsi ## #include /etc/nginx/naxsi_core.rules; ## # nginx-passenger config ## # Uncomment it if you installed nginx-passenger ## #passenger_root /usr; #passenger_ruby /usr/bin/ruby; ## # Virtual Host Configs ## proxy_cache_path /var/cache/nginx/img levels=1:2 keys_zone=img:64m inactive=3d max_size=450m; proxy_temp_path /var/cache/nginx/img/temp; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } Курение debug лога ничего не дает. Ни слова о cache при запросе картинки, но видно что выбирается нужная конфигурация using configuration "\.(jpg|jpeg|png)$" При прямом запросе картинки ответ от сервера получаю от nginx 200 или 304 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258607,258607#msg-258607 From postmaster at softsearch.ru Mon May 4 13:18:21 2015 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 4 May 2015 16:18:21 +0300 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0L3QsCB0bXBmcw==?= In-Reply-To: <550f65891e290b321fbe6fd37dfeb022.NginxMailingListRussian@forum.nginx.org> References: <550f65891e290b321fbe6fd37dfeb022.NginxMailingListRussian@forum.nginx.org> Message-ID: <1204374437.20150504161821@softsearch.ru> Здравствуйте, WolfTheGrey. Файлы, которые должны кэшироваться в tmpfs и так кэшировались бы в оперативке силами операционной системы. Так что класть их в tmpfs не имеет смысла. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Mon May 4 13:48:50 2015 From: nginx-forum at nginx.us (WolfTheGrey) Date: Mon, 04 May 2015 09:48:50 -0400 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0L3QsCB0bXBmcw==?= In-Reply-To: <1204374437.20150504161821@softsearch.ru> References: <1204374437.20150504161821@softsearch.ru> Message-ID: Здравствуйте, Михаил. Спасибо за ответ, с данной позицией я уже сталкивался в интернете. Я не владею подробностями как работает кэширование файлов со стороны ядра Linux. Но как я понимаю разница будет в том, что со стороны кэширования Nginx этот процесс более управляемый. Например, можно задать proxy_cache_min_uses и proxy_cache_valid, тем самым насильно хранить в кэше наиболее востребованные файлы. Указанные в конфиге значения ряда переменных чисто тестовые, ряд из них специально уменьшен. Для остальных, менее загружаемых файлов, на сервере остается прилично свободной оперативки под кэш силами операционки. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258607,258611#msg-258611 From mva at mva.name Mon May 4 14:07:29 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Mon, 04 May 2015 20:07:29 +0600 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0L3QsCB0bXBmcw==?= In-Reply-To: References: <1204374437.20150504161821@softsearch.ru> Message-ID: <8675521.Q1Gj3h6C3l@note> В письме от Пн, 4 мая 2015 09:48:50 пользователь WolfTheGrey написал: > Здравствуйте, Михаил. > > Спасибо за ответ, с данной позицией я уже сталкивался в интернете. > > Я не владею подробностями как работает кэширование файлов со стороны ядра Вот именно поэтому вам и приходит в голову идея делать то, что не нужно :) > тем самым насильно хранить в кэше наиболее востребованные файлы. Именно так оно и происходит с кешем большинства файловых систем, будь то Ext4, XFS (тут в особенности), btrfs, тысячи их. > Указанные в конфиге значения ряда переменных чисто тестовые, ряд из них > специально уменьшен. Да, только почему-то у вас в локейшене со статикой (картинками) указаны cache- директивы от proxy модуля... При том, что картинки берутся NgX'ом напрямую с файловой системы, а не выкачиваются из прокси (что, к слову, было бы верхом глупости и лишь вносило бы дополнительные задержки). Ну и вообще. В вашем "сетапе", я, почему-то, более, чем уверен, Apache, с большой долей вероятности, не нужен как таковой. Равно как и использование proxy-модуля в 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 nginx.org at dubrovskiy.net Mon May 4 14:14:27 2015 From: nginx.org at dubrovskiy.net (Ivan) Date: Mon, 04 May 2015 17:14:27 +0300 Subject: =?UTF-8?B?TkdJTlgg0LIg0LrQsNGH0LXRgdGC0LLQtSBodHRwL2h0dHBzLdC/0YDQvtC60YE=?= =?UTF-8?B?0Lg=?= Message-ID: Здравствуйте, уважаемые знатоки! Помогите, пожалуйста, в таком тривиальном на первый взгляд, вопросе, как настройка NGINX в качестве http/https-прокси наподобие squid. Как http-прокси настроил в два счёта, а вот https приручить не могу. Конфиг: server { listen *:8888; listen [::]:8888; server_name ""; access_log /tmp/proxy.access.log combined buffer=64k flush=5m; error_log /tmp/proxy.error.log; resolver 127.0.0.1; allow 192.168.0.0/16; deny all; location / { proxy_pass $scheme://$host; proxy_cache off; proxy_redirect off; # proxy_ssl_verify off; # По-дефолту и так OFF # proxy_set_header Host $host; # Оказалось, что сам подставляет заголовок host proxy_pass_header Set-Cookie; } } В журнале ошибок вообще пусто, а в access: 123.45.67.89 - - [04/May/2015:17:00:46 +0300] "CONNECT yandex.ru:443 HTTP/1.1" 400 166 "-" "-" 123.45.67.89 - - [04/May/2015:17:00:46 +0300] "CONNECT vk.com:443 HTTP/1.1" 400 166 "-" "-" даже заголовков агента браузера нет. меня смущает метод CONNECT... Подскажите, что стоит на Ваш взгяд ещё добавить, кроме кеширования - оно не нужно. From mdounin at mdounin.ru Mon May 4 14:22:27 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 4 May 2015 17:22:27 +0300 Subject: =?UTF-8?B?UmU6IE5HSU5YINCyINC60LDRh9C10YHRgtCy0LUgaHR0cC9odHRwcy3Qv9GA0L4=?= =?UTF-8?B?0LrRgdC4?= In-Reply-To: References: Message-ID: <20150504142226.GQ32429@mdounin.ru> Hello! On Mon, May 04, 2015 at 05:14:27PM +0300, Ivan wrote: > Здравствуйте, уважаемые знатоки! > Помогите, пожалуйста, в таком тривиальном на первый взгляд, вопросе, как > настройка NGINX в качестве http/https-прокси наподобие squid. > Как http-прокси настроил в два счёта, а вот https приручить не могу. Конфиг: Ответ столь же тривиален, как и вопрос: nginx не является forward proxy, работать не будет. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Mon May 4 20:31:16 2015 From: nginx-forum at nginx.us (WolfTheGrey) Date: Mon, 04 May 2015 16:31:16 -0400 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0L3QsCB0bXBmcw==?= In-Reply-To: <8675521.Q1Gj3h6C3l@note> References: <8675521.Q1Gj3h6C3l@note> Message-ID: <271199ce8ac8a673463a9562c8d973e7.NginxMailingListRussian@forum.nginx.org> mva Wrote: ------------------------------------------------------- > В письме от Пн, 4 мая 2015 09:48:50 пользователь WolfTheGrey написал: > > Здравствуйте, Михаил. > > > > Спасибо за ответ, с данной позицией я уже сталкивался в интернете. > > > > Я не владею подробностями как работает кэширование файлов со стороны > ядра > Вот именно поэтому вам и приходит в голову идея делать то, что не > нужно :) Спасибо, наставили на пусть истинный. :) > > тем самым насильно хранить в кэше наиболее востребованные файлы. > Именно так оно и происходит с кешем большинства файловых систем, будь > то Ext4, > XFS (тут в особенности), btrfs, тысячи их. > > Указанные в конфиге значения ряда переменных чисто тестовые, ряд из > них > > специально уменьшен. > Да, только почему-то у вас в локейшене со статикой (картинками) > указаны cache- > директивы от proxy модуля... При том, что картинки берутся NgX'ом > напрямую с > файловой системы, а не выкачиваются из прокси (что, к слову, было бы > верхом > глупости и лишь вносило бы дополнительные задержки). > > > Ну и вообще. В вашем "сетапе", я, почему-то, более, чем уверен, > Apache, с > большой долей вероятности, не нужен как таковой. Равно как и > использование > proxy-модуля в NginX. > Apache действительно особо не нужен. Наследие от начала эксплуатации сервера. Я с ним хорошо знаком. А с nginx только начинаю вести знакомство. > Ну и доверьте, всё же, кеширование статики файловой системе и > освободите себя > от этой головной боли. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258607,258625#msg-258625 From nginx-forum at nginx.us Tue May 5 06:14:00 2015 From: nginx-forum at nginx.us (sidewinder) Date: Tue, 05 May 2015 02:14:00 -0400 Subject: (13: Permission denied) In-Reply-To: <7704724.ur0KseDbm3@note> References: <7704724.ur0KseDbm3@note> Message-ID: <98ceb9ec0366dafa85776e0c6a73c5b6.NginxMailingListRussian@forum.nginx.org> Спасибо. Видимо действительно причина в SELinux. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258537,258627#msg-258627 From nginx-forum at nginx.us Tue May 5 06:51:33 2015 From: nginx-forum at nginx.us (skywww) Date: Tue, 05 May 2015 02:51:33 -0400 Subject: =?UTF-8?B?0J7QsdC90L7QstC40YLRjCDRg9C20LUg0YHRg9GJ0LXRgdGC0LLRg9GO0YnQuNC5?= =?UTF-8?B?IFNTTCDRgdC10YDRgtC40YTQuNC60LDRgg==?= Message-ID: Добрый день, коллеги. Есть действующий сервер Nginx с SSL сертификатом для сайта на нем. SSL сертификат скоро закончится. Сейчас все работает, в файле настроек сайта mysite.conf прописаны настройки: ssl_certificate, ssl_certificate_key и ssl_crl. Как правильно его обновить ? В интернете нашел инструкции как сгенерировать все с нуля, но при этом будет сгенерирован и новый секретный ключ. Это единственный способ ? Помогите пожалуйста, в nginx совсем новичок. Спасибо заранее. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258628,258628#msg-258628 From onokonem at gmail.com Tue May 5 06:59:55 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Tue, 5 May 2015 09:59:55 +0300 Subject: =?UTF-8?B?UmU6INCe0LHQvdC+0LLQuNGC0Ywg0YPQttC1INGB0YPRidC10YHRgtCy0YPRjtGJ?= =?UTF-8?B?0LjQuSBTU0wg0YHQtdGA0YLQuNGE0LjQutCw0YI=?= In-Reply-To: References: Message-ID: > В интернете нашел инструкции как сгенерировать все с нуля, но при этом будет > сгенерирован и новый секретный ключ. Это единственный способ ? Если почитать инструкцию внимательно - там сначала генерируется новый секретный ключ, а потом - certificate request, csr. раз ключ у вас уже есть - переходите сразу к генерации csr From nginx-forum at nginx.us Tue May 5 07:20:36 2015 From: nginx-forum at nginx.us (skywww) Date: Tue, 05 May 2015 03:20:36 -0400 Subject: =?UTF-8?B?UmU6INCe0LHQvdC+0LLQuNGC0Ywg0YPQttC1INGB0YPRidC10YHRgtCy0YPRjtGJ?= =?UTF-8?B?0LjQuSBTU0wg0YHQtdGA0YLQuNGE0LjQutCw0YI=?= In-Reply-To: References: Message-ID: <54ce60c897956a51ff53da91eae3e3f7.NginxMailingListRussian@forum.nginx.org> Не могли бы написать/дать ссылку - как именно это следует делать ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258628,258633#msg-258633 From alex.hha at gmail.com Tue May 5 07:25:12 2015 From: alex.hha at gmail.com (Alex Domoradov) Date: Tue, 5 May 2015 10:25:12 +0300 Subject: =?UTF-8?B?UmU6INCe0LHQvdC+0LLQuNGC0Ywg0YPQttC1INGB0YPRidC10YHRgtCy0YPRjtGJ?= =?UTF-8?B?0LjQuSBTU0wg0YHQtdGA0YLQuNGE0LjQutCw0YI=?= In-Reply-To: <54ce60c897956a51ff53da91eae3e3f7.NginxMailingListRussian@forum.nginx.org> References: <54ce60c897956a51ff53da91eae3e3f7.NginxMailingListRussian@forum.nginx.org> Message-ID: http://sys-adm.org.ua/security/ssl-howto читаем раздел - "Создание запроса на подпись сертификата" Либо можно одной командой сгенерировать и ключ и сертификат # openssl req -nodes -sha256 -newkey rsa:4096 -keyout www.example.net.key -out www.example.net.csr 2015-05-05 10:20 GMT+03:00 skywww : > Не могли бы написать/дать ссылку - как именно это следует делать ? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,258628,258633#msg-258633 > > _______________________________________________ > 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 Tue May 5 07:25:42 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Tue, 5 May 2015 10:25:42 +0300 Subject: =?UTF-8?B?UmU6INCe0LHQvdC+0LLQuNGC0Ywg0YPQttC1INGB0YPRidC10YHRgtCy0YPRjtGJ?= =?UTF-8?B?0LjQuSBTU0wg0YHQtdGA0YLQuNGE0LjQutCw0YI=?= In-Reply-To: <54ce60c897956a51ff53da91eae3e3f7.NginxMailingListRussian@forum.nginx.org> References: <54ce60c897956a51ff53da91eae3e3f7.NginxMailingListRussian@forum.nginx.org> Message-ID: 2015-05-05 10:20 GMT+03:00 skywww : > Не могли бы написать/дать ссылку - как именно это следует делать ? ну, к примеру, вот: http://www.westphahl.net/blog/2012/01/03/setting-up-https-with-nginx-and-startssl/ заветная команда (только имена файлов поправьте): openssl req -new -key example.com_secure.key -out example.com.csr From nginx-forum at nginx.us Tue May 5 07:55:52 2015 From: nginx-forum at nginx.us (skywww) Date: Tue, 05 May 2015 03:55:52 -0400 Subject: =?UTF-8?B?UmU6INCe0LHQvdC+0LLQuNGC0Ywg0YPQttC1INGB0YPRidC10YHRgtCy0YPRjtGJ?= =?UTF-8?B?0LjQuSBTU0wg0YHQtdGA0YLQuNGE0LjQutCw0YI=?= In-Reply-To: References: Message-ID: Daniel Podolsky Wrote: ------------------------------------------------------- > заветная команда (только имена файлов поправьте): > openssl req -new -key example.com_secure.key -out example.com.csr Подскажите по этой команде - в ней указано "-new -key example.com_secure.key" - это разве не означает, что будет создан новый секретный ключ? По ссылке http://sys-adm.org.ua/security/ssl-howto аналогично приводится инструкция по созданию нового секретного ключа и запроса на сертификат. Изначальный вопрос - а можно ли сохранить текущий секретный ключ (обновив только сертификат) ? Как будет выглядеть команда в этом случае ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258628,258639#msg-258639 From alex.hha at gmail.com Tue May 5 08:05:30 2015 From: alex.hha at gmail.com (Alex Domoradov) Date: Tue, 5 May 2015 11:05:30 +0300 Subject: =?UTF-8?B?UmU6INCe0LHQvdC+0LLQuNGC0Ywg0YPQttC1INGB0YPRidC10YHRgtCy0YPRjtGJ?= =?UTF-8?B?0LjQuSBTU0wg0YHQtdGA0YLQuNGE0LjQutCw0YI=?= In-Reply-To: References: Message-ID: А в чем глубокий смысл использовать старый private key? Я в целях безопасности всегда меняю ключ, при выпуске нового сертификата. # openssl req -new -key existing_private.key -out www.example.net.csr P.S. а что, google уже забанили? 2015-05-05 10:55 GMT+03:00 skywww : > Daniel Podolsky Wrote: > ------------------------------------------------------- > > заветная команда (только имена файлов поправьте): > > openssl req -new -key example.com_secure.key -out example.com.csr > > Подскажите по этой команде - в ней указано "-new -key > example.com_secure.key" - это разве не означает, что будет создан новый > секретный ключ? > > По ссылке http://sys-adm.org.ua/security/ssl-howto аналогично приводится > инструкция по созданию нового секретного ключа и запроса на сертификат. > > Изначальный вопрос - а можно ли сохранить текущий секретный ключ (обновив > только сертификат) ? > > Как будет выглядеть команда в этом случае ? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,258628,258639#msg-258639 > > _______________________________________________ > 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 May 5 08:13:06 2015 From: nginx-forum at nginx.us (skywww) Date: Tue, 05 May 2015 04:13:06 -0400 Subject: =?UTF-8?B?UmU6INCe0LHQvdC+0LLQuNGC0Ywg0YPQttC1INGB0YPRidC10YHRgtCy0YPRjtGJ?= =?UTF-8?B?0LjQuSBTU0wg0YHQtdGA0YLQuNGE0LjQutCw0YI=?= In-Reply-To: References: Message-ID: <200d537ff04772d3159e3d9eaa4f5639.NginxMailingListRussian@forum.nginx.org> > А в чем глубокий смысл использовать старый private key? Я в целях > безопасности всегда меняю ключ, при выпуске нового сертификата. > > # openssl req -new -key existing_private.key -out www.example.net.csr > > P.S. > а что, google уже забанили? Собственно вопрос и возник из-за того, что не смог найти в Интернете как это сделать, сохранив старый секретный ключ. Если у Вас есть ссылка/опыт, как это сделать, то поделитесь пожалуйста. То что можно это сделать, сгенерировав новый секретный ключ мне понятно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258628,258641#msg-258641 From nginx-forum at nginx.us Tue May 5 08:15:02 2015 From: nginx-forum at nginx.us (skywww) Date: Tue, 05 May 2015 04:15:02 -0400 Subject: =?UTF-8?B?UmU6INCe0LHQvdC+0LLQuNGC0Ywg0YPQttC1INGB0YPRidC10YHRgtCy0YPRjtGJ?= =?UTF-8?B?0LjQuSBTU0wg0YHQtdGA0YLQuNGE0LjQutCw0YI=?= In-Reply-To: <200d537ff04772d3159e3d9eaa4f5639.NginxMailingListRussian@forum.nginx.org> References: <200d537ff04772d3159e3d9eaa4f5639.NginxMailingListRussian@forum.nginx.org> Message-ID: Перечитал еще раз - понял - вы имели в виду использовать команду key вмсето newkey. Ушел тестировать :-). Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258628,258642#msg-258642 From nginx-forum at nginx.us Tue May 5 08:42:46 2015 From: nginx-forum at nginx.us (skywww) Date: Tue, 05 May 2015 04:42:46 -0400 Subject: =?UTF-8?B?UmU6INCe0LHQvdC+0LLQuNGC0Ywg0YPQttC1INGB0YPRidC10YHRgtCy0YPRjtGJ?= =?UTF-8?B?0LjQuSBTU0wg0YHQtdGA0YLQuNGE0LjQutCw0YI=?= In-Reply-To: References: Message-ID: День добрый еще раз. Вроде бы все получилось - файл запроса сгенерировался. Единственный момент - на нашем внутреннем CA (корпоративном) не могу протестировать - при попытке прикрепления запроса выдает ошибку - "Указан неправильный алгоритм 0x80090008". Это может быть из-за того, что внутренний CA на Windows ? или что-то неверно указал в запросе ? (делал командой openssl req -new -key my_existing_secret.key -out my_new.csr в консоли OpenSSL и затем вводил параметры серптификата в запросе: страна, регион, город и пр.). Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258628,258645#msg-258645 From onokonem at gmail.com Tue May 5 08:49:20 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Tue, 5 May 2015 11:49:20 +0300 Subject: =?UTF-8?B?UmU6INCe0LHQvdC+0LLQuNGC0Ywg0YPQttC1INGB0YPRidC10YHRgtCy0YPRjtGJ?= =?UTF-8?B?0LjQuSBTU0wg0YHQtdGA0YLQuNGE0LjQutCw0YI=?= In-Reply-To: References: Message-ID: > Это может быть из-за того, что внутренний CA на Windows ? или что-то неверно > указал в запросе ? это может быть из-за того, что ваша CA не принимает PEM формат. это может быть из-за того, что тот алгоритм, что используется вашей инсталляцией openssl по умолчанию, не нравится вашей CA это может быть еще из-за десятка вещей скажите, почему вы используете эту рассылку так, как используете? From nginx-forum at nginx.us Tue May 5 09:03:13 2015 From: nginx-forum at nginx.us (skywww) Date: Tue, 05 May 2015 05:03:13 -0400 Subject: =?UTF-8?B?UmU6INCe0LHQvdC+0LLQuNGC0Ywg0YPQttC1INGB0YPRidC10YHRgtCy0YPRjtGJ?= =?UTF-8?B?0LjQuSBTU0wg0YHQtdGA0YLQuNGE0LjQutCw0YI=?= In-Reply-To: References: Message-ID: <541e3fbe7695525ba901933a16ec9b4f.NginxMailingListRussian@forum.nginx.org> > это может быть из-за того, что ваша CA не принимает PEM формат. > это может быть из-за того, что тот алгоритм, что используется вашей > инсталляцией openssl по умолчанию, не нравится вашей CA > это может быть еще из-за десятка вещей > > скажите, почему вы используете эту рассылку так, как используете? Понял, спасибо. По поводу рассылки не понял. Делаю что-то не так ? Я предположил, что это форум и могу задать здесь вопрос по ПО nginx. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258628,258651#msg-258651 From onokonem at gmail.com Tue May 5 09:08:33 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Tue, 5 May 2015 12:08:33 +0300 Subject: =?UTF-8?B?UmU6INCe0LHQvdC+0LLQuNGC0Ywg0YPQttC1INGB0YPRidC10YHRgtCy0YPRjtGJ?= =?UTF-8?B?0LjQuSBTU0wg0YHQtdGA0YLQuNGE0LjQutCw0YI=?= In-Reply-To: <541e3fbe7695525ba901933a16ec9b4f.NginxMailingListRussian@forum.nginx.org> References: <541e3fbe7695525ba901933a16ec9b4f.NginxMailingListRussian@forum.nginx.org> Message-ID: > Я предположил, что это форум и могу задать здесь вопрос по ПО nginx. это не форум, это почтовая рассылка. ну и вопросы ваши к nginx не имеют отношения от слова "вообще" From nginx-forum at nginx.us Wed May 6 10:39:33 2015 From: nginx-forum at nginx.us (vlakas) Date: Wed, 06 May 2015 06:39:33 -0400 Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?= =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?= In-Reply-To: <553F79BB.3020306@nginx.com> References: <553F79BB.3020306@nginx.com> Message-ID: <2c6cd870f0e532ab2575f720db2b7e27.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Дебаг лог, во время повторения инцидента можно получить по ссылке: https://mega.co.nz/#!VI5DBbiI!GZDPBbfkyTCCmY8J0r9KFuov4UYldNegvN1SvtOYPVs (1.3 GB) Проблема была обнаружена 5 мая около 22:50 (лог в себ включает сообщения на временном промежутке 22:45 - 22:55). В самом логе вижу множество следующих сообщений: 2015/05/05 22:49:42 [debug] 6696#0: http file cache forced expire: #1 1 31dd5198 2015/05/05 22:49:42 [debug] 6696#0: http file cache forced expire: #1 1 bdb466de 2015/05/05 22:49:42 [debug] 6696#0: http file cache forced expire: #1 1 3207dd39 2015/05/05 22:49:42 [debug] 6696#0: http file cache forced expire: #1 1 b417f542 2015/05/05 22:49:42 [debug] 6696#0: http file cache forced expire: #1 1 14a73e73 При чем неоднократно повторяющихся. Если искать по hash id (напр., 31dd5198), нахожу только эти сообщения и ничего больше. Меня интересует, что в вышеприведенных логах означает 4-е поле (6696#0). Могу предположить, что это привязка к процессу cache manager, но не уверен. Если фильтровать логи по этому полю, нахожу следующее: 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock 2015/05/05 22:48:16 [debug] 6696#0: shmtx wake 634 2015/05/05 22:48:16 [debug] 6696#0: http file cache size: 20975604 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire 2015/05/05 22:48:16 [debug] 6696#0: malloc: 00000000026BAA20:65 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire: #0 1 a3397f6c 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock Я так понимаю, это удачная очистка кеша. И следующее: 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock 2015/05/05 22:48:16 [debug] 6696#0: shmtx wake 625 2015/05/05 22:48:16 [debug] 6696#0: http file cache size: 20975581 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire 2015/05/05 22:48:16 [debug] 6696#0: malloc: 00000000026BAA20:65 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire: #1 1 dd87e60a 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire: #0 1 93a2ff07 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock И еще: 2015/05/05 22:48:16 [debug] 6696#0: shmtx wake 571 2015/05/05 22:48:16 [debug] 6696#0: http file cache expire: "/opt2/nginx-cache-images1/2f/ee/093821fba4c1bf6f947a291d0dcfee2f" 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock 2015/05/05 22:48:16 [debug] 6696#0: slab free: 00007F66BE5FF380 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock 2015/05/05 22:48:16 [debug] 6696#0: shmtx wake 570 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock 2015/05/05 22:48:16 [debug] 6696#0: shmtx wake 569 2015/05/05 22:48:16 [debug] 6696#0: http file cache size: 20975519 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire 2015/05/05 22:48:16 [debug] 6696#0: malloc: 00000000026BAA20:65 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire: #1 1 dd87e60a 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire: #1 1 8bc7932f 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire: #0 1 91e3b5df 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock Во время инцидента с uptime'мом воркеров аномалий не обнаружено. P.S. Такая же версия nginx работает также на Ubuntu 12 LTS. В этом случае проблем не было обнаружено. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258679#msg-258679 From nginx-forum at nginx.us Wed May 6 10:45:54 2015 From: nginx-forum at nginx.us (vlakas) Date: Wed, 06 May 2015 06:45:54 -0400 Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?= =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?= In-Reply-To: <2c6cd870f0e532ab2575f720db2b7e27.NginxMailingListRussian@forum.nginx.org> References: <553F79BB.3020306@nginx.com> <2c6cd870f0e532ab2575f720db2b7e27.NginxMailingListRussian@forum.nginx.org> Message-ID: <50a51919c2a7094d7617dca6b1e40ec0.NginxMailingListRussian@forum.nginx.org> Еще доп. информация. Тут было упомянуто, что cache manager делает порядка 20 попыток удалить "устаревший" кеш. Хотя если искать, скажем по hash id 31dd5198 (http file cache forced expire: #1 1 31dd5198), за 10 мин. логов нахожу 515 сообщений такого рода. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258680#msg-258680 From arut at nginx.com Wed May 6 12:56:38 2015 From: arut at nginx.com (Roman Arutyunyan) Date: Wed, 6 May 2015 15:56:38 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?= =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?= In-Reply-To: <50a51919c2a7094d7617dca6b1e40ec0.NginxMailingListRussian@forum.nginx.org> References: <553F79BB.3020306@nginx.com> <2c6cd870f0e532ab2575f720db2b7e27.NginxMailingListRussian@forum.nginx.org> <50a51919c2a7094d7617dca6b1e40ec0.NginxMailingListRussian@forum.nginx.org> Message-ID: <12A29DC9-0F41-4F52-8ECA-AE057BDADED8@nginx.com> On 06 May 2015, at 13:45, vlakas wrote: > Еще доп. информация. > > Тут было упомянуто, что cache manager делает порядка 20 попыток удалить > "устаревший" кеш. Хотя если искать, скажем по hash id 31dd5198 (http file > cache forced expire: #1 1 31dd5198), за 10 мин. логов нахожу 515 сообщений > такого рода. Имелось в виду, что за один раз он делает 20 попыток. From maxim at nginx.com Wed May 6 20:09:31 2015 From: maxim at nginx.com (Maxim Konovalov) Date: Wed, 06 May 2015 23:09:31 +0300 Subject: Fwd: nginx.conf 2015 CFP is open In-Reply-To: References: Message-ID: <554A74FB.3040409@nginx.com> Добрый день! В сентябре 2015 года мы проводим вторую конференцию про nginx. Ниже call for papers для потенциальных докладчиков. -------- Forwarded Message -------- Subject: nginx.conf 2015 CFP is open Date: Wed, 6 May 2015 12:04:24 -0700 From: Sarah Novotny Reply-To: nginx at nginx.org To: nginx at nginx.org, nginx-devel at nginx.org nginx.conf 2015 Join us at Fort Mason in San Francisco from September 22-24, 2015. Submit a proposal to nginx.conf 2015! TL;DR ? Speaker proposals due: 11:59 PM PDT, June 2, 2015 ? Speakers notified: early July, 2015 ? Program schedule announced: late July, 2015 As a member of the NGINX community, you?re probably passionate about web performance, security, reliability, and scale. We?re excited to offer you the opportunity to teach (and learn from) your peers as a speaker at nginx.conf 2015 (September 22-24 in San Francisco). Please share with us how you and your company make the web speed along, instantly offering our always-on-society highly personalized and ever more creative experiences. Tell us how you solved an intractable scaling problem or shaved milliseconds (or seconds) off an RTT. Blog Post - http://nginx.com/blog/nginx-conf-2015-call-proposals-now-open/ CFP - https://nginxconf15.busyconf.com/proposals/new Twitter - https://twitter.com/nginxorg/status/596012137610260481 We want to hear your NGINX story! Sarah -- Maxim Konovalov http://nginx.com From sarah at nginx.com Wed May 6 23:54:30 2015 From: sarah at nginx.com (Sarah Novotny) Date: Wed, 6 May 2015 16:54:30 -0700 Subject: Fwd: nginx.conf 2015 CFP is open References: Message-ID: <752A02C4-A6A5-4C88-ABBE-F24DD14BDE83@nginx.com> I hope some of you will be able to join us. Sarah > Begin forwarded message: > > From: Sarah Novotny > > Subject: nginx.conf 2015 CFP is open > Date: May 6, 2015 at 12:04:24 PM PDT > > > nginx.conf 2015 > > Join us at Fort Mason in San Francisco from September 22-24, 2015. > > Submit a proposal to nginx.conf 2015! > > TL;DR > > ? Speaker proposals due: 11:59 PM PDT, June 2, 2015 > ? Speakers notified: early July, 2015 > ? Program schedule announced: late July, 2015 > > As a member of the NGINX community, you?re probably passionate about web performance, security, reliability, and scale. We?re excited to offer you the opportunity to teach (and learn from) your peers as a speaker at nginx.conf 2015 (September 22-24 in San Francisco). Please share with us how you and your company make the web speed along, instantly offering our always-on-society highly personalized and ever more creative experiences. Tell us how you solved an intractable scaling problem or shaved milliseconds (or seconds) off an RTT. > > Blog Post - http://nginx.com/blog/nginx-conf-2015-call-proposals-now-open/ > CFP - https://nginxconf15.busyconf.com/proposals/new > Twitter - https://twitter.com/nginxorg/status/596012137610260481 > > We want to hear your NGINX story! > > Sarah > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arut at nginx.com Thu May 7 05:58:57 2015 From: arut at nginx.com (Roman Arutyunyan) Date: Thu, 7 May 2015 08:58:57 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?= =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?= In-Reply-To: <2c6cd870f0e532ab2575f720db2b7e27.NginxMailingListRussian@forum.nginx.org> References: <553F79BB.3020306@nginx.com> <2c6cd870f0e532ab2575f720db2b7e27.NginxMailingListRussian@forum.nginx.org> Message-ID: <65E1AFEE-A86A-4487-9010-6E2E709C513E@nginx.com> On 06 May 2015, at 13:39, vlakas wrote: > Здравствуйте. > > Дебаг лог, во время повторения инцидента можно получить по ссылке: > https://mega.co.nz/#!VI5DBbiI!GZDPBbfkyTCCmY8J0r9KFuov4UYldNegvN1SvtOYPVs > (1.3 GB) > > Проблема была обнаружена 5 мая около 22:50 (лог в себ включает сообщения на > временном промежутке 22:45 - 22:55). Какое время прошло от старта nginx? Судя по логу, вы релоадили nginx и, вероятно, даже меняли число воркеров. Это так? Если этого не делать, проблема также появляется? > В самом логе вижу множество следующих сообщений: > 2015/05/05 22:49:42 [debug] 6696#0: http file cache forced expire: #1 1 > 31dd5198 > 2015/05/05 22:49:42 [debug] 6696#0: http file cache forced expire: #1 1 > bdb466de > 2015/05/05 22:49:42 [debug] 6696#0: http file cache forced expire: #1 1 > 3207dd39 > 2015/05/05 22:49:42 [debug] 6696#0: http file cache forced expire: #1 1 > b417f542 > 2015/05/05 22:49:42 [debug] 6696#0: http file cache forced expire: #1 1 > 14a73e73 > > При чем неоднократно повторяющихся. Если искать по hash id (напр., > 31dd5198), нахожу только эти сообщения и ничего больше. Это и есть основная проблема. У вас есть возможность поискать эту строку в более ранних логах? Cache manager очищает кеш в порядке lru, так что этот файл появился в кеше некоторое время назад и успел с тех пор стать самым старым. Что касается поиска файла, соответствующего ключу, я вам в прошлый раз дал не совсем верный алгоритм. Надо искать чуть иначе, вот пример из вашего же лога: 2015/05/05 22:45:33 [debug] 6696#0: http file cache forced expire: #0 1 b139cb65 2015/05/05 22:45:33 [debug] 6696#0: http file cache expire: "/opt2/nginx-cache-images1/c8/de/0ac4a89e20a39c1fb139cb65c2ffdec8" b139cb65 -> /opt2/nginx-cache-images1/c8/de/0ac4a89e20a39c1f b139cb65 c2ffdec8 > Меня интересует, что в вышеприведенных логах означает 4-е поле (6696#0). > Могу предположить, что это привязка к процессу cache manager, но не уверен. Это pid процесса (на ?#0' не обращайте внимания). > Если фильтровать логи по этому полю, нахожу следующее: > 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock > 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock > 2015/05/05 22:48:16 [debug] 6696#0: shmtx wake 634 > 2015/05/05 22:48:16 [debug] 6696#0: http file cache size: 20975604 > 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire > 2015/05/05 22:48:16 [debug] 6696#0: malloc: 00000000026BAA20:65 > 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock > 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire: #0 1 > a3397f6c > 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock > > Я так понимаю, это удачная очистка кеша. И следующее: > 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock > 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock > 2015/05/05 22:48:16 [debug] 6696#0: shmtx wake 625 > 2015/05/05 22:48:16 [debug] 6696#0: http file cache size: 20975581 > 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire > 2015/05/05 22:48:16 [debug] 6696#0: malloc: 00000000026BAA20:65 > 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock > 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire: #1 1 > dd87e60a > 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire: #0 1 > 93a2ff07 > 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock > > И еще: > 2015/05/05 22:48:16 [debug] 6696#0: shmtx wake 571 > 2015/05/05 22:48:16 [debug] 6696#0: http file cache expire: > "/opt2/nginx-cache-images1/2f/ee/093821fba4c1bf6f947a291d0dcfee2f" > 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock > 2015/05/05 22:48:16 [debug] 6696#0: slab free: 00007F66BE5FF380 > 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock > 2015/05/05 22:48:16 [debug] 6696#0: shmtx wake 570 > 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock > 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock > 2015/05/05 22:48:16 [debug] 6696#0: shmtx wake 569 > 2015/05/05 22:48:16 [debug] 6696#0: http file cache size: 20975519 > 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire > 2015/05/05 22:48:16 [debug] 6696#0: malloc: 00000000026BAA20:65 > 2015/05/05 22:48:16 [debug] 6696#0: shmtx lock > 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire: #1 1 > dd87e60a > 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire: #1 1 > 8bc7932f > 2015/05/05 22:48:16 [debug] 6696#0: http file cache forced expire: #0 1 > 91e3b5df > 2015/05/05 22:48:16 [debug] 6696#0: shmtx unlock > > Во время инцидента с uptime'мом воркеров аномалий не обнаружено. > > P.S. Такая же версия nginx работает также на Ubuntu 12 LTS. В этом случае > проблем не было обнаружено. Конфигурации и действия, которые вы производите с nginx, одинаковы? From nginx-forum at nginx.us Thu May 7 08:19:55 2015 From: nginx-forum at nginx.us (vlakas) Date: Thu, 07 May 2015 04:19:55 -0400 Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?= =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?= In-Reply-To: <65E1AFEE-A86A-4487-9010-6E2E709C513E@nginx.com> References: <65E1AFEE-A86A-4487-9010-6E2E709C513E@nginx.com> Message-ID: <24c7f92b49954f7d18ce6d6697b1902a.NginxMailingListRussian@forum.nginx.org> Роман, насколько я понимаю, вы говорите про shmtx lock/unlock. Единственное, что было сделано это: 1. Размер кеша - 80 Гб 2. В location добавлено: proxy_cache_use_stale error timeout updating; proxy_cache_lock on; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258704#msg-258704 From arut at nginx.com Thu May 7 09:11:22 2015 From: arut at nginx.com (Roman Arutyunyan) Date: Thu, 7 May 2015 12:11:22 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?= =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?= In-Reply-To: <24c7f92b49954f7d18ce6d6697b1902a.NginxMailingListRussian@forum.nginx.org> References: <65E1AFEE-A86A-4487-9010-6E2E709C513E@nginx.com> <24c7f92b49954f7d18ce6d6697b1902a.NginxMailingListRussian@forum.nginx.org> Message-ID: On 07 May 2015, at 11:19, vlakas wrote: > Роман, насколько я понимаю, вы говорите про shmtx lock/unlock. Единственное, > что было сделано это: > 1. Размер кеша - 80 Гб > 2. В location добавлено: > > proxy_cache_use_stale error timeout updating; > proxy_cache_lock on; Это вы на какой вопрос ответили? Не понял, при чем тут shmmtx lock/unlock. From nginx-forum at nginx.us Thu May 7 09:39:48 2015 From: nginx-forum at nginx.us (vlakas) Date: Thu, 07 May 2015 05:39:48 -0400 Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?= =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?= In-Reply-To: <65E1AFEE-A86A-4487-9010-6E2E709C513E@nginx.com> References: <65E1AFEE-A86A-4487-9010-6E2E709C513E@nginx.com> Message-ID: Рома, извините, не все вопросы увидел. Вот ответы. Roman Arutyunyan Wrote: ------------------------------------------------------- > Какое время прошло от старта nginx? Примерно 20 часов. Хотя сегодня инцидент повторился спустя 10 часов после рестарта, т.е. тут нет четкой закономерности. > > Судя по логу, вы релоадили nginx и, вероятно, даже меняли число > воркеров. > Это так? Если этого не делать, проблема также появляется? Нет, число воркеров не менялось. Nginx не релоадил. Можете указать, по каким признакам вы это увидели? Дело в том, что на этих же серверах стоит corosync + pacemaker (который теоретически может это делать). Но судя по логам corosync и uptime воркеров, это маловероятно. > > Это и есть основная проблема. У вас есть возможность поискать эту > строку > в более ранних логах? Cache manager очищает кеш в порядке lru, так > что > этот файл появился в кеше некоторое время назад и успел с тех пор > стать > самым старым. > Чуть позже посмотрю более ранние логи. Не факт что найду, поскольку нет возможности хранить большие объемы логов на сервере. > Что касается поиска файла, соответствующего ключу, я вам в прошлый раз > дал > не совсем верный алгоритм. Надо искать чуть иначе, вот пример из > вашего же лога: > > 2015/05/05 22:45:33 [debug] 6696#0: http file cache forced expire: #0 > 1 b139cb65 > 2015/05/05 22:45:33 [debug] 6696#0: http file cache expire: > "/opt2/nginx-cache-images1/c8/de/0ac4a89e20a39c1fb139cb65c2ffdec8" > > b139cb65 -> /opt2/nginx-cache-images1/c8/de/0ac4a89e20a39c1f b139cb65 > c2ffdec8 > > > Конфигурации и действия, которые вы производите с nginx, одинаковы? > На последний вопрос ответил в предыдущем посте. И еще раз скажу, в промежутке между инцидентами конфигурация nginx не меняется и сам nginx не релоадится. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258706#msg-258706 From arut at nginx.com Thu May 7 10:14:18 2015 From: arut at nginx.com (Roman Arutyunyan) Date: Thu, 7 May 2015 13:14:18 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?= =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?= In-Reply-To: References: <65E1AFEE-A86A-4487-9010-6E2E709C513E@nginx.com> Message-ID: <8112516B-8FA6-4860-B2EC-AFD40C4D4360@nginx.com> On 07 May 2015, at 12:39, vlakas wrote: > Рома, извините, не все вопросы увидел. > Вот ответы. > > Roman Arutyunyan Wrote: > ------------------------------------------------------- >> Какое время прошло от старта nginx? > > Примерно 20 часов. Хотя сегодня инцидент повторился спустя 10 часов после > рестарта, т.е. тут нет четкой закономерности. > >> >> Судя по логу, вы релоадили nginx и, вероятно, даже меняли число >> воркеров. >> Это так? Если этого не делать, проблема также появляется? > > Нет, число воркеров не менялось. Nginx не релоадил. Можете указать, по каким > признакам вы это увидели? pid мастера - 15084 pid воркеров - 6688-6696 Обычно они идут по порядку. В вашем случае мастер явно старше. From nginx-forum at nginx.us Thu May 7 11:38:51 2015 From: nginx-forum at nginx.us (vlakas) Date: Thu, 07 May 2015 07:38:51 -0400 Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?= =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?= In-Reply-To: <8112516B-8FA6-4860-B2EC-AFD40C4D4360@nginx.com> References: <8112516B-8FA6-4860-B2EC-AFD40C4D4360@nginx.com> Message-ID: Вас понял. Да, nginx релоадился, но не в момент сбора логов. Т.е. в течении этих 20+ часов (о которых я ранее говорил), nginx не релоадился. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258714#msg-258714 From simplebox66 at gmail.com Fri May 8 12:10:22 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 8 May 2015 15:10:22 +0300 Subject: =?UTF-8?B?d2ViZGF2INGB0LXRgNCy0LXRgCDQvdCwIG5naW54?= Message-ID: Поднял webdav сервер на nginx со следующим конфигом server { listen 80; server_name x.x.x.x; location / { autoindex on; root /etc/nginx/include/webdav; client_max_body_size 0; dav_methods PUT MKCOL COPY MOVE; create_full_put_path on; dav_access all:rw; } } права у директории drwxr-xr-x 2 root root 4096 Май 8 14:33 webdav если набрать в браузере http://x.x.x.x/ то видно файлики которые лежат в директории webdav и их можно скачать. А вот кадавер не работает cadaver http://x.x.x.x:80 Could not open collection: 405 Not Allowed dav:/? cyberduck тоже не работает пишет что удаленный хост закрыл соединение на стадии handshake Как сетевой диск в windows 7 тоже не цепляется. Подскажите, что я делаю не так? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mva at mva.name Fri May 8 12:35:38 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 08 May 2015 18:35:38 +0600 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDRgdC10YDQstC10YAg0L3QsCBuZ2lueA==?= In-Reply-To: References: Message-ID: <4804565.uoL01FoiTE@note> В письме от Пт, 8 мая 2015 15:10:22 пользователь Иван Мишин написал: > > Подскажите, что я делаю не так? Например, говорите какие сообщения вам даёт мало кому известный клиентский софт (в рассылке, где заведомо нет его разработчиков и никто не может соотнести сообщение с местом в коде когда оно возникает) вместо того, чтобы показать что при этом в error.log (возможно, и сами поняли бы причину) -- 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 vadim.lazovskiy at gmail.com Fri May 8 12:38:18 2015 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Fri, 8 May 2015 15:38:18 +0300 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDRgdC10YDQstC10YAg0L3QsCBuZ2lueA==?= In-Reply-To: References: Message-ID: Здравствуйте. В nginx отсутствует поддержка методов OPTIONS и PROPFIND, необходимых для полноценной работы протокола. Есть модуль dav_ext позволяющий осуществить задуманное: https://github.com/arut/nginx-dav-ext-module 8 мая 2015 г., 15:10 пользователь Иван Мишин написал: > Поднял webdav сервер на nginx со следующим конфигом > > server { > listen 80; > server_name x.x.x.x; > > > location / { > > autoindex on; > root /etc/nginx/include/webdav; > client_max_body_size 0; > dav_methods PUT MKCOL COPY MOVE; > create_full_put_path on; > dav_access all:rw; > } > } > > права у директории drwxr-xr-x 2 root root 4096 Май 8 14:33 webdav > > если набрать в браузере http://x.x.x.x/ то видно файлики которые лежат в > директории webdav > и их можно скачать. > > А вот кадавер не работает > cadaver http://x.x.x.x:80 > Could not open collection: > 405 Not Allowed > dav:/? > > cyberduck тоже не работает пишет что удаленный хост закрыл соединение на > стадии handshake > > Как сетевой диск в windows 7 тоже не цепляется. > > > Подскажите, что я делаю не так? > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- WBR, Vadim Lazovskiy From gmm at csdoc.com Fri May 8 12:51:42 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 08 May 2015 15:51:42 +0300 Subject: nginx-dav-ext-module In-Reply-To: References: Message-ID: <554CB15E.9000705@csdoc.com> On 08.05.2015 15:38, Vadim Lazovskiy wrote: > В nginx отсутствует поддержка методов OPTIONS и PROPFIND, необходимых > для полноценной работы протокола. > Есть модуль dav_ext позволяющий осуществить задуманное: > https://github.com/arut/nginx-dav-ext-module Кстати, не совсем понятно, что мешает включить код из этого модуля в состав nginx, ведь Roman Arutyunyan уже является сотрудником Nginx Inc. Тем более, что недавно модуль http://mdounin.ru/hg/ngx_http_auth_request_module/ был включен в состав nginx: http://nginx.org/en/docs/http/ngx_http_auth_request_module.html -- Best regards, Gena From mva at mva.name Fri May 8 13:01:02 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 08 May 2015 19:01:02 +0600 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDRgdC10YDQstC10YAg0L3QsCBuZ2lueA==?= In-Reply-To: References: Message-ID: <3609373.IfX19BGxxQ@note> В письме от Пт, 8 мая 2015 15:38:18 пользователь Vadim Lazovskiy написал: > https://github.com/arut/nginx-dav-ext-module кстати, довольно забавно, что `arut` (Роман Арутюнян, если я правильно транслитировал фамилию) работает в NginX Inc. // т.е. модуль имел все шансы оказаться в стандартной поставке :) -- 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 mdounin at mdounin.ru Fri May 8 13:01:12 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 8 May 2015 16:01:12 +0300 Subject: nginx-dav-ext-module In-Reply-To: <554CB15E.9000705@csdoc.com> References: <554CB15E.9000705@csdoc.com> Message-ID: <20150508130112.GV98215@mdounin.ru> Hello! On Fri, May 08, 2015 at 03:51:42PM +0300, Gena Makhomed wrote: > On 08.05.2015 15:38, Vadim Lazovskiy wrote: > > >В nginx отсутствует поддержка методов OPTIONS и PROPFIND, необходимых > >для полноценной работы протокола. > >Есть модуль dav_ext позволяющий осуществить задуманное: > >https://github.com/arut/nginx-dav-ext-module > > Кстати, не совсем понятно, что мешает включить код > из этого модуля в состав nginx, ведь Roman Arutyunyan > уже является сотрудником Nginx Inc. Модуль включать - это очевидно странное решение, один модуль про DAV в nginx'е уже есть. Втянуть функциональность - наверное имеет смысл, но код Романа зависит от Expat'а, и тащить эту зависимость не хотелось бы. -- Maxim Dounin http://nginx.org/ From simplebox66 at gmail.com Fri May 8 13:44:08 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 8 May 2015 16:44:08 +0300 Subject: =?UTF-8?B?UmU6IHdlYmRhdiDRgdC10YDQstC10YAg0L3QsCBuZ2lueA==?= In-Reply-To: <3609373.IfX19BGxxQ@note> References: <3609373.IfX19BGxxQ@note> Message-ID: > > В nginx отсутствует поддержка методов OPTIONS и PROPFIND, необходимых > для полноценной работы протокола. Тогда понятно, как-то я упустил из виду что спец клиенты webdav начинают свой разговор с сервером с помощью метода OPTIONS . 8 мая 2015 г., 16:01 пользователь Vadim A. Misbakh-Soloviov написал: > В письме от Пт, 8 мая 2015 15:38:18 пользователь Vadim Lazovskiy написал: > > https://github.com/arut/nginx-dav-ext-module > > кстати, довольно забавно, что `arut` (Роман Арутюнян, если я правильно > транслитировал фамилию) работает в NginX Inc. > // т.е. модуль имел все шансы оказаться в стандартной поставке :) > > -- > Best regards, > mva > > _______________________________________________ > 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 Sat May 9 08:08:28 2015 From: nginx-forum at nginx.us (yuoras) Date: Sat, 09 May 2015 04:08:28 -0400 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSDQvdCw0YHRgtGA0L7QudC60L7QuSDQv9C+0LQ=?= =?UTF-8?B?0LTQvtC80LXQvdCw?= Message-ID: Добрый день. Прошу помощи спецов. Не могу никак настроить поддомен 1.с DNS порядок 2.Привожу конфиг server { listen 80; server_name ubnt.xxx.in.ua; location / { root /media/DISK_A1/NOD32/base/; index index.php index.html index.htm index_eset.htm; } } server { listen 80; server_name xxx.in.ua; location / { root /media/DISK_A1/system/sait/; index index.html index.htm; } } Если использовать xxx.in.ua работает и с внешней сети и внутренней, а поддомен ubnt.xxx.in.ua с внутренней работает , а с внешней сети нет. Ещё раз с внетренней сети всё работает , только из внешней не хочет. Никаких файерволов нет , nginx установлен на Zyxel Keenetic . Буду очень благодарен за помощь. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258761,258761#msg-258761 From nginx-ru at sadok.spb.ru Sat May 9 08:27:32 2015 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Sat, 9 May 2015 11:27:32 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L3QsNGB0YLRgNC+0LnQutC+0Lkg0L8=?= =?UTF-8?B?0L7QtNC00L7QvNC10L3QsA==?= In-Reply-To: References: Message-ID: <1037251280.20150509112732@sadok.spb.ru> Здравствуйте, yuoras. Вы писали 9 мая 2015 г., 11:08:28: > 1.с DNS порядок Так может не будем прятать личико и назовем домен? -- С уважением, Dmitry mailto:nginx-ru at sadok.spb.ru From nginx-forum at nginx.us Sat May 9 12:21:37 2015 From: nginx-forum at nginx.us (yuoras) Date: Sat, 09 May 2015 08:21:37 -0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L3QsNGB0YLRgNC+0LnQutC+0Lkg0L8=?= =?UTF-8?B?0L7QtNC00L7QvNC10L3QsA==?= In-Reply-To: <1037251280.20150509112732@sadok.spb.ru> References: <1037251280.20150509112732@sadok.spb.ru> Message-ID: <6645313fd880bacc51760c89647f3cce.NginxMailingListRussian@forum.nginx.org> Dmitry Ivanov Wrote: ------------------------------------------------------- > Здравствуйте, yuoras. > > Вы писали 9 мая 2015 г., 11:08:28: > > > 1.с DNS порядок > > Так может не будем прятать личико и назовем домен? > > -- > С уважением, > Dmitry mailto:nginx-ru at sadok.spb.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru домен yuoras.in.ua поддомен ubnt.yuoras.in.ua Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258761,258764#msg-258764 From nginx-ru at sadok.spb.ru Sat May 9 15:37:36 2015 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Sat, 9 May 2015 18:37:36 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L3QsNGB0YLRgNC+0LnQutC+0Lkg0L8=?= =?UTF-8?B?0L7QtNC00L7QvNC10L3QsA==?= In-Reply-To: <6645313fd880bacc51760c89647f3cce.NginxMailingListRussian@forum.nginx.org> References: <1037251280.20150509112732@sadok.spb.ru> <6645313fd880bacc51760c89647f3cce.NginxMailingListRussian@forum.nginx.org> Message-ID: <499421749.20150509183736@sadok.spb.ru> Здравствуйте, yuoras. Вы писали 9 мая 2015 г., 15:21:37: > домен yuoras.in.ua > поддомен ubnt.yuoras.in.ua С ДНС все нормально. Но по 80 порту тишина. В любом случае надо включать дебаг и смотреть логи. -- С уважением, Dmitry mailto:nginx-ru at sadok.spb.ru From nginx-forum at nginx.us Sat May 9 18:18:06 2015 From: nginx-forum at nginx.us (yuoras) Date: Sat, 09 May 2015 14:18:06 -0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L3QsNGB0YLRgNC+0LnQutC+0Lkg0L8=?= =?UTF-8?B?0L7QtNC00L7QvNC10L3QsA==?= In-Reply-To: <499421749.20150509183736@sadok.spb.ru> References: <499421749.20150509183736@sadok.spb.ru> Message-ID: дебаг включен. Ни слова в логе о поддомене Такое чувство ,что пакеты просто не добегают до поддомена Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258761,258769#msg-258769 From nginx-forum at nginx.us Sun May 10 09:39:43 2015 From: nginx-forum at nginx.us (itcod) Date: Sun, 10 May 2015 05:39:43 -0400 Subject: =?UTF-8?B?UmU6INC30LDQsdGL0Lsg0YHQu9GN0Ygg0LIg0LrQvtC90YbQtSB1cmwg0L/QvtC7?= =?UTF-8?B?0YPRh9C40Lsg0YHRg9GB0LDQvdC40L0tYXV0b2luZGV4?= In-Reply-To: References: <9478888.l9gdBdEcf9@vbart-laptop> Message-ID: РЕШЕНО. Решил проблемку с относительными путями в body autoindex заменяя их полными URI. Тем самым привожу ссылки к однозначному толкованию в браузерах. Написал обработчик body на lua. https://github.com/itcod/md5index Может кому пригодится кроме меня:) Заодно добавил обработчику функционала: умеет добавлять контрольные суммы/хэши файлов и иконки по расширениям, и указывает тип. Внутри body добавляет для возможности автоматического парсинга данных на странице из JS Nginx addon for function autoindex. Add in body html: 1. HASH code files. Support secure hash: md5 md4 sha1 sha ripemd160; 2. Rewrite relative path body html to full URI path for files; 3. Add extension icons for folders and files. Require icons lib. Example icons lib 16x16: http://ihome.itcod.com/max/projects/libs/icons16/ Test computation in Lua (5.1) --- 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/icons16/; # путь к библиотека иконок set $md5index_icopref icon-; # префикс имени файла иконки #set $md5index_icosuf -icon; # суфикс имени файла иконки set $md5index_icoext .gif; # расширение файла иконки body_filter_by_lua_file /etc/nginx/lua/md5index.lua; # addon обработчик Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258337,258782#msg-258782 From xeioex at nginx.com Tue May 12 11:39:09 2015 From: xeioex at nginx.com (Dmitry Volyntsev) Date: Tue, 12 May 2015 14:39:09 +0300 Subject: [PATCH 0 of 1] Cache: move locked entries during forced expire to avoid overflow. In-Reply-To: References: Message-ID: Добрый день! Высылаю патч (успешно накладывается на 1.7.7) который позволит обойти проблему. Теперь nginx будет просто перекладывать залоченные записи в начало очереди, тем самым избегая проблемы с остановкой удаления записей из кеша. Кроме того это позволит нам обойтись без debug log. К сожалению так как мы до сих пор не можем воспроизвести оригинальную проблему (которая оставляет залоченные записи), высылаемый патч ее не решает. Что-бы мы могли выяснить причины оригинальной проблемы проделайте следующее: 1) соберите nginx с наложенным пачтем. 2) уберите debug log. 3) включите уровень логирования notice. 4) пришлите целиком весь error_log начиная со момента старта до появления первых сообщений "ignore long locked excess cache entry". From xeioex at nginx.com Tue May 12 11:39:10 2015 From: xeioex at nginx.com (Dmitry Volyntsev) Date: Tue, 12 May 2015 14:39:10 +0300 Subject: [PATCH 1 of 1] Cache: move locked entries during forced expire to avoid overflow In-Reply-To: References: Message-ID: # HG changeset patch # User Dmitry Volyntsev # Date 1431103222 -10800 # Fri May 08 19:40:22 2015 +0300 # Branch se # Node ID bbdd30b83a35a68c60ee69fea68530ef5e6560fd # Parent 079711e9b729d175c84fa58a959d786f5dc890f3 Cache: move locked entries during forced expire to avoid overflow. diff -r 079711e9b729 -r bbdd30b83a35 src/http/ngx_http_file_cache.c --- a/src/http/ngx_http_file_cache.c Thu Apr 23 14:10:42 2015 +0300 +++ b/src/http/ngx_http_file_cache.c Fri May 08 19:40:22 2015 +0300 @@ -1769,13 +1769,14 @@ ngx_http_file_cache_cleanup(void *data) static time_t ngx_http_file_cache_forced_expire(ngx_http_file_cache_t *cache) { - u_char *name; + u_char *name, *p; size_t len; time_t wait; ngx_uint_t tries; ngx_path_t *path; ngx_queue_t *q; ngx_http_file_cache_node_t *fcn; + u_char key[2 * NGX_HTTP_CACHE_KEY_LEN]; ngx_log_debug0(NGX_LOG_DEBUG_HTTP, ngx_cycle->log, 0, "http file cache forced expire"); @@ -1790,15 +1791,19 @@ ngx_http_file_cache_forced_expire(ngx_ht ngx_memcpy(name, path->name.data, path->name.len); - wait = 10; tries = 20; ngx_shmtx_lock(&cache->shpool->mutex); - for (q = ngx_queue_last(&cache->sh->queue); - q != ngx_queue_sentinel(&cache->sh->queue); - q = ngx_queue_prev(q)) - { + for ( ;; ) { + + if (ngx_queue_empty(&cache->sh->queue)) { + wait = 10; + break; + } + + q = ngx_queue_last(&cache->sh->queue); + fcn = ngx_queue_data(q, ngx_http_file_cache_node_t, queue); ngx_log_debug6(NGX_LOG_DEBUG_HTTP, ngx_cycle->log, 0, @@ -1811,6 +1816,18 @@ ngx_http_file_cache_forced_expire(ngx_ht wait = 0; } else { + p = ngx_hex_dump(key, (u_char *) &fcn->node.key, + sizeof(ngx_rbtree_key_t)); + len = NGX_HTTP_CACHE_KEY_LEN - sizeof(ngx_rbtree_key_t); + (void) ngx_hex_dump(p, fcn->key, len); + + ngx_queue_remove(q); + ngx_queue_insert_head(&cache->sh->queue, &fcn->queue); + + ngx_log_error(NGX_LOG_ALERT, ngx_cycle->log, 0, + "ignore long locked excess cache entry %*s, count:%d", + 2 * NGX_HTTP_CACHE_KEY_LEN, key, fcn->count); + if (--tries) { continue; } From chipitsine at gmail.com Tue May 12 19:33:11 2015 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 13 May 2015 00:33:11 +0500 Subject: =?UTF-8?B?UmU6INC30LDQsdGL0Lsg0YHQu9GN0Ygg0LIg0LrQvtC90YbQtSB1cmwg0L/QvtC7?= =?UTF-8?B?0YPRh9C40Lsg0YHRg9GB0LDQvdC40L0tYXV0b2luZGV4?= In-Reply-To: References: <9478888.l9gdBdEcf9@vbart-laptop> Message-ID: ваша настойчивость в изучении http технологий приятно удивляет. а что вы имеет в виду под "РЕШЕНО. Решил проблемку с относительными путями в body autoindex заменяя их полными URI." ? во-первых, не совсем понятно, зачем нужны абсолютные пути. на практике я сталкивался всего с двумя ситуациями, когда они были нужны а) приложение отправляет пользователю ссылку на почту (напр, чтобы вспомнить пароль) б) архитектура приложения такова, что с ним работают роботы, не браузер, напр. HAL на api в остальных случаях всегда хватало относительных ссылок. абсолютные ссылки это головная боль, как передать на приложение схему (если есть proxy_pass куда-то и есть терминация https на nginx). autoindex это ведь для браузеров ? так в чем проблема, отдайте им относительные ссылки. 10 мая 2015 г., 14:39 пользователь itcod написал: > РЕШЕНО. > Решил проблемку с относительными путями в body autoindex заменяя их полными > URI. > Тем самым привожу ссылки к однозначному толкованию в браузерах. > Написал обработчик body на lua. > https://github.com/itcod/md5index > Может кому пригодится кроме меня:) > > Заодно добавил обработчику функционала: умеет добавлять контрольные > суммы/хэши файлов и иконки по расширениям, и указывает тип. Внутри body > добавляет для возможности автоматического парсинга данных на > странице из JS > > Nginx addon for function autoindex. > Add in body html: > 1. HASH code files. Support secure hash: md5 md4 sha1 sha ripemd160; > 2. Rewrite relative path body html to full URI path for files; > 3. Add extension icons for folders and files. Require icons lib. > Example icons lib 16x16: > http://ihome.itcod.com/max/projects/libs/icons16/ > Test computation in Lua (5.1) > > --- > 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/icons16/; # путь > к библиотека иконок > set $md5index_icopref icon-; # префикс имени файла иконки > #set $md5index_icosuf -icon; # суфикс имени файла иконки > set $md5index_icoext .gif; # расширение файла иконки > body_filter_by_lua_file /etc/nginx/lua/md5index.lua; # addon > обработчик > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258337,258782#msg-258782 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From simplebox66 at gmail.com Wed May 13 07:58:26 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 13 May 2015 10:58:26 +0300 Subject: =?UTF-8?B?UmU6IExvY2F0aW9uINC00LvRjyBwaHAg0YHQutGA0LjQv9GC0LAg0YEg0L/QsNGA?= =?UTF-8?B?0LDQvNC10YLRgNCw0LzQuA==?= In-Reply-To: References: <551B0E6C.9090801@kopeyko.ru> Message-ID: Проблему решил, но через if. Сейчас снова столкнулся с похожей задачей, но в ней if использовать уже накладно. Как реализовать аналогичное, но без if ? То есть должно быть location / { proxy_pass http://127.0.0.1:8080; } location /index.php?param1=a¶m2=b¶mN=N { auth_basic "Restricted"; auth_basic_user_file include/passwd/testpass.txt; proxy_pass http://127.0.0.1:8080; } 2015-04-01 11:01 GMT+03:00 Иван Мишин : > Приведенная выше схема не работает > > 2015-04-01 10:59 GMT+03:00 Иван Мишин : > >> ВОт так? >> location / { >> if ($query_string ~ param1=a ) { >> error_page 418 = @restricted; >> } >> proxy_pass http://127.0.0.1:8080; >> } >> >> location @restricted { >> internal; >> auth_basic "Restricted"; >> auth_basic_user_file include/passwd/testpass.txt; >> proxy_pass http://127.0.0.1:8080; >> } >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mva at mva.name Wed May 13 08:31:47 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Wed, 13 May 2015 14:31:47 +0600 Subject: =?UTF-8?B?UmU6IExvY2F0aW9uINC00LvRjyBwaHAg0YHQutGA0LjQv9GC0LAg0YEg0L/QsNGA?= =?UTF-8?B?0LDQvNC10YLRgNCw0LzQuA==?= In-Reply-To: References: Message-ID: <8092471.G20k2kXYXM@note> Может, для начала поменять их местами? // на синтаксис не проверял -- 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 Wed May 13 09:27:54 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 13 May 2015 12:27:54 +0300 Subject: =?UTF-8?B?UmU6IExvY2F0aW9uINC00LvRjyBwaHAg0YHQutGA0LjQv9GC0LAg0YEg0L/QsNGA?= =?UTF-8?B?0LDQvNC10YLRgNCw0LzQuA==?= In-Reply-To: <8092471.G20k2kXYXM@note> References: <8092471.G20k2kXYXM@note> Message-ID: Дело в том что на сколько я понимаю location не реагирует на параметры скрипта 13 мая 2015 г., 11:31 пользователь Vadim A. Misbakh-Soloviov написал: > Может, для начала поменять их местами? > // на синтаксис не проверял > > -- > Best regards, > mva > > _______________________________________________ > 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 May 13 10:47:57 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Wed, 13 May 2015 13:47:57 +0300 Subject: =?UTF-8?B?UmU6IExvY2F0aW9uINC00LvRjyBwaHAg0YHQutGA0LjQv9GC0LAg0YEg0L/QsNGA?= =?UTF-8?B?0LDQvNC10YLRgNCw0LzQuA==?= In-Reply-To: References: <8092471.G20k2kXYXM@note> Message-ID: Вот мой полный конфиг сервера: server { listen 80; server_name test.info; location /index.php?param1=a¶m2=b¶mN=N { auth_basic "Restricted"; proxy_pass http://127.0.0.1:8080; } location / { proxy_pass http://127.0.0.1:8080; } Соответственно запрашивая http://test.info я попадаю во второй локейшн. А когда запрашиваю http://test.info/index.php?param1=a¶m2=b¶mN=N снова попадаю во второй. Не пойму в чем может проблема 13 мая 2015 г., 12:27 пользователь Иван Мишин написал: > Дело в том что на сколько я понимаю location не реагирует на параметры > скрипта > > 13 мая 2015 г., 11:31 пользователь Vadim A. Misbakh-Soloviov > написал: > >> Может, для начала поменять их местами? >> // на синтаксис не проверял >> >> -- >> Best regards, >> mva >> >> _______________________________________________ >> 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 sytar.alex at gmail.com Wed May 13 11:03:14 2015 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Wed, 13 May 2015 14:03:14 +0300 Subject: =?UTF-8?B?UmU6IExvY2F0aW9uINC00LvRjyBwaHAg0YHQutGA0LjQv9GC0LAg0YEg0L/QsNGA?= =?UTF-8?B?0LDQvNC10YLRgNCw0LzQuA==?= In-Reply-To: References: <8092471.G20k2kXYXM@note> Message-ID: 13 мая 2015 г., 13:47 пользователь Иван Мишин написал: > Вот мой полный конфиг сервера: > server { > listen 80; > server_name test.info; > > location /index.php?param1=a¶m2=b¶mN=N { > auth_basic "Restricted"; > proxy_pass http://127.0.0.1:8080; > } > > location / { > proxy_pass http://127.0.0.1:8080; > } > > Соответственно запрашивая http://test.info я попадаю во второй локейшн. > А когда запрашиваю http://test.info/index.php?param1=a¶m2=b¶mN=N > снова попадаю во второй. Не пойму в чем может проблема > QUERY_STRING не являются частью location -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed May 13 14:40:40 2015 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 13 May 2015 10:40:40 -0400 Subject: =?UTF-8?B?0JXRgdC70Lgg0YLQtdC70L4g0L7RgtCy0LXRgtCwINC/0YPRgdGC0L7QtSwg0L4=?= =?UTF-8?B?0YLQtNCw0LLQsNGC0YwgQ29udGVudC1MZW5ndGg6IDAsINCy0LzQtdGB0YI=?= =?UTF-8?B?0L4gVHJhbnNmZXItRW5jb2Rpbmc6IGNodW5rZWQ=?= Message-ID: По умолчанию, Nginx отдает ответ Transfer-Encoding: chunked, даже когда длина тела ответа равна нулю. Это мелочь, но будет лучше, если в этой ситуации Nginx будет отдавать Content-Length: 0. Такой ответ короче и более удобный для HTTP клиентов. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258857,258857#msg-258857 From vbart at nginx.com Wed May 13 15:06:44 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 13 May 2015 18:06:44 +0300 Subject: =?UTF-8?B?UmU6INCV0YHQu9C4INGC0LXQu9C+INC+0YLQstC10YLQsCDQv9GD0YHRgtC+0LUs?= =?UTF-8?B?INC+0YLQtNCw0LLQsNGC0YwgQ29udGVudC1MZW5ndGg6IDAsINCy0LzQtdGB?= =?UTF-8?B?0YLQviBUcmFuc2Zlci1FbmNvZGluZzogY2h1bmtlZA==?= In-Reply-To: References: Message-ID: <1988320.0FE8SaCWYQ@vbart-workstation> On Wednesday 13 May 2015 10:40:40 S.A.N wrote: > По умолчанию, Nginx отдает ответ Transfer-Encoding: chunked, даже когда > длина тела ответа равна нулю. Он отдает Transfer-Encoding: chunked когда размер ответа заранее неизвестен. > Это мелочь, но будет лучше, если в этой ситуации Nginx будет отдавать > Content-Length: 0. > Такой ответ короче и более удобный для HTTP клиентов. > См. выше. -- Валентин Бартенев From nginx-forum at nginx.us Wed May 13 15:51:43 2015 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 13 May 2015 11:51:43 -0400 Subject: =?UTF-8?B?UmU6INCV0YHQu9C4INGC0LXQu9C+INC+0YLQstC10YLQsCDQv9GD0YHRgtC+0LUs?= =?UTF-8?B?INC+0YLQtNCw0LLQsNGC0YwgQ29udGVudC1MZW5ndGg6IDAsINCy0LzQtdGB?= =?UTF-8?B?0YLQviBUcmFuc2Zlci1FbmNvZGluZzogY2h1bmtlZA==?= In-Reply-To: <1988320.0FE8SaCWYQ@vbart-workstation> References: <1988320.0FE8SaCWYQ@vbart-workstation> Message-ID: > Он отдает Transfer-Encoding: chunked когда размер ответа заранее > неизвестен. Я это понимаю, но думал что где-то на уровне буферизации ответа, Nginx может узнать что тело пустое, то того как начал передавать клиенту заголовки ответа. Но на нет и суда нет. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258857,258859#msg-258859 From nginx-forum at nginx.us Thu May 14 07:11:24 2015 From: nginx-forum at nginx.us (vlakas) Date: Thu, 14 May 2015 03:11:24 -0400 Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?= =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?= In-Reply-To: <8112516B-8FA6-4860-B2EC-AFD40C4D4360@nginx.com> References: <8112516B-8FA6-4860-B2EC-AFD40C4D4360@nginx.com> Message-ID: <7c7077e85b0c0f2b05c2cda23175a134.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Нашел такую же проблему: https://www.ruby-forum.com/topic/6872930 Оказывается она-таки существует. Обновил nginx до 1.8. Проблема осталась, но проявляется значительно реже (порядка 1-2 раз в неделю по отношению к раз в сутки с nginx 1.7.х) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258864#msg-258864 From simplebox66 at gmail.com Thu May 14 10:07:05 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Thu, 14 May 2015 13:07:05 +0300 Subject: =?UTF-8?B?UmU6IExvY2F0aW9uINC00LvRjyBwaHAg0YHQutGA0LjQv9GC0LAg0YEg0L/QsNGA?= =?UTF-8?B?0LDQvNC10YLRgNCw0LzQuA==?= In-Reply-To: References: <8092471.G20k2kXYXM@note> Message-ID: Дело в вопросительно знаке /index.php?param1=a¶m2=b¶mN=N. Подробнее вот http://forum.nginx.org/read.php?21,13622,13629#msg-13629 Кто-то сталкивался с таким? Порекомендуйте пожалуйста как решить задачу 13 мая 2015 г., 13:47 пользователь Иван Мишин написал: > Вот мой полный конфиг сервера: > server { > listen 80; > server_name test.info; > > location /index.php?param1=a¶m2=b¶mN=N { > auth_basic "Restricted"; > proxy_pass http://127.0.0.1:8080; > } > > location / { > proxy_pass http://127.0.0.1:8080; > } > > Соответственно запрашивая http://test.info я попадаю во второй локейшн. > А когда запрашиваю http://test.info/index.php?param1=a¶m2=b¶mN=N > снова попадаю во второй. Не пойму в чем может проблема > > > > > 13 мая 2015 г., 12:27 пользователь Иван Мишин > написал: > > Дело в том что на сколько я понимаю location не реагирует на параметры >> скрипта >> >> 13 мая 2015 г., 11:31 пользователь Vadim A. Misbakh-Soloviov < >> mva at mva.name> написал: >> >>> Может, для начала поменять их местами? >>> // на синтаксис не проверял >>> >>> -- >>> Best regards, >>> mva >>> >>> _______________________________________________ >>> 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 denis at webmaster.spb.ru Thu May 14 12:57:11 2015 From: denis at webmaster.spb.ru (denis) Date: Thu, 14 May 2015 15:57:11 +0300 Subject: =?UTF-8?B?0LfQsNC80LXQtNC70LXQvdC40LUg0YDQsNCx0L7RgtGL?= Message-ID: <55549BA7.1060704@webmaster.spb.ru> Добрый день. Иногда приходится слышать (и видеть) - "поставили nginx, всё стало тормозить". Напрямую запросы быстрые, после включения nginx В режиме proxy_pass (статики тоже, ибо с другого сервера) - ощутимо медленнее, time curl подтверждает, например 5с против 0.3 Как диагностировать такие случаи? From a.vasilishin at kpi.ua Thu May 14 12:58:49 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, 14 May 2015 15:58:49 +0300 Subject: =?UTF-8?B?UmU6INC30LDQvNC10LTQu9C10L3QuNC1INGA0LDQsdC+0YLRiw==?= In-Reply-To: <55549BA7.1060704@webmaster.spb.ru> References: <55549BA7.1060704@webmaster.spb.ru> Message-ID: <55549C09.8010101@kpi.ua> 14.05.2015 15:57, denis пишет: > Добрый день. > > Иногда приходится слышать (и видеть) - "поставили nginx, всё стало > тормозить". Напрямую запросы быстрые, после включения nginx В режиме > proxy_pass (статики тоже, ибо с другого сервера) - ощутимо медленнее, > time curl подтверждает, например 5с против 0.3 > > Как диагностировать такие случаи? > А кеширование используется? Или нгинкс в виде простой прокладки? From denis at webmaster.spb.ru Thu May 14 13:36:49 2015 From: denis at webmaster.spb.ru (denis) Date: Thu, 14 May 2015 16:36:49 +0300 Subject: =?UTF-8?B?UmU6INC30LDQvNC10LTQu9C10L3QuNC1INGA0LDQsdC+0YLRiw==?= In-Reply-To: <55549C09.8010101@kpi.ua> References: <55549BA7.1060704@webmaster.spb.ru> <55549C09.8010101@kpi.ua> Message-ID: <5554A4F1.5090504@webmaster.spb.ru> 14.05.2015 15:58, Андрей Василишин пишет: > 14.05.2015 15:57, denis пишет: >> Добрый день. >> >> Иногда приходится слышать (и видеть) - "поставили nginx, всё стало >> тормозить". Напрямую запросы быстрые, после включения nginx В режиме >> proxy_pass (статики тоже, ибо с другого сервера) - ощутимо медленнее, >> time curl подтверждает, например 5с против 0.3 >> >> Как диагностировать такие случаи? >> > > > А кеширование используется? Или нгинкс в виде простой прокладки? просто прокладка, типовые концигурации, единственный локейшен с прокси-пассом. . Но даже так - процентов 10 потери скорости будут не заметны, а больше - ненормально. Чуть уточню вопрос: бывает 2 вида проблемы 1) был апач в мир, поставили проксировать nginx (и статику), сервер один - тот же битрикс иногда существенно замедляется. Понятно, что правильно настроить чисто на динамику - и будет быстрее, но сам факт... Особенно актуально, когда на сервере 100-500 сайтов, под все конфиги писать - нужно время. 2) был сервер, его увели в локальную сеть, запросы проксируются - такой вариант бывает, когда было несколько серверов со своими айпи, их объединили в dmz и вывели через 1 айпи в мир. Домены не пересекаются. From a.vasilishin at kpi.ua Thu May 14 14:06:49 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, 14 May 2015 17:06:49 +0300 Subject: =?UTF-8?B?UmU6INC30LDQvNC10LTQu9C10L3QuNC1INGA0LDQsdC+0YLRiw==?= In-Reply-To: <5554A4F1.5090504@webmaster.spb.ru> References: <55549BA7.1060704@webmaster.spb.ru> <55549C09.8010101@kpi.ua> <5554A4F1.5090504@webmaster.spb.ru> Message-ID: <5554ABF9.9030804@kpi.ua> 14.05.2015 16:36, denis пишет: > 14.05.2015 15:58, Андрей Василишин пишет: >> 14.05.2015 15:57, denis пишет: >>> Добрый день. >>> >>> Иногда приходится слышать (и видеть) - "поставили nginx, всё стало >>> тормозить". Напрямую запросы быстрые, после включения nginx В режиме >>> proxy_pass (статики тоже, ибо с другого сервера) - ощутимо медленнее, >>> time curl подтверждает, например 5с против 0.3 >>> >>> Как диагностировать такие случаи? >>> >> >> >> А кеширование используется? Или нгинкс в виде простой прокладки? > просто прокладка, типовые концигурации, единственный локейшен с > прокси-пассом. . Но даже так - процентов 10 потери скорости будут не > заметны, а больше - ненормально. > > Чуть уточню вопрос: бывает 2 вида проблемы > 1) был апач в мир, поставили проксировать nginx (и статику), сервер один > - тот же битрикс иногда существенно замедляется. Понятно, что правильно > настроить чисто на динамику - и будет быстрее, но сам факт... Особенно > актуально, когда на сервере 100-500 сайтов, под все конфиги писать - > нужно время. > 2) был сервер, его увели в локальную сеть, запросы проксируются - такой > вариант бывает, когда было несколько серверов со своими айпи, их > объединили в dmz и вывели через 1 айпи в мир. Домены не пересекаются. > Тут какая-то каша описана. Если не использовать кеширование для статики, с чеговдруг должно работать быстрее? Если в Вашем случае делается двойная работа. From onokonem at gmail.com Thu May 14 14:29:33 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 14 May 2015 17:29:33 +0300 Subject: =?UTF-8?B?UmU6INC30LDQvNC10LTQu9C10L3QuNC1INGA0LDQsdC+0YLRiw==?= In-Reply-To: <5554ABF9.9030804@kpi.ua> References: <55549BA7.1060704@webmaster.spb.ru> <55549C09.8010101@kpi.ua> <5554A4F1.5090504@webmaster.spb.ru> <5554ABF9.9030804@kpi.ua> Message-ID: > Тут какая-то каша описана. Если не использовать кеширование для статики, с > чеговдруг должно работать быстрее? Если в Вашем случае делается двойная > работа. Но не "5с против 0.3"! тут есть какая-то проблема настройки, только мы не знаем, какая. From gmm at csdoc.com Thu May 14 14:35:07 2015 From: gmm at csdoc.com (Gena Makhomed) Date: Thu, 14 May 2015 17:35:07 +0300 Subject: =?UTF-8?B?UmU6INC30LDQvNC10LTQu9C10L3QuNC1INGA0LDQsdC+0YLRiw==?= In-Reply-To: <55549BA7.1060704@webmaster.spb.ru> References: <55549BA7.1060704@webmaster.spb.ru> Message-ID: <5554B29B.7000809@csdoc.com> On 14.05.2015 15:57, denis wrote: > Иногда приходится слышать (и видеть) - "поставили nginx, всё стало > тормозить". Напрямую запросы быстрые, после включения nginx В режиме > proxy_pass (статики тоже, ибо с другого сервера) - ощутимо медленнее, > time curl подтверждает, например 5с против 0.3 > > Как диагностировать такие случаи? Смотреть в логи nginx, там будет написано для каких файлов "an upstream response is buffered to a temporary file". Чтобы не было двойной буферизации статики - надо настроить отдачу этих файлов напрямую через nginx или через возврат X-Accel-Redirect со стороны апача. Возможно пригодится https://github.com/defanator/mod_aclr2 Если это nginx на frontend, за которым стоит много бекендов в виде nginx + php-fpm, тогда имеет смысл на самом первом nginx сделать: # If you want nginx to don't touch disk, use # This will still allow in-memory buffering and wouldn't touch disk. proxy_max_temp_file_size 0; # proxy_buffering off; - он тогда вообще не будет блокироваться на дисковых операциях. Возможно на nginx не хватает воркеров, а те что есть - блокируются на дисковых операциях. Тогда может помочь увеличение количества воркеров или использование http://nginx.org/en/docs/http/ngx_http_core_module.html#aio в режиме aio threads Если на nginx используется SSL - имеет смысл включить http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache - будет работать быстрее. Если к ssl включить spdy - тогда еще быстрее. -- Best regards, Gena From sytar.alex at gmail.com Thu May 14 14:47:21 2015 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Thu, 14 May 2015 17:47:21 +0300 Subject: =?UTF-8?B?UmU6INC30LDQvNC10LTQu9C10L3QuNC1INGA0LDQsdC+0YLRiw==?= In-Reply-To: <55549BA7.1060704@webmaster.spb.ru> References: <55549BA7.1060704@webmaster.spb.ru> Message-ID: 14 мая 2015 г., 15:57 пользователь denis написал: > Добрый день. > > Иногда приходится слышать (и видеть) - "поставили nginx, всё стало > тормозить". Напрямую запросы быстрые, после включения nginx В режиме > proxy_pass (статики тоже, ибо с другого сервера) - ощутимо медленнее, time > curl подтверждает, например 5с против 0.3 > > Как диагностировать такие случаи? > > Если это на винде, то вполне может быть... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu May 14 16:05:10 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 14 May 2015 19:05:10 +0300 Subject: =?UTF-8?B?UmU6INC30LDQvNC10LTQu9C10L3QuNC1INGA0LDQsdC+0YLRiw==?= In-Reply-To: <55549BA7.1060704@webmaster.spb.ru> References: <55549BA7.1060704@webmaster.spb.ru> Message-ID: <20150514160509.GC98215@mdounin.ru> Hello! On Thu, May 14, 2015 at 03:57:11PM +0300, denis wrote: > Добрый день. > > Иногда приходится слышать (и видеть) - "поставили nginx, всё стало > тормозить". Напрямую запросы быстрые, после включения nginx В режиме > proxy_pass (статики тоже, ибо с другого сервера) - ощутимо медленнее, time > curl подтверждает, например 5с против 0.3 > > Как диагностировать такие случаи? Если порядок проседания - 5 секунд против 0.3 ранее, то это означает, что во что-то конкретно так упёрлись. Я бы при таких цифрах - подозревал в первую очередь сеть, в частности - изменение нагрузки на неё в связи с большим количеством соединений между nginx'ом и бекендом, а именно: - сокеты в TIME-WAIT, особенно частно это становится проблемой на Linux'е; тюнить local portrage и tcp_tw_recycle, tcp_tw_reuse, можно ещё включить keepalive к upstream'ам в nginx'е; - statefull firewall между nginx'ом и бекендом, у которого заканчиваются state'ы. Ну и естественно в смысл посмотреть в логи nginx'а на предмет ошибок/предупреждений, а равно посмотреть в очереди всех учавствующих в процессе listen-сокетов ("netstat -Lan" на BSD-системах, "ss -nlt" на Linux'е), оценить общее состоянии системы с помощью стандартных инструментов (начиная от банального "top"). Для дополнительной локализации проблемы также полезно писать в логи различные времена, в частности $upstream_response_time. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Fri May 15 00:13:27 2015 From: nginx-forum at nginx.us (dima40985) Date: Thu, 14 May 2015 20:13:27 -0400 Subject: =?UTF-8?B?Z3ppcCDQvdC1INGB0LbQuNC80LDQtdGCIHRleHQvaHRtbA==?= Message-ID: <415453709a68f6789f50545048c8d737.NginxMailingListRussian@forum.nginx.org> Всем привет Проблема такая Включен gzip gzip on; gzip_min_length 1000; gzip_proxied any; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript; gzip_comp_level 4; Сжимает CSS и JS. Все супер Connection:keep-alive Content-Encoding:gzip Content-Type:text/css Date:Fri, 15 May 2015 00:08:03 GMT Last-Modified:Wed, 13 May 2015 23:09:30 GMT Server:nginx Transfer-Encoding:chunked Connection:keep-alive Content-Encoding:gzip Content-Type:application/javascript; charset=utf-8 Date:Fri, 15 May 2015 00:08:03 GMT Last-Modified:Wed, 13 May 2015 23:09:28 GMT Server:nginx Transfer-Encoding:chunked Но не сжимает html Cache-Control:public, max-age=3600 Connection:keep-alive Content-Type:text/html; charset=UTF-8 Date:Fri, 15 May 2015 00:08:03 GMT Last-Modified:Thu, 14 May 2015 21:59:42 GMT Pragma: Server:nginx Transfer-Encoding:chunked Хотя если выполнить wget с аналогичными броузерными заголовками, то все в порядке - приходит такой ответ ---request begin--- GET / HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Accept: */* Host: **************** Connection: Keep-Alive Accept-Encoding: gzip, deflate, sdch Cache-Control: no-cache Referer: ***************** Pragma: no-cache ---request end--- HTTP request sent, awaiting response... ---response begin--- HTTP/1.1 200 OK Server: nginx Date: Thu, 14 May 2015 23:24:37 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive Pragma: Cache-Control: public, max-age=3600 Last-Modified: Thu, 14 May 2015 21:59:42 GMT Content-Encoding: gzip Если кто в курсе подскажите пожалуйста. Второй день уже копаю. Результата ноль Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258883,258883#msg-258883 From redmine24 at gmail.com Fri May 15 09:43:11 2015 From: redmine24 at gmail.com (=?UTF-8?B?0JTQuNC80LAg0KDQtdC00LzQsNC50L0=?=) Date: Fri, 15 May 2015 12:43:11 +0300 Subject: =?UTF-8?B?UmU6IGd6aXAg0L3QtSDRgdC20LjQvNCw0LXRgiB0ZXh0L2h0bWw=?= In-Reply-To: <415453709a68f6789f50545048c8d737.NginxMailingListRussian@forum.nginx.org> References: <415453709a68f6789f50545048c8d737.NginxMailingListRussian@forum.nginx.org> Message-ID: добавьте в gzip_types text/html On Fri, May 15, 2015 at 3:13 AM, dima40985 wrote: > Всем привет > > Проблема такая > > > Включен gzip > > gzip on; > gzip_min_length 1000; > gzip_proxied any; > gzip_types text/plain text/css application/json > application/x-javascript text/xml application/xml application/xml+rss > text/javascript application/javascript; > gzip_comp_level 4; > > > > Сжимает CSS и JS. Все супер > > > Connection:keep-alive > Content-Encoding:gzip > Content-Type:text/css > Date:Fri, 15 May 2015 00:08:03 GMT > Last-Modified:Wed, 13 May 2015 23:09:30 GMT > Server:nginx > Transfer-Encoding:chunked > > > Connection:keep-alive > Content-Encoding:gzip > Content-Type:application/javascript; charset=utf-8 > Date:Fri, 15 May 2015 00:08:03 GMT > Last-Modified:Wed, 13 May 2015 23:09:28 GMT > Server:nginx > Transfer-Encoding:chunked > > > Но не сжимает html > > Cache-Control:public, max-age=3600 > Connection:keep-alive > Content-Type:text/html; charset=UTF-8 > Date:Fri, 15 May 2015 00:08:03 GMT > Last-Modified:Thu, 14 May 2015 21:59:42 GMT > Pragma: > Server:nginx > Transfer-Encoding:chunked > > > Хотя если выполнить wget с аналогичными броузерными заголовками, то все в > порядке - приходит такой ответ > > ---request begin--- > GET / HTTP/1.1 > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, > like Gecko) Chrome/42.0.2311.135 Safari/537.36 > Accept: */* > Host: **************** > Connection: Keep-Alive > Accept-Encoding: gzip, deflate, sdch > Cache-Control: no-cache > Referer: ***************** > Pragma: no-cache > > ---request end--- > HTTP request sent, awaiting response... > ---response begin--- > HTTP/1.1 200 OK > Server: nginx > Date: Thu, 14 May 2015 23:24:37 GMT > Content-Type: text/html; charset=UTF-8 > Transfer-Encoding: chunked > Connection: keep-alive > Pragma: > Cache-Control: public, max-age=3600 > Last-Modified: Thu, 14 May 2015 21:59:42 GMT > Content-Encoding: gzip > > > Если кто в курсе подскажите пожалуйста. Второй день уже копаю. Результата > ноль > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,258883,258883#msg-258883 > > _______________________________________________ > 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 me at kemko.ru Fri May 15 09:49:36 2015 From: me at kemko.ru (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JDQvdC00YDQtdC10LI=?=) Date: Fri, 15 May 2015 12:49:36 +0300 Subject: =?UTF-8?B?UmU6IGd6aXAg0L3QtSDRgdC20LjQvNCw0LXRgiB0ZXh0L2h0bWw=?= In-Reply-To: References: <415453709a68f6789f50545048c8d737.NginxMailingListRussian@forum.nginx.org> Message-ID: Ответы с типом ?text/html? сжимаются всегда. http://nginx.org/ru/docs/http/ngx_http_gzip_module.html#gzip_types curl можно запустить с параметром -V (--verbose) и сравнить заголовки. Если поведение gzip разное, значит какое-то отличие в них точно есть. 15 мая 2015 г., 12:43 пользователь Дима Редмайн написал: > добавьте в gzip_types text/html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From redmine24 at gmail.com Fri May 15 10:05:27 2015 From: redmine24 at gmail.com (=?UTF-8?B?0JTQuNC80LAg0KDQtdC00LzQsNC50L0=?=) Date: Fri, 15 May 2015 13:05:27 +0300 Subject: =?UTF-8?B?UmU6IGd6aXAg0L3QtSDRgdC20LjQvNCw0LXRgiB0ZXh0L2h0bWw=?= In-Reply-To: References: <415453709a68f6789f50545048c8d737.NginxMailingListRussian@forum.nginx.org> Message-ID: gzip_min_length 1000; какой у вас размер html страницы на тестах? 2015-05-15 12:49 GMT+03:00 Дмитрий Андреев : > Ответы с типом ?text/html? сжимаются всегда. > http://nginx.org/ru/docs/http/ngx_http_gzip_module.html#gzip_types > > > curl можно запустить с параметром -V (--verbose) и сравнить заголовки. > Если поведение gzip разное, значит какое-то отличие в них точно есть. > > 15 мая 2015 г., 12:43 пользователь Дима Редмайн > написал: > >> добавьте в gzip_types text/html >> > > > _______________________________________________ > 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 Fri May 15 11:02:15 2015 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 15 May 2015 07:02:15 -0400 Subject: =?UTF-8?B?UmU6IGd6aXAg0L3QtSDRgdC20LjQvNCw0LXRgiB0ZXh0L2h0bWw=?= In-Reply-To: <415453709a68f6789f50545048c8d737.NginxMailingListRussian@forum.nginx.org> References: <415453709a68f6789f50545048c8d737.NginxMailingListRussian@forum.nginx.org> Message-ID: > Хотя если выполнить wget с аналогичными броузерными заголовками, то > все в порядке - приходит такой ответ Возможно ваш антивирус или фаирвол, делает декомпресию на лету, тогда ваш браузер будет приходить незжатые страницы. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258883,258894#msg-258894 From nginx-forum at nginx.us Fri May 15 11:05:16 2015 From: nginx-forum at nginx.us (dima40985) Date: Fri, 15 May 2015 07:05:16 -0400 Subject: =?UTF-8?B?UmU6IGd6aXAg0L3QtSDRgdC20LjQvNCw0LXRgiB0ZXh0L2h0bWw=?= In-Reply-To: References: Message-ID: Да в том то и дело, что я запускал wget с такими же заголовками как и в браузере (писал в своем первом посту) и получил заголовок о сжатии, через Curl получу аналогичный результат. То есть проблема проявляется только через броузер Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258883,258895#msg-258895 From nginx-forum at nginx.us Fri May 15 11:07:11 2015 From: nginx-forum at nginx.us (dima40985) Date: Fri, 15 May 2015 07:07:11 -0400 Subject: =?UTF-8?B?UmU6IGd6aXAg0L3QtSDRgdC20LjQvNCw0LXRgiB0ZXh0L2h0bWw=?= In-Reply-To: References: <415453709a68f6789f50545048c8d737.NginxMailingListRussian@forum.nginx.org> Message-ID: хм...интересная идея..у меня Касперский...попробую вечером его выключить...но как тогда объяснить что он не разжимает на лету css и js Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258883,258896#msg-258896 From nginx-forum at nginx.us Fri May 15 11:49:55 2015 From: nginx-forum at nginx.us (d.v.biryukov) Date: Fri, 15 May 2015 07:49:55 -0400 Subject: =?UTF-8?B?UmU6INCU0LjQvdCw0LzQuNGH0L3QvtC1INCy0YDQtdC80Y8gdGltZW91dA==?= In-Reply-To: References: Message-ID: <6d71659d6b0223893f9e50ed52aeba34.NginxMailingListRussian@forum.nginx.org> в том то вся и грусняшка... что контекст для них исключает if вовсе ... от сюда и пришла идея использовать map с переменными Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257773,258898#msg-258898 From nginx-forum at nginx.us Fri May 15 11:51:41 2015 From: nginx-forum at nginx.us (d.v.biryukov) Date: Fri, 15 May 2015 07:51:41 -0400 Subject: =?UTF-8?B?UmU6INCU0LjQvdCw0LzQuNGH0L3QvtC1INCy0YDQtdC80Y8gdGltZW91dA==?= In-Reply-To: <55302C7D.50104@csdoc.com> References: <55302C7D.50104@csdoc.com> Message-ID: <8a90d60ade8f0454fa7e44146e26fbd0.NginxMailingListRussian@forum.nginx.org> спасибо за вектор Генадий, мысль и впрям хороша, но у меня есть ряд ограничений по которым я так не могу поступить, хотя с радостью бы так и сделал. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257773,258899#msg-258899 From nginx-forum at nginx.us Fri May 15 15:11:34 2015 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 15 May 2015 11:11:34 -0400 Subject: =?UTF-8?B?UmU6IGd6aXAg0L3QtSDRgdC20LjQvNCw0LXRgiB0ZXh0L2h0bWw=?= In-Reply-To: References: <415453709a68f6789f50545048c8d737.NginxMailingListRussian@forum.nginx.org> Message-ID: <7ae65686455c6e9effc3b494e448d644.NginxMailingListRussian@forum.nginx.org> > хм...интересная идея..у меня Касперский...попробую вечером его > выключить...но как тогда объяснить что он не разжимает на лету css и > js Вы можете проверить на других сайтах, например http://habrahabr.ru/ если в ответе не будет Content-Encoding: gzip, значит проблема на вашей стороне (антивирус или хитрый прокси) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258883,258904#msg-258904 From mva at mva.name Sat May 16 08:12:06 2015 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Sat, 16 May 2015 14:12:06 +0600 Subject: =?UTF-8?B?UmU6INC30LDQvNC10LTQu9C10L3QuNC1INGA0LDQsdC+0YLRiw==?= In-Reply-To: <5554B29B.7000809@csdoc.com> References: <55549BA7.1060704@webmaster.spb.ru> <5554B29B.7000809@csdoc.com> Message-ID: <3188034.AUNUSSY9gS@note> > http://nginx.org/en/docs/http/ngx_http_core_module.html#aio > в режиме aio threads Возможно, память меня подводит, но, вроде как, из 1.9 убали aio... -- 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 dmitry at labutin.com Sat May 16 08:39:04 2015 From: dmitry at labutin.com (Dmitry Labutin) Date: Sat, 16 May 2015 11:39:04 +0300 Subject: =?UTF-8?B?bmd4X2h0dHBfdXBzdHJlYW1fbW9kdWxlINCy0YHQtdCz0LTQsCDQv9GA0L7QstC1?= =?UTF-8?B?0YDRj9C10YIg0LbQuNCyINC70Lgg0YHQtdGA0LLQtdGAINC90LAg0LfQsNC/?= =?UTF-8?B?0YDQvtGB0LDRhSDRgNC10LDQu9GM0L3Ri9GFINC60LvQuNC10L3RgtC+0LI/?= Message-ID: <55570228.8020609@labutin.com> Доброго времени суток. Подскажите, пожалуйста, может я просто не нашел этого в документации. Я понимаю, что ngx_http_upstream_module работает так: Если в течении fail_timeout сервер max_fails раз не ответит, то он считается вышедшим из строя и в течении fail_timeout к серверу больше запросы слаться не будут. Но потом снова будут идти попытки запросов к этому серверу. Причем запросы реальных клиентов. И если сервер так и недоступен, то эти клиенты будут немного подтормаживать :( Другими словами nginx тестирует доступность сервером с помощью реальных запросов. Теперь вопрос: а можно сделать так, чтобы упавший сервер тыкал бы какой-то отдельный процесс, а запросы клиентов туда бы не слались пока сервер недоступен? Дмитрий Лабутин From sytar.alex at gmail.com Sat May 16 11:41:40 2015 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Sat, 16 May 2015 14:41:40 +0300 Subject: =?UTF-8?B?UmU6IG5neF9odHRwX3Vwc3RyZWFtX21vZHVsZSDQstGB0LXQs9C00LAg0L/RgNC+?= =?UTF-8?B?0LLQtdGA0Y/QtdGCINC20LjQsiDQu9C4INGB0LXRgNCy0LXRgCDQvdCwINC3?= =?UTF-8?B?0LDQv9GA0L7RgdCw0YUg0YDQtdCw0LvRjNC90YvRhSDQutC70LjQtdC90YI=?= =?UTF-8?B?0L7Qsj8=?= In-Reply-To: <55570228.8020609@labutin.com> References: <55570228.8020609@labutin.com> Message-ID: 16 мая 2015 г., 11:39 пользователь Dmitry Labutin написал: > Доброго времени суток. > > > Теперь вопрос: а можно сделать так, чтобы упавший сервер тыкал бы какой-то > отдельный процесс, а запросы клиентов туда бы не слались пока сервер > недоступен? > > Дмитрий Лабутин > http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#health_check Только в платной версии -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Sat May 16 12:17:03 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 16 May 2015 15:17:03 +0300 Subject: =?UTF-8?B?UmU6INC30LDQvNC10LTQu9C10L3QuNC1INGA0LDQsdC+0YLRiw==?= In-Reply-To: <3188034.AUNUSSY9gS@note> References: <55549BA7.1060704@webmaster.spb.ru> <5554B29B.7000809@csdoc.com> <3188034.AUNUSSY9gS@note> Message-ID: <4229008.RKfjSU1IrE@vbart-laptop> On Saturday 16 May 2015 14:12:06 Vadim A. Misbakh-Soloviov wrote: > > http://nginx.org/en/docs/http/ngx_http_core_module.html#aio > > в режиме aio threads > > Возможно, память меня подводит, но, вроде как, из 1.9 убали aio... > Подводит. -- Валентин Бартенев From chipitsine at gmail.com Sat May 16 13:40:18 2015 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 16 May 2015 18:40:18 +0500 Subject: =?UTF-8?B?UmU6IG5neF9odHRwX3Vwc3RyZWFtX21vZHVsZSDQstGB0LXQs9C00LAg0L/RgNC+?= =?UTF-8?B?0LLQtdGA0Y/QtdGCINC20LjQsiDQu9C4INGB0LXRgNCy0LXRgCDQvdCwINC3?= =?UTF-8?B?0LDQv9GA0L7RgdCw0YUg0YDQtdCw0LvRjNC90YvRhSDQutC70LjQtdC90YI=?= =?UTF-8?B?0L7Qsj8=?= In-Reply-To: <55570228.8020609@labutin.com> References: <55570228.8020609@labutin.com> Message-ID: возможно, настройка параметра proxy_connect_timeout решит проблему 16 мая 2015 г., 13:39 пользователь Dmitry Labutin написал: > Доброго времени суток. > > Подскажите, пожалуйста, может я просто не нашел этого в документации. > Я понимаю, что ngx_http_upstream_module работает так: > Если в течении fail_timeout сервер max_fails раз не ответит, то он считается > вышедшим из строя и в течении fail_timeout к серверу больше запросы слаться > не будут. > Но потом снова будут идти попытки запросов к этому серверу. Причем запросы > реальных клиентов. И если сервер так и недоступен, то эти клиенты будут > немного подтормаживать :( > Другими словами nginx тестирует доступность сервером с помощью реальных > запросов. > > Теперь вопрос: а можно сделать так, чтобы упавший сервер тыкал бы какой-то > отдельный процесс, а запросы клиентов туда бы не слались пока сервер > недоступен? > > Дмитрий Лабутин > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Sat May 16 21:16:23 2015 From: nginx-forum at nginx.us (billgx) Date: Sat, 16 May 2015 17:16:23 -0400 Subject: =?UTF-8?B?UHJveHkg0LHQtdC3INGA0LXQtNC40YDQtdC60YLQvtCyLCDRgdC60YDRi9GC0LA=?= =?UTF-8?B?0Y8g0L/QtdGA0LXQsNC00YDQtdGB0LDRhtC40Y8=?= Message-ID: Есть цепь редиректов: domain.org/1 >>> domain.org/2 >>> files.domain.org/3.jpg proxy_redirect задает редирект откуда и куда. Я бы хотел чтобы мой прокси сервер, отдавал по адресу domain.org/1 последний документ в цепи, в моем случае files.domain.org/3.jpg. Клиент не должен знать о редиректах Возможно ли такое? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258928,258928#msg-258928 From denis at webmaster.spb.ru Sun May 17 15:17:34 2015 From: denis at webmaster.spb.ru (denis) Date: Sun, 17 May 2015 18:17:34 +0300 Subject: =?UTF-8?B?cmVhbGlwINC4IGFwYWNoZSDQsdC10LcgbW9kX3JwYWY=?= Message-ID: <5558B10E.10209@webmaster.spb.ru> Что нужно, чтобы realip подставлял сам реальный адрес для апача? По разным причинам пока rpaf не ставится. From nginx-forum at nginx.us Sun May 17 16:54:15 2015 From: nginx-forum at nginx.us (billgx) Date: Sun, 17 May 2015 12:54:15 -0400 Subject: =?UTF-8?B?UmU6IFByb3h5INCx0LXQtyDRgNC10LTQuNGA0LXQutGC0L7Qsiwg0YHQutGA0Ys=?= =?UTF-8?B?0YLQsNGPINC/0LXRgNC10LDQtNGA0LXRgdCw0YbQuNGP?= In-Reply-To: References: Message-ID: <4602df9a1984834a265c3ea35f48e469.NginxMailingListRussian@forum.nginx.org> Проблема решена с 1 редиректом. В данный момент проблема с двумя редиректами. Первый отрабатывает nginx, и возвращает статус 200, location /(.*) { set $download_url $1; error_page 301 302 =200 @redir; proxy_pass $download_url; proxy_redirect off; } location @redir { resolver 8.8.8.8; set $redirect $upstream_http_location; proxy_pass $redirect; } Исход этого - Вывод nginx'ом страницы в виде html шаблона 302 - Found url Там где url , это уже url файла, которого нужно было отдать. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258928,258939#msg-258939 From andrey at kopeyko.ru Sun May 17 17:17:31 2015 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Sun, 17 May 2015 20:17:31 +0300 Subject: =?UTF-8?B?UmU6IFByb3h5INCx0LXQtyDRgNC10LTQuNGA0LXQutGC0L7Qsiwg0YHQutGA0Ys=?= =?UTF-8?B?0YLQsNGPINC/0LXRgNC10LDQtNGA0LXRgdCw0YbQuNGP?= In-Reply-To: <4602df9a1984834a265c3ea35f48e469.NginxMailingListRussian@forum.nginx.org> References: <4602df9a1984834a265c3ea35f48e469.NginxMailingListRussian@forum.nginx.org> Message-ID: <5558CD2B.5060007@kopeyko.ru> 17.05.2015 19:54, billgx пишет: > location /(.*) { > set $download_url $1; > error_page 301 302 =200 @redir; > proxy_pass $download_url; > proxy_redirect off; > } > > location @redir { > resolver 8.8.8.8; > set $redirect $upstream_http_location; > proxy_pass $redirect; > } Судя по конфигу, вы хотите построить squid. Не получится. Потому что nginx совсем для другого предназначен. > -- Best regards, Andrey Kopeyko From nginx-forum at nginx.us Sun May 17 23:02:17 2015 From: nginx-forum at nginx.us (billgx) Date: Sun, 17 May 2015 19:02:17 -0400 Subject: =?UTF-8?B?UmU6IFByb3h5INCx0LXQtyDRgNC10LTQuNGA0LXQutGC0L7Qsiwg0YHQutGA0Ys=?= =?UTF-8?B?0YLQsNGPINC/0LXRgNC10LDQtNGA0LXRgdCw0YbQuNGP?= In-Reply-To: <5558CD2B.5060007@kopeyko.ru> References: <5558CD2B.5060007@kopeyko.ru> Message-ID: т.е. нет возможности получить последний документ в цепи из 2х редиректов, скрыто отдав клиенту? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258928,258942#msg-258942 From swood at fotofor.biz Mon May 18 21:27:12 2015 From: swood at fotofor.biz (Anton Kiryushkin) Date: Tue, 19 May 2015 00:27:12 +0300 Subject: =?UTF-8?B?bmdpbngg0Lgg0YHQttCw0YLQuNC1?= Message-ID: Всем привет. Может ли кто-то подсказать, можно ли, в том числе и по протоколу, научить nginx принимать сжатый запрос. Ну и разжимать его на лету перед проксированием в бэкенд. -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Tue May 19 14:40:46 2015 From: nginx-forum at nginx.us (test.b) Date: Tue, 19 May 2015 10:40:46 -0400 Subject: =?UTF-8?B?RW1wdHkgcmVwbHkgZnJvbSBzZXJ2ZXIg0LjQu9C4INC00LDQvdC90YvQtSDQvdC1?= =?UTF-8?B?INC/0L7Qu9GD0YfQtdC90Ys=?= Message-ID: nginx 1.8 extras При входе на страницу браузером получаем ошибку "данные не получены" или если спросить курлом "curl: (52) Empty reply from server". Включен уровень лога дебаг. запрос curl -om на который nginx отдает "Empty reply from server" отличается от запроса без ошибки только блоком 2015/05/19 03:21:32 [debug] 12269#0: *310584 http cl:-1 max:20971520 2015/05/19 03:21:32 [debug] 12269#0: *310584 rewrite phase: 3 2015/05/19 03:21:32 [debug] 12269#0: *310584 rewrite phase: 4 2015/05/19 03:21:32 [debug] 12269#0: *310584 post rewrite phase: 5 2015/05/19 03:21:32 [debug] 12269#0: *310584 generic phase: 6 2015/05/19 03:21:32 [debug] 12269#0: *310584 generic phase: 7 2015/05/19 03:21:32 [debug] 12269#0: *310584 generic phase: 8 2015/05/19 03:21:32 [debug] 12269#0: *310584 access phase: 9 2015/05/19 03:21:32 [debug] 12269#0: *310584 access phase: 10 2015/05/19 03:21:32 [debug] 12269#0: *310584 access phase: 11 2015/05/19 03:21:32 [debug] 12269#0: *310584 access phase: 12 2015/05/19 03:21:32 [debug] 12269#0: *310584 post access phase: 13 2015/05/19 03:21:32 [debug] 12269#0: *310584 try files phase: 14 2015/05/19 03:21:32 [debug] 12269#0: *310584 event timer add: -55801232: 5000:1432020097980 2015/05/19 03:21:32 [debug] 12269#0: *310584 http cleanup add: 00007F1DFCEBACE0 2015/05/19 03:21:32 [debug] 12269#0: *310584 http finalize request: -4, "/stat?" a:1, c:2 2015/05/19 03:21:32 [debug] 12269#0: *310584 http request count:2 blk:0 скрин: http://i.imgur.com/rJURxEd.png В запросе с ошибкой этот блок повторяется на один раз больше чем в запросе без ошибки. Смотрите скриншот. Полные логи в файлах. лог ошибки: Server: nginx/1.8.0 Date: Tue, 19 May 2015 07:21:12 GMT Content-Type: application/octet-stream Transfer-Encoding: chunked Connection: close Strict-Transport-Security: max-age=15552000; Public-Key-Pins: pin-sha256="***************************************"; pin-sha256="***************************************"; max-age=3600; includeSubDomains 2015/05/19 03:21:12 [debug] 11847#0: *309227 write new buf t:1 f:0 00007F1DFD0364D8, pos 00007F1DFD0364D8, size: 379 file: 0, size: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 http write filter: l:0 f:0 s:379 2015/05/19 03:21:12 [debug] 11847#0: *309227 http output filter "/stat?" 2015/05/19 03:21:12 [debug] 11847#0: *309227 http copy filter: "/stat?" 2015/05/19 03:21:12 [debug] 11847#0: *309227 image filter 2015/05/19 03:21:12 [debug] 11847#0: *309227 xslt filter body 2015/05/19 03:21:12 [debug] 11847#0: *309227 http postpone filter "/stat?" 00007F1DFD0366D0 2015/05/19 03:21:12 [debug] 11847#0: *309227 http chunk: 7 2015/05/19 03:21:12 [debug] 11847#0: *309227 http chunk: 1 2015/05/19 03:21:12 [debug] 11847#0: *309227 write old buf t:1 f:0 00007F1DFD0364D8, pos 00007F1DFD0364D8, size: 379 file: 0, size: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 write new buf t:1 f:0 00007F1DFD036770, pos 00007F1DFD036770, size: 3 file: 0, size: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 write new buf t:0 f:0 00007F1DFCB411FE, pos 00007F1DFCB411FE, size: 7 file: 0, size: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 write new buf t:0 f:0 00007F1DFCA90368, pos 00007F1DFCA90368, size: 1 file: 0, size: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 write new buf t:0 f:0 0000000000000000, pos 00007F1DFC838F3D, size: 2 file: 0, size: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 http write filter: l:0 f:0 s:392 2015/05/19 03:21:12 [debug] 11847#0: *309227 http copy filter: 0 "/stat?" 2015/05/19 03:21:12 [debug] 11847#0: *309227 http output filter "/stat?" 2015/05/19 03:21:12 [debug] 11847#0: *309227 http copy filter: "/stat?" 2015/05/19 03:21:12 [debug] 11847#0: *309227 image filter 2015/05/19 03:21:12 [debug] 11847#0: *309227 xslt filter body 2015/05/19 03:21:12 [debug] 11847#0: *309227 http postpone filter "/stat?" 00007F1DFD036878 2015/05/19 03:21:12 [debug] 11847#0: *309227 http chunk: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 write old buf t:1 f:0 00007F1DFD0364D8, pos 00007F1DFD0364D8, size: 379 file: 0, size: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 write old buf t:1 f:0 00007F1DFD036770, pos 00007F1DFD036770, size: 3 file: 0, size: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 write old buf t:0 f:0 00007F1DFCB411FE, pos 00007F1DFCB411FE, size: 7 file: 0, size: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 write old buf t:0 f:0 00007F1DFCA90368, pos 00007F1DFCA90368, size: 1 file: 0, size: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 write old buf t:0 f:0 0000000000000000, pos 00007F1DFC838F3D, size: 2 file: 0, size: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 write new buf t:0 f:0 0000000000000000, pos 00007F1DFC838F3A, size: 5 file: 0, size: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 http write filter: l:1 f:0 s:397 2015/05/19 03:21:12 [debug] 11847#0: *309227 http write filter limit 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 writev: 397 of 397 2015/05/19 03:21:12 [debug] 11847#0: *309227 http write filter 0000000000000000 2015/05/19 03:21:12 [debug] 11847#0: *309227 http copy filter: 0 "/stat?" 2015/05/19 03:21:12 [debug] 11847#0: *309227 http set discard body 2015/05/19 03:21:12 [debug] 11847#0: *309227 http finalize request: 0, "/stat?" a:1, c:1 2015/05/19 03:21:12 [debug] 11847#0: *309227 event timer add: 118: 5000:1432020077307 2015/05/19 03:21:12 [debug] 11847#0: *309227 http lingering close handler 2015/05/19 03:21:12 [debug] 11847#0: *309227 recv: fd:118 -1 of 4096 2015/05/19 03:21:12 [debug] 11847#0: *309227 recv() not ready (11: Resource temporarily unavailable) 2015/05/19 03:21:12 [debug] 11847#0: *309227 lingering read: -2 2015/05/19 03:21:12 [debug] 11847#0: *309227 event timer: 118, old: 1432020077307, new: 1432020077307 2015/05/19 03:21:12 [debug] 11847#0: *309227 http lingering close handler 2015/05/19 03:21:12 [debug] 11847#0: *309227 recv: fd:118 0 of 4096 2015/05/19 03:21:12 [debug] 11847#0: *309227 lingering read: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 http request count:1 blk:0 2015/05/19 03:21:12 [debug] 11847#0: *309227 http close request 2015/05/19 03:21:12 [debug] 11847#0: *309227 http log handler 2015/05/19 03:21:12 [debug] 11847#0: *309227 free: 00007F1DFCF84020, unused: 8 2015/05/19 03:21:12 [debug] 11847#0: *309227 free: 00007F1DFD035EA0, unused: 1322 2015/05/19 03:21:12 [debug] 11847#0: *309227 close http connection: 118 2015/05/19 03:21:12 [debug] 11847#0: *309227 event timer del: 118: 1432020077307 2015/05/19 03:21:12 [debug] 11847#0: *309227 reusable connection: 0 2015/05/19 03:21:12 [debug] 11847#0: *309227 free: 00007F1DFCF94650 2015/05/19 03:21:12 [debug] 11847#0: *309227 free: 00007F1DFCC90A50, unused: 8 2015/05/19 03:21:12 [debug] 11847#0: *309227 free: 00007F1DFCF56690, unused: 72 2015/05/19 03:21:23 [debug] 12075#0: *310289 http cl:-1 max:20971520 2015/05/19 03:21:23 [debug] 12075#0: *310289 rewrite phase: 3 2015/05/19 03:21:23 [debug] 12075#0: *310289 rewrite phase: 4 2015/05/19 03:21:23 [debug] 12075#0: *310289 post rewrite phase: 5 2015/05/19 03:21:23 [debug] 12075#0: *310289 generic phase: 6 2015/05/19 03:21:23 [debug] 12075#0: *310289 generic phase: 7 2015/05/19 03:21:23 [debug] 12075#0: *310289 generic phase: 8 2015/05/19 03:21:23 [debug] 12075#0: *310289 access phase: 9 2015/05/19 03:21:23 [debug] 12075#0: *310289 access phase: 10 2015/05/19 03:21:23 [debug] 12075#0: *310289 access phase: 11 2015/05/19 03:21:23 [debug] 12075#0: *310289 access phase: 12 2015/05/19 03:21:23 [debug] 12075#0: *310289 post access phase: 13 2015/05/19 03:21:23 [debug] 12075#0: *310289 try files phase: 14 2015/05/19 03:21:23 [debug] 12075#0: *310289 event timer add: -55801232: 5000:1432020088523 2015/05/19 03:21:23 [debug] 12075#0: *310289 http cleanup add: 00007F1DFCC7A370 2015/05/19 03:21:23 [debug] 12075#0: *310289 http finalize request: -4, "/stat?" a:1, c:2 2015/05/19 03:21:23 [debug] 12075#0: *310289 http request count:2 blk:0 2015/05/19 03:21:32 [debug] 12269#0: *310584 http cl:-1 max:20971520 2015/05/19 03:21:32 [debug] 12269#0: *310584 rewrite phase: 3 2015/05/19 03:21:32 [debug] 12269#0: *310584 rewrite phase: 4 2015/05/19 03:21:32 [debug] 12269#0: *310584 post rewrite phase: 5 2015/05/19 03:21:32 [debug] 12269#0: *310584 generic phase: 6 2015/05/19 03:21:32 [debug] 12269#0: *310584 generic phase: 7 2015/05/19 03:21:32 [debug] 12269#0: *310584 generic phase: 8 2015/05/19 03:21:32 [debug] 12269#0: *310584 access phase: 9 2015/05/19 03:21:32 [debug] 12269#0: *310584 access phase: 10 2015/05/19 03:21:32 [debug] 12269#0: *310584 access phase: 11 2015/05/19 03:21:32 [debug] 12269#0: *310584 access phase: 12 2015/05/19 03:21:32 [debug] 12269#0: *310584 post access phase: 13 2015/05/19 03:21:32 [debug] 12269#0: *310584 try files phase: 14 2015/05/19 03:21:32 [debug] 12269#0: *310584 event timer add: -55801232: 5000:1432020097980 2015/05/19 03:21:32 [debug] 12269#0: *310584 http cleanup add: 00007F1DFCEBACE0 2015/05/19 03:21:32 [debug] 12269#0: *310584 http finalize request: -4, "/stat?" a:1, c:2 2015/05/19 03:21:32 [debug] 12269#0: *310584 http request count:2 blk:0 2015/05/19 03:21:37 [debug] 12269#0: *310584 event timer del: -55801232: 1432020097980 2015/05/19 03:21:37 [debug] 12269#0: *310584 echo sleep handler: "/stat?" 2015/05/19 03:21:37 [debug] 12269#0: *310584 uploadprogress error-tracker error: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 xslt filter header 2015/05/19 03:21:37 [debug] 12269#0: *310584 HTTP/1.1 200 OK а вот лог без ошибки, когда сервер отдает страницу правильно. Server: nginx/1.8.0 Date: Tue, 19 May 2015 07:21:37 GMT Content-Type: application/octet-stream Transfer-Encoding: chunked Connection: close Strict-Transport-Security: max-age=15552000; Public-Key-Pins: pin-sha256="***************************************"; pin-sha256="***************************************"; max-age=3600; includeSubDomains 2015/05/19 03:21:37 [debug] 12269#0: *310584 write new buf t:1 f:0 00007F1DFCB97AF8, pos 00007F1DFCB97AF8, size: 379 file: 0, size: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 http write filter: l:0 f:0 s:379 2015/05/19 03:21:37 [debug] 12269#0: *310584 http output filter "/stat?" 2015/05/19 03:21:37 [debug] 12269#0: *310584 http copy filter: "/stat?" 2015/05/19 03:21:37 [debug] 12269#0: *310584 image filter 2015/05/19 03:21:37 [debug] 12269#0: *310584 xslt filter body 2015/05/19 03:21:37 [debug] 12269#0: *310584 http postpone filter "/stat?" 00007F1DFCB97CF0 2015/05/19 03:21:37 [debug] 12269#0: *310584 http chunk: 7 2015/05/19 03:21:37 [debug] 12269#0: *310584 http chunk: 1 2015/05/19 03:21:37 [debug] 12269#0: *310584 write old buf t:1 f:0 00007F1DFCB97AF8, pos 00007F1DFCB97AF8, size: 379 file: 0, size: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 write new buf t:1 f:0 00007F1DFCB97D90, pos 00007F1DFCB97D90, size: 3 file: 0, size: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 write new buf t:0 f:0 00007F1DFCB411FE, pos 00007F1DFCB411FE, size: 7 file: 0, size: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 write new buf t:0 f:0 00007F1DFCA90368, pos 00007F1DFCA90368, size: 1 file: 0, size: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 write new buf t:0 f:0 0000000000000000, pos 00007F1DFC838F3D, size: 2 file: 0, size: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 http write filter: l:0 f:0 s:392 2015/05/19 03:21:37 [debug] 12269#0: *310584 http copy filter: 0 "/stat?" 2015/05/19 03:21:37 [debug] 12269#0: *310584 http output filter "/stat?" 2015/05/19 03:21:37 [debug] 12269#0: *310584 http copy filter: "/stat?" 2015/05/19 03:21:37 [debug] 12269#0: *310584 image filter 2015/05/19 03:21:37 [debug] 12269#0: *310584 xslt filter body 2015/05/19 03:21:37 [debug] 12269#0: *310584 http postpone filter "/stat?" 00007F1DFCB97E98 2015/05/19 03:21:37 [debug] 12269#0: *310584 http chunk: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 write old buf t:1 f:0 00007F1DFCB97AF8, pos 00007F1DFCB97AF8, size: 379 file: 0, size: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 write old buf t:1 f:0 00007F1DFCB97D90, pos 00007F1DFCB97D90, size: 3 file: 0, size: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 write old buf t:0 f:0 00007F1DFCB411FE, pos 00007F1DFCB411FE, size: 7 file: 0, size: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 write old buf t:0 f:0 00007F1DFCA90368, pos 00007F1DFCA90368, size: 1 file: 0, size: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 write old buf t:0 f:0 0000000000000000, pos 00007F1DFC838F3D, size: 2 file: 0, size: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 write new buf t:0 f:0 0000000000000000, pos 00007F1DFC838F3A, size: 5 file: 0, size: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 http write filter: l:1 f:0 s:397 2015/05/19 03:21:37 [debug] 12269#0: *310584 http write filter limit 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 writev: 397 of 397 2015/05/19 03:21:37 [debug] 12269#0: *310584 http write filter 0000000000000000 2015/05/19 03:21:37 [debug] 12269#0: *310584 http copy filter: 0 "/stat?" 2015/05/19 03:21:37 [debug] 12269#0: *310584 http set discard body 2015/05/19 03:21:37 [debug] 12269#0: *310584 http finalize request: 0, "/stat?" a:1, c:1 2015/05/19 03:21:37 [debug] 12269#0: *310584 event timer add: 82: 5000:1432020102980 2015/05/19 03:21:37 [debug] 12269#0: *310584 http lingering close handler 2015/05/19 03:21:37 [debug] 12269#0: *310584 recv: fd:82 -1 of 4096 2015/05/19 03:21:37 [debug] 12269#0: *310584 recv() not ready (11: Resource temporarily unavailable) 2015/05/19 03:21:37 [debug] 12269#0: *310584 lingering read: -2 2015/05/19 03:21:37 [debug] 12269#0: *310584 event timer: 82, old: 1432020102980, new: 1432020102980 2015/05/19 03:21:37 [debug] 12269#0: *310584 http lingering close handler 2015/05/19 03:21:37 [debug] 12269#0: *310584 recv: fd:82 0 of 4096 2015/05/19 03:21:37 [debug] 12269#0: *310584 lingering read: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 http request count:1 blk:0 2015/05/19 03:21:37 [debug] 12269#0: *310584 http close request 2015/05/19 03:21:37 [debug] 12269#0: *310584 http log handler 2015/05/19 03:21:37 [debug] 12269#0: *310584 free: 00007F1DFCEB9D00, unused: 8 2015/05/19 03:21:37 [debug] 12269#0: *310584 free: 00007F1DFCB974C0, unused: 1322 2015/05/19 03:21:37 [debug] 12269#0: *310584 close http connection: 82 2015/05/19 03:21:37 [debug] 12269#0: *310584 event timer del: 82: 1432020102980 2015/05/19 03:21:37 [debug] 12269#0: *310584 reusable connection: 0 2015/05/19 03:21:37 [debug] 12269#0: *310584 free: 00007F1DFCCB80C0 2015/05/19 03:21:37 [debug] 12269#0: *310584 free: 00007F1DFCDF2080, unused: 8 2015/05/19 03:21:37 [debug] 12269#0: *310584 free: 00007F1DFCCB7ED0, unused: 72 2015/05/19 03:22:11 [debug] 12130#0: *313115 http cl:-1 max:20971520 2015/05/19 03:22:11 [debug] 12130#0: *313115 rewrite phase: 3 2015/05/19 03:22:11 [debug] 12130#0: *313115 rewrite phase: 4 2015/05/19 03:22:11 [debug] 12130#0: *313115 post rewrite phase: 5 2015/05/19 03:22:11 [debug] 12130#0: *313115 generic phase: 6 2015/05/19 03:22:11 [debug] 12130#0: *313115 generic phase: 7 2015/05/19 03:22:11 [debug] 12130#0: *313115 generic phase: 8 2015/05/19 03:22:11 [debug] 12130#0: *313115 access phase: 9 2015/05/19 03:22:11 [debug] 12130#0: *313115 access phase: 10 2015/05/19 03:22:11 [debug] 12130#0: *313115 access phase: 11 2015/05/19 03:22:11 [debug] 12130#0: *313115 access phase: 12 2015/05/19 03:22:11 [debug] 12130#0: *313115 post access phase: 13 2015/05/19 03:22:11 [debug] 12130#0: *313115 try files phase: 14 2015/05/19 03:22:11 [debug] 12130#0: *313115 event timer add: -55801232: 5000:1432020136263 2015/05/19 03:22:11 [debug] 12130#0: *313115 http cleanup add: 00007F1DFCB984A0 2015/05/19 03:22:11 [debug] 12130#0: *313115 http finalize request: -4, "/stat?" a:1, c:2 2015/05/19 03:22:11 [debug] 12130#0: *313115 http request count:2 blk:0 2015/05/19 03:22:16 [debug] 12130#0: *313115 event timer del: -55801232: 1432020136263 2015/05/19 03:22:16 [debug] 12130#0: *313115 echo sleep handler: "/stat?" 2015/05/19 03:22:16 [debug] 12130#0: *313115 uploadprogress error-tracker error: 0 2015/05/19 03:22:16 [debug] 12130#0: *313115 xslt filter header 2015/05/19 03:22:16 [debug] 12130#0: *313115 HTTP/1.1 200 OK в какую сторону копать, где искать ошибку? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258986,258986#msg-258986 From vbart at nginx.com Tue May 19 14:54:27 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 19 May 2015 17:54:27 +0300 Subject: =?UTF-8?B?UmU6IEVtcHR5IHJlcGx5IGZyb20gc2VydmVyINC40LvQuCDQtNCw0L3QvdGL0LUg?= =?UTF-8?B?0L3QtSDQv9C+0LvRg9GH0LXQvdGL?= In-Reply-To: References: Message-ID: <1654567.u80Mc538zh@vbart-workstation> On Tuesday 19 May 2015 10:40:46 test.b wrote: > nginx 1.8 extras [..] > > лог ошибки: [..] Причина проблемы скорее всего отражена где-то до приведенного куса лога. > 2015/05/19 03:21:37 [debug] 12269#0: *310584 echo sleep handler: "/stat?" > 2015/05/19 03:21:37 [debug] 12269#0: *310584 uploadprogress error-tracker > error: 0 [..] Такие строчки официальная версия nginx печатать не умеет. > > > в какую сторону копать, где искать ошибку? > Попытаться воспроизвести без сторонних модулей. -- Валентин Бартенев From nginx-forum at nginx.us Tue May 19 19:30:45 2015 From: nginx-forum at nginx.us (itcod) Date: Tue, 19 May 2015 15:30:45 -0400 Subject: nginx + dav + dav_ext In-Reply-To: <85CD3610-5118-4C7F-9066-F818C21234CE@karagodov.name> References: <85CD3610-5118-4C7F-9066-F818C21234CE@karagodov.name> Message-ID: Добрый день уважаемые! >On 06.05.2012, at 22:17, Alexey V. Karagodov wrote: > и планируется-ли внедрение методов LOCK / UNLOCK ? >автор ответил: >arut commented on 54cebc1 4 minutes ago > 2) да, планируется, как только у меня будет время, сделаю Уважаемые кто нибудь вкурсе!? есть ли подвижки с 12го года с LOCK/UNLOCK? PS: Если воз и ныне там, то может кто нить знает как правильно заглушку для встроенного Microsoft-WebDrive-MiniRedir в конфиге написать.... что то типа: if ($request_method = LOCK) { # Unsupported, allways return 204 (No Content). return 204; } а то ругается масдай, что размер перетаскиваемого в dav-диск файла велик... и содержание смонтированного раздела после этого не обновляет.... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,225769,258995#msg-258995 From wanderermg at gmail.com Wed May 20 17:41:22 2015 From: wanderermg at gmail.com (Pavel Mironov) Date: Wed, 20 May 2015 20:41:22 +0300 Subject: =?UTF-8?Q?proxy=5Fbind_=D0=B2_ngx=5Fstream=5Fproxy=5Fmodule?= Message-ID: Добрый день! А можно ожидать в обозримом будущем появления директивы proxy_bind в ngx_stream_proxy_module, аналогичной таковой в ngx_http_proxy_module? А то именно этой опции не хватает, чтобы окончательно уйти с haproxy на nginx :) Заранее спасибо! -- Pavel Mironov -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Wed May 20 18:27:20 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 20 May 2015 21:27:20 +0300 Subject: =?UTF-8?Q?Re=3A_proxy=5Fbind_=D0=B2_ngx=5Fstream=5Fproxy=5Fmodule?= In-Reply-To: References: Message-ID: <1432149485.c7UZXz0ROV@vbart-workstation> On Wednesday 20 May 2015 20:41:22 Pavel Mironov wrote: > Добрый день! > > А можно ожидать в обозримом будущем появления директивы proxy_bind в > ngx_stream_proxy_module, аналогичной таковой в ngx_http_proxy_module? > > А то именно этой опции не хватает, чтобы окончательно уйти с haproxy на > nginx :) > > Заранее спасибо! > А кейс какой? Как эту опцию планируется использовать? -- Валентин Бартенев From arut at nginx.com Wed May 20 19:04:37 2015 From: arut at nginx.com (Roman Arutyunyan) Date: Wed, 20 May 2015 22:04:37 +0300 Subject: nginx + dav + dav_ext In-Reply-To: References: <85CD3610-5118-4C7F-9066-F818C21234CE@karagodov.name> Message-ID: On 19 May 2015, at 22:30, itcod wrote: > Добрый день уважаемые! > >> On 06.05.2012, at 22:17, Alexey V. Karagodov wrote: >> и планируется-ли внедрение методов LOCK / UNLOCK ? > >> автор ответил: >> arut commented on 54cebc1 4 minutes ago >> 2) да, планируется, как только у меня будет время, сделаю > > Уважаемые кто нибудь вкурсе!? > есть ли подвижки с 12го года с LOCK/UNLOCK? Подвижек, к сожалению, нет. > PS: Если воз и ныне там, то может кто нить знает как правильно заглушку для > встроенного Microsoft-WebDrive-MiniRedir в конфиге написать.... что то > типа: > > if ($request_method = LOCK) { # Unsupported, allways return 204 (No > Content). > return 204; > } > > а то ругается масдай, что размер перетаскиваемого в dav-диск файла велик... > и содержание смонтированного раздела после этого не обновляет.... Я не проверял, но думаю, так просто вы не отделаетесь. Вероятно, надо отдавать похожий на правду xml. -- Roman Arutyunyan From schors at gmail.com Thu May 21 07:04:40 2015 From: schors at gmail.com (Phil Kulin) Date: Thu, 21 May 2015 10:04:40 +0300 Subject: =?UTF-8?B?0YHQttCw0YLQuNC1INC80LXQttC00YMg0LTQstGD0LzRjyBuZ2lueCDQsiDRhtC1?= =?UTF-8?B?0L/QvtGH0LrQtQ==?= Message-ID: Есть такая схема: nginx frontend 1 (F1) <-> nginx frontend 2 (F1) <-> apache backend 1 (B1) (B1) не хочет ничего сжимать, потому что я ему так сказал. И модуль выключил. (F2) nginx/1.6.1 сжимает: gzip on; gzip_comp_level 9; gzip_proxied any; gzip_http_version 1.0; gzip_types text/plain text/css application/xml application/xhtml+xml image/svg+xml application/x-font-woff application/javascript; (F1) nginx/1.0.11 gzip off; Я хочу, чтобы между F1 и F2 трафик по возможности жался (тащу огромные новомодные CSS/JS/HTML килотоннами из-за рубежа). Но если я на (F1) включаю gzip, то внезапно контент начинает выдаваться с задержкой... Вопрос: 1. Есть подводные камни? Я что-то не так делаю? Что посмотреть? 2. А можно заставлять между сжиматься принудительно? -- Non nobis Domine non nobis sed Nomini Tuo da gloriam Phil Kulin From voron at amhost.net Thu May 21 10:05:16 2015 From: voron at amhost.net (Alex Vorona) Date: Thu, 21 May 2015 13:05:16 +0300 Subject: nginx-1.7.11 In-Reply-To: <20150324162213.GU88631@mdounin.ru> References: <20150324162213.GU88631@mdounin.ru> Message-ID: <555DADDC.4020006@amhost.net> 24.03.15 18:22, Maxim Dounin пишет: > Изменения в nginx 1.7.11 24.03.2015 > > *) Изменение: параметр sendfile директивы aio более не нужен; теперь > nginx автоматически использует AIO для подгрузки данных для sendfile, > если одновременно используются директивы aio и sendfile. > > *) Добавление: экспериментальная поддержка потоков. При использовании потоков столкнулся с неожиданной проблемой на CentOS 6. worker_processes 8, threads=64, reload nginx с удвоением количества процессов и имеем исчерпание лимита процессов на пользователя, потому что cat /etc/security/limits.d/90-nproc.conf # Default limit for number of user's processes to prevent # accidental fork bombs. # See rhbz #432903 for reasoning. * soft nproc 1024 И 8*64*2=1024 Добавление строчки nginx soft nproc 6000 решает проблему. При этом с самим nginx проблем не возникает, так как он запускается с лимитами root, проблемы возникают например с кронами пользователя nginx, sendmail начинает зависать и плодиться и тп. На CentOS 7 лимит по умолчанию уже 4096 процессов. From annulen at yandex.ru Thu May 21 10:52:22 2015 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 21 May 2015 13:52:22 +0300 Subject: =?UTF-8?B?UmU6INGB0LbQsNGC0LjQtSDQvNC10LbQtNGDINC00LLRg9C80Y8gbmdpbngg0LIg?= =?UTF-8?B?0YbQtdC/0L7Rh9C60LU=?= In-Reply-To: References: Message-ID: <5615051432205542@web8o.yandex.ru> 21.05.2015, 10:04, "Phil Kulin" : > Есть такая схема: > nginx frontend 1  (F1) <-> nginx frontend 2 (F1) <-> apache backend 1 (B1) > > (B1) не хочет ничего сжимать, потому что я ему так сказал. И модуль выключил. > (F2) nginx/1.6.1 > сжимает: > gzip on; > gzip_comp_level 9; > gzip_proxied any; > gzip_http_version 1.0; > gzip_types text/plain text/css application/xml application/xhtml+xml > image/svg+xml application/x-font-woff application/javascript; > (F1)  nginx/1.0.11 > gzip off; > > Я хочу, чтобы между F1 и F2 трафик по возможности жался (тащу огромные > новомодные CSS/JS/HTML килотоннами из-за рубежа). Так как F1 является исключительно кэширующим прокси, есть возможность, что для этого сценария лучше подойдет другое ПО, например, какой-нибудь Apache Traffic Server (дисклеймер: заключение чисто умозрительное, ATS на практике я не использовал) > Но если я на (F1) > включаю gzip, то внезапно контент начинает выдаваться с задержкой... Возможно, F1 пережимает траффик, и надо выключить сжатие для контента с Content-Encoding: gzip -- Regards, Konstantin From mdounin at mdounin.ru Thu May 21 13:39:11 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 21 May 2015 16:39:11 +0300 Subject: =?UTF-8?B?UmU6INGB0LbQsNGC0LjQtSDQvNC10LbQtNGDINC00LLRg9C80Y8gbmdpbngg0LIg?= =?UTF-8?B?0YbQtdC/0L7Rh9C60LU=?= In-Reply-To: References: Message-ID: <20150521133911.GR11860@mdounin.ru> Hello! On Thu, May 21, 2015 at 10:04:40AM +0300, Phil Kulin wrote: > Есть такая схема: > nginx frontend 1 (F1) <-> nginx frontend 2 (F1) <-> apache backend 1 (B1) В этой схеме оба фронтенда обозначены как F1, что затрудняет понимание. Далее комментарии в предположении, что "nginx frontend 2" на самом деле F2. > (B1) не хочет ничего сжимать, потому что я ему так сказал. И модуль выключил. > (F2) nginx/1.6.1 > сжимает: > gzip on; > gzip_comp_level 9; Не надо делать так, level 9 - это очень медленно и при этом бессмысленно. > gzip_proxied any; > gzip_http_version 1.0; > gzip_types text/plain text/css application/xml application/xhtml+xml > image/svg+xml application/x-font-woff application/javascript; > (F1) nginx/1.0.11 > gzip off; Имеет смысл обновиться. > Я хочу, чтобы между F1 и F2 трафик по возможности жался (тащу огромные > новомодные CSS/JS/HTML килотоннами из-за рубежа). Но если я на (F1) > включаю gzip, то внезапно контент начинает выдаваться с задержкой... Если я правильно расшифровал схему выше, то F1 - это внешний фронтенд, и соответственно на сжатие между F1 и F2 настройки gzip-фильтра на нём не влияют, т.к. жмёт F2. > Вопрос: > 1. Есть подводные камни? Я что-то не так делаю? Что посмотреть? См. выше про gzip_comp_level 9. Если часть из ресурсов - статика, то лучше их сжать заранее и загнать под gzip_static: http://nginx.org/ru/docs/http/ngx_http_gzip_static_module.html Следует иметь в виду, что сжатие приводит к потере заголовка Content-Length (если он был), и соответственно использованию "Transfer-Encoding: chunked" (в HTTP/1.1) или закрытию соединения (в HTTP/1.0). > 2. А можно заставлять между сжиматься принудительно? Включить gzip на F2, gunzip + "proxy_set_header Accept-Encoding gzip;" на F1. http://nginx.org/ru/docs/http/ngx_http_gunzip_module.html Потребуется обновить F1 на что-нибудь менее коллекционное. -- Maxim Dounin http://nginx.org/ From mdounin at mdounin.ru Thu May 21 14:03:56 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 21 May 2015 17:03:56 +0300 Subject: nginx-1.7.11 In-Reply-To: <555DADDC.4020006@amhost.net> References: <20150324162213.GU88631@mdounin.ru> <555DADDC.4020006@amhost.net> Message-ID: <20150521140355.GS11860@mdounin.ru> Hello! On Thu, May 21, 2015 at 01:05:16PM +0300, Alex Vorona wrote: > 24.03.15 18:22, Maxim Dounin пишет: > >Изменения в nginx 1.7.11 24.03.2015 > > > > *) Изменение: параметр sendfile директивы aio более не нужен; теперь > > nginx автоматически использует AIO для подгрузки данных для sendfile, > > если одновременно используются директивы aio и sendfile. > > > > *) Добавление: экспериментальная поддержка потоков. > При использовании потоков столкнулся с неожиданной проблемой на CentOS 6. > worker_processes 8, threads=64, reload nginx с удвоением количества > процессов и имеем исчерпание лимита процессов на пользователя, потому что > cat /etc/security/limits.d/90-nproc.conf > # Default limit for number of user's processes to prevent > # accidental fork bombs. > # See rhbz #432903 for reasoning. > > * soft nproc 1024 > И 8*64*2=1024 > > Добавление строчки > nginx soft nproc 6000 > решает проблему. При этом с самим nginx проблем не возникает, так как он > запускается с лимитами root, проблемы возникают например с кронами > пользователя nginx, sendmail начинает зависать и плодиться и тп. > > На CentOS 7 лимит по умолчанию уже 4096 процессов. Спасибо, возможно это имеет смысл отразить в документации. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Fri May 22 01:13:03 2015 From: nginx-forum at nginx.us (pincher) Date: Thu, 21 May 2015 21:13:03 -0400 Subject: nginx-1.8.0 + ngx_pagespeed-release-1.9.32.3-beta Message-ID: <15066539c5874c990422a63100388d28.NginxMailingListRussian@forum.nginx.org> Приветствую! В результате make обнаруживается ошибка: objs/addon/src/ngx_url_async_fetcher.o:/root/ngx_pagespeed-release-1.9.32.3-beta/src/ngx_url_async_fetcher.cc:84: first defined here collect2: error: ld returned 1 exit status make[1]: *** [objs/nginx] Error 1 make[1]: Leaving directory `/root/nginx-1.8.0' make: *** [build] Error 2 Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux Возможно сталкивались с подобным. Заранее благодарен за указанное направление. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259053,259053#msg-259053 From nginx-forum at nginx.us Fri May 22 01:54:37 2015 From: nginx-forum at nginx.us (pincher) Date: Thu, 21 May 2015 21:54:37 -0400 Subject: nginx-1.8.0 + ngx_pagespeed-release-1.9.32.3-beta In-Reply-To: <15066539c5874c990422a63100388d28.NginxMailingListRussian@forum.nginx.org> References: <15066539c5874c990422a63100388d28.NginxMailingListRussian@forum.nginx.org> Message-ID: <70faa25795c3b8410e55911c00c1f00c.NginxMailingListRussian@forum.nginx.org> Решилось внезапно после выполнения: #sudo apt-get install build-essential zlib1g-dev libpcre3 libpcre3-dev unzip #./configure --add-module=$HOME/ngx_pagespeed-release-${NPS_VERSION}-beta --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-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,--as-needed' --with-ipv6 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259053,259056#msg-259056 From egorovhome at gmail.com Fri May 22 13:11:11 2015 From: egorovhome at gmail.com (Sergey Egorov) Date: Fri, 22 May 2015 16:11:11 +0300 Subject: $request_body_file Message-ID: Всем Привет! 1.8.0 - проблемы с передачей $request_body_file в upstream. Нашел вот это - http://mailman.nginx.org/pipermail/nginx-ru/2007-December/015531.html Пробовал вот так ``` proxy_set_header X-FILE "$request_body_file"; proxy_pass http://127.0.0.1:8810/v1/upload?file=$request_body_file; ``` Пустая переменная при POST - X-FILE нет в заголовках, и пусто после file= Если вот так ``` proxy_set_header X-FILE "$request_body_file"; proxy_pass http://127.0.0.1:8810/v1/upload; ``` То в заголовках есть. Но хочется в запросе. Баг или так и задуманно? Сергей -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Fri May 22 13:43:58 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 22 May 2015 16:43:58 +0300 Subject: $request_body_file In-Reply-To: References: Message-ID: <20150522134358.GA11860@mdounin.ru> Hello! On Fri, May 22, 2015 at 04:11:11PM +0300, Sergey Egorov wrote: > Всем Привет! > > 1.8.0 - проблемы с передачей $request_body_file в upstream. > > Нашел вот это - > http://mailman.nginx.org/pipermail/nginx-ru/2007-December/015531.html > > Пробовал вот так > ``` > proxy_set_header X-FILE "$request_body_file"; > proxy_pass > http://127.0.0.1:8810/v1/upload?file=$request_body_file; > ``` > > Пустая переменная при POST - X-FILE нет в заголовках, и пусто после file= > > Если вот так > ``` > proxy_set_header X-FILE "$request_body_file"; > proxy_pass http://127.0.0.1:8810/v1/upload; > ``` > > То в заголовках есть. Но хочется в запросе. > > Баг или так и задуманно? Переменная $request_body_file имеет какое-либо разумное значение только после того, как прочитано тело. Меж тем, переменные в директиве proxy_pass разыменовываются до этого. Кроме того, в результате обращения к переменной $request_body_file - кешируется пустое значение, и используется в дальнейшем. Т.е., фактически, так и задумано. Точнее, предполагается, что так делать не будут, а кто сделал - тот получил уникальную возможность героически преодолевать трудности. Отдельно отмечу, что использовать переменные в proxy_pass без нужды - не очень хорошая идея сама по себе. В данном случае я бы рекомендовал ограничиться заголовком или proxy_set_body. -- Maxim Dounin http://nginx.org/ From schors at gmail.com Fri May 22 15:27:38 2015 From: schors at gmail.com (Phil Kulin) Date: Fri, 22 May 2015 18:27:38 +0300 Subject: =?UTF-8?B?UmU6INGB0LbQsNGC0LjQtSDQvNC10LbQtNGDINC00LLRg9C80Y8gbmdpbngg0LIg?= =?UTF-8?B?0YbQtdC/0L7Rh9C60LU=?= In-Reply-To: <20150521133911.GR11860@mdounin.ru> References: <20150521133911.GR11860@mdounin.ru> Message-ID: 21 мая 2015 г., 16:39 пользователь Maxim Dounin написал: > Hello! >> Есть такая схема: >> nginx frontend 1 (F1) <-> nginx frontend 2 (F1) <-> apache backend 1 (B1) > В этой схеме оба фронтенда обозначены как F1, что затрудняет > понимание. Далее комментарии в предположении, что "nginx frontend 2" > на самом деле F2. Да, конечно. Был напуган. >> gzip_proxied any; >> gzip_http_version 1.0; >> gzip_types text/plain text/css application/xml application/xhtml+xml >> image/svg+xml application/x-font-woff application/javascript; >> (F1) nginx/1.0.11 >> gzip off; > Имеет смысл обновиться. Видимо да... >> Я хочу, чтобы между F1 и F2 трафик по возможности жался (тащу огромные >> новомодные CSS/JS/HTML килотоннами из-за рубежа). Но если я на (F1) >> включаю gzip, то внезапно контент начинает выдаваться с задержкой... > Если я правильно расшифровал схему выше, то F1 - это внешний > фронтенд, и соответственно на сжатие между F1 и F2 настройки > gzip-фильтра на нём не влияют, т.к. жмёт F2. Ну вот странное подозрение, что что-то не так. Но видимо обновлюсь и применю схему ниже, тогда можно о чём-то конкретном говорить. > Следует иметь в виду, что сжатие приводит к потере заголовка > Content-Length (если он был), и соответственно использованию > "Transfer-Encoding: chunked" (в HTTP/1.1) или закрытию соединения > (в HTTP/1.0). Это в каких случаях будет срабатывать? Понятно, что в новой схеме на F1 будет: gzip_types text/plain text/css application/xml application/xhtml+xml image/svg+xml application/x-font-woff application/javascript; а gzip_proxied и gzip_http_version убраны. >> 2. А можно заставлять между сжиматься принудительно? > Включить gzip на F2, gunzip + "proxy_set_header Accept-Encoding > gzip;" на F1. > http://nginx.org/ru/docs/http/ngx_http_gunzip_module.html > Потребуется обновить F1 на что-нибудь менее коллекционное. О, спасибо. gunzip пропустил. Иду закапывать стюардессу. -- Non nobis Domine non nobis sed Nomini Tuo da gloriam Phil Kulin From mdounin at mdounin.ru Fri May 22 16:47:14 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 22 May 2015 19:47:14 +0300 Subject: =?UTF-8?B?UmU6INGB0LbQsNGC0LjQtSDQvNC10LbQtNGDINC00LLRg9C80Y8gbmdpbngg0LIg?= =?UTF-8?B?0YbQtdC/0L7Rh9C60LU=?= In-Reply-To: References: <20150521133911.GR11860@mdounin.ru> Message-ID: <20150522164714.GB11860@mdounin.ru> Hello! On Fri, May 22, 2015 at 06:27:38PM +0300, Phil Kulin wrote: > 21 мая 2015 г., 16:39 пользователь Maxim Dounin написал: [...] > > Следует иметь в виду, что сжатие приводит к потере заголовка > > Content-Length (если он был), и соответственно использованию > > "Transfer-Encoding: chunked" (в HTTP/1.1) или закрытию соединения > > (в HTTP/1.0). > > Это в каких случаях будет срабатывать? Заголовок Content-Length будет убираться в любых случаях. Соответственно если, e.g., между F1 и F2 используется HTTP/1.0 (а именно его nginx использует при общении с бекендами по умолчанию), то не будет контроля целостности ответа. А равно будет применяться несколько другая логика работы с соединением, что внутри nginx'а, что браузерами - что, соответственно, может влиять на некоторые видимые глазу показатели. -- Maxim Dounin http://nginx.org/ From for.poige+nginx at gmail.com Fri May 22 18:08:19 2015 From: for.poige+nginx at gmail.com (Igor M Podlesny) Date: Sat, 23 May 2015 01:08:19 +0700 Subject: nested location inheritance Message-ID: 2015-01-12 20:30 GMT+07:00 Maxim Dounin : > Hello! > > On Mon, Jan 12, 2015 at 04:06:33PM +0300, Vasil Mikhalenya wrote: > > > Добрый день, > > > > озадачен вопросом составления казалось бы тривиального конфига, задача - > > для определенно урла выключить логирование, обойдясь без дублирования > > конфигурации. Однако, как я понял, директивы fastcgi_pass не наследуются > во > > вложенный location. > > Директивы fastcgi_pass - не наследуются, однако все остальные > директивы fastcgi_* - наследуется. > Вот не замечаю такого для fastcgi_param, ибо если "include fastcgi_params;" находится в "location /", то нормального выполнения sub-"location ~ \.php$" не происходит. Лечится переносом include в этот самый sub-location. Абсолютно аналогично (ибо частный случай) и с отдельно стоящей fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; -- если это перенести в "location /", то скрипты опять же не работают. nginx version: nginx/1.8.0 -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri May 22 18:21:12 2015 From: nginx-forum at nginx.us (=?UTF-8?Q? =D0=9D=D0=B8=D0=BA=20=D0=93=D0=BE=D0=B4=D1=84=D0=B8=D0=BD?= =?UTF-8?Q?=D0=B3=D0=B5=D1=80 ?=) Date: Fri, 22 May 2015 14:21:12 -0400 Subject: =?UTF-8?B?0JrQsNC6INCy0LXRgNC90YPRgtGMINGA0LDQt9C80LXRgCDQv9GA0L7QutGB0Lg=?= =?UTF-8?B?0YDRg9C10LzQvtCz0L4g0L7RgtCy0LXRgtCwPw==?= Message-ID: <64e835adc273fb915284eb876db73a90.NginxMailingListRussian@forum.nginx.org> Добрый вечер. Есть ли возможность настроить localtion так чтобы возвращать размер ответа проксируемого сервера вместо тела ответа? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259066,259066#msg-259066 From mdounin at mdounin.ru Fri May 22 19:34:29 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 22 May 2015 22:34:29 +0300 Subject: nested location inheritance In-Reply-To: References: Message-ID: <20150522193429.GC11860@mdounin.ru> Hello! On Sat, May 23, 2015 at 01:08:19AM +0700, Igor M Podlesny wrote: > 2015-01-12 20:30 GMT+07:00 Maxim Dounin : > > > Hello! > > > > On Mon, Jan 12, 2015 at 04:06:33PM +0300, Vasil Mikhalenya wrote: > > > > > Добрый день, > > > > > > озадачен вопросом составления казалось бы тривиального конфига, задача - > > > для определенно урла выключить логирование, обойдясь без дублирования > > > конфигурации. Однако, как я понял, директивы fastcgi_pass не наследуются > > во > > > вложенный location. > > > > Директивы fastcgi_pass - не наследуются, однако все остальные > > директивы fastcgi_* - наследуется. > > > > Вот не замечаю такого для fastcgi_param, ибо если "include > fastcgi_params;" находится в "location /", то > нормального выполнения sub-"location ~ \.php$" не происходит. Лечится > переносом include в этот самый sub-location. > Абсолютно аналогично (ибо частный случай) и с отдельно стоящей > > fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; > > -- если это перенести в "location /", то скрипты опять же не работают. Если же есть подзрение, что в nginx'е что-то работает не так, как должно, имеет смысл привести проблемную и работающаю конфигурации полностью. Из текста следует, что проблема должна проявляться на двух таких конфигурациях: location / { fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; location ~ \.php$ { fastcgi_pass 127.0.0.1:8082; } } и location / { location ~ \.php$ { fastcgi_pass 127.0.0.1:8082; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } } Однако обе конфигурации формируют совершенно одинаковый fastcgi-запрос, параметры SCRIPT_FILENAME совпадают: 2015/05/22 22:18:37 [debug] 49590#0: *1 fastcgi param: "SCRIPT_FILENAME: /tmp/index.php" 2015/05/22 22:19:30 [debug] 49596#0: *1 fastcgi param: "SCRIPT_FILENAME: /tmp/index.php" Т.е., если проблема и есть, то она в нюансах. Или проблемы на самом деле нет, и вы просто что-то делаете не так. -- Maxim Dounin http://nginx.org/ From chipitsine at gmail.com Sun May 24 17:57:26 2015 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 24 May 2015 22:57:26 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQstC10YDQvdGD0YLRjCDRgNCw0LfQvNC10YAg0L/RgNC+0Lo=?= =?UTF-8?B?0YHQuNGA0YPQtdC80L7Qs9C+INC+0YLQstC10YLQsD8=?= In-Reply-To: <64e835adc273fb915284eb876db73a90.NginxMailingListRussian@forum.nginx.org> References: <64e835adc273fb915284eb876db73a90.NginxMailingListRussian@forum.nginx.org> Message-ID: если вы не хотите получать тело ответа - метод HEAD вам в помощь. а включит или не включит проксируемый сервер Content-Length - это как вы с ним договоритесь 22 мая 2015 г., 23:21 пользователь "Ник Годфингер" написал: > Добрый вечер. > > Есть ли возможность настроить localtion так чтобы возвращать размер ответа > проксируемого сервера вместо тела ответа? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259066,259066#msg-259066 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Sun May 24 18:18:41 2015 From: nginx-forum at nginx.us (=?UTF-8?Q? =D0=9D=D0=B8=D0=BA=20=D0=93=D0=BE=D0=B4=D1=84=D0=B8=D0=BD?= =?UTF-8?Q?=D0=B3=D0=B5=D1=80 ?=) Date: Sun, 24 May 2015 14:18:41 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQstC10YDQvdGD0YLRjCDRgNCw0LfQvNC10YAg0L/RgNC+0Lo=?= =?UTF-8?B?0YHQuNGA0YPQtdC80L7Qs9C+INC+0YLQstC10YLQsD8=?= In-Reply-To: References: Message-ID: это первое, что пришло мне в голову и, к сожалению, Content-Length не передаётся. второе, что пришло в голову, - встроенный perl. более штатных способов нет? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259066,259089#msg-259089 From nginx-forum at nginx.us Sun May 24 19:10:02 2015 From: nginx-forum at nginx.us (S.A.N) Date: Sun, 24 May 2015 15:10:02 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQstC10YDQvdGD0YLRjCDRgNCw0LfQvNC10YAg0L/RgNC+0Lo=?= =?UTF-8?B?0YHQuNGA0YPQtdC80L7Qs9C+INC+0YLQstC10YLQsD8=?= In-Reply-To: References: Message-ID: >более штатных способов нет? Возможно, $upstream_response_length, но я не проверял. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259066,259090#msg-259090 From nginx-forum at nginx.us Sun May 24 23:17:20 2015 From: nginx-forum at nginx.us (=?UTF-8?Q? =D0=9D=D0=B8=D0=BA=20=D0=93=D0=BE=D0=B4=D1=84=D0=B8=D0=BD?= =?UTF-8?Q?=D0=B3=D0=B5=D1=80 ?=) Date: Sun, 24 May 2015 19:17:20 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQstC10YDQvdGD0YLRjCDRgNCw0LfQvNC10YAg0L/RgNC+0Lo=?= =?UTF-8?B?0YHQuNGA0YPQtdC80L7Qs9C+INC+0YLQstC10YLQsD8=?= In-Reply-To: References: Message-ID: <86186978818df079f9429823415db0ff.NginxMailingListRussian@forum.nginx.org> пусто Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259066,259091#msg-259091 From postmaster at softsearch.ru Mon May 25 08:54:16 2015 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 25 May 2015 11:54:16 +0300 Subject: =?UTF-8?B?UmVbMl06INCa0LDQuiDQstC10YDQvdGD0YLRjCDRgNCw0LfQvNC10YAg0L/RgNC+?= =?UTF-8?B?0LrRgdC40YDRg9C10LzQvtCz0L4g0L7RgtCy0LXRgtCwPw==?= In-Reply-To: References: Message-ID: <3310547525.20150525115416@softsearch.ru> Здравствуйте, Ник. > это первое, что пришло мне в голову и, к сожалению, Content-Length > не передаётся. Если ответ на GET идёт чанками, то и HEAD не выдаст размер. Отключите чанки (что может быть чревато для больших ответов) и должен появиться Content-Length. -- С уважением, Михаил mailto:postmaster at softsearch.ru From simplebox66 at gmail.com Mon May 25 09:44:43 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 25 May 2015 12:44:43 +0300 Subject: =?UTF-8?B?0KfQsNGB0YLQuNGH0L3Ri9C5INGB0LHRgNC+0YEg0LrQtdGI0LAgLyDRgdCx0YA=?= =?UTF-8?B?0L7RgSDQutC10YjQsCDQtNC70Y8g0L7RgtC00LXQu9GM0L3QvtCz0L4gc2Vy?= =?UTF-8?B?dmVyX25hbWUg0LjQu9C4IGxvY2F0aW9u?= Message-ID: Все привет! Посоветуйте пожалуйста удобный механизм сброса кеша для отдельного server_name или location. Надо использовать директиву proxy_cache_purge или есть что-то более разумное? Спасибо. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simplebox66 at gmail.com Mon May 25 10:11:17 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 25 May 2015 13:11:17 +0300 Subject: =?UTF-8?B?UmU6INCn0LDRgdGC0LjRh9C90YvQuSDRgdCx0YDQvtGBINC60LXRiNCwIC8g0YE=?= =?UTF-8?B?0LHRgNC+0YEg0LrQtdGI0LAg0LTQu9GPINC+0YLQtNC10LvRjNC90L7Qs9C+?= =?UTF-8?B?IHNlcnZlcl9uYW1lINC40LvQuCBsb2NhdGlvbg==?= In-Reply-To: References: Message-ID: Рассмотрел вариант с proxy_cache_bypass, но возник вопрос, а если у меня несколько фронтенд nginx и при вводе домена в браузере я попадаю то на один фронтенд nginx то на другой , а уж затем на бекенд. Получается что при использовании proxy_cache_bypass я почищу кеш только на одном произвольном фронтенд nginx, а на остальных фронтендах кеш останется старый. Выходит в моем случае кеш можно чистить только удалением файлов из каталога с кешем? 25 мая 2015 г., 12:44 пользователь Иван Мишин написал: > Все привет! > Посоветуйте пожалуйста удобный механизм сброса кеша для отдельного > server_name или location. Надо использовать директиву proxy_cache_purge или > есть что-то более разумное? > Спасибо. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arut at nginx.com Mon May 25 10:27:52 2015 From: arut at nginx.com (Roman Arutyunyan) Date: Mon, 25 May 2015 13:27:52 +0300 Subject: =?UTF-8?B?UmU6INCn0LDRgdGC0LjRh9C90YvQuSDRgdCx0YDQvtGBINC60LXRiNCwIC8g0YE=?= =?UTF-8?B?0LHRgNC+0YEg0LrQtdGI0LAg0LTQu9GPINC+0YLQtNC10LvRjNC90L7Qs9C+?= =?UTF-8?B?IHNlcnZlcl9uYW1lINC40LvQuCBsb2NhdGlvbg==?= In-Reply-To: References: Message-ID: Добрый день, On 25 May 2015, at 13:11, Иван Мишин wrote: > Рассмотрел вариант с proxy_cache_bypass, но возник вопрос, а если у меня несколько фронтенд nginx и при вводе домена в браузере я попадаю то на один фронтенд nginx то на другой , а уж затем на бекенд. Получается что при использовании proxy_cache_bypass я почищу кеш только на одном произвольном фронтенд nginx, а на остальных фронтендах кеш останется старый. proxy_cache_bypass не чистит кеш, а игнорит закешированный ответ для конкретного запроса. Для очистки кеша надо использовать директиву proxy_cache_purge, но она на данный момент доступна лишь в коммерческой версии. В любом случае изменения, конечно, будут касаться именно того nginx, на котором вы выполняете указанные действия. > Выходит в моем случае кеш можно чистить только удалением файлов из каталога с кешем? В большинстве случаев это будет работать. -- Roman Arutyunyan From simplebox66 at gmail.com Mon May 25 10:43:51 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 25 May 2015 13:43:51 +0300 Subject: =?UTF-8?B?UmU6INCn0LDRgdGC0LjRh9C90YvQuSDRgdCx0YDQvtGBINC60LXRiNCwIC8g0YE=?= =?UTF-8?B?0LHRgNC+0YEg0LrQtdGI0LAg0LTQu9GPINC+0YLQtNC10LvRjNC90L7Qs9C+?= =?UTF-8?B?IHNlcnZlcl9uYW1lINC40LvQuCBsb2NhdGlvbg==?= In-Reply-To: References: Message-ID: > > proxy_cache_bypass не чистит кеш, а игнорит закешированный ответ для Ну к примеру лежит у меня в кеше xxx.ru/page.html Если я обращусь к xxx.ru/page.html то получу ее из кеша, а если обращусь к xxx.ru/page.html используя спец заголовок описанный в proxy_cache_bypass, то запрос пойдет на бекенд а по возвращении ляжет в кеш тем самым обновив старый кеш . И уже при последующем обращении к xxx.ru/page.html я получу в ответ уже обновленный кеш. Разве нет? > Выходит в моем случае кеш можно чистить только удалением файлов из > каталога с кешем? > > В большинстве случаев это будет работать. Вариант хорош, но у меня кеш огромного размера и мне потребуется сбросить кеш для определенного server_name то я получу десятки тысяч файлов, которые не понятно каким средствами можно удалить. 25 мая 2015 г., 13:27 пользователь Roman Arutyunyan написал: > Добрый день, > > On 25 May 2015, at 13:11, Иван Мишин wrote: > > > Рассмотрел вариант с proxy_cache_bypass, но возник вопрос, а если у меня > несколько фронтенд nginx и при вводе домена в браузере я попадаю то на один > фронтенд nginx то на другой , а уж затем на бекенд. Получается что при > использовании proxy_cache_bypass я почищу кеш только на одном произвольном > фронтенд nginx, а на остальных фронтендах кеш останется старый. > > proxy_cache_bypass не чистит кеш, а игнорит закешированный ответ для > конкретного запроса. Для очистки кеша надо использовать директиву > proxy_cache_purge, но она на данный момент доступна лишь в коммерческой > версии. > > В любом случае изменения, конечно, будут касаться именно того nginx, > на котором вы выполняете указанные действия. > > > Выходит в моем случае кеш можно чистить только удалением файлов из > каталога с кешем? > > В большинстве случаев это будет работать. > > -- > Roman Arutyunyan > > > > _______________________________________________ > 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 Mon May 25 11:01:00 2015 From: onokonem at gmail.com (Daniel Podolsky) Date: Mon, 25 May 2015 14:01:00 +0300 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQmtCw0Log0LLQtdGA0L3Rg9GC0Ywg0YDQsNC30LzQtdGAINC/?= =?UTF-8?B?0YDQvtC60YHQuNGA0YPQtdC80L7Qs9C+INC+0YLQstC10YLQsD8=?= In-Reply-To: <3310547525.20150525115416@softsearch.ru> References: <3310547525.20150525115416@softsearch.ru> Message-ID: я вот подумал - эту задачу можно решить только с помощью прокси, который будет получать ответ целиком, считать его длину, и отдавать что надо. прокси такой пишется на любом языке минут за 40. но вот что я хочу спросить - откуда такая задача взялась-то? >> это первое, что пришло мне в голову и, к сожалению, Content-Length >> не передаётся. > Если ответ на GET идёт чанками, то и HEAD не выдаст размер. Отключите > чанки (что может быть чревато для больших ответов) и должен появиться > Content-Length. From vbart at nginx.com Mon May 25 11:14:30 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 25 May 2015 14:14:30 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQstC10YDQvdGD0YLRjCDRgNCw0LfQvNC10YAg0L/RgNC+0Lo=?= =?UTF-8?B?0YHQuNGA0YPQtdC80L7Qs9C+INC+0YLQstC10YLQsD8=?= In-Reply-To: <3310547525.20150525115416@softsearch.ru> References: <3310547525.20150525115416@softsearch.ru> Message-ID: <2565730.Yy2AcK6O0K@vbart-workstation> On Monday 25 May 2015 11:54:16 Михаил Монашёв wrote: > Здравствуйте, Ник. > > > это первое, что пришло мне в голову и, к сожалению, Content-Length > > не передаётся. > > Если ответ на GET идёт чанками, то и HEAD не выдаст размер. Отключите > чанки (что может быть чревато для больших ответов) и должен появиться > Content-Length. > Не должен. К тому же, по умолчанию nginx использует HTTP/1.0 для запросов на бекенд, а там чанков быть и так не может. -- Валентин Бартенев From arut at nginx.com Mon May 25 11:31:53 2015 From: arut at nginx.com (Roman Arutyunyan) Date: Mon, 25 May 2015 14:31:53 +0300 Subject: =?UTF-8?B?UmU6INCn0LDRgdGC0LjRh9C90YvQuSDRgdCx0YDQvtGBINC60LXRiNCwIC8g0YE=?= =?UTF-8?B?0LHRgNC+0YEg0LrQtdGI0LAg0LTQu9GPINC+0YLQtNC10LvRjNC90L7Qs9C+?= =?UTF-8?B?IHNlcnZlcl9uYW1lINC40LvQuCBsb2NhdGlvbg==?= In-Reply-To: References: Message-ID: <748F0300-3D23-41C6-B552-4C3E01A98AD1@nginx.com> On 25 May 2015, at 13:43, Иван Мишин wrote: > proxy_cache_bypass не чистит кеш, а игнорит закешированный ответ для > Ну к примеру лежит у меня в кеше xxx.ru/page.html > Если я обращусь к xxx.ru/page.html то получу ее из кеша, а если обращусь к xxx.ru/page.html используя спец заголовок описанный в proxy_cache_bypass, то запрос пойдет на бекенд а по возвращении ляжет в кеш тем самым обновив старый кеш . И уже при последующем обращении к xxx.ru/page.html я получу в ответ уже обновленный кеш. Разве нет? Да, работать будет. Если вас устраивает такой способ обновления кеша, то все ок. > > > Выходит в моем случае кеш можно чистить только удалением файлов из каталога с кешем? > > В большинстве случаев это будет работать. > Вариант хорош, но у меня кеш огромного размера и мне потребуется сбросить кеш для определенного server_name то я получу десятки тысяч файлов, которые не понятно каким средствами можно удалить. Сделайте разные кеши для разных server_name, будете очищать всю директорию. > > 25 мая 2015 г., 13:27 пользователь Roman Arutyunyan написал: > Добрый день, > > On 25 May 2015, at 13:11, Иван Мишин wrote: > > > Рассмотрел вариант с proxy_cache_bypass, но возник вопрос, а если у меня несколько фронтенд nginx и при вводе домена в браузере я попадаю то на один фронтенд nginx то на другой , а уж затем на бекенд. Получается что при использовании proxy_cache_bypass я почищу кеш только на одном произвольном фронтенд nginx, а на остальных фронтендах кеш останется старый. > > proxy_cache_bypass не чистит кеш, а игнорит закешированный ответ для > конкретного запроса. Для очистки кеша надо использовать директиву > proxy_cache_purge, но она на данный момент доступна лишь в коммерческой > версии. > > В любом случае изменения, конечно, будут касаться именно того nginx, > на котором вы выполняете указанные действия. > > > Выходит в моем случае кеш можно чистить только удалением файлов из каталога с кешем? > > В большинстве случаев это будет работать. > > -- > Roman Arutyunyan > > > > _______________________________________________ > 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 -- Roman Arutyunyan From nginx-forum at nginx.us Mon May 25 11:38:17 2015 From: nginx-forum at nginx.us (=?UTF-8?Q? =D0=9D=D0=B8=D0=BA=20=D0=93=D0=BE=D0=B4=D1=84=D0=B8=D0=BD?= =?UTF-8?Q?=D0=B3=D0=B5=D1=80 ?=) Date: Mon, 25 May 2015 07:38:17 -0400 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQmtCw0Log0LLQtdGA0L3Rg9GC0Ywg0YDQsNC30LzQtdGAINC/?= =?UTF-8?B?0YDQvtC60YHQuNGA0YPQtdC80L7Qs9C+INC+0YLQstC10YLQsD8=?= In-Reply-To: References: Message-ID: <8611786cafa24a434ed0fdaedb8b91ed.NginxMailingListRussian@forum.nginx.org> Есть стороний api на который нельзя повлиять. Ответы этого api пришлось пропустить через свой nginx так как в ответах нет заголовка Access-Control-Allow-Origin. Есть запрос в ответ на который приходит json: массив хешей. И есть ситуация, когда нужно не тело ответа, а знание пуст ответ или нет, а так как ответ сам по себе может быть велик то хочется схитрить. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259066,259103#msg-259103 From simplebox66 at gmail.com Mon May 25 11:53:05 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Mon, 25 May 2015 14:53:05 +0300 Subject: =?UTF-8?B?UmU6INCn0LDRgdGC0LjRh9C90YvQuSDRgdCx0YDQvtGBINC60LXRiNCwIC8g0YE=?= =?UTF-8?B?0LHRgNC+0YEg0LrQtdGI0LAg0LTQu9GPINC+0YLQtNC10LvRjNC90L7Qs9C+?= =?UTF-8?B?IHNlcnZlcl9uYW1lINC40LvQuCBsb2NhdGlvbg==?= In-Reply-To: <748F0300-3D23-41C6-B552-4C3E01A98AD1@nginx.com> References: <748F0300-3D23-41C6-B552-4C3E01A98AD1@nginx.com> Message-ID: > > Да, работать будет. Если вас устраивает такой способ обновления кеша, то > все ок. В случае расположения директивы на уровне server, обратившись к xxx.ru используя спец заголовок, обновиться весь кеш ресурса к xxx.ru ? Сделайте разные кеши для разных server_name, будете очищать всю директорию. Слишком много server_name у меня для такой схемы, можно будет легко запутаться при настройке кеша для того или иного ресурса. 25 мая 2015 г., 14:31 пользователь Roman Arutyunyan написал: > > On 25 May 2015, at 13:43, Иван Мишин wrote: > > > proxy_cache_bypass не чистит кеш, а игнорит закешированный ответ для > > Ну к примеру лежит у меня в кеше xxx.ru/page.html > > Если я обращусь к xxx.ru/page.html то получу ее из кеша, а если > обращусь к xxx.ru/page.html используя спец заголовок описанный в > proxy_cache_bypass, то запрос пойдет на бекенд а по возвращении ляжет в кеш > тем самым обновив старый кеш . И уже при последующем обращении к > xxx.ru/page.html я получу в ответ уже обновленный кеш. Разве нет? > > Да, работать будет. Если вас устраивает такой способ обновления кеша, то > все ок. > > > > > > Выходит в моем случае кеш можно чистить только удалением файлов из > каталога с кешем? > > > > В большинстве случаев это будет работать. > > Вариант хорош, но у меня кеш огромного размера и мне потребуется > сбросить кеш для определенного server_name то я получу десятки тысяч > файлов, которые не понятно каким средствами можно удалить. > > Сделайте разные кеши для разных server_name, будете очищать всю директорию. > > > > > 25 мая 2015 г., 13:27 пользователь Roman Arutyunyan > написал: > > Добрый день, > > > > On 25 May 2015, at 13:11, Иван Мишин wrote: > > > > > Рассмотрел вариант с proxy_cache_bypass, но возник вопрос, а если у > меня несколько фронтенд nginx и при вводе домена в браузере я попадаю то на > один фронтенд nginx то на другой , а уж затем на бекенд. Получается что при > использовании proxy_cache_bypass я почищу кеш только на одном произвольном > фронтенд nginx, а на остальных фронтендах кеш останется старый. > > > > proxy_cache_bypass не чистит кеш, а игнорит закешированный ответ для > > конкретного запроса. Для очистки кеша надо использовать директиву > > proxy_cache_purge, но она на данный момент доступна лишь в коммерческой > > версии. > > > > В любом случае изменения, конечно, будут касаться именно того nginx, > > на котором вы выполняете указанные действия. > > > > > Выходит в моем случае кеш можно чистить только удалением файлов из > каталога с кешем? > > > > В большинстве случаев это будет работать. > > > > -- > > Roman Arutyunyan > > > > > > > > _______________________________________________ > > 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 > > -- > Roman Arutyunyan > > > > _______________________________________________ > 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 konstantin at symbi.org Mon May 25 12:55:57 2015 From: konstantin at symbi.org (Konstantin Baryshnikov) Date: Mon, 25 May 2015 15:55:57 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQstC10YDQvdGD0YLRjCDRgNCw0LfQvNC10YAg0L/RgNC+0Lo=?= =?UTF-8?B?0YHQuNGA0YPQtdC80L7Qs9C+INC+0YLQstC10YLQsD8=?= In-Reply-To: <8611786cafa24a434ed0fdaedb8b91ed.NginxMailingListRussian@forum.nginx.org> References: <8611786cafa24a434ed0fdaedb8b91ed.NginxMailingListRussian@forum.nginx.org> Message-ID: <0CB4080B-3116-4C6F-A373-27A4C61A5D7A@symbi.org> > Есть стороний api на который нельзя повлиять. Ответы этого api пришлось > пропустить через свой nginx так как в ответах нет заголовка > Access-Control-Allow-Origin. > Есть запрос в ответ на который приходит json: массив хешей. И есть ситуация, > когда нужно не тело ответа, а знание пуст ответ или нет, а так как ответ сам > по себе может быть велик то хочется схитрить. Если даже по запросе по HTTP/1.0 не отдается Content-Length, значит, так уж устроен этот стороний API, на который нельзя повлиять. Но, может быть, он поддерживает HTTP Range Requests? From nginx-forum at nginx.us Mon May 25 20:39:58 2015 From: nginx-forum at nginx.us (dwow) Date: Mon, 25 May 2015 16:39:58 -0400 Subject: =?UTF-8?B?0JfQsNCy0LjRgdCw0LXRgiDRgdC10YDQstC10YA=?= Message-ID: Добрый вечер, такая проблема. Есть сервер А, который забирает с сервера Б статический JS файл, методом GET по HTTPS. Проблема такая: если на сервер А возникают траблы с сетью/нагрузкой, т.е. он оооочень медленно открывается, то за ним следом падает и сервер Б, причем так, что перестает отвечать по SSH. Логи пустые. В чем может быть проблема? Сервер А забивает канал серверу Б, если да, то как это лечить? Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259117,259117#msg-259117 From postmaster at softsearch.ru Tue May 26 06:56:28 2015 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 26 May 2015 09:56:28 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC10YIg0YHQtdGA0LLQtdGA?= In-Reply-To: References: Message-ID: <1355054810.20150526095628@softsearch.ru> Здравствуйте, dwow. > Есть сервер А, который забирает с сервера Б статический JS файл, методом GET > по HTTPS. > Проблема такая: если на сервер А возникают траблы с сетью/нагрузкой, т.е. он > оооочень медленно открывается, то за ним следом падает и сервер Б, причем > так, что перестает отвечать по SSH. > Логи пустые. А какие логи Вы смотрели? -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Tue May 26 07:31:57 2015 From: nginx-forum at nginx.us (dwow) Date: Tue, 26 May 2015 03:31:57 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC10YIg0YHQtdGA0LLQtdGA?= In-Reply-To: <1355054810.20150526095628@softsearch.ru> References: <1355054810.20150526095628@softsearch.ru> Message-ID: <0f2c4160e40058ad6cc625676cf2ca06.NginxMailingListRussian@forum.nginx.org> Михаил Монашёв Wrote: ------------------------------------------------------- > А какие логи Вы смотрели? все логи nginx + syslog. спасибо, вопрос решился. ответ простой: некорректно настроенная ротация логов. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259117,259125#msg-259125 From simplebox66 at gmail.com Tue May 26 10:22:36 2015 From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Tue, 26 May 2015 13:22:36 +0300 Subject: =?UTF-8?B?UmU6INCn0LDRgdGC0LjRh9C90YvQuSDRgdCx0YDQvtGBINC60LXRiNCwIC8g0YE=?= =?UTF-8?B?0LHRgNC+0YEg0LrQtdGI0LAg0LTQu9GPINC+0YLQtNC10LvRjNC90L7Qs9C+?= =?UTF-8?B?IHNlcnZlcl9uYW1lINC40LvQuCBsb2NhdGlvbg==?= In-Reply-To: References: <748F0300-3D23-41C6-B552-4C3E01A98AD1@nginx.com> Message-ID: Может быть кто-то кроме Романа знает, что будет В случае расположения директивы на уровне server, обратившись к xxx.ru используя спец заголовок, обновиться ли весь кеш ресурса к xxx.ru ? 25 мая 2015 г., 14:53 пользователь Иван Мишин написал: > Да, работать будет. Если вас устраивает такой способ обновления кеша, то >> все ок. > > > В случае расположения директивы на уровне server, обратившись к xxx.ru > используя спец заголовок, обновиться весь кеш > ресурса к xxx.ru ? > > Сделайте разные кеши для разных server_name, будете очищать всю директорию. > > Слишком много server_name у меня для такой схемы, можно будет легко > запутаться при настройке кеша для того или иного ресурса. > > 25 мая 2015 г., 14:31 пользователь Roman Arutyunyan > написал: > > >> On 25 May 2015, at 13:43, Иван Мишин wrote: >> >> > proxy_cache_bypass не чистит кеш, а игнорит закешированный ответ для >> > Ну к примеру лежит у меня в кеше xxx.ru/page.html >> > Если я обращусь к xxx.ru/page.html то получу ее из кеша, а если >> обращусь к xxx.ru/page.html используя спец заголовок описанный в >> proxy_cache_bypass, то запрос пойдет на бекенд а по возвращении ляжет в кеш >> тем самым обновив старый кеш . И уже при последующем обращении к >> xxx.ru/page.html я получу в ответ уже обновленный кеш. Разве нет? >> >> Да, работать будет. Если вас устраивает такой способ обновления кеша, то >> все ок. >> >> > >> > > Выходит в моем случае кеш можно чистить только удалением файлов из >> каталога с кешем? >> > >> > В большинстве случаев это будет работать. >> > Вариант хорош, но у меня кеш огромного размера и мне потребуется >> сбросить кеш для определенного server_name то я получу десятки тысяч >> файлов, которые не понятно каким средствами можно удалить. >> >> Сделайте разные кеши для разных server_name, будете очищать всю >> директорию. >> >> > >> > 25 мая 2015 г., 13:27 пользователь Roman Arutyunyan >> написал: >> > Добрый день, >> > >> > On 25 May 2015, at 13:11, Иван Мишин wrote: >> > >> > > Рассмотрел вариант с proxy_cache_bypass, но возник вопрос, а если у >> меня несколько фронтенд nginx и при вводе домена в браузере я попадаю то на >> один фронтенд nginx то на другой , а уж затем на бекенд. Получается что при >> использовании proxy_cache_bypass я почищу кеш только на одном произвольном >> фронтенд nginx, а на остальных фронтендах кеш останется старый. >> > >> > proxy_cache_bypass не чистит кеш, а игнорит закешированный ответ для >> > конкретного запроса. Для очистки кеша надо использовать директиву >> > proxy_cache_purge, но она на данный момент доступна лишь в коммерческой >> > версии. >> > >> > В любом случае изменения, конечно, будут касаться именно того nginx, >> > на котором вы выполняете указанные действия. >> > >> > > Выходит в моем случае кеш можно чистить только удалением файлов из >> каталога с кешем? >> > >> > В большинстве случаев это будет работать. >> > >> > -- >> > Roman Arutyunyan >> > >> > >> > >> > _______________________________________________ >> > 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 >> >> -- >> Roman Arutyunyan >> >> >> >> _______________________________________________ >> 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 arut at nginx.com Tue May 26 10:37:43 2015 From: arut at nginx.com (Roman Arutyunyan) Date: Tue, 26 May 2015 13:37:43 +0300 Subject: =?UTF-8?B?UmU6INCn0LDRgdGC0LjRh9C90YvQuSDRgdCx0YDQvtGBINC60LXRiNCwIC8g0YE=?= =?UTF-8?B?0LHRgNC+0YEg0LrQtdGI0LAg0LTQu9GPINC+0YLQtNC10LvRjNC90L7Qs9C+?= =?UTF-8?B?IHNlcnZlcl9uYW1lINC40LvQuCBsb2NhdGlvbg==?= In-Reply-To: References: <748F0300-3D23-41C6-B552-4C3E01A98AD1@nginx.com> Message-ID: On 26 May 2015, at 13:22, Иван Мишин wrote: > Может быть кто-то кроме Романа знает, что будет В случае расположения директивы на уровне server, обратившись к xxx.ru используя спец заголовок, обновиться ли весь кеш ресурса к xxx.ru ? Не очень понятно, что вы имели в виду под "обновить весь кеш ресурса к xxx.ru?. Если вы располагаете proxy_cache_bypass на уровне server, то эта директива наследуется всеми локейшенами со всеми вытекающими последствиями. Будет обновлен тот один элемент кеша, который соответствует вашему ключу. > > 25 мая 2015 г., 14:53 пользователь Иван Мишин написал: > Да, работать будет. Если вас устраивает такой способ обновления кеша, то все ок. > > В случае расположения директивы на уровне server, обратившись к xxx.ru используя спец заголовок, обновиться весь кеш ресурса к xxx.ru ? > > Сделайте разные кеши для разных server_name, будете очищать всю директорию. > Слишком много server_name у меня для такой схемы, можно будет легко запутаться при настройке кеша для того или иного ресурса. > > 25 мая 2015 г., 14:31 пользователь Roman Arutyunyan написал: > > > On 25 May 2015, at 13:43, Иван Мишин wrote: > > > proxy_cache_bypass не чистит кеш, а игнорит закешированный ответ для > > Ну к примеру лежит у меня в кеше xxx.ru/page.html > > Если я обращусь к xxx.ru/page.html то получу ее из кеша, а если обращусь к xxx.ru/page.html используя спец заголовок описанный в proxy_cache_bypass, то запрос пойдет на бекенд а по возвращении ляжет в кеш тем самым обновив старый кеш . И уже при последующем обращении к xxx.ru/page.html я получу в ответ уже обновленный кеш. Разве нет? > > Да, работать будет. Если вас устраивает такой способ обновления кеша, то все ок. > > > > > > Выходит в моем случае кеш можно чистить только удалением файлов из каталога с кешем? > > > > В большинстве случаев это будет работать. > > Вариант хорош, но у меня кеш огромного размера и мне потребуется сбросить кеш для определенного server_name то я получу десятки тысяч файлов, которые не понятно каким средствами можно удалить. > > Сделайте разные кеши для разных server_name, будете очищать всю директорию. > > > > > 25 мая 2015 г., 13:27 пользователь Roman Arutyunyan написал: > > Добрый день, > > > > On 25 May 2015, at 13:11, Иван Мишин wrote: > > > > > Рассмотрел вариант с proxy_cache_bypass, но возник вопрос, а если у меня несколько фронтенд nginx и при вводе домена в браузере я попадаю то на один фронтенд nginx то на другой , а уж затем на бекенд. Получается что при использовании proxy_cache_bypass я почищу кеш только на одном произвольном фронтенд nginx, а на остальных фронтендах кеш останется старый. > > > > proxy_cache_bypass не чистит кеш, а игнорит закешированный ответ для > > конкретного запроса. Для очистки кеша надо использовать директиву > > proxy_cache_purge, но она на данный момент доступна лишь в коммерческой > > версии. > > > > В любом случае изменения, конечно, будут касаться именно того nginx, > > на котором вы выполняете указанные действия. > > > > > Выходит в моем случае кеш можно чистить только удалением файлов из каталога с кешем? > > > > В большинстве случаев это будет работать. > > > > -- > > Roman Arutyunyan > > > > > > > > _______________________________________________ > > 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 > > -- > Roman Arutyunyan > > > > _______________________________________________ > 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 -- Roman Arutyunyan From mdounin at mdounin.ru Tue May 26 14:17:25 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 26 May 2015 17:17:25 +0300 Subject: nginx-1.9.1 Message-ID: <20150526141725.GR11860@mdounin.ru> Изменения в nginx 1.9.1 26.05.2015 *) Изменение: теперь протокол SSLv3 по умолчанию запрещён. *) Изменение: некоторые давно устаревшие директивы больше не поддерживаются. *) Добавление: параметр reuseport директивы listen. Спасибо Sepherosa Ziehau и Yingqi Lu. *) Добавление: переменная $upstream_connect_time. *) Исправление: в директиве hash на big-endian платформах. *) Исправление: nginx мог не запускаться на некоторых старых версиях Linux; ошибка появилась в 1.7.11. *) Исправление: в парсинге IP-адресов. Спасибо Сергею Половко. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Tue May 26 16:19:19 2015 From: nginx-forum at nginx.us (vgoncharov) Date: Tue, 26 May 2015 12:19:19 -0400 Subject: =?UTF-8?B?0J/QtdGA0LXQvNC10L3QvdGL0LUgc2VudCBodHRwICDRgyDQvNC10L3RjyDQv9C+?= =?UTF-8?B?0YfQtdC80YMt0YLQviDQv9GD0YHRgtGL0LU=?= Message-ID: <51268e31543359375414d1feef270e74.NginxMailingListRussian@forum.nginx.org> Добрый день. Использую nginx как reverse-proxy. Бакенд иногда выдает неправильный Content-Type. Исправиль на бакенде это не получается, но можно добавлять кастомный header с нужным Contnt-Type. Таким образом nginx получает от бакенда такие response-headers: Content-tyype: text/html X-My-Content-type: text/csv Вообще, там еще есть X-Accel-redirect, но я пытаюсь упростить. Итак, мно нужно отдать клиенту: Content-type: text/csv Вот что я написал: location /myloc/ { proxy_pass ...; more_set_headers "Content-type: $sent_http_x_my_content_type"; } В итоге клиент получает ответ без response-header'а "Content-type", то есть $sent_http_x_my_content_type - пустое. Проверял firebug'ом - X-My-Content-type - в наличии. Пробовал more_set_headers "x-abc: x $sent_http_vary $sent_http_expires $sent_http_x_my_content_type"; Но клинт получал только: x-abc: x Вопрос: как мне правильно значение в X-My-Content-type подставить в Content-type? Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259138,259138#msg-259138 From nginx-forum at nginx.us Tue May 26 16:23:22 2015 From: nginx-forum at nginx.us (=?UTF-8?Q? =D0=9D=D0=B8=D0=BA=20=D0=93=D0=BE=D0=B4=D1=84=D0=B8=D0=BD?= =?UTF-8?Q?=D0=B3=D0=B5=D1=80 ?=) Date: Tue, 26 May 2015 12:23:22 -0400 Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LzQtdC90L3Ri9C1IHNlbnQgaHR0cCAg0YMg0LzQtdC90Y8g?= =?UTF-8?B?0L/QvtGH0LXQvNGDLdGC0L4g0L/Rg9GB0YLRi9C1?= In-Reply-To: <51268e31543359375414d1feef270e74.NginxMailingListRussian@forum.nginx.org> References: <51268e31543359375414d1feef270e74.NginxMailingListRussian@forum.nginx.org> Message-ID: proxy_ignore_headers Content-Type; proxy_hide_header Content-Type; add_header Content-Type $upstream_http_x_my_content_type; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259138,259139#msg-259139 From anatoly at sonru.com Tue May 26 22:05:38 2015 From: anatoly at sonru.com (Anatoly Mikhaylov) Date: Tue, 26 May 2015 23:05:38 +0100 Subject: $request_body_file In-Reply-To: <20150522134358.GA11860@mdounin.ru> References: <20150522134358.GA11860@mdounin.ru> Message-ID: <2F9CE44D-8951-430C-A91F-67F1CC36A9DD@sonru.com> В настоящее время такой конфиг работает с Nginx 1.5.13. Все данные, необходимые бэкэнду, чтобы принять proxy_pass, передаются в заголовках, проблем никаких не возникает. location /upload { limit_except POST { deny all; } keepalive_timeout 300s; client_body_temp_path /tmp/; client_body_in_file_only on; client_body_buffer_size 128K; client_max_body_size 100M; proxy_pass_request_headers on; proxy_set_header X-File $request_body_file; proxy_set_body off; proxy_redirect off; proxy_pass https://api.domain.com/v1/upload; error_log /var/log/nginx/nginx.upload.error.log; } Будет ли какие изменения поведения аплоада при апргейде до 1.8+? Анатолий On 22 May 2015, at 14:43, Maxim Dounin wrote: > Hello! > > On Fri, May 22, 2015 at 04:11:11PM +0300, Sergey Egorov wrote: > >> Всем Привет! >> >> 1.8.0 - проблемы с передачей $request_body_file в upstream. >> >> Нашел вот это - >> http://mailman.nginx.org/pipermail/nginx-ru/2007-December/015531.html >> >> Пробовал вот так >> ``` >> proxy_set_header X-FILE "$request_body_file"; >> proxy_pass >> http://127.0.0.1:8810/v1/upload?file=$request_body_file; >> ``` >> >> Пустая переменная при POST - X-FILE нет в заголовках, и пусто после file= >> >> Если вот так >> ``` >> proxy_set_header X-FILE "$request_body_file"; >> proxy_pass http://127.0.0.1:8810/v1/upload; >> ``` >> >> То в заголовках есть. Но хочется в запросе. >> >> Баг или так и задуманно? > > Переменная $request_body_file имеет какое-либо разумное значение > только после того, как прочитано тело. Меж тем, переменные в > директиве proxy_pass разыменовываются до этого. Кроме того, в > результате обращения к переменной $request_body_file - кешируется > пустое значение, и используется в дальнейшем. > > Т.е., фактически, так и задумано. Точнее, предполагается, что так > делать не будут, а кто сделал - тот получил уникальную возможность > героически преодолевать трудности. > > Отдельно отмечу, что использовать переменные в proxy_pass без > нужды - не очень хорошая идея сама по себе. В данном случае я бы > рекомендовал ограничиться заголовком или proxy_set_body. > > -- > 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 anatoly at sonru.com Tue May 26 22:40:18 2015 From: anatoly at sonru.com (Anatoly Mikhaylov) Date: Tue, 26 May 2015 23:40:18 +0100 Subject: nginx-1.9.1 In-Reply-To: <20150526141725.GR11860@mdounin.ru> References: <20150526141725.GR11860@mdounin.ru> Message-ID: reuseport доступен в open source версии? Anatoly > On 26 May 2015, at 15:17, Maxim Dounin wrote: > > Изменения в nginx 1.9.1 26.05.2015 > > *) Изменение: теперь протокол SSLv3 по умолчанию запрещён. > > *) Изменение: некоторые давно устаревшие директивы больше не > поддерживаются. > > *) Добавление: параметр reuseport директивы listen. > Спасибо Sepherosa Ziehau и Yingqi Lu. > > *) Добавление: переменная $upstream_connect_time. > > *) Исправление: в директиве hash на big-endian платформах. > > *) Исправление: nginx мог не запускаться на некоторых старых версиях > Linux; ошибка появилась в 1.7.11. > > *) Исправление: в парсинге IP-адресов. > Спасибо Сергею Половко. > > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Tue May 26 23:43:22 2015 From: nginx-forum at nginx.us (S.A.N) Date: Tue, 26 May 2015 19:43:22 -0400 Subject: cache_methods GET HEAD Message-ID: <4df6fdc1c7e79916e6248a2258370a49.NginxMailingListRussian@forum.nginx.org> При запросе методом HEAD, в кеше сохраняются только заголовки ответа. При следующем запросе методом GET, Nginx отдает из кеша ответ в котором нет тела, только заголовки. Раньше Nginx при запросе методом HEAD, на бекенд отправлял запрос методом GET, в кеш сохранял ответ бекенда, клиенту отдавал только заголовки. Таким образом ненужно было в конфиге Nginx в ключ кеша добавлять переменную $request_method, это была магия но довольно рациональна, в новых версиях Nginx, этой магии нет и нужно добавлять в ключ $request_method? Мой конфиг: gunzip on; fastcgi_cache cache; fastcgi_cache_lock on; fastcgi_cache_min_uses 2; fastcgi_cache_revalidate on; fastcgi_cache_methods GET HEAD; fastcgi_cache_key "$host$uri$is_args$args"; fastcgi_cache_use_stale error updating http_503; fastcgi_keep_conn on; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259148,259148#msg-259148 From nginx-ru at sadok.spb.ru Wed May 27 05:29:38 2015 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Wed, 27 May 2015 08:29:38 +0300 Subject: nginx-1.9.1 In-Reply-To: References: <20150526141725.GR11860@mdounin.ru> Message-ID: <907086531.20150527082938@sadok.spb.ru> Здравствуйте, Anatoly. Вы писали 27 мая 2015 г., 1:40:18: > reuseport доступен в open source версии? Как я понял, она в плюсе _еще_ не доступна: "(For NGINX Plus customers, this feature will be available in Release 7, which is scheduled for later this year.)" http://nginx.com/blog/socket-sharding-nginx-release-1-9-1/ -- С уважением, Dmitry mailto:nginx-ru at sadok.spb.ru From maxim at nginx.com Wed May 27 07:55:24 2015 From: maxim at nginx.com (Maxim Konovalov) Date: Wed, 27 May 2015 10:55:24 +0300 Subject: nginx-1.9.1 In-Reply-To: References: <20150526141725.GR11860@mdounin.ru> Message-ID: <5565786C.9050709@nginx.com> Анатолий, добрый день, On 5/27/15 1:40 AM, Anatoly Mikhaylov wrote: > reuseport доступен в open source версии? > Ниже наш обычный анонс очередного релиза nginx-oss. Ответ: да, доступен. > Anatoly > >> On 26 May 2015, at 15:17, Maxim Dounin wrote: >> >> Изменения в nginx 1.9.1 26.05.2015 >> >> *) Изменение: теперь протокол SSLv3 по умолчанию запрещён. >> >> *) Изменение: некоторые давно устаревшие директивы больше не >> поддерживаются. >> >> *) Добавление: параметр reuseport директивы listen. >> Спасибо Sepherosa Ziehau и Yingqi Lu. >> >> *) Добавление: переменная $upstream_connect_time. >> >> *) Исправление: в директиве hash на big-endian платформах. >> >> *) Исправление: nginx мог не запускаться на некоторых старых версиях >> Linux; ошибка появилась в 1.7.11. >> >> *) Исправление: в парсинге IP-адресов. >> Спасибо Сергею Половко. >> >> >> -- >> Maxim Dounin >> http://nginx.org/ -- Maxim Konovalov http://nginx.com From vbart at nginx.com Wed May 27 10:43:36 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 27 May 2015 13:43:36 +0300 Subject: nginx-1.9.1 In-Reply-To: References: <20150526141725.GR11860@mdounin.ru> Message-ID: <1818718.X2s0uzPqY5@vbart-workstation> On Tuesday 26 May 2015 23:40:18 Anatoly Mikhaylov wrote: > reuseport доступен в open source версии? > Changelog для NGINX Plus публикуется на nginx.com, а не тут. http://nginx.com/products/releases/ -- Валентин Бартенев From vbart at nginx.com Wed May 27 10:45:48 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 27 May 2015 13:45:48 +0300 Subject: $request_body_file In-Reply-To: <2F9CE44D-8951-430C-A91F-67F1CC36A9DD@sonru.com> References: <20150522134358.GA11860@mdounin.ru> <2F9CE44D-8951-430C-A91F-67F1CC36A9DD@sonru.com> Message-ID: <4594908.47ODXfB3Qv@vbart-workstation> On Tuesday 26 May 2015 23:05:38 Anatoly Mikhaylov wrote: > В настоящее время такой конфиг работает с Nginx 1.5.13. > Все данные, необходимые бэкэнду, чтобы принять proxy_pass, передаются > в заголовках, проблем никаких не возникает. > Речь шла про директиву proxy_pass, а не proxy_set_header. Директивы proxy_set_header обрабатываются уже после чтения тела запроса. > location /upload { > limit_except POST { deny all; } > > keepalive_timeout 300s; > client_body_temp_path /tmp/; > client_body_in_file_only on; > client_body_buffer_size 128K; > client_max_body_size 100M; > > proxy_pass_request_headers on; > proxy_set_header X-File $request_body_file; > proxy_set_body off; > proxy_redirect off; > proxy_pass https://api.domain.com/v1/upload; > error_log /var/log/nginx/nginx.upload.error.log; > } > > Будет ли какие изменения поведения аплоада при апргейде до 1.8+? > Не будет. -- Валентин Бартенев From vbart at nginx.com Wed May 27 10:48:47 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 27 May 2015 13:48:47 +0300 Subject: cache_methods GET HEAD In-Reply-To: <4df6fdc1c7e79916e6248a2258370a49.NginxMailingListRussian@forum.nginx.org> References: <4df6fdc1c7e79916e6248a2258370a49.NginxMailingListRussian@forum.nginx.org> Message-ID: <8189838.8gxm21URDf@vbart-workstation> On Tuesday 26 May 2015 19:43:22 S.A.N wrote: > При запросе методом HEAD, в кеше сохраняются только заголовки ответа. > При следующем запросе методом GET, Nginx отдает из кеша ответ в котором нет > тела, только заголовки. > > Раньше Nginx при запросе методом HEAD, на бекенд отправлял запрос методом > GET, в кеш сохранял ответ бекенда, клиенту отдавал только заголовки. И сейчас также. > Таким образом ненужно было в конфиге Nginx в ключ кеша добавлять переменную > $request_method, это была магия но довольно рациональна, в новых версиях > Nginx, этой магии нет и нужно добавлять в ключ $request_method? В новых версиях ничего не менялось в этом отношении. -- Валентин Бартенев From nginx-forum at nginx.us Wed May 27 11:54:05 2015 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 27 May 2015 07:54:05 -0400 Subject: cache_methods GET HEAD In-Reply-To: <8189838.8gxm21URDf@vbart-workstation> References: <8189838.8gxm21URDf@vbart-workstation> Message-ID: <2c6ca740b06c4d1514fbe9d4a6a12829.NginxMailingListRussian@forum.nginx.org> > В новых версиях ничего не менялось в этом отношении. В Nginx/1.9.1, с включенным кэшированием, на бекенд отправляется запрос HEAD методом. Вот простой скрипт РНР. curl -i -X HEAD http://host.dev/ HTTP/1.1 200 OK Server: nginx/1.9.1 Date: Wed, 27 May 2015 11:36:15 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive X-Powered-By: PHP/5.6.9 Cache-Control: max-age=1000 X-Method: HEAD X-Cache-Status: MISS curl -i -X GET http://host.dev/ HTTP/1.1 200 OK Server: nginx/1.9.1 Date: Wed, 27 May 2015 11:37:14 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive X-Powered-By: PHP/5.6.9 Cache-Control: max-age=1000 X-Method: HEAD X-Cache-Status: HIT Как видите, бекенд получил первый запрос HEAD методом, ответ сохранился в кеше, второй запрос GET методом, отдал предыдущий закешированый ответ от HEAD метода. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259148,259164#msg-259164 From mdounin at mdounin.ru Wed May 27 13:07:39 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 27 May 2015 16:07:39 +0300 Subject: $request_body_file In-Reply-To: <2F9CE44D-8951-430C-A91F-67F1CC36A9DD@sonru.com> References: <20150522134358.GA11860@mdounin.ru> <2F9CE44D-8951-430C-A91F-67F1CC36A9DD@sonru.com> Message-ID: <20150527130738.GA80666@mdounin.ru> Hello! On Tue, May 26, 2015 at 11:05:38PM +0100, Anatoly Mikhaylov wrote: > В настоящее время такой конфиг работает с Nginx 1.5.13. > Все данные, необходимые бэкэнду, чтобы принять proxy_pass, передаются > в заголовках, проблем никаких не возникает. [...] > proxy_pass_request_headers on; > proxy_set_header X-File $request_body_file; > proxy_set_body off; Just a side note: не совсем понятно, зачем передавать тело с текстом "off". > proxy_redirect off; > proxy_pass https://api.domain.com/v1/upload; > error_log /var/log/nginx/nginx.upload.error.log; > } > > Будет ли какие изменения поведения аплоада при апргейде до 1.8+? Нет, обсуждавшаяся проблема с использованием $request_body_file до того, как тело прочитано, не зависит от версии и не будет проявляться, если не пытаться использовать эту переменную раньше времени. В приведённом конфиге такого использования нет. -- Maxim Dounin http://nginx.org/ From vbart at nginx.com Wed May 27 14:08:11 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 27 May 2015 17:08:11 +0300 Subject: cache_methods GET HEAD In-Reply-To: <2c6ca740b06c4d1514fbe9d4a6a12829.NginxMailingListRussian@forum.nginx.org> References: <8189838.8gxm21URDf@vbart-workstation> <2c6ca740b06c4d1514fbe9d4a6a12829.NginxMailingListRussian@forum.nginx.org> Message-ID: <2868317.r3O6r3J04T@vbart-workstation> On Wednesday 27 May 2015 07:54:05 S.A.N wrote: > > В новых версиях ничего не менялось в этом отношении. > > В Nginx/1.9.1, с включенным кэшированием, на бекенд отправляется запрос HEAD > методом. > > Вот простой скрипт РНР. > > > header('Cache-Control: max-age=1000'); > header("X-Method: $_SERVER[REQUEST_METHOD]"); [..] Тут вы просто выводите значение переменной окружения, а как вы ее настроили такое там значение и будет. Если у вас в конфигурации указано: fastcgi_param REQUEST_METHOD $request_method; то будет передаваться значение переменной $request_method, а оно всегда содержит оригинальный метод запроса. Cтрого говоря в случае протокола FastCGI такого понятия, как запрос "HEAD методом" не существует. Протокол FastCGI ничего не знает о HTTP методах запроса. И ваше приложение может не разбираться в HTTP методах и все методы обрабатывать одинаково и это будет задача сервера отбросить тело в случае HEAD запроса. -- Валентин Бартенев From nginx-forum at nginx.us Wed May 27 14:28:11 2015 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 27 May 2015 10:28:11 -0400 Subject: cache_methods GET HEAD In-Reply-To: <2868317.r3O6r3J04T@vbart-workstation> References: <2868317.r3O6r3J04T@vbart-workstation> Message-ID: > fastcgi_param REQUEST_METHOD $request_method; > Cтрого говоря в случае протокола FastCGI такого понятия, как запрос > "HEAD методом" не существует Спасибо, теперь все понятно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259148,259178#msg-259178 From wangsamp at gmail.com Wed May 27 14:41:38 2015 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Wed, 27 May 2015 17:41:38 +0300 (EEST) Subject: cache_methods GET HEAD In-Reply-To: <2c6ca740b06c4d1514fbe9d4a6a12829.NginxMailingListRussian@forum.nginx.org> References: <8189838.8gxm21URDf@vbart-workstation> <2c6ca740b06c4d1514fbe9d4a6a12829.NginxMailingListRussian@forum.nginx.org> Message-ID: Today May 27, 2015 at 07:54 S.A.N wrote: > В Nginx/1.9.1, с включенным кэшированием, на бекенд отправляется запрос HEAD > методом. > > Вот простой скрипт РНР. > > header('Cache-Control: max-age=1000'); > header("X-Method: $_SERVER[REQUEST_METHOD]"); > > echo 'BODY'; > ?> > > curl -i -X HEAD http://host.dev/ > > HTTP/1.1 200 OK > Server: nginx/1.9.1 > Date: Wed, 27 May 2015 11:36:15 GMT > Content-Type: text/html; charset=UTF-8 > Connection: keep-alive > X-Powered-By: PHP/5.6.9 > Cache-Control: max-age=1000 > X-Method: HEAD > X-Cache-Status: MISS > > > curl -i -X GET http://host.dev/ > > HTTP/1.1 200 OK > Server: nginx/1.9.1 > Date: Wed, 27 May 2015 11:37:14 GMT > Content-Type: text/html; charset=UTF-8 > Transfer-Encoding: chunked > Connection: keep-alive > X-Powered-By: PHP/5.6.9 > Cache-Control: max-age=1000 > X-Method: HEAD > X-Cache-Status: HIT Как он ответил HIT на второй запрос при fastcgi_cache_min_uses 2? А если попробовать убрать fastcgi_keep_conn - вдруг бекенд с ним глючит? -- WNGS-RIPE From wangsamp at gmail.com Wed May 27 15:19:39 2015 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Wed, 27 May 2015 18:19:39 +0300 (EEST) Subject: cache_methods GET HEAD In-Reply-To: <2868317.r3O6r3J04T@vbart-workstation> References: <8189838.8gxm21URDf@vbart-workstation> <2c6ca740b06c4d1514fbe9d4a6a12829.NginxMailingListRussian@forum.nginx.org> <2868317.r3O6r3J04T@vbart-workstation> Message-ID: Today May 27, 2015 at 17:08 Валентин Бартенев wrote: > > > > > header('Cache-Control: max-age=1000'); > > header("X-Method: $_SERVER[REQUEST_METHOD]"); > [..] > > Тут вы просто выводите значение переменной окружения, а как вы ее настроили такое > там значение и будет. > Если у вас в конфигурации указано: > fastcgi_param REQUEST_METHOD $request_method;> > то будет передаваться значение переменной $request_method, а оно всегда содержит > оригинальный метод запроса. И именно такое значение в штатном fastcgi_params. > Cтрого говоря в случае протокола FastCGI такого понятия, как запрос "HEAD методом" > не существует. Протокол FastCGI ничего не знает о HTTP методах запроса. И ваше > приложение может не разбираться в HTTP методах и все методы обрабатывать одинаково > и это будет задача сервера отбросить тело в случае HEAD запроса. В примере код делает "echo 'BODY';" без привязки к методу, но тела нет в обоих ответах. Явно есть ошибка, но скорее всего в конфигурации. -- WNGS-RIPE From vbart at nginx.com Wed May 27 15:38:14 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 27 May 2015 18:38:14 +0300 Subject: cache_methods GET HEAD In-Reply-To: References: <8189838.8gxm21URDf@vbart-workstation> <2868317.r3O6r3J04T@vbart-workstation> Message-ID: <13268967.lgNA8FmBIW@vbart-workstation> On Wednesday 27 May 2015 18:19:39 Oleksandr V. Typlyns'kyi wrote: [..] > > Cтрого говоря в случае протокола FastCGI такого понятия, как запрос "HEAD методом" > > не существует. Протокол FastCGI ничего не знает о HTTP методах запроса. И ваше > > приложение может не разбираться в HTTP методах и все методы обрабатывать одинаково > > и это будет задача сервера отбросить тело в случае HEAD запроса. > > В примере код делает "echo 'BODY';" без привязки к методу, но тела нет в обоих ответах. > Явно есть ошибка, но скорее всего в конфигурации. Поверх этого кода есть ещё прослойка в виде php_fpm. Возможно что он смотрит на метод. -- Валентин Бартенев From nginx-forum at nginx.us Wed May 27 16:15:43 2015 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 27 May 2015 12:15:43 -0400 Subject: cache_methods GET HEAD In-Reply-To: <13268967.lgNA8FmBIW@vbart-workstation> References: <13268967.lgNA8FmBIW@vbart-workstation> Message-ID: > Поверх этого кода есть ещё прослойка в виде php_fpm. Возможно что он > смотрит на метод. Да, php_fpm не отдает тело ответа, если REQUEST_METHOD = HEAD. Эти нюансы могут стать проблемой, для РНР скриптов которые работали под Апачем, Nginx проксировал HTTP запросы к Апачу и кешировал, если эти РНР скрипты перенести в php_fpm, то вылезут нюансы, которых нужно учитывать. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259148,259187#msg-259187 From nginx-forum at nginx.us Wed May 27 23:25:05 2015 From: nginx-forum at nginx.us (mgaranin) Date: Wed, 27 May 2015 19:25:05 -0400 Subject: =?UTF-8?B?0JrQsNC6INGB0LTQtdC70LDRgtGMINC+0LbQuNC00LDQvdC40LUg0YTQsNC50Ls=?= =?UTF-8?B?0LA=?= Message-ID: <0f9d67e66a894af5a614908f1b1bf1f1.NginxMailingListRussian@forum.nginx.org> Здравствуйте, у меня бекенд готовит мелкие файлы которые дальше раздаёт nginx. Проблема в том, что клиент иногда запрашивает файл который ещё не готов. Сейчас клиент в таком случае получает 404 и снова делает запрос, мне это не нравиться. Можно ли средствами nginx сделать удержание запроса клиента до момента когда файл появиться? Заранее спасибо за ответы! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259205,259205#msg-259205 From nginx-forum at nginx.us Thu May 28 06:54:56 2015 From: nginx-forum at nginx.us (skeletor) Date: Thu, 28 May 2015 02:54:56 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCDQvtC20LjQtNCw0L3QuNC1INGE0LA=?= =?UTF-8?B?0LnQu9Cw?= In-Reply-To: <0f9d67e66a894af5a614908f1b1bf1f1.NginxMailingListRussian@forum.nginx.org> References: <0f9d67e66a894af5a614908f1b1bf1f1.NginxMailingListRussian@forum.nginx.org> Message-ID: <2b14f0aacffdbe74206274fbda8279a8.NginxMailingListRussian@forum.nginx.org> Можно попробовать использовать try /path/to/file /redirect/url , в которой /path/to/file - файл, который готовится, а /redirect/url - временный URL, куда будет попадать юзер, если файла ещё нет. Саму страничку URL'a можно оформить так: файл "готовится", с таймером, после которого будет опять запрошен этот же файл. Либо второй вариант - использовать встроенный perl и на нём писать задержку, проверку существования файла. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259205,259210#msg-259210 From voron at amhost.net Thu May 28 09:15:33 2015 From: voron at amhost.net (Alex Vorona) Date: Thu, 28 May 2015 12:15:33 +0300 Subject: nginx-1.9.1 In-Reply-To: <20150526141725.GR11860@mdounin.ru> References: <20150526141725.GR11860@mdounin.ru> Message-ID: <5566DCB5.2020701@amhost.net> 26.05.15 17:17, Maxim Dounin пишет: > *) Добавление: параметр reuseport директивы listen. > Спасибо Sepherosa Ziehau и Yingqi Lu. Кроме равномерного распределения коннектов между worker'ами какие еще use-case'ы ? Как работает совместно с multi_accept on ? From maxim at nginx.com Thu May 28 09:27:33 2015 From: maxim at nginx.com (Maxim Konovalov) Date: Thu, 28 May 2015 12:27:33 +0300 Subject: nginx-1.9.1 In-Reply-To: <5566DCB5.2020701@amhost.net> References: <20150526141725.GR11860@mdounin.ru> <5566DCB5.2020701@amhost.net> Message-ID: <5566DF85.7010808@nginx.com> On 5/28/15 12:15 PM, Alex Vorona wrote: > 26.05.15 17:17, Maxim Dounin пишет: >> *) Добавление: параметр reuseport директивы listen. >> Спасибо Sepherosa Ziehau и Yingqi Lu. > Кроме равномерного распределения коннектов между worker'ами какие > еще use-case'ы ? Как работает совместно с multi_accept on ? > Равномерное распределение коннектов -- это не use case. Use case: smp система, большое количество коротких tcp соединений. Подробно есть тут: http://nginx.com/blog/socket-sharding-nginx-release-1-9-1/ https://lwn.net/Articles/542629/ -- Maxim Konovalov http://nginx.com From mdounin at mdounin.ru Thu May 28 12:59:30 2015 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 28 May 2015 15:59:30 +0300 Subject: nginx-1.9.1 In-Reply-To: <5566DCB5.2020701@amhost.net> References: <20150526141725.GR11860@mdounin.ru> <5566DCB5.2020701@amhost.net> Message-ID: <20150528125930.GD26357@mdounin.ru> Hello! On Thu, May 28, 2015 at 12:15:33PM +0300, Alex Vorona wrote: > 26.05.15 17:17, Maxim Dounin пишет: > > *) Добавление: параметр reuseport директивы listen. > > Спасибо Sepherosa Ziehau и Yingqi Lu. > Кроме равномерного распределения коннектов между worker'ами какие еще > use-case'ы ? Как работает совместно с multi_accept on ? Про use case'ы Максим уже отписался - в первую очередь это имеет смысл, если речь идёт о workload'ах с высокой частотой accept'ов. Равномерность распределения соединений тоже может быть интересна, но скорее всего измерима слабо (возможно, уличшится latency при больших частотах установления SSL-соединений, но я не пробовал это тестировать). С multi_accept не пересекается никак - в зависимости от workload'а и желаемых результатов может иметь или не иметь смысл включать multi_accept. Проблема всё та же: multi_accept позволяет принять сразу несколько соединений за одну итерацию event loop'а, но ценой одного лишнего вызова accept(). Есть небольшой положительный эффект - при использовании reuseport из-за multi_accept'а не будут возникать перекосы в распределении соединений между рабочими процессами при microbenchmark'ах. От accept_mutex не зависит, все сокеты с reuseport из-под accept mutex'а автоматически выводятся. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Thu May 28 13:20:02 2015 From: nginx-forum at nginx.us (mgaranin) Date: Thu, 28 May 2015 09:20:02 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCDQvtC20LjQtNCw0L3QuNC1INGE0LA=?= =?UTF-8?B?0LnQu9Cw?= In-Reply-To: <2b14f0aacffdbe74206274fbda8279a8.NginxMailingListRussian@forum.nginx.org> References: <0f9d67e66a894af5a614908f1b1bf1f1.NginxMailingListRussian@forum.nginx.org> <2b14f0aacffdbe74206274fbda8279a8.NginxMailingListRussian@forum.nginx.org> Message-ID: <2ab48d7a2d31b6b0821f1d423840f3c5.NginxMailingListRussian@forum.nginx.org> увы, вариант со страницей мне не подходит: клиенты в основном флеш-плеер и ios-плеер, которые лезут за видео-чанками. то есть они сами понимают что при 404 нужно послать ещё запрос. меня не устраивает именно то что постоянно идёт шквал этих запросов то есть прежде чем файл подготовиться может придти 2-3 запроса от одного клиента. При этом похоже перестаёт работать "original shield" если трафик идёт через cdn, поскольку 404 не кешируются (да и не надо). Поэтому хотелось именно удержание, сделать. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259205,259222#msg-259222 From chipitsine at gmail.com Thu May 28 13:45:37 2015 From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 28 May 2015 18:45:37 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCDQvtC20LjQtNCw0L3QuNC1INGE0LA=?= =?UTF-8?B?0LnQu9Cw?= In-Reply-To: <2ab48d7a2d31b6b0821f1d423840f3c5.NginxMailingListRussian@forum.nginx.org> References: <0f9d67e66a894af5a614908f1b1bf1f1.NginxMailingListRussian@forum.nginx.org> <2b14f0aacffdbe74206274fbda8279a8.NginxMailingListRussian@forum.nginx.org> <2ab48d7a2d31b6b0821f1d423840f3c5.NginxMailingListRussian@forum.nginx.org> Message-ID: возможно, при помощи content_by_lua у вас получится. но ведь worker-процесс будет заблокирован ? может все таки лучше 404 ? 28 мая 2015 г., 18:20 пользователь mgaranin написал: > увы, вариант со страницей мне не подходит: клиенты в основном флеш-плеер и > ios-плеер, которые лезут за видео-чанками. то есть они сами понимают что при > 404 нужно послать ещё запрос. меня не устраивает именно то что постоянно > идёт шквал этих запросов то есть прежде чем файл подготовиться может придти > 2-3 запроса > от одного клиента. > При этом похоже перестаёт работать "original shield" если трафик идёт через > cdn, поскольку 404 не кешируются (да и не надо). > Поэтому хотелось именно удержание, сделать. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259205,259222#msg-259222 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nefer05 at gmail.com Thu May 28 13:46:01 2015 From: nefer05 at gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=) Date: Thu, 28 May 2015 16:46:01 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCDQvtC20LjQtNCw0L3QuNC1INGE0LA=?= =?UTF-8?B?0LnQu9Cw?= In-Reply-To: <2ab48d7a2d31b6b0821f1d423840f3c5.NginxMailingListRussian@forum.nginx.org> References: <0f9d67e66a894af5a614908f1b1bf1f1.NginxMailingListRussian@forum.nginx.org> <2b14f0aacffdbe74206274fbda8279a8.NginxMailingListRussian@forum.nginx.org> <2ab48d7a2d31b6b0821f1d423840f3c5.NginxMailingListRussian@forum.nginx.org> Message-ID: Страница может быть ПХП скриптом, который висит до появления файла либо таймаута и только тогда отдает 404 или еще что надо. 2015-05-28 16:20 GMT+03:00 mgaranin : > увы, вариант со страницей мне не подходит: клиенты в основном флеш-плеер и > ios-плеер, которые лезут за видео-чанками. то есть они сами понимают что > при > 404 нужно послать ещё запрос. меня не устраивает именно то что постоянно > идёт шквал этих запросов то есть прежде чем файл подготовиться может придти > 2-3 запроса > от одного клиента. > При этом похоже перестаёт работать "original shield" если трафик идёт через > cdn, поскольку 404 не кешируются (да и не надо). > Поэтому хотелось именно удержание, сделать. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,259205,259222#msg-259222 > > _______________________________________________ > 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 universite at ukr.net Thu May 28 14:25:36 2015 From: universite at ukr.net (Vladislav Prodan) Date: Thu, 28 May 2015 17:25:36 +0300 Subject: =?UTF-8?B?0JrQsNC6INCyIGFjY2Vzcy5sb2cg0LTQvtCx0LDQstC40YLRjCDQtNC70Y8g0Lc=?= =?UTF-8?B?0LDQv9GA0L7RgdC+0LIgc3JjIHBvcnQgPw==?= Message-ID: <1432823101.797487681.um013ju5@frv35.fwdcdn.com> Сабж. Достали открытые прокси, хочется фиксировать в логах не только src IP, но src port. Спасибо. -- Vladislav V. Prodan System & Network Administrator support.od.ua -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Thu May 28 14:48:40 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 28 May 2015 17:48:40 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQsiBhY2Nlc3MubG9nINC00L7QsdCw0LLQuNGC0Ywg0LTQu9GP?= =?UTF-8?B?INC30LDQv9GA0L7RgdC+0LIgc3JjIHBvcnQgPw==?= In-Reply-To: <1432823101.797487681.um013ju5@frv35.fwdcdn.com> References: <1432823101.797487681.um013ju5@frv35.fwdcdn.com> Message-ID: <2874246.rtr41Ga9KK@vbart-workstation> On Thursday 28 May 2015 17:25:36 Vladislav Prodan wrote: > Сабж. > > Достали открытые прокси, хочется фиксировать в логах не только src IP, но src port. > > Спасибо. > > http://nginx.org/r/$remote_port/ru -- Валентин Бартенев From nginx-forum at nginx.us Thu May 28 15:53:30 2015 From: nginx-forum at nginx.us (mgaranin) Date: Thu, 28 May 2015 11:53:30 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCDQvtC20LjQtNCw0L3QuNC1INGE0LA=?= =?UTF-8?B?0LnQu9Cw?= In-Reply-To: References: Message-ID: <9ff049264dc6379336a383897991fde3.NginxMailingListRussian@forum.nginx.org> У меня есть почти такой вариант: бекенд ,правда эрланговый, держит запрос ,ждет файл и потом send file. Просто хотелось знать можно ли сделать это только средствами Nginx. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259205,259232#msg-259232 From universite at ukr.net Thu May 28 16:15:44 2015 From: universite at ukr.net (Vladislav Prodan) Date: Thu, 28 May 2015 19:15:44 +0300 Subject: =?UTF-8?B?UmVbMl06INCa0LDQuiDQsiBhY2Nlc3MubG9nINC00L7QsdCw0LLQuNGC0Ywg0LQ=?= =?UTF-8?B?0LvRjyDQt9Cw0L/RgNC+0YHQvtCyIHNyYyBwb3J0ID8=?= In-Reply-To: <2874246.rtr41Ga9KK@vbart-workstation> References: <1432823101.797487681.um013ju5@frv35.fwdcdn.com> <1432823101.797487681.um013ju5@frv35.fwdcdn.com> <2874246.rtr41Ga9KK@vbart-workstation> Message-ID: <1432829647.331983827.6navmouj@frv35.fwdcdn.com>   --- Original message --- From: "Валентин Бартенев" Date: 28 May 2015, 17:48:47 On Thursday 28 May 2015 17:25:36 Vladislav Prodan wrote: > Сабж. > > Достали открытые прокси, хочется фиксировать в логах не только src IP, но src port. > > Спасибо. > > http://nginx.org/r/$remote_port/ru Ммм. Хотелось бы в access_log http://nginx.org/ru/docs/http/ngx_http_log_module.html И в access_list. чтоб сразу банить не только по IP, но и по порту. -- Vladislav V. Prodan System & Network Administrator support.od.ua -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Thu May 28 16:31:45 2015 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 28 May 2015 19:31:45 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQsiBhY2Nlc3MubG9nINC00L7QsdCw0LLQuNGC0Ywg0LTQu9GP?= =?UTF-8?B?INC30LDQv9GA0L7RgdC+0LIgc3JjIHBvcnQgPw==?= In-Reply-To: <1432829647.331983827.6navmouj@frv35.fwdcdn.com> References: <1432823101.797487681.um013ju5@frv35.fwdcdn.com> <2874246.rtr41Ga9KK@vbart-workstation> <1432829647.331983827.6navmouj@frv35.fwdcdn.com> Message-ID: <1818863.r0O8aYSVnV@vbart-workstation> On Thursday 28 May 2015 19:15:44 Vladislav Prodan wrote: > > --- Original message --- > From: "Валентин Бартенев" > Date: 28 May 2015, 17:48:47 > > On Thursday 28 May 2015 17:25:36 Vladislav Prodan wrote: > > Сабж. > > > > Достали открытые прокси, хочется фиксировать в логах не только src IP, но src port. > > > > Спасибо. > > > > > > http://nginx.org/r/$remote_port/ru > Ммм. Хотелось бы в access_log http://nginx.org/ru/docs/http/ngx_http_log_module.html Процитирую ссылку: "Кроме общих переменных в формате можно использовать..." "Кроме общих переменных..." > И в access_list. чтоб сразу банить не только по IP, но и по порту. > -- Валентин Бартенев From universite at ukr.net Thu May 28 18:37:42 2015 From: universite at ukr.net (Vladislav Prodan) Date: Thu, 28 May 2015 21:37:42 +0300 Subject: =?UTF-8?B?UmVbMl06INCa0LDQuiDQsiBhY2Nlc3MubG9nINC00L7QsdCw0LLQuNGC0Ywg0LQ=?= =?UTF-8?B?0LvRjyDQt9Cw0L/RgNC+0YHQvtCyIHNyYyBwb3J0ID8=?= In-Reply-To: <1818863.r0O8aYSVnV@vbart-workstation> References: <1432823101.797487681.um013ju5@frv35.fwdcdn.com> <2874246.rtr41Ga9KK@vbart-workstation> <1432829647.331983827.6navmouj@frv35.fwdcdn.com> <1432829647.331983827.6navmouj@frv35.fwdcdn.com> <1818863.r0O8aYSVnV@vbart-workstation> Message-ID: <1432838262.318402692.ek4ae2mn@frv35.fwdcdn.com>   --- Original message --- From: "Валентин Бартенев" Date: 28 May 2015, 19:31:52 On Thursday 28 May 2015 19:15:44 Vladislav Prodan wrote: > > --- Original message --- > From: "Валентин Бартенев" < vbart at nginx.com > > Date: 28 May 2015, 17:48:47 > > On Thursday 28 May 2015 17:25:36 Vladislav Prodan wrote: > > Сабж. > > > > Достали открытые прокси, хочется фиксировать в логах не только src IP, но src port. > > > > Спасибо. > > > > > > http://nginx.org/r/$remote_port/ru > Ммм. Хотелось бы в access_log http://nginx.org/ru/docs/http/ngx_http_log_module.html Процитирую ссылку: "Кроме общих переменных в формате можно использовать..." "Кроме общих переменных..." Благодарю, проблема закрыта. -- Vladislav V. Prodan System & Network Administrator support.od.ua -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu May 28 20:17:31 2015 From: nginx-forum at nginx.us (tester123) Date: Thu, 28 May 2015 16:17:31 -0400 Subject: the http output chain is empty bug In-Reply-To: <73335e88a4bcb2c6a054028e72803c6f.NginxMailingListRussian@forum.nginx.org> References: <3166049.EYtkHFoGR9@note> <19dff07fce58d3c6b26b95c940e53d4d.NginxMailingListRussian@forum.nginx.org> <73335e88a4bcb2c6a054028e72803c6f.NginxMailingListRussian@forum.nginx.org> Message-ID: <6d66e024745972e43471862c3c1222e8.NginxMailingListRussian@forum.nginx.org> УРА, РЕБЯТА!!! Не прошло и десяти лет, как кто-то наконец-то соизволил исправить эту багу. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,250456,259243#msg-259243 From dmitry at labutin.com Fri May 29 07:27:12 2015 From: dmitry at labutin.com (Dmitry Labutin) Date: Fri, 29 May 2015 10:27:12 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQsiBhY2Nlc3MubG9nINC00L7QsdCw0LLQuNGC0Ywg0LTQu9GP?= =?UTF-8?B?INC30LDQv9GA0L7RgdC+0LIgc3JjIHBvcnQgPw==?= In-Reply-To: <1432838262.318402692.ek4ae2mn@frv35.fwdcdn.com> References: <1432823101.797487681.um013ju5@frv35.fwdcdn.com> <2874246.rtr41Ga9KK@vbart-workstation> <1432829647.331983827.6navmouj@frv35.fwdcdn.com> <1432829647.331983827.6navmouj@frv35.fwdcdn.com> <1818863.r0O8aYSVnV@vbart-workstation> <1432838262.318402692.ek4ae2mn@frv35.fwdcdn.com> Message-ID: <556814D0.50801@labutin.com> Только вот зачем вам порт? Он же каждый раз разный будет! Это не тот порт, который будет настроен в браузере того, кто через open proxy идет. Это порт исходящего соединения с этого прокси сервера. И он выбирается упрощенно "первый свободный" и будет постоянно меняться. P.S. Если была мысль самому пособирать таким образом базу проксей (IP:port), то это не вариант. Дмитрий Лабутин 28.05.15 21:37, Vladislav Prodan пишет: > > > --- Original message --- > From: "Валентин Бартенев" > Date: 28 May 2015, 19:31:52 > > On Thursday 28 May 2015 19:15:44 Vladislav Prodan wrote: > > > > --- Original message --- > > From: "Валентин Бартенев" > > > Date: 28 May 2015, 17:48:47 > > > > On Thursday 28 May 2015 17:25:36 Vladislav Prodan wrote: > > > Сабж. > > > > > > Достали открытые прокси, хочется фиксировать в логах не только src IP, но src port. > > > > > > Спасибо. > > > > > > > > > >http://nginx.org/r/$remote_port/ru > > Ммм. Хотелось бы в access_loghttp://nginx.org/ru/docs/http/ngx_http_log_module.html > > Процитирую ссылку: "Кроме общих переменных в формате можно использовать..." > > "Кроме общих переменных..." > > Благодарю, проблема закрыта. > > -- > Vladislav V. Prodan > System & Network Administrator > support.od.ua > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From nginx-forum at nginx.us Sun May 31 22:47:25 2015 From: nginx-forum at nginx.us (AntonioNemcd) Date: Sun, 31 May 2015 18:47:25 -0400 Subject: =?UTF-8?B?UmU6IFdvcmRQcmVzcyArIE5naW54INGI0LjRhNGA0L7QstCw0L3QvdCw0Y8g0LA=?= =?UTF-8?B?0LTQvNC40L3QutCwINC/0YDQvtCx0LvQtdC80LAgPw==?= In-Reply-To: References: Message-ID: Приветствую! Чем же закончилась эта эпопея с https + админка? Сейчас столкнулся тоже с такой проблемой, нужно решать. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251401,259287#msg-259287 From nginx-forum at nginx.us Sun May 31 23:07:05 2015 From: nginx-forum at nginx.us (AntonioNemcd) Date: Sun, 31 May 2015 19:07:05 -0400 Subject: =?UTF-8?B?UmU6IFdvcmRQcmVzcyArIE5naW54INGI0LjRhNGA0L7QstCw0L3QvdCw0Y8g0LA=?= =?UTF-8?B?0LTQvNC40L3QutCwINC/0YDQvtCx0LvQtdC80LAgPw==?= In-Reply-To: References: Message-ID: Есть подозрение что где-то идет редирект на уровне скриптов, только пока не нашел где. Проблема давняя, уже должны был кто-то найти решение! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251401,259288#msg-259288