From nginx-forum на forum.nginx.org  Sun Feb  4 03:48:42 2018
From: nginx-forum на forum.nginx.org (Artem Smorodin)
Date: Sat, 03 Feb 2018 22:48:42 -0500
Subject: =?UTF-8?B?0JrQvtC90YTQu9C40LrRgiBtaXJyb3Ig0LggZGF2INC80L7QtNGD0LvQtdC5?=
Message-ID: <ca497f69a345a5dbdefb56f3f716cfca.NginxMailingListRussian@forum.nginx.org>

Здравствуйте, обнаружил конфликт в работе модулей Dav и Mirror.

 Пример конфигурации, при которой Dav модуль всегда будет возвращать HTTP
500, причем без записи в лог:

location / {
    root   /somedir;
	aio threads;
	
    client_max_body_size 30m;
    dav_access user:rw group:rw all:rw;
    dav_methods PUT;
    create_full_put_path on;
    client_body_temp_path /somedir/temp 1 2;
	mirror /mirror/127.0.0.2:80;
}

location ~* /mirror/(?<backend>.*) {	
	internal;
	client_max_body_size 0;
	proxy_pass http://$backend/$request_uri;
	proxy_ignore_client_abort on;
	proxy_buffering off; 
	proxy_method PUT;
	proxy_request_buffering off;
	proxy_connect_timeout 5s;
}


 Так происходит из-за того, что модуль ngx_http_dav_module, который работает
в фазе NGX_HTTP_CONTENT_PHASE требует, чтобы тело запроса было сохранено во
временный файл

r->request_body_in_file_only = 1;
r->request_body_in_persistent_file = 1;
r->request_body_in_clean_file = 1;
r->request_body_file_group_access = 1;
r->request_body_file_log_level = 0;

rc = ngx_http_read_client_request_body(r, ngx_http_dav_put_handler);

Однако модуль ngx_http_mirror_module, который работает в фазе
NGX_HTTP_PRECONTENT_PHASE так же считывает содержимое тела запроса, но
делает это раньше и с параметрами по умолчанию

Default: client_body_in_file_only off;

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

static void
ngx_http_dav_put_handler(ngx_http_request_t *r)
{

    /****** some code here ******/

    if (r->request_body == NULL || r->request_body->temp_file == NULL) {
        ngx_http_finalize_request(r, NGX_HTTP_INTERNAL_SERVER_ERROR);
        return;
    }


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

client_body_in_file_only clean;


Если я прав, добавьте, пожалуйста, эту информацию в документацию.

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


From exelib на gmail.com  Sun Feb  4 08:51:13 2018
From: exelib на gmail.com (Anton Bessonov)
Date: Sun, 4 Feb 2018 09:51:13 +0100
Subject: =?UTF-8?B?UmU6INCe0YLQsdGA0LDQsdC+0YLQutCwINC60L7QvNCw0L3QtCDQsiDRhNCw0Lk=?=
 =?UTF-8?B?0LvQtSBodGFjY2Vzcw==?=
In-Reply-To: <363771517387998@web34g.yandex.ru>
References: <363771517387998@web34g.yandex.ru>
Message-ID: <5A76C981.8050409@gmail.com>

Зачем столько рекламы? Для агенства очень слабенько, однако.

Для решения проблемы просто установите Apache и .htaccess начнёт 
обрабатываться, если в конфигурации не напортачите.

On 31.01.2018 09:39, kozlow на texterra.ru wrote:
> Вас беспокоит интернет-агенство Texterra, мы оказываем услуги интернет 
> маркетинга для одного из клиентов вашего веб-сервера-https://proivf.ru/.
> В ходе работы у нас возникла проблема с настройкой перенаправлений в 
> файле htaccess, из-за того что клиент является пользователем вашего 
> веб-сервера, то что мы прописываем в htaccess не отрабатывается. В 
> частности нам необходимо настроить редиректы со страницы "без /" на 
> страницы "с /" для элементов разделов.
> Подскажите как нам решить эту проблему?
> -- 
> С уважением,
> Даниил Козлов,
> Project-менеджер
> Phone:  +7 9096761189
> Читайте нашблог <https://texterra.ru/blog/>.
> -------------------------
> Хотите дать обратную связь по качеству нашей работы?
> Обращайтесь к руководителю отдела контроля качества — 
> Елизавете Язиной: phone: +7 909 943 24 81
> yazina на texterra.ru <mailto:mariali на texterra.ru>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


-- 
Certified Prince2:2009 Project Manager
Professional Scrum Expert
Oracle Certified Expert, Enterprise JavaBeans Developer
Oracle Certified Professional, Java SE 6 Programmer

Now that's a test of the character of an organization.
Of the organizations that are attempting to implement
Scrum probably, 30% - 35% will successfully implement it.
- Ken Schwaber

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180204/cb08cc26/attachment.html>

From pixselgts на gmail.com  Sun Feb  4 13:43:49 2018
From: pixselgts на gmail.com (=?UTF-8?B?0JDRgNGC0ZHQvCBWWg==?=)
Date: Sun, 4 Feb 2018 18:43:49 +0500
Subject: help
In-Reply-To: <CANGZ+mUBDbA1FyUtmWd465=gA27KmNpez7RZn14qKjh=fK6FHw@mail.gmail.com>
References: <CANGZ+mVbNW11PZ21Sxjnq8yNMiuPzdGK9E_nqKTcf9PK546Jag@mail.gmail.com>
 <CANGZ+mVFvYVbSewa85yYAQmemBp5rtgz2fUDzMVe+90g8qDWVQ@mail.gmail.com>
 <CANGZ+mUBDbA1FyUtmWd465=gA27KmNpez7RZn14qKjh=fK6FHw@mail.gmail.com>
Message-ID: <CANGZ+mUmuUzZm+_=7x_d-u9_ms=SJg5SXOVXb8GaMdCQ=qYAZg@mail.gmail.com>

Или как можно достичь распределение по менее нагруженным серверам и при
этом с сохранением сессии

26 января 2018 г., 16:33 пользователь Артём VZ <pixselgts на gmail.com>
написал:

> Тобишь вот так правильно. Можно ли применять при балансировке одновременно
> least_conn; и ip_hash; будут ли одновременно работать и как правильно
> прописать ? Вот так если всё пропишу как в примере ниже, то всё будет
> работать или что да как можно\нужно ?
>
> upstream myapp1 {
>     *least_conn;*
> *    ip_hash;*
>     сервер srv1.example.com;
>     сервер srv2.example.com;
>     сервер srv3.example.com;
> }
>
>
>
> 26 января 2018 г., 16:27 пользователь Артём VZ <pixselgts на gmail.com>
> написал:
>
> Очепятка, *minimum_conn;* считать как *least_conn;*
>>
>> 26 января 2018 г., 16:23 пользователь Артём VZ <pixselgts на gmail.com>
>> написал:
>>
>> Всем привет ! Из оф. документации (http://nginx.org/en/docs/http
>>> /load_balancing.html) не всё понял по балансировке. А именно, можно ли
>>> применять при балансировке одновременно minimum_conn; и ip_hash; будут
>>> ли одновременно работать и как правильно прописать ?
>>>
>>> upstream myapp1 {
>>>
>>> *minimum_conn;    ip_hash;*
>>>     сервер srv1.example.com;
>>>     сервер srv2.example.com;
>>>     сервер srv3.example.com;
>>> }
>>>
>>>
>>> Вот так если всё пропишу как в примере выше, то всё будет работать или
>>> что да как можно\нужно ?
>>>
>>> Буду признателен за ответ, спасибо
>>>
>>
>>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180204/b3a76486/attachment.html>

From mdounin на mdounin.ru  Sun Feb  4 18:30:31 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sun, 4 Feb 2018 21:30:31 +0300
Subject: help
In-Reply-To: <CANGZ+mUmuUzZm+_=7x_d-u9_ms=SJg5SXOVXb8GaMdCQ=qYAZg@mail.gmail.com>
References: <CANGZ+mVbNW11PZ21Sxjnq8yNMiuPzdGK9E_nqKTcf9PK546Jag@mail.gmail.com>
 <CANGZ+mVFvYVbSewa85yYAQmemBp5rtgz2fUDzMVe+90g8qDWVQ@mail.gmail.com>
 <CANGZ+mUBDbA1FyUtmWd465=gA27KmNpez7RZn14qKjh=fK6FHw@mail.gmail.com>
 <CANGZ+mUmuUzZm+_=7x_d-u9_ms=SJg5SXOVXb8GaMdCQ=qYAZg@mail.gmail.com>
Message-ID: <20180204183031.GO24410@mdounin.ru>

Hello!

On Sun, Feb 04, 2018 at 06:43:49PM +0500, Артём VZ wrote:

> Или как можно достичь распределение по менее нагруженным серверам и при
> этом с сохранением сессии

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

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Mon Feb  5 09:52:00 2018
From: nginx-forum на forum.nginx.org (iotch)
Date: Mon, 05 Feb 2018 04:52:00 -0500
Subject: =?UTF-8?B?0KHQtdGA0LLQtdGAINC/0L4g0YPQvNC+0LvRh9Cw0L3QuNGOINC00LvRjyBTU0w=?=
Message-ID: <ad74af31a533ac61641253a95376405f.NginxMailingListRussian@forum.nginx.org>

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

Пытаюсь настроить дефолтный сервер для неописанных хостов:

server {
    listen       10.0.0.2:80 default_server;
    listen       10.0.0.2:443 default_server;

    server_name  '';

    location / {
        return 444;
    }
}

Проблема возникает при попытке обращения к неописанному хосту по https - "no
"ssl_certificate" is defined in server listening on SSL port while SSL
handshaking"

Если в эту конфигурацию добавить ssl_certificate и ssl_certificate_key с
путями к любому сертификату и ключу, то все работает как ожидается, но это
выглядит как палеатив - ведь мы не можем получить сертификат на неизвестный
домен. Как быть в этом случае? 

Спасибо!

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


From nginx-forum на forum.nginx.org  Mon Feb  5 10:03:07 2018
From: nginx-forum на forum.nginx.org (iotch)
Date: Mon, 05 Feb 2018 05:03:07 -0500
Subject: =?UTF-8?B?UmU6INCh0LXRgNCy0LXRgCDQv9C+INGD0LzQvtC70YfQsNC90LjRjiDQtNC70Y8g?=
 =?UTF-8?B?U1NM?=
In-Reply-To: <ad74af31a533ac61641253a95376405f.NginxMailingListRussian@forum.nginx.org>
References: <ad74af31a533ac61641253a95376405f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <83738efbc1e93ea6bde04440729d047b.NginxMailingListRussian@forum.nginx.org>

*паллиатив

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278349,278350#msg-278350


From nginx на mva.name  Mon Feb  5 10:09:14 2018
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Mon, 05 Feb 2018 17:09:14 +0700
Subject: =?UTF-8?B?UmU6INCh0LXRgNCy0LXRgCDQv9C+INGD0LzQvtC70YfQsNC90LjRjiDQtNC70Y8g?=
 =?UTF-8?B?U1NM?=
In-Reply-To: <ad74af31a533ac61641253a95376405f.NginxMailingListRussian@forum.nginx.org>
References: <ad74af31a533ac61641253a95376405f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1699695.nO86k9OiDY@note>

1) у вас для ssl'ового listen'а не указано "ssl" в аргументах.

