From igor at sysoev.ru  Sat Mar  1 15:40:37 2014
From: igor at sysoev.ru (Igor Sysoev)
Date: Sat, 1 Mar 2014 19:40:37 +0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtGG0LXRgdGB0L3QsNGPINC80L7QtNC10LvRjA==?=
In-Reply-To: <f198d500e59774a2acc9e222be41a380.NginxMailingListRussian@forum.nginx.org>
References: <530F067E.1090102@citrin.ru>
 <f198d500e59774a2acc9e222be41a380.NginxMailingListRussian@forum.nginx.org>
Message-ID: <EE330D29-EC8A-480D-8EA3-680F7FDB5571@sysoev.ru>

On Feb 27, 2014, at 22:22 , AlexyFrost wrote:

> Anton Yuzhaninov Wrote:
> -------------------------------------------------------
>> On 02/26/14 03:17, AlexyFrost wrote:
>> Мусора в том, что наследуется нет.
>> 
>> listen socket нужен.
>> других сокетов, открытых в мастере не должно быть.
>> 
>> Обработчики сигналов AFAIK переопределяются, если нужно.
> 
> Вот об этом я и говорил: с использованием fork() воркер попадает в сильную
> зависимость от того, что должно и не должно быть инициализировано в мастере,
> т.е., какие контр-действия придётся ему делать (закрытие чего то, отключение
> сигналов etc). Понятное дело, что для компилируемой программы этот аргумент
> не столь важен, но, тем не менее, для большого и сложного проекта, который
> пишет не один человек, такие сайд-эффекты вполне существенны, мне кажется. 
> 
> К тому же, если форки используются для разных типов воркеров (обработка
> соединений, какой то кеш, какие то сервисные штуки), то у них могут быть
> разные реакции на унаследованные от мастера данные - кому то надо сделать
> то, кому то это, и в случае внесения изменений в мастер (добавили новый
> сигнал?) придётся править код всех воркеров.
> 
>> То что worker-ы используют память мастера (через COW) очень даже
>> полезно - 
>> большая геобаза загруженная мастером будет использоваться всеми
>> процессами и не 
>> надо будет загружать её N раз в каждый worker отдельно.
> 
> Для подобных данных можно использовать shared memory, что так же выглядит
> логичнее, чем "копия" данных мастера, да и в случе потребностей горячей
> замены таких данных сделать это будет проще в одном месте.

Shared memory в неродственных процессах сочетании с ASRL превращается в ад.

>> В адресное пространство воркеров попадает часть кода и данных, не
>> нужных 
>> worker-ом, но ничего плохого в этом нет.
> 
> Меня, в целом, не столько беспокоят "левые" данные мастера в воркере,
> сколько потенциальные проблемы, которые они могут привнести (выше
> перечислял).

Ввиду отсутствия fork()а на Windows, nginx/Windows запускает новые процессы.
Вот там проблемы, так проблемы. Сигналы - это семечки.


-- 
Igor Sysoev
http://nginx.com

From postmaster at softsearch.ru  Sat Mar  1 17:46:01 2014
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Sat, 1 Mar 2014 21:46:01 +0400
Subject: =?UTF-8?B?UmVbMl06INCf0YDQvtGG0LXRgdGB0L3QsNGPINC80L7QtNC10LvRjA==?=
In-Reply-To: <EE330D29-EC8A-480D-8EA3-680F7FDB5571@sysoev.ru>
References: <530F067E.1090102@citrin.ru>
 <f198d500e59774a2acc9e222be41a380.NginxMailingListRussian@forum.nginx.org>
 <EE330D29-EC8A-480D-8EA3-680F7FDB5571@sysoev.ru>
Message-ID: <1678519320.20140301214601@softsearch.ru>

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

> Ввиду  отсутствия  fork()а на Windows, nginx/Windows запускает новые
> процессы. Вот там проблемы, так проблемы. Сигналы - это семечки.

А  есть  желание эти проблемы преодолевать? Т.е. есть желание покорять
венду с её вендо-админами?

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


From anatoly at sonru.com  Mon Mar  3 09:47:14 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Mon, 3 Mar 2014 09:47:14 +0000
Subject: =?UTF-8?B?UmU6INCf0YDQvtGG0LXRgdGB0L3QsNGPINC80L7QtNC10LvRjA==?=
In-Reply-To: <1678519320.20140301214601@softsearch.ru>
References: <530F067E.1090102@citrin.ru>
 <f198d500e59774a2acc9e222be41a380.NginxMailingListRussian@forum.nginx.org>
 <EE330D29-EC8A-480D-8EA3-680F7FDB5571@sysoev.ru>
 <1678519320.20140301214601@softsearch.ru>
Message-ID: <FA83CE71-AE19-43B8-8864-E9569E73FB90@sonru.com>


On 01 Mar 2014, at 17:46, Михаил Монашёв <postmaster at softsearch.ru> wrote:

> Здравствуйте, Igor.
> 
>> Ввиду  отсутствия  fork()а на Windows, nginx/Windows запускает новые
>> процессы. Вот там проблемы, так проблемы. Сигналы - это семечки.
> 
> А  есть  желание эти проблемы преодолевать? Т.е. есть желание покорять
> венду с её вендо-админами?

мне кажется, ROI достаточно низкий, да и ребята из Nginx не будут распыляться на все подряд

> 
> -- 
> С уважением,
> Михаил                          mailto:postmaster at softsearch.ru
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From igor at sysoev.ru  Mon Mar  3 12:21:07 2014
From: igor at sysoev.ru (Igor Sysoev)
Date: Mon, 3 Mar 2014 16:21:07 +0400
Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQn9GA0L7RhtC10YHRgdC90LDRjyDQvNC+0LTQtdC70Yw=?=
In-Reply-To: <1678519320.20140301214601@softsearch.ru>
References: <530F067E.1090102@citrin.ru>
 <f198d500e59774a2acc9e222be41a380.NginxMailingListRussian@forum.nginx.org>
 <EE330D29-EC8A-480D-8EA3-680F7FDB5571@sysoev.ru>
 <1678519320.20140301214601@softsearch.ru>
Message-ID: <B97B67D7-EBF0-49EB-9D54-F8CF1FDAD1E8@sysoev.ru>

On Mar 1, 2014, at 21:46 , Михаил Монашёв wrote:

> Здравствуйте, Igor.
> 
>> Ввиду  отсутствия  fork()а на Windows, nginx/Windows запускает новые
>> процессы. Вот там проблемы, так проблемы. Сигналы - это семечки.
> 
> А  есть  желание эти проблемы преодолевать? Т.е. есть желание покорять
> венду с её вендо-админами?

Конкретно эти проблемы - проблемы взаимодействия и передачи данных из
мастера в воркеры - уже преодолены. Это к вопросу о том, что проще -
делать fork() или fork()/exec() для родственных процессов.


-- 
Igor Sysoev
http://nginx.com


From nginx-forum at nginx.us  Mon Mar  3 12:23:51 2014
From: nginx-forum at nginx.us (Miklucho)
Date: Mon, 03 Mar 2014 07:23:51 -0500
Subject: =?UTF-8?B?UmU6IENyb24g0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQsNC10YIg0LfQsNC00LDQvdC4?=
 =?UTF-8?B?0LU=?=
In-Reply-To: <2046511.f0FaY0ElGg@vbart-laptop>
References: <2046511.f0FaY0ElGg@vbart-laptop>
Message-ID: <148ea64e9e05b711ae45da15067e6970.NginxMailingListRussian@forum.nginx.org>

Валентин, спасибо за подсказку. Как-то совсем забыл про wget, действительно
дело оказалось в нем.

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


From nginx-forum at nginx.us  Tue Mar  4 15:20:58 2014
From: nginx-forum at nginx.us (vromanov)
Date: Tue, 04 Mar 2014 10:20:58 -0500
Subject: =?UTF-8?B?0JDRgdC40L3RhdGA0L7QvdC90YvQuSDQvNC+0LTRg9C70Ywg0LbQtNGD0YnQuNC5?=
 =?UTF-8?B?INCy0L3QtdGI0L3RjtGOINGB0LjRgdGC0LXQvNGDIC0g0LrQsNC6INC00LU=?=
 =?UTF-8?B?0LvQsNGC0Yw=?=
Message-ID: <6f93e570b1bc2200b4aab032328c7645.NginxMailingListRussian@forum.nginx.org>

Добрый день!
Собираемся разработать следующий модуль
1) Приходит запрос. Инофрмация из запроса (куки) помещаются в очередь в SHM.
Запрос ставится на холд
2) Отдельный внеший процесс разгребает эту очередь (запрашивая внешние
системы) и помещает рузультат в базу.
3) nginx периодически просыпается и смотрит, появилась ли информация в базе.
Если появилась, то запрос проксируется на бакенд.

Аналог такого поведения есть в ngx_http_limit_req_module.c

Может етсь более правильный способ реализации?

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


From mdounin at mdounin.ru  Tue Mar  4 15:23:31 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 4 Mar 2014 19:23:31 +0400
Subject: nginx-1.5.11
Message-ID: <20140304152331.GV34696@mdounin.ru>

Изменения в nginx 1.5.11                                          04.03.2014

    *) Безопасность: при обработке специально созданного запроса модулем
       ngx_http_spdy_module на 32-битных платформах могла повреждаться
       память рабочего процесса, что потенциально могло приводить к
       выполнению произвольного кода (CVE-2014-0088); ошибка появилась в
       1.5.10.
       Спасибо Lucas Molas из Programa STIC, Fundaci?n Dr. Manuel Sadosky,
       Buenos Aires, Argentina.

    *) Добавление: переменная $ssl_session_reused.

    *) Исправление: директива client_max_body_size могла не работать при
       чтении тела запроса с использованием chunked transfer encoding;
       ошибка появилась в 1.3.9.
       Спасибо Lucas Molas.

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

    *) Исправление: в рабочем процессе мог произойти segmentation fault,
       если использовался модуль ngx_http_spdy_module на 32-битных
       платформах; ошибка появилась в 1.5.10.

    *) Исправление: значение переменной $upstream_status могло быть
       неверным, если использовались директивы proxy_cache_use_stale или
       proxy_cache_revalidate.
       Спасибо Piotr Sikora.

    *) Исправление: в рабочем процессе мог произойти segmentation fault,
       если ошибки с кодом 400 с помощью директивы error_page
       перенаправлялись в именованный location.

    *) Исправление: nginx/Windows не собирался с Visual Studio 2013.


-- 
Maxim Dounin
http://nginx.org/en/donation.html


From mdounin at mdounin.ru  Tue Mar  4 15:24:02 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 4 Mar 2014 19:24:02 +0400
Subject: nginx-1.4.6
Message-ID: <20140304152402.GZ34696@mdounin.ru>

Изменения в nginx 1.4.6                                           04.03.2014

    *) Исправление: директива client_max_body_size могла не работать при
       чтении тела запроса с использованием chunked transfer encoding;
       ошибка появилась в 1.3.9.
       Спасибо Lucas Molas.

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


-- 
Maxim Dounin
http://nginx.org/en/donation.html


From mdounin at mdounin.ru  Tue Mar  4 15:24:31 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 4 Mar 2014 19:24:31 +0400
Subject: nginx security advisory (CVE-2014-0088)
Message-ID: <20140304152431.GD34696@mdounin.ru>

Hello!

Была обнаружена ошибка в экспериментальной реализации SPDY в nginx
1.5.10, из-за которой с помощью специально созданного запроса в
некоторых случаях было возможно повредить память рабочего процесса, что
потенциально могло приводить к выполнению произвольного кода
(CVE-2014-0088).

Проблеме подвержен nginx 1.5.10 на 32-битных платформах, если он собран
с модулем ngx_http_spdy_module (по умолчанию не собирается) и в
конфигурационном файле используется параметр spdy директивы listen.

Проблема исправлена в nginx 1.5.11.

Патч, исправляющий проблему, доступен тут:

http://nginx.org/download/patch.2014.spdy.txt

Спасибо Lucas Molas из Programa STIC, Fundaci?n Dr. Manuel Sadosky,
Buenos Aires, Argentina.


-- 
Maxim Dounin
http://nginx.org/en/donation.html


From tetsio.nainn at gmail.com  Tue Mar  4 21:36:03 2014
From: tetsio.nainn at gmail.com (=?UTF-8?B?0Jwu0JAuINCc0L7RhdC90LDRh9C10LLRgdC60LjQuQ==?=)
Date: Wed, 5 Mar 2014 07:36:03 +1000
Subject: =?UTF-8?B?UmU6INCQ0YHQuNC90YXRgNC+0L3QvdGL0Lkg0LzQvtC00YPQu9GMINC20LTRg9GJ?=
 =?UTF-8?B?0LjQuSDQstC90LXRiNC90Y7RjiDRgdC40YHRgtC10LzRgyAtINC60LDQuiA=?=
 =?UTF-8?B?0LTQtdC70LDRgtGM?=
In-Reply-To: <6f93e570b1bc2200b4aab032328c7645.NginxMailingListRussian@forum.nginx.org>
References: <6f93e570b1bc2200b4aab032328c7645.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CALXqZiGa2z9qB4h1CCXFj0KiVh817dG4gTFDxihHvimHo9_akg@mail.gmail.com>

lua?


5 марта 2014 г., 1:20 пользователь vromanov <nginx-forum at nginx.us> написал:

> Добрый день!
> Собираемся разработать следующий модуль
> 1) Приходит запрос. Инофрмация из запроса (куки) помещаются в очередь в
> SHM.
> Запрос ставится на холд
> 2) Отдельный внеший процесс разгребает эту очередь (запрашивая внешние
> системы) и помещает рузультат в базу.
> 3) nginx периодически просыпается и смотрит, появилась ли информация в
> базе.
> Если появилась, то запрос проксируется на бакенд.
>
> Аналог такого поведения есть в ngx_http_limit_req_module.c
>
> Может етсь более правильный способ реализации?
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,248088,248088#msg-248088
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
С ув. М.А. Мохначевский
Отдел системного администрирования
ООО "Компания "СахаИнтернет НТ"
к.т. (4112)219711 доб. 927
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140305/be5073cc/attachment.html>

From vbart at nginx.com  Tue Mar  4 23:31:21 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 05 Mar 2014 03:31:21 +0400
Subject: =?UTF-8?B?UmU6INCQ0YHQuNC90YXRgNC+0L3QvdGL0Lkg0LzQvtC00YPQu9GMINC20LTRg9GJ?=
 =?UTF-8?B?0LjQuSDQstC90LXRiNC90Y7RjiDRgdC40YHRgtC10LzRgyAtINC60LDQuiA=?=
 =?UTF-8?B?0LTQtdC70LDRgtGM?=
In-Reply-To: <6f93e570b1bc2200b4aab032328c7645.NginxMailingListRussian@forum.nginx.org>
References: <6f93e570b1bc2200b4aab032328c7645.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2135949.MkAipynOjd@vbart-laptop>

On Tuesday 04 March 2014 10:20:58 vromanov wrote:
> Добрый день!
> Собираемся разработать следующий модуль
> 1) Приходит запрос. Инофрмация из запроса (куки) помещаются в очередь в SHM.
> Запрос ставится на холд
> 2) Отдельный внеший процесс разгребает эту очередь (запрашивая внешние
> системы) и помещает рузультат в базу.
> 3) nginx периодически просыпается и смотрит, появилась ли информация в базе.
> Если появилась, то запрос проксируется на бакенд.
> 
> Аналог такого поведения есть в ngx_http_limit_req_module.c
> 
> Может етсь более правильный способ реализации?
> 

http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html
и никаких самописных модулей к nginx.

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

From nginx-forum at nginx.us  Wed Mar  5 05:56:12 2014
From: nginx-forum at nginx.us (vromanov)
Date: Wed, 05 Mar 2014 00:56:12 -0500
Subject: =?UTF-8?B?UmU6INCQ0YHQuNC90YXRgNC+0L3QvdGL0Lkg0LzQvtC00YPQu9GMINC20LTRg9GJ?=
 =?UTF-8?B?0LjQuSDQstC90LXRiNC90Y7RjiDRgdC40YHRgtC10LzRgyAtINC60LDQuiA=?=
 =?UTF-8?B?0LTQtdC70LDRgtGM?=
In-Reply-To: <2135949.MkAipynOjd@vbart-laptop>
References: <2135949.MkAipynOjd@vbart-laptop>
Message-ID: <ac95ca0c5caa88ddea20c388bff5676c.NginxMailingListRussian@forum.nginx.org>

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

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


From nginx-forum at nginx.us  Wed Mar  5 12:44:11 2014
From: nginx-forum at nginx.us (ddr400)
Date: Wed, 05 Mar 2014 07:44:11 -0500
Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSBjdXJsLCBwcm94eSBjYWNoZSDQuCBDb250ZW50?=
 =?UTF-8?B?LUxlbmdodA==?=
Message-ID: <548dcd88c5ab6799a1a0b2272b53d838.NginxMailingListRussian@forum.nginx.org>

Всем привет!

Столкнулся с неожиданной проблемой. Если включен proxy_cache и используется
ssi, curl часто выдает ошибку

* Received problem 3 in the chunky parser
* Closing connection #0
curl: (56) Received problem 3 in the chunky parser

и в error.log:

2014/03/05 16:33:55 [info] 31373#0: *525 client prematurely closed
connection while sending to client, client: 1.1.1.1, server: host.ru,
request: "GET / HTTP/1.1", subrequest: "/includes/lists/tabloid", upstream:
"http://127.0.0.1:9030/includes/lists/tabloid", host: "host.ru"

Все начинает правильно работать, при следующих условиях:

1. ssi off и тогда nginx начинает передавать curl заголовок Content-Lenght
2. proxy_cache не используется и ssi on

Конфиг:

        ssi on;

        gzip_static on;

        keepalive_requests 20;
        location ~ ^/includes {

                include /etc/nginx/conf/access.conf;

                proxy_cache some-cache;
                proxy_cache_valid 200 302 301 304 10s;
                proxy_cache_key "$request_method|$host|$uri";
                proxy_hide_header "Set-Cookie";
                proxy_ignore_headers "Cache-Control" "Expires";
                proxy_cache_use_stale error timeout invalid_header updating
http_500 http_502 http_503;
                proxy_cache_lock on;

                proxy_http_version 1.1;

                proxy_set_header        X-Real-IP       $remote_addr;
                proxy_set_header        X-Forwarded-For
$proxy_add_x_forwarded_for;

                proxy_set_header        Accept          text/html;
                proxy_set_header        Host            host.ru;

                proxy_pass      http://localhost:9030;


        }

        location / {

                proxy_cache some-cache;
                proxy_cache_valid 200 302 301 304 30s;
                proxy_cache_key "$request_method|$host|$uri";
                proxy_hide_header "Set-Cookie";
                proxy_ignore_headers "Cache-Control" "Expires";
                proxy_cache_use_stale error timeout invalid_header updating
http_500 http_502 http_503;
                proxy_cache_lock on;

                proxy_http_version 1.1;

                proxy_set_header        X-Real-IP       $remote_addr;
                proxy_set_header        X-Forwarded-For
$proxy_add_x_forwarded_for;

                proxy_set_header        Accept          text/html;
                proxy_set_header        Host            host.ru;

                proxy_pass      http://localhost:9030;
        }

Заголовки приложения:

< HTTP/1.1 200 OK
< Date: Wed, 05 Mar 2014 12:38:37 GMT
< Status: 200 OK
< Connection: close
< Content-Type: text/html; charset=utf-8
< Content-Length: 20041
< X-UA-Compatible: IE=Edge,chrome=1
< ETag: "8bdee631c5839fef72100f192025570b"
< Cache-Control: max-age=0, private, must-revalidate
< X-Request-Id: bd50bffa8386d8c870448d47f2f00941
< X-Runtime: 0.116565

Заголовки которые отдает nginx:

< HTTP/1.1 200 OK
< Server: nginx
< Date: Wed, 05 Mar 2014 12:38:11 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< Status: 200 OK
< X-UA-Compatible: IE=Edge,chrome=1
< Cache-Control: max-age=0, private, must-revalidate
< X-Request-Id: 5238e092ddcf2a4b83e527fda2892145
< X-Runtime: 0.098263

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


From mdounin at mdounin.ru  Wed Mar  5 13:54:10 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 5 Mar 2014 17:54:10 +0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgY3VybCwgcHJveHkgY2FjaGUg0LggQ29u?=
 =?UTF-8?B?dGVudC1MZW5naHQ=?=
In-Reply-To: <548dcd88c5ab6799a1a0b2272b53d838.NginxMailingListRussian@forum.nginx.org>
References: <548dcd88c5ab6799a1a0b2272b53d838.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140305135410.GS34696@mdounin.ru>

Hello!

On Wed, Mar 05, 2014 at 07:44:11AM -0500, ddr400 wrote:

> Всем привет!
> 
> Столкнулся с неожиданной проблемой. Если включен proxy_cache и используется
> ssi, curl часто выдает ошибку
> 
> * Received problem 3 in the chunky parser
> * Closing connection #0
> curl: (56) Received problem 3 in the chunky parser
> 
> и в error.log:
> 
> 2014/03/05 16:33:55 [info] 31373#0: *525 client prematurely closed
> connection while sending to client, client: 1.1.1.1, server: host.ru,
> request: "GET / HTTP/1.1", subrequest: "/includes/lists/tabloid", upstream:
> "http://127.0.0.1:9030/includes/lists/tabloid", host: "host.ru"
> 
> Все начинает правильно работать, при следующих условиях:
> 
> 1. ssi off и тогда nginx начинает передавать curl заголовок Content-Lenght
> 2. proxy_cache не используется и ssi on
> 
> Конфиг:
> 
>         ssi on;
> 
>         gzip_static on;
> 
>         keepalive_requests 20;
>         location ~ ^/includes {
> 
>                 include /etc/nginx/conf/access.conf;
> 
>                 proxy_cache some-cache;
>                 proxy_cache_valid 200 302 301 304 10s;
>                 proxy_cache_key "$request_method|$host|$uri";
>                 proxy_hide_header "Set-Cookie";
>                 proxy_ignore_headers "Cache-Control" "Expires";
>                 proxy_cache_use_stale error timeout invalid_header updating
> http_500 http_502 http_503;
>                 proxy_cache_lock on;

Возможно, речь идёт о проблеме proxy_cache_lock в подзапросах 
(i.e., ssi include'ах).  Попробуйте выключить proxy_cache_lock.

Ну и да, было бы неплохо увидеть debug log и собственно ответ, 
который возвращает nginx (не только заголовки).

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


From nginx-forum at nginx.us  Wed Mar  5 15:37:29 2014
From: nginx-forum at nginx.us (den68)
Date: Wed, 05 Mar 2014 10:37:29 -0500
Subject: =?UTF-8?B?0KHRg9CxINC00L7QvNC10L3RiyDQvdCwINGA0LDQt9C90YvRhSBzZXJ2ZXIuLg==?=
Message-ID: <12f8b5462195ef76fec0a6aa44e9cad1.NginxMailingListRussian@forum.nginx.org>

Помогите с решением казалось-бы тривиальной задачи.
Требуется чтоб домены типа *.abc.ru уходили на первый сервер, а домены
home.*.abc.ru на второй, причем на втором должен быть proxy_pass, то есть
редирект если я правильно понимаю не очень подходит, туда данные GET'ом
передаются..

1.
server {
        server_name
            abc.ru
            *.abc.ru;
....

2.
server {
        server_name
            home.*.abc.ru; /знаю, так писать в реалии нельзя.. для
наглядности../
            proxy_pass http://127.0.0.1:998877/;

Пробовал различные варианты с PCRE - результатом не увенчалось:

#~^home.*\.abc\.ru$;
#server_name "^~home\.(?<domain>.+)$";
#server_name "~^(home\.)?(?<domain>.+)$";
#server_name "~^(home\.)?(.+)$";
#server_name "~^home\.(?P<domain>.*)$";

..
ка правильно-то ?

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


From onokonem at gmail.com  Wed Mar  5 15:49:48 2014
From: onokonem at gmail.com (Daniel Podolsky)
Date: Wed, 5 Mar 2014 19:49:48 +0400
Subject: =?UTF-8?B?UmU6INCh0YPQsSDQtNC+0LzQtdC90Ysg0L3QsCDRgNCw0LfQvdGL0YUgc2VydmVy?=
 =?UTF-8?B?Li4=?=
In-Reply-To: <12f8b5462195ef76fec0a6aa44e9cad1.NginxMailingListRussian@forum.nginx.org>
References: <12f8b5462195ef76fec0a6aa44e9cad1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKaHDOH2k4+A5OONwT032QicNVyAC+SAhVQ6oAKQLszLTvo_=w@mail.gmail.com>

> ка правильно-то ?
правильно - вынести тильду из кавычек, и окружить пробелами

From mdounin at mdounin.ru  Wed Mar  5 16:18:38 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 5 Mar 2014 20:18:38 +0400
Subject: =?UTF-8?B?UmU6INCh0YPQsSDQtNC+0LzQtdC90Ysg0L3QsCDRgNCw0LfQvdGL0YUgc2VydmVy?=
 =?UTF-8?B?Li4=?=
In-Reply-To: <12f8b5462195ef76fec0a6aa44e9cad1.NginxMailingListRussian@forum.nginx.org>
References: <12f8b5462195ef76fec0a6aa44e9cad1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140305161838.GU34696@mdounin.ru>

Hello!

On Wed, Mar 05, 2014 at 10:37:29AM -0500, den68 wrote:

> Помогите с решением казалось-бы тривиальной задачи.
> Требуется чтоб домены типа *.abc.ru уходили на первый сервер, а домены
> home.*.abc.ru на второй, причем на втором должен быть proxy_pass, то есть
> редирект если я правильно понимаю не очень подходит, туда данные GET'ом
> передаются..
> 
> 1.
> server {
>         server_name
>             abc.ru
>             *.abc.ru;
> ....
> 
> 2.
> server {
>         server_name
>             home.*.abc.ru; /знаю, так писать в реалии нельзя.. для
> наглядности../
>             proxy_pass http://127.0.0.1:998877/;
> 
> Пробовал различные варианты с PCRE - результатом не увенчалось:
> 
> #~^home.*\.abc\.ru$;
> #server_name "^~home\.(?<domain>.+)$";
> #server_name "~^(home\.)?(?<domain>.+)$";
> #server_name "~^(home\.)?(.+)$";
> #server_name "~^home\.(?P<domain>.*)$";
> 
> ..
> ка правильно-то ?

Если в конфиге есть server_name *.abc.ru, то регулярные выражения 
к соответствующим именам применяться не будут, см. документацию:

http://nginx.org/r/server_name/ru

Если нужно, чтобы home.*.abc.ru и *.abc.ru обрабатывались в разных 
блоках server{}, то надо переписать конфиг как-то так:

    server {
        server_name ~^home\..+\.abc\.ru$;
        ...
    }
    server {
        server_name ~.+\.abc\.ru$;
        ...
    }

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

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


From nginx-forum at nginx.us  Wed Mar  5 16:48:43 2014
From: nginx-forum at nginx.us (den68)
Date: Wed, 05 Mar 2014 11:48:43 -0500
Subject: =?UTF-8?B?UmU6INCh0YPQsSDQtNC+0LzQtdC90Ysg0L3QsCDRgNCw0LfQvdGL0YUgc2VydmVy?=
 =?UTF-8?B?Li4=?=
In-Reply-To: <20140305161838.GU34696@mdounin.ru>
References: <20140305161838.GU34696@mdounin.ru>
Message-ID: <7ac54f9e3b335033547f484cda3c81f2.NginxMailingListRussian@forum.nginx.org>

Оо! спасибо большое, все получилось!

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


From nginx-forum at nginx.us  Thu Mar  6 06:42:36 2014
From: nginx-forum at nginx.us (ddr400)
Date: Thu, 06 Mar 2014 01:42:36 -0500
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgY3VybCwgcHJveHkgY2FjaGUg0LggQ29u?=
 =?UTF-8?B?dGVudC1MZW5naHQ=?=
In-Reply-To: <20140305135410.GS34696@mdounin.ru>
References: <20140305135410.GS34696@mdounin.ru>
Message-ID: <73cf4ae9e5007863047aee8e9bba3bd1.NginxMailingListRussian@forum.nginx.org>

Ответ, вы имеете в виду html который возвращает nginx?

Вот debug log - http://pastebin.com/gu9a9kns

Отключение proxy_cache_lock не помогло.

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


From mdounin at mdounin.ru  Thu Mar  6 10:07:14 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 6 Mar 2014 14:07:14 +0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgY3VybCwgcHJveHkgY2FjaGUg0LggQ29u?=
 =?UTF-8?B?dGVudC1MZW5naHQ=?=
In-Reply-To: <73cf4ae9e5007863047aee8e9bba3bd1.NginxMailingListRussian@forum.nginx.org>
References: <20140305135410.GS34696@mdounin.ru>
 <73cf4ae9e5007863047aee8e9bba3bd1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140306100714.GC34696@mdounin.ru>

Hello!

On Thu, Mar 06, 2014 at 01:42:36AM -0500, ddr400 wrote:

> Ответ, вы имеете в виду html который возвращает nginx?

Я имею в виду собственно http-ответ.  В первую очередь - интересует 
корректность chunked-разметки, раз curl на неё почему-то ругается.  
Проще всего просто записать всё, что передаётся в соответствующем 
соединении по сети с помощью tcpdump'а.

> Вот debug log - http://pastebin.com/gu9a9kns

В debug log'е ничего подозрительного, в том числе сообщений 
"client prematurely closed connection", не отмечено.

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


From nginx-forum at nginx.us  Thu Mar  6 10:39:16 2014
From: nginx-forum at nginx.us (ddr400)
Date: Thu, 06 Mar 2014 05:39:16 -0500
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgY3VybCwgcHJveHkgY2FjaGUg0LggQ29u?=
 =?UTF-8?B?dGVudC1MZW5naHQ=?=
In-Reply-To: <20140306100714.GC34696@mdounin.ru>
References: <20140306100714.GC34696@mdounin.ru>
Message-ID: <9bd2558adde0fa136e5c3882970c8848.NginxMailingListRussian@forum.nginx.org>

Судя по tcpdump страница отдается полностью http://pastebin.com/ZDkWPtdv

а в терминале curl останавливается на таком

</div>
<div class="span4">

71b
<section class="b-yellow-box">
* Received problem 3 in the chunky parser
* Closing connection #0
curl: (56) Received problem 3 in the chunky parser
<div class="b-yellow-box

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


From nginx-forum at nginx.us  Thu Mar  6 12:57:57 2014
From: nginx-forum at nginx.us (vaal)
Date: Thu, 06 Mar 2014 07:57:57 -0500
Subject: =?UTF-8?B?0L7QtNC40L0g0YHQtdGA0LLQtdGAINGBINC90LXRgdC60L7Qu9GM0LrQuNC80Lgg?=
 =?UTF-8?B?0YHQsNC50YLQsNC80Lgg0YEv0LHQtdC3IHNzbA==?=
Message-ID: <5ebcd769736d49e5903b6e222b9bbc7d.NginxMailingListRussian@forum.nginx.org>

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

Ситуация.
Один сервер (с одним ip), на котором работает несколько сайтов и только пара
из них имеет и использует SSL сертификаты.
В тоже время к другим сайтам (без ssl) можно обратить по протоколу https -
что приводит к сообщениям/предупреждения в браузере и т.п..

Какие есть способы решения этой проблемы?

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


From mdounin at mdounin.ru  Thu Mar  6 14:04:06 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 6 Mar 2014 18:04:06 +0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgY3VybCwgcHJveHkgY2FjaGUg0LggQ29u?=
 =?UTF-8?B?dGVudC1MZW5naHQ=?=
In-Reply-To: <9bd2558adde0fa136e5c3882970c8848.NginxMailingListRussian@forum.nginx.org>
References: <20140306100714.GC34696@mdounin.ru>
 <9bd2558adde0fa136e5c3882970c8848.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140306140405.GF34696@mdounin.ru>

Hello!

On Thu, Mar 06, 2014 at 05:39:16AM -0500, ddr400 wrote:

> Судя по tcpdump страница отдается полностью http://pastebin.com/ZDkWPtdv
> 
> а в терминале curl останавливается на таком
> 
> </div>
> <div class="span4">
> 
> 71b
> <section class="b-yellow-box">
> * Received problem 3 in the chunky parser
> * Closing connection #0
> curl: (56) Received problem 3 in the chunky parser
> <div class="b-yellow-box

Взгляд глазами позволяет предположить, что ответ, возможно, 
повреждён где-то тут (начала chunk'а, ближе к концу которого curl 
ругается):

<section class="b-layout b-layout_main">
<div class="g-layout">

3e
<!-- ............ ...... .................. .............. -->
3e
<!-- ............ ...... .................. .............. -->
3057
op7-for-main">
<div class="span4">
<div class="first-item">
<a href="/news/2014/03/06/crimea/" class="js-dh"><img alt="............ .................. ...................." class="g-

Говорить о чём либо однозначно - сложно, т.к. и вывод 
tcpdump'а, и debug log явно обрабатывались руками, и строки там 
как минимум местами двояться, не говоря уже про наивные попытки 
замены доменов.  Но судя по всему этому соответствует вот этот 
кусок debug log'а:

2014/03/06 09:56:08 [debug] 2251#0: *20 http chunk: 12586
2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 000000000158B970, pos 000000000158B970, size: 4 file: 0, size: 0
2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 000000000155BF60, pos 000000000155D42E, size: 66 file: 418, size: 30734
2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:0 f:0 000000000158BA78, pos 00000000004920FD, size: 2 file: 0, size: 0
2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 000000000158BAB0, pos 000000000158BAB0, size: 4 file: 0, size: 0
2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:0 f:0 0000000000000000, pos 0000000000000000, size: 0 file: 0, size: 0
2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 0000000001522CA8, pos 0000000001522CA8, size: 62 file: 0, size: 0
2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:0 f:0 00000000013C3F90, pos 00000000004920FD, size: 2 file: 0, size: 0
2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 00000000013C3E58, pos 00000000013C3E58, size: 4 file: 0, size: 0
2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 0000000001522CA8, pos 0000000001522CA8, size: 62 file: 0, size: 0
2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:0 f:0 0000000001522E48, pos 00000000004920FD, size: 2 file: 0, size: 0
2014/03/06 09:56:08 [debug] 2251#0: *20 write new buf t:1 f:0 000000000158BB68, pos 000000000158BB68, size: 6 file: 0, size: 0
2014/03/06 09:56:08 [debug] 2251#0: *20 write new buf t:1 f:1 000000000155BF60, pos 000000000155D4AB, size: 12586 file: 5869, size: 12586
2014/03/06 09:56:08 [debug] 2251#0: *20 write new buf t:0 f:0 0000000000000000, pos 00000000004920FD, size: 2 file: 0, size: 0
2014/03/06 09:56:08 [debug] 2251#0: *20 http write filter: l:0 f:0 s:12802
2014/03/06 09:56:08 [debug] 2251#0: *20 http write filter limit 0
2014/03/06 09:56:08 [debug] 2251#0: *20 writev: 214
2014/03/06 09:56:08 [debug] 2251#0: *20 sendfile: @5931 12524
2014/03/06 09:56:08 [debug] 2251#0: *20 sendfile: 12524, @5931 12524:12524
2014/03/06 09:56:08 [debug] 2251#0: *20 writev: 2
2014/03/06 09:56:08 [debug] 2251#0: *20 http write filter 0000000000000000
2014/03/06 09:56:08 [debug] 2251#0: *20 http postpone filter wake "/includes/lists/last24?"

По каким-то непонятным причинам sendfile'у предлагается послать 
12524 вместо обозначенных в буфере 12586.  Разница в 62 байта 
подозрительно похожа на размеры некоторых предыдущих буферов, и 
как бы намекает на ошибку в работе с sendfile'ом на linux'е в случаях, 
когда работа с файлами сильно перемешенана с буферами в памяти.

Попробуйте выключить sendfile, должно помочь.

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


From andrey at kopeyko.ru  Thu Mar  6 14:15:16 2014
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Thu, 06 Mar 2014 18:15:16 +0400
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <5ebcd769736d49e5903b6e222b9bbc7d.NginxMailingListRussian@forum.nginx.org>
References: <5ebcd769736d49e5903b6e222b9bbc7d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <531882F4.1090201@kopeyko.ru>

06.03.2014 16:57, vaal пишет:
> Приветствую!
>
> Ситуация.
> Один сервер (с одним ip), на котором работает несколько сайтов и только пара
> из них имеет и использует SSL сертификаты.
> В тоже время к другим сайтам (без ssl) можно обратить по протоколу https -
> что приводит к сообщениям/предупреждения в браузере и т.п..
>
> Какие есть способы решения этой проблемы?

Да, конечно : Вам надо получить второй IP-адрес и перенести на него все 
ваши сайты, которым SSL не требуется.

>


-- 
Best regards,
Andrey Kopeyko <andrey at kopeyko.ru>


From slava.kokorin at gmail.com  Thu Mar  6 14:27:00 2014
From: slava.kokorin at gmail.com (Slava Kokorin)
Date: Thu, 6 Mar 2014 18:27:00 +0400
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <5ebcd769736d49e5903b6e222b9bbc7d.NginxMailingListRussian@forum.nginx.org>
References: <5ebcd769736d49e5903b6e222b9bbc7d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAEwm3CE++mN_bE7Dq_5EXJRnaBauwbsNLUJY1JSZ3LwqQSv-=A@mail.gmail.com>

Вы описали ситуацию.
Но не описали проблему.
Что хочется видеть в итоге? В чём проблема состоит?


6 марта 2014 г., 16:57 пользователь vaal <nginx-forum at nginx.us> написал:

> Приветствую!
>
> Ситуация.
> Один сервер (с одним ip), на котором работает несколько сайтов и только
> пара
> из них имеет и использует SSL сертификаты.
> В тоже время к другим сайтам (без ssl) можно обратить по протоколу https -
> что приводит к сообщениям/предупреждения в браузере и т.п..
>
> Какие есть способы решения этой проблемы?
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,248179,248179#msg-248179
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Regards,
Slava
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140306/0d0d82ab/attachment.html>

From mdounin at mdounin.ru  Thu Mar  6 14:36:50 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 6 Mar 2014 18:36:50 +0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgY3VybCwgcHJveHkgY2FjaGUg0LggQ29u?=
 =?UTF-8?B?dGVudC1MZW5naHQ=?=
In-Reply-To: <20140306140405.GF34696@mdounin.ru>
References: <20140306100714.GC34696@mdounin.ru>
 <9bd2558adde0fa136e5c3882970c8848.NginxMailingListRussian@forum.nginx.org>
 <20140306140405.GF34696@mdounin.ru>
Message-ID: <20140306143649.GH34696@mdounin.ru>

Hello!

On Thu, Mar 06, 2014 at 06:04:06PM +0400, Maxim Dounin wrote:

> Hello!
> 
> On Thu, Mar 06, 2014 at 05:39:16AM -0500, ddr400 wrote:
> 
> > Судя по tcpdump страница отдается полностью http://pastebin.com/ZDkWPtdv
> > 
> > а в терминале curl останавливается на таком
> > 
> > </div>
> > <div class="span4">
> > 
> > 71b
> > <section class="b-yellow-box">
> > * Received problem 3 in the chunky parser
> > * Closing connection #0
> > curl: (56) Received problem 3 in the chunky parser
> > <div class="b-yellow-box
> 
> Взгляд глазами позволяет предположить, что ответ, возможно, 
> повреждён где-то тут (начала chunk'а, ближе к концу которого curl 
> ругается):
> 
> <section class="b-layout b-layout_main">
> <div class="g-layout">
> 
> 3e
> <!-- ............ ...... .................. .............. -->
> 3e
> <!-- ............ ...... .................. .............. -->
> 3057
> op7-for-main">
> <div class="span4">
> <div class="first-item">
> <a href="/news/2014/03/06/crimea/" class="js-dh"><img alt="............ .................. ...................." class="g-
> 
> Говорить о чём либо однозначно - сложно, т.к. и вывод 
> tcpdump'а, и debug log явно обрабатывались руками, и строки там 
> как минимум местами двояться, не говоря уже про наивные попытки 
> замены доменов.  Но судя по всему этому соответствует вот этот 
> кусок debug log'а:
> 
> 2014/03/06 09:56:08 [debug] 2251#0: *20 http chunk: 12586
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 000000000158B970, pos 000000000158B970, size: 4 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 000000000155BF60, pos 000000000155D42E, size: 66 file: 418, size: 30734
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:0 f:0 000000000158BA78, pos 00000000004920FD, size: 2 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 000000000158BAB0, pos 000000000158BAB0, size: 4 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:0 f:0 0000000000000000, pos 0000000000000000, size: 0 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 0000000001522CA8, pos 0000000001522CA8, size: 62 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:0 f:0 00000000013C3F90, pos 00000000004920FD, size: 2 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 00000000013C3E58, pos 00000000013C3E58, size: 4 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:1 f:0 0000000001522CA8, pos 0000000001522CA8, size: 62 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write old buf t:0 f:0 0000000001522E48, pos 00000000004920FD, size: 2 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write new buf t:1 f:0 000000000158BB68, pos 000000000158BB68, size: 6 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write new buf t:1 f:1 000000000155BF60, pos 000000000155D4AB, size: 12586 file: 5869, size: 12586
> 2014/03/06 09:56:08 [debug] 2251#0: *20 write new buf t:0 f:0 0000000000000000, pos 00000000004920FD, size: 2 file: 0, size: 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 http write filter: l:0 f:0 s:12802
> 2014/03/06 09:56:08 [debug] 2251#0: *20 http write filter limit 0
> 2014/03/06 09:56:08 [debug] 2251#0: *20 writev: 214
> 2014/03/06 09:56:08 [debug] 2251#0: *20 sendfile: @5931 12524
> 2014/03/06 09:56:08 [debug] 2251#0: *20 sendfile: 12524, @5931 12524:12524
> 2014/03/06 09:56:08 [debug] 2251#0: *20 writev: 2
> 2014/03/06 09:56:08 [debug] 2251#0: *20 http write filter 0000000000000000
> 2014/03/06 09:56:08 [debug] 2251#0: *20 http postpone filter wake "/includes/lists/last24?"
> 
> По каким-то непонятным причинам sendfile'у предлагается послать 
> 12524 вместо обозначенных в буфере 12586.  Разница в 62 байта 
> подозрительно похожа на размеры некоторых предыдущих буферов, и 
> как бы намекает на ошибку в работе с sendfile'ом на linux'е в случаях, 
> когда работа с файлами сильно перемешенана с буферами в памяти.
> 
> Попробуйте выключить sendfile, должно помочь.

Впрочем нет, более подробное изучение вопроса позволяет 
предположить, что всё-таки проблема где-то раньше, т.к. offset 
посылаемых данных также сдвигается.

Такое ощущение, что по каким-то причинам в цепочке буферов для 
вывода обоих блоков ssi stub использован один и тот же буфер. 

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

Что говорит nginx -V, нет ли каких-либо локальных изменений в коде?

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


From nginx-forum at nginx.us  Thu Mar  6 16:44:51 2014
From: nginx-forum at nginx.us (ddr400)
Date: Thu, 06 Mar 2014 11:44:51 -0500
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgY3VybCwgcHJveHkgY2FjaGUg0LggQ29u?=
 =?UTF-8?B?dGVudC1MZW5naHQ=?=
In-Reply-To: <20140306143649.GH34696@mdounin.ru>
References: <20140306143649.GH34696@mdounin.ru>
Message-ID: <53b43ff71a2c2257a82e8b1062356755.NginxMailingListRussian@forum.nginx.org>

Отключение sendfile, кстати, помогло, но почему-то начал менятся response
time с 2-4мс иногда до 600мс. Такое ощущение что ошибка изменилась на
задержку.

В код никаких изменений не вносилось... По логам только прошелся replace'ом,
заменив ip и хосты, поскольку в паблике.

nginx version: nginx/1.4.2
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx/ --sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid
--lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=lenta --group=www
--with-http_ssl_module --with-http_realip_module --with-http_addition_module
--with-http_sub_module --with-http_dav_module --with-http_flv_module
--with-http_mp4_module --with-http_gzip_static_module
--with-http_random_index_module --with-http_secure_link_module
--with-http_stub_status_module --with-http_geoip_module --with-file-aio
--with-debug --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
-mtune=generic'

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


From mdounin at mdounin.ru  Thu Mar  6 17:06:22 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 6 Mar 2014 21:06:22 +0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgY3VybCwgcHJveHkgY2FjaGUg0LggQ29u?=
 =?UTF-8?B?dGVudC1MZW5naHQ=?=
In-Reply-To: <53b43ff71a2c2257a82e8b1062356755.NginxMailingListRussian@forum.nginx.org>
References: <20140306143649.GH34696@mdounin.ru>
 <53b43ff71a2c2257a82e8b1062356755.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140306170622.GP34696@mdounin.ru>

Hello!

On Thu, Mar 06, 2014 at 11:44:51AM -0500, ddr400 wrote:

> Отключение sendfile, кстати, помогло, но почему-то начал менятся response
> time с 2-4мс иногда до 600мс. Такое ощущение что ошибка изменилась на
> задержку.

Отключение sendfile могло помочь по другим причинам - ответ теперь 
отправляется за один раз с помощью writev(), и за счёт этого 
дублирующиеся буфера не сказываются.  Проблема вылезет опять, 
если, например, клиент будет медленный, и в буфер сокета за один 
раз всё не поместится.

> В код никаких изменений не вносилось... По логам только прошелся replace'ом,
> заменив ip и хосты, поскольку в паблике.

Проблема с "прошёлся replace'ом" состоит в том, что при 
сколько-нибудь неаккуратном обращении едут размеры, а они тут 
важны.

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

(Ну или http://nginx.com/, там есть непубличные способы получения 
поддержки.)

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


From nolux2 at gmail.com  Thu Mar  6 17:59:25 2014
From: nolux2 at gmail.com (=?KOI8-R?B?88XSx8XKIO3JyMHKzM/X?=)
Date: Thu, 6 Mar 2014 21:59:25 +0400
Subject: =?UTF-8?B?0JLQvtC/0YDQvtGBINC/0YDQviDRgdC+0LLQvNC10YHRgtC40LzQvtGB0YLRjCBO?=
 =?UTF-8?B?Z2lueCDRgSDQtNC+0LzQtdC90LDQvNC4IC5pMnA=?=
Message-ID: <CAKYgWWtgvfirRr7tTnHsBW-q7yLtViPtn5wC_0GKjDUFLS01zQ@mail.gmail.com>

Имею проблемы при работе с доменом в зоне i2p: в переменной Nginx $host
содержится только название домена, без зоны.

Я думаю что это ещё не все проблемы, связанные с обработкой доменов данной
зоны: ссылки на сайте все такие же пустые, без зоны (и соответственно
подключённые к странице скрипты и css файлы не грузятся).
Как исправить ситуацию?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140306/98826195/attachment.html>

From mva at mva.name  Fri Mar  7 04:11:54 2014
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Fri, 07 Mar 2014 11:11:54 +0700
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9GA0L4g0YHQvtCy0LzQtdGB0YLQuNC80L7RgdGC?=
 =?UTF-8?B?0YwgTmdpbngg0YEg0LTQvtC80LXQvdCw0LzQuCAuaTJw?=
In-Reply-To: <CAKYgWWtgvfirRr7tTnHsBW-q7yLtViPtn5wC_0GKjDUFLS01zQ@mail.gmail.com>
References: <CAKYgWWtgvfirRr7tTnHsBW-q7yLtViPtn5wC_0GKjDUFLS01zQ@mail.gmail.com>
Message-ID: <7497681.zc18iFJedK@note>

На сколько я могу знать, NginX сам по себе (без сторонних модулей и с 
выключенным SSI (не SSL, если что)) вообще никак не притрагивается к html-коду 
(а соответственно ссылкам) ни отдаваемых статических фалов, ни того, что 
проксирует.
Переменная $host, на сколько мне известно, тоже формируется из 
соответствующего заголовка, передаваемого клиетом (в отличие от server_name).


В письме от Чт, 6 марта 2014 21:59:25 пользователь Сергей Михайлов написал:
> Имею проблемы при работе с доменом в зоне i2p: в переменной Nginx $host
> содержится только название домена, без зоны.
> 
> Я думаю что это ещё не все проблемы, связанные с обработкой доменов данной
> зоны: ссылки на сайте все такие же пустые, без зоны (и соответственно
> подключённые к странице скрипты и css файлы не грузятся).
> Как исправить ситуацию?

-- 
Best regsrds,
mva
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140307/094874e6/attachment.bin>

From semenukha at gmail.com  Fri Mar  7 04:46:42 2014
From: semenukha at gmail.com (Styopa Semenukha)
Date: Thu, 06 Mar 2014 23:46:42 -0500
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9GA0L4g0YHQvtCy0LzQtdGB0YLQuNC80L7RgdGC?=
 =?UTF-8?B?0YwgTmdpbngg0YEg0LTQvtC80LXQvdCw0LzQuCAuaTJw?=
In-Reply-To: <7497681.zc18iFJedK@note>
References: <CAKYgWWtgvfirRr7tTnHsBW-q7yLtViPtn5wC_0GKjDUFLS01zQ@mail.gmail.com>
 <7497681.zc18iFJedK@note>
Message-ID: <126747605.7ssBhkKx3p@hydra>

https://geti2p.net/en/docs/naming
Я спеки не читал, но предположу, что, раз i2p ? псевдозона, то браузер её отбрасывает и оставляет только Base64 строку.
Суффикс i2p, видимо, нужен только для резолвера, чтобы не путать с обычным интернетом.
Скорее всего, и в Торе так же.

On Friday, March 07, 2014 11:11:54 AM Vadim A. Misbakh-Soloviov wrote:
> На сколько я могу знать, NginX сам по себе (без сторонних модулей и с 
> выключенным SSI (не SSL, если что)) вообще никак не притрагивается к html-коду 
> (а соответственно ссылкам) ни отдаваемых статических фалов, ни того, что 
> проксирует.
> Переменная $host, на сколько мне известно, тоже формируется из 
> соответствующего заголовка, передаваемого клиетом (в отличие от server_name).
> 
> 
> В письме от Чт, 6 марта 2014 21:59:25 пользователь Сергей Михайлов написал:
> > Имею проблемы при работе с доменом в зоне i2p: в переменной Nginx $host
> > содержится только название домена, без зоны.
> > 
> > Я думаю что это ещё не все проблемы, связанные с обработкой доменов данной
> > зоны: ссылки на сайте все такие же пустые, без зоны (и соответственно
> > подключённые к странице скрипты и css файлы не грузятся).
> > Как исправить ситуацию?
> 
> 
-- 
Sincerely yours,
Styopa Semenukha.

From nginx-forum at nginx.us  Fri Mar  7 08:27:28 2014
From: nginx-forum at nginx.us (vaal)
Date: Fri, 07 Mar 2014 03:27:28 -0500
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <531882F4.1090201@kopeyko.ru>
References: <531882F4.1090201@kopeyko.ru>
Message-ID: <2b64ba7a8fdcf73c2ccdcce4e692d674.NginxMailingListRussian@forum.nginx.org>

Спасибо!

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


From nginx-forum at nginx.us  Fri Mar  7 08:31:35 2014
From: nginx-forum at nginx.us (vaal)
Date: Fri, 07 Mar 2014 03:31:35 -0500
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <CAEwm3CE++mN_bE7Dq_5EXJRnaBauwbsNLUJY1JSZ3LwqQSv-=A@mail.gmail.com>
References: <CAEwm3CE++mN_bE7Dq_5EXJRnaBauwbsNLUJY1JSZ3LwqQSv-=A@mail.gmail.com>
Message-ID: <d8261204d764a6238077c98c113dc162.NginxMailingListRussian@forum.nginx.org>

Проблема в том что пользователи могут заходить по https на сайты для которых
не установлены ssl. При этом они будут получать в браузере сообщения про
проблему с ssl и т.п.., которые могут их "напугать".

В итоге хотелось бы чтобы на сайты без ssl нельзя попытаться было войти по
https. Выше мне уже ответили что нужен второй ip.

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


From uncleandyv at gmail.com  Fri Mar  7 08:56:35 2014
From: uncleandyv at gmail.com (Andrey Velikoredchanin)
Date: Fri, 7 Mar 2014 12:56:35 +0400
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <d8261204d764a6238077c98c113dc162.NginxMailingListRussian@forum.nginx.org>
References: <CAEwm3CE++mN_bE7Dq_5EXJRnaBauwbsNLUJY1JSZ3LwqQSv-=A@mail.gmail.com>
 <d8261204d764a6238077c98c113dc162.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAOrB69PYtO3-oZA9eTLsAdmaaXcaWQVznszDhiCUo3hSvqyiDw@mail.gmail.com>

А в конфиге nginx прописать только 80 порт для сайтов без ssl не пробовали?


7 марта 2014 г., 12:31 пользователь vaal <nginx-forum at nginx.us> написал:

> Проблема в том что пользователи могут заходить по https на сайты для
> которых
> не установлены ssl. При этом они будут получать в браузере сообщения про
> проблему с ssl и т.п.., которые могут их "напугать".
>
> В итоге хотелось бы чтобы на сайты без ssl нельзя попытаться было войти по
> https. Выше мне уже ответили что нужен второй ip.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,248179,248215#msg-248215
>
> _______________________________________________
> 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/20140307/cc18a681/attachment.html>

From onokonem at gmail.com  Fri Mar  7 08:59:22 2014
From: onokonem at gmail.com (Daniel Podolsky)
Date: Fri, 7 Mar 2014 12:59:22 +0400
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <CAOrB69PYtO3-oZA9eTLsAdmaaXcaWQVznszDhiCUo3hSvqyiDw@mail.gmail.com>
References: <CAEwm3CE++mN_bE7Dq_5EXJRnaBauwbsNLUJY1JSZ3LwqQSv-=A@mail.gmail.com>
 <d8261204d764a6238077c98c113dc162.NginxMailingListRussian@forum.nginx.org>
 <CAOrB69PYtO3-oZA9eTLsAdmaaXcaWQVznszDhiCUo3hSvqyiDw@mail.gmail.com>
Message-ID: <CAKaHDOFBegXCB4oTdOshjJhaEtgPjozbz-ReO93aZxy9i2+r4g@mail.gmail.com>

> А в конфиге nginx прописать только 80 порт для сайтов без ssl не пробовали?
DNS записи от этого не поправятся

From uncleandyv at gmail.com  Fri Mar  7 09:03:43 2014
From: uncleandyv at gmail.com (Andrey Velikoredchanin)
Date: Fri, 7 Mar 2014 13:03:43 +0400
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <CAKaHDOFBegXCB4oTdOshjJhaEtgPjozbz-ReO93aZxy9i2+r4g@mail.gmail.com>
References: <CAEwm3CE++mN_bE7Dq_5EXJRnaBauwbsNLUJY1JSZ3LwqQSv-=A@mail.gmail.com>
 <d8261204d764a6238077c98c113dc162.NginxMailingListRussian@forum.nginx.org>
 <CAOrB69PYtO3-oZA9eTLsAdmaaXcaWQVznszDhiCUo3hSvqyiDw@mail.gmail.com>
 <CAKaHDOFBegXCB4oTdOshjJhaEtgPjozbz-ReO93aZxy9i2+r4g@mail.gmail.com>
Message-ID: <CAOrB69PaxhEqOzMkT0Qs-htTfmgnnKHhF2SC1v=p=w48Za1rgw@mail.gmail.com>

При чем тут DNS? Если поставить 80 порт для сайтов без SSL, то они
перестанут отвечать по https порту (443). Я так понимаю, именно это и нужно
автору?


7 марта 2014 г., 12:59 пользователь Daniel Podolsky <onokonem at gmail.com>написал:

> > А в конфиге nginx прописать только 80 порт для сайтов без ssl не
> пробовали?
> DNS записи от этого не поправятся
> _______________________________________________
> 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/20140307/5c023409/attachment-0001.html>

From onokonem at gmail.com  Fri Mar  7 09:09:32 2014
From: onokonem at gmail.com (Daniel Podolsky)
Date: Fri, 7 Mar 2014 13:09:32 +0400
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <CAOrB69PaxhEqOzMkT0Qs-htTfmgnnKHhF2SC1v=p=w48Za1rgw@mail.gmail.com>
References: <CAEwm3CE++mN_bE7Dq_5EXJRnaBauwbsNLUJY1JSZ3LwqQSv-=A@mail.gmail.com>
 <d8261204d764a6238077c98c113dc162.NginxMailingListRussian@forum.nginx.org>
 <CAOrB69PYtO3-oZA9eTLsAdmaaXcaWQVznszDhiCUo3hSvqyiDw@mail.gmail.com>
 <CAKaHDOFBegXCB4oTdOshjJhaEtgPjozbz-ReO93aZxy9i2+r4g@mail.gmail.com>
 <CAOrB69PaxhEqOzMkT0Qs-htTfmgnnKHhF2SC1v=p=w48Za1rgw@mail.gmail.com>
Message-ID: <CAKaHDOF9V5JxWvo3FDxXqeLq-jtTxhkb=HxY7_tdG8RKBYpXbw@mail.gmail.com>

> При чем тут DNS? Если поставить 80 порт для сайтов без SSL, то они
> перестанут отвечать по https порту (443). Я так понимаю, именно это и нужно
> автору?
Если на сервере один ip, и есть хотя бы один сайт с ssl - этот сервер
будет отвечать на порту 443 по всем именам, которые в dns на этот ip
ведут.

From nolux2 at gmail.com  Fri Mar  7 11:51:15 2014
From: nolux2 at gmail.com (=?KOI8-R?B?88XSx8XKIO3JyMHKzM/X?=)
Date: Fri, 7 Mar 2014 15:51:15 +0400
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9GA0L4g0YHQvtCy0LzQtdGB0YLQuNC80L7RgdGC?=
 =?UTF-8?B?0YwgTmdpbngg0YEg0LTQvtC80LXQvdCw0LzQuCAuaTJw?=
In-Reply-To: <126747605.7ssBhkKx3p@hydra>
References: <CAKYgWWtgvfirRr7tTnHsBW-q7yLtViPtn5wC_0GKjDUFLS01zQ@mail.gmail.com>
 <7497681.zc18iFJedK@note> <126747605.7ssBhkKx3p@hydra>
Message-ID: <CAKYgWWtnW_6+Lw+FeYUFgKpPb4o+8p2fPggi=7OU3qBS-yo68w@mail.gmail.com>

Я нашёл причину: я сам указал имя домена без зоны, в настройках серверного
туннеля: Имя веб-сайта(W):должно быть вида "mysite.i2p" а не "mysite", как
было у меня. Изменил на mysite.i2p и всё заработало.


7 марта 2014 г., 8:46 пользователь Styopa Semenukha
<semenukha at gmail.com>написал:

> https://geti2p.net/en/docs/naming
> Я спеки не читал, но предположу, что, раз i2p -- псевдозона, то браузер её
> отбрасывает и оставляет только Base64 строку.
> Суффикс i2p, видимо, нужен только для резолвера, чтобы не путать с обычным
> интернетом.
> Скорее всего, и в Торе так же.
>
> On Friday, March 07, 2014 11:11:54 AM Vadim A. Misbakh-Soloviov wrote:
> > На сколько я могу знать, NginX сам по себе (без сторонних модулей и с
> > выключенным SSI (не SSL, если что)) вообще никак не притрагивается к
> html-коду
> > (а соответственно ссылкам) ни отдаваемых статических фалов, ни того, что
> > проксирует.
> > Переменная $host, на сколько мне известно, тоже формируется из
> > соответствующего заголовка, передаваемого клиетом (в отличие от
> server_name).
> >
> >
> > В письме от Чт, 6 марта 2014 21:59:25 пользователь Сергей Михайлов
> написал:
> > > Имею проблемы при работе с доменом в зоне i2p: в переменной Nginx $host
> > > содержится только название домена, без зоны.
> > >
> > > Я думаю что это ещё не все проблемы, связанные с обработкой доменов
> данной
> > > зоны: ссылки на сайте все такие же пустые, без зоны (и соответственно
> > > подключённые к странице скрипты и css файлы не грузятся).
> > > Как исправить ситуацию?
> >
> >
> --
> Sincerely yours,
> Styopa Semenukha.
> _______________________________________________
> 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/20140307/c5ae430a/attachment.html>

From vbart at nginx.com  Fri Mar  7 15:13:22 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 07 Mar 2014 19:13:22 +0400
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <d8261204d764a6238077c98c113dc162.NginxMailingListRussian@forum.nginx.org>
References: <CAEwm3CE++mN_bE7Dq_5EXJRnaBauwbsNLUJY1JSZ3LwqQSv-=A@mail.gmail.com>
 <d8261204d764a6238077c98c113dc162.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2643934.tnxmpLtCP6@vbart-laptop>

On Friday 07 March 2014 03:31:35 vaal wrote:
> Проблема в том что пользователи могут заходить по https на сайты для которых
> не установлены ssl. При этом они будут получать в браузере сообщения про
> проблему с ssl и т.п.., которые могут их "напугать".
> 
> В итоге хотелось бы чтобы на сайты без ssl нельзя попытаться было войти по
> https. Выше мне уже ответили что нужен второй ip.
> 

Попытаться всегда можно.  Повесив https на отдельный ip вы только измените 
сообщение об ошибке и вообще лишите пользователя возможности увидеть сайт.

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

From dmitry.goryainov at gmail.com  Sat Mar  8 22:33:07 2014
From: dmitry.goryainov at gmail.com (Dmitry)
Date: Sun, 9 Mar 2014 02:33:07 +0400
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <2643934.tnxmpLtCP6@vbart-laptop>
References: <CAEwm3CE++mN_bE7Dq_5EXJRnaBauwbsNLUJY1JSZ3LwqQSv-=A@mail.gmail.com>
 <d8261204d764a6238077c98c113dc162.NginxMailingListRussian@forum.nginx.org>
 <2643934.tnxmpLtCP6@vbart-laptop>
Message-ID: <CAHzBpYVChQ=dp+wiQnjrVJLo4Y7NZVc9_dbXBLfnqZL1sEqSMg@mail.gmail.com>

Э... странный способ, но м.б. тупо добавить к сайтам без https:

if ( $scheme = "https" ) {
 rewrite ^/(.*)$ http://$host/$1 permanent;
 }

?

2014-03-07 19:13 GMT+04:00 Валентин Бартенев <vbart at nginx.com>:

> On Friday 07 March 2014 03:31:35 vaal wrote:
> > Проблема в том что пользователи могут заходить по https на сайты для
> которых
> > не установлены ssl. При этом они будут получать в браузере сообщения про
> > проблему с ssl и т.п.., которые могут их "напугать".
> >
> > В итоге хотелось бы чтобы на сайты без ssl нельзя попытаться было войти
> по
> > https. Выше мне уже ответили что нужен второй ip.
> >
>
> Попытаться всегда можно.  Повесив https на отдельный ip вы только измените
> сообщение об ошибке и вообще лишите пользователя возможности увидеть сайт.
>
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
Dmitry Goryainov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140309/70157515/attachment.html>

From onokonem at gmail.com  Sat Mar  8 22:38:18 2014
From: onokonem at gmail.com (Daniel Podolsky)
Date: Sun, 9 Mar 2014 02:38:18 +0400
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <CAHzBpYVChQ=dp+wiQnjrVJLo4Y7NZVc9_dbXBLfnqZL1sEqSMg@mail.gmail.com>
References: <CAEwm3CE++mN_bE7Dq_5EXJRnaBauwbsNLUJY1JSZ3LwqQSv-=A@mail.gmail.com>
 <d8261204d764a6238077c98c113dc162.NginxMailingListRussian@forum.nginx.org>
 <2643934.tnxmpLtCP6@vbart-laptop>
 <CAHzBpYVChQ=dp+wiQnjrVJLo4Y7NZVc9_dbXBLfnqZL1sEqSMg@mail.gmail.com>
Message-ID: <CAKaHDOF9dgn22Bx-=TcZunCBLqMtSCEyfgSABdNd4HxQmV4RAg@mail.gmail.com>

> Э... странный способ, но м.б. тупо добавить к сайтам без https:
>
> if ( $scheme = "https" ) {
>  rewrite ^/(.*)$ http://$host/$1 permanent;
>  }
Это произойдет только после установки соединения, соответственно -
после появления предупреждения.

From nginx-forum at nginx.us  Sun Mar  9 10:43:32 2014
From: nginx-forum at nginx.us (yaushev)
Date: Sun, 09 Mar 2014 06:43:32 -0400
Subject: =?UTF-8?B?Tmdpbngg0L3QtSDQstC+0YHQv9GA0LjQvdC40LzQsNC10YIgc2VydmVyIG5hbWU=?=
Message-ID: <e36d8a5e4095f87029a91389590badf1.NginxMailingListRussian@forum.nginx.org>

Здравствуйте! Я пытаюсь поднять сервер nginx. Использую связку
nginx+uwsgi+django. Вроде как настроил конфиг для проекта, но проблема в том
что открытие сайта в браузере происходит только если вводить ip адрес, а
доменное имя которое я задал в конфиг.файле он не воспринимает. Я создавал
конфиг.файл mysite.ru в /etc/nginx/sites-available и такой же в
sites-enabled
Вот конфиг:
server {
listen 80;
server_name mysite.ru www.mysite.ru;
access_log /var/log/nginx/mysite.ru_access.log;
error_log /var/log/nginx/mysite.ru_error.log;

location / {
uwsgi_pass unix:///tmp/mysite.ru.sock;
include uwsgi_params;
}

location /media/ {
alias /home/ed/projects/mysite/media/;
}

location /static/ {
alias /home/ed/projects/mysite/static/;
}
}

Если дело не в настройке конфига, тогда в чем может быть?

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


From zmey1992 at ya.ru  Mon Mar 10 09:50:36 2014
From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=)
Date: Mon, 10 Mar 2014 13:50:36 +0400
Subject: =?UTF-8?B?UmU6IE5naW54INC90LUg0LLQvtGB0L/RgNC40L3QuNC80LDQtdGCIHNlcnZlciBu?=
 =?UTF-8?B?YW1l?=
In-Reply-To: <e36d8a5e4095f87029a91389590badf1.NginxMailingListRussian@forum.nginx.org>
References: <e36d8a5e4095f87029a91389590badf1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <697861394445036@web9j.yandex.ru>

Вы и пытаетесь попасть на сайт с помощью домена mysite.ru?
Если нет, то после применения нового конфига применяли настройки, перезапустив nginx?
Если да, то он прописан у вас в hosts с соответствующим вашему серверу IP?

09.03.2014, 14:43, "yaushev" <nginx-forum at nginx.us>:
> Здравствуйте! Я пытаюсь поднять сервер nginx. Использую связку
> nginx+uwsgi+django. Вроде как настроил конфиг для проекта, но проблема в том
> что открытие сайта в браузере происходит только если вводить ip адрес, а
> доменное имя которое я задал в конфиг.файле он не воспринимает. Я создавал
> конфиг.файл mysite.ru в /etc/nginx/sites-available и такой же в
> sites-enabled
> Вот конфиг:
> server {
> listen 80;
> server_name mysite.ru www.mysite.ru;
> access_log /var/log/nginx/mysite.ru_access.log;
> error_log /var/log/nginx/mysite.ru_error.log;
>
> location / {
> uwsgi_pass unix:///tmp/mysite.ru.sock;
> include uwsgi_params;
> }
>
> location /media/ {
> alias /home/ed/projects/mysite/media/;
> }
>
> location /static/ {
> alias /home/ed/projects/mysite/static/;
> }
> }
>
> Если дело не в настройке конфига, тогда в чем может быть?
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,248249,248249#msg-248249
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From andrey at kopeyko.ru  Mon Mar 10 20:13:58 2014
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Tue, 11 Mar 2014 00:13:58 +0400
Subject: =?UTF-8?B?UmU6IE5naW54INC90LUg0LLQvtGB0L/RgNC40L3QuNC80LDQtdGCIHNlcnZlciBu?=
 =?UTF-8?B?YW1l?=
In-Reply-To: <e36d8a5e4095f87029a91389590badf1.NginxMailingListRussian@forum.nginx.org>
References: <e36d8a5e4095f87029a91389590badf1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <531E1D06.9070407@kopeyko.ru>

09.03.2014 14:43, yaushev пишет:
> Здравствуйте! Я пытаюсь поднять сервер nginx. Использую связку
> nginx+uwsgi+django. Вроде как настроил конфиг для проекта, но проблема в том
> что открытие сайта в браузере происходит только если вводить ip адрес, а
> доменное имя которое я задал в конфиг.файле он не воспринимает.

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

Убедитесь, что ваше имя "mysite.ru" разрешается именно в IP-адрес вашего 
сервера. Судя по описанным вами симптомам, оно разрешается в какой-то 
иной адрес - и поэтому вы можете соединиться с вашим сервером лишь введя 
его IP-адрес напрямую в адресную строку браузера.


>


-- 
Best regards,
Andrey Kopeyko <andrey at kopeyko.ru>


From nginx-forum at nginx.us  Tue Mar 11 14:24:58 2014
From: nginx-forum at nginx.us (vaal)
Date: Tue, 11 Mar 2014 10:24:58 -0400
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <531882F4.1090201@kopeyko.ru>
References: <531882F4.1090201@kopeyko.ru>
Message-ID: <fd0d627f716576d45d9bf065b8af89fa.NginxMailingListRussian@forum.nginx.org>

По этому варианту возник дополнительный вопрос.
Например имеется такой конфиг (без лишней инфы)

server {
    listen 80;
    listen 443 ssl;
    server_name  example.com;
}

server {
    listen 80;
    listen 443 ssl;
    server_name  example.ru;
}

server {
    listen 80;
    server_name  test.ru;
}

будет достаточно изменить его на

server {
    listen 1.2.3.4:80;
    listen 1.2.3.4:443 ssl;
    server_name  example.com;
}

server {
    listen 1.2.3.4:80;
    listen 1.2.3.4:443 ssl;
    server_name  example.ru;
}

server {
    listen 1.2.3.5:80;
    server_name  test.ru;
}

или возможно есть какие-то подводные камни?

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


From andrey at kopeyko.ru  Wed Mar 12 01:54:17 2014
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Wed, 12 Mar 2014 05:54:17 +0400
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <fd0d627f716576d45d9bf065b8af89fa.NginxMailingListRussian@forum.nginx.org>
References: <531882F4.1090201@kopeyko.ru>
 <fd0d627f716576d45d9bf065b8af89fa.NginxMailingListRussian@forum.nginx.org>
Message-ID: <531FBE49.2070903@kopeyko.ru>

11.03.2014 18:24, vaal пишет:
> По этому варианту возник дополнительный вопрос.
> Например имеется такой конфиг (без лишней инфы)
>
...
>
> будет достаточно изменить его на

Да, test.ru перестанет отзываться на SSL.

> server {
>      listen 1.2.3.4:80;
>      listen 1.2.3.4:443 ssl;
>      server_name  example.com;
> }
>
> server {
>      listen 1.2.3.4:80;
>      listen 1.2.3.4:443 ssl;
>      server_name  example.ru;
> }
>
> server {
>      listen 1.2.3.5:80;
>      server_name  test.ru;
> }
>
> или возможно есть какие-то подводные камни?

Будет проблема показа правильного сертификата для "example.com" и 
"example.ru" : если неумеющий SNI клиент пойдёт на "example.ru" - ему 
покажут сертификат для "example.com". И клиент от такого может обидеться.

Лечится
- либо обретением третьего IP-адреса и отсаживанием на него "example.ru"
- либо обретением SSL-сертификата на оба эти имени разом. Присмотритесь 
к "True BusinessID" или "UC/SAN" от ГеоТраста:
   http://www.geotrust.com/ssl/ssl-certificates/
   http://www.geotrust.com/ssl/ssl-certificates-san-uc/



-- 
Best regards,
Andrey Kopeyko <andrey at kopeyko.ru>


From nginx-forum at nginx.us  Wed Mar 12 06:17:21 2014
From: nginx-forum at nginx.us (georgiy_s)
Date: Wed, 12 Mar 2014 02:17:21 -0400
Subject: =?UTF-8?B?0YHQstC+0Lkgcm9vdCDQtNC70Y8g0L7Qv9GA0LXQtNC10L3QvdC+0LPQviDRg9GA?=
 =?UTF-8?B?0LvQsA==?=
Message-ID: <436545d4c47167fbb8f8b961ac74c77c.NginxMailingListRussian@forum.nginx.org>

Добрый день!

Столкнулся с казалось бы простой проблемой - нужно для определенного урла
задать определенный root.
Вот конфиг, с которым я тестирую:

    server {
	listen 80;
	server_name test.loc;
	root /var/www/test;
	
	error_log /var/log/nginx/mytest.log;
	index index.html index.php;
	
	location / {
	    #index index.html index.php;
	    try_files $uri $uri/ /index.php?$args;
	    set $root /var/www/test;
	}
	
	location /sample {
	  try_files $uri $uri/ /index.php;
	  root /var/www/test2;
	  #set $root /var/www/test2;
	  }
	  
	location ~ \.php$ {
	  #try_files $uri =404;
	  #fastcgi_split_path_info ^(.+\.php)(/.+)$;
	  #fastcgi_split_path_info  ^(.+\.php)(.+)$;
	  include fastcgi_params;
	  fastcgi_param PATH_INFO $fastcgi_path_info;
	  fastcgi_index index.php;
	  fastcgi_param  PATH_TRANSLATED  $document_root$fastcgi_script_name;
	  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
	  fastcgi_pass   127.0.0.1:9000;
	}
    }


Вкратце, чего я хочу добиться: чтобы переходя на урл, начинающийся с /sample
, выполнялся код из другого каталога.
Заранее спасибо за ответ.

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


From tetsio.nainn at gmail.com  Wed Mar 12 06:33:51 2014
From: tetsio.nainn at gmail.com (=?UTF-8?B?0Jwu0JAuINCc0L7RhdC90LDRh9C10LLRgdC60LjQuQ==?=)
Date: Wed, 12 Mar 2014 16:33:51 +1000
Subject: =?UTF-8?B?UmU6INGB0LLQvtC5IHJvb3Qg0LTQu9GPINC+0L/RgNC10LTQtdC90L3QvtCz0L4g?=
 =?UTF-8?B?0YPRgNC70LA=?=
In-Reply-To: <436545d4c47167fbb8f8b961ac74c77c.NginxMailingListRussian@forum.nginx.org>
References: <436545d4c47167fbb8f8b961ac74c77c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CALXqZiHq6tsB=iPT-M=wcx44H52ztsxFkA9KPxRQFPC4486T5g@mail.gmail.com>

мб Вам вот это поможет?
http://nginx.org/ru/docs/http/ngx_http_core_module.html#alias


12 марта 2014 г., 16:17 пользователь georgiy_s <nginx-forum at nginx.us>написал:

> Добрый день!
>
> Столкнулся с казалось бы простой проблемой - нужно для определенного урла
> задать определенный root.
> Вот конфиг, с которым я тестирую:
>
>     server {
>         listen 80;
>         server_name test.loc;
>         root /var/www/test;
>
>         error_log /var/log/nginx/mytest.log;
>         index index.html index.php;
>
>         location / {
>             #index index.html index.php;
>             try_files $uri $uri/ /index.php?$args;
>             set $root /var/www/test;
>         }
>
>         location /sample {
>           try_files $uri $uri/ /index.php;
>           root /var/www/test2;
>           #set $root /var/www/test2;
>           }
>
>         location ~ \.php$ {
>           #try_files $uri =404;
>           #fastcgi_split_path_info ^(.+\.php)(/.+)$;
>           #fastcgi_split_path_info  ^(.+\.php)(.+)$;
>           include fastcgi_params;
>           fastcgi_param PATH_INFO $fastcgi_path_info;
>           fastcgi_index index.php;
>           fastcgi_param  PATH_TRANSLATED
>  $document_root$fastcgi_script_name;
>           fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
>           fastcgi_pass   127.0.0.1:9000;
>         }
>     }
>
>
> Вкратце, чего я хочу добиться: чтобы переходя на урл, начинающийся с
> /sample
> , выполнялся код из другого каталога.
> Заранее спасибо за ответ.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,248289,248289#msg-248289
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
С ув. М.А. Мохначевский
Отдел системного администрирования
ООО "Компания "СахаИнтернет НТ"
к.т. (4112)219711 доб. 927
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140312/569979ce/attachment.html>

From nginx-forum at nginx.us  Wed Mar 12 06:52:26 2014
From: nginx-forum at nginx.us (georgiy_s)
Date: Wed, 12 Mar 2014 02:52:26 -0400
Subject: =?UTF-8?B?UmU6INGB0LLQvtC5IHJvb3Qg0LTQu9GPINC+0L/RgNC10LTQtdC90L3QvtCz0L4g?=
 =?UTF-8?B?0YPRgNC70LA=?=
In-Reply-To: <CALXqZiHq6tsB=iPT-M=wcx44H52ztsxFkA9KPxRQFPC4486T5g@mail.gmail.com>
References: <CALXqZiHq6tsB=iPT-M=wcx44H52ztsxFkA9KPxRQFPC4486T5g@mail.gmail.com>
Message-ID: <df41390dba207bcfc41af38aec3588e8.NginxMailingListRussian@forum.nginx.org>

перебрал уже множество вариантов, пробывал и этот (хоть как-то заработать
конфиг не получилось).
в итоге максимум, что получилось - чтобы при запросе test.loc/sample
отображалось содержимое файла из папки test2.
при запросе test.loc/sample/index.php скачивается сам php файл, что
печально.


М.А. Мохначевский Wrote:
-------------------------------------------------------
> мб Вам вот это поможет?
> http://nginx.org/ru/docs/http/ngx_http_core_module.html#alias

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


From nefer05 at gmail.com  Wed Mar 12 06:52:45 2014
From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=)
Date: Wed, 12 Mar 2014 10:52:45 +0400
Subject: =?UTF-8?B?UmU6INGB0LLQvtC5IHJvb3Qg0LTQu9GPINC+0L/RgNC10LTQtdC90L3QvtCz0L4g?=
 =?UTF-8?B?0YPRgNC70LA=?=
In-Reply-To: <CALXqZiHq6tsB=iPT-M=wcx44H52ztsxFkA9KPxRQFPC4486T5g@mail.gmail.com>
References: <436545d4c47167fbb8f8b961ac74c77c.NginxMailingListRussian@forum.nginx.org>
 <CALXqZiHq6tsB=iPT-M=wcx44H52ztsxFkA9KPxRQFPC4486T5g@mail.gmail.com>
Message-ID: <CAE-UrwiSKTVk2NGkigAHbJHgAbzt8f2xTstq7hYuUXtpp=symg@mail.gmail.com>

Тут просто надо понять, что с данным конфигом PHP файлы выполняются не в
локации /sample, а в локации \.php$...
Лечить лучше вложенными локейшенами.


2014-03-12 10:33 GMT+04:00 М.А. Мохначевский <tetsio.nainn at gmail.com>:

> мб Вам вот это поможет?
> http://nginx.org/ru/docs/http/ngx_http_core_module.html#alias
>
>
> 12 марта 2014 г., 16:17 пользователь georgiy_s <nginx-forum at nginx.us>написал:
>
> Добрый день!
>>
>> Столкнулся с казалось бы простой проблемой - нужно для определенного урла
>> задать определенный root.
>> Вот конфиг, с которым я тестирую:
>>
>>     server {
>>         listen 80;
>>         server_name test.loc;
>>         root /var/www/test;
>>
>>         error_log /var/log/nginx/mytest.log;
>>         index index.html index.php;
>>
>>         location / {
>>             #index index.html index.php;
>>             try_files $uri $uri/ /index.php?$args;
>>             set $root /var/www/test;
>>         }
>>
>>         location /sample {
>>           try_files $uri $uri/ /index.php;
>>           root /var/www/test2;
>>           #set $root /var/www/test2;
>>           }
>>
>>         location ~ \.php$ {
>>           #try_files $uri =404;
>>           #fastcgi_split_path_info ^(.+\.php)(/.+)$;
>>           #fastcgi_split_path_info  ^(.+\.php)(.+)$;
>>           include fastcgi_params;
>>           fastcgi_param PATH_INFO $fastcgi_path_info;
>>           fastcgi_index index.php;
>>           fastcgi_param  PATH_TRANSLATED
>>  $document_root$fastcgi_script_name;
>>           fastcgi_param SCRIPT_FILENAME
>> $document_root$fastcgi_script_name;
>>           fastcgi_pass   127.0.0.1:9000;
>>         }
>>     }
>>
>>
>> Вкратце, чего я хочу добиться: чтобы переходя на урл, начинающийся с
>> /sample
>> , выполнялся код из другого каталога.
>> Заранее спасибо за ответ.
>>
>> Posted at Nginx Forum:
>> http://forum.nginx.org/read.php?21,248289,248289#msg-248289
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> --
> С ув. М.А. Мохначевский
> Отдел системного администрирования
> ООО "Компания "СахаИнтернет НТ"
> к.т. (4112)219711 доб. 927
>
> _______________________________________________
> 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/20140312/90b83466/attachment-0001.html>

From nginx-forum at nginx.us  Wed Mar 12 07:42:59 2014
From: nginx-forum at nginx.us (vaal)
Date: Wed, 12 Mar 2014 03:42:59 -0400
Subject: =?UTF-8?B?UmU6INC+0LTQuNC9INGB0LXRgNCy0LXRgCDRgSDQvdC10YHQutC+0LvRjNC60Lg=?=
 =?UTF-8?B?0LzQuCDRgdCw0LnRgtCw0LzQuCDRgS/QsdC10Lcgc3Ns?=
In-Reply-To: <531FBE49.2070903@kopeyko.ru>
References: <531FBE49.2070903@kopeyko.ru>
Message-ID: <96065f05cb90b44103b24c389e8d2621.NginxMailingListRussian@forum.nginx.org>

Спасибо еще раз!

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


From nginx-forum at nginx.us  Wed Mar 12 09:38:34 2014
From: nginx-forum at nginx.us (georgiy_s)
Date: Wed, 12 Mar 2014 05:38:34 -0400
Subject: =?UTF-8?B?UmU6INGB0LLQvtC5IHJvb3Qg0LTQu9GPINC+0L/RgNC10LTQtdC90L3QvtCz0L4g?=
 =?UTF-8?B?0YPRgNC70LA=?=
In-Reply-To: <CAE-UrwiSKTVk2NGkigAHbJHgAbzt8f2xTstq7hYuUXtpp=symg@mail.gmail.com>
References: <CAE-UrwiSKTVk2NGkigAHbJHgAbzt8f2xTstq7hYuUXtpp=symg@mail.gmail.com>
Message-ID: <0484ae1d78b9407b0928ce239dc060af.NginxMailingListRussian@forum.nginx.org>

Насколько понимаю, это должно выглядеть так:

    server {
	listen 80;
	server_name test.loc;
	root /var/www/test;
	
	error_log /var/log/nginx/mytest.log;
	index index.html index.php;
	
	location / {
	
	index index.html index.php;
	try_files $uri $uri/ /index.php?$args;
	set $root /var/www/test;
		
	  		
	}
	
	location /sample {
	   
	    index index.html index.php;
	    try_files $uri $uri/ /index.php?$args;
	    alias /var/www/test2;
	    
	    location ~ \.php$ {
		include fastcgi_params;
		fastcgi_param PATH_INFO $fastcgi_path_info;
		fastcgi_index index.php;
		fastcgi_param  PATH_TRANSLATED  $document_root$fastcgi_script_name;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		fastcgi_pass   127.0.0.1:9000;
	    }
	}
	
	location ~ \.php$ {
	  #try_files $uri =404;
	  #fastcgi_split_path_info ^(.+\.php)(/.+)$;
	  #fastcgi_split_path_info  ^(.+\.php)(.+)$;
	  
	  include fastcgi_params;
	  fastcgi_param PATH_INFO $fastcgi_path_info;
	  fastcgi_index index.php;
	  fastcgi_param  PATH_TRANSLATED  $document_root$fastcgi_script_name;
	  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
	  fastcgi_pass   127.0.0.1:9000;
	}
	
    }

всё теперь почти работает. но присутвтвует привязка к названию алиаса. т.е.
мы прописываем алиас sample и поэтому по урлу
http://test.loc/sample/index.php запрашивается файл
/var/www/test2/sample/index.php , а нужен файл /var/www/test2/index.php .

подскажите, пожалуйста, как разрешить эту зависимость?

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


From nginx-forum at nginx.us  Wed Mar 12 10:18:53 2014
From: nginx-forum at nginx.us (euxomen)
Date: Wed, 12 Mar 2014 06:18:53 -0400
Subject: =?UTF-8?B?0J7RiNC40LHQutCwLiDQptC40LrQuyDQv9GA0Lgg0L7QsdGA0LDRidC10L3QuNC4?=
 =?UTF-8?B?INC6INC40LzQtdC90L7QstCw0L3QvtC5INC70L7QutCw0YbQuNC4ICJyZXdy?=
 =?UTF-8?B?aXRlIG9yIGludGVybmFsIHJlZGlyZWN0aW9uIGN5Y2xlIHdoaWxlIHJlZGly?=
 =?UTF-8?B?ZWN0IHRvIG5hbWVkIGxvY2F0aW9uIg==?=
Message-ID: <0eeefd754041e508dd192058e49a64e4.NginxMailingListRussian@forum.nginx.org>

OS: FreeBSD 9
Nginx: 1.4.4
Конфигурация сервера:

server {
        listen 80;
        root /www/domain;
        access_log /var/log/access.log;
        error_log  /var/log/error.log;
        index index.php;

        server_name my.domain.ru;

        location / {
                try_files $uri @front;
        }

        location @front {
                client_body_in_file_only clean;
                client_body_buffer_size 128K;
                client_max_body_size 120M;
                fastcgi_pass 127.0.0.1:9000;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME  $document_root/index.php;
                fastcgi_param SCRIPT_NAME      /index.php;
        }
}

Почему то происходит зацикливание. На другой машине (под убунту и нгинкс
1.4.1) этот конфиг работает нормально. Не пойму в чем ошибка?

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


From nefer05 at gmail.com  Wed Mar 12 10:29:36 2014
From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=)
Date: Wed, 12 Mar 2014 14:29:36 +0400
Subject: =?UTF-8?B?UmU6INGB0LLQvtC5IHJvb3Qg0LTQu9GPINC+0L/RgNC10LTQtdC90L3QvtCz0L4g?=
 =?UTF-8?B?0YPRgNC70LA=?=
In-Reply-To: <0484ae1d78b9407b0928ce239dc060af.NginxMailingListRussian@forum.nginx.org>
References: <CAE-UrwiSKTVk2NGkigAHbJHgAbzt8f2xTstq7hYuUXtpp=symg@mail.gmail.com>
 <0484ae1d78b9407b0928ce239dc060af.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAE-UrwhcQFCAPD-BYNmOQgrT+-iqP_2E-omwSoWz3fw_=gie2Q@mail.gmail.com>

Зачем алиас? Рута нового пропишите!


2014-03-12 13:38 GMT+04:00 georgiy_s <nginx-forum at nginx.us>:

> Насколько понимаю, это должно выглядеть так:
>
>     server {
>         listen 80;
>         server_name test.loc;
>         root /var/www/test;
>
>         error_log /var/log/nginx/mytest.log;
>         index index.html index.php;
>
>         location / {
>
>         index index.html index.php;
>         try_files $uri $uri/ /index.php?$args;
>         set $root /var/www/test;
>
>
>         }
>
>         location /sample {
>
>             index index.html index.php;
>             try_files $uri $uri/ /index.php?$args;
>             alias /var/www/test2;
>
>             location ~ \.php$ {
>                 include fastcgi_params;
>                 fastcgi_param PATH_INFO $fastcgi_path_info;
>                 fastcgi_index index.php;
>                 fastcgi_param  PATH_TRANSLATED
>  $document_root$fastcgi_script_name;
>                 fastcgi_param SCRIPT_FILENAME
> $document_root$fastcgi_script_name;
>                 fastcgi_pass   127.0.0.1:9000;
>             }
>         }
>
>         location ~ \.php$ {
>           #try_files $uri =404;
>           #fastcgi_split_path_info ^(.+\.php)(/.+)$;
>           #fastcgi_split_path_info  ^(.+\.php)(.+)$;
>
>           include fastcgi_params;
>           fastcgi_param PATH_INFO $fastcgi_path_info;
>           fastcgi_index index.php;
>           fastcgi_param  PATH_TRANSLATED
>  $document_root$fastcgi_script_name;
>           fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
>           fastcgi_pass   127.0.0.1:9000;
>         }
>
>     }
>
> всё теперь почти работает. но присутвтвует привязка к названию алиаса. т.е.
> мы прописываем алиас sample и поэтому по урлу
> http://test.loc/sample/index.php запрашивается файл
> /var/www/test2/sample/index.php , а нужен файл /var/www/test2/index.php .
>
> подскажите, пожалуйста, как разрешить эту зависимость?
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,248289,248294#msg-248294
>
> _______________________________________________
> 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/20140312/a30a0593/attachment.html>

From nginx-forum at nginx.us  Wed Mar 12 10:56:05 2014
From: nginx-forum at nginx.us (georgiy_s)
Date: Wed, 12 Mar 2014 06:56:05 -0400
Subject: =?UTF-8?B?UmU6INGB0LLQvtC5IHJvb3Qg0LTQu9GPINC+0L/RgNC10LTQtdC90L3QvtCz0L4g?=
 =?UTF-8?B?0YPRgNC70LA=?=
In-Reply-To: <CAE-UrwhcQFCAPD-BYNmOQgrT+-iqP_2E-omwSoWz3fw_=gie2Q@mail.gmail.com>
References: <CAE-UrwhcQFCAPD-BYNmOQgrT+-iqP_2E-omwSoWz3fw_=gie2Q@mail.gmail.com>
Message-ID: <59833e35ac238913f8079419f50e8b39.NginxMailingListRussian@forum.nginx.org>

поменял alias на root, та же проблема осталась, к сожалению. Т.е. для 
location /sample {
нужна обязательно папка sample, если её нет
то по урлу http://test.loc/sample отображается контент файла
/var/www/test/index.php , а для http://test.loc/sample/index.php 404 not
found.

Подскажите, пожалуйста, как по запросу http://test.loc/sample выполнять код
из /var/www/test/index.php

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


From nefer05 at gmail.com  Wed Mar 12 11:05:50 2014
From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=)
Date: Wed, 12 Mar 2014 15:05:50 +0400
Subject: =?UTF-8?B?UmU6INGB0LLQvtC5IHJvb3Qg0LTQu9GPINC+0L/RgNC10LTQtdC90L3QvtCz0L4g?=
 =?UTF-8?B?0YPRgNC70LA=?=
In-Reply-To: <59833e35ac238913f8079419f50e8b39.NginxMailingListRussian@forum.nginx.org>
References: <CAE-UrwhcQFCAPD-BYNmOQgrT+-iqP_2E-omwSoWz3fw_=gie2Q@mail.gmail.com>
 <59833e35ac238913f8079419f50e8b39.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAE-Urwjz+HB=Li-z1vem5CYXQRnrvCev36CmQV8Dt-j79uT5Og@mail.gmail.com>

Плывем далее. try_files для чего в локейшене?


2014-03-12 14:56 GMT+04:00 georgiy_s <nginx-forum at nginx.us>:

> поменял alias на root, та же проблема осталась, к сожалению. Т.е. для
> location /sample {
> нужна обязательно папка sample, если её нет
> то по урлу http://test.loc/sample отображается контент файла
> /var/www/test/index.php , а для http://test.loc/sample/index.php 404 not
> found.
>
> Подскажите, пожалуйста, как по запросу http://test.loc/sample выполнять
> код
> из /var/www/test/index.php
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,248289,248297#msg-248297
>
> _______________________________________________
> 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/20140312/26e4fe4a/attachment.html>

From nginx-forum at nginx.us  Wed Mar 12 11:25:51 2014
From: nginx-forum at nginx.us (georgiy_s)
Date: Wed, 12 Mar 2014 07:25:51 -0400
Subject: =?UTF-8?B?UmU6INGB0LLQvtC5IHJvb3Qg0LTQu9GPINC+0L/RgNC10LTQtdC90L3QvtCz0L4g?=
 =?UTF-8?B?0YPRgNC70LA=?=
In-Reply-To: <CAE-Urwjz+HB=Li-z1vem5CYXQRnrvCev36CmQV8Dt-j79uT5Og@mail.gmail.com>
References: <CAE-Urwjz+HB=Li-z1vem5CYXQRnrvCev36CmQV8Dt-j79uT5Og@mail.gmail.com>
Message-ID: <aeeef0f60444600a7c8a8fb685fa6082.NginxMailingListRussian@forum.nginx.org>

затрудняюсь ответить, вставили от безысходности. на данный момент добились
таких результатов:
создавая папку с таким же именем, как в location то всё работает, иначе не
работает.

сейчас конфиг такой:

    server {
	listen 80;
	server_name test.loc;
	root /var/www/test;
	
	error_log /var/log/nginx/mytest.log;
	index index.html index.php;
	
	location / {
	
	    index index.html index.php;
	    #try_files $uri $uri/ /index.php?$args;
	    set $root /var/www/test;
	}
	
	location /qqq {
	   
	    index index.html index.php;
	    #try_files $uri $uri/ /index.php?$args;
	    alias /var/www/test2;
	    
	    
	    location ~ \.php$ {
		include fastcgi_params;
		fastcgi_param PATH_INFO $fastcgi_path_info;
		fastcgi_index index.php;
		fastcgi_param	PATH_TRANSLATED  $document_root$fastcgi_script_name;
		fastcgi_param	SCRIPT_FILENAME $document_root$fastcgi_script_name;
		fastcgi_pass   127.0.0.1:9000;
	    }
	}
	
	location ~ \.php$ {
  
	  include fastcgi_params;
	  fastcgi_param PATH_INFO $fastcgi_path_info;
	  fastcgi_index index.php;
	  fastcgi_param  PATH_TRANSLATED  $document_root$fastcgi_script_name;
	  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
	  fastcgi_pass   127.0.0.1:9000;
	}
	
    }

по этому урлу http://test.loc/qqq/ сейчас ошибка "File not found."

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


From mdounin at mdounin.ru  Wed Mar 12 11:32:50 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 12 Mar 2014 15:32:50 +0400
Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsC4g0KbQuNC60Lsg0L/RgNC4INC+0LHRgNCw0YnQtdC9?=
 =?UTF-8?B?0LjQuCDQuiDQuNC80LXQvdC+0LLQsNC90L7QuSDQu9C+0LrQsNGG0LjQuCAi?=
 =?UTF-8?B?cmV3cml0ZSBvciBpbnRlcm5hbCByZWRpcmVjdGlvbiBjeWNsZSB3aGlsZSBy?=
 =?UTF-8?B?ZWRpcmVjdCB0byBuYW1lZCBsb2NhdGlvbiI=?=
In-Reply-To: <0eeefd754041e508dd192058e49a64e4.NginxMailingListRussian@forum.nginx.org>
References: <0eeefd754041e508dd192058e49a64e4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140312113250.GH34696@mdounin.ru>

Hello!

On Wed, Mar 12, 2014 at 06:18:53AM -0400, euxomen wrote:

> OS: FreeBSD 9
> Nginx: 1.4.4
> Конфигурация сервера:
> 
> server {
>         listen 80;
>         root /www/domain;
>         access_log /var/log/access.log;
>         error_log  /var/log/error.log;
>         index index.php;
> 
>         server_name my.domain.ru;
> 
>         location / {
>                 try_files $uri @front;
>         }
> 
>         location @front {
>                 client_body_in_file_only clean;
>                 client_body_buffer_size 128K;
>                 client_max_body_size 120M;
>                 fastcgi_pass 127.0.0.1:9000;
>                 include fastcgi_params;
>                 fastcgi_param SCRIPT_FILENAME  $document_root/index.php;
>                 fastcgi_param SCRIPT_NAME      /index.php;
>         }
> }
> 
> Почему то происходит зацикливание. На другой машине (под убунту и нгинкс
> 1.4.1) этот конфиг работает нормально. Не пойму в чем ошибка?

В процитированном конфиге - ошибки нет.  Наиболее вероятные 
причины проблемы - php-скрипт возвращает X-Accel-Redirect на 
несуществующий файл, тем самым вызывая цикл, или конфиг на самом 
деле не такой.

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


From nginx-forum at nginx.us  Wed Mar 12 13:31:35 2014
From: nginx-forum at nginx.us (euxomen)
Date: Wed, 12 Mar 2014 09:31:35 -0400
Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsC4g0KbQuNC60Lsg0L/RgNC4INC+0LHRgNCw0YnQtdC9?=
 =?UTF-8?B?0LjQuCDQuiDQuNC80LXQvdC+0LLQsNC90L7QuSDQu9C+0LrQsNGG0LjQuCAi?=
 =?UTF-8?B?cmV3cml0ZSBvciBpbnRlcm5hbCByZWRpcmVjdGlvbiBjeWNsZSB3aGlsZSBy?=
 =?UTF-8?B?ZWRpcmVjdCB0byBuYW1lZCBsb2NhdGlvbiI=?=
In-Reply-To: <20140312113250.GH34696@mdounin.ru>
References: <20140312113250.GH34696@mdounin.ru>
Message-ID: <283d95533582482cd8a2b17f69ae1196.NginxMailingListRussian@forum.nginx.org>

Да так и есть. xAccl на несуществующий файл. Спасибо.

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


From vbart at nginx.com  Wed Mar 12 15:41:22 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 12 Mar 2014 19:41:22 +0400
Subject: =?UTF-8?B?UmU6INGB0LLQvtC5IHJvb3Qg0LTQu9GPINC+0L/RgNC10LTQtdC90L3QvtCz0L4g?=
 =?UTF-8?B?0YPRgNC70LA=?=
In-Reply-To: <aeeef0f60444600a7c8a8fb685fa6082.NginxMailingListRussian@forum.nginx.org>
References: <CAE-Urwjz+HB=Li-z1vem5CYXQRnrvCev36CmQV8Dt-j79uT5Og@mail.gmail.com>
 <aeeef0f60444600a7c8a8fb685fa6082.NginxMailingListRussian@forum.nginx.org>
Message-ID: <34869366.44LUnnWD3z@vbart-laptop>

On Wednesday 12 March 2014 07:25:51 georgiy_s wrote:
> затрудняюсь ответить, вставили от безысходности. на данный момент добились
> таких результатов:
> создавая папку с таким же именем, как в location то всё работает, иначе не
> работает.
> 
> сейчас конфиг такой:
[..]
> 		fastcgi_param PATH_INFO $fastcgi_path_info;
> 		fastcgi_index index.php;
> 		fastcgi_param	PATH_TRANSLATED  $document_root$fastcgi_script_name;
> 		fastcgi_param	SCRIPT_FILENAME $document_root$fastcgi_script_name;
[..]

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

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

From nginx-forum at nginx.us  Thu Mar 13 06:52:44 2014
From: nginx-forum at nginx.us (delfi)
Date: Thu, 13 Mar 2014 02:52:44 -0400
Subject: =?UTF-8?B?0J/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUg0LfQsNC/0YDQvtGB0LAg0LHQtdC3?=
 =?UTF-8?B?INC30LDQs9C+0LvQvtCy0LrQsCDQsiBHRVQg0LfQsNC/0YDQvtGBINC90LAg?=
 =?UTF-8?B?YXBhY2hl?=
Message-ID: <a2bbeae4a162d63a1911355e86ad7e45.NginxMailingListRussian@forum.nginx.org>

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

Видел только access.log на apache, где виден запрос без GET и прочих
служебных записей.

В итоге надо принять этот запрос, дать ему эти заголовки и отправить на
apache. Реально ли это сделать на nginx и в какую сторону копать?

Спасибо

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


From mdounin at mdounin.ru  Thu Mar 13 11:24:20 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 13 Mar 2014 15:24:20 +0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA0L7RgdCwINCx?=
 =?UTF-8?B?0LXQtyDQt9Cw0LPQvtC70L7QstC60LAg0LIgR0VUINC30LDQv9GA0L7RgSA=?=
 =?UTF-8?B?0L3QsCBhcGFjaGU=?=
In-Reply-To: <a2bbeae4a162d63a1911355e86ad7e45.NginxMailingListRussian@forum.nginx.org>
References: <a2bbeae4a162d63a1911355e86ad7e45.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140313112420.GO34696@mdounin.ru>

Hello!

On Thu, Mar 13, 2014 at 02:52:44AM -0400, delfi wrote:

> Есть задача, что на сервер с определенного устройства приходит запрос без
> заголовка. Пока еще поверхностно задачу определили, дамп пришлют позже,
> поэтому могу в чем-то ошибаться.
> 
> Видел только access.log на apache, где виден запрос без GET и прочих
> служебных записей.
> 
> В итоге надо принять этот запрос, дать ему эти заголовки и отправить на
> apache. Реально ли это сделать на nginx и в какую сторону копать?

Если "запрос" действительно не содержит GET, то это, вероятно, не 
HTTP-запрос, и nginx его обрабатывать откажется.

Если запрос, который приходит, соответстует HTTP - то принять и 
отправить на бекенд с добавлением любых заголовков его легко, см. 
http://nginx.org/r/proxy_set_header.

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


From nginx-forum at nginx.us  Thu Mar 13 12:03:52 2014
From: nginx-forum at nginx.us (delfi)
Date: Thu, 13 Mar 2014 08:03:52 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA0L7RgdCwINCx?=
 =?UTF-8?B?0LXQtyDQt9Cw0LPQvtC70L7QstC60LAg0LIgR0VUINC30LDQv9GA0L7RgSA=?=
 =?UTF-8?B?0L3QsCBhcGFjaGU=?=
In-Reply-To: <20140313112420.GO34696@mdounin.ru>
References: <20140313112420.GO34696@mdounin.ru>
Message-ID: <4708c2ddffccf670f45f725c343619e2.NginxMailingListRussian@forum.nginx.org>

Действительно, там http и не пахнет.

http://habrastorage.org/files/170/32e/784/17032e7848184771beb1cb7f2643c173.jpg

Спасибо, буду тогда искать варианты обернуть в http запрос.

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


From corochoone at gmail.com  Fri Mar 14 08:44:34 2014
From: corochoone at gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=)
Date: Fri, 14 Mar 2014 12:44:34 +0400
Subject: =?UTF-8?B?0JTQuNGA0LXQutGC0LjQstGLINGB0LbQsNGC0LjRjyDQtNGD0LHQu9C40YDQvtCy?=
 =?UTF-8?B?0LDQvdGLPw==?=
Message-ID: <CAM6AoWZG6ncnCCUuvsxQitOX_jOB3AMYnpkYkvO=6vvh4X_EpQ@mail.gmail.com>

Сегодня разбирался с сжатием и открыл для себя, что мало сказать:
gzip on
надо ещё ОБЯЗАТЕЛЬНО перечислить MIME типы для которых будет осуществляться
сжатие.
Тогда возникает вопрос, а зачем тогда вообще нужен gzip on?
По факту-то получается, что сжатие включается именно директивой gzip_types.
Только путаница и дублирование.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140314/0faa6664/attachment.html>

From denis at webmaster.spb.ru  Fri Mar 14 09:01:09 2014
From: denis at webmaster.spb.ru (denis)
Date: Fri, 14 Mar 2014 13:01:09 +0400
Subject: =?UTF-8?B?UmU6INCU0LjRgNC10LrRgtC40LLRiyDRgdC20LDRgtC40Y8g0LTRg9Cx0LvQuNGA?=
 =?UTF-8?B?0L7QstCw0L3Riz8=?=
In-Reply-To: <CAM6AoWZG6ncnCCUuvsxQitOX_jOB3AMYnpkYkvO=6vvh4X_EpQ@mail.gmail.com>
References: <CAM6AoWZG6ncnCCUuvsxQitOX_jOB3AMYnpkYkvO=6vvh4X_EpQ@mail.gmail.com>
Message-ID: <5322C555.50705@webmaster.spb.ru>

14.03.2014 12:44, Виктор Вислобоков пишет:
> Сегодня разбирался с сжатием и открыл для себя, что мало сказать:
> gzip on
> надо ещё ОБЯЗАТЕЛЬНО перечислить MIME типы для которых будет 
> осуществляться сжатие.
> Тогда возникает вопрос, а зачем тогда вообще нужен gzip on?
> По факту-то получается, что сжатие включается именно директивой 
> gzip_types. Только путаница и дублирование.
>
http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_types
syntax:|*gzip_types*|/mime-type/|...;|
default:

gzip_types text/html;


Можно было бы сделать по умолчанию все основные сжимаемые типы, да, но и 
так html при верном типе должен жаться. Или какая версия и дистр, если 
дебилян с древней как Г мамонта версией - обновить обязательно.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140314/455f0d47/attachment.html>

From ice at rusklimat.ru  Fri Mar 14 09:22:56 2014
From: ice at rusklimat.ru (=?koi8-r?B?+sHR0s7ZyiDzxdLHxco=?=)
Date: Fri, 14 Mar 2014 09:22:56 +0000
Subject: =?UTF-8?B?UkU6INCU0LjRgNC10LrRgtC40LLRiyDRgdC20LDRgtC40Y8g0LTRg9Cx0LvQuNGA?=
 =?UTF-8?B?0L7QstCw0L3Riz8=?=
In-Reply-To: <5322C555.50705@webmaster.spb.ru>
References: <CAM6AoWZG6ncnCCUuvsxQitOX_jOB3AMYnpkYkvO=6vvh4X_EpQ@mail.gmail.com>
 <5322C555.50705@webmaster.spb.ru>
Message-ID: <5579442683B523488ADE0F6D82314D74C7E053F3@EXMBX1.rusklimat.ru>

По факту получается что используется дефолтное значение, т.е. сжимается text/html  только.

Встречный вопрос - есть ли внятные статисследования какие контент типы сжимать опасно? 
 


-----Original Message-----
From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of denis
Sent: Friday, March 14, 2014 1:01 PM
To: nginx-ru at nginx.org
Subject: Re: Директивы сжатия дублированы?

14.03.2014 12:44, Виктор Вислобоков пишет: 

	Сегодня разбирался с сжатием и открыл для себя, что мало сказать:
	gzip on
	
	надо ещё ОБЯЗАТЕЛЬНО перечислить MIME типы для которых будет осуществляться сжатие.
	
	Тогда возникает вопрос, а зачем тогда вообще нужен gzip on?
	
	По факту-то получается, что сжатие включается именно директивой gzip_types. Только путаница и дублирование.
	


http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_types
syntax:gzip_types mime-type ...;
default: 
gzip_types text/html;

Можно было бы сделать по умолчанию все основные сжимаемые типы, да, но и так html при верном типе должен жаться. Или какая версия и дистр, если дебилян с древней как Г мамонта версией - обновить обязательно.


From citrin at citrin.ru  Fri Mar 14 09:50:28 2014
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Fri, 14 Mar 2014 13:50:28 +0400
Subject: =?UTF-8?B?UmU6INCU0LjRgNC10LrRgtC40LLRiyDRgdC20LDRgtC40Y8g0LTRg9Cx0LvQuNGA?=
 =?UTF-8?B?0L7QstCw0L3Riz8=?=
In-Reply-To: <5579442683B523488ADE0F6D82314D74C7E053F3@EXMBX1.rusklimat.ru>
References: <CAM6AoWZG6ncnCCUuvsxQitOX_jOB3AMYnpkYkvO=6vvh4X_EpQ@mail.gmail.com>
 <5322C555.50705@webmaster.spb.ru>
 <5579442683B523488ADE0F6D82314D74C7E053F3@EXMBX1.rusklimat.ru>
Message-ID: <5322D0E4.4070200@citrin.ru>

On 03/14/14 13:22, Заярный Сергей wrote:
> Встречный вопрос - есть ли внятные статисследования какие контент типы сжимать опасно?

В IE6 иногда наблюдались проблемы со сжатым css (ссылки на подробные описания у 
меня не сохранились).

В современных браузерах проблем не должно быть со сжатием любых текстовых данных.


From denis at webmaster.spb.ru  Fri Mar 14 09:50:48 2014
From: denis at webmaster.spb.ru (denis)
Date: Fri, 14 Mar 2014 13:50:48 +0400
Subject: =?UTF-8?B?UmU6INCU0LjRgNC10LrRgtC40LLRiyDRgdC20LDRgtC40Y8g0LTRg9Cx0LvQuNGA?=
 =?UTF-8?B?0L7QstCw0L3Riz8=?=
In-Reply-To: <5579442683B523488ADE0F6D82314D74C7E053F3@EXMBX1.rusklimat.ru>
References: <CAM6AoWZG6ncnCCUuvsxQitOX_jOB3AMYnpkYkvO=6vvh4X_EpQ@mail.gmail.com>
 <5322C555.50705@webmaster.spb.ru>
 <5579442683B523488ADE0F6D82314D74C7E053F3@EXMBX1.rusklimat.ru>
Message-ID: <5322D0F8.1010808@webmaster.spb.ru>

14.03.2014 13:22, Заярный Сергей пишет:
> По факту получается что используется дефолтное значение, т.е. сжимается text/html  только.
>
> Встречный вопрос - есть ли внятные статисследования какие контент типы сжимать опасно?
опасно? чем это? Бессмысленно - да, есть такое, например jpg и так сжат, 
меньше уже не станет.
А так - gzip_types *;
и будет жать всё.

А, да, есть еще косяки со всяким старьём типа ие6, для чего там обычно 
добавляется исключение по MSIE, так как оно заявляет что умеет сжатие, 
хотя на самом деле не умеет. Только это уже просто костыль 
совместимости, ие6 уже никто в здравом уме не поддерживает.


From s.rasnikov at gmail.com  Fri Mar 14 16:37:14 2014
From: s.rasnikov at gmail.com (Serge Rasnikov)
Date: Fri, 14 Mar 2014 20:37:14 +0400
Subject: x-accel-redirect + websocket
Message-ID: <CAAiTQPLhebLmD7uP_ksr-pWrKc3xSo0QH8UFg+LYx1MXSQ33EQ@mail.gmail.com>

Работает. Вопрос в том, имеет ли такая конструкция право на существование?


    location ~ ^/sio(.*)$ {
        internal;

        proxy_read_timeout 950s;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_pass http://127.0.0.1:25000/socket.io$1;
    }

    location ~ ^/socket.io(.*) {
        proxy_pass http://127.0.0.1:25001/sio$1;
    }


-- 
С уважением,
Сергей Расников
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140314/2a3714bb/attachment.html>

From 747500 at gmail.com  Fri Mar 14 16:53:45 2014
From: 747500 at gmail.com (Serge)
Date: Fri, 14 Mar 2014 20:53:45 +0400
Subject: X-Accel-Redirect + WebSocket
Message-ID: <CAAiTQPL-U7kwwPxi0sTaufFEexAy5YvA9bgri5d6BgeO2YGq7A@mail.gmail.com>

Работает. Вопрос в том, имеет ли такая конструкция право на существование?


    location ~ ^/sio(.*)$ {
        internal;

        proxy_read_timeout 950s;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_pass http://127.0.0.1:25000/socket.io$1;
    }

    location ~ ^/socket.io(.*) {
        proxy_pass http://127.0.0.1:25001/sio$1;
    }

-- 
С уважением,
Сергей Расников
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140314/f101d417/attachment.html>

From nginx-forum at nginx.us  Sat Mar 15 19:41:57 2014
From: nginx-forum at nginx.us (unrecovered)
Date: Sat, 15 Mar 2014 15:41:57 -0400
Subject: =?UTF-8?B?bmdpbngsIHBocC1mcG0g0Lgg0L/RgNC+0LHQu9C10LzRiyDQv9GA0L7QuNC30LI=?=
 =?UTF-8?B?0L7QtNC40YLQtdC70YzQvdC+0YHRgtC4?=
Message-ID: <79ae2d57cda923802248122e16141fe2.NginxMailingListRussian@forum.nginx.org>

Приветствую. Недавно сменил на домашнем веб-сервере апач на nginx+php-fpm.
Наблюдаю странное явление: с одних адресов сайт грузится почти мгновенно, с
других - тупит по минуте. Не нашел никакой зависимости - может различаться
по производительности при заходе из одной подсети одного провайдера, а может
показывать сверхбыструю загрузки при обращении из разных городов. Куда
копать - не представляю.

Адрес сайта http://webstudia43.ru

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


From andrey at kopeyko.ru  Sun Mar 16 19:19:42 2014
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Sun, 16 Mar 2014 23:19:42 +0400
Subject: =?UTF-8?B?UmU6IG5naW54LCBwaHAtZnBtINC4INC/0YDQvtCx0LvQtdC80Ysg0L/RgNC+0Lg=?=
 =?UTF-8?B?0LfQstC+0LTQuNGC0LXQu9GM0L3QvtGB0YLQuA==?=
In-Reply-To: <79ae2d57cda923802248122e16141fe2.NginxMailingListRussian@forum.nginx.org>
References: <79ae2d57cda923802248122e16141fe2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5325F94E.2000103@kopeyko.ru>

15.03.2014 23:41, unrecovered пишет:
> Приветствую.

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

> Куда
> копать - не представляю.

В логи смотрите. Уровень логирования повыше поставьте, notice или info.

>


-- 
Best regards,
Andrey Kopeyko <andrey at kopeyko.ru>


From esokolov.test at gmail.com  Sun Mar 16 22:08:28 2014
From: esokolov.test at gmail.com (=?UTF-8?B?0JXQstCz0LXQvdC40Lkg0JrQstCw0LfQsNGA?=)
Date: Mon, 17 Mar 2014 04:08:28 +0600
Subject: =?UTF-8?B?UmU6IG5naW54LCBwaHAtZnBtINC4INC/0YDQvtCx0LvQtdC80Ysg0L/RgNC+0Lg=?=
 =?UTF-8?B?0LfQstC+0LTQuNGC0LXQu9GM0L3QvtGB0YLQuA==?=
In-Reply-To: <5325F94E.2000103@kopeyko.ru>
References: <79ae2d57cda923802248122e16141fe2.NginxMailingListRussian@forum.nginx.org>
 <5325F94E.2000103@kopeyko.ru>
Message-ID: <CAJDSoiAKRTU0JDVHzWKzt79zjFdei1pgsU8dAXZ0AY0r_6BqCw@mail.gmail.com>

Частенько бывает, что в коде страницы сайта имеется обращение к внешним
ресурсам (сводки курсов валют, прогнозов погоды, баннерокрутилки итп),
имеющим проблемы с доступностью.
Если ситуация с их недоступностью не продумывалась заранее, будет тупить
весь сайт.


17 марта 2014 г., 1:19 пользователь Andrey Kopeyko <andrey at kopeyko.ru>написал:

> 15.03.2014 23:41, unrecovered пишет:
>
>> Приветствую.
>>
>
> Добрый вечер!
>
>
>  Куда
>> копать - не представляю.
>>
>
> В логи смотрите. Уровень логирования повыше поставьте, notice или info.
>
>
>>
>
> --
> Best regards,
> Andrey Kopeyko <andrey at kopeyko.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/20140317/40ab5a2e/attachment.html>

From mdounin at mdounin.ru  Mon Mar 17 03:09:46 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 17 Mar 2014 07:09:46 +0400
Subject: x-accel-redirect + websocket
In-Reply-To: <CAAiTQPLhebLmD7uP_ksr-pWrKc3xSo0QH8UFg+LYx1MXSQ33EQ@mail.gmail.com>
References: <CAAiTQPLhebLmD7uP_ksr-pWrKc3xSo0QH8UFg+LYx1MXSQ33EQ@mail.gmail.com>
Message-ID: <20140317030945.GS34696@mdounin.ru>

Hello!

On Fri, Mar 14, 2014 at 08:37:14PM +0400, Serge Rasnikov wrote:

> Работает. Вопрос в том, имеет ли такая конструкция право на существование?
> 
> 
>     location ~ ^/sio(.*)$ {
>         internal;
> 
>         proxy_read_timeout 950s;
>         proxy_http_version 1.1;
>         proxy_set_header Upgrade $http_upgrade;
>         proxy_set_header Connection "upgrade";
>         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> 
>         proxy_pass http://127.0.0.1:25000/socket.io$1;
>     }
> 
>     location ~ ^/socket.io(.*) {
>         proxy_pass http://127.0.0.1:25001/sio$1;
>     }

Регулярные выражения в location'ах - выглядят лишёнными смысла.

Что до перенаправления WebSocket-соединений с помощью 
X-Accel-Redirect - то X-Accel-Redirect просто делает 
пренаправление запроса, и если вам оно зачем-то надо, то всё 
должно работать.

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


From nginx-forum at nginx.us  Mon Mar 17 03:43:36 2014
From: nginx-forum at nginx.us (zemtsov_nick)
Date: Sun, 16 Mar 2014 23:43:36 -0400
Subject: =?UTF-8?B?0L/RgNC+0LHQu9C10LzQsCDQt9Cw0LPRgNGD0LfQutC4INC60L7QvdGC0LXQvdGC?=
 =?UTF-8?B?0LA=?=
Message-ID: <97626a529f0c28fe15d2fe5da20484d5.NginxMailingListRussian@forum.nginx.org>

Добрый день! 

Стоит  nginx-1.4.5,1+apache22-itk-mpm-2.2.25 в связке фронтэнд бекэнд,
иногда(не систематически) часть контента не загружается, например должна
быть выгружена таблица 50 записей, а получаем только 20 при этом в хроме, в
инструментах разработчика, в консоли сыпется ошибка Failed to load resource:
net::ERR_CONNECTION_RESET. Когда этот же сайт работал на чистом apache, все
было норм, но из-за большого числа пользователей архитектура фронтэнд бекэнд
необходима! При этой ошибке не в логах apache, ни в nginx ничего нету.
Подскажите хотя бы где искать?

p.s. заранее спасибо!

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


From nginx-forum at nginx.us  Mon Mar 17 03:53:48 2014
From: nginx-forum at nginx.us (zemtsov_nick)
Date: Sun, 16 Mar 2014 23:53:48 -0400
Subject: =?UTF-8?B?UmU6INC/0YDQvtCx0LvQtdC80LAg0LfQsNCz0YDRg9C30LrQuCDQutC+0L3RgtC1?=
 =?UTF-8?B?0L3RgtCw?=
In-Reply-To: <97626a529f0c28fe15d2fe5da20484d5.NginxMailingListRussian@forum.nginx.org>
References: <97626a529f0c28fe15d2fe5da20484d5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <31cce16764b81698dcc9d7dc1a9c73b5.NginxMailingListRussian@forum.nginx.org>

забыл написать, при повторном открытии проблемной страницы или обновлении ее
же, все открывается нормально, хорошо и полно!

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


From nginx-forum at nginx.us  Mon Mar 17 06:19:03 2014
From: nginx-forum at nginx.us (unrecovered)
Date: Mon, 17 Mar 2014 02:19:03 -0400
Subject: =?UTF-8?B?UmU6IG5naW54LCBwaHAtZnBtINC4INC/0YDQvtCx0LvQtdC80Ysg0L/RgNC+0Lg=?=
 =?UTF-8?B?0LfQstC+0LTQuNGC0LXQu9GM0L3QvtGB0YLQuA==?=
In-Reply-To: <CAJDSoiAKRTU0JDVHzWKzt79zjFdei1pgsU8dAXZ0AY0r_6BqCw@mail.gmail.com>
References: <CAJDSoiAKRTU0JDVHzWKzt79zjFdei1pgsU8dAXZ0AY0r_6BqCw@mail.gmail.com>
Message-ID: <a691b2e208ebf4a07e80cff9bba905fa.NginxMailingListRussian@forum.nginx.org>

посмотрел по gtmetrix - дольше всего тупит сам index.php 
проблемы где-то на стыке? я когда отлаживал поставил форвард php на
локалхост на 9000 порт, попробую еще через unix-сокет

да, логирование повышу, посмотрю чего получится...

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


From nginx-forum at nginx.us  Mon Mar 17 18:07:26 2014
From: nginx-forum at nginx.us (grisha2217)
Date: Mon, 17 Mar 2014 14:07:26 -0400
Subject: =?UTF-8?B?0J7RgtC00LDQstCw0YLRjCA0NDQg0YLQtdC8LCDRgyDQutC+0LPQviDQsiDQt9Cw?=
 =?UTF-8?B?0L/RgNC+0YHQtSDRgdC+0LTQtdGA0LbQuNGC0YHRjyAiLy8i?=
Message-ID: <1c2611da4dbe5baddcbe8f7b230c54d5.NginxMailingListRussian@forum.nginx.org>

Заметил, что сайт подвергается ддос атакам, в логах такие запросы:
//?msg=SuckBith!!!&msg2=ITISDD0S!
//??????-?????
//?=E73994C7=BLAAAAAAAAAAAAA&gt;E3&lt;6=5789 


Как сделать универсальный bad_request для таких запросов.

Так?
$request ~* "//?*"


Я боюсь блокировать запросы, содержащие //, так как пользователь может
ошибиться и ввести случайно 2 слэша. Нужно, чтобы влетали только те
айпишники, которые посылают запрос // + минимум один символ

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


From igor at sysoev.ru  Mon Mar 17 18:14:11 2014
From: igor at sysoev.ru (Igor Sysoev)
Date: Mon, 17 Mar 2014 22:14:11 +0400
Subject: =?UTF-8?B?UmU6INCe0YLQtNCw0LLQsNGC0YwgNDQ0INGC0LXQvCwg0YMg0LrQvtCz0L4g0LIg?=
 =?UTF-8?B?0LfQsNC/0YDQvtGB0LUg0YHQvtC00LXRgNC20LjRgtGB0Y8gIi8vIg==?=
In-Reply-To: <1c2611da4dbe5baddcbe8f7b230c54d5.NginxMailingListRussian@forum.nginx.org>
References: <1c2611da4dbe5baddcbe8f7b230c54d5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <88C696C9-16E3-4121-995B-D33424DA64C7@sysoev.ru>

On Mar 17, 2014, at 22:07 , grisha2217 wrote:

> Заметил, что сайт подвергается ддос атакам, в логах такие запросы:
> //?msg=SuckBith!!!&msg2=ITISDD0S!
> //??????-?????
> //?=E73994C7=BLAAAAAAAAAAAAA&gt;E3&lt;6=5789 
> 
> 
> Как сделать универсальный bad_request для таких запросов.
> 
> Так?
> $request ~* "//?*"
> 
> 
> Я боюсь блокировать запросы, содержащие //, так как пользователь может
> ошибиться и ввести случайно 2 слэша. Нужно, чтобы влетали только те
> айпишники, которые посылают запрос // + минимум один символ

if ($request_uri ~ "^//\?") {
    return 444;
}


-- 
Igor Sysoev
http://nginx.com


From anatoly at sonru.com  Tue Mar 18 11:04:27 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Tue, 18 Mar 2014 11:04:27 +0000
Subject: =?UTF-8?B?SFRUUCDQv9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtSAxLjE=?=
Message-ID: <10E1EDD4-A951-4ECC-9057-731A76DAA127@sonru.com>

Добрый день,

По последнему blog post (http://nginx.com/blog/load-balancing-with-nginx-plus-part2/)
возник вопрос: какой эффект производит proxy_set_header Connection ?"?

Поясню вопрос на примере, имеется следующий конфиг для проксирования 
S3 запросов (опущены лишние детали):

location ~* ^/i/(.*) {
  proxy_http_version     1.1;
  proxy_set_header       Authorization '';
  proxy_hide_header      Set-Cookie;
  proxy_ignore_headers   "Set-Cookie?;
  ...
  proxy_pass             ...;
}

В данном случае версия http для проксирования установлена в 1.1,
то есть ожидаем повторное использование подключения,
что в данном случае изменит proxy_set_header Connection ?" ?

Анатолий

From mdounin at mdounin.ru  Tue Mar 18 11:08:45 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 18 Mar 2014 15:08:45 +0400
Subject: =?UTF-8?B?UmU6IEhUVFAg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgMS4x?=
In-Reply-To: <10E1EDD4-A951-4ECC-9057-731A76DAA127@sonru.com>
References: <10E1EDD4-A951-4ECC-9057-731A76DAA127@sonru.com>
Message-ID: <20140318110845.GH34696@mdounin.ru>

Hello!

On Tue, Mar 18, 2014 at 11:04:27AM +0000, Anatoly Mikhailov wrote:

> Добрый день,
> 
> По последнему blog post (http://nginx.com/blog/load-balancing-with-nginx-plus-part2/)
> возник вопрос: какой эффект производит proxy_set_header Connection ?"?
> 
> Поясню вопрос на примере, имеется следующий конфиг для проксирования 
> S3 запросов (опущены лишние детали):
> 
> location ~* ^/i/(.*) {
>   proxy_http_version     1.1;
>   proxy_set_header       Authorization '';
>   proxy_hide_header      Set-Cookie;
>   proxy_ignore_headers   "Set-Cookie?;
>   ...
>   proxy_pass             ...;
> }
> 
> В данном случае версия http для проксирования установлена в 1.1,
> то есть ожидаем повторное использование подключения,
> что в данном случае изменит proxy_set_header Connection ?" ?

По умолчанию добавляется "Connection: close"[1], и использование  
"proxy_set_header Connection ''" нужно, чтобы этого избежать.

http://nginx.org/r/proxy_set_header/ru

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


From anatoly at sonru.com  Tue Mar 18 12:28:08 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Tue, 18 Mar 2014 12:28:08 +0000
Subject: =?UTF-8?B?UmU6IEhUVFAg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgMS4x?=
In-Reply-To: <20140318110845.GH34696@mdounin.ru>
References: <10E1EDD4-A951-4ECC-9057-731A76DAA127@sonru.com>
 <20140318110845.GH34696@mdounin.ru>
Message-ID: <9BEB08CD-2200-441A-83E3-A21ACDF1033F@sonru.com>


On 18 Mar 2014, at 11:08, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
> 
> On Tue, Mar 18, 2014 at 11:04:27AM +0000, Anatoly Mikhailov wrote:
> 
>> Добрый день,
>> 
>> По последнему blog post (http://nginx.com/blog/load-balancing-with-nginx-plus-part2/)
>> возник вопрос: какой эффект производит proxy_set_header Connection ?"?
>> 
>> Поясню вопрос на примере, имеется следующий конфиг для проксирования 
>> S3 запросов (опущены лишние детали):
>> 
>> location ~* ^/i/(.*) {
>>  proxy_http_version     1.1;
>>  proxy_set_header       Authorization '';
>>  proxy_hide_header      Set-Cookie;
>>  proxy_ignore_headers   "Set-Cookie?;
>>  ...
>>  proxy_pass             ...;
>> }
>> 
>> В данном случае версия http для проксирования установлена в 1.1,
>> то есть ожидаем повторное использование подключения,
>> что в данном случае изменит proxy_set_header Connection ?" ?
> 
> По умолчанию добавляется "Connection: close"[1], и использование  
> "proxy_set_header Connection ''" нужно, чтобы этого избежать.
> 
> http://nginx.org/r/proxy_set_header/ru

Максим, понятно, HTTP подключение закрывается после каждого запроса по умолчанию,
но достаточно ли Connection ?? для реиспользования HTTP 1.1 подключения? Обязательно ли
явно добавлять блок upstream и указывать директиву keepalive?

> 
> -- 
> 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/20140318/1c9f08d6/attachment.html>

From mdounin at mdounin.ru  Tue Mar 18 13:51:18 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 18 Mar 2014 17:51:18 +0400
Subject: =?UTF-8?B?UmU6IEhUVFAg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgMS4x?=
In-Reply-To: <9BEB08CD-2200-441A-83E3-A21ACDF1033F@sonru.com>
References: <10E1EDD4-A951-4ECC-9057-731A76DAA127@sonru.com>
 <20140318110845.GH34696@mdounin.ru>
 <9BEB08CD-2200-441A-83E3-A21ACDF1033F@sonru.com>
Message-ID: <20140318135118.GR34696@mdounin.ru>

Hello!

On Tue, Mar 18, 2014 at 12:28:08PM +0000, Anatoly Mikhailov wrote:

> 
> On 18 Mar 2014, at 11:08, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > Hello!
> > 
> > On Tue, Mar 18, 2014 at 11:04:27AM +0000, Anatoly Mikhailov wrote:
> > 
> >> Добрый день,
> >> 
> >> По последнему blog post (http://nginx.com/blog/load-balancing-with-nginx-plus-part2/)
> >> возник вопрос: какой эффект производит proxy_set_header Connection ?"?
> >> 
> >> Поясню вопрос на примере, имеется следующий конфиг для проксирования 
> >> S3 запросов (опущены лишние детали):
> >> 
> >> location ~* ^/i/(.*) {
> >>  proxy_http_version     1.1;
> >>  proxy_set_header       Authorization '';
> >>  proxy_hide_header      Set-Cookie;
> >>  proxy_ignore_headers   "Set-Cookie?;
> >>  ...
> >>  proxy_pass             ...;
> >> }
> >> 
> >> В данном случае версия http для проксирования установлена в 1.1,
> >> то есть ожидаем повторное использование подключения,
> >> что в данном случае изменит proxy_set_header Connection ?" ?
> > 
> > По умолчанию добавляется "Connection: close"[1], и использование  
> > "proxy_set_header Connection ''" нужно, чтобы этого избежать.
> > 
> > http://nginx.org/r/proxy_set_header/ru
> 
> Максим, понятно, HTTP подключение закрывается после каждого запроса по умолчанию,
> но достаточно ли Connection ?? для реиспользования HTTP 1.1 подключения? Обязательно ли
> явно добавлять блок upstream и указывать директиву keepalive?

Нужно и то, и другое.  Из заголовков запроса нужно убрать 
"Connection: close", чтобы бекенд не закрывал соединение, а сам 
nginx - проинструктировать соединения сохранять и использовать 
повторно.

Maxim Dounin
http://nginx.org/


From anatoly at sonru.com  Tue Mar 18 15:08:31 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Tue, 18 Mar 2014 15:08:31 +0000
Subject: =?UTF-8?B?UmU6IEhUVFAg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgMS4x?=
In-Reply-To: <20140318135118.GR34696@mdounin.ru>
References: <10E1EDD4-A951-4ECC-9057-731A76DAA127@sonru.com>
 <20140318110845.GH34696@mdounin.ru>
 <9BEB08CD-2200-441A-83E3-A21ACDF1033F@sonru.com>
 <20140318135118.GR34696@mdounin.ru>
Message-ID: <48F97DED-99ED-4921-82E0-EF8168B6BE58@sonru.com>


On 18 Mar 2014, at 13:51, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
> 
> On Tue, Mar 18, 2014 at 12:28:08PM +0000, Anatoly Mikhailov wrote:
> 
>> 
>> On 18 Mar 2014, at 11:08, Maxim Dounin <mdounin at mdounin.ru> wrote:
>> 
>>> Hello!
>>> 
>>> On Tue, Mar 18, 2014 at 11:04:27AM +0000, Anatoly Mikhailov wrote:
>>> 
>>>> Добрый день,
>>>> 
>>>> По последнему blog post (http://nginx.com/blog/load-balancing-with-nginx-plus-part2/)
>>>> возник вопрос: какой эффект производит proxy_set_header Connection ?"?
>>>> 
>>>> Поясню вопрос на примере, имеется следующий конфиг для проксирования 
>>>> S3 запросов (опущены лишние детали):
>>>> 
>>>> location ~* ^/i/(.*) {
>>>> proxy_http_version     1.1;
>>>> proxy_set_header       Authorization '';
>>>> proxy_hide_header      Set-Cookie;
>>>> proxy_ignore_headers   "Set-Cookie?;
>>>> ...
>>>> proxy_pass             ...;
>>>> }
>>>> 
>>>> В данном случае версия http для проксирования установлена в 1.1,
>>>> то есть ожидаем повторное использование подключения,
>>>> что в данном случае изменит proxy_set_header Connection ?" ?
>>> 
>>> По умолчанию добавляется "Connection: close"[1], и использование  
>>> "proxy_set_header Connection ''" нужно, чтобы этого избежать.
>>> 
>>> http://nginx.org/r/proxy_set_header/ru
>> 
>> Максим, понятно, HTTP подключение закрывается после каждого запроса по умолчанию,
>> но достаточно ли Connection ?? для реиспользования HTTP 1.1 подключения? Обязательно ли
>> явно добавлять блок upstream и указывать директиву keepalive?
> 
> Нужно и то, и другое.  Из заголовков запроса нужно убрать 
> "Connection: close", чтобы бекенд не закрывал соединение, а сам 
> nginx - проинструктировать соединения сохранять и использовать 
> повторно.

Понял, спасибо, Максим! Контекст директивы keepalive для бэкэнда только upstream,
если смотреть документацию, но может есть какой-то элегантный способ передать
keepalive в proxy_pass сразу, без объявления блока upstream?

> 
> 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/20140318/5160ac28/attachment-0001.html>

From mdounin at mdounin.ru  Tue Mar 18 15:10:47 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 18 Mar 2014 19:10:47 +0400
Subject: =?UTF-8?B?UmU6IEhUVFAg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgMS4x?=
In-Reply-To: <48F97DED-99ED-4921-82E0-EF8168B6BE58@sonru.com>
References: <10E1EDD4-A951-4ECC-9057-731A76DAA127@sonru.com>
 <20140318110845.GH34696@mdounin.ru>
 <9BEB08CD-2200-441A-83E3-A21ACDF1033F@sonru.com>
 <20140318135118.GR34696@mdounin.ru>
 <48F97DED-99ED-4921-82E0-EF8168B6BE58@sonru.com>
Message-ID: <20140318151047.GT34696@mdounin.ru>

Hello!

On Tue, Mar 18, 2014 at 03:08:31PM +0000, Anatoly Mikhailov wrote:

> 
> On 18 Mar 2014, at 13:51, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > Hello!
> > 
> > On Tue, Mar 18, 2014 at 12:28:08PM +0000, Anatoly Mikhailov wrote:
> > 
> >> 
> >> On 18 Mar 2014, at 11:08, Maxim Dounin <mdounin at mdounin.ru> wrote:
> >> 
> >>> Hello!
> >>> 
> >>> On Tue, Mar 18, 2014 at 11:04:27AM +0000, Anatoly Mikhailov wrote:
> >>> 
> >>>> Добрый день,
> >>>> 
> >>>> По последнему blog post (http://nginx.com/blog/load-balancing-with-nginx-plus-part2/)
> >>>> возник вопрос: какой эффект производит proxy_set_header Connection ?"?
> >>>> 
> >>>> Поясню вопрос на примере, имеется следующий конфиг для проксирования 
> >>>> S3 запросов (опущены лишние детали):
> >>>> 
> >>>> location ~* ^/i/(.*) {
> >>>> proxy_http_version     1.1;
> >>>> proxy_set_header       Authorization '';
> >>>> proxy_hide_header      Set-Cookie;
> >>>> proxy_ignore_headers   "Set-Cookie?;
> >>>> ...
> >>>> proxy_pass             ...;
> >>>> }
> >>>> 
> >>>> В данном случае версия http для проксирования установлена в 1.1,
> >>>> то есть ожидаем повторное использование подключения,
> >>>> что в данном случае изменит proxy_set_header Connection ?" ?
> >>> 
> >>> По умолчанию добавляется "Connection: close"[1], и использование  
> >>> "proxy_set_header Connection ''" нужно, чтобы этого избежать.
> >>> 
> >>> http://nginx.org/r/proxy_set_header/ru
> >> 
> >> Максим, понятно, HTTP подключение закрывается после каждого запроса по умолчанию,
> >> но достаточно ли Connection ?? для реиспользования HTTP 1.1 подключения? Обязательно ли
> >> явно добавлять блок upstream и указывать директиву keepalive?
> > 
> > Нужно и то, и другое.  Из заголовков запроса нужно убрать 
> > "Connection: close", чтобы бекенд не закрывал соединение, а сам 
> > nginx - проинструктировать соединения сохранять и использовать 
> > повторно.
> 
> Понял, спасибо, Максим! Контекст директивы keepalive для бэкэнда только upstream,
> если смотреть документацию, но может есть какой-то элегантный способ передать
> keepalive в proxy_pass сразу, без объявления блока upstream?

Нет.

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


From mdounin at mdounin.ru  Tue Mar 18 16:44:45 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 18 Mar 2014 20:44:45 +0400
Subject: nginx-1.5.12
Message-ID: <20140318164445.GB34696@mdounin.ru>

Изменения в nginx 1.5.12                                          18.03.2014

    *) Безопасность: при обработке специально созданного запроса модулем
       ngx_http_spdy_module могло происходить переполнение буфера в рабочем
       процессе, что потенциально могло приводить к выполнению произвольного
       кода (CVE-2014-0133).
       Спасибо Lucas Molas из Programa STIC, Fundaci?n Dr. Manuel Sadosky,
       Buenos Aires, Argentina.

    *) Добавление: параметр proxy_protocol в директивах listen и
       real_ip_header, переменная $proxy_protocol_addr.

    *) Исправление: в директиве fastcgi_next_upstream.
       Спасибо Lucas Molas.


-- 
Maxim Dounin
http://nginx.org/en/donation.html


From mdounin at mdounin.ru  Tue Mar 18 16:45:07 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 18 Mar 2014 20:45:07 +0400
Subject: nginx-1.4.7
Message-ID: <20140318164507.GF34696@mdounin.ru>

Изменения в nginx 1.4.7                                           18.03.2014

    *) Безопасность: при обработке специально созданного запроса модулем
       ngx_http_spdy_module могло происходить переполнение буфера в рабочем
       процессе, что потенциально могло приводить к выполнению произвольного
       кода (CVE-2014-0133).
       Спасибо Lucas Molas из Programa STIC, Fundaci?n Dr. Manuel Sadosky,
       Buenos Aires, Argentina.

    *) Исправление: в директиве fastcgi_next_upstream.
       Спасибо Lucas Molas.


-- 
Maxim Dounin
http://nginx.org/en/donation.html


From mdounin at mdounin.ru  Tue Mar 18 16:45:51 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 18 Mar 2014 20:45:51 +0400
Subject: nginx security advisory (CVE-2014-0133)
Message-ID: <20140318164551.GJ34696@mdounin.ru>

Hello!

Была обнаружена ошибка в экспериментальной реализации SPDY в nginx,
из-за которой с помощью специально созданного запроса в некоторых
случаях было возможно вызывать переполнение буфера в рабочем процессе,
что потенциально могло приводить к выполнению произвольного кода
(CVE-2014-0133).

Проблеме подвержен nginx 1.3.15 - 1.5.11, если он собран с модулем
ngx_http_spdy_module (по умолчанию не собирается), без параметра
--with-debug, и при этом в конфигурационном файле используется параметр
spdy директивы listen.

Проблема исправлена в nginx 1.5.12, 1.4.7.

Патч, исправляющий проблему, доступен тут:

http://nginx.org/download/patch.2014.spdy2.txt

Спасибо Lucas Molas из Programa STIC, Fundaci?n Dr. Manuel Sadosky,
Buenos Aires, Argentina.


-- 
Maxim Dounin
http://nginx.org/en/donation.html


From anatoly at sonru.com  Wed Mar 19 10:42:26 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Wed, 19 Mar 2014 10:42:26 +0000
Subject: =?UTF-8?B?UmU6IEhUVFAg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgMS4x?=
In-Reply-To: <20140318151047.GT34696@mdounin.ru>
References: <10E1EDD4-A951-4ECC-9057-731A76DAA127@sonru.com>
 <20140318110845.GH34696@mdounin.ru>
 <9BEB08CD-2200-441A-83E3-A21ACDF1033F@sonru.com>
 <20140318135118.GR34696@mdounin.ru>
 <48F97DED-99ED-4921-82E0-EF8168B6BE58@sonru.com>
 <20140318151047.GT34696@mdounin.ru>
Message-ID: <B5BDEAAB-D3EC-4C88-AFA5-B46AE826B9B9@sonru.com>


On 18 Mar 2014, at 15:10, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
> 
> On Tue, Mar 18, 2014 at 03:08:31PM +0000, Anatoly Mikhailov wrote:
> 
>> 
>> On 18 Mar 2014, at 13:51, Maxim Dounin <mdounin at mdounin.ru> wrote:
>> 
>>> Hello!
>>> 
>>> On Tue, Mar 18, 2014 at 12:28:08PM +0000, Anatoly Mikhailov wrote:
>>> 
>>>> 
>>>> On 18 Mar 2014, at 11:08, Maxim Dounin <mdounin at mdounin.ru> wrote:
>>>> 
>>>>> Hello!
>>>>> 
>>>>> On Tue, Mar 18, 2014 at 11:04:27AM +0000, Anatoly Mikhailov wrote:
>>>>> 
>>>>>> Добрый день,
>>>>>> 
>>>>>> По последнему blog post (http://nginx.com/blog/load-balancing-with-nginx-plus-part2/)
>>>>>> возник вопрос: какой эффект производит proxy_set_header Connection ?"?
>>>>>> 
>>>>>> Поясню вопрос на примере, имеется следующий конфиг для проксирования 
>>>>>> S3 запросов (опущены лишние детали):
>>>>>> 
>>>>>> location ~* ^/i/(.*) {
>>>>>> proxy_http_version     1.1;
>>>>>> proxy_set_header       Authorization '';
>>>>>> proxy_hide_header      Set-Cookie;
>>>>>> proxy_ignore_headers   "Set-Cookie?;
>>>>>> ...
>>>>>> proxy_pass             ...;
>>>>>> }
>>>>>> 
>>>>>> В данном случае версия http для проксирования установлена в 1.1,
>>>>>> то есть ожидаем повторное использование подключения,
>>>>>> что в данном случае изменит proxy_set_header Connection ?" ?
>>>>> 
>>>>> По умолчанию добавляется "Connection: close"[1], и использование  
>>>>> "proxy_set_header Connection ''" нужно, чтобы этого избежать.
>>>>> 
>>>>> http://nginx.org/r/proxy_set_header/ru
>>>> 
>>>> Максим, понятно, HTTP подключение закрывается после каждого запроса по умолчанию,
>>>> но достаточно ли Connection ?? для реиспользования HTTP 1.1 подключения? Обязательно ли
>>>> явно добавлять блок upstream и указывать директиву keepalive?
>>> 
>>> Нужно и то, и другое.  Из заголовков запроса нужно убрать 
>>> "Connection: close", чтобы бекенд не закрывал соединение, а сам 
>>> nginx - проинструктировать соединения сохранять и использовать 
>>> повторно.
>> 
>> Понял, спасибо, Максим! Контекст директивы keepalive для бэкэнда только upstream,
>> если смотреть документацию, но может есть какой-то элегантный способ передать
>> keepalive в proxy_pass сразу, без объявления блока upstream?
> 
> Нет.

супер, переписал конфигурацию для проксирования S3 на upstream, получилось очень классно,
вопрос - почему бы не сделать keepalive для бэкэнда по умолчанию?

> 
> -- 
> 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/20140319/a533aa2d/attachment.html>

From anatoly at sonru.com  Wed Mar 19 11:15:11 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Wed, 19 Mar 2014 11:15:11 +0000
Subject: =?UTF-8?B?UmU6IEhUVFAg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgMS4x?=
In-Reply-To: <B5BDEAAB-D3EC-4C88-AFA5-B46AE826B9B9@sonru.com>
References: <10E1EDD4-A951-4ECC-9057-731A76DAA127@sonru.com>
 <20140318110845.GH34696@mdounin.ru>
 <9BEB08CD-2200-441A-83E3-A21ACDF1033F@sonru.com>
 <20140318135118.GR34696@mdounin.ru>
 <48F97DED-99ED-4921-82E0-EF8168B6BE58@sonru.com>
 <20140318151047.GT34696@mdounin.ru>
 <B5BDEAAB-D3EC-4C88-AFA5-B46AE826B9B9@sonru.com>
Message-ID: <E6186F2B-F928-4113-B9C0-A7848E7B2125@sonru.com>


On 19 Mar 2014, at 10:42, Anatoly Mikhailov <anatoly at sonru.com> wrote:

> 
> On 18 Mar 2014, at 15:10, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
>> Hello!
>> 
>> On Tue, Mar 18, 2014 at 03:08:31PM +0000, Anatoly Mikhailov wrote:
>> 
>>> 
>>> On 18 Mar 2014, at 13:51, Maxim Dounin <mdounin at mdounin.ru> wrote:
>>> 
>>>> Hello!
>>>> 
>>>> On Tue, Mar 18, 2014 at 12:28:08PM +0000, Anatoly Mikhailov wrote:
>>>> 
>>>>> 
>>>>> On 18 Mar 2014, at 11:08, Maxim Dounin <mdounin at mdounin.ru> wrote:
>>>>> 
>>>>>> Hello!
>>>>>> 
>>>>>> On Tue, Mar 18, 2014 at 11:04:27AM +0000, Anatoly Mikhailov wrote:
>>>>>> 
>>>>>>> Добрый день,
>>>>>>> 
>>>>>>> По последнему blog post (http://nginx.com/blog/load-balancing-with-nginx-plus-part2/)
>>>>>>> возник вопрос: какой эффект производит proxy_set_header Connection ?"?
>>>>>>> 
>>>>>>> Поясню вопрос на примере, имеется следующий конфиг для проксирования 
>>>>>>> S3 запросов (опущены лишние детали):
>>>>>>> 
>>>>>>> location ~* ^/i/(.*) {
>>>>>>> proxy_http_version     1.1;
>>>>>>> proxy_set_header       Authorization '';
>>>>>>> proxy_hide_header      Set-Cookie;
>>>>>>> proxy_ignore_headers   "Set-Cookie?;
>>>>>>> ...
>>>>>>> proxy_pass             ...;
>>>>>>> }
>>>>>>> 
>>>>>>> В данном случае версия http для проксирования установлена в 1.1,
>>>>>>> то есть ожидаем повторное использование подключения,
>>>>>>> что в данном случае изменит proxy_set_header Connection ?" ?
>>>>>> 
>>>>>> По умолчанию добавляется "Connection: close"[1], и использование  
>>>>>> "proxy_set_header Connection ''" нужно, чтобы этого избежать.
>>>>>> 
>>>>>> http://nginx.org/r/proxy_set_header/ru
>>>>> 
>>>>> Максим, понятно, HTTP подключение закрывается после каждого запроса по умолчанию,
>>>>> но достаточно ли Connection ?? для реиспользования HTTP 1.1 подключения? Обязательно ли
>>>>> явно добавлять блок upstream и указывать директиву keepalive?
>>>> 
>>>> Нужно и то, и другое.  Из заголовков запроса нужно убрать 
>>>> "Connection: close", чтобы бекенд не закрывал соединение, а сам 
>>>> nginx - проинструктировать соединения сохранять и использовать 
>>>> повторно.
>>> 
>>> Понял, спасибо, Максим! Контекст директивы keepalive для бэкэнда только upstream,
>>> если смотреть документацию, но может есть какой-то элегантный способ передать
>>> keepalive в proxy_pass сразу, без объявления блока upstream?
>> 
>> Нет.
> 
> супер, переписал конфигурацию для проксирования S3 на upstream, получилось очень классно,
> вопрос - почему бы не сделать keepalive для бэкэнда по умолчанию?
> 

набросал тут конфиг для проксирования соединений к backend и S3 с кэшированием и keep-alive:
https://gist.github.com/mikhailov/9639593

Максим, что тут можно поправить?


>> 
>> -- 
>> Maxim Dounin
>> http://nginx.org/
>> 
>> _______________________________________________
>> 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/20140319/612b76ed/attachment-0001.html>

From mdounin at mdounin.ru  Wed Mar 19 13:37:00 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 19 Mar 2014 17:37:00 +0400
Subject: =?UTF-8?B?UmU6IEhUVFAg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgMS4x?=
In-Reply-To: <B5BDEAAB-D3EC-4C88-AFA5-B46AE826B9B9@sonru.com>
References: <10E1EDD4-A951-4ECC-9057-731A76DAA127@sonru.com>
 <20140318110845.GH34696@mdounin.ru>
 <9BEB08CD-2200-441A-83E3-A21ACDF1033F@sonru.com>
 <20140318135118.GR34696@mdounin.ru>
 <48F97DED-99ED-4921-82E0-EF8168B6BE58@sonru.com>
 <20140318151047.GT34696@mdounin.ru>
 <B5BDEAAB-D3EC-4C88-AFA5-B46AE826B9B9@sonru.com>
Message-ID: <20140319133700.GW34696@mdounin.ru>

Hello!

On Wed, Mar 19, 2014 at 10:42:26AM +0000, Anatoly Mikhailov wrote:

> 
> On 18 Mar 2014, at 15:10, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > Hello!
> > 
> > On Tue, Mar 18, 2014 at 03:08:31PM +0000, Anatoly Mikhailov wrote:
> > 
> >> 
> >> On 18 Mar 2014, at 13:51, Maxim Dounin <mdounin at mdounin.ru> wrote:
> >> 
> >>> Hello!
> >>> 
> >>> On Tue, Mar 18, 2014 at 12:28:08PM +0000, Anatoly Mikhailov wrote:
> >>> 
> >>>> 
> >>>> On 18 Mar 2014, at 11:08, Maxim Dounin <mdounin at mdounin.ru> wrote:
> >>>> 
> >>>>> Hello!
> >>>>> 
> >>>>> On Tue, Mar 18, 2014 at 11:04:27AM +0000, Anatoly Mikhailov wrote:
> >>>>> 
> >>>>>> Добрый день,
> >>>>>> 
> >>>>>> По последнему blog post (http://nginx.com/blog/load-balancing-with-nginx-plus-part2/)
> >>>>>> возник вопрос: какой эффект производит proxy_set_header Connection ?"?
> >>>>>> 
> >>>>>> Поясню вопрос на примере, имеется следующий конфиг для проксирования 
> >>>>>> S3 запросов (опущены лишние детали):
> >>>>>> 
> >>>>>> location ~* ^/i/(.*) {
> >>>>>> proxy_http_version     1.1;
> >>>>>> proxy_set_header       Authorization '';
> >>>>>> proxy_hide_header      Set-Cookie;
> >>>>>> proxy_ignore_headers   "Set-Cookie?;
> >>>>>> ...
> >>>>>> proxy_pass             ...;
> >>>>>> }
> >>>>>> 
> >>>>>> В данном случае версия http для проксирования установлена в 1.1,
> >>>>>> то есть ожидаем повторное использование подключения,
> >>>>>> что в данном случае изменит proxy_set_header Connection ?" ?
> >>>>> 
> >>>>> По умолчанию добавляется "Connection: close"[1], и использование  
> >>>>> "proxy_set_header Connection ''" нужно, чтобы этого избежать.
> >>>>> 
> >>>>> http://nginx.org/r/proxy_set_header/ru
> >>>> 
> >>>> Максим, понятно, HTTP подключение закрывается после каждого запроса по умолчанию,
> >>>> но достаточно ли Connection ?? для реиспользования HTTP 1.1 подключения? Обязательно ли
> >>>> явно добавлять блок upstream и указывать директиву keepalive?
> >>> 
> >>> Нужно и то, и другое.  Из заголовков запроса нужно убрать 
> >>> "Connection: close", чтобы бекенд не закрывал соединение, а сам 
> >>> nginx - проинструктировать соединения сохранять и использовать 
> >>> повторно.
> >> 
> >> Понял, спасибо, Максим! Контекст директивы keepalive для бэкэнда только upstream,
> >> если смотреть документацию, но может есть какой-то элегантный способ передать
> >> keepalive в proxy_pass сразу, без объявления блока upstream?
> > 
> > Нет.
> 
> супер, переписал конфигурацию для проксирования S3 на upstream, получилось очень классно,
> вопрос - почему бы не сделать keepalive для бэкэнда по умолчанию?

Использование постоянных соединений полезно в основном в тех 
случаях, когда до бекенда - далеко.  В условиях близких бекендов 
оно обычно не нужно.  Наоборот, в некоторых ситуациях постоянные 
соединения могут повредить - например, если бекенд сильно ограничен по 
количеству соединений, которые он может обрабатывать.  В 
документации даже специально добавлено замечание про это, т.к. 
люди периодически наступают, cм. http://nginx.org/r/keepalive/ru.

Так что я к идее сделать keepalive к бекендам поведением по 
умолчанию - отношусь скептически.

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


From anatoly at sonru.com  Thu Mar 20 12:03:23 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Thu, 20 Mar 2014 12:03:23 +0000
Subject: =?UTF-8?B?UmU6IEhUVFAg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgMS4x?=
In-Reply-To: <20140319133700.GW34696@mdounin.ru>
References: <10E1EDD4-A951-4ECC-9057-731A76DAA127@sonru.com>
 <20140318110845.GH34696@mdounin.ru>
 <9BEB08CD-2200-441A-83E3-A21ACDF1033F@sonru.com>
 <20140318135118.GR34696@mdounin.ru>
 <48F97DED-99ED-4921-82E0-EF8168B6BE58@sonru.com>
 <20140318151047.GT34696@mdounin.ru>
 <B5BDEAAB-D3EC-4C88-AFA5-B46AE826B9B9@sonru.com>
 <20140319133700.GW34696@mdounin.ru>
Message-ID: <900F8910-2655-4DAD-B08E-00CDFD080637@sonru.com>


On 19 Mar 2014, at 13:37, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
> 
> On Wed, Mar 19, 2014 at 10:42:26AM +0000, Anatoly Mikhailov wrote:
> 
>> 
>> On 18 Mar 2014, at 15:10, Maxim Dounin <mdounin at mdounin.ru> wrote:
>> 
>>> Hello!
>>> 
>>> On Tue, Mar 18, 2014 at 03:08:31PM +0000, Anatoly Mikhailov wrote:
>>> 
>>>> 
>>>> On 18 Mar 2014, at 13:51, Maxim Dounin <mdounin at mdounin.ru> wrote:
>>>> 
>>>>> Hello!
>>>>> 
>>>>> On Tue, Mar 18, 2014 at 12:28:08PM +0000, Anatoly Mikhailov wrote:
>>>>> 
>>>>>> 
>>>>>> On 18 Mar 2014, at 11:08, Maxim Dounin <mdounin at mdounin.ru> wrote:
>>>>>> 
>>>>>>> Hello!
>>>>>>> 
>>>>>>> On Tue, Mar 18, 2014 at 11:04:27AM +0000, Anatoly Mikhailov wrote:
>>>>>>> 
>>>>>>>> Добрый день,
>>>>>>>> 
>>>>>>>> По последнему blog post (http://nginx.com/blog/load-balancing-with-nginx-plus-part2/)
>>>>>>>> возник вопрос: какой эффект производит proxy_set_header Connection ?"?
>>>>>>>> 
>>>>>>>> Поясню вопрос на примере, имеется следующий конфиг для проксирования 
>>>>>>>> S3 запросов (опущены лишние детали):
>>>>>>>> 
>>>>>>>> location ~* ^/i/(.*) {
>>>>>>>> proxy_http_version     1.1;
>>>>>>>> proxy_set_header       Authorization '';
>>>>>>>> proxy_hide_header      Set-Cookie;
>>>>>>>> proxy_ignore_headers   "Set-Cookie?;
>>>>>>>> ...
>>>>>>>> proxy_pass             ...;
>>>>>>>> }
>>>>>>>> 
>>>>>>>> В данном случае версия http для проксирования установлена в 1.1,
>>>>>>>> то есть ожидаем повторное использование подключения,
>>>>>>>> что в данном случае изменит proxy_set_header Connection ?" ?
>>>>>>> 
>>>>>>> По умолчанию добавляется "Connection: close"[1], и использование  
>>>>>>> "proxy_set_header Connection ''" нужно, чтобы этого избежать.
>>>>>>> 
>>>>>>> http://nginx.org/r/proxy_set_header/ru
>>>>>> 
>>>>>> Максим, понятно, HTTP подключение закрывается после каждого запроса по умолчанию,
>>>>>> но достаточно ли Connection ?? для реиспользования HTTP 1.1 подключения? Обязательно ли
>>>>>> явно добавлять блок upstream и указывать директиву keepalive?
>>>>> 
>>>>> Нужно и то, и другое.  Из заголовков запроса нужно убрать 
>>>>> "Connection: close", чтобы бекенд не закрывал соединение, а сам 
>>>>> nginx - проинструктировать соединения сохранять и использовать 
>>>>> повторно.
>>>> 
>>>> Понял, спасибо, Максим! Контекст директивы keepalive для бэкэнда только upstream,
>>>> если смотреть документацию, но может есть какой-то элегантный способ передать
>>>> keepalive в proxy_pass сразу, без объявления блока upstream?
>>> 
>>> Нет.
>> 
>> супер, переписал конфигурацию для проксирования S3 на upstream, получилось очень классно,
>> вопрос - почему бы не сделать keepalive для бэкэнда по умолчанию?
> 
> Использование постоянных соединений полезно в основном в тех 
> случаях, когда до бекенда - далеко.  В условиях близких бекендов 
> оно обычно не нужно.  Наоборот, в некоторых ситуациях постоянные 
> соединения могут повредить - например, если бекенд сильно ограничен по 
> количеству соединений, которые он может обрабатывать.  В 
> документации даже специально добавлено замечание про это, т.к. 
> люди периодически наступают, cм. http://nginx.org/r/keepalive/ru.
> 
> Так что я к идее сделать keepalive к бекендам поведением по 
> умолчанию - отношусь скептически.
> 

Я правильно понимаю, keepalive (в контексте upstream) задает количество
TCP соединений, которые не будут закрываться, даже при отсутствии будущих запросов?
Если да, то какой таймаут, такой же как для клиентских TCP подключений, указанных
через директиву keepalive_timeout?

Вопрос второй - если известно, что бэкэнд держит, скажем, 50 соединений, 
то keepalive 50 поможет нам повторно их использовать в будущем, без повторных syn+ack?

> -- 
> 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/20140320/d24e43d0/attachment.html>

From anatoly at sonru.com  Thu Mar 20 12:16:07 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Thu, 20 Mar 2014 12:16:07 +0000
Subject: =?UTF-8?B?UmU6INCg0LDRgdC/0YDQtdC00LXQu9GR0L3QvdC+0LUg0YXRgNCw0L3QtdC90Lg=?=
 =?UTF-8?B?0LUg0YTQsNC50LvQvtCyIFtPRkZUT1BJQ10=?=
In-Reply-To: <CALUn_U4JN65cQ5T=vnmQdFZbiNX_U6JK76Lw18ROx+pnC280jA@mail.gmail.com>
References: <6610675732.20140216233310@softsearch.ru>
 <CAHZbs3PTr9Z2UghfLaju5YnoCbhaYOj5W2K8sfpS4LHcd1hkvg@mail.gmail.com>
 <CAOrB69MORx61F21H9TTCrHxqWktquhZ+wjVbg4j8Vf1VY6YGuA@mail.gmail.com>
 <CALUn_U4JN65cQ5T=vnmQdFZbiNX_U6JK76Lw18ROx+pnC280jA@mail.gmail.com>
Message-ID: <EF81DE53-4283-46AF-A21D-E81221B3187E@sonru.com>

Если вы на AWS, то удобно использовать корзины S3 с кэширующим прокси,
например, наш конфиг выглядит так: https://gist.github.com/mikhailov/9639593

S3 корзины практически безразмерны + можно выбрать георасположение,
с кэширующим Nginx это вполне сносное решение.

Анатолий

On 18 Feb 2014, at 06:33, Danila Shtan <danila at shtan.ru> wrote:

> Мы положили в mongodb, а перед раздатчиками поставили кэширующие прокси на nginx.
> 
> Д.
> 
> понедельник, 17 февраля 2014 г. пользователь Andrey Velikoredchanin написал:
> Когда у меня была такая задача, я исходил из принципа что самое надежное решение - самое простое. Я использовал много серверов с NFS, запись в базе того, на каком сервере лежит файл и X-Accel-Redirect при его выдаче.
> 
> 
> 17 февраля 2014 г., 1:41 пользователь Alex Yakovenko <aleksey.yakovenko at gmail.com> написал:
> https://github.com/mogilefs/
> 
> 16 февраля 2014 г., 21:33 пользователь Михаил Монашёв
> <postmaster at softsearch.ru> написал:
> > Здравствуйте.
> >
> > Расскажите,  пожалуйста,  как Вы храните много разных файлов, если они
> > на  один  сервер  не  влазят?  Есть  ли  специальные  инструменты  для
> > распространения  файлов  по  серверам,  поддержания нужного количества
> > реплик, обхода всех файлов или файлов с каким-то признаком и т.п.
> >
> > --
> > С уважением,
> >  Михаил                          mailto:postmaster at softsearch.ru
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> 
> 
> --
> WBR
> Alex Yakovenko
> _______________________________________________
> 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/20140320/b76d94cd/attachment-0001.html>

From ksyblast at gmail.com  Thu Mar 20 12:17:57 2014
From: ksyblast at gmail.com (=?KOI8-R?B?69PFzsnRIODS2MXXzsEg4szB3dXL?=)
Date: Thu, 20 Mar 2014 15:17:57 +0300
Subject: =?UTF-8?B?0L3QuNC30LrQsNGPINGB0LrQvtGA0L7RgdGC0Ywg0LIg0YHQstGP0LfQutC1IG5n?=
 =?UTF-8?B?aW54K2FwYWNoZQ==?=
Message-ID: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>

Добрый день.

Помогите пожалуйста разобраться, в каком месте проблема. Имеется проект по
отложенному просмотру телепередач. Видео записывается в файлы по одному
часу каждый. При просмотре передач видео собирается из нескольких файлов
или же файл проигрывается с определенного и до определенного момента (в
соответствии с телепрограммой), это реализовано средствами php. Проблема в
том,
что в связке nginx+apache скорость отдачи файла <=200КБ/c, что вызывает
тормоза с видео и звуком. Многочисленные манипуляции с буферами в nginx
ничего не дали.

Отдельно nginx файлы отдаются без проблем (без этих наворотов с php),
отдельно apache тоже (с php).
Если просто качать файл через связку (опять же без наворотов c php), то
проблем нет.

Пожалуйста, дайте совет, в какую сторону копать? Откуда может браться это
ограничение в 200 КБ/c и кто виноват?

Пример ссылки:
http://mydomain.dom/get.php?filename=20140320-08.mpg&ch_id=2&token=5e64989c44afbfdfc82cac4d66712742&start=900&duration=2700&osd_title=%D0%91%D0%B5%D0%BB%D0%B0%D1%80%D1%83%D1%81%D1%8C+1+%E2%80%94+%D0%94%D0%BE%D0%B1%D1%80%D0%BE%D0%B5+%D1%83%D1%82%D1%80%D0%BE%2C+%D0%91%D0%B5%D0%BB%D0%B0%D1%80%D1%83%D1%81%D1%8C%21&real_id=2_1395292500

Заранее большое спасибо.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140320/31a8e824/attachment.html>

From anatoly at sonru.com  Thu Mar 20 12:22:32 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Thu, 20 Mar 2014 12:22:32 +0000
Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60LgsINC60L4=?=
 =?UTF-8?B?0YLQvtGA0YPRjiDQs9C10L3QtdGA0LjRgNGD0LXRgiDQsdGN0LrRjdC90LQ=?=
In-Reply-To: <C0B73EEF-2E1C-471A-B439-94C3BFE61523@sysoev.ru>
References: <4F29D5F6-D32A-42C4-BA78-9528EFD01A5C@sonru.com>
 <CAFHpkQF1_SovDEwyV7Q3xkBH915+vO9YNKf58yuSX-BnSR7nzw@mail.gmail.com>
 <E40AD672-2F4A-43C5-A278-7E1BDD24A826@sonru.com>
 <CAFHpkQFp0-7h3-N1hgyA6sSCuKyF+=GG96x+vSqHcLBWBgJTwg@mail.gmail.com>
 <801E7EA4-0624-4536-82B9-EE17A583AACE@sonru.com>
 <914BE6DF-0EEA-4420-9ACA-E6F2D5D769BC@sysoev.ru>
 <DA6B3B0D-B8B2-459A-B26C-3A71D1B6F875@sonru.com>
 <C0B73EEF-2E1C-471A-B439-94C3BFE61523@sysoev.ru>
Message-ID: <2E812DFC-CCD1-45FB-9749-3DC73C41C84F@sonru.com>


On 20 Jan 2014, at 11:41, Igor Sysoev <igor at sysoev.ru> wrote:

> On Jan 20, 2014, at 15:27 , Anatoly Mikhailov wrote:
> 
>> 
>> On 20 Jan 2014, at 11:02, Igor Sysoev <igor at sysoev.ru> wrote:
>> 
>>> On Jan 20, 2014, at 14:52 , Anatoly Mikhailov wrote:
>>> 
>>>> в нашем случае - локально настроенная Jira с 10 пользователями,
>>>> сомневаюсь, что приложение загнется при такой нагрузке.
>>>> 
>>>> и все же, кто как кэширует статику, сгенерированную налету?
>>> 
>>> http {
>>>    proxy_cache_path  /path/to/cache  keys_zone=CACHE:20M;
>>>    proxy_temp_path   /path/to/temp;
>>> 
>>>    server {
>>>        location /static/ {
>>>            proxy_pass   http://backend;
>>>            proxy_cache  CACHE;
>>>            proxy_cache_valid  1h;
>>>        }
>>>    }
>>> }
>> 
>> Игорь, спасибо, проблема решена, но возможно не оптимальным образом:
>> 
>>   proxy_cache_path      /.../nginx/cache levels=1:2 keys_zone=STATIC:20M;
>>   proxy_temp_path       /.../nginx/tmp;
>> 
>>   server {
>>     listen        8000;
>> 
>>     location /jira {
>>       proxy_pass            http://jira_upstream/jira;
>>       proxy_set_header      Host $host;
>>       proxy_set_header      X-Real-IP $remote_addr;
>>       proxy_set_header      X-Forwarded-for $remote_addr;
>>       proxy_redirect        off;
>>       proxy_connect_timeout 120;
>>       proxy_send_timeout    120;
>>       proxy_read_timeout    180;
>>     }
>> 
>>     location /jira/s/ {
>>       proxy_pass            http://jira_upstream/jira/s/;
>>       proxy_set_header      Host $host;
>>       proxy_set_header      X-Real-IP $remote_addr;
>>       proxy_set_header      X-Forwarded-for $remote_addr;
>>       proxy_redirect        off;
>>       proxy_connect_timeout 120;
>>       proxy_send_timeout    120;
>>       proxy_read_timeout    180;
>> 
>>       proxy_ignore_headers "Set-Cookie";
> 
> Ещё нужно
> proxy_hide_header  Set-Cookie;
> иначе клиенты будут получать чужие куки.
> 

получилось хорошее решение, и точечная инвалидация работает:
https://gist.github.com/mikhailov/9639593

> -- 
> Igor Sysoev
> http://nginx.com
> 
>>       proxy_cache          STATIC;
>>       proxy_cache_valid    60m;
>>     }
>> 
>> 
>> Анатолий
> 
> _______________________________________________
> 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/20140320/b56a996b/attachment.html>

From public-mail at alekciy.ru  Thu Mar 20 12:39:21 2014
From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=)
Date: Thu, 20 Mar 2014 16:39:21 +0400
Subject: =?UTF-8?B?UmU6INC90LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINCyINGB0LLRj9C30Lo=?=
 =?UTF-8?B?0LUgbmdpbngrYXBhY2hl?=
In-Reply-To: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
References: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
Message-ID: <CAPP2NXq+wqtjFEv0OsTu4i9_QYYufxECytUvCSYv=zBdHoF2kA@mail.gmail.com>

>Помогите пожалуйста разобраться, в каком месте проблема.
"это реализовано средствами php", т.е. на стороне php скрипта.


20 марта 2014 г., 16:17 пользователь Ксения Юрьевна Блащук <
ksyblast at gmail.com> написал:

> Добрый день.
>
> Помогите пожалуйста разобраться, в каком месте проблема. Имеется проект по
> отложенному просмотру телепередач. Видео записывается в файлы по одному
> часу каждый. При просмотре передач видео собирается из нескольких файлов
> или же файл проигрывается с определенного и до определенного момента (в
> соответствии с телепрограммой), это реализовано средствами php. Проблема в
> том,
> что в связке nginx+apache скорость отдачи файла <=200КБ/c, что вызывает
> тормоза с видео и звуком. Многочисленные манипуляции с буферами в nginx
> ничего не дали.
>
> Отдельно nginx файлы отдаются без проблем (без этих наворотов с php),
> отдельно apache тоже (с php).
> Если просто качать файл через связку (опять же без наворотов c php), то
> проблем нет.
>
> Пожалуйста, дайте совет, в какую сторону копать? Откуда может браться это
> ограничение в 200 КБ/c и кто виноват?
>
> Пример ссылки:
>
> http://mydomain.dom/get.php?filename=20140320-08.mpg&ch_id=2&token=5e64989c44afbfdfc82cac4d66712742&start=900&duration=2700&osd_title=%D0%91%D0%B5%D0%BB%D0%B0%D1%80%D1%83%D1%81%D1%8C+1+%E2%80%94+%D0%94%D0%BE%D0%B1%D1%80%D0%BE%D0%B5+%D1%83%D1%82%D1%80%D0%BE%2C+%D0%91%D0%B5%D0%BB%D0%B0%D1%80%D1%83%D1%81%D1%8C%21&real_id=2_1395292500
>
> Заранее большое спасибо.
>
> _______________________________________________
> 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/20140320/02f8a2bd/attachment-0001.html>

From ksyblast at gmail.com  Thu Mar 20 12:53:42 2014
From: ksyblast at gmail.com (=?KOI8-R?B?69PFzsnRIODS2MXXzsEg4szB3dXL?=)
Date: Thu, 20 Mar 2014 15:53:42 +0300
Subject: =?UTF-8?B?UmU6INC90LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINCyINGB0LLRj9C30Lo=?=
 =?UTF-8?B?0LUgbmdpbngrYXBhY2hl?=
In-Reply-To: <CAPP2NXq+wqtjFEv0OsTu4i9_QYYufxECytUvCSYv=zBdHoF2kA@mail.gmail.com>
References: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
 <CAPP2NXq+wqtjFEv0OsTu4i9_QYYufxECytUvCSYv=zBdHoF2kA@mail.gmail.com>
Message-ID: <CAMvGrGeFCxYE7nXOWo4Wh=yZ-87HQBnvk2t4ZaCkE73ipuSrxQ@mail.gmail.com>

Так если отдавать одним апачем то проблем нет.



20 марта 2014 г., 15:39 пользователь Алексей Сундуков <
public-mail at alekciy.ru> написал:

> >Помогите пожалуйста разобраться, в каком месте проблема.
> "это реализовано средствами php", т.е. на стороне php скрипта.
>
>
> 20 марта 2014 г., 16:17 пользователь Ксения Юрьевна Блащук <
> ksyblast at gmail.com> написал:
>
>> Добрый день.
>>
>> Помогите пожалуйста разобраться, в каком месте проблема. Имеется проект
>> по отложенному просмотру телепередач. Видео записывается в файлы по одному
>> часу каждый. При просмотре передач видео собирается из нескольких файлов
>> или же файл проигрывается с определенного и до определенного момента (в
>> соответствии с телепрограммой), это реализовано средствами php. Проблема в
>> том,
>> что в связке nginx+apache скорость отдачи файла <=200КБ/c, что вызывает
>> тормоза с видео и звуком. Многочисленные манипуляции с буферами в nginx
>> ничего не дали.
>>
>> Отдельно nginx файлы отдаются без проблем (без этих наворотов с php),
>> отдельно apache тоже (с php).
>> Если просто качать файл через связку (опять же без наворотов c php), то
>> проблем нет.
>>
>> Пожалуйста, дайте совет, в какую сторону копать? Откуда может браться это
>> ограничение в 200 КБ/c и кто виноват?
>>
>> Пример ссылки:
>>
>> http://mydomain.dom/get.php?filename=20140320-08.mpg&ch_id=2&token=5e64989c44afbfdfc82cac4d66712742&start=900&duration=2700&osd_title=%D0%91%D0%B5%D0%BB%D0%B0%D1%80%D1%83%D1%81%D1%8C+1+%E2%80%94+%D0%94%D0%BE%D0%B1%D1%80%D0%BE%D0%B5+%D1%83%D1%82%D1%80%D0%BE%2C+%D0%91%D0%B5%D0%BB%D0%B0%D1%80%D1%83%D1%81%D1%8C%21&real_id=2_1395292500
>>
>> Заранее большое спасибо.
>>
>> _______________________________________________
>> 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/20140320/020feaca/attachment.html>

From mdounin at mdounin.ru  Thu Mar 20 13:32:11 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 20 Mar 2014 17:32:11 +0400
Subject: =?UTF-8?B?UmU6IEhUVFAg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgMS4x?=
In-Reply-To: <900F8910-2655-4DAD-B08E-00CDFD080637@sonru.com>
References: <10E1EDD4-A951-4ECC-9057-731A76DAA127@sonru.com>
 <20140318110845.GH34696@mdounin.ru>
 <9BEB08CD-2200-441A-83E3-A21ACDF1033F@sonru.com>
 <20140318135118.GR34696@mdounin.ru>
 <48F97DED-99ED-4921-82E0-EF8168B6BE58@sonru.com>
 <20140318151047.GT34696@mdounin.ru>
 <B5BDEAAB-D3EC-4C88-AFA5-B46AE826B9B9@sonru.com>
 <20140319133700.GW34696@mdounin.ru>
 <900F8910-2655-4DAD-B08E-00CDFD080637@sonru.com>
Message-ID: <20140320133211.GF34696@mdounin.ru>

Hello!

On Thu, Mar 20, 2014 at 12:03:23PM +0000, Anatoly Mikhailov wrote:

> 
> On 19 Mar 2014, at 13:37, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > Hello!
> > 
> > On Wed, Mar 19, 2014 at 10:42:26AM +0000, Anatoly Mikhailov wrote:
> > 
> >> 
> >> On 18 Mar 2014, at 15:10, Maxim Dounin <mdounin at mdounin.ru> wrote:

[...]

> >> супер, переписал конфигурацию для проксирования S3 на upstream, получилось очень классно,
> >> вопрос - почему бы не сделать keepalive для бэкэнда по умолчанию?
> > 
> > Использование постоянных соединений полезно в основном в тех 
> > случаях, когда до бекенда - далеко.  В условиях близких бекендов 
> > оно обычно не нужно.  Наоборот, в некоторых ситуациях постоянные 
> > соединения могут повредить - например, если бекенд сильно ограничен по 
> > количеству соединений, которые он может обрабатывать.  В 
> > документации даже специально добавлено замечание про это, т.к. 
> > люди периодически наступают, cм. http://nginx.org/r/keepalive/ru.
> > 
> > Так что я к идее сделать keepalive к бекендам поведением по 
> > умолчанию - отношусь скептически.
> > 
> 
> Я правильно понимаю, keepalive (в контексте upstream) задает количество
> TCP соединений, которые не будут закрываться, даже при отсутствии будущих запросов?

Да.

Следует, однако, учитывать, что это число - на каждый рабочий 
процесс.

> Если да, то какой таймаут, такой же как для клиентских TCP подключений, указанных
> через директиву keepalive_timeout?

Таймаут определяется тем, сколько соединение будет поддерживать 
бекенд.  Сам nginx ничего закрывать не пытается.

> Вопрос второй - если известно, что бэкэнд держит, скажем, 50 соединений, 
> то keepalive 50 поможет нам повторно их использовать в будущем, без повторных syn+ack?

Если бекенд держит только 50 соединений, то ставить в конфиге 
"keepalive 50" - нецелесообразно, т.к. при таких настройках весь 
бекенд может быть занят одним рабочим процессом.

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


From public-mail at alekciy.ru  Thu Mar 20 13:37:02 2014
From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=)
Date: Thu, 20 Mar 2014 17:37:02 +0400
Subject: =?UTF-8?B?UmU6INC90LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINCyINGB0LLRj9C30Lo=?=
 =?UTF-8?B?0LUgbmdpbngrYXBhY2hl?=
In-Reply-To: <CAMvGrGeFCxYE7nXOWo4Wh=yZ-87HQBnvk2t4ZaCkE73ipuSrxQ@mail.gmail.com>
References: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
 <CAPP2NXq+wqtjFEv0OsTu4i9_QYYufxECytUvCSYv=zBdHoF2kA@mail.gmail.com>
 <CAMvGrGeFCxYE7nXOWo4Wh=yZ-87HQBnvk2t4ZaCkE73ipuSrxQ@mail.gmail.com>
Message-ID: <CAPP2NXrRVLixirqqHcoXPNKW6AQK0XChEhFwdo5s7wray0CwRQ@mail.gmail.com>

Апачем каким образом? Можно ведь отдавать и статическим файлом. Точно через
php уходит?

Если используется fastcgi, то нужно понимать, что до 1.5.6 версии nginx
отключить буферизацию невозможно:
http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_buffering

Вообще отдавать видео через php плохая идея. Рекомендую смотреть в сторону
erlyvideo (это erlang).



20 марта 2014 г., 16:53 пользователь Ксения Юрьевна Блащук <
ksyblast at gmail.com> написал:

> Так если отдавать одним апачем то проблем нет.
>
>
>
> 20 марта 2014 г., 15:39 пользователь Алексей Сундуков <
> public-mail at alekciy.ru> написал:
>
> >Помогите пожалуйста разобраться, в каком месте проблема.
>> "это реализовано средствами php", т.е. на стороне php скрипта.
>>
>>
>> 20 марта 2014 г., 16:17 пользователь Ксения Юрьевна Блащук <
>> ksyblast at gmail.com> написал:
>>
>>> Добрый день.
>>>
>>> Помогите пожалуйста разобраться, в каком месте проблема. Имеется проект
>>> по отложенному просмотру телепередач. Видео записывается в файлы по одному
>>> часу каждый. При просмотре передач видео собирается из нескольких файлов
>>> или же файл проигрывается с определенного и до определенного момента (в
>>> соответствии с телепрограммой), это реализовано средствами php. Проблема в
>>> том,
>>> что в связке nginx+apache скорость отдачи файла <=200КБ/c, что вызывает
>>> тормоза с видео и звуком. Многочисленные манипуляции с буферами в nginx
>>> ничего не дали.
>>>
>>> Отдельно nginx файлы отдаются без проблем (без этих наворотов с php),
>>> отдельно apache тоже (с php).
>>> Если просто качать файл через связку (опять же без наворотов c php), то
>>> проблем нет.
>>>
>>> Пожалуйста, дайте совет, в какую сторону копать? Откуда может браться
>>> это ограничение в 200 КБ/c и кто виноват?
>>>
>>> Пример ссылки:
>>>
>>> http://mydomain.dom/get.php?filename=20140320-08.mpg&ch_id=2&token=5e64989c44afbfdfc82cac4d66712742&start=900&duration=2700&osd_title=%D0%91%D0%B5%D0%BB%D0%B0%D1%80%D1%83%D1%81%D1%8C+1+%E2%80%94+%D0%94%D0%BE%D0%B1%D1%80%D0%BE%D0%B5+%D1%83%D1%82%D1%80%D0%BE%2C+%D0%91%D0%B5%D0%BB%D0%B0%D1%80%D1%83%D1%81%D1%8C%21&real_id=2_1395292500
>>>
>>> Заранее большое спасибо.
>>>
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140320/0ba498a2/attachment.html>

From ksyblast at gmail.com  Thu Mar 20 14:23:34 2014
From: ksyblast at gmail.com (=?KOI8-R?B?69PFzsnRIODS2MXXzsEg4szB3dXL?=)
Date: Thu, 20 Mar 2014 17:23:34 +0300
Subject: =?UTF-8?B?UmU6INC90LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINCyINGB0LLRj9C30Lo=?=
 =?UTF-8?B?0LUgbmdpbngrYXBhY2hl?=
In-Reply-To: <CAPP2NXrRVLixirqqHcoXPNKW6AQK0XChEhFwdo5s7wray0CwRQ@mail.gmail.com>
References: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
 <CAPP2NXq+wqtjFEv0OsTu4i9_QYYufxECytUvCSYv=zBdHoF2kA@mail.gmail.com>
 <CAMvGrGeFCxYE7nXOWo4Wh=yZ-87HQBnvk2t4ZaCkE73ipuSrxQ@mail.gmail.com>
 <CAPP2NXrRVLixirqqHcoXPNKW6AQK0XChEhFwdo5s7wray0CwRQ@mail.gmail.com>
Message-ID: <CAMvGrGc=1hqZzDDfA-PqXTauPNOtDhyO6yoaELsFtYQ9A2DpFA@mail.gmail.com>

Да, точно через php.
Вот ссылка
http://mydomain.dom/get.php?filename=20140320-08.mpg&ch_id=2&token=5e64989c44afbfdfc82cac4d66712742&start=900&duration=2700&osd_title=%D0%91%D0%B5%D0%BB%D0%B0%D1%80%D1%83%D1%81%D1%8C+1+%E2%80%94+%D0%94%D0%BE%D0%B1%D1%80%D0%BE%D0%B5+%D1%83%D1%82%D1%80%D0%BE%2C+%D0%91%D0%B5%D0%BB%D0%B0%D1%80%D1%83%D1%81%D1%8C%21&real_id=2_1395292500

Статическим файлом кстати работает нормально через связку.
Мне-то тоже не нравится, что отдается через php. Но просят именно такую
схему (типа ее рекомендовал разработчик и все такое) - я в тупике :).



20 марта 2014 г., 16:37 пользователь Алексей Сундуков <
public-mail at alekciy.ru> написал:

> Апачем каким образом? Можно ведь отдавать и статическим файлом. Точно
> через php уходит?
>
> Если используется fastcgi, то нужно понимать, что до 1.5.6 версии nginx
> отключить буферизацию невозможно:
> http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_buffering
>
> Вообще отдавать видео через php плохая идея. Рекомендую смотреть в сторону
> erlyvideo (это erlang).
>
>
>
> 20 марта 2014 г., 16:53 пользователь Ксения Юрьевна Блащук <
> ksyblast at gmail.com> написал:
>
> Так если отдавать одним апачем то проблем нет.
>>
>>
>>
>> 20 марта 2014 г., 15:39 пользователь Алексей Сундуков <
>> public-mail at alekciy.ru> написал:
>>
>> >Помогите пожалуйста разобраться, в каком месте проблема.
>>> "это реализовано средствами php", т.е. на стороне php скрипта.
>>>
>>>
>>> 20 марта 2014 г., 16:17 пользователь Ксения Юрьевна Блащук <
>>> ksyblast at gmail.com> написал:
>>>
>>>> Добрый день.
>>>>
>>>> Помогите пожалуйста разобраться, в каком месте проблема. Имеется проект
>>>> по отложенному просмотру телепередач. Видео записывается в файлы по одному
>>>> часу каждый. При просмотре передач видео собирается из нескольких файлов
>>>> или же файл проигрывается с определенного и до определенного момента (в
>>>> соответствии с телепрограммой), это реализовано средствами php. Проблема в
>>>> том,
>>>> что в связке nginx+apache скорость отдачи файла <=200КБ/c, что вызывает
>>>> тормоза с видео и звуком. Многочисленные манипуляции с буферами в nginx
>>>> ничего не дали.
>>>>
>>>> Отдельно nginx файлы отдаются без проблем (без этих наворотов с php),
>>>> отдельно apache тоже (с php).
>>>> Если просто качать файл через связку (опять же без наворотов c php), то
>>>> проблем нет.
>>>>
>>>> Пожалуйста, дайте совет, в какую сторону копать? Откуда может браться
>>>> это ограничение в 200 КБ/c и кто виноват?
>>>>
>>>> Пример ссылки:
>>>>
>>>> http://mydomain.dom/get.php?filename=20140320-08.mpg&ch_id=2&token=5e64989c44afbfdfc82cac4d66712742&start=900&duration=2700&osd_title=%D0%91%D0%B5%D0%BB%D0%B0%D1%80%D1%83%D1%81%D1%8C+1+%E2%80%94+%D0%94%D0%BE%D0%B1%D1%80%D0%BE%D0%B5+%D1%83%D1%82%D1%80%D0%BE%2C+%D0%91%D0%B5%D0%BB%D0%B0%D1%80%D1%83%D1%81%D1%8C%21&real_id=2_1395292500
>>>>
>>>> Заранее большое спасибо.
>>>>
>>>> _______________________________________________
>>>> nginx-ru mailing list
>>>> nginx-ru at nginx.org
>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>>
>>>
>>>
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140320/09f65459/attachment-0001.html>

From vbart at nginx.com  Thu Mar 20 14:29:01 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 20 Mar 2014 18:29:01 +0400
Subject: =?UTF-8?B?UmU6INC90LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINCyINGB0LLRj9C30Lo=?=
 =?UTF-8?B?0LUgbmdpbngrYXBhY2hl?=
In-Reply-To: <CAPP2NXrRVLixirqqHcoXPNKW6AQK0XChEhFwdo5s7wray0CwRQ@mail.gmail.com>
References: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
 <CAMvGrGeFCxYE7nXOWo4Wh=yZ-87HQBnvk2t4ZaCkE73ipuSrxQ@mail.gmail.com>
 <CAPP2NXrRVLixirqqHcoXPNKW6AQK0XChEhFwdo5s7wray0CwRQ@mail.gmail.com>
Message-ID: <9693263.u9mpiO4qPH@vbart-laptop>

On Thursday 20 March 2014 17:37:02 Алексей Сундуков wrote:
> Апачем каким образом? Можно ведь отдавать и статическим файлом. Точно через
> php уходит?
> 
> Если используется fastcgi, то нужно понимать, что до 1.5.6 версии nginx
> отключить буферизацию невозможно:
> http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_buffering

Отключение наоборот негативно влияет на производительность и необходимо в 
основном для long polling задач.

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

From vbart at nginx.com  Thu Mar 20 14:32:13 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 20 Mar 2014 18:32:13 +0400
Subject: =?UTF-8?B?UmU6INC90LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINCyINGB0LLRj9C30Lo=?=
 =?UTF-8?B?0LUgbmdpbngrYXBhY2hl?=
In-Reply-To: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
References: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
Message-ID: <1553863.0nj9pZmGWM@vbart-laptop>

On Thursday 20 March 2014 15:17:57 Ксения Юрьевна Блащук wrote:
> Добрый день.
> 
> Помогите пожалуйста разобраться, в каком месте проблема. Имеется проект по
> отложенному просмотру телепередач. Видео записывается в файлы по одному
> часу каждый. При просмотре передач видео собирается из нескольких файлов
> или же файл проигрывается с определенного и до определенного момента (в
> соответствии с телепрограммой), это реализовано средствами php. Проблема в
> том,
> что в связке nginx+apache скорость отдачи файла <=200КБ/c, что вызывает
> тормоза с видео и звуком. Многочисленные манипуляции с буферами в nginx
> ничего не дали.
> 
> Отдельно nginx файлы отдаются без проблем (без этих наворотов с php),
> отдельно apache тоже (с php).
> Если просто качать файл через связку (опять же без наворотов c php), то
> проблем нет.
> 
> Пожалуйста, дайте совет, в какую сторону копать? Откуда может браться это
> ограничение в 200 КБ/c и кто виноват?
> 

Копайте в сторону http://nginx.org/r/proxy_max_temp_file_size/ru

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

From anatoly at sonru.com  Thu Mar 20 14:38:58 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Thu, 20 Mar 2014 14:38:58 +0000
Subject: =?UTF-8?B?UmU6IEhUVFAg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgMS4x?=
In-Reply-To: <20140320133211.GF34696@mdounin.ru>
References: <10E1EDD4-A951-4ECC-9057-731A76DAA127@sonru.com>
 <20140318110845.GH34696@mdounin.ru>
 <9BEB08CD-2200-441A-83E3-A21ACDF1033F@sonru.com>
 <20140318135118.GR34696@mdounin.ru>
 <48F97DED-99ED-4921-82E0-EF8168B6BE58@sonru.com>
 <20140318151047.GT34696@mdounin.ru>
 <B5BDEAAB-D3EC-4C88-AFA5-B46AE826B9B9@sonru.com>
 <20140319133700.GW34696@mdounin.ru>
 <900F8910-2655-4DAD-B08E-00CDFD080637@sonru.com>
 <20140320133211.GF34696@mdounin.ru>
Message-ID: <2940C2EB-26C5-439E-BE3B-C4168BB1C313@sonru.com>


On 20 Mar 2014, at 13:32, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
> 
> On Thu, Mar 20, 2014 at 12:03:23PM +0000, Anatoly Mikhailov wrote:
> 
>> 
>> On 19 Mar 2014, at 13:37, Maxim Dounin <mdounin at mdounin.ru> wrote:
>> 
>>> Hello!
>>> 
>>> On Wed, Mar 19, 2014 at 10:42:26AM +0000, Anatoly Mikhailov wrote:
>>> 
>>>> 
>>>> On 18 Mar 2014, at 15:10, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> [...]
> 
>>>> супер, переписал конфигурацию для проксирования S3 на upstream, получилось очень классно,
>>>> вопрос - почему бы не сделать keepalive для бэкэнда по умолчанию?
>>> 
>>> Использование постоянных соединений полезно в основном в тех 
>>> случаях, когда до бекенда - далеко.  В условиях близких бекендов 
>>> оно обычно не нужно.  Наоборот, в некоторых ситуациях постоянные 
>>> соединения могут повредить - например, если бекенд сильно ограничен по 
>>> количеству соединений, которые он может обрабатывать.  В 
>>> документации даже специально добавлено замечание про это, т.к. 
>>> люди периодически наступают, cм. http://nginx.org/r/keepalive/ru.
>>> 
>>> Так что я к идее сделать keepalive к бекендам поведением по 
>>> умолчанию - отношусь скептически.
>>> 
>> 
>> Я правильно понимаю, keepalive (в контексте upstream) задает количество
>> TCP соединений, которые не будут закрываться, даже при отсутствии будущих запросов?
> 
> Да.
> 
> Следует, однако, учитывать, что это число - на каждый рабочий 
> процесс.
> 
>> Если да, то какой таймаут, такой же как для клиентских TCP подключений, указанных
>> через директиву keepalive_timeout?
> 
> Таймаут определяется тем, сколько соединение будет поддерживать 
> бекенд.  Сам nginx ничего закрывать не пытается.
> 
>> Вопрос второй - если известно, что бэкэнд держит, скажем, 50 соединений, 
>> то keepalive 50 поможет нам повторно их использовать в будущем, без повторных syn+ack?
> 
> Если бекенд держит только 50 соединений, то ставить в конфиге 
> "keepalive 50" - нецелесообразно, т.к. при таких настройках весь 
> бекенд может быть занят одним рабочим процессом.

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

> 
> -- 
> 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/20140320/b672ae25/attachment.html>

From mdounin at mdounin.ru  Thu Mar 20 15:00:30 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 20 Mar 2014 19:00:30 +0400
Subject: =?UTF-8?B?UmU6IEhUVFAg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgMS4x?=
In-Reply-To: <2940C2EB-26C5-439E-BE3B-C4168BB1C313@sonru.com>
References: <20140318110845.GH34696@mdounin.ru>
 <9BEB08CD-2200-441A-83E3-A21ACDF1033F@sonru.com>
 <20140318135118.GR34696@mdounin.ru>
 <48F97DED-99ED-4921-82E0-EF8168B6BE58@sonru.com>
 <20140318151047.GT34696@mdounin.ru>
 <B5BDEAAB-D3EC-4C88-AFA5-B46AE826B9B9@sonru.com>
 <20140319133700.GW34696@mdounin.ru>
 <900F8910-2655-4DAD-B08E-00CDFD080637@sonru.com>
 <20140320133211.GF34696@mdounin.ru>
 <2940C2EB-26C5-439E-BE3B-C4168BB1C313@sonru.com>
Message-ID: <20140320150030.GK34696@mdounin.ru>

Hello!

On Thu, Mar 20, 2014 at 02:38:58PM +0000, Anatoly Mikhailov wrote:

> 
> On 20 Mar 2014, at 13:32, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > Hello!
> > 
> > On Thu, Mar 20, 2014 at 12:03:23PM +0000, Anatoly Mikhailov wrote:
> > 
> >> 
> >> On 19 Mar 2014, at 13:37, Maxim Dounin <mdounin at mdounin.ru> wrote:
> >> 
> >>> Hello!
> >>> 
> >>> On Wed, Mar 19, 2014 at 10:42:26AM +0000, Anatoly Mikhailov wrote:
> >>> 
> >>>> 
> >>>> On 18 Mar 2014, at 15:10, Maxim Dounin <mdounin at mdounin.ru> wrote:
> > 
> > [...]
> > 
> >>>> супер, переписал конфигурацию для проксирования S3 на upstream, получилось очень классно,
> >>>> вопрос - почему бы не сделать keepalive для бэкэнда по умолчанию?
> >>> 
> >>> Использование постоянных соединений полезно в основном в тех 
> >>> случаях, когда до бекенда - далеко.  В условиях близких бекендов 
> >>> оно обычно не нужно.  Наоборот, в некоторых ситуациях постоянные 
> >>> соединения могут повредить - например, если бекенд сильно ограничен по 
> >>> количеству соединений, которые он может обрабатывать.  В 
> >>> документации даже специально добавлено замечание про это, т.к. 
> >>> люди периодически наступают, cм. http://nginx.org/r/keepalive/ru.
> >>> 
> >>> Так что я к идее сделать keepalive к бекендам поведением по 
> >>> умолчанию - отношусь скептически.
> >>> 
> >> 
> >> Я правильно понимаю, keepalive (в контексте upstream) задает количество
> >> TCP соединений, которые не будут закрываться, даже при отсутствии будущих запросов?
> > 
> > Да.
> > 
> > Следует, однако, учитывать, что это число - на каждый рабочий 
> > процесс.
> > 
> >> Если да, то какой таймаут, такой же как для клиентских TCP подключений, указанных
> >> через директиву keepalive_timeout?
> > 
> > Таймаут определяется тем, сколько соединение будет поддерживать 
> > бекенд.  Сам nginx ничего закрывать не пытается.
> > 
> >> Вопрос второй - если известно, что бэкэнд держит, скажем, 50 соединений, 
> >> то keepalive 50 поможет нам повторно их использовать в будущем, без повторных syn+ack?
> > 
> > Если бекенд держит только 50 соединений, то ставить в конфиге 
> > "keepalive 50" - нецелесообразно, т.к. при таких настройках весь 
> > бекенд может быть занят одним рабочим процессом.
> 
> Все понятно, кроме этого момента. Если keepalive - нижняя граница, то второй рабочий
> процесс откроет больше соединений, чем указано в keepalive... или здесь все по другому?

Рассмотрим такой пример:

- пусть у нас бекенд может обработать до 50 соединений 
  включительно (e.g., он использует модель process-per-connection, 
  и запущено 50 процессов);

- пусть все эти соединения открыл один рабочих процессов nginx'а 
  и держит открытыми, сохранив в кеш (ему сказано кешировать до 50  
  соединений включительно);

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

Проблема состоит в том, что наш бекенд - умеет только 50 
соединений, больше - не умеет.  И то 51-е соединение, которое мы 
пытаемся открыть, - обслуживать некому.  Соответственно это 
соединение никто не примет, и случится ошибка.

Чтобы такого не происходило - нужно ограничивать количество 
постоянных соединений.  В RFC2616, например, по этому вопросу 
сказано: "A single-user client SHOULD NOT maintain more than 2 
connections with any server or proxy".  Столь малыми значениями 
сейчас не ограничиваются даже браузеры, но и сильно много 
соединений держать в кеше не нужно.

Совсем простое правило - не следует делать кеш соединений больше, 
чем (N / worker_process) - 1, где N - число соединений, которое 
способен обслуживать бекенд.

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


From bogdar at gmail.com  Thu Mar 20 16:42:59 2014
From: bogdar at gmail.com (Bogdan)
Date: Thu, 20 Mar 2014 19:42:59 +0300
Subject: =?UTF-8?B?0JzQvtC00LjRhNC40LrQsNGG0LjRjyBmYXN0Y2dpX3BhcmFtIFJFUVVFU1RfVVJJ?=
 =?UTF-8?B?INC4INC80L3QvtC20LXRgdGC0LLQtdC90L3Ri9C1IHJld3JpdGU=?=
Message-ID: <CACz2Q8HSLvB8b5X6AQwbUpBJ-+vWQtXUxKNCFDtcOStqEsJkpQ@mail.gmail.com>

Добрый день.

Хочу иметь возможно многократно делать rewrite и получать в конце в
параметр REQUEST_URI "последний" результат работы rewrite

Т.е. что-то такое:

URL: http://site.com/page-10

rewrite ^/page-(.*) /main/handler?page=$1;
rewrite ^/main/.* /router;

location / {
                index index.php;
                try_files $uri $uri/ /index.php?$args;
}

        location ~ \.php$ {
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini

                # With php5-fpm:
                fastcgi_pass backend;
                fastcgi_index index.php;
                fastcgi_connect_timeout 1;
                fastcgi_send_timeout 1;
                include fastcgi_params;
 }

В результате я хотел бы получить при обращении к URL http://site.com/page-10
в параметре REQUEST_URI передаваемому fastcgi-серверу значние вида:
/router?page=10
Сейчас в REQUEST_URI передаётся переменная $request_uri со значением
"/page-10", а переменная $uri содержит "/index.php"

Подскажите пожалуйста, как это можно сделать, особенно хотелось бы обойтись
без if .. set
В крайнем случае устроил бы и всего один rewrite, но нужно так или иначе
предавать в fastcgi модифицированный вариант URI.

Спасибо.

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

From bogdar at gmail.com  Thu Mar 20 16:47:40 2014
From: bogdar at gmail.com (Bogdan)
Date: Thu, 20 Mar 2014 19:47:40 +0300
Subject: =?UTF-8?B?UmU6INC90LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINCyINGB0LLRj9C30Lo=?=
 =?UTF-8?B?0LUgbmdpbngrYXBhY2hl?=
In-Reply-To: <1553863.0nj9pZmGWM@vbart-laptop>
References: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
 <1553863.0nj9pZmGWM@vbart-laptop>
Message-ID: <CACz2Q8EY=Aa_B+T0ouDxGG-0+j8jVKVXgVfwZ344cm3umoLhGg@mail.gmail.com>

А X-Accel-Redirect заказчика никак не удовлетворит?


2014-03-20 17:32 GMT+03:00 Валентин Бартенев <vbart at nginx.com>:

> On Thursday 20 March 2014 15:17:57 Ксения Юрьевна Блащук wrote:
> > Добрый день.
> >
> > Помогите пожалуйста разобраться, в каком месте проблема. Имеется проект
> по
> > отложенному просмотру телепередач. Видео записывается в файлы по одному
> > часу каждый. При просмотре передач видео собирается из нескольких файлов
> > или же файл проигрывается с определенного и до определенного момента (в
> > соответствии с телепрограммой), это реализовано средствами php. Проблема
> в
> > том,
> > что в связке nginx+apache скорость отдачи файла <=200КБ/c, что вызывает
> > тормоза с видео и звуком. Многочисленные манипуляции с буферами в nginx
> > ничего не дали.
> >
> > Отдельно nginx файлы отдаются без проблем (без этих наворотов с php),
> > отдельно apache тоже (с php).
> > Если просто качать файл через связку (опять же без наворотов c php), то
> > проблем нет.
> >
> > Пожалуйста, дайте совет, в какую сторону копать? Откуда может браться это
> > ограничение в 200 КБ/c и кто виноват?
> >
>
> Копайте в сторону http://nginx.org/r/proxy_max_temp_file_size/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/20140320/427eb792/attachment.html>

From mdounin at mdounin.ru  Thu Mar 20 16:55:58 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 20 Mar 2014 20:55:58 +0400
Subject: =?UTF-8?B?UmU6INCc0L7QtNC40YTQuNC60LDRhtC40Y8gZmFzdGNnaV9wYXJhbSBSRVFVRVNU?=
 =?UTF-8?B?X1VSSSDQuCDQvNC90L7QttC10YHRgtCy0LXQvdC90YvQtSByZXdyaXRl?=
In-Reply-To: <CACz2Q8HSLvB8b5X6AQwbUpBJ-+vWQtXUxKNCFDtcOStqEsJkpQ@mail.gmail.com>
References: <CACz2Q8HSLvB8b5X6AQwbUpBJ-+vWQtXUxKNCFDtcOStqEsJkpQ@mail.gmail.com>
Message-ID: <20140320165558.GN34696@mdounin.ru>

Hello!

On Thu, Mar 20, 2014 at 07:42:59PM +0300, Bogdan wrote:

> Добрый день.
> 
> Хочу иметь возможно многократно делать rewrite и получать в конце в
> параметр REQUEST_URI "последний" результат работы rewrite
> 
> Т.е. что-то такое:
> 
> URL: http://site.com/page-10
> 
> rewrite ^/page-(.*) /main/handler?page=$1;
> rewrite ^/main/.* /router;
> 
> location / {
>                 index index.php;
>                 try_files $uri $uri/ /index.php?$args;
> }
> 
>         location ~ \.php$ {
>                 fastcgi_split_path_info ^(.+\.php)(/.+)$;
>                 # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
> 
>                 # With php5-fpm:
>                 fastcgi_pass backend;
>                 fastcgi_index index.php;
>                 fastcgi_connect_timeout 1;
>                 fastcgi_send_timeout 1;
>                 include fastcgi_params;
>  }
> 
> В результате я хотел бы получить при обращении к URL http://site.com/page-10
> в параметре REQUEST_URI передаваемому fastcgi-серверу значние вида:
> /router?page=10
> Сейчас в REQUEST_URI передаётся переменная $request_uri со значением
> "/page-10", а переменная $uri содержит "/index.php"
> 
> Подскажите пожалуйста, как это можно сделать, особенно хотелось бы обойтись
> без if .. set
> В крайнем случае устроил бы и всего один rewrite, но нужно так или иначе
> предавать в fastcgi модифицированный вариант URI.

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

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


From ksyblast at gmail.com  Thu Mar 20 18:20:46 2014
From: ksyblast at gmail.com (=?KOI8-R?B?69PFzsnRIODS2MXXzsEg4szB3dXL?=)
Date: Thu, 20 Mar 2014 21:20:46 +0300
Subject: =?UTF-8?B?UmU6INC90LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINCyINGB0LLRj9C30Lo=?=
 =?UTF-8?B?0LUgbmdpbngrYXBhY2hl?=
In-Reply-To: <CACz2Q8EY=Aa_B+T0ouDxGG-0+j8jVKVXgVfwZ344cm3umoLhGg@mail.gmail.com>
References: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
 <1553863.0nj9pZmGWM@vbart-laptop>
 <CACz2Q8EY=Aa_B+T0ouDxGG-0+j8jVKVXgVfwZ344cm3umoLhGg@mail.gmail.com>
Message-ID: <CAMvGrGcYK2pnWgjGpb2xLNB-KuhCXUUjfP4UpV0f77a9kDHiVA@mail.gmail.com>

>>А X-Accel-Redirect заказчика никак не удовлетворит?
Возможно. Спасибо, попробуем.


20 марта 2014 г., 19:47 пользователь Bogdan <bogdar at gmail.com> написал:

> А X-Accel-Redirect заказчика никак не удовлетворит?
>
>
> 2014-03-20 17:32 GMT+03:00 Валентин Бартенев <vbart at nginx.com>:
>
> On Thursday 20 March 2014 15:17:57 Ксения Юрьевна Блащук wrote:
>> > Добрый день.
>> >
>> > Помогите пожалуйста разобраться, в каком месте проблема. Имеется проект
>> по
>> > отложенному просмотру телепередач. Видео записывается в файлы по одному
>> > часу каждый. При просмотре передач видео собирается из нескольких файлов
>> > или же файл проигрывается с определенного и до определенного момента (в
>> > соответствии с телепрограммой), это реализовано средствами php.
>> Проблема в
>> > том,
>> > что в связке nginx+apache скорость отдачи файла <=200КБ/c, что вызывает
>> > тормоза с видео и звуком. Многочисленные манипуляции с буферами в nginx
>> > ничего не дали.
>> >
>> > Отдельно nginx файлы отдаются без проблем (без этих наворотов с php),
>> > отдельно apache тоже (с php).
>> > Если просто качать файл через связку (опять же без наворотов c php), то
>> > проблем нет.
>> >
>> > Пожалуйста, дайте совет, в какую сторону копать? Откуда может браться
>> это
>> > ограничение в 200 КБ/c и кто виноват?
>> >
>>
>> Копайте в сторону http://nginx.org/r/proxy_max_temp_file_size/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/20140320/87b024c1/attachment.html>

From ksyblast at gmail.com  Thu Mar 20 18:23:00 2014
From: ksyblast at gmail.com (=?KOI8-R?B?69PFzsnRIODS2MXXzsEg4szB3dXL?=)
Date: Thu, 20 Mar 2014 21:23:00 +0300
Subject: =?UTF-8?B?UmU6INC90LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINCyINGB0LLRj9C30Lo=?=
 =?UTF-8?B?0LUgbmdpbngrYXBhY2hl?=
In-Reply-To: <1553863.0nj9pZmGWM@vbart-laptop>
References: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
 <1553863.0nj9pZmGWM@vbart-laptop>
Message-ID: <CAMvGrGdBuSj3y815FmPp22-WfQeS8C8D+fWMT0VdAOuVup=MJQ@mail.gmail.com>

 <http://nginx.org/r/proxy_max_temp_file_size/ru>
Пробовала - без изменений, те же 200кб/c (.


20 марта 2014 г., 17:32 пользователь Валентин Бартенев <vbart at nginx.com>написал:

> On Thursday 20 March 2014 15:17:57 Ксения Юрьевна Блащук wrote:
> > Добрый день.
> >
> > Помогите пожалуйста разобраться, в каком месте проблема. Имеется проект
> по
> > отложенному просмотру телепередач. Видео записывается в файлы по одному
> > часу каждый. При просмотре передач видео собирается из нескольких файлов
> > или же файл проигрывается с определенного и до определенного момента (в
> > соответствии с телепрограммой), это реализовано средствами php. Проблема
> в
> > том,
> > что в связке nginx+apache скорость отдачи файла <=200КБ/c, что вызывает
> > тормоза с видео и звуком. Многочисленные манипуляции с буферами в nginx
> > ничего не дали.
> >
> > Отдельно nginx файлы отдаются без проблем (без этих наворотов с php),
> > отдельно apache тоже (с php).
> > Если просто качать файл через связку (опять же без наворотов c php), то
> > проблем нет.
> >
> > Пожалуйста, дайте совет, в какую сторону копать? Откуда может браться это
> > ограничение в 200 КБ/c и кто виноват?
> >
>
> Копайте в сторону http://nginx.org/r/proxy_max_temp_file_size/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/20140320/a561304c/attachment.html>

From gmm at csdoc.com  Thu Mar 20 19:12:37 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Thu, 20 Mar 2014 21:12:37 +0200
Subject: =?UTF-8?B?UmU6INC90LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINCyINGB0LLRj9C30Lo=?=
 =?UTF-8?B?0LUgbmdpbngrYXBhY2hl?=
In-Reply-To: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
References: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
Message-ID: <532B3DA5.8070701@csdoc.com>

On 20.03.2014 14:17, Ксения Юрьевна Блащук wrote:

> Помогите пожалуйста разобраться, в каком месте проблема. Имеется проект
> по отложенному просмотру телепередач. Видео записывается в файлы по
> одному часу каждый. При просмотре передач видео собирается из нескольких
> файлов или же файл проигрывается с определенного и до определенного
> момента (в соответствии с телепрограммой), это реализовано средствами
> php. Проблема в том,
> что в связке nginx+apache скорость отдачи файла <=200КБ/c, что вызывает
> тормоза с видео и звуком. Многочисленные манипуляции с буферами в nginx
> ничего не дали.
>
> Отдельно nginx файлы отдаются без проблем (без этих наворотов с php),
> отдельно apache тоже (с php).
> Если просто качать файл через связку (опять же без наворотов c php), то
> проблем нет.
>
> Пожалуйста, дайте совет, в какую сторону копать? Откуда может браться
> это ограничение в 200 КБ/c и кто виноват?

php скрипт может выставлять в ответе
заголовок X-Accel-Limit-Rate на который реагирует nginx:

http://nginx.org/ru/docs/http/ngx_http_core_module.html#limit_rate

какие именно заголовки возвращает
php скрипт можно посмотреть с помощью curl:

curl -I http://.......................

-- 
Best regards,
  Gena


From schors at gmail.com  Thu Mar 20 19:17:40 2014
From: schors at gmail.com (Phil Kulin)
Date: Thu, 20 Mar 2014 23:17:40 +0400
Subject: =?UTF-8?B?U1NMINC4INCw0LvQs9C+0YDQuNGC0LzRiyDQk9Ce0KHQog==?=
Message-ID: <CAK=u2EVHd=4yfCQa5e7_Dy5SE5ZrakJtV+aP14wrzaepPCZK6w@mail.gmail.com>

Есть nginx, хочется делать соединение SSL с ГОСТовскими ключами. В том
числе приём клиентских сертификатов. Стоит OpenSSL 1.0.1, конфиг есть,
BIND например всё видит и домены ключами ГОСТ подписаны (где-то здесь
минутка саморекламы :).

В nginx надо что-то прописывать особенное? Или "сам поймёт"? Или
наоборот "не поймёт"?

-- 
Non nobis Domine non nobis sed Nomini Tuo da gloriam
Phil Kulin

From igor at sysoev.ru  Thu Mar 20 19:26:35 2014
From: igor at sysoev.ru (Igor Sysoev)
Date: Thu, 20 Mar 2014 23:26:35 +0400
Subject: =?UTF-8?B?UmU6IFNTTCDQuCDQsNC70LPQvtGA0LjRgtC80Ysg0JPQntCh0KI=?=
In-Reply-To: <CAK=u2EVHd=4yfCQa5e7_Dy5SE5ZrakJtV+aP14wrzaepPCZK6w@mail.gmail.com>
References: <CAK=u2EVHd=4yfCQa5e7_Dy5SE5ZrakJtV+aP14wrzaepPCZK6w@mail.gmail.com>
Message-ID: <AE3D2611-15E1-4BB1-8AAA-AC91A60FC036@sysoev.ru>

On Mar 20, 2014, at 23:17 , Phil Kulin wrote:

> Есть nginx, хочется делать соединение SSL с ГОСТовскими ключами. В том
> числе приём клиентских сертификатов. Стоит OpenSSL 1.0.1, конфиг есть,
> BIND например всё видит и домены ключами ГОСТ подписаны (где-то здесь
> минутка саморекламы :).
> 
> В nginx надо что-то прописывать особенное? Или "сам поймёт"? Или
> наоборот "не поймёт"?

Насчёт клиентских сертификатов сказать не могу, а вообще должно работать.


-- 
Igor Sysoev
http://nginx.com


From vbart at nginx.com  Thu Mar 20 19:28:17 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 20 Mar 2014 23:28:17 +0400
Subject: =?UTF-8?B?UmU6INC90LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINCyINGB0LLRj9C30Lo=?=
 =?UTF-8?B?0LUgbmdpbngrYXBhY2hl?=
In-Reply-To: <CAMvGrGdBuSj3y815FmPp22-WfQeS8C8D+fWMT0VdAOuVup=MJQ@mail.gmail.com>
References: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
 <1553863.0nj9pZmGWM@vbart-laptop>
 <CAMvGrGdBuSj3y815FmPp22-WfQeS8C8D+fWMT0VdAOuVup=MJQ@mail.gmail.com>
Message-ID: <2170183.NRzq6IoL7T@vbart-laptop>

On Thursday 20 March 2014 21:23:00 Ксения Юрьевна Блащук wrote:
>  <http://nginx.org/r/proxy_max_temp_file_size/ru>
> Пробовала - без изменений, те же 200кб/c (.
> 

А что пробовали?  Без полного конфига вообще сложно что-то подсказать.

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

From schors at gmail.com  Thu Mar 20 19:28:54 2014
From: schors at gmail.com (Phil Kulin)
Date: Thu, 20 Mar 2014 23:28:54 +0400
Subject: =?UTF-8?B?UmU6IFNTTCDQuCDQsNC70LPQvtGA0LjRgtC80Ysg0JPQntCh0KI=?=
In-Reply-To: <AE3D2611-15E1-4BB1-8AAA-AC91A60FC036@sysoev.ru>
References: <CAK=u2EVHd=4yfCQa5e7_Dy5SE5ZrakJtV+aP14wrzaepPCZK6w@mail.gmail.com>
 <AE3D2611-15E1-4BB1-8AAA-AC91A60FC036@sysoev.ru>
Message-ID: <CAK=u2EVGAJqAwD=WeNX_iehRz2P3oOtj0Yk4+1d6+VCxhmqhaw@mail.gmail.com>

20 марта 2014 г., 23:26 пользователь Igor Sysoev <igor at sysoev.ru> написал:

>> Есть nginx, хочется делать соединение SSL с ГОСТовскими ключами. В том
>> числе приём клиентских сертификатов. Стоит OpenSSL 1.0.1, конфиг есть,
>> BIND например всё видит и домены ключами ГОСТ подписаны (где-то здесь
>> минутка саморекламы :).
>> В nginx надо что-то прописывать особенное? Или "сам поймёт"? Или
>> наоборот "не поймёт"?
> Насчёт клиентских сертификатов сказать не могу, а вообще должно работать.

А вот этот список ssl_cipher? По умолчанию оставить? Просто в том же
BIND надо чего-то сказать ему при сборке. Но я плохо разбираюсь в
библиотеке

-- 
Non nobis Domine non nobis sed Nomini Tuo da gloriam
Phil Kulin

From igor at sysoev.ru  Thu Mar 20 19:39:32 2014
From: igor at sysoev.ru (Igor Sysoev)
Date: Thu, 20 Mar 2014 23:39:32 +0400
Subject: =?UTF-8?B?UmU6IFNTTCDQuCDQsNC70LPQvtGA0LjRgtC80Ysg0JPQntCh0KI=?=
In-Reply-To: <CAK=u2EVGAJqAwD=WeNX_iehRz2P3oOtj0Yk4+1d6+VCxhmqhaw@mail.gmail.com>
References: <CAK=u2EVHd=4yfCQa5e7_Dy5SE5ZrakJtV+aP14wrzaepPCZK6w@mail.gmail.com>
 <AE3D2611-15E1-4BB1-8AAA-AC91A60FC036@sysoev.ru>
 <CAK=u2EVGAJqAwD=WeNX_iehRz2P3oOtj0Yk4+1d6+VCxhmqhaw@mail.gmail.com>
Message-ID: <D97BD125-D020-4E6D-AC0C-D13F33582247@sysoev.ru>

On Mar 20, 2014, at 23:28 , Phil Kulin wrote:

> 20 марта 2014 г., 23:26 пользователь Igor Sysoev <igor at sysoev.ru> написал:
> 
>>> Есть nginx, хочется делать соединение SSL с ГОСТовскими ключами. В том
>>> числе приём клиентских сертификатов. Стоит OpenSSL 1.0.1, конфиг есть,
>>> BIND например всё видит и домены ключами ГОСТ подписаны (где-то здесь
>>> минутка саморекламы :).
>>> В nginx надо что-то прописывать особенное? Или "сам поймёт"? Или
>>> наоборот "не поймёт"?
>> Насчёт клиентских сертификатов сказать не могу, а вообще должно работать.
> 
> А вот этот список ssl_cipher? По умолчанию оставить? Просто в том же
> BIND надо чего-то сказать ему при сборке. Но я плохо разбираюсь в
> библиотеке

По-моему, ничего не нужно специально настраивать, достаточно правильного
/etc/openssl.conf.

Если не получится, то

ssl_engine  gost;

http {
   ssl_ciphers  "GOST2001-GOST89-GOST89";
   ...



-- 
Igor Sysoev
http://nginx.com


From schors at gmail.com  Thu Mar 20 21:08:29 2014
From: schors at gmail.com (Phil Kulin)
Date: Fri, 21 Mar 2014 01:08:29 +0400
Subject: =?UTF-8?B?UmU6IFNTTCDQuCDQsNC70LPQvtGA0LjRgtC80Ysg0JPQntCh0KI=?=
In-Reply-To: <D97BD125-D020-4E6D-AC0C-D13F33582247@sysoev.ru>
References: <CAK=u2EVHd=4yfCQa5e7_Dy5SE5ZrakJtV+aP14wrzaepPCZK6w@mail.gmail.com>
 <AE3D2611-15E1-4BB1-8AAA-AC91A60FC036@sysoev.ru>
 <CAK=u2EVGAJqAwD=WeNX_iehRz2P3oOtj0Yk4+1d6+VCxhmqhaw@mail.gmail.com>
 <D97BD125-D020-4E6D-AC0C-D13F33582247@sysoev.ru>
Message-ID: <CAK=u2EX_48YTYX7FvHjx7Dy4w7-8VCyhkk9tcrh2Qv+Syf-k0Q@mail.gmail.com>

20 марта 2014 г., 23:39 пользователь Igor Sysoev <igor at sysoev.ru> написал:

> По-моему, ничего не нужно специально настраивать, достаточно правильного
> /etc/openssl.conf.
> Если не получится, то
> ssl_engine  gost;
> http {
>    ssl_ciphers  "GOST2001-GOST89-GOST89";
>    ...

Спасибо. Практика показывает, что работает без этого. А проблема моя
состояла в том, что я сделал USR1 после пересборки nginx вместо
полного перезапуска :)

Однако то ли вопрос, то ли фичреквест - а можно как-нибудь узнать с
каким OpenSSL собрано (например, если собирать из портов с
WITH_OPENSSL_PORT=yes, то configure самого nginx выдаёт With OpenSSL
System, при этом собирается таки с портовым)? Если никак, то может
сделать ключик или выдавать по -V? Те же возможные engine и ciphers?

-- 
Non nobis Domine non nobis sed Nomini Tuo da gloriam
Phil Kulin

From vbart at nginx.com  Thu Mar 20 21:47:54 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 21 Mar 2014 01:47:54 +0400
Subject: =?UTF-8?B?UmU6IFNTTCDQuCDQsNC70LPQvtGA0LjRgtC80Ysg0JPQntCh0KI=?=
In-Reply-To: <CAK=u2EX_48YTYX7FvHjx7Dy4w7-8VCyhkk9tcrh2Qv+Syf-k0Q@mail.gmail.com>
References: <CAK=u2EVHd=4yfCQa5e7_Dy5SE5ZrakJtV+aP14wrzaepPCZK6w@mail.gmail.com>
 <D97BD125-D020-4E6D-AC0C-D13F33582247@sysoev.ru>
 <CAK=u2EX_48YTYX7FvHjx7Dy4w7-8VCyhkk9tcrh2Qv+Syf-k0Q@mail.gmail.com>
Message-ID: <2771942.mRRRA78DQT@vbart-laptop>

On Friday 21 March 2014 01:08:29 Phil Kulin wrote:
> 20 марта 2014 г., 23:39 пользователь Igor Sysoev <igor at sysoev.ru> написал:
> 
> > По-моему, ничего не нужно специально настраивать, достаточно правильного
> > /etc/openssl.conf.
> > Если не получится, то
> > ssl_engine  gost;
> > http {
> >    ssl_ciphers  "GOST2001-GOST89-GOST89";
> >    ...
> 
> Спасибо. Практика показывает, что работает без этого. А проблема моя
> состояла в том, что я сделал USR1 после пересборки nginx вместо
> полного перезапуска :)
> 
> Однако то ли вопрос, то ли фичреквест - а можно как-нибудь узнать с
> каким OpenSSL собрано (например, если собирать из портов с
> WITH_OPENSSL_PORT=yes, то configure самого nginx выдаёт With OpenSSL
> System, при этом собирается таки с портовым)?

man ldd

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

From schors at gmail.com  Fri Mar 21 07:23:51 2014
From: schors at gmail.com (Phil Kulin)
Date: Fri, 21 Mar 2014 11:23:51 +0400
Subject: =?UTF-8?B?0LDRg9GC0LXQvdGC0LjRhNC40LrQsNGG0LjRjyDQv9C+INC60LvQuNC10L3RgtGB?=
 =?UTF-8?B?0LrQvtC80YMg0YHQtdGA0YLQuNGE0LjQutCw0YLRgyBTU0w=?=
Message-ID: <CAK=u2EVPDjQ=sx+an+KPVk0vWusjnqKTfCkEbzu0z+T4n9Ta8g@mail.gmail.com>

Собственно вопрос не новый, но вдруг что-то изменилось.
1. Есть ли какой-то способ клиенту, который не предоставил сертификат
вдруг его подставить и аутентифицироваться им?
2. Возможно ли насильно сбросить соединение с клиентом? Это решало бы
не только эту проблему. Грубовато, но часто действенно.

-- 
Non nobis Domine non nobis sed Nomini Tuo da gloriam
Phil Kulin

From pavel2000 at ngs.ru  Fri Mar 21 07:28:59 2014
From: pavel2000 at ngs.ru (Pavel V.)
Date: Fri, 21 Mar 2014 14:28:59 +0700
Subject: =?UTF-8?B?UmU6INCw0YPRgtC10L3RgtC40YTQuNC60LDRhtC40Y8g0L/QviDQutC70LjQtdC9?=
 =?UTF-8?B?0YLRgdC60L7QvNGDINGB0LXRgNGC0LjRhNC40LrQsNGC0YMgU1NM?=
In-Reply-To: <CAK=u2EVPDjQ=sx+an+KPVk0vWusjnqKTfCkEbzu0z+T4n9Ta8g@mail.gmail.com>
References: <CAK=u2EVPDjQ=sx+an+KPVk0vWusjnqKTfCkEbzu0z+T4n9Ta8g@mail.gmail.com>
Message-ID: <184885228.20140321142859@ngs.ru>

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

Вы писали 21 марта 2014 г., 14:23:51:

> Собственно вопрос не новый, но вдруг что-то изменилось.
> 1. Есть ли какой-то способ клиенту, который не предоставил сертификат
> вдруг его подставить и аутентифицироваться им?

Что значит "вдруг"? Вы про HTTP говорите?

> 2. Возможно ли насильно сбросить соединение с клиентом? Это решало бы
> не только эту проблему. Грубовато, но часто действенно.

http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#return код 444



-- 
С уважением,
 Pavel                          mailto:pavel2000 at ngs.ru


From schors at gmail.com  Fri Mar 21 07:58:30 2014
From: schors at gmail.com (Phil Kulin)
Date: Fri, 21 Mar 2014 11:58:30 +0400
Subject: =?UTF-8?B?UmU6INCw0YPRgtC10L3RgtC40YTQuNC60LDRhtC40Y8g0L/QviDQutC70LjQtdC9?=
 =?UTF-8?B?0YLRgdC60L7QvNGDINGB0LXRgNGC0LjRhNC40LrQsNGC0YMgU1NM?=
In-Reply-To: <184885228.20140321142859@ngs.ru>
References: <CAK=u2EVPDjQ=sx+an+KPVk0vWusjnqKTfCkEbzu0z+T4n9Ta8g@mail.gmail.com>
 <184885228.20140321142859@ngs.ru>
Message-ID: <CAK=u2EWRsUcReJwKy5WQQqdgiJxvtY6fzB0dNixW=YupovcekQ@mail.gmail.com>

21 марта 2014 г., 11:28 пользователь Pavel V. <pavel2000 at ngs.ru> написал:

>> Собственно вопрос не новый, но вдруг что-то изменилось.
>> 1. Есть ли какой-то способ клиенту, который не предоставил сертификат
>> вдруг его подставить и аутентифицироваться им?
> Что значит "вдруг"? Вы про HTTP говорите?

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

>> 2. Возможно ли насильно сбросить соединение с клиентом? Это решало бы
>> не только эту проблему. Грубовато, но часто действенно.
> http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#return код 444

Вот куда я не посмотрел. Да. Это вариант.

-- 
Non nobis Domine non nobis sed Nomini Tuo da gloriam
Phil Kulin

From pavel2000 at ngs.ru  Fri Mar 21 09:45:02 2014
From: pavel2000 at ngs.ru (Pavel V.)
Date: Fri, 21 Mar 2014 16:45:02 +0700
Subject: =?UTF-8?B?UmU6INCw0YPRgtC10L3RgtC40YTQuNC60LDRhtC40Y8g0L/QviDQutC70LjQtdC9?=
 =?UTF-8?B?0YLRgdC60L7QvNGDINGB0LXRgNGC0LjRhNC40LrQsNGC0YMgU1NM?=
In-Reply-To: <CAK=u2EWRsUcReJwKy5WQQqdgiJxvtY6fzB0dNixW=YupovcekQ@mail.gmail.com>
References: <CAK=u2EVPDjQ=sx+an+KPVk0vWusjnqKTfCkEbzu0z+T4n9Ta8g@mail.gmail.com>
 <184885228.20140321142859@ngs.ru>
 <CAK=u2EWRsUcReJwKy5WQQqdgiJxvtY6fzB0dNixW=YupovcekQ@mail.gmail.com>
Message-ID: <414294457.20140321164502@ngs.ru>

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

Вы писали 21 марта 2014 г., 14:58:30:

> 21 марта 2014 г., 11:28 пользователь Pavel V. <pavel2000 at ngs.ru> написал:

>>> Собственно вопрос не новый, но вдруг что-то изменилось.
>>> 1. Есть ли какой-то способ клиенту, который не предоставил сертификат
>>> вдруг его подставить и аутентифицироваться им?
>> Что значит "вдруг"? Вы про HTTP говорите?

> HTTPS. Клиент получил сертификат, установил его, я хочу его
> аутентифицировать по нему. Насколько я понимаю, сейчас должен или
> истечь таймаут сессии, или он должен закрыть/открыть браузер.

Если в этом действительно имеется проблема (лично я с такой ситуацией не сталкивался и практического
опыта не имею), то одним из решений может быть "разнести домены авторизации и получения
сертификата".  Может быть достаточно будет разнести в разные локейшны ssl_verify_client on и off.


-- 
С уважением,
 Pavel                          mailto:pavel2000 at ngs.ru


From schors at gmail.com  Fri Mar 21 12:16:14 2014
From: schors at gmail.com (Phil Kulin)
Date: Fri, 21 Mar 2014 16:16:14 +0400
Subject: =?UTF-8?B?0L3QtSDQvdCw0YHQu9C10LTRg9GO0YLRgdGPINC90LXQutC+0YLQvtGA0YvQtSA=?=
 =?UTF-8?B?0LTQuNGA0LXQutGC0LjQstGLINC/0YDQuCBTU0wt0YHQvtC10LTQuNC90LU=?=
 =?UTF-8?B?0L3QuNC4?=
Message-ID: <CAK=u2EVGZNH0tVEAZLui+yXWiqKbcoasBtzqOX7zJ=yOYkTc-A@mail.gmail.com>

 Давно уже заметил, сейчас только беспокоить стало. Есть вот такая конструкция:

http {
       proxy_set_header        X-Real-IP $remote_addr;
       server {
                 listen 192.168.0.2:80 default_server;
                 listen 192.168.0.2:443 default_server ssl;
....
       }
....
}

При обычном соединении HTTP - заголовок X-Real-IP приходит на бэкенд.
При HTTPS - нет. Если proxy_set_header продублировать в секцию server
- всё нормально.
Я ещё на 0.7.чтототам заметил. На 1.4.5 воспроизводится.

Всё не так страшно, но хотелось бы понимать, какие директивы
наследуются, а какие нет. Что надо тащить с собой, а что нет.

-- 
Non nobis Domine non nobis sed Nomini Tuo da gloriam
Phil Kulin

From vbart at nginx.com  Fri Mar 21 12:18:54 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 21 Mar 2014 16:18:54 +0400
Subject: =?UTF-8?B?UmU6INC90LUg0L3QsNGB0LvQtdC00YPRjtGC0YHRjyDQvdC10LrQvtGC0L7RgNGL?=
 =?UTF-8?B?0LUg0LTQuNGA0LXQutGC0LjQstGLINC/0YDQuCBTU0wt0YHQvtC10LTQuNC9?=
 =?UTF-8?B?0LXQvdC40Lg=?=
In-Reply-To: <CAK=u2EVGZNH0tVEAZLui+yXWiqKbcoasBtzqOX7zJ=yOYkTc-A@mail.gmail.com>
References: <CAK=u2EVGZNH0tVEAZLui+yXWiqKbcoasBtzqOX7zJ=yOYkTc-A@mail.gmail.com>
Message-ID: <3754457.YM5UaeqTtm@vbart-laptop>

On Friday 21 March 2014 16:16:14 Phil Kulin wrote:
>  Давно уже заметил, сейчас только беспокоить стало. Есть вот такая 
конструкция:
> 
> http {
>        proxy_set_header        X-Real-IP $remote_addr;
>        server {
>                  listen 192.168.0.2:80 default_server;
>                  listen 192.168.0.2:443 default_server ssl;
> ....
>        }
> ....
> }
> 
> При обычном соединении HTTP - заголовок X-Real-IP приходит на бэкенд.
> При HTTPS - нет. Если proxy_set_header продублировать в секцию server
> - всё нормально.
> Я ещё на 0.7.чтототам заметил. На 1.4.5 воспроизводится.
> 
> Всё не так страшно, но хотелось бы понимать, какие директивы
> наследуются, а какие нет. Что надо тащить с собой, а что нет.
> 

http://nginx.org/r/proxy_set_header/ru

Третье по счету предложение.

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

From citrin at citrin.ru  Fri Mar 21 12:20:07 2014
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Fri, 21 Mar 2014 16:20:07 +0400
Subject: =?UTF-8?B?UmU6INC90LUg0L3QsNGB0LvQtdC00YPRjtGC0YHRjyDQvdC10LrQvtGC0L7RgNGL?=
 =?UTF-8?B?0LUg0LTQuNGA0LXQutGC0LjQstGLINC/0YDQuCBTU0wt0YHQvtC10LTQuNC9?=
 =?UTF-8?B?0LXQvdC40Lg=?=
In-Reply-To: <CAK=u2EVGZNH0tVEAZLui+yXWiqKbcoasBtzqOX7zJ=yOYkTc-A@mail.gmail.com>
References: <CAK=u2EVGZNH0tVEAZLui+yXWiqKbcoasBtzqOX7zJ=yOYkTc-A@mail.gmail.com>
Message-ID: <532C2E77.1090202@citrin.ru>

On 03/21/14 16:16, Phil Kulin wrote:
>   Давно уже заметил, сейчас только беспокоить стало. Есть вот такая конструкция:
>
> http {
>         proxy_set_header        X-Real-IP $remote_addr;
>         server {
>                   listen 192.168.0.2:80 default_server;
>                   listen 192.168.0.2:443 default_server ssl;
> ....
>         }
> ....
> }
>
> При обычном соединении HTTP - заголовок X-Real-IP приходит на бэкенд.
> При HTTPS - нет. Если proxy_set_header продублировать в секцию server
> - всё нормально.

proxy_set_header наследуется, но не аддитивно.
Т. е. если на уровне server нет никаких proxy_set_header, то наследуется набор 
proxy_set_header с уровня http.
Если есть - то не наследуется.

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


From ksyblast at gmail.com  Fri Mar 21 12:29:19 2014
From: ksyblast at gmail.com (=?KOI8-R?B?69PFzsnRIODS2MXXzsEg4szB3dXL?=)
Date: Fri, 21 Mar 2014 15:29:19 +0300
Subject: =?UTF-8?B?UmU6INC90LjQt9C60LDRjyDRgdC60L7RgNC+0YHRgtGMINCyINGB0LLRj9C30Lo=?=
 =?UTF-8?B?0LUgbmdpbngrYXBhY2hl?=
In-Reply-To: <2170183.NRzq6IoL7T@vbart-laptop>
References: <CAMvGrGdJpiZMPSbxP5JUPsNgGw+m0FQFhwpT1Dv4ZuFS887uqQ@mail.gmail.com>
 <1553863.0nj9pZmGWM@vbart-laptop>
 <CAMvGrGdBuSj3y815FmPp22-WfQeS8C8D+fWMT0VdAOuVup=MJQ@mail.gmail.com>
 <2170183.NRzq6IoL7T@vbart-laptop>
Message-ID: <CAMvGrGeYA56fqJFTGfHGftNS6nyb5HN-8eys0H-BAPiWMBD3iA@mail.gmail.com>

Короче говоря, проблема решилась внезапно и банально. Ответили разработчики:
В тв архиве запись должна отдаваться через apache в обход nginx.
Думаю, ковыряться дальше не имеет смысла.
Всем спасибо.




20 марта 2014 г., 22:28 пользователь Валентин Бартенев <vbart at nginx.com>написал:

> On Thursday 20 March 2014 21:23:00 Ксения Юрьевна Блащук wrote:
> >  <http://nginx.org/r/proxy_max_temp_file_size/ru>
> > Пробовала - без изменений, те же 200кб/c (.
> >
>
> А что пробовали?  Без полного конфига вообще сложно что-то подсказать.
>
> --
> Валентин Бартенев
> _______________________________________________
> 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/20140321/c84cb030/attachment.html>

From schors at gmail.com  Fri Mar 21 12:31:14 2014
From: schors at gmail.com (Phil Kulin)
Date: Fri, 21 Mar 2014 16:31:14 +0400
Subject: =?UTF-8?B?UmU6INC90LUg0L3QsNGB0LvQtdC00YPRjtGC0YHRjyDQvdC10LrQvtGC0L7RgNGL?=
 =?UTF-8?B?0LUg0LTQuNGA0LXQutGC0LjQstGLINC/0YDQuCBTU0wt0YHQvtC10LTQuNC9?=
 =?UTF-8?B?0LXQvdC40Lg=?=
In-Reply-To: <532C2E77.1090202@citrin.ru>
References: <CAK=u2EVGZNH0tVEAZLui+yXWiqKbcoasBtzqOX7zJ=yOYkTc-A@mail.gmail.com>
 <532C2E77.1090202@citrin.ru>
Message-ID: <CAK=u2EU=uAzRnP-SfDL4BgYupBV_rZj+htZsP3Q++Mp7h9XJ5A@mail.gmail.com>

21 марта 2014 г., 16:20 пользователь Anton Yuzhaninov
<citrin at citrin.ru> написал:

> proxy_set_header наследуется, но не аддитивно.
> Т. е. если на уровне server нет никаких proxy_set_header, то наследуется
> набор proxy_set_header с уровня http.
> Если есть - то не наследуется.
> Т. е. если хочется добавлять несколько заголовков - они все должны быть на
> одном уровне.

Вопрос снят. До меня плохо доходит написанное :)

-- 
Non nobis Domine non nobis sed Nomini Tuo da gloriam
Phil Kulin

From sshilovsky at gmail.com  Sun Mar 23 02:56:03 2014
From: sshilovsky at gmail.com (Sergei Shilovsky)
Date: Sun, 23 Mar 2014 06:56:03 +0400
Subject: =?UTF-8?B?0LTQvtGB0YLRg9C/INC6INC60L7QvdGE0LjQs9GD0YDQsNGG0LjQuCDQvNC+0LQ=?=
 =?UTF-8?B?0YPQu9GPINCyINGF0YPQutC1IGluaXRfcHJvY2Vzcw==?=
Message-ID: <CAHc2pO1=wKAsVVvQbEbTNqCTEuUK7bvM6=wKisC0NruQf_br7g@mail.gmail.com>

Добрый день.

Пишу модуль, в конфиге есть такой блок:

`http { pgconfig_connection "host=localhost dbname=db ..."; ... }`

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

Сейчас для этого в `init_main_conf` дублирую строку в глобальную
переменную, которую использую в `init_process`.

Но интересно, есть ли надежный (и простой) способ в хуке `init_process`
получить доступ к конфигурации модуля по структуре `ngx_cycle_t`?

Если нет, подскажите, пожалуйста, как правильно инициализировать соединение
процесса.

Спасибо

-- 
С уважением,
Сергей Шиловский
Sergei Shilovsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140323/16597aee/attachment.html>

From vadim.lazovskiy at gmail.com  Sun Mar 23 08:11:21 2014
From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy)
Date: Sun, 23 Mar 2014 12:11:21 +0400
Subject: =?UTF-8?B?UmU6INC00L7RgdGC0YPQvyDQuiDQutC+0L3RhNC40LPRg9GA0LDRhtC40Lgg0Lw=?=
 =?UTF-8?B?0L7QtNGD0LvRjyDQsiDRhdGD0LrQtSBpbml0X3Byb2Nlc3M=?=
In-Reply-To: <CAHc2pO1=wKAsVVvQbEbTNqCTEuUK7bvM6=wKisC0NruQf_br7g@mail.gmail.com>
References: <CAHc2pO1=wKAsVVvQbEbTNqCTEuUK7bvM6=wKisC0NruQf_br7g@mail.gmail.com>
Message-ID: <CAL-L5YBA+2y3PUH0=no6rKxfKL+B38r_qfmf8LQTVcvSOeuMxw@mail.gmail.com>

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

cf = ngx_http_cycle_get_module_main_conf(cycle, your_module);

как-то так, вроде.


23 марта 2014 г., 6:56 пользователь Sergei Shilovsky
<sshilovsky at gmail.com>написал:

> Добрый день.
>
> Пишу модуль, в конфиге есть такой блок:
>
> `http { pgconfig_connection "host=localhost dbname=db ..."; ... }`
>
> Эта строка используется для подключения к БД, причем на каждый рабочий
> процесс планируется одно подключение.
>
> Сейчас для этого в `init_main_conf` дублирую строку в глобальную
> переменную, которую использую в `init_process`.
>
> Но интересно, есть ли надежный (и простой) способ в хуке `init_process`
> получить доступ к конфигурации модуля по структуре `ngx_cycle_t`?
>
> Если нет, подскажите, пожалуйста, как правильно инициализировать
> соединение процесса.
>
> Спасибо
>
> --
> С уважением,
> Сергей Шиловский
> Sergei Shilovsky
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
Best Regards,
Vadim Lazovskiy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140323/b60caf26/attachment.html>

From nginx-forum at nginx.us  Mon Mar 24 04:45:53 2014
From: nginx-forum at nginx.us (softshape)
Date: Mon, 24 Mar 2014 00:45:53 -0400
Subject: =?UTF-8?B?0J7Rh9C10L3RjCDRgdGC0YDQsNC90L3Ri9C1INGC0L7RgNC80L7Qt9Cw?=
Message-ID: <5e9bc6958c1e4335c51674ebadf64f3e.NginxMailingListRussian@forum.nginx.org>

Всем привет,

у нас наблюдается странный тормоз при проксировании через Nginx, я не могу
понять его природу. 

На днях я подключил новую вебкамеру - http://94.154.80.37:3456/image
Открывается в браузере за доли секунды.

Чтобы не отсвечивать на сайте IP'шник, делаю прокси через Nginx -

    location /r/webcam3/ {
        proxy_pass
http://94.154.80.37:3456/image?res=half&quality=18&doublescan=1;
        proxy_set_header host 94.154.80.37:3456;
    }

Если я прямо на сервере делаю wget http://www.irk.fm/r/webcam3/, запрос
также отрабатывает моментально - 0.008 сек. Но в браузере адрес
http://www.irk.fm/r/webcam3/ висит около 5 секунд прежде, чем показать
картинку.

При этом "просто картинки" с сервера отдаются нормально - легко проверить,
зайдя на сам сайт. Я хотел было написать "...а завернутая в Nginx картинка
тормозит" - но ведь wget её на самом сервере срабатывает моментально.
Тормозит она только при запросе из браузера и вот этого я никак не могу
понять...

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


From ilvin at mail.ru  Mon Mar 24 06:09:53 2014
From: ilvin at mail.ru (=?UTF-8?B?0JjQu9GM0Y8g0JLQuNC90L7QutGD0YDQvtCy?=)
Date: Mon, 24 Mar 2014 10:09:53 +0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0YHRgtGA0LDQvdC90YvQtSDRgtC+0YDQvNC+0LfQsA==?=
In-Reply-To: <5e9bc6958c1e4335c51674ebadf64f3e.NginxMailingListRussian@forum.nginx.org>
References: <5e9bc6958c1e4335c51674ebadf64f3e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1395641393.890925819@f210.i.mail.ru>


Из Москвы открылось моментально. В чем проблема-то?

С почтением,
  Илья Винокуров.

Mon, 24 Mar 2014 00:45:53 -0400 от "softshape" <nginx-forum at nginx.us>:
>Всем привет,
>
>у нас наблюдается странный тормоз при проксировании через Nginx, я не могу
>понять его природу. 
>
>На днях я подключил новую вебкамеру -  http://94.154.80.37:3456/image
>Открывается в браузере за доли секунды.
>
>Чтобы не отсвечивать на сайте IP'шник, делаю прокси через Nginx -
>
>    location /r/webcam3/ {
>        proxy_pass
>http://94.154.80.37:3456/image?res=half&quality=18&doublescan=1;
>        proxy_set_header host 94.154.80.37:3456;
>    }
>
>Если я прямо на сервере делаю wget  http://www.irk.fm/r/webcam3/ , запрос
>также отрабатывает моментально - 0.008 сек. Но в браузере адрес
>http://www.irk.fm/r/webcam3/ висит около 5 секунд прежде, чем показать
>картинку.
>
>При этом "просто картинки" с сервера отдаются нормально - легко проверить,
>зайдя на сам сайт. Я хотел было написать "...а завернутая в Nginx картинка
>тормозит" - но ведь wget её на самом сервере срабатывает моментально.
>Тормозит она только при запросе из браузера и вот этого я никак не могу
>понять...
>
>Posted at Nginx Forum:  http://forum.nginx.org/read.php?21,248605,248605#msg-248605
>
>_______________________________________________
>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/20140324/031766d9/attachment.html>

From nginx-forum at nginx.us  Mon Mar 24 06:32:47 2014
From: nginx-forum at nginx.us (softshape)
Date: Mon, 24 Mar 2014 02:32:47 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0YHRgtGA0LDQvdC90YvQtSDRgtC+0YDQvNC+0LfQsA==?=
In-Reply-To: <1395641393.890925819@f210.i.mail.ru>
References: <1395641393.890925819@f210.i.mail.ru>
Message-ID: <d2991d6b6b9f3c5897809467ea64d5b1.NginxMailingListRussian@forum.nginx.org>

Значит проблема локальная. Тоже хорошо :), спасибо за отзыв!

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


From nginx-forum at nginx.us  Mon Mar 24 13:22:04 2014
From: nginx-forum at nginx.us (skeletor)
Date: Mon, 24 Mar 2014 09:22:04 -0400
Subject: nginx + last rewrite
Message-ID: <6ded0365027664592104bf9b44f1f1f2.NginxMailingListRussian@forum.nginx.org>

Всем привет.
Не получается правильно написать last rewrite. Суть в следующем: при запросе
URL'a вида http://domain.com/events/blabla.html нужно его среврайтить на
http://domain.com/events/blabla.php и выполнить этот php не меняя основного
URL'a. На сервере в папке лежит именно events/blabla.php. Все остальные
php-скрипты отрабатываются нормально.
Вот код nginx'a

        location / {
                index index.php;
        }

        location /events {
                 rewrite ^/events/(.*)\.html$ $1.php last;
        }

        location ~ .php$ {
                include fastcgi_params;
                fastcgi_pass unix:/var/tmp/php.sock;
                fastcgi_index index.php;
                fastcgi_param DOCUMENT_ROOT /home/www/sites/domain.com;
                fastcgi_param SCRIPT_FILENAME
/home/www/sites/domain.com$fastcgi_script_name;
                fastcgi_param PATH_TRANSLATED
/home/www/sites/domain.com$fastcgi_script_name;
        }

Пробовал по-разному:
- выносил rewrite в корень сайта, помещал в lacation /
- добавлял fastcgi_ в location /events (пробовал разные вариации с
fastcgi_param SCRIPT_FILENAME)

При запросе в логе вот такое:

FastCGI sent in stderr: "Primary script unknown" while reading response
header from upstream, client: XX.XX.XX.XX, server: domain.com, request: "GET
/events/brand-awards-2013.html HTTP/1.1", upstream:
"fastcgi://unix:/var/tmp/php.sock:", host: "domain.com"

Я так понимаю, по какой-то причине не передаётся правильно сам php-скрипт
дальше, на fastcgi. Не могу понять, как это исправить.

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

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


From mdounin at mdounin.ru  Mon Mar 24 13:52:57 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 24 Mar 2014 17:52:57 +0400
Subject: nginx + last rewrite
In-Reply-To: <6ded0365027664592104bf9b44f1f1f2.NginxMailingListRussian@forum.nginx.org>
References: <6ded0365027664592104bf9b44f1f1f2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140324135257.GL34696@mdounin.ru>

Hello!

On Mon, Mar 24, 2014 at 09:22:04AM -0400, skeletor wrote:

> Всем привет.
> Не получается правильно написать last rewrite. Суть в следующем: при запросе
> URL'a вида http://domain.com/events/blabla.html нужно его среврайтить на
> http://domain.com/events/blabla.php и выполнить этот php не меняя основного
> URL'a. На сервере в папке лежит именно events/blabla.php. Все остальные
> php-скрипты отрабатываются нормально.

Правильное решение - сделать как-то так:

    location = /events/blabla.html {
        fastcgi_pass unix:/var/tmp/php.sock;
        fastcgi_param SCRIPT_FILENAME $document_root/events/blabla.php;
        include fastcgi_params;
    }

И не пытаться искать себе проблем не ровном месте.

Если очень хочется починить именно тот конфиг, который вы пытались 
писать, то проблема, вероятно, где-то тут:

>         location /events {
>                  rewrite ^/events/(.*)\.html$ $1.php last;
>         }

Вы убираете из URI префикс /events/, и в результате php не может 
найти скрипт - потому что он таки лежит в папке events.

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


From nginx-forum at nginx.us  Mon Mar 24 14:16:06 2014
From: nginx-forum at nginx.us (skeletor)
Date: Mon, 24 Mar 2014 10:16:06 -0400
Subject: nginx + last rewrite
In-Reply-To: <20140324135257.GL34696@mdounin.ru>
References: <20140324135257.GL34696@mdounin.ru>
Message-ID: <e375e92b514ac29a2a4f48a0962ac4a1.NginxMailingListRussian@forum.nginx.org>

Спасибо, Максим, получилось для конкретного html. Насколько я вас понял,
унифицировать для всех html не получится?

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


From nginx-forum at nginx.us  Mon Mar 24 14:20:38 2014
From: nginx-forum at nginx.us (skeletor)
Date: Mon, 24 Mar 2014 10:20:38 -0400
Subject: nginx + last rewrite
In-Reply-To: <e375e92b514ac29a2a4f48a0962ac4a1.NginxMailingListRussian@forum.nginx.org>
References: <20140324135257.GL34696@mdounin.ru>
 <e375e92b514ac29a2a4f48a0962ac4a1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <4beebd7b4e461d0c00a03b7ec33fd504.NginxMailingListRussian@forum.nginx.org>

Вот так заработало (переделал location events):

        location ~ /events/(.*)\.html {
                rewrite ^/events/(.*)\.html$ /events/$1.php last;
        }

Остальные блоки без изменений.

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


From mdounin at mdounin.ru  Mon Mar 24 14:22:30 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 24 Mar 2014 18:22:30 +0400
Subject: nginx + last rewrite
In-Reply-To: <e375e92b514ac29a2a4f48a0962ac4a1.NginxMailingListRussian@forum.nginx.org>
References: <20140324135257.GL34696@mdounin.ru>
 <e375e92b514ac29a2a4f48a0962ac4a1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140324142230.GO34696@mdounin.ru>

Hello!

On Mon, Mar 24, 2014 at 10:16:06AM -0400, skeletor wrote:

> Спасибо, Максим, получилось для конкретного html. Насколько я вас понял,
> унифицировать для всех html не получится?

Получится, но писать конфиг на rewrite'ах - это плохой путь.

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


From koticka at mail.ru  Mon Mar 24 16:02:54 2014
From: koticka at mail.ru (Kostya Alexandrov)
Date: Mon, 24 Mar 2014 20:02:54 +0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0YHRgtGA0LDQvdC90YvQtSDRgtC+0YDQvNC+0LfQsA==?=
In-Reply-To: <5e9bc6958c1e4335c51674ebadf64f3e.NginxMailingListRussian@forum.nginx.org>
References: <5e9bc6958c1e4335c51674ebadf64f3e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5330572E.4070503@mail.ru>

Попробуйте с 
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_buffering
proxy_buffering off;
еще вариант, врядли он тут "причем" но всеже, 
http://nginx.org/ru/docs/http/ngx_http_core_module.html#postpone_output
postpone_output 0;

On 24.03.14, 8:45, softshape wrote:
> Всем привет,
>
> у нас наблюдается странный тормоз при проксировании через Nginx, я не могу
> понять его природу.
>
> На днях я подключил новую вебкамеру - http://94.154.80.37:3456/image
> Открывается в браузере за доли секунды.
>
> Чтобы не отсвечивать на сайте IP'шник, делаю прокси через Nginx -
>
>      location /r/webcam3/ {
>          proxy_pass
> http://94.154.80.37:3456/image?res=half&quality=18&doublescan=1;
>          proxy_set_header host 94.154.80.37:3456;
>      }
>
> Если я прямо на сервере делаю wget http://www.irk.fm/r/webcam3/, запрос
> также отрабатывает моментально - 0.008 сек. Но в браузере адрес
> http://www.irk.fm/r/webcam3/ висит около 5 секунд прежде, чем показать
> картинку.
>
> При этом "просто картинки" с сервера отдаются нормально - легко проверить,
> зайдя на сам сайт. Я хотел было написать "...а завернутая в Nginx картинка
> тормозит" - но ведь wget её на самом сервере срабатывает моментально.
> Тормозит она только при запросе из браузера и вот этого я никак не могу
> понять...
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,248605,248605#msg-248605
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From dmitry.goryainov at gmail.com  Mon Mar 24 16:58:52 2014
From: dmitry.goryainov at gmail.com (Dmitry)
Date: Mon, 24 Mar 2014 20:58:52 +0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0YHRgtGA0LDQvdC90YvQtSDRgtC+0YDQvNC+0LfQsA==?=
In-Reply-To: <5330572E.4070503@mail.ru>
References: <5e9bc6958c1e4335c51674ebadf64f3e.NginxMailingListRussian@forum.nginx.org>
 <5330572E.4070503@mail.ru>
Message-ID: <CAHzBpYWbk9OUMQYZiun7OC=T4mt5zvTzfNT_u44FpmOiSXQi8A@mail.gmail.com>

по адресу http://www.irk.fm/r/webcam3/ открывается быстро (из Москвы, через
Yotab и с мобильного) там ночь и мало что меняется за несколько часов. так
и должно быть?



2014-03-24 20:02 GMT+04:00 Kostya Alexandrov <koticka at mail.ru>:

> Попробуйте с http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#
> proxy_buffering
> proxy_buffering off;
> еще вариант, врядли он тут "причем" но всеже,
> http://nginx.org/ru/docs/http/ngx_http_core_module.html#postpone_output
> postpone_output 0;
>
>
> On 24.03.14, 8:45, softshape wrote:
>
>> Всем привет,
>>
>> у нас наблюдается странный тормоз при проксировании через Nginx, я не могу
>> понять его природу.
>>
>> На днях я подключил новую вебкамеру - http://94.154.80.37:3456/image
>> Открывается в браузере за доли секунды.
>>
>> Чтобы не отсвечивать на сайте IP'шник, делаю прокси через Nginx -
>>
>>      location /r/webcam3/ {
>>          proxy_pass
>> http://94.154.80.37:3456/image?res=half&quality=18&doublescan=1;
>>          proxy_set_header host 94.154.80.37:3456;
>>      }
>>
>> Если я прямо на сервере делаю wget http://www.irk.fm/r/webcam3/, запрос
>> также отрабатывает моментально - 0.008 сек. Но в браузере адрес
>> http://www.irk.fm/r/webcam3/ висит около 5 секунд прежде, чем показать
>> картинку.
>>
>> При этом "просто картинки" с сервера отдаются нормально - легко проверить,
>> зайдя на сам сайт. Я хотел было написать "...а завернутая в Nginx картинка
>> тормозит" - но ведь wget её на самом сервере срабатывает моментально.
>> Тормозит она только при запросе из браузера и вот этого я никак не могу
>> понять...
>>
>> Posted at Nginx Forum: http://forum.nginx.org/read.
>> php?21,248605,248605#msg-248605
>>
>> _______________________________________________
>> 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
>



-- 
Dmitry Goryainov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140324/e877139e/attachment.html>

From nginx-forum at nginx.us  Mon Mar 24 19:12:11 2014
From: nginx-forum at nginx.us (Sferg)
Date: Mon, 24 Mar 2014 15:12:11 -0400
Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSDQvtCz0YDQsNC90LjRh9C10L3QuNC10Lwg0LQ=?=
 =?UTF-8?B?0L7RgdGC0YPQv9CwINC6INC00LjRgNC10LrRgtC+0YDQuNC4Lg==?=
Message-ID: <981853224c6693857d8d45605b22b9b0.NginxMailingListRussian@forum.nginx.org>

Здравствуйте, господа. Имеется следующий конфиг (максимально сократил):

user www-data;
worker_processes 2;
worker_rlimit_nofile 8192;
events {}
http { index index.html index.htm index.php;
server {
    listen 80;
    root /home/example.com/www;
    location / {}
    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
    }
    location ~* ^/(loc1|loc2)($|\/) {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        allow 127.0.0.1;
        allow 192.168.0.0/24;
        deny all;
    }
}
}

В /home/example.com/www есть директории /loc1 и /loc2 (c файлами). При
обращении из локальной сети к директориям /loc1 и /loc2 выводится ошибка 404
(File not found). В чём может быть проблема?

С уважением.

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


From nginx-forum at nginx.us  Tue Mar 25 02:48:38 2014
From: nginx-forum at nginx.us (softshape)
Date: Mon, 24 Mar 2014 22:48:38 -0400
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0YHRgtGA0LDQvdC90YvQtSDRgtC+0YDQvNC+0LfQsA==?=
In-Reply-To: <CAHzBpYWbk9OUMQYZiun7OC=T4mt5zvTzfNT_u44FpmOiSXQi8A@mail.gmail.com>
References: <CAHzBpYWbk9OUMQYZiun7OC=T4mt5zvTzfNT_u44FpmOiSXQi8A@mail.gmail.com>
Message-ID: <6fc54965c4a85fe944242755139214e0.NginxMailingListRussian@forum.nginx.org>

Ночь? Ну конечно должна быть :)

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


From dmitriy at lyalyuev.info  Tue Mar 25 06:39:02 2014
From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev)
Date: Tue, 25 Mar 2014 08:39:02 +0200
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0YHRgtGA0LDQvdC90YvQtSDRgtC+0YDQvNC+0LfQsA==?=
In-Reply-To: <5e9bc6958c1e4335c51674ebadf64f3e.NginxMailingListRussian@forum.nginx.org>
References: <5e9bc6958c1e4335c51674ebadf64f3e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <53312486.7080804@lyalyuev.info>

Добрый день.

Украина, Донецк - открывается мгновенно.

24.03.2014 06:45, softshape пишет:
> Всем привет,
>
> у нас наблюдается странный тормоз при проксировании через Nginx, я не могу
> понять его природу.
>
> На днях я подключил новую вебкамеру - http://94.154.80.37:3456/image
> Открывается в браузере за доли секунды.
>
> Чтобы не отсвечивать на сайте IP'шник, делаю прокси через Nginx -
>
>      location /r/webcam3/ {
>          proxy_pass
> http://94.154.80.37:3456/image?res=half&quality=18&doublescan=1;
>          proxy_set_header host 94.154.80.37:3456;
>      }
>
> Если я прямо на сервере делаю wget http://www.irk.fm/r/webcam3/, запрос
> также отрабатывает моментально - 0.008 сек. Но в браузере адрес
> http://www.irk.fm/r/webcam3/ висит около 5 секунд прежде, чем показать
> картинку.
>
> При этом "просто картинки" с сервера отдаются нормально - легко проверить,
> зайдя на сам сайт. Я хотел было написать "...а завернутая в Nginx картинка
> тормозит" - но ведь wget её на самом сервере срабатывает моментально.
> Тормозит она только при запросе из браузера и вот этого я никак не могу
> понять...
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,248605,248605#msg-248605
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From nginx-forum at nginx.us  Tue Mar 25 07:20:01 2014
From: nginx-forum at nginx.us (eug.l)
Date: Tue, 25 Mar 2014 03:20:01 -0400
Subject: =?UTF-8?B?0L3QtdGB0LrQvtC70YzQutC+INGB0LDQudGC0L7QsiDQsiDQvtC00L3QvtC8INC0?=
 =?UTF-8?B?0L7QvNC10L3QtSwg0YEg0LDQvdCw0LvQvtCz0LjRh9C90YvQvNC4INC70L4=?=
 =?UTF-8?B?0LrQudC10YjQtdC90LDQvNC4Lg==?=
Message-ID: <b7835fa36c23218be7d88b70b92d9a3e.NginxMailingListRussian@forum.nginx.org>

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

1. Необходимо сделать несколько сайтов в одном домене.Сайты различаются
только языковой версией,являющейся обязательной для идентификации.
Например, 
mydomen.com/ru/
mydomen.com/eng/
mydomen.com/esp/

Сайты расположены на различных vps (бэкэнд) и nginx проксирует запросы к
этим бэкэндам. Одновременно с этим запросы кэшируются.
Для быстрой отдачи статики сделаны локейшины, которые для каждого сайта
свои, но имеют общие названия.
Например,

location ^~ /styles/ {
alias /patch/site1/public_html/_css/;
try_files $uri $uri/ /index.php;
error_page 404 = /fetch$uri;
access_log off;
}

location ^~ /styles/ {
alias /patch/site2/public_html/_css/;
try_files $uri $uri/ /index.php;
error_page 404 = /fetch$uri;
access_log off;
}

location ^~ /styles/ {
alias /patch/site3/public_html/_css/;
try_files $uri $uri/ /index.php;
error_page 404 = /fetch$uri;
access_log off;
}

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

server {
        server_name mysite.com;
        rewrite ^(.*)$ http://www.mysite.com$1 permanent;
}

server {
        listen 80;

        index index.php index.html index.htm;
        server_name www.mysite.com;


        location / {

		include /etc/nginx/conf.d/location/redirect_1.conf;
                include /etc/nginx/conf.d/location/redirect_2.conf;
                include /etc/nginx/conf.d/location/drop_1.conf;
		include /etc/nginx/conf.d/location/static_main.conf;

               location /ru/ {
			include /etc/nginx/conf.d/location/static_s1.conf; ############
##Здесь nginx выдаёт ошибку дублирования , так как в локейшене встречаются
аналогичные описания для основного сайта.
                       proxy_pass http://mysite1_backend;
                       access_log /var/log/nginx/mysite1/my1.log up_head;
                       }

	location /de/ {
			include /etc/nginx/conf.d/location/static_s2.conf; #############
                       proxy_pass http://mysite2_backend;
                       access_log /var/log/nginx/mysite2/my2.log up_head;
                       }

	location /esp/ {
			include /etc/nginx/conf.d/location/static_s3.conf; ########
                       proxy_pass http://mysite3_backend;
                       access_log /var/log/nginx/mysite1/my3.log up_head;
                       }

}

Возможно ли как-то обойти ошибку не меняя описания в самом локейшене?

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


From tetsio.nainn at gmail.com  Tue Mar 25 08:50:30 2014
From: tetsio.nainn at gmail.com (=?UTF-8?B?0Jwu0JAuINCc0L7RhdC90LDRh9C10LLRgdC60LjQuQ==?=)
Date: Tue, 25 Mar 2014 18:50:30 +1000
Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0YHRgtGA0LDQvdC90YvQtSDRgtC+0YDQvNC+0LfQsA==?=
In-Reply-To: <53312486.7080804@lyalyuev.info>
References: <5e9bc6958c1e4335c51674ebadf64f3e.NginxMailingListRussian@forum.nginx.org>
 <53312486.7080804@lyalyuev.info>
Message-ID: <CALXqZiFHbkC29n8XL-fjGpTJRcQ0V0Gwoe+qKm1Zp96520Zmbg@mail.gmail.com>

Россия, Дальний Восток, Якутск - открывается мгновенно


25 марта 2014 г., 16:39 пользователь Dmitriy Lyalyuev <dmitriy at lyalyuev.info
> написал:

> Добрый день.
>
> Украина, Донецк - открывается мгновенно.
>
> 24.03.2014 06:45, softshape пишет:
>
>  Всем привет,
>>
>> у нас наблюдается странный тормоз при проксировании через Nginx, я не могу
>> понять его природу.
>>
>> На днях я подключил новую вебкамеру - http://94.154.80.37:3456/image
>> Открывается в браузере за доли секунды.
>>
>> Чтобы не отсвечивать на сайте IP'шник, делаю прокси через Nginx -
>>
>>      location /r/webcam3/ {
>>          proxy_pass
>> http://94.154.80.37:3456/image?res=half&quality=18&doublescan=1;
>>          proxy_set_header host 94.154.80.37:3456;
>>      }
>>
>> Если я прямо на сервере делаю wget http://www.irk.fm/r/webcam3/, запрос
>> также отрабатывает моментально - 0.008 сек. Но в браузере адрес
>> http://www.irk.fm/r/webcam3/ висит около 5 секунд прежде, чем показать
>> картинку.
>>
>> При этом "просто картинки" с сервера отдаются нормально - легко проверить,
>> зайдя на сам сайт. Я хотел было написать "...а завернутая в Nginx картинка
>> тормозит" - но ведь wget её на самом сервере срабатывает моментально.
>> Тормозит она только при запросе из браузера и вот этого я никак не могу
>> понять...
>>
>> Posted at Nginx Forum: http://forum.nginx.org/read.
>> php?21,248605,248605#msg-248605
>>
>> _______________________________________________
>> 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
>



-- 
С ув. М.А. Мохначевский
Отдел системного администрирования
ООО "Компания "СахаИнтернет НТ"
к.т. (4112)219711 доб. 927
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140325/6fd7ddb3/attachment.html>

From denis at webmaster.spb.ru  Tue Mar 25 11:33:06 2014
From: denis at webmaster.spb.ru (denis)
Date: Tue, 25 Mar 2014 15:33:06 +0400
Subject: =?UTF-8?B?0L/RgNC+0LLQtdGA0LrQsCDQutC+0L3RhNC40LPQvtCyINC40Lcg0YHQutGA0Lg=?=
 =?UTF-8?B?0L/RgtCw?=
Message-ID: <53316972.4080300@webmaster.spb.ru>

if [ "`/usr/local/sbin/nginx -t | grep 'syntax is ok'`" != '' ] ; then

Говорит что всё ок, но не работает... А как тогда?


From vadim.lazovskiy at gmail.com  Tue Mar 25 11:43:04 2014
From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy)
Date: Tue, 25 Mar 2014 15:43:04 +0400
Subject: =?UTF-8?B?UmU6INC/0YDQvtCy0LXRgNC60LAg0LrQvtC90YTQuNCz0L7QsiDQuNC3INGB0Lo=?=
 =?UTF-8?B?0YDQuNC/0YLQsA==?=
In-Reply-To: <53316972.4080300@webmaster.spb.ru>
References: <53316972.4080300@webmaster.spb.ru>
Message-ID: <CAL-L5YCQzhEFh-UdFtaa6ZtrrQ6hKKoGfecVZ0WggRL3-XMmwA@mail.gmail.com>

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

root at fs1:~# /usr/local/nginx/sbin/nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is
successful
root at fs1:~# echo $?
0
root at fs1:~# echo zzz >> /usr/local/nginx/conf/nginx.conf
root at fs1:~# /usr/local/nginx/sbin/nginx -t
nginx: [emerg] unexpected end of file, expecting ";" or "}" in
/usr/local/nginx/conf/nginx.conf:248
nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed
root at fs1:~# echo $?
1

Проверять exitcode команды любым удобным способом.
Можно /usr/local/nginx/sbin/nginx -t && kill -HUP `cat /var/run/nginx.pid`


25 марта 2014 г., 15:33 пользователь denis <denis at webmaster.spb.ru> написал:

> if [ "`/usr/local/sbin/nginx -t | grep 'syntax is ok'`" != '' ] ; then
>
> Говорит что всё ок, но не работает... А как тогда?
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Best Regards,
Vadim Lazovskiy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140325/d9f697dc/attachment-0001.html>

From laa at laa.zp.ua  Tue Mar 25 13:12:54 2014
From: laa at laa.zp.ua (Lystopad Aleksandr)
Date: Tue, 25 Mar 2014 17:12:54 +0400
Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDRgSB1cmkg0Lggcm9vdA==?=
Message-ID: <20140325131254.GK71382@laa.zp.ua>

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

Использую nginx/1.4.4 на freebsd 8.4.
Есть ссылка http://site.com/%d0%d4%d1/P044022-15ES--small.jpg

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

Конфигурация nginx.conf:


 location ~* --.*.(jpg|jpeg|gif)$ {
         if ($host !~* "^photo.*") {
                 rewrite ^(.*)$ http://site2.com$1 permanent;
         }
         root            /dir/photo/;
         try_files       $uri $uri_lowercase @1_fallback;
 }

 location ~* \.(jpg|jpeg|gif)$ {
         root            /dir/photo/;
         try_files       $uri $uri_lowercase @1_fallback;
 }

 location @1_fallback {
         root            /dir/photo/dir2/;
         try_files       $uri $uri_lowercase @fallback;
         error_page 404  = @fallback;
 }


 location / {
         proxy_set_header Host $host;
         proxy_set_header X-Forwarded-Server $host;
         proxy_set_header X-nginx-real-ip-client $proxy_add_x_forwarded_for;
         proxy_pass http://$host:88;
         index index.php index.php4 index.html index.htm;
         more_clear_headers 'X-Powered-By';
 }



если этот файл открывать при помощи ls -l, то получается вот что:


# ls -l '/dir/photo/dir2/\xD0\xD4\xD1/p044022-15es--frontsmall.jpg'
-rwxrwxr-x  1 user  web  - 8183 Mar 20 18:02 /dir/photo/dir2/\xD0\xD4\xD1/p044022-15es--frontsmall.jpg

# ls -l /dir/photo/dir2/\xD0\xD4\xD1/p044022-15es--frontsmall.jpg
ls: /dir/photo/dir2/xD0xD4xD1/p044022-15es--frontsmall.jpg: No such file or directory

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

Нужно настроить nginx на отдачу файлов с подобным именем при помощи root .

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

Прошу помочь снять с ручника: где я туплю?

-- 
 Lystopad Aleksandr 


From denis at webmaster.spb.ru  Tue Mar 25 14:44:48 2014
From: denis at webmaster.spb.ru (denis)
Date: Tue, 25 Mar 2014 18:44:48 +0400
Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0YEgdXJpINC4IHJvb3Q=?=
In-Reply-To: <20140325131254.GK71382@laa.zp.ua>
References: <20140325131254.GK71382@laa.zp.ua>
Message-ID: <53319660.80204@webmaster.spb.ru>

25.03.2014 17:12, Lystopad Aleksandr пишет:
> Нужно настроить nginx на отдачу файлов с подобным именем при помощи root .
>
> Догадываюсь, что проблему можно решить путем изменения ссылки.
>
> Прошу помочь снять с ручника: где я туплю?
http://nginx.org/ru/docs/debugging_log.html
включить дебаг-лог и смотреть, куда оно лезет за файлами.
Для изменения места где искать
http://nginx.org/ru/docs/http/ngx_http_core_module.html#alias


From mdounin at mdounin.ru  Tue Mar 25 16:19:39 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 25 Mar 2014 20:19:39 +0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L7Qs9GA0LDQvdC40YfQtdC90LjQtdC8?=
 =?UTF-8?B?INC00L7RgdGC0YPQv9CwINC6INC00LjRgNC10LrRgtC+0YDQuNC4Lg==?=
In-Reply-To: <981853224c6693857d8d45605b22b9b0.NginxMailingListRussian@forum.nginx.org>
References: <981853224c6693857d8d45605b22b9b0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140325161939.GY34696@mdounin.ru>

Hello!

On Mon, Mar 24, 2014 at 03:12:11PM -0400, Sferg wrote:

> Здравствуйте, господа. Имеется следующий конфиг (максимально сократил):
> 
> user www-data;
> worker_processes 2;
> worker_rlimit_nofile 8192;
> events {}
> http { index index.html index.htm index.php;
> server {
>     listen 80;
>     root /home/example.com/www;
>     location / {}
>     location ~ \.php$ {
>         include fastcgi_params;
>         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
>         fastcgi_pass unix:/var/run/php5-fpm.sock;
>     }
>     location ~* ^/(loc1|loc2)($|\/) {
>         include fastcgi_params;
>         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
>         fastcgi_pass unix:/var/run/php5-fpm.sock;
>         allow 127.0.0.1;
>         allow 192.168.0.0/24;
>         deny all;
>     }
> }
> }
> 
> В /home/example.com/www есть директории /loc1 и /loc2 (c файлами). При
> обращении из локальной сети к директориям /loc1 и /loc2 выводится ошибка 404
> (File not found). В чём может быть проблема?

Конфиг как бы намекает, что все запросы в /loc1 и /loc2 - 
передаются для обработки в php.  Это как минимум странно для 
собственно самого каталога - запрос к "/loc1" php точно не сможет 
никак обработать.  Скорее всего вы хотели написать в конфиге 
что-то другое, а не то, что написали.

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


From mdounin at mdounin.ru  Tue Mar 25 16:36:13 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 25 Mar 2014 20:36:13 +0400
Subject: =?UTF-8?B?UmU6INC90LXRgdC60L7Qu9GM0LrQviDRgdCw0LnRgtC+0LIg0LIg0L7QtNC90L4=?=
 =?UTF-8?B?0Lwg0LTQvtC80LXQvdC1LCDRgSDQsNC90LDQu9C+0LPQuNGH0L3Ri9C80Lgg?=
 =?UTF-8?B?0LvQvtC60LnQtdGI0LXQvdCw0LzQuC4=?=
In-Reply-To: <b7835fa36c23218be7d88b70b92d9a3e.NginxMailingListRussian@forum.nginx.org>
References: <b7835fa36c23218be7d88b70b92d9a3e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140325163613.GZ34696@mdounin.ru>

Hello!

On Tue, Mar 25, 2014 at 03:20:01AM -0400, eug.l wrote:

> Добрый день,уважаемые коллеги!
> Помогите,пожалуйста, новичку разрешить следующую проблему.
> 
> 1. Необходимо сделать несколько сайтов в одном домене.Сайты различаются
> только языковой версией,являющейся обязательной для идентификации.
> Например, 
> mydomen.com/ru/
> mydomen.com/eng/
> mydomen.com/esp/
> 
> Сайты расположены на различных vps (бэкэнд) и nginx проксирует запросы к
> этим бэкэндам. Одновременно с этим запросы кэшируются.
> Для быстрой отдачи статики сделаны локейшины, которые для каждого сайта
> свои, но имеют общие названия.

У префиксных location'ов - не названия, а префиксные строки, 
которые сопоставляются с URI запроса.  Их нужно сделать разными, 
так, как вы уже сделали для собственно проксирования.

Как-то так:

    location /ru/ {
        ...
    }
     
    location /ru/styles/ {
        ...
    }

    location /de/ {
        ...
    }

    location /de/styles/ {
        ...
    }

Для лучшего понимания вопроса крайне рекомендуется прочитать 
описание директивы location тут:

http://nginx.org/ru/docs/http/ngx_http_core_module.html#location

А равно основы обработки запросов тут:

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

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


From nginx-forum at nginx.us  Tue Mar 25 17:36:18 2014
From: nginx-forum at nginx.us (Sferg)
Date: Tue, 25 Mar 2014 13:36:18 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L7Qs9GA0LDQvdC40YfQtdC90LjQtdC8?=
 =?UTF-8?B?INC00L7RgdGC0YPQv9CwINC6INC00LjRgNC10LrRgtC+0YDQuNC4Lg==?=
In-Reply-To: <20140325161939.GY34696@mdounin.ru>
References: <20140325161939.GY34696@mdounin.ru>
Message-ID: <e52da4310ff29959af58f51bb954b20e.NginxMailingListRussian@forum.nginx.org>

Ну, в директориях /loc1 и /loc2 у меня расположены некие PHP-скрипты, к
которым мне бы хотелось запретить доступ посторонним. Интересное, что если
обратиться к директории /loc3, которая не прописана в строчке:

location ~* ^/(loc1|loc2)($|\/) {

, то доступ к ней (и к скриптам в ней) есть. Если из строчки убрать loc1 или
loc2, то в них можно зайти... Если же они прописаны, то возвращается 404-ая
ошибка.

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


From nginx-forum at nginx.us  Tue Mar 25 18:16:29 2014
From: nginx-forum at nginx.us (alexserbul)
Date: Tue, 25 Mar 2014 14:16:29 -0400
Subject: =?UTF-8?B?0JHRg9GE0LXRgCDQsiDRhNC40LvRjNGC0YDQtSAtINC60LDQuiDQv9C+0LTRgdGC?=
 =?UTF-8?B?0LDQstC40YLRjCDRgdCy0L7QuT8=?=
Message-ID: <656f0055478774de83b45f7cc0b986d1.NginxMailingListRussian@forum.nginx.org>

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

Пишу фильтр. Создал буфер (ngx_buf_t), выделив память из аллокатора
(ngx_pcalloc), установил:
b->start
b->pos
b->last
b->end

Остальные свойства буфера - нулевые, не трогал.

Пытаюсь заменить приходящий в фильтр в цепочке ngx_chain_t буфер - своим
буфером. Зависает.

Получилось только в приходящем в цепочке в фильтр буфере установить pos и
last на выделенную в моем буфере в аллокаторе память, что я понимаю не очень
красивое решение.

Таким образом, просто заменить приходящий в фильтр буфер своим - не
получилось никак.

У структуры буфера (ngx_buf_t) - 21 свойства. Видимо не все буферы можно
заменять, менять (напр. с свойством "memory"). Где почитать как их учитывать
в фильтре? Спасибо.

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


From mdounin at mdounin.ru  Tue Mar 25 18:37:10 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 25 Mar 2014 22:37:10 +0400
Subject: =?UTF-8?B?UmU6INCR0YPRhNC10YAg0LIg0YTQuNC70YzRgtGA0LUgLSDQutCw0Log0L/QvtC0?=
 =?UTF-8?B?0YHRgtCw0LLQuNGC0Ywg0YHQstC+0Lk/?=
In-Reply-To: <656f0055478774de83b45f7cc0b986d1.NginxMailingListRussian@forum.nginx.org>
References: <656f0055478774de83b45f7cc0b986d1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140325183710.GD34696@mdounin.ru>

Hello!

On Tue, Mar 25, 2014 at 02:16:29PM -0400, alexserbul wrote:

> Добрый вечер!
> 
> Пишу фильтр. Создал буфер (ngx_buf_t), выделив память из аллокатора
> (ngx_pcalloc), установил:
> b->start
> b->pos
> b->last
> b->end
> 
> Остальные свойства буфера - нулевые, не трогал.
> 
> Пытаюсь заменить приходящий в фильтр в цепочке ngx_chain_t буфер - своим
> буфером. Зависает.

Базовое правило при работе с цепочками буфров: чужую цепочку 
(всмысле, структуры ngx_chain_t) трогать нельзя, если нужно что-то 
поменять - следует создать свою цепочку (и подцепить к ней нужные 
буфера).

Ну и как минимум у буфра должен стоять флаг, определяющий, где 
именно располагаются его данные.  Если буфер с данными в памяти - 
то b->temporary или b->memory, если в файле - то b->file.

> Получилось только в приходящем в цепочке в фильтр буфере установить pos и
> last на выделенную в моем буфере в аллокаторе память, что я понимаю не очень
> красивое решение.

Да, так делать неправильно.

> Таким образом, просто заменить приходящий в фильтр буфер своим - не
> получилось никак.
> 
> У структуры буфера (ngx_buf_t) - 21 свойства. Видимо не все буферы можно
> заменять, менять (напр. с свойством "memory"). Где почитать как их учитывать
> в фильтре? Спасибо.

Use The Source, Luke!

Некоторые вещи, впрочем, описаны у Evan'а Miller'а, ссылки есть тут:

http://nginx.org/en/links.html

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


From nginx-forum at nginx.us  Tue Mar 25 19:57:26 2014
From: nginx-forum at nginx.us (alexserbul)
Date: Tue, 25 Mar 2014 15:57:26 -0400
Subject: =?UTF-8?B?UmU6INCR0YPRhNC10YAg0LIg0YTQuNC70YzRgtGA0LUgLSDQutCw0Log0L/QvtC0?=
 =?UTF-8?B?0YHRgtCw0LLQuNGC0Ywg0YHQstC+0Lk/?=
In-Reply-To: <20140325183710.GD34696@mdounin.ru>
References: <20140325183710.GD34696@mdounin.ru>
Message-ID: <cdb411db011551f836fad197de6cf84e.NginxMailingListRussian@forum.nginx.org>

Спасибо за подробный ответ!

Возник еще один вопрос.

Как внутри фильтра лучше скрыть/удалить пришедший "чужой буфер в цепочке",
приходящий в фильтр, чтобы он не попал в вывод? Я собираю контент всех
буферов в отдельной цепочке в контексте фильтра и нужно скрыть все
скопированные "чужие" буферы, в т.ч. последний буфер ответа (last_buf), а
затем добавить свой буфер с модифицированным контентом.

Пока решается установкой свойств каждого "чужого буфера":  buf->last =
buf->pos.

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


From mdounin at mdounin.ru  Wed Mar 26 10:51:56 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 26 Mar 2014 14:51:56 +0400
Subject: =?UTF-8?B?UmU6INCR0YPRhNC10YAg0LIg0YTQuNC70YzRgtGA0LUgLSDQutCw0Log0L/QvtC0?=
 =?UTF-8?B?0YHRgtCw0LLQuNGC0Ywg0YHQstC+0Lk/?=
In-Reply-To: <cdb411db011551f836fad197de6cf84e.NginxMailingListRussian@forum.nginx.org>
References: <20140325183710.GD34696@mdounin.ru>
 <cdb411db011551f836fad197de6cf84e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140326105156.GF34696@mdounin.ru>

Hello!

On Tue, Mar 25, 2014 at 03:57:26PM -0400, alexserbul wrote:

> Спасибо за подробный ответ!
> 
> Возник еще один вопрос.
> 
> Как внутри фильтра лучше скрыть/удалить пришедший "чужой буфер в цепочке",
> приходящий в фильтр, чтобы он не попал в вывод? Я собираю контент всех
> буферов в отдельной цепочке в контексте фильтра и нужно скрыть все
> скопированные "чужие" буферы, в т.ч. последний буфер ответа (last_buf), а
> затем добавить свой буфер с модифицированным контентом.
> 
> Пока решается установкой свойств каждого "чужого буфера":  buf->last =
> buf->pos.

Нужно создать свою цепочу с новым содержимым и отдать её дальше, 
для всех "чужих" буферов, которые дальше не отданы - сделать 
buf->pos = buf->last (если буфер в памяти, но это обычно 
обеспечивается установкой r->[main_]filter_need_in_memory), см. 
например xslt-фильтр.

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


From mdounin at mdounin.ru  Wed Mar 26 12:06:55 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 26 Mar 2014 16:06:55 +0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L7Qs9GA0LDQvdC40YfQtdC90LjQtdC8?=
 =?UTF-8?B?INC00L7RgdGC0YPQv9CwINC6INC00LjRgNC10LrRgtC+0YDQuNC4Lg==?=
In-Reply-To: <e52da4310ff29959af58f51bb954b20e.NginxMailingListRussian@forum.nginx.org>
References: <20140325161939.GY34696@mdounin.ru>
 <e52da4310ff29959af58f51bb954b20e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140326120654.GI34696@mdounin.ru>

Hello!

On Tue, Mar 25, 2014 at 01:36:18PM -0400, Sferg wrote:

> Ну, в директориях /loc1 и /loc2 у меня расположены некие PHP-скрипты, к
> которым мне бы хотелось запретить доступ посторонним. Интересное, что если
> обратиться к директории /loc3, которая не прописана в строчке:
> 
> location ~* ^/(loc1|loc2)($|\/) {
> 
> , то доступ к ней (и к скриптам в ней) есть. Если из строчки убрать loc1 или
> loc2, то в них можно зайти... Если же они прописаны, то возвращается 404-ая
> ошибка.

Вы начните с того, что определитесь, как выглядит запрос и какой 
вы ожидаете на него ответ.  Как вам уже было указано, запрос к 
"/loc1" у вас работать совершенно точно не будет.

Ну и в error log загляните, это тоже всегда полезно.

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


From nginx-forum at nginx.us  Wed Mar 26 19:56:44 2014
From: nginx-forum at nginx.us (alexserbul)
Date: Wed, 26 Mar 2014 15:56:44 -0400
Subject: =?UTF-8?B?UmU6INCR0YPRhNC10YAg0LIg0YTQuNC70YzRgtGA0LUgLSDQutCw0Log0L/QvtC0?=
 =?UTF-8?B?0YHRgtCw0LLQuNGC0Ywg0YHQstC+0Lk/?=
In-Reply-To: <20140326105156.GF34696@mdounin.ru>
References: <20140326105156.GF34696@mdounin.ru>
Message-ID: <6778c7dad3959512316db7dfbe50fe36.NginxMailingListRussian@forum.nginx.org>

Спасибо! Сделал, получилось, заработало.

Еще вопрос. Установив флаг filter_need_in_memory в хэдерной части фильтра -
можно ли 100% гарантировать, что все буферы будут в памяти и их можно будет
скрывать НЕЗАВИСИМО от sendfile, работы через апстрим, проксированиях и
т.п.?

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

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


From mdounin at mdounin.ru  Wed Mar 26 20:21:38 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 27 Mar 2014 00:21:38 +0400
Subject: =?UTF-8?B?UmU6INCR0YPRhNC10YAg0LIg0YTQuNC70YzRgtGA0LUgLSDQutCw0Log0L/QvtC0?=
 =?UTF-8?B?0YHRgtCw0LLQuNGC0Ywg0YHQstC+0Lk/?=
In-Reply-To: <6778c7dad3959512316db7dfbe50fe36.NginxMailingListRussian@forum.nginx.org>
References: <20140326105156.GF34696@mdounin.ru>
 <6778c7dad3959512316db7dfbe50fe36.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140326202138.GP34696@mdounin.ru>

Hello!

On Wed, Mar 26, 2014 at 03:56:44PM -0400, alexserbul wrote:

> Спасибо! Сделал, получилось, заработало.
> 
> Еще вопрос. Установив флаг filter_need_in_memory в хэдерной части фильтра -
> можно ли 100% гарантировать, что все буферы будут в памяти и их можно будет
> скрывать НЕЗАВИСИМО от sendfile, работы через апстрим, проксированиях и
> т.п.?
> 
> Хочется одного, чтобы фильтр брал буферы из памяти, собирал и посылал свой
> вариант данных - независимо от настроек конфига.

Именно для этого флаг и сделан - он даёт знать copy-фильтру, что 
данные буферов нужны в памяти, и если они вдруг на диске - их надо 
прочитать.

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


From a.vasilishin at kpi.ua  Thu Mar 27 12:19:35 2014
From: a.vasilishin at kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=)
Date: Thu, 27 Mar 2014 14:19:35 +0200
Subject: start time is out mp4 stsc chunks
Message-ID: <53341757.7030601@kpi.ua>

Добрый день!
Есть такая проблема: есть 2 сервера с одинаковым конфигом, но разными 
нгинксами, на первом такой:
# nginx  -V
nginx version: nginx/1.2.4
configure arguments: --prefix=/etc/nginx 
--conf-path=/etc/nginx/nginx.conf 
--error-log-path=/var/log/nginx/error.log 
--http-client-body-temp-path=/var/lib/nginx/body 
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi 
--http-log-path=/var/log/nginx/access.log 
--http-proxy-temp-path=/var/lib/nginx/proxy 
--lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid 
--with-debug --with-file-aio --with-http_flv_module 
--with-http_geoip_module --with-http_mp4_module 
--with-http_realip_module --with-http_secure_link_module 
--with-http_stub_status_module --without-http_scgi_module 
--without-http_split_clients_module --without-http_ssi_module 
--without-http_userid_module --without-http_uwsgi_module


на втором такой:
# nginx -V
nginx version: nginx/1.5.7
built by gcc 4.7.2 (Debian 4.7.2-5)
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx 
--conf-path=/etc/nginx/nginx.conf 
--error-log-path=/var/log/nginx/error.log 
--http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid 
--lock-path=/var/run/nginx.lock 
--http-client-body-temp-path=/var/cache/nginx/client_temp 
--http-proxy-temp-path=/var/cache/nginx/proxy_temp 
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp 
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp 
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=www-data 
--group=www-data --with-http_ssl_module --with-http_realip_module 
--with-http_addition_module --with-http_sub_module 
--with-http_dav_module --with-http_flv_module --with-http_mp4_module 
--with-http_gunzip_module --with-http_gzip_static_module 
--with-http_random_index_module --with-http_secure_link_module 
--with-http_stub_status_module --with-http_auth_request_module 
--with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 
-fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security' --with-ld-opt=-Wl,-z,relro --with-ipv6 --with-debug


Один и тот же файл mp4 на первом проигрывается и перематывается 
нормально, а навтором при перемотке возникает ошибка:

2014/03/26 14:01:55 [debug] 51008#0: *118478378 start_sample:16, new count:1
2014/03/26 14:01:55 [debug] 51008#0: *118478378 mp4 stss atom update
2014/03/26 14:01:55 [debug] 51008#0: *118478378 mp4 ctts atom update
2014/03/26 14:01:55 [debug] 51008#0: *118478378 mp4 stsc atom update
2014/03/26 14:01:55 [debug] 51008#0: *118478378 start_sample:16, 
chunk:1, chunks:0, samples:36
2014/03/26 14:01:55 [error] 51008#0: *118478378 start time is out mp4 
stsc chunks in "/var/www/test.com-mst3/files/hd_01/file_720.mp4", 
client: 176.104.55.60, server: test.com, request: "GET 
/s/91f3ee1ab9adaf461376a5e94e4f0eb7/hd_01/file_720.mp4?start=3072.76 
HTTP/1.1", upstream: 
"http://127.0.0.1:8080/kino.php?code=91f3ee1ab9adaf461376a5e94e4f0eb7&film=hd_01/file_720.mp4&start=3072.76", 
host: "test.com", referrer: "http://filmix.net/uppod.swf"
2014/03/26 14:01:55 [debug] 51008#0: *118478378 free: 0000000005600010
2014/03/26 14:01:55 [debug] 51008#0: *118478378 free: 000000000201DAB0
2014/03/26 14:01:55 [debug] 51008#0: *118478378 http finalize request: 
500, 
"/test.com-mst3/files/hd_01/file_720.mp4?code=91f3ee1ab9adaf461376a5e94e4f0eb7&film=hd_01/file_720.mp4&start=3072.76" 
a:1, c:2
2014/03/26 14:01:55 [debug] 51008#0: *118478378 http special response: 
500, 
"/test.com-mst3/files/hd_01/file_720.mp4?code=91f3ee1ab9adaf461376a5e94e4f0eb7&film=hd_01/file_720.mp4&start=3072.76"
2014/03/26 14:01:55 [debug] 51008#0: *118478378 HTTP/1.1 500 Internal 
Server Error
Server: nginx/1.5.7

Кто виноват и что делать?


From mdounin at mdounin.ru  Thu Mar 27 12:59:19 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 27 Mar 2014 16:59:19 +0400
Subject: start time is out mp4 stsc chunks
In-Reply-To: <53341757.7030601@kpi.ua>
References: <53341757.7030601@kpi.ua>
Message-ID: <20140327125919.GX34696@mdounin.ru>

Hello!

On Thu, Mar 27, 2014 at 02:19:35PM +0200, Андрей Василишин wrote:

> Добрый день!
> Есть такая проблема: есть 2 сервера с одинаковым конфигом, но разными
> нгинксами, на первом такой:
> # nginx  -V
> nginx version: nginx/1.2.4

[...]

> на втором такой:
> # nginx -V
> nginx version: nginx/1.5.7

[...]

> Один и тот же файл mp4 на первом проигрывается и перематывается нормально, а
> навтором при перемотке возникает ошибка:

[...]

> 2014/03/26 14:01:55 [error] 51008#0: *118478378 start time is out mp4 stsc
> chunks in "/var/www/test.com-mst3/files/hd_01/file_720.mp4", client:
> 176.104.55.60, server: test.com, request: "GET
> /s/91f3ee1ab9adaf461376a5e94e4f0eb7/hd_01/file_720.mp4?start=3072.76
> HTTP/1.1", upstream: "http://127.0.0.1:8080/kino.php?code=91f3ee1ab9adaf461376a5e94e4f0eb7&film=hd_01/file_720.mp4&start=3072.76",
> host: "test.com", referrer: "http://filmix.net/uppod.swf"

[...]

> Кто виноват и что делать?

Проблема в том, что в mp4-файле присутствует короткая дорожа.

В старых версиях nginx просто выкидывал все дорожки неизвестных 
типов, но начиная с 1.3.5 - оставляет, т.к. предыдущее поведение 
ломало субтитры:

    *) Change: opening and closing a connection without sending any data in
       it is no longer logged to access_log with error code 400.

Чтобы заработало - нужно либо убрать дорожки из файла, либо 
обновится до nginx 1.5.10+:

    *) Feature: the ngx_http_mp4_module now skips tracks too short for a
       seek requested.

Подробнее можно почитать где-то тут:

http://trac.nginx.org/nginx/ticket/414

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


From mdounin at mdounin.ru  Thu Mar 27 13:06:30 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 27 Mar 2014 17:06:30 +0400
Subject: start time is out mp4 stsc chunks
In-Reply-To: <20140327125919.GX34696@mdounin.ru>
References: <53341757.7030601@kpi.ua>
 <20140327125919.GX34696@mdounin.ru>
Message-ID: <20140327130630.GZ34696@mdounin.ru>

Hello!

On Thu, Mar 27, 2014 at 04:59:19PM +0400, Maxim Dounin wrote:

> Hello!
> 
> On Thu, Mar 27, 2014 at 02:19:35PM +0200, Андрей Василишин wrote:
> 
> > Добрый день!
> > Есть такая проблема: есть 2 сервера с одинаковым конфигом, но разными
> > нгинксами, на первом такой:
> > # nginx  -V
> > nginx version: nginx/1.2.4
> 
> [...]
> 
> > на втором такой:
> > # nginx -V
> > nginx version: nginx/1.5.7
> 
> [...]
> 
> > Один и тот же файл mp4 на первом проигрывается и перематывается нормально, а
> > навтором при перемотке возникает ошибка:
> 
> [...]
> 
> > 2014/03/26 14:01:55 [error] 51008#0: *118478378 start time is out mp4 stsc
> > chunks in "/var/www/test.com-mst3/files/hd_01/file_720.mp4", client:
> > 176.104.55.60, server: test.com, request: "GET
> > /s/91f3ee1ab9adaf461376a5e94e4f0eb7/hd_01/file_720.mp4?start=3072.76
> > HTTP/1.1", upstream: "http://127.0.0.1:8080/kino.php?code=91f3ee1ab9adaf461376a5e94e4f0eb7&film=hd_01/file_720.mp4&start=3072.76",
> > host: "test.com", referrer: "http://filmix.net/uppod.swf"
> 
> [...]
> 
> > Кто виноват и что делать?
> 
> Проблема в том, что в mp4-файле присутствует короткая дорожа.
> 
> В старых версиях nginx просто выкидывал все дорожки неизвестных 
> типов, но начиная с 1.3.5 - оставляет, т.к. предыдущее поведение 
> ломало субтитры:
> 
>     *) Change: opening and closing a connection without sending any data in
>        it is no longer logged to access_log with error code 400.

Opps, should be:

    *) Change: the ngx_http_mp4_module module no longer skips tracks in
       formats other than H.264 and AAC.

> Чтобы заработало - нужно либо убрать дорожки из файла, либо 
> обновится до nginx 1.5.10+:
> 
>     *) Feature: the ngx_http_mp4_module now skips tracks too short for a
>        seek requested.
> 
> Подробнее можно почитать где-то тут:
> 
> http://trac.nginx.org/nginx/ticket/414

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


From a.vasilishin at kpi.ua  Thu Mar 27 18:18:55 2014
From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=)
Date: Thu, 27 Mar 2014 20:18:55 +0200
Subject: start time is out mp4 stsc chunks
In-Reply-To: <20140327130630.GZ34696@mdounin.ru>
References: <53341757.7030601@kpi.ua> <20140327125919.GX34696@mdounin.ru>
 <20140327130630.GZ34696@mdounin.ru>
Message-ID: <53346B8F.6050309@kpi.ua>


>> Чтобы заработало - нужно либо убрать дорожки из файла, либо
>> обновится до nginx 1.5.10+:
>>

Спасибо за ответы, Максим!
Но есть еще вопросы:
Обновился до
# nginx -V
nginx version: nginx/1.5.12
built by gcc 4.7.2 (Debian 4.7.2-5)
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx 
--conf-path=/etc/nginx/nginx.conf 
--error-log-path=/var/log/nginx/error.log 
--http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid 
--lock-path=/var/run/nginx.lock 
--http-client-body-temp-path=/var/cache/nginx/client_temp 
--http-proxy-temp-path=/var/cache/nginx/proxy_temp 
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp 
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp 
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=www-data 
--group=www-data --with-http_geoip_module --with-http_realip_module 
--with-http_flv_module --with-http_mp4_module 
--with-http_random_index_module --with-http_secure_link_module 
--with-http_stub_status_module --with-file-aio --with-http_spdy_module 
--with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 
-Wformat -Werror=format-security' --with-ld-opt=-Wl,-z,relro --with-ipv6 
--with-debug

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

Про какие дорожки речь?
# mediainfo file_720.mp4
General
Complete name                            : file_720.mp4
Format                                   : MPEG-4
Format profile                           : Base Media
Codec ID                                 : isom
File size                                : 995 MiB
Duration                                 : 1h 54mn
Overall bit rate mode                    : Variable
Overall bit rate                         : 1 211 Kbps
Writing application                      : Lavf55.19.104

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High at L3.1
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 1h 54mn
Bit rate                                 : 1 024 Kbps
Width                                    : 1 280 pixels
Height                                   : 532 pixels
Display aspect ratio                     : 2.40:1
Frame rate mode                          : Constant
Frame rate                               : 25.000 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.060
Stream size                              : 832 MiB (84%)
Writing library                          : x264 core 142
Encoding settings                        : cabac=1 / ref=2 / 
deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=6 / psy=1 / 
psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 
8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / 
threads=24 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 
/ interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / 
b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / 
weightp=1 / keyint=50 / keyint_min=5 / scenecut=40 / intra_refresh=0 / 
rc_lookahead=30 / rc=abr / mbtree=1 / bitrate=1024 / ratetol=1.0 / 
qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language                                 : English

Audio
ID                                       : 2
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format profile                           : LC
Codec ID                                 : 40
Duration                                 : 1h 54mn
Bit rate mode                            : Constant
Bit rate                                 : 192 Kbps
Channel(s)                               : 6 channels
Channel positions                        : Front: L C R, Side: L R, LFE
Sampling rate                            : 48.0 KHz
Compression mode                         : Lossy
Delay relative to video                  : -1s 24ms
Stream size                              : 158 MiB (16%)
Language                                 : Russian

Text
ID                                       : 3
Format                                   : Apple text
Codec ID                                 : text
Duration                                 : 1h 54mn
Bit rate mode                            : Variable
Bit rate                                 : 0 bps
Delay relative to video                  : -1s 24ms
Stream size                              : 135 Bytes (0%)
Language                                 : English

Menu
00:00:00.000                             : 1
00:02:49.000                             : 2
00:05:38.000                             : 3
00:08:32.000                             : 4
00:10:52.000                             : 5
00:13:50.000                             : 6
00:17:46.000                             : 7
00:20:37.000                             : 8
00:23:30.000                             : 9
00:26:28.000                             : 10
00:30:05.000                             : 11
00:32:16.000                             : 12
00:34:57.000                             : 13
00:38:15.000                             : 14
00:40:28.000                             : 15
00:44:47.000                             : 16
00:48:09.000                             : 17
00:51:25.000                             : 18
00:54:31.000                             : 19
00:57:23.000                             : 20
00:59:57.000                             : 21
01:03:05.000                             : 22
01:05:23.000                             : 23
01:09:21.000                             : 24
01:11:17.000                             : 25
01:14:01.000                             : 26
01:18:25.000                             : 27
01:22:44.000                             : 28
01:28:46.000                             : 29
01:30:17.000                             : 30
01:33:47.000                             : 31
01:35:32.000                             : 32
01:38:17.000                             : 33
01:39:41.000                             : 34
01:42:54.000                             : 35
01:44:20.000                             : 36




From mdounin at mdounin.ru  Fri Mar 28 11:57:04 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 28 Mar 2014 15:57:04 +0400
Subject: start time is out mp4 stsc chunks
In-Reply-To: <53346B8F.6050309@kpi.ua>
References: <53341757.7030601@kpi.ua> <20140327125919.GX34696@mdounin.ru>
 <20140327130630.GZ34696@mdounin.ru> <53346B8F.6050309@kpi.ua>
Message-ID: <20140328115704.GJ34696@mdounin.ru>

Hello!

On Thu, Mar 27, 2014 at 08:18:55PM +0200, Андрей Василишин wrote:

> 
> >>Чтобы заработало - нужно либо убрать дорожки из файла, либо
> >>обновится до nginx 1.5.10+:
> >>
> 
> Спасибо за ответы, Максим!
> Но есть еще вопросы:
> Обновился до
> # nginx -V
> nginx version: nginx/1.5.12
> built by gcc 4.7.2 (Debian 4.7.2-5)

[...]

> Теперь 500-ой общибки при перемотке нет, но при перемотке просто идет
> скачиваение файла и при этом не показывается в плеере ничего, кроме полосы
> загрузки.
> 
> Про какие дорожки речь?
> # mediainfo file_720.mp4
> General
> Complete name                            : file_720.mp4
> Format                                   : MPEG-4
> Format profile                           : Base Media
> Codec ID                                 : isom
> File size                                : 995 MiB
> Duration                                 : 1h 54mn
> Overall bit rate mode                    : Variable
> Overall bit rate                         : 1 211 Kbps
> Writing application                      : Lavf55.19.104

[...]

> Text
> ID                                       : 3
> Format                                   : Apple text
> Codec ID                                 : text
> Duration                                 : 1h 54mn
> Bit rate mode                            : Variable
> Bit rate                                 : 0 bps
> Delay relative to video                  : -1s 24ms
> Stream size                              : 135 Bytes (0%)
> Language                                 : English

Видимо, проблема в этой дорожке.  Она не выглядит короткой, так 
что скорее всего ошибка была из-за каких-то нюансов расположения 
данных.  Но при этом она явно не перемешана с остальными дорожками 
(просто из-за очень малого размера), и попытка отдать диапазон 
файла "начиная с такой-то секунды", видимо, требует отдачи 
практически всего файла, т.к. для этой дорожки данные начинаются в 
начале файла.

Наиболее простое решение - убрать из файла эту дорожку.

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


From aa.schurov at gmail.com  Fri Mar 28 14:47:27 2014
From: aa.schurov at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KnRg9GA0L7Qsg==?=)
Date: Fri, 28 Mar 2014 18:47:27 +0400
Subject: =?UTF-8?B?ItCX0LDQvNC40YDQsNC10YIiINC/0LXRgNC10LTQsNGH0LAg0YHRgtCw0YLQuNGH?=
 =?UTF-8?B?0L3QvtCz0L4g0YTQsNC50LvQsA==?=
Message-ID: <CAMSfEarme6BgC0Tg=F9xmD5=Dr8AUtR4ZbCJuOZQHGoRqgtP+A@mail.gmail.com>

Проблема заключается в периодическом "замирании" передачи статичного
файла, возникает в основном на высокоскоростных соединениях.
С включенным limit_rate 200k я ни разу не поймал проблему.
Включил debug_connection для одного тестового клиента, далее
отфильтрованные записи из лога (могу полный лог отправить если надо):
2014/03/28 16:09:44 [debug] 22512#0: *102725 HTTP/1.1 200 OK
Server: nginx/1.4.7
Date: Fri, 28 Mar 2014 12:09:44 GMT
Content-Type: application/octet-stream
Content-Length: 17775749
Connection: keep-alive
ETag: "532070bd-10f3c85"
Last-Modified: Fri, 2 Jan 1970 00:00:01 GMT
Accept-Ranges: bytes

2014/03/28 16:09:44 [debug] 22512#0: *102725 write new buf t:1 f:0
00000000072252E8, pos 00000000072252E8, size: 260 file: 0, size: 0
...
2014/03/28 16:09:44 [debug] 22512#0: *102725 write old buf t:1 f:0
00000000072252E8, pos 00000000072252E8, size: 260 file: 0, size: 0
2014/03/28 16:09:44 [debug] 22512#0: *102725 write new buf t:0 f:1
0000000000000000, pos 0000000000000000, size: 0 file: 0, size:
17775749
...
2014/03/28 16:09:44 [debug] 22512#0: *102725 writev: 260
2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: @0 17775749
2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: 3440640, @0
3440640:17775749
...
2014/03/28 16:09:44 [debug] 22512#0: *102725 write old buf t:0 f:1
0000000000000000, pos 0000000000000000, size: 0 file: 3440640, size:
14335109
2014/03/28 16:09:44 [debug] 22512#0: *102725 http write filter: l:1
f:0 s:14335109
2014/03/28 16:09:44 [debug] 22512#0: *102725 http write filter limit 0
2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: @3440640 14335109
2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile() is not ready
(11: Resource temporarily unavailable)
2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: -1, @3440640 0:14335109
2014/03/28 16:09:44 [debug] 22512#0: *102725 http write filter 0000000007225478
2014/03/28 16:09:44 [debug] 22512#0: *102725 http copy filter: -2 "/test.bin?"
2014/03/28 16:09:44 [debug] 22512#0: *102725 http writer output
filter: -2, "/test.bin?"
2014/03/28 16:09:44 [debug] 22512#0: *102725 event timer: 154, old:
1396008594706, new: 1396008594706
...
2014/03/28 16:09:54 [debug] 22512#0: *102725 event timer del: 154: 1396008594706
2014/03/28 16:09:54 [debug] 22512#0: *102725 http run request: "/test.bin?"
2014/03/28 16:09:54 [debug] 22512#0: *102725 http writer handler: "/test.bin?"
2014/03/28 16:09:54 [info] 22512#0: *102725 client timed out (110:
Connection timed out) while sending response to client, ...

В общем как мне кажется проблема где-то около "sendfile() is not ready
(11: Resource temporarily unavailable)"
Похожая ситуация возникает с sendfile off, но уже "writev() not ready
(11: Resource temporarily unavailable)"

Сервер используется для раздачи видео с модулями mp4/flv, GeoIP вместе
с if/set, lua подсчитывает попадания по каждому урлу в именованный
location @proxy с помощью lua_shared_dict, но по факту и без
выполнения lua возникают проблемы.
Перекомпилировал nginx с необходимыми модулями:
# nginx -V
nginx version: nginx/1.4.7
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-54)
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log
--pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx
--group=nginx --add-module=../../SOURCES/ngx_devel_kit
--add-module=../../SOURCES/lua-nginx-module --with-select_module
--with-poll_module --with-rtsig_module --with-http_flv_module
--with-http_mp4_module --with-http_geoip_module
--with-http_stub_status_module --with-http_secure_link_module
--with-file-aio --with-cc-opt='-O2 -g -m64 -mtune=generic'

kernel 2.6.18-371.6.1.el5 (CentOS 5.10)

На время тестирования пробовал включать все опции по умолчанию,
тестовый файл отдельно от остального контента:
send_timeout 10s;
location = /test.bin {
    root   /cache/data3;
    sendfile on;
}

В чем может быть проблема, в какую сторону копать?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140328/6bc6a3e4/attachment.html>

From vbart at nginx.com  Fri Mar 28 16:04:23 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 28 Mar 2014 20:04:23 +0400
Subject: =?UTF-8?B?UmU6ICLQl9Cw0LzQuNGA0LDQtdGCIiDQv9C10YDQtdC00LDRh9CwINGB0YLQsNGC?=
 =?UTF-8?B?0LjRh9C90L7Qs9C+INGE0LDQudC70LA=?=
In-Reply-To: <CAMSfEarme6BgC0Tg=F9xmD5=Dr8AUtR4ZbCJuOZQHGoRqgtP+A@mail.gmail.com>
References: <CAMSfEarme6BgC0Tg=F9xmD5=Dr8AUtR4ZbCJuOZQHGoRqgtP+A@mail.gmail.com>
Message-ID: <11261632.YB9cSUhv3W@vbart-laptop>

On Friday 28 March 2014 18:47:27 Алексей Щуров wrote:
> Проблема заключается в периодическом "замирании" передачи статичного
> файла, возникает в основном на высокоскоростных соединениях.
> С включенным limit_rate 200k я ни разу не поймал проблему.
> Включил debug_connection для одного тестового клиента, далее
> отфильтрованные записи из лога (могу полный лог отправить если надо):
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 HTTP/1.1 200 OK
> Server: nginx/1.4.7
> Date: Fri, 28 Mar 2014 12:09:44 GMT
> Content-Type: application/octet-stream
> Content-Length: 17775749
> Connection: keep-alive
> ETag: "532070bd-10f3c85"
> Last-Modified: Fri, 2 Jan 1970 00:00:01 GMT
> Accept-Ranges: bytes
> 
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 write new buf t:1 f:0
> 00000000072252E8, pos 00000000072252E8, size: 260 file: 0, size: 0
> ...
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 write old buf t:1 f:0
> 00000000072252E8, pos 00000000072252E8, size: 260 file: 0, size: 0
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 write new buf t:0 f:1
> 0000000000000000, pos 0000000000000000, size: 0 file: 0, size:
> 17775749
> ...
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 writev: 260
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: @0 17775749
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: 3440640, @0
> 3440640:17775749
> ...
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 write old buf t:0 f:1
> 0000000000000000, pos 0000000000000000, size: 0 file: 3440640, size:
> 14335109
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 http write filter: l:1
> f:0 s:14335109
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 http write filter limit 0
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: @3440640 14335109
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile() is not ready
> (11: Resource temporarily unavailable)
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 sendfile: -1, @3440640 0:14335109
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 http write filter 0000000007225478
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 http copy filter: -2 "/test.bin?"
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 http writer output
> filter: -2, "/test.bin?"
> 2014/03/28 16:09:44 [debug] 22512#0: *102725 event timer: 154, old:
> 1396008594706, new: 1396008594706
> ...
> 2014/03/28 16:09:54 [debug] 22512#0: *102725 event timer del: 154: 1396008594706
> 2014/03/28 16:09:54 [debug] 22512#0: *102725 http run request: "/test.bin?"
> 2014/03/28 16:09:54 [debug] 22512#0: *102725 http writer handler: "/test.bin?"
> 2014/03/28 16:09:54 [info] 22512#0: *102725 client timed out (110:
> Connection timed out) while sending response to client, ...

Из лога видно, что клиент отвалился по таймауту, тех 10 секунд
что вы поставили в send_timeout явно не достаточно, вероятно клиент
не успевает потреблять с такой скоростью.

Значение по умолчанию там 60 секунд, зачем трогали?

> 
> В общем как мне кажется проблема где-то около "sendfile() is not ready
> (11: Resource temporarily unavailable)"
> Похожая ситуация возникает с sendfile off, но уже "writev() not ready
> (11: Resource temporarily unavailable)"
[..]

Эти сообщения - часть нормальной работы: сокетный буфер заполнился,
писать больше некуда.

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

From aa.schurov at gmail.com  Fri Mar 28 16:54:50 2014
From: aa.schurov at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KnRg9GA0L7Qsg==?=)
Date: Fri, 28 Mar 2014 20:54:50 +0400
Subject: nginx-ru Digest, Vol 53, Issue 40
In-Reply-To: <mailman.14.1396008001.41502.nginx-ru@nginx.org>
References: <mailman.14.1396008001.41502.nginx-ru@nginx.org>
Message-ID: <CAMSfEape+QOWEpq5AJ7GnOY4_0ojDbzO6mR2OFd3+sV0nW_nCw@mail.gmail.com>

С таймаутом 60 секунд всё тоже самое, только клиент дольше ожидает данные.
У тестового клиента очень высокая скорость и со стороны клиента это
выглядит как быстро передавшиеся первые 1-4 Мбайта, потом полное молчание
со стороны сервера и по таймауту от nginx приходит RST пакет.

Как я понял когда буфер заканчивается sendfile возвращает nginx что он не
полностью отдал файл:
2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: @0 17775749
2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: 1302528, @0
1302528:17775749

а потом nginx по событию готовности клиента вызывает sendfile с последней
позиции:
2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: @1302528 16473221

но у меня почему то стабильно останавливается передача после этой строки:
2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile() is not ready (11:
Resource temporarily unavailable)
2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: -1, @1302528 0:16473221

Это был уже другой пример неудачной передачи и уже на nginx 1.5.12 с таким
же spec файлом.

-----------
Вот так выглядит успешная передача:
2014/03/28 20:48:13 [debug] 9529#0: *115723 sendfile: @0 17775749
2014/03/28 20:48:13 [debug] 9529#0: *115723 sendfile: 17775749, @0
17775749:17775749
...
2014/03/28 20:48:13 [debug] 9529#0: *115723 recv: fd:102 -1 of 4096
2014/03/28 20:48:13 [debug] 9529#0: *115723 recv() not ready (11: Resource
temporarily unavailable)

-----------
Вот так выглядит успешная передача с включенным limit_rate:
2014/03/28 20:49:35 [debug] 9542#0: *118644 write new buf t:0 f:1
0000000000000000, pos 0000000000000000, size: 0 file: 0, size: 9304019
2014/03/28 20:49:35 [debug] 9542#0: *118644 sendfile: @0 1253376
2014/03/28 20:49:35 [debug] 9542#0: *118644 sendfile: 1253376, @0
1253376:1253376
...
2014/03/28 20:49:35 [debug] 9542#0: *118644 event timer add: 68:
1001:1396025376095
...
2014/03/28 20:49:36 [debug] 9542#0: *118644 event timer del: 68:
1396025376095
...
2014/03/28 20:49:36 [debug] 9542#0: *118644 write old buf t:0 f:1
0000000000000000, pos 0000000000000000, size: 0 file: 1253376, size: 8050643
2014/03/28 20:49:36 [debug] 9542#0: *118644 http write filter: l:1 f:0
s:8050643
2014/03/28 20:49:36 [debug] 9542#0: *118644 http write filter limit 204497
2014/03/28 20:49:36 [debug] 9542#0: *118644 sendfile: @1253376 204800
2014/03/28 20:49:36 [debug] 9542#0: *118644 sendfile: 204800, @1253376
204800:204800
...
2014/03/28 20:49:36 [debug] 9542#0: *118644 event timer add: 68:
1000:1396025377294
...
2014/03/28 20:49:37 [debug] 9542#0: *118644 event timer del: 68:
1396025377294
...
2014/03/28 20:49:37 [debug] 9542#0: *118644 write old buf t:0 f:1
0000000000000000, pos 0000000000000000, size: 0 file: 1458176, size: 7845843
2014/03/28 20:49:37 [debug] 9542#0: *118644 http write filter: l:1 f:0
s:7845843
2014/03/28 20:49:37 [debug] 9542#0: *118644 http write filter limit 204497
2014/03/28 20:49:37 [debug] 9542#0: *118644 sendfile: @1458176 204800
2014/03/28 20:49:37 [debug] 9542#0: *118644 sendfile: 204800, @1458176
204800:204800
...
...
2014/03/28 20:50:15 [debug] 9542#0: *118644 sendfile: @9240576 63443
2014/03/28 20:50:15 [debug] 9542#0: *118644 sendfile: 63443, @9240576
63443:63443
...
2014/03/28 20:50:15 [debug] 9542#0: *118644 recv: fd:68 -1 of 4096
2014/03/28 20:50:15 [debug] 9542#0: *118644 recv() not ready (11: Resource
temporarily unavailable)






28 марта 2014 г., 16:00 пользователь <nginx-ru-request at nginx.org> написал:

> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
> отправлять по адресу
>         nginx-ru at nginx.org
>
> Для изменения параметров подписки вы можеже использовать веб-страницу
>         http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> Для получения информации о том, как пользовать почтовым интерфейсом,
> отправьте письмо, в теле или теме которого будет слово 'help', по
> адресу:
>         nginx-ru-request at nginx.org
>
> Адрес человека, ответственного за этот список рассылки:
>         nginx-ru-owner at nginx.org
>
> При ответе, пожалуйста, измение тему письма так, чтобы она была более
> содержательной чем "Re: Содержание дайджеста списка рассылки
> nginx-ru..."
>
> Today's Topics:
>
>    1. start time is out mp4 stsc chunks (Андрей Василишин)
>    2. Re: start time is out mp4 stsc chunks (Maxim Dounin)
>    3. Re: start time is out mp4 stsc chunks (Maxim Dounin)
>    4. Re: start time is out mp4 stsc chunks (Андрей Василишин)
>    5. Re: start time is out mp4 stsc chunks (Maxim Dounin)
>
>
> ---------- Пересылаемое сообщение ----------
> From: "Андрей Василишин" <a.vasilishin at kpi.ua>
> To: nginx-ru at nginx.org
> Cc:
> Date: Thu, 27 Mar 2014 14:19:35 +0200
> Subject: start time is out mp4 stsc chunks
> Добрый день!
> Есть такая проблема: есть 2 сервера с одинаковым конфигом, но разными
> нгинксами, на первом такой:
> # nginx  -V
> nginx version: nginx/1.2.4
> configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf
> --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body
> --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log
> --http-proxy-temp-path=/var/lib/nginx/proxy --lock-path=/var/lock/nginx.lock
> --pid-path=/var/run/nginx.pid --with-debug --with-file-aio
> --with-http_flv_module --with-http_geoip_module --with-http_mp4_module
> --with-http_realip_module --with-http_secure_link_module
> --with-http_stub_status_module --without-http_scgi_module
> --without-http_split_clients_module --without-http_ssi_module
> --without-http_userid_module --without-http_uwsgi_module
>
>
> на втором такой:
> # nginx -V
> nginx version: nginx/1.5.7
> built by gcc 4.7.2 (Debian 4.7.2-5)
> TLS SNI support enabled
> configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
> --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid
> --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp
> --http-proxy-temp-path=/var/cache/nginx/proxy_temp
> --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
> --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
> --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=www-data
> --group=www-data --with-http_ssl_module --with-http_realip_module
> --with-http_addition_module --with-http_sub_module --with-http_dav_module
> --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module
> --with-http_gzip_static_module --with-http_random_index_module
> --with-http_secure_link_module --with-http_stub_status_module
> --with-http_auth_request_module --with-file-aio --with-http_spdy_module
> --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security' --with-ld-opt=-Wl,-z,relro --with-ipv6 --with-debug
>
>
> Один и тот же файл mp4 на первом проигрывается и перематывается нормально,
> а навтором при перемотке возникает ошибка:
>
> 2014/03/26 14:01:55 [debug] 51008#0: *118478378 start_sample:16, new
> count:1
> 2014/03/26 14:01:55 [debug] 51008#0: *118478378 mp4 stss atom update
> 2014/03/26 14:01:55 [debug] 51008#0: *118478378 mp4 ctts atom update
> 2014/03/26 14:01:55 [debug] 51008#0: *118478378 mp4 stsc atom update
> 2014/03/26 14:01:55 [debug] 51008#0: *118478378 start_sample:16, chunk:1,
> chunks:0, samples:36
> 2014/03/26 14:01:55 [error] 51008#0: *118478378 start time is out mp4 stsc
> chunks in "/var/www/test.com-mst3/files/hd_01/file_720.mp4", client:
> 176.104.55.60, server: test.com, request: "GET /s/
> 91f3ee1ab9adaf461376a5e94e4f0eb7/hd_01/file_720.mp4?start=3072.76
> HTTP/1.1", upstream: "http://127.0.0.1:8080/kino.php?code=
> 91f3ee1ab9adaf461376a5e94e4f0eb7&film=hd_01/file_720.mp4&start=3072.76",
> host: "test.com", referrer: "http://filmix.net/uppod.swf"
> 2014/03/26 14:01:55 [debug] 51008#0: *118478378 free: 0000000005600010
> 2014/03/26 14:01:55 [debug] 51008#0: *118478378 free: 000000000201DAB0
> 2014/03/26 14:01:55 [debug] 51008#0: *118478378 http finalize request:
> 500, "/test.com-mst3/files/hd_01/file_720.mp4?code=
> 91f3ee1ab9adaf461376a5e94e4f0eb7&film=hd_01/file_720.mp4&start=3072.76"
> a:1, c:2
> 2014/03/26 14:01:55 [debug] 51008#0: *118478378 http special response:
> 500, "/test.com-mst3/files/hd_01/file_720.mp4?code=
> 91f3ee1ab9adaf461376a5e94e4f0eb7&film=hd_01/file_720.mp4&start=3072.76"
> 2014/03/26 14:01:55 [debug] 51008#0: *118478378 HTTP/1.1 500 Internal
> Server Error
> Server: nginx/1.5.7
>
> Кто виноват и что делать?
>
>
>
>
> ---------- Пересылаемое сообщение ----------
> From: Maxim Dounin <mdounin at mdounin.ru>
> To: nginx-ru at nginx.org
> Cc:
> Date: Thu, 27 Mar 2014 16:59:19 +0400
> Subject: Re: start time is out mp4 stsc chunks
> Hello!
>
> On Thu, Mar 27, 2014 at 02:19:35PM +0200, Андрей Василишин wrote:
>
> > Добрый день!
> > Есть такая проблема: есть 2 сервера с одинаковым конфигом, но разными
> > нгинксами, на первом такой:
> > # nginx  -V
> > nginx version: nginx/1.2.4
>
> [...]
>
> > на втором такой:
> > # nginx -V
> > nginx version: nginx/1.5.7
>
> [...]
>
> > Один и тот же файл mp4 на первом проигрывается и перематывается
> нормально, а
> > навтором при перемотке возникает ошибка:
>
> [...]
>
> > 2014/03/26 14:01:55 [error] 51008#0: *118478378 start time is out mp4
> stsc
> > chunks in "/var/www/test.com-mst3/files/hd_01/file_720.mp4", client:
> > 176.104.55.60, server: test.com, request: "GET
> > /s/91f3ee1ab9adaf461376a5e94e4f0eb7/hd_01/file_720.mp4?start=3072.76
> > HTTP/1.1", upstream: "
> http://127.0.0.1:8080/kino.php?code=91f3ee1ab9adaf461376a5e94e4f0eb7&film=hd_01/file_720.mp4&start=3072.76
> ",
> > host: "test.com", referrer: "http://filmix.net/uppod.swf"
>
> [...]
>
> > Кто виноват и что делать?
>
> Проблема в том, что в mp4-файле присутствует короткая дорожа.
>
> В старых версиях nginx просто выкидывал все дорожки неизвестных
> типов, но начиная с 1.3.5 - оставляет, т.к. предыдущее поведение
> ломало субтитры:
>
>     *) Change: opening and closing a connection without sending any data in
>        it is no longer logged to access_log with error code 400.
>
> Чтобы заработало - нужно либо убрать дорожки из файла, либо
> обновится до nginx 1.5.10+:
>
>     *) Feature: the ngx_http_mp4_module now skips tracks too short for a
>        seek requested.
>
> Подробнее можно почитать где-то тут:
>
> http://trac.nginx.org/nginx/ticket/414
>
> --
> Maxim Dounin
> http://nginx.org/
>
>
>
>
> ---------- Пересылаемое сообщение ----------
> From: Maxim Dounin <mdounin at mdounin.ru>
> To: nginx-ru at nginx.org
> Cc:
> Date: Thu, 27 Mar 2014 17:06:30 +0400
> Subject: Re: start time is out mp4 stsc chunks
> Hello!
>
> On Thu, Mar 27, 2014 at 04:59:19PM +0400, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Thu, Mar 27, 2014 at 02:19:35PM +0200, Андрей Василишин wrote:
> >
> > > Добрый день!
> > > Есть такая проблема: есть 2 сервера с одинаковым конфигом, но разными
> > > нгинксами, на первом такой:
> > > # nginx  -V
> > > nginx version: nginx/1.2.4
> >
> > [...]
> >
> > > на втором такой:
> > > # nginx -V
> > > nginx version: nginx/1.5.7
> >
> > [...]
> >
> > > Один и тот же файл mp4 на первом проигрывается и перематывается
> нормально, а
> > > навтором при перемотке возникает ошибка:
> >
> > [...]
> >
> > > 2014/03/26 14:01:55 [error] 51008#0: *118478378 start time is out mp4
> stsc
> > > chunks in "/var/www/test.com-mst3/files/hd_01/file_720.mp4", client:
> > > 176.104.55.60, server: test.com, request: "GET
> > > /s/91f3ee1ab9adaf461376a5e94e4f0eb7/hd_01/file_720.mp4?start=3072.76
> > > HTTP/1.1", upstream: "
> http://127.0.0.1:8080/kino.php?code=91f3ee1ab9adaf461376a5e94e4f0eb7&film=hd_01/file_720.mp4&start=3072.76
> ",
> > > host: "test.com", referrer: "http://filmix.net/uppod.swf"
> >
> > [...]
> >
> > > Кто виноват и что делать?
> >
> > Проблема в том, что в mp4-файле присутствует короткая дорожа.
> >
> > В старых версиях nginx просто выкидывал все дорожки неизвестных
> > типов, но начиная с 1.3.5 - оставляет, т.к. предыдущее поведение
> > ломало субтитры:
> >
> >     *) Change: opening and closing a connection without sending any data
> in
> >        it is no longer logged to access_log with error code 400.
>
> Opps, should be:
>
>     *) Change: the ngx_http_mp4_module module no longer skips tracks in
>        formats other than H.264 and AAC.
>
> > Чтобы заработало - нужно либо убрать дорожки из файла, либо
> > обновится до nginx 1.5.10+:
> >
> >     *) Feature: the ngx_http_mp4_module now skips tracks too short for a
> >        seek requested.
> >
> > Подробнее можно почитать где-то тут:
> >
> > http://trac.nginx.org/nginx/ticket/414
>
> --
> Maxim Dounin
> http://nginx.org/
>
>
>
>
> ---------- Пересылаемое сообщение ----------
> From: "Андрей Василишин" <a.vasilishin at kpi.ua>
> To: nginx-ru at nginx.org
> Cc:
> Date: Thu, 27 Mar 2014 20:18:55 +0200
> Subject: Re: start time is out mp4 stsc chunks
>
>  Чтобы заработало - нужно либо убрать дорожки из файла, либо
>>> обновится до nginx 1.5.10+:
>>>
>>>
> Спасибо за ответы, Максим!
> Но есть еще вопросы:
> Обновился до
> # nginx -V
> nginx version: nginx/1.5.12
> built by gcc 4.7.2 (Debian 4.7.2-5)
> configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
> --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid
> --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp
> --http-proxy-temp-path=/var/cache/nginx/proxy_temp
> --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
> --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
> --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=www-data
> --group=www-data --with-http_geoip_module --with-http_realip_module
> --with-http_flv_module --with-http_mp4_module --with-http_random_index_module
> --with-http_secure_link_module --with-http_stub_status_module
> --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2
> -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security' --with-ld-opt=-Wl,-z,relro --with-ipv6 --with-debug
>
> Теперь 500-ой общибки при перемотке нет, но при перемотке просто идет
> скачиваение файла и при этом не показывается в плеере ничего, кроме полосы
> загрузки.
>
> Про какие дорожки речь?
> # mediainfo file_720.mp4
> General
> Complete name                            : file_720.mp4
> Format                                   : MPEG-4
> Format profile                           : Base Media
> Codec ID                                 : isom
> File size                                : 995 MiB
> Duration                                 : 1h 54mn
> Overall bit rate mode                    : Variable
> Overall bit rate                         : 1 211 Kbps
> Writing application                      : Lavf55.19.104
>
> Video
> ID                                       : 1
> Format                                   : AVC
> Format/Info                              : Advanced Video Codec
> Format profile                           : High at L3.1
> Format settings, CABAC                   : Yes
> Format settings, ReFrames                : 4 frames
> Codec ID                                 : avc1
> Codec ID/Info                            : Advanced Video Coding
> Duration                                 : 1h 54mn
> Bit rate                                 : 1 024 Kbps
> Width                                    : 1 280 pixels
> Height                                   : 532 pixels
> Display aspect ratio                     : 2.40:1
> Frame rate mode                          : Constant
> Frame rate                               : 25.000 fps
> Color space                              : YUV
> Chroma subsampling                       : 4:2:0
> Bit depth                                : 8 bits
> Scan type                                : Progressive
> Bits/(Pixel*Frame)                       : 0.060
> Stream size                              : 832 MiB (84%)
> Writing library                          : x264 core 142
> Encoding settings                        : cabac=1 / ref=2 / deblock=1:0:0
> / analyse=0x3:0x113 / me=hex / subme=6 / psy=1 / psy_rd=1.00:0.00 /
> mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 /
> deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=24 /
> lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 /
> bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1
> / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=50 /
> keyint_min=5 / scenecut=40 / intra_refresh=0 / rc_lookahead=30 / rc=abr /
> mbtree=1 / bitrate=1024 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 /
> qpstep=4 / ip_ratio=1.40 / aq=1:1.00
> Language                                 : English
>
> Audio
> ID                                       : 2
> Format                                   : AAC
> Format/Info                              : Advanced Audio Codec
> Format profile                           : LC
> Codec ID                                 : 40
> Duration                                 : 1h 54mn
> Bit rate mode                            : Constant
> Bit rate                                 : 192 Kbps
> Channel(s)                               : 6 channels
> Channel positions                        : Front: L C R, Side: L R, LFE
> Sampling rate                            : 48.0 KHz
> Compression mode                         : Lossy
> Delay relative to video                  : -1s 24ms
> Stream size                              : 158 MiB (16%)
> Language                                 : Russian
>
> Text
> ID                                       : 3
> Format                                   : Apple text
> Codec ID                                 : text
> Duration                                 : 1h 54mn
> Bit rate mode                            : Variable
> Bit rate                                 : 0 bps
> Delay relative to video                  : -1s 24ms
> Stream size                              : 135 Bytes (0%)
> Language                                 : English
>
> Menu
> 00:00:00.000                             : 1
> 00:02:49.000                             : 2
> 00:05:38.000                             : 3
> 00:08:32.000                             : 4
> 00:10:52.000                             : 5
> 00:13:50.000                             : 6
> 00:17:46.000                             : 7
> 00:20:37.000                             : 8
> 00:23:30.000                             : 9
> 00:26:28.000                             : 10
> 00:30:05.000                             : 11
> 00:32:16.000                             : 12
> 00:34:57.000                             : 13
> 00:38:15.000                             : 14
> 00:40:28.000                             : 15
> 00:44:47.000                             : 16
> 00:48:09.000                             : 17
> 00:51:25.000                             : 18
> 00:54:31.000                             : 19
> 00:57:23.000                             : 20
> 00:59:57.000                             : 21
> 01:03:05.000                             : 22
> 01:05:23.000                             : 23
> 01:09:21.000                             : 24
> 01:11:17.000                             : 25
> 01:14:01.000                             : 26
> 01:18:25.000                             : 27
> 01:22:44.000                             : 28
> 01:28:46.000                             : 29
> 01:30:17.000                             : 30
> 01:33:47.000                             : 31
> 01:35:32.000                             : 32
> 01:38:17.000                             : 33
> 01:39:41.000                             : 34
> 01:42:54.000                             : 35
> 01:44:20.000                             : 36
>
>
>
>
>
>
> ---------- Пересылаемое сообщение ----------
> From: Maxim Dounin <mdounin at mdounin.ru>
> To: nginx-ru at nginx.org
> Cc:
> Date: Fri, 28 Mar 2014 15:57:04 +0400
> Subject: Re: start time is out mp4 stsc chunks
> Hello!
>
> On Thu, Mar 27, 2014 at 08:18:55PM +0200, Андрей Василишин wrote:
>
> >
> > >>Чтобы заработало - нужно либо убрать дорожки из файла, либо
> > >>обновится до nginx 1.5.10+:
> > >>
> >
> > Спасибо за ответы, Максим!
> > Но есть еще вопросы:
> > Обновился до
> > # nginx -V
> > nginx version: nginx/1.5.12
> > built by gcc 4.7.2 (Debian 4.7.2-5)
>
> [...]
>
> > Теперь 500-ой общибки при перемотке нет, но при перемотке просто идет
> > скачиваение файла и при этом не показывается в плеере ничего, кроме
> полосы
> > загрузки.
> >
> > Про какие дорожки речь?
> > # mediainfo file_720.mp4
> > General
> > Complete name                            : file_720.mp4
> > Format                                   : MPEG-4
> > Format profile                           : Base Media
> > Codec ID                                 : isom
> > File size                                : 995 MiB
> > Duration                                 : 1h 54mn
> > Overall bit rate mode                    : Variable
> > Overall bit rate                         : 1 211 Kbps
> > Writing application                      : Lavf55.19.104
>
> [...]
>
> > Text
> > ID                                       : 3
> > Format                                   : Apple text
> > Codec ID                                 : text
> > Duration                                 : 1h 54mn
> > Bit rate mode                            : Variable
> > Bit rate                                 : 0 bps
> > Delay relative to video                  : -1s 24ms
> > Stream size                              : 135 Bytes (0%)
> > Language                                 : English
>
> Видимо, проблема в этой дорожке.  Она не выглядит короткой, так
> что скорее всего ошибка была из-за каких-то нюансов расположения
> данных.  Но при этом она явно не перемешана с остальными дорожками
> (просто из-за очень малого размера), и попытка отдать диапазон
> файла "начиная с такой-то секунды", видимо, требует отдачи
> практически всего файла, т.к. для этой дорожки данные начинаются в
> начале файла.
>
> Наиболее простое решение - убрать из файла эту дорожку.
>
> --
> Maxim Dounin
> http://nginx.org/
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 

Regards,
 Alexey Schurov
 e-mail: aa.schurov at gmail.com
 Mob: +7 9160 624477
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140328/37f976a8/attachment-0001.html>

From a.vasilishin at kpi.ua  Fri Mar 28 17:18:37 2014
From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=)
Date: Fri, 28 Mar 2014 19:18:37 +0200
Subject: start time is out mp4 stsc chunks
In-Reply-To: <20140328115704.GJ34696@mdounin.ru>
References: <53341757.7030601@kpi.ua> <20140327125919.GX34696@mdounin.ru>
 <20140327130630.GZ34696@mdounin.ru> <53346B8F.6050309@kpi.ua>
 <20140328115704.GJ34696@mdounin.ru>
Message-ID: <5335AEED.6000800@kpi.ua>


>> Text
>> ID                                       : 3
>> Format                                   : Apple text
>> Codec ID                                 : text
>> Duration                                 : 1h 54mn
>> Bit rate mode                            : Variable
>> Bit rate                                 : 0 bps
>> Delay relative to video                  : -1s 24ms
>> Stream size                              : 135 Bytes (0%)
>> Language                                 : English
>
> Видимо, проблема в этой дорожке.  Она не выглядит короткой, так
> что скорее всего ошибка была из-за каких-то нюансов расположения
> данных.  Но при этом она явно не перемешана с остальными дорожками
> (просто из-за очень малого размера), и попытка отдать диапазон
> файла "начиная с такой-то секунды", видимо, требует отдачи
> практически всего файла, т.к. для этой дорожки данные начинаются в
> начале файла.
>
> Наиболее простое решение - убрать из файла эту дорожку.
>

А как же обновление до nginx 1.5.10+, это непомогает?


From vbart at nginx.com  Fri Mar 28 18:02:18 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 28 Mar 2014 22:02:18 +0400
Subject: =?UTF-8?B?UmU6ICLQl9Cw0LzQuNGA0LDQtdGCIiDQv9C10YDQtdC00LDRh9CwINGB0YLQsNGC?=
 =?UTF-8?B?0LjRh9C90L7Qs9C+INGE0LDQudC70LA=?=
In-Reply-To: <CAMSfEape+QOWEpq5AJ7GnOY4_0ojDbzO6mR2OFd3+sV0nW_nCw@mail.gmail.com>
References: <mailman.14.1396008001.41502.nginx-ru@nginx.org>
 <CAMSfEape+QOWEpq5AJ7GnOY4_0ojDbzO6mR2OFd3+sV0nW_nCw@mail.gmail.com>
Message-ID: <4901734.Cy4kXH9oxx@vbart-laptop>

On Friday 28 March 2014 20:54:50 Алексей Щуров wrote:
> С таймаутом 60 секунд всё тоже самое, только клиент дольше ожидает данные.
> У тестового клиента очень высокая скорость и со стороны клиента это
> выглядит как быстро передавшиеся первые 1-4 Мбайта, потом полное молчание
> со стороны сервера и по таймауту от nginx приходит RST пакет.
> 
> Как я понял когда буфер заканчивается sendfile возвращает nginx что он не
> полностью отдал файл:
> 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: @0 17775749
> 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: 1302528, @0
> 1302528:17775749

Мы не знаем причину по которой sendfile() отдал файл не полностью, поэтому
зовем sendfile() ещё раз.

> 
> а потом nginx по событию готовности клиента вызывает sendfile с последней
> позиции:
> 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: @1302528 16473221

Это не по событию, это просто следующий вызов sendfile() на очередной
итерации цикла.  В этом нет ничего необычного.


> 
> но у меня почему то стабильно останавливается передача после этой строки:
> 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile() is not ready (11:
> Resource temporarily unavailable)
> 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: -1, @1302528 0:16473221
> 
> Это был уже другой пример неудачной передачи и уже на nginx 1.5.12 с таким
> же spec файлом.

Значит о событии готовности nginx-у больше не сообщают.  Либо клиент просто
больше не читает из-за ошибки в самом клиенте или из-за проблем с сетью,
либо ядро не сообщает (2.6.18 - тухлый антиквариат, там может быть что 
угодно), или же где-то ошибка в nginx.

Стоит посмотреть тем же tcpdump-ом что происходит при этом на соединении.

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

From mdounin at mdounin.ru  Fri Mar 28 18:13:39 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 28 Mar 2014 22:13:39 +0400
Subject: nginx-ru Digest, Vol 53, Issue 40
In-Reply-To: <CAMSfEape+QOWEpq5AJ7GnOY4_0ojDbzO6mR2OFd3+sV0nW_nCw@mail.gmail.com>
References: <mailman.14.1396008001.41502.nginx-ru@nginx.org>
 <CAMSfEape+QOWEpq5AJ7GnOY4_0ojDbzO6mR2OFd3+sV0nW_nCw@mail.gmail.com>
Message-ID: <20140328181339.GV34696@mdounin.ru>

Hello!

On Fri, Mar 28, 2014 at 08:54:50PM +0400, Алексей Щуров wrote:

(В скобках замечу, что отвечать на digest - это плохая идея, т.к. 
в результате не строятся цепочки сообщений и нет возможности 
нормально посмотреть историю.)

> С таймаутом 60 секунд всё тоже самое, только клиент дольше ожидает данные.
> У тестового клиента очень высокая скорость и со стороны клиента это
> выглядит как быстро передавшиеся первые 1-4 Мбайта, потом полное молчание
> со стороны сервера и по таймауту от nginx приходит RST пакет.
> 
> Как я понял когда буфер заканчивается sendfile возвращает nginx что он не
> полностью отдал файл:
> 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: @0 17775749
> 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: 1302528, @0
> 1302528:17775749
> 
> а потом nginx по событию готовности клиента вызывает sendfile с последней
> позиции:
> 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: @1302528 16473221
> 
> но у меня почему то стабильно останавливается передача после этой строки:
> 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile() is not ready (11:
> Resource temporarily unavailable)
> 2014/03/28 20:40:22 [debug] 9564#0: *99502 sendfile: -1, @1302528 0:16473221

По получению EAGAIN из sendfile'а nginx должен сказать ядру (если 
не сделал этого ранее), что ему следует уведомить nginx о 
возможности записи в указанный сокет.  А ядро, соответственно - 
уведомить nginx, когда такая возможность появится.

Если этого не происходит, то возможно одно из двух:

1) В nginx'е где-то ошибка, и соответствующий event не 
устанавливается.

2) В ядре где-то ошибка, и о соответствующем event'е nginx'у не 
сообщают. 

Чтобы понять, что именно происходит, нужно как минимум видеть 
полный конфиг и полный debug log, а равно вывод "nginx -V" и 
информацию о системе.

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

http://wiki.nginx.org/Debugging

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


From mdounin at mdounin.ru  Fri Mar 28 18:24:49 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 28 Mar 2014 22:24:49 +0400
Subject: start time is out mp4 stsc chunks
In-Reply-To: <5335AEED.6000800@kpi.ua>
References: <53341757.7030601@kpi.ua> <20140327125919.GX34696@mdounin.ru>
 <20140327130630.GZ34696@mdounin.ru> <53346B8F.6050309@kpi.ua>
 <20140328115704.GJ34696@mdounin.ru> <5335AEED.6000800@kpi.ua>
Message-ID: <20140328182449.GW34696@mdounin.ru>

Hello!

On Fri, Mar 28, 2014 at 07:18:37PM +0200, Андрей Василишин wrote:

> 
> >>Text
> >>ID                                       : 3
> >>Format                                   : Apple text
> >>Codec ID                                 : text
> >>Duration                                 : 1h 54mn
> >>Bit rate mode                            : Variable
> >>Bit rate                                 : 0 bps
> >>Delay relative to video                  : -1s 24ms
> >>Stream size                              : 135 Bytes (0%)
> >>Language                                 : English
> >
> >Видимо, проблема в этой дорожке.  Она не выглядит короткой, так
> >что скорее всего ошибка была из-за каких-то нюансов расположения
> >данных.  Но при этом она явно не перемешана с остальными дорожками
> >(просто из-за очень малого размера), и попытка отдать диапазон
> >файла "начиная с такой-то секунды", видимо, требует отдачи
> >практически всего файла, т.к. для этой дорожки данные начинаются в
> >начале файла.
> >
> >Наиболее простое решение - убрать из файла эту дорожку.
> >
> 
> А как же обновление до nginx 1.5.10+, это непомогает?

Помогает, насколько я понял, ошибок же больше нет?

Последняя рекомендация касается того факта, что при "перемотке 
просто идёт скачивание файла".  Насколько я понимаю структуру 
файла, любой или почти любой запрос медиаданных по времени - будет 
включать практически весь файл целиком, и псевдостриминг теряет 
смысл.

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


From a.vasilishin at kpi.ua  Fri Mar 28 21:15:54 2014
From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=)
Date: Fri, 28 Mar 2014 23:15:54 +0200
Subject: start time is out mp4 stsc chunks
In-Reply-To: <20140328182449.GW34696@mdounin.ru>
References: <53341757.7030601@kpi.ua> <20140327125919.GX34696@mdounin.ru>
 <20140327130630.GZ34696@mdounin.ru> <53346B8F.6050309@kpi.ua>
 <20140328115704.GJ34696@mdounin.ru> <5335AEED.6000800@kpi.ua>
 <20140328182449.GW34696@mdounin.ru>
Message-ID: <5335E68A.1060703@kpi.ua>

28.03.2014 20:24, Maxim Dounin пишет:
> Hello!
>
> On Fri, Mar 28, 2014 at 07:18:37PM +0200, Андрей Василишин wrote:
>
>>
>>>> Text
>>>> ID                                       : 3
>>>> Format                                   : Apple text
>>>> Codec ID                                 : text
>>>> Duration                                 : 1h 54mn
>>>> Bit rate mode                            : Variable
>>>> Bit rate                                 : 0 bps
>>>> Delay relative to video                  : -1s 24ms
>>>> Stream size                              : 135 Bytes (0%)
>>>> Language                                 : English
>>>
>>> Видимо, проблема в этой дорожке.  Она не выглядит короткой, так
>>> что скорее всего ошибка была из-за каких-то нюансов расположения
>>> данных.  Но при этом она явно не перемешана с остальными дорожками
>>> (просто из-за очень малого размера), и попытка отдать диапазон
>>> файла "начиная с такой-то секунды", видимо, требует отдачи
>>> практически всего файла, т.к. для этой дорожки данные начинаются в
>>> начале файла.
>>>
>>> Наиболее простое решение - убрать из файла эту дорожку.
>>>
>>
>> А как же обновление до nginx 1.5.10+, это непомогает?
>
> Помогает, насколько я понял, ошибок же больше нет?
>
> Последняя рекомендация касается того факта, что при "перемотке
> просто идёт скачивание файла".  Насколько я понимаю структуру
> файла, любой или почти любой запрос медиаданных по времени - будет
> включать практически весь файл целиком, и псевдостриминг теряет
> смысл.
>


Но ведь это дорожка субтитров, получается, до 1.3.5 ее просто 
отбрасывало, а после 1.5.10 не работает псевдостримминг.


From universite at ukr.net  Fri Mar 28 23:43:41 2014
From: universite at ukr.net (Vladislav Prodan)
Date: Sat, 29 Mar 2014 01:43:41 +0200
Subject: =?UTF-8?B?0KHRgtGA0LDQvdC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUg0YEgaHR0cHJlYWR5?=
 =?UTF-8?B?INC4IGRhdGFyZWFkeQ==?=
Message-ID: <1396050046.72682922.828a5r7a@frv35.fwdcdn.com>


# grep accept_filter nginx.conf
  listen xx.xx.xx.57 accept_filter=httpready accept_filter=dataready ;
  listen xx.xx.xx.60 accept_filter=httpready accept_filter=dataready ;
  listen xx.xx.xx.58 accept_filter=httpready accept_filter=dataready ;
  listen xx.xx.xx.56 accept_filter=httpready accept_filter=dataready ;

				
В итоге отдельные боты долбят небольшими пакетами овер 5kpps

...
01:34:20.942605 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    5.10.83.89.41060 > xx.xx.xx.58.80: Flags [.], cksum 0x871a (correct), seq 2, ack 1, win 115, options [nop,nop,TS val 1334154219 ecr 2410240396], length 0
01:34:20.942613 IP (tos 0x0, ttl 64, id 44144, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->766c)!)
    xx.xx.xx.58.80 > 5.10.83.89.41060: Flags [.], cksum 0x180e (incorrect -> 0x8d2d), seq 0, ack 1, win 32, length 0
01:34:20.942615 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    5.10.83.89.41060 > xx.xx.xx.58.80: Flags [.], cksum 0x871a (correct), seq 2, ack 1, win 115, options [nop,nop,TS val 1334154219 ecr 2410240396], length 0
01:34:20.942622 IP (tos 0x0, ttl 64, id 44145, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->766b)!)
    xx.xx.xx.58.80 > 5.10.83.89.41060: Flags [.], cksum 0x180e (incorrect -> 0x8d2d), seq 0, ack 1, win 32, length 0
01:34:20.942976 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    5.10.83.89.41060 > xx.xx.xx.58.80: Flags [.], cksum 0x871a (correct), seq 2, ack 1, win 115, options [nop,nop,TS val 1334154219 ecr 2410240396], length 0
01:34:20.942986 IP (tos 0x0, ttl 64, id 44146, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->766a)!)
    xx.xx.xx.58.80 > 5.10.83.89.41060: Flags [.], cksum 0x180e (incorrect -> 0x8d2d), seq 0, ack 1, win 32, length 0
01:34:20.942988 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    5.10.83.89.41060 > xx.xx.xx.58.80: Flags [.], cksum 0x871a (correct), seq 2, ack 1, win 115, options [nop,nop,TS val 1334154219 ecr 2410240396], length 0
01:34:20.942996 IP (tos 0x0, ttl 64, id 44147, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 0 (->7669)!)
    xx.xx.xx.58.80 > 5.10.83.89.41060: Flags [.], cksum 0x180e (incorrect -> 0x8d2d), seq 0, ack 1, win 32, length 0
...
	

# nginx -V
nginx version: nginx/1.4.7
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-file-aio --with-ipv6 --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_flv_module --with-http_stub_status_module --with-http_sub_module --with-pcre --with-http_ssl_module

# uname -a
FreeBSD vm-10-1.domain.com 10.0-STABLE FreeBSD 10.0-STABLE #0: Tue Mar 18 23:06:27 EET 2014     root at vm-10-1.domain.com:/usr/obj/usr/src/sys/vm-10.3  amd64

# kldstat -v | grep accf_
                285 accf_http
                284 accf_dns
                283 accf_data
			

-- 
Vladislav V. Prodan 
System & Network Administrator 
http://support.od.ua 
+380 67 4584408, +380 99 4060508
VVP88-RIPE


From postmaster at softsearch.ru  Sat Mar 29 06:50:52 2014
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Sat, 29 Mar 2014 10:50:52 +0400
Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1INGBIGh0dHBy?=
 =?UTF-8?B?ZWFkeSDQuCBkYXRhcmVhZHk=?=
In-Reply-To: <1396050046.72682922.828a5r7a@frv35.fwdcdn.com>
References: <1396050046.72682922.828a5r7a@frv35.fwdcdn.com>
Message-ID: <1447281370.20140329105052@softsearch.ru>

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

> # grep accept_filter nginx.conf
>   listen xx.xx.xx.57 accept_filter=httpready accept_filter=dataready ;
>   listen xx.xx.xx.60 accept_filter=httpready accept_filter=dataready ;
>   listen xx.xx.xx.58 accept_filter=httpready accept_filter=dataready ;
>   listen xx.xx.xx.56 accept_filter=httpready accept_filter=dataready ;

Если  я  не  ошибаюсь, то нет смысла использовать dataready, если есть
httpready.  Они  про  одно  и  тоже,  только второй ещё проверяет, что
пришедшие данные похожи на HTTP.

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


From universite at ukr.net  Sat Mar 29 22:55:25 2014
From: universite at ukr.net (Vladislav Prodan)
Date: Sun, 30 Mar 2014 00:55:25 +0200
Subject: =?UTF-8?B?UmVbMl06INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1INGBIGh0?=
 =?UTF-8?B?dHByZWFkeSDQuCBkYXRhcmVhZHk=?=
In-Reply-To: <1447281370.20140329105052@softsearch.ru>
References: <1396050046.72682922.828a5r7a@frv35.fwdcdn.com>
 <1447281370.20140329105052@softsearch.ru>
Message-ID: <1396133631.898325553.ra7gv2ss@frv35.fwdcdn.com>



 
 --- Исходное сообщение ---
 От кого: "Михаил Монашёв" <postmaster at softsearch.ru>
 Дата: 29 марта 2014, 08:53:59
  


> Здравствуйте, Vladislav.
> 
> > # grep accept_filter nginx.conf
> > listen xx.xx.xx.57 accept_filter=httpready accept_filter=dataready ;
> > listen xx.xx.xx.60 accept_filter=httpready accept_filter=dataready ;
> > listen xx.xx.xx.58 accept_filter=httpready accept_filter=dataready ;
> > listen xx.xx.xx.56 accept_filter=httpready accept_filter=dataready ;
> 
> Если я не ошибаюсь, то нет смысла использовать dataready, если есть
> httpready. Они про одно и тоже, только второй ещё проверяет, что
> пришедшие данные похожи на HTTP.
> 

Тем не менее, сабж очень неприятный - лавинообразный рост мелких пакетов.
Хотелось бы выяснить, в этом виноват nginx или модули accf_http+accf_data ?



-- 
Vladislav V. Prodan 
System & Network Administrator 
http://support.od.ua 
+380 67 4584408, +380 99 4060508
VVP88-RIPE
 


From postmaster at softsearch.ru  Sun Mar 30 07:58:50 2014
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Sun, 30 Mar 2014 11:58:50 +0400
Subject: =?UTF-8?B?UmVbM106INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1INGBIGh0?=
 =?UTF-8?B?dHByZWFkeSDQuCBkYXRhcmVhZHk=?=
In-Reply-To: <1396133631.898325553.ra7gv2ss@frv35.fwdcdn.com>
References: <1396050046.72682922.828a5r7a@frv35.fwdcdn.com>
 <1447281370.20140329105052@softsearch.ru>
 <1396133631.898325553.ra7gv2ss@frv35.fwdcdn.com>
Message-ID: <1334785671.20140330115850@softsearch.ru>

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

>> > # grep accept_filter nginx.conf
>> > listen xx.xx.xx.57 accept_filter=httpready accept_filter=dataready ;
>> > listen xx.xx.xx.60 accept_filter=httpready accept_filter=dataready ;
>> > listen xx.xx.xx.58 accept_filter=httpready accept_filter=dataready ;
>> > listen xx.xx.xx.56 accept_filter=httpready accept_filter=dataready ;
>> 
>> Если я не ошибаюсь, то нет смысла использовать dataready, если есть
>> httpready. Они про одно и тоже, только второй ещё проверяет, что
>> пришедшие данные похожи на HTTP.
>> 

> Тем не менее, сабж очень неприятный - лавинообразный рост мелких пакетов.
> Хотелось бы выяснить, в этом виноват nginx или модули accf_http+accf_data ?

Оставьте один фильтр httpready и весь мусор, не похожий на HTTP до
nginx-а не будет доходить.

И где этот рост мелких пакетов происходит? Чем они Вам мешают?


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


From universite at ukr.net  Sun Mar 30 13:08:07 2014
From: universite at ukr.net (Vladislav Prodan)
Date: Sun, 30 Mar 2014 16:08:07 +0300
Subject: =?UTF-8?B?UmVbNF06INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1INGBIGh0?=
 =?UTF-8?B?dHByZWFkeSDQuCBkYXRhcmVhZHk=?=
In-Reply-To: <1334785671.20140330115850@softsearch.ru>
References: <1396050046.72682922.828a5r7a@frv35.fwdcdn.com>
 <1447281370.20140329105052@softsearch.ru>
 <1396133631.898325553.ra7gv2ss@frv35.fwdcdn.com>
 <1334785671.20140330115850@softsearch.ru>
Message-ID: <1396184357.631842979.igvh1tcr@frv35.fwdcdn.com>



 
 --- Исходное сообщение ---
 От кого: "Михаил Монашёв" <postmaster at softsearch.ru>
 Дата: 30 марта 2014, 10:59:26
  


> Здравствуйте, Vladislav.
> 
> >> > # grep accept_filter nginx.conf
> >> > listen xx.xx.xx.57 accept_filter=httpready accept_filter=dataready ;
> >> > listen xx.xx.xx.60 accept_filter=httpready accept_filter=dataready ;
> >> > listen xx.xx.xx.58 accept_filter=httpready accept_filter=dataready ;
> >> > listen xx.xx.xx.56 accept_filter=httpready accept_filter=dataready ;
> >> 
> >> Если я не ошибаюсь, то нет смысла использовать dataready, если есть
> >> httpready. Они про одно и тоже, только второй ещё проверяет, что
> >> пришедшие данные похожи на HTTP.
> >> 
> 
> > Тем не менее, сабж очень неприятный - лавинообразный рост мелких пакетов.
> > Хотелось бы выяснить, в этом виноват nginx или модули accf_http+accf_data ?
> 
> Оставьте один фильтр httpready и весь мусор, не похожий на HTTP до
> nginx-а не будет доходить.
> 
> И где этот рост мелких пакетов происходит? Чем они Вам мешают?
> 

8kpps unicast пакетов в обе стороны с сетевого интерфейса.
Реалтек выдерживает до 100 kpps.
При лавинном росте - этот предел будет достигнут через 10-12 часов.
Напоминаю, большие значение pps больны и неприятны в первую очередь провайдеру-хостеру, и уж потом непосредственно серверу.


-- 
Vladislav V. Prodan 
System & Network Administrator 
http://support.od.ua 
+380 67 4584408, +380 99 4060508
VVP88-RIPE
 


From nginx-forum at nginx.us  Sun Mar 30 13:47:02 2014
From: nginx-forum at nginx.us (ast-ross)
Date: Sun, 30 Mar 2014 09:47:02 -0400
Subject: =?UTF-8?B?Y2xpZW50IG1heCBib2R5IHNpemUg0LIg0LvQvtC60LXQudGI0LjQvdC1?=
Message-ID: <ff5c01a6de943523a8645d292100d057.NginxMailingListRussian@forum.nginx.org>

Никак не могу решить проблему с client_max_body_size

В общем суть в том что есть только 1 входной файл index.php (YII Framework)
вот конфиг:

========================
server {
    listen 80;
    server_name example.com;
    client_max_body_size 1m;

    set  $home_root "/var/www/mysite";
    root $home_root/public;

    location /manage {
        client_max_body_size 100m;
        try_files $uri $uri/ /index.php?$args;
    }

    location / {
        index  index.php index.html;
        try_files $uri $uri/ /index.php?$args;
    }
                                                                  
    location ~ \.php {                                            
        fastcgi_split_path_info  ^(.+\.php)(.*)$;                 
        set $fsn /index.php;                                      
        if (-f $document_root$fastcgi_script_name) { set $fsn
$fastcgi_script_name; }
        fastcgi_pass   backend-php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fsn;
        fastcgi_param  PATH_INFO        $fastcgi_path_info;
        fastcgi_param  PATH_TRANSLATED  $document_root$fsn;
        include fastcgi_params;
    }
    
}
========================

В самом фреймворке роутинг для админки прописывается на подобии
/manage/publication/edit/12 /manage/publication/delete/12
/manage/publication/12/files и т.д. 

Так вот для всех URL которые начинаются на manage надо увеличить
client_max_body_size что я и попытался сделать в приведенном конфиге. Не
сработало, видимо потоу что с локейшена /manage запрос все равно уходит в
локейшен / а там видимо client_max_body_size = 1m

Как решить эту задачу?

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


From danila at shtan.ru  Mon Mar 31 04:55:03 2014
From: danila at shtan.ru (Danila Shtan)
Date: Mon, 31 Mar 2014 10:55:03 +0600
Subject: =?UTF-8?B?UmU6IGNsaWVudCBtYXggYm9keSBzaXplINCyINC70L7QutC10LnRiNC40L3QtQ==?=
In-Reply-To: <ff5c01a6de943523a8645d292100d057.NginxMailingListRussian@forum.nginx.org>
References: <ff5c01a6de943523a8645d292100d057.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CALUn_U4EzgexW0Y1AmZRh=20aHJYT8imkVgJsXLz4493GcPfKg@mail.gmail.com>

Определить  location ~ \.php { внутри location /manage
http://nginx.org/ru/docs/http/ngx_http_core_module.html#location

Д.


2014-03-30 19:47 GMT+06:00 ast-ross <nginx-forum at nginx.us>:

> Никак не могу решить проблему с client_max_body_size
>
> В общем суть в том что есть только 1 входной файл index.php (YII Framework)
> вот конфиг:
>
> ========================
> server {
>     listen 80;
>     server_name example.com;
>     client_max_body_size 1m;
>
>     set  $home_root "/var/www/mysite";
>     root $home_root/public;
>
>     location /manage {
>         client_max_body_size 100m;
>         try_files $uri $uri/ /index.php?$args;
>     }
>
>     location / {
>         index  index.php index.html;
>         try_files $uri $uri/ /index.php?$args;
>     }
>
>     location ~ \.php {
>         fastcgi_split_path_info  ^(.+\.php)(.*)$;
>         set $fsn /index.php;
>         if (-f $document_root$fastcgi_script_name) { set $fsn
> $fastcgi_script_name; }
>         fastcgi_pass   backend-php;
>         fastcgi_param  SCRIPT_FILENAME  $document_root$fsn;
>         fastcgi_param  PATH_INFO        $fastcgi_path_info;
>         fastcgi_param  PATH_TRANSLATED  $document_root$fsn;
>         include fastcgi_params;
>     }
>
> }
> ========================
>
> В самом фреймворке роутинг для админки прописывается на подобии
> /manage/publication/edit/12 /manage/publication/delete/12
> /manage/publication/12/files и т.д.
>
> Так вот для всех URL которые начинаются на manage надо увеличить
> client_max_body_size что я и попытался сделать в приведенном конфиге. Не
> сработало, видимо потоу что с локейшена /manage запрос все равно уходит в
> локейшен / а там видимо client_max_body_size = 1m
>
> Как решить эту задачу?
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,248855,248855#msg-248855
>
> _______________________________________________
> 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/20140331/69a4677e/attachment.html>

From mdounin at mdounin.ru  Mon Mar 31 11:29:40 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 31 Mar 2014 15:29:40 +0400
Subject: start time is out mp4 stsc chunks
In-Reply-To: <5335E68A.1060703@kpi.ua>
References: <53341757.7030601@kpi.ua> <20140327125919.GX34696@mdounin.ru>
 <20140327130630.GZ34696@mdounin.ru> <53346B8F.6050309@kpi.ua>
 <20140328115704.GJ34696@mdounin.ru> <5335AEED.6000800@kpi.ua>
 <20140328182449.GW34696@mdounin.ru> <5335E68A.1060703@kpi.ua>
Message-ID: <20140331112940.GC34696@mdounin.ru>

Hello!

On Fri, Mar 28, 2014 at 11:15:54PM +0200, Андрей Василишин wrote:

> 28.03.2014 20:24, Maxim Dounin пишет:
> >Hello!
> >
> >On Fri, Mar 28, 2014 at 07:18:37PM +0200, Андрей Василишин wrote:
> >
> >>
> >>>>Text
> >>>>ID                                       : 3
> >>>>Format                                   : Apple text
> >>>>Codec ID                                 : text
> >>>>Duration                                 : 1h 54mn
> >>>>Bit rate mode                            : Variable
> >>>>Bit rate                                 : 0 bps
> >>>>Delay relative to video                  : -1s 24ms
> >>>>Stream size                              : 135 Bytes (0%)
> >>>>Language                                 : English
> >>>
> >>>Видимо, проблема в этой дорожке.  Она не выглядит короткой, так
> >>>что скорее всего ошибка была из-за каких-то нюансов расположения
> >>>данных.  Но при этом она явно не перемешана с остальными дорожками
> >>>(просто из-за очень малого размера), и попытка отдать диапазон
> >>>файла "начиная с такой-то секунды", видимо, требует отдачи
> >>>практически всего файла, т.к. для этой дорожки данные начинаются в
> >>>начале файла.
> >>>
> >>>Наиболее простое решение - убрать из файла эту дорожку.
> >>>
> >>
> >>А как же обновление до nginx 1.5.10+, это непомогает?
> >
> >Помогает, насколько я понял, ошибок же больше нет?
> >
> >Последняя рекомендация касается того факта, что при "перемотке
> >просто идёт скачивание файла".  Насколько я понимаю структуру
> >файла, любой или почти любой запрос медиаданных по времени - будет
> >включать практически весь файл целиком, и псевдостриминг теряет
> >смысл.
> >
> 
> 
> Но ведь это дорожка субтитров, получается, до 1.3.5 ее просто отбрасывало, а
> после 1.5.10 не работает псевдостримминг.

Как я уже пытался объяснить выше, судя по всему, одни и те же 
данные этой дорожки - относятся ко всему временному диапазону, и 
эти данные располагаются в начале файла.  Т.к. при псевдостриминге 
nginx отдаёт диапазон медиаданных, от первого байта самых ранних 
данных какой-либо из дорожек и до конца файла, то в такой ситуации 
псевдостриминг становится фактически бесполезен.  Приблизительно 
то же самое будет если, например, аудио и видео дорожки не 
перемешаны между собой, а записаны последовательно.

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


From mdounin at mdounin.ru  Mon Mar 31 11:35:10 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 31 Mar 2014 15:35:10 +0400
Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1INGBIGh0dHBy?=
 =?UTF-8?B?ZWFkeSDQuCBkYXRhcmVhZHk=?=
In-Reply-To: <1334785671.20140330115850@softsearch.ru>
References: <1396050046.72682922.828a5r7a@frv35.fwdcdn.com>
 <1447281370.20140329105052@softsearch.ru>
 <1396133631.898325553.ra7gv2ss@frv35.fwdcdn.com>
 <1334785671.20140330115850@softsearch.ru>
Message-ID: <20140331113510.GD34696@mdounin.ru>

Hello!

On Sun, Mar 30, 2014 at 11:58:50AM +0400, Михаил Монашёв wrote:

> Здравствуйте, Vladislav.
> 
> >> > # grep accept_filter nginx.conf
> >> > listen xx.xx.xx.57 accept_filter=httpready accept_filter=dataready ;
> >> > listen xx.xx.xx.60 accept_filter=httpready accept_filter=dataready ;
> >> > listen xx.xx.xx.58 accept_filter=httpready accept_filter=dataready ;
> >> > listen xx.xx.xx.56 accept_filter=httpready accept_filter=dataready ;
> >> 
> >> Если я не ошибаюсь, то нет смысла использовать dataready, если есть
> >> httpready. Они про одно и тоже, только второй ещё проверяет, что
> >> пришедшие данные похожи на HTTP.
> >> 
> 
> > Тем не менее, сабж очень неприятный - лавинообразный рост мелких пакетов.
> > Хотелось бы выяснить, в этом виноват nginx или модули accf_http+accf_data ?
> 
> Оставьте один фильтр httpready и весь мусор, не похожий на HTTP до
> nginx-а не будет доходить.

Нет, фильтр httpready - пропускает всё, что не похоже на 
http (если совсем точно - на GET или HEAD-запрос).  Его 
предназначение - дождаться, пока клиент пришлёт запрос полностью, 
тем самым по возможности уменьшив количество соединений в 
приложении.  Но никаким отсечением чего-либо некорректного он не 
занимается.

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


From nginx-forum at nginx.us  Mon Mar 31 11:44:29 2014
From: nginx-forum at nginx.us (ast-ross)
Date: Mon, 31 Mar 2014 07:44:29 -0400
Subject: =?UTF-8?B?UmU6IGNsaWVudCBtYXggYm9keSBzaXplINCyINC70L7QutC10LnRiNC40L3QtQ==?=
In-Reply-To: <CALUn_U4EzgexW0Y1AmZRh=20aHJYT8imkVgJsXLz4493GcPfKg@mail.gmail.com>
References: <CALUn_U4EzgexW0Y1AmZRh=20aHJYT8imkVgJsXLz4493GcPfKg@mail.gmail.com>
Message-ID: <6b24304b27d09507f34c2ff05a41632a.NginxMailingListRussian@forum.nginx.org>

И что это даст?

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


From universite at ukr.net  Mon Mar 31 11:45:09 2014
From: universite at ukr.net (Vladislav Prodan)
Date: Mon, 31 Mar 2014 14:45:09 +0300
Subject: =?UTF-8?B?UmVbMl06INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1INGBIGh0?=
 =?UTF-8?B?dHByZWFkeSDQuCBkYXRhcmVhZHk=?=
In-Reply-To: <20140331113510.GD34696@mdounin.ru>
References: <1396050046.72682922.828a5r7a@frv35.fwdcdn.com>
 <1447281370.20140329105052@softsearch.ru>
 <1396133631.898325553.ra7gv2ss@frv35.fwdcdn.com>
 <1334785671.20140330115850@softsearch.ru>
 <20140331113510.GD34696@mdounin.ru>
Message-ID: <1396266309.502577209.c5f3uf9m@frv35.fwdcdn.com>



 
 --- Исходное сообщение ---
 От кого: "Maxim Dounin" <mdounin at mdounin.ru>
 Дата: 31 марта 2014, 14:35:14
  


> Hello!
> 
> On Sun, Mar 30, 2014 at 11:58:50AM +0400, Михаил Монашёв wrote:
> 
> > Здравствуйте, Vladislav.
> > 
> > >> > # grep accept_filter nginx.conf
> > >> > listen xx.xx.xx.57 accept_filter=httpready accept_filter=dataready ;
> > >> > listen xx.xx.xx.60 accept_filter=httpready accept_filter=dataready ;
> > >> > listen xx.xx.xx.58 accept_filter=httpready accept_filter=dataready ;
> > >> > listen xx.xx.xx.56 accept_filter=httpready accept_filter=dataready ;
> > >> 
> > >> Если я не ошибаюсь, то нет смысла использовать dataready, если есть
> > >> httpready. Они про одно и тоже, только второй ещё проверяет, что
> > >> пришедшие данные похожи на HTTP.
> > >> 
> > 
> > > Тем не менее, сабж очень неприятный - лавинообразный рост мелких пакетов.
> > > Хотелось бы выяснить, в этом виноват nginx или модули accf_http+accf_data ?
> > 
> > Оставьте один фильтр httpready и весь мусор, не похожий на HTTP до
> > nginx-а не будет доходить.
> 
> Нет, фильтр httpready - пропускает всё, что не похоже на 
> http (если совсем точно - на GET или HEAD-запрос). Его 
> предназначение - дождаться, пока клиент пришлёт запрос полностью, 
> тем самым по возможности уменьшив количество соединений в 
> приложении. Но никаким отсечением чего-либо некорректного он не 
> занимается.
> 

Я выключаю httpready.
Вот график кол-ва пакетов
http://radikal.ru/fp/5d8a463d336143a483363e2e6199d442



-- 
Vladislav V. Prodan 
System & Network Administrator 
http://support.od.ua 
+380 67 4584408, +380 99 4060508
VVP88-RIPE
 


From nginx-forum at nginx.us  Mon Mar 31 11:50:19 2014
From: nginx-forum at nginx.us (ast-ross)
Date: Mon, 31 Mar 2014 07:50:19 -0400
Subject: =?UTF-8?B?UmU6IGNsaWVudCBtYXggYm9keSBzaXplINCyINC70L7QutC10LnRiNC40L3QtQ==?=
In-Reply-To: <CALUn_U4EzgexW0Y1AmZRh=20aHJYT8imkVgJsXLz4493GcPfKg@mail.gmail.com>
References: <CALUn_U4EzgexW0Y1AmZRh=20aHJYT8imkVgJsXLz4493GcPfKg@mail.gmail.com>
Message-ID: <280a330c41b8b3b59061a7ee829d9e2f.NginxMailingListRussian@forum.nginx.org>

ramm Wrote:
-------------------------------------------------------
> Определить  location ~ \.php { внутри location /manage
> http://nginx.org/ru/docs/http/ngx_http_core_module.html#location
> 
> Д.
> 
> 
> 2014-03-30 19:47 GMT+06:00 ast-ross <nginx-forum at nginx.us>:
> 
> > Никак не могу решить проблему с client_max_body_size
> >
> > В общем суть в том что есть только 1 входной файл index.php (YII
> Framework)
> > вот конфиг:
> >
> > ========================
> > server {
> >     listen 80;
> >     server_name example.com;
> >     client_max_body_size 1m;
> >
> >     set  $home_root "/var/www/mysite";
> >     root $home_root/public;
> >
> >     location /manage {
> >         client_max_body_size 100m;
> >         try_files $uri $uri/ /index.php?$args;
> >     }
> >
> >     location / {
> >         index  index.php index.html;
> >         try_files $uri $uri/ /index.php?$args;
> >     }
> >
> >     location ~ \.php {
> >         fastcgi_split_path_info  ^(.+\.php)(.*)$;
> >         set $fsn /index.php;
> >         if (-f $document_root$fastcgi_script_name) { set $fsn
> > $fastcgi_script_name; }
> >         fastcgi_pass   backend-php;
> >         fastcgi_param  SCRIPT_FILENAME  $document_root$fsn;
> >         fastcgi_param  PATH_INFO        $fastcgi_path_info;
> >         fastcgi_param  PATH_TRANSLATED  $document_root$fsn;
> >         include fastcgi_params;
> >     }
> >
> > }
> > ========================
> >
> > В самом фреймворке роутинг для админки прописывается на подобии
> > /manage/publication/edit/12 /manage/publication/delete/12
> > /manage/publication/12/files и т.д.
> >
> > Так вот для всех URL которые начинаются на manage надо увеличить
> > client_max_body_size что я и попытался сделать в приведенном
> конфиге. Не
> > сработало, видимо потоу что с локейшена /manage запрос все равно
> уходит в
> > локейшен / а там видимо client_max_body_size = 1m
> >
> > Как решить эту задачу?
> >
> > Posted at Nginx Forum:
> > http://forum.nginx.org/read.php?21,248855,248855#msg-248855
> >
> > _______________________________________________
> > 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


Тогда
location / {
...
}
останется без PHP. А он там нужен.

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


From mdounin at mdounin.ru  Mon Mar 31 11:56:25 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 31 Mar 2014 15:56:25 +0400
Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1INGBIGh0dHBy?=
 =?UTF-8?B?ZWFkeSDQuCBkYXRhcmVhZHk=?=
In-Reply-To: <1396266309.502577209.c5f3uf9m@frv35.fwdcdn.com>
References: <1396050046.72682922.828a5r7a@frv35.fwdcdn.com>
 <1447281370.20140329105052@softsearch.ru>
 <1396133631.898325553.ra7gv2ss@frv35.fwdcdn.com>
 <1334785671.20140330115850@softsearch.ru>
 <20140331113510.GD34696@mdounin.ru>
 <1396266309.502577209.c5f3uf9m@frv35.fwdcdn.com>
Message-ID: <20140331115624.GE34696@mdounin.ru>

Hello!

On Mon, Mar 31, 2014 at 02:45:09PM +0300, Vladislav Prodan wrote:

> 
> 
>  
>  --- Исходное сообщение ---
>  От кого: "Maxim Dounin" <mdounin at mdounin.ru>
>  Дата: 31 марта 2014, 14:35:14
>   
> 
> 
> > Hello!
> > 
> > On Sun, Mar 30, 2014 at 11:58:50AM +0400, Михаил Монашёв wrote:
> > 
> > > Здравствуйте, Vladislav.
> > > 
> > > >> > # grep accept_filter nginx.conf
> > > >> > listen xx.xx.xx.57 accept_filter=httpready accept_filter=dataready ;
> > > >> > listen xx.xx.xx.60 accept_filter=httpready accept_filter=dataready ;
> > > >> > listen xx.xx.xx.58 accept_filter=httpready accept_filter=dataready ;
> > > >> > listen xx.xx.xx.56 accept_filter=httpready accept_filter=dataready ;

Отдельно замечу, что такая конфигурация - смысла не имеет, и на 
самом деле включает только dataready.

> > > >> 
> > > >> Если я не ошибаюсь, то нет смысла использовать dataready, если есть
> > > >> httpready. Они про одно и тоже, только второй ещё проверяет, что
> > > >> пришедшие данные похожи на HTTP.
> > > >> 
> > > 
> > > > Тем не менее, сабж очень неприятный - лавинообразный рост мелких пакетов.
> > > > Хотелось бы выяснить, в этом виноват nginx или модули accf_http+accf_data ?
> > > 
> > > Оставьте один фильтр httpready и весь мусор, не похожий на HTTP до
> > > nginx-а не будет доходить.
> > 
> > Нет, фильтр httpready - пропускает всё, что не похоже на 
> > http (если совсем точно - на GET или HEAD-запрос). Его 
> > предназначение - дождаться, пока клиент пришлёт запрос полностью, 
> > тем самым по возможности уменьшив количество соединений в 
> > приложении. Но никаким отсечением чего-либо некорректного он не 
> > занимается.
> > 
> 
> Я выключаю httpready.
> Вот график кол-ва пакетов
> http://radikal.ru/fp/5d8a463d336143a483363e2e6199d442

Имеет смысл пожаловаться куда-нибудь в freebsd-net@, с более 
подробной диагностикой.  Ну или вот Глеб заинтересовался, Cc'd.

To Глеб:

Исходное письмо с фрагментом tcpdump'а тут:
http://mailman.nginx.org/pipermail/nginx-ru/2014-March/053686.html

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


From a.vasilishin at kpi.ua  Mon Mar 31 12:58:31 2014
From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=)
Date: Mon, 31 Mar 2014 15:58:31 +0300
Subject: start time is out mp4 stsc chunks
In-Reply-To: <20140331112940.GC34696@mdounin.ru>
References: <53341757.7030601@kpi.ua> <20140327125919.GX34696@mdounin.ru>
 <20140327130630.GZ34696@mdounin.ru> <53346B8F.6050309@kpi.ua>
 <20140328115704.GJ34696@mdounin.ru> <5335AEED.6000800@kpi.ua>
 <20140328182449.GW34696@mdounin.ru> <5335E68A.1060703@kpi.ua>
 <20140331112940.GC34696@mdounin.ru>
Message-ID: <53396677.8090605@kpi.ua>


>> Но ведь это дорожка субтитров, получается, до 1.3.5 ее просто отбрасывало, а
>> после 1.5.10 не работает псевдостримминг.
>
> Как я уже пытался объяснить выше, судя по всему, одни и те же
> данные этой дорожки - относятся ко всему временному диапазону, и
> эти данные располагаются в начале файла.  Т.к. при псевдостриминге
> nginx отдаёт диапазон медиаданных, от первого байта самых ранних
> данных какой-либо из дорожек и до конца файла, то в такой ситуации
> псевдостриминг становится фактически бесполезен.  Приблизительно
> то же самое будет если, например, аудио и видео дорожки не
> перемешаны между собой, а записаны последовательно.
>

Спасибо!
Вот теперь понятно, может как-то предусмотреть все-таки  какой-то флаг, 
  чтобы можно было сделать поведение как в нгинкс < 1.3.5? Что-то типа 
skpip_h264_aac on;