From chipitsine at gmail.com  Wed Apr  1 06:52:28 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 1 Apr 2015 11:52:28 +0500
Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0YPQutCw0LfRi9Cy0LDRgtGM?=
 =?UTF-8?B?INC/0LDRgNCw0LzQtdGC0YAgZ3ppcF90eXBlcyDQtNC70Y8gImFwcGxpY2F0?=
 =?UTF-8?B?aW9uL2F0b20reG1sO3R5cGU9ZmVlZDtjaGFyc2V0PXV0Zi04IiA/?=
In-Reply-To: <CAFHpkQGTUwqjU5vRPhTQeYQFJEp0oJcW9tKQtw_7sqdfJmyu2g@mail.gmail.com>
References: <CAFHpkQGTUwqjU5vRPhTQeYQFJEp0oJcW9tKQtw_7sqdfJmyu2g@mail.gmail.com>
Message-ID: <CAFHpkQFimp3qhtJncCYzKR74AHD7ELQjrm+G4SydNBk4aKn+BQ@mail.gmail.com>

up

24 марта 2015 г., 22:59 пользователь Илья Шипицин
<chipitsine at gmail.com> написал:
> Добрый день!
>
> есть контент типа application/atom+xml;type=feed;charset=utf-8
> как его сжать ?
>
> Илья Шипицин

From nginx-forum at nginx.us  Wed Apr  1 07:48:26 2015
From: nginx-forum at nginx.us (xaleks)
Date: Wed, 01 Apr 2015 03:48:26 -0400
Subject: nginx rewrite
Message-ID: <6f4d4ccb3f9791c5a51de7a312c4d81c.NginxMailingListRussian@forum.nginx.org>

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

mydomain.com/folder/123/ или mydomain.com/folder/321/

нужно добавлять index.php. т.е. ссылка должна выглядеть так:

mydomain.com/folder/index.php/123/ mydomain.com/folder/index.php/321/

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257781,257781#msg-257781


From simplebox66 at gmail.com  Wed Apr  1 07:59:46 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Wed, 1 Apr 2015 10:59:46 +0300
Subject: =?UTF-8?B?UmU6IExvY2F0aW9uINC00LvRjyBwaHAg0YHQutGA0LjQv9GC0LAg0YEg0L/QsNGA?=
 =?UTF-8?B?0LDQvNC10YLRgNCw0LzQuA==?=
In-Reply-To: <551B0E6C.9090801@kopeyko.ru>
References: <CA+ksgAAQ6NxQyp0YujuaXFY5YfqnDoOY3JCOfmw7Hpie0tVOaw@mail.gmail.com>
 <551B0E6C.9090801@kopeyko.ru>
Message-ID: <CA+ksgAA9UExXqfgOq+6HMYa1qFBhLSmfKF=6Cn6dS+n=xN9okQ@mail.gmail.com>

ВОт так?
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150401/dba4a92b/attachment.html>

From simplebox66 at gmail.com  Wed Apr  1 08:01:06 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Wed, 1 Apr 2015 11:01:06 +0300
Subject: =?UTF-8?B?UmU6IExvY2F0aW9uINC00LvRjyBwaHAg0YHQutGA0LjQv9GC0LAg0YEg0L/QsNGA?=
 =?UTF-8?B?0LDQvNC10YLRgNCw0LzQuA==?=
In-Reply-To: <CA+ksgAA9UExXqfgOq+6HMYa1qFBhLSmfKF=6Cn6dS+n=xN9okQ@mail.gmail.com>
References: <CA+ksgAAQ6NxQyp0YujuaXFY5YfqnDoOY3JCOfmw7Hpie0tVOaw@mail.gmail.com>
 <551B0E6C.9090801@kopeyko.ru>
 <CA+ksgAA9UExXqfgOq+6HMYa1qFBhLSmfKF=6Cn6dS+n=xN9okQ@mail.gmail.com>
Message-ID: <CA+ksgABnazirFG7FdD0GuniBZi-G79PFSeFybdkREms+2eWSAA@mail.gmail.com>

Приведенная выше схема не работает

2015-04-01 10:59 GMT+03:00 Иван Мишин <simplebox66 at gmail.com>:

> ВОт так?
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150401/31cd56af/attachment.html>

From nginx-forum at nginx.us  Wed Apr  1 16:04:09 2015
From: nginx-forum at nginx.us (S.A.N)
Date: Wed, 01 Apr 2015 12:04:09 -0400
Subject: Cache revalidation using If-None-Match
In-Reply-To: <20140715225203.GG1849@mdounin.ru>
References: <20140715225203.GG1849@mdounin.ru>
Message-ID: <beecfe776b7c87dd4f64484734e2c099.NginxMailingListRussian@forum.nginx.org>

> Extension", http://tools.ietf.org/html/rfc5861#section-4. Т.е.
> возможность задать в заголовках ответа - можно ли этот ответ в
> дальнейшем использовать при ошибках

Chrome, реализовал директиву stale-while-revalidate, опция пока что
экспериментальная её нужно активировать:
chrome://flags/#enable-stale-while-revalidate

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

Пример HTTP заголовка:
Cache-Control: max-age=0, stale-while-revalidate=1000000,
stale-if-error=1000000

Nginx планирует в новых версиях реализовать HTTP 2
будет очень хорошо если Nginx реализует модуль - HTTP Cache-Control
Extensions for Stale Content, для управления своим кешем.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251189,257788#msg-257788


From nginx-forum at nginx.us  Wed Apr  1 17:18:27 2015
From: nginx-forum at nginx.us (s.ivanov)
Date: Wed, 01 Apr 2015 13:18:27 -0400
Subject: =?UTF-8?B?0KDQtdCz0YPQu9GP0YDQvdGL0LUg0LLRi9GA0LDQttC10L3QuNGPINCyIGxvY2F0?=
 =?UTF-8?B?aW9u?=
Message-ID: <4b7d49e60a5298381a82e25c2cbe95a6.NginxMailingListRussian@forum.nginx.org>

Необходимо сделать проксирование запросов вида
http://site.ru/Mydll.dll?al=5f4ff3cb6478424481d6dfdf9d9a3696 на другой
веб-сервер.При этом проксировать нужно только запросы указанного вида, любые
другие в том числе и http://site.ru/Mydll.dll должны быть запрещены.

1.так
location ~* ^/Mydll.dll(.*) {
proxy_pass http://192.168.0.2:3000/$1$is_args$args;
}
срабатывает на любые запросы.

2. так
location ~* ^/Mydll.dll$ {
deny all;
}

location ~* ^/Mydll.dll(.*) {
proxy_pass http://192.168.0.2:3000/$1$is_args$args;
}
Запрещено всё вообще, не редиректит разрешённые запросы.

3. так
location = /Mydll.dll\?al=(.*) {
proxy_pass http://192.168.0.2:3000/$1$is_args$args;
}
тоже не работает - правило не срабатывает.

Вопрос: как составить регулярное выражение, чтобы правило в location
срабатывало только на URL разрешённого вида?
Спасибо.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257789,257789#msg-257789


From onokonem at gmail.com  Wed Apr  1 17:28:55 2015
From: onokonem at gmail.com (Daniel Podolsky)
Date: Wed, 1 Apr 2015 20:28:55 +0300
Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0L3Ri9C1INCy0YvRgNCw0LbQtdC90LjRjyDQsiBs?=
 =?UTF-8?B?b2NhdGlvbg==?=
In-Reply-To: <4b7d49e60a5298381a82e25c2cbe95a6.NginxMailingListRussian@forum.nginx.org>
References: <4b7d49e60a5298381a82e25c2cbe95a6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKaHDOEOGRYV31BggQa8aT+g-JmJfApET93NmJ4X5GKhs88x1A@mail.gmail.com>

Для начала - query string не проверяется при поиске location

Надо делать именованный, проверять аргумент в if и переходить в
именованный. В этом виде if - не evil

On Wednesday, April 1, 2015, s.ivanov <nginx-forum at nginx.us> wrote:

> Необходимо сделать проксирование запросов вида
> http://site.ru/Mydll.dll?al=5f4ff3cb6478424481d6dfdf9d9a3696 на другой
> веб-сервер.При этом проксировать нужно только запросы указанного вида,
> любые
> другие в том числе и http://site.ru/Mydll.dll должны быть запрещены.
>
> 1.так
> location ~* ^/Mydll.dll(.*) {
> proxy_pass http://192.168.0.2:3000/$1$is_args$args;
> }
> срабатывает на любые запросы.
>
> 2. так
> location ~* ^/Mydll.dll$ {
> deny all;
> }
>
> location ~* ^/Mydll.dll(.*) {
> proxy_pass http://192.168.0.2:3000/$1$is_args$args;
> }
> Запрещено всё вообще, не редиректит разрешённые запросы.
>
> 3. так
> location = /Mydll.dll\?al=(.*) {
> proxy_pass http://192.168.0.2:3000/$1$is_args$args;
> }
> тоже не работает - правило не срабатывает.
>
> Вопрос: как составить регулярное выражение, чтобы правило в location
> срабатывало только на URL разрешённого вида?
> Спасибо.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,257789,257789#msg-257789
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org <javascript:;>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150401/2c6503d3/attachment.html>

From v.v.biriukov at gmail.com  Wed Apr  1 17:30:17 2015
From: v.v.biriukov at gmail.com (Viacheslav Biriukov)
Date: Wed, 1 Apr 2015 20:30:17 +0300
Subject: =?UTF-8?B?UmU6INCR0L7Qu9GM0YjQvtC5IFBPU1Qg0LfQsNC/0YDQvtGBINC4INC80LPQvdC+?=
 =?UTF-8?B?0LLQtdC90L3Ri9C5INGA0LXQtNC40YDQtdC60YI=?=
In-Reply-To: <551A76CD.4020108@csdoc.com>
References: <CAPKsgQxdwy5f-JLjjH9zfG+9e-LCPkqnixEtZOOw70-WQwHa4g@mail.gmail.com>
 <649024984.20150331000252@softsearch.ru>
 <319685874.20150331112217@ngs.ru> <551A76CD.4020108@csdoc.com>
Message-ID: <CAPKsgQwmADnu-emcynkU3kBLKzCR+v8OXOEtZ+cCaPiKp5SOXQ@mail.gmail.com>

За ссылку на upload.html большое спасибо. На текущий момент, по моим
экспериментам ничего не поменялось

Принимать проблематично иногда эти лишние 50 метров данных. И да решение с
100 Continue это вроде то, что нужно, только браузеры этого не делают.

31 марта 2015 г., 13:28 пользователь Gena Makhomed <gmm at csdoc.com> написал:

> On 31.03.2015 8:22, Pavel V. wrote:
>
>  Вопрос следующий: есть клиентское приложение (сайт), которое
>>>> отсылает большие (~50MB) посты мультипартом. Хочется на некоторые
>>>> отсылать редирект: 302 или 307 √ не имеет значения.
>>>>
>>>
> Значение имеет, потому что после 302 редиректа POST превратится в GET.
>
>  Но сразу, а не зачитывая/буферезируя реквест боди на прокси. Можно?
>>>>
>>>
> Можно без проблем, если клиент работает по протоколу HTTP/1.1
> и поддерживает Expect / Continue:
>
> http://blog.eexit.net/curl-forward-post-over-http-redirections/
>
>  Могу ошибаться, но по протоколу http 1 ответ
>>> отправляется после получения всего запроса.
>>>
>>
> Даже в самом худшем случае - ничто не запрещает получить
> весь запрос (~50MB) и в ответ на него вернуть клиенту редирект.
>
>  А 413 (Request Entity Too Large) когда отправляется? Тоже после получения
>> всего запроса?
>>
>
> в 2007 году ситуация была такой: http://sysoev.ru/web/upload.html
> Почему невозможно корректно ограничить размер закачиваемого файла
>
> --
> Best regards,
>  Gena
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
Viacheslav Biriukov
BR
http://biriukov.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150401/8a1e1761/attachment.html>

From simplebox66 at gmail.com  Thu Apr  2 06:10:22 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Thu, 2 Apr 2015 09:10:22 +0300
Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0L3Ri9C1INCy0YvRgNCw0LbQtdC90LjRjyDQsiBs?=
 =?UTF-8?B?b2NhdGlvbg==?=
In-Reply-To: <CAKaHDOEOGRYV31BggQa8aT+g-JmJfApET93NmJ4X5GKhs88x1A@mail.gmail.com>
References: <4b7d49e60a5298381a82e25c2cbe95a6.NginxMailingListRussian@forum.nginx.org>
 <CAKaHDOEOGRYV31BggQa8aT+g-JmJfApET93NmJ4X5GKhs88x1A@mail.gmail.com>
Message-ID: <CA+ksgAB7G-t63i1L48QDVaWU9BGmthWK0QYaNRutYE9LS3bd-g@mail.gmail.com>

я бы предложил вот такой вариант

 location / {
                        if ($query_string ~
al=5f4ff3cb6478424481d6dfdf9d9a3696
<http://site.ru/Mydll.dll?al=5f4ff3cb6478424481d6dfdf9d9a3696>) {
                                return 418;
                        }
                        error_page 418 = @nameloc;
                        deny all;
                }

                location @nameloc{
                        internal;
                        proxy_pass http://other_serv;
                }

Соответственно все что не al=5f4ff3cb6478424481d6dfdf9d9a3696
<http://site.ru/Mydll.dll?al=5f4ff3cb6478424481d6dfdf9d9a3696> будет
выдавать ошибку 403, то что al=5f4ff3cb6478424481d6dfdf9d9a3696
<http://site.ru/Mydll.dll?al=5f4ff3cb6478424481d6dfdf9d9a3696> будет
проксироваться на другой сервер


1 апреля 2015 г., 20:28 пользователь Daniel Podolsky <onokonem at gmail.com>
написал:

> Для начала - query string не проверяется при поиске location
>
> Надо делать именованный, проверять аргумент в if и переходить в
> именованный. В этом виде if - не evil
>
>
> On Wednesday, April 1, 2015, s.ivanov <nginx-forum at nginx.us> wrote:
>
>> Необходимо сделать проксирование запросов вида
>> http://site.ru/Mydll.dll?al=5f4ff3cb6478424481d6dfdf9d9a3696 на другой
>> веб-сервер.При этом проксировать нужно только запросы указанного вида,
>> любые
>> другие в том числе и http://site.ru/Mydll.dll должны быть запрещены.
>>
>> 1.так
>> location ~* ^/Mydll.dll(.*) {
>> proxy_pass http://192.168.0.2:3000/$1$is_args$args;
>> }
>> срабатывает на любые запросы.
>>
>> 2. так
>> location ~* ^/Mydll.dll$ {
>> deny all;
>> }
>>
>> location ~* ^/Mydll.dll(.*) {
>> proxy_pass http://192.168.0.2:3000/$1$is_args$args;
>> }
>> Запрещено всё вообще, не редиректит разрешённые запросы.
>>
>> 3. так
>> location = /Mydll.dll\?al=(.*) {
>> proxy_pass http://192.168.0.2:3000/$1$is_args$args;
>> }
>> тоже не работает - правило не срабатывает.
>>
>> Вопрос: как составить регулярное выражение, чтобы правило в location
>> срабатывало только на URL разрешённого вида?
>> Спасибо.
>>
>> Posted at Nginx Forum:
>> http://forum.nginx.org/read.php?21,257789,257789#msg-257789
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150402/ec01afbc/attachment-0001.html>

From vbart at nginx.com  Thu Apr  2 07:13:09 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 02 Apr 2015 10:13:09 +0300
Subject: Cache revalidation using If-None-Match
In-Reply-To: <beecfe776b7c87dd4f64484734e2c099.NginxMailingListRussian@forum.nginx.org>
References: <20140715225203.GG1849@mdounin.ru>
 <beecfe776b7c87dd4f64484734e2c099.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3944314.D1AExzBguZ@vbart-laptop>

On Wednesday 01 April 2015 12:04:09 S.A.N wrote:
[..]
> Nginx планирует в новых версиях реализовать HTTP 2
> будет очень хорошо если Nginx реализует модуль - HTTP Cache-Control
> Extensions for Stale Content, для управления своим кешем.
> 

HTTP2 к этому вообще никакого отношения не имеет.

--
Валентин Бартенев

From vbart at nginx.com  Thu Apr  2 07:18:35 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 02 Apr 2015 10:18:35 +0300
Subject: =?UTF-8?B?UmU6INC60LDQuiDQv9GA0LDQstC40LvRjNC90L4g0YPQutCw0LfRi9Cy0LDRgtGM?=
 =?UTF-8?B?INC/0LDRgNCw0LzQtdGC0YAgZ3ppcF90eXBlcyDQtNC70Y8gImFwcGxpY2F0?=
 =?UTF-8?B?aW9uL2F0b20reG1sO3R5cGU9ZmVlZDtjaGFyc2V0PXV0Zi04IiA/?=
In-Reply-To: <CAFHpkQGTUwqjU5vRPhTQeYQFJEp0oJcW9tKQtw_7sqdfJmyu2g@mail.gmail.com>
References: <CAFHpkQGTUwqjU5vRPhTQeYQFJEp0oJcW9tKQtw_7sqdfJmyu2g@mail.gmail.com>
Message-ID: <3501886.cSTlicq07x@vbart-laptop>

On Tuesday 24 March 2015 22:59:05 Илья Шипицин wrote:
> Добрый день!
> 
> есть контент типа application/atom+xml;type=feed;charset=utf-8
> как его сжать ?
> 

   gzip_types application/atom+xml;

--
Валентин Бартенев

From nginx-forum at nginx.us  Tue Apr  7 08:58:03 2015
From: nginx-forum at nginx.us (s.ivanov)
Date: Tue, 07 Apr 2015 04:58:03 -0400
Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0L3Ri9C1INCy0YvRgNCw0LbQtdC90LjRjyDQsiBs?=
 =?UTF-8?B?b2NhdGlvbg==?=
In-Reply-To: <CA+ksgAB7G-t63i1L48QDVaWU9BGmthWK0QYaNRutYE9LS3bd-g@mail.gmail.com>
References: <CA+ksgAB7G-t63i1L48QDVaWU9BGmthWK0QYaNRutYE9LS3bd-g@mail.gmail.com>
Message-ID: <7d09dc1c385c15133dc8752dc1b1921e.NginxMailingListRussian@forum.nginx.org>

Проксировать нужно не только al=5f4ff3cb6478424481d6dfdf9d9a3696, но и все
запросы вида al=5f4ff3cb6478424481d6dfdf9d9a3696 (значение может быть любое
из соответствующего количества букв и цифр, это переменная).

Попытка заменить в предложенном варианте 

al=5f4ff3cb6478424481d6dfdf9d9a3696

на

al=([\w\d]{32})

или

al=([a-z0-9]{32})

или даже

al=([a-z0-9]+) 

приводят к ошибке: nginx: [emerg] invalid condition "al=([\w\d]"
и nginx: [emerg] invalid condition "$query_string" соответственно.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,17244,257853#msg-257853


From simplebox66 at gmail.com  Tue Apr  7 09:00:32 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Tue, 7 Apr 2015 12:00:32 +0300
Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0L3Ri9C1INCy0YvRgNCw0LbQtdC90LjRjyDQsiBs?=
 =?UTF-8?B?b2NhdGlvbg==?=
In-Reply-To: <7d09dc1c385c15133dc8752dc1b1921e.NginxMailingListRussian@forum.nginx.org>
References: <CA+ksgAB7G-t63i1L48QDVaWU9BGmthWK0QYaNRutYE9LS3bd-g@mail.gmail.com>
 <7d09dc1c385c15133dc8752dc1b1921e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CA+ksgABBfa8Ochuz6RUDWXRd12fy2rKrL9oHmfmNmRq=Okmzew@mail.gmail.com>

Попробуйте заменить ($query_string ~ al=5f4ff3cb6478424481d6dfdf9d9a3696
<http://site.ru/Mydll.dll?al=5f4ff3cb6478424481d6dfdf9d9a3696>) на
($query_string ~ al= )

7 апреля 2015 г., 11:58 пользователь s.ivanov <nginx-forum at nginx.us>
написал:

> Проксировать нужно не только al=5f4ff3cb6478424481d6dfdf9d9a3696, но и все
> запросы вида al=5f4ff3cb6478424481d6dfdf9d9a3696 (значение может быть любое
> из соответствующего количества букв и цифр, это переменная).
>
> Попытка заменить в предложенном варианте
>
> al=5f4ff3cb6478424481d6dfdf9d9a3696
>
> на
>
> al=([\w\d]{32})
>
> или
>
> al=([a-z0-9]{32})
>
> или даже
>
> al=([a-z0-9]+)
>
> приводят к ошибке: nginx: [emerg] invalid condition "al=([\w\d]"
> и nginx: [emerg] invalid condition "$query_string" соответственно.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,17244,257853#msg-257853
>
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150407/c8528aac/attachment.html>

From mdounin at mdounin.ru  Tue Apr  7 16:20:40 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 7 Apr 2015 19:20:40 +0300
Subject: nginx-1.6.3
Message-ID: <20150407162040.GA88631@mdounin.ru>

Изменения в nginx 1.6.3                                           07.04.2015

    *) Добавление: теперь директива tcp_nodelay работает для
       SPDY-соединений.

    *) Исправление: в обработке ошибок.
       Спасибо Yichun Zhang и Даниилу Бондареву.

    *) Исправление: при использовании директивы post_action в лог писались
       сообщения "header already sent"; ошибка появилась в nginx 1.5.4.

    *) Исправление: в лог могли писаться сообщения "sem_post() failed".

    *) Исправление: в обработке хэш-таблиц.
       Спасибо Chris West.

    *) Исправление: в обработке целочисленных переполнений.
       Спасибо R?gis Leroy.


-- 
Maxim Dounin
http://nginx.org/


From mdounin at mdounin.ru  Tue Apr  7 16:23:40 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 7 Apr 2015 19:23:40 +0300
Subject: nginx-1.7.12
Message-ID: <20150407162339.GE88631@mdounin.ru>

Изменения в nginx 1.7.12                                          07.04.2015

    *) Добавление: теперь директива tcp_nodelay работает для SSL-соединений
       с бэкендами.

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

    *) Исправление: в директиве proxy_request_buffering.

    *) Исправление: при использовании потоков на Linux в рабочем процессе
       мог произойти segmentation fault.

    *) Исправление: в обработке ошибок при использовании директивы
       ssl_stapling.
       Спасибо Filipe da Silva.

    *) Исправление: в модуле ngx_http_spdy_module.


-- 
Maxim Dounin
http://nginx.org/


From gmm at csdoc.com  Wed Apr  8 21:22:56 2015
From: gmm at csdoc.com (Gena Makhomed)
Date: Thu, 09 Apr 2015 00:22:56 +0300
Subject: MD5 vs SHA-1
Message-ID: <55259C30.9070508@csdoc.com>

Здравствуйте!

Судя по исходникам, nginx использует везде MD5
- и для кеша и для ngx_http_secure_link_module

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

The security of the MD5 hash function is severely compromised.
A collision attack exists that can find collisions within seconds
on a computer with a 2.6 GHz Pentium 4 processor (complexity of 224.1)

Автор утилиты http://zbackup.org/ использует первые 128 бит
от SHA-1 вместо MD5 и говорит, что получается win-win ситуация.

Возможно и в случае с nginx все будет точно так же, если
полностью отказаться от использования MD5 и перейти на SHA-1 ?

Из MD5 "find collisions within seconds" очень легко будет сделать
"nginx cache poisoning", - если я правильно понял исходники nginx.

-- 
Best regards,
  Gena


From nginx-forum at nginx.us  Thu Apr  9 03:45:13 2015
From: nginx-forum at nginx.us (softshape)
Date: Wed, 08 Apr 2015 23:45:13 -0400
Subject: nginx-1.7.12
In-Reply-To: <20150407162339.GE88631@mdounin.ru>
References: <20150407162339.GE88631@mdounin.ru>
Message-ID: <bce5f5e1d5c812496c8b74a8d46036aa.NginxMailingListRussian@forum.nginx.org>

Что-то сломалось с X-Accel-Redirect. Попытка запустить версию 1.7.12
приводит к 500 ошибке на тех файлах, которые у нас отдавались через X-Accel.
Откат на 1.7.6 решает эту проблему.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257892,257914#msg-257914


From mdounin at mdounin.ru  Thu Apr  9 10:34:13 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 9 Apr 2015 13:34:13 +0300
Subject: nginx-1.7.12
In-Reply-To: <bce5f5e1d5c812496c8b74a8d46036aa.NginxMailingListRussian@forum.nginx.org>
References: <20150407162339.GE88631@mdounin.ru>
 <bce5f5e1d5c812496c8b74a8d46036aa.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150409103413.GO88631@mdounin.ru>

Hello!

On Wed, Apr 08, 2015 at 11:45:13PM -0400, softshape wrote:

> Что-то сломалось с X-Accel-Redirect. Попытка запустить версию 1.7.12
> приводит к 500 ошибке на тех файлах, которые у нас отдавались через X-Accel.
> Откат на 1.7.6 решает эту проблему.

В 1.7.8 было вот такое добавление:

    *) Добавление: теперь с помощью X-Accel-Redirect можно перейти в
       именованный location.
       Спасибо Toshikuni Fukaya.

Оно влияет на обработку X-Accel-Redirect с символом @ в первой 
позиции.  Ранее такие перенаправления были некорректны, но могли 
как-то работать из-за отсутствия проверок.

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

-- 
Maxim Dounin
http://nginx.org/


From annulen at yandex.ru  Thu Apr  9 15:40:17 2015
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Thu, 09 Apr 2015 18:40:17 +0300
Subject: MD5 vs SHA-1
In-Reply-To: <55259C30.9070508@csdoc.com>
References: <55259C30.9070508@csdoc.com>
Message-ID: <36901428594017@web23g.yandex.ru>



09.04.2015, 00:22, "Gena Makhomed" <gmm at csdoc.com>:
> Здравствуйте!
>
> Судя по исходникам, nginx использует везде MD5
> - и для кеша и для ngx_http_secure_link_module

Что касается ngx_http_secure_link_module, то в нем вообще по-хорошему надо использовать HMAC-MD5 (или HMAC-SHA1), а не "сырую" хэш-функцию.
 
>
> По сравнению с SHA-1 у MD5 есть несколько недостатков:
> 1. MD5 на современных машинах вычисляется медленне за SHA-1
> 2. MD5 на сегодня уже не является безопасной хэш-функцией:
>
> The security of the MD5 hash function is severely compromised.
> A collision attack exists that can find collisions within seconds
> on a computer with a 2.6 GHz Pentium 4 processor (complexity of 224.1)
>
> Автор утилиты http://zbackup.org/ использует первые 128 бит
> от SHA-1 вместо MD5 и говорит, что получается win-win ситуация.
>
> Возможно и в случае с nginx все будет точно так же, если
> полностью отказаться от использования MD5 и перейти на SHA-1 ?
>
> Из MD5 "find collisions within seconds" очень легко будет сделать
> "nginx cache poisoning", - если я правильно понял исходники nginx.
>
> --
> Best regards,
>   Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Regards,
Konstantin


From simplebox66 at gmail.com  Fri Apr 10 08:03:00 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Fri, 10 Apr 2015 11:03:00 +0300
Subject: =?UTF-8?B?0JrQtdGI0LjRgNC+0LLQsNC90LjQtSDQt9Cw0L/RgNC+0YHQvtCyINCx0LXQtyA=?=
 =?UTF-8?B?0LrRg9C60L7Qsg==?=
Message-ID: <CA+ksgAB86CVhy5ua+JHRmHsDDjZHFZYU6xoHte4A8X9YNKmbaQ@mail.gmail.com>

Добрый день!

Обратил внимание что если делать запрос с отсутствующим заголовком Cookie
то nginx не кеширует такой запрос.

Например если с помощью утилиты curl сделать запрос, то он не закешируется,
а если в curl прописать заголовок Cookie к запросу то кеш срабатывает.

Как решить эту проблему? Как сделать чтобы nginx кешировал не взирая на
наличие заголовка Cookie в запросе.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150410/41e9ef21/attachment.html>

From simplebox66 at gmail.com  Fri Apr 10 08:48:04 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Fri, 10 Apr 2015 11:48:04 +0300
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0LfQsNC/0YDQvtGB0L7QsiDQsdC1?=
 =?UTF-8?B?0Lcg0LrRg9C60L7Qsg==?=
In-Reply-To: <CA+ksgAB86CVhy5ua+JHRmHsDDjZHFZYU6xoHte4A8X9YNKmbaQ@mail.gmail.com>
References: <CA+ksgAB86CVhy5ua+JHRmHsDDjZHFZYU6xoHte4A8X9YNKmbaQ@mail.gmail.com>
Message-ID: <CA+ksgABoPe1MYp6B_Ou-ZDVb22EBJkgxActyWeVH7wTCSJDHXQ@mail.gmail.com>

Точнее даже переформирую немного вопрос. Как сделать чтобы nginx кешировал
как запросы пользователей с Cookie в хедерсах, так и запросы пользователей
без Cookie, то есть необходимо чтобы nginx кешировал запросы ЛЮБОГО типа
пользователей.

10 апреля 2015 г., 11:03 пользователь Иван Мишин <simplebox66 at gmail.com>
написал:

> Добрый день!
>
> Обратил внимание что если делать запрос с отсутствующим заголовком Cookie
> то nginx не кеширует такой запрос.
>
> Например если с помощью утилиты curl сделать запрос, то он не
> закешируется, а если в curl прописать заголовок Cookie к запросу то кеш
> срабатывает.
>
> Как решить эту проблему? Как сделать чтобы nginx кешировал не взирая на
> наличие заголовка Cookie в запросе.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150410/bec23bce/attachment.html>

From mdounin at mdounin.ru  Fri Apr 10 14:12:41 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 10 Apr 2015 17:12:41 +0300
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0LfQsNC/0YDQvtGB0L7QsiDQsdC1?=
 =?UTF-8?B?0Lcg0LrRg9C60L7Qsg==?=
In-Reply-To: <CA+ksgAB86CVhy5ua+JHRmHsDDjZHFZYU6xoHte4A8X9YNKmbaQ@mail.gmail.com>
References: <CA+ksgAB86CVhy5ua+JHRmHsDDjZHFZYU6xoHte4A8X9YNKmbaQ@mail.gmail.com>
Message-ID: <20150410141241.GT88631@mdounin.ru>

Hello!

On Fri, Apr 10, 2015 at 11:03:00AM +0300, Иван Мишин wrote:

> Добрый день!
> 
> Обратил внимание что если делать запрос с отсутствующим заголовком Cookie
> то nginx не кеширует такой запрос.
> 
> Например если с помощью утилиты curl сделать запрос, то он не закешируется,
> а если в curl прописать заголовок Cookie к запросу то кеш срабатывает.
> 
> Как решить эту проблему? Как сделать чтобы nginx кешировал не взирая на
> наличие заголовка Cookie в запросе.

По умолчанию nginx кеширует запросы вне зависимости от наличия или 
отсутствия заголовка Cookie в запросе.  

Скорее всего, в вашем случае проблема в том, что в ответе бекенда 
присутствует заголовок Set-Cookie (и это, в свою очередь, 
случается только для запросов без Cookie).  

Если это требуется, то разрешить кеширование ответов с заголовком 
Set-Cookie можно с помощью директивы proxy_ignore_headers (см. 
http://nginx.org/r/proxy_ignore_headers/ru) или аналога для других 
протоколов.  Но обычно это плохая идея, т.к. в результате одна и 
та же кука будет отдаваться всем пользователям, получившим ответ 
из кеша.  И, соответственно, подобную настройку следует дополнять 
директивой proxy_hide_header Set-Cookie, чтобы заголовок 
Set-Cookie не отдавался клиентам.

-- 
Maxim Dounin
http://nginx.org/


From simplebox66 at gmail.com  Fri Apr 10 14:38:10 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Fri, 10 Apr 2015 17:38:10 +0300
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0LfQsNC/0YDQvtGB0L7QsiDQsdC1?=
 =?UTF-8?B?0Lcg0LrRg9C60L7Qsg==?=
In-Reply-To: <20150410141241.GT88631@mdounin.ru>
References: <CA+ksgAB86CVhy5ua+JHRmHsDDjZHFZYU6xoHte4A8X9YNKmbaQ@mail.gmail.com>
 <20150410141241.GT88631@mdounin.ru>
Message-ID: <CA+ksgABSdw-f8WwtHd8QkaQ_o4ijP3mgfDSWGvq+=mpfD6=Eeg@mail.gmail.com>

Да, Вы правы. У меня бекенд кладет в ответ заголовок Set-Cookie.

То есть все что мне нужно это прописать proxy_hide_header Set-Cookie ?


10 апреля 2015 г., 17:12 пользователь Maxim Dounin <mdounin at mdounin.ru>
написал:

> Hello!
>
> On Fri, Apr 10, 2015 at 11:03:00AM +0300, Иван Мишин wrote:
>
> > Добрый день!
> >
> > Обратил внимание что если делать запрос с отсутствующим заголовком Cookie
> > то nginx не кеширует такой запрос.
> >
> > Например если с помощью утилиты curl сделать запрос, то он не
> закешируется,
> > а если в curl прописать заголовок Cookie к запросу то кеш срабатывает.
> >
> > Как решить эту проблему? Как сделать чтобы nginx кешировал не взирая на
> > наличие заголовка Cookie в запросе.
>
> По умолчанию nginx кеширует запросы вне зависимости от наличия или
> отсутствия заголовка Cookie в запросе.
>
> Скорее всего, в вашем случае проблема в том, что в ответе бекенда
> присутствует заголовок Set-Cookie (и это, в свою очередь,
> случается только для запросов без Cookie).
>
> Если это требуется, то разрешить кеширование ответов с заголовком
> Set-Cookie можно с помощью директивы proxy_ignore_headers (см.
> http://nginx.org/r/proxy_ignore_headers/ru) или аналога для других
> протоколов.  Но обычно это плохая идея, т.к. в результате одна и
> та же кука будет отдаваться всем пользователям, получившим ответ
> из кеша.  И, соответственно, подобную настройку следует дополнять
> директивой proxy_hide_header Set-Cookie, чтобы заголовок
> Set-Cookie не отдавался клиентам.
>
> --
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150410/aeb5c61d/attachment.html>

From simplebox66 at gmail.com  Fri Apr 10 14:56:41 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Fri, 10 Apr 2015 17:56:41 +0300
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0LfQsNC/0YDQvtGB0L7QsiDQsdC1?=
 =?UTF-8?B?0Lcg0LrRg9C60L7Qsg==?=
In-Reply-To: <CA+ksgABSdw-f8WwtHd8QkaQ_o4ijP3mgfDSWGvq+=mpfD6=Eeg@mail.gmail.com>
References: <CA+ksgAB86CVhy5ua+JHRmHsDDjZHFZYU6xoHte4A8X9YNKmbaQ@mail.gmail.com>
 <20150410141241.GT88631@mdounin.ru>
 <CA+ksgABSdw-f8WwtHd8QkaQ_o4ijP3mgfDSWGvq+=mpfD6=Eeg@mail.gmail.com>
Message-ID: <CA+ksgADx1tGkH03cdLM+WL1T0ujNiV4aTiEHuu8ejMbAWoS4eQ@mail.gmail.com>

И да, бекенд ведь не спроста куки шлет, а поставив proxy_hide_header
Set-Cookie, получится что куки клиенту передаваться больше не будут. Что не
совсем верно, мне кажется.

10 апреля 2015 г., 17:38 пользователь Иван Мишин <simplebox66 at gmail.com>
написал:

> Да, Вы правы. У меня бекенд кладет в ответ заголовок Set-Cookie.
>
> То есть все что мне нужно это прописать proxy_hide_header Set-Cookie ?
>
>
> 10 апреля 2015 г., 17:12 пользователь Maxim Dounin <mdounin at mdounin.ru>
> написал:
>
> Hello!
>>
>> On Fri, Apr 10, 2015 at 11:03:00AM +0300, Иван Мишин wrote:
>>
>> > Добрый день!
>> >
>> > Обратил внимание что если делать запрос с отсутствующим заголовком
>> Cookie
>> > то nginx не кеширует такой запрос.
>> >
>> > Например если с помощью утилиты curl сделать запрос, то он не
>> закешируется,
>> > а если в curl прописать заголовок Cookie к запросу то кеш срабатывает.
>> >
>> > Как решить эту проблему? Как сделать чтобы nginx кешировал не взирая на
>> > наличие заголовка Cookie в запросе.
>>
>> По умолчанию nginx кеширует запросы вне зависимости от наличия или
>> отсутствия заголовка Cookie в запросе.
>>
>> Скорее всего, в вашем случае проблема в том, что в ответе бекенда
>> присутствует заголовок Set-Cookie (и это, в свою очередь,
>> случается только для запросов без Cookie).
>>
>> Если это требуется, то разрешить кеширование ответов с заголовком
>> Set-Cookie можно с помощью директивы proxy_ignore_headers (см.
>> http://nginx.org/r/proxy_ignore_headers/ru) или аналога для других
>> протоколов.  Но обычно это плохая идея, т.к. в результате одна и
>> та же кука будет отдаваться всем пользователям, получившим ответ
>> из кеша.  И, соответственно, подобную настройку следует дополнять
>> директивой proxy_hide_header Set-Cookie, чтобы заголовок
>> Set-Cookie не отдавался клиентам.
>>
>> --
>> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150410/069854c6/attachment.html>

From mva at mva.name  Fri Apr 10 16:31:52 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Fri, 10 Apr 2015 22:31:52 +0600
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0LfQsNC/0YDQvtGB0L7QsiDQsdC1?=
 =?UTF-8?B?0Lcg0LrRg9C60L7Qsg==?=
In-Reply-To: <CA+ksgADx1tGkH03cdLM+WL1T0ujNiV4aTiEHuu8ejMbAWoS4eQ@mail.gmail.com>
References: <CA+ksgAB86CVhy5ua+JHRmHsDDjZHFZYU6xoHte4A8X9YNKmbaQ@mail.gmail.com>
 <CA+ksgABSdw-f8WwtHd8QkaQ_o4ijP3mgfDSWGvq+=mpfD6=Eeg@mail.gmail.com>
 <CA+ksgADx1tGkH03cdLM+WL1T0ujNiV4aTiEHuu8ejMbAWoS4eQ@mail.gmail.com>
Message-ID: <3373855.0ZngzD8M3Q@note>

В письме от Пт, 10 апреля 2015 17:56:41 пользователь Иван Мишин написал:
> И да, бекенд ведь не спроста куки шлет, а поставив proxy_hide_header
> Set-Cookie, получится что куки клиенту передаваться больше не будут. Что не
> совсем верно, мне кажется.

1) какой смысл слать всем клиентам идентичную куку? Если она идентичная, 
значит параметр в ней можно прописать в настройках приложения статически.
2) Вы не можете одновременно слать уникальные куки клиентам и отдавать ответ 
из кеша, а не из бекенда.

Так что правильный путь ? либо не кешировать тот локейшн, который выдаёт куку 
(а на уровне приложения, например, вынести установку куки клиенту в 
JavaScript), при этом, кешировать всё остальное, либо же исправить логику 
приложения.
 
-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150410/2bec1275/attachment-0001.bin>

From nginx-forum at nginx.us  Fri Apr 10 16:33:49 2015
From: nginx-forum at nginx.us (softshape)
Date: Fri, 10 Apr 2015 12:33:49 -0400
Subject: nginx-1.7.12
In-Reply-To: <20150409103413.GO88631@mdounin.ru>
References: <20150409103413.GO88631@mdounin.ru>
Message-ID: <5c1a48ebc066d0e5fd1d47f574ad92b0.NginxMailingListRussian@forum.nginx.org>

У нас да, X-Accel использует адрес типа "@upload/...." и в конфиге определен
location -

location ^~ @upload { internal; alias /home/www/upload; }

А как правильно делать теперь? @ на / заменить?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257892,257948#msg-257948


From postmaster at softsearch.ru  Sun Apr 12 08:28:16 2015
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Sun, 12 Apr 2015 11:28:16 +0300
Subject: MD5 vs SHA-1
In-Reply-To: <55259C30.9070508@csdoc.com>
References: <55259C30.9070508@csdoc.com>
Message-ID: <169222578.20150412112816@softsearch.ru>

Здравствуйте, Gena.

> Судя по исходникам, nginx использует везде MD5
> - и для кеша и для ngx_http_secure_link_module

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

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

Т.е.  в  теории атака через коллизии ИМХО возможна, особенно, если урл
может  частично формироваться не самим сайтом, а юзерами из вне (через
имя файла, например).

-- 
С уважением,
 Михаил                          mailto:postmaster at softsearch.ru


From nginx-forum at nginx.us  Sun Apr 12 12:19:02 2015
From: nginx-forum at nginx.us (Andrey Vlasov)
Date: Sun, 12 Apr 2015 08:19:02 -0400
Subject: proxy_cache_revalidate
Message-ID: <1850eca8288af02d51ae9a29b5d9c1aa.NginxMailingListRussian@forum.nginx.org>

Добрый день,
Если я правильно понимаю, то при ревалидации данные в кеше должны быть
обновлены (повторно загружены с бекенда), только если они обновились на
бекенде (if-Modified-Since/If-None-Match отличается от Last-modified), но
судя по логам, данные с бекенда берутся в полном объеме, даже если они не
изменились.

example.com -> proxy -> backend
*прокси тут только для статистики трафика, если его исключить, картина не
измениться 

proxy_cache_path one levels=1:2 keys_zone=one:10m inactive=24h max_size=1G;
server {
	listen       80;
	server_name  backend;
	location / { root /var/www/backend; }
}

server {
	listen       80;
	server_name   example.com;

	location / {
	proxy_set_header Host backend;
	proxy_pass http://unix:/tmp/proxy.sock;
	proxy_cache one;
	proxy_cache_revalidate on;
	proxy_cache_valid 200 1m;  
	}
}

server {
	listen       unix:/tmp/proxy.sock;
	server_name  proxy;

	location / {
	proxy_pass http://$host;
	}
}

backend отвечает файлом index.html размером в 1 мб

лог трафика example.com
request_length:73 bytes_sent:105997 body_bytes_sent:105768 # (MISS)
request_length:73 bytes_sent:591528 body_bytes_sent:591300 # (HIT)
request_length:73 bytes_sent:164076 body_bytes_sent:163840 # (REVALIDATED)

лог трафика proxy
request_length:91 bytes_sent:1048769 body_bytes_sent:1048576 # (MISS)
request_length:175 bytes_sent:4096 body_bytes_sent:3918 # (REVALIDATED)

лог трафика backend
request_length:91 bytes_sent:1048769 body_bytes_sent:1048576 # (MISS)
request_length:175 bytes_sent:1048754 body_bytes_sent:1048576 #
(REVALIDATED)
---------
Из лога видно, что 1 запрос передается на proxy, потом на backend, 2 запрос
отдается с example.com из кеша не затрагивая proxy и как следствие backend
(и не попадает в их логи), а вот 3 запрос ? когда идет ревалидация меня
завел в тупик,  proxy отправляет example.com  4096 байт, но вот backend
отправляет на proxy полностью весь ответ (1048769)

при ревалидации получается вот так
example.com <-4096- proxy <-1048769- backend
хотя должно быть вот так
example.com <-4096- proxy <-4096- backend
----
в чем тут проблема? как не загружать с бекенда полностью весь ответ (1048769
bytes), а только обновить данные что кеш валидный затратив на это всего 4096
bytes

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257971,257971#msg-257971


From nginx-forum at nginx.us  Sun Apr 12 13:33:43 2015
From: nginx-forum at nginx.us (S.A.N)
Date: Sun, 12 Apr 2015 09:33:43 -0400
Subject: proxy_cache_revalidate
In-Reply-To: <1850eca8288af02d51ae9a29b5d9c1aa.NginxMailingListRussian@forum.nginx.org>
References: <1850eca8288af02d51ae9a29b5d9c1aa.NginxMailingListRussian@forum.nginx.org>
Message-ID: <90f3d0c7b48f7a25115cfd1c37057fde.NginxMailingListRussian@forum.nginx.org>

> в чем тут проблема? как не загружать с бекенда полностью весь ответ
> (1048769 bytes), а только обновить данные что кеш валидный затратив на
> это всего 4096 bytes

Если if-Modified-Since/If-None-Match валидные, отдавайте 304 статус, без
тела ответа.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257971,257972#msg-257972


From nginx-forum at nginx.us  Sun Apr 12 18:16:24 2015
From: nginx-forum at nginx.us (alexpts)
Date: Sun, 12 Apr 2015 14:16:24 -0400
Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSBhZGQgaGVhZGVyICsgdHJ5IGZpbGVz?=
Message-ID: <1c2f23a255ba285ac37672e9235fa6c9.NginxMailingListRussian@forum.nginx.org>

Привет!

Имею такой конфиг

location ~ \.html {
    gzip_static on;
    root xxx;
    try_files $uri /index.php$is_args$args;
}

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

Потребовалось, сетить клиенту куку с ip клиента. Изменил конфиг:


location ~ \.html {
    gzip_static on;
    root xxx;

    if ($cookie___lastip != $remote_addr) {
        add_header Set-Cookie
"__lastip=$remote_addr;Domain=$host;Path=/;Max-Age=31536000";
    }

    try_files $uri /index.php$is_args$args;
}


Если документ в кеше, то условие работает верно и если сменился ip или не
было такой куки, то приходит кука в ответе от сервера.
А вот если документа нет в кеше и нет куки с таким именем или значение куки
не равно ip адресу, то запрос возвращает 404. Try_files не находит документ,
но в другой локейшен не заходит.

Не знаю баг это или нет.

Подскажите как можно решить данную задачу.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257975,257975#msg-257975


From nginx-forum at nginx.us  Sun Apr 12 18:17:17 2015
From: nginx-forum at nginx.us (Andrey Vlasov)
Date: Sun, 12 Apr 2015 14:17:17 -0400
Subject: proxy_cache_revalidate
In-Reply-To: <90f3d0c7b48f7a25115cfd1c37057fde.NginxMailingListRussian@forum.nginx.org>
References: <1850eca8288af02d51ae9a29b5d9c1aa.NginxMailingListRussian@forum.nginx.org>
 <90f3d0c7b48f7a25115cfd1c37057fde.NginxMailingListRussian@forum.nginx.org>
Message-ID: <83538ad591cd413ee9bfa1367a02054b.NginxMailingListRussian@forum.nginx.org>

S.A.N Wrote:
-------------------------------------------------------
> > в чем тут проблема? как не загружать с бекенда полностью весь ответ
> > (1048769 bytes), а только обновить данные что кеш валидный затратив
> на
> > это всего 4096 bytes
> 
> Если if-Modified-Since/If-None-Match валидные, отдавайте 304 статус,
> без тела ответа.

так 304 и отдается, НО backend вместе с 304 ответом отдает еще и полностью
сущность (что видно из его лога)

лог proxy (тут все нормально, первый запрос отдал полностью сущность, второй
при ревалидации только заголовок) 
status:200 request_length:91 bytes_sent:1048769 body_bytes_sent:1048576
status:304 request_length:175 bytes_sent:4096 body_bytes_sent:3918

а вот лог backend, видно что при ревалидации отдает не только 304, но и
полную сущность, а не только заголовок 
status:200 request_length:91 bytes_sent:1048769 body_bytes_sent:1048576
status:304 request_length:175 bytes_sent:1048754 body_bytes_sent:1048576

конфиг с которым тестировалось приведен выше

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257971,257976#msg-257976


From gmm at csdoc.com  Sun Apr 12 18:45:41 2015
From: gmm at csdoc.com (Gena Makhomed)
Date: Sun, 12 Apr 2015 21:45:41 +0300
Subject: proxy_cache_revalidate
In-Reply-To: <83538ad591cd413ee9bfa1367a02054b.NginxMailingListRussian@forum.nginx.org>
References: <1850eca8288af02d51ae9a29b5d9c1aa.NginxMailingListRussian@forum.nginx.org>
 <90f3d0c7b48f7a25115cfd1c37057fde.NginxMailingListRussian@forum.nginx.org>
 <83538ad591cd413ee9bfa1367a02054b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <552ABD55.1050808@csdoc.com>

On 12.04.2015 21:17, Andrey Vlasov wrote:

>>> в чем тут проблема? как не загружать с бекенда полностью весь ответ
>>> (1048769 bytes), а только обновить данные что кеш валидный затратив
>> на
>>> это всего 4096 bytes
>>
>> Если if-Modified-Since/If-None-Match валидные, отдавайте 304 статус,
>> без тела ответа.
>
> так 304 и отдается, НО backend вместе с 304 ответом отдает еще и полностью
> сущность (что видно из его лога)

RFC2616: The 304 response MUST NOT contain a message-body, and thus
is always terminated by the first empty line after the header fields

RFC7232: http://tools.ietf.org/html/rfc7232#section-4.1
A 304 response cannot contain a message-body; it is always terminated
by the first empty line after the header fields.

-- 
Best regards,
  Gena


From nginx-forum at nginx.us  Sun Apr 12 18:45:03 2015
From: nginx-forum at nginx.us (S.A.N)
Date: Sun, 12 Apr 2015 14:45:03 -0400
Subject: proxy_cache_revalidate
In-Reply-To: <83538ad591cd413ee9bfa1367a02054b.NginxMailingListRussian@forum.nginx.org>
References: <1850eca8288af02d51ae9a29b5d9c1aa.NginxMailingListRussian@forum.nginx.org>
 <90f3d0c7b48f7a25115cfd1c37057fde.NginxMailingListRussian@forum.nginx.org>
 <83538ad591cd413ee9bfa1367a02054b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <f2b6abb68fe8bd441c633029da9d3164.NginxMailingListRussian@forum.nginx.org>

> а вот лог backend, видно что при ревалидации отдает не только 304, но
> и полную сущность, а не только заголовок 

Бекенд, не должен отдавать тело ответа со статусом 304, вам достаточно
отдать только заголовки и статус 304.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257971,257978#msg-257978


From nginx-forum at nginx.us  Sun Apr 12 18:51:47 2015
From: nginx-forum at nginx.us (alexpts)
Date: Sun, 12 Apr 2015 14:51:47 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgYWRkIGhlYWRlciArIHRyeSBmaWxlcw==?=
In-Reply-To: <1c2f23a255ba285ac37672e9235fa6c9.NginxMailingListRussian@forum.nginx.org>
References: <1c2f23a255ba285ac37672e9235fa6c9.NginxMailingListRussian@forum.nginx.org>
Message-ID: <0a69352e03fdb5b7aacc98ca49e56202.NginxMailingListRussian@forum.nginx.org>

Убрал условие. Заголовок стал передаваться на каждый запрос с кукой. Стало
работать...

location ~ \.html {
gzip_static on;
root xxx;

add_header Set-Cookie
"__lastip=$remote_addr;Domain=$host;Path=/;Max-Age=31536000";

try_files $uri /index.php$is_args$args;
}

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257975,257980#msg-257980


From nginx-forum at nginx.us  Sun Apr 12 19:10:26 2015
From: nginx-forum at nginx.us (Andrey Vlasov)
Date: Sun, 12 Apr 2015 15:10:26 -0400
Subject: proxy_cache_revalidate
In-Reply-To: <1850eca8288af02d51ae9a29b5d9c1aa.NginxMailingListRussian@forum.nginx.org>
References: <1850eca8288af02d51ae9a29b5d9c1aa.NginxMailingListRussian@forum.nginx.org>
Message-ID: <e5d76a4984399a84579f5864aa6f869e.NginxMailingListRussian@forum.nginx.org>

Всем спасибо за внимание, это было ложное срабатывание (не все
3rdPartyModules одинаково полезны), 
проблема оказалась связана с модулем VTS
https://github.com/vozlt/nginx-module-vts

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257971,257981#msg-257981


From bogdar at gmail.com  Mon Apr 13 10:31:49 2015
From: bogdar at gmail.com (Bogdan)
Date: Mon, 13 Apr 2015 13:31:49 +0300
Subject: =?UTF-8?B?UmU6INC+0LHRidC40Lkg0LrRjdGIINC00LvRjyDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0YUgbmdpbng=?=
In-Reply-To: <CAFHpkQHB58-1D-J0OZ=ta7ZkV7tUZtMK5oGQSQ=6ukx7cWQv7g@mail.gmail.com>
References: <CAHRZc-2aA3UmYju3iNk1ZbJYavHrU3kkrQQ5A+0b+zuEUz=s=Q@mail.gmail.com>
 <CAFHpkQFQugMvxTCmHHVrae8uygxc9Edxtq6jgx3wQ=EO0MVz-w@mail.gmail.com>
 <CAHRZc-0MWn-gzLiszs0-_DqT3mGiUH2fPEKwnL2kw_nb2UKLOA@mail.gmail.com>
 <CAFHpkQFdJnCVnEshyqCrO=9w_jyBEcY0GJw3ajZBzf1q=04K9w@mail.gmail.com>
 <CAHRZc-3+W3LFvYsrC9--vzoZDCH36dSxpUmoU+UnD9ndpZncjw@mail.gmail.com>
 <CAFHpkQHB58-1D-J0OZ=ta7ZkV7tUZtMK5oGQSQ=6ukx7cWQv7g@mail.gmail.com>
Message-ID: <CACz2Q8FZmrysMOFhzOERmTgjt6v-HAAkgoTM8i3_2mCcU_K7oA@mail.gmail.com>

Привет.

1. Общий кэш на файловой системе - единая точка отказа. В лучшем случае
потеряете сам кэш - в худшем - все балансировщики.
2. Эффективность существующего кэша надо оценивать, если там 90% - я не
силён в математике, но буст будет не так велик ИМХО.
3. Если хочется новых острых впечатлений в продакшене - можно кэшировать в
общем мемкэше. Но есть шанс потерять кэш вообще, либо получить холодный кэш.
4. Можно отдавать ответы не с бэкендов, а через кластер couchbase -
http://labs.couchbase.com/couchbase-nginx-module/, но придётся доработать
приложение так, чтобы оно сам писало кэш в кучбейс и самостоятельно же
чистило его.


2015-03-23 17:58 GMT+03:00 Илья Шипицин <chipitsine at gmail.com>:

> расчеты можно сделать исходя, например, из access-логов.
> залогируйте $upstream_response_time, посмотрите, какие запросы могли
> бы обработаться из кеша, если бы он был общий, просуммируйте.
>
> можно взять граничное условие, что, если запрос берется из кеша, то
> временнЫе затраты на это равны нулю, т.е. в первом приближении
> пренебречь дисковым вводом-выводом. это может быть справедливо, если у
> вас действительно тяжелая генерация ответов.
>
> 23 марта 2015 г., 18:24 пользователь Михаил Пульман <pullmix at gmail.com>
> написал:
> > Расчетов нет, есть предположение. Вы подскажите как реализовать, а
> > последующие тесты покажут результативность такого решения. Чисто из
> > логических соображений прирост должен быть обязательно.
> >
> > С уважением, Михаил
> >
> > 23 марта 2015 г., 16:10 пользователь Илья Шипицин <chipitsine at gmail.com>
> > написал:
> >
> >> а есть расчеты, подтверждающие хороший прирост производительности ?
> >>
> >> 23 марта 2015 г., 17:30 пользователь Михаил Пульман <pullmix at gmail.com>
> >> написал:
> >> > Ситуация в том что есть железный балансировщик, он раскидывает трафик
> по
> >> > 4-6
> >> > штукам nginx, а нжинксы балансируя траффик с помощью апстрима
> >> > перенаправляют
> >> > на бэкенд сервера. На балансировщиках nginx  настроен кэш. Получается
> >> > что на
> >> > всех балансировщиках разный кеш. Допусти клиентский запрос попавший на
> >> > балансир номер 1 кеша там не обнаружилось и запрос пошел на бэкенд, в
> то
> >> > время как на балансировщике номер 2 нужный кеш в этот момент был, но
> по
> >> > понятным причинам не был использоан. Вообщем если сделать общий кеш
> для
> >> > всех
> >> > балансировщиков nginx  можно получить хороший прирост
> >> > производительности.
> >> >
> >> > С уважением, Михаил
> >> >
> >> > 23 марта 2015 г., 12:56 пользователь Илья Шипицин <
> chipitsine at gmail.com>
> >> > написал:
> >> >
> >> >> возможно, вы придете к монстроидной схеме
> >> >>
> >> >> nginx --> squid (с поддержкой ICAP) --> бекенды
> >> >>
> >> >> и даже после танцев с бубном вы ее настроите.
> >> >>
> >> >> но, практика показывает, что в таких случаях надо уметь отвечать на
> >> >> вопрос "зачем это надо ?".
> >> >> после ответа на который часто оказывается, что на самом деле - не
> надо.
> >> >>
> >> >> вы бы рассказали про вашу ситуацию в деталях ?
> >> >>
> >> >> 23 марта 2015 г., 13:54 пользователь Михаил Пульман <
> pullmix at gmail.com>
> >> >> написал:
> >> >> > Добрый день коллеги!
> >> >> >
> >> >> > На фронте имеется n-ое количество nginx которые выступают в
> качестве
> >> >> > балансировщиков.
> >> >> > Нужно наладить единый кэш для всех фронтенд nginxов. Какие есть
> >> >> > возможности
> >> >> > в nginx для реализации этой задачи?
> >> >> >
> >> >> > С уважением, Михаил
> >> >> >
> >> >> > _______________________________________________
> >> >> > nginx-ru mailing list
> >> >> > nginx-ru at nginx.org
> >> >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >> >> _______________________________________________
> >> >> nginx-ru mailing list
> >> >> nginx-ru at nginx.org
> >> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > nginx-ru mailing list
> >> > nginx-ru at nginx.org
> >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >> _______________________________________________
> >> nginx-ru mailing list
> >> nginx-ru at nginx.org
> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> >
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
WBR,  Bogdan B. Rudas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150413/b501c2fc/attachment-0001.html>

From mdounin at mdounin.ru  Mon Apr 13 12:02:23 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 13 Apr 2015 15:02:23 +0300
Subject: nginx-1.7.12
In-Reply-To: <5c1a48ebc066d0e5fd1d47f574ad92b0.NginxMailingListRussian@forum.nginx.org>
References: <20150409103413.GO88631@mdounin.ru>
 <5c1a48ebc066d0e5fd1d47f574ad92b0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150413120223.GB88631@mdounin.ru>

Hello!

On Fri, Apr 10, 2015 at 12:33:49PM -0400, softshape wrote:

> У нас да, X-Accel использует адрес типа "@upload/...." и в конфиге определен
> location -
> 
> location ^~ @upload { internal; alias /home/www/upload; }
> 
> А как правильно делать теперь? @ на / заменить?

Да, использовать обычные URI.  И заодно можно приседания с "alias" 
выкинуть, обычного "root /home/www;" хватит.

-- 
Maxim Dounin
http://nginx.org/


From mdounin at mdounin.ru  Mon Apr 13 12:50:52 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 13 Apr 2015 15:50:52 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgYWRkIGhlYWRlciArIHRyeSBmaWxlcw==?=
In-Reply-To: <1c2f23a255ba285ac37672e9235fa6c9.NginxMailingListRussian@forum.nginx.org>
References: <1c2f23a255ba285ac37672e9235fa6c9.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150413125052.GE88631@mdounin.ru>

Hello!

On Sun, Apr 12, 2015 at 02:16:24PM -0400, alexpts wrote:

> Привет!
> 
> Имею такой конфиг
> 
> location ~ \.html {
>     gzip_static on;
>     root xxx;
>     try_files $uri /index.php$is_args$args;
> }
> 
> Локейшен проверяет есть ли в ФС статический документ и отдает его клиенту из
> кеша, Если документа нет, то отдает управление переходит в локейшен, который
> обрабатывает php  скрипты для генерации документа.
> 
> Потребовалось, сетить клиенту куку с ip клиента. Изменил конфиг:
> 
> 
> location ~ \.html {
>     gzip_static on;
>     root xxx;
> 
>     if ($cookie___lastip != $remote_addr) {
>         add_header Set-Cookie
> "__lastip=$remote_addr;Domain=$host;Path=/;Max-Age=31536000";
>     }
> 
>     try_files $uri /index.php$is_args$args;
> }
> 
> 
> Если документ в кеше, то условие работает верно и если сменился ip или не
> было такой куки, то приходит кука в ответе от сервера.
> А вот если документа нет в кеше и нет куки с таким именем или значение куки
> не равно ip адресу, то запрос возвращает 404. Try_files не находит документ,
> но в другой локейшен не заходит.
> 
> Не знаю баг это или нет.
> 
> Подскажите как можно решить данную задачу.

На всякий случай оставлю эту ссылку здесь:

http://wiki.nginx.org/IfIsEvil

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Mon Apr 13 16:58:12 2015
From: nginx-forum at nginx.us (itcod)
Date: Mon, 13 Apr 2015 12:58:12 -0400
Subject: webdav+ext base.auth+var=error
In-Reply-To: <fb0f8b496f98fe37d9646ae79ba6b02c.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQGTCigObF5xNpcr2ohuCTrYziU_=dhKgORNjxrK+UEaPg@mail.gmail.com>
 <fb0f8b496f98fe37d9646ae79ba6b02c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <079c3ea83343b3101f9cebef88220441.NginxMailingListRussian@forum.nginx.org>

Вот результат. Пользуйтесь на здоровье. 
Ногами не пинать. эт моя первая программка на lui
https://ihome.itcod.com/max/projects/auth-dav/

Замечания предложения итд пишите мылом ссылку на обсуждение:)

# auth-dav
Nginx Base Authenticate url/.htpasswd for WebDAV and HTTP secure
directory(links). Support CRYPT(3) MD5 SHA-1 secure hash. Test computation
in Lua (5.1)

-- Copyright (c) 2015 by Yura Vdovytchenko (max at itcod.com)
"https://ihome.itcod.com/max/projects/auth-dav/",

Nginx Base Authenticate url/.htpasswd for WebDAV and HTTP secure
directory(links)
Support CRYPT(3) MD5 SHA-1 secure hash.
Test computation in Lua (5.1)
Author by Yura Vdovytchenko 
License MIT

ОПИСАНИЕ

Модуль аутентификации для nginx. Nginx с поддержкой lua 5.1. 
Основная задача модуля обеспечить независимую парольную защиту для каждой
папки на сайте (WEBDAV-хранилище/облака).
Реализовано методом автоматической Base-авторизации при обнаружении в
папке/url файла авторизации (например: .htpasswd).
Поддерживает три базовых метода кодирования CRYPT(3) MD5 SHA1

ЗАМЕЧАНИЯ

На текущий момент WEBDAV-клиенты (BitKenix/FAR-NetDrive) обеспечивают только
авторизацию при первичном входе, и не умеют выдавать запрос авторизации при
переходе в подпапку с иным авторизуемым пользователем. Браузеры умеют.

REQUIRE

require "base64" -- base64.lua https://github.com/toastdriven/lua-base64
local utf8 = require "utf8" -- utf8.lua Kyle Smith
https://gist.github.com/markandgo/5776124
local csv = require("csv") -- lua-csv
https://github.com/geoffleyland/lua-csv
local resty_sha1 = require "resty.sha1" --
https://github.com/openresty/lua-resty-core
local apr = require "apr.core" -- lua-apr
-- Loading the library. crypt -- https://github.com/PlugwiseBV/luacrypt
descrypt = assert(package.loadlib("/usr/local/lib/lua/5.1/crypt.so",
"luaopen_crypt"))

STARTUP

--path lua file: /etc/nginx/lua/auth-dav.lua
--Example Nginx virtual example.conf

server {
    ...
    set $dir /opt/home;
    set $dir_path $dir;
    set $home $dir_path;
    set $sadm_passwd .htpsw;
    set $user_passwd .uhtpasswd;

    location / {
	dav_methods PUT DELETE MKCOL COPY MOVE;
	dav_ext_methods PROPFIND OPTIONS;
	create_full_put_path on;
	dav_access user:rw group:rw;
	client_body_temp_path /opt/itcod-dav.tmp/;
	access_by_lua_file /etc/nginx/lua/auth-dav.lua;
	client_max_body_size 0;
	autoindex on;
        root /opt/home/;

        limit_except GET {
    	    allow all;
    	    #deny all;
        }
    }
    location ~/\.ht {
	deny all;
    }
}

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257511,258000#msg-258000


From nginx-forum at nginx.us  Mon Apr 13 17:04:53 2015
From: nginx-forum at nginx.us (itcod)
Date: Mon, 13 Apr 2015 13:04:53 -0400
Subject: webdav+ext base.auth+var=error
In-Reply-To: <24e3d299dc16400075a6e80d79ff1099.NginxMailingListRussian@forum.nginx.org>
References: <d82813dec5b7d5f36cf1b20306f60b47.NginxMailingListRussian@forum.nginx.org>
 <24e3d299dc16400075a6e80d79ff1099.NginxMailingListRussian@forum.nginx.org>
Message-ID: <222c6bd8b74e93077fc24a1b826031f4.NginxMailingListRussian@forum.nginx.org>

РЕШЕНО
http://forum.nginx.org/read.php?21,257511,258000#msg-258000

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257495,258001#msg-258001


From nginx-forum at nginx.us  Mon Apr 13 17:18:08 2015
From: nginx-forum at nginx.us (itcod)
Date: Mon, 13 Apr 2015 13:18:08 -0400
Subject: webdav+ext base.auth+var=error
In-Reply-To: <079c3ea83343b3101f9cebef88220441.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQGTCigObF5xNpcr2ohuCTrYziU_=dhKgORNjxrK+UEaPg@mail.gmail.com>
 <fb0f8b496f98fe37d9646ae79ba6b02c.NginxMailingListRussian@forum.nginx.org>
 <079c3ea83343b3101f9cebef88220441.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3771e4eb49be64576bf34e7365d8887e.NginxMailingListRussian@forum.nginx.org>

Планы на будущее.
1. Добавить блокирование доступа пользователей WEBDAV к файлам паролей в
папках
2. Обеспечить доступ к файлам паролей админам папок
3. Внедрить расширеное управление доступными коммандами WEBDAV 
dav_methods PUT DELETE MKCOL COPY MOVE;
dav_ext_methods PROPFIND OPTIONS;
посредством расширения формата .htpasswd
test:password
до формата
test:password:accessKeys

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257511,258003#msg-258003


From nginx-forum at nginx.us  Mon Apr 13 17:32:44 2015
From: nginx-forum at nginx.us (itcod)
Date: Mon, 13 Apr 2015 13:32:44 -0400
Subject: webdav+ext base.auth+var=error
In-Reply-To: <20150321144512.GR88631@mdounin.ru>
References: <20150321144512.GR88631@mdounin.ru>
Message-ID: <1e60282205dbf315b53fbd487c4ad696.NginxMailingListRussian@forum.nginx.org>

Максим добрый день. Вы были абсолютно правы. В процессе написания
аутентификатора на lua выяснил, что если переменные (например
$file_password) создается в location / то при работе из WEBDAV клиентов они
не обрабатываются и остаются пустыми. Видимо это жучёк в nginx.
Вот так не работает:
server {
...

location / {
set $file_password $dir/$1;
...
}}

А если их глобально вынести выше описания location в секцию server то они
заполняются (не пусты).
Вот так работает:
server {
...
set $file_password $dir/$1;

location / {
...
}}

И кстати при работе с WEBDAV, аутентификация через дополнительный реквест
/auth у меня ни разу не сработала... много проверил вариаций.... гдето в
инете вычитал, что это ошибка в nginx и патч видел для nginx.... но мне
такой вариант не понравился.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257519,258004#msg-258004


From mdounin at mdounin.ru  Mon Apr 13 20:18:53 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 13 Apr 2015 23:18:53 +0300
Subject: webdav+ext base.auth+var=error
In-Reply-To: <1e60282205dbf315b53fbd487c4ad696.NginxMailingListRussian@forum.nginx.org>
References: <20150321144512.GR88631@mdounin.ru>
 <1e60282205dbf315b53fbd487c4ad696.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150413201853.GG88631@mdounin.ru>

Hello!

On Mon, Apr 13, 2015 at 01:32:44PM -0400, itcod wrote:

> Максим добрый день. Вы были абсолютно правы. В процессе написания
> аутентификатора на lua выяснил, что если переменные (например
> $file_password) создается в location / то при работе из WEBDAV клиентов они
> не обрабатываются и остаются пустыми. Видимо это жучёк в nginx.
> Вот так не работает:
> server {
> ...
> 
> location / {
> set $file_password $dir/$1;
> ...
> }}
> 
> А если их глобально вынести выше описания location в секцию server то они
> заполняются (не пусты).
> Вот так работает:
> server {
> ...
> set $file_password $dir/$1;
> 
> location / {
> ...
> }}

При этом в "location /" ипользуется limit_except, правильно?

Выглядит как багофича limit_except в сочетании с rewrite'ами, 
директивы rewrite не выполняются для "лимитированных" запросов.  
Наверное, это имеет смысл поправить.

> И кстати при работе с WEBDAV, аутентификация через дополнительный реквест
> /auth у меня ни разу не сработала... много проверил вариаций.... гдето в
> инете вычитал, что это ошибка в nginx и патч видел для nginx.... но мне
> такой вариант не понравился.

Повторюсь: если показать конфигурацию - больше шансов, что помогут 
найти проблему.

Единственная известная мне проблема, проявлявшаяся при 
взаимодействии dav'а и auth_request'а - исправлена больше двух лет 
назад, в nginx 1.3.9.

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Tue Apr 14 09:28:36 2015
From: nginx-forum at nginx.us (itcod)
Date: Tue, 14 Apr 2015 05:28:36 -0400
Subject: =?UTF-8?B?0LTQuNC90LDQvNC40YfQtdGB0LrQuNC5IGRhdiBtZXRob2RzICREQVY7?=
Message-ID: <69692e82fc9b9c8a716c815e37bbd4a1.NginxMailingListRussian@forum.nginx.org>

Добрый день уважаемые
Кто нибудь уже решал эти задачки по динамическому изменению dav_methods для
location

1.
set $DAV  PUT DELETE MKCOL COPY MOVE;
Выскакивает ошибка конфигурции. возникло предположение, 
что нужно экранировать пробел. попробовал так:
set $DAV\  PUT\ DELETE\ MKCOL\ COPY\ MOVE;
сработало.... Правильно ли я сделал?

2.
dav_methods $DAV;
Получаю ошибку:
nginx: [warn] invalid value "$DAV" in .....
Что тут не так?

3.
set $DAVEXT PROPFIND;
dav_ext_methods $DAVEXT;
Получаю ошибку:
nginx: [warn] invalid value "$DAVEXT" in .....
(указывает на строку dav_ext_methods $DAVEXT;)
похоже ошибка анналогична п2....

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258018,258018#msg-258018


From nginx-forum at nginx.us  Tue Apr 14 09:55:05 2015
From: nginx-forum at nginx.us (itcod)
Date: Tue, 14 Apr 2015 05:55:05 -0400
Subject: webdav+ext base.auth+var=error
In-Reply-To: <20150413201853.GG88631@mdounin.ru>
References: <20150413201853.GG88631@mdounin.ru>
Message-ID: <f8485fe87600a957f19c204971dd9ec1.NginxMailingListRussian@forum.nginx.org>

Максим добрый день.
Нет в location не было limit_except. версия nginx 1.7.11
В принципе поиск в тех вариациях конфиг ошибок, уже не критичен. 
Разве, что это кому нибудь ещё понадобится.

Постучавшись головой в ошибки... решил задачу написанием авторизатора на
lua
заодно и добавил не только crypt(3), а и md5 и sha1
http://forum.nginx.org/read.php?21,257511,258000#msg-258000

а счас пытаюсь разобраться с динамическим изменением dav_methods и
dav_ext_methods в location
Там тоже как то всё кривовато с передачей переменных.... не принимают
"аднака" :) или я торможу.... или модули.... или nginx.... :))))
http://forum.nginx.org/read.php?21,258018

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257519,258020#msg-258020


From mdounin at mdounin.ru  Tue Apr 14 12:24:38 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 14 Apr 2015 15:24:38 +0300
Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60LjQuSBkYXYgbWV0aG9kcyAkREFWOw==?=
In-Reply-To: <69692e82fc9b9c8a716c815e37bbd4a1.NginxMailingListRussian@forum.nginx.org>
References: <69692e82fc9b9c8a716c815e37bbd4a1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150414122438.GH88631@mdounin.ru>

Hello!

On Tue, Apr 14, 2015 at 05:28:36AM -0400, itcod wrote:

> Добрый день уважаемые
> Кто нибудь уже решал эти задачки по динамическому изменению dav_methods для
> location
> 
> 1.
> set $DAV  PUT DELETE MKCOL COPY MOVE;
> Выскакивает ошибка конфигурции. возникло предположение, 
> что нужно экранировать пробел. попробовал так:
> set $DAV\  PUT\ DELETE\ MKCOL\ COPY\ MOVE;
> сработало.... Правильно ли я сделал?
> 
> 2.
> dav_methods $DAV;
> Получаю ошибку:
> nginx: [warn] invalid value "$DAV" in .....
> Что тут не так?

Директива dav_methods не поддерживает переменные.  Если нужно, 
чтобы в разных частях сайта поддерживались разные методы - следует 
использовать для разделения этих частей директиву location.  Если 
нужно ограничить доступ к отдельным методам - следует использовать 
средства контроля доступа.

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Tue Apr 14 12:25:10 2015
From: nginx-forum at nginx.us (dwow)
Date: Tue, 14 Apr 2015 08:25:10 -0400
Subject: nginx-1.7.12
In-Reply-To: <20150407162339.GE88631@mdounin.ru>
References: <20150407162339.GE88631@mdounin.ru>
Message-ID: <d7800b4a1d415a76cde34ba8ee9cf889.NginxMailingListRussian@forum.nginx.org>

Приветствую,

Maxim Dounin Wrote:
-------------------------------------------------------
>     *) Исправление: в модуле ngx_http_spdy_module.

А можно расширить, что за исправление, что исправило?

Спасибо.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257892,258023#msg-258023


From mdounin at mdounin.ru  Tue Apr 14 12:28:46 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 14 Apr 2015 15:28:46 +0300
Subject: webdav+ext base.auth+var=error
In-Reply-To: <20150413201853.GG88631@mdounin.ru>
References: <20150321144512.GR88631@mdounin.ru>
 <1e60282205dbf315b53fbd487c4ad696.NginxMailingListRussian@forum.nginx.org>
 <20150413201853.GG88631@mdounin.ru>
Message-ID: <20150414122846.GI88631@mdounin.ru>

Hello!

On Mon, Apr 13, 2015 at 11:18:53PM +0300, Maxim Dounin wrote:

[...]

> Выглядит как багофича limit_except в сочетании с rewrite'ами, 
> директивы rewrite не выполняются для "лимитированных" запросов.  
> Наверное, это имеет смысл поправить.

Впрочем, нет, поправить это фактически нельзя, т.к. среди директив 
rewrite могут быть if'ы (и соответственно другие вложенные 
location'ы).  Так что, видимо, следует задокументировать 
где-нибудь в районе http://wiki.nginx.org/IfIsEvil.

-- 
Maxim Dounin
http://nginx.org/


From mdounin at mdounin.ru  Tue Apr 14 12:46:44 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 14 Apr 2015 15:46:44 +0300
Subject: webdav+ext base.auth+var=error
In-Reply-To: <f8485fe87600a957f19c204971dd9ec1.NginxMailingListRussian@forum.nginx.org>
References: <20150413201853.GG88631@mdounin.ru>
 <f8485fe87600a957f19c204971dd9ec1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150414124643.GJ88631@mdounin.ru>

Hello!

On Tue, Apr 14, 2015 at 05:55:05AM -0400, itcod wrote:

> Максим добрый день.
> Нет в location не было limit_except. версия nginx 1.7.11
> В принципе поиск в тех вариациях конфиг ошибок, уже не критичен. 
> Разве, что это кому нибудь ещё понадобится.

Ну вот повторюсь в очередной раз: если у вас есть проблема - 
показывайте конфиг, достаточный для её воспроизведения.  Скорее 
всего всё сведётся к тому, что в конфиге написано нечто, что nginx 
обрабатывает не так, как вы думаете.
 
> Постучавшись головой в ошибки... решил задачу написанием авторизатора на
> lua
> заодно и добавил не только crypt(3), а и md5 и sha1
> http://forum.nginx.org/read.php?21,257511,258000#msg-258000

Just in case, nginx умеет не только crypt (который, в свою 
очередь, бывает разный, читать про "modular crypt format" на 
https://en.wikipedia.org/wiki/Crypt_(C)), но и $apr1$, {PLAIN}, 
{SHA} и {SSHA}.  Подробнее тут:

http://nginx.org/ru/docs/http/ngx_http_auth_basic_module.html

-- 
Maxim Dounin
http://nginx.org/


From mdounin at mdounin.ru  Tue Apr 14 12:50:01 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 14 Apr 2015 15:50:01 +0300
Subject: nginx-1.7.12
In-Reply-To: <d7800b4a1d415a76cde34ba8ee9cf889.NginxMailingListRussian@forum.nginx.org>
References: <20150407162339.GE88631@mdounin.ru>
 <d7800b4a1d415a76cde34ba8ee9cf889.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150414125001.GK88631@mdounin.ru>

Hello!

On Tue, Apr 14, 2015 at 08:25:10AM -0400, dwow wrote:

> Приветствую,
> 
> Maxim Dounin Wrote:
> -------------------------------------------------------
> >     *) Исправление: в модуле ngx_http_spdy_module.
> 
> А можно расширить, что за исправление, что исправило?

http://hg.nginx.org/nginx/rev/c81d79a7befd

-- 
Maxim Dounin
http://nginx.org/


From simplebox66 at gmail.com  Tue Apr 14 13:20:41 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Tue, 14 Apr 2015 16:20:41 +0300
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0LfQsNC/0YDQvtGB0L7QsiDQsdC1?=
 =?UTF-8?B?0Lcg0LrRg9C60L7Qsg==?=
In-Reply-To: <3373855.0ZngzD8M3Q@note>
References: <CA+ksgAB86CVhy5ua+JHRmHsDDjZHFZYU6xoHte4A8X9YNKmbaQ@mail.gmail.com>
 <CA+ksgABSdw-f8WwtHd8QkaQ_o4ijP3mgfDSWGvq+=mpfD6=Eeg@mail.gmail.com>
 <CA+ksgADx1tGkH03cdLM+WL1T0ujNiV4aTiEHuu8ejMbAWoS4eQ@mail.gmail.com>
 <3373855.0ZngzD8M3Q@note>
Message-ID: <CA+ksgACMzLXf9y43PO-1j3fA4XvDbKYdOQFnbBbtwax+kfA84Q@mail.gmail.com>

>
> По умолчанию nginx кеширует запросы вне зависимости от наличия или
> отсутствия заголовка Cookie в запросе.
> Скорее всего, в вашем случае проблема в том, что в ответе бекенда
> присутствует заголовок Set-Cookie (и это, в свою очередь,
> случается только для запросов без Cookie)


Максим, вы говорите что nginx кеширует вне зависимости от Cookie, тогда не
почему мешает  заголовок Set-Cookie, не понимаю ?

1) какой смысл слать всем клиентам идентичную куку? Если она идентичная,
> значит параметр в ней можно прописать в настройках приложения статически.
> 2) Вы не можете одновременно слать уникальные куки клиентам и отдавать
> ответ
> из кеша, а не из бекенда.
> Так что правильный путь ? либо не кешировать тот локейшн, который выдаёт
> куку
> (а на уровне приложения, например, вынести установку куки клиенту в
> JavaScript), при этом, кешировать всё остальное, либо же исправить логику
> приложения.


А откуда вы взяли что шлется идентичная кука всем клиентам??

Дополнительное описание ситуации:
Есть элемент(ы) которые подвержены кешированию и на основе изучения логов
есть следующее:

1)урл не кеше, запрашиваем урл с помощью curl, получаем промах, еще раз
опять промах и т.д.
2)урл не в кеше, запрашиваем урл с помощью любого браузера - первый раз
промах, второй и последующие разы ответ возвращается из кеша
3)урл УЖЕ в кеше, запрашиваем урл с помощью curl   и каждый раз получаем
ответ из кеша.

Не понимаю почему при запросах с браузера поведение нормальное, а при
запросе curl-ом ответ в кеш не кладется. И как на это влияет  Set-Cookie.
если со слов Максима

> По умолчанию nginx кеширует запросы вне зависимости от наличия или
> отсутствия заголовка Cookie в запросе.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150414/800e83de/attachment.html>

From nginx-forum at nginx.us  Tue Apr 14 13:59:53 2015
From: nginx-forum at nginx.us (s.ivanov)
Date: Tue, 14 Apr 2015 09:59:53 -0400
Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0L3Ri9C1INCy0YvRgNCw0LbQtdC90LjRjyDQsiBs?=
 =?UTF-8?B?b2NhdGlvbg==?=
In-Reply-To: <CA+ksgABBfa8Ochuz6RUDWXRd12fy2rKrL9oHmfmNmRq=Okmzew@mail.gmail.com>
References: <CA+ksgABBfa8Ochuz6RUDWXRd12fy2rKrL9oHmfmNmRq=Okmzew@mail.gmail.com>
Message-ID: <d326988aad46f479087627f6aa3a50ec.NginxMailingListRussian@forum.nginx.org>

С таким вариантом получаем 403 Forbidden на URL любого типа, разрешённые и
нет ? проксирования не происходит, не срабатывает правило.
Пробовал и так:

location /Mydll.dll {
if ($query_string ~ al= ) {
proxy_pass http://192.168.0.2:3000;
}
deny all;
}

и так:
proxy_pass http://192.168.0.2:3000$1;

и так:
proxy_pass http://192.168.0.2:3000/$1$is_args$args;;


Предложенный вами синтаксис location/ пришлось сократить, иначе при проверке
конфигурации возникала ошибка:
nginx: [emerg] named location "@nameloc" can be on the server level only

Возможно, столь сложные конструкции регулярных выражений (разрешить всё
кроме) не поддерживаются в nginx в принципе?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,17244,258029#msg-258029


From nginx-forum at nginx.us  Tue Apr 14 14:18:38 2015
From: nginx-forum at nginx.us (itcod)
Date: Tue, 14 Apr 2015 10:18:38 -0400
Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60LjQuSBkYXYgbWV0aG9kcyAkREFWOw==?=
In-Reply-To: <20150414122438.GH88631@mdounin.ru>
References: <20150414122438.GH88631@mdounin.ru>
Message-ID: <1f6698144bc2b1f0cee2874b5d4f224e.NginxMailingListRussian@forum.nginx.org>

Максим спасибо...
хм..... imho оч странный по моему подход.... зачем это ограничение.... я
хотел сделать чтобы у каждого юзера свои права были на локейшн... одному
можно писать другому нельзя... одному можно создавать папки другому "сиди -
чай пей" и так далее :)

а какие варианты существуют.... 
1. патчить ngx_http_dav_module.c - я не настолько знаток си...
2. обратится с предложением к Игорю Сысоеву....
3..... 

Как вы считаете какой вариант реальнее?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258024,258030#msg-258030


From nginx-forum at nginx.us  Tue Apr 14 14:27:03 2015
From: nginx-forum at nginx.us (itcod)
Date: Tue, 14 Apr 2015 10:27:03 -0400
Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60LjQuSBkYXYgbWV0aG9kcyAkREFWOw==?=
In-Reply-To: <20150414122438.GH88631@mdounin.ru>
References: <20150414122438.GH88631@mdounin.ru>
Message-ID: <8e02e0d06d6bafaf9da56854bcf7a734.NginxMailingListRussian@forum.nginx.org>

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

Максим подскажите пожалуйста, какие модули вы подразумевали под "средства
контроля доступа" ?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258024,258031#msg-258031


From simplebox66 at gmail.com  Tue Apr 14 14:54:32 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Tue, 14 Apr 2015 17:54:32 +0300
Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0L3Ri9C1INCy0YvRgNCw0LbQtdC90LjRjyDQsiBs?=
 =?UTF-8?B?b2NhdGlvbg==?=
In-Reply-To: <d326988aad46f479087627f6aa3a50ec.NginxMailingListRussian@forum.nginx.org>
References: <CA+ksgABBfa8Ochuz6RUDWXRd12fy2rKrL9oHmfmNmRq=Okmzew@mail.gmail.com>
 <d326988aad46f479087627f6aa3a50ec.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CA+ksgAC+HYQfhNMYnkkyGoeXkmY8aWK7_YFti5dZZMQbOmrmrA@mail.gmail.com>

>
> Предложенный вами синтаксис location/ пришлось сократить, иначе при
> проверке
> конфигурации возникала ошибка:
> nginx: [emerg] named location "@nameloc" can be on the server level only


Будьте внимательнее!
В ошибке явно же написано   что именованные локейшн @nameloc должен быть на
уровне директивы server. В моем варианте именно так и есть, скорее всего вы
опечатались когда пробовали мой вариант.

Сам не так давно сталкивался с похожей задачей, поэтому мой конфиг 100%
рабочий ибо опробован.

14 апреля 2015 г., 16:59 пользователь s.ivanov <nginx-forum at nginx.us>
написал:

> С таким вариантом получаем 403 Forbidden на URL любого типа, разрешённые и
> нет ? проксирования не происходит, не срабатывает правило.
> Пробовал и так:
>
> location /Mydll.dll {
> if ($query_string ~ al= ) {
> proxy_pass http://192.168.0.2:3000;
> }
> deny all;
> }
>
> и так:
> proxy_pass http://192.168.0.2:3000$1;
>
> и так:
> proxy_pass http://192.168.0.2:3000/$1$is_args$args;;
>
>
> Предложенный вами синтаксис location/ пришлось сократить, иначе при
> проверке
> конфигурации возникала ошибка:
> nginx: [emerg] named location "@nameloc" can be on the server level only
>
> Возможно, столь сложные конструкции регулярных выражений (разрешить всё
> кроме) не поддерживаются в nginx в принципе?
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,17244,258029#msg-258029
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150414/c89b7df9/attachment.html>

From nginx-forum at nginx.us  Tue Apr 14 15:18:51 2015
From: nginx-forum at nginx.us (s.ivanov)
Date: Tue, 14 Apr 2015 11:18:51 -0400
Subject: =?UTF-8?B?UmU6INCg0LXQs9GD0LvRj9GA0L3Ri9C1INCy0YvRgNCw0LbQtdC90LjRjyDQsiBs?=
 =?UTF-8?B?b2NhdGlvbg==?=
In-Reply-To: <CA+ksgAC+HYQfhNMYnkkyGoeXkmY8aWK7_YFti5dZZMQbOmrmrA@mail.gmail.com>
References: <CA+ksgAC+HYQfhNMYnkkyGoeXkmY8aWK7_YFti5dZZMQbOmrmrA@mail.gmail.com>
Message-ID: <c45d14371170aa179bfd41d63c15b3a3.NginxMailingListRussian@forum.nginx.org>

Действительно, после выноса @nameloc на уровень сервера заработало как и
требовалось: запросы к самой dll без аргументов запрещены, запросы с
правильным ключом проксируются.
Большое спасибо!

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,17244,258033#msg-258033


From sytar.alex at gmail.com  Tue Apr 14 17:17:57 2015
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Tue, 14 Apr 2015 20:17:57 +0300
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0LfQsNC/0YDQvtGB0L7QsiDQsdC1?=
 =?UTF-8?B?0Lcg0LrRg9C60L7Qsg==?=
In-Reply-To: <CA+ksgACMzLXf9y43PO-1j3fA4XvDbKYdOQFnbBbtwax+kfA84Q@mail.gmail.com>
References: <CA+ksgAB86CVhy5ua+JHRmHsDDjZHFZYU6xoHte4A8X9YNKmbaQ@mail.gmail.com>
 <CA+ksgABSdw-f8WwtHd8QkaQ_o4ijP3mgfDSWGvq+=mpfD6=Eeg@mail.gmail.com>
 <CA+ksgADx1tGkH03cdLM+WL1T0ujNiV4aTiEHuu8ejMbAWoS4eQ@mail.gmail.com>
 <3373855.0ZngzD8M3Q@note>
 <CA+ksgACMzLXf9y43PO-1j3fA4XvDbKYdOQFnbBbtwax+kfA84Q@mail.gmail.com>
Message-ID: <CAKqRTSG31DxbLn2EK0LOs+6TTsuS3+eRZStA53sAU0hanRJ7gg@mail.gmail.com>

14 апреля 2015 г., 16:20 пользователь Иван Мишин <simplebox66 at gmail.com>
написал:

> 1)урл не кеше, запрашиваем урл с помощью curl, получаем промах, еще раз
> опять промах и т.д.
> 2)урл не в кеше, запрашиваем урл с помощью любого браузера - первый раз
> промах, второй и последующие разы ответ возвращается из кеша
>

А давно curl научился в разных итерациях следовать Cache-Control и локально
кешировать?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150414/c1ebd897/attachment.html>

From mdounin at mdounin.ru  Tue Apr 14 17:53:41 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 14 Apr 2015 20:53:41 +0300
Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60LjQuSBkYXYgbWV0aG9kcyAkREFWOw==?=
In-Reply-To: <8e02e0d06d6bafaf9da56854bcf7a734.NginxMailingListRussian@forum.nginx.org>
References: <20150414122438.GH88631@mdounin.ru>
 <8e02e0d06d6bafaf9da56854bcf7a734.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150414175341.GM88631@mdounin.ru>

Hello!

On Tue, Apr 14, 2015 at 10:27:03AM -0400, itcod wrote:

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

Для ограничения доступа в nginx'е существует три стандартных 
модуля:

http://nginx.org/ru/docs/http/ngx_http_access_module.html
http://nginx.org/ru/docs/http/ngx_http_auth_basic_module.html
http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html

А также стандартные директивы satisfy и limit_except:

http://nginx.org/ru/docs/http/ngx_http_core_module.html#satisfy
http://nginx.org/ru/docs/http/ngx_http_core_module.html#limit_except

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

http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html

-- 
Maxim Dounin
http://nginx.org/


From mdounin at mdounin.ru  Tue Apr 14 18:00:10 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 14 Apr 2015 21:00:10 +0300
Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60LjQuSBkYXYgbWV0aG9kcyAkREFWOw==?=
In-Reply-To: <1f6698144bc2b1f0cee2874b5d4f224e.NginxMailingListRussian@forum.nginx.org>
References: <20150414122438.GH88631@mdounin.ru>
 <1f6698144bc2b1f0cee2874b5d4f224e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150414180010.GN88631@mdounin.ru>

Hello!

On Tue, Apr 14, 2015 at 10:18:38AM -0400, itcod wrote:

> Максим спасибо...
> хм..... imho оч странный по моему подход.... зачем это ограничение.... я
> хотел сделать чтобы у каждого юзера свои права были на локейшн... одному
> можно писать другому нельзя... одному можно создавать папки другому "сиди -
> чай пей" и так далее :)

Странно - это использовать для подобного разделения директиву 
dav_methods.  Для контроля доступа следует пользоваться средствами 
контроля доступа.

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

> а какие варианты существуют.... 
> 1. патчить ngx_http_dav_module.c - я не настолько знаток си...
> 2. обратится с предложением к Игорю Сысоеву....
> 3..... 
> 
> Как вы считаете какой вариант реальнее?

Реальнее - использовать средства контроля доступа, см. выше.

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Tue Apr 14 19:38:11 2015
From: nginx-forum at nginx.us (itcod)
Date: Tue, 14 Apr 2015 15:38:11 -0400
Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60LjQuSBkYXYgbWV0aG9kcyAkREFWOw==?=
In-Reply-To: <20150414180010.GN88631@mdounin.ru>
References: <20150414180010.GN88631@mdounin.ru>
Message-ID: <3306a4e76a0e31de70b974a591b19814.NginxMailingListRussian@forum.nginx.org>

"Реальнее - использовать средства контроля доступа, см. выше."

Максим спасибо. 
Из всех перечисленных вами средств похоже только limit_except по описанию
может раздельно влиять 
на методы применяемые в WEBDAV (DELETE, MKCOL, COPY, MOVE, OPTIONS,
PROPFIND)

Задача тривиальна при изменении переменной (она изменяется из программы lua)
разрешить или блокировать метод GET. Создал для проверки конструкцию

set $limit_get all;
limit_except GET {
    deny  $limit_get all;
}
Получил ошибку:
nginx: [emerg] invalid parameter "limit_get" ....

Вывод1. Средство контроля не знает переменных и не может в зависимости от
внешних условий (прав пользователя) заблокировать/разблокировать метод.

Вывод2. Перечисленные вами средства контроля не решают задачи динамической
установки доступных пользователю(имя:пароль) методов (прав доступа).
 
Я пока не вижу способа запретить ему создавать каталоги или стирать файлы
если он зашёл в папку.... и это приводит нас к однопользовательской системе
алядос... может я чего то не вижу ? может где то есть эта возможность
динамически управлять методами(правами). Всё таки хочется сделать
простенькую полноценную систему управления доступом к файлам в webdav... 

и снова я возвращаюсь к вопросу
> а какие варианты существуют....
> 1. патчить ngx_http_dav_module.c - я не настолько знаток си...
> 2. обратится с предложением к Игорю Сысоеву....
3 патчить модуль где описан limit_except
4.............
>

Как вы считаете какой вариант реальнее?

PS: Может есть ещё какой нибудь модуль управления этими методами который
умеет получать переменные?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258024,258042#msg-258042


From nginx-forum at nginx.us  Tue Apr 14 19:47:45 2015
From: nginx-forum at nginx.us (itcod)
Date: Tue, 14 Apr 2015 15:47:45 -0400
Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60LjQuSBkYXYgbWV0aG9kcyAkREFWOw==?=
In-Reply-To: <3306a4e76a0e31de70b974a591b19814.NginxMailingListRussian@forum.nginx.org>
References: <20150414180010.GN88631@mdounin.ru>
 <3306a4e76a0e31de70b974a591b19814.NginxMailingListRussian@forum.nginx.org>
Message-ID: <4f2aebca3a13ba402a2a3cdb45ebc6e7.NginxMailingListRussian@forum.nginx.org>

в предыдущем посте ошибку допустил когда писал сюда
конечно не работает
limit_except GET {
deny $limit_get;
}

перечитал топик ещё раз.....
возникла мысль через if подключать блоки
limit_except GET {
deny all;
}

завтра попобую.... Максим спасибо за идеи.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258024,258043#msg-258043


From nginx-forum at nginx.us  Tue Apr 14 20:01:33 2015
From: nginx-forum at nginx.us (itcod)
Date: Tue, 14 Apr 2015 16:01:33 -0400
Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60LjQuSBkYXYgbWV0aG9kcyAkREFWOw==?=
In-Reply-To: <4f2aebca3a13ba402a2a3cdb45ebc6e7.NginxMailingListRussian@forum.nginx.org>
References: <20150414180010.GN88631@mdounin.ru>
 <3306a4e76a0e31de70b974a591b19814.NginxMailingListRussian@forum.nginx.org>
 <4f2aebca3a13ba402a2a3cdb45ebc6e7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <80478bfa3d5f1b744760c34769335f2b.NginxMailingListRussian@forum.nginx.org>

Конструкция:
set $limit_get all;
if ($limit_get) {
   limit_except GET {
      deny all;
   }
}

Ошибка
nginx: [emerg] "limit_except" directive is not allowed here in .....

И снова возвращаемся к вопросам о вечном :/
Что делать... кто виноват.... кудакуда идти:))))))

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258024,258044#msg-258044


From mdounin at mdounin.ru  Tue Apr 14 21:42:38 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 15 Apr 2015 00:42:38 +0300
Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60LjQuSBkYXYgbWV0aG9kcyAkREFWOw==?=
In-Reply-To: <3306a4e76a0e31de70b974a591b19814.NginxMailingListRussian@forum.nginx.org>
References: <20150414180010.GN88631@mdounin.ru>
 <3306a4e76a0e31de70b974a591b19814.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150414214238.GO88631@mdounin.ru>

Hello!

On Tue, Apr 14, 2015 at 03:38:11PM -0400, itcod wrote:

> "Реальнее - использовать средства контроля доступа, см. выше."
> 
> Максим спасибо. 
> Из всех перечисленных вами средств похоже только limit_except по описанию
> может раздельно влиять 
> на методы применяемые в WEBDAV (DELETE, MKCOL, COPY, MOVE, OPTIONS,
> PROPFIND)

Вам кажется.  Контроль доступа в зависимости от метода можно 
делать, помимо limit_except, ещё как минимум с помощью директив 
модуля rewrite:

    if ($request_method = POST) {
        return 403;
    }

Не говоря уже о выгрузке логики доступа в скриптовые языки (perl, 
тот же lua) или вообще на бекенды с помощью auth_request.

> Задача тривиальна при изменении переменной (она изменяется из программы lua)
> разрешить или блокировать метод GET. Создал для проверки конструкцию
> 
> set $limit_get all;
> limit_except GET {
>     deny  $limit_get all;
> }
> Получил ошибку:
> nginx: [emerg] invalid parameter "limit_get" ....
> 
> Вывод1. Средство контроля не знает переменных и не может в зависимости от
> внешних условий (прав пользователя) заблокировать/разблокировать метод.

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

> Вывод2. Перечисленные вами средства контроля не решают задачи динамической
> установки доступных пользователю(имя:пароль) методов (прав доступа).

См. выше, вам кажется.

> Я пока не вижу способа запретить ему создавать каталоги или стирать файлы
> если он зашёл в папку.... и это приводит нас к однопользовательской системе
> алядос... может я чего то не вижу ? может где то есть эта возможность
> динамически управлять методами(правами). Всё таки хочется сделать
> простенькую полноценную систему управления доступом к файлам в webdav... 

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

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

    server {
        listen 80;
        server_name dav.example.com;

        location / {
            auth_basic "restricted site";
            auth_basic_user_file /path/to/users;

            dav_methods PUT DELETE;

            limit_except GET {
                auth_basic "restricted site";
                auth_basic_user_file /path/to/admins;
            }

            ...
        }
    }

-- 
Maxim Dounin
http://nginx.org/


From a.vasilishin at kpi.ua  Tue Apr 14 23:28:07 2015
From: a.vasilishin at kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=)
Date: Wed, 15 Apr 2015 02:28:07 +0300
Subject: =?UTF-8?B?dXBsb2FkcHJvZ3Jlc3MsINGB0YLRgNCw0L3QvdCw0Y8g0L7QsdGA0LDQsdC+0YI=?=
 =?UTF-8?B?0LrQsCDQt9Cw0L/RgNC+0YHQvtCy?=
Message-ID: <552DA287.5080004@kpi.ua>

После обновления нгинкса с дотдебовского репозитория случилось что-то 
странное. Не вижу обработки запроса, сразу вылазит ошибка 400:

2015/04/15 02:23:57 [debug] 385#0: *387 accept: 176.104.56.218 fd:43
2015/04/15 02:23:57 [debug] 385#0: posix_memalign: 0000000001F0B610:256 @16
2015/04/15 02:23:57 [debug] 385#0: *387 event timer add: 43: 
60000:1429053897756
2015/04/15 02:23:57 [debug] 385#0: *387 reusable connection: 1
2015/04/15 02:23:57 [debug] 385#0: *387 epoll add event: fd:43 op:1 
ev:80002001
2015/04/15 02:23:57 [debug] 385#0: *387 post event 00007FC7711B0280
2015/04/15 02:23:57 [debug] 385#0: *387 delete posted event 00007FC7711B0280
2015/04/15 02:23:57 [debug] 385#0: *387 http check ssl handshake
2015/04/15 02:23:57 [debug] 385#0: *387 http recv(): 1
2015/04/15 02:23:57 [debug] 385#0: *387 plain http
2015/04/15 02:23:57 [debug] 385#0: *387 http wait request handler
2015/04/15 02:23:57 [debug] 385#0: *387 malloc: 0000000001EAFCB0:1024
2015/04/15 02:23:57 [debug] 385#0: *387 recv: fd:43 493 of 1024
2015/04/15 02:23:57 [debug] 385#0: *387 reusable connection: 0
2015/04/15 02:23:57 [debug] 385#0: *387 posix_memalign: 
0000000001F7A410:4096 @16
2015/04/15 02:23:57 [debug] 385#0: *387 http process request line
2015/04/15 02:23:57 [debug] 385#0: *387 http request line: "GET 
/upload/img/photos/site/video/43/4367/436717/436717m.jpg HTTP/1.1"
2015/04/15 02:23:57 [debug] 385#0: *387 http uri: 
"/upload/img/photos/site/video/43/4367/436717/436717m.jpg"
2015/04/15 02:23:57 [debug] 385#0: *387 http args: ""
2015/04/15 02:23:57 [debug] 385#0: *387 http exten: "jpg"
2015/04/15 02:23:57 [debug] 385#0: *387 http process request header line
2015/04/15 02:23:57 [debug] 385#0: *387 posix_memalign: 
0000000001F7B420:4096 @16
2015/04/15 02:23:57 [debug] 385#0: *387 http header: "Host: s4.site.tv"
2015/04/15 02:23:57 [debug] 385#0: *387 http header: "Connection: 
keep-alive"
2015/04/15 02:23:57 [debug] 385#0: *387 http header: "User-Agent: 
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like 
Gecko) Chrome/41.0.2272.101 Safari/537.36"
2015/04/15 02:23:57 [debug] 385#0: *387 http header: "X-Requested-With: 
ShockwaveFlash/17.0.0.134"
2015/04/15 02:23:57 [debug] 385#0: *387 http header: "Accept: */*"
2015/04/15 02:23:57 [debug] 385#0: *387 http header: "Accept-Encoding: 
gzip, deflate, sdch"
2015/04/15 02:23:57 [debug] 385#0: *387 http header: "Accept-Language: 
ru,en-US;q=0.8,en;q=0.6,uk;q=0.4"
2015/04/15 02:23:57 [debug] 385#0: *387 http header: "Cookie: 
PHPSESSID=iq0b1esb2b413jtahhdtgo4bb1; lang_code=ru; _gat=1; 
_ga=GA1.2.327265239.1427830768"
2015/04/15 02:23:57 [debug] 385#0: *387 http header done
2015/04/15 02:23:57 [info] 385#0: *387 client sent plain HTTP request to 
HTTPS port while reading client request headers, client: 176.104.56.218, 
server: s4.site.tv, request: "GET /upload/img/p
hotos/site/video/43/4367/436717/436717m.jpg HTTP/1.1", host: "s4.site.tv"
2015/04/15 02:23:57 [debug] 385#0: *387 http finalize request: 497, 
"/upload/img/photos/site/video/43/4367/436717/436717m.jpg?" a:1, c:1
2015/04/15 02:23:57 [debug] 385#0: *387 event timer del: 43: 1429053897756
2015/04/15 02:23:57 [debug] 385#0: *387 http special response: 497, 
"/upload/img/photos/site/video/43/4367/436717/436717m.jpg?"
2015/04/15 02:23:57 [debug] 385#0: *387 http set discard body
2015/04/15 02:23:57 [debug] 385#0: *387 uploadprogress error-tracker 
error: 400
2015/04/15 02:23:57 [debug] 385#0: *387 uploadprogress error-tracker not 
tracking in this location
2015/04/15 02:23:57 [debug] 385#0: *387 HTTP/1.1 400 Bad Request
Server: nginx/1.6.3
Date: Tue, 14 Apr 2015 23:23:57 GMT
Content-Type: text/html
Content-Length: 672
Connection: close


From a.vasilishin at kpi.ua  Tue Apr 14 23:34:00 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: Wed, 15 Apr 2015 02:34:00 +0300
Subject: =?UTF-8?B?UmU6IHVwbG9hZHByb2dyZXNzLCDRgdGC0YDQsNC90L3QsNGPINC+0LHRgNCw0LE=?=
 =?UTF-8?B?0L7RgtC60LAg0LfQsNC/0YDQvtGB0L7Qsg==?=
In-Reply-To: <552DA287.5080004@kpi.ua>
References: <552DA287.5080004@kpi.ua>
Message-ID: <552DA3E8.4080104@kpi.ua>

Разобрался, uploadprogress тут не причем. Всему виной было ssl on;


From simplebox66 at gmail.com  Wed Apr 15 05:45:36 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Wed, 15 Apr 2015 08:45:36 +0300
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUg0LfQsNC/0YDQvtGB0L7QsiDQsdC1?=
 =?UTF-8?B?0Lcg0LrRg9C60L7Qsg==?=
In-Reply-To: <CAKqRTSG31DxbLn2EK0LOs+6TTsuS3+eRZStA53sAU0hanRJ7gg@mail.gmail.com>
References: <CA+ksgAB86CVhy5ua+JHRmHsDDjZHFZYU6xoHte4A8X9YNKmbaQ@mail.gmail.com>
 <CA+ksgABSdw-f8WwtHd8QkaQ_o4ijP3mgfDSWGvq+=mpfD6=Eeg@mail.gmail.com>
 <CA+ksgADx1tGkH03cdLM+WL1T0ujNiV4aTiEHuu8ejMbAWoS4eQ@mail.gmail.com>
 <3373855.0ZngzD8M3Q@note>
 <CA+ksgACMzLXf9y43PO-1j3fA4XvDbKYdOQFnbBbtwax+kfA84Q@mail.gmail.com>
 <CAKqRTSG31DxbLn2EK0LOs+6TTsuS3+eRZStA53sAU0hanRJ7gg@mail.gmail.com>
Message-ID: <CA+ksgACu10jxq9Jv4D-HxhXX-0eVhU9GWvTZSCRppyJ+KcmDig@mail.gmail.com>

>
> А давно curl научился в разных итерациях следовать Cache-Control и
> локально кешировать?

А я не про локальное кеширование говорю. Речь идет о кешировании на стороне
nginx!
А  Cache-Control и Expired у меня кстати стоят за директивой
proxy_ignore_headers

14 апреля 2015 г., 20:17 пользователь Aleksandr Sytar <sytar.alex at gmail.com>
написал:

>
> 14 апреля 2015 г., 16:20 пользователь Иван Мишин <simplebox66 at gmail.com>
> написал:
>
>> 1)урл не кеше, запрашиваем урл с помощью curl, получаем промах, еще раз
>> опять промах и т.д.
>> 2)урл не в кеше, запрашиваем урл с помощью любого браузера - первый раз
>> промах, второй и последующие разы ответ возвращается из кеша
>>
>
> А давно curl научился в разных итерациях следовать Cache-Control и
> локально кешировать?
>
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150415/62480a5c/attachment.html>

From nginx-forum at nginx.us  Wed Apr 15 06:04:57 2015
From: nginx-forum at nginx.us (itcod)
Date: Wed, 15 Apr 2015 02:04:57 -0400
Subject: =?UTF-8?B?UmU6INC00LjQvdCw0LzQuNGH0LXRgdC60LjQuSBkYXYgbWV0aG9kcyAkREFWOw==?=
In-Reply-To: <20150414214238.GO88631@mdounin.ru>
References: <20150414214238.GO88631@mdounin.ru>
Message-ID: <6e22b04ad6b0ea1eb1e73fddaec0da94.NginxMailingListRussian@forum.nginx.org>

"то проще всего вашу задачу решить с помощью скриптового языка же, вернув
ошибку непосредственно из него."
Максим спасибо! вы гений!!! блин..... ну чво я то так туплю:)))))))))))))))

И этот вариант вполне хорош, но первый лучше
if ($request_method = POST) {
return 403;
}

СПАСИБО! пойду попишу:)

PS Надеюсь запомню :)))))))
"BTW, если в какой-либо директиве можно использовать переменные - это явно
указано в документации."

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258024,258049#msg-258049


From simplebox66 at gmail.com  Wed Apr 15 12:06:08 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Wed, 15 Apr 2015 15:06:08 +0300
Subject: =?UTF-8?B?UmU6INC+0LHRidC40Lkg0LrRjdGIINC00LvRjyDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0YUgbmdpbng=?=
In-Reply-To: <CACz2Q8FZmrysMOFhzOERmTgjt6v-HAAkgoTM8i3_2mCcU_K7oA@mail.gmail.com>
References: <CAHRZc-2aA3UmYju3iNk1ZbJYavHrU3kkrQQ5A+0b+zuEUz=s=Q@mail.gmail.com>
 <CAFHpkQFQugMvxTCmHHVrae8uygxc9Edxtq6jgx3wQ=EO0MVz-w@mail.gmail.com>
 <CAHRZc-0MWn-gzLiszs0-_DqT3mGiUH2fPEKwnL2kw_nb2UKLOA@mail.gmail.com>
 <CAFHpkQFdJnCVnEshyqCrO=9w_jyBEcY0GJw3ajZBzf1q=04K9w@mail.gmail.com>
 <CAHRZc-3+W3LFvYsrC9--vzoZDCH36dSxpUmoU+UnD9ndpZncjw@mail.gmail.com>
 <CAFHpkQHB58-1D-J0OZ=ta7ZkV7tUZtMK5oGQSQ=6ukx7cWQv7g@mail.gmail.com>
 <CACz2Q8FZmrysMOFhzOERmTgjt6v-HAAkgoTM8i3_2mCcU_K7oA@mail.gmail.com>
Message-ID: <CA+ksgABe09UtjpEZbjAjKS0fPn44zzOGdYPVK4ZbVKtutyOkMg@mail.gmail.com>

Всем привет!
Меня тоже интересует идея общего кеша для нескольких nginx. При этом
понравилась идея про оценку эффективности существующего кеша. Что бы точно
понимать есть ли смысл в идеи общего кеша. А потому хотелось бы узнать,
кто-то пробовал считать/оценивать эффективность кеша nginx? каким образом
это можно сделать? Мне кроме тестирования с помощью ab ни чего в голову и
не приходит, а  хотелось бы какой-то более серьезный расчет получить

13 апреля 2015 г., 13:31 пользователь Bogdan <bogdar at gmail.com> написал:

> Привет.
>
> 1. Общий кэш на файловой системе - единая точка отказа. В лучшем случае
> потеряете сам кэш - в худшем - все балансировщики.
> 2. Эффективность существующего кэша надо оценивать, если там 90% - я не
> силён в математике, но буст будет не так велик ИМХО.
> 3. Если хочется новых острых впечатлений в продакшене - можно кэшировать в
> общем мемкэше. Но есть шанс потерять кэш вообще, либо получить холодный кэш.
> 4. Можно отдавать ответы не с бэкендов, а через кластер couchbase -
> http://labs.couchbase.com/couchbase-nginx-module/, но придётся доработать
> приложение так, чтобы оно сам писало кэш в кучбейс и самостоятельно же
> чистило его.
>
>
> 2015-03-23 17:58 GMT+03:00 Илья Шипицин <chipitsine at gmail.com>:
>
>> расчеты можно сделать исходя, например, из access-логов.
>> залогируйте $upstream_response_time, посмотрите, какие запросы могли
>> бы обработаться из кеша, если бы он был общий, просуммируйте.
>>
>> можно взять граничное условие, что, если запрос берется из кеша, то
>> временнЫе затраты на это равны нулю, т.е. в первом приближении
>> пренебречь дисковым вводом-выводом. это может быть справедливо, если у
>> вас действительно тяжелая генерация ответов.
>>
>> 23 марта 2015 г., 18:24 пользователь Михаил Пульман <pullmix at gmail.com>
>> написал:
>> > Расчетов нет, есть предположение. Вы подскажите как реализовать, а
>> > последующие тесты покажут результативность такого решения. Чисто из
>> > логических соображений прирост должен быть обязательно.
>> >
>> > С уважением, Михаил
>> >
>> > 23 марта 2015 г., 16:10 пользователь Илья Шипицин <chipitsine at gmail.com
>> >
>> > написал:
>> >
>> >> а есть расчеты, подтверждающие хороший прирост производительности ?
>> >>
>> >> 23 марта 2015 г., 17:30 пользователь Михаил Пульман <pullmix at gmail.com
>> >
>> >> написал:
>> >> > Ситуация в том что есть железный балансировщик, он раскидывает
>> трафик по
>> >> > 4-6
>> >> > штукам nginx, а нжинксы балансируя траффик с помощью апстрима
>> >> > перенаправляют
>> >> > на бэкенд сервера. На балансировщиках nginx  настроен кэш. Получается
>> >> > что на
>> >> > всех балансировщиках разный кеш. Допусти клиентский запрос попавший
>> на
>> >> > балансир номер 1 кеша там не обнаружилось и запрос пошел на бэкенд,
>> в то
>> >> > время как на балансировщике номер 2 нужный кеш в этот момент был, но
>> по
>> >> > понятным причинам не был использоан. Вообщем если сделать общий кеш
>> для
>> >> > всех
>> >> > балансировщиков nginx  можно получить хороший прирост
>> >> > производительности.
>> >> >
>> >> > С уважением, Михаил
>> >> >
>> >> > 23 марта 2015 г., 12:56 пользователь Илья Шипицин <
>> chipitsine at gmail.com>
>> >> > написал:
>> >> >
>> >> >> возможно, вы придете к монстроидной схеме
>> >> >>
>> >> >> nginx --> squid (с поддержкой ICAP) --> бекенды
>> >> >>
>> >> >> и даже после танцев с бубном вы ее настроите.
>> >> >>
>> >> >> но, практика показывает, что в таких случаях надо уметь отвечать на
>> >> >> вопрос "зачем это надо ?".
>> >> >> после ответа на который часто оказывается, что на самом деле - не
>> надо.
>> >> >>
>> >> >> вы бы рассказали про вашу ситуацию в деталях ?
>> >> >>
>> >> >> 23 марта 2015 г., 13:54 пользователь Михаил Пульман <
>> pullmix at gmail.com>
>> >> >> написал:
>> >> >> > Добрый день коллеги!
>> >> >> >
>> >> >> > На фронте имеется n-ое количество nginx которые выступают в
>> качестве
>> >> >> > балансировщиков.
>> >> >> > Нужно наладить единый кэш для всех фронтенд nginxов. Какие есть
>> >> >> > возможности
>> >> >> > в nginx для реализации этой задачи?
>> >> >> >
>> >> >> > С уважением, Михаил
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > nginx-ru mailing list
>> >> >> > nginx-ru at nginx.org
>> >> >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >> >> _______________________________________________
>> >> >> nginx-ru mailing list
>> >> >> nginx-ru at nginx.org
>> >> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > nginx-ru mailing list
>> >> > nginx-ru at nginx.org
>> >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >> _______________________________________________
>> >> nginx-ru mailing list
>> >> nginx-ru at nginx.org
>> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >
>> >
>> >
>> > _______________________________________________
>> > nginx-ru mailing list
>> > nginx-ru at nginx.org
>> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
>
> --
> WBR,  Bogdan B. Rudas
>
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150415/ddb40416/attachment.html>

From vbart at nginx.com  Wed Apr 15 17:01:59 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 15 Apr 2015 20:01:59 +0300
Subject: =?UTF-8?B?UmU6INC+0LHRidC40Lkg0LrRjdGIINC00LvRjyDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0YUgbmdpbng=?=
In-Reply-To: <CA+ksgABe09UtjpEZbjAjKS0fPn44zzOGdYPVK4ZbVKtutyOkMg@mail.gmail.com>
References: <CAHRZc-2aA3UmYju3iNk1ZbJYavHrU3kkrQQ5A+0b+zuEUz=s=Q@mail.gmail.com>
 <CACz2Q8FZmrysMOFhzOERmTgjt6v-HAAkgoTM8i3_2mCcU_K7oA@mail.gmail.com>
 <CA+ksgABe09UtjpEZbjAjKS0fPn44zzOGdYPVK4ZbVKtutyOkMg@mail.gmail.com>
Message-ID: <3921110.3oMSEEtUKJ@vbart-laptop>

On Wednesday 15 April 2015 15:06:08 Иван Мишин wrote:
> Всем привет!
> Меня тоже интересует идея общего кеша для нескольких nginx. При этом
> понравилась идея про оценку эффективности существующего кеша. Что бы точно
> понимать есть ли смысл в идеи общего кеша. А потому хотелось бы узнать,
> кто-то пробовал считать/оценивать эффективность кеша nginx? каким образом
> это можно сделать? Мне кроме тестирования с помощью ab ни чего в голову и
> не приходит, а  хотелось бы какой-то более серьезный расчет получить
[..]

Проще всего эффективность кэша отслеживать в реальном времени в nginx plus
с помощью status-модуля: http://nginx.org/ru/docs/http/ngx_http_status_module.html#caches

Наглядно: http://demo.nginx.com/status.html#anchor-caches

--
Валентин Бартенев

From simplebox66 at gmail.com  Thu Apr 16 06:24:28 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Thu, 16 Apr 2015 09:24:28 +0300
Subject: =?UTF-8?B?UmU6INC+0LHRidC40Lkg0LrRjdGIINC00LvRjyDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0YUgbmdpbng=?=
In-Reply-To: <3921110.3oMSEEtUKJ@vbart-laptop>
References: <CAHRZc-2aA3UmYju3iNk1ZbJYavHrU3kkrQQ5A+0b+zuEUz=s=Q@mail.gmail.com>
 <CACz2Q8FZmrysMOFhzOERmTgjt6v-HAAkgoTM8i3_2mCcU_K7oA@mail.gmail.com>
 <CA+ksgABe09UtjpEZbjAjKS0fPn44zzOGdYPVK4ZbVKtutyOkMg@mail.gmail.com>
 <3921110.3oMSEEtUKJ@vbart-laptop>
Message-ID: <CA+ksgADHAEnJH2SDJG5=pnQcZSOUZaDBAgY=36CmnwjjYiae1Q@mail.gmail.com>

Меня все же интересуют free варианты

15 апреля 2015 г., 20:01 пользователь Валентин Бартенев <vbart at nginx.com>
написал:

> On Wednesday 15 April 2015 15:06:08 Иван Мишин wrote:
> > Всем привет!
> > Меня тоже интересует идея общего кеша для нескольких nginx. При этом
> > понравилась идея про оценку эффективности существующего кеша. Что бы
> точно
> > понимать есть ли смысл в идеи общего кеша. А потому хотелось бы узнать,
> > кто-то пробовал считать/оценивать эффективность кеша nginx? каким образом
> > это можно сделать? Мне кроме тестирования с помощью ab ни чего в голову и
> > не приходит, а  хотелось бы какой-то более серьезный расчет получить
> [..]
>
> Проще всего эффективность кэша отслеживать в реальном времени в nginx plus
> с помощью status-модуля:
> http://nginx.org/ru/docs/http/ngx_http_status_module.html#caches
>
> Наглядно: http://demo.nginx.com/status.html#anchor-caches
>
> --
> Валентин Бартенев
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150416/345151a1/attachment.html>

From nginx-forum at nginx.us  Thu Apr 16 07:51:03 2015
From: nginx-forum at nginx.us (dwow)
Date: Thu, 16 Apr 2015 03:51:03 -0400
Subject: =?UTF-8?B?0JzQtdC00LvQtdC90L3QviDQvtGC0LTQsNGO0YLRgdGPINC00LDQvdC90YvQtSA=?=
 =?UTF-8?B?0LrQu9C40LXQvdGC0YM=?=
Message-ID: <beef2e8fc5c7aa885af39703d53e3c06.NginxMailingListRussian@forum.nginx.org>

Добрый день, 
такая проблема. Nginx стал медленно отдавать контент клиенту. 
Проблема не в сети, потому что пробовали замерить скорость отдачи статики с
того же сервера, но через Апач -- все работает как надо.
Nginx не нагружен. Контент отдается по SSL/SPDY.

В чем может быть проблема?

Спасибо.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258068,258068#msg-258068


From nginx-forum at nginx.us  Thu Apr 16 08:27:12 2015
From: nginx-forum at nginx.us (itcod)
Date: Thu, 16 Apr 2015 04:27:12 -0400
Subject: PUT & access_by_lua_file
Message-ID: <014534d85ad822248eb6d66b3e6a868b.NginxMailingListRussian@forum.nginx.org>

Здравствуйте уважаемые!
Наблюдаю странное поведение nginx. 
В тестовом авторизационном файле луа сказано, что метод PUT запрещён (см
листинг ниже).
И при этом когда захожу вижу, что сначало nginx разрешает PUT и идет
передача файла на WEBDAV и только после завершения передачи файла nginx
стартует access_by_lua_file /etc/nginx/lua/auth-dav1.lua и возвращает запрет
PUT(передачи файла)... см лог ниже.
По факту получается, что я не могу запретить из луа-авторизатора передачу
файла? конечно его размещение запрещается... но при этом он качается на
сервер и излишне грузит nginx и канал!!!
Почему так?  Это баг, фича, я глючу или ещё чвото?

------------------------
лог файл BitKinex (кстати FAR-NetDrive ведёт себя анналогично)
Resolving host name "dav.example.com" ...
Connecting ( dav.example.com => ip: 10.0.0.1, port: 80 )
Connected (10.0.0.1:80)
<<< PUT /IMG_20150414_184225.jpg HTTP/1.1
<<< Host: dav.example.com
<<< User-Agent: BitKinex/3.2.3
<<< Accept: */*
<<< Pragma: no-cache
<<< Cache-Control: no-cache
<<< Content-Length: 696983
<<< Content-Type: application/octet-stream
<<< Translate: f
>>> HTTP/1.1 405 Not Allowed
>>> Server: nginx/0.8.54
>>> Date: Thu, 16 Apr 2015 08:08:52 GMT
>>> Content-Type: text/html
>>> Connection: keep-alive
>>> Content-Length: 173
Connection closed

-----------------------------
Конфиг virt

dav.conf
server {
    listen       80;
    server_name  dav.example.com;
    server_name_in_redirect	off;
    access_log /var/log/nginx/dav-access.log main;
    resolver 10.255.255.1 [::1]:5353;
	set $dir /opt/home;
	set $dir_path $dir;
	if ($uri ~* ^(.*)([$/].*)$) {
		set $dir_path $dir$1;
	}
	set $home $dir_path;
	set $sadm_passwd .htpsw;
	set $user_passwd .uhtpasswd;
    location / {
	access_by_lua_file /etc/nginx/lua/auth-dav1.lua;
	dav_methods PUT DELETE MKCOL COPY MOVE;
	dav_ext_methods PROPFIND OPTIONS;
	create_full_put_path on;
	dav_access user:rw group:rw;
	client_body_temp_path /opt/itcod-dav.tmp/;
	client_max_body_size 0;
	autoindex on;
        root /opt/home/;
    }
    location ~/\.ht {
	deny all;
    }
}
---------------------------------------------------
тестовый листинг луа 
auth-dav1.lua

if ngx.var.request_method == 'PUT' then
   ngx.exit(405)
end

PS: так же пробовал ngx.exit(403) ngx.exit(423) - результат не меняется.
сначало грузит потом запрещает.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258069#msg-258069


From nginx-forum at nginx.us  Thu Apr 16 08:51:52 2015
From: nginx-forum at nginx.us (itcod)
Date: Thu, 16 Apr 2015 04:51:52 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <014534d85ad822248eb6d66b3e6a868b.NginxMailingListRussian@forum.nginx.org>
References: <014534d85ad822248eb6d66b3e6a868b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <11e84ec6b933b33c58b750c1be590c3e.NginxMailingListRussian@forum.nginx.org>

и на эту ситуацию ещё накладывается дефолтное поведение BitKinex
автоматически повторять посылку файла при неудаче... а любой код возврата от
PUT кроме успеха он считает неудачей, и многократно повторяет передачу....
ну и передача в 600к при таком поведении превращается в 18мегов, 30 лишних
сессий и в 30 раз больше времени...

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258070#msg-258070


From bazilek at gmail.com  Thu Apr 16 09:26:31 2015
From: bazilek at gmail.com (Vasil Mikhalenya)
Date: Thu, 16 Apr 2015 11:26:31 +0200
Subject: nginx cache
Message-ID: <CAPc4iSD1bOSu6Uo_hcOXQ8PWZ=4V573pfh9mEnV1JGkSyrzHqA@mail.gmail.com>

Вопрос по кешированию,

proxy_cache_path /var/lib/nginx/cache keys_zone=one:20m inactive=1d
use_temp_path=off;

server {
    listen 80;
    server_name _;

    proxy_cache one;

    location / {
        proxy_pass http://origin.corp.com;
        proxy_set_header Host       $proxy_host;
        add_header Cache $upstream_cache_status;
    }
}

приходит 10 запросов от клиентов, файла в кеше нет - создается 10 файлов в
cache temp dir

-rw------- 1 nginx nginx 1988247552 Apr 16 09:19 0000000001
-rw------- 1 nginx nginx 1985142784 Apr 16 09:19 0000000003
-rw------- 1 nginx nginx 1547857920 Apr 16 09:19 0000000004
-rw------- 1 nginx nginx 1767833600 Apr 16 09:19 0000000006
-rw------- 1 nginx nginx 1144295424 Apr 16 09:19 0000000007
-rw------- 1 nginx nginx 1661476864 Apr 16 09:19 0000000008
-rw------- 1 nginx nginx 1252536320 Apr 16 09:19 0000000009
-rw------- 1 nginx nginx 1593856000 Apr 16 09:19 0000000010
-rw------- 1 nginx nginx 1242357760 Apr 16 09:19 0000000011
-rw------- 1 nginx nginx  902340608 Apr 16 09:19 0000000012
-rw------- 1 nginx nginx  872054784 Apr 16 09:19 0000000013

Когда проходит 100 запросов - файл не выкачается и не закешируется никогда
т.к. канал будет полностью заполнен.

nginx version: nginx/1.7.10

Nginx действительно так работает, или я что-то упустил ?


-- 
Best regards,
Vasil Mikhalenya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150416/23b99114/attachment.html>

From bazilek at gmail.com  Thu Apr 16 09:40:59 2015
From: bazilek at gmail.com (Vasil Mikhalenya)
Date: Thu, 16 Apr 2015 11:40:59 +0200
Subject: nginx cache
In-Reply-To: <CAPc4iSD1bOSu6Uo_hcOXQ8PWZ=4V573pfh9mEnV1JGkSyrzHqA@mail.gmail.com>
References: <CAPc4iSD1bOSu6Uo_hcOXQ8PWZ=4V573pfh9mEnV1JGkSyrzHqA@mail.gmail.com>
Message-ID: <CAPc4iSDwx3hVzicPXcGWamp37JKrkHFJx0FcJwRaAJd3oB8MZw@mail.gmail.com>

ситуацию спасло добавление

proxy_cache_lock_age 120s;

однако из описания неясен смысл директивы proxy_cache_lock_timeout, кто-то
может пояснить

2015-04-16 11:26 GMT+02:00 Vasil Mikhalenya <bazilek at gmail.com>:

> Вопрос по кешированию,
>
> proxy_cache_path /var/lib/nginx/cache keys_zone=one:20m inactive=1d
> use_temp_path=off;
>
> server {
>     listen 80;
>     server_name _;
>
>     proxy_cache one;
>
>     location / {
>         proxy_pass http://origin.corp.com;
>         proxy_set_header Host       $proxy_host;
>         add_header Cache $upstream_cache_status;
>     }
> }
>
> приходит 10 запросов от клиентов, файла в кеше нет - создается 10 файлов в
> cache temp dir
>
> -rw------- 1 nginx nginx 1988247552 Apr 16 09:19 0000000001
> -rw------- 1 nginx nginx 1985142784 Apr 16 09:19 0000000003
> -rw------- 1 nginx nginx 1547857920 Apr 16 09:19 0000000004
> -rw------- 1 nginx nginx 1767833600 Apr 16 09:19 0000000006
> -rw------- 1 nginx nginx 1144295424 Apr 16 09:19 0000000007
> -rw------- 1 nginx nginx 1661476864 Apr 16 09:19 0000000008
> -rw------- 1 nginx nginx 1252536320 Apr 16 09:19 0000000009
> -rw------- 1 nginx nginx 1593856000 Apr 16 09:19 0000000010
> -rw------- 1 nginx nginx 1242357760 Apr 16 09:19 0000000011
> -rw------- 1 nginx nginx  902340608 Apr 16 09:19 0000000012
> -rw------- 1 nginx nginx  872054784 Apr 16 09:19 0000000013
>
> Когда проходит 100 запросов - файл не выкачается и не закешируется никогда
> т.к. канал будет полностью заполнен.
>
> nginx version: nginx/1.7.10
>
> Nginx действительно так работает, или я что-то упустил ?
>
>
> --
> Best regards,
> Vasil Mikhalenya
>



-- 
Best regards,
Vasil Mikhalenya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150416/ec3bf5ad/attachment-0001.html>

From redmine24 at gmail.com  Thu Apr 16 10:18:59 2015
From: redmine24 at gmail.com (=?UTF-8?B?0JTQuNC80LAg0KDQtdC00LzQsNC50L0=?=)
Date: Thu, 16 Apr 2015 13:18:59 +0300
Subject: =?UTF-8?B?UmU6INCc0LXQtNC70LXQvdC90L4g0L7RgtC00LDRjtGC0YHRjyDQtNCw0L3QvdGL?=
 =?UTF-8?B?0LUg0LrQu9C40LXQvdGC0YM=?=
In-Reply-To: <beef2e8fc5c7aa885af39703d53e3c06.NginxMailingListRussian@forum.nginx.org>
References: <beef2e8fc5c7aa885af39703d53e3c06.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAP8W4nAndknCJQBc0w6HuxRNLG+f1_igdX5WFY8sJg2=eCJgow@mail.gmail.com>

Для начала напишите после каких действий появилась проблема.

2015-04-16 10:51 GMT+03:00 dwow <nginx-forum at nginx.us>:

> Добрый день,
> такая проблема. Nginx стал медленно отдавать контент клиенту.
> Проблема не в сети, потому что пробовали замерить скорость отдачи статики с
> того же сервера, но через Апач -- все работает как надо.
> Nginx не нагружен. Контент отдается по SSL/SPDY.
>
> В чем может быть проблема?
>
> Спасибо.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,258068,258068#msg-258068
>
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150416/299ed3e9/attachment.html>

From chipitsine at gmail.com  Thu Apr 16 10:33:15 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 16 Apr 2015 15:33:15 +0500
Subject: PUT & access_by_lua_file
In-Reply-To: <014534d85ad822248eb6d66b3e6a868b.NginxMailingListRussian@forum.nginx.org>
References: <014534d85ad822248eb6d66b3e6a868b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQEeLUP2mcTtX7K5SuwW8NbZ4pSob2JUyVM=FnMpc7UVZA@mail.gmail.com>

чтобы ответить до начала передачи файла, надо реализовать "Expect: 100-Continue"


16 апреля 2015 г., 13:27 пользователь itcod <nginx-forum at nginx.us> написал:
> Здравствуйте уважаемые!
> Наблюдаю странное поведение nginx.
> В тестовом авторизационном файле луа сказано, что метод PUT запрещён (см
> листинг ниже).
> И при этом когда захожу вижу, что сначало nginx разрешает PUT и идет
> передача файла на WEBDAV и только после завершения передачи файла nginx
> стартует access_by_lua_file /etc/nginx/lua/auth-dav1.lua и возвращает запрет
> PUT(передачи файла)... см лог ниже.
> По факту получается, что я не могу запретить из луа-авторизатора передачу
> файла? конечно его размещение запрещается... но при этом он качается на
> сервер и излишне грузит nginx и канал!!!
> Почему так?  Это баг, фича, я глючу или ещё чвото?
>
> ------------------------
> лог файл BitKinex (кстати FAR-NetDrive ведёт себя анналогично)
> Resolving host name "dav.example.com" ...
> Connecting ( dav.example.com => ip: 10.0.0.1, port: 80 )
> Connected (10.0.0.1:80)
> <<< PUT /IMG_20150414_184225.jpg HTTP/1.1
> <<< Host: dav.example.com
> <<< User-Agent: BitKinex/3.2.3
> <<< Accept: */*
> <<< Pragma: no-cache
> <<< Cache-Control: no-cache
> <<< Content-Length: 696983
> <<< Content-Type: application/octet-stream
> <<< Translate: f
>>>> HTTP/1.1 405 Not Allowed
>>>> Server: nginx/0.8.54
>>>> Date: Thu, 16 Apr 2015 08:08:52 GMT
>>>> Content-Type: text/html
>>>> Connection: keep-alive
>>>> Content-Length: 173
> Connection closed
>
> -----------------------------
> Конфиг virt
>
> dav.conf
> server {
>     listen       80;
>     server_name  dav.example.com;
>     server_name_in_redirect     off;
>     access_log /var/log/nginx/dav-access.log main;
>     resolver 10.255.255.1 [::1]:5353;
>         set $dir /opt/home;
>         set $dir_path $dir;
>         if ($uri ~* ^(.*)([$/].*)$) {
>                 set $dir_path $dir$1;
>         }
>         set $home $dir_path;
>         set $sadm_passwd .htpsw;
>         set $user_passwd .uhtpasswd;
>     location / {
>         access_by_lua_file /etc/nginx/lua/auth-dav1.lua;
>         dav_methods PUT DELETE MKCOL COPY MOVE;
>         dav_ext_methods PROPFIND OPTIONS;
>         create_full_put_path on;
>         dav_access user:rw group:rw;
>         client_body_temp_path /opt/itcod-dav.tmp/;
>         client_max_body_size 0;
>         autoindex on;
>         root /opt/home/;
>     }
>     location ~/\.ht {
>         deny all;
>     }
> }
> ---------------------------------------------------
> тестовый листинг луа
> auth-dav1.lua
>
> if ngx.var.request_method == 'PUT' then
>    ngx.exit(405)
> end
>
> PS: так же пробовал ngx.exit(403) ngx.exit(423) - результат не меняется.
> сначало грузит потом запрещает.
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258069#msg-258069
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Thu Apr 16 10:34:37 2015
From: nginx-forum at nginx.us (dwow)
Date: Thu, 16 Apr 2015 06:34:37 -0400
Subject: =?UTF-8?B?UmU6INCc0LXQtNC70LXQvdC90L4g0L7RgtC00LDRjtGC0YHRjyDQtNCw0L3QvdGL?=
 =?UTF-8?B?0LUg0LrQu9C40LXQvdGC0YM=?=
In-Reply-To: <CAP8W4nAndknCJQBc0w6HuxRNLG+f1_igdX5WFY8sJg2=eCJgow@mail.gmail.com>
References: <CAP8W4nAndknCJQBc0w6HuxRNLG+f1_igdX5WFY8sJg2=eCJgow@mail.gmail.com>
Message-ID: <85cf159f6c2ba213f68bd4cd60744fb7.NginxMailingListRussian@forum.nginx.org>

Дима Редмайн Wrote:
-------------------------------------------------------
> Для начала напишите после каких действий появилась проблема.

выросла нагрузка на сервер в целом (добавили бэкэнд с "тяжелыми" расчетами).

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258068,258085#msg-258085


From chipitsine at gmail.com  Thu Apr 16 10:35:32 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 16 Apr 2015 15:35:32 +0500
Subject: PUT & access_by_lua_file
In-Reply-To: <11e84ec6b933b33c58b750c1be590c3e.NginxMailingListRussian@forum.nginx.org>
References: <014534d85ad822248eb6d66b3e6a868b.NginxMailingListRussian@forum.nginx.org>
 <11e84ec6b933b33c58b750c1be590c3e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQGQEWKwxq-sYsnjQ8PQd3p+mFv8z+fhF-MdGuP0-dL94Q@mail.gmail.com>

еще можно попробовать реализовать запрет PUT таким образом, что в
ответе на OPTIONS не показывать PUT

16 апреля 2015 г., 13:51 пользователь itcod <nginx-forum at nginx.us> написал:
> и на эту ситуацию ещё накладывается дефолтное поведение BitKinex
> автоматически повторять посылку файла при неудаче... а любой код возврата от
> PUT кроме успеха он считает неудачей, и многократно повторяет передачу....
> ну и передача в 600к при таком поведении превращается в 18мегов, 30 лишних
> сессий и в 30 раз больше времени...
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258070#msg-258070
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From chipitsine at gmail.com  Thu Apr 16 10:38:42 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 16 Apr 2015 15:38:42 +0500
Subject: =?UTF-8?B?UmU6INC+0LHRidC40Lkg0LrRjdGIINC00LvRjyDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0YUgbmdpbng=?=
In-Reply-To: <CA+ksgADHAEnJH2SDJG5=pnQcZSOUZaDBAgY=36CmnwjjYiae1Q@mail.gmail.com>
References: <CAHRZc-2aA3UmYju3iNk1ZbJYavHrU3kkrQQ5A+0b+zuEUz=s=Q@mail.gmail.com>
 <CACz2Q8FZmrysMOFhzOERmTgjt6v-HAAkgoTM8i3_2mCcU_K7oA@mail.gmail.com>
 <CA+ksgABe09UtjpEZbjAjKS0fPn44zzOGdYPVK4ZbVKtutyOkMg@mail.gmail.com>
 <3921110.3oMSEEtUKJ@vbart-laptop>
 <CA+ksgADHAEnJH2SDJG5=pnQcZSOUZaDBAgY=36CmnwjjYiae1Q@mail.gmail.com>
Message-ID: <CAFHpkQHx7Ga_CXih--q_GyM=XJKr-oSJs9zZkdyyOART_7imrA@mail.gmail.com>

расскажите более подробно, в каком формате вы хотите получить ответ на
ваш вопрос ? если можно с примерами

16 апреля 2015 г., 11:24 пользователь Иван Мишин
<simplebox66 at gmail.com> написал:
> Меня все же интересуют free варианты
>
> 15 апреля 2015 г., 20:01 пользователь Валентин Бартенев <vbart at nginx.com>
> написал:
>
>> On Wednesday 15 April 2015 15:06:08 Иван Мишин wrote:
>> > Всем привет!
>> > Меня тоже интересует идея общего кеша для нескольких nginx. При этом
>> > понравилась идея про оценку эффективности существующего кеша. Что бы
>> > точно
>> > понимать есть ли смысл в идеи общего кеша. А потому хотелось бы узнать,
>> > кто-то пробовал считать/оценивать эффективность кеша nginx? каким
>> > образом
>> > это можно сделать? Мне кроме тестирования с помощью ab ни чего в голову
>> > и
>> > не приходит, а  хотелось бы какой-то более серьезный расчет получить
>> [..]
>>
>> Проще всего эффективность кэша отслеживать в реальном времени в nginx plus
>> с помощью status-модуля:
>> http://nginx.org/ru/docs/http/ngx_http_status_module.html#caches
>>
>> Наглядно: http://demo.nginx.com/status.html#anchor-caches
>>
>> --
>> Валентин Бартенев
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Thu Apr 16 11:25:10 2015
From: nginx-forum at nginx.us (dwow)
Date: Thu, 16 Apr 2015 07:25:10 -0400
Subject: =?UTF-8?B?UmU6INCc0LXQtNC70LXQvdC90L4g0L7RgtC00LDRjtGC0YHRjyDQtNCw0L3QvdGL?=
 =?UTF-8?B?0LUg0LrQu9C40LXQvdGC0YM=?=
In-Reply-To: <beef2e8fc5c7aa885af39703d53e3c06.NginxMailingListRussian@forum.nginx.org>
References: <beef2e8fc5c7aa885af39703d53e3c06.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3ab53c90b264a49a50ff71a59f04e961.NginxMailingListRussian@forum.nginx.org>

В общем проблема найдена. До увеличения нагрузки был добавлен SSL (3 мес
назад и общую картину не изменил, на тот момент), но вместе с последними
добавлениями... стало заметно :)

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258068,258090#msg-258090


From gmm at csdoc.com  Thu Apr 16 13:34:48 2015
From: gmm at csdoc.com (Gena Makhomed)
Date: Thu, 16 Apr 2015 16:34:48 +0300
Subject: =?UTF-8?B?UmU6INCc0LXQtNC70LXQvdC90L4g0L7RgtC00LDRjtGC0YHRjyDQtNCw0L3QvdGL?=
 =?UTF-8?B?0LUg0LrQu9C40LXQvdGC0YM=?=
In-Reply-To: <3ab53c90b264a49a50ff71a59f04e961.NginxMailingListRussian@forum.nginx.org>
References: <beef2e8fc5c7aa885af39703d53e3c06.NginxMailingListRussian@forum.nginx.org>
 <3ab53c90b264a49a50ff71a59f04e961.NginxMailingListRussian@forum.nginx.org>
Message-ID: <552FBA78.3030808@csdoc.com>

On 16.04.2015 14:25, dwow wrote:

> В общем проблема найдена. До увеличения нагрузки был добавлен SSL (3 мес
> назад и общую картину не изменил, на тот момент), но вместе с последними
> добавлениями... стало заметно :)

если SSL тормозит - скорее всего не был включен ssl_session_cache:

http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache

включать его надо примерно так:

ssl_session_cache shared:SSL:10m;

еще больше ускорить отдачу контента клиенту поможет включение spdy:

http://nginx.org/en/docs/http/ngx_http_core_module.html#listen

только для этого надо будет использовать 1.7.12 версию nginx,
говорят что в 1.6.х есть какие-то глюки при работе с spdy.

-- 
Best regards,
  Gena


From bazilek at gmail.com  Thu Apr 16 15:48:20 2015
From: bazilek at gmail.com (Vasil Mikhalenya)
Date: Thu, 16 Apr 2015 17:48:20 +0200
Subject: nginx cache
In-Reply-To: <CAPc4iSDwx3hVzicPXcGWamp37JKrkHFJx0FcJwRaAJd3oB8MZw@mail.gmail.com>
References: <CAPc4iSD1bOSu6Uo_hcOXQ8PWZ=4V573pfh9mEnV1JGkSyrzHqA@mail.gmail.com>
 <CAPc4iSDwx3hVzicPXcGWamp37JKrkHFJx0FcJwRaAJd3oB8MZw@mail.gmail.com>
Message-ID: <CAPc4iSDp1hA1VPjko75Ku4Ps8V82OBy5Cjr4nKwJ90SKMPeu5g@mail.gmail.com>

возможно ли ограничить количество одновременно загружаемых файлов с
апстрима?

2015-04-16 11:40 GMT+02:00 Vasil Mikhalenya <bazilek at gmail.com>:

> ситуацию спасло добавление
>
> proxy_cache_lock_age 120s;
>
> однако из описания неясен смысл директивы proxy_cache_lock_timeout,
> кто-то может пояснить
>
> 2015-04-16 11:26 GMT+02:00 Vasil Mikhalenya <bazilek at gmail.com>:
>
>> Вопрос по кешированию,
>>
>> proxy_cache_path /var/lib/nginx/cache keys_zone=one:20m inactive=1d
>> use_temp_path=off;
>>
>> server {
>>     listen 80;
>>     server_name _;
>>
>>     proxy_cache one;
>>
>>     location / {
>>         proxy_pass http://origin.corp.com;
>>         proxy_set_header Host       $proxy_host;
>>         add_header Cache $upstream_cache_status;
>>     }
>> }
>>
>> приходит 10 запросов от клиентов, файла в кеше нет - создается 10 файлов
>> в cache temp dir
>>
>> -rw------- 1 nginx nginx 1988247552 Apr 16 09:19 0000000001
>> -rw------- 1 nginx nginx 1985142784 Apr 16 09:19 0000000003
>> -rw------- 1 nginx nginx 1547857920 Apr 16 09:19 0000000004
>> -rw------- 1 nginx nginx 1767833600 Apr 16 09:19 0000000006
>> -rw------- 1 nginx nginx 1144295424 Apr 16 09:19 0000000007
>> -rw------- 1 nginx nginx 1661476864 Apr 16 09:19 0000000008
>> -rw------- 1 nginx nginx 1252536320 Apr 16 09:19 0000000009
>> -rw------- 1 nginx nginx 1593856000 Apr 16 09:19 0000000010
>> -rw------- 1 nginx nginx 1242357760 Apr 16 09:19 0000000011
>> -rw------- 1 nginx nginx  902340608 Apr 16 09:19 0000000012
>> -rw------- 1 nginx nginx  872054784 Apr 16 09:19 0000000013
>>
>> Когда проходит 100 запросов - файл не выкачается и не закешируется
>> никогда т.к. канал будет полностью заполнен.
>>
>> nginx version: nginx/1.7.10
>>
>> Nginx действительно так работает, или я что-то упустил ?
>>
>>
>> --
>> Best regards,
>> Vasil Mikhalenya
>>
>
>
>
> --
> Best regards,
> Vasil Mikhalenya
>



-- 
Best regards,
Vasil Mikhalenya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150416/67288477/attachment.html>

From nginx-forum at nginx.us  Thu Apr 16 15:52:18 2015
From: nginx-forum at nginx.us (RavilK)
Date: Thu, 16 Apr 2015 11:52:18 -0400
Subject: =?UTF-8?B?0JrQsNC6INC90LDRgdGC0YDQvtC40YLRjCDRgNC10LTQuNGA0LXQutGCIHd3dywg?=
 =?UTF-8?B?aHR0cCwgaHR0cHMg0LzQtdC20LTRgyDRgNCw0LfQvdGL0LzQuCDQtNC+0Lw=?=
 =?UTF-8?B?0LXQvdCw0LzQuA==?=
Message-ID: <320424a29fd6aefa3d24f168e6548f55.NginxMailingListRussian@forum.nginx.org>

Добрый день уважаемые формучане!
С nginx, apache ранее не приходилось сталкиваться. Поэтому учту все
замечания)))
Имеетя связка nginx + apache. nginx в качестве проски для апача.
Домен второго уровня site.com
Уже имеются рабочие 2 vhost'а - site.som, web.site.com 
Все хосты привязаны к https, ssl сертификат соответственно используется один
на домен *site.com
Запросы с www,http  на site.com и web.site.com  упешно перенаправлются на
https://site.com и https://web.site.com соответсвенно. 
Два хоста site.com b web.site.com ранее были настроены специалистом компаний
интегратора
Все крутится на одном сервере
Несколько дней назад была поставлена задача развернуть новый vhost который
будет именоваться далее - club.site.com
Вот теперь самое интересное:
Руководство купило доменное имя clubsite.com, именно clubsite.com))объяснив
это тем, что, если клиент по ошибке набирает в браузере www.clubsite.com или
просто clubsite.com,
запрос должен быть перенаправлен на https://club.site.com
Я по аналогий рабочих конфигов site.com  и web.site com настроил vhost в
апач и nginx.
Для проверки посал запросы в виде www.club.site.com, http://club.site.com ,
редирект на https://club.site.com отработал нормально.
А как настроить такой же редирект с домена clubsite.com в nginx:

www.clubsite.com  ----> club.site.com
http://clubsite.com  -----> club.site.com

Однако, я заметил одну непонятную вещь, все запросы с домена  clubsite.com 
уже перенаправляются, только совсем на другой хост:

www.clubsite.kg  ---> web.site.com
clubsite.com ---> web.clubsite


Вот конфиг файлы vhost в apache и конфиг файла в nginx -->

1) /apache/sites-available/club.site.conf

<VirtualHost *:8083>
   ServerName club.site.com 
   ServerAlias www.club.site.com
   DocumentRoot /var/www/club.site.com/
       <Directory "/var/www/club.site.com /">
               Options Indexes FollowSymLinks MultiViews
               AllowOverride All
               Order allow,deny
               Allow from all
       </Directory>
       ErrorLog ${APACHE_LOG_DIR}/error.log
       RewriteEngine on
       # Possible values include: debug, info, notice, warn, error, crit,
       # alert, emerg.
       LogLevel warn
       CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>


2) /nginx/sites-enables/club.site.conf

server {
  listen 80;
   server_name www.club.site.com club.site.com clubsite.com
www.clubsite.com; 
   return 301 https://$server_name$request_uri;
}

server {
  listen 443;
    server_name www.club.site.com www.clubsite.com clubsite.com
club.site.com;        
    ssl on;
    ssl_certificate /etc/nginx/ssl/certs/site.com.crt;
    ssl_certificate_key /etc/nginx/ssl/private/site.com.key;

location / {
     proxy_temp_path  /tmp/nginx_proxy/;
     proxy_pass http://127.0.0.1:8083; 
     proxy_set_header   Host $host;
     proxy_set_header   X-Real-IP $remote_addr;
     proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header   X-Forwarded-Proto $scheme;
}
     location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|swf|txt|pdf|zip)$ {
     root /var/www/club.site.com/;
     }

Теперь сам вопрос господа
Как настроить такое вот  перенаправление с www.clubsite.com и
http://clubsite.com на https://club.site.com

Заранее спасибо!

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258108,258108#msg-258108


From nginx-forum at nginx.us  Thu Apr 16 16:23:49 2015
From: nginx-forum at nginx.us (dwow)
Date: Thu, 16 Apr 2015 12:23:49 -0400
Subject: =?UTF-8?B?UmU6INCc0LXQtNC70LXQvdC90L4g0L7RgtC00LDRjtGC0YHRjyDQtNCw0L3QvdGL?=
 =?UTF-8?B?0LUg0LrQu9C40LXQvdGC0YM=?=
In-Reply-To: <552FBA78.3030808@csdoc.com>
References: <552FBA78.3030808@csdoc.com>
Message-ID: <deecdd5bc236f16a052c93ed08a1c38c.NginxMailingListRussian@forum.nginx.org>

Gena Makhomed Wrote:
-------------------------------------------------------
> если SSL тормозит - скорее всего не был включен ssl_session_cache:
> 
> http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cac
> he
> 
> включать его надо примерно так:
> 
> ssl_session_cache shared:SSL:10m;
> 
> еще больше ускорить отдачу контента клиенту поможет включение spdy:
> 
> http://nginx.org/en/docs/http/ngx_http_core_module.html#listen
> 
> только для этого надо будет использовать 1.7.12 версию nginx,
> говорят что в 1.6.х есть какие-то глюки при работе с spdy.
> 

Все базовые настройки оптимизации были сделаны. Ветка 1.7.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258068,258110#msg-258110


From nginx-forum at nginx.us  Thu Apr 16 16:27:24 2015
From: nginx-forum at nginx.us (dwow)
Date: Thu, 16 Apr 2015 12:27:24 -0400
Subject: reset_timedout_connection
Message-ID: <c6eb4bd2c1274c3c691631b4663c6a17.NginxMailingListRussian@forum.nginx.org>

Добрый вечер,

"Разрешает или запрещает сброс соединений по таймауту. ..."
http://nginx.org/ru/docs/http/ngx_http_core_module.html#reset_timedout_connection

по какому таймауту? какая переменная регулирует этот таймаут?

Спасибо.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258111,258111#msg-258111


From mdounin at mdounin.ru  Thu Apr 16 16:36:04 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 16 Apr 2015 19:36:04 +0300
Subject: reset_timedout_connection
In-Reply-To: <c6eb4bd2c1274c3c691631b4663c6a17.NginxMailingListRussian@forum.nginx.org>
References: <c6eb4bd2c1274c3c691631b4663c6a17.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150416163604.GB88631@mdounin.ru>

Hello!

On Thu, Apr 16, 2015 at 12:27:24PM -0400, dwow wrote:

> Добрый вечер,
> 
> "Разрешает или запрещает сброс соединений по таймауту. ..."
> http://nginx.org/ru/docs/http/ngx_http_core_module.html#reset_timedout_connection
> 
> по какому таймауту? какая переменная регулирует этот таймаут?

По любому таймауту общения с клиентом.
В частности, это:

http://nginx.org/ru/docs/http/ngx_http_core_module.html#send_timeout
http://nginx.org/ru/docs/http/ngx_http_core_module.html#client_header_timeout
http://nginx.org/ru/docs/http/ngx_http_core_module.html#client_body_timeout

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Thu Apr 16 16:40:47 2015
From: nginx-forum at nginx.us (dwow)
Date: Thu, 16 Apr 2015 12:40:47 -0400
Subject: reset_timedout_connection
In-Reply-To: <20150416163604.GB88631@mdounin.ru>
References: <20150416163604.GB88631@mdounin.ru>
Message-ID: <21436f58222adfcb196a7399ce9acc18.NginxMailingListRussian@forum.nginx.org>

Ага, спасибо.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258111,258114#msg-258114


From nginx-forum at nginx.us  Thu Apr 16 18:47:00 2015
From: nginx-forum at nginx.us (itcod)
Date: Thu, 16 Apr 2015 14:47:00 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <CAFHpkQGQEWKwxq-sYsnjQ8PQd3p+mFv8z+fhF-MdGuP0-dL94Q@mail.gmail.com>
References: <CAFHpkQGQEWKwxq-sYsnjQ8PQd3p+mFv8z+fhF-MdGuP0-dL94Q@mail.gmail.com>
Message-ID: <5252b19aa7559ff603921151947c4395.NginxMailingListRussian@forum.nginx.org>

Илья добрый день!
>>еще можно попробовать реализовать запрет PUT таким образом, что в
ответе на OPTIONS не показывать PUT

А тут мы упираемся в корректность реализации клиента WEBDAV о которой нам
ничего не известно... не особо хочется "наслово" полагаться на соответствие
всех возможных webdav клиентов букве стандарта....

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258118#msg-258118


From nginx-forum at nginx.us  Thu Apr 16 18:56:09 2015
From: nginx-forum at nginx.us (itcod)
Date: Thu, 16 Apr 2015 14:56:09 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <CAFHpkQEeLUP2mcTtX7K5SuwW8NbZ4pSob2JUyVM=FnMpc7UVZA@mail.gmail.com>
References: <CAFHpkQEeLUP2mcTtX7K5SuwW8NbZ4pSob2JUyVM=FnMpc7UVZA@mail.gmail.com>
Message-ID: <cff961a9564fe742acbeef2621bff7c9.NginxMailingListRussian@forum.nginx.org>

Илья добрый вечер!
>> чтобы ответить до начала передачи файла, надо реализовать "Expect:
100-Continue"

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

и получаем что вариант Expect: 100-Continue возможен только в сети идеальных
законопослушников:))))

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

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258119#msg-258119


From nginx-forum at nginx.us  Thu Apr 16 21:35:04 2015
From: nginx-forum at nginx.us (itcod)
Date: Thu, 16 Apr 2015 17:35:04 -0400
Subject: =?UTF-8?B?UmU6INCU0LjQvdCw0LzQuNGH0L3QvtC1INCy0YDQtdC80Y8gdGltZW91dA==?=
In-Reply-To: <f2bdec8b4fbe7f8f18636d4ba83e57a0.NginxMailingListRussian@forum.nginx.org>
References: <f2bdec8b4fbe7f8f18636d4ba83e57a0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <cb7444cd820346033a8d2157288568cd.NginxMailingListRussian@forum.nginx.org>

а интересно.... proxy_* в if завернуть можно?.... проверь....
конечно это не динамическое будет, а одна ступенька... 
но если сработает... то костыль на время необходимости сгодится...

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,257773,258127#msg-258127


From gmm at csdoc.com  Thu Apr 16 21:41:17 2015
From: gmm at csdoc.com (Gena Makhomed)
Date: Fri, 17 Apr 2015 00:41:17 +0300
Subject: =?UTF-8?B?UmU6INCU0LjQvdCw0LzQuNGH0L3QvtC1INCy0YDQtdC80Y8gdGltZW91dA==?=
In-Reply-To: <f2bdec8b4fbe7f8f18636d4ba83e57a0.NginxMailingListRussian@forum.nginx.org>
References: <f2bdec8b4fbe7f8f18636d4ba83e57a0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <55302C7D.50104@csdoc.com>

On 31.03.2015 14:36, d.v.biryukov wrote:

> народ, подскажите, может кто знает
> пытаюсь сделать такой трюк
>
> map $remote_addr $timeoutlimit {
> default 900;
> 127.0.0.1 1900;
> }
>
> proxy_connect_timeout·······$timeoutlimit;
> proxy_send_timeout······$timeoutlimit;
> proxy_read_timeout······$timeoutlimit;
>
> но зараза ругается...
> не комильфо говорит юзать переменную в proxy_connect_timeout и им подобным
> (((
>
> как бы поступить? есть идеи?
>
> мне с одного хоста надо таймауты бы увеличить так как там обмен происходит и
> он обрывается по 504 timeout (

сделать два блока server {...} - один для всех клиентов,
второй - для этого одного хоста (с другим server_name).

-- 
Best regards,
  Gena


From vbart at nginx.com  Thu Apr 16 23:27:00 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 17 Apr 2015 02:27 +0300
Subject: nginx cache
In-Reply-To: <CAPc4iSDp1hA1VPjko75Ku4Ps8V82OBy5Cjr4nKwJ90SKMPeu5g@mail.gmail.com>
References: <CAPc4iSD1bOSu6Uo_hcOXQ8PWZ=4V573pfh9mEnV1JGkSyrzHqA@mail.gmail.com>
 <CAPc4iSDwx3hVzicPXcGWamp37JKrkHFJx0FcJwRaAJd3oB8MZw@mail.gmail.com>
 <CAPc4iSDp1hA1VPjko75Ku4Ps8V82OBy5Cjr4nKwJ90SKMPeu5g@mail.gmail.com>
Message-ID: <2117741.WdtaKZC1TT@vbart-laptop>

On Thursday 16 April 2015 17:48:20 Vasil Mikhalenya wrote:
> возможно ли ограничить количество одновременно загружаемых файлов с
> апстрима?
> 
[..]

http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html

--
Валентин Бартенев

From chipitsine at gmail.com  Fri Apr 17 03:23:59 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 17 Apr 2015 08:23:59 +0500
Subject: PUT & access_by_lua_file
In-Reply-To: <5252b19aa7559ff603921151947c4395.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQGQEWKwxq-sYsnjQ8PQd3p+mFv8z+fhF-MdGuP0-dL94Q@mail.gmail.com>
 <5252b19aa7559ff603921151947c4395.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQEtj9FeOXpvpxqPLdH4dLOOcztozJU9k4fG4UoLiadijQ@mail.gmail.com>

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

16 апреля 2015 г., 23:47 пользователь itcod <nginx-forum at nginx.us> написал:
> Илья добрый день!
>>>еще можно попробовать реализовать запрет PUT таким образом, что в
> ответе на OPTIONS не показывать PUT
>
> А тут мы упираемся в корректность реализации клиента WEBDAV о которой нам
> ничего не известно... не особо хочется "наслово" полагаться на соответствие
> всех возможных webdav клиентов букве стандарта....
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258118#msg-258118
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From simplebox66 at gmail.com  Fri Apr 17 05:59:22 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Fri, 17 Apr 2015 08:59:22 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCw0YHRgtGA0L7QuNGC0Ywg0YDQtdC00LjRgNC10LrRgiB3?=
 =?UTF-8?B?d3csIGh0dHAsIGh0dHBzINC80LXQttC00YMg0YDQsNC30L3Ri9C80Lgg0LQ=?=
 =?UTF-8?B?0L7QvNC10L3QsNC80Lg=?=
In-Reply-To: <320424a29fd6aefa3d24f168e6548f55.NginxMailingListRussian@forum.nginx.org>
References: <320424a29fd6aefa3d24f168e6548f55.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CA+ksgAAb=Q8jihy9iXW03emHM8gS=GzsVWLLkX77A=qu=AdszA@mail.gmail.com>

Предположу, что надо сделать вот так:
 это
>
> server {
>   listen 80;
>    server_name www.club.site.com club.site.com clubsite.com
> www.clubsite.com;
>    return 301 https://$server_name$request_uri;
> }


надо заменить на
server {
  listen 80;
   server_name www.club.site.com club.site.com clubsite.com
www.clubsite.com;
   return 301 https://club.site.com$request_uri;
}

16 апреля 2015 г., 18:52 пользователь RavilK <nginx-forum at nginx.us> написал:

> Добрый день уважаемые формучане!
> С nginx, apache ранее не приходилось сталкиваться. Поэтому учту все
> замечания)))
> Имеетя связка nginx + apache. nginx в качестве проски для апача.
> Домен второго уровня site.com
> Уже имеются рабочие 2 vhost'а - site.som, web.site.com
> Все хосты привязаны к https, ssl сертификат соответственно используется
> один
> на домен *site.com
> Запросы с www,http  на site.com и web.site.com  упешно перенаправлются на
> https://site.com и https://web.site.com соответсвенно.
> Два хоста site.com b web.site.com ранее были настроены специалистом
> компаний
> интегратора
> Все крутится на одном сервере
> Несколько дней назад была поставлена задача развернуть новый vhost который
> будет именоваться далее - club.site.com
> Вот теперь самое интересное:
> Руководство купило доменное имя clubsite.com, именно clubsite.com
> ))объяснив
> это тем, что, если клиент по ошибке набирает в браузере www.clubsite.com
> или
> просто clubsite.com,
> запрос должен быть перенаправлен на https://club.site.com
> Я по аналогий рабочих конфигов site.com  и web.site com настроил vhost в
> апач и nginx.
> Для проверки посал запросы в виде www.club.site.com, http://club.site.com
> ,
> редирект на https://club.site.com отработал нормально.
> А как настроить такой же редирект с домена clubsite.com в nginx:
>
> www.clubsite.com  ----> club.site.com
> http://clubsite.com  -----> club.site.com
>
> Однако, я заметил одну непонятную вещь, все запросы с домена  clubsite.com
> уже перенаправляются, только совсем на другой хост:
>
> www.clubsite.kg  ---> web.site.com
> clubsite.com ---> web.clubsite
>
>
> Вот конфиг файлы vhost в apache и конфиг файла в nginx -->
>
> 1) /apache/sites-available/club.site.conf
>
> <VirtualHost *:8083>
>    ServerName club.site.com
>    ServerAlias www.club.site.com
>    DocumentRoot /var/www/club.site.com/
>        <Directory "/var/www/club.site.com /">
>                Options Indexes FollowSymLinks MultiViews
>                AllowOverride All
>                Order allow,deny
>                Allow from all
>        </Directory>
>        ErrorLog ${APACHE_LOG_DIR}/error.log
>        RewriteEngine on
>        # Possible values include: debug, info, notice, warn, error, crit,
>        # alert, emerg.
>        LogLevel warn
>        CustomLog ${APACHE_LOG_DIR}/access.log combined
> </VirtualHost>
>
>
> 2) /nginx/sites-enables/club.site.conf
>
> server {
>   listen 80;
>    server_name www.club.site.com club.site.com clubsite.com
> www.clubsite.com;
>    return 301 https://$server_name$request_uri;
> }
>
> server {
>   listen 443;
>     server_name www.club.site.com www.clubsite.com clubsite.com
> club.site.com;
>     ssl on;
>     ssl_certificate /etc/nginx/ssl/certs/site.com.crt;
>     ssl_certificate_key /etc/nginx/ssl/private/site.com.key;
>
> location / {
>      proxy_temp_path  /tmp/nginx_proxy/;
>      proxy_pass http://127.0.0.1:8083;
>      proxy_set_header   Host $host;
>      proxy_set_header   X-Real-IP $remote_addr;
>      proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
>      proxy_set_header   X-Forwarded-Proto $scheme;
> }
>      location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|swf|txt|pdf|zip)$ {
>      root /var/www/club.site.com/;
>      }
>
> Теперь сам вопрос господа
> Как настроить такое вот  перенаправление с www.clubsite.com и
> http://clubsite.com на https://club.site.com
>
> Заранее спасибо!
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,258108,258108#msg-258108
>
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150417/2ffb8e9f/attachment-0001.html>

From nginx-forum at nginx.us  Fri Apr 17 06:07:33 2015
From: nginx-forum at nginx.us (itcod)
Date: Fri, 17 Apr 2015 02:07:33 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <CAFHpkQEtj9FeOXpvpxqPLdH4dLOOcztozJU9k4fG4UoLiadijQ@mail.gmail.com>
References: <CAFHpkQEtj9FeOXpvpxqPLdH4dLOOcztozJU9k4fG4UoLiadijQ@mail.gmail.com>
Message-ID: <9d632e2886020cbd3ec5abe23dcba5de.NginxMailingListRussian@forum.nginx.org>

Илья добрый день!
>>вы сами клиенту сказали, что поддерживаете PUT, он делает PUT, вы его
фейлите.
прикиньте, как клиент расстраивается от такого расклада ))

Это спорный вопрос расстраивается или просто некоректна логика обработки
ответов от сервера в данной точке программы клиента:) Если бы nginx сразу на
PUT ответил 405 (Method Not Allowed), то все некорректности по обработке
кода ответа можно было бы свалить на клиента, и оповестить их разработчика.

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

Запросы методом OPTIONS при PUT:
BitKinex - не использует
FAR-NetDrive - использует

Даже тут чехарда. Да я буду пытаться сказать клиентам, что использовать
можно, а что нельзя...
Только это imho косметический костыль. Так как тот кто специально решит
проигнорировать рекомендации сервера (я имею в виду если кому захочется
положить сервер), он всегда сможет выполнить, то что я обнаружил. А это imho
с точки зрения надёжности nginx большой минус. Да и я сам делая самописный
WebDAV клиент ориентировался бы больше на обаботку ответов и уже во втором
эшелоне на рекомендации сервера.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258134#msg-258134


From mva at mva.name  Fri Apr 17 06:13:54 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Fri, 17 Apr 2015 12:13:54 +0600
Subject: PUT & access_by_lua_file
In-Reply-To: <9d632e2886020cbd3ec5abe23dcba5de.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQEtj9FeOXpvpxqPLdH4dLOOcztozJU9k4fG4UoLiadijQ@mail.gmail.com>
 <9d632e2886020cbd3ec5abe23dcba5de.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3964477.SGZ0HDHBzX@note>

В письме от Пт, 17 апреля 2015 02:07:33 пользователь itcod написал:
> Илья добрый день!
> 
> >>вы сами клиенту сказали, что поддерживаете PUT, он делает PUT, вы его
> 
> фейлите.
> прикиньте, как клиент расстраивается от такого расклада ))
> 
> Это спорный вопрос расстраивается или просто некоректна логика обработки
> ответов от сервера в данной точке программы клиента:) Если бы nginx сразу на
> PUT ответил 405 (Method Not Allowed), то все некорректности по обработке
> кода ответа можно было бы свалить на клиента, и оповестить их разработчика.
> 

Дело в том, что, на сколько я понил проблему при описании с ваших слов, со 
стороны NginX всё корректно. На PUT он отвечает "нельзя" сразу по получении 
(т.е. по окончании) *запроса*.
А отвечать "нельзя" по получении одного лишь заголовка, не дожидаясь тела ? 
неправильно.

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150417/84508e21/attachment.bin>

From nginx-forum at nginx.us  Fri Apr 17 06:50:14 2015
From: nginx-forum at nginx.us (itcod)
Date: Fri, 17 Apr 2015 02:50:14 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <3964477.SGZ0HDHBzX@note>
References: <3964477.SGZ0HDHBzX@note>
Message-ID: <9774c422c1fe769185f23d8b628785bd.NginxMailingListRussian@forum.nginx.org>

mva добрый день!
>>На PUT он отвечает "нельзя" сразу по получении (т.е. по окончании)
*запроса*.
Да. вы описываете ситуацию верно... как я её вижу.

1. получение nginx'ом заголовка сообщения
2. получение тела сообщения
[... lua ...] -> 405

>> А отвечать "нельзя" по получении одного лишь заголовка, не дожидаясь тела
?
неправильно.

Если не затруднит обоснуйте плиззз свою точку зрения.

Моя такова:
Если метод запрещён внутри (и не важно знает об этом клиент или нет), то
можно и даже нужно обрывать соединение и вернуть код 405!. Зачем нам
получать огромное тело сообщения, если мы не обрабатываем этот метод и не
будем обрабатывать тело.

Пример:
Инициирую 1000-10000 сессий, игнорирую рекомендации nginx в OPTION и Origin,
и каждая сессия инициирует PUT video.mp4 размером скажем 4G. С большой долей
вероятности положу атакуемый сервер. А даже если не положу, то заспамлю и
загружу холостой работой.

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

И отсуда вытекает.... вопрос к разработчикам о внутренностях nginx.....
существует ли возможность реализовать запуск выполнения авторизатора на lua
между двумя этапами обработки.

1. получение nginx'ом заголовка сообщения
[... lua ...] ->405
2. УЖЕ НЕ! получаем тела сообщения

Или существуют ещё какие либо более простые методы решения.....

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258136#msg-258136


From nginx-forum at nginx.us  Fri Apr 17 07:03:19 2015
From: nginx-forum at nginx.us (itcod)
Date: Fri, 17 Apr 2015 03:03:19 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <014534d85ad822248eb6d66b3e6a868b.NginxMailingListRussian@forum.nginx.org>
References: <014534d85ad822248eb6d66b3e6a868b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <a4702d38c83755d89da056ddd162a22e.NginxMailingListRussian@forum.nginx.org>

PS: У меня дежавю..... прецедент вспомнился.... подобная тема обсуждалась в
годах 1995 в fido-конференции по ifcico. Актуальность подобных холостых
передач там была очень высокая, из за ограниченного кол-ва каналов передачи,
их низких скоростей и высокой стоимости.. как результат реализовали обрыв
подобных сессий для предотвращения излишних затрат и освобождения линий.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258137#msg-258137


From nginx-forum at nginx.us  Fri Apr 17 07:37:41 2015
From: nginx-forum at nginx.us (RavilK)
Date: Fri, 17 Apr 2015 03:37:41 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCw0YHRgtGA0L7QuNGC0Ywg0YDQtdC00LjRgNC10LrRgiB3?=
 =?UTF-8?B?d3csIGh0dHAsIGh0dHBzINC80LXQttC00YMg0YDQsNC30L3Ri9C80Lgg0LQ=?=
 =?UTF-8?B?0L7QvNC10L3QsNC80Lg=?=
In-Reply-To: <CA+ksgAAb=Q8jihy9iXW03emHM8gS=GzsVWLLkX77A=qu=AdszA@mail.gmail.com>
References: <CA+ksgAAb=Q8jihy9iXW03emHM8gS=GzsVWLLkX77A=qu=AdszA@mail.gmail.com>
Message-ID: <3bf8d4be8b51335629da6da2c48bbd1a.NginxMailingListRussian@forum.nginx.org>

Михаил спасибо за ваш ответ.
Но к сожалению ничего не изменилось(
Как последний вариант убрать редирект через nginx и настроить его через
 htaccess

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258108,258139#msg-258139


From nginx-forum at nginx.us  Fri Apr 17 10:06:49 2015
From: nginx-forum at nginx.us (dwow)
Date: Fri, 17 Apr 2015 06:06:49 -0400
Subject: =?UTF-8?B?bGltaXQgY29ubiDRgdGH0LXRgtGH0LjQuiDQv9C10YDQtdC/0L7Qu9C90LXQvdC4?=
 =?UTF-8?B?0LU=?=
Message-ID: <e09672a1b97c3788904f4f195960eec1.NginxMailingListRussian@forum.nginx.org>

Добрый день.

Была задача ограничить кол-во запросов к бэкенду. Например, чтобы
одновременно не поступало более 1 запроса. Остальные запросы, пока работает
бэкенд, могли отваливаться по ошибке, это не страшно.
С помощью Perl я устанавливал переменную, которая показывала идет ли запрос
для проксирования на бэкенд или нет. И эту переменную использовал в качестве
ключа для
http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html#limit_conn_zone

perl_set $service_hit '
        sub {
            my $r = shift;
            if($r->uri =~ m|^/services/post|){
                return "services";
            } else {
                return "";
            }
        }
';
limit_conn_zone "$service_hit" zone=perservice:10m;

Потом перед проксированием на бэкенд (в location) использовал ограничениие
http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html#limit_conn

limit_conn perservice 1;

Все отлично работает, но только первые 30-60 минут, потом nginx для всех
запросов возвращает 503 ошибку, т.е. счетчик не сбрасывается. Если
остановить-запустить nginx, то опять какое-то время все работает корректно.
В чем может быть проблема?

Спасибо.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258140,258140#msg-258140


From mva at mva.name  Fri Apr 17 10:30:31 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Fri, 17 Apr 2015 16:30:31 +0600
Subject: PUT & access_by_lua_file
In-Reply-To: <9774c422c1fe769185f23d8b628785bd.NginxMailingListRussian@forum.nginx.org>
References: <3964477.SGZ0HDHBzX@note>
 <9774c422c1fe769185f23d8b628785bd.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1661836.OgkSjrkJir@note>

А вы, всё-таки, ответьте, пожалуйста, на вопрос, почему вы не хотите убрать 
PUT из OPTIONS? ;)
-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150417/9ecb6886/attachment.bin>

From mva at mva.name  Fri Apr 17 10:43:13 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Fri, 17 Apr 2015 16:43:13 +0600
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCw0YHRgtGA0L7QuNGC0Ywg0YDQtdC00LjRgNC10LrRgiB3?=
 =?UTF-8?B?d3csIGh0dHAsIGh0dHBzINC80LXQttC00YMg0YDQsNC30L3Ri9C80Lgg0LQ=?=
 =?UTF-8?B?0L7QvNC10L3QsNC80Lg=?=
In-Reply-To: <3bf8d4be8b51335629da6da2c48bbd1a.NginxMailingListRussian@forum.nginx.org>
References: <CA+ksgAAb=Q8jihy9iXW03emHM8gS=GzsVWLLkX77A=qu=AdszA@mail.gmail.com>
 <3bf8d4be8b51335629da6da2c48bbd1a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2180060.cikfNM6Asz@note>

В письме от Пт, 17 апреля 2015 03:37:41 пользователь RavilK написал:
> Михаил спасибо за ваш ответ.
> Но к сожалению ничего не изменилось(
А Вы точно перезагружали NginX?
И, если на сервере вместо операционной систмы Debian или RH/копейка (не уверен 
на счёт RHEL/CentOS, но там тоже могли извратиться с conf.avail), то точно ли 
конфиг вируального хоста загружается NginX'ом? :)

> Как последний вариант убрать редирект через nginx и настроить его через
>  htaccess
А зачем вам тогда NginX, если вы всё делаете на Apache? ;)



// вообще, я бы спросил зачем вам вообще Apache как таковой, но это будет уже 
холиваром :)


-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150417/566cc88e/attachment-0001.bin>

From chipitsine at gmail.com  Fri Apr 17 11:10:09 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 17 Apr 2015 16:10:09 +0500
Subject: PUT & access_by_lua_file
In-Reply-To: <3964477.SGZ0HDHBzX@note>
References: <CAFHpkQEtj9FeOXpvpxqPLdH4dLOOcztozJU9k4fG4UoLiadijQ@mail.gmail.com>
 <9d632e2886020cbd3ec5abe23dcba5de.NginxMailingListRussian@forum.nginx.org>
 <3964477.SGZ0HDHBzX@note>
Message-ID: <CAFHpkQGVQL2hh2fj=6rQJKLqnEwuNNLhwxzM-jDNtAH3EMmg1A@mail.gmail.com>

если клиент говорит "Expect: 100-Continue", то в этом случае вы можете
ему сказать 405 сразу (или ответить 100-м кодом).
без этого хедера - да, ответить можно, только получив запрос полностью

17 апреля 2015 г., 11:13 пользователь Vadim A. Misbakh-Soloviov
<mva at mva.name> написал:
> В письме от Пт, 17 апреля 2015 02:07:33 пользователь itcod написал:
>> Илья добрый день!
>>
>> >>вы сами клиенту сказали, что поддерживаете PUT, он делает PUT, вы его
>>
>> фейлите.
>> прикиньте, как клиент расстраивается от такого расклада ))
>>
>> Это спорный вопрос расстраивается или просто некоректна логика обработки
>> ответов от сервера в данной точке программы клиента:) Если бы nginx сразу на
>> PUT ответил 405 (Method Not Allowed), то все некорректности по обработке
>> кода ответа можно было бы свалить на клиента, и оповестить их разработчика.
>>
>
> Дело в том, что, на сколько я понил проблему при описании с ваших слов, со
> стороны NginX всё корректно. На PUT он отвечает "нельзя" сразу по получении
> (т.е. по окончании) *запроса*.
> А отвечать "нельзя" по получении одного лишь заголовка, не дожидаясь тела ?
> неправильно.
>
> --
> Best regards,
> mva
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From simplebox66 at gmail.com  Fri Apr 17 11:10:58 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Fri, 17 Apr 2015 14:10:58 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCw0YHRgtGA0L7QuNGC0Ywg0YDQtdC00LjRgNC10LrRgiB3?=
 =?UTF-8?B?d3csIGh0dHAsIGh0dHBzINC80LXQttC00YMg0YDQsNC30L3Ri9C80Lgg0LQ=?=
 =?UTF-8?B?0L7QvNC10L3QsNC80Lg=?=
In-Reply-To: <2180060.cikfNM6Asz@note>
References: <CA+ksgAAb=Q8jihy9iXW03emHM8gS=GzsVWLLkX77A=qu=AdszA@mail.gmail.com>
 <3bf8d4be8b51335629da6da2c48bbd1a.NginxMailingListRussian@forum.nginx.org>
 <2180060.cikfNM6Asz@note>
Message-ID: <CA+ksgACOPcbazeu8e5HYUoF2H7E3pnShifeLJOAu=TrRhqR74A@mail.gmail.com>

>
> Михаил спасибо за ваш ответ.
> Но к сожалению ничего не изменилось(
> Как последний вариант убрать редирект через nginx и настроить его через
>  htaccess


 Я Иван, а не Михаил )

Раз уж совсем ничего не изменилось, то предполагаю что вы nginx не
релоудили )

17 апреля 2015 г., 13:43 пользователь Vadim A. Misbakh-Soloviov <
mva at mva.name> написал:

> В письме от Пт, 17 апреля 2015 03:37:41 пользователь RavilK написал:
> > Михаил спасибо за ваш ответ.
> > Но к сожалению ничего не изменилось(
> А Вы точно перезагружали NginX?
> И, если на сервере вместо операционной систмы Debian или RH/копейка (не
> уверен
> на счёт RHEL/CentOS, но там тоже могли извратиться с conf.avail), то точно
> ли
> конфиг вируального хоста загружается NginX'ом? :)
>
> > Как последний вариант убрать редирект через nginx и настроить его через
> >  htaccess
> А зачем вам тогда NginX, если вы всё делаете на Apache? ;)
>
>
>
> // вообще, я бы спросил зачем вам вообще Apache как таковой, но это будет
> уже
> холиваром :)
>
>
> --
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150417/5cd4a7ae/attachment.html>

From nginx-forum at nginx.us  Fri Apr 17 11:56:11 2015
From: nginx-forum at nginx.us (RavilK)
Date: Fri, 17 Apr 2015 07:56:11 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCw0YHRgtGA0L7QuNGC0Ywg0YDQtdC00LjRgNC10LrRgiB3?=
 =?UTF-8?B?d3csIGh0dHAsIGh0dHBzINC80LXQttC00YMg0YDQsNC30L3Ri9C80Lgg0LQ=?=
 =?UTF-8?B?0L7QvNC10L3QsNC80Lg=?=
In-Reply-To: <CA+ksgACOPcbazeu8e5HYUoF2H7E3pnShifeLJOAu=TrRhqR74A@mail.gmail.com>
References: <CA+ksgACOPcbazeu8e5HYUoF2H7E3pnShifeLJOAu=TrRhqR74A@mail.gmail.com>
Message-ID: <78385bda64e8d3c2ab049bb04a86e440.NginxMailingListRussian@forum.nginx.org>

Прошу прощения Иван!
Спасибо ща помощь!

Я пробовал уже и такое:

server {
  listen 80;
   server_name www.club.site.com clubsite.com www.clubsite.com; 
   return 301 https://club.site.com$request_uri;
}

и в .htaccess 
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

и такое

RewriteCond %{HTTP_HOST} ^www.clubsite.com$ [NC,OR]
RewriteCond %{HTTP_HOST} ^clubsite.com$ [NC]
RewriteRule (.*) https://club.site.com/$1 [R=301,L]

Еще раз просмотрел все конфиг файлы и не нашел где наcтроенно
перенаправление c www.clubsite.com и www.club.site.com  на web.site.com
 Где может быть еще трабл?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258108,258145#msg-258145


From simplebox66 at gmail.com  Fri Apr 17 12:00:44 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Fri, 17 Apr 2015 15:00:44 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCw0YHRgtGA0L7QuNGC0Ywg0YDQtdC00LjRgNC10LrRgiB3?=
 =?UTF-8?B?d3csIGh0dHAsIGh0dHBzINC80LXQttC00YMg0YDQsNC30L3Ri9C80Lgg0LQ=?=
 =?UTF-8?B?0L7QvNC10L3QsNC80Lg=?=
In-Reply-To: <78385bda64e8d3c2ab049bb04a86e440.NginxMailingListRussian@forum.nginx.org>
References: <CA+ksgACOPcbazeu8e5HYUoF2H7E3pnShifeLJOAu=TrRhqR74A@mail.gmail.com>
 <78385bda64e8d3c2ab049bb04a86e440.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CA+ksgACsfyk04mRS6WyevVZNpJ_ojKqPW3ULB68Rmm5_ArWKTw@mail.gmail.com>

Вы выложили полный конфиг nginx ? если нет то выкладывайте целиком, все
локейшены

17 апреля 2015 г., 14:56 пользователь RavilK <nginx-forum at nginx.us> написал:

> Прошу прощения Иван!
> Спасибо ща помощь!
>
> Я пробовал уже и такое:
>
> server {
>   listen 80;
>    server_name www.club.site.com clubsite.com www.clubsite.com;
>    return 301 https://club.site.com$request_uri;
> }
>
> и в .htaccess
> RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
> RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
>
> и такое
>
> RewriteCond %{HTTP_HOST} ^www.clubsite.com$ [NC,OR]
> RewriteCond %{HTTP_HOST} ^clubsite.com$ [NC]
> RewriteRule (.*) https://club.site.com/$1 [R=301,L]
>
> Еще раз просмотрел все конфиг файлы и не нашел где наcтроенно
> перенаправление c www.clubsite.com и www.club.site.com  на web.site.com
>  Где может быть еще трабл?
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,258108,258145#msg-258145
>
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150417/99da6339/attachment.html>

From nginx-forum at nginx.us  Fri Apr 17 12:30:08 2015
From: nginx-forum at nginx.us (itcod)
Date: Fri, 17 Apr 2015 08:30:08 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <1661836.OgkSjrkJir@note>
References: <1661836.OgkSjrkJir@note>
Message-ID: <897a6bfb2e2293961f4714ddc3ce5281.NginxMailingListRussian@forum.nginx.org>

mva добрый день
>>А вы, всё-таки, ответьте, пожалуйста, на вопрос, почему вы не хотите
убрать
PUT из OPTIONS? ;)

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

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258147#msg-258147


From nginx-forum at nginx.us  Fri Apr 17 12:36:39 2015
From: nginx-forum at nginx.us (itcod)
Date: Fri, 17 Apr 2015 08:36:39 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <CAFHpkQGVQL2hh2fj=6rQJKLqnEwuNNLhwxzM-jDNtAH3EMmg1A@mail.gmail.com>
References: <CAFHpkQGVQL2hh2fj=6rQJKLqnEwuNNLhwxzM-jDNtAH3EMmg1A@mail.gmail.com>
Message-ID: <f0989aa7b043c3f9f87e3420711a7ad2.NginxMailingListRussian@forum.nginx.org>

Илья добрый день.
>> если клиент говорит "Expect: 100-Continue", то в этом случае вы можете
ему сказать 405 сразу (или ответить 100-м кодом).
Спасибо Илья. Понял принцип.

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

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258148#msg-258148


From mva at mva.name  Fri Apr 17 12:44:00 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Fri, 17 Apr 2015 18:44 +0600
Subject: PUT & access_by_lua_file
In-Reply-To: <f0989aa7b043c3f9f87e3420711a7ad2.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQGVQL2hh2fj=6rQJKLqnEwuNNLhwxzM-jDNtAH3EMmg1A@mail.gmail.com>
 <f0989aa7b043c3f9f87e3420711a7ad2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <4300619.gX1xVpt55M@note>

В письме от Пт, 17 апреля 2015 08:36:39 пользователь itcod написал:
> 
> Нескромный вопрос.... так и оставим существовать эту PUT дырку?
> пока кого нибудь не заклюеет жареный петух....

Ну, у меня на сервере с отключенным PUT, например, 405+400 выбрасывается 
сразу, не получая содержимое файла.

Другое же дело, когда метод фигурирует в разрешённых у сервера на более низком 
уровне (module_http_dav) и рулится уже в access-модуле (да ещё и в ngx_lua, 
что ещё дальше) ;)

Т.е. ситуация такая:
DAV-модуль говорит серверу, что он готов получать и обрабатывать PUT.
Сервер, следовательно, считает PUT валидным запросом.
Следовательно, когда приходит PUT ? он получает запрос целиком (до этого 
момента он валиден) и только потом, получив запрос, целиком отдаёт его дальше 
по цепочке в модули. Поэтому в руках ngx_lua (в access-директиве) оказывается 
запрос целиком.
Да и в обычном, емнип, access-модуле, тоже обработка происходит ПОСЛЕ 
получения запроса, а не на этапе заголовков :)

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150417/25809246/attachment.bin>

From mdounin at mdounin.ru  Fri Apr 17 12:56:41 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 17 Apr 2015 15:56:41 +0300
Subject: =?UTF-8?B?UmU6IGxpbWl0IGNvbm4g0YHRh9C10YLRh9C40Log0L/QtdGA0LXQv9C+0LvQvdC1?=
 =?UTF-8?B?0L3QuNC1?=
In-Reply-To: <e09672a1b97c3788904f4f195960eec1.NginxMailingListRussian@forum.nginx.org>
References: <e09672a1b97c3788904f4f195960eec1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150417125641.GE88631@mdounin.ru>

Hello!

On Fri, Apr 17, 2015 at 06:06:49AM -0400, dwow wrote:

> Добрый день.
> 
> Была задача ограничить кол-во запросов к бэкенду. Например, чтобы
> одновременно не поступало более 1 запроса. Остальные запросы, пока работает
> бэкенд, могли отваливаться по ошибке, это не страшно.
> С помощью Perl я устанавливал переменную, которая показывала идет ли запрос
> для проксирования на бэкенд или нет. И эту переменную использовал в качестве
> ключа для
> http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html#limit_conn_zone
> 
> perl_set $service_hit '
>         sub {
>             my $r = shift;
>             if($r->uri =~ m|^/services/post|){
>                 return "services";
>             } else {
>                 return "";
>             }
>         }
> ';
> limit_conn_zone "$service_hit" zone=perservice:10m;

Just a side note: не надо делать так, вместо этого правильно 
написать отдельный location, в котором и задать ограничение.

> Потом перед проксированием на бэкенд (в location) использовал ограничениие
> http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html#limit_conn
> 
> limit_conn perservice 1;
> 
> Все отлично работает, но только первые 30-60 минут, потом nginx для всех
> запросов возвращает 503 ошибку, т.е. счетчик не сбрасывается. Если
> остановить-запустить nginx, то опять какое-то время все работает корректно.
> В чем может быть проблема?

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

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Fri Apr 17 13:01:31 2015
From: nginx-forum at nginx.us (itcod)
Date: Fri, 17 Apr 2015 09:01:31 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <4300619.gX1xVpt55M@note>
References: <4300619.gX1xVpt55M@note>
Message-ID: <dee3c41f63c0f516e94f94f44ed86a2f.NginxMailingListRussian@forum.nginx.org>

mva добрый день ещё раз:)

>>Ну, у меня на сервере с отключенным PUT, например, 405+400 
>>выбрасывается сразу, не получая содержимое файла.
А у вас это в динамике или статично прописана блокировка? если динамично
поделитесь идеей плиззз...

>> Другое же дело, когда метод фигурирует в разрешённых у сервера на более
низком
>> уровне (module_http_dav) 
Я пытался решить задачку на этом уровне... мня предложили порешать её в этой
точке :)))
http://forum.nginx.org/read.php?21,258024,258045#msg-258045

>> и рулится уже в access-модуле (да ещё и в ngx_lua, что ещё дальше) ;)
А куда деваться.... я пробовал решить её на иных уровнях... а там переменные
конфг не поддерживает и потому динамику не организовать....

>>Т.е. ситуация такая:
>> DAV-модуль говорит серверу, что он готов получать и обрабатывать PUT.
>> Сервер, следовательно, считает PUT валидным запросом.

mva!!!! можно подробнее!!! 
Вы хотите сказать, что если я в хидерах укажу что PUT запрещён - то nginx
откажется принимать тело если поймает на входе PUT????????????? И это
произойдёт вне зависимости, будет клиент послушным мальчиком, или будет
пихать пальцы во все дырки... не обращая вниание на анонсы nginx???????
ВЫ В ЭТОМ УВЕРЕНЫ?????

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

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258151#msg-258151


From nginx-forum at nginx.us  Fri Apr 17 13:05:39 2015
From: nginx-forum at nginx.us (itcod)
Date: Fri, 17 Apr 2015 09:05:39 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <dee3c41f63c0f516e94f94f44ed86a2f.NginxMailingListRussian@forum.nginx.org>
References: <4300619.gX1xVpt55M@note>
 <dee3c41f63c0f516e94f94f44ed86a2f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2f8efb9b494871e79acf4c9f193a5bb3.NginxMailingListRussian@forum.nginx.org>

ЗЫ....
>>Т.е. ситуация такая:
>> DAV-модуль говорит серверу, что он готов получать и обрабатывать PUT.
>> Сервер, следовательно, считает PUT валидным запросом.

а ваш коментарий про OPTIONS и PUT.... 
а если я из lua попытаюсь изменить OPTIONS.... то PUT для DAV-модуля будет
инвалидным????.....

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258152#msg-258152


From nginx-forum at nginx.us  Fri Apr 17 13:15:21 2015
From: nginx-forum at nginx.us (dwow)
Date: Fri, 17 Apr 2015 09:15:21 -0400
Subject: =?UTF-8?B?UmU6IGxpbWl0IGNvbm4g0YHRh9C10YLRh9C40Log0L/QtdGA0LXQv9C+0LvQvdC1?=
 =?UTF-8?B?0L3QuNC1?=
In-Reply-To: <20150417125641.GE88631@mdounin.ru>
References: <20150417125641.GE88631@mdounin.ru>
Message-ID: <a4494576f8f6b1b025e7d68c4eb2e69a.NginxMailingListRussian@forum.nginx.org>

Maxim Dounin Wrote:
-------------------------------------------------------
 
> Just a side note: не надо делать так, вместо этого правильно 
> написать отдельный location, в котором и задать ограничение.

вот это я не понял.

у меня так
location /services/post/ {
   limit_conn perservice 1;
   proxy_pass bakcend;
}



> Скорее всего проблема в том, что limit_conn органичивает не 
> соединения на бекенду, а активные соединения.  Соответственно, 
> если кто-то сходил на бекенд, получил оттуда достаточно большой 
> ответ и неспеша забирает его у nginx'а - ограничение будет 
> продолжать срабатывать.  Например, если клиент сделал запрос 
> (ответ на который не помещается в буфер сокета), после чего пропал 
> и на пакеты не отвечает - ограничение будет срабатывать, пока не 
> случится send_timeout.

Ага, и тогда через  send_timeout (default: 60s), счетчик должен
декрементироваться и следующий запрос пойти на бекенд, так? Но этого не
происходит(

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258150,258154#msg-258154


From mdounin at mdounin.ru  Fri Apr 17 14:53:18 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 17 Apr 2015 17:53:18 +0300
Subject: =?UTF-8?B?UmU6IGxpbWl0IGNvbm4g0YHRh9C10YLRh9C40Log0L/QtdGA0LXQv9C+0LvQvdC1?=
 =?UTF-8?B?0L3QuNC1?=
In-Reply-To: <a4494576f8f6b1b025e7d68c4eb2e69a.NginxMailingListRussian@forum.nginx.org>
References: <20150417125641.GE88631@mdounin.ru>
 <a4494576f8f6b1b025e7d68c4eb2e69a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150417145317.GJ88631@mdounin.ru>

Hello!

On Fri, Apr 17, 2015 at 09:15:21AM -0400, dwow wrote:

> Maxim Dounin Wrote:
> -------------------------------------------------------
>  
> > Just a side note: не надо делать так, вместо этого правильно 
> > написать отдельный location, в котором и задать ограничение.
> 
> вот это я не понял.
> 
> у меня так
> location /services/post/ {
>    limit_conn perservice 1;
>    proxy_pass bakcend;
> }

Тогда зачем у вас используется perl_set?

Если limit_conn в других location'ах не включён, то для 
ограничения всех соединений в конкретном location'е - достаточно 
любого константного значения.

> > Скорее всего проблема в том, что limit_conn органичивает не 
> > соединения на бекенду, а активные соединения.  Соответственно, 
> > если кто-то сходил на бекенд, получил оттуда достаточно большой 
> > ответ и неспеша забирает его у nginx'а - ограничение будет 
> > продолжать срабатывать.  Например, если клиент сделал запрос 
> > (ответ на который не помещается в буфер сокета), после чего пропал 
> > и на пакеты не отвечает - ограничение будет срабатывать, пока не 
> > случится send_timeout.
> 
> Ага, и тогда через  send_timeout (default: 60s), счетчик должен
> декрементироваться и следующий запрос пойти на бекенд, так? Но этого не
> происходит(

Если send_timeout случится - то да.  Если же вдруг какой-то клиент 
очерь медленно качает что-то большое - то процесс может занять 
бесконечное время.

Ну и да, безусловно имеет смысл заглянуть в error log, и убедится, 
что рабочие процессы не завершаются аварийно.

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Fri Apr 17 15:12:42 2015
From: nginx-forum at nginx.us (itcod)
Date: Fri, 17 Apr 2015 11:12:42 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <dee3c41f63c0f516e94f94f44ed86a2f.NginxMailingListRussian@forum.nginx.org>
References: <4300619.gX1xVpt55M@note>
 <dee3c41f63c0f516e94f94f44ed86a2f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <d4e0a67cddd8c1edfc036e30c24b4dcb.NginxMailingListRussian@forum.nginx.org>

проверил Access-Control-Allow-Methods
- проблема сохранилась nginx разрешает заливать в себя сколько влезет....

BitKinex - послал PROPFIND
nginx - ответил Access-Control-Allow-Methods: GET
BitKinex - игнорировал хидер и инициировал PUT
nginx - разрешил PUT и получил файл....
[lua] блокировал его размещение HTTP/1.1 405 Not Allowed
:(

Resolving host name "dav.example.com" ...
Connecting ( home.itcod.com => ip: 10.1.1.1, port: 80 )
Connected (10.1.1.1:80)
<<< PROPFIND / HTTP/1.1
<<< Host: home.itcod.com
<<< User-Agent: BitKinex/3.2.3
<<< Accept: */*
<<< Pragma: no-cache
<<< Cache-Control: no-cache
<<< Depth: 1
<<< Content-Length: 220
<<< Content-Type: text/xml
<<< Authorization: Basic блаблабла==
>>> HTTP/1.1 207 Multi-Status
>>> Server: nginx/0.8.54
>>> Date: Fri, 17 Apr 2015 15:01:13 GMT
>>> Content-Type: application/octet-stream
>>> Transfer-Encoding: chunked
>>> Connection: keep-alive
>>> Access-Control-Allow-Methods: GET
<<< PUT /IMG_20150414_184225.jpg HTTP/1.1
<<< Host: home.itcod.com
<<< User-Agent: BitKinex/3.2.3
<<< Accept: */*
<<< Pragma: no-cache
<<< Cache-Control: no-cache
<<< Content-Length: 696983
<<< Content-Type: application/octet-stream
<<< Translate: f
<<< Authorization: Basic блаблабла==
>>> HTTP/1.1 405 Not Allowed
>>> Server: nginx/0.8.54
>>> Date: Fri, 17 Apr 2015 15:01:19 GMT
>>> Content-Type: text/html
>>> Connection: keep-alive
>>> Content-Length: 173
Connection closed

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258158#msg-258158


From nginx-forum at nginx.us  Fri Apr 17 16:28:03 2015
From: nginx-forum at nginx.us (dwow)
Date: Fri, 17 Apr 2015 12:28:03 -0400
Subject: =?UTF-8?B?UmU6IGxpbWl0IGNvbm4g0YHRh9C10YLRh9C40Log0L/QtdGA0LXQv9C+0LvQvdC1?=
 =?UTF-8?B?0L3QuNC1?=
In-Reply-To: <20150417145317.GJ88631@mdounin.ru>
References: <20150417145317.GJ88631@mdounin.ru>
Message-ID: <0b7205b4d1b68a3ffdc81dc1b2c6bb0c.NginxMailingListRussian@forum.nginx.org>

Maxim Dounin Wrote:
-------------------------------------------------------
> Если limit_conn в других location'ах не включён, то для 
> ограничения всех соединений в конкретном location'е - достаточно 
> любого константного значения.

Если не используется в др. локейшенах, то можно сделать вот так:
limit_conn_zone "service" zone=perservice:10m;
location /services/post/ {
   limit_conn perservice 1;
   proxy_pass bakcend;
}

и будет работать?


> Если send_timeout случится - то да.  Если же вдруг какой-то клиент 
> очерь медленно качает что-то большое - то процесс может занять 
> бесконечное время.
и как от таких избавляться? 

 
> Ну и да, безусловно имеет смысл заглянуть в error log, и убедится, 
> что рабочие процессы не завершаются аварийно.
ошибок нет.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258150,258159#msg-258159


From mdounin at mdounin.ru  Fri Apr 17 17:05:34 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 17 Apr 2015 20:05:34 +0300
Subject: =?UTF-8?B?UmU6IGxpbWl0IGNvbm4g0YHRh9C10YLRh9C40Log0L/QtdGA0LXQv9C+0LvQvdC1?=
 =?UTF-8?B?0L3QuNC1?=
In-Reply-To: <0b7205b4d1b68a3ffdc81dc1b2c6bb0c.NginxMailingListRussian@forum.nginx.org>
References: <20150417145317.GJ88631@mdounin.ru>
 <0b7205b4d1b68a3ffdc81dc1b2c6bb0c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150417170534.GL88631@mdounin.ru>

Hello!

On Fri, Apr 17, 2015 at 12:28:03PM -0400, dwow wrote:

> Maxim Dounin Wrote:
> -------------------------------------------------------
> > Если limit_conn в других location'ах не включён, то для 
> > ограничения всех соединений в конкретном location'е - достаточно 
> > любого константного значения.
> 
> Если не используется в др. локейшенах, то можно сделать вот так:
> limit_conn_zone "service" zone=perservice:10m;
> location /services/post/ {
>    limit_conn perservice 1;
>    proxy_pass bakcend;
> }
> 
> и будет работать?

Да.  В старых версиях (до nginx 1.7.6), возможно, потребуется 
какая-нибудь константная переменная (например, $nginx_version), а 
не просто строка.

> > Если send_timeout случится - то да.  Если же вдруг какой-то клиент 
> > очерь медленно качает что-то большое - то процесс может занять 
> > бесконечное время.
> и как от таких избавляться? 

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

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

-- 
Maxim Dounin
http://nginx.org/


From gmm at csdoc.com  Fri Apr 17 17:53:32 2015
From: gmm at csdoc.com (Gena Makhomed)
Date: Fri, 17 Apr 2015 20:53:32 +0300
Subject: =?UTF-8?B?UmU6IGxpbWl0IGNvbm4g0YHRh9C10YLRh9C40Log0L/QtdGA0LXQv9C+0LvQvdC1?=
 =?UTF-8?B?0L3QuNC1?=
In-Reply-To: <0b7205b4d1b68a3ffdc81dc1b2c6bb0c.NginxMailingListRussian@forum.nginx.org>
References: <20150417145317.GJ88631@mdounin.ru>
 <0b7205b4d1b68a3ffdc81dc1b2c6bb0c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5531489C.7000003@csdoc.com>

On 17.04.2015 19:28, dwow wrote:

 >>> Была задача ограничить кол-во запросов к бэкенду.
 >>> Например, чтобы одновременно не поступало более 1 запроса.

>> Если же вдруг какой-то клиент очерь медленно качает
>> что-то большое - то процесс может занять бесконечное время.

> и как от таких избавляться?

1) купить платную версию NGINX Plus, там есть max_conns=number
http://nginx.org/en/docs/http/ngx_http_upstream_module.html

2) поставить между клиентом [или nginx] и бэкендом
haproxy - haproxy умеет это делать прямо из коробки:
https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2-maxconn

-- 
Best regards,
  Gena


From nginx-forum at nginx.us  Fri Apr 17 17:58:20 2015
From: nginx-forum at nginx.us (itcod)
Date: Fri, 17 Apr 2015 13:58:20 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <014534d85ad822248eb6d66b3e6a868b.NginxMailingListRussian@forum.nginx.org>
References: <014534d85ad822248eb6d66b3e6a868b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <04d1bcdc2de30229dd9478df868ff1c4.NginxMailingListRussian@forum.nginx.org>

Упростил схему. 
1. из dav_methods изъял PUT
2. отключил луа авторизатор
тестил BitKinex'ом

Результат: метод PUT не блокирует nginx, хотя он запрещён в модуле DAV.
то есть всё как было. сначало принимаем большой файл, а потом говорим, что
нам этого нельзя.

server {
listen 80;
server_name dav.example.com;
server_name_in_redirect off;
access_log /var/log/nginx/dav-access.log main;
location / {
access_by_lua_file /etc/nginx/lua/auth-dav1.lua;
dav_methods DELETE COPY MOVE;
dav_ext_methods PROPFIND OPTIONS;
create_full_put_path on;
dav_access user:rw group:rw;
client_body_temp_path /opt/itcod-dav.tmp/;
client_max_body_size 0;
autoindex on;
root /opt/home/;
}
location ~/\.ht {
deny all;
}
}

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258162#msg-258162


From nginx-forum at nginx.us  Fri Apr 17 18:41:26 2015
From: nginx-forum at nginx.us (itcod)
Date: Fri, 17 Apr 2015 14:41:26 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <04d1bcdc2de30229dd9478df868ff1c4.NginxMailingListRussian@forum.nginx.org>
References: <014534d85ad822248eb6d66b3e6a868b.NginxMailingListRussian@forum.nginx.org>
 <04d1bcdc2de30229dd9478df868ff1c4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <7ea21a6c2860b79888509bd82d6c3704.NginxMailingListRussian@forum.nginx.org>

добавил в location конструкцию
if ($request_method = PUT) {
return 403;
}

по прежнему PUT прокачивает холостые гигобайты трафика! :(

Буду рад мыслям сообщества!
какими ещё существующими средствами nginx, можно всё таки прекратить такое
"сверхлояльное" поведение nginx с настырными PUT'анами:)))))))

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258163#msg-258163


From chipitsine at gmail.com  Fri Apr 17 18:50:20 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 17 Apr 2015 23:50:20 +0500
Subject: PUT & access_by_lua_file
In-Reply-To: <f0989aa7b043c3f9f87e3420711a7ad2.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQGVQL2hh2fj=6rQJKLqnEwuNNLhwxzM-jDNtAH3EMmg1A@mail.gmail.com>
 <f0989aa7b043c3f9f87e3420711a7ad2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQHd7ZkAFuC0iWzN_Hb7geHec=H-OB6dK_CWN_idQ2sREQ@mail.gmail.com>

хотите совет? поставьте CEPH
в качестве упражнения, ваши манипуляции с DAV выглядят вполне симпатично.

для продакшена распределенный кластер CEPH/S3 (по сути тот же
http-доступ) более крут.
клиентов S3 не меньше, чем DAV

документации полно, она хорошего качества,
http://habrahabr.ru/company/performix/blog/218065/

17 апреля 2015 г., 17:36 пользователь itcod <nginx-forum at nginx.us> написал:
> Илья добрый день.
>>> если клиент говорит "Expect: 100-Continue", то в этом случае вы можете
> ему сказать 405 сразу (или ответить 100-м кодом).
> Спасибо Илья. Понял принцип.
>
>>>без этого хедера - да, ответить можно, только получив запрос полностью
> Нескромный вопрос.... так и оставим существовать эту PUT дырку?
> пока кого нибудь не заклюеет жареный петух....
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258148#msg-258148
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From wangsamp at gmail.com  Fri Apr 17 22:01:26 2015
From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi)
Date: Sat, 18 Apr 2015 01:01:26 +0300 (EEST)
Subject: PUT & access_by_lua_file
In-Reply-To: <d4e0a67cddd8c1edfc036e30c24b4dcb.NginxMailingListRussian@forum.nginx.org>
References: <4300619.gX1xVpt55M@note>
 <dee3c41f63c0f516e94f94f44ed86a2f.NginxMailingListRussian@forum.nginx.org>
 <d4e0a67cddd8c1edfc036e30c24b4dcb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <alpine.BSF.2.00.1504180051140.98215@u.fchgavxzrqvn.arg>

Yesterday Apr 17, 2015 at 11:12 itcod wrote:

> Resolving host name "dav.example.com" ...
> Connecting ( home.itcod.com => ip: 10.1.1.1, port: 80 )
> Connected (10.1.1.1:80)
> <<< PROPFIND / HTTP/1.1
> <<< Host: home.itcod.com

> >>> HTTP/1.1 207 Multi-Status
> >>> Server: nginx/0.8.54

  Заметил древнюю версию и сделал аналогичный запрос, а в теле ответа другая:
  <center><h1>401 Authorization Required</h1></center>
  <hr><center>nginx/1.7.11</center>
  У Вас один nginx за другим nginx?
  Если да, то первый полностью принимает запрос и лишь после этого отправляет
  его второму, а тот возвращает 405.
-- 
WNGS-RIPE


From nginx-forum at nginx.us  Sat Apr 18 05:34:39 2015
From: nginx-forum at nginx.us (itcod)
Date: Sat, 18 Apr 2015 01:34:39 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <alpine.BSF.2.00.1504180051140.98215@u.fchgavxzrqvn.arg>
References: <alpine.BSF.2.00.1504180051140.98215@u.fchgavxzrqvn.arg>
Message-ID: <5b7394358f809eabcdd9616094017053.NginxMailingListRussian@forum.nginx.org>

Добрый день Александр!
Да там получается пара друг за дугом. Фронт старичёк....
Ура!!! Вы совершенно правы!!! Обратился BitKinex к внутреннему
Он обрывает PUT сразу!!!

<<< PUT /IMG_20150414_184225.jpg HTTP/1.1
<<< Host: home.virtual.ko:7070
<<< User-Agent: BitKinex/3.2.3
<<< Accept: */*
<<< Pragma: no-cache
<<< Cache-Control: no-cache
<<< Content-Length: 696983
<<< Content-Type: application/octet-stream
<<< Translate: f
<<< Authorization: Basic блаблабла==
>>> HTTP/1.1 405 Not Allowed
>>> Server: nginx/1.7.11
>>> Date: Sat, 18 Apr 2015 05:25:34 GMT
>>> Content-Type: text/html
>>> Content-Length: 173
>>> Connection: keep-alive
Connection closed

Спасибо огромное!!!!
Надо покурить эту инфу...

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258178#msg-258178


From nginx-forum at nginx.us  Sat Apr 18 05:56:52 2015
From: nginx-forum at nginx.us (itcod)
Date: Sat, 18 Apr 2015 01:56:52 -0400
Subject: PUT & access_by_lua_file
In-Reply-To: <CAFHpkQHd7ZkAFuC0iWzN_Hb7geHec=H-OB6dK_CWN_idQ2sREQ@mail.gmail.com>
References: <CAFHpkQHd7ZkAFuC0iWzN_Hb7geHec=H-OB6dK_CWN_idQ2sREQ@mail.gmail.com>
Message-ID: <a719caea29492936dbe4e9013c2e9601.NginxMailingListRussian@forum.nginx.org>

>> поставьте CEPH
Илья спасибо:) хороший совет:)
Наверное интересный софт. я его обязательно погрызу на досуге.... 
На всё время нужно... Для WEBDAV, я знаю на следующие этапы JS и Perl
либы.... 
а S3, это всё с нуля..... В умке по S3 шаром покати... ток амазон и
всплывает:)))))

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258069,258179#msg-258179


From nginx-forum at nginx.us  Mon Apr 20 10:07:08 2015
From: nginx-forum at nginx.us (claygod)
Date: Mon, 20 Apr 2015 06:07:08 -0400
Subject: =?UTF-8?B?0J/QvtC00LrQu9GO0YfQuNGC0Ywg0LzQvtC00YPQu9GMIFBvc3RncmVTUUwg0LIg?=
 =?UTF-8?B?V2luINCy0LXRgNGB0LjQuA==?=
Message-ID: <4e9fe0e5976189da02cc641d01a1916d.NginxMailingListRussian@forum.nginx.org>

Простой вопрос - как этот сторонний модуль можно подключить и использовать в
Вин-версии ?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258209,258209#msg-258209


From nginx-forum at nginx.us  Mon Apr 20 12:38:27 2015
From: nginx-forum at nginx.us (Sovigod)
Date: Mon, 20 Apr 2015 08:38:27 -0400
Subject: image_filter request_time
Message-ID: <c3c4433085266838dbbdd5490a464453.NginxMailingListRussian@forum.nginx.org>

День добрый!

Столкнулся с проблемой логирования.

Переменная в $request_time всегда равна 0 в запросах использующих ресайз
картинки модулем image_filter

Формат лога
        log_format main
                '$remote_addr [$time_local] '
                '$host "$request" St:"$status" $bytes_sent
Cookie:"$http_cookie"'
                '"$http_referer" "$http_user_agent" '
                '"$upstream_addr"  ReqTime:"$request_time"
"$upstream_response_time" Cache:"$upstream_cache_status"';


Примеры из лога

127.0.0.1 [20/Apr/2015:15:22:15 +0300] cdn2 "GET
/r/GoqWrJ_RZ0IOiC4zBOWgtw/-x180/user/106/1062391/201501/18f778458b1f94f84ea5f2a53630e4a4.jpg
HTTP/1.1" St:"200" 17582 Cookie:"-""http://www..ru/" "Mozilla/5.0 (Windows
NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115
YaBrowser/15.2.2214.3645 Safari/537.36" "-"  ReqTime:"0.000" "-" Cache:"-"
127.0.0.1 [20/Apr/2015:15:22:16 +0300] img "GET
/r/QIO69D7020HASPoycSl87w/-x180/0/7/5/075a6864f64655922ee112ab6e99ee05.jpg
HTTP/1.1" St:"404" 334 Cookie:"-""-" "msnbot-media/1.1
(+http://search.msn.com/msnbot.htm)" "-"  ReqTime:"0.000" "-" Cache:"-"
127.0.0.1 [20/Apr/2015:15:22:16 +0300] cdn "GET
/r/Bqbdq4LKoZXz9cTH_xKAMA/60x60/navatar/75/752884/141aa5e66843f2e56651043be9b4408a.jpg
HTTP/1.1" St:"200" 4031 Cookie:"-""http://m..ru/" "Mozilla/5.0 (iPhone; CPU
iPhone OS 8_2 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko)
Version/8.0 Mobile/12D508 Safari/600.1.4" "-"  ReqTime:"0.000" "-"
Cache:"-"


конфиг сервера


	server {
	        listen      8081;
		access_log "/var/log/nginx/img-resize-access_log" main;
		error_log "/var/log/nginx/img-resize-error_log" info;
		error_page 403 404 415 500 502 503 504 = /404;

		image_filter_buffer 3M;

		location ~ ^/i/([^/]+)/(.+) {
			alias /mnt/imgbbr4/$2;
			secure_link $1;
			secure_link_md5  123/$2;
			try_files "" /404;
			if ($secure_link = "") { return 404; }
			image_filter size;
		}

                location ~ ^/c/([^/]+)/(\d+|-)x(\d+|-)/(.+) {
			secure_link $1;
			secure_link_md5  123/$4;
                        set $width  $2;
                        set $height $3;
                        alias /mnt/imgbbr4/$4;
                        try_files "" /404;
                        if ($secure_link = "") { return 404; }
                        image_filter crop  $width  $height;
                }

                location ~ ^/r/([^/]+)/(\d+|-)x(\d+|-)/(.+) {
			secure_link $1;
			secure_link_md5  123/$4;
                        set $width  $2;
                        set $height $3;
                        alias /mnt/imgbbr4/$4;
                        try_files "" /404;
                        if ($secure_link = "") { return 404; }
			image_filter_jpeg_quality 95;
                        image_filter resize  $width  $height;
                }

                location /404 { return 404; }
	    }


cdn01 inc # nginx -V
nginx version: nginx/1.7.6
TLS SNI support enabled
configure arguments: --prefix=/usr --conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error_log --pid-path=/run/nginx.pid
--lock-path=/run/lock/nginx.lock --with-cc-opt=-I/usr/include
--with-ld-opt=-L/usr/lib64 --http-log-path=/var/log/nginx/access_log
--http-client-body-temp-path=//var/lib/nginx/tmp/client
--http-proxy-temp-path=//var/lib/nginx/tmp/proxy
--http-fastcgi-temp-path=//var/lib/nginx/tmp/fastcgi
--http-scgi-temp-path=//var/lib/nginx/tmp/scgi
--http-uwsgi-temp-path=//var/lib/nginx/tmp/uwsgi --with-file-aio
--with-aio_module --with-ipv6 --with-pcre --with-http_geoip_module
--with-http_image_filter_module --with-http_secure_link_module
--with-http_stub_status_module --with-http_realip_module
--add-module=external_module/headers-more-nginx-module-0.25
--add-module=external_module/ngx_slowfs_cache-1.10
--add-module=external_module/nginx-push-stream-module-0.4.0
--with-http_ssl_module --without-mail_imap_module --without-mail_pop3_module
--without-mail_smtp_module --user=nginx --group=nginx

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258211,258211#msg-258211


From nginx-forum at nginx.us  Mon Apr 20 13:13:24 2015
From: nginx-forum at nginx.us (nNgzlTtv3k5lzmKRvlmS22tSl8sJr68k)
Date: Mon, 20 Apr 2015 09:13:24 -0400
Subject: =?UTF-8?B?0J3QtSDRgNCw0LHQvtGC0LDQtdGCINGD0YHQu9C+0LLQvdC+0LUg0LvQvtCz0LM=?=
 =?UTF-8?B?0LjRgNC+0LLQsNC90LjQtQ==?=
Message-ID: <8be955fb314b261747b0a8091db81ada.NginxMailingListRussian@forum.nginx.org>

Задаю в секции server{} следующее

set $do_log 0;
if ($status = 200){ set $do_log 1; }
access_log /var/log/nginx/code-200.log combined if=$do_log;

логгирование не работает, в лог вообще ничего не летит. Если использовать
другие переменные, не $status, работает. Это ошибка в nginx ?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258213,258213#msg-258213


From mdounin at mdounin.ru  Mon Apr 20 13:31:58 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 20 Apr 2015 16:31:58 +0300
Subject: image_filter request_time
In-Reply-To: <c3c4433085266838dbbdd5490a464453.NginxMailingListRussian@forum.nginx.org>
References: <c3c4433085266838dbbdd5490a464453.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150420133157.GA32429@mdounin.ru>

Hello!

On Mon, Apr 20, 2015 at 08:38:27AM -0400, Sovigod wrote:

> День добрый!
> 
> Столкнулся с проблемой логирования.
> 
> Переменная в $request_time всегда равна 0 в запросах использующих ресайз
> картинки модулем image_filter

Это потому, что nginx обновляет своё внутреннее время только после 
получения новых событий из ядра.  Соответственно если обработка 
запроса запроса происходит без возврата в ядро - то в 
$request_time будет 0, даже если на самом деле обработка заняла 
ненулевое время.

Немного про это можно прочитать в документации тут:

http://nginx.org/ru/docs/ngx_core_module.html#timer_resolution

-- 
Maxim Dounin
http://nginx.org/


From mdounin at mdounin.ru  Mon Apr 20 13:41:16 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 20 Apr 2015 16:41:16 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRg9GB0LvQvtCy0L3QvtC1INC70L4=?=
 =?UTF-8?B?0LPQs9C40YDQvtCy0LDQvdC40LU=?=
In-Reply-To: <8be955fb314b261747b0a8091db81ada.NginxMailingListRussian@forum.nginx.org>
References: <8be955fb314b261747b0a8091db81ada.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150420134116.GB32429@mdounin.ru>

Hello!

On Mon, Apr 20, 2015 at 09:13:24AM -0400, nNgzlTtv3k5lzmKRvlmS22tSl8sJr68k wrote:

> Задаю в секции server{} следующее
> 
> set $do_log 0;
> if ($status = 200){ set $do_log 1; }
> access_log /var/log/nginx/code-200.log combined if=$do_log;
> 
> логгирование не работает, в лог вообще ничего не летит. Если использовать
> другие переменные, не $status, работает. Это ошибка в nginx ?

Нет, это ошибка в конфиге.  Директивы модуля rewrite выполняются 
до того, как становится известен статус ответа, соответственно 
директива if в вышеприведённом фрагменте не может сработать 
никогда.

Правильно так:

    map $status $status_200 {
        200     1;
    }

    access_log /path/to/200.log combined if=$status_200;

Подробнее про директивы модуля rewrite, если всё-таки хочется их 
использовать, имеет смысл прочитать тут:

http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html

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

http://nginx.org/ru/docs/http/ngx_http_map_module.html

-- 
Maxim Dounin
http://nginx.org/


From mdounin at mdounin.ru  Mon Apr 20 14:05:19 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 20 Apr 2015 17:05:19 +0300
Subject: =?UTF-8?B?UmU6INCf0L7QtNC60LvRjtGH0LjRgtGMINC80L7QtNGD0LvRjCBQb3N0Z3JlU1FM?=
 =?UTF-8?B?INCyIFdpbiDQstC10YDRgdC40Lg=?=
In-Reply-To: <4e9fe0e5976189da02cc641d01a1916d.NginxMailingListRussian@forum.nginx.org>
References: <4e9fe0e5976189da02cc641d01a1916d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150420140519.GE32429@mdounin.ru>

Hello!

On Mon, Apr 20, 2015 at 06:07:08AM -0400, claygod wrote:

> Простой вопрос - как этот сторонний модуль можно подключить и использовать в
> Вин-версии ?

Инструкция по самостоятельной сборке win32-версии тут:

http://nginx.org/en/docs/howto_build_on_win32.html

Сторонние модули при сборке подключаются так же, как и на 
UNIX-системах.  Соберётся ли конкретный сторонний модуль на 
win32 (и будет ли работать, если соберётся) - не знаю.

-- 
Maxim Dounin
http://nginx.org/


From myc at cname.me  Mon Apr 20 14:39:18 2015
From: myc at cname.me (Eugene Mychlo)
Date: Mon, 20 Apr 2015 17:39:18 +0300
Subject: try_files + subrequest + proxy-handler
Message-ID: <1A16C0C0-D6FE-41CE-BBC4-F4FA095A30AC@cname.me>

Добрый день,

Столкнулся со странной поведением nginx при использовании subrequest в сочетании с try_files с proxy-хэндлером.
В приведенной ниже конфигурации, ожидалось, что при наличии файла  /tmp/tres,  на запрос

http://127.0.0.1:8080/uno

nginx вернет строку "uno  duo " или  "tres tres ", но никак не  "uno  tres ".

Т.е. URI основного запроса передается без изменений (как и описано в документации), а подзапроса - нет.
Ситуация воспроизводится на nginx версий 1.7.9 - 1.7.12.

Отсюда вопрос: является ли подобное поведение задуманным или это бага?
Будет ли меняться?  И не стоит ли отметить это в документации?



    server {
        listen       8081;
        default_type text/html;

        location /uno {   return 200 "uno  ";   }
        location /duo {   return 200 "duo  ";   }
        location /tres {   return 200 "tres  ";   }
    }


    server {
        listen       8080;

        location / {
            root /tmp;
            try_files /tres =404;
            proxy_pass http://127.0.0.1:8081;
            add_after_body /duo;
        }
    }



--
Regards,
Eugene Mychlo MYC-RIPE EAMYC-RIPN


From nginx-forum at nginx.us  Mon Apr 20 14:43:44 2015
From: nginx-forum at nginx.us (claygod)
Date: Mon, 20 Apr 2015 10:43:44 -0400
Subject: =?UTF-8?B?0JTQvtGB0YLRg9C/INC6INGB0L7QtNC10YDQttC40LzQvtC80YMgJHJlcXVlc3Qg?=
 =?UTF-8?B?Ym9keSDQsiBQT1NUINC30LDQv9GA0L7RgdC1?=
Message-ID: <6b0af699e60013da967fb979e7dcb2d2.NginxMailingListRussian@forum.nginx.org>

Тип запроса (GET, POST) можно определить в $request_method, тело запроса в
$request_body. Как посмотреть содержимое запроса, чтобы принять какое-то
решение (в какой локейшен например, и т.д.). Т.е. оперировать не
составляющими урла ?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258223,258223#msg-258223


From nginx-forum at nginx.us  Mon Apr 20 14:54:57 2015
From: nginx-forum at nginx.us (nNgzlTtv3k5lzmKRvlmS22tSl8sJr68k)
Date: Mon, 20 Apr 2015 10:54:57 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRg9GB0LvQvtCy0L3QvtC1INC70L4=?=
 =?UTF-8?B?0LPQs9C40YDQvtCy0LDQvdC40LU=?=
In-Reply-To: <8be955fb314b261747b0a8091db81ada.NginxMailingListRussian@forum.nginx.org>
References: <8be955fb314b261747b0a8091db81ada.NginxMailingListRussian@forum.nginx.org>
Message-ID: <4f1ad3f181fca15a4c90aaadb03f967f.NginxMailingListRussian@forum.nginx.org>

Да, версия nginx - 1.7.10

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258213,258224#msg-258224


From nginx-forum at nginx.us  Mon Apr 20 15:05:57 2015
From: nginx-forum at nginx.us (nNgzlTtv3k5lzmKRvlmS22tSl8sJr68k)
Date: Mon, 20 Apr 2015 11:05:57 -0400
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRg9GB0LvQvtCy0L3QvtC1INC70L4=?=
 =?UTF-8?B?0LPQs9C40YDQvtCy0LDQvdC40LU=?=
In-Reply-To: <20150420134116.GB32429@mdounin.ru>
References: <20150420134116.GB32429@mdounin.ru>
Message-ID: <1d5b3fcdf939358f451d7fb48fece401.NginxMailingListRussian@forum.nginx.org>

Ясно, спасибо. А по поводу остальных переменных, есть какие-то ещё, значение
которых вычисляется после отработки модуля rewrite и точно так же не будут
работать в моём примере ? В документации описание этих моментов что-то не
припоминаю.

Просьба: можно добавить уточнение про модуль rewrite в описании директивы
access_log, т.к. описание работы её параметров в первую очередь тянет
смотреть именно в документации по ней ?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258213,258225#msg-258225


From mdounin at mdounin.ru  Mon Apr 20 15:22:13 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 20 Apr 2015 18:22:13 +0300
Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0YPQvyDQuiDRgdC+0LTQtdGA0LbQuNC80L7QvNGDICRyZXF1?=
 =?UTF-8?B?ZXN0IGJvZHkg0LIgUE9TVCDQt9Cw0L/RgNC+0YHQtQ==?=
In-Reply-To: <6b0af699e60013da967fb979e7dcb2d2.NginxMailingListRussian@forum.nginx.org>
References: <6b0af699e60013da967fb979e7dcb2d2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150420152213.GF32429@mdounin.ru>

Hello!

On Mon, Apr 20, 2015 at 10:43:44AM -0400, claygod wrote:

> Тип запроса (GET, POST) можно определить в $request_method, тело запроса в
> $request_body. Как посмотреть содержимое запроса, чтобы принять какое-то
> решение (в какой локейшен например, и т.д.). Т.е. оперировать не
> составляющими урла ?

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

-- 
Maxim Dounin
http://nginx.org/


From mdounin at mdounin.ru  Mon Apr 20 16:07:24 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 20 Apr 2015 19:07:24 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiDRg9GB0LvQvtCy0L3QvtC1INC70L4=?=
 =?UTF-8?B?0LPQs9C40YDQvtCy0LDQvdC40LU=?=
In-Reply-To: <1d5b3fcdf939358f451d7fb48fece401.NginxMailingListRussian@forum.nginx.org>
References: <20150420134116.GB32429@mdounin.ru>
 <1d5b3fcdf939358f451d7fb48fece401.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150420160724.GG32429@mdounin.ru>

Hello!

On Mon, Apr 20, 2015 at 11:05:57AM -0400, nNgzlTtv3k5lzmKRvlmS22tSl8sJr68k wrote:

> Ясно, спасибо. А по поводу остальных переменных, есть какие-то ещё, значение
> которых вычисляется после отработки модуля rewrite и точно так же не будут
> работать в моём примере ? В документации описание этих моментов что-то не
> припоминаю.

В документации модуля rewrite сказано:

: Модуль ngx_http_rewrite_module позволяет изменять URI запроса с 
: помощью регулярных выражений, делать перенаправления и выбирать 
: конфигурацию по условию.

А равно расписан порядок обработки директив этого модуля.  Из 
этого описания однозначно следует, что вся эта обработка делается 
до того, как результат обработки запроса известен.

> Просьба: можно добавить уточнение про модуль rewrite в описании директивы
> access_log, т.к. описание работы её параметров в первую очередь тянет
> смотреть именно в документации по ней ?

Работа параметров директивы access_log никак не связана с работой 
директив модуля rewrite.

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Tue Apr 21 07:42:35 2015
From: nginx-forum at nginx.us (claygod)
Date: Tue, 21 Apr 2015 03:42:35 -0400
Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0YPQvyDQuiDRgdC+0LTQtdGA0LbQuNC80L7QvNGDICRyZXF1?=
 =?UTF-8?B?ZXN0IGJvZHkg0LIgUE9TVCDQt9Cw0L/RgNC+0YHQtQ==?=
In-Reply-To: <20150420152213.GF32429@mdounin.ru>
References: <20150420152213.GF32429@mdounin.ru>
Message-ID: <0cc5693e1dec381131d16468c5ef1d10.NginxMailingListRussian@forum.nginx.org>

Максим, спасибо за ответ, я в принципе так и думал.
А на сегодня такой сторонний модуль существует?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258226,258246#msg-258246


From nginx-forum at nginx.us  Tue Apr 21 08:29:37 2015
From: nginx-forum at nginx.us (dwow)
Date: Tue, 21 Apr 2015 04:29:37 -0400
Subject: =?UTF-8?B?0JLQu9C+0LbQtdC90L3Ri9C5IGxvY2F0aW9u?=
Message-ID: <88ad2bbb5b36374e03276f5a50b13acc.NginxMailingListRussian@forum.nginx.org>

Добрый день,

Такой конфиг:

location ~* /s/(?<static_file>.*) {
        root /home/...;

        open_file_cache          max=1000 inactive=20s;
        try_files /static/$static_file $uri;

        location ~* /s/(?<img>.*?\.(gif|png|jpg|jpeg)$) {
            expires 30d;
        }
}

В такой конфигурации на запрос /s/pix.jpg будет 404 ошибка. Если во
вложенный location добавить try_files /static/$img $uri; то все будет
работать нормально. Так и должно быть?

И второй вопрос, если так и должно быть, то будет ли корректно работать
open_file_cache во вложенных location, т.е. будут ли файлы кешироваться?

Спасибо.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258248,258248#msg-258248


From simplebox66 at gmail.com  Tue Apr 21 08:40:05 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Tue, 21 Apr 2015 11:40:05 +0300
Subject: try_files + subrequest + proxy-handler
In-Reply-To: <1A16C0C0-D6FE-41CE-BBC4-F4FA095A30AC@cname.me>
References: <1A16C0C0-D6FE-41CE-BBC4-F4FA095A30AC@cname.me>
Message-ID: <CA+ksgAAjSw7NJ1vLTSOTAoC03r63GrgDf6rfNjmHEH4HCK9s6w@mail.gmail.com>

Добрый день!
>
>  add_after_body /duo;

Для чего эта строка в конфиге?
Ну а так вроде бы все правильно по логике должно выдавать  "uno  tres ". В
чем проблема не совсем понятно

20 апреля 2015 г., 17:39 пользователь Eugene Mychlo <myc at cname.me> написал:

> Добрый день,
>
> Столкнулся со странной поведением nginx при использовании subrequest в
> сочетании с try_files с proxy-хэндлером.
> В приведенной ниже конфигурации, ожидалось, что при наличии файла
> /tmp/tres,  на запрос
>
> http://127.0.0.1:8080/uno
>
> nginx вернет строку "uno  duo " или  "tres tres ", но никак не  "uno  tres
> ".
>
> Т.е. URI основного запроса передается без изменений (как и описано в
> документации), а подзапроса - нет.
> Ситуация воспроизводится на nginx версий 1.7.9 - 1.7.12.
>
> Отсюда вопрос: является ли подобное поведение задуманным или это бага?
> Будет ли меняться?  И не стоит ли отметить это в документации?
>
>
>
>     server {
>         listen       8081;
>         default_type text/html;
>
>         location /uno {   return 200 "uno  ";   }
>         location /duo {   return 200 "duo  ";   }
>         location /tres {   return 200 "tres  ";   }
>     }
>
>
>     server {
>         listen       8080;
>
>         location / {
>             root /tmp;
>             try_files /tres =404;
>             proxy_pass http://127.0.0.1:8081;
>             add_after_body /duo;
>         }
>     }
>
>
>
> --
> Regards,
> Eugene Mychlo MYC-RIPE EAMYC-RIPN
>
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150421/26caed42/attachment.html>

From myc at cname.me  Tue Apr 21 09:08:51 2015
From: myc at cname.me (Eugene Mychlo)
Date: Tue, 21 Apr 2015 12:08:51 +0300
Subject: try_files + subrequest + proxy-handler
In-Reply-To: <CA+ksgAAjSw7NJ1vLTSOTAoC03r63GrgDf6rfNjmHEH4HCK9s6w@mail.gmail.com>
References: <1A16C0C0-D6FE-41CE-BBC4-F4FA095A30AC@cname.me>
 <CA+ksgAAjSw7NJ1vLTSOTAoC03r63GrgDf6rfNjmHEH4HCK9s6w@mail.gmail.com>
Message-ID: <7072E87B-E0F1-4685-9340-6ABE18A4BA20@cname.me>

add_after_body тут нужен исключительно для демонстрации сабреквеста.
Подобную ситуацию можно получить с любым модулем, использующим сабреквест.

http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_pass <http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_pass>

 Если директива proxy_pass указана без URI, то при обработке первоначального запроса на сервер передаётся URI запроса в том же виде, в каком его прислал клиент, а при обработке изменённого URI - нормализованный URI запроса целиком:

Исходя из этого совсем не очевидно почему main request долетает до бэкенда без изменения URI, а subrequest с изменением URI.



> 21 апр. 2015 г., в 11:40, Иван Мишин <simplebox66 at gmail.com> написал(а):
> 
> Добрый день!
>  add_after_body /duo;
> Для чего эта строка в конфиге?
> Ну а так вроде бы все правильно по логике должно выдавать  "uno  tres ". В чем проблема не совсем понятно
> 
> 20 апреля 2015 г., 17:39 пользователь Eugene Mychlo <myc at cname.me <mailto:myc at cname.me>> написал:
> Добрый день,
> 
> Столкнулся со странной поведением nginx при использовании subrequest в сочетании с try_files с proxy-хэндлером.
> В приведенной ниже конфигурации, ожидалось, что при наличии файла  /tmp/tres,  на запрос
> 
> http://127.0.0.1:8080/uno <http://127.0.0.1:8080/uno>
> 
> nginx вернет строку "uno  duo " или  "tres tres ", но никак не  "uno  tres ".
> 
> Т.е. URI основного запроса передается без изменений (как и описано в документации), а подзапроса - нет.
> Ситуация воспроизводится на nginx версий 1.7.9 - 1.7.12.
> 
> Отсюда вопрос: является ли подобное поведение задуманным или это бага?
> Будет ли меняться?  И не стоит ли отметить это в документации?
> 
> 
> 
>     server {
>         listen       8081;
>         default_type text/html;
> 
>         location /uno {   return 200 "uno  ";   }
>         location /duo {   return 200 "duo  ";   }
>         location /tres {   return 200 "tres  ";   }
>     }
> 
> 
>     server {
>         listen       8080;
> 
>         location / {
>             root /tmp;
>             try_files /tres =404;
>             proxy_pass http://127.0.0.1:8081 <http://127.0.0.1:8081/>;
>             add_after_body /duo;
>         }
>     }
> 
> 
> 
> --
> Regards,
> Eugene Mychlo MYC-RIPE EAMYC-RIPN
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org <mailto:nginx-ru at nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150421/a3d9cef4/attachment-0001.html>

From redmine24 at gmail.com  Tue Apr 21 09:35:47 2015
From: redmine24 at gmail.com (=?UTF-8?B?0JTQuNC80LAg0KDQtdC00LzQsNC50L0=?=)
Date: Tue, 21 Apr 2015 12:35:47 +0300
Subject: =?UTF-8?B?UmU6INCS0LvQvtC20LXQvdC90YvQuSBsb2NhdGlvbg==?=
In-Reply-To: <88ad2bbb5b36374e03276f5a50b13acc.NginxMailingListRussian@forum.nginx.org>
References: <88ad2bbb5b36374e03276f5a50b13acc.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAP8W4nBMe3FO7rAE9bvfRo5eSr6188pDvqXreeQ4C1qGF1Zt+g@mail.gmail.com>

В такой конфигурации на запрос /s/pix.jpg будет 404 ошибка. Если во
вложенный location добавить try_files /static/$img $uri; то все будет
работать нормально. Так и должно быть?

-- а файл /static/pix.jpg существует?

2015-04-21 11:29 GMT+03:00 dwow <nginx-forum at nginx.us>:

> Добрый день,
>
> Такой конфиг:
>
> location ~* /s/(?<static_file>.*) {
>         root /home/...;
>
>         open_file_cache          max=1000 inactive=20s;
>         try_files /static/$static_file $uri;
>
>         location ~* /s/(?<img>.*?\.(gif|png|jpg|jpeg)$) {
>             expires 30d;
>         }
> }
>
> В такой конфигурации на запрос /s/pix.jpg будет 404 ошибка. Если во
> вложенный location добавить try_files /static/$img $uri; то все будет
> работать нормально. Так и должно быть?
>
> И второй вопрос, если так и должно быть, то будет ли корректно работать
> open_file_cache во вложенных location, т.е. будут ли файлы кешироваться?
>
> Спасибо.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,258248,258248#msg-258248
>
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150421/05897e21/attachment.html>

From denis at webmaster.spb.ru  Tue Apr 21 09:59:56 2015
From: denis at webmaster.spb.ru (denis)
Date: Tue, 21 Apr 2015 12:59:56 +0300
Subject: =?UTF-8?Q?chrome_41_=D0=B8_err=5Fssl=5Fversion=5For=5Fcipher=5Fmismatch?=
Message-ID: <55361F9C.9030406@webmaster.spb.ru>

Добрый день.
Обнаружилось, что в новом хроме опять что-то сломали, и теперь 
err_ssl_version_or_cipher_mismatch. Нормальные браузеры и более старые 
хромы - работают. Может знает кто, что можно указать нгинху или куда 
пнуть хром. Сам сертификат RSA 2048 бит.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150421/9a53e192/attachment.html>

From aquatique at rusunix.org  Tue Apr 21 10:14:39 2015
From: aquatique at rusunix.org (Evgueni V. Gavrilov)
Date: Tue, 21 Apr 2015 16:14:39 +0600
Subject: =?UTF-8?Q?Re=3A_chrome_41_=D0=B8_err=5Fssl=5Fversion=5For=5Fcipher=5Fmisma?=
 =?UTF-8?Q?tch?=
In-Reply-To: <55361F9C.9030406@webmaster.spb.ru>
References: <55361F9C.9030406@webmaster.spb.ru>
Message-ID: <5536230F.1090304@rusunix.org>

http://googleonlinesecurity.blogspot.ru/2014/09/gradually-sunsetting-sha-1.html

On 21.04.2015 15:59, denis wrote:

> Добрый день.
> Обнаружилось, что в новом хроме опять что-то сломали, и теперь
> err_ssl_version_or_cipher_mismatch. Нормальные браузеры и более старые
> хромы - работают. Может знает кто, что можно указать нгинху или куда
> пнуть хром. Сам сертификат RSA 2048 бит.


From mdounin at mdounin.ru  Tue Apr 21 13:03:34 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 21 Apr 2015 16:03:34 +0300
Subject: =?UTF-8?B?UmU6INCS0LvQvtC20LXQvdC90YvQuSBsb2NhdGlvbg==?=
In-Reply-To: <88ad2bbb5b36374e03276f5a50b13acc.NginxMailingListRussian@forum.nginx.org>
References: <88ad2bbb5b36374e03276f5a50b13acc.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150421130334.GR32429@mdounin.ru>

Hello!

On Tue, Apr 21, 2015 at 04:29:37AM -0400, dwow wrote:

> Добрый день,
> 
> Такой конфиг:
> 
> location ~* /s/(?<static_file>.*) {
>         root /home/...;
> 
>         open_file_cache          max=1000 inactive=20s;
>         try_files /static/$static_file $uri;
> 
>         location ~* /s/(?<img>.*?\.(gif|png|jpg|jpeg)$) {
>             expires 30d;
>         }
> }
> 
> В такой конфигурации на запрос /s/pix.jpg будет 404 ошибка. Если во
> вложенный location добавить try_files /static/$img $uri; то все будет
> работать нормально. Так и должно быть?

Да, директива try_files во вложенный location - не наследуется.

> И второй вопрос, если так и должно быть, то будет ли корректно работать
> open_file_cache во вложенных location, т.е. будут ли файлы кешироваться?

Да.

-- 
Maxim Dounin
http://nginx.org/


From mdounin at mdounin.ru  Tue Apr 21 15:19:52 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 21 Apr 2015 18:19:52 +0300
Subject: nginx-1.8.0
Message-ID: <20150421151951.GW32429@mdounin.ru>

Изменения в nginx 1.8.0                                           21.04.2015

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


-- 
Maxim Dounin
http://nginx.org/


From mva at mva.name  Tue Apr 21 15:32:52 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Tue, 21 Apr 2015 21:32:52 +0600
Subject: nginx-1.8.0
In-Reply-To: <20150421151951.GW32429@mdounin.ru>
References: <20150421151951.GW32429@mdounin.ru>
Message-ID: <2148876.B7BQjyYu3J@note>

В письме от Вт, 21 апреля 2015 18:19:52 пользователь Maxim Dounin написал:
> Изменения в nginx 1.8.0                                           21.04.2015
> 
>     *) Стабильная ветка 1.8.x.

Я, конечно, предчуствовал, что выйдет 1.8, а не 1.7.13, но всё же интересно, а 
где же новый TCP-балансировщик, который из Plus перекинули? Не вошёл в релиз, 
чтоли? :)

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150421/d59a877d/attachment.bin>

From maxim at nginx.com  Tue Apr 21 15:44:28 2015
From: maxim at nginx.com (Maxim Konovalov)
Date: Tue, 21 Apr 2015 18:44:28 +0300
Subject: nginx-1.8.0
In-Reply-To: <2148876.B7BQjyYu3J@note>
References: <20150421151951.GW32429@mdounin.ru> <2148876.B7BQjyYu3J@note>
Message-ID: <5536705C.5090702@nginx.com>

On 4/21/15 6:32 PM, Vadim A. Misbakh-Soloviov wrote:
> В письме от Вт, 21 апреля 2015 18:19:52 пользователь Maxim Dounin написал:
>> Изменения в nginx 1.8.0                                           21.04.2015
>>
>>     *) Стабильная ветка 1.8.x.
> 
> Я, конечно, предчуствовал, что выйдет 1.8, а не 1.7.13, но всё же интересно, а 
> где же новый TCP-балансировщик, который из Plus перекинули? Не вошёл в релиз, 
> чтоли? :)
> 
Использовалась "секретная" магия бранчей.

Балансировщих будет в 1.9.0 в ближайшее время. Но никто не мешает
скачать исходники уже сейчас.

Предчувствия можно сверять с http://trac.nginx.org/nginx/roadmap

-- 
Maxim Konovalov
http://nginx.com


From nginx-forum at nginx.us  Tue Apr 21 15:50:30 2015
From: nginx-forum at nginx.us (S.A.N)
Date: Tue, 21 Apr 2015 11:50:30 -0400
Subject: nginx-1.8.0
In-Reply-To: <20150421151951.GW32429@mdounin.ru>
References: <20150421151951.GW32429@mdounin.ru>
Message-ID: <e1c2108bb2d52b8ab683f0d1ae012083.NginxMailingListRussian@forum.nginx.org>

mainline version будет 1.9, или будет только одна ветка stable а mainline
удалите?

Я спрашиваю, чтобы правильно отредактировать путь для repo в CentOS, сейчас
так:
http://nginx.org/packages/mainline/centos/7/$basearch/
Этот baseurl останется актуальным?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258271,258275#msg-258275


From mdounin at mdounin.ru  Tue Apr 21 16:25:10 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 21 Apr 2015 19:25:10 +0300
Subject: nginx-1.8.0
In-Reply-To: <e1c2108bb2d52b8ab683f0d1ae012083.NginxMailingListRussian@forum.nginx.org>
References: <20150421151951.GW32429@mdounin.ru>
 <e1c2108bb2d52b8ab683f0d1ae012083.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150421162509.GY32429@mdounin.ru>

Hello!

On Tue, Apr 21, 2015 at 11:50:30AM -0400, S.A.N wrote:

> mainline version будет 1.9, или будет только одна ветка stable а mainline
> удалите?

Mainline будет 1.9.0,
http://hg.nginx.org/nginx/rev/c1cae8b2270c

> Я спрашиваю, чтобы правильно отредактировать путь для repo в CentOS, сейчас
> так:
> http://nginx.org/packages/mainline/centos/7/$basearch/
> Этот baseurl останется актуальным?

Если не переходить на другой branch - то ничего менять не надо.

-- 
Maxim Dounin
http://nginx.org/


From mdounin at mdounin.ru  Tue Apr 21 19:11:35 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 21 Apr 2015 22:11:35 +0300
Subject: try_files + subrequest + proxy-handler
In-Reply-To: <1A16C0C0-D6FE-41CE-BBC4-F4FA095A30AC@cname.me>
References: <1A16C0C0-D6FE-41CE-BBC4-F4FA095A30AC@cname.me>
Message-ID: <20150421191135.GZ32429@mdounin.ru>

Hello!

On Mon, Apr 20, 2015 at 05:39:18PM +0300, Eugene Mychlo wrote:

> Добрый день,
> 
> Столкнулся со странной поведением nginx при использовании subrequest в сочетании с try_files с proxy-хэндлером.
> В приведенной ниже конфигурации, ожидалось, что при наличии файла  /tmp/tres,  на запрос
> 
> http://127.0.0.1:8080/uno
> 
> nginx вернет строку "uno  duo " или  "tres tres ", но никак не  "uno  tres ".
> 
> Т.е. URI основного запроса передается без изменений (как и описано в документации), а подзапроса - нет.
> Ситуация воспроизводится на nginx версий 1.7.9 - 1.7.12.
> 
> Отсюда вопрос: является ли подобное поведение задуманным или это бага?
> Будет ли меняться?  И не стоит ли отметить это в документации?
> 
> 
> 
>     server {
>         listen       8081;
>         default_type text/html;
> 
>         location /uno {   return 200 "uno  ";   }
>         location /duo {   return 200 "duo  ";   }
>         location /tres {   return 200 "tres  ";   }
>     }
> 
> 
>     server {
>         listen       8080;
> 
>         location / {
>             root /tmp;
>             try_files /tres =404;
>             proxy_pass http://127.0.0.1:8081;
>             add_after_body /duo;
>         }
>     }

Наблюдаемый эффект - следствие того, что try_files меняет URI 
запроса.  (Мне лично кажется, что это - скорее неправильное 
поведение.  По хорошему, ему следует оставлять URI тем же, а 
менять только соответствующий текущему URI файл.  Но именно так 
оно сейчас реализовано, и не совсем понятно, хотим ли мы это 
менять.  Когда делался try_files - какая-либо дальнейшая 
обработка, которая бы зависила от URI, просто не предполагалась, 
насколько я понимаю.)

При этом try_files используется как для обработки основного 
запроса, так и для подзапроса.   Т.е. $uri в обоих случаях в 
момент проксирования - "/tres".

Однако при этом URI основного запроса считается низменённым 
(потому что по хорошему try_files URI менять не должен, см. выше), 
и соответственно соединение с бекендом (ибо proxy_pass без URI) 
использует исходный URI запроса в том виде, как он был передан 
клиентом, "/uno".  В подзапросе же URI заведомо изменён, и 
proxy_pass в соответствии с документацией использует 
нормализованный URI запроса целиком, т.е. "/tres".

Возможных решений представляется два:

- переделать try_files так, чтобы URI не менялся, тогда будет "uno 
  duo";

- узаконить текущее поведение try_files и при изменении им URI 
  сбрасывать флаг r->valid_unparsed_uri, тогда будет "tres tres".

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

Ну и да, текущее поведение - явно баг, имеет смысл добавить на 
trac.nginx.org.

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Wed Apr 22 09:23:55 2015
From: nginx-forum at nginx.us (vlakas)
Date: Wed, 22 Apr 2015 05:23:55 -0400
Subject: =?UTF-8?B?0J3QtdC60L7QvdGC0YDQvtC70LvQuNGA0YPQtdC80YvQuSDQvtCx0YrQtdC8INC6?=
 =?UTF-8?B?0LXRiNCwIE5naW54?=
Message-ID: <fa4be5fb2cc5f4348a33820da3ec7c59.NginxMailingListRussian@forum.nginx.org>

Здравствуйте.

Время от времени на серверах с Nginx наблюдается рость объема кеша, который
превышает значение max_size. Это приводит к тому, что свободного места на
разделе, где находится кешь, практически не остается. При этом в error.log я
ничего подозрительного не вижу.

Определение кеша в nginx.conf:
proxy_cache_path  /opt2/nginx-cache-images1  max_size=150g levels=2:2 
keys_zone=images1:1024m inactive=24h;
proxy_temp_path   /opt2/proxy_temp 1 2;

Объем /opt2/nginx-cache-images1 на данный момент около 200G.

В конфиге сайта:
    location / {
       proxy_set_header Host      $host;
       proxy_set_header X-Forwarded-For $remote_addr;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Is-Referer-Search-Engine
$is_referer_search_engine;
       proxy_hide_header Set-Cookie;
       proxy_hide_header Content-Disposition;
       proxy_pass http://ua-image-proxy;
       default_type image/jpeg;

       proxy_cache images1;
       proxy_cache_key ua$request_uri$is_referer_search_engine;
       proxy_cache_valid 200 24h;
       proxy_cache_valid 301 24h;
       proxy_cache_valid 404 1h;
    }

Такое поведение наблюдается на nginx версий 1.7.7 и 1.7.9.
Nginx собирался из исходников на Ubuntu 14.04 со следующими опциями:
--with-http_stub_status_module --with-http_gzip_static_module         
--with-http_ssl_module --with-file-aio --with-http_realip_module
--with-http_dav_module 
--add-module=/opt/workspace/infrastructure/server/nginx/nginx-x-rid-header
--with-ld-opt=-luuid

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

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258292#msg-258292


From arut at nginx.com  Wed Apr 22 10:54:20 2015
From: arut at nginx.com (Roman Arutyunyan)
Date: Wed, 22 Apr 2015 13:54:20 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?=
 =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?=
In-Reply-To: <fa4be5fb2cc5f4348a33820da3ec7c59.NginxMailingListRussian@forum.nginx.org>
References: <fa4be5fb2cc5f4348a33820da3ec7c59.NginxMailingListRussian@forum.nginx.org>
Message-ID: <55348F60-6420-4165-A4E0-DAEB37D1E872@nginx.com>

Добрый день.

On 22 Apr 2015, at 12:23, vlakas <nginx-forum at nginx.us> wrote:

> Здравствуйте.
> 
> Время от времени на серверах с Nginx наблюдается рость объема кеша, который
> превышает значение max_size. Это приводит к тому, что свободного места на
> разделе, где находится кешь, практически не остается. При этом в error.log я
> ничего подозрительного не вижу.

Не замечали, при перезапуске nginx размер приходит в норму?

Было бы здорово, если бы вы предоставили информацию о том, что происходит с
процессом nginx cache manager, например, для начала, его strace.

> Определение кеша в nginx.conf:
> proxy_cache_path  /opt2/nginx-cache-images1  max_size=150g levels=2:2 
> keys_zone=images1:1024m inactive=24h;
> proxy_temp_path   /opt2/proxy_temp 1 2;
> 
> Объем /opt2/nginx-cache-images1 на данный момент около 200G.
> 
> В конфиге сайта:
>    location / {
>       proxy_set_header Host      $host;
>       proxy_set_header X-Forwarded-For $remote_addr;
>       proxy_set_header X-Real-IP $remote_addr;
>       proxy_set_header X-Is-Referer-Search-Engine
> $is_referer_search_engine;
>       proxy_hide_header Set-Cookie;
>       proxy_hide_header Content-Disposition;
>       proxy_pass http://ua-image-proxy;
>       default_type image/jpeg;
> 
>       proxy_cache images1;
>       proxy_cache_key ua$request_uri$is_referer_search_engine;
>       proxy_cache_valid 200 24h;
>       proxy_cache_valid 301 24h;
>       proxy_cache_valid 404 1h;
>    }
> 
> Такое поведение наблюдается на nginx версий 1.7.7 и 1.7.9.
> Nginx собирался из исходников на Ubuntu 14.04 со следующими опциями:
> --with-http_stub_status_module --with-http_gzip_static_module         
> --with-http_ssl_module --with-file-aio --with-http_realip_module
> --with-http_dav_module 
> --add-module=/opt/workspace/infrastructure/server/nginx/nginx-x-rid-header
> --with-ld-opt=-luuid
> 
> Не могу понять, в каком направлении двигаться, чтобы решить проблему.
> 
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258292#msg-258292
> 
> _______________________________________________
> 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  Wed Apr 22 11:43:29 2015
From: nginx-forum at nginx.us (vlakas)
Date: Wed, 22 Apr 2015 07:43:29 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?=
 =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?=
In-Reply-To: <55348F60-6420-4165-A4E0-DAEB37D1E872@nginx.com>
References: <55348F60-6420-4165-A4E0-DAEB37D1E872@nginx.com>
Message-ID: <527f364c0b6d1e4e5fee84b73e4be61c.NginxMailingListRussian@forum.nginx.org>

Роман, спасибо за ответ.

strace процесса cache manager с работающего сервера (идентичная конфигурация
nginx):

epoll_wait(12, {}, 512, 10000)          = 0
unlink("/opt2/nginx-cache-images1/f6/2f/6c5feae527bdfb8bbbee50e07ceb2ff6") =
0
unlink("/opt2/nginx-cache-images1/e3/90/0d645cceeb8db22b90cd393cb3db90e3") =
0
unlink("/opt2/nginx-cache-images1/c1/ab/72c757a6fa44b3e7c21485949cccabc1") =
0
unlink("/opt2/nginx-cache-images1/7c/03/ce6ce5bf9e889c34b644ed56769b037c") =
0
unlink("/opt2/nginx-cache-images1/79/cf/47ef548f228fe8b0c18e18128273cf79") =
0
unlink("/opt2/nginx-cache-images1/02/95/59729c74c06cf7821f8682073b589502") =
0
unlink("/opt2/nginx-cache-images1/c3/7d/950fccf0745b37729ddfcc79f5b07dc3") =
0
unlink("/opt2/nginx-cache-images1/5e/95/52524d64d629b2d2ead42d6dc429955e") =
0
unlink("/opt2/nginx-cache-images1/5e/47/c42624d6470ae1ff7ec3f3d847d1475e") =
0
unlink("/opt2/nginx-cache-images1/37/e0/977b6db01688432805a51a9da636e037") =
0
unlink("/opt2/nginx-cache-images1/44/82/768cd3ff0b155a08eda7cfbc42908244") =
0
unlink("/opt2/nginx-cache-images1/f5/fd/add21bd75624036ae9c6603e63eafdf5") =
0
unlink("/opt2/nginx-cache-images1/5f/ea/a71f1b85f340dcd07710388d5505ea5f") =
0
epoll_wait(12, {}, 512, 10000)          = 0
unlink("/opt2/nginx-cache-images1/e1/bd/cf70c8a3a732e8178d0ea35d73b6bde1") =
0

Ниже - с проблемного сервера:

epoll_wait(12, {}, 512, 1000)           = 0
epoll_wait(12, {}, 512, 1000)           = 0
epoll_wait(12, {}, 512, 1000)           = 0
epoll_wait(12, {}, 512, 1000)           = 0
epoll_wait(12, {}, 512, 1000)           = 0
epoll_wait(12, {}, 512, 1000)           = 0
epoll_wait(12, {}, 512, 1000)           = 0
epoll_wait(12, {}, 512, 1000)           = 0
epoll_wait(12, {}, 512, 1000)           = 0
epoll_wait(12, {}, 512, 1000)           = 0
epoll_wait(12, {}, 512, 1000)           = 0

И более ничего. Хотя, что самое интересно, в логах я вижу cache hit на обоих
серверах.

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

При рестарте сервиса nginx запускается cache loader и объем кеша продолжает
расти (насколько я понимаю, при этом кеш неуправляем), но затем объем кеша
приходит в норму.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258297#msg-258297


From arut at nginx.com  Wed Apr 22 12:20:02 2015
From: arut at nginx.com (Roman Arutyunyan)
Date: Wed, 22 Apr 2015 15:20:02 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?=
 =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?=
In-Reply-To: <527f364c0b6d1e4e5fee84b73e4be61c.NginxMailingListRussian@forum.nginx.org>
References: <55348F60-6420-4165-A4E0-DAEB37D1E872@nginx.com>
 <527f364c0b6d1e4e5fee84b73e4be61c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <68BFD438-2ACC-4A8E-BC52-61F44F04A91E@nginx.com>


On 22 Apr 2015, at 14:43, vlakas <nginx-forum at nginx.us> wrote:

> Роман, спасибо за ответ.
> 
> strace процесса cache manager с работающего сервера (идентичная конфигурация
> nginx):
> 
> epoll_wait(12, {}, 512, 10000)          = 0
> unlink("/opt2/nginx-cache-images1/f6/2f/6c5feae527bdfb8bbbee50e07ceb2ff6") =
> 0
> unlink("/opt2/nginx-cache-images1/e3/90/0d645cceeb8db22b90cd393cb3db90e3") =
> 0
> unlink("/opt2/nginx-cache-images1/c1/ab/72c757a6fa44b3e7c21485949cccabc1") =
> 0
> unlink("/opt2/nginx-cache-images1/7c/03/ce6ce5bf9e889c34b644ed56769b037c") =
> 0
> unlink("/opt2/nginx-cache-images1/79/cf/47ef548f228fe8b0c18e18128273cf79") =
> 0
> unlink("/opt2/nginx-cache-images1/02/95/59729c74c06cf7821f8682073b589502") =
> 0
> unlink("/opt2/nginx-cache-images1/c3/7d/950fccf0745b37729ddfcc79f5b07dc3") =
> 0
> unlink("/opt2/nginx-cache-images1/5e/95/52524d64d629b2d2ead42d6dc429955e") =
> 0
> unlink("/opt2/nginx-cache-images1/5e/47/c42624d6470ae1ff7ec3f3d847d1475e") =
> 0
> unlink("/opt2/nginx-cache-images1/37/e0/977b6db01688432805a51a9da636e037") =
> 0
> unlink("/opt2/nginx-cache-images1/44/82/768cd3ff0b155a08eda7cfbc42908244") =
> 0
> unlink("/opt2/nginx-cache-images1/f5/fd/add21bd75624036ae9c6603e63eafdf5") =
> 0
> unlink("/opt2/nginx-cache-images1/5f/ea/a71f1b85f340dcd07710388d5505ea5f") =
> 0
> epoll_wait(12, {}, 512, 10000)          = 0
> unlink("/opt2/nginx-cache-images1/e1/bd/cf70c8a3a732e8178d0ea35d73b6bde1") =
> 0
> 
> Ниже - с проблемного сервера:
> 
> epoll_wait(12, {}, 512, 1000)           = 0
> epoll_wait(12, {}, 512, 1000)           = 0
> epoll_wait(12, {}, 512, 1000)           = 0
> epoll_wait(12, {}, 512, 1000)           = 0
> epoll_wait(12, {}, 512, 1000)           = 0
> epoll_wait(12, {}, 512, 1000)           = 0
> epoll_wait(12, {}, 512, 1000)           = 0
> epoll_wait(12, {}, 512, 1000)           = 0
> epoll_wait(12, {}, 512, 1000)           = 0
> epoll_wait(12, {}, 512, 1000)           = 0
> epoll_wait(12, {}, 512, 1000)           = 0
> 
> И более ничего. Хотя, что самое интересно, в логах я вижу cache hit на обоих
> серверах.
> 
> "проблемный" и "рабочий" серверы - условное обозначение, поскольку на
> "работающем" сервере может произойти то же самое.
> 
> При рестарте сервиса nginx запускается cache loader и объем кеша продолжает
> расти (насколько я понимаю, при этом кеш неуправляем), но затем объем кеша
> приходит в норму.
> 
> Posted at Nginx Forum: http://forum.ngin

Debug log не могли бы настроить?  Он будет большой, но интересует лишь его
фрагмент в тот период, когда проявляется проблема.

http://nginx.org/ru/docs/debugging_log.html

From nginx-forum at nginx.us  Wed Apr 22 12:21:14 2015
From: nginx-forum at nginx.us (konev)
Date: Wed, 22 Apr 2015 08:21:14 -0400
Subject: =?UTF-8?B?0JLQt9Cw0LjQvNC+0LTQtdC50YHRgtCy0LjQtSDRgSBPcGVuU1NM?=
Message-ID: <b7091b967367adfe1934a8b2ace8d93f.NginxMailingListRussian@forum.nginx.org>

Добрый день.

При реализации проекта заказчик попросил ответить на следующие вопросы
относительно взаимодействия Nginx c сертифицированной ФСБ версией OpenSSL
(обычная openSSL только с бумажкой от ФСБ):
1. Выполнение рекомендаций, изложенных в руководстве программиста
соответствующего СКЗИ, т.е. используется ли при взаимодействии с openSSL
только документированное высокоуровневое API?
2. Осуществляется ли очистка памяти после выполнения криптографических
операций (удаление из памяти ключевой информации, контекстов хэша,
криптопровайдера и т.д.)?
3. Правильно ли производится обработка Nginx ошибочных ситуаций при
взаимодействии с СКЗИ? 
4. Осуществляются ли следующие проверки перед выполнением криптографической
операции: 
- сроков действия используемых сертификатов, списка отозванных
сертификатов;
- отсутствия используемых сертификатов в списке отозванных сертификатов;
- соответствия используемых сертификатов области применения (должна быть
исключена возможность использования сертификата, предназначенного только для
шифрования, при формировании ЭП);
- правильности построения цепочки используемых сертификатов, списка
отозванных сертификатов (если цепочка заключается в связке ?сертификат ?
корневой сертификат?, ?СОС - корневой сертификат?, то проверка цепочки
заключается в проверке подписи сертификата, СОС на корневом сертификате).

Можете, пожалуйста, что-то подсказать?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258298,258298#msg-258298


From nginx-forum at nginx.us  Wed Apr 22 12:38:11 2015
From: nginx-forum at nginx.us (vlakas)
Date: Wed, 22 Apr 2015 08:38:11 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?=
 =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?=
In-Reply-To: <68BFD438-2ACC-4A8E-BC52-61F44F04A91E@nginx.com>
References: <68BFD438-2ACC-4A8E-BC52-61F44F04A91E@nginx.com>
Message-ID: <056aa5987754a9c04384696e335b1470.NginxMailingListRussian@forum.nginx.org>

Да, настрою дебаг. Думаю, что зерез пару дней смогу предоставить логи.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258300#msg-258300


From arut at nginx.com  Wed Apr 22 12:44:41 2015
From: arut at nginx.com (Roman Arutyunyan)
Date: Wed, 22 Apr 2015 15:44:41 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?=
 =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?=
In-Reply-To: <056aa5987754a9c04384696e335b1470.NginxMailingListRussian@forum.nginx.org>
References: <68BFD438-2ACC-4A8E-BC52-61F44F04A91E@nginx.com>
 <056aa5987754a9c04384696e335b1470.NginxMailingListRussian@forum.nginx.org>
Message-ID: <AD4FAEA9-9038-47C9-BAEC-4DB2CC945986@nginx.com>


On 22 Apr 2015, at 15:38, vlakas <nginx-forum at nginx.us> wrote:

> Да, настрою дебаг. Думаю, что зерез пару дней смогу предоставить логи.

Еще:

* убедитесь, что воркеры не падали с момента запуска nginx.  У вас вкомпилен
third-party модуль, это может приводить к нестабильности.

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

From nginx-forum at nginx.us  Thu Apr 23 11:03:12 2015
From: nginx-forum at nginx.us (itcod)
Date: Thu, 23 Apr 2015 07:03:12 -0400
Subject: =?UTF-8?B?0LrQsNC6INCy0YvQstC10YHRgtC4INGA0YPRgdGB0LrQuNC1INCx0YPQutCy0Ysg?=
 =?UTF-8?B?0LIg0L7QutC90LUg0LDQstGC0L7RgNC40LfQsNGG0LjQuA==?=
Message-ID: <cacf56685de716b8ed377cd090dbb34b.NginxMailingListRussian@forum.nginx.org>

Здравствуйте уважаемые!

в секции server имею запись
charset utf-8;

в location имею
auth_basic "Авторизация"
auth_basic_user_file /path/.htaccess

Открываю браузерами и вижу в окне запроса юзера+пароля
????²?????????·?°???????

curl показывает заголовок content-type "text/html; charset=utf-8"
видимо браузеры не понимают что в WWW-Authenticate кодировка utf-8

Подскажите плиззз как это вылечить. Как браузерам сообщить в какой кодировке
передан им хидер WWW-Authenticate

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258313,258313#msg-258313


From nginx-forum at nginx.us  Thu Apr 23 11:49:46 2015
From: nginx-forum at nginx.us (itcod)
Date: Thu, 23 Apr 2015 07:49:46 -0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDQstGL0LLQtdGB0YLQuCDRgNGD0YHRgdC60LjQtSDQsdGD0Lo=?=
 =?UTF-8?B?0LLRiyDQsiDQvtC60L3QtSDQsNCy0YLQvtGA0LjQt9Cw0YbQuNC4?=
In-Reply-To: <cacf56685de716b8ed377cd090dbb34b.NginxMailingListRussian@forum.nginx.org>
References: <cacf56685de716b8ed377cd090dbb34b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <91ab513e72212837801187fc32e2ed79.NginxMailingListRussian@forum.nginx.org>

нарыл вот этот документ
The 'Basic' HTTP Authentication Scheme
draft-ietf-httpauth-basicauth-update-07
https://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-07#section-2.1

где описывается вот такая схема:
WWW-Authenticate: Basic realm="foo", charset="UTF-8"

а работает ли такое в nginx?
у меня что то не сработало из lua.... 
да и как в стандартный auth_basic такую конструкцию вписать......
???

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258313,258316#msg-258316


From nginx-forum at nginx.us  Thu Apr 23 11:55:06 2015
From: nginx-forum at nginx.us (itcod)
Date: Thu, 23 Apr 2015 07:55:06 -0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDQstGL0LLQtdGB0YLQuCDRgNGD0YHRgdC60LjQtSDQsdGD0Lo=?=
 =?UTF-8?B?0LLRiyDQsiDQvtC60L3QtSDQsNCy0YLQvtGA0LjQt9Cw0YbQuNC4?=
In-Reply-To: <91ab513e72212837801187fc32e2ed79.NginxMailingListRussian@forum.nginx.org>
References: <cacf56685de716b8ed377cd090dbb34b.NginxMailingListRussian@forum.nginx.org>
 <91ab513e72212837801187fc32e2ed79.NginxMailingListRussian@forum.nginx.org>
Message-ID: <49519f97fa6dac748eb8cba7a7e138ef.NginxMailingListRussian@forum.nginx.org>

> у меня что то не сработало из lua....
ошибся сработало.... только похоже браузеры не поняли этой конструкции.... 
походу этот вариант неживой ещё...
а как тогда?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258313,258318#msg-258318


From chipitsine at gmail.com  Thu Apr 23 13:15:12 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 23 Apr 2015 18:15:12 +0500
Subject: =?UTF-8?B?UmU6INC60LDQuiDQstGL0LLQtdGB0YLQuCDRgNGD0YHRgdC60LjQtSDQsdGD0Lo=?=
 =?UTF-8?B?0LLRiyDQsiDQvtC60L3QtSDQsNCy0YLQvtGA0LjQt9Cw0YbQuNC4?=
In-Reply-To: <49519f97fa6dac748eb8cba7a7e138ef.NginxMailingListRussian@forum.nginx.org>
References: <cacf56685de716b8ed377cd090dbb34b.NginxMailingListRussian@forum.nginx.org>
 <91ab513e72212837801187fc32e2ed79.NginxMailingListRussian@forum.nginx.org>
 <49519f97fa6dac748eb8cba7a7e138ef.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQHAenYEG9MOxUjoBX02TS_d84rjkiJFF_viFeXQcsLY3Q@mail.gmail.com>

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

вариант - отправлять латиницу, а при декодировании проверять кирилицу
в нескольких кодировках

23 апреля 2015 г., 16:55 пользователь itcod <nginx-forum at nginx.us> написал:
>> у меня что то не сработало из lua....
> ошибся сработало.... только похоже браузеры не поняли этой конструкции....
> походу этот вариант неживой ещё...
> а как тогда?
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258313,258318#msg-258318
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Thu Apr 23 13:31:15 2015
From: nginx-forum at nginx.us (itcod)
Date: Thu, 23 Apr 2015 09:31:15 -0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDQstGL0LLQtdGB0YLQuCDRgNGD0YHRgdC60LjQtSDQsdGD0Lo=?=
 =?UTF-8?B?0LLRiyDQsiDQvtC60L3QtSDQsNCy0YLQvtGA0LjQt9Cw0YbQuNC4?=
In-Reply-To: <CAFHpkQHAenYEG9MOxUjoBX02TS_d84rjkiJFF_viFeXQcsLY3Q@mail.gmail.com>
References: <CAFHpkQHAenYEG9MOxUjoBX02TS_d84rjkiJFF_viFeXQcsLY3Q@mail.gmail.com>
Message-ID: <2cded8fa8a6efa1e19527fff7b1d17ea.NginxMailingListRussian@forum.nginx.org>

Илья добрый день!
Та чво тут удивляться:) сколько идей столько и велосипедов:)

я так понимаю, что раз эти вопросы с кодировками базовой авторизации за 20
лет так и не утрясли на уровне стандартов... то тоже придётся свой вилисАпед
выпиливать.... или колеса отпилить:))))))
"пилите Шура"(с)Osя :))))

Спасибо Илья!

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258313,258322#msg-258322


From chipitsine at gmail.com  Thu Apr 23 13:33:38 2015
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 23 Apr 2015 18:33:38 +0500
Subject: =?UTF-8?B?UmU6INC60LDQuiDQstGL0LLQtdGB0YLQuCDRgNGD0YHRgdC60LjQtSDQsdGD0Lo=?=
 =?UTF-8?B?0LLRiyDQsiDQvtC60L3QtSDQsNCy0YLQvtGA0LjQt9Cw0YbQuNC4?=
In-Reply-To: <2cded8fa8a6efa1e19527fff7b1d17ea.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQHAenYEG9MOxUjoBX02TS_d84rjkiJFF_viFeXQcsLY3Q@mail.gmail.com>
 <2cded8fa8a6efa1e19527fff7b1d17ea.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQF7-PgADm1dejCxmqzc=nF7A-XOgwY6ywcfdq+11z=viw@mail.gmail.com>

с кодировками на самом деле все хорошо если в авторизации не
использовать кирилицу

23 апреля 2015 г., 18:31 пользователь itcod <nginx-forum at nginx.us> написал:
> Илья добрый день!
> Та чво тут удивляться:) сколько идей столько и велосипедов:)
>
> я так понимаю, что раз эти вопросы с кодировками базовой авторизации за 20
> лет так и не утрясли на уровне стандартов... то тоже придётся свой вилисАпед
> выпиливать.... или колеса отпилить:))))))
> "пилите Шура"(с)Osя :))))
>
> Спасибо Илья!
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258313,258322#msg-258322
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From mdounin at mdounin.ru  Thu Apr 23 13:37:11 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 23 Apr 2015 16:37:11 +0300
Subject: =?UTF-8?B?UmU6INC60LDQuiDQstGL0LLQtdGB0YLQuCDRgNGD0YHRgdC60LjQtSDQsdGD0Lo=?=
 =?UTF-8?B?0LLRiyDQsiDQvtC60L3QtSDQsNCy0YLQvtGA0LjQt9Cw0YbQuNC4?=
In-Reply-To: <49519f97fa6dac748eb8cba7a7e138ef.NginxMailingListRussian@forum.nginx.org>
References: <cacf56685de716b8ed377cd090dbb34b.NginxMailingListRussian@forum.nginx.org>
 <91ab513e72212837801187fc32e2ed79.NginxMailingListRussian@forum.nginx.org>
 <49519f97fa6dac748eb8cba7a7e138ef.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150423133711.GG32429@mdounin.ru>

Hello!

On Thu, Apr 23, 2015 at 07:55:06AM -0400, itcod wrote:

> > у меня что то не сработало из lua....
> ошибся сработало.... только похоже браузеры не поняли этой конструкции.... 
> походу этот вариант неживой ещё...
> а как тогда?

Никак.
Для воодушевления можно почитать, например, вот этот баг:

https://bugzilla.mozilla.org/show_bug.cgi?id=41489

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Thu Apr 23 13:52:16 2015
From: nginx-forum at nginx.us (itcod)
Date: Thu, 23 Apr 2015 09:52:16 -0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDQstGL0LLQtdGB0YLQuCDRgNGD0YHRgdC60LjQtSDQsdGD0Lo=?=
 =?UTF-8?B?0LLRiyDQsiDQvtC60L3QtSDQsNCy0YLQvtGA0LjQt9Cw0YbQuNC4?=
In-Reply-To: <CAFHpkQF7-PgADm1dejCxmqzc=nF7A-XOgwY6ywcfdq+11z=viw@mail.gmail.com>
References: <CAFHpkQF7-PgADm1dejCxmqzc=nF7A-XOgwY6ywcfdq+11z=viw@mail.gmail.com>
Message-ID: <e3f2a2a8f6a133d7eb44df1759dd3bf6.NginxMailingListRussian@forum.nginx.org>

:))))))))) 
конечно солидарен!!! 
сферический конь в идеальном вакууме идеален по определению:)))))

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258313,258326#msg-258326


From nginx-forum at nginx.us  Thu Apr 23 14:03:49 2015
From: nginx-forum at nginx.us (itcod)
Date: Thu, 23 Apr 2015 10:03:49 -0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDQstGL0LLQtdGB0YLQuCDRgNGD0YHRgdC60LjQtSDQsdGD0Lo=?=
 =?UTF-8?B?0LLRiyDQsiDQvtC60L3QtSDQsNCy0YLQvtGA0LjQt9Cw0YbQuNC4?=
In-Reply-To: <20150423133711.GG32429@mdounin.ru>
References: <20150423133711.GG32429@mdounin.ru>
Message-ID: <160a1abc1c26fc706438965fa397d754.NginxMailingListRussian@forum.nginx.org>

Максим добрый день!
позитивное чтиво:))) сенькс....
5лет без результата.... знач ещё не менее 10ти будут кота за хвост
таскать:)))

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258313,258327#msg-258327


From mdounin at mdounin.ru  Thu Apr 23 14:06:48 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 23 Apr 2015 17:06:48 +0300
Subject: =?UTF-8?B?UmU6INC60LDQuiDQstGL0LLQtdGB0YLQuCDRgNGD0YHRgdC60LjQtSDQsdGD0Lo=?=
 =?UTF-8?B?0LLRiyDQsiDQvtC60L3QtSDQsNCy0YLQvtGA0LjQt9Cw0YbQuNC4?=
In-Reply-To: <160a1abc1c26fc706438965fa397d754.NginxMailingListRussian@forum.nginx.org>
References: <20150423133711.GG32429@mdounin.ru>
 <160a1abc1c26fc706438965fa397d754.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150423140647.GI32429@mdounin.ru>

Hello!

On Thu, Apr 23, 2015 at 10:03:49AM -0400, itcod wrote:

> Максим добрый день!
> позитивное чтиво:))) сенькс....
> 5лет без результата.... знач ещё не менее 10ти будут кота за хвост
> таскать:)))

Баг открыт 2000-06-04, скоро будет 15.

-- 
Maxim Dounin
http://nginx.org/


From nginx-forum at nginx.us  Thu Apr 23 14:15:20 2015
From: nginx-forum at nginx.us (itcod)
Date: Thu, 23 Apr 2015 10:15:20 -0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDQstGL0LLQtdGB0YLQuCDRgNGD0YHRgdC60LjQtSDQsdGD0Lo=?=
 =?UTF-8?B?0LLRiyDQsiDQvtC60L3QtSDQsNCy0YLQvtGA0LjQt9Cw0YbQuNC4?=
In-Reply-To: <20150423140647.GI32429@mdounin.ru>
References: <20150423140647.GI32429@mdounin.ru>
Message-ID: <470495236719b4150ce487366c84677c.NginxMailingListRussian@forum.nginx.org>

о точно.... я прочел что 2000... и чвото у мня калькулятор сбойнул:)))))
15 лет.... imho неверно задача поставлена похоже....
вот и не решается:)

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258313,258329#msg-258329


From simplebox66 at gmail.com  Thu Apr 23 14:16:19 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Thu, 23 Apr 2015 17:16:19 +0300
Subject: =?UTF-8?Q?syslog_=D0=B2_nginx_1=2E8?=
Message-ID: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>

Добрый вечер!

Обновил nginx то версии 1.8. и пытаюсь наладить syslog в сторону сислог
сервера с ip адресом x.x.x.x. При этом ip на котором крутиться nginx y.y.y.y

Конфиг
 access_log syslog:server=x.x.x.x:415,facility=local4,tag=ololo main;

В итоге в логах пусто, а tcpdump выдает следующее

tcpdump  -vv -nn -i eth0 port 415

17:06:49.298620 IP (tos 0x0, ttl 64, id 16905, offset 0, flags [DF], proto
UDP (17), length 462)
    y.y.y.y.56811 > x.x.x.x.415: [bad udp cksum 7a11!] UDP, length 434

В чем может быть проблема?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150423/20a9312e/attachment.html>

From simplebox66 at gmail.com  Thu Apr 23 14:40:34 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Thu, 23 Apr 2015 17:40:34 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
References: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
Message-ID: <CA+ksgACuUbm7m1gwZ7vJU99VGvjN_1hBp-=0uerv2E8YLkAVeA@mail.gmail.com>

Кажется понял, проблема в proto UDP , а мне надо proto TCP.
Как заставить nginx юзать TCP ?

23 апреля 2015 г., 17:16 пользователь Иван Мишин <simplebox66 at gmail.com>
написал:

> Добрый вечер!
>
> Обновил nginx то версии 1.8. и пытаюсь наладить syslog в сторону сислог
> сервера с ip адресом x.x.x.x. При этом ip на котором крутиться nginx y.y.y.y
>
> Конфиг
>  access_log syslog:server=x.x.x.x:415,facility=local4,tag=ololo main;
>
> В итоге в логах пусто, а tcpdump выдает следующее
>
> tcpdump  -vv -nn -i eth0 port 415
>
> 17:06:49.298620 IP (tos 0x0, ttl 64, id 16905, offset 0, flags [DF], proto
> UDP (17), length 462)
>     y.y.y.y.56811 > x.x.x.x.415: [bad udp cksum 7a11!] UDP, length 434
>
> В чем может быть проблема?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150423/1d682940/attachment-0001.html>

From onokonem at gmail.com  Thu Apr 23 14:45:56 2015
From: onokonem at gmail.com (Daniel Podolsky)
Date: Thu, 23 Apr 2015 17:45:56 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <CA+ksgACuUbm7m1gwZ7vJU99VGvjN_1hBp-=0uerv2E8YLkAVeA@mail.gmail.com>
References: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
 <CA+ksgACuUbm7m1gwZ7vJU99VGvjN_1hBp-=0uerv2E8YLkAVeA@mail.gmail.com>
Message-ID: <CAKaHDOE+9BeBxN77_3x88u74psteLfRrotEDFQHLPPUr-NthYg@mail.gmail.com>

> Кажется понял, проблема в proto UDP , а мне надо proto TCP.
> Как заставить nginx юзать TCP ?
ну зачем же вам TCP? чтобы все встало, если на той стороне лег syslog?

From simplebox66 at gmail.com  Thu Apr 23 14:50:54 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Thu, 23 Apr 2015 17:50:54 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <CAKaHDOE+9BeBxN77_3x88u74psteLfRrotEDFQHLPPUr-NthYg@mail.gmail.com>
References: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
 <CA+ksgACuUbm7m1gwZ7vJU99VGvjN_1hBp-=0uerv2E8YLkAVeA@mail.gmail.com>
 <CAKaHDOE+9BeBxN77_3x88u74psteLfRrotEDFQHLPPUr-NthYg@mail.gmail.com>
Message-ID: <CA+ksgAAmqhGAj6q-D6eUVxgHKWu3Oa0hDXN4BXrB4LBE3fVERw@mail.gmail.com>

сислог сервер уже использует TCP и изменять это я не в праве.

23 апреля 2015 г., 17:45 пользователь Daniel Podolsky <onokonem at gmail.com>
написал:

> > Кажется понял, проблема в proto UDP , а мне надо proto TCP.
> > Как заставить nginx юзать TCP ?
> ну зачем же вам TCP? чтобы все встало, если на той стороне лег syslog?
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150423/652b581a/attachment.html>

From onokonem at gmail.com  Thu Apr 23 15:04:02 2015
From: onokonem at gmail.com (Daniel Podolsky)
Date: Thu, 23 Apr 2015 18:04:02 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <CA+ksgAAmqhGAj6q-D6eUVxgHKWu3Oa0hDXN4BXrB4LBE3fVERw@mail.gmail.com>
References: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
 <CA+ksgACuUbm7m1gwZ7vJU99VGvjN_1hBp-=0uerv2E8YLkAVeA@mail.gmail.com>
 <CAKaHDOE+9BeBxN77_3x88u74psteLfRrotEDFQHLPPUr-NthYg@mail.gmail.com>
 <CA+ksgAAmqhGAj6q-D6eUVxgHKWu3Oa0hDXN4BXrB4LBE3fVERw@mail.gmail.com>
Message-ID: <CAKaHDOE5M-3arBf=NczHqpV6ZzkE3WCgPUJ-5fkAQNN4NCTfGw@mail.gmail.com>

2015-04-23 17:50 GMT+03:00 Иван Мишин <simplebox66 at gmail.com>:
> сислог сервер уже использует TCP и изменять это я не в праве.
ну тогда надо, наверное, выяснить, умеет ли nginx слать логи по tcp. а
потом озаботиться настройког syslog на localhost для проксирования из
udp в tcp

From nginx-forum at nginx.us  Thu Apr 23 19:18:56 2015
From: nginx-forum at nginx.us (itcod)
Date: Thu, 23 Apr 2015 15:18:56 -0400
Subject: =?UTF-8?B?0LfQsNCx0YvQuyDRgdC70Y3RiCDQsiDQutC+0L3RhtC1IHVybCDQv9C+0LvRg9GH?=
 =?UTF-8?B?0LjQuyDRgdGD0YHQsNC90LjQvS1hdXRvaW5kZXg=?=
Message-ID: <5966c39551854d7c76a86cabed427f25.NginxMailingListRussian@forum.nginx.org>

Добрый день уважаемые!
Столкнулся с странным поведением толи браузеров... толи autoindex в
location... толи своими кривыми ручками.... Странность проявляется в
различном отображении путей ссылок (нижняя строка браузера) при наведении на
ссылку в листинге autoindex. Проявляется при отсутствии закрывающего слэша в
url
Можете взлянуть вживую
пример правильного поведения: http://ihome.itcod.com/max/projects/ 
пример неправильного поведения: http://ihome.itcod.com/max/projects 
(СЛЭШ ЗАКРЫВАЮЩИЙ ЗАБЫЛ:))

В обоих случаях страница формируется вроде одинаковая... не увидел
разницы...
<html>
<head><title>Index of /max/projects//</title></head>
<body bgcolor="white">
<h1>Index of /max/projects//</h1><hr><pre><a href="../">../</a>
<a href="auth-dav/">auth-dav/</a>                                         
23-Apr-2015 18:31                   -
<a href="itcod/">itcod/</a>                                            
21-Apr-2015 10:32                   -
</pre><hr></body>
</html>

Но если навести на ссылку auth-dav (если слеш забыли в конце) и посмотреть
внизу куда ведёт путь... то увидим что "project" отрезан и нам предлагается
перейти на http://ihome.itcod.com/max/auth-dav/  Собственно в никуда она и
ведёт... ведь правильно это http://ihome.itcod.com/max/projects/auth-dav/

Кто слопал project при потеряном слэше? как его вернуть при потеряном
слэше?

Проверял в браузерах Opera и SeaMonkey

server {
listen       80;
server_name  dav.example.com;
server_name_in_redirect off;
access_log /var/log/nginx/dav.example.com-access.log main;
#resolver 10.255.255.1 [::1]:5353;
charset utf-8;

set $dir /opt/home;
set $testdir $dir$uri;
set $uri_type none;
if (-d $testdir) {
set $uri_type dir;
rewrite ^(.*)$ $1/;
rewrite ^(.*)/+$ $1/;
}
if (-f $testdir) {
set $uri_type file;
}
if ($request_method = "MKCOL") {
rewrite ^(.*)$ $1/;
rewrite ^(.*)/+$ $1/;
set $uri_type dir;
}
set $sadm_passwd .uhtpsw;
set $user_passwd .htpasswd; #user:password[crypt(3)/md5/sha1]
set $user_permit .htpermit; #user:GET,PUT,....OPTIONS
set $user_permit_default GET,PROPFIND,OPTIONS; # Allow

merge_slashes on;

location / {
access_by_lua_file /etc/nginx/lua/auth-dav.lua;
dav_methods PUT DELETE MKCOL COPY MOVE;
dav_ext_methods PROPFIND OPTIONS;
create_full_put_path on;
dav_access user:rw group:rw;
client_body_temp_path /opt/itcod-dav.tmp/;
client_max_body_size 0;
autoindex on;
    root $dir;

}
location ~/\.uht {
deny all;
}

}

авторизатор auth-dav.lua если потребуется тут
http://ihome.itcod.com/max/projects/auth-dav/

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258337,258337#msg-258337


From vbart at nginx.com  Thu Apr 23 19:41:00 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 23 Apr 2015 22:41 +0300
Subject: =?UTF-8?B?UmU6INC30LDQsdGL0Lsg0YHQu9GN0Ygg0LIg0LrQvtC90YbQtSB1cmwg0L/QvtC7?=
 =?UTF-8?B?0YPRh9C40Lsg0YHRg9GB0LDQvdC40L0tYXV0b2luZGV4?=
In-Reply-To: <5966c39551854d7c76a86cabed427f25.NginxMailingListRussian@forum.nginx.org>
References: <5966c39551854d7c76a86cabed427f25.NginxMailingListRussian@forum.nginx.org>
Message-ID: <9478888.l9gdBdEcf9@vbart-laptop>

On Thursday 23 April 2015 15:18:56 itcod wrote:
> Добрый день уважаемые!
> Столкнулся с странным поведением толи браузеров... толи autoindex в
> location... толи своими кривыми ручками.... Странность проявляется в
> различном отображении путей ссылок (нижняя строка браузера) при наведении на
> ссылку в листинге autoindex. Проявляется при отсутствии закрывающего слэша в
> url
> Можете взлянуть вживую
> пример правильного поведения: http://ihome.itcod.com/max/projects/ 
> пример неправильного поведения: http://ihome.itcod.com/max/projects 
> (СЛЭШ ЗАКРЫВАЮЩИЙ ЗАБЫЛ:))
> 
> В обоих случаях страница формируется вроде одинаковая... не увидел
> разницы...
> <html>
> <head><title>Index of /max/projects//</title></head>
> <body bgcolor="white">
> <h1>Index of /max/projects//</h1><hr><pre><a href="../">../</a>
> <a href="auth-dav/">auth-dav/</a>                                         
> 23-Apr-2015 18:31                   -
> <a href="itcod/">itcod/</a>                                            
> 21-Apr-2015 10:32                   -
> </pre><hr></body>
> </html>
> 
> Но если навести на ссылку auth-dav (если слеш забыли в конце) и посмотреть
> внизу куда ведёт путь... то увидим что "project" отрезан и нам предлагается
> перейти на http://ihome.itcod.com/max/auth-dav/  Собственно в никуда она и
> ведёт... ведь правильно это http://ihome.itcod.com/max/projects/auth-dav/
> 
> Кто слопал project при потеряном слэше? как его вернуть при потеряном
> слэше?
> 

Изучать основы: https://tools.ietf.org/html/rfc3986#section-5

2.3. Merge Paths

   o  return a string consisting of the reference's path component
      appended to all but the last segment of the base URI's path (i.e.,
      excluding any characters after the right-most "/" in the base URI
      path, or excluding the entire base URI path if it does not contain
      any "/" characters)

--
Валентин Бартенев

From simplebox66 at gmail.com  Fri Apr 24 05:31:53 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Fri, 24 Apr 2015 08:31:53 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <CAKaHDOE5M-3arBf=NczHqpV6ZzkE3WCgPUJ-5fkAQNN4NCTfGw@mail.gmail.com>
References: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
 <CA+ksgACuUbm7m1gwZ7vJU99VGvjN_1hBp-=0uerv2E8YLkAVeA@mail.gmail.com>
 <CAKaHDOE+9BeBxN77_3x88u74psteLfRrotEDFQHLPPUr-NthYg@mail.gmail.com>
 <CA+ksgAAmqhGAj6q-D6eUVxgHKWu3Oa0hDXN4BXrB4LBE3fVERw@mail.gmail.com>
 <CAKaHDOE5M-3arBf=NczHqpV6ZzkE3WCgPUJ-5fkAQNN4NCTfGw@mail.gmail.com>
Message-ID: <CA+ksgABGFux8a3J3ugxYBsfbZ0V+-sW2ESi5ELJZ06YFtjDD4Q@mail.gmail.com>

Гуру nginx, подскажите умеет ли nginx слать логи по TCP ?

23 апреля 2015 г., 18:04 пользователь Daniel Podolsky <onokonem at gmail.com>
написал:

> 2015-04-23 17:50 GMT+03:00 Иван Мишин <simplebox66 at gmail.com>:
> > сислог сервер уже использует TCP и изменять это я не в праве.
> ну тогда надо, наверное, выяснить, умеет ли nginx слать логи по tcp. а
> потом озаботиться настройког syslog на localhost для проксирования из
> udp в tcp
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150424/2c9d1f6f/attachment.html>

From mva at mva.name  Fri Apr 24 05:47:16 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Fri, 24 Apr 2015 11:47:16 +0600
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <CA+ksgABGFux8a3J3ugxYBsfbZ0V+-sW2ESi5ELJZ06YFtjDD4Q@mail.gmail.com>
References: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
 <CAKaHDOE5M-3arBf=NczHqpV6ZzkE3WCgPUJ-5fkAQNN4NCTfGw@mail.gmail.com>
 <CA+ksgABGFux8a3J3ugxYBsfbZ0V+-sW2ESi5ELJZ06YFtjDD4Q@mail.gmail.com>
Message-ID: <2959551.cVc6KOJ7YF@note>

На сколько мне известно ? нет.
Только в unix-сокет и по UDP.
Во-первых, это единственный способ сделать эту операцию неблокирующей (а это 
именно то ради чего NginX и писался: не делать блокирующих операций). Хотя по 
поводу unix-сокетов не всё так гладко с неблокируемостью, как хотелось бы :)
Во-вторых, лично я, опять же, с подхода "неблокируемость ? добро", не вижу 
логического обоснования отправки каких бы то ни было логов по TCP. Даже 
netconsole в линуксовом ядре и та использует UDP. Потому что иначе это очень 
"опасная" вещь, если на той стороне никто не будет слушать :)

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150424/eabae84a/attachment-0001.bin>

From nginx-forum at nginx.us  Fri Apr 24 07:11:14 2015
From: nginx-forum at nginx.us (itcod)
Date: Fri, 24 Apr 2015 03:11:14 -0400
Subject: =?UTF-8?B?UmU6INC30LDQsdGL0Lsg0YHQu9GN0Ygg0LIg0LrQvtC90YbQtSB1cmwg0L/QvtC7?=
 =?UTF-8?B?0YPRh9C40Lsg0YHRg9GB0LDQvdC40L0tYXV0b2luZGV4?=
In-Reply-To: <9478888.l9gdBdEcf9@vbart-laptop>
References: <9478888.l9gdBdEcf9@vbart-laptop>
Message-ID: <de13a2ac509695979893b0c15527e6e2.NginxMailingListRussian@forum.nginx.org>

Валентин добрый день!
Спасибо за науку. Хорошая вещь стандарты:)

Перефразирую вопрос. 
Существуют ли какие либо методы передать браузеру правильный url (с слэшем)
и заставить баузер исправить url не инициируя это действо кодом 301? По
аналогии как из JS можно поменять не перечитывая страницу. Дело в том, что
клиенты WEBDAV водимо не любят 301 и рвут соединение (видел у BitKinex)

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258337,258346#msg-258346


From nginx-forum at nginx.us  Fri Apr 24 07:24:46 2015
From: nginx-forum at nginx.us (itcod)
Date: Fri, 24 Apr 2015 03:24:46 -0400
Subject: =?UTF-8?B?UmU6INC30LDQsdGL0Lsg0YHQu9GN0Ygg0LIg0LrQvtC90YbQtSB1cmwg0L/QvtC7?=
 =?UTF-8?B?0YPRh9C40Lsg0YHRg9GB0LDQvdC40L0tYXV0b2luZGV4?=
In-Reply-To: <de13a2ac509695979893b0c15527e6e2.NginxMailingListRussian@forum.nginx.org>
References: <9478888.l9gdBdEcf9@vbart-laptop>
 <de13a2ac509695979893b0c15527e6e2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <30215edfc53133e04a6ff448950eaedb.NginxMailingListRussian@forum.nginx.org>

Сам вижу только - тестами проверить дав клиентов на поддержку HTTP/1.1 и
кода

307 Temporary Redirect ? запрашиваемый ресурс на короткое время доступен по
другому URI, указанный в поле Location заголовка. Этот код был введён вместе
с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616
(обновление HTTP/1.1).

Хотя сильно сомневаюсь что сработает.....
Буду благодарен если кто то подскажет рабочее решение или ещё варианты
решения.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258337,258347#msg-258347


From nginx-forum at nginx.us  Fri Apr 24 09:41:18 2015
From: nginx-forum at nginx.us (vlakas)
Date: Fri, 24 Apr 2015 05:41:18 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?=
 =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?=
In-Reply-To: <AD4FAEA9-9038-47C9-BAEC-4DB2CC945986@nginx.com>
References: <AD4FAEA9-9038-47C9-BAEC-4DB2CC945986@nginx.com>
Message-ID: <70528e3b8d2d8fbde02d9b2209cbf1ed.NginxMailingListRussian@forum.nginx.org>

Проблема повторилась. Дебаг можно скачать по ссылке:
https://mega.co.nz/#!QcJDCJQC!eEAjwoUzJTwrQ98lTWD3oTeC3mPx4uX5kcMmkwZ4h1M

Логи за 5 минут. В течении этого времени рост кеша наблюдался.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258349#msg-258349


From nginx-forum at nginx.us  Fri Apr 24 10:28:14 2015
From: nginx-forum at nginx.us (vlakas)
Date: Fri, 24 Apr 2015 06:28:14 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?=
 =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?=
In-Reply-To: <AD4FAEA9-9038-47C9-BAEC-4DB2CC945986@nginx.com>
References: <AD4FAEA9-9038-47C9-BAEC-4DB2CC945986@nginx.com>
Message-ID: <72aed10caed349456720dde8ed3973c2.NginxMailingListRussian@forum.nginx.org>

Еще для информации. Больших файлов на бэкенде нет. Единственное, что должен
отдавать бэкенд - это изображения размером не более 100 Кб.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258350#msg-258350


From vbart at nginx.com  Fri Apr 24 11:04:54 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 24 Apr 2015 14:04:54 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <2959551.cVc6KOJ7YF@note>
References: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
 <CA+ksgABGFux8a3J3ugxYBsfbZ0V+-sW2ESi5ELJZ06YFtjDD4Q@mail.gmail.com>
 <2959551.cVc6KOJ7YF@note>
Message-ID: <1923423.uramyBQmUj@vbart-laptop>

On Friday 24 April 2015 11:47:16 Vadim A. Misbakh-Soloviov wrote:
> На сколько мне известно ? нет.
> Только в unix-сокет и по UDP.
> Во-первых, это единственный способ сделать эту операцию неблокирующей (а это 
> именно то ради чего NginX и писался: не делать блокирующих операций). Хотя по 
> поводу unix-сокетов не всё так гладко с неблокируемостью, как хотелось бы :)
> Во-вторых, лично я, опять же, с подхода "неблокируемость ? добро", не вижу 
> логического обоснования отправки каких бы то ни было логов по TCP. Даже 
> netconsole в линуксовом ядре и та использует UDP. Потому что иначе это очень 
> "опасная" вещь, если на той стороне никто не будет слушать :)
> 

Так, между прочим, HTTP работает по TCP. =)

Поддержка syslog в nginx реализована по RFC 3164, который не раз
упомянут в документации.

Цитата из RFC:
 | syslog uses the user datagram protocol (UDP) as its underlying
 | transport layer mechanism.

--
Валентин Бартенев

From mva at mva.name  Fri Apr 24 11:08:23 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Fri, 24 Apr 2015 17:08:23 +0600
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <1923423.uramyBQmUj@vbart-laptop>
References: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
 <2959551.cVc6KOJ7YF@note> <1923423.uramyBQmUj@vbart-laptop>
Message-ID: <3186481.ORbF7Cuo7V@note>

> Так, между прочим, HTTP работает по TCP. =)

Не долго ему осталось :) Google c QUIK уже спешит на помощь :)

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150424/704b5ed4/attachment.bin>

From simplebox66 at gmail.com  Fri Apr 24 12:25:54 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Fri, 24 Apr 2015 15:25:54 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <3186481.ORbF7Cuo7V@note>
References: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
 <2959551.cVc6KOJ7YF@note> <1923423.uramyBQmUj@vbart-laptop>
 <3186481.ORbF7Cuo7V@note>
Message-ID: <CA+ksgADAYbB4iRYi0gb+cV96CWbjYRJZGb_wdhu0ZQ78kp07vg@mail.gmail.com>

Лучше бы поддержка syslog была по rfc5424

24 апреля 2015 г., 14:08 пользователь Vadim A. Misbakh-Soloviov <
mva at mva.name> написал:

> > Так, между прочим, HTTP работает по TCP. =)
>
> Не долго ему осталось :) Google c QUIK уже спешит на помощь :)
>
> --
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150424/c236d8be/attachment.html>

From igor at sysoev.ru  Fri Apr 24 12:45:53 2015
From: igor at sysoev.ru (Igor Sysoev)
Date: Fri, 24 Apr 2015 15:45:53 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <CA+ksgADAYbB4iRYi0gb+cV96CWbjYRJZGb_wdhu0ZQ78kp07vg@mail.gmail.com>
References: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
 <2959551.cVc6KOJ7YF@note> <1923423.uramyBQmUj@vbart-laptop>
 <3186481.ORbF7Cuo7V@note>
 <CA+ksgADAYbB4iRYi0gb+cV96CWbjYRJZGb_wdhu0ZQ78kp07vg@mail.gmail.com>
Message-ID: <7B5131B5-AD88-4818-A7CF-A9618DD5E902@sysoev.ru>

On 24 Apr 2015, at 15:25, Иван Мишин <simplebox66 at gmail.com> wrote:

> Лучше бы поддержка syslog была по rfc5424


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


-- 
Igor Sysoev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150424/755e9f07/attachment.html>

From vitaliy.okulov at gmail.com  Fri Apr 24 12:49:04 2015
From: vitaliy.okulov at gmail.com (Vitaliy Okulov)
Date: Fri, 24 Apr 2015 15:49:04 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <7B5131B5-AD88-4818-A7CF-A9618DD5E902@sysoev.ru>
References: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
 <2959551.cVc6KOJ7YF@note> <1923423.uramyBQmUj@vbart-laptop>
 <3186481.ORbF7Cuo7V@note>
 <CA+ksgADAYbB4iRYi0gb+cV96CWbjYRJZGb_wdhu0ZQ78kp07vg@mail.gmail.com>
 <7B5131B5-AD88-4818-A7CF-A9618DD5E902@sysoev.ru>
Message-ID: <CALiQiZmkyXEfu_yyNW6gCPAk=bZgR3JgaSpeAZBft4+898QStw@mail.gmail.com>

Платная версия syslog-ng умеет гарантировать доставку. В этой ситуации
стоит поднять локальный syslog.
24 апр. 2015 г. 15:46 пользователь "Igor Sysoev" <igor at sysoev.ru> написал:

> On 24 Apr 2015, at 15:25, Иван Мишин <simplebox66 at gmail.com> wrote:
>
> Лучше бы поддержка syslog была по rfc5424
>
>
> Если нужна надёжная доставка логов, то их надо записывать в локальные
> файлы, ротировать их хоть каждую минуту и копировать в централизованное
> хранилище. Логирование в syslog - это для тех, кому надёжная доставка не
> критична.
>
>
> --
> Igor Sysoev
>
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150424/2448c507/attachment.html>

From igor at sysoev.ru  Fri Apr 24 12:59:23 2015
From: igor at sysoev.ru (Igor Sysoev)
Date: Fri, 24 Apr 2015 15:59:23 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <CALiQiZmkyXEfu_yyNW6gCPAk=bZgR3JgaSpeAZBft4+898QStw@mail.gmail.com>
References: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
 <2959551.cVc6KOJ7YF@note> <1923423.uramyBQmUj@vbart-laptop>
 <3186481.ORbF7Cuo7V@note>
 <CA+ksgADAYbB4iRYi0gb+cV96CWbjYRJZGb_wdhu0ZQ78kp07vg@mail.gmail.com>
 <7B5131B5-AD88-4818-A7CF-A9618DD5E902@sysoev.ru>
 <CALiQiZmkyXEfu_yyNW6gCPAk=bZgR3JgaSpeAZBft4+898QStw@mail.gmail.com>
Message-ID: <FEA643E5-9459-47D2-96CF-4D626217E266@sysoev.ru>

On 24 Apr 2015, at 15:49, Vitaliy Okulov <vitaliy.okulov at gmail.com> wrote:
> Платная версия syslog-ng умеет гарантировать доставку. В этой ситуации стоит поднять локальный syslog.
> 
А что будет с syslog-ng, если удалённый хост не доступен, он будет полученное локально складировать?
Гарантируется ли, что запись в syslog-ng не будет блокировать записывающий процесс дольше, чем
запись на диск?


-- 
Igor Sysoev
http://nginx.com

> 24 апр. 2015 г. 15:46 пользователь "Igor Sysoev" <igor at sysoev.ru> написал:
> On 24 Apr 2015, at 15:25, Иван Мишин <simplebox66 at gmail.com> wrote:
> 
>> Лучше бы поддержка syslog была по rfc5424
> 
> 
> Если нужна надёжная доставка логов, то их надо записывать в локальные
> файлы, ротировать их хоть каждую минуту и копировать в централизованное
> хранилище. Логирование в syslog - это для тех, кому надёжная доставка не
> критична.
> 
> 
> -- 
> Igor Sysoev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150424/7535f091/attachment.html>

From xeioex at nginx.com  Fri Apr 24 14:10:59 2015
From: xeioex at nginx.com (Dmitry)
Date: Fri, 24 Apr 2015 17:10:59 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?=
 =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?=
In-Reply-To: <70528e3b8d2d8fbde02d9b2209cbf1ed.NginxMailingListRussian@forum.nginx.org>
References: <AD4FAEA9-9038-47C9-BAEC-4DB2CC945986@nginx.com>
 <70528e3b8d2d8fbde02d9b2209cbf1ed.NginxMailingListRussian@forum.nginx.org>
Message-ID: <553A4EF3.6010800@nginx.com>

к сожалению, из логов только видны последствия некоторой проблемы

grep 'http file cache forced expire' error.log
2015/04/24 11:17:02 [debug] 6829#0: http file cache forced expire
2015/04/24 11:17:02 [debug] 6829#0: http file cache forced expire: #1 1 
854b2eed
2015/04/24 11:17:02 [debug] 6829#0: http file cache forced expire: #1 1 
a77628c2
...

в данном логе, первое поле после # это счетчик использования записи в кеше.
Что можно видеть из лога на данный момент это то, что кеш-менеджеру не
удается удалить записи так как счетчик использования записей ненулевой. 
Менеджер
пытается удалять записи в порядке от самых старых к самым новым, тут мы 
наблюдаем
что >=20 самых старых записей в кеше, все еще 'используются' (в 
текущей   реализации
nginx перестает пытаться удалять файлы если >20 попыток удаления были 
неуспешны).
Есть несколько гипотез которые могут объяснить такое поведение:
1) упал воркер (падающий воркер может оставить записи которые он 
обрабатывал в момент падения
в общем кеше (shmem) в неконсистентном состоянии)
2) файлы все еще используются (но судя по логам не нашел этому 
подтверждений)
3) ошибка в nginx, так что в какой то момент, счетчик недекрементируется.

1) можно исключить проверив аптайм воркер-процессов.

есть ощущение что самое интересное произошло гораздо раньше.
Не могли бы Вы сделать следующее?
1) сократить размер кеша, так мы сократим время воспроизведения проблемы
2) прислать дебаг-лог начиная с начала работы nginx. Конкретно интересует
часть лога до первого сообщения 'http file cache forced expire: #1'.


On 24.04.2015 12:41, vlakas wrote:
> Проблема повторилась. Дебаг можно скачать по ссылке:
> https://mega.co.nz/#!QcJDCJQC!eEAjwoUzJTwrQ98lTWD3oTeC3mPx4uX5kcMmkwZ4h1M
>
> Логи за 5 минут. В течении этого времени рост кеша наблюдался.
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258349#msg-258349
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From vitaliy.okulov at gmail.com  Fri Apr 24 14:21:07 2015
From: vitaliy.okulov at gmail.com (Vitaliy Okulov)
Date: Fri, 24 Apr 2015 17:21:07 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <FEA643E5-9459-47D2-96CF-4D626217E266@sysoev.ru>
References: <CA+ksgABFvmy+ODBU16Uv6N-iwtNKYB23oyVp0qzDbxGRcoYVrQ@mail.gmail.com>
 <2959551.cVc6KOJ7YF@note> <1923423.uramyBQmUj@vbart-laptop>
 <3186481.ORbF7Cuo7V@note>
 <CA+ksgADAYbB4iRYi0gb+cV96CWbjYRJZGb_wdhu0ZQ78kp07vg@mail.gmail.com>
 <7B5131B5-AD88-4818-A7CF-A9618DD5E902@sysoev.ru>
 <CALiQiZmkyXEfu_yyNW6gCPAk=bZgR3JgaSpeAZBft4+898QStw@mail.gmail.com>
 <FEA643E5-9459-47D2-96CF-4D626217E266@sysoev.ru>
Message-ID: <CALiQiZmB+1XaSRvMPiaWWNx9zjGTmR6+DN35isk5eDFOZao4WQ@mail.gmail.com>

Судя по описанию - будет складировать, а потом дошлет
https://www.balabit.com/network-security/syslog-ng/central-syslog-server/features

Думаю что блокировать не будет, иначе при отвале коллектора сервер встанет.
24 апр. 2015 г. 15:59 пользователь "Igor Sysoev" <igor at sysoev.ru> написал:

> On 24 Apr 2015, at 15:49, Vitaliy Okulov <vitaliy.okulov at gmail.com> wrote:
>
> Платная версия syslog-ng умеет гарантировать доставку. В этой ситуации
> стоит поднять локальный syslog.
>
> А что будет с syslog-ng, если удалённый хост не доступен, он будет
> полученное локально складировать?
> Гарантируется ли, что запись в syslog-ng не будет блокировать записывающий
> процесс дольше, чем
> запись на диск?
>
>
> --
> Igor Sysoev
> http://nginx.com
>
> 24 апр. 2015 г. 15:46 пользователь "Igor Sysoev" <igor at sysoev.ru> написал:
>
>> On 24 Apr 2015, at 15:25, Иван Мишин <simplebox66 at gmail.com> wrote:
>>
>> Лучше бы поддержка syslog была по rfc5424
>>
>>
>> Если нужна надёжная доставка логов, то их надо записывать в локальные
>> файлы, ротировать их хоть каждую минуту и копировать в централизованное
>> хранилище. Логирование в syslog - это для тех, кому надёжная доставка не
>> критична.
>>
>>
>> --
>> Igor Sysoev
>>
>
>
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150424/17d0f4b9/attachment-0001.html>

From nginx-forum at nginx.us  Fri Apr 24 15:47:59 2015
From: nginx-forum at nginx.us (igor.goncharenko)
Date: Fri, 24 Apr 2015 11:47:59 -0400
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <CALiQiZmB+1XaSRvMPiaWWNx9zjGTmR6+DN35isk5eDFOZao4WQ@mail.gmail.com>
References: <CALiQiZmB+1XaSRvMPiaWWNx9zjGTmR6+DN35isk5eDFOZao4WQ@mail.gmail.com>
Message-ID: <1a00983691f4e9284c3a8529436a7181.NginxMailingListRussian@forum.nginx.org>

rsyslog тоже умеет уже с достаточно древних версий отложенную доставку в
бесплатной версии (не знаю, есть ли там платная), но только если доставка по
tcp если мне не изменяет память.

В общем, "они все могут". Другое дело что нужно очень аккуратно все это
конфигурить, конечно.

Vitaliy Okulov Wrote:
-------------------------------------------------------
> Судя по описанию - будет складировать, а потом дошлет
> https://www.balabit.com/network-security/syslog-ng/central-syslog-serv
> er/features
> 
> Думаю что блокировать не будет, иначе при отвале коллектора сервер
> встанет.
> 24 апр. 2015 г. 15:59 пользователь "Igor Sysoev" <igor at sysoev.ru>
> написал:
> 
> > On 24 Apr 2015, at 15:49, Vitaliy Okulov <vitaliy.okulov at gmail.com>
> wrote:
> >
> > Платная версия syslog-ng умеет гарантировать доставку. В этой
> ситуации
> > стоит поднять локальный syslog.
> >
> > А что будет с syslog-ng, если удалённый хост не доступен, он будет
> > полученное локально складировать?
> > Гарантируется ли, что запись в syslog-ng не будет блокировать
> записывающий
> > процесс дольше, чем
> > запись на диск?
> >
> >
> > --
> > Igor Sysoev
> > http://nginx.com
> >
> > 24 апр. 2015 г. 15:46 пользователь "Igor Sysoev" <igor at sysoev.ru>
> написал:
> >
> >> On 24 Apr 2015, at 15:25, Иван Мишин <simplebox66 at gmail.com>
> wrote:
> >>
> >> Лучше бы поддержка syslog была по rfc5424
> >>
> >>
> >> Если нужна надёжная доставка логов, то их надо записывать в
> локальные
> >> файлы, ротировать их хоть каждую минуту и копировать в
> централизованное
> >> хранилище. Логирование в syslog - это для тех, кому надёжная
> доставка не
> >> критична.
> >>
> >>
> >> --
> >> Igor Sysoev
> >>
> >
> >
> > _______________________________________________
> > 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

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258330,258364#msg-258364


From nginx-forum at nginx.us  Sat Apr 25 18:22:55 2015
From: nginx-forum at nginx.us (grigory)
Date: Sat, 25 Apr 2015 14:22:55 -0400
Subject: =?UTF-8?B?0JTQvtC70LPQvtC1INCy0YDQtdC80Y8g0LfQsNCz0YDRg9C30LrQuCDRgdGC0LA=?=
 =?UTF-8?B?0YLQuNC60Lg=?=
Message-ID: <cc6f295a58072cf5d5fffb23a8f83992.NginxMailingListRussian@forum.nginx.org>

Всем привет,

Есть выделенный сервер на iWeb.com (i3-540 + 8GB RAM). Канал полностью
свободен, загрузка сервера в районе 0.05-0.2 в течение дня и I/O wait ratio
очень низкий.

Однако, время от времени Nginx 1.4.2 загружает в браузере картинку размером
1Мб в течение 20-30 секунд. Иногда бывает и в течение 2 секунд, как и должно
быть, но не всегда. Делал тесты канала ? всё в порядке.

Обновился до nginx 1.8.0 ? проблема не ушла.
ОС ? CentOS 6.6. Nginx собран без доп. модулей.

Мой конфиг:
==============================================================
worker_processes 4;
worker_rlimit_nofile 12400;

events {
worker_connections 32768;
}

http {
include mime.types;
default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] $request '
'"$status" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

sendfile on;
tcp_nopush on;
tcp_nodelay on;

gzip on;
gzip_min_length 1400;
gzip_proxied any;
gzip_types text/plain text/xml application/xml application/x-javascript
text/javascript text/css text/json;
gzip_comp_level 6;

map $http_host $root_dir {
hostnames;
}
root $root_dir;

server {
listen 188.88.88.88:80;
server_name domain.com www.domain.com;
access_log /nginx/logs/domain.com-access.log main;

location / {
proxy_pass http://domain.com:8080/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

client_max_body_size 20m;
client_body_buffer_size 128k;

proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;

proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;

root /home/www/domain.com;
}
}
}
==============================================================

На сервер висит несколько сайтов, один из которых ? хостинг картинок. Обычно
на нем раздаются картинки размером до 1Мб, но недавно я создал несколько
сервисов, где посетитель может закачать картинку по 3-5Мб для работы с ней.
И вот в этот момент отображение картинки тормозится.

Буду рад любой помощи.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258374,258374#msg-258374


From nginx-forum at nginx.us  Sat Apr 25 19:24:05 2015
From: nginx-forum at nginx.us (grigory)
Date: Sat, 25 Apr 2015 15:24:05 -0400
Subject: =?UTF-8?B?UmU6INCU0L7Qu9Cz0L7QtSDQstGA0LXQvNGPINC30LDQs9GA0YPQt9C60Lgg0YE=?=
 =?UTF-8?B?0YLQsNGC0LjQutC4?=
In-Reply-To: <cc6f295a58072cf5d5fffb23a8f83992.NginxMailingListRussian@forum.nginx.org>
References: <cc6f295a58072cf5d5fffb23a8f83992.NginxMailingListRussian@forum.nginx.org>
Message-ID: <c4e6de7e7fc0deebc673d5c9e46c0c07.NginxMailingListRussian@forum.nginx.org>

Что пробовал:
sendfile off ? без толку;
output_buffers 1 512k ? без толку.

Запустил под раздачу картинок вообще отдельный nginx ? без толку.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258374,258375#msg-258375


From nginx-forum at nginx.us  Sun Apr 26 09:27:24 2015
From: nginx-forum at nginx.us (itcod)
Date: Sun, 26 Apr 2015 05:27:24 -0400
Subject: =?UTF-8?B?0L/QvtGB0YLQvtCx0YDQsNCx0L7RgtC60LAg0L7RgtCy0LXRgtCwINGB0LrRgNC4?=
 =?UTF-8?B?0L/RgtC+0LwgbHVh?=
Message-ID: <81399ff3192819da2c6f8431af1c65e1.NginxMailingListRussian@forum.nginx.org>

Добрый день уважаемые!
Просветите плиззз! Как реализовать сабж.
Необходимо чтобы локейшн отработал всё что положено (модулями и скриптами)
сгенерил какойто ответ,
и этот ответ в результате поступил на обработку скрипту lua.

Возможно ли такое? если да то как?

ЗЫ: Реально задача заключается в том что в локейшене модуль webdav
отрабатывает команду PUT и принимает от пользователя файл. В конце этого
процесса - когда пользователю отдается ответ (успех или неудача) мне
необходимо выполнить действия над этим полученным файлом.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258380,258380#msg-258380


From nginx-forum at nginx.us  Sun Apr 26 10:01:33 2015
From: nginx-forum at nginx.us (itcod)
Date: Sun, 26 Apr 2015 06:01:33 -0400
Subject: =?UTF-8?B?UmU6INC/0L7RgdGC0L7QsdGA0LDQsdC+0YLQutCwINC+0YLQstC10YLQsCDRgdC6?=
 =?UTF-8?B?0YDQuNC/0YLQvtC8IGx1YQ==?=
In-Reply-To: <81399ff3192819da2c6f8431af1c65e1.NginxMailingListRussian@forum.nginx.org>
References: <81399ff3192819da2c6f8431af1c65e1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <962b0094295326f7bb3e5fcbf691eb6a.NginxMailingListRussian@forum.nginx.org>

нашёл на просторах вот такое
body_filter_by_lua_file
не знаю подойдёт или нет...

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

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258380,258381#msg-258381


From nginx-forum at nginx.us  Sun Apr 26 10:11:59 2015
From: nginx-forum at nginx.us (grigory)
Date: Sun, 26 Apr 2015 06:11:59 -0400
Subject: =?UTF-8?B?UmU6INCU0L7Qu9Cz0L7QtSDQstGA0LXQvNGPINC30LDQs9GA0YPQt9C60Lgg0YE=?=
 =?UTF-8?B?0YLQsNGC0LjQutC4?=
In-Reply-To: <cc6f295a58072cf5d5fffb23a8f83992.NginxMailingListRussian@forum.nginx.org>
References: <cc6f295a58072cf5d5fffb23a8f83992.NginxMailingListRussian@forum.nginx.org>
Message-ID: <ca5e2cb91629092ddf91b32469f4b6ff.NginxMailingListRussian@forum.nginx.org>

Забыл добавить часть конфига из блока "server":

        # Static files location
        location ~*
^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf|js)$
{
              if ($args ~* "^download") {
                   add_header Content-Disposition "attachment;
filename=$1";
              }

            expires    30d;
            root   /home/www/domain.com;
        }

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258374,258383#msg-258383


From mva at mva.name  Sun Apr 26 11:30:48 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Sun, 26 Apr 2015 17:30:48 +0600
Subject: =?UTF-8?B?UmU6INC/0L7RgdGC0L7QsdGA0LDQsdC+0YLQutCwINC+0YLQstC10YLQsCDRgdC6?=
 =?UTF-8?B?0YDQuNC/0YLQvtC8IGx1YQ==?=
In-Reply-To: <962b0094295326f7bb3e5fcbf691eb6a.NginxMailingListRussian@forum.nginx.org>
References: <81399ff3192819da2c6f8431af1c65e1.NginxMailingListRussian@forum.nginx.org>
 <962b0094295326f7bb3e5fcbf691eb6a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <10292916.aFCig5hHB3@note>

В письме от Вс, 26 апреля 2015 06:01:33 пользователь itcod написал:
> нашёл на просторах вот такое
> body_filter_by_lua_file
> не знаю подойдёт или нет...
> 
> Подскажите плиззз, где есть документация на эти конструкции.... какие
> бывают, для чего применяются... как работают....
> 

Есть документация. Вот здесь.
https://github.com/openresty/lua-nginx-module/

И, к слову, там же есть ссылка на maillist где можно задавать вопросы по Lua 
Module с большим шансом получить ответ от разработчика :)

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150426/0249a884/attachment.bin>

From nginx-forum at nginx.us  Sun Apr 26 13:45:02 2015
From: nginx-forum at nginx.us (itcod)
Date: Sun, 26 Apr 2015 09:45:02 -0400
Subject: =?UTF-8?B?UmU6INC/0L7RgdGC0L7QsdGA0LDQsdC+0YLQutCwINC+0YLQstC10YLQsCDRgdC6?=
 =?UTF-8?B?0YDQuNC/0YLQvtC8IGx1YQ==?=
In-Reply-To: <10292916.aFCig5hHB3@note>
References: <10292916.aFCig5hHB3@note>
Message-ID: <5a090cd913e2a8be93d878a64cd64bbb.NginxMailingListRussian@forum.nginx.org>

mva добрый день!
спасибо. 
на чердак... и учит его учить и учить:)

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258380,258385#msg-258385


From nginx-forum at nginx.us  Sun Apr 26 17:25:11 2015
From: nginx-forum at nginx.us (sadus)
Date: Sun, 26 Apr 2015 13:25:11 -0400
Subject: =?UTF-8?B?0J/QtdGA0LXQstC10YHRgtC4IC5odGFjY2VzcyDQsiDQutC+0L3RhNC40LMgbmdp?=
 =?UTF-8?B?bng=?=
Message-ID: <239a29ff573682a666665c97f6d70349.NginxMailingListRussian@forum.nginx.org>

Ребятки помогите пожалуйста перевести .htaccess в конфиг nginx
никак не получается 

AddDefaultCharset utf-8
Options -Indexes

DirectoryIndex index.php index.html

RewriteEngine On

RewriteRule ^.htaccess$ - [F]

# if a directory or a file exists, use it directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

# otherwise forward it to index.php
RewriteRule . index.php

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258386,258386#msg-258386


From a.vasylev at 404-group.com  Mon Apr 27 05:31:48 2015
From: a.vasylev at 404-group.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCS0LDRgdC40LvRjNC10LI=?=)
Date: Mon, 27 Apr 2015 08:31:48 +0300
Subject: =?UTF-8?B?UmU6INCf0LXRgNC10LLQtdGB0YLQuCAuaHRhY2Nlc3Mg0LIg0LrQvtC90YTQuNCz?=
 =?UTF-8?B?IG5naW54?=
In-Reply-To: <239a29ff573682a666665c97f6d70349.NginxMailingListRussian@forum.nginx.org>
References: <239a29ff573682a666665c97f6d70349.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAJ6XDsvuOpRGpbixgmGydH5P5AbNKXGEF1ohJD7+7CkALxgHyg@mail.gmail.com>

Используйте конструкцию

try_files $uri $uri/ /index.php;
On Apr 26, 2015 8:25 PM, "sadus" <nginx-forum at nginx.us> wrote:

> Ребятки помогите пожалуйста перевести .htaccess в конфиг nginx
> никак не получается
>
> AddDefaultCharset utf-8
> Options -Indexes
>
> DirectoryIndex index.php index.html
>
> RewriteEngine On
>
> RewriteRule ^.htaccess$ - [F]
>
> # if a directory or a file exists, use it directly
> RewriteCond %{REQUEST_FILENAME} !-f
> RewriteCond %{REQUEST_FILENAME} !-d
>
> # otherwise forward it to index.php
> RewriteRule . index.php
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,258386,258386#msg-258386
>
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150427/47cf7b1d/attachment.html>

From motienko at gmail.com  Mon Apr 27 21:27:09 2015
From: motienko at gmail.com (Oleg Motienko)
Date: Tue, 28 Apr 2015 00:27:09 +0300
Subject: =?UTF-8?B?0JDQtNGA0LXRgSB0Y3Ag0YHQvtC60LXRgtCwINC/0L7RgdC70LUgc2V0X3JlYWxf?=
 =?UTF-8?B?aXBfZnJvbQ==?=
Message-ID: <CAAtQP1wqCS_DSdmo5Gszr-VMX5DPeLMDjq45KfRc_J=Smr=ELA@mail.gmail.com>

Добрый день.

Подскажите, в какой переменной в случае использования set_real_ip_from
всё-таки увидеть адрес другой tcp сокета ? Т.е. нужно получить адрес
сервера, откуда пришел запрос.

-- 
Regards,
Oleg

From nginx-forum at nginx.us  Tue Apr 28 03:46:41 2015
From: nginx-forum at nginx.us (ankirich)
Date: Mon, 27 Apr 2015 23:46:41 -0400
Subject: reverse proxy and client certificates
Message-ID: <e31f37d93a33dee8ffcf5fed820731eb.NginxMailingListRussian@forum.nginx.org>

День добрый,

Имеется следующий сценарий - nginx используется как балансировщик входящих
https запросов распределяемых между несолькими https бэкендами в зависимости
от URI.  Т.е. nginx принимает sslсессию, анализирует запрос и
переустанавливает ssl с бэкендами. Клиенты, обращающиеся к системе,  в
рамках ssl хендшейка  передают свои сертификаты.  Чтобы передатьих далее на
бэкенд, nginx может сгенерировать дополнительный http header и добавить туда
сертификат. Google search показывает нексолько примеров, как может быть
сконфигурировано через "proxy_set_header X-SSL-CERT $ssl_client_cert"

Вопрос, есть ли какие-то другие способы передать клиентский сертификат в
сторону бэкенд сервера ?
Если в конфиге nginx нет никаких спициальных директив по этому поводу,
каково будет дефолтное поведение ?  

Спасибо,
ak

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258418,258418#msg-258418


From arut at nginx.com  Tue Apr 28 06:18:41 2015
From: arut at nginx.com (Roman Arutyunyan)
Date: Tue, 28 Apr 2015 09:18:41 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?=
 =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?=
In-Reply-To: <70528e3b8d2d8fbde02d9b2209cbf1ed.NginxMailingListRussian@forum.nginx.org>
References: <AD4FAEA9-9038-47C9-BAEC-4DB2CC945986@nginx.com>
 <70528e3b8d2d8fbde02d9b2209cbf1ed.NginxMailingListRussian@forum.nginx.org>
Message-ID: <7BA71350-03F6-4A14-8FC7-8BF9CDF6B09B@nginx.com>

Судя по логу, у вас имеются активные запросы (или по ошибке считающиеся такими)
к некоторому количеству элементов кеша.  Таких запросов как минимум 20, они
являются самым старыми элементами кеша, все более новое уже удалено, очистка
кеша уперлась в эти элементы.

В чем причина проблемы без анализа полного debug лога и gdb понять тяжело.

Попробуйте выяснить, что это за элементы, когда были запросы к ним.
Для этого найдите файлы в кеше по префиксам ключей: 854b2eed -> ../85/4b/2eed..,
посмотрите, что там.  В access.log можно попробовать найти соответствия по времени
и найти какие-то странности с этими запросами.  Кроме того, убедитесь, что
после релоада конфигурации у вас не висят подолгу (или даже бесконечно долго)
?shutting down? процессы.

2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 854b2eed
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 a77628c2
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 20374078
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 5dbd6cc5
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 556809d8
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 5f316ff2
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 3be8ec5c
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 ef60c351
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 b9b3ba84
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 3a704f7e
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 01d90614
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 ae9fac1e
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 328cd295
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 085451ea
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 5ee67fde
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 f6ffe362
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 b2d88eaa
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 2b40e985
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 97715f69
2015/04/24 11:13:35 [debug] 6829#0: http file cache forced expire: #1 1 43bf0c49

On 24 Apr 2015, at 12:41, vlakas <nginx-forum at nginx.us> wrote:

> Проблема повторилась. Дебаг можно скачать по ссылке:
> https://mega.co.nz/#!QcJDCJQC!eEAjwoUzJTwrQ98lTWD3oTeC3mPx4uX5kcMmkwZ4h1M
> 
> Логи за 5 минут. В течении этого времени рост кеша наблюдался.
> 
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258349#msg-258349
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From nginx-forum at nginx.us  Tue Apr 28 11:20:30 2015
From: nginx-forum at nginx.us (vlakas)
Date: Tue, 28 Apr 2015 07:20:30 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?=
 =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?=
In-Reply-To: <7BA71350-03F6-4A14-8FC7-8BF9CDF6B09B@nginx.com>
References: <7BA71350-03F6-4A14-8FC7-8BF9CDF6B09B@nginx.com>
Message-ID: <3192fb8c1330377945727e61d864c8f4.NginxMailingListRussian@forum.nginx.org>

Роман, Дмитрий, спасибо за рекомендации.

Падение воркеров nginx'а не было замечено. При рестарте nginx воркеры
недолго находятся в состоянии "shutting down". Тут все хорошо.

Сейчас кеш был значительно уменьшен и включен дебаг.

Проблема пока не проявляется, но вижу подозрительные вещи в дебаг логе:

2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #0 1
21c1cd6e
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #0 1
304bc486
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #0 1
5468f149
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #0 1
0614276a
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #0 1
47d72b84
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #0 1
6ded07ab
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #0 1
7c700af9
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #0 1
2f6fc358
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #0 1
1b1dda91
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:40:38 [debug] 22500#0: http file cache forced expire: #0 1
1c3dda56

(Обратите внимание на 29fddad7)

Хотя в файловой системе его не нахожу:
# ls -all /opt/nginx-cache-images1/29/fd/
total 156
drwx------   2 www-data www-data 12288 Apr 28 13:47 .
drwx------ 258 www-data www-data  4096 Apr 17 11:04 ..
-rw-------   1 www-data www-data 11120 Apr 26 22:08
187415d376209c37038d3e536a4cfd29
-rw-------   1 www-data www-data  6653 Apr 28 13:41
1e43883d6ddcfb56e9ea84f4e2dffd29
-rw-------   1 www-data www-data 23033 Apr 28 13:41
5bdba55383559ec9f50fe6eec83cfd29
-rw-------   1 www-data www-data 13527 Apr 28 13:45
7983c75832ea3f0458e4315b83dcfd29
-rw-------   1 www-data www-data 11731 Apr 28 13:47
85e329c59da26ddac0e5844adc23fd29
-rw-------   1 www-data www-data 17182 Apr 28 13:44
90d0b75025acf141f8fd5f0bc431fd29
-rw-------   1 www-data www-data 17620 Apr 28 13:45
a1498de45e99ca3538f59da22f9cfd29
-rw-------   1 www-data www-data  4805 Apr 28 13:43
d33a7459a80456c5dc2aa4f56a84fd29
-rw-------   1 www-data www-data 17668 Apr 28 13:47
d7deedc7100d675b024eaebb99c6fd29

Открытых файлов  в этой директории на данный момент тоже нет.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258429#msg-258429


From nginx-forum at nginx.us  Tue Apr 28 11:20:40 2015
From: nginx-forum at nginx.us (vlakas)
Date: Tue, 28 Apr 2015 07:20:40 -0400
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?=
 =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?=
In-Reply-To: <7BA71350-03F6-4A14-8FC7-8BF9CDF6B09B@nginx.com>
References: <7BA71350-03F6-4A14-8FC7-8BF9CDF6B09B@nginx.com>
Message-ID: <bcf8ea64349421da23c5a16294181318.NginxMailingListRussian@forum.nginx.org>

Роман, Дмитрий, спасибо за рекомендации.

Размер кеша уменьшил до 10 Гб, включил дебаг.

Проблема пока не проявляется, но в дебаг логе вижу подозрительные вещи:

2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
35fdec05
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
39769558
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
1ef351b0
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
0b4eaa2e
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
81d7ae20
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
d80ef979
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
e7875a78
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
c2ad99cc
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
6f3d1738
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
bc7b6d5a
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
9bee7f9c
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
b10ba9bf
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
29fddad7
2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
68f86aaf

(Обратите внимание на 29fddad7)

При этом в файловой системе я его не нахожу (в удаленных, но незкакрытых
файлах тоже нет):

# ls -all /opt/nginx-cache-images1/29/fd/
total 96
drwx------   2 www-data www-data 12288 Apr 28 14:00 .
drwx------ 258 www-data www-data  4096 Apr 17 11:04 ..
-rw-------   1 www-data www-data 11120 Apr 26 22:08
187415d376209c37038d3e536a4cfd29
-rw-------   1 www-data www-data  4667 Apr 28 13:54
77b0dc15b1aec3ce8bb1d3d904ccfd29
-rw-------   1 www-data www-data 14241 Apr 28 13:57
85e329c59da26ddac0e5844adc23fd29
-rw-------   1 www-data www-data 17182 Apr 28 13:56
90d0b75025acf141f8fd5f0bc431fd29
-rw-------   1 www-data www-data  5297 Apr 28 13:52
9d1edeca10f5f596d1bb13d62e7dfd29
-rw-------   1 www-data www-data 13903 Apr 28 13:56
d7deedc7100d675b024eaebb99c6fd29

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258430#msg-258430


From arut at nginx.com  Tue Apr 28 12:12:38 2015
From: arut at nginx.com (Roman Arutyunyan)
Date: Tue, 28 Apr 2015 15:12:38 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?=
 =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?=
In-Reply-To: <bcf8ea64349421da23c5a16294181318.NginxMailingListRussian@forum.nginx.org>
References: <7BA71350-03F6-4A14-8FC7-8BF9CDF6B09B@nginx.com>
 <bcf8ea64349421da23c5a16294181318.NginxMailingListRussian@forum.nginx.org>
Message-ID: <10D1CBD9-A0E6-45F7-B365-F8F309834701@nginx.com>


On 28 Apr 2015, at 14:20, vlakas <nginx-forum at nginx.us> wrote:

> Роман, Дмитрий, спасибо за рекомендации.
> 
> Размер кеша уменьшил до 10 Гб, включил дебаг.
> 
> Проблема пока не проявляется, но в дебаг логе вижу подозрительные вещи:
> 
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7

Это первая ласточка, надо искать причину.

[..]

> (Обратите внимание на 29fddad7)
> 
> При этом в файловой системе я его не нахожу (в удаленных, но незкакрытых
> файлах тоже нет):
> 
> # ls -all /opt/nginx-cache-images1/29/fd/
> total 96
> drwx------   2 www-data www-data 12288 Apr 28 14:00 .
> drwx------ 258 www-data www-data  4096 Apr 17 11:04 ..
> -rw-------   1 www-data www-data 11120 Apr 26 22:08
> 187415d376209c37038d3e536a4cfd29
> -rw-------   1 www-data www-data  4667 Apr 28 13:54
> 77b0dc15b1aec3ce8bb1d3d904ccfd29
> -rw-------   1 www-data www-data 14241 Apr 28 13:57
> 85e329c59da26ddac0e5844adc23fd29
> -rw-------   1 www-data www-data 17182 Apr 28 13:56
> 90d0b75025acf141f8fd5f0bc431fd29
> -rw-------   1 www-data www-data  5297 Apr 28 13:52
> 9d1edeca10f5f596d1bb13d62e7dfd29
> -rw-------   1 www-data www-data 13903 Apr 28 13:56
> d7deedc7100d675b024eaebb99c6fd29

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

2015/04/24 11:13:35 [debug] 6821#0: *20626640 cache file: "/opt2/nginx-cache-images1/38/5c/6f30ca3d762e9ab98d0764f8a0295c38"

From xeioex at nginx.com  Tue Apr 28 12:14:51 2015
From: xeioex at nginx.com (Dmitry)
Date: Tue, 28 Apr 2015 15:14:51 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0L3RgtGA0L7Qu9C70LjRgNGD0LXQvNGL0Lkg0L7QsdGK0LU=?=
 =?UTF-8?B?0Lwg0LrQtdGI0LAgTmdpbng=?=
In-Reply-To: <bcf8ea64349421da23c5a16294181318.NginxMailingListRussian@forum.nginx.org>
References: <7BA71350-03F6-4A14-8FC7-8BF9CDF6B09B@nginx.com>
 <bcf8ea64349421da23c5a16294181318.NginxMailingListRussian@forum.nginx.org>
Message-ID: <553F79BB.3020306@nginx.com>

А есть ли дополнительная информация в логе для записи

29fddad7? Очень похоже на первую залоченную запись. нужно попробовать собрать
максимум информации по таким записям.


On 28.04.2015 14:20, vlakas wrote:
> Роман, Дмитрий, спасибо за рекомендации.
>
> Размер кеша уменьшил до 10 Гб, включил дебаг.
>
> Проблема пока не проявляется, но в дебаг логе вижу подозрительные вещи:
>
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
> 35fdec05
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
> 39769558
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
> 1ef351b0
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
> 0b4eaa2e
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
> 81d7ae20
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
> d80ef979
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
> e7875a78
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
> c2ad99cc
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
> 6f3d1738
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
> bc7b6d5a
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
> 9bee7f9c
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
> b10ba9bf
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #1 1
> 29fddad7
> 2015/04/28 13:57:07 [debug] 22500#0: http file cache forced expire: #0 1
> 68f86aaf
>
> (Обратите внимание на 29fddad7)
>
> При этом в файловой системе я его не нахожу (в удаленных, но незкакрытых
> файлах тоже нет):
>
> # ls -all /opt/nginx-cache-images1/29/fd/
> total 96
> drwx------   2 www-data www-data 12288 Apr 28 14:00 .
> drwx------ 258 www-data www-data  4096 Apr 17 11:04 ..
> -rw-------   1 www-data www-data 11120 Apr 26 22:08
> 187415d376209c37038d3e536a4cfd29
> -rw-------   1 www-data www-data  4667 Apr 28 13:54
> 77b0dc15b1aec3ce8bb1d3d904ccfd29
> -rw-------   1 www-data www-data 14241 Apr 28 13:57
> 85e329c59da26ddac0e5844adc23fd29
> -rw-------   1 www-data www-data 17182 Apr 28 13:56
> 90d0b75025acf141f8fd5f0bc431fd29
> -rw-------   1 www-data www-data  5297 Apr 28 13:52
> 9d1edeca10f5f596d1bb13d62e7dfd29
> -rw-------   1 www-data www-data 13903 Apr 28 13:56
> d7deedc7100d675b024eaebb99c6fd29
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258292,258430#msg-258430
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From simplebox66 at gmail.com  Tue Apr 28 12:46:36 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Tue, 28 Apr 2015 15:46:36 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <1a00983691f4e9284c3a8529436a7181.NginxMailingListRussian@forum.nginx.org>
References: <CALiQiZmB+1XaSRvMPiaWWNx9zjGTmR6+DN35isk5eDFOZao4WQ@mail.gmail.com>
 <1a00983691f4e9284c3a8529436a7181.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CA+ksgAD7EXeqouNSG-_mDK2whaq=N6UuRVXFVcGBron-XJ59PQ@mail.gmail.com>

А есть ли какое-то ограничение на длину syslog сообщения поступающего со
стороны nginx в rsyslog?

24 апреля 2015 г., 18:47 пользователь igor.goncharenko <nginx-forum at nginx.us
> написал:

> rsyslog тоже умеет уже с достаточно древних версий отложенную доставку в
> бесплатной версии (не знаю, есть ли там платная), но только если доставка
> по
> tcp если мне не изменяет память.
>
> В общем, "они все могут". Другое дело что нужно очень аккуратно все это
> конфигурить, конечно.
>
> Vitaliy Okulov Wrote:
> -------------------------------------------------------
> > Судя по описанию - будет складировать, а потом дошлет
> > https://www.balabit.com/network-security/syslog-ng/central-syslog-serv
> > er/features
> >
> > Думаю что блокировать не будет, иначе при отвале коллектора сервер
> > встанет.
> > 24 апр. 2015 г. 15:59 пользователь "Igor Sysoev" <igor at sysoev.ru>
> > написал:
> >
> > > On 24 Apr 2015, at 15:49, Vitaliy Okulov <vitaliy.okulov at gmail.com>
> > wrote:
> > >
> > > Платная версия syslog-ng умеет гарантировать доставку. В этой
> > ситуации
> > > стоит поднять локальный syslog.
> > >
> > > А что будет с syslog-ng, если удалённый хост не доступен, он будет
> > > полученное локально складировать?
> > > Гарантируется ли, что запись в syslog-ng не будет блокировать
> > записывающий
> > > процесс дольше, чем
> > > запись на диск?
> > >
> > >
> > > --
> > > Igor Sysoev
> > > http://nginx.com
> > >
> > > 24 апр. 2015 г. 15:46 пользователь "Igor Sysoev" <igor at sysoev.ru>
> > написал:
> > >
> > >> On 24 Apr 2015, at 15:25, Иван Мишин <simplebox66 at gmail.com>
> > wrote:
> > >>
> > >> Лучше бы поддержка syslog была по rfc5424
> > >>
> > >>
> > >> Если нужна надёжная доставка логов, то их надо записывать в
> > локальные
> > >> файлы, ротировать их хоть каждую минуту и копировать в
> > централизованное
> > >> хранилище. Логирование в syslog - это для тех, кому надёжная
> > доставка не
> > >> критична.
> > >>
> > >>
> > >> --
> > >> Igor Sysoev
> > >>
> > >
> > >
> > > _______________________________________________
> > > 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
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,258330,258364#msg-258364
>
> _______________________________________________
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150428/542b6303/attachment.html>

From onokonem at gmail.com  Tue Apr 28 13:25:23 2015
From: onokonem at gmail.com (Daniel Podolsky)
Date: Tue, 28 Apr 2015 16:25:23 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <CA+ksgAD7EXeqouNSG-_mDK2whaq=N6UuRVXFVcGBron-XJ59PQ@mail.gmail.com>
References: <CALiQiZmB+1XaSRvMPiaWWNx9zjGTmR6+DN35isk5eDFOZao4WQ@mail.gmail.com>
 <1a00983691f4e9284c3a8529436a7181.NginxMailingListRussian@forum.nginx.org>
 <CA+ksgAD7EXeqouNSG-_mDK2whaq=N6UuRVXFVcGBron-XJ59PQ@mail.gmail.com>
Message-ID: <CAKaHDOFK6Vm3RHvXqn6rd2pQaQogJ3K1bNTagojBLb9tTMMzfA@mail.gmail.com>

> А есть ли какое-то ограничение на длину syslog сообщения поступающего со
> стороны nginx в rsyslog?
есть ограничение на длину UDP пакета, и оно определяется MTU интерфеса

From nginx-forum at nginx.us  Tue Apr 28 15:18:26 2015
From: nginx-forum at nginx.us (BieZax)
Date: Tue, 28 Apr 2015 11:18:26 -0400
Subject: =?UTF-8?B?0JvQvtCz0LjRgNC+0LLQsNC90LjQtSDQsiDQvtC00LjQvSDRhNCw0LnQuyDQuNC3?=
 =?UTF-8?B?INGA0LDQt9C90YvRhSBzZXJ2ZXI=?=
Message-ID: <cce167a8409d97892a76792ed98f8cb3.NginxMailingListRussian@forum.nginx.org>

Добрый  день.

Сейчас имеется  такая структура:
server{
access_log /var/log/nginx_a.log;
location / {
proxy_pass http://127.0.0.1:8080/
}
location /1/ {
access_log /var/log/nginx_b.log;
proxy_pass http://be/;
}
}
server{
listen 127.0.0.1:8080;
access_log /var/log/nginx_b.log;
proxy_pass http://be/;
}
Если  запрос не попал  в  локейшен  первого сервера, то он проезжает на
второй  сервер   и отправляется на  бекэнд, если попал  в  локейшен , то
напрямую отправляется на бекэнд.  Проблема в том, что    на  бекэнде  был 
зафиксирован  запрос, который не отразился в /var/log/nginx_b.log,  но при 
этом  был в /var/log/nginx_a.log.  Можно  ли писать  в один файл  из  разных
server?  Не  будет  ли  проблем,  при  записи  access  лога на разных 
уровнях (server,location)?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258439,258439#msg-258439


From mdounin at mdounin.ru  Tue Apr 28 15:43:17 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 28 Apr 2015 18:43:17 +0300
Subject: nginx-1.9.0
Message-ID: <20150428154316.GI32429@mdounin.ru>

Изменения в nginx 1.9.0                                           28.04.2015

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

    *) Добавление: директива zone в блоке upstream.

    *) Добавление: модуль stream.

    *) Добавление: поддержка byte ranges для ответов модуля
       ngx_http_memcached_module.
       Спасибо Martin Mlyn??.

    *) Добавление: разделяемую память теперь можно использовать на версиях
       Windows с рандомизацией адресного пространства.
       Спасибо Сергею Брестеру.

    *) Добавление: директиву error_log теперь можно использовать на уровнях
       mail и server в почтовом прокси-сервере.

    *) Исправление: параметр proxy_protocol директивы listen не работал,
       если не был указан в первой директиве listen для данного
       listen-сокета.


-- 
Maxim Dounin
http://nginx.org/


From mva at mva.name  Tue Apr 28 15:56:30 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Tue, 28 Apr 2015 21:56:30 +0600
Subject: nginx-1.9.0
In-Reply-To: <20150428154316.GI32429@mdounin.ru>
References: <20150428154316.GI32429@mdounin.ru>
Message-ID: <36687119.nmMIrk5HsF@note>

В письме от Вт, 28 апреля 2015 18:43:17 пользователь Maxim Dounin написал:
> Изменения в nginx 1.9.0                                           28.04.2015
>     *) Добавление: модуль stream.
> 
Возрадуемся же // и выкинем HAProxy наконец.
>     *) Добавление: директиву error_log теперь можно использовать на уровнях
>        mail и server в почтовом прокси-сервере.
ok.jpg

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150428/29361b94/attachment.bin>

From mva at mva.name  Tue Apr 28 16:25:25 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Tue, 28 Apr 2015 22:25:25 +0600
Subject: nginx-1.9.0
In-Reply-To: <36687119.nmMIrk5HsF@note>
References: <20150428154316.GI32429@mdounin.ru> <36687119.nmMIrk5HsF@note>
Message-ID: <1824814.SYec3WGJDo@note>

Кстати, обнаружил, что в доках нигде нет описания cpp_test_module и с чем его 
едят :)
Ну, или я плохо искал и гуглил :)

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150428/535f2c81/attachment.bin>

From mva at mva.name  Tue Apr 28 16:28:21 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Tue, 28 Apr 2015 22:28:21 +0600
Subject: nginx-1.9.0
In-Reply-To: <1824814.SYec3WGJDo@note>
References: <20150428154316.GI32429@mdounin.ru> <36687119.nmMIrk5HsF@note>
 <1824814.SYec3WGJDo@note>
Message-ID: <4258417.1loX27BqPb@note>

Быстрофикс: нигде, кроме, собственно, коммита, в котором Игорь его добавляет в 
0.7 ветку :)
Но, имхо, всё равно не плохо бы где-нибудь в документации оставить заметку о 
том что оно такое и для чего :)

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150428/dda362d8/attachment.bin>

From vbart at nginx.com  Tue Apr 28 16:28:31 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Tue, 28 Apr 2015 19:28:31 +0300
Subject: nginx-1.9.0
In-Reply-To: <1824814.SYec3WGJDo@note>
References: <20150428154316.GI32429@mdounin.ru> <36687119.nmMIrk5HsF@note>
 <1824814.SYec3WGJDo@note>
Message-ID: <5147569.DqszF6ejrk@vbart-workstation>

On Tuesday 28 April 2015 22:25:25 Vadim A. Misbakh-Soloviov wrote:
> Кстати, обнаружил, что в доках нигде нет описания cpp_test_module и с чем его 
> едят :)
> Ну, или я плохо искал и гуглил :)
> 
> 

А должно быть?  Это проверка на сборку с C++.

--
Валентин Бартенев

From v.antonovich at gmail.com  Tue Apr 28 16:38:06 2015
From: v.antonovich at gmail.com (Victor Antonovich)
Date: Tue, 28 Apr 2015 19:38:06 +0300
Subject: nginx-1.9.0
In-Reply-To: <36687119.nmMIrk5HsF@note>
References: <20150428154316.GI32429@mdounin.ru> <36687119.nmMIrk5HsF@note>
Message-ID: <553FB76E.8080508@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

28.04.2015 18:56, Vadim A. Misbakh-Soloviov пишет:
> В письме от Вт, 28 апреля 2015 18:43:17 пользователь Maxim Dounin
> написал:
>> Изменения в nginx 1.9.0
>> 28.04.2015 *) Добавление: модуль stream.
>> 
> Возрадуемся же // и выкинем HAProxy наконец.

Я бы вот с удовольствием выкинул, но есть ли в модуле stream поддержка
протокола PROXY для бекендов? Бегло просмотрел исходники, нашел только
ngx_proxy_protocol_parse. Получается, сейчас бекендам никак не
прокинуть адрес клиента с фронтенда?

- ---
Cheers!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVP7duAAoJEM4WD7SRG0oPHN0H/2hny+/xG99HfRbVHcpc10HO
5DAQwINlC9AzESh3IEQiDwBfHKGkl7aIlqvIDYo9nQ0Mv+6aIeaqMvvSAei/7h3H
liBd/zRnWCgqkl6kOvkBivQJAuZrPVxZctG8D07kq0HnI3t1bJwECFEWNsMyFZCw
0OSTN7nxjyHNrxwBvlfDRy2LQn8bXxe/xdvr0sXNZ55qpl131/lnN+vvJgQSFleb
b1hRBv08d1qIgj84fd+w44rCogdUKTm5kRm8hTjbCk5e4rlDIgEGfo2tPLS7KKyP
0104C75iAJv3rpcM6GLPe8pGPKClXolTgXytxZIA03se60hyOax1nbzR3e1Cbh0=
=oLJA
-----END PGP SIGNATURE-----


From annulen at yandex.ru  Tue Apr 28 18:20:41 2015
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Tue, 28 Apr 2015 21:20:41 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <CA+ksgAD7EXeqouNSG-_mDK2whaq=N6UuRVXFVcGBron-XJ59PQ@mail.gmail.com>
References: <CALiQiZmB+1XaSRvMPiaWWNx9zjGTmR6+DN35isk5eDFOZao4WQ@mail.gmail.com>
 <1a00983691f4e9284c3a8529436a7181.NginxMailingListRussian@forum.nginx.org>
 <CA+ksgAD7EXeqouNSG-_mDK2whaq=N6UuRVXFVcGBron-XJ59PQ@mail.gmail.com>
Message-ID: <541951430245241@web22g.yandex.ru>



28.04.2015, 15:46, "Иван Мишин" <simplebox66 at gmail.com>:
> А есть ли какое-то ограничение на длину syslog сообщения поступающего со стороны nginx в rsyslog?

Из rfc3164: "The total length of the packet MUST be 1024 bytes or less"

>
> 24 апреля 2015 г., 18:47 пользователь igor.goncharenko <nginx-forum at nginx.us> написал:
>> rsyslog тоже умеет уже с достаточно древних версий отложенную доставку в
>> бесплатной версии (не знаю, есть ли там платная), но только если доставка по
>> tcp если мне не изменяет память.
>>
>> В общем, "они все могут". Другое дело что нужно очень аккуратно все это
>> конфигурить, конечно.
>>
>> Vitaliy Okulov Wrote:
>> -------------------------------------------------------
>>> Судя по описанию - будет складировать, а потом дошлет
>>> https://www.balabit.com/network-security/syslog-ng/central-syslog-serv
>>> er/features
>>>
>>> Думаю что блокировать не будет, иначе при отвале коллектора сервер
>>> встанет.
>>> 24 апр. 2015 г. 15:59 пользователь "Igor Sysoev" <igor at sysoev.ru>
>>> написал:
>>>
>>> > On 24 Apr 2015, at 15:49, Vitaliy Okulov <vitaliy.okulov at gmail.com>
>>> wrote:
>>> >
>>> > Платная версия syslog-ng умеет гарантировать доставку. В этой
>>> ситуации
>>> > стоит поднять локальный syslog.
>>> >
>>> > А что будет с syslog-ng, если удалённый хост не доступен, он будет
>>> > полученное локально складировать?
>>> > Гарантируется ли, что запись в syslog-ng не будет блокировать
>>> записывающий
>>> > процесс дольше, чем
>>> > запись на диск?
>>> >
>>> >
>>> > --
>>> > Igor Sysoev
>>> > http://nginx.com
>>> >
>>> > 24 апр. 2015 г. 15:46 пользователь "Igor Sysoev" <igor at sysoev.ru>
>>> написал:
>>> >
>>> >> On 24 Apr 2015, at 15:25, Иван Мишин <simplebox66 at gmail.com>
>>> wrote:
>>> >>
>>> >> Лучше бы поддержка syslog была по rfc5424
>>> >>
>>> >>
>>> >> Если нужна надёжная доставка логов, то их надо записывать в
>>> локальные
>>> >> файлы, ротировать их хоть каждую минуту и копировать в
>>> централизованное
>>> >> хранилище. Логирование в syslog - это для тех, кому надёжная
>>> доставка не
>>> >> критична.
>>> >>
>>> >>
>>> >> --
>>> >> Igor Sysoev
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>
>> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258330,258364#msg-258364
>>
>> _______________________________________________
>> 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


-- 
Regards,
Konstantin


From mdounin at mdounin.ru  Tue Apr 28 19:19:02 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 28 Apr 2015 22:19:02 +0300
Subject: =?UTF-8?B?UmU6INCb0L7Qs9C40YDQvtCy0LDQvdC40LUg0LIg0L7QtNC40L0g0YTQsNC50Lsg?=
 =?UTF-8?B?0LjQtyDRgNCw0LfQvdGL0YUgc2VydmVy?=
In-Reply-To: <cce167a8409d97892a76792ed98f8cb3.NginxMailingListRussian@forum.nginx.org>
References: <cce167a8409d97892a76792ed98f8cb3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20150428191902.GN32429@mdounin.ru>

Hello!

On Tue, Apr 28, 2015 at 11:18:26AM -0400, BieZax wrote:

> Добрый  день.
> 
> Сейчас имеется  такая структура:
> server{
> access_log /var/log/nginx_a.log;
> location / {
> proxy_pass http://127.0.0.1:8080/
> }
> location /1/ {
> access_log /var/log/nginx_b.log;
> proxy_pass http://be/;
> }
> }
> server{
> listen 127.0.0.1:8080;
> access_log /var/log/nginx_b.log;
> proxy_pass http://be/;
> }
> Если  запрос не попал  в  локейшен  первого сервера, то он проезжает на
> второй  сервер   и отправляется на  бекэнд, если попал  в  локейшен , то
> напрямую отправляется на бекэнд.  Проблема в том, что    на  бекэнде  был 
> зафиксирован  запрос, который не отразился в /var/log/nginx_b.log,  но при 
> этом  был в /var/log/nginx_a.log.  Можно  ли писать  в один файл  из  разных
> server?  Не  будет  ли  проблем,  при  записи  access  лога на разных 
> уровнях (server,location)?

Можно, проблем быть не должно.

Если что-то не пишется - это либо ошибка в системе, либо ошибка в 
nginx'е, либо ошибка в вашем понимании того, что и куда должно 
писаться.  E.g., в приведённом конфиге запросы, отправленные на 
бекенд, могут не попадать в nginx_b.log, если также используется 
обработка ошибок с помощью директивы error_page.

-- 
Maxim Dounin
http://nginx.org/


From denis at webmaster.spb.ru  Tue Apr 28 20:26:17 2015
From: denis at webmaster.spb.ru (denis)
Date: Tue, 28 Apr 2015 23:26:17 +0300
Subject: =?UTF-8?B?UmU6INCb0L7Qs9C40YDQvtCy0LDQvdC40LUg0LIg0L7QtNC40L0g0YTQsNC50Lsg?=
 =?UTF-8?B?0LjQtyDRgNCw0LfQvdGL0YUgc2VydmVy?=
In-Reply-To: <cce167a8409d97892a76792ed98f8cb3.NginxMailingListRussian@forum.nginx.org>
References: <cce167a8409d97892a76792ed98f8cb3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <553FECE9.5040100@webmaster.spb.ru>

Нужно учитывать багофичу: если на уровне http  определен ахсекс или 
еррор лог, а где-то глубже лог снова появляется - в корневой оно уже не 
попадёт. Это вынуждает городить сложные системы инклудов, когда 1 запись 
нужна в 2-3-... файлах. Банально - сбор информации по доменам - 
определяем на уровнях http, server, locaton и ВСЕХ местах, где есть 
вывод в отдельный лог.
Хорошо бы сделать опцию например global, чтобы в этот файл писалось 
ВСЕГДА, но если это и будет, то только в платной версии :(
> Если  запрос не попал  в  локейшен  первого сервера, то он проезжает на
> второй  сервер   и отправляется на  бекэнд, если попал  в  локейшен , то
> напрямую отправляется на бекэнд.  Проблема в том, что    на  бекэнде  был
> зафиксирован  запрос, который не отразился в /var/log/nginx_b.log,  но при
> этом  был в /var/log/nginx_a.log.  Можно  ли писать  в один файл  из  разных
> server?  Не  будет  ли  проблем,  при  записи  access  лога на разных
> уровнях (server,location)?


From bogdar at gmail.com  Wed Apr 29 03:56:39 2015
From: bogdar at gmail.com (Bogdan)
Date: Wed, 29 Apr 2015 06:56:39 +0300
Subject: =?UTF-8?B?0JHQsNC70LDQvdGB0LjRgNC+0LLQutCwINC80LXQttC00YMgSFRUUCDQuCBGYXN0?=
 =?UTF-8?B?Q0dJINCx0Y3QutC10L3QtNCw0LzQuA==?=
Message-ID: <CACz2Q8Ht5hrMDm8=boQPYPPdfLEUGUq1A_SNjiGOF5zxw=7fVQ@mail.gmail.com>

Добрый день.

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

Пока в голову приходит только двойное проксирование через два отдельных
локальных server, один из которых будет передавать трафик на http, а второй
- на fastcgi-бэкенды.

Может быть есть более гуманные методы?

-- 
WBR,  Bogdan B. Rudas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150429/a41ab125/attachment.html>

From nginx-ru at sadok.spb.ru  Wed Apr 29 05:46:18 2015
From: nginx-ru at sadok.spb.ru (Dmitry Ivanov)
Date: Wed, 29 Apr 2015 08:46:18 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <541951430245241@web22g.yandex.ru>
References: <CALiQiZmB+1XaSRvMPiaWWNx9zjGTmR6+DN35isk5eDFOZao4WQ@mail.gmail.com>
 <1a00983691f4e9284c3a8529436a7181.NginxMailingListRussian@forum.nginx.org>
 <CA+ksgAD7EXeqouNSG-_mDK2whaq=N6UuRVXFVcGBron-XJ59PQ@mail.gmail.com>
 <541951430245241@web22g.yandex.ru>
Message-ID: <71379671.20150429084618@sadok.spb.ru>

Здравствуйте, Konstantin.

Вы писали 28 апреля 2015 г., 21:20:41:


> 28.04.2015, 15:46, "Иван Мишин" <simplebox66 at gmail.com>:
>> А есть ли какое-то ограничение на длину syslog сообщения поступающего со стороны nginx в rsyslog?

> Из rfc3164: "The total length of the packet MUST be 1024 bytes or less"

Я смотрю поток с ASA и там есть и по 1900 байт сообщения.

-- 
С уважением,
 Dmitry                          mailto:nginx-ru at sadok.spb.ru


From mva at mva.name  Wed Apr 29 05:56:57 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Wed, 29 Apr 2015 11:56:57 +0600
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <71379671.20150429084618@sadok.spb.ru>
References: <CALiQiZmB+1XaSRvMPiaWWNx9zjGTmR6+DN35isk5eDFOZao4WQ@mail.gmail.com>
 <541951430245241@web22g.yandex.ru> <71379671.20150429084618@sadok.spb.ru>
Message-ID: <7582042.hKvKZcYmed@note>

В письме от Ср, 29 апреля 2015 08:46:18 пользователь Dmitry Ivanov написал:
> > Из rfc3164: "The total length of the packet MUST be 1024 bytes or less"
> 
> Я смотрю поток с ASA и там есть и по 1900 байт сообщения.

Если какие-то "большие" бренды намеренно и массово нарушают стандарты, это 
вовсе не означает, что стандарт ? то, как делают большие бренды :)


-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150429/6f4ec40b/attachment.bin>

From mva at mva.name  Wed Apr 29 05:58:40 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Wed, 29 Apr 2015 11:58:40 +0600
Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCDQvNC10LbQtNGDIEhUVFAg0Lgg?=
 =?UTF-8?B?RmFzdENHSSDQsdGN0LrQtdC90LTQsNC80Lg=?=
In-Reply-To: <CACz2Q8Ht5hrMDm8=boQPYPPdfLEUGUq1A_SNjiGOF5zxw=7fVQ@mail.gmail.com>
References: <CACz2Q8Ht5hrMDm8=boQPYPPdfLEUGUq1A_SNjiGOF5zxw=7fVQ@mail.gmail.com>
Message-ID: <3469185.jrovqLLESp@note>

В письме от Ср, 29 апреля 2015 06:56:39 пользователь Bogdan написал:
> Может быть есть более гуманные методы?

Не могли бы вы чуть более детально описать проблему?
А то в текущей версии объяснения я не вижу необходимости поднимать лишнюю 
"прослойку", например...

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150429/bf2ab55e/attachment.bin>

From simplebox66 at gmail.com  Wed Apr 29 07:51:37 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Wed, 29 Apr 2015 10:51:37 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <7582042.hKvKZcYmed@note>
References: <CALiQiZmB+1XaSRvMPiaWWNx9zjGTmR6+DN35isk5eDFOZao4WQ@mail.gmail.com>
 <541951430245241@web22g.yandex.ru>
 <71379671.20150429084618@sadok.spb.ru> <7582042.hKvKZcYmed@note>
Message-ID: <CA+ksgAB2+T4VeHLrsnAXNA922hfywxutgau1rNocPm23eTnuvg@mail.gmail.com>

>
> 28.04.2015, 15:46, "Иван Мишин" <simplebox66 at gmail.com>:
> > А есть ли какое-то ограничение на длину syslog сообщения поступающего со
> стороны nginx в rsyslog?
> Из rfc3164: "The total length of the packet MUST be 1024 bytes or less"


А в rf5424:Syslog message size limits are dictated by the syslog transport
   mapping in use. There is no upper limit per se.

И вообще это ограничение касается syslog, а не nginx


 > Я смотрю поток с ASA и там есть и по 1900 байт сообщения.
> Если какие-то "большие" бренды намеренно и массово нарушают стандарты, это
> вовсе не означает, что стандарт ? то, как делают большие бренды :)


А я наладил rsyslog себе, который работает в соответствии с rf5424.
Поставил лимит на длину сообщения 24k и попробовал сгенерить запрос такого
размера. И увидел что nginx нормально передает длину строки 24k, а rsyslog
нормально ее кушает и записывает в журнал.  Жаль только что nginx способен
с сислогом общаться только по UDP. Ну хорошо хотя бы порт можно поменять.

29 апреля 2015 г., 8:56 пользователь Vadim A. Misbakh-Soloviov <mva at mva.name
> написал:

> В письме от Ср, 29 апреля 2015 08:46:18 пользователь Dmitry Ivanov написал:
> > > Из rfc3164: "The total length of the packet MUST be 1024 bytes or less"
> >
> > Я смотрю поток с ASA и там есть и по 1900 байт сообщения.
>
> Если какие-то "большие" бренды намеренно и массово нарушают стандарты, это
> вовсе не означает, что стандарт ? то, как делают большие бренды :)
>
>
> --
> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150429/70fed5a7/attachment.html>

From bogdar at gmail.com  Wed Apr 29 09:17:09 2015
From: bogdar at gmail.com (Bogdan)
Date: Wed, 29 Apr 2015 12:17:09 +0300
Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCDQvNC10LbQtNGDIEhUVFAg0Lgg?=
 =?UTF-8?B?RmFzdENHSSDQsdGN0LrQtdC90LTQsNC80Lg=?=
In-Reply-To: <3469185.jrovqLLESp@note>
References: <CACz2Q8Ht5hrMDm8=boQPYPPdfLEUGUq1A_SNjiGOF5zxw=7fVQ@mail.gmail.com>
 <3469185.jrovqLLESp@note>
Message-ID: <CACz2Q8Epx4ekH_POMVaiASVpuiM3RXtOQGnU-ptwfNaeJjjgQw@mail.gmail.com>

Есть два набора бэкендов:

Старый - доступен по FastCGI
Новый - доступен по HTTP
Нужно часть запросов направить на новый набор бэкендов.
Сейчас запросы передаются на бэкенды путём указания fastcgi_pass который
указывает на upstream где перечисленый fastcgi бэкенды.


2015-04-29 8:58 GMT+03:00 Vadim A. Misbakh-Soloviov <mva at mva.name>:

> В письме от Ср, 29 апреля 2015 06:56:39 пользователь Bogdan написал:
> > Может быть есть более гуманные методы?
>
> Не могли бы вы чуть более детально описать проблему?
> А то в текущей версии объяснения я не вижу необходимости поднимать лишнюю
> "прослойку", например...
>
> --
> Best regards,
> mva
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
WBR,  Bogdan B. Rudas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150429/6b874396/attachment-0001.html>

From bazilek at gmail.com  Wed Apr 29 09:35:22 2015
From: bazilek at gmail.com (Vasil Mikhalenya)
Date: Wed, 29 Apr 2015 12:35:22 +0300
Subject: nginx cache
In-Reply-To: <2117741.WdtaKZC1TT@vbart-laptop>
References: <CAPc4iSD1bOSu6Uo_hcOXQ8PWZ=4V573pfh9mEnV1JGkSyrzHqA@mail.gmail.com>
 <CAPc4iSDwx3hVzicPXcGWamp37JKrkHFJx0FcJwRaAJd3oB8MZw@mail.gmail.com>
 <CAPc4iSDp1hA1VPjko75Ku4Ps8V82OBy5Cjr4nKwJ90SKMPeu5g@mail.gmail.com>
 <2117741.WdtaKZC1TT@vbart-laptop>
Message-ID: <CAPc4iSBuoWoh2QTBFA7-TXR_M5ZqyHmm0xogS_BmPEWRef5kkg@mail.gmail.com>

Коллеги, подскажите что происходит

CentOS Linux release 7.1.1503 (Core)

nginx version: nginx/1.7.10

built by gcc 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC)

TLS SNI support enabled

configure arguments: --user=nginx --group=nginx --prefix=/usr/share/nginx
--sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log
--http-client-body-temp-path=/var/lib/nginx/tmp/client_body
--http-proxy-temp-path=/var/lib/nginx/tmp/proxy
--http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi
--pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx
--with-openssl=/builddir/build/BUILD/nginx-1.7.10/openssl-1.0.2a
--with-openssl-opt=enable-tlsext --with-http_secure_link_module
--with-http_random_index_module --with-http_ssl_module
--with-http_realip_module --with-http_addition_module
--with-http_sub_module --with-http_dav_module
--with-http_gzip_static_module --with-http_stub_status_module
--with-http_geoip_module --with-http_spdy_module
--with-http_auth_request_module --with-debug --with-file-aio
--with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic'
--add-module=/builddir/build/BUILD/nginx-1.7.10/ngx_devel_kit-0.2.19
--add-module=/builddir/build/BUILD/nginx-1.7.10/nginx_accept_language_module
--add-module=/builddir/build/BUILD/nginx-1.7.10/lua-nginx-module-0.9.12
--add-module=/builddir/build/BUILD/nginx-1.7.10/nginx-dav-ext-module
--add-module=/builddir/build/BUILD/nginx-1.7.10/naxsi-0.53-2/naxsi_src
--add-module=/builddir/build/BUILD/nginx-1.7.10/ngx_http_redis-0.3.7
--add-module=/builddir/build/BUILD/nginx-1.7.10/echo-nginx-module-0.56


proxy_cache_path /var/lib/nginx/cache keys_zone=mycdn:20m inactive=1d
use_temp_path=off;


server {

    listen 80;

    server_name mycdn.com 127.0.0.1;


    proxy_cache mycdn;


    location / {

        proxy_pass http://origin;

        proxy_set_header Host       $proxy_host;

        proxy_cache_lock on;

        proxy_cache_lock_age 2h;

        proxy_cache_lock_timeout 2h;

        proxy_cache_key "$uri";

        add_header Cache $upstream_cache_status;

    }

}


[root at node ~]# ll /var/lib/nginx/cache/ | wc -l

228
т.е. у nginx в cache есть около 2 сотен популярных файлов  (118G
/var/lib/nginx/cache/),
он успешно отдает несколько дней, ничего нового из origin не качает, в
какой то момент случается это

[root at node ~]# ll /var/lib/nginx/cache/temp/ | wc -l

5714

Т.е. число файлов в temp растет очень быстро, хотя обычно = 0.

restart nginx и очистка tempdir не помогает (файлы в tempdir появляются
снова), помогает только полная очистка cache

Пользователи делают запросы с range.




2015-04-17 2:27 GMT+03:00 Валентин Бартенев <vbart at nginx.com>:

> On Thursday 16 April 2015 17:48:20 Vasil Mikhalenya wrote:
> > возможно ли ограничить количество одновременно загружаемых файлов с
> > апстрима?
> >
> [..]
>
> http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html
>
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Best regards,
Vasil Mikhalenya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150429/51dd40bb/attachment.html>

From mdounin at mdounin.ru  Wed Apr 29 11:18:18 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 29 Apr 2015 14:18:18 +0300
Subject: nginx cache
In-Reply-To: <CAPc4iSBuoWoh2QTBFA7-TXR_M5ZqyHmm0xogS_BmPEWRef5kkg@mail.gmail.com>
References: <CAPc4iSD1bOSu6Uo_hcOXQ8PWZ=4V573pfh9mEnV1JGkSyrzHqA@mail.gmail.com>
 <CAPc4iSDwx3hVzicPXcGWamp37JKrkHFJx0FcJwRaAJd3oB8MZw@mail.gmail.com>
 <CAPc4iSDp1hA1VPjko75Ku4Ps8V82OBy5Cjr4nKwJ90SKMPeu5g@mail.gmail.com>
 <2117741.WdtaKZC1TT@vbart-laptop>
 <CAPc4iSBuoWoh2QTBFA7-TXR_M5ZqyHmm0xogS_BmPEWRef5kkg@mail.gmail.com>
Message-ID: <20150429111818.GQ32429@mdounin.ru>

Hello!

On Wed, Apr 29, 2015 at 12:35:22PM +0300, Vasil Mikhalenya wrote:

> Коллеги, подскажите что происходит

[...]

> proxy_cache_path /var/lib/nginx/cache keys_zone=mycdn:20m inactive=1d
> use_temp_path=off;
> 
> 
> server {
>     listen 80;
>     server_name mycdn.com 127.0.0.1;
> 
>     proxy_cache mycdn;
> 
>     location / {
>         proxy_pass http://origin;
>         proxy_set_header Host       $proxy_host;
>         proxy_cache_lock on;
>         proxy_cache_lock_age 2h;
>         proxy_cache_lock_timeout 2h;
>         proxy_cache_key "$uri";
>         add_header Cache $upstream_cache_status;
>     }
> }
> 
> 
> [root at node ~]# ll /var/lib/nginx/cache/ | wc -l
> 
> 228
> т.е. у nginx в cache есть около 2 сотен популярных файлов  (118G
> /var/lib/nginx/cache/),
> он успешно отдает несколько дней, ничего нового из origin не качает, в
> какой то момент случается это

Видимо, это происходит в тот момент, когда ответы в кеше 
expire'ятся.  Имеет смысл включить "proxy_cache_use_stale 
updating", см. тут:

http://nginx.org/r/proxy_cache_use_stale/ru

Кроме того, если речь идёт о больших статических файлах - имеет 
смысл также использовать proxy_cache_revalidate, см. тут:

http://nginx.org/r/proxy_cache_revalidate/ru

> [root at node ~]# ll /var/lib/nginx/cache/temp/ | wc -l
> 
> 5714
> 
> Т.е. число файлов в temp растет очень быстро, хотя обычно = 0.
> 
> restart nginx и очистка tempdir не помогает (файлы в tempdir появляются
> снова), помогает только полная очистка cache

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

-- 
Maxim Dounin
http://nginx.org/


From mdounin at mdounin.ru  Wed Apr 29 12:21:27 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 29 Apr 2015 15:21:27 +0300
Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCDQvNC10LbQtNGDIEhUVFAg0Lgg?=
 =?UTF-8?B?RmFzdENHSSDQsdGN0LrQtdC90LTQsNC80Lg=?=
In-Reply-To: <CACz2Q8Ht5hrMDm8=boQPYPPdfLEUGUq1A_SNjiGOF5zxw=7fVQ@mail.gmail.com>
References: <CACz2Q8Ht5hrMDm8=boQPYPPdfLEUGUq1A_SNjiGOF5zxw=7fVQ@mail.gmail.com>
Message-ID: <20150429122127.GV32429@mdounin.ru>

Hello!

On Wed, Apr 29, 2015 at 06:56:39AM +0300, Bogdan wrote:

> Добрый день.
> 
> В связи с миграцией на новую версию приложения хочется подать часть
> нагрузки на новый HTTP-бэкенд.
> 
> Пока в голову приходит только двойное проксирование через два отдельных
> локальных server, один из которых будет передавать трафик на http, а второй
> - на fastcgi-бэкенды.
> 
> Может быть есть более гуманные методы?

Можно воспользоваться возможностями модуля rewrite, и по 
какому-либо признаку (например, с помощью split_clients) часть 
трафика отправить в отдельно место.

Если конфигурация простая - то можно даже обойтись одной 
директивой if, как-то так:

    split_clients $remote_addr $new {
                   0.5%        1;
                   *           0;
    }

    server {
        ...

        location / {
            if ($new) {
                proxy_pass http://new.example.com;
            }

            fastcgi_pass old.example.com;
        }
    }

Документация тут:

http://nginx.org/ru/docs/http/ngx_http_split_clients_module.html
http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html

-- 
Maxim Dounin
http://nginx.org/


From mdounin at mdounin.ru  Wed Apr 29 14:01:08 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 29 Apr 2015 17:01:08 +0300
Subject: =?UTF-8?B?UmU6INCQ0LTRgNC10YEgdGNwINGB0L7QutC10YLQsCDQv9C+0YHQu9C1IHNldF9y?=
 =?UTF-8?B?ZWFsX2lwX2Zyb20=?=
In-Reply-To: <CAAtQP1wqCS_DSdmo5Gszr-VMX5DPeLMDjq45KfRc_J=Smr=ELA@mail.gmail.com>
References: <CAAtQP1wqCS_DSdmo5Gszr-VMX5DPeLMDjq45KfRc_J=Smr=ELA@mail.gmail.com>
Message-ID: <20150429140108.GB32429@mdounin.ru>

Hello!

On Tue, Apr 28, 2015 at 12:27:09AM +0300, Oleg Motienko wrote:

> Добрый день.
> 
> Подскажите, в какой переменной в случае использования set_real_ip_from
> всё-таки увидеть адрес другой tcp сокета ? Т.е. нужно получить адрес
> сервера, откуда пришел запрос.

Сейчас этого сделать нельзя.

-- 
Maxim Dounin
http://nginx.org/


From vugluskr at vugluskr.org.ua  Wed Apr 29 15:06:10 2015
From: vugluskr at vugluskr.org.ua (Dmitry Bogun)
Date: Wed, 29 Apr 2015 10:06:10 -0500
Subject: SSI include VS html encode
Message-ID: <ABCD5516-3927-4C36-ADE9-CEEBCF3AC975@vugluskr.org.ua>

День добрый.

Столкнулся с проблемой, на странице имеется SSI инструкция, примерно такого вида:

<!--# include virtual="/ssi/user/name&quot;/tags.html? -->

При обработке которой получаем ошибку вида:
*31707821 open() ?/www/ssi/user/name&quot;/tags.html" failed (2: No such file or directory)

Что в целом справедливо - на FS символ ? не экранизирован т.к. там это не требуется? Вопрос прав ли nginx, что ломится за файлом без преобразования экранизированных символов или не прав?

# nginx -v
nginx version: nginx/1.7.6

From konstantin at symbi.org  Thu Apr 30 03:06:05 2015
From: konstantin at symbi.org (Konstantin Baryshnikov)
Date: Thu, 30 Apr 2015 06:06:05 +0300
Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCDQvNC10LbQtNGDIEhUVFAg0Lgg?=
 =?UTF-8?B?RmFzdENHSSDQsdGN0LrQtdC90LTQsNC80Lg=?=
In-Reply-To: <20150429122127.GV32429@mdounin.ru>
References: <CACz2Q8Ht5hrMDm8=boQPYPPdfLEUGUq1A_SNjiGOF5zxw=7fVQ@mail.gmail.com>
 <20150429122127.GV32429@mdounin.ru>
Message-ID: <F45CA052-3237-423A-A1C1-8AFF2A277763@symbi.org>

On Apr 29, 2015, at 3:21 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

>        location / {
>            if ($new) {
>                proxy_pass http://new.example.com;
>            }
> 
>            fastcgi_pass old.example.com;
>        }
>    }

Ого, а это теперь работает?

Всегда считал это гарантированным способом отстрелить себе ногу. Что-то изменилось?

From mva at mva.name  Thu Apr 30 06:12:05 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 30 Apr 2015 12:12:05 +0600
Subject: nginx-1.9.0
In-Reply-To: <20150428154316.GI32429@mdounin.ru>
References: <20150428154316.GI32429@mdounin.ru>
Message-ID: <2577780.ATHIf8JsOm@note>

Кстати, как справедливо заметил кто-то в интернетах, что-то у stream module 
слишком много "вкусных" фич всё ещё осталось в NgX+.
Ну и документация пока только на английском (хотя это уже не такая большая 
досада, как первое) :)

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150430/39339710/attachment.bin>

From mva at mva.name  Thu Apr 30 07:10:13 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 30 Apr 2015 13:10:13 +0600
Subject: nginx-1.9.0
In-Reply-To: <20150428154316.GI32429@mdounin.ru>
References: <20150428154316.GI32429@mdounin.ru>
Message-ID: <1719246.uqHqBrdbN3@note>

Кстати, на правах фичреквеста:
в stream-модуле не хватает access, log и rewrite (на самом деле, только `if` 
из него, хоть он и "Evil") субмодулей (каковые есть у http).

Вроде, как я вижу по коду, ngx_http_set_connection_log уже перекочевал в 
глобальный ngx_set_connection_log, так что, вроде как, есть надежда на 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150430/35c5c980/attachment.bin>

From motienko at gmail.com  Thu Apr 30 07:13:35 2015
From: motienko at gmail.com (Oleg Motienko)
Date: Thu, 30 Apr 2015 10:13:35 +0300
Subject: =?UTF-8?B?UmU6INCQ0LTRgNC10YEgdGNwINGB0L7QutC10YLQsCDQv9C+0YHQu9C1IHNldF9y?=
 =?UTF-8?B?ZWFsX2lwX2Zyb20=?=
In-Reply-To: <20150429140108.GB32429@mdounin.ru>
References: <CAAtQP1wqCS_DSdmo5Gszr-VMX5DPeLMDjq45KfRc_J=Smr=ELA@mail.gmail.com>
 <20150429140108.GB32429@mdounin.ru>
Message-ID: <CAAtQP1xeLi-4yHi5zNd6TEkEdtVCELMNVY1S1tUjAjQrN=kqRQ@mail.gmail.com>

Спасибо, буду продолжать раз в 1,5-2 года поднимать этот вопрос.

2015-04-29 17:01 GMT+03:00 Maxim Dounin <mdounin at mdounin.ru>:
>
> Hello!
>
> On Tue, Apr 28, 2015 at 12:27:09AM +0300, Oleg Motienko wrote:
>
> > Добрый день.
> >
> > Подскажите, в какой переменной в случае использования set_real_ip_from
> > всё-таки увидеть адрес другой tcp сокета ? Т.е. нужно получить адрес
> > сервера, откуда пришел запрос.
>
> Сейчас этого сделать нельзя.
>



-- 
Regards,
Oleg

From vbart at nginx.com  Thu Apr 30 07:16:09 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 30 Apr 2015 10:16:09 +0300
Subject: nginx-1.9.0
In-Reply-To: <1719246.uqHqBrdbN3@note>
References: <20150428154316.GI32429@mdounin.ru> <1719246.uqHqBrdbN3@note>
Message-ID: <1987134.Yy55mS7sHN@vbart-laptop>

On Thursday 30 April 2015 13:10:13 Vadim A. Misbakh-Soloviov wrote:
> Кстати, на правах фичреквеста:
> в stream-модуле не хватает access, log и rewrite (на самом деле, только `if` 
> из него, хоть он и "Evil") субмодулей (каковые есть у http).

Что предполагается делать с if с учетом отсутствия location и переменных
как класса?

> 
> Вроде, как я вижу по коду, ngx_http_set_connection_log уже перекочевал в 
> глобальный ngx_set_connection_log, так что, вроде как, есть надежда на log-
> модуль. Про остальные, впрочем, не ясно (ну, хотя, я не так пристально 
> вглядывался в код по этому поводу).

Это функции error_log и к лог модулю отношения не имеют.
error_log там есть, он же логирует подключения на уровне info.

--
Валентин

From pavel2000 at ngs.ru  Thu Apr 30 07:44:00 2015
From: pavel2000 at ngs.ru (Pavel V.)
Date: Thu, 30 Apr 2015 13:44:00 +0600
Subject: =?UTF-8?B?UmU6INCQ0LTRgNC10YEgdGNwINGB0L7QutC10YLQsCDQv9C+0YHQu9C1IHNldF9y?=
 =?UTF-8?B?ZWFsX2lwX2Zyb20=?=
In-Reply-To: <CAAtQP1xeLi-4yHi5zNd6TEkEdtVCELMNVY1S1tUjAjQrN=kqRQ@mail.gmail.com>
References: <CAAtQP1wqCS_DSdmo5Gszr-VMX5DPeLMDjq45KfRc_J=Smr=ELA@mail.gmail.com>
 <20150429140108.GB32429@mdounin.ru>
 <CAAtQP1xeLi-4yHi5zNd6TEkEdtVCELMNVY1S1tUjAjQrN=kqRQ@mail.gmail.com>
Message-ID: <2710679975.20150430134400@ngs.ru>

Здравствуйте, Oleg.

> Спасибо, буду продолжать раз в 1,5-2 года поднимать этот вопрос.

Настройте фронтенды, чтобы каждый из них передавал свой адрес дополнительным HTTP-заголовком.
Если это возможно, конечно.


>>
>> > Добрый день.
>> >
>> > Подскажите, в какой переменной в случае использования set_real_ip_from
>> > всё-таки увидеть адрес другой tcp сокета ? Т.е. нужно получить адрес
>> > сервера, откуда пришел запрос.
>>
>> Сейчас этого сделать нельзя.
>>

-- 
С уважением,
 Pavel                          mailto:pavel2000 at ngs.ru


From mva at mva.name  Thu Apr 30 08:00:14 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 30 Apr 2015 14:00:14 +0600
Subject: nginx-1.9.0
In-Reply-To: <1987134.Yy55mS7sHN@vbart-laptop>
References: <20150428154316.GI32429@mdounin.ru> <1719246.uqHqBrdbN3@note>
 <1987134.Yy55mS7sHN@vbart-laptop>
Message-ID: <22718843.8ktbYSCAQW@note>

> Что предполагается делать с if с учетом отсутствия location и переменных
> как класса?

Ну, вообще, совсем в идеале ? разрешить if вне location и пременные. Ну и, 
кстати, совсем забыл про geo и map модули, которые тоже хотелось бы видеть и 
тут.

Т.е., например, что-нибудь а-ля:
```
map $cond1 $var1 { ... }
geo $var2 { ... }

if ($var1) { deny all; }
if ($var2 ~ "moo") { deny all; }
```


> Это функции error_log и к лог модулю отношения не имеют.
> error_log там есть, он же логирует подключения на уровне info.

Ну так я ж и говорю, "надежда" :)

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150430/277b2ac7/attachment-0001.bin>

From simplebox66 at gmail.com  Thu Apr 30 09:11:43 2015
From: simplebox66 at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Thu, 30 Apr 2015 12:11:43 +0300
Subject: =?UTF-8?Q?Re=3A_syslog_=D0=B2_nginx_1=2E8?=
In-Reply-To: <CA+ksgAB2+T4VeHLrsnAXNA922hfywxutgau1rNocPm23eTnuvg@mail.gmail.com>
References: <CALiQiZmB+1XaSRvMPiaWWNx9zjGTmR6+DN35isk5eDFOZao4WQ@mail.gmail.com>
 <541951430245241@web22g.yandex.ru>
 <71379671.20150429084618@sadok.spb.ru> <7582042.hKvKZcYmed@note>
 <CA+ksgAB2+T4VeHLrsnAXNA922hfywxutgau1rNocPm23eTnuvg@mail.gmail.com>
Message-ID: <CA+ksgABhggsP9eJ=JL_3LECXbM892nfyqAxKp8qoV6SjJ09iDA@mail.gmail.com>

А кто-нибудь в курсе как заставить nginx в зависимости от типа запроса http
или https выставлять определенный syslog priority ?
Что-то через if городить костыль не хотелось бы

29 апреля 2015 г., 10:51 пользователь Иван Мишин <simplebox66 at gmail.com>
написал:

> 28.04.2015, 15:46, "Иван Мишин" <simplebox66 at gmail.com>:
>> > А есть ли какое-то ограничение на длину syslog сообщения поступающего
>> со стороны nginx в rsyslog?
>> Из rfc3164: "The total length of the packet MUST be 1024 bytes or less"
>
>
> А в rf5424:Syslog message size limits are dictated by the syslog transport
>    mapping in use. There is no upper limit per se.
>
> И вообще это ограничение касается syslog, а не nginx
>
>
>  > Я смотрю поток с ASA и там есть и по 1900 байт сообщения.
>> Если какие-то "большие" бренды намеренно и массово нарушают стандарты, это
>> вовсе не означает, что стандарт ? то, как делают большие бренды :)
>
>
> А я наладил rsyslog себе, который работает в соответствии с rf5424.
> Поставил лимит на длину сообщения 24k и попробовал сгенерить запрос такого
> размера. И увидел что nginx нормально передает длину строки 24k, а rsyslog
> нормально ее кушает и записывает в журнал.  Жаль только что nginx способен
> с сислогом общаться только по UDP. Ну хорошо хотя бы порт можно поменять.
>
> 29 апреля 2015 г., 8:56 пользователь Vadim A. Misbakh-Soloviov <
> mva at mva.name> написал:
>
>> В письме от Ср, 29 апреля 2015 08:46:18 пользователь Dmitry Ivanov
>> написал:
>> > > Из rfc3164: "The total length of the packet MUST be 1024 bytes or
>> less"
>> >
>> > Я смотрю поток с ASA и там есть и по 1900 байт сообщения.
>>
>> Если какие-то "большие" бренды намеренно и массово нарушают стандарты, это
>> вовсе не означает, что стандарт ? то, как делают большие бренды :)
>>
>>
>> --
>> 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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150430/a230b7dc/attachment.html>

From nginx-forum at nginx.us  Thu Apr 30 10:07:19 2015
From: nginx-forum at nginx.us (sidewinder)
Date: Thu, 30 Apr 2015 06:07:19 -0400
Subject: (13: Permission denied)
Message-ID: <86ecfcce3bf7d2a02c3b048006447581.NginxMailingListRussian@forum.nginx.org>

Поискал в инете всё на эту тему - решения не нашёл. Отметил что проблема
встречается часто и давно.
Ситуация такая:
есть nginx/1.6.2 и вирутальный сервер в ~/html - настроен на один домен. Всё
работает. 
nginx работает под пользователем www-data, владелец ~/html - другой
пользоователь. Права на на чтение для всех.
Что делаю дальше:
копирую ~/html в ~/html-bc - все права остаются соответственно
копирую /etc/nginx/sites-enabled/site1.conf в
/etc/nginx/sites-enabled/site2.conf (имена условные)
в этом файле меняю server_name и root и имена лог-файлов
перезапускаю сервер.
Результат: при обращении к site2 - в логе 

2015/04/30 12:54:41 [crit] 29091#0: *76 open() "/home/user/html-bc/test.php"
failed (13: Permission denied), client: 194.1.195.216, server: *.site2.com,
request: "GET /test.php HTTP/1.1", host: "www.site2.com"

права на этот файл есть, даже если "зайти" под пользователм www-data - и
файл виден и содержимое.
если в настройках сервера для домена site2 поменять root - на html (вместо
html-bc) тогда всё работает: виден один сайт под разными доменами. Но любое
другое значение в поле root приводит к такой ошибке. 

на сервере работает ещё php-fpm и memcached - но сервер один и тот-же ,
настройки для всех одинаковые, но для одной директории (в качетвет root
виртуального сайте ) работает, а для других нет.
что за магия?

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258537,258537#msg-258537


From mva at mva.name  Thu Apr 30 10:36:00 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 30 Apr 2015 16:36 +0600
Subject: (13: Permission denied)
In-Reply-To: <86ecfcce3bf7d2a02c3b048006447581.NginxMailingListRussian@forum.nginx.org>
References: <86ecfcce3bf7d2a02c3b048006447581.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2270521.iSYunKQvYE@note>

В письме от Чт, 30 апреля 2015 06:07:19 пользователь sidewinder написал:
> копирую ~/html в ~/html-bc - все права остаются соответственно
Не "соответственно" и не "остаются" :)
Это при перемещении они остаются (и то, зависит от того, внутри ли файловой 
системы или нет). А при копировании владельцем становится копирующий 
пользователь, а права выставляются согласно umask.

> Результат: при обращении к site2 - в логе
> 
> 2015/04/30 12:54:41 [crit] 29091#0: *76 open() "/home/user/html-bc/test.php"
> failed (13: Permission denied), client: 194.1.195.216, server: *.site2.com,
> request: "GET /test.php HTTP/1.1", host: "www.site2.com"
Эта ошибка бывает так же когда нету доступа хотя бы к одному из элементов пути 
(например, у одного из каталогов нет +x для "правила",под которым пользователь 
www-data к ней обращается (user/group/other, если говорить о синтаксисе chmod)

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150430/88da582b/attachment.bin>

From bazilek at gmail.com  Thu Apr 30 11:05:13 2015
From: bazilek at gmail.com (Vasil Mikhalenya)
Date: Thu, 30 Apr 2015 14:05:13 +0300
Subject: nginx cache
In-Reply-To: <20150429111818.GQ32429@mdounin.ru>
References: <CAPc4iSD1bOSu6Uo_hcOXQ8PWZ=4V573pfh9mEnV1JGkSyrzHqA@mail.gmail.com>
 <CAPc4iSDwx3hVzicPXcGWamp37JKrkHFJx0FcJwRaAJd3oB8MZw@mail.gmail.com>
 <CAPc4iSDp1hA1VPjko75Ku4Ps8V82OBy5Cjr4nKwJ90SKMPeu5g@mail.gmail.com>
 <2117741.WdtaKZC1TT@vbart-laptop>
 <CAPc4iSBuoWoh2QTBFA7-TXR_M5ZqyHmm0xogS_BmPEWRef5kkg@mail.gmail.com>
 <20150429111818.GQ32429@mdounin.ru>
Message-ID: <CAPc4iSBf_WVMpEwXTLCi_jjfun8XcjiLLDZAU=cMMrkLbg8Lyw@mail.gmail.com>

Спасибо, пробуем.

Однако это не совсем очевидно, что во время валидации cache в tmpdir
начинают появляться файлы на каждый range запрос.

2015-04-29 14:18 GMT+03:00 Maxim Dounin <mdounin at mdounin.ru>:

> Hello!
>
> On Wed, Apr 29, 2015 at 12:35:22PM +0300, Vasil Mikhalenya wrote:
>
> > Коллеги, подскажите что происходит
>
> [...]
>
> > proxy_cache_path /var/lib/nginx/cache keys_zone=mycdn:20m inactive=1d
> > use_temp_path=off;
> >
> >
> > server {
> >     listen 80;
> >     server_name mycdn.com 127.0.0.1;
> >
> >     proxy_cache mycdn;
> >
> >     location / {
> >         proxy_pass http://origin;
> >         proxy_set_header Host       $proxy_host;
> >         proxy_cache_lock on;
> >         proxy_cache_lock_age 2h;
> >         proxy_cache_lock_timeout 2h;
> >         proxy_cache_key "$uri";
> >         add_header Cache $upstream_cache_status;
> >     }
> > }
> >
> >
> > [root at node ~]# ll /var/lib/nginx/cache/ | wc -l
> >
> > 228
> > т.е. у nginx в cache есть около 2 сотен популярных файлов  (118G
> > /var/lib/nginx/cache/),
> > он успешно отдает несколько дней, ничего нового из origin не качает, в
> > какой то момент случается это
>
> Видимо, это происходит в тот момент, когда ответы в кеше
> expire'ятся.  Имеет смысл включить "proxy_cache_use_stale
> updating", см. тут:
>
> http://nginx.org/r/proxy_cache_use_stale/ru
>
> Кроме того, если речь идёт о больших статических файлах - имеет
> смысл также использовать proxy_cache_revalidate, см. тут:
>
> http://nginx.org/r/proxy_cache_revalidate/ru
>
> > [root at node ~]# ll /var/lib/nginx/cache/temp/ | wc -l
> >
> > 5714
> >
> > Т.е. число файлов в temp растет очень быстро, хотя обычно = 0.
> >
> > restart nginx и очистка tempdir не помогает (файлы в tempdir появляются
> > снова), помогает только полная очистка cache
>
> Потому что proxy_cache_lock используется только при добавлении
> элементов в кеш.  Если хочется избежать одновременных обращений на
> бекенд нескольких клиентов при обновлении, то надо включать
> "proxy_cache_use_stale updating", см.  выше.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
Best regards,
Vasil Mikhalenya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150430/4d836838/attachment-0001.html>

From vbart at nginx.com  Thu Apr 30 12:41:53 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 30 Apr 2015 15:41:53 +0300
Subject: nginx-1.9.0
In-Reply-To: <22718843.8ktbYSCAQW@note>
References: <20150428154316.GI32429@mdounin.ru>
 <1987134.Yy55mS7sHN@vbart-laptop> <22718843.8ktbYSCAQW@note>
Message-ID: <16257629.AHyRbmbdmx@vbart-workstation>

On Thursday 30 April 2015 14:00:14 Vadim A. Misbakh-Soloviov wrote:
> > Что предполагается делать с if с учетом отсутствия location и переменных
> > как класса?
> 
> Ну, вообще, совсем в идеале ? разрешить if вне location и пременные. Ну и, 
> кстати, совсем забыл про geo и map модули, которые тоже хотелось бы видеть и 
> тут.
> 
> Т.е., например, что-нибудь а-ля:
> ```
> map $cond1 $var1 { ... }
> geo $var2 { ... }
> 
> if ($var1) { deny all; }
> if ($var2 ~ "moo") { deny all; }
> ```
> 

Там из переменных только ip может быть.  Зачем все так усложнять?

--
Валентин

From nginx-forum at nginx.us  Thu Apr 30 13:33:45 2015
From: nginx-forum at nginx.us (sidewinder)
Date: Thu, 30 Apr 2015 09:33:45 -0400
Subject: (13: Permission denied)
In-Reply-To: <2270521.iSYunKQvYE@note>
References: <2270521.iSYunKQvYE@note>
Message-ID: <073261e4708c8ec7db79d18cb619622e.NginxMailingListRussian@forum.nginx.org>

Да. Все права проверил. Копировал тот же пользователь свои же файлы. Он был
владельцем стараых и стал владельцем новых. Старый сайт работает, новый
нет.
Кроме того сделал такую штуку: 
sudo su - s www-data
lsl -l /home/user/html-bc/test.php
cat /home/user/html-bc/test.php
доступ есть - и на чтение директории и на чтение файла.
У меня уже просто крыша едет - не могу понять в чём проблема, каких ещё
пермишенов не хватает.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,258537,258542#msg-258542


From vbart at nginx.com  Thu Apr 30 13:38:21 2015
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 30 Apr 2015 16:38:21 +0300
Subject: (13: Permission denied)
In-Reply-To: <073261e4708c8ec7db79d18cb619622e.NginxMailingListRussian@forum.nginx.org>
References: <2270521.iSYunKQvYE@note>
 <073261e4708c8ec7db79d18cb619622e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <11727709.EHt516CsDb@vbart-workstation>

On Thursday 30 April 2015 09:33:45 sidewinder wrote:
> Да. Все права проверил. Копировал тот же пользователь свои же файлы. Он был
> владельцем стараых и стал владельцем новых. Старый сайт работает, новый
> нет.
> Кроме того сделал такую штуку: 
> sudo su - s www-data
> lsl -l /home/user/html-bc/test.php
> cat /home/user/html-bc/test.php
> доступ есть - и на чтение директории и на чтение файла.
> У меня уже просто крыша едет - не могу понять в чём проблема, каких ещё
> пермишенов не хватает.
> 

selinux?

--
Валентин Бартенев

From mdounin at mdounin.ru  Thu Apr 30 13:49:02 2015
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 30 Apr 2015 16:49:02 +0300
Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCDQvNC10LbQtNGDIEhUVFAg0Lgg?=
 =?UTF-8?B?RmFzdENHSSDQsdGN0LrQtdC90LTQsNC80Lg=?=
In-Reply-To: <F45CA052-3237-423A-A1C1-8AFF2A277763@symbi.org>
References: <CACz2Q8Ht5hrMDm8=boQPYPPdfLEUGUq1A_SNjiGOF5zxw=7fVQ@mail.gmail.com>
 <20150429122127.GV32429@mdounin.ru>
 <F45CA052-3237-423A-A1C1-8AFF2A277763@symbi.org>
Message-ID: <20150430134902.GC32429@mdounin.ru>

Hello!

On Thu, Apr 30, 2015 at 06:06:05AM +0300, Konstantin Baryshnikov wrote:

> On Apr 29, 2015, at 3:21 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> >        location / {
> >            if ($new) {
> >                proxy_pass http://new.example.com;
> >            }
> > 
> >            fastcgi_pass old.example.com;
> >        }
> >    }
> 
> Ого, а это теперь работает?
> 
> Всегда считал это гарантированным способом отстрелить себе ногу. Что-то изменилось?

Вот конкретно приведённая конструкция - работает, и без каких-либо 
проблем.  И, собственно, всегда работала.  Но если конфиг будет 
чуть сложнее - то нога в опасности, да.  Подробнее про опасности 
расписано вот тут:

http://wiki.nginx.org/IfIsEvil

-- 
Maxim Dounin
http://nginx.org/


From mva at mva.name  Thu Apr 30 14:08:51 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 30 Apr 2015 20:08:51 +0600
Subject: (13: Permission denied)
In-Reply-To: <073261e4708c8ec7db79d18cb619622e.NginxMailingListRussian@forum.nginx.org>
References: <2270521.iSYunKQvYE@note>
 <073261e4708c8ec7db79d18cb619622e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <7704724.ur0KseDbm3@note>

В письме от Чт, 30 апреля 2015 09:33:45 пользователь sidewinder написал:
> Да. Все права проверил. Копировал тот же пользователь свои же файлы. Он был
> владельцем стараых и стал владельцем новых. Старый сайт работает, новый
> нет.
> Кроме того сделал такую штуку:
> sudo su - s www-data
1) НЕ СТОИТ делать "sudo su". Для этого есть sudo -s и sudo -i. Пользователь 
указывается ключом -u. Совмещать эти команды ? моветон.
2) что такое "s" в данном случае? Если это должно быть ключом "su", то он 
пишется слитно (и, вообще-то, задаёт shell который нужно использовать). Если 
это какая-то команда, то не ясно что она должна делать.
> lsl -l /home/user/html-bc/test.php
3) `lsl`? Опечатка?
> cat /home/user/html-bc/test.php
> доступ есть - и на чтение директории и на чтение файла.
4) Речь не только о последних "узлах" пути, но и о каждом предыдущем.
Натравите `ls -ld` на каждую директорию, участвующую в пути до файла (всё, что 
отделено слешами (`/`).
> У меня уже просто крыша едет - не могу понять в чём проблема, каких ещё
> пермишенов не хватает.
Ну и как сказали чуть выше ? вполне возможно, что если у вас включен SELinux в 
Enforcing режиме и текущие политики не разрешают веб-серверу доступ к этим 
файлам, то он, то он, собственно, не сможет его получить и это тоже может 
являться причиной. Решением будет написать политику, разрешающую доступ веб-
серверу к этой директории (проще всего будет скопировать ту политику, которая 
разрешает доступ к первой и поправить её). Либо перевести SELinux в Permissve-
режим.

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150430/3c496899/attachment.bin>

From mva at mva.name  Thu Apr 30 14:30:03 2015
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 30 Apr 2015 20:30:03 +0600
Subject: nginx-1.9.0
In-Reply-To: <16257629.AHyRbmbdmx@vbart-workstation>
References: <20150428154316.GI32429@mdounin.ru> <22718843.8ktbYSCAQW@note>
 <16257629.AHyRbmbdmx@vbart-workstation>
Message-ID: <10591011.ZNfuhKAKvO@note>

> Там из переменных только ip может быть.  Зачем все так усложнять?

Ну, например, затем, что эти модули уже есть.
К слову, кроме IP в переменных, теоретически, может ещё быть "пришёл ли 
коннект по ssl или нет", "ssl-сертификат клиента" и тому подобное :) И это 
вполне могут быть кейсы по которым может хотеться пускать или не пускать 
коннект к апстриму :)

-- 
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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150430/fa8ae04c/attachment.bin>