2) вы сами ответили на свой вопрос: вы не можете иметь универсального 
сертификата для всех доменов (чтобы подсунуть его для случая, когда кто-то 
ломится на домен, который не сконфигурирован в server{}-блоках.
Поэтому вы можете использовать там абсолютно любой. Всё равно с большой долей 
вероятности он будет невалиден при попадании запроса в дефолтный vhost.




В письме от понедельник, 5 февраля 2018 г. 16:52:00 +07 пользователь iotch 
написал:
> Здравствуйте.
> 
> Пытаюсь настроить дефолтный сервер для неописанных хостов:
> 
> server {
>     listen       10.0.0.2:80 default_server;
>     listen       10.0.0.2:443 default_server;
> 
>     server_name  '';
> 
>     location / {
>         return 444;
>     }
> }
> 
> Проблема возникает при попытке обращения к неописанному хосту по https - "no
> "ssl_certificate" is defined in server listening on SSL port while SSL
> handshaking"
> 
> Если в эту конфигурацию добавить ssl_certificate и ssl_certificate_key с
> путями к любому сертификату и ключу, то все работает как ожидается, но это
> выглядит как палеатив - ведь мы не можем получить сертификат на неизвестный
> домен. Как быть в этом случае?
> 
> Спасибо!
> 
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,278349,278349#msg-278349
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From nginx-forum на forum.nginx.org  Mon Feb  5 10:22:01 2018
From: nginx-forum на forum.nginx.org (iotch)
Date: Mon, 05 Feb 2018 05:22:01 -0500
Subject: =?UTF-8?B?UmU6INCh0LXRgNCy0LXRgCDQv9C+INGD0LzQvtC70YfQsNC90LjRjiDQtNC70Y8g?=
 =?UTF-8?B?U1NM?=
In-Reply-To: <1699695.nO86k9OiDY@note>
References: <1699695.nO86k9OiDY@note>
Message-ID: <b4254271ead09c7dd770ae38fdecd580.NginxMailingListRussian@forum.nginx.org>

> у вас для ssl'ового listen'а не указано "ssl" в аргументах

Да, спасибо, в данном случае это не играет роли, судя по тестам.

> Поэтому вы можете использовать там абсолютно любой.

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

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278349,278353#msg-278353


From swood на fotofor.biz  Mon Feb  5 10:56:14 2018
From: swood на fotofor.biz (Anton Kiryushkin)
Date: Mon, 5 Feb 2018 10:56:14 +0000
Subject: =?UTF-8?B?UmU6INCh0LXRgNCy0LXRgCDQv9C+INGD0LzQvtC70YfQsNC90LjRjiDQtNC70Y8g?=
 =?UTF-8?B?U1NM?=
In-Reply-To: <b4254271ead09c7dd770ae38fdecd580.NginxMailingListRussian@forum.nginx.org>
References: <1699695.nO86k9OiDY@note>
 <b4254271ead09c7dd770ae38fdecd580.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAM_jxg3Tg4cOFBLT+tJ+o0jUn6Fuaa2pnPBV2pHv=muGJSY91A@mail.gmail.com>

Смотря какую задачу вы решаете.


5 февраля 2018 г., 10:22 пользователь iotch <nginx-forum на forum.nginx.org>
написал:

> > у вас для ssl'ового listen'а не указано "ssl" в аргументах
>
> Да, спасибо, в данном случае это не играет роли, судя по тестам.
>
> > Поэтому вы можете использовать там абсолютно любой.
>
> Так и делаю, но подумал, есть какое-то стандартное решение для таких
> случаев.
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,278349,278353#msg-278353
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
Best regards,
Anton Kiryushkin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180205/363a5dce/attachment.html>

From swood на fotofor.biz  Mon Feb  5 10:56:47 2018
From: swood на fotofor.biz (Anton Kiryushkin)
Date: Mon, 5 Feb 2018 10:56:47 +0000
Subject: =?UTF-8?B?UmU6INCh0LXRgNCy0LXRgCDQv9C+INGD0LzQvtC70YfQsNC90LjRjiDQtNC70Y8g?=
 =?UTF-8?B?U1NM?=
In-Reply-To: <CAM_jxg3Tg4cOFBLT+tJ+o0jUn6Fuaa2pnPBV2pHv=muGJSY91A@mail.gmail.com>
References: <1699695.nO86k9OiDY@note>
 <b4254271ead09c7dd770ae38fdecd580.NginxMailingListRussian@forum.nginx.org>
 <CAM_jxg3Tg4cOFBLT+tJ+o0jUn6Fuaa2pnPBV2pHv=muGJSY91A@mail.gmail.com>
Message-ID: <CAM_jxg3cFTmptt-9de2z+PB5ugdO2jxaFdF_P_A1SOfBAse-Qg@mail.gmail.com>

Вы можете сделать самоподписный сертификат для дефолтного хоста и надеяться
на то, что все ваши клиенты умеют в SNI.

5 февраля 2018 г., 10:56 пользователь Anton Kiryushkin <swood на fotofor.biz>
написал:

> Смотря какую задачу вы решаете.
>
>
> 5 февраля 2018 г., 10:22 пользователь iotch <nginx-forum на forum.nginx.org>
> написал:
>
> > у вас для ssl'ового listen'а не указано "ssl" в аргументах
>>
>> Да, спасибо, в данном случае это не играет роли, судя по тестам.
>>
>> > Поэтому вы можете использовать там абсолютно любой.
>>
>> Так и делаю, но подумал, есть какое-то стандартное решение для таких
>> случаев.
>>
>> Posted at Nginx Forum: https://forum.nginx.org/read.p
>> hp?21,278349,278353#msg-278353
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
>
> --
> Best regards,
> Anton Kiryushkin
>
>


-- 
Best regards,
Anton Kiryushkin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180205/be77f9ff/attachment.html>

From chipitsine на gmail.com  Mon Feb  5 11:02:06 2018
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 5 Feb 2018 16:02:06 +0500
Subject: =?UTF-8?B?UmU6INCh0LXRgNCy0LXRgCDQv9C+INGD0LzQvtC70YfQsNC90LjRjiDQtNC70Y8g?=
 =?UTF-8?B?U1NM?=
In-Reply-To: <1699695.nO86k9OiDY@note>
References: <ad74af31a533ac61641253a95376405f.NginxMailingListRussian@forum.nginx.org>
 <1699695.nO86k9OiDY@note>
Message-ID: <CAFHpkQF34MOdGnkJcVWQMAZQbQo=hkxfxCmcaqM_tANH41uqrg@mail.gmail.com>

если у вас не используется SSL без SNI, и вы хотите в дефолтном сервере
сбрасывать подключения, можно рассмотреть

ssl_ciphers aNULL;

5 февраля 2018 г., 15:09 пользователь Vadim A. Misbakh-Soloviov <
nginx на mva.name> написал:

> 1) у вас для ssl'ового listen'а не указано "ssl" в аргументах.
>
> 2) вы сами ответили на свой вопрос: вы не можете иметь универсального
> сертификата для всех доменов (чтобы подсунуть его для случая, когда кто-то
> ломится на домен, который не сконфигурирован в server{}-блоках.
> Поэтому вы можете использовать там абсолютно любой. Всё равно с большой
> долей
> вероятности он будет невалиден при попадании запроса в дефолтный vhost.
>
>
>
>
> В письме от понедельник, 5 февраля 2018 г. 16:52:00 +07 пользователь iotch
> написал:
> > Здравствуйте.
> >
> > Пытаюсь настроить дефолтный сервер для неописанных хостов:
> >
> > server {
> >     listen       10.0.0.2:80 default_server;
> >     listen       10.0.0.2:443 default_server;
> >
> >     server_name  '';
> >
> >     location / {
> >         return 444;
> >     }
> > }
> >
> > Проблема возникает при попытке обращения к неописанному хосту по https -
> "no
> > "ssl_certificate" is defined in server listening on SSL port while SSL
> > handshaking"
> >
> > Если в эту конфигурацию добавить ssl_certificate и ssl_certificate_key с
> > путями к любому сертификату и ключу, то все работает как ожидается, но
> это
> > выглядит как палеатив - ведь мы не можем получить сертификат на
> неизвестный
> > домен. Как быть в этом случае?
> >
> > Спасибо!
> >
> > Posted at Nginx Forum:
> > https://forum.nginx.org/read.php?21,278349,278349#msg-278349
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru на nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180205/032b9963/attachment.html>

From pixselgts на gmail.com  Mon Feb  5 15:59:01 2018
From: pixselgts на gmail.com (=?UTF-8?B?0JDRgNGC0ZHQvCBWWg==?=)
Date: Mon, 5 Feb 2018 20:59:01 +0500
Subject: help
In-Reply-To: <20180204183031.GO24410@mdounin.ru>
References: <CANGZ+mVbNW11PZ21Sxjnq8yNMiuPzdGK9E_nqKTcf9PK546Jag@mail.gmail.com>
 <CANGZ+mVFvYVbSewa85yYAQmemBp5rtgz2fUDzMVe+90g8qDWVQ@mail.gmail.com>
 <CANGZ+mUBDbA1FyUtmWd465=gA27KmNpez7RZn14qKjh=fK6FHw@mail.gmail.com>
 <CANGZ+mUmuUzZm+_=7x_d-u9_ms=SJg5SXOVXb8GaMdCQ=qYAZg@mail.gmail.com>
 <20180204183031.GO24410@mdounin.ru>
Message-ID: <CANGZ+mUS4KQo9eLcG1uLk8cdjzkqcvx5+W9CaKLnSyiQfVSpSw@mail.gmail.com>

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

4 февраля 2018 г., 23:30 пользователь Maxim Dounin <mdounin на mdounin.ru>
написал:

> Hello!
>
> On Sun, Feb 04, 2018 at 06:43:49PM +0500, Артём VZ wrote:
>
> > Или как можно достичь распределение по менее нагруженным серверам и при
> > этом с сохранением сессии
>
> Попробуйте хранить сессии так, чтобы к ним имели доступ все
> бэкенды.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180205/77abd4d2/attachment.html>

From mdounin на mdounin.ru  Mon Feb  5 16:12:56 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 5 Feb 2018 19:12:56 +0300
Subject: help
In-Reply-To: <CANGZ+mUS4KQo9eLcG1uLk8cdjzkqcvx5+W9CaKLnSyiQfVSpSw@mail.gmail.com>
References: <CANGZ+mVbNW11PZ21Sxjnq8yNMiuPzdGK9E_nqKTcf9PK546Jag@mail.gmail.com>
 <CANGZ+mVFvYVbSewa85yYAQmemBp5rtgz2fUDzMVe+90g8qDWVQ@mail.gmail.com>
 <CANGZ+mUBDbA1FyUtmWd465=gA27KmNpez7RZn14qKjh=fK6FHw@mail.gmail.com>
 <CANGZ+mUmuUzZm+_=7x_d-u9_ms=SJg5SXOVXb8GaMdCQ=qYAZg@mail.gmail.com>
 <20180204183031.GO24410@mdounin.ru>
 <CANGZ+mUS4KQo9eLcG1uLk8cdjzkqcvx5+W9CaKLnSyiQfVSpSw@mail.gmail.com>
Message-ID: <20180205161256.GA24410@mdounin.ru>

Hello!

On Mon, Feb 05, 2018 at 08:59:01PM +0500, Артём VZ wrote:

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

Типичные решения - хранить сессии в базе или memcached.  Впрочем, 
к nginx'у это имеет мало отношения.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Tue Feb  6 12:55:38 2018
From: nginx-forum на forum.nginx.org (darksmoke)
Date: Tue, 06 Feb 2018 07:55:38 -0500
Subject: =?UTF-8?B?0JTQstCwIGxvY2F0aW9uINGB0L4g0YHRgtCw0YLQuNC60L7QuQ==?=
Message-ID: <75626e00e36f20b9faaf4a497e3e1607.NginxMailingListRussian@forum.nginx.org>

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

    location /v3/ {                                                         
                                        
        location ~* \.(xsl|ico|gif|png|svg|js|css|html|ttf|woff|json|xml)$ {
                                        
            index index.html;                                               
                                        
            root /opt/DATA/stat/otp24v3;                                    
                              
            expires -1;                                                     
                                        
        }                                                                   
                                        
    }                                                                       
                                        
                                                                            
                                        
    location / {                                                            
                                        
        location ~* \.(xsl|ico|gif|png|svg|js|css|html|ttf|woff|json|xml)$ {
                                        
            index index.html;                                               
                                        
            access_log off;                                                 
                                        
            root /opt/DATA/stat/otp24;                                      
                              
            expires -1;                                                     
                                        
        }                                                                   
                                        
    }  

дергаю домен/v3/ получаю 404

В логе
018/02/06 14:34:02 [error] 1338189#0: *217105 open() "/opt/nginx/html/v3"
failed (2: No such file or directory), cli
ent: 10.42.1.53, server: domain.ru, request: "GET /v3 HTTP/1.1", host:
"domain.ru"

Файлы статики по путям ессть, корень отрабатывает четко, а вот v3 выдает 404
и не могу побороть  ((

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


From kulmaks на gmail.com  Tue Feb  6 12:59:43 2018
From: kulmaks на gmail.com (Maksim Kulik)
Date: Tue, 6 Feb 2018 15:59:43 +0300
Subject: =?UTF-8?B?UmU6INCU0LLQsCBsb2NhdGlvbiDRgdC+INGB0YLQsNGC0LjQutC+0Lk=?=
In-Reply-To: <75626e00e36f20b9faaf4a497e3e1607.NginxMailingListRussian@forum.nginx.org>
References: <75626e00e36f20b9faaf4a497e3e1607.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CA+zavHkQKp_CKhBg5O=9zz8J9ustSCsf3au4LbHsRoru7ApVYg@mail.gmail.com>

Запрос GET /v3 явно не попадает в ваш локейшен со сменой root. Т.е.
попадает в /v3/, но не во вложенный и root у него не меняется.


    location /v3/ {

        location ~* \.(xsl|ico|gif|png|svg|js|css|html|ttf|woff|json|xml)$ {

            index index.html;

            root /opt/DATA/stat/otp24v3;

            expires -1;

        }

    }

Покажите весь конфиг.

6 февраля 2018 г., 15:55 пользователь darksmoke <nginx-forum на forum.nginx.org
> написал:

> Добрый день
> Помогите пожалуйста настроить nginx. На одном домене, два урла. Надо что бы
> по двум урлам отдавалась разная статика.
>
>     location /v3/ {
>
>         location ~* \.(xsl|ico|gif|png|svg|js|css|html|ttf|woff|json|xml)$
> {
>
>             index index.html;
>
>             root /opt/DATA/stat/otp24v3;
>
>             expires -1;
>
>         }
>
>     }
>
>
>
>     location / {
>
>         location ~* \.(xsl|ico|gif|png|svg|js|css|html|ttf|woff|json|xml)$
> {
>
>             index index.html;
>
>             access_log off;
>
>             root /opt/DATA/stat/otp24;
>
>             expires -1;
>
>         }
>
>     }
>
> дергаю домен/v3/ получаю 404
>
> В логе
> 018/02/06 14:34:02 [error] 1338189#0: *217105 open() "/opt/nginx/html/v3"
> failed (2: No such file or directory), cli
> ent: 10.42.1.53, server: domain.ru, request: "GET /v3 HTTP/1.1", host:
> "domain.ru"
>
> Файлы статики по путям ессть, корень отрабатывает четко, а вот v3 выдает
> 404
> и не могу побороть  ((
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,278376,278376#msg-278376
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180206/cb25d98d/attachment.html>

From nginx-forum на forum.nginx.org  Tue Feb  6 13:42:52 2018
From: nginx-forum на forum.nginx.org (darksmoke)
Date: Tue, 06 Feb 2018 08:42:52 -0500
Subject: =?UTF-8?B?UmU6INCU0LLQsCBsb2NhdGlvbiDRgdC+INGB0YLQsNGC0LjQutC+0Lk=?=
In-Reply-To: <CA+zavHkQKp_CKhBg5O=9zz8J9ustSCsf3au4LbHsRoru7ApVYg@mail.gmail.com>
References: <CA+zavHkQKp_CKhBg5O=9zz8J9ustSCsf3au4LbHsRoru7ApVYg@mail.gmail.com>
Message-ID: <28290935d85ef2f88226ef7fcca63324.NginxMailingListRussian@forum.nginx.org>

server {                                                                    
                                        
    server_name domain.ru;                                                  
                         
    listen 443 ssl;                                                         
                                        
                                                                            
                                        
    ssl_certificate       certs/domain.ru/fullchain3.pem;                   
                         
    ssl_certificate_key   certs/domain.ru/privkey3.pem;                     
                         
                                                                            
                                        
                                                                            
                                        
    location /v3/ {                                                         
                                        
        location ~* \.(xsl|ico|gif|png|svg|js|css|html|ttf|woff|json|xml)$ {
                                        
            index index.html;                                               
                                        
            root /opt/DATA/stat/otp24v3;                                    
                              
            expires -1;                                                     
                                        
        }                                                                   
                                        
    }                                                                       
                                        
                                                                            
                                        
    location / {                                                            
                                        
        location ~* \.(xsl|ico|gif|png|svg|js|css|html|ttf|woff|json|xml)$ {
                                        
            index index.html;                                               
                                        
            access_log off;                                                 
                                        
            root /opt/DATA/stat/otp24;                                      
                              
            expires -1;                                                     
                                        
        }                                                                   
                                        
    }                                                                       
                                        
                                                                            
                                        
                                                                            
                                        
                                                                            
                                        
    location /api/ {                                                        
                                        
        proxy_pass http://10.56.2.225:8080/otp/api/;                        
                                        
        proxy_set_header Host $host;                                        
                                        
        proxy_set_header X-Real-IP $remote_addr;                            
                                        
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;        
                                        
                                                                            
                                        
        access_log  /opt/nginx/logs/now/domain.ru.access.log up_log;        
                                       
        error_log   /opt/nginx/logs/domain.ru.error.log;                    
                                       
                                                                            
                                        
    }                                                                       
                                        
                                                                            
                                        
}

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278376,278379#msg-278379


From vbart на nginx.com  Tue Feb  6 13:54:10 2018
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Tue, 06 Feb 2018 16:54:10 +0300
Subject: =?UTF-8?B?UmU6INCU0LLQsCBsb2NhdGlvbiDRgdC+INGB0YLQsNGC0LjQutC+0Lk=?=
In-Reply-To: <75626e00e36f20b9faaf4a497e3e1607.NginxMailingListRussian@forum.nginx.org>
References: <75626e00e36f20b9faaf4a497e3e1607.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1793399.xQ5fykpqo8@vbart-workstation>

On Tuesday 06 February 2018 07:55:38 darksmoke wrote:
> Добрый день
> Помогите пожалуйста настроить nginx. На одном домене, два урла. Надо что бы
> по двум урлам отдавалась разная статика.
> 
>     location /v3/ {                                                         
>                                         
>         location ~* \.(xsl|ico|gif|png|svg|js|css|html|ttf|woff|json|xml)$ {
>                                         
>             index index.html;                                               
>                                         
>             root /opt/DATA/stat/otp24v3;                                    
>                               
>             expires -1;                                                     
>                                         
>         }                                                                   
>                                         
>     }                                                                       
>                                         
>                                                                             
>                                         
>     location / {                                                            
>                                         
>         location ~* \.(xsl|ico|gif|png|svg|js|css|html|ttf|woff|json|xml)$ {
>                                         
>             index index.html;                                               
>                                         
>             access_log off;                                                 
>                                         
>             root /opt/DATA/stat/otp24;                                      
>                               
>             expires -1;                                                     
>                                         
>         }                                                                   
>                                         
>     }  
> 
> дергаю домен/v3/ получаю 404
> 
> В логе
> 018/02/06 14:34:02 [error] 1338189#0: *217105 open() "/opt/nginx/html/v3"
> failed (2: No such file or directory), cli
> ent: 10.42.1.53, server: domain.ru, request: "GET /v3 HTTP/1.1", host:
> "domain.ru"
> 
> Файлы статики по путям ессть, корень отрабатывает четко, а вот v3 выдает 404
> и не могу побороть  ((
> 

Очевидно, что запрос "/v3" не попадает в location /v3/, а тем более в location
с регулярным выражением внутри него.

Если вы хотите чтобы попадал запрос без слеша, то нужно убрать слеш и из location.
А чтобы всё это работало, ещё и root в нём указать правильно.

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

From nginx-forum на forum.nginx.org  Tue Feb  6 14:08:21 2018
From: nginx-forum на forum.nginx.org (darksmoke)
Date: Tue, 06 Feb 2018 09:08:21 -0500
Subject: =?UTF-8?B?UmU6INCU0LLQsCBsb2NhdGlvbiDRgdC+INGB0YLQsNGC0LjQutC+0Lk=?=
In-Reply-To: <1793399.xQ5fykpqo8@vbart-workstation>
References: <1793399.xQ5fykpqo8@vbart-workstation>
Message-ID: <8fa04094e3e6a83cadef250785375c6f.NginxMailingListRussian@forum.nginx.org>

root правильный проверил сто раз
Я пробовал и со слэшом в конце и без все равно 404

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278376,278381#msg-278381


From vbart на nginx.com  Tue Feb  6 14:11:50 2018
From: vbart на nginx.com (Valentin V. Bartenev)
Date: Tue, 06 Feb 2018 17:11:50 +0300
Subject: =?UTF-8?B?UmU6INCU0LLQsCBsb2NhdGlvbiDRgdC+INGB0YLQsNGC0LjQutC+0Lk=?=
In-Reply-To: <8fa04094e3e6a83cadef250785375c6f.NginxMailingListRussian@forum.nginx.org>
References: <1793399.xQ5fykpqo8@vbart-workstation>
 <8fa04094e3e6a83cadef250785375c6f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1582920.gYMp0uLVtr@vbart-workstation>

On Tuesday 06 February 2018 09:08:21 darksmoke wrote:
> root правильный проверил сто раз
> Я пробовал и со слэшом в конце и без все равно 404
> 

У вас root в location /v3/ вообще не указан и наследуется скорее всего
из блока http {}.

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

From mdounin на mdounin.ru  Tue Feb  6 14:13:09 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 6 Feb 2018 17:13:09 +0300
Subject: =?UTF-8?B?UmU6INCU0LLQsCBsb2NhdGlvbiDRgdC+INGB0YLQsNGC0LjQutC+0Lk=?=
In-Reply-To: <1793399.xQ5fykpqo8@vbart-workstation>
References: <75626e00e36f20b9faaf4a497e3e1607.NginxMailingListRussian@forum.nginx.org>
 <1793399.xQ5fykpqo8@vbart-workstation>
Message-ID: <20180206141308.GG24410@mdounin.ru>

Hello!

On Tue, Feb 06, 2018 at 04:54:10PM +0300, Валентин Бартенев wrote:

> On Tuesday 06 February 2018 07:55:38 darksmoke wrote:
> > Добрый день
> > Помогите пожалуйста настроить nginx. На одном домене, два урла. Надо что бы
> > по двум урлам отдавалась разная статика.
> > 
> >     location /v3/ {                                                         
> >                                         
> >         location ~* \.(xsl|ico|gif|png|svg|js|css|html|ttf|woff|json|xml)$ {
> >                                         
> >             index index.html;                                               
> >                                         
> >             root /opt/DATA/stat/otp24v3;                                    
> >                               
> >             expires -1;                                                     
> >                                         
> >         }                                                                   
> >                                         
> >     }                                                                       
> >                                         
> >                                                                             
> >                                         
> >     location / {                                                            
> >                                         
> >         location ~* \.(xsl|ico|gif|png|svg|js|css|html|ttf|woff|json|xml)$ {
> >                                         
> >             index index.html;                                               
> >                                         
> >             access_log off;                                                 
> >                                         
> >             root /opt/DATA/stat/otp24;                                      
> >                               
> >             expires -1;                                                     
> >                                         
> >         }                                                                   
> >                                         
> >     }  
> > 
> > дергаю домен/v3/ получаю 404
> > 
> > В логе
> > 018/02/06 14:34:02 [error] 1338189#0: *217105 open() "/opt/nginx/html/v3"
> > failed (2: No such file or directory), cli
> > ent: 10.42.1.53, server: domain.ru, request: "GET /v3 HTTP/1.1", host:
> > "domain.ru"
> > 
> > Файлы статики по путям ессть, корень отрабатывает четко, а вот v3 выдает 404
> > и не могу побороть  ((
> > 
> 
> Очевидно, что запрос "/v3" не попадает в location /v3/, а тем более в location
> с регулярным выражением внутри него.
> 
> Если вы хотите чтобы попадал запрос без слеша, то нужно убрать слеш и из location.
> А чтобы всё это работало, ещё и root в нём указать правильно.

Стоит при этом иметь в виду, что под "location /v3" (без слэша) 
подпадают не только запросы к "/v3", "/v3/", и "/v3/some/file" но 
и "/v3-and-some-other-chars".  Так как location'ы работают по 
строковому префиксу.

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

    location = /v3 {
        return 302 /v3/;
    }

    location /v3/ {
        ...
    }

В большинстве случаев - такой отдельный "location = /v3" 
оказывается не нужен, так как:

- перенаправление с /v3 на /v3/ автоматчески возвращается, если на 
  диске есть соответствующий каталог;

- такое же перенаправление автоматически возвращается, если в 
  "location /v3/" написан proxy_pass / fastcgi_pass и т.п.

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

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

-- 
Maxim Dounin
http://mdounin.ru/

From arut на nginx.com  Wed Feb  7 15:18:56 2018
From: arut на nginx.com (Roman Arutyunyan)
Date: Wed, 7 Feb 2018 18:18:56 +0300
Subject: =?UTF-8?B?UmU6INCa0L7QvdGE0LvQuNC60YIgbWlycm9yINC4IGRhdiDQvNC+0LTRg9C70LU=?=
 =?UTF-8?B?0Lk=?=
In-Reply-To: <ca497f69a345a5dbdefb56f3f716cfca.NginxMailingListRussian@forum.nginx.org>
References: <ca497f69a345a5dbdefb56f3f716cfca.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180207151856.GA81821@Romans-MacBook-Air.local>

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

On Sat, Feb 03, 2018 at 10:48:42PM -0500, Artem Smorodin wrote:
> Здравствуйте, обнаружил конфликт в работе модулей Dav и Mirror.
> 
>  Пример конфигурации, при которой Dav модуль всегда будет возвращать HTTP
> 500, причем без записи в лог:
> 
> location / {
>     root   /somedir;
> 	aio threads;
> 	
>     client_max_body_size 30m;
>     dav_access user:rw group:rw all:rw;
>     dav_methods PUT;
>     create_full_put_path on;
>     client_body_temp_path /somedir/temp 1 2;
> 	mirror /mirror/127.0.0.2:80;
> }
> 
> location ~* /mirror/(?<backend>.*) {	
> 	internal;
> 	client_max_body_size 0;
> 	proxy_pass http://$backend/$request_uri;
> 	proxy_ignore_client_abort on;
> 	proxy_buffering off; 
> 	proxy_method PUT;
> 	proxy_request_buffering off;
> 	proxy_connect_timeout 5s;
> }
> 
> 
>  Так происходит из-за того, что модуль ngx_http_dav_module, который работает
> в фазе NGX_HTTP_CONTENT_PHASE требует, чтобы тело запроса было сохранено во
> временный файл
> 
> r->request_body_in_file_only = 1;
> r->request_body_in_persistent_file = 1;
> r->request_body_in_clean_file = 1;
> r->request_body_file_group_access = 1;
> r->request_body_file_log_level = 0;
> 
> rc = ngx_http_read_client_request_body(r, ngx_http_dav_put_handler);
> 
> Однако модуль ngx_http_mirror_module, который работает в фазе
> NGX_HTTP_PRECONTENT_PHASE так же считывает содержимое тела запроса, но
> делает это раньше и с параметрами по умолчанию
> 
> Default: client_body_in_file_only off;
> 
> В итоге мы пытаемся повторно считать тело запроса, но метод
> ngx_http_read_client_request_body возвращает уже считанную информацию и
> проверка в методе ngx_http_dav_put_handler  не проходит.
> 
> static void
> ngx_http_dav_put_handler(ngx_http_request_t *r)
> {
> 
>     /****** some code here ******/
> 
>     if (r->request_body == NULL || r->request_body->temp_file == NULL) {
>         ngx_http_finalize_request(r, NGX_HTTP_INTERNAL_SERVER_ERROR);
>         return;
>     }

В этом месте явно недоставало логгирования.  Теперь оно есть:

http://hg.nginx.org/nginx/rev/573f20116163

>  По идее, чтобы сохранить независимость модулей нужно реализовывать сброс
> считанного буфера в файл, но лично я решил проблему просто добавив
> директиву
> 
> client_body_in_file_only clean;

Да, решение выглядит правильным.

> Если я прав, добавьте, пожалуйста, эту информацию в документацию.

Да, стоит добавить.  Спасибо.

-- 
Roman Arutyunyan

From coddoc на mail.ru  Fri Feb  9 09:38:32 2018
From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=)
Date: Fri, 09 Feb 2018 12:38:32 +0300
Subject: =?UTF-8?B?0JLQvtC/0YDQvtGBINC/0L4gYWNjZXNzX2xvZw==?=
Message-ID: <1518169112.69790414@f368.i.mail.ru>

Доброе время суток!
nginx/1.13.8

Случайно обнаружилась непонятка.

Конфиг 1:
http {
        ....
        log_format f1 '[$time_local - 1]';
        log_format f2 '[$time_local - 2]';

        access_log /var/log/nginx/1.log f1;
        access_log /var/log/nginx/2.log f2;

        server {
            listen ...
            root ....
            index .....
#            access_log /var/log/nginx/1.log f1;
#            access_log /var/log/nginx/2.log f2;
        }
}

Делаем запрос и получаем ожидаемое: запись в ОБА файла.
-------------------------------------------------------------------------------------------
Теперь так.
Конфиг 2:
http {
        ....
        log_format f1 '[$time_local - 1]';
        log_format f2 '[$time_local - 2]';

        access_log /var/log/nginx/1.log f1;
#        access_log /var/log/nginx/2.log f2;

        server {
            listen ...
            root ....
            index .....
#            access_log /var/log/nginx/1.log f1;
            access_log /var/log/nginx/2.log f2;
        }
}

И запись ТОЛЬКО во второй файл.
-------------------------------------------------------------------------------------------
Конфиг 3:
http {
        ....
        log_format f1 '[$time_local - 1]';
        log_format f2 '[$time_local - 2]';

#        access_log /var/log/nginx/1.log f1;
#        access_log /var/log/nginx/2.log f2;

        server {
            listen ...
            root ....
            index .....
            access_log /var/log/nginx/1.log f1;
            access_log /var/log/nginx/2.log f2;
        }
}

Опять все ожидаемо, запись в оба файла.
-------------------------------------------------------------------------------------------
В server / location похожая ситуация:
server {
    listen ...
    root ...
    index ...
    ....
    access_log /var/log/nginx/1.log f1;
    ........

    # Все, что не совпало с разрешенными
    location "" {
        return 404;
    }

    error_page 404 = @err404;

    location @err404 {
        keepalive_timeout 0;
        rewrite ^ /err/404.html break;
        access_log /var/log/nginx/2.log f2;
    }
}

Ожидаемо: бредовый запрос должен отметиться и в 1.log, и в 2.log
По факту: если работает "access_log /var/log/nginx/2.log f2;", соответственно, не работает "access_log /var/log/nginx/1.log f1;"
Правильный запрос приходит в 1.log, бредовый - в 2.log

Если "access_log /var/log/nginx/2.log f2;" отключить, тогда в 1.log приходят все запросы, и правильные, и бредовые.

access_log в нижестоящем контексте отменяет все вышестоящие?
--
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180209/7d5edf3a/attachment.html>

From mdounin на mdounin.ru  Fri Feb  9 13:01:09 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 9 Feb 2018 16:01:09 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IGFjY2Vzc19sb2c=?=
In-Reply-To: <1518169112.69790414@f368.i.mail.ru>
References: <1518169112.69790414@f368.i.mail.ru>
Message-ID: <20180209130109.GQ24410@mdounin.ru>

Hello!

On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:

[...]

> access_log в нижестоящем контексте отменяет все вышестоящие?

Как и все остальные директивы, access_log наследуется с 
предыдущих уровней тогда и только тогда, когда на данном уровне не 
указано директив access_log.

-- 
Maxim Dounin
http://mdounin.ru/

From slw на zxy.spb.ru  Fri Feb  9 13:11:16 2018
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Fri, 9 Feb 2018 16:11:16 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IGFjY2Vzc19sb2c=?=
In-Reply-To: <20180209130109.GQ24410@mdounin.ru>
References: <1518169112.69790414@f368.i.mail.ru>
 <20180209130109.GQ24410@mdounin.ru>
Message-ID: <20180209131116.GA81872@zxy.spb.ru>

On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
> 
> [...]
> 
> > access_log в нижестоящем контексте отменяет все вышестоящие?
> 
> Как и все остальные директивы, access_log наследуется с 
> предыдущих уровней тогда и только тогда, когда на данном уровне не 
> указано директив access_log.

и при этом, кажется, нет возможности просто включать/выключать acceess
log, не трогая его настройки?

From ru на nginx.com  Fri Feb  9 13:26:42 2018
From: ru на nginx.com (Ruslan Ermilov)
Date: Fri, 9 Feb 2018 16:26:42 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IGFjY2Vzc19sb2c=?=
In-Reply-To: <20180209131116.GA81872@zxy.spb.ru>
References: <1518169112.69790414@f368.i.mail.ru>
 <20180209130109.GQ24410@mdounin.ru>
 <20180209131116.GA81872@zxy.spb.ru>
Message-ID: <20180209132642.GD65829@lo0.su>

On Fri, Feb 09, 2018 at 04:11:16PM +0300, Slawa Olhovchenkov wrote:
> On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
> > 
> > [...]
> > 
> > > access_log в нижестоящем контексте отменяет все вышестоящие?
> > 
> > Как и все остальные директивы, access_log наследуется с 
> > предыдущих уровней тогда и только тогда, когда на данном уровне не 
> > указано директив access_log.
> 
> и при этом, кажется, нет возможности просто включать/выключать acceess
> log, не трогая его настройки?

Запись в лог может быть условной при помощи параметра "if=".

Кроме того, можно на внешнем уровне (напр., server) задать access_log'и,
а на вложенном уровне (напр., location) указать "access_log off;".
Тогда на данном вложенном уровне access_log'и будут отключены, а
на других вложенных уровнях (где не указаны свои access_log'и) будут
действовать настройки как на внешнем уровне.

Я, впрочем, не уверен, что понял Ваш витиеватый вопрос правильно.

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

From slw на zxy.spb.ru  Fri Feb  9 13:35:05 2018
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Fri, 9 Feb 2018 16:35:05 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IGFjY2Vzc19sb2c=?=
In-Reply-To: <20180209132642.GD65829@lo0.su>
References: <1518169112.69790414@f368.i.mail.ru>
 <20180209130109.GQ24410@mdounin.ru>
 <20180209131116.GA81872@zxy.spb.ru> <20180209132642.GD65829@lo0.su>
Message-ID: <20180209133505.GB81872@zxy.spb.ru>

On Fri, Feb 09, 2018 at 04:26:42PM +0300, Ruslan Ermilov wrote:

> On Fri, Feb 09, 2018 at 04:11:16PM +0300, Slawa Olhovchenkov wrote:
> > On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
> > > 
> > > [...]
> > > 
> > > > access_log в нижестоящем контексте отменяет все вышестоящие?
> > > 
> > > Как и все остальные директивы, access_log наследуется с 
> > > предыдущих уровней тогда и только тогда, когда на данном уровне не 
> > > указано директив access_log.
> > 
> > и при этом, кажется, нет возможности просто включать/выключать acceess
> > log, не трогая его настройки?
> 
> Запись в лог может быть условной при помощи параметра "if=".
> 
> Кроме того, можно на внешнем уровне (напр., server) задать access_log'и,
> а на вложенном уровне (напр., location) указать "access_log off;".
> Тогда на данном вложенном уровне access_log'и будут отключены, а
> на других вложенных уровнях (где не указаны свои access_log'и) будут
> действовать настройки как на внешнем уровне.
> 
> Я, впрочем, не уверен, что понял Ваш витиеватый вопрос правильно.

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

ну вот я не вижу возможности так поступить, не повторяя в каждом
location директивы access_log со всеми этими параметрами.

From coddoc на mail.ru  Fri Feb  9 14:13:50 2018
From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=)
Date: Fri, 09 Feb 2018 17:13:50 +0300
Subject: =?UTF-8?B?UmVbMl06INCS0L7Qv9GA0L7RgSDQv9C+IGFjY2Vzc19sb2c=?=
In-Reply-To: <20180209130109.GQ24410@mdounin.ru>
References: <1518169112.69790414@f368.i.mail.ru>
 <20180209130109.GQ24410@mdounin.ru>
Message-ID: <1518185630.911107578@f107.i.mail.ru>

Да, спасибо, уже разобрался "методом научного тыка".
ИМХО, неплохо было бы это в доках указать


>Пятница,  9 февраля 2018, 16:01 +03:00 от Maxim Dounin <mdounin на mdounin.ru>:
>
>Hello!
>
>On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
>
>[...]
>
>> access_log в нижестоящем контексте отменяет все вышестоящие?
>
>Как и все остальные директивы, access_log наследуется с 
>предыдущих уровней тогда и только тогда, когда на данном уровне не 
>указано директив access_log.
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>_______________________________________________
>nginx-ru mailing list
>nginx-ru на nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


--
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180209/5eb2d812/attachment.html>

From coddoc на mail.ru  Fri Feb  9 14:16:09 2018
From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=)
Date: Fri, 09 Feb 2018 17:16:09 +0300
Subject: =?UTF-8?B?UmVbMl06INCS0L7Qv9GA0L7RgSDQv9C+IGFjY2Vzc19sb2c=?=
In-Reply-To: <20180209132642.GD65829@lo0.su>
References: <1518169112.69790414@f368.i.mail.ru>
 <20180209131116.GA81872@zxy.spb.ru> <20180209132642.GD65829@lo0.su>
Message-ID: <1518185769.125019433@f107.i.mail.ru>

Насчет уровня location не проверял, но точно проверено, что 'access_log off' в уровне server глушит все access_log уровня http
Думаю, с location будет то же самое


>Пятница,  9 февраля 2018, 16:26 +03:00 от Ruslan Ermilov <ru на nginx.com>:
>
>On Fri, Feb 09, 2018 at 04:11:16PM +0300, Slawa Olhovchenkov wrote:
>> On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote:
>> 
>> > Hello!
>> > 
>> > On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
>> > 
>> > [...]
>> > 
>> > > access_log в нижестоящем контексте отменяет все вышестоящие?
>> > 
>> > Как и все остальные директивы, access_log наследуется с 
>> > предыдущих уровней тогда и только тогда, когда на данном уровне не 
>> > указано директив access_log.
>> 
>> и при этом, кажется, нет возможности просто включать/выключать acceess
>> log, не трогая его настройки?
>
>Запись в лог может быть условной при помощи параметра "if=".
>
>Кроме того, можно на внешнем уровне (напр., server) задать access_log'и,
>а на вложенном уровне (напр., location) указать "access_log off;".
>Тогда на данном вложенном уровне access_log'и будут отключены, а
>на других вложенных уровнях (где не указаны свои access_log'и) будут
>действовать настройки как на внешнем уровне.
>
>Я, впрочем, не уверен, что понял Ваш витиеватый вопрос правильно.
>
>http://nginx.org/r/access_log/ru
>_______________________________________________
>nginx-ru mailing list
>nginx-ru на nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


--
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180209/19c14314/attachment.html>

From alex на vorona.com.ua  Fri Feb  9 14:32:35 2018
From: alex на vorona.com.ua (Alex Vorona)
Date: Fri, 9 Feb 2018 16:32:35 +0200
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IGFjY2Vzc19sb2c=?=
In-Reply-To: <20180209133505.GB81872@zxy.spb.ru>
References: <1518169112.69790414@f368.i.mail.ru>
 <20180209130109.GQ24410@mdounin.ru> <20180209131116.GA81872@zxy.spb.ru>
 <20180209132642.GD65829@lo0.su> <20180209133505.GB81872@zxy.spb.ru>
Message-ID: <688c17cc-b5ec-ba34-309c-4b4d0bcf2762@vorona.com.ua>

Привет,

09.02.18 15:35, Slawa Olhovchenkov wrote:
[...]

> ну хочется указать accesslog. с кучей параметров (ну там путь,
> буферезиция и все такое). а потом по дефолту его запретить. и
> разрешать только для отдельный location.
> 
> ну вот я не вижу возможности так поступить, не повторяя в каждом
> location директивы access_log со всеми этими параметрами.
Использую для похожих задач include.

--
Alex Vorona

From slw на zxy.spb.ru  Fri Feb  9 14:37:49 2018
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Fri, 9 Feb 2018 17:37:49 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IGFjY2Vzc19sb2c=?=
In-Reply-To: <688c17cc-b5ec-ba34-309c-4b4d0bcf2762@vorona.com.ua>
References: <1518169112.69790414@f368.i.mail.ru>
 <20180209130109.GQ24410@mdounin.ru>
 <20180209131116.GA81872@zxy.spb.ru> <20180209132642.GD65829@lo0.su>
 <20180209133505.GB81872@zxy.spb.ru>
 <688c17cc-b5ec-ba34-309c-4b4d0bcf2762@vorona.com.ua>
Message-ID: <20180209143749.GC81872@zxy.spb.ru>

On Fri, Feb 09, 2018 at 04:32:35PM +0200, Alex Vorona wrote:

> Привет,
> 
> 09.02.18 15:35, Slawa Olhovchenkov wrote:
> [...]
> 
> > ну хочется указать accesslog. с кучей параметров (ну там путь,
> > буферезиция и все такое). а потом по дефолту его запретить. и
> > разрешать только для отдельный location.
> > 
> > ну вот я не вижу возможности так поступить, не повторяя в каждом
> > location директивы access_log со всеми этими параметрами.
> Использую для похожих задач include.

я прямо испытываю оргазм от одной мысли так делать.
нарезать все по одной строке и инклюды-инклюды-инклюды!
а уж какой кайф это редактировать или пытаться понять как конфиг
выглядит.

From annulen на yandex.ru  Fri Feb  9 14:43:56 2018
From: annulen на yandex.ru (Konstantin Tokarev)
Date: Fri, 09 Feb 2018 17:43:56 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IGFjY2Vzc19sb2c=?=
In-Reply-To: <688c17cc-b5ec-ba34-309c-4b4d0bcf2762@vorona.com.ua>
References: <1518169112.69790414@f368.i.mail.ru>
 <20180209130109.GQ24410@mdounin.ru> <20180209131116.GA81872@zxy.spb.ru>
 <20180209132642.GD65829@lo0.su> <20180209133505.GB81872@zxy.spb.ru>
 <688c17cc-b5ec-ba34-309c-4b4d0bcf2762@vorona.com.ua>
Message-ID: <321261518187436@web48o.yandex.ru>



09.02.2018, 17:33, "Alex Vorona" <alex на vorona.com.ua>:
> Привет,
>
> 09.02.18 15:35, Slawa Olhovchenkov wrote:
> [...]
>
>>  ну хочется указать accesslog. с кучей параметров (ну там путь,
>>  буферезиция и все такое). а потом по дефолту его запретить. и
>>  разрешать только для отдельный location.
>>
>>  ну вот я не вижу возможности так поступить, не повторяя в каждом
>>  location директивы access_log со всеми этими параметрами.
>
> Использую для похожих задач include.

Есть предложение к разработчикам.

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

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

-- 
Regards,
Konstantin


From vbart на nginx.com  Fri Feb  9 18:59:16 2018
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 09 Feb 2018 21:59:16 +0300
Subject: =?UTF-8?B?0KDQtdC70LjQtyBVbml0IDAuNiBiZXRh?=
Message-ID: <8437854.oVyo0UdQ4t@vbart-workstation>

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

Рад сообщить о выпуске новой бета версии NGINX Unit с расширенными возможностями
управления процессами и поддержкой Perl/PSGI.  Благодаря Perl модулю Unit теперь
позволяет, в частности, запускать Bugzilla.

Изменения в Unit 0.5                                              08.02.2017

    *) Изменение: опция приложений "workers" была удалена; вместо неё должна
       использоваться опция "processes".

    *) Добавление: опция "processes" позволяющая настраивать предварительный
       запуск процессов приложений и их динамическое масштабирование.

    *) Добавление: модуль Perl.

    *) Исправление: в чтении тела клиентского запроса; ошибка появилась в 0.3.

    *) Исправление: некоторые приложения на Python могли не работать из-за
       отсутствия в environ объекта "wsgi.errors".

    *) Исправление: HTTP chunked transfer encoding на 32-битных системах
       кодировался неправильно.

    *) Исправление: зацикливание при парсинге HTTP.

    *) Исправление: segmentation fault в роутере.


Изменения в Unit 0.6                                              09.02.2017

    *) Исправление: основной процесс погибал, когда в опции приложения "type"
       содержалась версия; ошибка появилась в 0.5.


Анонс версии 0.5 так и не состоялся из-за серьезной регрессии, которая была
замечена сразу после сборки и публикации пакетов.

Помимо бинарных пакетов для CentOS, RHEL, Debian, Ubuntu и Amazon Linux,
теперь выпускаются и официальные Docker-образа.  Подробности по ссылкам
ниже:

 - Пакеты:  https://unit.nginx.org/installation/#precompiled-packages
 - Docker:  https://hub.docker.com/r/nginx/unit/tags/

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

From ru на nginx.com  Fri Feb  9 19:27:22 2018
From: ru на nginx.com (Ruslan Ermilov)
Date: Fri, 9 Feb 2018 22:27:22 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IGFjY2Vzc19sb2c=?=
In-Reply-To: <20180209133505.GB81872@zxy.spb.ru>
References: <1518169112.69790414@f368.i.mail.ru>
 <20180209130109.GQ24410@mdounin.ru>
 <20180209131116.GA81872@zxy.spb.ru> <20180209132642.GD65829@lo0.su>
 <20180209133505.GB81872@zxy.spb.ru>
Message-ID: <20180209192722.GA73219@lo0.su>

On Fri, Feb 09, 2018 at 04:35:05PM +0300, Slawa Olhovchenkov wrote:
> On Fri, Feb 09, 2018 at 04:26:42PM +0300, Ruslan Ermilov wrote:
> 
> > On Fri, Feb 09, 2018 at 04:11:16PM +0300, Slawa Olhovchenkov wrote:
> > > On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote:
> > > 
> > > > Hello!
> > > > 
> > > > On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > access_log в нижестоящем контексте отменяет все вышестоящие?
> > > > 
> > > > Как и все остальные директивы, access_log наследуется с 
> > > > предыдущих уровней тогда и только тогда, когда на данном уровне не 
> > > > указано директив access_log.
> > > 
> > > и при этом, кажется, нет возможности просто включать/выключать acceess
> > > log, не трогая его настройки?
> > 
> > Запись в лог может быть условной при помощи параметра "if=".
> > 
> > Кроме того, можно на внешнем уровне (напр., server) задать access_log'и,
> > а на вложенном уровне (напр., location) указать "access_log off;".
> > Тогда на данном вложенном уровне access_log'и будут отключены, а
> > на других вложенных уровнях (где не указаны свои access_log'и) будут
> > действовать настройки как на внешнем уровне.
> > 
> > Я, впрочем, не уверен, что понял Ваш витиеватый вопрос правильно.
> 
> ну хочется указать accesslog. с кучей параметров (ну там путь,
> буферезиция и все такое). а потом по дефолту его запретить. и
> разрешать только для отдельный location.
> 
> ну вот я не вижу возможности так поступить, не повторяя в каждом
> location директивы access_log со всеми этими параметрами.

Мне кажется, я уже ответил на Ваш вопрос ранее.

access_log <много_параметров> if="$log";

location /1 {
    set $log 1;
    <тут он будет работать>
}

location /2 {
    <а тут - нет>
}

From ru на nginx.com  Fri Feb  9 19:30:23 2018
From: ru на nginx.com (Ruslan Ermilov)
Date: Fri, 9 Feb 2018 22:30:23 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IGFjY2Vzc19sb2c=?=
In-Reply-To: <20180209143749.GC81872@zxy.spb.ru>
References: <1518169112.69790414@f368.i.mail.ru>
 <20180209130109.GQ24410@mdounin.ru>
 <20180209131116.GA81872@zxy.spb.ru> <20180209132642.GD65829@lo0.su>
 <20180209133505.GB81872@zxy.spb.ru>
 <688c17cc-b5ec-ba34-309c-4b4d0bcf2762@vorona.com.ua>
 <20180209143749.GC81872@zxy.spb.ru>
Message-ID: <20180209193023.GB73219@lo0.su>

On Fri, Feb 09, 2018 at 05:37:49PM +0300, Slawa Olhovchenkov wrote:
> On Fri, Feb 09, 2018 at 04:32:35PM +0200, Alex Vorona wrote:
> 
> > Привет,
> > 
> > 09.02.18 15:35, Slawa Olhovchenkov wrote:
> > [...]
> > 
> > > ну хочется указать accesslog. с кучей параметров (ну там путь,
> > > буферезиция и все такое). а потом по дефолту его запретить. и
> > > разрешать только для отдельный location.
> > > 
> > > ну вот я не вижу возможности так поступить, не повторяя в каждом
> > > location директивы access_log со всеми этими параметрами.
> > Использую для похожих задач include.
> 
> я прямо испытываю оргазм от одной мысли так делать.
> нарезать все по одной строке и инклюды-инклюды-инклюды!
> а уж какой кайф это редактировать или пытаться понять как конфиг
> выглядит.

В части понимания, с include'ов легко расправляется "nginx -T".

From slw на zxy.spb.ru  Fri Feb  9 20:38:36 2018
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Fri, 9 Feb 2018 23:38:36 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IGFjY2Vzc19sb2c=?=
In-Reply-To: <20180209192722.GA73219@lo0.su>
References: <1518169112.69790414@f368.i.mail.ru>
 <20180209130109.GQ24410@mdounin.ru>
 <20180209131116.GA81872@zxy.spb.ru> <20180209132642.GD65829@lo0.su>
 <20180209133505.GB81872@zxy.spb.ru> <20180209192722.GA73219@lo0.su>
Message-ID: <20180209203836.GD81872@zxy.spb.ru>

On Fri, Feb 09, 2018 at 10:27:22PM +0300, Ruslan Ermilov wrote:

> On Fri, Feb 09, 2018 at 04:35:05PM +0300, Slawa Olhovchenkov wrote:
> > On Fri, Feb 09, 2018 at 04:26:42PM +0300, Ruslan Ermilov wrote:
> > 
> > > On Fri, Feb 09, 2018 at 04:11:16PM +0300, Slawa Olhovchenkov wrote:
> > > > On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote:
> > > > 
> > > > > Hello!
> > > > > 
> > > > > On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > access_log в нижестоящем контексте отменяет все вышестоящие?
> > > > > 
> > > > > Как и все остальные директивы, access_log наследуется с 
> > > > > предыдущих уровней тогда и только тогда, когда на данном уровне не 
> > > > > указано директив access_log.
> > > > 
> > > > и при этом, кажется, нет возможности просто включать/выключать acceess
> > > > log, не трогая его настройки?
> > > 
> > > Запись в лог может быть условной при помощи параметра "if=".
> > > 
> > > Кроме того, можно на внешнем уровне (напр., server) задать access_log'и,
> > > а на вложенном уровне (напр., location) указать "access_log off;".
> > > Тогда на данном вложенном уровне access_log'и будут отключены, а
> > > на других вложенных уровнях (где не указаны свои access_log'и) будут
> > > действовать настройки как на внешнем уровне.
> > > 
> > > Я, впрочем, не уверен, что понял Ваш витиеватый вопрос правильно.
> > 
> > ну хочется указать accesslog. с кучей параметров (ну там путь,
> > буферезиция и все такое). а потом по дефолту его запретить. и
> > разрешать только для отдельный location.
> > 
> > ну вот я не вижу возможности так поступить, не повторяя в каждом
> > location директивы access_log со всеми этими параметрами.
> 
> Мне кажется, я уже ответил на Ваш вопрос ранее.
> 
> access_log <много_параметров> if="$log";
> 
> location /1 {
>     set $log 1;
>     <тут он будет работать>
> }
> 
> location /2 {
>     <а тут - нет>
> }

а что при этом с производительностью?

From ru на nginx.com  Fri Feb  9 20:54:22 2018
From: ru на nginx.com (Ruslan Ermilov)
Date: Fri, 9 Feb 2018 23:54:22 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IGFjY2Vzc19sb2c=?=
In-Reply-To: <20180209203836.GD81872@zxy.spb.ru>
References: <1518169112.69790414@f368.i.mail.ru>
 <20180209130109.GQ24410@mdounin.ru>
 <20180209131116.GA81872@zxy.spb.ru> <20180209132642.GD65829@lo0.su>
 <20180209133505.GB81872@zxy.spb.ru> <20180209192722.GA73219@lo0.su>
 <20180209203836.GD81872@zxy.spb.ru>
Message-ID: <20180209205422.GE73219@lo0.su>

On Fri, Feb 09, 2018 at 11:38:36PM +0300, Slawa Olhovchenkov wrote:
> On Fri, Feb 09, 2018 at 10:27:22PM +0300, Ruslan Ermilov wrote:
> 
> > On Fri, Feb 09, 2018 at 04:35:05PM +0300, Slawa Olhovchenkov wrote:
> > > On Fri, Feb 09, 2018 at 04:26:42PM +0300, Ruslan Ermilov wrote:
> > > 
> > > > On Fri, Feb 09, 2018 at 04:11:16PM +0300, Slawa Olhovchenkov wrote:
> > > > > On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote:
> > > > > 
> > > > > > Hello!
> > > > > > 
> > > > > > On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > > access_log в нижестоящем контексте отменяет все вышестоящие?
> > > > > > 
> > > > > > Как и все остальные директивы, access_log наследуется с 
> > > > > > предыдущих уровней тогда и только тогда, когда на данном уровне не 
> > > > > > указано директив access_log.
> > > > > 
> > > > > и при этом, кажется, нет возможности просто включать/выключать acceess
> > > > > log, не трогая его настройки?
> > > > 
> > > > Запись в лог может быть условной при помощи параметра "if=".
> > > > 
> > > > Кроме того, можно на внешнем уровне (напр., server) задать access_log'и,
> > > > а на вложенном уровне (напр., location) указать "access_log off;".
> > > > Тогда на данном вложенном уровне access_log'и будут отключены, а
> > > > на других вложенных уровнях (где не указаны свои access_log'и) будут
> > > > действовать настройки как на внешнем уровне.
> > > > 
> > > > Я, впрочем, не уверен, что понял Ваш витиеватый вопрос правильно.
> > > 
> > > ну хочется указать accesslog. с кучей параметров (ну там путь,
> > > буферезиция и все такое). а потом по дефолту его запретить. и
> > > разрешать только для отдельный location.
> > > 
> > > ну вот я не вижу возможности так поступить, не повторяя в каждом
> > > location директивы access_log со всеми этими параметрами.
> > 
> > Мне кажется, я уже ответил на Ваш вопрос ранее.
> > 
> > access_log <много_параметров> if="$log";
> > 
> > location /1 {
> >     set $log 1;
> >     <тут он будет работать>
> > }
> > 
> > location /2 {
> >     <а тут - нет>
> > }
> 
> а что при этом с производительностью?

Зависит от сложности вычисления условия.  В случае с "set", это будет
практически неизмеримо.  Цитата из кода:

        if (log[l].filter) {
            if (ngx_http_complex_value(r, log[l].filter, &val) != NGX_OK) {
                return NGX_ERROR;
            }

            if (val.len == 0 || (val.len == 1 && val.data[0] == '0')) {
                continue;
            }
        }

From nginx-forum на forum.nginx.org  Sun Feb 11 02:03:09 2018
From: nginx-forum на forum.nginx.org (salink888)
Date: Sat, 10 Feb 2018 21:03:09 -0500
Subject: HEPA Filter Made in China
Message-ID: <f5f57019589133f1c399829ccf5b6323.NginxMailingListRussian@forum.nginx.org>

HEPA Air Filter for Hand Dryer
Material   Paper 
Logo Customized 
Size Customized 
Color Refer to the picture(other colors are available) 
Usage Hand dryer 
Payment Terms T/T ,LC (guarantee the quality  and delivery date),Credit card
,paypal 
  HEPA Filter Made in China
website:http://www.aike-handdryer.com/hand-dryer-accessories/hepa-filter/.

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


From nginx-forum на forum.nginx.org  Sun Feb 11 02:03:24 2018
From: nginx-forum на forum.nginx.org (salink888)
Date: Sat, 10 Feb 2018 21:03:24 -0500
Subject: 6063 Aluminum Sheet factory
Message-ID: <9043165abab34753fb89979aebbf3684.NginxMailingListRussian@forum.nginx.org>

Founded in 2008, Zhejiang Hanlv Aluminum Industry Co., Ltd. is an integrated
enterprise which specializes in aluminum products manufacturing &
processing, international sales & domestic sales. As a modernized enterprise
with high technology and self-management export, we are of solid financial
base and great capability for production, research and development. To
provide customers with one-stop service from the material to the finished
product.
Through the years, we got the certificate of ISO9001:2015,and built up many
morden production lines, including one 1+2 hot rolling production line, six
2450mm, 2050mm, 1650mm, 1450mm cold rolling lines, two 1650mm foil rolling
production lines, two 1850mm continuous rolling production lines and one
roll coating production line. Besides, we bring in 8x20 annealing furnaces,
tension leveled machine, tension pre-stretch machine, cutting machine,
brushed equipment, CNC equipment, clean equipment, testing machine and
packing equipment from domestic and abroad.
Advanced equipment and strict management both contribute to the excellent
quality of products. Our main products are all kinds of cold rolling and hot
rolling aluminum sheet, coil, checkered plate, embossed plate, aluminum
disc, aluminum profile, painted aluminum sheet and coil. As well as
downstream processing products, such as aluminum brushed sheet, aluminum
punching plate, stamping parts, blank sheet, aluminum door, aluminum fence,
etc. Our products are sold to all over the world, including South America,
North America, Europe, Middle-East, South-East Asia, Africa etc and used in
various fields such as construction, decoration, automobile, electronic,
machinery, boat construction, aeronautics&astronautics, cookware, packing
etc.
Adhering to the principle of " Surviving with quality and developing with
credibility", Hanlv hopes to work with all customers for a better
future.6063 Aluminum Sheet factory
website:http://www.aluminumhl.com/.

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


From nginx-forum на forum.nginx.org  Sun Feb 11 02:03:55 2018
From: nginx-forum на forum.nginx.org (salink888)
Date: Sat, 10 Feb 2018 21:03:55 -0500
Subject: High Density Foam Double Size Pocket Spring Mattress factory
Message-ID: <4a984f5a6ffce8eda8741709cc0654d5.NginxMailingListRussian@forum.nginx.org>

Founded in 2005, AH has been specializing in design, manufacture and sell of
mattress. From selected material to authoritative certificates, from skilled
workers to advanced equipment, from professional sales to quality services,
we are committed to providing every customer with the most satisfied
products and services, also a new superior sleep experience for final users.

AH is located in Dalian, China, 25km from Dalian Port, here has developed
shipping, convenient transportation network and the best air conditions for
mattress. 
Besides, our one-stop services including pre-sale, on-sale and after-sale
guarantee customers the maximize satisfaction and benefits. 
AH has family culture, just like our logo, thanksgiving and altruism are our
team tenets. We’d love to transfer AH positive energy to everyone. 
If you are interested in our products, we believe that we will offer our
professionalism and sincerity, to achieve win-win cooperation. 
 High Density Foam Double Size Pocket Spring Mattress factory
website:http://www.amorhome.com/.

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


From nginx-forum на forum.nginx.org  Sun Feb 11 02:04:05 2018
From: nginx-forum на forum.nginx.org (salink888)
Date: Sat, 10 Feb 2018 21:04:05 -0500
Subject: China Clutch Booster For Suzuki
Message-ID: <d44ba62439fde178623cc5b2efbdabb4.NginxMailingListRussian@forum.nginx.org>

This is clutch booster, its OEM number is 51000-60C10, it’s a normal small
item, the diameter is 5”, it is used for Suzuki Wagonr, it has big demand in
Indonesia market, the item takes use of precise professional equipment and
rigorously follows the industry standard such as ISO9001:2000.China Clutch
Booster For Suzuki
website:http://www.aydbrakebooster.com/clutch-booster/clutch-booster-for-suzuki/.

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


From nginx-forum на forum.nginx.org  Mon Feb 12 07:03:28 2018
From: nginx-forum на forum.nginx.org (Set)
Date: Mon, 12 Feb 2018 02:03:28 -0500
Subject: =?UTF-8?B?0JjRgdC60LvRjtGH0LjRgtGMINC40Lcg0YDQtdC00LjRgNC10LrRgtCw?=
Message-ID: <8900cdc519bc478ae95ae744850784b1.NginxMailingListRussian@forum.nginx.org>

Добрый день.
Настроен редирект с http на https.
server {
    server_name example.com example.com;
    listen 127.0.0.1:80;
    return 301 https://example.com$request_uri;
}
Вопрос, как отменить редкирект для определенного локейшина (не редиректить
на https)? Отдавать локеишин по http.

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


From andrey на kopeyko.ru  Mon Feb 12 07:07:27 2018
From: andrey на kopeyko.ru (Andrey Kopeyko)
Date: Mon, 12 Feb 2018 10:07:27 +0300
Subject: =?UTF-8?B?UmU6INCY0YHQutC70Y7Rh9C40YLRjCDQuNC3INGA0LXQtNC40YDQtdC60YLQsA==?=
In-Reply-To: <8900cdc519bc478ae95ae744850784b1.NginxMailingListRussian@forum.nginx.org>
References: <8900cdc519bc478ae95ae744850784b1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5a4edd441ec1bd24cc57c96bdcd39c66@kopeyko.ru>

Set писал 2018-02-12 10:03:
> Добрый день.

Добрый день, Set!

> Настроен редирект с http на https.
> server {
>     server_name example.com example.com;
>     listen 127.0.0.1:80;
>     return 301 https://example.com$request_uri;
> }
> Вопрос, как отменить редкирект для определенного локейшина (не 
> редиректить
> на https)? Отдавать локеишин по http.

Довольно просто
- вам надо описать этот location
- и не конфигурить в нём редирект.
- если отдавать нужно с локального диска - сконфигурите root



-- 
Best regards,
Andrey A. Kopeyko <andrey на kopeyko.ru>

From nginx-forum на forum.nginx.org  Mon Feb 12 07:31:36 2018
From: nginx-forum на forum.nginx.org (jtiq)
Date: Mon, 12 Feb 2018 02:31:36 -0500
Subject: =?UTF-8?B?cHJveHkgbm8gY2FjaGUg0LTQuNGA0LXQutGC0LjQstCw?=
Message-ID: <95774db128000dc8b0f80d1f520a53ad.NginxMailingListRussian@forum.nginx.org>

Здравствуйте, интересует вопрос: proxy_no_cache может ли отслеживать
содержимое? Например, не кэшировать если ответ от прокси содержит какой то
кусок текста.

proxy_no_cache $body 'some text here for no-cache'

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


From arut на nginx.com  Mon Feb 12 08:52:52 2018
From: arut на nginx.com (Roman Arutyunyan)
Date: Mon, 12 Feb 2018 11:52:52 +0300
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <95774db128000dc8b0f80d1f520a53ad.NginxMailingListRussian@forum.nginx.org>
References: <95774db128000dc8b0f80d1f520a53ad.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180212085251.GA4346@Romans-MacBook-Air.local>

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

On Mon, Feb 12, 2018 at 02:31:36AM -0500, jtiq wrote:
> Здравствуйте, интересует вопрос: proxy_no_cache может ли отслеживать
> содержимое? Например, не кэшировать если ответ от прокси содержит какой то
> кусок текста.
> 
> proxy_no_cache $body 'some text here for no-cache'

Директива proxy_no_cache может отслеживать содержимое заголовков ответа от
бекенда, например $upstream_http_foo.  А вот содержимое тела ответа
анализировать не получится т.к. в момент проверки proxy_no_cache тело еще
не прочитано.

Вообще, проверки типа "что-то содержит текст" в подобных случаях делаются с
помощью map.

-- 
Roman Arutyunyan

From nginx-forum на forum.nginx.org  Mon Feb 12 09:02:12 2018
From: nginx-forum на forum.nginx.org (Set)
Date: Mon, 12 Feb 2018 04:02:12 -0500
Subject: =?UTF-8?B?UmU6INCY0YHQutC70Y7Rh9C40YLRjCDQuNC3INGA0LXQtNC40YDQtdC60YLQsA==?=
In-Reply-To: <5a4edd441ec1bd24cc57c96bdcd39c66@kopeyko.ru>
References: <5a4edd441ec1bd24cc57c96bdcd39c66@kopeyko.ru>
Message-ID: <f3f7d3e80127600198166dccf2158406.NginxMailingListRussian@forum.nginx.org>

Спасибо большое.

Получилось реализовать в такой конструкции. 


server {
    server_name example.com example.com;
    listen 127.0.0.1:80;

    location / {
        return 301 https://example.com$request_uri;
    }

    location /some/ {
       root   /var/www/html/site;
    }
}

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278490,278494#msg-278494


From nginx-forum на forum.nginx.org  Mon Feb 12 09:59:43 2018
From: nginx-forum на forum.nginx.org (jtiq)
Date: Mon, 12 Feb 2018 04:59:43 -0500
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <20180212085251.GA4346@Romans-MacBook-Air.local>
References: <20180212085251.GA4346@Romans-MacBook-Air.local>
Message-ID: <a743f6e9dd8c88ce915667dfd243e60c.NginxMailingListRussian@forum.nginx.org>

А можно пример map?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278493,278496#msg-278496


From arut на nginx.com  Mon Feb 12 11:03:27 2018
From: arut на nginx.com (Roman Arutyunyan)
Date: Mon, 12 Feb 2018 14:03:27 +0300
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <a743f6e9dd8c88ce915667dfd243e60c.NginxMailingListRussian@forum.nginx.org>
References: <20180212085251.GA4346@Romans-MacBook-Air.local>
 <a743f6e9dd8c88ce915667dfd243e60c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180212110327.GB4346@Romans-MacBook-Air.local>

On Mon, Feb 12, 2018 at 04:59:43AM -0500, jtiq wrote:
> А можно пример map?

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

-- 
Roman Arutyunyan

From nginx-forum на forum.nginx.org  Mon Feb 12 11:06:15 2018
From: nginx-forum на forum.nginx.org (jtiq)
Date: Mon, 12 Feb 2018 06:06:15 -0500
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <20180212110327.GB4346@Romans-MacBook-Air.local>
References: <20180212110327.GB4346@Romans-MacBook-Air.local>
Message-ID: <2d0df4349b8540c91b593f65bf46e4f7.NginxMailingListRussian@forum.nginx.org>

Ваш саппорт на этом форуме такой ничтожный, просто даже спрашивать не
хочется. Как в детском саду.

Вы пример напишите как сделать:
> Вообще, проверки типа "что-то содержит текст" в подобных случаях делаются
с помощью map.

Я этот пример спрашивал.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278493,278498#msg-278498


From alex.hha на gmail.com  Mon Feb 12 11:13:27 2018
From: alex.hha на gmail.com (Alex Domoradov)
Date: Mon, 12 Feb 2018 13:13:27 +0200
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <2d0df4349b8540c91b593f65bf46e4f7.NginxMailingListRussian@forum.nginx.org>
References: <20180212110327.GB4346@Romans-MacBook-Air.local>
 <2d0df4349b8540c91b593f65bf46e4f7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAK90gp4yhZFnHqPEUTi07P9YohTTSCe0t0Tz2q6RKiBKoetnYQ@mail.gmail.com>

> Ваш саппорт на этом форуме такой ничтожный, просто даже спрашивать не
хочется. Как в детском саду.

вам кто-то что-то должен? Вы заплатили деньги за саппорт? У вас забанили
гугл? :)


2018-02-12 13:06 GMT+02:00 jtiq <nginx-forum на forum.nginx.org>:

> Ваш саппорт на этом форуме такой ничтожный, просто даже спрашивать не
> хочется. Как в детском саду.
>
> Вы пример напишите как сделать:
> > Вообще, проверки типа "что-то содержит текст" в подобных случаях делаются
> с помощью map.
>
> Я этот пример спрашивал.
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,278493,278498#msg-278498
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180212/2cf433cf/attachment-0001.html>

From nginx-forum на forum.nginx.org  Mon Feb 12 11:17:55 2018
From: nginx-forum на forum.nginx.org (jtiq)
Date: Mon, 12 Feb 2018 06:17:55 -0500
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <CAK90gp4yhZFnHqPEUTi07P9YohTTSCe0t0Tz2q6RKiBKoetnYQ@mail.gmail.com>
References: <CAK90gp4yhZFnHqPEUTi07P9YohTTSCe0t0Tz2q6RKiBKoetnYQ@mail.gmail.com>
Message-ID: <638c494663a284af83ced8262fd0283e.NginxMailingListRussian@forum.nginx.org>

Всё с вами ясно, вы теперь только за бабки нормальные ответы готовы писать.
Фуу и тут теперь бабки. Продажный nginx.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278493,278500#msg-278500


From arut на nginx.com  Mon Feb 12 11:21:12 2018
From: arut на nginx.com (Roman Arutyunyan)
Date: Mon, 12 Feb 2018 14:21:12 +0300
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <2d0df4349b8540c91b593f65bf46e4f7.NginxMailingListRussian@forum.nginx.org>
References: <20180212110327.GB4346@Romans-MacBook-Air.local>
 <2d0df4349b8540c91b593f65bf46e4f7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180212112112.GC4346@Romans-MacBook-Air.local>

On Mon, Feb 12, 2018 at 06:06:15AM -0500, jtiq wrote:
> Ваш саппорт на этом форуме такой ничтожный, просто даже спрашивать не
> хочется. Как в детском саду.
> 
> Вы пример напишите как сделать:
> > Вообще, проверки типа "что-то содержит текст" в подобных случаях делаются
> с помощью map.
> 
> Я этот пример спрашивал.

Подходящий пример идет вторым по указанной ссылке.  Уверен, разобраться в этом
не очень сложно, особенно в сочетании с описанием директивы proxy_no_cache,
которое, я надеюсь, вы прочитали прежде чем жаловаться на "ничтожный" саппорт:

: Задаёт условия, при которых ответ не будет сохраняться в кэш. Если значение
: хотя бы одного из строковых параметров непустое и не равно “0”, то ответ не
: будет сохранён:



-- 
Roman Arutyunyan

From nginx-forum на forum.nginx.org  Mon Feb 12 11:26:26 2018
From: nginx-forum на forum.nginx.org (jtiq)
Date: Mon, 12 Feb 2018 06:26:26 -0500
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <20180212112112.GC4346@Romans-MacBook-Air.local>
References: <20180212112112.GC4346@Romans-MacBook-Air.local>
Message-ID: <73b240549bce83d011a15c227ce94849.NginxMailingListRussian@forum.nginx.org>

Так проблема, что читать чтобы делать map??? Вы видите в примере map что
нибудь про proxy_no_cache? Я лично нет.
Вам ведь так сложно написать 4 строки неопытному пользователю. Вы ссылаетесь
на примеры, которые я и без этого нашёл.

Ничтожный продажный саппорт. 100 рублей хватит на нормальный человеческий
ответ?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278493,278502#msg-278502


From dmitriy на lyalyuev.info  Mon Feb 12 12:52:10 2018
From: dmitriy на lyalyuev.info (Dmitriy Lyalyuev)
Date: Mon, 12 Feb 2018 14:52:10 +0200
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <73b240549bce83d011a15c227ce94849.NginxMailingListRussian@forum.nginx.org>
References: <20180212112112.GC4346@Romans-MacBook-Air.local>
 <73b240549bce83d011a15c227ce94849.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAM+k4XExhkPZ2=Xoj7M0ZNM5FS8LE8LSx5gO5-uM7b0z+GBhKw@mail.gmail.com>

С таким отношением тарифы немного выше.
50 долларов за час работы, 4 часа минимум, предоплата.

Готовы?

2018-02-12 13:26 GMT+02:00 jtiq <nginx-forum на forum.nginx.org>:

> Так проблема, что читать чтобы делать map??? Вы видите в примере map что
> нибудь про proxy_no_cache? Я лично нет.
> Вам ведь так сложно написать 4 строки неопытному пользователю. Вы
> ссылаетесь
> на примеры, которые я и без этого нашёл.
>
> Ничтожный продажный саппорт. 100 рублей хватит на нормальный человеческий
> ответ?
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,278493,278502#msg-278502
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
With best regards,
Dmitriy Lyalyuev
https://lyalyuev.info
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180212/7f7a22ac/attachment.html>

From nginx-forum на forum.nginx.org  Mon Feb 12 12:57:20 2018
From: nginx-forum на forum.nginx.org (jtiq)
Date: Mon, 12 Feb 2018 07:57:20 -0500
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <CAM+k4XExhkPZ2=Xoj7M0ZNM5FS8LE8LSx5gO5-uM7b0z+GBhKw@mail.gmail.com>
References: <CAM+k4XExhkPZ2=Xoj7M0ZNM5FS8LE8LSx5gO5-uM7b0z+GBhKw@mail.gmail.com>
Message-ID: <ce08848446d9fa68669eee1aa28d8c68.NginxMailingListRussian@forum.nginx.org>

С каким отношением? Чтобы ваши жёны и девушки были такие же продажные, и за
такие тарифы.
Понял что у вас помощи не дождусь. Пойду на другие площадки.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278493,278513#msg-278513


From mdounin на mdounin.ru  Mon Feb 12 13:07:35 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 12 Feb 2018 16:07:35 +0300
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <ce08848446d9fa68669eee1aa28d8c68.NginxMailingListRussian@forum.nginx.org>
References: <CAM+k4XExhkPZ2=Xoj7M0ZNM5FS8LE8LSx5gO5-uM7b0z+GBhKw@mail.gmail.com>
 <ce08848446d9fa68669eee1aa28d8c68.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180212130735.GX24410@mdounin.ru>

Hello!

On Mon, Feb 12, 2018 at 07:57:20AM -0500, jtiq wrote:

> С каким отношением? Чтобы ваши жёны и девушки были такие же продажные, и за
> такие тарифы.
> Понял что у вас помощи не дождусь. Пойду на другие площадки.

Нам очень жаль, что вам не понравилось.  Но, к сожалению, в мире 
opensource это так работает: вам дают ответы люди, вкладывающие 
своё личное время в проект, и не получающие за это денег.  И если 
вы, вместо того, чтобы прочитать ответ и воспользоваться 
документацией (не говоря уже о том, чтобы поблагодарить), 
начинаете хамить в ответ, то единственный выход - это идти на 
другие полщадки, потому что на этой вам уже больше ничего не 
светит, кроме разве что бана.  Отмечу на всякий случай, что вести 
себя так же и на других площадках - я бы не рекомендовал, это 
чревато аналогичными последствиями и там.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Mon Feb 12 13:17:35 2018
From: nginx-forum на forum.nginx.org (jtiq)
Date: Mon, 12 Feb 2018 08:17:35 -0500
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <20180212130735.GX24410@mdounin.ru>
References: <20180212130735.GX24410@mdounin.ru>
Message-ID: <65ae999cff71201e124850908c66fb83.NginxMailingListRussian@forum.nginx.org>

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

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

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278493,278515#msg-278515


From dmitriy на lyalyuev.info  Mon Feb 12 13:23:34 2018
From: dmitriy на lyalyuev.info (Dmitriy Lyalyuev)
Date: Mon, 12 Feb 2018 15:23:34 +0200
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <65ae999cff71201e124850908c66fb83.NginxMailingListRussian@forum.nginx.org>
References: <20180212130735.GX24410@mdounin.ru>
 <65ae999cff71201e124850908c66fb83.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAM+k4XGUqh9K=jWCMygvUDuojk13cnaoB7T1H-Fmj25yDUMDNA@mail.gmail.com>

1. Это не форум, а список рассылки. И тут нет официальной поддержки, а
только энтузиасты, которые помогают всем, что ведет себя подобающе.
2. Вам никто и ничего не должен.
3. Хамить в любом сообществе не принято.
4. Вам дали варианты решения вашей задачи. Если вы не хотите погружаться
сам, то за решение ВАШЕЙ задачи в НАШЕ свободное время придется платить.
5. Никто от вас денег не требовал, а только предложили помощь на возмездной
основе. И не официальные лица, а лично я. Я никакого отношения к компании
Nginx не имею.
6. В ответ вы опять нахамили. Из чего я делаю вывод, что вы неадекватный
тролль и пришли сда не решить свою проблемму, а самоутвердиться.

Вывод напрашивается сам собой - персональный игнор и бан ваших сообщений
будет адекватной реакцией.

Удачи в поисках решения.

2018-02-12 15:17 GMT+02:00 jtiq <nginx-forum на forum.nginx.org>:

> Во-первых, вы сами не знаете ответа на мой вопрос и ссылаетесь на примеры
> которые ни какого отношения к моему вопросу не имеют.
> Во-вторых, не надо вводить в заблуждение других пользователей.
> В третьих, какая переменная предоставляет на чтение куска текста (пары
> слов)
> в ответе от прокси сервера? Её нет, так зачем вы путаете и говорите про
> какие то деньги?
>
> На других ресурсах всегда был чёткий ответ за обычное спасибо, а opensource
> nginx проект настолько зажрался, что теперь требуют бабки за ответ. Не раз
> убеждаюсь, что бабки портят всё и вся. Я обязательно расскажу про ваши
> требования другим, чтобы понимали что на официальном форуме поддержки nginx
> за ответ требуют бабки и не малые.
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,278493,278515#msg-278515
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
With best regards,
Dmitriy Lyalyuev
https://lyalyuev.info
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180212/a52fe1c1/attachment-0001.html>

From coddoc на mail.ru  Mon Feb 12 13:31:18 2018
From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=)
Date: Mon, 12 Feb 2018 16:31:18 +0300
Subject: =?UTF-8?B?0JIg0LrQsNC60L7QvCDQv9C+0YDRj9C00LrQtSDQvtCx0YDQsNCx0LDRgtGL0LI=?=
 =?UTF-8?B?0LDRjtGC0YHRjyBsb2NhdGlvbj8=?=
Message-ID: <1518442278.958426078@f45.i.mail.ru>


Доброе время суток!
Слегка запутался в порядке обработки локейшенов.
Такая структура:

/1/index.html
/23/index.html
/456/index.html
/7890/index.html

Все файлы index.html, естественно, разные.

Соответственно, тестовый конфиг:

server {
    ....
    location = /1/ { rewrite ^ /1/index.html break; }
    location = /23/ { rewrite ^ /23/index.html break; }
    location = /456/ { rewrite ^ /456/index.html break; }
    location = /7890/ { rewrite ^ /7890/index.html break; }

    location ~ (\.html$|\.php$) { internal; }

    location "" { return 404; }

    error_page 404 = @err404;

    # все, что не соответствует
    location @err404 {
        keepalive_timeout 0;
        rewrite ^ /err/404.html break;
    }
}

Из дебага:

2018/02/12 16:02:05 [debug] 11200#11200: *1 http request line: "GET /1/ HTTP/1.1"
2018/02/12 16:02:05 [debug] 11200#11200: *1 http uri: "/1/"

2018/02/12 16:02:05 [debug] 11200#11200: *1 test location: ""
<<< === здесь ожидалось test location: "/7890/", как локейшен максимальной длины
2018/02/12 16:02:05 [debug] 11200#11200: *1 test location: "/456/"
2018/02/12 16:02:05 [debug] 11200#11200: *1 test location: "/23/"
2018/02/12 16:02:05 [debug] 11200#11200: *1 test location: "/1/"
2018/02/12 16:02:05 [debug] 11200#11200: *1 using configuration "=/1/"

=====================================================

2018/02/12 16:03:05 [debug] 11246#11246: *1 http request line: "GET /23/ HTTP/1.1"
2018/02/12 16:03:05 [debug] 11246#11246: *1 http uri: "/23/"

2018/02/12 16:03:05 [debug] 11246#11246: *1 test location: ""
<<< === здесь также ожидалось test location: "/7890/", как локейшен максимальной длины
2018/02/12 16:03:05 [debug] 11246#11246: *1 test location: "/456/"
2018/02/12 16:03:05 [debug] 11246#11246: *1 test location: "/23/"
2018/02/12 16:03:05 [debug] 11246#11246: *1 using configuration "=/23/"

=======================================================

2018/02/12 16:03:51 [debug] 11283#11283: *1 http request line: "GET /456/ HTTP/1.1"
2018/02/12 16:03:51 [debug] 11283#11283: *1 http uri: "/456/"

2018/02/12 16:03:51 [debug] 11283#11283: *1 test location: ""
2018/02/12 16:03:51 [debug] 11283#11283: *1 test location: "/456/"
2018/02/12 16:03:51 [debug] 11283#11283: *1 using configuration "=/456/"

=====================================================
Запрос в несуществующий локейшен

2018/02/12 16:22:47 [debug] 11285#11285: *3 http request line: "GET /7890/qqqqqqqqqqqq HTTP/1.1"
2018/02/12 16:22:47 [debug] 11285#11285: *3 http uri: "/7890/qqqqqqqqqqqq"

2018/02/12 16:22:47 [debug] 11285#11285: *3 test location: ""
2018/02/12 16:22:47 [debug] 11285#11285: *3 test location: "/456/"
2018/02/12 16:22:47 [debug] 11285#11285: *3 test location: "/7890/"
2018/02/12 16:22:47 [debug] 11285#11285: *3 test location: ~ "(\.html$|\.php$)"
2018/02/12 16:22:47 [debug] 11285#11285: *3 using configuration ""

2018/02/12 16:22:47 [debug] 11285#11285: *3 rewrite phase: 3
2018/02/12 16:22:47 [debug] 11285#11285: *3 http finalize request: 404, "/7890/qqqqqqqqqqqq?" a:1, c:1
2018/02/12 16:22:47 [debug] 11285#11285: *3 http special response: 404, "/7890/qqqqqqqqqqqq?"
2018/02/12 16:22:47 [debug] 11285#11285: *3 test location: "@err404"
2018/02/12 16:22:47 [debug] 11285#11285: *3 using location: @err404 "/7890/qqqqqqqqqqqq?"
......
=====================================================

Т.е. работает-то оно правильно, но проверки существующих локейшенов почему-то всегда начинаюся с "/456/". Не понимаю, чем он такой особенный? Если отталкиваться от длины, так самый длинный "/7890/"

Спасибо.

--
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180212/72db79cb/attachment.html>

From mdounin на mdounin.ru  Mon Feb 12 13:42:07 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 12 Feb 2018 16:42:07 +0300
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <65ae999cff71201e124850908c66fb83.NginxMailingListRussian@forum.nginx.org>
References: <20180212130735.GX24410@mdounin.ru>
 <65ae999cff71201e124850908c66fb83.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180212134207.GZ24410@mdounin.ru>

Hello!

On Mon, Feb 12, 2018 at 08:17:35AM -0500, jtiq wrote:

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

Ещё раз, для ясности:

- Это не "официальный форум", это список рассылки.

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

- Ответ вам был дан сразу же, и вполне однозначный.  Перечитайте, 
  http://mailman.nginx.org/pipermail/nginx-ru/2018-February/060913.html.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin на mdounin.ru  Mon Feb 12 13:51:46 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 12 Feb 2018 16:51:46 +0300
Subject: =?UTF-8?B?UmU6INCSINC60LDQutC+0Lwg0L/QvtGA0Y/QtNC60LUg0L7QsdGA0LDQsdCw0YI=?=
 =?UTF-8?B?0YvQstCw0Y7RgtGB0Y8gbG9jYXRpb24/?=
In-Reply-To: <1518442278.958426078@f45.i.mail.ru>
References: <1518442278.958426078@f45.i.mail.ru>
Message-ID: <20180212135146.GA24410@mdounin.ru>

Hello!

On Mon, Feb 12, 2018 at 04:31:18PM +0300, CoDDoC wrote:

> Доброе время суток!
> Слегка запутался в порядке обработки локейшенов.
> Такая структура:
> 
> /1/index.html
> /23/index.html
> /456/index.html
> /7890/index.html
> 
> Все файлы index.html, естественно, разные.
> 
> Соответственно, тестовый конфиг:
> 
> server {
>     ....
>     location = /1/ { rewrite ^ /1/index.html break; }
>     location = /23/ { rewrite ^ /23/index.html break; }
>     location = /456/ { rewrite ^ /456/index.html break; }
>     location = /7890/ { rewrite ^ /7890/index.html break; }

[...]

> Т.е. работает-то оно правильно, но проверки существующих 
> локейшенов почему-то всегда начинаюся с "/456/". Не понимаю, чем 
> он такой особенный? Если отталкиваться от длины, так самый 
> длинный "/7890/"

Префиксные location'ы не проверяются последовательно, а строится 
дерево, и поиск максимально совпадающего location'а делается 
проходом по дереву.  В вашем случае location /456/ оказался в 
корне дерева, и поэтому проверяется первым.

-- 
Maxim Dounin
http://mdounin.ru/

From coddoc на mail.ru  Mon Feb 12 13:58:32 2018
From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=)
Date: Mon, 12 Feb 2018 16:58:32 +0300
Subject: =?UTF-8?B?UmVbMl06INCSINC60LDQutC+0Lwg0L/QvtGA0Y/QtNC60LUg0L7QsdGA0LDQsdCw?=
 =?UTF-8?B?0YLRi9Cy0LDRjtGC0YHRjyBsb2NhdGlvbj8=?=
In-Reply-To: <20180212135146.GA24410@mdounin.ru>
References: <1518442278.958426078@f45.i.mail.ru>
 <20180212135146.GA24410@mdounin.ru>
Message-ID: <1518443912.284563539@f372.i.mail.ru>

>> location /456/ оказался в корне дерева, и поэтому проверяется первым.
А почему именно этот? Можно поподробнее?

Спасибо.

>Понедельник, 12 февраля 2018, 16:52 +03:00 от Maxim Dounin <mdounin на mdounin.ru>:
>
>Hello!
>
>On Mon, Feb 12, 2018 at 04:31:18PM +0300, CoDDoC wrote:
>
>> Доброе время суток!
>> Слегка запутался в порядке обработки локейшенов.
>> Такая структура:
>> 
>> /1/index.html
>> /23/index.html
>> /456/index.html
>> /7890/index.html
>> 
>> Все файлы index.html, естественно, разные.
>> 
>> Соответственно, тестовый конфиг:
>> 
>> server {
>>     ....
>>     location = /1/ { rewrite ^ /1/index.html break; }
>>     location = /23/ { rewrite ^ /23/index.html break; }
>>     location = /456/ { rewrite ^ /456/index.html break; }
>>     location = /7890/ { rewrite ^ /7890/index.html break; }
>
>[...]
>
>> Т.е. работает-то оно правильно, но проверки существующих 
>> локейшенов почему-то всегда начинаюся с "/456/". Не понимаю, чем 
>> он такой особенный? Если отталкиваться от длины, так самый 
>> длинный "/7890/"
>
>Префиксные location'ы не проверяются последовательно, а строится 
>дерево, и поиск максимально совпадающего location'а делается 
>проходом по дереву.  В вашем случае location /456/ оказался в 
>корне дерева, и поэтому проверяется первым.
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>_______________________________________________
>nginx-ru mailing list
>nginx-ru на nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


--
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180212/598c8d42/attachment-0001.html>

From mdounin на mdounin.ru  Mon Feb 12 14:17:25 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 12 Feb 2018 17:17:25 +0300
Subject: =?UTF-8?B?UmU6INCSINC60LDQutC+0Lwg0L/QvtGA0Y/QtNC60LUg0L7QsdGA0LDQsdCw0YI=?=
 =?UTF-8?B?0YvQstCw0Y7RgtGB0Y8gbG9jYXRpb24/?=
In-Reply-To: <1518443912.284563539@f372.i.mail.ru>
References: <1518442278.958426078@f45.i.mail.ru>
 <20180212135146.GA24410@mdounin.ru>
 <1518443912.284563539@f372.i.mail.ru>
Message-ID: <20180212141725.GB24410@mdounin.ru>

Hello!

On Mon, Feb 12, 2018 at 04:58:32PM +0300, CoDDoC wrote:

> >> location /456/ оказался в корне дерева, и поэтому проверяется первым.
> А почему именно этот? Можно поподробнее?

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

-- 
Maxim Dounin
http://mdounin.ru/

From chipitsine на gmail.com  Mon Feb 12 14:24:14 2018
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 12 Feb 2018 19:24:14 +0500
Subject: =?UTF-8?B?UmU6IHByb3h5IG5vIGNhY2hlINC00LjRgNC10LrRgtC40LLQsA==?=
In-Reply-To: <65ae999cff71201e124850908c66fb83.NginxMailingListRussian@forum.nginx.org>
References: <20180212130735.GX24410@mdounin.ru>
 <65ae999cff71201e124850908c66fb83.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQErUsFejpaTjS=U23otBR-BoZ9kYX7ZkGXZSPKxSwBMLg@mail.gmail.com>

12 февраля 2018 г., 18:17 пользователь jtiq <nginx-forum на forum.nginx.org>
написал:

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

в прокуратуру, в ООН, и на прямой линии президенту.

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


>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,278493,278515#msg-278515
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180212/50be1836/attachment.html>

From coddoc на mail.ru  Mon Feb 12 14:30:37 2018
From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=)
Date: Mon, 12 Feb 2018 17:30:37 +0300
Subject: =?UTF-8?B?UmVbMl06INCSINC60LDQutC+0Lwg0L/QvtGA0Y/QtNC60LUg0L7QsdGA0LDQsdCw?=
 =?UTF-8?B?0YLRi9Cy0LDRjtGC0YHRjyBsb2NhdGlvbj8=?=
In-Reply-To: <20180212141725.GB24410@mdounin.ru>
References: <1518442278.958426078@f45.i.mail.ru>
 <1518443912.284563539@f372.i.mail.ru>
 <20180212141725.GB24410@mdounin.ru>
Message-ID: <1518445837.411458796@f327.i.mail.ru>

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


>Понедельник, 12 февраля 2018, 17:17 +03:00 от Maxim Dounin <mdounin на mdounin.ru>:
>
>Hello!
>
>On Mon, Feb 12, 2018 at 04:58:32PM +0300, CoDDoC wrote:
>
>> >> location /456/ оказался в корне дерева, и поэтому проверяется первым.
>> А почему именно этот? Можно поподробнее?
>
>Потом что он находится в середине списка location'ов, 
>отсортированного строково.  Такой подход позволяет минимизировать 
>количество необходимых сравнений: если строковое сравнение URI 
>запроса с /456/ говорит, что URI меньше, то дальнейший поиск 
>нужного location'а будет делаться только среди location'ов, 
>которые меньше /456/.
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>_______________________________________________
>nginx-ru mailing list
>nginx-ru на nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


--
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180212/99aa90ea/attachment.html>

From nginx-forum на forum.nginx.org  Wed Feb 14 09:56:42 2018
From: nginx-forum на forum.nginx.org (imsystem)
Date: Wed, 14 Feb 2018 04:56:42 -0500
Subject: nginx restart AND listen ip:port
Message-ID: <64887095e668ff0337c585fbdaf09ffb.NginxMailingListRussian@forum.nginx.org>

Здравствуйте. Обнаружил такую проблему(багу?).
При добавлении блока:

server {
        listen ip:80 default_server;
        server_name _;
        return 301 https://mysite.com;
}

Перестаёт работать рестарт сервера.
Если же ip:80 заменить на просто порт 80, то команды service nginx restart
или systemctl restart nginx работают.

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

Может я чего-то не понимаю?
Спасибо за внимание.

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


From nginx-forum на forum.nginx.org  Wed Feb 14 10:04:36 2018
From: nginx-forum на forum.nginx.org (imsystem)
Date: Wed, 14 Feb 2018 05:04:36 -0500
Subject: nginx restart AND listen ip:port
In-Reply-To: <64887095e668ff0337c585fbdaf09ffb.NginxMailingListRussian@forum.nginx.org>
References: <64887095e668ff0337c585fbdaf09ffb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <698c172271c569ff9c28c9fb06bc95ca.NginxMailingListRussian@forum.nginx.org>

Добавлю что nginx используется для проксирования на backend.
Два интерфейса внешний и локальный. Везде ip - внешний ip.
Для сайтов блоки:
server {
listen ip:80 ..
return ...
}
server {
listen ip:443 ..
...
}
Проксирование идёт по локалке.
Если принудительно не указывать ip в listen, то не проксируется.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278548,278549#msg-278549


From nginx-forum на forum.nginx.org  Wed Feb 14 10:10:06 2018
From: nginx-forum на forum.nginx.org (imsystem)
Date: Wed, 14 Feb 2018 05:10:06 -0500
Subject: nginx restart AND listen ip:port
In-Reply-To: <698c172271c569ff9c28c9fb06bc95ca.NginxMailingListRussian@forum.nginx.org>
References: <64887095e668ff0337c585fbdaf09ffb.NginxMailingListRussian@forum.nginx.org>
 <698c172271c569ff9c28c9fb06bc95ca.NginxMailingListRussian@forum.nginx.org>
Message-ID: <4814a753693bf79b1c40efa6317e8bbb.NginxMailingListRussian@forum.nginx.org>

И совсем забыл.

nginx -V
nginx version: nginx/1.12.1
built by gcc 6.3.0 20170516 (Debian 6.3.0-18)
built with OpenSSL 1.1.1-dev  xx XXX xxxx
TLS SNI support enabled
configure arguments: --prefix=/usr/local/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
--user=www-data --group=www-data --with-threads --with-file-aio
--with-http_ssl_module --with-openssl=/home/sysadmin/src/openssl
--with-http_v2_module --with-http_realip_module --with-http_addition_module
--with-http_xslt_module --with-http_image_filter_module
--with-http_geoip_module --with-http_sub_module --with-http_dav_module
--with-http_flv_module --with-http_mp4_module --with-http_gunzip_module
--with-http_gzip_static_module --with-http_auth_request_module
--with-http_random_index_module --with-http_secure_link_module
--with-http_degradation_module --with-http_slice_module
--with-http_stub_status_module --with-stream --with-stream_ssl_module

uname -a
Linux gateway 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)
x86_64 GNU/Linux

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278548,278550#msg-278550


From coddoc на mail.ru  Wed Feb 14 10:55:33 2018
From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=)
Date: Wed, 14 Feb 2018 13:55:33 +0300
Subject: nginx restart AND listen ip:port
In-Reply-To: <4814a753693bf79b1c40efa6317e8bbb.NginxMailingListRussian@forum.nginx.org>
References: <64887095e668ff0337c585fbdaf09ffb.NginxMailingListRussian@forum.nginx.org>
 <698c172271c569ff9c28c9fb06bc95ca.NginxMailingListRussian@forum.nginx.org>
 <4814a753693bf79b1c40efa6317e8bbb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1518605733.615022725@f25.i.mail.ru>

Вам обязательно 'service nginx restart'?
'nginx -s reload' пробовали?

Насчет версии 1.12.1. В stable ветке доступна 1.12.2. Может там уже пофиксили?

>> Два интерфейса внешний и локальный. Везде ip - внешний ip.
>> Проксирование идёт по локалке.
>> Если принудительно не указывать ip в listen, то не проксируется.
Потрудитесь четко формулировать вопрос.
Что и куда вы проксируете? nginx на nginx? 80-й порт на 443-й? Бэкенд где находится? На том же сервере или на другом?
ip  в конфиге внешние?


>Среда, 14 февраля 2018, 13:10 +03:00 от "imsystem" <nginx-forum на forum.nginx.org>:
>
>И совсем забыл.
>
>nginx -V
>nginx version: nginx/1.12.1
>built by gcc 6.3.0 20170516 (Debian 6.3.0-18)
>built with OpenSSL 1.1.1-dev  xx XXX xxxx
>TLS SNI support enabled
>configure arguments: --prefix=/usr/local/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
>--user=www-data --group=www-data --with-threads --with-file-aio
>--with-http_ssl_module --with-openssl=/home/sysadmin/src/openssl
>--with-http_v2_module --with-http_realip_module --with-http_addition_module
>--with-http_xslt_module --with-http_image_filter_module
>--with-http_geoip_module --with-http_sub_module --with-http_dav_module
>--with-http_flv_module --with-http_mp4_module --with-http_gunzip_module
>--with-http_gzip_static_module --with-http_auth_request_module
>--with-http_random_index_module --with-http_secure_link_module
>--with-http_degradation_module --with-http_slice_module
>--with-http_stub_status_module --with-stream --with-stream_ssl_module
>
>uname -a
>Linux gateway 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)
>x86_64 GNU/Linux
>
>Posted at Nginx Forum:  https://forum.nginx.org/read.php?21,278548,278550#msg-278550
>
>_______________________________________________
>nginx-ru mailing list
>nginx-ru на nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


--
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180214/8827f677/attachment.html>

From nginx-forum на forum.nginx.org  Wed Feb 14 12:32:12 2018
From: nginx-forum на forum.nginx.org (ellaizzer)
Date: Wed, 14 Feb 2018 07:32:12 -0500
Subject: =?UTF-8?B?UmU6INCd0LAg0L/RgdC10LLQtNC+0L3QuNC80LUg0YHQsNC50YLQsCDQvdC1INC6?=
 =?UTF-8?B?0LXRiNC40YDRg9GO0YLRgdGPINC60LDRgNGC0LjQvdC60Lgg0Lgg0LTRgNGD?=
 =?UTF-8?B?0LPQuNC1INGE0LDQudC70YsgLSBuZ2lueA==?=
In-Reply-To: <CAKqRTSFjZRS=acJAmYGGb_VKmb6A4udgbbtCr7VMQY2bDVMfrA@mail.gmail.com>
References: <CAKqRTSFjZRS=acJAmYGGb_VKmb6A4udgbbtCr7VMQY2bDVMfrA@mail.gmail.com>
Message-ID: <ba8e6847f26986c3858d22477960b4cd.NginxMailingListRussian@forum.nginx.org>

Aleksandr Sytar Wrote:
-------------------------------------------------------
> 2018-01-15 11:43 GMT+03:00 ellaizzer <nginx-forum на forum.nginx.org>:
> 
> >
> > Проблема в том что не кешуруются файлы на псевдонимах m.example.com
> и
> > www.m.example.com, но кешируются на example.com и www.example.com
> >
> > Кто подскажет в чем может быть проблема некеширования на
> псевдонимах?
> >
> >
> На каком уровне кеширование должно быть по вашему мнению - в браузере
> или в
> nginx и как именно вы проверяете что не кешируется?
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


Речь про кеширование в браузере, проверяю в хроме в Developer Tools ->
Network (Response Headers -> Cache-Control отстутствует в мобильной версии
совсем, в десктопной присутствует)

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278140,278552#msg-278552


From mdounin на mdounin.ru  Wed Feb 14 12:40:45 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 14 Feb 2018 15:40:45 +0300
Subject: nginx restart AND listen ip:port
In-Reply-To: <64887095e668ff0337c585fbdaf09ffb.NginxMailingListRussian@forum.nginx.org>
References: <64887095e668ff0337c585fbdaf09ffb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180214124045.GL24410@mdounin.ru>

Hello!

On Wed, Feb 14, 2018 at 04:56:42AM -0500, imsystem wrote:

> Здравствуйте. Обнаружил такую проблему(багу?).
> При добавлении блока:
> 
> server {
>         listen ip:80 default_server;
>         server_name _;
>         return 301 https://mysite.com;
> }
> 
> Перестаёт работать рестарт сервера.
> Если же ip:80 заменить на просто порт 80, то команды service nginx restart
> или systemctl restart nginx работают.
> 
> В обоих случаях команда nginx -t говорит, что всё хорошо, в логах
> соответственно ничего нет.
> Команды на старт/стоп работают в обоих случаях, т.е. я просто не могу
> перезагрузить.

С учётом того, что restart - это фактически stop и следующий за 
ним stop, либо у вас в service-файле для systemd написано что-то 
странное, либо вы на самом деле путаете, и речь про reload.

С reload'ом на Linux'е имеется достаточно типичная проблема: в 
отличие от других операционных систем, linux не позволяет 
одновременно открыть listen-сокеты на *:80 и <ip>:80.

В результате если nginx уже запущен с listen на *:80, то написать 
вместо него в конфигурации listen <ip>:80 и сделать reload - 
нельзя, nginx не сможет создать новые listen-сокеты для новой 
конфигурации, так как они конфликтуют с уже открытыми 
listen-сокетами старой конфигурации.  В error log'е, заданном на 
глобальном уровне, будет при этом что-то вроде:

2018/02/14 15:32:52 [notice] 1672#1672: signal 1 (SIGHUP) received from 1762, reconfiguring
2018/02/14 15:32:52 [notice] 1672#1672: reconfiguring
2018/02/14 15:32:52 [emerg] 1672#1672: bind() to 127.0.0.1:80 failed (98: Address already in use)
2018/02/14 15:32:52 [notice] 1672#1672: try again to bind() after 500ms
2018/02/14 15:32:52 [emerg] 1672#1672: bind() to 127.0.0.1:80 failed (98: Address already in use)
2018/02/14 15:32:52 [notice] 1672#1672: try again to bind() after 500ms
2018/02/14 15:32:52 [emerg] 1672#1672: bind() to 127.0.0.1:80 failed (98: Address already in use)
2018/02/14 15:32:52 [notice] 1672#1672: try again to bind() after 500ms
2018/02/14 15:32:52 [emerg] 1672#1672: bind() to 127.0.0.1:80 failed (98: Address already in use)
2018/02/14 15:32:52 [notice] 1672#1672: try again to bind() after 500ms
2018/02/14 15:32:52 [emerg] 1672#1672: bind() to 127.0.0.1:80 failed (98: Address already in use)
2018/02/14 15:32:52 [notice] 1672#1672: try again to bind() after 500ms
2018/02/14 15:32:52 [emerg] 1672#1672: still could not bind()

Соответственно nginx не сможет создать новую конфигурацию, и 
продолжит работать со старой.

Если такое изменение в listen-сокетах действительно необходимо, то 
следует сделать restart - то есть выключить nginx, и включить его 
обратно.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Wed Feb 14 12:50:53 2018
From: nginx-forum на forum.nginx.org (imsystem)
Date: Wed, 14 Feb 2018 07:50:53 -0500
Subject: nginx restart AND listen ip:port
In-Reply-To: <1518605733.615022725@f25.i.mail.ru>
References: <1518605733.615022725@f25.i.mail.ru>
Message-ID: <1ce27fbb9e4a9d9a6acb3859746c407d.NginxMailingListRussian@forum.nginx.org>

> Вам обязательно 'service nginx restart'?
> 'nginx -s reload' пробовали?
Нет, не обязательно.
Нет, не пробовал, считал её сопоставимой команде service nginx reload, а она
работает.
Меня сам факт смущает.

> Насчет версии 1.12.1. В stable ветке доступна 1.12.2. Может там уже
> пофиксили?
Может и пофиксили.

> >> Два интерфейса внешний и локальный. Везде ip - внешний ip.
> >> Проксирование идёт по локалке.
> >> Если принудительно не указывать ip в listen, то не проксируется.
> Потрудитесь четко формулировать вопрос.
> Что и куда вы проксируете? nginx на nginx? 80-й порт на 443-й? Бэкенд
> где находится? На том же сервере или на другом?
> ip  в конфиге внешние?
С nginx на IIS, сервера разные, 80 порт перенаправляется на 443 (http ->
https).
ip которые слушает nginx внешние, проксирует соответственно на локальный ip
IIS по https протоколу.


> >Среда, 14 февраля 2018, 13:10 +03:00 от "imsystem"
> <nginx-forum на forum.nginx.org>:
> >
> >И совсем забыл.
> >
> >nginx -V
> >nginx version: nginx/1.12.1
> >built by gcc 6.3.0 20170516 (Debian 6.3.0-18)
> >built with OpenSSL 1.1.1-dev  xx XXX xxxx
> >TLS SNI support enabled
> >configure arguments: --prefix=/usr/local/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
> >--user=www-data --group=www-data --with-threads --with-file-aio
> >--with-http_ssl_module --with-openssl=/home/sysadmin/src/openssl
> >--with-http_v2_module --with-http_realip_module
> --with-http_addition_module
> >--with-http_xslt_module --with-http_image_filter_module
> >--with-http_geoip_module --with-http_sub_module
> --with-http_dav_module
> >--with-http_flv_module --with-http_mp4_module
> --with-http_gunzip_module
> >--with-http_gzip_static_module --with-http_auth_request_module
> >--with-http_random_index_module --with-http_secure_link_module
> >--with-http_degradation_module --with-http_slice_module
> >--with-http_stub_status_module --with-stream --with-stream_ssl_module
> >
> >uname -a
> >Linux gateway 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1
> (2017-12-23)
> >x86_64 GNU/Linux
> >
> >Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?21,278548,278550#msg-278550
> >
> >_______________________________________________
> >nginx-ru mailing list
> >nginx-ru на nginx.org
> >http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> 
> --
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278551,278554#msg-278554


From nginx-forum на forum.nginx.org  Wed Feb 14 12:56:10 2018
From: nginx-forum на forum.nginx.org (imsystem)
Date: Wed, 14 Feb 2018 07:56:10 -0500
Subject: nginx restart AND listen ip:port
In-Reply-To: <20180214124045.GL24410@mdounin.ru>
References: <20180214124045.GL24410@mdounin.ru>
Message-ID: <8c5a138dbc4218e78933ddcad599c74a.NginxMailingListRussian@forum.nginx.org>

restart|force-reload)
        echo -n "Restarting $DESC: "
        start-stop-daemon --stop --quiet --pidfile \
                /var/run/$NAME.pid --exec $DAEMON
        sleep 1
        start-stop-daemon --start --quiet --pidfile \
                /var/run/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS
        echo "$NAME."
        ;;
  reload)
      echo -n "Reloading $DESC configuration: "
      start-stop-daemon --stop --signal HUP --quiet --pidfile
/var/run/$NAME.pid \
          --exec $DAEMON
      echo "$NAME."
      ;;

Ничего такого.

Спасибо подробный за ответ, но это явно не то, т.к. reload работал без каких
либо ошибок, новая конфигурация подгружалась.


Maxim Dounin Wrote:
-------------------------------------------------------
> Hello!
> 
> On Wed, Feb 14, 2018 at 04:56:42AM -0500, imsystem wrote:
> 
> > Здравствуйте. Обнаружил такую проблему(багу?).
> > При добавлении блока:
> > 
> > server {
> >         listen ip:80 default_server;
> >         server_name _;
> >         return 301 https://mysite.com;
> > }
> > 
> > Перестаёт работать рестарт сервера.
> > Если же ip:80 заменить на просто порт 80, то команды service nginx
> restart
> > или systemctl restart nginx работают.
> > 
> > В обоих случаях команда nginx -t говорит, что всё хорошо, в логах
> > соответственно ничего нет.
> > Команды на старт/стоп работают в обоих случаях, т.е. я просто не
> могу
> > перезагрузить.
> 
> С учётом того, что restart - это фактически stop и следующий за 
> ним stop, либо у вас в service-файле для systemd написано что-то 
> странное, либо вы на самом деле путаете, и речь про reload.
> 
> С reload'ом на Linux'е имеется достаточно типичная проблема: в 
> отличие от других операционных систем, linux не позволяет 
> одновременно открыть listen-сокеты на *:80 и <ip>:80.
> 
> В результате если nginx уже запущен с listen на *:80, то написать 
> вместо него в конфигурации listen <ip>:80 и сделать reload - 
> нельзя, nginx не сможет создать новые listen-сокеты для новой 
> конфигурации, так как они конфликтуют с уже открытыми 
> listen-сокетами старой конфигурации.  В error log'е, заданном на 
> глобальном уровне, будет при этом что-то вроде:
> 
> 2018/02/14 15:32:52 [notice] 1672#1672: signal 1 (SIGHUP) received
> from 1762, reconfiguring
> 2018/02/14 15:32:52 [notice] 1672#1672: reconfiguring
> 2018/02/14 15:32:52 [emerg] 1672#1672: bind() to 127.0.0.1:80 failed
> (98: Address already in use)
> 2018/02/14 15:32:52 [notice] 1672#1672: try again to bind() after
> 500ms
> 2018/02/14 15:32:52 [emerg] 1672#1672: bind() to 127.0.0.1:80 failed
> (98: Address already in use)
> 2018/02/14 15:32:52 [notice] 1672#1672: try again to bind() after
> 500ms
> 2018/02/14 15:32:52 [emerg] 1672#1672: bind() to 127.0.0.1:80 failed
> (98: Address already in use)
> 2018/02/14 15:32:52 [notice] 1672#1672: try again to bind() after
> 500ms
> 2018/02/14 15:32:52 [emerg] 1672#1672: bind() to 127.0.0.1:80 failed
> (98: Address already in use)
> 2018/02/14 15:32:52 [notice] 1672#1672: try again to bind() after
> 500ms
> 2018/02/14 15:32:52 [emerg] 1672#1672: bind() to 127.0.0.1:80 failed
> (98: Address already in use)
> 2018/02/14 15:32:52 [notice] 1672#1672: try again to bind() after
> 500ms
> 2018/02/14 15:32:52 [emerg] 1672#1672: still could not bind()
> 
> Соответственно nginx не сможет создать новую конфигурацию, и 
> продолжит работать со старой.
> 
> Если такое изменение в listen-сокетах действительно необходимо, то 
> следует сделать restart - то есть выключить nginx, и включить его 
> обратно.
> 
> -- 
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278548,278555#msg-278555


From mdounin на mdounin.ru  Wed Feb 14 14:02:43 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 14 Feb 2018 17:02:43 +0300
Subject: nginx restart AND listen ip:port
In-Reply-To: <8c5a138dbc4218e78933ddcad599c74a.NginxMailingListRussian@forum.nginx.org>
References: <20180214124045.GL24410@mdounin.ru>
 <8c5a138dbc4218e78933ddcad599c74a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180214140243.GO24410@mdounin.ru>

Hello!

On Wed, Feb 14, 2018 at 07:56:10AM -0500, imsystem wrote:

> restart|force-reload)
>         echo -n "Restarting $DESC: "
>         start-stop-daemon --stop --quiet --pidfile \
>                 /var/run/$NAME.pid --exec $DAEMON
>         sleep 1
>         start-stop-daemon --start --quiet --pidfile \
>                 /var/run/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS
>         echo "$NAME."
>         ;;
>   reload)
>       echo -n "Reloading $DESC configuration: "
>       start-stop-daemon --stop --signal HUP --quiet --pidfile
> /var/run/$NAME.pid \
>           --exec $DAEMON
>       echo "$NAME."
>       ;;
> 
> Ничего такого.
> 
> Спасибо подробный за ответ, но это явно не то, т.к. reload работал без каких
> либо ошибок, новая конфигурация подгружалась.

Значит разбирайтесь внимательно, что происходит при restart'е и 
почему он ломается.  Сам nginx при проблемах всегда пишет, в чём 
дело (и в лог, и в stderr), так что либо дело не в нём, а в 
init-скрипте, либо вы что-то упустили.  В частности, после того, 
как restart сломается - загляните в "systemctl status nginx" и в 
"journalctl -xe".

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Wed Feb 14 14:58:28 2018
From: nginx-forum на forum.nginx.org (imsystem)
Date: Wed, 14 Feb 2018 09:58:28 -0500
Subject: nginx restart AND listen ip:port
In-Reply-To: <20180214140243.GO24410@mdounin.ru>
References: <20180214140243.GO24410@mdounin.ru>
Message-ID: <e86835b8ae9b11ef1033866bd3343c31.NginxMailingListRussian@forum.nginx.org>

systemctl status nginx

● nginx.service - LSB: starts the nginx web server
   Loaded: loaded (/etc/init.d/nginx; generated; vendor preset: enabled)
  Drop-In: /etc/systemd/system/nginx.service.d
           └─limits.conf
   Active: failed (Result: exit-code) since Wed 2018-02-14 17:46:35 MSK; 5s
ago
     Docs: man:systemd-sysv-generator(8)
  Process: 8890 ExecStop=/etc/init.d/nginx stop (code=exited,
status=0/SUCCESS)
  Process: 8892 ExecStart=/etc/init.d/nginx start (code=exited,
status=1/FAILURE)
    Tasks: 0 (limit: 9830)
   CGroup: /system.slice/nginx.service

Feb 14 17:46:35 gateway systemd[1]: Stopped LSB: starts the nginx web
server.
Feb 14 17:46:35 gateway systemd[1]: Starting LSB: starts the nginx web
server...
Feb 14 17:46:35 gateway nginx[8892]: Starting nginx:
Feb 14 17:46:35 gateway systemd[1]: nginx.service: Control process exited,
code=exited status=1
Feb 14 17:46:35 gateway systemd[1]: Failed to start LSB: starts the nginx
web server.
Feb 14 17:46:35 gateway systemd[1]: nginx.service: Unit entered failed
state.
Feb 14 17:46:35 gateway systemd[1]: nginx.service: Failed with result
'exit-code'.
_____________
journalctl -xe

-- Unit nginx.service has finished shutting down.
Feb 14 17:49:14 gateway systemd[1]: Starting LSB: starts the nginx web
server...
-- Subject: Unit nginx.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit nginx.service has begun starting up.
Feb 14 17:49:14 gateway nginx[9378]: Starting nginx:
Feb 14 17:49:14 gateway systemd[1]: nginx.service: Control process exited,
code=exited status=1
Feb 14 17:49:14 gateway systemd[1]: Failed to start LSB: starts the nginx
web server.
-- Subject: Unit nginx.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit nginx.service has failed.
--
-- The result is failed.
Feb 14 17:49:14 gateway systemd[1]: nginx.service: Unit entered failed
state.
Feb 14 17:49:14 gateway systemd[1]: nginx.service: Failed with result
'exit-code'.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278548,278559#msg-278559


From mdounin на mdounin.ru  Wed Feb 14 15:16:44 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 14 Feb 2018 18:16:44 +0300
Subject: nginx restart AND listen ip:port
In-Reply-To: <e86835b8ae9b11ef1033866bd3343c31.NginxMailingListRussian@forum.nginx.org>
References: <20180214140243.GO24410@mdounin.ru>
 <e86835b8ae9b11ef1033866bd3343c31.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180214151644.GP24410@mdounin.ru>

Hello!

On Wed, Feb 14, 2018 at 09:58:28AM -0500, imsystem wrote:

> systemctl status nginx
> 
> ● nginx.service - LSB: starts the nginx web server
>    Loaded: loaded (/etc/init.d/nginx; generated; vendor preset: enabled)
>   Drop-In: /etc/systemd/system/nginx.service.d
>            └─limits.conf
>    Active: failed (Result: exit-code) since Wed 2018-02-14 17:46:35 MSK; 5s
> ago
>      Docs: man:systemd-sysv-generator(8)
>   Process: 8890 ExecStop=/etc/init.d/nginx stop (code=exited,
> status=0/SUCCESS)
>   Process: 8892 ExecStart=/etc/init.d/nginx start (code=exited,
> status=1/FAILURE)
>     Tasks: 0 (limit: 9830)
>    CGroup: /system.slice/nginx.service
> 
> Feb 14 17:46:35 gateway systemd[1]: Stopped LSB: starts the nginx web
> server.
> Feb 14 17:46:35 gateway systemd[1]: Starting LSB: starts the nginx web
> server...
> Feb 14 17:46:35 gateway nginx[8892]: Starting nginx:
> Feb 14 17:46:35 gateway systemd[1]: nginx.service: Control process exited,
> code=exited status=1

Судя по всему, init-скрипт после слов "Starting nginx:" ничего 
более не пытался вывести, и при этом завершился с ошибкой.  Куда 
он при этом потерял вывод самого nginx'а, и был ли он вообще - 
надо разбираться собственно в init-скрипте.  Ищите там.

Отдельно отмечу, что тут хорошо видно, что секция "restart" в 
init-скрипте никак не используется.  Для перезапуска systemd 
сначала вызывает init-скрипт с параметром stop, а затем с 
параметром start.  Это, в частности, с высокой вероятностью 
приведёт к проблемам, если init-скрипт не дожидается собственно 
завершения nginx'а, а просто отсылает сигнал и выходит.

[...]

-- 
Maxim Dounin
http://mdounin.ru/

From coddoc на mail.ru  Wed Feb 14 15:28:08 2018
From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=)
Date: Wed, 14 Feb 2018 18:28:08 +0300
Subject: nginx restart AND listen ip:port
In-Reply-To: <1ce27fbb9e4a9d9a6acb3859746c407d.NginxMailingListRussian@forum.nginx.org>
References: <1518605733.615022725@f25.i.mail.ru>
 <1ce27fbb9e4a9d9a6acb3859746c407d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1518622088.835107121@f366.i.mail.ru>

Да, сопоставима. Просто вы об этом ничего не сказали.
Насчет опции -s и прочих можете посмотреть nginx -h
Будет что-то типа:
nginx version: nginx/1.13.8
Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives]

Options:
  -?,-h         : this help
  -v            : show version and exit
  -V            : show version and configure options then exit
  -t            : test configuration and exit
  -T            : test configuration, dump it and exit
  -q            : suppress non-error messages during configuration testing
  -s signal     : send signal to a master process: stop, quit, reopen, reload
  -p prefix     : set prefix path (default: /etc/nginx/)
  -c filename   : set configuration file (default: /etc/nginx/nginx.conf)
  -g directives : set global directives out of configuration file

По остальному вам Максим ответил.

А почему не проксирует - я вам уже сказал. С такой скудной информацией, что вы даете, нужен хрустальный шар. Не нужно вываливать весь конфиг, достаточно частей, относящихся к теме. Причин на самом деле может быть много. Начиная от правил FW и заканчивая локейшеном, в который падает запрос.


>Среда, 14 февраля 2018, 15:51 +03:00 от "imsystem" <nginx-forum на forum.nginx.org>:
>
>> Вам обязательно 'service nginx restart'?
>> 'nginx -s reload' пробовали?
>Нет, не обязательно.
>Нет, не пробовал, считал её сопоставимой команде service nginx reload, а она
>работает.
>Меня сам факт смущает.
>
>> Насчет версии 1.12.1. В stable ветке доступна 1.12.2. Может там уже
>> пофиксили?
>Может и пофиксили.
>
>> >> Два интерфейса внешний и локальный. Везде ip - внешний ip.
>> >> Проксирование идёт по локалке.
>> >> Если принудительно не указывать ip в listen, то не проксируется.
>> Потрудитесь четко формулировать вопрос.
>> Что и куда вы проксируете? nginx на nginx? 80-й порт на 443-й? Бэкенд
>> где находится? На том же сервере или на другом?
>> ip  в конфиге внешние?
>С nginx на IIS, сервера разные, 80 порт перенаправляется на 443 (http ->
>https).
>ip которые слушает nginx внешние, проксирует соответственно на локальный ip
>IIS потоо https прколу.
>
>
>> >Среда, 14 февраля 2018, 13:10 +03:00 от "imsystem"
>> < nginx-forum на forum.nginx.org >:
>> >
>> >И совсем забыл.
>> >
>> >nginx -V
>> >nginx version: nginx/1.12.1
>> >built by gcc 6.3.0 20170516 (Debian 6.3.0-18)
>> >built with OpenSSL 1.1.1-dev  xx XXX xxxx
>> >TLS SNI support enabled
>> >configure arguments: --prefix=/usr/local/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
>> >--user=www-data --group=www-data --with-threads --with-file-aio
>> >--with-http_ssl_module --with-openssl=/home/sysadmin/src/openssl
>> >--with-http_v2_module --with-http_realip_module
>> --with-http_addition_module
>> >--with-http_xslt_module --with-http_image_filter_module
>> >--with-http_geoip_module --with-http_sub_module
>> --with-http_dav_module
>> >--with-http_flv_module --with-http_mp4_module
>> --with-http_gunzip_module
>> >--with-http_gzip_static_module --with-http_auth_request_module
>> >--with-http_random_index_module --with-http_secure_link_module
>> >--with-http_degradation_module --with-http_slice_module
>> >--with-http_stub_status_module --with-stream --with-stream_ssl_module
>> >
>> >uname -a
>> >Linux gateway 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1
>> (2017-12-23)
>> >x86_64 GNU/Linux
>> >
>> >Posted at Nginx Forum: 
>>  https://forum.nginx.org/read.php?21,278548,278550#msg-278550
>> >
>> >_______________________________________________
>> >nginx-ru mailing list
>> > nginx-ru на nginx.org
>> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> 
>> 
>> --
>> _______________________________________________
>> nginx-ru mailing list
>>  nginx-ru на nginx.org
>>  http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>Posted at Nginx Forum:  https://forum.nginx.org/read.php?21,278551,278554#msg-278554
>
>_______________________________________________
>nginx-ru mailing list
>nginx-ru на nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


--
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180214/5ba0ac3c/attachment.html>

From nginx-forum на forum.nginx.org  Wed Feb 14 16:08:42 2018
From: nginx-forum на forum.nginx.org (imsystem)
Date: Wed, 14 Feb 2018 11:08:42 -0500
Subject: nginx restart AND listen ip:port
In-Reply-To: <20180214151644.GP24410@mdounin.ru>
References: <20180214151644.GP24410@mdounin.ru>
Message-ID: <fde616ab5fe12c3034cb236ea6bd2f0d.NginxMailingListRussian@forum.nginx.org>

Спасибо ещё раз, посмотрю примеры init конфигов, насколько мне известно он
дефолтный.
Но, вы забыли изначальную причину данной "проблемы", в одном случае
конфигурации listen, init скрипт срабатывает как надо, а во втором что-то
идёт не так.

Maxim Dounin Wrote:
-------------------------------------------------------
> Hello!
> 
> On Wed, Feb 14, 2018 at 09:58:28AM -0500, imsystem wrote:
> 
> > systemctl status nginx
> > 
> > ● nginx.service - LSB: starts the nginx web server
> >    Loaded: loaded (/etc/init.d/nginx; generated; vendor preset:
> enabled)
> >   Drop-In: /etc/systemd/system/nginx.service.d
> >            └─limits.conf
> >    Active: failed (Result: exit-code) since Wed 2018-02-14 17:46:35
> MSK; 5s
> > ago
> >      Docs: man:systemd-sysv-generator(8)
> >   Process: 8890 ExecStop=/etc/init.d/nginx stop (code=exited,
> > status=0/SUCCESS)
> >   Process: 8892 ExecStart=/etc/init.d/nginx start (code=exited,
> > status=1/FAILURE)
> >     Tasks: 0 (limit: 9830)
> >    CGroup: /system.slice/nginx.service
> > 
> > Feb 14 17:46:35 gateway systemd[1]: Stopped LSB: starts the nginx
> web
> > server.
> > Feb 14 17:46:35 gateway systemd[1]: Starting LSB: starts the nginx
> web
> > server...
> > Feb 14 17:46:35 gateway nginx[8892]: Starting nginx:
> > Feb 14 17:46:35 gateway systemd[1]: nginx.service: Control process
> exited,
> > code=exited status=1
> 
> Судя по всему, init-скрипт после слов "Starting nginx:" ничего 
> более не пытался вывести, и при этом завершился с ошибкой.  Куда 
> он при этом потерял вывод самого nginx'а, и был ли он вообще - 
> надо разбираться собственно в init-скрипте.  Ищите там.
> 
> Отдельно отмечу, что тут хорошо видно, что секция "restart" в 
> init-скрипте никак не используется.  Для перезапуска systemd 
> сначала вызывает init-скрипт с параметром stop, а затем с 
> параметром start.  Это, в частности, с высокой вероятностью 
> приведёт к проблемам, если init-скрипт не дожидается собственно 
> завершения nginx'а, а просто отсылает сигнал и выходит.
> 
> [...]
> 
> -- 
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278548,278567#msg-278567


From nginx-forum на forum.nginx.org  Wed Feb 14 16:13:24 2018
From: nginx-forum на forum.nginx.org (imsystem)
Date: Wed, 14 Feb 2018 11:13:24 -0500
Subject: nginx restart AND listen ip:port
In-Reply-To: <1518622088.835107121@f366.i.mail.ru>
References: <1518622088.835107121@f366.i.mail.ru>
Message-ID: <d8a25890500c4e2f06927256a8dda0ca.NginxMailingListRussian@forum.nginx.org>

Всё проксирует, при записи
server {
listen external_IP_nginx:443;
location / { proxy_pass https://local_IP_IIS; }
}

При этой записи не проксирует, выдавало, насколько помню, 403
server {
listen 443;
location / { proxy_pass https://backend; }
}

А прочие команды я и в документации видел, просто через service/systemctl
как-то привычнее.

CoDDoC Wrote:
-------------------------------------------------------
> Да, сопоставима. Просто вы об этом ничего не сказали.
> Насчет опции -s и прочих можете посмотреть nginx -h
> Будет что-то типа:
> nginx version: nginx/1.13.8
> Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g
> directives]
> 
> Options:
>   -?,-h         : this help
>   -v            : show version and exit
>   -V            : show version and configure options then exit
>   -t            : test configuration and exit
>   -T            : test configuration, dump it and exit
>   -q            : suppress non-error messages during configuration
> testing
>   -s signal     : send signal to a master process: stop, quit, reopen,
> reload
>   -p prefix     : set prefix path (default: /etc/nginx/)
>   -c filename   : set configuration file (default:
> /etc/nginx/nginx.conf)
>   -g directives : set global directives out of configuration file
> 
> По остальному вам Максим ответил.
> 
> А почему не проксирует - я вам уже сказал. С такой скудной
> информацией, что вы даете, нужен хрустальный шар. Не нужно вываливать
> весь конфиг, достаточно частей, относящихся к теме. Причин на самом
> деле может быть много. Начиная от правил FW и заканчивая локейшеном, в
> который падает запрос.
> 
> 
> >Среда, 14 февраля 2018, 15:51 +03:00 от "imsystem"
> <nginx-forum на forum.nginx.org>:
> >
> >> Вам обязательно 'service nginx restart'?
> >> 'nginx -s reload' пробовали?
> >Нет, не обязательно.
> >Нет, не пробовал, считал её сопоставимой команде service nginx
> reload, а она
> >работает.
> >Меня сам факт смущает.
> >
> >> Насчет версии 1.12.1. В stable ветке доступна 1.12.2. Может там уже
> >> пофиксили?
> >Может и пофиксили.
> >
> >> >> Два интерфейса внешний и локальный. Везде ip - внешний ip.
> >> >> Проксирование идёт по локалке.
> >> >> Если принудительно не указывать ip в listen, то не проксируется.
> >> Потрудитесь четко формулировать вопрос.
> >> Что и куда вы проксируете? nginx на nginx? 80-й порт на 443-й?
> Бэкенд
> >> где находится? На том же сервере или на другом?
> >> ip  в конфиге внешние?
> >С nginx на IIS, сервера разные, 80 порт перенаправляется на 443 (http
> ->
> >https).
> >ip которые слушает nginx внешние, проксирует соответственно на
> локальный ip
> >IIS потоо https прколу.
> >
> >
> >> >Среда, 14 февраля 2018, 13:10 +03:00 от "imsystem"
> >> < nginx-forum на forum.nginx.org >:
> >> >
> >> >И совсем забыл.
> >> >
> >> >nginx -V
> >> >nginx version: nginx/1.12.1
> >> >built by gcc 6.3.0 20170516 (Debian 6.3.0-18)
> >> >built with OpenSSL 1.1.1-dev  xx XXX xxxx
> >> >TLS SNI support enabled
> >> >configure arguments: --prefix=/usr/local/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
> >> >--user=www-data --group=www-data --with-threads --with-file-aio
> >> >--with-http_ssl_module --with-openssl=/home/sysadmin/src/openssl
> >> >--with-http_v2_module --with-http_realip_module
> >> --with-http_addition_module
> >> >--with-http_xslt_module --with-http_image_filter_module
> >> >--with-http_geoip_module --with-http_sub_module
> >> --with-http_dav_module
> >> >--with-http_flv_module --with-http_mp4_module
> >> --with-http_gunzip_module
> >> >--with-http_gzip_static_module --with-http_auth_request_module
> >> >--with-http_random_index_module --with-http_secure_link_module
> >> >--with-http_degradation_module --with-http_slice_module
> >> >--with-http_stub_status_module --with-stream
> --with-stream_ssl_module
> >> >
> >> >uname -a
> >> >Linux gateway 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1
> >> (2017-12-23)
> >> >x86_64 GNU/Linux
> >> >
> >> >Posted at Nginx Forum: 
> >>  https://forum.nginx.org/read.php?21,278548,278550#msg-278550
> >> >
> >> >_______________________________________________
> >> >nginx-ru mailing list
> >> > nginx-ru на nginx.org
> >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >> 
> >> 
> >> --
> >> _______________________________________________
> >> nginx-ru mailing list
> >>  nginx-ru на nginx.org
> >>  http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> >Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?21,278551,278554#msg-278554
> >
> >_______________________________________________
> >nginx-ru mailing list
> >nginx-ru на nginx.org
> >http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> 
> --
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278551,278568#msg-278568


From nginx-forum на forum.nginx.org  Wed Feb 14 16:14:06 2018
From: nginx-forum на forum.nginx.org (imsystem)
Date: Wed, 14 Feb 2018 11:14:06 -0500
Subject: nginx restart AND listen ip:port
In-Reply-To: <d8a25890500c4e2f06927256a8dda0ca.NginxMailingListRussian@forum.nginx.org>
References: <1518622088.835107121@f366.i.mail.ru>
 <d8a25890500c4e2f06927256a8dda0ca.NginxMailingListRussian@forum.nginx.org>
Message-ID: <022524c28f9ad5c60a8a1b2792fc15b1.NginxMailingListRussian@forum.nginx.org>

Во второй записи backend = local_IP_IIS

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278551,278569#msg-278569


From mdounin на mdounin.ru  Wed Feb 14 16:49:14 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 14 Feb 2018 19:49:14 +0300
Subject: nginx restart AND listen ip:port
In-Reply-To: <fde616ab5fe12c3034cb236ea6bd2f0d.NginxMailingListRussian@forum.nginx.org>
References: <20180214151644.GP24410@mdounin.ru>
 <fde616ab5fe12c3034cb236ea6bd2f0d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180214164914.GQ24410@mdounin.ru>

Hello!

On Wed, Feb 14, 2018 at 11:08:42AM -0500, imsystem wrote:

> Спасибо ещё раз, посмотрю примеры init конфигов, насколько мне известно он
> дефолтный.

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

> Но, вы забыли изначальную причину данной "проблемы", в одном случае
> конфигурации listen, init скрипт срабатывает как надо, а во втором что-то
> идёт не так.

Тут причин может быть масса, начиная от "просто повезло", и 
заканчивая "nginx ругался на ошибку, но init-скрипт всё спрятал".   
Для начала попробуйте добавить к start-stop-daemon параметр "--no-close".

-- 
Maxim Dounin
http://mdounin.ru/

From nginx на mva.name  Wed Feb 14 17:28:56 2018
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 15 Feb 2018 00:28:56 +0700
Subject: =?UTF-8?B?0JLQvtC30LzQvtC20L3QvtGB0YLRjCDQv9GA0L7QstC10YDQuNGC0Ywg0YPRgdC/?=
 =?UTF-8?B?0LXRiNC90L7RgdGC0YwgYXV0aF9iYXNpYyDQsNCy0YLQvtGA0LjQt9Cw0YY=?=
 =?UTF-8?B?0LjQuA==?=
Message-ID: <3049459.s5snxBelkH@note>

Всем привет.
У меня тут возникла необходимость в проверке успешности auth_basic авторизации 
(каковая, например, есть для client_certificate ($ssl_client_verify)).

У меня была идея сделать (средствами NginX) basic-авторизацию (в одном и том 
же локейшне) необязательной, но принципиально применимой. И в случае 
предоставления логина-пароля — обрабатывать этот кейс (а точнее - использовать 
содержимое $remote_user для определённых целей).

Логичным решением мне показалось использовать `satisfy any`+`allow all`
+`auth_basic`.

Однако в данном случае при предоставлении неправильного пароля в $remote_user 
всё равно оказывается переданное имя пользователя. Что является немного не тем 
результатом, на который я рассчитывал, но с этим можно было бы смириться (в 
конце концов, никто и не говорил, что директива содержит имя только в случае 
успешной авторизации), если бы был способ проверить успешность авторизации. А 
такового я не нашёл (возможно, плохо искал).

В общем, подскажите пожалуйста:

1) есть ли способ узнать, была ли авторизация успешной? Может, я и в самом 
деле слепой и не вижу в документации того, что там есть?

2) может быть, есть иной способ добиться того, что я хотел кроме `satisfy any`
+`allow all`?

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

From mdounin на mdounin.ru  Wed Feb 14 18:22:53 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 14 Feb 2018 21:22:53 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L7RgdGC0Ywg0L/RgNC+0LLQtdGA0LjRgtGMINGD?=
 =?UTF-8?B?0YHQv9C10YjQvdC+0YHRgtGMIGF1dGhfYmFzaWMg0LDQstGC0L7RgNC40Lc=?=
 =?UTF-8?B?0LDRhtC40Lg=?=
In-Reply-To: <3049459.s5snxBelkH@note>
References: <3049459.s5snxBelkH@note>
Message-ID: <20180214182253.GR24410@mdounin.ru>

Hello!

On Thu, Feb 15, 2018 at 12:28:56AM +0700, Vadim A. Misbakh-Soloviov wrote:

> Всем привет.
> У меня тут возникла необходимость в проверке успешности auth_basic авторизации 
> (каковая, например, есть для client_certificate ($ssl_client_verify)).
> 
> У меня была идея сделать (средствами NginX) basic-авторизацию (в одном и том 
> же локейшне) необязательной, но принципиально применимой. И в случае 
> предоставления логина-пароля — обрабатывать этот кейс (а точнее - использовать 
> содержимое $remote_user для определённых целей).
> 
> Логичным решением мне показалось использовать `satisfy any`+`allow all`
> +`auth_basic`.
> 
> Однако в данном случае при предоставлении неправильного пароля в $remote_user 
> всё равно оказывается переданное имя пользователя. Что является немного не тем 
> результатом, на который я рассчитывал, но с этим можно было бы смириться (в 
> конце концов, никто и не говорил, что директива содержит имя только в случае 
> успешной авторизации), если бы был способ проверить успешность авторизации. А 
> такового я не нашёл (возможно, плохо искал).
> 
> В общем, подскажите пожалуйста:
> 
> 1) есть ли способ узнать, была ли авторизация успешной? Может, я и в самом 
> деле слепой и не вижу в документации того, что там есть?

Если в конфиге сказано "satisfy any; allow all; auth_basic ...", 
то проверки паролей в соответствии с auth_basic вообще не будут 
выполняться.  Операция проверки IP-адреса дешевле, и делается в 
первую очередь.  Если она говорит, что доступ следует 
предоставить, то доступ предоставляется без каких-либо дальнейших 
проверок.

Соответственно вопрос, была ли аутентификация успешной, в такой 
конфигурации не имеет ответа, так как самой аутентификации - не 
было.

Кроме того, сама http-аутентификация предполагает, что браузер 
отправляет заголовок Authorization в ответ на 401 c 
WWW-Authenticate, и непонятно, откуда она вообще возьмётся в такой 
конфигурации.

> 2) может быть, есть иной способ добиться того, что я хотел кроме `satisfy any`
> +`allow all`?

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

Тут можно либо реализовать любую собственную логику с помощью 
имеющегося интерфейса, либо же схитрить, и воспользоваться тем, 
что auth_request выполняется после auth_basic (что, впрочем, 
implementation detail, так что caveat emptor applies).  В 
результате в конфигурации вида


    location / {
        satisfy any;
        auth_basic secure;
        auth_basic_user_file /tmp/foo;
        auth_request /auth;
        add_header X-Auth $remote_user:$auth_failed;
    }

    location /auth {
        set $auth_failed 1;
        return 204;
    }

всегда будет делаться проверка по auth_basic, и в случае, если 
проверка по auth_basic не была успешна по какой-либо причине - 
переменная $auth_failed будет установлена в 1.

-- 
Maxim Dounin
http://mdounin.ru/

From coddoc на mail.ru  Thu Feb 15 05:49:11 2018
From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=)
Date: Thu, 15 Feb 2018 08:49:11 +0300
Subject: nginx restart AND listen ip:port
In-Reply-To: <d8a25890500c4e2f06927256a8dda0ca.NginxMailingListRussian@forum.nginx.org>
References: <1518622088.835107121@f366.i.mail.ru>
 <d8a25890500c4e2f06927256a8dda0ca.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1518673751.245739303@f489.i.mail.ru>

Третий и последний раз повторяю, хотите, чтобы вам помогли - обозначайте ВСЕ части конфига, отвечающие за проблему. То, что по вашему мнению должно работать, но не работает.
Вы видите разницу в ваших локейшенах?
Апстрим backend у вас как-то определен?
В error.log, случаем, не проскакивает что-то типа 'host not found in upstream ...' ?
И, кстати, все-же рекомендую перечитывать конфиг как 'nginx -s reload'. Так вы сразу увидите ошибку. 'service nginx reload' вам ответит ОК, а ошибку скинет в лог.


>Среда, 14 февраля 2018, 19:13 +03:00 от "imsystem" <nginx-forum на forum.nginx.org>:
>
>Всё проксирует, при записи
>server {
>listen external_IP_nginx:443;
>location / { proxy_pass https://local_IP_IIS; }
>}
>
>При этой записи не проксирует, выдавало, насколько помню, 403
>server {
>listen 443;
>location / { proxy_pass https://backend; }
>}
>
>А прочие команды я и в документации видел, просто через service/systemctl
>как-то привычнее.
>
>CoDDoC Wrote:
>-------------------------------------------------------
>> Да, сопоставима. Просто вы об этом ничего не сказали.
>> Насчет опции -s и прочих можете посмотреть nginx -h
>> Будет что-то типа:
>> nginx version: nginx/1.13.8
>> Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g
>> directives]
>> 
>> Options:
>>   -?,-h         : this help
>>   -v            : show version and exit
>>   -V            : show version and configure options then exit
>>   -t            : test configuration and exit
>>   -T            : test configuration, dump it and exit
>>   -q            : suppress non-error messages during configuration
>> testing
>>   -s signal     : send signal to a master process: stop, quit, reopen,
>> reload
>>   -p prefix     : set prefix path (default: /etc/nginx/)
>>   -c filename   : set configuration file (default:
>> /etc/nginx/nginx.conf)
>>   -g directives : set global directives out of configuration file
>> 
>> По остальному вам Максим ответил.
>> 
>> А почему не проксирует - я вам уже сказал. С такой скудной
>> информацией, что вы даете, нужен хрустальный шар. Не нужно вываливать
>> весь конфиг, достаточно частей, относящихся к теме. Причин на самом
>> деле может быть много. Начиная от правил FW и заканчивая локейшеном, в
>> который падает запрос.
>> 
>> 
>> >Среда, 14 февраля 2018, 15:51 +03:00 от "imsystem"
>> < nginx-forum на forum.nginx.org >:
>> >
>> >> Вам обязательно 'service nginx restart'?
>> >> 'nginx -s reload' пробовали?
>> >Нет, не обязательно.
>> >Нет, не пробовал, считал её сопоставимой команде service nginx
>> reload, а она
>> >работает.
>> >Меня сам факт смущает.
>> >
>> >> Насчет версии 1.12.1. В stable ветке доступна 1.12.2. Может там уже
>> >> пофиксили?
>> >Может и пофиксили.
>> >
>> >> >> Два интерфейса внешний и локальный. Везде ip - внешний ip.
>> >> >> Проксирование идёт по локалке.
>> >> >> Если принудительно не указывать ip в listen, то не проксируется.
>> >> Потрудитесь четко формулировать вопрос.
>> >> Что и куда вы проксируете? nginx на nginx? 80-й порт на 443-й?
>> Бэкенд
>> >> где находится? На том же сервере или на другом?
>> >> ip  в конфиге внешние?
>> >С nginx на IIS, сервера разные, 80 порт перенаправляется на 443 (http
>> ->
>> >https).
>> >ip которые слушает nginx внешние, проксирует соответственно на
>> локальный ip
>> >IIS потоо https прколу.
>> >
>> >
>> >> >Среда, 14 февраля 2018, 13:10 +03:00 от "imsystem"
>> >> <  nginx-forum на forum.nginx.org >:
>> >> >
>> >> >И совсем забыл.
>> >> >
>> >> >nginx -V
>> >> >nginx version: nginx/1.12.1
>> >> >built by gcc 6.3.0 20170516 (Debian 6.3.0-18)
>> >> >built with OpenSSL 1.1.1-dev  xx XXX xxxx
>> >> >TLS SNI support enabled
>> >> >configure arguments: --prefix=/usr/local/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
>> >> >--user=www-data --group=www-data --with-threads --with-file-aio
>> >> >--with-http_ssl_module --with-openssl=/home/sysadmin/src/openssl
>> >> >--with-http_v2_module --with-http_realip_module
>> >> --with-http_addition_module
>> >> >--with-http_xslt_module --with-http_image_filter_module
>> >> >--with-http_geoip_module --with-http_sub_module
>> >> --with-http_dav_module
>> >> >--with-http_flv_module --with-http_mp4_module
>> >> --with-http_gunzip_module
>> >> >--with-http_gzip_static_module --with-http_auth_request_module
>> >> >--with-http_random_index_module --with-http_secure_link_module
>> >> >--with-http_degradation_module --with-http_slice_module
>> >> >--with-http_stub_status_module --with-stream
>> --with-stream_ssl_module
>> >> >
>> >> >uname -a
>> >> >Linux gateway 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1
>> >> (2017-12-23)
>> >> >x86_64 GNU/Linux
>> >> >
>> >> >Posted at Nginx Forum: 
>> >>  https://forum.nginx.org/read.php?21,278548,278550#msg-278550
>> >> >
>> >> >_______________________________________________
>> >> >nginx-ru mailing list
>> >> >  nginx-ru на nginx.org
>> >> >  http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >> 
>> >> 
>> >> --
>> >> _______________________________________________
>> >> nginx-ru mailing list
>> >>  nginx-ru на nginx.org
>> >>  http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >
>> >Posted at Nginx Forum: 
>>  https://forum.nginx.org/read.php?21,278551,278554#msg-278554
>> >
>> >_______________________________________________
>> >nginx-ru mailing list
>> > nginx-ru на nginx.org
>> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> 
>> 
>> --
>> _______________________________________________
>> nginx-ru mailing list
>>  nginx-ru на nginx.org
>>  http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>Posted at Nginx Forum:  https://forum.nginx.org/read.php?21,278551,278568#msg-278568
>
>_______________________________________________
>nginx-ru mailing list
>nginx-ru на nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


--
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180215/6c9a9227/attachment-0001.html>

From nginx-forum на forum.nginx.org  Thu Feb 15 14:01:17 2018
From: nginx-forum на forum.nginx.org (digger)
Date: Thu, 15 Feb 2018 09:01:17 -0500
Subject: =?UTF-8?B?0JrQsNC6INGD0LTQsNC70LjRgtGMINC40LcgVVJMINGB0LDQudGC0LAg0LfQsNCy?=
 =?UTF-8?B?0LXRgNGI0LDRjtGJ0LjQuSDRgdC40LzQstC+0LsgIyA/?=
Message-ID: <a0147289bc7eceb9136255e4a46db144.NginxMailingListRussian@forum.nginx.org>

Подскажите, пожалуйста, как удалить из URL сайта завершающий символ решетки
#.
Точка успешно удаляется следующией конструкцией:

 if ($http_host ~ "\.$" ){
     rewrite ^(.*) $scheme://$host$1 permanent;
 }		

Попытка удалить символ # успехом не увенчалась:

if ($http_host ~ "\#$" ){
     rewrite ^(.*) $scheme://$host$1 permanent;
}

Так тоже не сработало:

if ($http_host ~ "#$" ){
     rewrite ^(.*) $scheme://$host$1 permanent;
}

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


From nefer05 на gmail.com  Thu Feb 15 14:05:03 2018
From: nefer05 на gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=)
Date: Thu, 15 Feb 2018 17:05:03 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCDQuNC3IFVSTCDRgdCw0LnRgtCwINC3?=
 =?UTF-8?B?0LDQstC10YDRiNCw0Y7RidC40Lkg0YHQuNC80LLQvtC7ICMgPw==?=
In-Reply-To: <a0147289bc7eceb9136255e4a46db144.NginxMailingListRussian@forum.nginx.org>
References: <a0147289bc7eceb9136255e4a46db144.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAE-Urwi-htt6eyYj+O89ykCsfy4vCWUtxhnRcMmsDm+BLW4jUg@mail.gmail.com>

Диез остаеется у браузера, серверу он не передается. Соответственно,
пытаться его удалить на сервере немного... странно

2018-02-15 17:01 GMT+03:00 digger <nginx-forum на forum.nginx.org>:

> Подскажите, пожалуйста, как удалить из URL сайта завершающий символ решетки
> #.
> Точка успешно удаляется следующией конструкцией:
>
>  if ($http_host ~ "\.$" ){
>      rewrite ^(.*) $scheme://$host$1 permanent;
>  }
>
> Попытка удалить символ # успехом не увенчалась:
>
> if ($http_host ~ "\#$" ){
>      rewrite ^(.*) $scheme://$host$1 permanent;
> }
>
> Так тоже не сработало:
>
> if ($http_host ~ "#$" ){
>      rewrite ^(.*) $scheme://$host$1 permanent;
> }
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,278596,278596#msg-278596
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180215/922899d1/attachment.html>

From nginx-forum на forum.nginx.org  Thu Feb 15 15:02:13 2018
From: nginx-forum на forum.nginx.org (digger)
Date: Thu, 15 Feb 2018 10:02:13 -0500
Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LDQu9C40YLRjCDQuNC3IFVSTCDRgdCw0LnRgtCwINC3?=
 =?UTF-8?B?0LDQstC10YDRiNCw0Y7RidC40Lkg0YHQuNC80LLQvtC7ICMgPw==?=
In-Reply-To: <CAE-Urwi-htt6eyYj+O89ykCsfy4vCWUtxhnRcMmsDm+BLW4jUg@mail.gmail.com>
References: <CAE-Urwi-htt6eyYj+O89ykCsfy4vCWUtxhnRcMmsDm+BLW4jUg@mail.gmail.com>
Message-ID: <56d65e6a892ee1494a1106f5fc94aa7c.NginxMailingListRussian@forum.nginx.org>

Спасибо!

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278596,278602#msg-278602


From nginx-forum на forum.nginx.org  Fri Feb 16 04:19:23 2018
From: nginx-forum на forum.nginx.org (Helper code)
Date: Thu, 15 Feb 2018 23:19:23 -0500
Subject: PID file
Message-ID: <9398ee36f50480649788e360ff9f96e2.NginxMailingListRussian@forum.nginx.org>

После установки чистой установки  Nginx/1.13.8 на Ubuntu 16.04.1 x64
наблюдаю в логе systemd строчку:

nginx.service: PID file /var/run/nginx.pid not readable (yet?) after start:
No such file or directory

при этом все работает. Почему возникает это сообщение и как это исправить?

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


From vovansystems на gmail.com  Fri Feb 16 10:11:28 2018
From: vovansystems на gmail.com (VovansystemS)
Date: Fri, 16 Feb 2018 13:11:28 +0300
Subject: PID file
In-Reply-To: <9398ee36f50480649788e360ff9f96e2.NginxMailingListRussian@forum.nginx.org>
References: <9398ee36f50480649788e360ff9f96e2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAAwq3jxAbzUHVVG_KjPMpDTXACCJVSo_3zxWAyXJTjucoFT-PQ@mail.gmail.com>

Добрый день,

читайте этот тред:
http://mailman.nginx.org/pipermail/nginx-ru/2017-November/060604.html
https://forum.nginx.org/read.php?21,277438

From kpoxa на kpoxa.net  Fri Feb 16 10:12:43 2018
From: kpoxa на kpoxa.net (kpoxa)
Date: Fri, 16 Feb 2018 13:12:43 +0300
Subject: =?UTF-8?B?0J3QtdC60L7RgNGA0LXQutGC0L3QsNGPINGA0LDQsdC+0YLQsCDQv9GA0Lgg0LI=?=
 =?UTF-8?B?0YvQstC10LTQtdC90LjQuCDRgdC10YDQstC10YDQsCDQuNC3INCw0L/RgdGC?=
 =?UTF-8?B?0YDQuNC80LAg0LfQsCB0aW1lb3V0?=
Message-ID: <CABL5twCv4Jy=xPYXMX-tEwQjY4TDEChZPmNQoOpi2fQ2gWod7g@mail.gmail.com>

Добрый день.

nginx version: nginx/1.12.2

Кслассическая схема:

nginx - apache (10 серверов) - mysql

В случае перегрузки базы данных апач отвечает медленно, что логично.
Перестаёт отвечать nginx'у.
И как следствие nginx выводит сервер с апачом из работы. Соответственно
сервер начинает то включаться в работу то выключаться.

Далее наблюдается следующая картина, которая у вызывает у меня вопрос, у
апачей куча детей в статусе R, т.е. reading request.

strace на процесс Апача примерно такой:

accept(

пришел syn пакет и апач его принял

read(

ждём HTTP запрос от nginx в течении 60+ секунд.




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


--
Рустам Нарманов.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180216/81e5ff4b/attachment.html>

From mdounin на mdounin.ru  Fri Feb 16 12:01:42 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 16 Feb 2018 15:01:42 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQutC+0YDRgNC10LrRgtC90LDRjyDRgNCw0LHQvtGC0LAg0L/RgNC4?=
 =?UTF-8?B?INCy0YvQstC10LTQtdC90LjQuCDRgdC10YDQstC10YDQsCDQuNC3INCw0L8=?=
 =?UTF-8?B?0YHRgtGA0LjQvNCwINC30LAgdGltZW91dA==?=
In-Reply-To: <CABL5twCv4Jy=xPYXMX-tEwQjY4TDEChZPmNQoOpi2fQ2gWod7g@mail.gmail.com>
References: <CABL5twCv4Jy=xPYXMX-tEwQjY4TDEChZPmNQoOpi2fQ2gWod7g@mail.gmail.com>
Message-ID: <20180216120142.GA24410@mdounin.ru>

Hello!

On Fri, Feb 16, 2018 at 01:12:43PM +0300, kpoxa wrote:

> Добрый день.
> 
> nginx version: nginx/1.12.2
> 
> Кслассическая схема:
> 
> nginx - apache (10 серверов) - mysql
> 
> В случае перегрузки базы данных апач отвечает медленно, что логично.
> Перестаёт отвечать nginx'у.
> И как следствие nginx выводит сервер с апачом из работы. Соответственно
> сервер начинает то включаться в работу то выключаться.
> 
> Далее наблюдается следующая картина, которая у вызывает у меня вопрос, у
> апачей куча детей в статусе R, т.е. reading request.
> 
> strace на процесс Апача примерно такой:
> 
> accept(
> 
> пришел syn пакет и апач его принял
> 
> read(
> 
> ждём HTTP запрос от nginx в течении 60+ секунд.
> 
> не знаю в какой момент, но nginx открывает соединения, возможно до вывода
> сервера из работы, а далее не отправляет на него запросы, как следствие
> дети Апача заняты ожиданием запросов и апач в итоге не отвечают нормально.

Попробуйте снять tcpdump (причём желательно - с двух сторон, 
nginx'а и backend'а), возможно станет понятнее, что тут 
происходит.

Ну и сразу стоит убедиться, что между nginx'ом и апачами нет 
какого-нибудь умного statefull firewall'а, а если вдруг есть - 
убрать или тщательно исследовать на предмет настроек и ошибок.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Sat Feb 17 09:31:21 2018
From: nginx-forum на forum.nginx.org (Helper code)
Date: Sat, 17 Feb 2018 04:31:21 -0500
Subject: PID file
In-Reply-To: <CAAwq3jxAbzUHVVG_KjPMpDTXACCJVSo_3zxWAyXJTjucoFT-PQ@mail.gmail.com>
References: <CAAwq3jxAbzUHVVG_KjPMpDTXACCJVSo_3zxWAyXJTjucoFT-PQ@mail.gmail.com>
Message-ID: <dad6de2f2671abb429ad218009fd353e.NginxMailingListRussian@forum.nginx.org>

Спасибо. Значит, если я правильно понял, можно игнорировать это
предупреждение.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278610,278631#msg-278631


From coddoc на mail.ru  Mon Feb 19 15:18:52 2018
From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=)
Date: Mon, 19 Feb 2018 18:18:52 +0300
Subject: =?UTF-8?B?0J4g0LfQsNCz0L7Qu9C+0LLQutC1IGNvbnRlbnQtdHlwZQ==?=
Message-ID: <1519053532.609467195@f335.i.mail.ru>

Доброе время суток!

Есть такой локейшен:
location ~ "^/img/" { internal; }

Естественно, прямой запрос 'GET /img/file.jpg' получает 404
Все хорошо, но нужно вместо стандартной nginx страницы отдать кастомную.
Можно решать разными способами, я решил попробовать через 'return 404 <text>' (минимум внутренних реврайтов/редиректов).

Получилось так (упрощенно):

error_page 404 = @err404;
location @err404 {
      return 404 '<!DOCTYPE html> <html> <body> <h1> <center> WTF ? </center> </h1> </body> </html>';
      add_header "Content-Type" "text/html; charset=UTF-8" always;
}

Оно работает, одно смущает: дублирование заголовка Content-Type: сперва 'image/jpeg', затем уже 'text/html; charset=UTF-8'
Браузер-то, ясное дело, возьмет по итогу второй заголовок. Но, может, есть какой-либо цивилизованный способ оставить один Content-Type без прикручивания костыля типа headers-more ?

proxy_hide_header не годится - нет проксирования. Отправлять все "не-пойми-какие" запросы на бэкенд - не вижу в этом  особого смысла.

Спасибо.
--
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180219/4c306844/attachment.html>

From mdounin на mdounin.ru  Mon Feb 19 16:25:55 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 19 Feb 2018 19:25:55 +0300
Subject: =?UTF-8?B?UmU6INCeINC30LDQs9C+0LvQvtCy0LrQtSBjb250ZW50LXR5cGU=?=
In-Reply-To: <1519053532.609467195@f335.i.mail.ru>
References: <1519053532.609467195@f335.i.mail.ru>
Message-ID: <20180219162555.GE24410@mdounin.ru>

Hello!

On Mon, Feb 19, 2018 at 06:18:52PM +0300, CoDDoC wrote:

> Доброе время суток!
> 
> Есть такой локейшен:
> location ~ "^/img/" { internal; }
> 
> Естественно, прямой запрос 'GET /img/file.jpg' получает 404
> Все хорошо, но нужно вместо стандартной nginx страницы отдать кастомную.
> Можно решать разными способами, я решил попробовать через 'return 404 <text>' (минимум внутренних реврайтов/редиректов).
> 
> Получилось так (упрощенно):
> 
> error_page 404 = @err404;
> location @err404 {
>       return 404 '<!DOCTYPE html> <html> <body> <h1> <center> WTF ? </center> </h1> </body> </html>';
>       add_header "Content-Type" "text/html; charset=UTF-8" always;
> }
> 
> Оно работает, одно смущает: дублирование заголовка Content-Type: сперва 'image/jpeg', затем уже 'text/html; charset=UTF-8'
> Браузер-то, ясное дело, возьмет по итогу второй заголовок. Но, может, есть какой-либо цивилизованный способ оставить один Content-Type без прикручивания костыля типа headers-more ?

Правильно - не пытаться прибить левый Content-Type гвоздями с 
помощью add_header, а задать его штатными средствами.  Например 
так:

    error_page 404 = /error404.html;
    location = /error404.html {
        charset utf-8;
        return 404 '<!DOCTYPE html> ...';
    }

Или, если по каким-то причинам очень хочется именно именованный 
location, то так:

    error_page 404 = @err404;
    location @err404 {
        types {}
        default_type text/html;
        charset utf-8;
        return 404 '<!DOCTYPE html> ...';
    }

-- 
Maxim Dounin
http://mdounin.ru/

From coddoc на mail.ru  Tue Feb 20 07:23:39 2018
From: coddoc на mail.ru (=?UTF-8?B?Q29ERG9D?=)
Date: Tue, 20 Feb 2018 10:23:39 +0300
Subject: =?UTF-8?B?UmVbMl06INCeINC30LDQs9C+0LvQvtCy0LrQtSBjb250ZW50LXR5cGU=?=
In-Reply-To: <20180219162555.GE24410@mdounin.ru>
References: <1519053532.609467195@f335.i.mail.ru>
 <20180219162555.GE24410@mdounin.ru>
Message-ID: <1519111419.71619875@f337.i.mail.ru>

Ааааа... голова дырявая. Забыл про types.
Спасибо.

>Понедельник, 19 февраля 2018, 19:26 +03:00 от Maxim Dounin <mdounin на mdounin.ru>:
>
>Hello!
>
>On Mon, Feb 19, 2018 at 06:18:52PM +0300, CoDDoC wrote:
>
>> Доброе время суток!
>> 
>> Есть такой локейшен:
>> location ~ "^/img/" { internal; }
>> 
>> Естественно, прямой запрос 'GET /img/file.jpg' получает 404
>> Все хорошо, но нужно вместо стандартной nginx страницы отдать кастомную.
>> Можно решать разными способами, я решил попробовать через 'return 404 <text>' (минимум внутренних реврайтов/редиректов).
>> 
>> Получилось так (упрощенно):
>> 
>> error_page 404 = @err404;
>> location @err404 {
>>       return 404 '<!DOCTYPE html> <html> <body> <h1> <center> WTF ? </center> </h1> </body> </html>';
>>       add_header "Content-Type" "text/html; charset=UTF-8" always;
>> }
>> 
>> Оно работает, одно смущает: дублирование заголовка Content-Type: сперва 'image/jpeg', затем уже 'text/html; charset=UTF-8'
>> Браузер-то, ясное дело, возьмет по итогу второй заголовок. Но, может, есть какой-либо цивилизованный способ оставить один Content-Type без прикручивания костыля типа headers-more ?
>
>Правильно - не пытаться прибить левый Content-Type гвоздями с 
>помощью add_header, а задать его штатными средствами.  Например 
>так:
>
>    error_page 404 = /error404.html;
>    location = /error404.html {
>        charset utf-8;
>        return 404 '<!DOCTYPE html> ...';
>    }
>
>Или, если по каким-то причинам очень хочется именно именованный 
>location, то так:
>
>    error_page 404 = @err404;
>    location @err404 {
>        types {}
>        default_type text/html;
>        charset utf-8;
>        return 404 '<!DOCTYPE html> ...';
>    }
>
>-- 
>Maxim Dounin
>http://mdounin.ru/
>_______________________________________________
>nginx-ru mailing list
>nginx-ru на nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


--
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180220/f04d0c1a/attachment.html>

From mdounin на mdounin.ru  Tue Feb 20 14:25:10 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 20 Feb 2018 17:25:10 +0300
Subject: nginx-1.13.9
Message-ID: <20180220142510.GM24410@mdounin.ru>

Изменения в nginx 1.13.9                                          20.02.2018

    *) Добавление: поддержка HTTP/2 server push; директивы http2_push и
       http2_push_preload.

    *) Исправление: при использовании кэша в логах могли появляться
       сообщения "header already sent"; ошибка появилась в 1.9.13.

    *) Исправление: при использовании директивы ssl_verify_client в рабочем
       процессе мог произойти segmentation fault, если в виртуальном сервере
       не был указан SSL-сертификат.

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

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


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

From nginx-forum на forum.nginx.org  Tue Feb 20 15:49:19 2018
From: nginx-forum на forum.nginx.org (VeeSot)
Date: Tue, 20 Feb 2018 10:49:19 -0500
Subject: =?UTF-8?B?0KHRgtGA0LDQvdC90L7QtSDQstC30LDQuNC80L7QtNC10LnRgdGC0LLQuNC1INGB?=
 =?UTF-8?B?IHVXU0dJ?=
Message-ID: <525ae300bba89acf4bfbc544a8a6d4c7.NginxMailingListRussian@forum.nginx.org>

Тут интересная сиутация второй день подряд, может подскажешь шо..

Есть  сервис, который отдает зип-файлики. Перва собирает ХМЛ-ку потом
заворачивает в зип и потом отдает.
Поверх сервиса работает uWSGI.Обеспечивает некую многопоточность.
Поверх всего этого добра - работает NGINX.

И в половине случаев - всё хорошо,файлики доходят до потребителя(в нашем
случае робот Яндекс.Маркета).
Но в другой половине случаев - uWSGI отдает файлик размером 2мб, на nginx -
уже отдает файлик размером в несколько КБ.И причем отдает не сразу, а через
некоторое время.

В логах uWSGI вижу что он передает то что ожидается, в логах NGINX - пустое
тело ответа.

Косяк где то на уровне их сопряжения... но хде?? Всё облазил, всё покрутил.
Сбоит без всякой очевидной причины. Может  отработать три запроса нормально,
а на четвертый вернуть пустоту.

Пример логирования с подключеным lua

5.45.235.119 - - [20/Feb/2018:20:40:20 +0500] "GET /my_url/1/ HTTP/1.1" 200
15941 "-" "YandexMarket/1.9-2 (compatible; http://market.yandex.ru)" 94.683
<"-" >""
5.45.235.73 - - [20/Feb/2018:20:42:11 +0500] "GET /my_url/2/ HTTP/1.1" 200
15938 "-" "YandexMarket/1.9-2 (compatible; http://market.yandex.ru)" 104.958
<"-" >""

в то же время в uWSGI

[pid: 6261|app: 0|req: 36/88] 5.45.235.119 () {36 vars in 467 bytes} [Tue
Feb 20 20:38:45 2018] GET /my_url/1/  => generated 1605423 bytes in 34680
msecs (HTTP/1.1 200) 5 headers in 308 bytes (8 switches on core 0)

[pid: 6261|app: 0|req: 37/90] 5.45.235.73 () {36 vars in 464 bytes} [Tue Feb
20 20:40:26 2018] GET  /my_url/2/  => generated 2030314 bytes in 44940 msecs
(HTTP/1.1 200) 5 headers in 311 bytes (10 switches on core 2)

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


From slw на zxy.spb.ru  Tue Feb 20 15:56:26 2018
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Tue, 20 Feb 2018 18:56:26 +0300
Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0LLQt9Cw0LjQvNC+0LTQtdC50YHRgtCy0Lg=?=
 =?UTF-8?B?0LUg0YEgdVdTR0k=?=
In-Reply-To: <525ae300bba89acf4bfbc544a8a6d4c7.NginxMailingListRussian@forum.nginx.org>
References: <525ae300bba89acf4bfbc544a8a6d4c7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180220155626.GK81872@zxy.spb.ru>

On Tue, Feb 20, 2018 at 10:49:19AM -0500, VeeSot wrote:

> Тут интересная сиутация второй день подряд, может подскажешь шо..
> 
> Есть  сервис, который отдает зип-файлики. Перва собирает ХМЛ-ку потом
> заворачивает в зип и потом отдает.
> Поверх сервиса работает uWSGI.Обеспечивает некую многопоточность.
> Поверх всего этого добра - работает NGINX.
> 
> И в половине случаев - всё хорошо,файлики доходят до потребителя(в нашем
> случае робот Яндекс.Маркета).
> Но в другой половине случаев - uWSGI отдает файлик размером 2мб, на nginx -
> уже отдает файлик размером в несколько КБ.И причем отдает не сразу, а через
> некоторое время.
> 
> В логах uWSGI вижу что он передает то что ожидается, в логах NGINX - пустое
> тело ответа.
> 
> Косяк где то на уровне их сопряжения... но хде?? Всё облазил, всё покрутил.
> Сбоит без всякой очевидной причины. Может  отработать три запроса нормально,
> а на четвертый вернуть пустоту.
> 
> Пример логирования с подключеным lua
> 
> 5.45.235.119 - - [20/Feb/2018:20:40:20 +0500] "GET /my_url/1/ HTTP/1.1" 200
> 15941 "-" "YandexMarket/1.9-2 (compatible; http://market.yandex.ru)" 94.683
> <"-" >""
> 5.45.235.73 - - [20/Feb/2018:20:42:11 +0500] "GET /my_url/2/ HTTP/1.1" 200
> 15938 "-" "YandexMarket/1.9-2 (compatible; http://market.yandex.ru)" 104.958
> <"-" >""
> 
> в то же время в uWSGI
> 
> [pid: 6261|app: 0|req: 36/88] 5.45.235.119 () {36 vars in 467 bytes} [Tue
> Feb 20 20:38:45 2018] GET /my_url/1/  => generated 1605423 bytes in 34680
> msecs (HTTP/1.1 200) 5 headers in 308 bytes (8 switches on core 0)
> 
> [pid: 6261|app: 0|req: 37/90] 5.45.235.73 () {36 vars in 464 bytes} [Tue Feb
> 20 20:40:26 2018] GET  /my_url/2/  => generated 2030314 bytes in 44940 msecs
> (HTTP/1.1 200) 5 headers in 311 bytes (10 switches on core 2)

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

From nginx-forum на forum.nginx.org  Tue Feb 20 15:56:59 2018
From: nginx-forum на forum.nginx.org (VeeSot)
Date: Tue, 20 Feb 2018 10:56:59 -0500
Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0LLQt9Cw0LjQvNC+0LTQtdC50YHRgtCy0Lg=?=
 =?UTF-8?B?0LUg0YEgdVdTR0k=?=
In-Reply-To: <525ae300bba89acf4bfbc544a8a6d4c7.NginxMailingListRussian@forum.nginx.org>
References: <525ae300bba89acf4bfbc544a8a6d4c7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <d60ce9b0c3cb9b33e90805e7b1a815c1.NginxMailingListRussian@forum.nginx.org>

Часть конфига что отвечает за работу с uWSGI

upstream yml {
    ip_hash;
    server unix:/tmp/imi3-yml.sock;
}


location /my_urll/ {
        include uwsgi_params;
        uwsgi_intercept_errors on;
        uwsgi_read_timeout 600;
        uwsgi_pass yml;

 }

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278670,278671#msg-278671


From nginx-forum на forum.nginx.org  Tue Feb 20 16:11:24 2018
From: nginx-forum на forum.nginx.org (VeeSot)
Date: Tue, 20 Feb 2018 11:11:24 -0500
Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0LLQt9Cw0LjQvNC+0LTQtdC50YHRgtCy0Lg=?=
 =?UTF-8?B?0LUg0YEgdVdTR0k=?=
In-Reply-To: <20180220155626.GK81872@zxy.spb.ru>
References: <20180220155626.GK81872@zxy.spb.ru>
Message-ID: <dcd6ed521102e320d4d990d1dbabf47e.NginxMailingListRussian@forum.nginx.org>

tcpdump поможет собрать информацию если обмен идет по сокету? Я выше привел
выдержку из конфига.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278670,278673#msg-278673


From kpoxa на kpoxa.net  Tue Feb 20 16:16:29 2018
From: kpoxa на kpoxa.net (kpoxa)
Date: Tue, 20 Feb 2018 19:16:29 +0300
Subject: proxy_bind ipv4 & server ipv6
Message-ID: <CABL5twAs6AMoVqtP2dP-+8iSFp4VsedhAoXG_FEVqWMQx-aL_w@mail.gmail.com>

Добрый день.

Комбинация proxy_bind на ipv4 адрес с апстримом с адресом ipv6 даёт ошибку

[crit] 14852#14852: *21 bind(10.0.0.10) failed (22: Invalid argument) while
connecting to upstream

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


---
Рустам Нарманов.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180220/84a4b648/attachment.html>

From slw на zxy.spb.ru  Tue Feb 20 16:22:12 2018
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Tue, 20 Feb 2018 19:22:12 +0300
Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0LLQt9Cw0LjQvNC+0LTQtdC50YHRgtCy0Lg=?=
 =?UTF-8?B?0LUg0YEgdVdTR0k=?=
In-Reply-To: <dcd6ed521102e320d4d990d1dbabf47e.NginxMailingListRussian@forum.nginx.org>
References: <20180220155626.GK81872@zxy.spb.ru>
 <dcd6ed521102e320d4d990d1dbabf47e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180220162212.GL81872@zxy.spb.ru>

On Tue, Feb 20, 2018 at 11:11:24AM -0500, VeeSot wrote:

> tcpdump поможет собрать информацию если обмен идет по сокету? Я выше привел
> выдержку из конфига.

можно попробовать через socat.

From mdounin на mdounin.ru  Tue Feb 20 16:39:59 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 20 Feb 2018 19:39:59 +0300
Subject: proxy_bind ipv4 & server ipv6
In-Reply-To: <CABL5twAs6AMoVqtP2dP-+8iSFp4VsedhAoXG_FEVqWMQx-aL_w@mail.gmail.com>
References: <CABL5twAs6AMoVqtP2dP-+8iSFp4VsedhAoXG_FEVqWMQx-aL_w@mail.gmail.com>
Message-ID: <20180220163959.GO24410@mdounin.ru>

Hello!

On Tue, Feb 20, 2018 at 07:16:29PM +0300, kpoxa wrote:

> Добрый день.
> 
> Комбинация proxy_bind на ipv4 адрес с апстримом с адресом ipv6 даёт ошибку
> 
> [crit] 14852#14852: *21 bind(10.0.0.10) failed (22: Invalid argument) while
> connecting to upstream
> 
> Т.к. у адрес сервера резолвился динамически, то ушло полчаса на то, чтобы
> понять где ошибка, возможно более человекопонятная надпись была бы более
> уместна.

Чтобы ловить в том числе такие проблемы - в каждом сообщении об 
ошибке написан ещё и адрес upstream-сервера, к которому пытались 
установить соединение.

-- 
Maxim Dounin
http://mdounin.ru/

From identw на gmail.com  Wed Feb 21 09:36:02 2018
From: identw на gmail.com (Dmitry Sergeev)
Date: Wed, 21 Feb 2018 14:36:02 +0500
Subject: =?UTF-8?B?NDk5IGMg0L3Rg9C70LXQstGL0LwgJHJlcXVlc3RfdGltZQ==?=
Message-ID: <4535c33d-66b0-488a-8aae-8f88ffa5c618@gmail.com>

Всем привет.

В логах nginx, 499 статус ответа означает отмену запроса на стороне 
клиента. Также в лог ведется запись переменной $request_time.

При любых тестах локально, даже если моментально отменять запрос, 
какое-то значение, хоть и малеьнкое, в переменной $request_time есть.

Но на продакшене, если например взять сервер где 303 264 000 запросов в 
день(около 3400/сек. в среднем), из них 183 278 запросов имеют статус 
499 со значением 0.000 в переменной $request_time.

Небольшое уточнение: Все запросы динамические (то есть проксируются на 
бэкенд), статика у нас раздается CDN серверами отдельно.

Посдкажите пожаулйста, в каких случаях при 499 статучc $request_time 
может быть 0? Может кто знает. Или это нормальная ситуация, и у всех в 
0.06% случаев запросы отменяются на стороне клиентов.

Может быть это происходит в случае долгого коннекта с клиентом?

-- 
Kind regards
Dmitry Sergeev
Tel: +7 (951) 129-75-72


From mdounin на mdounin.ru  Wed Feb 21 15:16:13 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 21 Feb 2018 18:16:13 +0300
Subject: =?UTF-8?B?UmU6IDQ5OSBjINC90YPQu9C10LLRi9C8ICRyZXF1ZXN0X3RpbWU=?=
In-Reply-To: <4535c33d-66b0-488a-8aae-8f88ffa5c618@gmail.com>
References: <4535c33d-66b0-488a-8aae-8f88ffa5c618@gmail.com>
Message-ID: <20180221151613.GU24410@mdounin.ru>

Hello!

On Wed, Feb 21, 2018 at 02:36:02PM +0500, Dmitry Sergeev wrote:

> Всем привет.
> 
> В логах nginx, 499 статус ответа означает отмену запроса на стороне 
> клиента. Также в лог ведется запись переменной $request_time.
> 
> При любых тестах локально, даже если моментально отменять запрос, 
> какое-то значение, хоть и малеьнкое, в переменной $request_time есть.
> 
> Но на продакшене, если например взять сервер где 303 264 000 запросов в 
> день(около 3400/сек. в среднем), из них 183 278 запросов имеют статус 
> 499 со значением 0.000 в переменной $request_time.
> 
> Небольшое уточнение: Все запросы динамические (то есть проксируются на 
> бэкенд), статика у нас раздается CDN серверами отдельно.
> 
> Посдкажите пожаулйста, в каких случаях при 499 статучc $request_time 
> может быть 0? Может кто знает. Или это нормальная ситуация, и у всех в 
> 0.06% случаев запросы отменяются на стороне клиентов.
> 
> Может быть это происходит в случае долгого коннекта с клиентом?

В случае 499 значение $request_time может быть 0, если nginx 
узнаёт, что клиент закрыл соединение, в ту же итерацию цикла 
обработки событий, что и получает сам запрос.

Чтобы такое повторить в тесте - надо в процессе предыдущей 
итерации цикла успеть установить соединение, прислать запрос, и 
успеть закрыть соединение.

-- 
Maxim Dounin
http://mdounin.ru/

From igor.bliss на gmail.com  Thu Feb 22 13:10:04 2018
From: igor.bliss на gmail.com (Igor Savenko)
Date: Thu, 22 Feb 2018 15:10:04 +0200
Subject: =?UTF-8?B?0J/QvtGA0Y/QtNC+0Log0L/RgNC+0YXQvtC20LTQtdC90LjRjyDRhdC10L3QtNC7?=
 =?UTF-8?B?0LXRgNC+0LIg0LIg0YTQsNC30LU=?=
Message-ID: <CAKG3w5+RhaoqAZYXRJU0+1L-XsFtpVz9BuTrBc5jFQ2Kj8=row@mail.gmail.com>

Добрый день! Есть ли способ указать, что данный хендлер (в моем случае
ModSecurity handler в access-phase) должен вызываться последним Или после
определенного хендлера? Или, как воркэраунд, в данном модуле проверить
определенное условие, и если оно не выставлено, выдать NGX_DECLINED, чтобы
потом этот модуль в акцесс-фазе был вызван вновь, после того, как остальные
хендлеры уже отработали? Влияет ли на этот фукнционал состояние директивы
satisfy ?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180222/523d21f2/attachment.html>

From nginx-forum на forum.nginx.org  Thu Feb 22 13:12:25 2018
From: nginx-forum на forum.nginx.org (papajoe)
Date: Thu, 22 Feb 2018 08:12:25 -0500
Subject: sendfile() failed (9: Bad file descriptor) while sending request
 to upstream
In-Reply-To: <20100812122320.GY99657@mdounin.ru>
References: <20100812122320.GY99657@mdounin.ru>
Message-ID: <7b9f0ee6d2d26ff8769d5d2176331485.NginxMailingListRussian@forum.nginx.org>

Hey everybody,

I experienced this issue using nginx version 1.10.x and 1.13.x


given a basic configuration like:

upstream myupstream {
    server internal01:80;
    server internal02:80 backup;
}

server {
    listen 81 default_server;
    listen [::]:81 default_server;

    server_name _;

    location / {
        proxy_pass http://myupstream;
        post_action @hot_standby;
    }

    location @hot_standby {
        proxy_pass http://internal02:80;
    }
}


I receive the "sendfile() failed (9: Bad file descriptor) while sending
request to upstream"  error when trying to POST data exceeding 16k body
size. The error does not occur for requests with less than 16k data.
As far as I can understand the code / documentation, 16k by default (for
64bit systems) is the limit when nginx starts to use a tempfile instead of a
memory buffer.
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_buffer_size

This makes me believe that the problem only kicks in when nginx decides to
use a tempfile instead of an inmemory buffer.


For my setup I was able to fix the issue by an alignment between
client_body_buffer_size and client_max_body_size.

client_max_body_size    1m;
client_body_buffer_size   1m;


Hope this can help anybody.

Best
Benny

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,118976,278721#msg-278721


From mdounin на mdounin.ru  Thu Feb 22 16:08:02 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 22 Feb 2018 19:08:02 +0300
Subject: =?UTF-8?B?UmU6INCf0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8g0YXQtdC9?=
 =?UTF-8?B?0LTQu9C10YDQvtCyINCyINGE0LDQt9C1?=
In-Reply-To: <CAKG3w5+RhaoqAZYXRJU0+1L-XsFtpVz9BuTrBc5jFQ2Kj8=row@mail.gmail.com>
References: <CAKG3w5+RhaoqAZYXRJU0+1L-XsFtpVz9BuTrBc5jFQ2Kj8=row@mail.gmail.com>
Message-ID: <20180222160802.GY24410@mdounin.ru>

Hello!

On Thu, Feb 22, 2018 at 03:10:04PM +0200, Igor Savenko wrote:

> Добрый день! Есть ли способ указать, что данный хендлер (в моем случае
> ModSecurity handler в access-phase) должен вызываться последним Или после
> определенного хендлера? Или, как воркэраунд, в данном модуле проверить
> определенное условие, и если оно не выставлено, выдать NGX_DECLINED, чтобы
> потом этот модуль в акцесс-фазе был вызван вновь, после того, как остальные
> хендлеры уже отработали?

Порядок вызова модулей в фазе определяется при сборке - сначала 
вызываются обработчики тех модулей, которые идут в списке модулей 
последними (и соответственно добавили свой обработчик в фазу 
последними).  Соответственно в access-фазе сторонние модули в 
общем случае будут вызываться раньше встроенных, а взаимный 
порядок сторонних модулей определяется порядком опций --add-module.

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

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

> Влияет ли на этот фукнционал состояние директивы satisfy ?

Директива satisfy определяет, будет ли требоватся разрешение на 
выполнение от всех модулей access-фазы (all) или хотя бы от одного 
(any).  В случае "satisfy all" все модули фазы вызываются 
последовательно, если хотя бы один из них вернёт ошибку - 
пользователю будет возвращена ошибка.  В случае "satisfy any" все 
модули фазы вызываются последовательно, пока хотя бы один из них 
не разрешит выполнение запроса.  После этого обработка запроса 
переходит к следующей фазе, остальные модули фазы не вызываются.

Вышеописанное следует учитывать при создании модулей для 
access-фазы - в случае "satisfy any" они могут не быть вызваны 
вовсе (если какой-то другой модуль разрешил выполнение запроса), и 
сами не должны возвращать NGX_OK, если не хотят явно разрешить 
доступ клиенту, минуя проверки других модулей.

-- 
Maxim Dounin
http://mdounin.ru/

From igor.bliss на gmail.com  Thu Feb 22 16:15:35 2018
From: igor.bliss на gmail.com (Igor Savenko)
Date: Thu, 22 Feb 2018 18:15:35 +0200
Subject: =?UTF-8?B?UmU6INCf0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8g0YXQtdC9?=
 =?UTF-8?B?0LTQu9C10YDQvtCyINCyINGE0LDQt9C1?=
In-Reply-To: <20180222160802.GY24410@mdounin.ru>
References: <CAKG3w5+RhaoqAZYXRJU0+1L-XsFtpVz9BuTrBc5jFQ2Kj8=row@mail.gmail.com>
 <20180222160802.GY24410@mdounin.ru>
Message-ID: <CAKG3w5LbNa2VSNgat4bHDWHCNw1K2Sp5+9hzx6=oaBUqjMLZGQ@mail.gmail.com>

Большое спасибо, Максим! Тем временем, я обратил внимание на то, каким
образом в openresty реализован фукнционал сдвига выполнения модуля в самый
конец фазы:

    if (!lmcf->postponed_to_access_phase_end) {

        lmcf->postponed_to_access_phase_end = 1;

        cmcf = ngx_http_get_module_main_conf(r, ngx_http_core_module);

        ph = cmcf->phase_engine.handlers;
        cur_ph = &ph[r->phase_handler];

        /* we should skip the post_access phase handler here too */
        last_ph = &ph[cur_ph->next - 2];

        dd("ph cur: %d, ph next: %d", (int) r->phase_handler,
           (int) (cur_ph->next - 2));

#if 0
        if (cur_ph == last_ph) {
            dd("XXX our handler is already the last access phase handler");
        }
#endif

        if (cur_ph < last_ph) {
            dd("swaping the contents of cur_ph and last_ph...");

            tmp = *cur_ph;

            memmove(cur_ph, cur_ph + 1,
                    (last_ph - cur_ph) * sizeof (ngx_http_phase_handler_t));

            *last_ph = tmp;

            r->phase_handler--; /* redo the current ph */

            return NGX_DECLINED;
        }
    }

Актуален ли данный подход? Это хак, недокументированная возможность или
широкоизвестная в узких кругах функциональность?

22 февраля 2018 г., 18:08 пользователь Maxim Dounin <mdounin на mdounin.ru>
написал:

> Hello!
>
> On Thu, Feb 22, 2018 at 03:10:04PM +0200, Igor Savenko wrote:
>
> > Добрый день! Есть ли способ указать, что данный хендлер (в моем случае
> > ModSecurity handler в access-phase) должен вызываться последним Или после
> > определенного хендлера? Или, как воркэраунд, в данном модуле проверить
> > определенное условие, и если оно не выставлено, выдать NGX_DECLINED,
> чтобы
> > потом этот модуль в акцесс-фазе был вызван вновь, после того, как
> остальные
> > хендлеры уже отработали?
>
> Порядок вызова модулей в фазе определяется при сборке - сначала
> вызываются обработчики тех модулей, которые идут в списке модулей
> последними (и соответственно добавили свой обработчик в фазу
> последними).  Соответственно в access-фазе сторонние модули в
> общем случае будут вызываться раньше встроенных, а взаимный
> порядок сторонних модулей определяется порядком опций --add-module.
>
> Чуть больше контроля есть при динамической загрузке - с помощью
> переменной ngx_module_order можно задать произвольную позицию,
> куда следует загружать модуль.
>
> Но вообще, если порядок вдруг важен - стоит подумать о том,
> правильно ли выбрана фаза.  Если хочется позвать обработчик
> последним - то, возможно, вам нужна другая фаза.
>
> > Влияет ли на этот фукнционал состояние директивы satisfy ?
>
> Директива satisfy определяет, будет ли требоватся разрешение на
> выполнение от всех модулей access-фазы (all) или хотя бы от одного
> (any).  В случае "satisfy all" все модули фазы вызываются
> последовательно, если хотя бы один из них вернёт ошибку -
> пользователю будет возвращена ошибка.  В случае "satisfy any" все
> модули фазы вызываются последовательно, пока хотя бы один из них
> не разрешит выполнение запроса.  После этого обработка запроса
> переходит к следующей фазе, остальные модули фазы не вызываются.
>
> Вышеописанное следует учитывать при создании модулей для
> access-фазы - в случае "satisfy any" они могут не быть вызваны
> вовсе (если какой-то другой модуль разрешил выполнение запроса), и
> сами не должны возвращать NGX_OK, если не хотят явно разрешить
> доступ клиенту, минуя проверки других модулей.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180222/ad84ec2d/attachment-0001.html>

From mdounin на mdounin.ru  Thu Feb 22 16:52:59 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 22 Feb 2018 19:52:59 +0300
Subject: =?UTF-8?B?UmU6INCf0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8g0YXQtdC9?=
 =?UTF-8?B?0LTQu9C10YDQvtCyINCyINGE0LDQt9C1?=
In-Reply-To: <CAKG3w5LbNa2VSNgat4bHDWHCNw1K2Sp5+9hzx6=oaBUqjMLZGQ@mail.gmail.com>
References: <CAKG3w5+RhaoqAZYXRJU0+1L-XsFtpVz9BuTrBc5jFQ2Kj8=row@mail.gmail.com>
 <20180222160802.GY24410@mdounin.ru>
 <CAKG3w5LbNa2VSNgat4bHDWHCNw1K2Sp5+9hzx6=oaBUqjMLZGQ@mail.gmail.com>
Message-ID: <20180222165259.GA24410@mdounin.ru>

Hello!

On Thu, Feb 22, 2018 at 06:15:35PM +0200, Igor Savenko wrote:

> Большое спасибо, Максим! Тем временем, я обратил внимание на то, каким
> образом в openresty реализован фукнционал сдвига выполнения модуля в самый
> конец фазы:
> 
>     if (!lmcf->postponed_to_access_phase_end) {
> 
>         lmcf->postponed_to_access_phase_end = 1;
> 
>         cmcf = ngx_http_get_module_main_conf(r, ngx_http_core_module);
> 
>         ph = cmcf->phase_engine.handlers;
>         cur_ph = &ph[r->phase_handler];

[...]

> Актуален ли данный подход? Это хак, недокументированная возможность или
> широкоизвестная в узких кругах функциональность?

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

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

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

Не надо делать так.

-- 
Maxim Dounin
http://mdounin.ru/

From igor.bliss на gmail.com  Thu Feb 22 16:59:55 2018
From: igor.bliss на gmail.com (Igor Savenko)
Date: Thu, 22 Feb 2018 18:59:55 +0200
Subject: =?UTF-8?B?UmU6INCf0L7RgNGP0LTQvtC6INC/0YDQvtGF0L7QttC00LXQvdC40Y8g0YXQtdC9?=
 =?UTF-8?B?0LTQu9C10YDQvtCyINCyINGE0LDQt9C1?=
In-Reply-To: <20180222165259.GA24410@mdounin.ru>
References: <CAKG3w5+RhaoqAZYXRJU0+1L-XsFtpVz9BuTrBc5jFQ2Kj8=row@mail.gmail.com>
 <20180222160802.GY24410@mdounin.ru>
 <CAKG3w5LbNa2VSNgat4bHDWHCNw1K2Sp5+9hzx6=oaBUqjMLZGQ@mail.gmail.com>
 <20180222165259.GA24410@mdounin.ru>
Message-ID: <CAKG3w5L7-1MDiL_uTdkdLjnseyxZwtZuhFDmOTDQ21TnaRxCyw@mail.gmail.com>

Спасибо! :) Понятно

22 февраля 2018 г., 18:52 пользователь Maxim Dounin <mdounin на mdounin.ru>
написал:

> Hello!
>
> On Thu, Feb 22, 2018 at 06:15:35PM +0200, Igor Savenko wrote:
>
> > Большое спасибо, Максим! Тем временем, я обратил внимание на то, каким
> > образом в openresty реализован фукнционал сдвига выполнения модуля в
> самый
> > конец фазы:
> >
> >     if (!lmcf->postponed_to_access_phase_end) {
> >
> >         lmcf->postponed_to_access_phase_end = 1;
> >
> >         cmcf = ngx_http_get_module_main_conf(r, ngx_http_core_module);
> >
> >         ph = cmcf->phase_engine.handlers;
> >         cur_ph = &ph[r->phase_handler];
>
> [...]
>
> > Актуален ли данный подход? Это хак, недокументированная возможность или
> > широкоизвестная в узких кругах функциональность?
>
> Приблизительно всё, что можно найти в openresty - это хаки разной
> степени тяжести.  Процитированный код - характерный представитель.
>
> Во-первых, он лезет во внутренние структуры http core.  Однажды мы
> что-нибудь поменяем внутри - и оно всё сломается с удивительными
> спецэффектами.
>
> Во-вторых, он пытается менять конфигурацию внутри работающего
> рабочего процесса.  Это просто глупо, так как приведёт к тому, что
> соответствующие структуры будут дублироваться в памяти разных
> рабочих процессов.
>
> Не надо делать так.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180222/c3c06ed1/attachment.html>

From nginx-forum на forum.nginx.org  Thu Feb 22 17:03:10 2018
From: nginx-forum на forum.nginx.org (Bloof)
Date: Thu, 22 Feb 2018 12:03:10 -0500
Subject: =?UTF-8?B?d2FpdCB0aW1lINC/0YDQuCDQutC10YjQuNGA0L7QstCw0L3QuNC4IHByb3h5IGNh?=
 =?UTF-8?B?Y2hl?=
Message-ID: <f05a5220c32e78776e1e7ad314d01041.NginxMailingListRussian@forum.nginx.org>

Добрый день.

Я использую nginx как раздающий сервер для кеширования небольших видеофайлов
с другого сервера-хранилища. Среднее время получения одного файла из
хранилища 20 мсек, максимальное 200 мсек. Если два клиента приходят к nginx
за одним файлом практически одновременно, то nginx одного клиента ставит на
загрузку файла из хранилища, а второй клиент попадает на ожидание
lock_timeout/lock_age
(https://github.com/nginx/nginx/blob/branches/stable-1.12/src/http/ngx_http_file_cache.c#L452).
При этом ставится таймер, который каждые 500 мсек проверяет наличие файла в
кеше. Получается, что время таймера сильно больше времени получения файла из
хранилища. Уменьшать proxy_cache_lock_timeout нет возможности, так как можно
перегрузить канал между nginx и хранилищем. Есть ли возможность
обойти/уменьшить этот таймер, кроме как менять значение в сорцах и
перекомпилировать nginx? Можно ли поставить что-то типа inotify ивента на
появление/изменение файла в кеше?

Мой nginx.conf

worker_processes 8;
worker_cpu_affinity auto;

events {
    worker_connections 32768;
    use epoll;
    multi_accept on;
}

http {
	sendfile on;
	tcp_nopush on;

	proxy_cache_path /storage/cache levels=1:2 keys_zone=ssd_cache:10m
inactive=10m use_temp_path=off max_size=1G;
	proxy_http_version 1.1;

	upstream backend {
        server some_other_server:80 max_fails=0;
        keepalive 16;
    }

    server {
    	listen 80;

    	location ~ ^/($<fname>.+)\.mp4$ {
    	    proxy_pass http://backend;
            proxy_cache_key "$request_method|$fname";
            proxy_cache ssd_cache;
            proxy_cache_revalidate on;
            proxy_set_header Connection "";
            proxy_cache_lock on;
            proxy_cache_lock_timeout 300s;
            proxy_cache_lock_age 5s;
            proxy_cache_use_stale error timeout invalid_header updating;
            proxy_buffering on;
    	}
    }
}

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


From mdounin на mdounin.ru  Thu Feb 22 17:06:52 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 22 Feb 2018 20:06:52 +0300
Subject: sendfile() failed (9: Bad file descriptor) while sending request
 to upstream
In-Reply-To: <7b9f0ee6d2d26ff8769d5d2176331485.NginxMailingListRussian@forum.nginx.org>
References: <20100812122320.GY99657@mdounin.ru>
 <7b9f0ee6d2d26ff8769d5d2176331485.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180222170652.GB24410@mdounin.ru>

Hello!

On Thu, Feb 22, 2018 at 08:12:25AM -0500, papajoe wrote:

> Hey everybody,
> 
> I experienced this issue using nginx version 1.10.x and 1.13.x
> 
> 
> given a basic configuration like:
> 
> upstream myupstream {
>     server internal01:80;
>     server internal02:80 backup;
> }
> 
> server {
>     listen 81 default_server;
>     listen [::]:81 default_server;
> 
>     server_name _;
> 
>     location / {
>         proxy_pass http://myupstream;
>         post_action @hot_standby;
>     }
> 
>     location @hot_standby {
>         proxy_pass http://internal02:80;
>     }
> }
> 
> 
> I receive the "sendfile() failed (9: Bad file descriptor) while sending
> request to upstream"  error when trying to POST data exceeding 16k body
> size. The error does not occur for requests with less than 16k data.
> As far as I can understand the code / documentation, 16k by default (for
> 64bit systems) is the limit when nginx starts to use a tempfile instead of a
> memory buffer.
> http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_buffer_size
> 
> This makes me believe that the problem only kicks in when nginx decides to
> use a tempfile instead of an inmemory buffer.
> 
> 
> For my setup I was able to fix the issue by an alignment between
> client_body_buffer_size and client_max_body_size.
> 
> client_max_body_size    1m;
> client_body_buffer_size   1m;
> 
> 
> Hope this can help anybody.

Just in case you are interested in details, this is a result in 
optimization in the proxy module, which removes the request body 
file as soon as a response is received.  Additional details can be 
found here:

http://hg.nginx.org/nginx/rev/f583559aadc7
https://trac.nginx.org/nginx/ticket/585

To fix this, consider using mirror instead of the [intentionally 
undocumented] post_action directive, see 
http://nginx.org/en/docs/http/ngx_http_mirror_module.html.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin на mdounin.ru  Thu Feb 22 17:48:32 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 22 Feb 2018 20:48:32 +0300
Subject: =?UTF-8?B?UmU6IHdhaXQgdGltZSDQv9GA0Lgg0LrQtdGI0LjRgNC+0LLQsNC90LjQuCBwcm94?=
 =?UTF-8?B?eSBjYWNoZQ==?=
In-Reply-To: <f05a5220c32e78776e1e7ad314d01041.NginxMailingListRussian@forum.nginx.org>
References: <f05a5220c32e78776e1e7ad314d01041.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180222174832.GC24410@mdounin.ru>

Hello!

On Thu, Feb 22, 2018 at 12:03:10PM -0500, Bloof wrote:

> Добрый день.
> 
> Я использую nginx как раздающий сервер для кеширования небольших видеофайлов
> с другого сервера-хранилища. Среднее время получения одного файла из
> хранилища 20 мсек, максимальное 200 мсек. Если два клиента приходят к nginx
> за одним файлом практически одновременно, то nginx одного клиента ставит на
> загрузку файла из хранилища, а второй клиент попадает на ожидание
> lock_timeout/lock_age
> (https://github.com/nginx/nginx/blob/branches/stable-1.12/src/http/ngx_http_file_cache.c#L452).
> При этом ставится таймер, который каждые 500 мсек проверяет наличие файла в
> кеше. Получается, что время таймера сильно больше времени получения файла из
> хранилища. Уменьшать proxy_cache_lock_timeout нет возможности, так как можно
> перегрузить канал между nginx и хранилищем. Есть ли возможность
> обойти/уменьшить этот таймер, кроме как менять значение в сорцах и
> перекомпилировать nginx? Можно ли поставить что-то типа inotify ивента на
> появление/изменение файла в кеше?

Нет, сейчас способов как-то повлиять на этот таймер, кроме как с 
помощью малого значения proxy_cache_lock_timeout, нет.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Fri Feb 23 19:36:02 2018
From: nginx-forum на forum.nginx.org (papajoe)
Date: Fri, 23 Feb 2018 14:36:02 -0500
Subject: sendfile() failed (9: Bad file descriptor) while sending request
 to upstream
In-Reply-To: <20180222170652.GB24410@mdounin.ru>
References: <20180222170652.GB24410@mdounin.ru>
Message-ID: <0221ff7632ec4dc3f9e2d10536903de3.NginxMailingListRussian@forum.nginx.org>

Hey Maxim!

Thank you very much for your suggestion. Unfortunately our "project" still
uses 1.13.3 (as of today only 1.13.3 is available via stretch-backports), so
the mirror module (>= 1.13.4) is not yet available for here.

I hope I will find the time to eventually report back on your config
suggestion this as soon as I have the option to run your configuration with
"live conditions".

I very much appreciate there is an official implementation for "replaying
requests" now. Keep on rocking!

Best
Benny

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,118976,278743#msg-278743


From nginx-forum на forum.nginx.org  Mon Feb 26 08:49:34 2018
From: nginx-forum на forum.nginx.org (Dmytro Lavryk)
Date: Mon, 26 Feb 2018 03:49:34 -0500
Subject: =?UTF-8?Q?ipv6_=D0=B8_error_400?=
Message-ID: <7bfa92037b80f3067a8e301f1ade1b13.NginxMailingListRussian@forum.nginx.org>

Доброго всем здоровья!
Недавно прикрутил к нескольким сайтам на сервере ipv6 адреса, прописал в
nginx . В  access на этих сайтах периодически по непонятным причинам
проскакивает код ответа 400. При чем ИСКЛЮЧИТЕЛЬНО при обращениях через
ipv6.

Чтобы могло быть? Как можно подробнее продиагностировать - чего не хватает?

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


From nginx на mva.name  Mon Feb 26 09:01:29 2018
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Mon, 26 Feb 2018 16:01:29 +0700
Subject: =?UTF-8?Q?Re=3A_ipv6_=D0=B8_error_400?=
In-Reply-To: <7bfa92037b80f3067a8e301f1ade1b13.NginxMailingListRussian@forum.nginx.org>
References: <7bfa92037b80f3067a8e301f1ade1b13.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2067534.0p9OTYVcL0@note>

А прописали точно и для ssl и для http?
И как именно указали?


В письме от понедельник, 26 февраля 2018 г. 15:49:34 +07 пользователь Dmytro 
Lavryk написал:
> Доброго всем здоровья!
> Недавно прикрутил к нескольким сайтам на сервере ipv6 адреса, прописал в
> nginx . В  access на этих сайтах периодически по непонятным причинам
> проскакивает код ответа 400. При чем ИСКЛЮЧИТЕЛЬНО при обращениях через
> ipv6.
> 
> Чтобы могло быть? Как можно подробнее продиагностировать - чего не хватает?
> 
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,278759,278759#msg-278759
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From bgx на protva.ru  Mon Feb 26 09:25:28 2018
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Mon, 26 Feb 2018 12:25:28 +0300
Subject: =?UTF-8?Q?Re=3A_ipv6_=D0=B8_error_400?=
In-Reply-To: <7bfa92037b80f3067a8e301f1ade1b13.NginxMailingListRussian@forum.nginx.org>
References: <7bfa92037b80f3067a8e301f1ade1b13.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180226092528.GV22602@protva.ru>

On Mon, Feb 26, 2018 at 03:49:34AM -0500, Dmytro Lavryk wrote:
> Доброго всем здоровья!
> Недавно прикрутил к нескольким сайтам на сервере ipv6 адреса, прописал в
> nginx . В  access на этих сайтах периодически по непонятным причинам
> проскакивает код ответа 400. При чем ИСКЛЮЧИТЕЛЬНО при обращениях через
> ipv6.
> 
> Чтобы могло быть? Как можно подробнее продиагностировать - чего не хватает?

 Для начала следует поинтересоваться, в каких случаях сервер может дать
 статус-код 400. Затем проверить, действительно ли на проблемный запрос
 должен быть дан 400. И лишь когда есть конкретный запрос, для которого
 видимых причин выдачи кода 400 нет, можно запостить этот запрос сюда
 и спросить, правильно ли поступает nginx, выдавая ошибку.
-- 
 Eugene Berdnikov

From nginx-forum на forum.nginx.org  Mon Feb 26 09:27:52 2018
From: nginx-forum на forum.nginx.org (Dmytro Lavryk)
Date: Mon, 26 Feb 2018 04:27:52 -0500
Subject: =?UTF-8?Q?Re=3A_ipv6_=D0=B8_error_400?=
In-Reply-To: <2067534.0p9OTYVcL0@note>
References: <2067534.0p9OTYVcL0@note>
Message-ID: <9bc55b683042c3c5e57f2c49dca261ee.NginxMailingListRussian@forum.nginx.org>

Vadim A. Misbakh-Soloviov Wrote:
-------------------------------------------------------
> А прописали точно и для ssl и для http?
> И как именно указали?

server {

    listen   [2a01:4f8:190:XXXX::2]:80;
    listen   [2a01:4f8:190:XXXX::2]:443 ssl http2;

    listen   80;
    listen   443 ssl http2;

    server_name ... 

и т.д. 

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

2a03:4000:6:d03e::1 [26/Feb/2018:08:00:14 +0200] "GET / HTTP/1.1" 400 666
"-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/58.0.3029.110 Safari/537.36"
2a03:4000:6:d03e::1 [26/Feb/2018:08:00:17 +0200] "GET / HTTP/1.1" 200 53257
"-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/58.0.3029.110 Safari/537.36"



> 
> В письме от понедельник, 26 февраля 2018 г. 15:49:34 +07 пользователь
> Dmytro 
> Lavryk написал:
> > Доброго всем здоровья!
> > Недавно прикрутил к нескольким сайтам на сервере ipv6 адреса,
> прописал в
> > nginx . В  access на этих сайтах периодически по непонятным причинам
> > проскакивает код ответа 400. При чем ИСКЛЮЧИТЕЛЬНО при обращениях
> через
> > ipv6.
> > 
> > Чтобы могло быть? Как можно подробнее продиагностировать - чего не
> хватает?
> > 
> > Posted at Nginx Forum:
> > https://forum.nginx.org/read.php?21,278759,278759#msg-278759
> > 
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru на nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278759,278761#msg-278761


From nginx-ru на sadok.spb.ru  Mon Feb 26 10:01:44 2018
From: nginx-ru на sadok.spb.ru (Dmitry Ivanov)
Date: Mon, 26 Feb 2018 13:01:44 +0300
Subject: =?UTF-8?Q?Re=3A_ipv6_=D0=B8_error_400?=
In-Reply-To: <9bc55b683042c3c5e57f2c49dca261ee.NginxMailingListRussian@forum.nginx.org>
References: <2067534.0p9OTYVcL0@note>
 <9bc55b683042c3c5e57f2c49dca261ee.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1328609106.20180226130144@sadok.spb.ru>

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

Вы писали 26 февраля 2018 г., 12:27:52:

> 2a03:4000:6:d03e::1 [26/Feb/2018:08:00:14 +0200] "GET / HTTP/1.1" 400 666
> "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
> like Gecko) Chrome/58.0.3029.110 Safari/537.36"
> 2a03:4000:6:d03e::1 [26/Feb/2018:08:00:17 +0200] "GET / HTTP/1.1" 200 53257
> "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
> like Gecko) Chrome/58.0.3029.110 Safari/537.36"

Можно  посмотреть  запрос  полностью,  не  через  лог?  Я в свое время
удивился,  когда мне Netscaler стал такими ошибками плеваться. В итоге
дикий клиент с мегабайтными GET


-- 
С уважением,
 Dmitry                       nginx-ru на sadok.spb.ru


From nginx-forum на forum.nginx.org  Mon Feb 26 10:22:32 2018
From: nginx-forum на forum.nginx.org (Dmytro Lavryk)
Date: Mon, 26 Feb 2018 05:22:32 -0500
Subject: =?UTF-8?Q?Re=3A_ipv6_=D0=B8_error_400?=
In-Reply-To: <1328609106.20180226130144@sadok.spb.ru>
References: <1328609106.20180226130144@sadok.spb.ru>
Message-ID: <32fc4b4a0393041ba1aeac5b92df2dac.NginxMailingListRussian@forum.nginx.org>

Dmitry Ivanov Wrote:
-------------------------------------------------------
> Можно  посмотреть  запрос  полностью,  не  через  лог?  Я в свое время
> удивился,  когда мне Netscaler стал такими ошибками плеваться. В итоге
> дикий клиент с мегабайтными GET

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

2a02:6b8:0:1a21::10 [26/Feb/2018:07:35:36 +0200] "GET
/phpbb/files/2003_8e3579882284805a2cb9b620f21a6dc7.png HTTP/1.1" 400 264 "-"
"Mozilla/5.0 (compatible; YandexImageResizer/2.0; +http://yandex.com/bots)"

Где-то на просторах гугла нарыл совет обязательно убрать строку "ssl on;" из
конфига. Тайного смысла не понял. но строка была, убрал. Пока ответов с
кодом 400 нету - наблюдаю. Возможно это и есть решение, только мне непонятно
"в чем заковыка".

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278759,278764#msg-278764


From alex на vorona.com.ua  Mon Feb 26 10:39:01 2018
From: alex на vorona.com.ua (Alex Vorona)
Date: Mon, 26 Feb 2018 12:39:01 +0200
Subject: =?UTF-8?Q?Re=3A_ipv6_=D0=B8_error_400?=
In-Reply-To: <32fc4b4a0393041ba1aeac5b92df2dac.NginxMailingListRussian@forum.nginx.org>
References: <1328609106.20180226130144@sadok.spb.ru>
 <32fc4b4a0393041ba1aeac5b92df2dac.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2d53f9ea-8408-0cca-54ec-b4893b4a7a41@vorona.com.ua>

Hello,


26.02.18 12:22, Dmytro Lavryk wrote:

> Где-то на просторах гугла нарыл совет обязательно убрать строку "ssl on;" из
> конфига. Тайного смысла не понял. но строка была, убрал. Пока ответов с
> кодом 400 нету - наблюдаю. Возможно это и есть решение, только мне непонятно
> "в чем заковыка".

ssl on; включал SSL на всех listen соответствующего server. Скорее всего 
у вас 400-ки были на 80-м порту, добавление $server_port в формат логов 
при сохранении ssl on сможет ответить на этот вопрос.

--
Alex Vorona

From mdounin на mdounin.ru  Mon Feb 26 13:31:12 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 26 Feb 2018 16:31:12 +0300
Subject: =?UTF-8?Q?Re=3A_ipv6_=D0=B8_error_400?=
In-Reply-To: <7bfa92037b80f3067a8e301f1ade1b13.NginxMailingListRussian@forum.nginx.org>
References: <7bfa92037b80f3067a8e301f1ade1b13.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180226133112.GB89840@mdounin.ru>

Hello!

On Mon, Feb 26, 2018 at 03:49:34AM -0500, Dmytro Lavryk wrote:

> Доброго всем здоровья!
> Недавно прикрутил к нескольким сайтам на сервере ipv6 адреса, прописал в
> nginx . В  access на этих сайтах периодически по непонятным причинам
> проскакивает код ответа 400. При чем ИСКЛЮЧИТЕЛЬНО при обращениях через
> ipv6.
> 
> Чтобы могло быть? Как можно подробнее продиагностировать - чего не хватает?

Если ответ с кодом 400 возвращает nginx - то причина будет в error 
log на уровне info.

-- 
Maxim Dounin
http://mdounin.ru/

From yorick на ya.ru  Mon Feb 26 15:46:34 2018
From: yorick на ya.ru (Yury Lyakh)
Date: Mon, 26 Feb 2018 16:46:34 +0100
Subject: =?UTF-8?B?R0VUINC30LDQv9GA0L7RgSwgMjAwINC60L7QtCDQuCBib2R5X2J5dGVzX3NlbnQ9?=
 =?UTF-8?B?PTAg0L/RgNC4INC90LXQv9GD0YHRgtC+0Lwg0L7QsdGK0LXQutGC0LUg0LI=?=
 =?UTF-8?B?0YvQtNCw0YfQuCwg0LrQsNC6Pw==?=
Message-ID: <864604DE-EE90-4172-B697-213B4A70292F@ya.ru>


День добрый всем,

не подскажет ли сообщество, в каких случаях nginx может писать в лог GET с таким раскладом:
$response_code == 200
$body_bytes_sent == 0
$bytes_sent != 0

выдача из кеша (впрочем такая же картина и при MISS с хождением в бэкенд, есть ощущение что это связано с поведением пользователя в первую очередь):

"83.6.141.89" "-" "-" "[15/Feb/2018:14:37:24 +0000]" "GET /hls-vod/mjxCYlUG8gQh4WApAv94JA/1518726762/120/0x500003970b782deb/e58180d4dc134dd8a440d56214dbf890.mp4Frag6Num5.ts HTTP/2.0" "200" "0" "https://rube.ru/play/embed/10936010 <http://rube.ru/play/embed/10936010>" "Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_2 like Mac OS X) AppleWebKit/604.4.7 (KHTML, like Gecko) Version/11.0 Mobile/15C202 Safari/604.1" "257" "-" "https" "c.rube.ru <http://c.rube.ru/>" "60.000" "-" "95" "-" "HIT" "-" "-" "645" "2038"

"85.172.79.11" "-" "-" "[26/Feb/2018:15:01:22 +0000]" "GET /hls-vod/idSHrOHQR97_xWvsyJve1g/1519677788/119/0x500003970b8815d3/cead5d5a8e6a4e0bb99c5ea4244bc4b6.mp4Frag158Num158.ts HTTP/2.0" "200" "0" "https://rube.ru/play/embed/10878914?wmode=opaque&playlist=1&fakeFullscreen=1 <https://rube.ru/play/embed/10878914?wmode=opaque&playlist=1&fakeFullscreen=1>" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36" "235" "-" "https" "c.rube.ru <http://c.rube.ru/>" "19.907" "-" "98" "-" "HIT" "-" "-" "645" "2038"

здесь построчно соответственно поля равны:
200, 0, 257
200, 0, 235

То есть соединение корректно закрылось сразу после получения заголовков, от body клиент отмахался, не стал принимать?
Если бы был HEAD запрос я бы еще понял что происходит, но тут GET.

Сами объекты не пустые, то есть в логе присутствует их выдача ненулевого body, да и в кеше посмотрел, вполне себе нормальные файлы.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180226/2c611764/attachment.html>

From yorick на ya.ru  Mon Feb 26 15:55:27 2018
From: yorick на ya.ru (Yury Lyakh)
Date: Mon, 26 Feb 2018 16:55:27 +0100
Subject: =?UTF-8?B?UmU6IEdFVCDQt9Cw0L/RgNC+0YEsIDIwMCDQutC+0LQg0LggYm9keV9ieXRlc19z?=
 =?UTF-8?B?ZW50PT0wINC/0YDQuCDQvdC10L/Rg9GB0YLQvtC8INC+0LHRitC10LrRgtC1?=
 =?UTF-8?B?INCy0YvQtNCw0YfQuCwg0LrQsNC6Pw==?=
In-Reply-To: <864604DE-EE90-4172-B697-213B4A70292F@ya.ru>
References: <864604DE-EE90-4172-B697-213B4A70292F@ya.ru>
Message-ID: <F94BA398-A20C-4AA6-A75A-ADBD5408B0D6@ya.ru>

забыл добавить главное, версия nginx самая распоследняя 1.13.9

> On 26 Feb 2018, at 16:46, Yury Lyakh <yorick на ya.ru> wrote:
> 
> 
> День добрый всем,
> 
> не подскажет ли сообщество, в каких случаях nginx может писать в лог GET с таким раскладом:
> $response_code == 200
> $body_bytes_sent == 0
> $bytes_sent != 0
> 
> выдача из кеша (впрочем такая же картина и при MISS с хождением в бэкенд, есть ощущение что это связано с поведением пользователя в первую очередь):
> 
> "83.6.141.89" "-" "-" "[15/Feb/2018:14:37:24 +0000]" "GET /hls-vod/mjxCYlUG8gQh4WApAv94JA/1518726762/120/0x500003970b782deb/e58180d4dc134dd8a440d56214dbf890.mp4Frag6Num5.ts HTTP/2.0" "200" "0" "https://rube.ru/play/embed/10936010 <http://rube.ru/play/embed/10936010>" "Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_2 like Mac OS X) AppleWebKit/604.4.7 (KHTML, like Gecko) Version/11.0 Mobile/15C202 Safari/604.1" "257" "-" "https" "c.rube.ru <http://c.rube.ru/>" "60.000" "-" "95" "-" "HIT" "-" "-" "645" "2038"
> 
> "85.172.79.11" "-" "-" "[26/Feb/2018:15:01:22 +0000]" "GET /hls-vod/idSHrOHQR97_xWvsyJve1g/1519677788/119/0x500003970b8815d3/cead5d5a8e6a4e0bb99c5ea4244bc4b6.mp4Frag158Num158.ts HTTP/2.0" "200" "0" "https://rube.ru/play/embed/10878914?wmode=opaque&playlist=1&fakeFullscreen=1 <https://rube.ru/play/embed/10878914?wmode=opaque&playlist=1&fakeFullscreen=1>" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36" "235" "-" "https" "c.rube.ru <http://c.rube.ru/>" "19.907" "-" "98" "-" "HIT" "-" "-" "645" "2038"
> 
> здесь построчно соответственно поля равны:
> 200, 0, 257
> 200, 0, 235
> 
> То есть соединение корректно закрылось сразу после получения заголовков, от body клиент отмахался, не стал принимать?
> Если бы был HEAD запрос я бы еще понял что происходит, но тут GET.
> 
> Сами объекты не пустые, то есть в логе присутствует их выдача ненулевого body, да и в кеше посмотрел, вполне себе нормальные файлы.
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180226/821099b1/attachment-0001.html>

From mdounin на mdounin.ru  Mon Feb 26 17:33:05 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 26 Feb 2018 20:33:05 +0300
Subject: =?UTF-8?B?UmU6IEdFVCDQt9Cw0L/RgNC+0YEsIDIwMCDQutC+0LQg0LggYm9keV9ieXRlc19z?=
 =?UTF-8?B?ZW50PT0wINC/0YDQuCDQvdC10L/Rg9GB0YLQvtC8INC+0LHRitC10LrRgtC1?=
 =?UTF-8?B?INCy0YvQtNCw0YfQuCwg0LrQsNC6Pw==?=
In-Reply-To: <864604DE-EE90-4172-B697-213B4A70292F@ya.ru>
References: <864604DE-EE90-4172-B697-213B4A70292F@ya.ru>
Message-ID: <20180226173305.GD89840@mdounin.ru>

Hello!

On Mon, Feb 26, 2018 at 04:46:34PM +0100, Yury Lyakh wrote:

> 
> День добрый всем,
> 
> не подскажет ли сообщество, в каких случаях nginx может писать в лог GET с таким раскладом:
> $response_code == 200
> $body_bytes_sent == 0
> $bytes_sent != 0
> 
> выдача из кеша (впрочем такая же картина и при MISS с хождением в бэкенд, есть ощущение что это связано с поведением пользователя в первую очередь):
> 
> "83.6.141.89" "-" "-" "[15/Feb/2018:14:37:24 +0000]" "GET /hls-vod/mjxCYlUG8gQh4WApAv94JA/1518726762/120/0x500003970b782deb/e58180d4dc134dd8a440d56214dbf890.mp4Frag6Num5.ts HTTP/2.0" "200" "0" "https://rube.ru/play/embed/10936010 <http://rube.ru/play/embed/10936010>" "Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_2 like Mac OS X) AppleWebKit/604.4.7 (KHTML, like Gecko) Version/11.0 Mobile/15C202 Safari/604.1" "257" "-" "https" "c.rube.ru <http://c.rube.ru/>" "60.000" "-" "95" "-" "HIT" "-" "-" "645" "2038"
> 
> "85.172.79.11" "-" "-" "[26/Feb/2018:15:01:22 +0000]" "GET /hls-vod/idSHrOHQR97_xWvsyJve1g/1519677788/119/0x500003970b8815d3/cead5d5a8e6a4e0bb99c5ea4244bc4b6.mp4Frag158Num158.ts HTTP/2.0" "200" "0" "https://rube.ru/play/embed/10878914?wmode=opaque&playlist=1&fakeFullscreen=1 <https://rube.ru/play/embed/10878914?wmode=opaque&playlist=1&fakeFullscreen=1>" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36" "235" "-" "https" "c.rube.ru <http://c.rube.ru/>" "19.907" "-" "98" "-" "HIT" "-" "-" "645" "2038"
> 
> здесь построчно соответственно поля равны:
> 200, 0, 257
> 200, 0, 235
> 
> То есть соединение корректно закрылось сразу после получения заголовков, от body клиент отмахался, не стал принимать?
> Если бы был HEAD запрос я бы еще понял что происходит, но тут GET.

В случае GET существует также более одного способа получить 
заголовок, но не получать тело.

В данном случае, с учётом использования HTTP/2, я бы предположил, 
что клиент присылает RST_STREAM после получения заголовка.  В 
error log'е при этом на уровне info будут детали, что-нибудь вроде 
"client canceled stream..." или "client terminated stream...", в 
зависимости от конкретных причин закрытия запроса.

Впрочем, может быть и просто закрыто соединение - в error log'е, 
опять же, будут детали на уровне info.

-- 
Maxim Dounin
http://mdounin.ru/

From andrey на kopeyko.ru  Mon Feb 26 20:22:40 2018
From: andrey на kopeyko.ru (Andrey Kopeyko)
Date: Mon, 26 Feb 2018 23:22:40 +0300
Subject: =?UTF-8?Q?Re=3A_ipv6_=D0=B8_error_400?=
In-Reply-To: <1328609106.20180226130144@sadok.spb.ru>
References: <2067534.0p9OTYVcL0@note>
 <9bc55b683042c3c5e57f2c49dca261ee.NginxMailingListRussian@forum.nginx.org>
 <1328609106.20180226130144@sadok.spb.ru>
Message-ID: <ae6472c3f6279cce129b2dfaebde42e1@kopeyko.ru>

Dmitry Ivanov писал 2018-02-26 13:01:

Добрый день, Дмитрий!

> Можно  посмотреть  запрос  полностью,  не  через  лог?

Можно, но по-прежнему в логе - 
http://nginx.org/ru/docs/ngx_core_module.html#debug_connection

Однако, нужно знать IP-адрес логируемого, или хотя бы его сеть.


-- 
Best regards,
Andrey A. Kopeyko <andrey на kopeyko.ru>

From nick на methodlab.info  Tue Feb 27 07:17:07 2018
From: nick на methodlab.info (Nick Lavlinsky - Method Lab)
Date: Tue, 27 Feb 2018 10:17:07 +0300
Subject: =?UTF-8?B?0JLQvtC/0YDQvtGB0Ysg0L/QviBodHRwMiBwdXNo?=
Message-ID: <3d7f04c7-26f9-6896-f42f-5810928d97f1@methodlab.info>

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

Начал тестировать http2_push сразу после релиза. Появилось 2 вопроса.

1. Есть ли возможность пушить ресурсы до ответа на основной запрос (так 
делает у себя Fastly, называя async push)? Таким образом можно получить 
экономию не только в 1RTT, но и за счет серверного времени на генерацию 
html (https://www.fastly.com/blog/optimizing-http2-server-push-fastly).

2. При использовании директивы http2_push в конфиге сайта браузеры 
(Chrome Stable и 66, FF 58.0.2) показывают, что только 1 ресурс был 
запушен, хотя стоят сразу несколько (смотрю в DevTools с отключенным 
кэшем). Например:

     location / {
         proxy_pass http://127.0.0.1:9090/pcgi/index.pl?$uri?&$args;
         proxy_redirect     off;

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

     http2_push /css/colorbox.css;
     http2_push /img/design/logo.png;
     http2_push /js/core.js;
     http2_push /images/border.png;
     http2_push /img/no_foto.png;
     http2_push /js/jq/jquery-2.1.3.min.js;

     }

В браузерах отображается в виде push только /img/design/logo.png, так 
как этот ресурс используется на странице (остальные - нет). Поведение 
одинаково и в Chrome и в FF.

Если делать push через заголовок Link (http2_push_preload on;), то в 
Chrome все ресурсы показываются в DevTools. В FF показываются только те 
ресурсы, которые используются на странице.

При анализе загрузки ресурсов через nghttp -ans или Webpagetest всегда 
(и в http2_push, и в http2_push_preload) видны все push запросы.

Не знаю, бага это или фича, может будет полезно.

-- 

С уважением,
Лавлинский Николай,
Метод Лаб: делаем правильно!
www.methodlab.ru
+7 (499) 519-00-12


From nginx-forum на forum.nginx.org  Tue Feb 27 10:16:24 2018
From: nginx-forum на forum.nginx.org (Dmytro Lavryk)
Date: Tue, 27 Feb 2018 05:16:24 -0500
Subject: =?UTF-8?Q?Re=3A_ipv6_=D0=B8_error_400?=
In-Reply-To: <2d53f9ea-8408-0cca-54ec-b4893b4a7a41@vorona.com.ua>
References: <2d53f9ea-8408-0cca-54ec-b4893b4a7a41@vorona.com.ua>
Message-ID: <19247bbc49ee2a8516bbf68c6d57e7d0.NginxMailingListRussian@forum.nginx.org>

Alex Vorona Wrote:
-------------------------------------------------------
> Hello,
> 
> 
> 26.02.18 12:22, Dmytro Lavryk wrote:
> 
> > Где-то на просторах гугла нарыл совет обязательно убрать строку "ssl
> on;" из
> > конфига. Тайного смысла не понял. но строка была, убрал. Пока
> ответов с
> > кодом 400 нету - наблюдаю. Возможно это и есть решение, только мне
> непонятно
> > "в чем заковыка".
> 
> ssl on; включал SSL на всех listen соответствующего server. Скорее
> всего 
> у вас 400-ки были на 80-м порту, добавление $server_port в формат
> логов 
> при сохранении ssl on сможет ответить на этот вопрос.

Похоже дело именно в ssl on; - после того, как его убрал  - за сутки ни
одного кода ответа 400.

Большое спасибо, всем, принимавшим участие в обсуждении!

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278759,278787#msg-278787


From nginx-forum на forum.nginx.org  Tue Feb 27 12:36:49 2018
From: nginx-forum на forum.nginx.org (digger)
Date: Tue, 27 Feb 2018 07:36:49 -0500
Subject: =?UTF-8?B?0JrQsNC6INC30LDQv9GD0YHRgtC40YLRjCBuZ2lueCDQvdCwIElQLCDQutC+0YI=?=
 =?UTF-8?B?0L7RgNC+0LUg0LLRi9C00LXQu9GP0LXRgtGB0Y8g0YfQtdGA0LXQtyBPcGVu?=
 =?UTF-8?B?VlBO?=
Message-ID: <45649a5044d280d1ab70b7606d81f4ae.NginxMailingListRussian@forum.nginx.org>

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

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

Подскажите, пожалуйста, как лучше организовать такой запуск?
Если через crontab, то как проверять, что nginx запущен, и как его
запустить, если он не работает?
Спасибо!

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


From nefer05 на gmail.com  Tue Feb 27 12:49:15 2018
From: nefer05 на gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=)
Date: Tue, 27 Feb 2018 15:49:15 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0L/Rg9GB0YLQuNGC0Ywgbmdpbngg0L3QsCBJUCwg0Lo=?=
 =?UTF-8?B?0L7RgtC+0YDQvtC1INCy0YvQtNC10LvRj9C10YLRgdGPINGH0LXRgNC10Lcg?=
 =?UTF-8?B?T3BlblZQTg==?=
In-Reply-To: <45649a5044d280d1ab70b7606d81f4ae.NginxMailingListRussian@forum.nginx.org>
References: <45649a5044d280d1ab70b7606d81f4ae.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAE-Urwgkh4_x5Fw6Zuj4pPT+RtL3N3CGdC=LzMvfF4x=1-kUyA@mail.gmail.com>

openvpn умеет дергать скрипт после поднятия и при опущении..

2018-02-27 15:36 GMT+03:00 digger <nginx-forum на forum.nginx.org>:

> Мне нужно запустить nginx на адресе IP, который выделяется клиентом
> OpenVPN.
> Проблема в том, что этот адрес появляется не сразу после загрузки хоста, а
> через некоторое время.
>
> Соответственно, nginx видит, что адреса IP, прописанного в конфиге, нет, и
> не запускается.
> Руками потом запустить можно, но должно запускаться автоматически сразу,
> как
> только IP будет доступен.
>
> Подскажите, пожалуйста, как лучше организовать такой запуск?
> Если через crontab, то как проверять, что nginx запущен, и как его
> запустить, если он не работает?
> Спасибо!
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,278789,278789#msg-278789
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180227/f5d3e364/attachment.html>

From pavel2000 на ngs.ru  Tue Feb 27 12:57:22 2018
From: pavel2000 на ngs.ru (Pavel V.)
Date: Tue, 27 Feb 2018 19:57:22 +0700
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0L/Rg9GB0YLQuNGC0Ywgbmdpbngg0L3QsCBJUCwg0Lo=?=
 =?UTF-8?B?0L7RgtC+0YDQvtC1INCy0YvQtNC10LvRj9C10YLRgdGPINGH0LXRgNC10Lcg?=
 =?UTF-8?B?T3BlblZQTg==?=
In-Reply-To: <45649a5044d280d1ab70b7606d81f4ae.NginxMailingListRussian@forum.nginx.org>
References: <45649a5044d280d1ab70b7606d81f4ae.NginxMailingListRussian@forum.nginx.org>
Message-ID: <374682231.20180227195722@ngs.ru>

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

Вы писали 27 февраля 2018 г., 19:36:49:

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

Это у вас неправильная конфигурация.

Настройте систему, чтобы она автоматически создавала и конфигурировала интерфейс при старте.

должно быть аналогичное тому, что сделает пара команд:

openvpn --mktun --dev tap0
ifconfig tap0 inet 192.168.1.2/24
.... маршрутизация...


В конфиге OpenVPN:

dev tap0
#dev tun0
ifconfig-noexec

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

> Соответственно, nginx видит, что адреса IP, прописанного в конфиге, нет, и
> не запускается.
> Руками потом запустить можно, но должно запускаться автоматически сразу, как
> только IP будет доступен.

> Подскажите, пожалуйста, как лучше организовать такой запуск?
> Если через crontab, то как проверять, что nginx запущен, и как его
> запустить, если он не работает?
> Спасибо!




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


From gmm на csdoc.com  Tue Feb 27 13:46:28 2018
From: gmm на csdoc.com (Gena Makhomed)
Date: Tue, 27 Feb 2018 15:46:28 +0200
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0L/Rg9GB0YLQuNGC0Ywgbmdpbngg0L3QsCBJUCwg0Lo=?=
 =?UTF-8?B?0L7RgtC+0YDQvtC1INCy0YvQtNC10LvRj9C10YLRgdGPINGH0LXRgNC10Lcg?=
 =?UTF-8?B?T3BlblZQTg==?=
In-Reply-To: <45649a5044d280d1ab70b7606d81f4ae.NginxMailingListRussian@forum.nginx.org>
References: <45649a5044d280d1ab70b7606d81f4ae.NginxMailingListRussian@forum.nginx.org>
Message-ID: <81cc7e83-97b0-98c3-c5f4-40eb77454a0a@csdoc.com>

On 27.02.2018 14:36, digger wrote:

> Мне нужно запустить nginx на адресе IP, который выделяется клиентом
> OpenVPN.
> Проблема в том, что этот адрес появляется не сразу после загрузки хоста, а
> через некоторое время.
> 
> Соответственно, nginx видит, что адреса IP, прописанного в конфиге, нет, и
> не запускается.
> Руками потом запустить можно, но должно запускаться автоматически сразу, как
> только IP будет доступен.
> 
> Подскажите, пожалуйста, как лучше организовать такой запуск?

Есть два варианта. Самый простой - это сделать так, чтобы nginx слушал
на всех интерфейсах, везде прописать "listen 80" и не указывать явно IP.

Второй вариант - прописать net.ipv4.ip_nonlocal_bind=1 в sysctl,
тогда nginx запустится, даже если в данный момент IP не доступен.

-- 
Best regards,
  Gena


From nginx-forum на forum.nginx.org  Tue Feb 27 14:30:24 2018
From: nginx-forum на forum.nginx.org (monah1983)
Date: Tue, 27 Feb 2018 09:30:24 -0500
Subject: 400 Bad RequestThe SSL certificate error
Message-ID: <4c5c9fa4217a16824c0b086a1635ccd8.NginxMailingListRussian@forum.nginx.org>

Добрый день!
Есть проблема. 
Есть vps с vestacp. На ней несколько доменов. 
На одном из них включил ssl через Lets Encrypt.
Также включен -  Поддержка ProxyNGINX
Создал сертификат CA, подписал и отдал пользователю сертификат. 
При заходе на сайт, требует сертификат, его выбираю, и потом ошибка 400 Bad
RequestThe SSL certificate error
вот мой конфиг 
server {
    listen      *****:443;
    server_name ***.tk www.***.tk;
    ssl         on;
    ssl_certificate      /home/admin/conf/web/ssl.***.tk.pem; - тут
сертификаты Lets Encrypt
    ssl_certificate_key  /home/admin/conf/web/ssl.***.tk.key; тут
сертификаты Lets Encrypt
    ssl_client_certificate /etc/ssl/***.tk/ca.crt;  - тут мой
    ssl_verify_client on;
    ssl_ciphers
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AES:!ECDH+3DES:!DH+3DES:!RSA+3DES:!aNULL:!MD5:!DSS;
    ssl_verify_depth 1;
    keepalive_timeout 70;
    fastcgi_param SSL_VERIFIED $ssl_client_verify;
    fastcgi_param SSL_CLIENT_SERIAL $ssl_client_serial;
    fastcgi_param SSL_CLIENT_CERT $ssl_client_cert;
    fastcgi_param SSL_DN $ssl_client_s_dn;
    error_log  /var/log/httpd/domains/****.tk.error.log error;

    location / {
        proxy_pass      https://*****:8443;
        location ~*
^.+\.(jpg|jpeg|gif|png|ico|svg|css|zip|tgz|gz|rar|bz2|exe|pdf|doc|xls|ppt|txt|odt|ods|odp|odf|tar|bmp|rtf|js|mp3|avi|mpeg|flv|html|htm)$
{
            root           /home/admin/web/****.tk/public_html;
            access_log     /var/log/httpd/domains/***.tk.log combined;
            access_log     /var/log/httpd/domains/***.tk.bytes bytes;
	
            expires        max;
            try_files      $uri @fallback;
        }
    }

    location /error/ {
        alias   /home/admin/web/***.tk/document_errors/;
    }

    location @fallback {
        proxy_pass      https://*****:8443;
    }

    location ~ /\.ht    {return 404;}
    location ~ /\.svn/  {return 404;}
    location ~ /\.git/  {return 404;}
    location ~ /\.hg/   {return 404;}
    location ~ /\.bzr/  {return 404;}

    include /home/admin/conf/web/snginx.***.tk.conf*;
}
В чем может быть дело?

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


From ru на nginx.com  Tue Feb 27 14:32:39 2018
From: ru на nginx.com (Ruslan Ermilov)
Date: Tue, 27 Feb 2018 17:32:39 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgdGLINC/0L4gaHR0cDIgcHVzaA==?=
In-Reply-To: <3d7f04c7-26f9-6896-f42f-5810928d97f1@methodlab.info>
References: <3d7f04c7-26f9-6896-f42f-5810928d97f1@methodlab.info>
Message-ID: <20180227143239.GG94767@lo0.su>

On Tue, Feb 27, 2018 at 10:17:07AM +0300, Nick Lavlinsky - Method Lab wrote:
> Здравствуйте!
> 
> Начал тестировать http2_push сразу после релиза. Появилось 2 вопроса.
> 
> 1. Есть ли возможность пушить ресурсы до ответа на основной запрос (так 
> делает у себя Fastly, называя async push)? Таким образом можно получить 
> экономию не только в 1RTT, но и за счет серверного времени на генерацию 
> html (https://www.fastly.com/blog/optimizing-http2-server-push-fastly).

Нет, сейчас такой возможности нет и вряд ли она появится.

Сейчас nginx дожидается заголовка ответа на основной запрос,
прежде чем отправить PUSH_PROMISE'ы и собственно начать пушить
ответы.  Причин тому несколько.  Во-первых, это единственный
способ при конвертации Link preload'ов в push'и.  Во-вторых,
если так не делать, и ответа на основной запрос нет (например,
бэкенд неживой), то непонятно, на каком основании вообще мы
должны делать push.

> 2. При использовании директивы http2_push в конфиге сайта браузеры 
> (Chrome Stable и 66, FF 58.0.2) показывают, что только 1 ресурс был 
> запушен, хотя стоят сразу несколько (смотрю в DevTools с отключенным 
> кэшем). Например:
> 
>      location / {
>          proxy_pass http://127.0.0.1:9090/pcgi/index.pl?$uri?&$args;
>          proxy_redirect     off;
> 
>          proxy_set_header   Host             $host;
>          proxy_set_header   X-Real-IP        $remote_addr;
>          proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
> 
>      http2_push /css/colorbox.css;
>      http2_push /img/design/logo.png;
>      http2_push /js/core.js;
>      http2_push /images/border.png;
>      http2_push /img/no_foto.png;
>      http2_push /js/jq/jquery-2.1.3.min.js;
> 
>      }
> 
> В браузерах отображается в виде push только /img/design/logo.png, так 
> как этот ресурс используется на странице (остальные - нет). Поведение 
> одинаково и в Chrome и в FF.
> 
> Если делать push через заголовок Link (http2_push_preload on;), то в 
> Chrome все ресурсы показываются в DevTools.

При этом внизу выдаётся warning, что некоторые ресурсы не используются.

> В FF показываются только те 
> ресурсы, которые используются на странице.
> 
> При анализе загрузки ресурсов через nghttp -ans или Webpagetest всегда 
> (и в http2_push, и в http2_push_preload) видны все push запросы.
> 
> Не знаю, бага это или фича, может будет полезно.

В chrome://net-internals/#http2 видно, что они push'атся.  Почему
так по-разному показывает DevTools, я лично не знаю.  Но это точно
не вопрос к nginx'у.

From mdounin на mdounin.ru  Tue Feb 27 15:32:35 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 27 Feb 2018 18:32:35 +0300
Subject: 400 Bad RequestThe SSL certificate error
In-Reply-To: <4c5c9fa4217a16824c0b086a1635ccd8.NginxMailingListRussian@forum.nginx.org>
References: <4c5c9fa4217a16824c0b086a1635ccd8.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180227153235.GG89840@mdounin.ru>

Hello!

On Tue, Feb 27, 2018 at 09:30:24AM -0500, monah1983 wrote:

> Добрый день!
> Есть проблема. 
> Есть vps с vestacp. На ней несколько доменов. 
> На одном из них включил ssl через Lets Encrypt.
> Также включен -  Поддержка ProxyNGINX
> Создал сертификат CA, подписал и отдал пользователю сертификат. 
> При заходе на сайт, требует сертификат, его выбираю, и потом ошибка 400 Bad
> RequestThe SSL certificate error
> вот мой конфиг 
> server {
>     listen      *****:443;
>     server_name ***.tk www.***.tk;
>     ssl         on;
>     ssl_certificate      /home/admin/conf/web/ssl.***.tk.pem; - тут
> сертификаты Lets Encrypt
>     ssl_certificate_key  /home/admin/conf/web/ssl.***.tk.key; тут
> сертификаты Lets Encrypt
>     ssl_client_certificate /etc/ssl/***.tk/ca.crt;  - тут мой
>     ssl_verify_client on;
>     ssl_ciphers
> ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AES:!ECDH+3DES:!DH+3DES:!RSA+3DES:!aNULL:!MD5:!DSS;
>     ssl_verify_depth 1;
>     keepalive_timeout 70;
>     fastcgi_param SSL_VERIFIED $ssl_client_verify;
>     fastcgi_param SSL_CLIENT_SERIAL $ssl_client_serial;
>     fastcgi_param SSL_CLIENT_CERT $ssl_client_cert;
>     fastcgi_param SSL_DN $ssl_client_s_dn;
>     error_log  /var/log/httpd/domains/****.tk.error.log error;

[...]

> В чем может быть дело?

В случае ошибок проверки сертификата - подробности логгируются в 
error log на уровне info.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Tue Feb 27 15:50:26 2018
From: nginx-forum на forum.nginx.org (monah1983)
Date: Tue, 27 Feb 2018 10:50:26 -0500
Subject: 400 Bad RequestThe SSL certificate error
In-Reply-To: <20180227153235.GG89840@mdounin.ru>
References: <20180227153235.GG89840@mdounin.ru>
Message-ID: <971a14b487772f7911b45948d70fc4d7.NginxMailingListRussian@forum.nginx.org>

а где именно искать этот лог?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278799,278805#msg-278805


From nginx-forum на forum.nginx.org  Tue Feb 27 15:51:46 2018
From: nginx-forum на forum.nginx.org (monah1983)
Date: Tue, 27 Feb 2018 10:51:46 -0500
Subject: 400 Bad RequestThe SSL certificate error
In-Reply-To: <20180227153235.GG89840@mdounin.ru>
References: <20180227153235.GG89840@mdounin.ru>
Message-ID: <f13c51740744ed84ac4a8565ce2f3152.NginxMailingListRussian@forum.nginx.org>

2018/02/27 17:07:51 [alert] 6852#6852: *36 ignoring stale global SSL error
(SSL: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message
digest algorithm) while waiting for request, client: 000000, server:
000000:443
2018/02/27 17:22:56 [alert] 6852#6852: *350 ignoring stale global SSL error
(SSL: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message
digest algorithm) while waiting for request, client: 0000, server: 000:443

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278799,278806#msg-278806


From nginx-forum на forum.nginx.org  Tue Feb 27 16:17:40 2018
From: nginx-forum на forum.nginx.org (monah1983)
Date: Tue, 27 Feb 2018 11:17:40 -0500
Subject: 400 Bad RequestThe SSL certificate error
In-Reply-To: <20180227153235.GG89840@mdounin.ru>
References: <20180227153235.GG89840@mdounin.ru>
Message-ID: <5a3e2d53ab0a2fa6cfd532db636f300c.NginxMailingListRussian@forum.nginx.org>

[Tue Feb 27 15:27:04.404778 2018] [mpm_prefork:notice] [pid 2298] AH00163:
Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 PHP/5.6.30
configured -- resuming normal operations
[Tue Feb 27 15:27:04.404824 2018] [core:notice] [pid 2298] AH00094: Command
line: '/usr/sbin/httpd -D FOREGROUND'
[Tue Feb 27 16:00:24.650271 2018] [mpm_prefork:notice] [pid 2298] AH00170:
caught SIGWINCH, shutting down gracefully
[Tue Feb 27 16:00:25.875222 2018] [suexec:notice] [pid 3500] AH01232: suEXEC
mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Feb 27 16:00:25.876857 2018] [ssl:warn] [pid 3500] AH02292: Init:
Name-based SSL virtual hosts only work for clients with TLS server name
indication support (RFC 4366)
[Tue Feb 27 16:00:25.894014 2018] [so:warn] [pid 3500] AH01574: module
ruid2_module is already loaded, skipping
[Tue Feb 27 16:00:25.987414 2018] [auth_digest:notice] [pid 3500] AH01757:
generating secret for digest authentication ...
[Tue Feb 27 16:00:25.989736 2018] [ssl:warn] [pid 3500] AH02292: Init:
Name-based SSL virtual hosts only work for clients with TLS server name
indication support (RFC 4366)
[Tue Feb 27 16:00:25.991203 2018] [:notice] [pid 3500] mod_ruid2/0.9.8
enabled
[Tue Feb 27 16:00:26.130481 2018] [mpm_prefork:notice] [pid 3500] AH00163:
Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 PHP/5.6.30
configured -- resuming normal operations
[Tue Feb 27 16:00:26.130545 2018] [core:notice] [pid 3500] AH00094: Command
line: '/usr/sbin/httpd -D FOREGROUND'

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278799,278807#msg-278807


From mdounin на mdounin.ru  Tue Feb 27 17:40:34 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 27 Feb 2018 20:40:34 +0300
Subject: 400 Bad RequestThe SSL certificate error
In-Reply-To: <971a14b487772f7911b45948d70fc4d7.NginxMailingListRussian@forum.nginx.org>
References: <20180227153235.GG89840@mdounin.ru>
 <971a14b487772f7911b45948d70fc4d7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180227174034.GI89840@mdounin.ru>

Hello!

On Tue, Feb 27, 2018 at 10:50:26AM -0500, monah1983 wrote:

> а где именно искать этот лог?

В сообщении, на которое вы отвечали, директива "error_log" была 
процитирована не просто так.

Отмечу также, что в ней уровень логгирования был установлен в 
"error", а нужно - "info".

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin на mdounin.ru  Tue Feb 27 17:52:11 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 27 Feb 2018 20:52:11 +0300
Subject: 400 Bad RequestThe SSL certificate error
In-Reply-To: <f13c51740744ed84ac4a8565ce2f3152.NginxMailingListRussian@forum.nginx.org>
References: <20180227153235.GG89840@mdounin.ru>
 <f13c51740744ed84ac4a8565ce2f3152.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180227175211.GJ89840@mdounin.ru>

Hello!

On Tue, Feb 27, 2018 at 10:51:46AM -0500, monah1983 wrote:

> 2018/02/27 17:07:51 [alert] 6852#6852: *36 ignoring stale global SSL error
> (SSL: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message
> digest algorithm) while waiting for request, client: 000000, server:
> 000000:443
> 2018/02/27 17:22:56 [alert] 6852#6852: *350 ignoring stale global SSL error
> (SSL: error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message
> digest algorithm) while waiting for request, client: 0000, server: 000:443

Проверьте, с какой версией OpenSSL собран nginx ("nginx -V"), и что
именно используется в сертификатах ("openssl x509 -text -noout -in <cert>").

Если я правильно понимаю, такие ошибки будут, например, если 
пытаться использовать OpenSSL 0.9.7 с современными сертификатами, 
подписанными с помощью SHA256.  С другой стороны - непонятно, 
откуда в современном мире может взяться OpenSSL 0.9.7, так что 
возможно, вы сделали что-то экзотическое при генерации 
сертификата.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin на mdounin.ru  Tue Feb 27 18:01:36 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 27 Feb 2018 21:01:36 +0300
Subject: 400 Bad RequestThe SSL certificate error
In-Reply-To: <5a3e2d53ab0a2fa6cfd532db636f300c.NginxMailingListRussian@forum.nginx.org>
References: <20180227153235.GG89840@mdounin.ru>
 <5a3e2d53ab0a2fa6cfd532db636f300c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180227180136.GK89840@mdounin.ru>

Hello!

On Tue, Feb 27, 2018 at 11:17:40AM -0500, monah1983 wrote:

> [Tue Feb 27 15:27:04.404778 2018] [mpm_prefork:notice] [pid 2298] AH00163:
> Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 PHP/5.6.30
> configured -- resuming normal operations

[...]

Это всё имеет мало отношения к nginx'у, так как приведён лог от 
Apache, но если в системе действительно используется OpenSSL-fips, 
то это может накладывать массу неочевидных ограничений, жить с 
которыми - может оказаться нетривальным.

В данном случае - возможно, дело в том, что вы сгенерили 
сертификат с использованием MD5 в подписи, и это приводит к 
ошибкам, потому что в OpenSSL-fips нет MD5.  Если это так, то в 
данном случае FIPS-ограничения всё сделали правильно: не надо 
использовать сертификаты с MD5, это небезопасно.  Впрочем, в 
современных версиях OpenSSL ошибка тоже была бы, и была бы куда 
более читаемой.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Tue Feb 27 18:09:00 2018
From: nginx-forum на forum.nginx.org (monah1983)
Date: Tue, 27 Feb 2018 13:09:00 -0500
Subject: 400 Bad RequestThe SSL certificate error
In-Reply-To: <20180227175211.GJ89840@mdounin.ru>
References: <20180227175211.GJ89840@mdounin.ru>
Message-ID: <312813b9f0f8a409c87191eb218d5781.NginxMailingListRussian@forum.nginx.org>

nginx version: nginx/1.12.2
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC)
built with OpenSSL 1.0.2k-fips  26 Jan 2017
TLS SNI support enabled

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278799,278813#msg-278813


From nginx-forum на forum.nginx.org  Tue Feb 27 18:49:02 2018
From: nginx-forum на forum.nginx.org (monah1983)
Date: Tue, 27 Feb 2018 13:49:02 -0500
Subject: 400 Bad RequestThe SSL certificate error
In-Reply-To: <20180227180136.GK89840@mdounin.ru>
References: <20180227180136.GK89840@mdounin.ru>
Message-ID: <f259f8a24ffb675dc11f10c9db2a3fbc.NginxMailingListRussian@forum.nginx.org>

все получилось))) поменял MD5 на sha256

пользовался вот это инструкцией https://habrahabr.ru/post/349720/
СПАСИБО!!!!

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278799,278815#msg-278815


From nginx-forum на forum.nginx.org  Tue Feb 27 19:11:54 2018
From: nginx-forum на forum.nginx.org (S.A.N)
Date: Tue, 27 Feb 2018 14:11:54 -0500
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgdGLINC/0L4gaHR0cDIgcHVzaA==?=
In-Reply-To: <3d7f04c7-26f9-6896-f42f-5810928d97f1@methodlab.info>
References: <3d7f04c7-26f9-6896-f42f-5810928d97f1@methodlab.info>
Message-ID: <92de6b979234bcb269a1ca73c66cca69.NginxMailingListRussian@forum.nginx.org>

Я не вижу большой пользы от push, очень редкий случай когда нужно отправить
дополнительный  не кешируемый контент без запросов, или я ошибаюсь, вы
можете перечислить свои use case?

Спасибо.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278784,278816#msg-278816


From nginx-forum на forum.nginx.org  Tue Feb 27 19:19:24 2018
From: nginx-forum на forum.nginx.org (digger)
Date: Tue, 27 Feb 2018 14:19:24 -0500
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0L/Rg9GB0YLQuNGC0Ywgbmdpbngg0L3QsCBJUCwg0Lo=?=
 =?UTF-8?B?0L7RgtC+0YDQvtC1INCy0YvQtNC10LvRj9C10YLRgdGPINGH0LXRgNC10Lcg?=
 =?UTF-8?B?T3BlblZQTg==?=
In-Reply-To: <81cc7e83-97b0-98c3-c5f4-40eb77454a0a@csdoc.com>
References: <81cc7e83-97b0-98c3-c5f4-40eb77454a0a@csdoc.com>
Message-ID: <67588c0acf3f2ac80bb15d81fa5d55ae.NginxMailingListRussian@forum.nginx.org>

Огромное спасибо! Действительно, достаточно было запустить nginx на всех
интерфейсах, и все получилось как надо.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278789,278808#msg-278808


From nick на methodlab.info  Wed Feb 28 06:40:39 2018
From: nick на methodlab.info (Nick Lavlinsky - Method Lab)
Date: Wed, 28 Feb 2018 09:40:39 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgdGLINC/0L4gaHR0cDIgcHVzaA==?=
In-Reply-To: <92de6b979234bcb269a1ca73c66cca69.NginxMailingListRussian@forum.nginx.org>
References: <3d7f04c7-26f9-6896-f42f-5810928d97f1@methodlab.info>
 <92de6b979234bcb269a1ca73c66cca69.NginxMailingListRussian@forum.nginx.org>
Message-ID: <fb3d5b6e-3543-b4b3-b3ea-2aaf5eafb490@methodlab.info>

27.02.2018 22:11, S.A.N пишет:
> Я не вижу большой пользы от push, очень редкий случай когда нужно отправить
> дополнительный  не кешируемый контент без запросов, или я ошибаюсь, вы
> можете перечислить свои use case?
>
> Спасибо.
>
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278784,278816#msg-278816
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

Не совсем понял ваши слова про "не кешируемый контент".

А use case простой: замена inline CSS, который блокирует отрисовку 
страницы. А также любые ресурсы из критического пути рендеринга страницы.

-- 

С уважением,
Лавлинский Николай,
Метод Лаб: делаем правильно!
www.methodlab.ru
+7 (499) 519-00-12


From nick на methodlab.info  Wed Feb 28 06:41:01 2018
From: nick на methodlab.info (Nick Lavlinsky - Method Lab)
Date: Wed, 28 Feb 2018 09:41:01 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgdGLINC/0L4gaHR0cDIgcHVzaA==?=
In-Reply-To: <20180227143239.GG94767@lo0.su>
References: <3d7f04c7-26f9-6896-f42f-5810928d97f1@methodlab.info>
 <20180227143239.GG94767@lo0.su>
Message-ID: <19c67b5b-9fed-dc53-afae-ea75d2d23da9@methodlab.info>

27.02.2018 17:32, Ruslan Ermilov пишет:
>
> Нет, сейчас такой возможности нет и вряд ли она появится.
>
> Сейчас nginx дожидается заголовка ответа на основной запрос,
> прежде чем отправить PUSH_PROMISE'ы и собственно начать пушить
> ответы.  Причин тому несколько.  Во-первых, это единственный
> способ при конвертации Link preload'ов в push'и.  Во-вторых,
> если так не делать, и ответа на основной запрос нет (например,
> бэкенд неживой), то непонятно, на каком основании вообще мы
> должны делать push.
>

Очень жаль, такой режим увеличил бы эффективность server push 
радикально. Понятно, что делать такое поведение по умолчанию не стоит, 
но если сделать специальную опцию (с описанием и предостережениями), то 
я не вижу проблем. Если бекенд не живой, то путь пройдёт Push, скорее 
всего в нём будет статика, которая не зависит от бекенда.

-- 

С уважением,
Лавлинский Николай,
Метод Лаб: делаем правильно!
www.methodlab.ru
+7 (499) 519-00-12


From nginx-forum на forum.nginx.org  Wed Feb 28 08:40:41 2018
From: nginx-forum на forum.nginx.org (S.A.N)
Date: Wed, 28 Feb 2018 03:40:41 -0500
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgdGLINC/0L4gaHR0cDIgcHVzaA==?=
In-Reply-To: <fb3d5b6e-3543-b4b3-b3ea-2aaf5eafb490@methodlab.info>
References: <fb3d5b6e-3543-b4b3-b3ea-2aaf5eafb490@methodlab.info>
Message-ID: <48d030e6a198b06ce76be7c242acd24c.NginxMailingListRussian@forum.nginx.org>

> Не совсем понял ваши слова про "не кешируемый контент".

По спецификации НТТР 2, браузер push ответы могут кешировать только в
отдельном кеше соединенния (смотрите на connection_id в devtools), после
закрытия соединения кеш очищается.
Или я не прав, браузеры сохранят push ответы в общем кеше и потом можно их
использовать в разных connection и ревалидировать?
 
> А use case простой: замена inline CSS, который блокирует отрисовку 
> страницы. А также любые ресурсы из критического пути рендеринга
> страницы.

Для этих целей лучше использовать отдельные запросы, с заголовками НТТР
кешированием на год и инвалидировать этот кеш только по изменению юрл.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278784,278821#msg-278821


From nick на methodlab.info  Wed Feb 28 09:45:07 2018
From: nick на methodlab.info (Nick Lavlinsky - Method Lab)
Date: Wed, 28 Feb 2018 12:45:07 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgdGLINC/0L4gaHR0cDIgcHVzaA==?=
In-Reply-To: <48d030e6a198b06ce76be7c242acd24c.NginxMailingListRussian@forum.nginx.org>
References: <fb3d5b6e-3543-b4b3-b3ea-2aaf5eafb490@methodlab.info>
 <48d030e6a198b06ce76be7c242acd24c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3d17682e-3094-3606-d135-d94f45a17c7f@methodlab.info>

28.02.2018 11:40, S.A.N пишет:
>> Не совсем понял ваши слова про "не кешируемый контент".
> По спецификации НТТР 2, браузер push ответы могут кешировать только в
> отдельном кеше соединенния (смотрите на connection_id в devtools), после
> закрытия соединения кеш очищается.
> Или я не прав, браузеры сохранят push ответы в общем кеше и потом можно их
> использовать в разных connection и ревалидировать?

Нет, есть разные кеши: push cache и http cache. Наоборот, при push по 
спецификации рекомендуется использовать кешируемые ответы (все заголовки 
при push приходят как обычно). Push cache очищается при закрытии 
соединения, но все элементы при первом использовании браузером будут 
помещены в http cache, так что всё нормально.
Подробнее здесь: 
https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/

>> А use case простой: замена inline CSS, который блокирует отрисовку
>> страницы. А также любые ресурсы из критического пути рендеринга
>> страницы.
> Для этих целей лучше использовать отдельные запросы, с заголовками НТТР
> кешированием на год и инвалидировать этот кеш только по изменению юрл.
Push делает то же самое, только без ожидания запроса (экономия до 1RTT).
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278784,278821#msg-278821
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


-- 

С уважением,
Лавлинский Николай,
Метод Лаб: делаем правильно!
www.methodlab.ru
+7 (499) 519-00-12


From nginx-forum на forum.nginx.org  Wed Feb 28 09:59:31 2018
From: nginx-forum на forum.nginx.org (S.A.N)
Date: Wed, 28 Feb 2018 04:59:31 -0500
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgdGLINC/0L4gaHR0cDIgcHVzaA==?=
In-Reply-To: <3d17682e-3094-3606-d135-d94f45a17c7f@methodlab.info>
References: <3d17682e-3094-3606-d135-d94f45a17c7f@methodlab.info>
Message-ID: <c6103a73a3b3de288663f218f77059a7.NginxMailingListRussian@forum.nginx.org>

> Push cache очищается при закрытии 
> соединения, но все элементы при первом использовании браузером будут 
> помещены в http cache, так что всё нормально.
> Подробнее здесь: 
> https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/

Если ресурс отданный push ответом, используется на странице и в ответе были
заголовки НТТР кеширование, браузер этот ресурс перемещает в НТТР кеш?
Когда я экспериментировал с push ответами, браузеры не перемещал push
ресурсы в НТТР кеш, вы тестировали только в новом Chrome, как обстоят дела в
других браузерах?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278784,278824#msg-278824


From nick на methodlab.info  Wed Feb 28 13:15:50 2018
From: nick на methodlab.info (Nick Lavlinsky - Method Lab)
Date: Wed, 28 Feb 2018 16:15:50 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgdGLINC/0L4gaHR0cDIgcHVzaA==?=
In-Reply-To: <c6103a73a3b3de288663f218f77059a7.NginxMailingListRussian@forum.nginx.org>
References: <3d17682e-3094-3606-d135-d94f45a17c7f@methodlab.info>
 <c6103a73a3b3de288663f218f77059a7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <7681b5ee-4eda-d6c2-7811-b96cb54a5282@methodlab.info>

28.02.2018 12:59, S.A.N пишет:
> Если ресурс отданный push ответом, используется на странице и в ответе 
> были
> заголовки НТТР кеширование, браузер этот ресурс перемещает в НТТР кеш?

Да.
> Когда я экспериментировал с push ответами, браузеры не перемещал push
> ресурсы в НТТР кеш, вы тестировали только в новом Chrome, как обстоят дела в
> других браузерах?
Сейчас потестил в Сhrome 66, FF 58.0.2 всё работает правильно, кеширует 
ресурсы, которые были запушены и использованы.

> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,278784,278824#msg-278824
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


-- 

С уважением,
Лавлинский Николай,
Метод Лаб: делаем правильно!
www.methodlab.ru
+7 (499) 519-00-12


From nginx-forum на forum.nginx.org  Wed Feb 28 21:15:45 2018
From: nginx-forum на forum.nginx.org (gz)
Date: Wed, 28 Feb 2018 16:15:45 -0500
Subject: nginx 1.11 + fast-cgi cache + map + ssi
In-Reply-To: <684d5f96d9c207b204bbc7d568c0a3c7.NginxMailingListRussian@forum.nginx.org>
References: <684d5f96d9c207b204bbc7d568c0a3c7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <8e78c5236b54bf93e838db55c793d52c.NginxMailingListRussian@forum.nginx.org>

Укажите флаг volatile, чтобы значения не кэшировались после первого
вычисления в рамках основного запроса.

map $request_uri $fastcgi_cache_key {
	volatile;

	default
$request_method|$host|$uri|$request_uri|$cookie_currency|$cookie_show_mode;
	~^/objekti/.+
$request_method|$host|$uri|$request_uri|$cookie_currency|$http_x_requested_with;
	~^/xml/yml.php $request_method|$host|$uri|$arg_type|$arg_nosim;
}

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267467,278848#msg-278848