From onokonem at gmail.com  Sun Jun  1 04:26:50 2014
From: onokonem at gmail.com (Daniel Podolsky)
Date: Sun, 1 Jun 2014 08:26:50 +0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LjQsdC40YLRjCDRgdC/0LXRhtC40YTQuNGH0LXRgdC6?=
 =?UTF-8?B?0LjRhSDQsdC+0YLQvtCyINGB0YDQtdC00YHRgtCy0LDQvNC4IE5naW54?=
In-Reply-To: <2ec36f4bd15df5331ef41f4f6646176d.NginxMailingListRussian@forum.nginx.org>
References: <1193793177.20140531234406@softsearch.ru>
 <2ec36f4bd15df5331ef41f4f6646176d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKaHDOGuWMYs38yRWaX3PhDXegpun4ej3nVJsJ1GG2n=wQGQYA@mail.gmail.com>

2014-06-01 0:04 GMT+04:00 lisua <nginx-forum at nginx.us>:
> неужели Nginx не умеет с отлупом 444 банить по сигнатуре http хедера досих
> пор ?
с одной стороны - умеет.

с другой - какой в этом смысл? мы же хотим защитить nginx от бездарной
траты ресурсов на этих ботов, так?

а для того, чтобы "банить по сигнатуре http хедера" - надо и
соединение установить, и хедер принять, потом распарсить.

банить на файрволе - хоть бы и непосредственно на самой машине с nginx
- гораздо эффективнее

From nginx-forum at nginx.us  Sun Jun  1 09:03:26 2014
From: nginx-forum at nginx.us (lisua)
Date: Sun, 01 Jun 2014 05:03:26 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LjQsdC40YLRjCDRgdC/0LXRhtC40YTQuNGH0LXRgdC6?=
 =?UTF-8?B?0LjRhSDQsdC+0YLQvtCyINGB0YDQtdC00YHRgtCy0LDQvNC4IE5naW54?=
In-Reply-To: <CAKaHDOGuWMYs38yRWaX3PhDXegpun4ej3nVJsJ1GG2n=wQGQYA@mail.gmail.com>
References: <CAKaHDOGuWMYs38yRWaX3PhDXegpun4ej3nVJsJ1GG2n=wQGQYA@mail.gmail.com>
Message-ID: <e335dc01bacb8cc713007b6678ff1aeb.NginxMailingListRussian@forum.nginx.org>

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

Ну коли мне тут из знатоков помогать не собирается, пожалуй я тоже своё
решение в паблик не выложу, это конечно хамство, но тут 2 варианта:

1) Никто не знает ответов на эти вопросы (именитые админы с форума SE
понтовались дай денег и тп, но никто ничего не предложил по факту также
никакого рабочего варианта)

2) Всячески пытаются склонить на термоядерную подписку по Nginx plus

Свой вопрос я в принципе решил уже самостоятельно, привет Grep, awk  и
Google :)

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


From mail at knutov.com  Sun Jun  1 09:12:55 2014
From: mail at knutov.com (Nick Knutov)
Date: Sun, 01 Jun 2014 13:12:55 +0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LjQsdC40YLRjCDRgdC/0LXRhtC40YTQuNGH0LXRgdC6?=
 =?UTF-8?B?0LjRhSDQsdC+0YLQvtCyINGB0YDQtdC00YHRgtCy0LDQvNC4IE5naW54?=
In-Reply-To: <1193793177.20140531234406@softsearch.ru>
References: <e67775aaf7d6972685fd50ba59c65e2c.NginxMailingListRussian@forum.nginx.org>
 <1193793177.20140531234406@softsearch.ru>
Message-ID: <538AEE97.70406@knutov.com>

Это плохой путь. ип адресов может быть очень много.
Лучше почитать документацию и на map/if сделать правила на заголовки.


31.05.2014 23:44, Михаил Монашёв пишет:
[...]
> 
> Пиши лог нужные поля, а в цикле с паузой в секунду грепай этой лог по
> известным значения, вытаскивай ip и бань по нему силами фаервола.
> 
> Это почти реально время, не ресурсозатратно и весьма гибко.
> 
> Со временем можно будет дополнять правила, по которым ip надо
> вытаскивать.
> 

-- 
Best Regards,
Nick Knutov
http://knutov.com
ICQ: 272873706
Voice: +7-904-84-23-130


From a.vasilishin at kpi.ua  Sun Jun  1 10:28:51 2014
From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=)
Date: Sun, 01 Jun 2014 13:28:51 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LjQsdC40YLRjCDRgdC/0LXRhtC40YTQuNGH0LXRgdC6?=
 =?UTF-8?B?0LjRhSDQsdC+0YLQvtCyINGB0YDQtdC00YHRgtCy0LDQvNC4IE5naW54?=
In-Reply-To: <e335dc01bacb8cc713007b6678ff1aeb.NginxMailingListRussian@forum.nginx.org>
References: <CAKaHDOGuWMYs38yRWaX3PhDXegpun4ej3nVJsJ1GG2n=wQGQYA@mail.gmail.com>
 <e335dc01bacb8cc713007b6678ff1aeb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <538B0063.1060301@kpi.ua>

01.06.2014 12:03, lisua пишет:
> А, по существу по человечески про формат кастом лога я так понимаю мне никто
> не ответит ?

Что сложно прочитать 
http://nginx.org/ru/docs/http/ngx_http_log_module.html#log_format и 
http://nginx.org/ru/docs/http/ngx_http_core_module.html#variables и 
составить свой лог-формат типа:

log_format bots '$remote_addr $http_keep_alive $http_accept_language'

и потом в конфиге хоста:
	access_log  /var/log/nginx/bots.log;

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

> Задача не допустить зверят до бекенда Nginx стоит на фильтрующей проксе.
>
> Ну коли мне тут из знатоков помогать не собирается, пожалуй я тоже своё
> решение в паблик не выложу, это конечно хамство, но тут 2 варианта:
>
> 1) Никто не знает ответов на эти вопросы (именитые админы с форума SE
> понтовались дай денег и тп, но никто ничего не предложил по факту также
> никакого рабочего варианта)

напугали ежа голой жопой

>
> 2) Всячески пытаются склонить на термоядерную подписку по Nginx plus
>
> Свой вопрос я в принципе решил уже самостоятельно, привет Grep, awk  и
> Google :)


ну, вот же, главное захотеть.


From postmaster at softsearch.ru  Sun Jun  1 13:47:40 2014
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Sun, 1 Jun 2014 17:47:40 +0400
Subject: =?UTF-8?B?UmVbMl06INCa0LDQuiDQv9GA0LjQsdC40YLRjCDRgdC/0LXRhtC40YTQuNGH0LU=?=
 =?UTF-8?B?0YHQutC40YUg0LHQvtGC0L7QsiDRgdGA0LXQtNGB0YLQstCw0LzQuCBOZ2lu?=
 =?UTF-8?B?eA==?=
In-Reply-To: <538AEE97.70406@knutov.com>
References: <e67775aaf7d6972685fd50ba59c65e2c.NginxMailingListRussian@forum.nginx.org>
 <1193793177.20140531234406@softsearch.ru> <538AEE97.70406@knutov.com>
Message-ID: <07440774.20140601174740@softsearch.ru>

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

> Это плохой путь. ип адресов может быть очень много.

И чем именно это плохо?

> Лучше почитать документацию и на map/if сделать правила на заголовки.

Прочитать документацию - это всегда самое лучшее. Особенно в данном
случае.

А правила так можно только простейшие написать. Если понадобится
что-то вроде: сначала зашёл на страницу такую-то, а потом запросов к
картинкам с реферером предыдущей страницы не было, то как это на map
написать?

> 31.05.2014 23:44, Михаил Монашёв пишет:
> [...]
>> 
>> Пиши лог нужные поля, а в цикле с паузой в секунду грепай этой лог по
>> известным значения, вытаскивай ip и бань по нему силами фаервола.
>> 
>> Это почти реально время, не ресурсозатратно и весьма гибко.
>> 
>> Со временем можно будет дополнять правила, по которым ip надо
>> вытаскивать.
>> 




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


From nginx-forum at nginx.us  Mon Jun  2 07:32:06 2014
From: nginx-forum at nginx.us (Brazzford)
Date: Mon, 02 Jun 2014 03:32:06 -0400
Subject: =?UTF-8?B?0J/QvtGH0LXQvNGDINC90LDQs9GA0YPQttCw0LXRgtGB0Y8g0YLQvtC70YzQutC+?=
 =?UTF-8?B?IDEgd29ya2VyPw==?=
Message-ID: <f7992d3a5e2072765706f9959d54d3b5.NginxMailingListRussian@forum.nginx.org>

Здравствуйте! У меня VPS с одно ядерным процессором. В конфиге Nginx
поставлено 2 worker'а. Когда я делаю тест с помощью AB, вижу,  что всю
нагрузку принимает либо первый либо второй worker. Именно поэтому
рекомендуют запускать количество worker'ов равных числу ядер? Потому что
остальные задействованы не будут? А почему два worker'a не могут
распределить нагрузку между собой, работая на одном ядре процессора? Я знаю,
что одно ядро, в одно и тоже время может выполнять только один процесс, но
ведь существует переключатель процессов, который с одного процесса
переключается на другой... и я не могу понять почему у меня нагружается
только один worker. Помогите пожалуйста понять суть дела.

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


From vbart at nginx.com  Mon Jun  2 09:37:11 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Mon, 02 Jun 2014 13:37:11 +0400
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQvdCw0LPRgNGD0LbQsNC10YLRgdGPINGC0L7Qu9GM?=
 =?UTF-8?B?0LrQviAxIHdvcmtlcj8=?=
In-Reply-To: <f7992d3a5e2072765706f9959d54d3b5.NginxMailingListRussian@forum.nginx.org>
References: <f7992d3a5e2072765706f9959d54d3b5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1683647.37GgLVxkHv@vbart-workstation>

On Monday 02 June 2014 03:32:06 Brazzford wrote:
> Здравствуйте! У меня VPS с одно ядерным процессором. В конфиге Nginx
> поставлено 2 worker'а. Когда я делаю тест с помощью AB, вижу,  что всю
> нагрузку принимает либо первый либо второй worker. Именно поэтому
> рекомендуют запускать количество worker'ов равных числу ядер? Потому что
> остальные задействованы не будут? А почему два worker'a не могут
> распределить нагрузку между собой, работая на одном ядре процессора? Я знаю,
> что одно ядро, в одно и тоже время может выполнять только один процесс, но
> ведь существует переключатель процессов, который с одного процесса
> переключается на другой... и я не могу понять почему у меня нагружается
> только один worker. Помогите пожалуйста понять суть дела.
> 

Стоит указать операционную систему.

Если это Linux, то по всей видимости вы сами так настроили,
разрешив multi_accept.

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

From nginx-forum at nginx.us  Mon Jun  2 10:00:08 2014
From: nginx-forum at nginx.us (Brazzford)
Date: Mon, 02 Jun 2014 06:00:08 -0400
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQvdCw0LPRgNGD0LbQsNC10YLRgdGPINGC0L7Qu9GM?=
 =?UTF-8?B?0LrQviAxIHdvcmtlcj8=?=
In-Reply-To: <1683647.37GgLVxkHv@vbart-workstation>
References: <1683647.37GgLVxkHv@vbart-workstation>
Message-ID: <2dcb76deb22d9bf6a230d17e9efae2e6.NginxMailingListRussian@forum.nginx.org>

У меня ubuntu 12.04. multi_accept on - закомментирован. И всё равно
получается так, что, например, один worker 50% CPU, а второй 0%


Валентин Бартенев Wrote:
-------------------------------------------------------
> On Monday 02 June 2014 03:32:06 Brazzford wrote:
> > Здравствуйте! У меня VPS с одно ядерным процессором. В конфиге Nginx
> > поставлено 2 worker'а. Когда я делаю тест с помощью AB, вижу,  что
> всю
> > нагрузку принимает либо первый либо второй worker. Именно поэтому
> > рекомендуют запускать количество worker'ов равных числу ядер? Потому
> что
> > остальные задействованы не будут? А почему два worker'a не могут
> > распределить нагрузку между собой, работая на одном ядре процессора?
> Я знаю,
> > что одно ядро, в одно и тоже время может выполнять только один
> процесс, но
> > ведь существует переключатель процессов, который с одного процесса
> > переключается на другой... и я не могу понять почему у меня
> нагружается
> > только один worker. Помогите пожалуйста понять суть дела.
> > 
> 
> Стоит указать операционную систему.
> 
> Если это Linux, то по всей видимости вы сами так настроили,
> разрешив multi_accept.
> 
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

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


From nginx-forum at nginx.us  Mon Jun  2 13:18:57 2014
From: nginx-forum at nginx.us (iron.udjin)
Date: Mon, 02 Jun 2014 09:18:57 -0400
Subject: =?UTF-8?B?c2VydmVyIG5hbWVzINC/0YDQuCDQv9GA0L7QstC10YDQutC1IHZhbGlkIHJlZmVy?=
 =?UTF-8?B?ZXJz?=
Message-ID: <02be80d38ac47bd9b85583f1fb5b703f.NginxMailingListRussian@forum.nginx.org>

Доброго времени суток,

Имеется:
server {
        listen 80;
        server_name _;
        ...
}

При проверке valid_referers:
 location ~* ^.+\.(jpg|jpeg|gif|css|png|js|ico|bmp)$ {
        valid_referers none blocked server_names *.domain.com;
        if ($invalid_referer) {
              return   403;
        }
}

... в server_names не присутствует доменное имя по которому клиент пришел на
сайт.
Смысл таков: при регистрации на сайте пользователь получает сабдомен
<username>.domain.com (именно по этому все запросы отправляются в
"server_name _" да бы не клепать сотни виртуалхостов). Но при желании он
может подключить свой домен к сервису. Хочется пресечь возможность
хотлинкинга загружаемых им статических файлов. Пробовал добавлять $host в
valid_referers, но так не работает. Подскажите пожалуйста как решить данную
проблему.

Заранее благодарен!

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


From nginx-forum at nginx.us  Mon Jun  2 14:53:40 2014
From: nginx-forum at nginx.us (chebevara)
Date: Mon, 02 Jun 2014 10:53:40 -0400
Subject: =?UTF-8?B?UmU6IFNTTCDQntGI0LjQsdC60LA=?=
In-Reply-To: <CAKqRTSHeHeXSNHN2vR=wyn5FDOfb5BXeV2bQBmysEjvZZfe4iQ@mail.gmail.com>
References: <CAKqRTSHeHeXSNHN2vR=wyn5FDOfb5BXeV2bQBmysEjvZZfe4iQ@mail.gmail.com>
Message-ID: <ddd2a5c95af55379b83a4381b37c9187.NginxMailingListRussian@forum.nginx.org>

Aleksandr Sytar Wrote:
-------------------------------------------------------
> 5 января 2014 г., 1:55 пользователь mishatatinets
> <nginx-forum at nginx.us>написал:
> 
> > Я пытаюсь установить сертификат, но мне при тестировании выкидывает
> > следующую ошибку.
> >
> > nginx: [emerg] BIO_new_file("/etc/nginx/certificates/domain.crt")
> failed
> > (SSL: error:02001002:system library:fopen:No such file or
> > directory:fopen('/etc/nginx/certificates/domain.crt','r')
> > error:2006D080:BIO
> > routines:BIO_new_file:no such file)
> >
> >                                     ^^^^^^^^^^^^^
> 
> Очевидно же: либо нет файла по указанному пути, либо nginx не имеет
> прав
> его читать.
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Добрый день.

У меня возникла аналогичная проблема.
Не могу понять что не так делаю.

Тестовый сервер, Есть nginx, запускаю все из под root. Все файлы сертификаты
лежат там где указываю.
Но Nginx все равно пишет что 
[root at msk-1299 nginx]# service nginx restart
nginx: [emerg] BIO_new_file("/etc/nginx/ssl/infolog2.ru.crt") failed (SSL:
error:02001002:system library:fopen:No such file or
directory:fopen('/etc/nginx/ssl/infolog2.ru.crt','r') error:2006D080:BIO
routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed.

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

Спасибо.

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


From denis at webmaster.spb.ru  Mon Jun  2 15:02:32 2014
From: denis at webmaster.spb.ru (denis)
Date: Mon, 02 Jun 2014 19:02:32 +0400
Subject: =?UTF-8?B?UmU6IFNTTCDQntGI0LjQsdC60LA=?=
In-Reply-To: <ddd2a5c95af55379b83a4381b37c9187.NginxMailingListRussian@forum.nginx.org>
References: <CAKqRTSHeHeXSNHN2vR=wyn5FDOfb5BXeV2bQBmysEjvZZfe4iQ@mail.gmail.com>
 <ddd2a5c95af55379b83a4381b37c9187.NginxMailingListRussian@forum.nginx.org>
Message-ID: <538C9208.306@webmaster.spb.ru>

02.06.2014 18:53, chebevara пишет:
> Можете подсказать в каком направлении копать?
ls -la /etc/nginx/ssl/infolog2.ru.crt
ls -la /etc/nginx/ssl/
и проверить права. Может сертификаты не от рута пытается прочесть а от 
nginx или nobody или еще от кого..


From mdounin at mdounin.ru  Mon Jun  2 15:40:25 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 2 Jun 2014 19:40:25 +0400
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQvdCw0LPRgNGD0LbQsNC10YLRgdGPINGC0L7Qu9GM?=
 =?UTF-8?B?0LrQviAxIHdvcmtlcj8=?=
In-Reply-To: <f7992d3a5e2072765706f9959d54d3b5.NginxMailingListRussian@forum.nginx.org>
References: <f7992d3a5e2072765706f9959d54d3b5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140602154025.GG1849@mdounin.ru>

Hello!

On Mon, Jun 02, 2014 at 03:32:06AM -0400, Brazzford wrote:

> Здравствуйте! У меня VPS с одно ядерным процессором. В конфиге Nginx
> поставлено 2 worker'а. Когда я делаю тест с помощью AB, вижу,  что всю
> нагрузку принимает либо первый либо второй worker. Именно поэтому
> рекомендуют запускать количество worker'ов равных числу ядер? Потому что
> остальные задействованы не будут? А почему два worker'a не могут
> распределить нагрузку между собой, работая на одном ядре процессора? Я знаю,
> что одно ядро, в одно и тоже время может выполнять только один процесс, но
> ведь существует переключатель процессов, который с одного процесса
> переключается на другой... и я не могу понять почему у меня нагружается
> только один worker. Помогите пожалуйста понять суть дела.

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

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

- accept_mutex выключить;
- multi_accept, если вдруг включён, выключить;
- убедиться, что тесты не используют постоянные соединения и/или 
  количество устанавливаемых соединений так или иначе велико.

Ссылки:

http://nginx.org/r/accept_mutex/ru
http://nginx.org/r/multi_accept/ru

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


From nginx-forum at nginx.us  Mon Jun  2 20:02:48 2014
From: nginx-forum at nginx.us (chebevara)
Date: Mon, 02 Jun 2014 16:02:48 -0400
Subject: =?UTF-8?B?UmU6IFNTTCDQntGI0LjQsdC60LA=?=
In-Reply-To: <538C9208.306@webmaster.spb.ru>
References: <538C9208.306@webmaster.spb.ru>
Message-ID: <ab1ce5bd9a41d2fbf3a69432fb71364c.NginxMailingListRussian@forum.nginx.org>

Спасибо за наводку.
Была ошибка в символе пути (невнимательность).

Сделав все как нужно, объединив сертификаты и указав на сертификат и ключ
запустил nginx.
Не запускается.
Выдает ошибку
PEM_read_bio_X509_AUX("/etc/nginx/ssl/infologistics.ru/infolog2.ru.crt")
failed (SSL:)

Что означает она?

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


From nginx-forum at nginx.us  Mon Jun  2 20:17:25 2014
From: nginx-forum at nginx.us (chebevara)
Date: Mon, 02 Jun 2014 16:17:25 -0400
Subject: =?UTF-8?B?UmU6IFNTTCDQntGI0LjQsdC60LA=?=
In-Reply-To: <d00a4c838ed500a1b44aec4dbb31d98c.NginxMailingListRussian@forum.nginx.org>
References: <d00a4c838ed500a1b44aec4dbb31d98c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <d76210f18d805382d133e8518fae0b8b.NginxMailingListRussian@forum.nginx.org>

Вопрос снят.
Была ошибка в сертификате.

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


From chipitsine at gmail.com  Tue Jun  3 03:19:16 2014
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 3 Jun 2014 09:19:16 +0600
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQvdCw0LPRgNGD0LbQsNC10YLRgdGPINGC0L7Qu9GM?=
 =?UTF-8?B?0LrQviAxIHdvcmtlcj8=?=
In-Reply-To: <20140602154025.GG1849@mdounin.ru>
References: <f7992d3a5e2072765706f9959d54d3b5.NginxMailingListRussian@forum.nginx.org>
 <20140602154025.GG1849@mdounin.ru>
Message-ID: <CAFHpkQE4Qh5WRcC=yqoAkudA6QkG2DMo0XOQ9g2m2cdbdL6Vag@mail.gmail.com>

Максим, насчет keepalive, наверное, мысль была в том, чтобы в тесте
воссоздать нечто, максимально похожее на боевые условия.
ни текущая ситуация (когда, вероятно, все запросы идут в рамках одного
конекта), ни то, что вы предложили ("убедиться, что тесты не
используют постоянные соединения") на боевые условия не похожи.

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

не подскажете, какие есть еще варианты ?

2 июня 2014 г., 21:40 пользователь Maxim Dounin <mdounin at mdounin.ru> написал:
> Hello!
>
> On Mon, Jun 02, 2014 at 03:32:06AM -0400, Brazzford wrote:
>
>> Здравствуйте! У меня VPS с одно ядерным процессором. В конфиге Nginx
>> поставлено 2 worker'а. Когда я делаю тест с помощью AB, вижу,  что всю
>> нагрузку принимает либо первый либо второй worker. Именно поэтому
>> рекомендуют запускать количество worker'ов равных числу ядер? Потому что
>> остальные задействованы не будут? А почему два worker'a не могут
>> распределить нагрузку между собой, работая на одном ядре процессора? Я знаю,
>> что одно ядро, в одно и тоже время может выполнять только один процесс, но
>> ведь существует переключатель процессов, который с одного процесса
>> переключается на другой... и я не могу понять почему у меня нагружается
>> только один worker. Помогите пожалуйста понять суть дела.
>
> По умолчанию nginx старается работать так, чтобы "пробуждалось"
> минимальное количество рабочих процессов - это позволяет экономить
> затраты на переключение контекстов и "лишние" пробуждения
> процессов.  При реальной работе - в результате используется
> столько процессов, сколько на самом деле нужно для обработки той
> нагрузки, которая есть.
>
> Если хочется получить более ровное распределение в тестах - то
> имеет смысл:
>
> - accept_mutex выключить;
> - multi_accept, если вдруг включён, выключить;
> - убедиться, что тесты не используют постоянные соединения и/или
>   количество устанавливаемых соединений так или иначе велико.
>
> Ссылки:
>
> http://nginx.org/r/accept_mutex/ru
> http://nginx.org/r/multi_accept/ru
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From vbart at nginx.com  Tue Jun  3 05:34:04 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Tue, 03 Jun 2014 09:34:04 +0400
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C10LzRgyDQvdCw0LPRgNGD0LbQsNC10YLRgdGPINGC0L7Qu9GM?=
 =?UTF-8?B?0LrQviAxIHdvcmtlcj8=?=
In-Reply-To: <CAFHpkQE4Qh5WRcC=yqoAkudA6QkG2DMo0XOQ9g2m2cdbdL6Vag@mail.gmail.com>
References: <f7992d3a5e2072765706f9959d54d3b5.NginxMailingListRussian@forum.nginx.org>
 <20140602154025.GG1849@mdounin.ru>
 <CAFHpkQE4Qh5WRcC=yqoAkudA6QkG2DMo0XOQ9g2m2cdbdL6Vag@mail.gmail.com>
Message-ID: <8553318.EkhYMILBRh@vbart-laptop>

On Tuesday 03 June 2014 09:19:16 Илья Шипицин wrote:
> Максим, насчет keepalive, наверное, мысль была в том, чтобы в тесте
> воссоздать нечто, максимально похожее на боевые условия.
> ни текущая ситуация (когда, вероятно, все запросы идут в рамках одного
> конекта), ни то, что вы предложили ("убедиться, что тесты не
> используют постоянные соединения") на боевые условия не похожи.
> 
> у нас как-то была задача посчитать, сколько в боевых условиях в
> среднем проходит запросов в рамках одного keepalive-соединения.
> красивого и понятного решения не нашли. придумали логировать исходящий
> tcp-порт на клиенте (и верить, что это признак keepalive).
> 
> не подскажете, какие есть еще варианты ?
[..]

$connection + $connection_requests
http://nginx.org/ru/docs/http/ngx_http_log_module.html#var_connection

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

From a.vasilishin at kpi.ua  Tue Jun  3 17:03:48 2014
From: a.vasilishin at kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=)
Date: Tue, 03 Jun 2014 20:03:48 +0300
Subject: =?UTF-8?B?0JrQsNC6INCx0YvRgtGMINGBIExPSUMg0LTQtNC+0YHQtdGA0LDQvNC4Pw==?=
Message-ID: <538DFFF4.8000905@kpi.ua>

Кто-то начал баловаться LOIC'ом вкаждом запросе добавляют аргументы 
вида: ?id=1401813985641&msg=
где id всегда разный, а msg - пустой

Не могу понять как написать


if ($arg_id ~ "[0-9]{10}" & $arg_msg = '' ) {
     return 444;
}

чтоб оно работало?


From mdounin at mdounin.ru  Tue Jun  3 17:24:28 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 3 Jun 2014 21:24:28 +0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQsdGL0YLRjCDRgSBMT0lDINC00LTQvtGB0LXRgNCw0LzQuD8=?=
In-Reply-To: <538DFFF4.8000905@kpi.ua>
References: <538DFFF4.8000905@kpi.ua>
Message-ID: <20140603172428.GV1849@mdounin.ru>

Hello!

On Tue, Jun 03, 2014 at 08:03:48PM +0300, Андрей Василишин wrote:

> Кто-то начал баловаться LOIC'ом вкаждом запросе добавляют аргументы вида:
> ?id=1401813985641&msg=
> где id всегда разный, а msg - пустой
> 
> Не могу понять как написать
> 
> 
> if ($arg_id ~ "[0-9]{10}" & $arg_msg = '' ) {
>     return 444;
> }
> 
> чтоб оно работало?

Самый простой способ - проверить всю строку, вместо отдельных её 
частей:

    if ($args ~ "^id=[0-9]{10}&msg=$") {
        return 444;
    }

Ну или вариации на тему множественных условий,
http://wiki.nginx.org/RewriteMultiCondExample:

    set $test "";

    if ($arg_id ~ "[0-9]{10}") {
        set $test 1;
    }

    if ($arg_msg = "") {
        set $test ${test}1;
    }

    if ($test = "11") {
        return 444;
    }


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


From a.vasilishin at kpi.ua  Tue Jun  3 17:48:42 2014
From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=)
Date: Tue, 03 Jun 2014 20:48:42 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQsdGL0YLRjCDRgSBMT0lDINC00LTQvtGB0LXRgNCw0LzQuD8=?=
In-Reply-To: <20140603172428.GV1849@mdounin.ru>
References: <538DFFF4.8000905@kpi.ua> <20140603172428.GV1849@mdounin.ru>
Message-ID: <538E0A7A.4080505@kpi.ua>


> Самый простой способ - проверить всю строку, вместо отдельных её
> частей:
>
>      if ($args ~ "^id=[0-9]{10}&msg=$") {
>          return 444;
>      }



Спасибо, мне его как раз хватило


From nginx-forum at nginx.us  Wed Jun  4 07:40:24 2014
From: nginx-forum at nginx.us (RedRat)
Date: Wed, 04 Jun 2014 03:40:24 -0400
Subject: =?UTF-8?B?0JrQtdGI0LjRgNC+0LLQsNC90LjQtSBTU0kg0LjQvdC60LvRjtC00L7QsiAtINCy?=
 =?UTF-8?B?0L7Qt9C80L7QttC90L4g0LvQuCDRjdGC0L4/?=
Message-ID: <59d8f1d8ceebf72a91c94a32110774b6.NginxMailingListRussian@forum.nginx.org>

Есть довольно сложный сайт, запутанная внутренняя логика которого
препятствует нормальному включению кеширования на уровне nginx. Разработчик
выделил все неизменяемые блоки контента под отдельный URI, которые инклюдит
их шаблона страницы через SSI. Пытаюсь для локейшена с этими блоками
включить кеширование, чтобы они брались из кеша, а не генерились каждый раз
движком, но запросы всё равно уходят в движок.

Собственно, вопрос к разработчикам: возможно ли настроить кеширование для
SSI инклюдов, если все они попадают в определённый локейшен? Или они всегда
запрашиваются "напрямую"?

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


From nginx-forum at nginx.us  Wed Jun  4 10:13:38 2014
From: nginx-forum at nginx.us (RedRat)
Date: Wed, 04 Jun 2014 06:13:38 -0400
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUgU1NJINC40L3QutC70Y7QtNC+0LIg?=
 =?UTF-8?B?LSDQstC+0LfQvNC+0LbQvdC+INC70Lgg0Y3RgtC+Pw==?=
In-Reply-To: <59d8f1d8ceebf72a91c94a32110774b6.NginxMailingListRussian@forum.nginx.org>
References: <59d8f1d8ceebf72a91c94a32110774b6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <514246f0597f4c4d71b0fa0ae213e2aa.NginxMailingListRussian@forum.nginx.org>

Переформулируя вопрос: можно ли как-то выделить в локейшене запросы, которые
надо кешировать, пропуская все остальные напрямую к движку? То есть, нужна
логика, обратная директиве proxy_cache_bypass. Пока придумал только одно:
устанавливать переменную для всех запросов, в нужном локейшене её
сбрасывать, а в именованном локейшене для бэкенда уже смотреть на неё.

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


From vbart at nginx.com  Wed Jun  4 10:20:37 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 04 Jun 2014 14:20:37 +0400
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUgU1NJINC40L3QutC70Y7QtNC+0LIg?=
 =?UTF-8?B?LSDQstC+0LfQvNC+0LbQvdC+INC70Lgg0Y3RgtC+Pw==?=
In-Reply-To: <514246f0597f4c4d71b0fa0ae213e2aa.NginxMailingListRussian@forum.nginx.org>
References: <59d8f1d8ceebf72a91c94a32110774b6.NginxMailingListRussian@forum.nginx.org>
 <514246f0597f4c4d71b0fa0ae213e2aa.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1497476.HT3H2dR5Lq@vbart-workstation>

On Wednesday 04 June 2014 06:13:38 RedRat wrote:
> Переформулируя вопрос: можно ли как-то выделить в локейшене запросы, которые
> надо кешировать, пропуская все остальные напрямую к движку? То есть, нужна
> логика, обратная директиве proxy_cache_bypass. Пока придумал только одно:
> устанавливать переменную для всех запросов, в нужном локейшене её
> сбрасывать, а в именованном локейшене для бэкенда уже смотреть на неё.
> 

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

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

From nginx-forum at nginx.us  Wed Jun  4 10:43:31 2014
From: nginx-forum at nginx.us (RedRat)
Date: Wed, 04 Jun 2014 06:43:31 -0400
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUgU1NJINC40L3QutC70Y7QtNC+0LIg?=
 =?UTF-8?B?LSDQstC+0LfQvNC+0LbQvdC+INC70Lgg0Y3RgtC+Pw==?=
In-Reply-To: <1497476.HT3H2dR5Lq@vbart-workstation>
References: <1497476.HT3H2dR5Lq@vbart-workstation>
Message-ID: <68b9d63eba2caf42a2d6d0e1e1f3a427.NginxMailingListRussian@forum.nginx.org>

> А зачем их выделять в одном location-е? Заведите отдельный location,
> где будет включено кэширование и куда будут попадать все запросы,
> которые необходимо кэшировать.

Все запросы к движку попадают в один именованный локейшен. Если выделять ещё
один или несколько локейшенов под запросы, которые надо кешировать, придётся
там дублировать всю конфигурацию бэкэндов. Что чревато. А директива
proxy_cache не может быть размещена внутри if, и внутри именованного
локейшена нельзя разместить ещё один, обычный. Поэтому и возник такой
вопрос.

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


From vbart at nginx.com  Wed Jun  4 10:53:44 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 04 Jun 2014 14:53:44 +0400
Subject: =?UTF-8?B?UmU6INCa0LXRiNC40YDQvtCy0LDQvdC40LUgU1NJINC40L3QutC70Y7QtNC+0LIg?=
 =?UTF-8?B?LSDQstC+0LfQvNC+0LbQvdC+INC70Lgg0Y3RgtC+Pw==?=
In-Reply-To: <68b9d63eba2caf42a2d6d0e1e1f3a427.NginxMailingListRussian@forum.nginx.org>
References: <1497476.HT3H2dR5Lq@vbart-workstation>
 <68b9d63eba2caf42a2d6d0e1e1f3a427.NginxMailingListRussian@forum.nginx.org>
Message-ID: <21907300.syebsFJrqj@vbart-workstation>

On Wednesday 04 June 2014 06:43:31 RedRat wrote:
> > А зачем их выделять в одном location-е? Заведите отдельный location,
> > где будет включено кэширование и куда будут попадать все запросы,
> > которые необходимо кэшировать.
> 
> Все запросы к движку попадают в один именованный локейшен. Если выделять ещё
> один или несколько локейшенов под запросы, которые надо кешировать,
> придётся там дублировать всю конфигурацию бэкэндов. Что чревато.
[..]

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

Читать:
http://mailman.nginx.org/pipermail/nginx-ru/2011-November/044461.html

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

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

From nginx-forum at nginx.us  Wed Jun  4 11:54:58 2014
From: nginx-forum at nginx.us (Magi)
Date: Wed, 04 Jun 2014 07:54:58 -0400
Subject: =?UTF-8?B?0KHQstGP0LfQutCwIG5naW54LWFwYWNoZSDQsiDQutCw0YfQtdGB0YLQstC1INC/?=
 =?UTF-8?B?0YDQvtC60YHQuA==?=
Message-ID: <949915e2267e7ad77d973229555e2139.NginxMailingListRussian@forum.nginx.org>

Здравствуйте!
Подскажите пожалуйста, на сайте domain.ru с ip 1.1.1.1 стоял apache 2.2 и
Joomla 1.5 и в конфиге были такие строки

ProxyRequests On
ProxyVia Block
AllowCONNECT 21 25 110 443 22 554 563 5190 1080 8080 5140 5160 4000 1478
1479 1480 8008 1480>

<Proxy *>
  Order deny,allow
  deny from all
  allow from xxx.xx.xx.xx
</Proxy>

Апач работал, как прокси, в настрйоках брайзера был прописан ip сайта и 80
порт.
Но после переезда на Joomla 2.5 увеличилась нагрузка и возникла
необходимость поставить nginx.
nginx поставил, но отпал функционал прокси. Конфиг nginx прилагается.
# user nginx;
worker_processes  4;
timer_resolution 100ms;

# error_log  /dev/null;
error_log  /usr/local/nginx/logs/error.log  crit;
#pid        logs/nginx.pid;
worker_rlimit_nofile 200000;
worker_priority -5;
events { worker_connections  4000;

multi_accept on; }
http { include       mime.types; default_type  application/octet-stream;
types { text/plain    data;  }
    log_format  main  '$remote_addr - $remote_user [$time_local] $host
$request
'
                      '"$status" $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_src_client_ip"';

#access_log /usr/local/nginx/logs/access.log  main;
access_log off;

# Caches information about open FDs, freqently accessed files.
open_file_cache max=200000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;


    sendfile        on;
    tcp_nopush     on;
    tcp_nodelay    on;
   
    gzip           on;
    gzip_min_length 10240;
    gzip_buffers 64 8k;
    gzip_comp_level 3;
    gzip_http_version 1.1;
    gzip_proxied expired no-cache no-store private auth;
    gzip_types text/plan application/xml application/x-javascript text/css
text/xml text/javascript;
    gzip_disable "msie6";
    client_body_timeout 10;
    client_header_timeout 10;
    send_timeout 2;
   
    keepalive_timeout  30;
    keepalive_requests 1000;
   
    server_tokens off;
    server_names_hash_bucket_size 64;
    proxy_buffers     100 64k;
    proxy_read_timeout 300;
    proxy_send_timeout 300;
    client_max_body_size 1500m;
    reset_timedout_connection on;

proxy_cache_path /var/cache/nginx/cache levels=1:2 keys_zone=one:16m
inactive=7d max_size=1024m;
proxy_temp_path /var/cache/nginx/temp;

server {
      listen       *:80;
      server_name   *.com;
location /nginx_status { stub_status on; access_log off; allow 1.1.1.1; deny
all; }
location /munin { alias   /var/www/html/munin; autoindex on; auth_basic
"Munin"; auth_basic_user_file /etc/munin/munin-htpasswd; }
      location / {
            proxy_pass        http://1.1.1.1:8181;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Real-IP $remote_addr;
      }

}

server {
      listen       *:80;
      server_name   www.domain.ru domain.ru;
location /nginx_status { stub_status on; access_log off; allow 1.1.1.1; deny
all; }
location /munin { alias   /var/www/html/munin; autoindex on; auth_basic
"Munin"; auth_basic_user_file /etc/munin/munin-htpasswd; }
# proxy_temp_path /var/cache/nginx/domain.ru;

location / {
#            $host='domain.ru:80'
            proxy_pass http://1.1.1.1:80;
            proxy_set_header Host domain.ru;
        proxy_redirect off;
}
       
# location /administrator {
location ~*(administrator|comprofiler)* {
         proxy_cache off;
         proxy_pass        http://1.1.1.1:8181;
         proxy_set_header Host $host;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Real-IP $remote_addr;

}

}
}



Сейчас нужно вернуть возможность использовать связку nginx-apache в качестве
прокси. На сервере открыт только 80 и 22 порты, других не будет. Подскажите,
как вернуть функционал прокси?

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


From nginx-forum at nginx.us  Thu Jun  5 08:27:02 2014
From: nginx-forum at nginx.us (endo)
Date: Thu, 05 Jun 2014 04:27:02 -0400
Subject: =?UTF-8?B?0JrQsNC6INGA0LDQt9GA0LXRiNC40YLRjCDRgtC+0LvRjNC60L4g0L7Qv9GA0LU=?=
 =?UTF-8?B?0LTQtdC70LXQvdC90YvQuSBjb250ZW50LXR5cGUg0LIg0L7RgtCy0LXRgtC1?=
 =?UTF-8?B?INC+0YIgdXBzdHJlYW0/?=
Message-ID: <bbcb5c13165b0c411bab4c6a71635449.NginxMailingListRussian@forum.nginx.org>

Доброго дня всем.

Возник вопрос: как реализовать логику фильтрации content-type в ответе от
upstream , и в зависимости от этого - отдавать определенный код (404 если не
разрешенный content-type от апстрима).


Пробовал через переменную $upstream_http_content_type

map $upstream_http_content_type $ctype_allowed {
        default    0;
        "~image" 1;
}

...
add_header X-ctype $ctype_allowed;

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

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


From mdounin at mdounin.ru  Thu Jun  5 12:11:11 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 5 Jun 2014 16:11:11 +0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0LfRgNC10YjQuNGC0Ywg0YLQvtC70YzQutC+INC+0L8=?=
 =?UTF-8?B?0YDQtdC00LXQu9C10L3QvdGL0LkgY29udGVudC10eXBlINCyINC+0YLQstC1?=
 =?UTF-8?B?0YLQtSDQvtGCIHVwc3RyZWFtPw==?=
In-Reply-To: <bbcb5c13165b0c411bab4c6a71635449.NginxMailingListRussian@forum.nginx.org>
References: <bbcb5c13165b0c411bab4c6a71635449.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140605121111.GD1849@mdounin.ru>

Hello!

On Thu, Jun 05, 2014 at 04:27:02AM -0400, endo wrote:

> Доброго дня всем.
> 
> Возник вопрос: как реализовать логику фильтрации content-type в ответе от
> upstream , и в зависимости от этого - отдавать определенный код (404 если не
> разрешенный content-type от апстрима).
> 
> 
> Пробовал через переменную $upstream_http_content_type
> 
> map $upstream_http_content_type $ctype_allowed {
>         default    0;
>         "~image" 1;
> }
> 
> ...
> add_header X-ctype $ctype_allowed;
> 
> в таком варианте заголовок проставляется вроде бы правильный, но как по
> переменной $ctype_allowed или в принципе по содержимому заголовков от
> апстрима разрешить или запретить ответ клиенту?

Для произвольного типа - никак, надо писать собственный фильтр, 
который сделает это (ну или искать сторонний).

Конкретно для картинок - имеет смысл посмотреть на "image_filter 
test".  Там, правда, не проверка типа, а анализ сигнатур 
содержимого (и безусловное переопределение типа по результатам 
анализа).  Подробности тут:

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

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


From anatoly at sonru.com  Fri Jun  6 13:21:31 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Fri, 6 Jun 2014 14:21:31 +0100
Subject: =?UTF-8?B?UmU6IFNQRFkg0LLQvNC10YHRgtC1INGBINCy0LrQu9GO0YfQtdC90L3Ri9C8IHBy?=
 =?UTF-8?B?b3h5X2NhY2hlX2J5cGFzcyAoIzQyOCk=?=
In-Reply-To: <B0D6D6AA-35E4-471D-935B-513E0641CDA2@sonru.com>
References: <482D278A-1A4D-47A9-B936-1E1786D37CCC@sonru.com>
 <2702734.o9QWP8dTeh@vbart-workstation>
 <D5091AAB-380F-4EC9-A60D-AB2CAC0D7CD3@sonru.com>
 <1878949.JPPHYv9qVD@vbart-workstation>
 <B0D6D6AA-35E4-471D-935B-513E0641CDA2@sonru.com>
Message-ID: <1B285EBC-A43C-4D8A-84A1-CCE7FB1F034F@sonru.com>


On 29 May 2014, at 14:57, Anatoly Mikhailov <anatoly at sonru.com> wrote:

> 
> On 29 May 2014, at 14:36, Валентин Бартенев <vbart at nginx.com> wrote:
> 
>> On Thursday 29 May 2014 12:49:28 Anatoly Mikhailov wrote:
>>> On 27 May 2014, at 12:53, Валентин Бартенев <vbart at nginx.com> wrote:
>>> 
>>> 
>>>> On Tuesday 27 May 2014 12:40:35 Anatoly Mikhailov wrote:
>>>> [..]
>>>> 
>>>>> 
>>>>> Валентин, пока подходящее решение не будет найдено, есть планы выложить
>>>>> текущий патч сюда http://nginx.org/patches/ ? Это было бы очень удобно.
>>>> 
>>>> 
>>>> ok
>>>> 
>>>> http://nginx.org/patches/patch.spdy_upstream_fix.txt
>>> 
>>> 
>>> спасибо! соберу на тестовом сервере и проверю как система себя ведет с этим
>>> патчем, если не секрет, в коммерческий релиз Nginx этот патч тоже пока не
>>> попал? 
>>> 
>> 
>> Пакеты для nginx plus давно собираются с патчем.  Таким образом, там проблем 
>> наблюдаться не должно.
> 
> Валентин, патч решил проблему, спасибо! Будем ждать данный патч в опен-сорс версии Nginx!

начал ловить те же баги на не пропатченном Nginx на другом сервере 
с меньшей нагрузкой, этот патч в опен-сорсе очень бы не помешал!

> 
>> 
>> --
>> Валентин Бартенев
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

From maxim at nginx.com  Fri Jun  6 13:27:17 2014
From: maxim at nginx.com (Maxim Konovalov)
Date: Fri, 06 Jun 2014 17:27:17 +0400
Subject: =?UTF-8?B?UmU6IFNQRFkg0LLQvNC10YHRgtC1INGBINCy0LrQu9GO0YfQtdC90L3Ri9C8IHBy?=
 =?UTF-8?B?b3h5X2NhY2hlX2J5cGFzcyAoIzQyOCk=?=
In-Reply-To: <1B285EBC-A43C-4D8A-84A1-CCE7FB1F034F@sonru.com>
References: <482D278A-1A4D-47A9-B936-1E1786D37CCC@sonru.com>
 <2702734.o9QWP8dTeh@vbart-workstation>
 <D5091AAB-380F-4EC9-A60D-AB2CAC0D7CD3@sonru.com>
 <1878949.JPPHYv9qVD@vbart-workstation>
 <B0D6D6AA-35E4-471D-935B-513E0641CDA2@sonru.com>
 <1B285EBC-A43C-4D8A-84A1-CCE7FB1F034F@sonru.com>
Message-ID: <5391C1B5.7060403@nginx.com>

[...]
> начал ловить те же баги на не пропатченном Nginx на другом сервере 
> с меньшей нагрузкой, этот патч в опен-сорсе очень бы не помешал!
> 
Код в процессе внутреннего ревью.

-- 
Maxim Konovalov
http://nginx.com


From anatoly at sonru.com  Fri Jun  6 15:13:06 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Fri, 6 Jun 2014 16:13:06 +0100
Subject: =?UTF-8?B?UmU6IFNQRFkg0LLQvNC10YHRgtC1INGBINCy0LrQu9GO0YfQtdC90L3Ri9C8IHBy?=
 =?UTF-8?B?b3h5X2NhY2hlX2J5cGFzcyAoIzQyOCk=?=
In-Reply-To: <5391C1B5.7060403@nginx.com>
References: <482D278A-1A4D-47A9-B936-1E1786D37CCC@sonru.com>
 <2702734.o9QWP8dTeh@vbart-workstation>
 <D5091AAB-380F-4EC9-A60D-AB2CAC0D7CD3@sonru.com>
 <1878949.JPPHYv9qVD@vbart-workstation>
 <B0D6D6AA-35E4-471D-935B-513E0641CDA2@sonru.com>
 <1B285EBC-A43C-4D8A-84A1-CCE7FB1F034F@sonru.com> <5391C1B5.7060403@nginx.com>
Message-ID: <5DE2A9DB-6BA7-45E6-BB3A-C4316AE2DFEF@sonru.com>


On 06 Jun 2014, at 14:27, Maxim Konovalov <maxim at nginx.com> wrote:

> [...]
>> начал ловить те же баги на не пропатченном Nginx на другом сервере 
>> с меньшей нагрузкой, этот патч в опен-сорсе очень бы не помешал!
>> 
> Код в процессе внутреннего ревью.

Отличная новость в пятницу, спасибо!

> 
> -- 
> Maxim Konovalov
> http://nginx.com
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From arutemus at gmail.com  Sun Jun  8 19:38:49 2014
From: arutemus at gmail.com (Arteom Pogartsev)
Date: Sun, 08 Jun 2014 22:38:49 +0300
Subject: =?UTF-8?B?0J7QsdGA0LDQsdC+0YLQutCwIENvbnRlbnQtRW5jb2Rpbmcg0L/RgNC4INCy0Ys=?=
 =?UTF-8?B?0YHRgtCw0LLQu9C10L3QvdC+0LwgWC1BY2NlbC1SZWRpcmVjdA==?=
Message-ID: <5394BBC9.2020306@gmail.com>

Hi,

Интересует причина, по которой в src/http/ngx_http_upstream.c поле 
redirect для Content-Encoding высталвлено в 0.

Соответственно заголовок Content-Encoding не наследуется от бэкенда, 
если также имеется заголовок X-Accel-Redirect.

Будет ли принят патч, делающий это поведение хотя бы опциональным? Или 
существуют какие-то весомые причины, по которым заголовок 
Content-Encoding безусловно отбрасывается?


From eugene.peregudov at gmail.com  Mon Jun  9 08:02:32 2014
From: eugene.peregudov at gmail.com (Eugene Peregudov)
Date: Mon, 09 Jun 2014 15:02:32 +0700
Subject: ssl_prefer_server_ciphers
Message-ID: <op.xg6gmiqrx116d8@ciu-306-05.corp.nstu.ru>

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

Как в nginx обстоят дела с использованием аппаратного ускорения aes-ni?

OpenSSL рекомендует использовать высокоуровневый интерфейс EVP - из вывода  
cli видно, что вызываются соотвествующие методы, ускорение есть (OpenSSL  
1.0.1e-fips 11 Feb 2013, RHEL6.5):
$openssl speed -elapsed aes-128-cbc
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192  
bytes
aes-128 cbc      65708.40k    74542.55k    72715.78k   152230.91k    
161742.85k

$openssl speed -elapsed -evp aes-128-cbc
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192  
bytes
aes-128-cbc     466421.73k   526309.33k   559382.53k   600289.28k    
590875.31k

$openssl speed -elapsed aes-256-cbc
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192  
bytes
aes-256 cbc      43067.45k    51166.19k    51947.09k   100144.13k    
104420.69k

$openssl speed -elapsed -evp aes-256-cbc
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192  
bytes
aes-256-cbc     364533.73k   389520.45k   433119.49k   458341.38k    
450338.82k

В коде стабильной версии (nginx-1.6.0) нашел только aes_128_cbc, а где же  
256?
grep -R EVP_aes *
src/event/ngx_event_openssl.c:        EVP_EncryptInit_ex(ectx,  
EVP_aes_128_cbc(), NULL, key[0].aes_key, iv);
src/event/ngx_event_openssl.c:        EVP_DecryptInit_ex(ectx,  
EVP_aes_128_cbc(), NULL, key[i].aes_key, iv);

Принуждает ли такой конфиг ssl использование браузером шифров aes128/256 и  
будет ли реально использоваться AES-NI?

ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout  10m;
ssl_ciphers  
RSA+AES:ECDH+AES+aRSA:ECDH+AES+aECDSA:!AEDH:!EDH:!kEDH:!aNULL:!MD5:!LOW:!3DES:!EXP:!PSK:!SRP:!DSS:!RC4;
ssl_protocols TLSv1.2 TLSv1.1 TLSv1 SSLv3;

-- 
With best regards, Eugene JONIK Peregudov
mailto: eugene.peregudov at gmail.com

From vbart at nginx.com  Mon Jun  9 16:15:38 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Mon, 09 Jun 2014 20:15:38 +0400
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBDb250ZW50LUVuY29kaW5nINC/0YDQuCA=?=
 =?UTF-8?B?0LLRi9GB0YLQsNCy0LvQtdC90L3QvtC8IFgtQWNjZWwtUmVkaXJlY3Q=?=
In-Reply-To: <5394BBC9.2020306@gmail.com>
References: <5394BBC9.2020306@gmail.com>
Message-ID: <18953348.65G28Zf6yJ@vbart-workstation>

On Sunday 08 June 2014 22:38:49 Arteom Pogartsev wrote:
> Hi,
> 
> Интересует причина, по которой в src/http/ngx_http_upstream.c поле
> redirect для Content-Encoding высталвлено в 0.
> 

Это естественное поведение, желаемое в большинстве случаев.

> Соответственно заголовок Content-Encoding не наследуется от бэкенда,
> если также имеется заголовок X-Accel-Redirect.
> 
> Будет ли принят патч, делающий это поведение хотя бы опциональным? Или
> существуют какие-то весомые причины, по которым заголовок
> Content-Encoding безусловно отбрасывается?
> 

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

  add_header Content-Encoding $upstream_http_content_encoding;

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

From arutemus at gmail.com  Mon Jun  9 16:49:50 2014
From: arutemus at gmail.com (Arteom Pogartsev)
Date: Mon, 09 Jun 2014 19:49:50 +0300
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBDb250ZW50LUVuY29kaW5nINC/0YDQuCA=?=
 =?UTF-8?B?0LLRi9GB0YLQsNCy0LvQtdC90L3QvtC8IFgtQWNjZWwtUmVkaXJlY3Q=?=
In-Reply-To: <18953348.65G28Zf6yJ@vbart-workstation>
References: <5394BBC9.2020306@gmail.com>
 <18953348.65G28Zf6yJ@vbart-workstation>
Message-ID: <5395E5AE.1050601@gmail.com>

>> Сомневаюсь, что такой патч может быть принят, тем более, что существует
>> другой способ сохранить заголовок из ответа бэкенда:
>>
>>    add_header Content-Encoding $upstream_http_content_encoding;

Ровно так и сделано в текущий момент.

>> Это естественное поведение, желаемое в большинстве случаев.

Почему? Когда может помешать скопированный с бэкенда content-encoding?

Если включено gzip сжатие не для того location, то каша получится в 
любом случае, так как файл уже и так сжат.

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

Или, также возможно, если включен модуль gunzip не для того location.

Потому и предлагается или ввести управлющую опцию, или редиректить 
заголовок content-encoding, если не включен gunzip/gzip.

On 06/09/2014 07:15 PM, Валентин Бартенев wrote:
> On Sunday 08 June 2014 22:38:49 Arteom Pogartsev wrote:
>> Hi,
>>
>> Интересует причина, по которой в src/http/ngx_http_upstream.c поле
>> redirect для Content-Encoding высталвлено в 0.
>>
>
> Это естественное поведение, желаемое в большинстве случаев.
>
>> Соответственно заголовок Content-Encoding не наследуется от бэкенда,
>> если также имеется заголовок X-Accel-Redirect.
>>
>> Будет ли принят патч, делающий это поведение хотя бы опциональным? Или
>> существуют какие-то весомые причины, по которым заголовок
>> Content-Encoding безусловно отбрасывается?
>>
>
> Сомневаюсь, что такой патч может быть принят, тем более, что существует
> другой способ сохранить заголовок из ответа бэкенда:
>
>    add_header Content-Encoding $upstream_http_content_encoding;
>
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>


From arutemus at gmail.com  Mon Jun  9 19:22:30 2014
From: arutemus at gmail.com (Arteom Pogartsev)
Date: Mon, 09 Jun 2014 22:22:30 +0300
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBDb250ZW50LUVuY29kaW5nINC/0YDQuCA=?=
 =?UTF-8?B?0LLRi9GB0YLQsNCy0LvQtdC90L3QvtC8IFgtQWNjZWwtUmVkaXJlY3Q=?=
In-Reply-To: <5395E5AE.1050601@gmail.com>
References: <5394BBC9.2020306@gmail.com>
 <18953348.65G28Zf6yJ@vbart-workstation> <5395E5AE.1050601@gmail.com>
Message-ID: <53960976.1080108@gmail.com>

Также дополню, что даже при включенном gunzip заголовок Content-Encoding 
принудительно удалится, если он был редиректнут с апстрима, а файл 
распакуется.

При включенном gzip не проставится второй заголовок Content-Encoding и 
не произойдет повторного сжатия.

При текущем положение дел:

1) Включаем gunzip:

Файл распаковываться не будет(заголовка Content-Encoding-то нету), 
заголовок не редиректится - получаем кашу.

2) Включаем gzip:

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


Т.е. есть сценарии, только когда непереданный  заголовок 
content-encoding создает проблемы, сценарии, когда переданный заголовок 
content-encoding как-то помешает, отсутствуют.

On 06/09/2014 07:49 PM, Arteom Pogartsev wrote:
>>> Сомневаюсь, что такой патч может быть принят, тем более, что существует
>>> другой способ сохранить заголовок из ответа бэкенда:
>>>
>>>    add_header Content-Encoding $upstream_http_content_encoding;
>
> Ровно так и сделано в текущий момент.
>
>>> Это естественное поведение, желаемое в большинстве случаев.
>
> Почему? Когда может помешать скопированный с бэкенда content-encoding?
>
> Если включено gzip сжатие не для того location, то каша получится в
> любом случае, так как файл уже и так сжат.
>
> Проблема может проявиться только, если из-за неправильно настроенного
> бэкенда почему-то передался заголовок content-encoding для несжатого
> контента.
>
> Или, также возможно, если включен модуль gunzip не для того location.
>
> Потому и предлагается или ввести управлющую опцию, или редиректить
> заголовок content-encoding, если не включен gunzip/gzip.
>
> On 06/09/2014 07:15 PM, Валентин Бартенев wrote:
>> On Sunday 08 June 2014 22:38:49 Arteom Pogartsev wrote:
>>> Hi,
>>>
>>> Интересует причина, по которой в src/http/ngx_http_upstream.c поле
>>> redirect для Content-Encoding высталвлено в 0.
>>>
>>
>> Это естественное поведение, желаемое в большинстве случаев.
>>
>>> Соответственно заголовок Content-Encoding не наследуется от бэкенда,
>>> если также имеется заголовок X-Accel-Redirect.
>>>
>>> Будет ли принят патч, делающий это поведение хотя бы опциональным? Или
>>> существуют какие-то весомые причины, по которым заголовок
>>> Content-Encoding безусловно отбрасывается?
>>>
>>
>> Сомневаюсь, что такой патч может быть принят, тем более, что существует
>> другой способ сохранить заголовок из ответа бэкенда:
>>
>>    add_header Content-Encoding $upstream_http_content_encoding;
>>
>> --
>> Валентин Бартенев
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>


From mdounin at mdounin.ru  Tue Jun 10 10:29:09 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 10 Jun 2014 14:29:09 +0400
Subject: =?UTF-8?B?UmU6INCe0LHRgNCw0LHQvtGC0LrQsCBDb250ZW50LUVuY29kaW5nINC/0YDQuCA=?=
 =?UTF-8?B?0LLRi9GB0YLQsNCy0LvQtdC90L3QvtC8IFgtQWNjZWwtUmVkaXJlY3Q=?=
In-Reply-To: <53960976.1080108@gmail.com>
References: <5394BBC9.2020306@gmail.com>
 <18953348.65G28Zf6yJ@vbart-workstation>
 <5395E5AE.1050601@gmail.com> <53960976.1080108@gmail.com>
Message-ID: <20140610102909.GQ1849@mdounin.ru>

Hello!

On Mon, Jun 09, 2014 at 10:22:30PM +0300, Arteom Pogartsev wrote:

[...]

> Т.е. есть сценарии, только когда непереданный  заголовок content-encoding
> создает проблемы, сценарии, когда переданный заголовок content-encoding
> как-то помешает, отсутствуют.

Переданный заголовок Content-Encoding помешает в том случае, если 
он не соответствует предполагаемому после X-Accel-Redirect ответу, 
а был, например, добавлен в результате автоматического сжатия 
ответа бекендом.  И мне лично данный сценарий представляется 
вполне вероятным.

IMHO, если хочется ставить Content-Encoding в ответах после 
X-Accel-Redirect - имеет смысл пользоваться для этого штатными 
средставми, e.g., gzip_static (http://nginx.org/r/gzip_static).

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


From mdounin at mdounin.ru  Tue Jun 10 11:16:29 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 10 Jun 2014 15:16:29 +0400
Subject: ssl_prefer_server_ciphers
In-Reply-To: <op.xg6gmiqrx116d8@ciu-306-05.corp.nstu.ru>
References: <op.xg6gmiqrx116d8@ciu-306-05.corp.nstu.ru>
Message-ID: <20140610111628.GR1849@mdounin.ru>

Hello!

On Mon, Jun 09, 2014 at 03:02:32PM +0700, Eugene Peregudov wrote:

> Здравствуйте!
> 
> Как в nginx обстоят дела с использованием аппаратного ускорения aes-ni?
> 
> OpenSSL рекомендует использовать высокоуровневый интерфейс EVP - из вывода
> cli видно, что вызываются соотвествующие методы, ускорение есть (OpenSSL
> 1.0.1e-fips 11 Feb 2013, RHEL6.5):

Дела обстоят так же, как и вообще в OpenSSL - функциями 
AES_cbc_encrypt() / AES_encrypt() напрямую nginx не пользуется, 
соответственно работает реализация в рамках EVP - которая, в свою 
очередь, в современных версиях умеет AES-NI.

[...]

> В коде стабильной версии (nginx-1.6.0) нашел только aes_128_cbc, а где же
> 256?
> grep -R EVP_aes *
> src/event/ngx_event_openssl.c:        EVP_EncryptInit_ex(ectx,
> EVP_aes_128_cbc(), NULL, key[0].aes_key, iv);
> src/event/ngx_event_openssl.c:        EVP_DecryptInit_ex(ectx,
> EVP_aes_128_cbc(), NULL, key[i].aes_key, iv);

В коде - шифрование session ticket'ов, применяемое в случае 
использования общих ключей (http://nginx.org/r/ssl_session_ticket_key).
К шифрам, применяемым для общения с клиентами, это не имеет 
отношения.

> Принуждает ли такой конфиг ssl использование браузером шифров aes128/256 и
> будет ли реально использоваться AES-NI?
> 
> ssl_prefer_server_ciphers on;
> ssl_session_cache shared:SSL:10m;
> ssl_session_timeout  10m;
> ssl_ciphers RSA+AES:ECDH+AES+aRSA:ECDH+AES+aECDSA:!AEDH:!EDH:!kEDH:!aNULL:!MD5:!LOW:!3DES:!EXP:!PSK:!SRP:!DSS:!RC4;
> ssl_protocols TLSv1.2 TLSv1.1 TLSv1 SSLv3;

Полный список шифров, в которые OpenSSL разворачивает 
соответствующую строку на вашем сервере, можно посмотреть с 
помощью команды "openssl ciphers".  Поскольку все "положительные" 
элементы в списке содержат AES, то ничего кроме AES быть, 
соответственно, и не может.

Про AES-NI смотри выше.

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


From bogdar at gmail.com  Wed Jun 11 08:45:01 2014
From: bogdar at gmail.com (Bogdan)
Date: Wed, 11 Jun 2014 11:45:01 +0300
Subject: =?UTF-8?B?U1NMLdGB0LXRgNGC0LjRhNC40LrQsNGCINC/0L4g0YPQvNC+0LvRh9Cw0L3QuNGO?=
 =?UTF-8?B?INC00LvRjyDQutC70LjQtdC90YLQvtCyINCx0LXQtyBTTkk=?=
Message-ID: <CACz2Q8EWDGOU7hXqxgkynQotp+duM-QX4frx5TS3kGhhKwRAvg@mail.gmail.com>

Добрый день.

Есть несколько сертификатов на одном адресе  (различные server на одном
порту). Как можно задать сертификат, который будет использоваться при
общении с клиентами которые не поддерживают SNI?

Nginx 0.7.67

Спасибо.

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

From mva at mva.name  Wed Jun 11 09:07:44 2014
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Wed, 11 Jun 2014 16:07:44 +0700
Subject: =?UTF-8?B?UmU6IFNTTC3RgdC10YDRgtC40YTQuNC60LDRgiDQv9C+INGD0LzQvtC70YfQsNC9?=
 =?UTF-8?B?0LjRjiDQtNC70Y8g0LrQu9C40LXQvdGC0L7QsiDQsdC10LcgU05J?=
In-Reply-To: <CACz2Q8EWDGOU7hXqxgkynQotp+duM-QX4frx5TS3kGhhKwRAvg@mail.gmail.com>
References: <CACz2Q8EWDGOU7hXqxgkynQotp+duM-QX4frx5TS3kGhhKwRAvg@mail.gmail.com>
Message-ID: <1716913.yUmAZtKW8f@note>

В письме от Ср, 11 июня 2014 11:45:01 пользователь Bogdan написал:
> Добрый день.
> 
> Есть несколько сертификатов на одном адресе  (различные server на одном
> порту). Как можно задать сертификат, который будет использоваться при
> общении с клиентами которые не поддерживают SNI?

объявив его в default ssl вхосте
> 
> Nginx 0.7.67
> 

А так же желательно обновиться до современной версии, имхо.
> Спасибо.
> 
> -- 
> WBR,  Bogdan B. Rudas

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

From nginx-forum at nginx.us  Wed Jun 11 09:32:25 2014
From: nginx-forum at nginx.us (sahe123)
Date: Wed, 11 Jun 2014 05:32:25 -0400
Subject: =?UTF-8?B?U3RhdHVzIFJlYWRpbmcg0YHRgtCw0Lsg0L3Rg9C70LXQstGL0Lw=?=
Message-ID: <bf65aa1f3af07baffd3ed83beff6722f.NginxMailingListRussian@forum.nginx.org>

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

Обновил nginx с версии 0.7.67 до версии 1.6.0.
Визуально вроде все работает, беспокоит только то, что "Reading" в статусе
стал "0".
И другого значения я там не наблюдаю.
Я понимаю что "перепрыгнул" через много версий, может быть было какое-то
глобальное изменение в подсчете Reading, которое я пропустил?

Спасибо.

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


From vbart at nginx.com  Wed Jun 11 09:46:28 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 11 Jun 2014 13:46:28 +0400
Subject: =?UTF-8?B?UmU6IFN0YXR1cyBSZWFkaW5nINGB0YLQsNC7INC90YPQu9C10LLRi9C8?=
In-Reply-To: <bf65aa1f3af07baffd3ed83beff6722f.NginxMailingListRussian@forum.nginx.org>
References: <bf65aa1f3af07baffd3ed83beff6722f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2336635.KmbV9dZ01c@vbart-workstation>

On Wednesday 11 June 2014 05:32:25 sahe123 wrote:
> Здравствуйте.
> 
> Обновил nginx с версии 0.7.67 до версии 1.6.0.
> Визуально вроде все работает, беспокоит только то, что "Reading" в статусе
> стал "0".
> И другого значения я там не наблюдаю.
> Я понимаю что "перепрыгнул" через много версий, может быть было какое-то
> глобальное изменение в подсчете Reading, которое я пропустил?
> 
> Спасибо.
> 

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

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

From nginx-forum at nginx.us  Wed Jun 11 09:52:42 2014
From: nginx-forum at nginx.us (sahe123)
Date: Wed, 11 Jun 2014 05:52:42 -0400
Subject: =?UTF-8?B?UmU6IFN0YXR1cyBSZWFkaW5nINGB0YLQsNC7INC90YPQu9C10LLRi9C8?=
In-Reply-To: <2336635.KmbV9dZ01c@vbart-workstation>
References: <2336635.KmbV9dZ01c@vbart-workstation>
Message-ID: <9669b3faf807a33d13c9fde40c22111c.NginxMailingListRussian@forum.nginx.org>

Я так и подумал, после того как попробовал telnet localhost 80 (reading не
изменился) и после GET / HTTP/1.1 значение увеличилось.
Спасибо за ответ!

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


From gmm at csdoc.com  Wed Jun 11 10:30:12 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Wed, 11 Jun 2014 13:30:12 +0300
Subject: =?UTF-8?B?0J7QsSDQvtC00L3QvtC5INC80LDQu9C+0LjQt9Cy0LXRgdGC0L3QvtC5INGD0Y8=?=
 =?UTF-8?B?0LfQstC40LzQvtGB0YLQuCDQsiDQstC10LEg0YHQsNC50YLQsNGF?=
In-Reply-To: <2310697.ov1uODaMRR@vbart-laptop>
References: <52CEAABF.6030504@csdoc.com> <52CFDD57.5040502@csdoc.com>
 <52CFE253.8020801@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop>
Message-ID: <53982FB4.8090903@csdoc.com>

On 10.01.2014 15:07, Валентин Бартенев wrote:

>>>>>> http://habrahabr.ru/post/166855/

> Единственный правильный способ: пойти в IETF с предложением исправить
> соответствующие RFC, которые в том числе оговаривают, что следует делать
> при получении нескольких заголовков Host, ну а потом уже сюда.

http://tools.ietf.org/html/rfc7230#section-5.4

    When a proxy receives a request with an absolute-form of
    request-target, the proxy MUST ignore the received Host header field
    (if any) and instead replace it with the host information of the
    request-target.  A proxy that forwards such a request MUST generate a
    new Host field-value based on the received request-target rather than
    forward the received Host field-value.

Referer: http://www.opennet.ru/opennews/art.shtml?num=39956

-- 
Best regards,
  Gena


From vbart at nginx.com  Wed Jun 11 10:42:14 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 11 Jun 2014 14:42:14 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <53982FB4.8090903@csdoc.com>
References: <52CEAABF.6030504@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop>
 <53982FB4.8090903@csdoc.com>
Message-ID: <2674454.V4cZd09FeB@vbart-workstation>

On Wednesday 11 June 2014 13:30:12 Gena Makhomed wrote:
> On 10.01.2014 15:07, Валентин Бартенев wrote:
> >>>>>> http://habrahabr.ru/post/166855/
> > 
> > Единственный правильный способ: пойти в IETF с предложением исправить
> > соответствующие RFC, которые в том числе оговаривают, что следует делать
> > при получении нескольких заголовков Host, ну а потом уже сюда.
> 
> http://tools.ietf.org/html/rfc7230#section-5.4
> 
>     When a proxy receives a request with an absolute-form of
>     request-target, the proxy MUST ignore the received Host header field
>     (if any) and instead replace it with the host information of the
>     request-target.  A proxy that forwards such a request MUST generate a
>     new Host field-value based on the received request-target rather than
>     forward the received Host field-value.
> 
> Referer: http://www.opennet.ru/opennews/art.shtml?num=39956

Не очень понятно, а что хотели сказать этой цитатой?

Так, на всякий случай, nginx не является "proxy" согласно терминологии того
же RFC 7230.

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

From gmm at csdoc.com  Wed Jun 11 11:25:38 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Wed, 11 Jun 2014 14:25:38 +0300
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <2674454.V4cZd09FeB@vbart-workstation>
References: <52CEAABF.6030504@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop>
 <53982FB4.8090903@csdoc.com> <2674454.V4cZd09FeB@vbart-workstation>
Message-ID: <53983CB2.9080808@csdoc.com>

On 11.06.2014 13:42, Валентин Бартенев wrote:

>>>>>>>> http://habrahabr.ru/post/166855/
>>>
>>> Единственный правильный способ: пойти в IETF с предложением исправить
>>> соответствующие RFC, которые в том числе оговаривают, что следует делать
>>> при получении нескольких заголовков Host, ну а потом уже сюда.
>>
>> http://tools.ietf.org/html/rfc7230#section-5.4
>>
>>      When a proxy receives a request with an absolute-form of
>>      request-target, the proxy MUST ignore the received Host header field
>>      (if any) and instead replace it with the host information of the
>>      request-target.  A proxy that forwards such a request MUST generate a
>>      new Host field-value based on the received request-target rather than
>>      forward the received Host field-value.
>>
>> Referer: http://www.opennet.ru/opennews/art.shtml?num=39956
>
> Не очень понятно, а что хотели сказать этой цитатой?
>
> Так, на всякий случай, nginx не является "proxy" согласно терминологии того
> же RFC 7230.

Ok.

http://tools.ietf.org/html/rfc7230#section-5.4

    A server MUST respond with a 400 (Bad Request) status code to any
    HTTP/1.1 request message that lacks a Host header field and to any
    request message that contains more than one Host header field or a
    Host header field with an invalid field-value.

"invalid field-value" - это в том числе, когда клиент не выполняет 
требований, которые изложены выше в этом же документе:

    A client MUST send a Host header field in all HTTP/1.1 request
    messages.  If the target URI includes an authority component, then a
    client MUST send a field-value for Host that is identical to that
    authority component, excluding any userinfo subcomponent and its "@"
    delimiter (Section 2.7.1).

следовательно, если приходит запрос

GET http://example.com/ HTTP/1.1
Host: example.org

- это "Host header field with an invalid field-value"
и nginx "MUST respond with a 400 (Bad Request) status code".

Если такой запрос приходит по HTTP/1.0 - в этой версии
протокола нет absolute-form и тоже надо отвечать 400 статусом.

текущее поведение nginx не соответствует требованиям RFC 7230 ?

P.S.

и да, отвечать с 400 статусом тут даже более логично,
потому что если authority component в строке запроса
и в заголовке Host: разные - это явно попытка взлома.

-- 
Best regards,
  Gena


From nginx-forum at nginx.us  Wed Jun 11 17:01:25 2014
From: nginx-forum at nginx.us (sahe123)
Date: Wed, 11 Jun 2014 13:01:25 -0400
Subject: =?UTF-8?B?UmU6IFN0YXR1cyBSZWFkaW5nINGB0YLQsNC7INC90YPQu9C10LLRi9C8?=
In-Reply-To: <2336635.KmbV9dZ01c@vbart-workstation>
References: <2336635.KmbV9dZ01c@vbart-workstation>
Message-ID: <5ff3b02abcee521ddd7fe1de9aaa2acd.NginxMailingListRussian@forum.nginx.org>

Валентин Бартенев Wrote:
-------------------------------------------------------
> > Визуально вроде все работает, беспокоит только то, что "Reading" в
> статусе
> > стал "0".
> http://hg.nginx.org/nginx/rev/d346adac0462

Валентин, по этой же причине может уменьшиться количество принятых (и
соответственно обработаннх) соединений в той же статистике?

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


From vbart at nginx.com  Wed Jun 11 17:13:14 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 11 Jun 2014 21:13:14 +0400
Subject: =?UTF-8?B?UmU6IFN0YXR1cyBSZWFkaW5nINGB0YLQsNC7INC90YPQu9C10LLRi9C8?=
In-Reply-To: <5ff3b02abcee521ddd7fe1de9aaa2acd.NginxMailingListRussian@forum.nginx.org>
References: <2336635.KmbV9dZ01c@vbart-workstation>
 <5ff3b02abcee521ddd7fe1de9aaa2acd.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2674499.jmRQdCx8Va@vbart-workstation>

On Wednesday 11 June 2014 13:01:25 sahe123 wrote:
> Валентин Бартенев Wrote:
> -------------------------------------------------------
> 
> > > Визуально вроде все работает, беспокоит только то, что "Reading" в
> > 
> > статусе
> > 
> > > стал "0".
> > 
> > http://hg.nginx.org/nginx/rev/d346adac0462
> 
> Валентин, по этой же причине может уменьшиться количество принятых (и
> соответственно обработаннх) соединений в той же статистике?
> 

Если речь идет об accepts и handled, то нет, это не влияет.

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

From mdounin at mdounin.ru  Wed Jun 11 19:53:32 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 11 Jun 2014 23:53:32 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <53983CB2.9080808@csdoc.com>
References: <52CEAABF.6030504@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop>
 <53982FB4.8090903@csdoc.com> <2674454.V4cZd09FeB@vbart-workstation>
 <53983CB2.9080808@csdoc.com>
Message-ID: <20140611195331.GD1849@mdounin.ru>

Hello!

On Wed, Jun 11, 2014 at 02:25:38PM +0300, Gena Makhomed wrote:

> On 11.06.2014 13:42, Валентин Бартенев wrote:
> 
> >>>>>>>>http://habrahabr.ru/post/166855/
> >>>
> >>>Единственный правильный способ: пойти в IETF с предложением исправить
> >>>соответствующие RFC, которые в том числе оговаривают, что следует делать
> >>>при получении нескольких заголовков Host, ну а потом уже сюда.
> >>
> >>http://tools.ietf.org/html/rfc7230#section-5.4
> >>
> >>     When a proxy receives a request with an absolute-form of
> >>     request-target, the proxy MUST ignore the received Host header field
> >>     (if any) and instead replace it with the host information of the
> >>     request-target.  A proxy that forwards such a request MUST generate a
> >>     new Host field-value based on the received request-target rather than
> >>     forward the received Host field-value.
> >>
> >>Referer: http://www.opennet.ru/opennews/art.shtml?num=39956
> >
> >Не очень понятно, а что хотели сказать этой цитатой?
> >
> >Так, на всякий случай, nginx не является "proxy" согласно терминологии того
> >же RFC 7230.
> 
> Ok.
> 
> http://tools.ietf.org/html/rfc7230#section-5.4
> 
>    A server MUST respond with a 400 (Bad Request) status code to any
>    HTTP/1.1 request message that lacks a Host header field and to any
>    request message that contains more than one Host header field or a
>    Host header field with an invalid field-value.
> 
> "invalid field-value" - это в том числе, когда клиент не выполняет
> требований, которые изложены выше в этом же документе:
> 
>    A client MUST send a Host header field in all HTTP/1.1 request
>    messages.  If the target URI includes an authority component, then a
>    client MUST send a field-value for Host that is identical to that
>    authority component, excluding any userinfo subcomponent and its "@"
>    delimiter (Section 2.7.1).

Если исходить из такой трактовки термина "invalid field-value", то 
ранее процитированное требование про "the proxy MUST ignore the 
received Host header..." и далее по тексту - не имеет смысла.

Я просто оставлю эту ссылку здесь:

http://lurkmore.to/Взаимоисключающие_параграфы

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


From dmitry.goryainov at gmail.com  Wed Jun 11 19:54:52 2014
From: dmitry.goryainov at gmail.com (Dmitry)
Date: Wed, 11 Jun 2014 23:54:52 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <53983CB2.9080808@csdoc.com>
References: <52CEAABF.6030504@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop>
 <53982FB4.8090903@csdoc.com> <2674454.V4cZd09FeB@vbart-workstation>
 <53983CB2.9080808@csdoc.com>
Message-ID: <CAHzBpYUPOX4wV+pk6i9cpcrN9e41a73HbO6QLcUJhwrJ4pXEQg@mail.gmail.com>

Не понял в чем проблема, чисто наитием использую давно:

# Add default fake server
include /..../default_server.conf;

где default_server.conf:
=================

server {
listen *:80 default_server;
server_name _;
return 403;
}



2014-06-11 15:25 GMT+04:00 Gena Makhomed <gmm at csdoc.com>:

> On 11.06.2014 13:42, Валентин Бартенев wrote:
>
>  http://habrahabr.ru/post/166855/
>>>>>>>>>
>>>>>>>>
>>>> Единственный правильный способ: пойти в IETF с предложением исправить
>>>> соответствующие RFC, которые в том числе оговаривают, что следует делать
>>>> при получении нескольких заголовков Host, ну а потом уже сюда.
>>>>
>>>
>>> http://tools.ietf.org/html/rfc7230#section-5.4
>>>
>>>      When a proxy receives a request with an absolute-form of
>>>      request-target, the proxy MUST ignore the received Host header field
>>>      (if any) and instead replace it with the host information of the
>>>      request-target.  A proxy that forwards such a request MUST generate
>>> a
>>>      new Host field-value based on the received request-target rather
>>> than
>>>      forward the received Host field-value.
>>>
>>> Referer: http://www.opennet.ru/opennews/art.shtml?num=39956
>>>
>>
>> Не очень понятно, а что хотели сказать этой цитатой?
>>
>> Так, на всякий случай, nginx не является "proxy" согласно терминологии
>> того
>> же RFC 7230.
>>
>
> Ok.
>
> http://tools.ietf.org/html/rfc7230#section-5.4
>
>    A server MUST respond with a 400 (Bad Request) status code to any
>    HTTP/1.1 request message that lacks a Host header field and to any
>    request message that contains more than one Host header field or a
>    Host header field with an invalid field-value.
>
> "invalid field-value" - это в том числе, когда клиент не выполняет
> требований, которые изложены выше в этом же документе:
>
>    A client MUST send a Host header field in all HTTP/1.1 request
>    messages.  If the target URI includes an authority component, then a
>    client MUST send a field-value for Host that is identical to that
>    authority component, excluding any userinfo subcomponent and its "@"
>    delimiter (Section 2.7.1).
>
> следовательно, если приходит запрос
>
> GET http://example.com/ HTTP/1.1
> Host: example.org
>
> - это "Host header field with an invalid field-value"
> и nginx "MUST respond with a 400 (Bad Request) status code".
>
> Если такой запрос приходит по HTTP/1.0 - в этой версии
> протокола нет absolute-form и тоже надо отвечать 400 статусом.
>
> текущее поведение nginx не соответствует требованиям RFC 7230 ?
>
> P.S.
>
> и да, отвечать с 400 статусом тут даже более логично,
> потому что если authority component в строке запроса
> и в заголовке Host: разные - это явно попытка взлома.
>
> --
> Best regards,
>  Gena
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



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

From nginx-forum at nginx.us  Wed Jun 11 20:32:12 2014
From: nginx-forum at nginx.us (sahe123)
Date: Wed, 11 Jun 2014 16:32:12 -0400
Subject: =?UTF-8?B?UmU6IFN0YXR1cyBSZWFkaW5nINGB0YLQsNC7INC90YPQu9C10LLRi9C8?=
In-Reply-To: <2674499.jmRQdCx8Va@vbart-workstation>
References: <2674499.jmRQdCx8Va@vbart-workstation>
Message-ID: <ccfd511f830d56327a4889a8c113ddce.NginxMailingListRussian@forum.nginx.org>

Валентин Бартенев Wrote:
> > Валентин, по этой же причине может уменьшиться количество принятых
> (и
> > соответственно обработаннх) соединений в той же статистике?
> Если речь идет об accepts и handled, то нет, это не влияет.

То есть если к серверу подключиться в 10 потоков и не передавать ни одного
байта, то reading будет 0, а accepted и handled будут 10?

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


From vbart at nginx.com  Wed Jun 11 20:37:22 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 12 Jun 2014 00:37:22 +0400
Subject: =?UTF-8?B?UmU6IFN0YXR1cyBSZWFkaW5nINGB0YLQsNC7INC90YPQu9C10LLRi9C8?=
In-Reply-To: <ccfd511f830d56327a4889a8c113ddce.NginxMailingListRussian@forum.nginx.org>
References: <2674499.jmRQdCx8Va@vbart-workstation>
 <ccfd511f830d56327a4889a8c113ddce.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3183265.eIKppMBXml@vbart-laptop>

On Wednesday 11 June 2014 16:32:12 sahe123 wrote:
> Валентин Бартенев Wrote:
> > > Валентин, по этой же причине может уменьшиться количество принятых (и
> > > соответственно обработаннх) соединений в той же статистике?
> > Если речь идет об accepts и handled, то нет, это не влияет.
> 
> То есть если к серверу подключиться в 10 потоков и не передавать ни одного
> байта, то reading будет 0, а accepted и handled будут 10?
> 

Да, примерно так.

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

From gmm at csdoc.com  Thu Jun 12 12:40:21 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Thu, 12 Jun 2014 15:40:21 +0300
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <20140611195331.GD1849@mdounin.ru>
References: <52CEAABF.6030504@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop>
 <53982FB4.8090903@csdoc.com> <2674454.V4cZd09FeB@vbart-workstation>
 <53983CB2.9080808@csdoc.com> <20140611195331.GD1849@mdounin.ru>
Message-ID: <53999FB5.2040108@csdoc.com>

On 11.06.2014 22:53, Maxim Dounin wrote:

>>>>>>>>>> http://habrahabr.ru/post/166855/
...
>>>>> Единственный правильный способ: пойти в IETF с предложением исправить
>>>>> соответствующие RFC, которые в том числе оговаривают, что следует делать
>>>>> при получении нескольких заголовков Host, ну а потом уже сюда.
...
>> http://tools.ietf.org/html/rfc7230#section-5.4
>>
>>     A server MUST respond with a 400 (Bad Request) status code to any
>>     HTTP/1.1 request message that lacks a Host header field and to any
>>     request message that contains more than one Host header field or a
>>     Host header field with an invalid field-value.
>>
>> "invalid field-value" - это в том числе, когда клиент не выполняет
>> требований, которые изложены выше в этом же документе:
>>
>>     A client MUST send a Host header field in all HTTP/1.1 request
>>     messages.  If the target URI includes an authority component, then a
>>     client MUST send a field-value for Host that is identical to that
>>     authority component, excluding any userinfo subcomponent and its "@"
>>     delimiter (Section 2.7.1).
>
> Если исходить из такой трактовки термина "invalid field-value", то
> ранее процитированное требование про "the proxy MUST ignore the
> received Host header..." и далее по тексту - не имеет смысла.

В стандарте дается однозначное определение, что такое "proxy":

     A "proxy" is a message-forwarding agent that is selected
     by the client, usually via local configuration rules.

nginx - это "reverse proxy" / "gateway", и все те требования,
которые там предъявляются к "proxy", - к nginx не применимы.

Как подходить к трактовке термина "invalid field-value"
в RFC 7230 тоже написано: http://tools.ietf.org/html/rfc7230#section-1.1

Сейчас nginx этим требованиям стандарта HTTP/1.1 не соответствует,
и пытается обрабатывать те запросы, на которые он на самом деле
MUST respond with a 400 (Bad Request) status code.

И это создает security проблемы с backend`ами, которые работают
по протоколу FastCGI и расчитывают на то, что nginx соответствует
требованиям стандарта HTTP/1.1 и не пропустит на backend запрос
с невалидным значением в заголовке Host. (RFC 2616 или RFC 7230)

Более правильно в этой ситуации наверное будет все-таки
привести nginx в соответствие с требованиями RFC 7230,
вместо того чтобы добавлять workaround`ы для этого бага
на стороне каждого backend`а, который работает с nginx.

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

Вопрос: признают ли разработчики nginx эту ошибку
и будет ли она исправлена в новых версиях сервера?

Второй вопрос: признается ли эта ошибка в nginx
проблемой с безопасностью (security vulnerability)
и будет ли по этому поводу выпущено CVE / advisorу
на http://nginx.org/en/security_advisories.html ?

-- 
Best regards,
  Gena


From nginx-forum at nginx.us  Thu Jun 12 14:47:14 2014
From: nginx-forum at nginx.us (S.A.N)
Date: Thu, 12 Jun 2014 10:47:14 -0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <53983CB2.9080808@csdoc.com>
References: <53983CB2.9080808@csdoc.com>
Message-ID: <e871de016853a9a0892439dceccac45e.NginxMailingListRussian@forum.nginx.org>

Gena Makhomed Wrote:
-------------------------------------------------------
> 
> и да, отвечать с 400 статусом тут даже более логично,
> потому что если authority component в строке запроса
> и в заголовке Host: разные - это явно попытка взлома.
> 

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

Не понятная позиция Nginx в нежелании реализовать данную логику.

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


From nginx-forum at nginx.us  Thu Jun 12 19:33:04 2014
From: nginx-forum at nginx.us (sahe123)
Date: Thu, 12 Jun 2014 15:33:04 -0400
Subject: =?UTF-8?B?UmU6IFN0YXR1cyBSZWFkaW5nINGB0YLQsNC7INC90YPQu9C10LLRi9C8?=
In-Reply-To: <3183265.eIKppMBXml@vbart-laptop>
References: <3183265.eIKppMBXml@vbart-laptop>
Message-ID: <0ff85d3fddb819d75d0cbedb574b9b07.NginxMailingListRussian@forum.nginx.org>

Валентин Бартенев Wrote:
-------------------------------------------------------
> > То есть если к серверу подключиться в 10 потоков и не передавать ни
> одного
> > байта, то reading будет 0, а accepted и handled будут 10?
> Да, примерно так.

Спасибо за ответ, тогда я не знаю что делать.
После обновления на 1.6.0 у меня резко (в 2 - 2.5 раза) падает график
обработанных соединений (после возврата старой версии график так же резко
восстанавливается).
График этот считается на основе accepted/handled.
Визуально все работает, ошибок не видно.
Попробую провести эксперимент с пустыми коннектами.

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


From vbart at nginx.com  Thu Jun 12 19:37:32 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 12 Jun 2014 23:37:32 +0400
Subject: =?UTF-8?B?UmU6IFN0YXR1cyBSZWFkaW5nINGB0YLQsNC7INC90YPQu9C10LLRi9C8?=
In-Reply-To: <0ff85d3fddb819d75d0cbedb574b9b07.NginxMailingListRussian@forum.nginx.org>
References: <3183265.eIKppMBXml@vbart-laptop>
 <0ff85d3fddb819d75d0cbedb574b9b07.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3210681.Fp6r4txJIg@vbart-laptop>

On Thursday 12 June 2014 15:33:04 sahe123 wrote:
> Валентин Бартенев Wrote:
> -------------------------------------------------------
> > > То есть если к серверу подключиться в 10 потоков и не передавать ни
> > одного
> > > байта, то reading будет 0, а accepted и handled будут 10?
> > Да, примерно так.
> 
> Спасибо за ответ, тогда я не знаю что делать.
> После обновления на 1.6.0 у меня резко (в 2 - 2.5 раза) падает график
> обработанных соединений (после возврата старой версии график так же резко
> восстанавливается).
> График этот считается на основе accepted/handled.
> Визуально все работает, ошибок не видно.
> Попробую провести эксперимент с пустыми коннектами.
> 

Вы уверены, что ваш график показывает именно accepted или handled,
а не requests?

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

From nginx-forum at nginx.us  Thu Jun 12 19:48:58 2014
From: nginx-forum at nginx.us (sahe123)
Date: Thu, 12 Jun 2014 15:48:58 -0400
Subject: =?UTF-8?B?UmU6IFN0YXR1cyBSZWFkaW5nINGB0YLQsNC7INC90YPQu9C10LLRi9C8?=
In-Reply-To: <3210681.Fp6r4txJIg@vbart-laptop>
References: <3210681.Fp6r4txJIg@vbart-laptop>
Message-ID: <9b620a324717ae8c654a29460946b6c6.NginxMailingListRussian@forum.nginx.org>

Валентин Бартенев Wrote:
> > Спасибо за ответ, тогда я не знаю что делать.
> > После обновления на 1.6.0 у меня резко (в 2 - 2.5 раза) падает
> график
> > обработанных соединений (после возврата старой версии график так же
> резко
> > восстанавливается).
> > График этот считается на основе accepted/handled.
> > Визуально все работает, ошибок не видно.
> > Попробую провести эксперимент с пустыми коннектами.
> Вы уверены, что ваш график показывает именно accepted или handled,
> а не requests?

Вы абсолютно правы, как выяснилось, он показывает requests.
Сейчас как раз скачиваю старую версию, чтобы проверить реакцию requests на
пустые коннекты.

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


From nginx-forum at nginx.us  Thu Jun 12 20:01:14 2014
From: nginx-forum at nginx.us (sahe123)
Date: Thu, 12 Jun 2014 16:01:14 -0400
Subject: =?UTF-8?B?UmU6IFN0YXR1cyBSZWFkaW5nINGB0YLQsNC7INC90YPQu9C10LLRi9C8?=
In-Reply-To: <3210681.Fp6r4txJIg@vbart-laptop>
References: <3210681.Fp6r4txJIg@vbart-laptop>
Message-ID: <0340e5443a13a9db0f42f3cb1951cd6f.NginxMailingListRussian@forum.nginx.org>

Валентин Бартенев Wrote:
-------------------------------------------------------
> Вы уверены, что ваш график показывает именно accepted или handled,
> а не requests?

Проверил, вы правы, все версии считают accepted и handled по факту
соединения, в момент подключения они увеличиваются на единицу, а requests
увеличивается только в старой версии и только после разрыва соединения.

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

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

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


From nginx-forum at nginx.us  Fri Jun 13 08:51:44 2014
From: nginx-forum at nginx.us (AlexFC)
Date: Fri, 13 Jun 2014 04:51:44 -0400
Subject: =?UTF-8?B?0L3QtdC/0L7QvdGP0YLQvdGL0Lkg0LHQsNCzLCDQutC+0L3RgtC10L3RgiDRgSA=?=
 =?UTF-8?B?0LTRgNGD0LPQvtCz0L4g0LTQvtC80LXQvdCw?=
Message-ID: <f86f7fa0c47cd205992179d44843d93b.NginxMailingListRussian@forum.nginx.org>

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

Столкнулся со следующей проблемой:
Возникает на каждом новом юзере, воспроизводится.
Создаю новый ввв-домен, можно с новым пользователем, можно на существующем.
Обращаюсь http://домен/images/logo.png (или что угодно другое из статики не
существующей в этом домене).
Получаю в ответ картинку другого пользователя.
В логе nginx вижу, что обращение происходит к другому пользователю, 
хотя в nginx.conf явно прописаны server_name для обоих доменов, никаких
вайлдкардов, никаких особых конфигов, просто 2 обычных пользователя.
Делаю service nginx restart, проблема уходит, получаю 404.
Если я после этого пересоздам домен, все будет нормально.
Если же я удалю домен, сделаю nginx restart, и создам опять, проблема опять
возникает.
nginx reload не помогает!

Немного о системе:
Centos 6.x, ISPManager 4 Pro
NGINX + Apache + PHP FastCGI

NGINX обновил до 1.6.0, не помогло.

Буду рад любому совету, спасибо!

Ну и немного конфигов:
Конфиг домена, с которого отдается статика (индивидуальные данные заменил):
server {
server_name somedomain.com www.somedomain.com;
listen 1.2.3.4;
set $root_path /var/www/username/data/www/somedomain.com;
location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|av
i|zip|gz|bz2?|rar|swf)$ {
root $root_path;
access_log /var/www/nginx-logs/username isp;
access_log /var/www/httpd-logs/somedomain.com.access.log ;
error_page 404 = @fallback;
}
location / {
proxy_pass http://1.2.3.4:81;
proxy_redirect http://1.2.3.4:81/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
location ~* ^/(webstat|awstats|webmail|myadmin|pgadmin)/ {
proxy_pass http://1.2.3.4:81;
proxy_redirect http://1.2.3.4:81/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
location @fallback {
proxy_pass http://1.2.3.4:81;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
location ^~ /webstat/ {
auth_basic "Restricted area";
auth_basic_user_file /var/www/username/data/etc/138789.passwd;
try_files $uri @fallback;
}
include /usr/local/ispmgr/etc/nginx.inc;
}

Вполне себе стандартный конфиг сгенерированный ISPManager, такой же у всех
остальных +/-

nginx.conf:
user nginx;worker_processes 10;
worker_rlimit_nofile 32768;

error_log /var/log/nginx/error.log;
error_log /var/log/nginx/error.log notice;
error_log /var/log/nginx/error.log info;

pid /var/run/nginx.pid;


#----------------------------------------------------------------------
# Events Module
#
# http://wiki.nginx.org/NginxHttpEventsModule
#
#----------------------------------------------------------------------

events {
worker_connections 1024;
}


#----------------------------------------------------------------------
# HTTP Core Module
#
# http://wiki.nginx.org/NginxHttpCoreModule
#
#----------------------------------------------------------------------

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
log_format main2 '$remote_addr - $remote_user [$time_local] "$request $host"
'
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main2 buffer=32k;

sendfile on;
#tcp_nopush on;

#keepalive_timeout 0;
keepalive_timeout 65;
proxy_read_timeout 2000;
proxy_connect_timeout 300;
proxy_cache_path cache levels=1 keys_zone=my-cache:20m max_size=1000m
inactive=600m;
proxy_temp_path cache/tmp;
server_names_hash_max_size 32768;
proxy_buffers 8 16k;
proxy_buffer_size 32k;

#gzip on;

# Load config files from the /etc/nginx/conf.d directory
# The default server is in conf.d/default.conf
include /etc/nginx/conf.d/*.conf;

open_file_cache max=20000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;

client_max_body_size 160M;
log_format isp '$bytes_sent $request_length';
server {
.....
далее конфиги доменов (типовые)

в conf.d значимый только default.conf:
server {
listen 80 default_server;
server_name _;

#charset koi8-r;

#access_log logs/host.access.log main;

location / {
root /usr/share/nginx/html;
index index.html index.htm;
}

error_page 404 /404.html;
location = /404.html {
root /usr/share/nginx/html;
}

# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}

# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}

# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# root html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
# include fastcgi_params;
#}

# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}

В /usr/share/nginx/html дефолтный welcome от nginx.


Проверил, при условии что на тестовом домене отдается картинка домена X,
если на тестовом домене положить вместо нее другую картинку, отдаваться
будет все равно картинка домена X, а вот если положить картинку с другим
именем файла, то будет отдаваться правильно - файл с тестового домена.

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


From kulmaks at gmail.com  Fri Jun 13 09:48:30 2014
From: kulmaks at gmail.com (Maksim Kulik)
Date: Fri, 13 Jun 2014 12:48:30 +0300
Subject: =?UTF-8?B?UmU6INC90LXQv9C+0L3Rj9GC0L3Ri9C5INCx0LDQsywg0LrQvtC90YLQtdC90YIg?=
 =?UTF-8?B?0YEg0LTRgNGD0LPQvtCz0L4g0LTQvtC80LXQvdCw?=
In-Reply-To: <f86f7fa0c47cd205992179d44843d93b.NginxMailingListRussian@forum.nginx.org>
References: <f86f7fa0c47cd205992179d44843d93b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CA+zavH=KgTd2v6wr-T9Nu-JL_uFDJtNUWH6uHnMGKnWRPaxjPw@mail.gmail.com>

Здравствуйте!
Посмотрите в сторону
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_key
Вам надо включить в proxy_cache_key переменную $host (как минимум).


13 июня 2014 г., 11:51 пользователь AlexFC <nginx-forum at nginx.us> написал:

> Здравствуйте!
>
> Столкнулся со следующей проблемой:
> Возникает на каждом новом юзере, воспроизводится.
> Создаю новый ввв-домен, можно с новым пользователем, можно на существующем.
> Обращаюсь http://домен/images/logo.png
> <http://xn--d1acufc/images/logo.png> (или что угодно другое из статики не
> существующей в этом домене).
> Получаю в ответ картинку другого пользователя.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,250834,250834#msg-250834
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140613/a76b156d/attachment.html>

From nginx-forum at nginx.us  Fri Jun 13 10:05:43 2014
From: nginx-forum at nginx.us (AlexFC)
Date: Fri, 13 Jun 2014 06:05:43 -0400
Subject: =?UTF-8?B?UmU6INC90LXQv9C+0L3Rj9GC0L3Ri9C5INCx0LDQsywg0LrQvtC90YLQtdC90YIg?=
 =?UTF-8?B?0YEg0LTRgNGD0LPQvtCz0L4g0LTQvtC80LXQvdCw?=
In-Reply-To: <CA+zavH=KgTd2v6wr-T9Nu-JL_uFDJtNUWH6uHnMGKnWRPaxjPw@mail.gmail.com>
References: <CA+zavH=KgTd2v6wr-T9Nu-JL_uFDJtNUWH6uHnMGKnWRPaxjPw@mail.gmail.com>
Message-ID: <f022a1541b1b6bb5f0dbdc3ac9bcf114.NginxMailingListRussian@forum.nginx.org>

Глобально кеш не используется, кеш был активирован для одного из доменов, не
домена X и не тестового, для чистоты эксперимента убрал, и вычистил из
конфига все что касается proxy_cache*
И на сколько я понимаю это все же кеширование динамического контента от
апача, который в данном случае вообще не задействован.
Прибиваю апач вообще проблема таже самая, это статика отдаваемая NGINX.

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


From denis at webmaster.spb.ru  Sat Jun 14 05:34:36 2014
From: denis at webmaster.spb.ru (denis)
Date: Sat, 14 Jun 2014 09:34:36 +0400
Subject: =?UTF-8?B?UmU6INC90LXQv9C+0L3Rj9GC0L3Ri9C5INCx0LDQsywg0LrQvtC90YLQtdC90YIg?=
 =?UTF-8?B?0YEg0LTRgNGD0LPQvtCz0L4g0LTQvtC80LXQvdCw?=
In-Reply-To: <f86f7fa0c47cd205992179d44843d93b.NginxMailingListRussian@forum.nginx.org>
References: <f86f7fa0c47cd205992179d44843d93b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <539BDEEC.3020804@webmaster.spb.ru>

13.06.2014 12:51, AlexFC пишет:
> Здравствуйте!
>
> Столкнулся со следующей проблемой:
> Возникает на каждом новом юзере, воспроизводится.
> Создаю новый ввв-домен, можно с новым пользователем, можно на существующем.
> Обращаюсь http://домен/images/logo.png (или что угодно другое из статики не
> существующей в этом домене).
> Получаю в ответ картинку другого пользователя.
> В логе nginx вижу, что обращение происходит к другому пользователю,
> хотя в nginx.conf явно прописаны server_name для обоих доменов, никаких
> вайлдкардов, никаких особых конфигов, просто 2 обычных пользователя.
> Делаю service nginx restart, проблема уходит, получаю 404.
возможно, не было релоада, имеет смысл создать ветку на форуме 
ispmanager. Без релоада должно отдавать файлы default домена или того, 
кто первый в списке.

> Если я после этого пересоздам домен, все будет нормально.
> Если же я удалю домен, сделаю nginx restart, и создам опять, проблема опять
> возникает.
> nginx reload не помогает!
практика показывает, что в некоторых версиях линей reload при ошибке в 
конфиге говорит ОК, но ничего не рестартит, поэтому у меня уже привычка 
сначала делать nginx -t или service nginx configtest. Но чтобы рестарт 
при этом помогал - это похоже на баг. Был например баг с 
mod_passenger+freebsd, после релоада руби ломался, надо было делать 
именно рестарт, но с той поры года 2 прошло.

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


From nginx-forum at nginx.us  Sat Jun 14 05:52:56 2014
From: nginx-forum at nginx.us (AlexFC)
Date: Sat, 14 Jun 2014 01:52:56 -0400
Subject: =?UTF-8?B?UmU6INC90LXQv9C+0L3Rj9GC0L3Ri9C5INCx0LDQsywg0LrQvtC90YLQtdC90YIg?=
 =?UTF-8?B?0YEg0LTRgNGD0LPQvtCz0L4g0LTQvtC80LXQvdCw?=
In-Reply-To: <539BDEEC.3020804@webmaster.spb.ru>
References: <539BDEEC.3020804@webmaster.spb.ru>
Message-ID: <9dbe80cc39a9d1c93e3e0a77c15831ae.NginxMailingListRussian@forum.nginx.org>

denis Wrote:
-------------------------------------------------------
> 13.06.2014 12:51, AlexFC пишет:
> возможно, не было релоада, имеет смысл создать ветку на форуме 
> ispmanager. Без релоада должно отдавать файлы default домена или того,
> 
> кто первый в списке.
Релоад точно происходит, и в том числе я его делал вручную, тестовый домен
начинает работать, с него отдается статика, и динамический контент, но если
есть статика на домене Х с таким же именем файла, то отдается она.
На ISPManager я ветку создал ранее, но думаю, что все же к панели эта
проблема отношения не имеет.

> похоже на какой-то кэш. Может браузера? Вообще такие вещи надо 
> тестировать курлом. Нет ли еще промежуточных серверов, которые могут 
> кэшировать? Что при полном удалении упоминаний кэширования?
Промежуточных серверов нет, вычистил из конфига все что связано с
open_file_cache* и proxy_cache,
выключил апач, проверяю с помощью telnet+tcpdump, проблема воспроизводится.

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


From kulmaks at gmail.com  Sat Jun 14 10:24:55 2014
From: kulmaks at gmail.com (Maksim Kulik)
Date: Sat, 14 Jun 2014 13:24:55 +0300
Subject: =?UTF-8?B?UmU6INC90LXQv9C+0L3Rj9GC0L3Ri9C5INCx0LDQsywg0LrQvtC90YLQtdC90YIg?=
 =?UTF-8?B?0YEg0LTRgNGD0LPQvtCz0L4g0LTQvtC80LXQvdCw?=
In-Reply-To: <9dbe80cc39a9d1c93e3e0a77c15831ae.NginxMailingListRussian@forum.nginx.org>
References: <539BDEEC.3020804@webmaster.spb.ru>
 <9dbe80cc39a9d1c93e3e0a77c15831ae.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CA+zavHk3BAzOGxgfrcSy9Rsyn5+R6DO1mzQ61rGf6tcFPP9OWg@mail.gmail.com>

Попробуйте в необходимом блоке server (или во всех необходимых location)
вписать proxy_cache off;
Эта директива может быть унаследована с верхнего уровня.
14.06.2014 8:53 пользователь "AlexFC" <nginx-forum at nginx.us> написал:

> denis Wrote:
> -------------------------------------------------------
> > 13.06.2014 12:51, AlexFC пишет:
> > возможно, не было релоада, имеет смысл создать ветку на форуме
> > ispmanager. Без релоада должно отдавать файлы default домена или того,
> >
> > кто первый в списке.
> Релоад точно происходит, и в том числе я его делал вручную, тестовый домен
> начинает работать, с него отдается статика, и динамический контент, но если
> есть статика на домене Х с таким же именем файла, то отдается она.
> На ISPManager я ветку создал ранее, но думаю, что все же к панели эта
> проблема отношения не имеет.
>
> > похоже на какой-то кэш. Может браузера? Вообще такие вещи надо
> > тестировать курлом. Нет ли еще промежуточных серверов, которые могут
> > кэшировать? Что при полном удалении упоминаний кэширования?
> Промежуточных серверов нет, вычистил из конфига все что связано с
> open_file_cache* и proxy_cache,
> выключил апач, проверяю с помощью telnet+tcpdump, проблема воспроизводится.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,250834,250851#msg-250851
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140614/26128a54/attachment.html>

From mdounin at mdounin.ru  Sat Jun 14 18:14:34 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sat, 14 Jun 2014 22:14:34 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <53999FB5.2040108@csdoc.com>
References: <52CEAABF.6030504@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop>
 <53982FB4.8090903@csdoc.com> <2674454.V4cZd09FeB@vbart-workstation>
 <53983CB2.9080808@csdoc.com> <20140611195331.GD1849@mdounin.ru>
 <53999FB5.2040108@csdoc.com>
Message-ID: <20140614181433.GL1849@mdounin.ru>

Hello!

On Thu, Jun 12, 2014 at 03:40:21PM +0300, Gena Makhomed wrote:

> On 11.06.2014 22:53, Maxim Dounin wrote:
> 
> >>>>>>>>>>http://habrahabr.ru/post/166855/
> ...
> >>>>>Единственный правильный способ: пойти в IETF с предложением исправить
> >>>>>соответствующие RFC, которые в том числе оговаривают, что следует делать
> >>>>>при получении нескольких заголовков Host, ну а потом уже сюда.
> ...
> >>http://tools.ietf.org/html/rfc7230#section-5.4
> >>
> >>    A server MUST respond with a 400 (Bad Request) status code to any
> >>    HTTP/1.1 request message that lacks a Host header field and to any
> >>    request message that contains more than one Host header field or a
> >>    Host header field with an invalid field-value.
> >>
> >>"invalid field-value" - это в том числе, когда клиент не выполняет
> >>требований, которые изложены выше в этом же документе:
> >>
> >>    A client MUST send a Host header field in all HTTP/1.1 request
> >>    messages.  If the target URI includes an authority component, then a
> >>    client MUST send a field-value for Host that is identical to that
> >>    authority component, excluding any userinfo subcomponent and its "@"
> >>    delimiter (Section 2.7.1).
> >
> >Если исходить из такой трактовки термина "invalid field-value", то
> >ранее процитированное требование про "the proxy MUST ignore the
> >received Host header..." и далее по тексту - не имеет смысла.
> 
> В стандарте дается однозначное определение, что такое "proxy":
> 
>     A "proxy" is a message-forwarding agent that is selected
>     by the client, usually via local configuration rules.
> 
> nginx - это "reverse proxy" / "gateway", и все те требования,
> которые там предъявляются к "proxy", - к nginx не применимы.

Я нигде не говорил, что требование - применимо к nginx'у.  Я 
говорил, что упомянутое требование - не имеет смысла, если 
пользоваться предлагаемой интерпретацией термина "invalid 
field-value".

Прокси-сервер, помимо всего прочего, является сервером, и 
процитированное требование вернуть 400 в ответ на "Host header 
field with an invalid field-value" - к нему тоже относится.  
Соответственно, если трактовать термин "invalid field-value" как 
включающий проверку не только синтаксиса, но и требований, 
предъявляемых к формированию заголовка Host клиентом, то 
требование "ignore the received Host header" теряет смысл.

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

> Как подходить к трактовке термина "invalid field-value"
> в RFC 7230 тоже написано: http://tools.ietf.org/html/rfc7230#section-1.1

Приведённая ссылка не имеет никакого отношения к термину "invalid 
field-value".

Теримн "field-value" расшифровывается в "3.2.  Header Fields", 
http://tools.ietf.org/html/rfc7230#section-3.2:

    field-value    = *( field-content / obs-fold )

Соответственно invalid - это то, что не соответствует указанному 
синтаксису.

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

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


From gmm at csdoc.com  Sun Jun 15 20:07:58 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Sun, 15 Jun 2014 23:07:58 +0300
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <20140614181433.GL1849@mdounin.ru>
References: <52CEAABF.6030504@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop>
 <53982FB4.8090903@csdoc.com> <2674454.V4cZd09FeB@vbart-workstation>
 <53983CB2.9080808@csdoc.com> <20140611195331.GD1849@mdounin.ru>
 <53999FB5.2040108@csdoc.com> <20140614181433.GL1849@mdounin.ru>
Message-ID: <539DFD1E.3010605@csdoc.com>

On 14.06.2014 21:14, Maxim Dounin wrote:

>>>>>>>>>>>> http://habrahabr.ru/post/166855/
...
> Прокси-сервер, помимо всего прочего, является сервером, и
> процитированное требование вернуть 400 в ответ на "Host header
> field with an invalid field-value" - к нему тоже относится.
> Соответственно, если трактовать термин "invalid field-value" как
> включающий проверку не только синтаксиса, но и требований,
> предъявляемых к формированию заголовка Host клиентом, то
> требование "ignore the received Host header" теряет смысл.

Максим, теперь я понял, в чем была моя ошибка, спасибо!

> Теримн "field-value" расшифровывается в "3.2.  Header Fields",
> http://tools.ietf.org/html/rfc7230#section-3.2:
>
>      field-value    = *( field-content / obs-fold )
>
> Соответственно invalid - это то, что не соответствует указанному
> синтаксису.

Понял, спасибо!

Но есть один не совсем понятный нюанс -
озвученные в RFC 7230 требования к клиенту:

http://tools.ietf.org/html/rfc7230#section-5.4

    A client MUST send a Host header field in all HTTP/1.1 request
    messages.  If the target URI includes an authority component, then a
    client MUST send a field-value for Host that is identical to that
    authority component, excluding any userinfo subcomponent and its "@"
    delimiter (Section 2.7.1).

- это ведь требования к синтаксису, которые обязательны для выполнения.
А вот что есть в RFC 7231:

http://tools.ietf.org/html/rfc7231#section-6.5.1

6.5.1. 400 Bad Request

    The 400 (Bad Request) status code indicates that the server cannot or
    will not process the request due to something that is perceived to be
    a client error (e.g., malformed request syntax, invalid request
    message framing, or deceptive request routing).

Следовательно, сервер имеет право вернуть 400 статус,
если получит запрос с разными authority component
в заголовке Host и в absolute Request URI ?

Кроме того, в разделе 5.5. Effective Request URI
http://tools.ietf.org/html/rfc7230#section-5.5

даже прямо говорят, что запрос может быть misdirected,
deliberately or accidentally, и что origin server должен
сам решить, обрабатывать такой запрос или нет, потому что
"it might indicate an attempt to bypass security filters,
trick the server into delivering non-public content,
or poison a cache."

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

GET http://apple.com/ HTTP/1.1
Host: samsung.com

Разве ответить на такой запрос 400-м статусом не будет лучше?

-- 
Best regards,
  Gena


From mdounin at mdounin.ru  Mon Jun 16 12:00:53 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 16 Jun 2014 16:00:53 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <539DFD1E.3010605@csdoc.com>
References: <52CEAABF.6030504@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop>
 <53982FB4.8090903@csdoc.com> <2674454.V4cZd09FeB@vbart-workstation>
 <53983CB2.9080808@csdoc.com> <20140611195331.GD1849@mdounin.ru>
 <53999FB5.2040108@csdoc.com> <20140614181433.GL1849@mdounin.ru>
 <539DFD1E.3010605@csdoc.com>
Message-ID: <20140616120053.GS1849@mdounin.ru>

Hello!

On Sun, Jun 15, 2014 at 11:07:58PM +0300, Gena Makhomed wrote:

> On 14.06.2014 21:14, Maxim Dounin wrote:
> 
> >>>>>>>>>>>>http://habrahabr.ru/post/166855/
> ...
> >Прокси-сервер, помимо всего прочего, является сервером, и
> >процитированное требование вернуть 400 в ответ на "Host header
> >field with an invalid field-value" - к нему тоже относится.
> >Соответственно, если трактовать термин "invalid field-value" как
> >включающий проверку не только синтаксиса, но и требований,
> >предъявляемых к формированию заголовка Host клиентом, то
> >требование "ignore the received Host header" теряет смысл.
> 
> Максим, теперь я понял, в чем была моя ошибка, спасибо!
> 
> >Теримн "field-value" расшифровывается в "3.2.  Header Fields",
> >http://tools.ietf.org/html/rfc7230#section-3.2:
> >
> >     field-value    = *( field-content / obs-fold )
> >
> >Соответственно invalid - это то, что не соответствует указанному
> >синтаксису.
> 
> Понял, спасибо!
> 
> Но есть один не совсем понятный нюанс -
> озвученные в RFC 7230 требования к клиенту:
> 
> http://tools.ietf.org/html/rfc7230#section-5.4
> 
>    A client MUST send a Host header field in all HTTP/1.1 request
>    messages.  If the target URI includes an authority component, then a
>    client MUST send a field-value for Host that is identical to that
>    authority component, excluding any userinfo subcomponent and its "@"
>    delimiter (Section 2.7.1).
> 
> - это ведь требования к синтаксису, которые обязательны для выполнения.

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

> А вот что есть в RFC 7231:
> 
> http://tools.ietf.org/html/rfc7231#section-6.5.1
> 
> 6.5.1. 400 Bad Request
> 
>    The 400 (Bad Request) status code indicates that the server cannot or
>    will not process the request due to something that is perceived to be
>    a client error (e.g., malformed request syntax, invalid request
>    message framing, or deceptive request routing).
> 
> Следовательно, сервер имеет право вернуть 400 статус,
> если получит запрос с разными authority component
> в заголовке Host и в absolute Request URI ?

Сервер имеет право вернуть 400 более или менее в любой момент.

> Кроме того, в разделе 5.5. Effective Request URI
> http://tools.ietf.org/html/rfc7230#section-5.5
> 
> даже прямо говорят, что запрос может быть misdirected,
> deliberately or accidentally, и что origin server должен
> сам решить, обрабатывать такой запрос или нет, потому что
> "it might indicate an attempt to bypass security filters,
> trick the server into delivering non-public content,
> or poison a cache."
> 
> именно это ведь и происходит в случае запроса
> 
> GET http://apple.com/ HTTP/1.1
> Host: samsung.com
> 
> Разве ответить на такой запрос 400-м статусом не будет лучше?

Это зависит от многих факторов.  Вот тут Валентин давеча 
напрограммировал возврат 400, если имя, указанное в SNI, не 
совпадало с именем, используемым в запросе, ибо RFC 6066 говорит:

   ... If the server_name is
   established in the TLS session handshake, the client SHOULD NOT
   attempt to request a different server name at the application layer.

Так пришлось распрограмировать обратно - потому что Chrome 
использует "a different server name at the application layer", 
когда считает нужным/возможным.

То, как ведёт себя nginx по умолчанию - вполне себе безопасно, и 
проблемы нет.  Какая-либо проблема появляется тогда и только 
тогда, когда администратор начинает писать в конфиге $http_host, 
не думая о последствиях.  Есть мнение, что совсем простое решение 
этой проблемы - не делать так (c) анекдот.

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


From nginx-forum at nginx.us  Mon Jun 16 15:19:57 2014
From: nginx-forum at nginx.us (S.A.N)
Date: Mon, 16 Jun 2014 11:19:57 -0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <20140616120053.GS1849@mdounin.ru>
References: <20140616120053.GS1849@mdounin.ru>
Message-ID: <f4be6889579f213d513cb3b0f134de77.NginxMailingListRussian@forum.nginx.org>

Maxim Dounin Wrote:
-------------------------------------------------------
> Какая-либо проблема появляется тогда и только 
> тогда, когда администратор начинает писать в конфиге $http_host, 
> не думая о последствиях.  Есть мнение, что совсем простое решение 
> этой проблемы - не делать так (c) анекдот.

Вся проблема в том что сами программисты Nginx в модуле FastCGI используют
переменную $http_host для HTTP_HOST, вместо нормализованной переменой $host,
администраторам на оборот приходится исправлять это своими руками и писать в
конфиге
fastcgi_param  HTTP_HOST  $host;
Если следовать вашей логике, надо изменить код модуля FastCGI, чтобы по
умолчанию Nginx был вполне себе безопасный.

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


From mdounin at mdounin.ru  Mon Jun 16 15:37:02 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 16 Jun 2014 19:37:02 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <f4be6889579f213d513cb3b0f134de77.NginxMailingListRussian@forum.nginx.org>
References: <20140616120053.GS1849@mdounin.ru>
 <f4be6889579f213d513cb3b0f134de77.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140616153702.GA1849@mdounin.ru>

Hello!

On Mon, Jun 16, 2014 at 11:19:57AM -0400, S.A.N wrote:

> Maxim Dounin Wrote:
> -------------------------------------------------------
> > Какая-либо проблема появляется тогда и только 
> > тогда, когда администратор начинает писать в конфиге $http_host, 
> > не думая о последствиях.  Есть мнение, что совсем простое решение 
> > этой проблемы - не делать так (c) анекдот.
> 
> Вся проблема в том что сами программисты Nginx в модуле FastCGI используют
> переменную $http_host для HTTP_HOST, вместо нормализованной переменой $host,
> администраторам на оборот приходится исправлять это своими руками и писать в
> конфиге
> fastcgi_param  HTTP_HOST  $host;
> Если следовать вашей логике, надо изменить код модуля FastCGI, чтобы по
> умолчанию Nginx был вполне себе безопасный.

По умолчанию в fastcgi http-заголовки передаются как есть, в виде 
параметров HTTP_*.  Каноническое же имя сервера доступно в 
параметре SERVER_NAME.  Что из этого и как использовать - это 
вопрос к приложению, а не к nginx'у.

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


From nginx-forum at nginx.us  Mon Jun 16 19:36:38 2014
From: nginx-forum at nginx.us (S.A.N)
Date: Mon, 16 Jun 2014 15:36:38 -0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <20140616153702.GA1849@mdounin.ru>
References: <20140616153702.GA1849@mdounin.ru>
Message-ID: <a713ee6c7b7d5a8540b8df740f1a6f95.NginxMailingListRussian@forum.nginx.org>

> > Maxim Dounin Wrote:
> > -------------------------------------------------------
> > > Какая-либо проблема появляется тогда и только 
> > > тогда, когда администратор начинает писать в конфиге $http_host, 
> > > не думая о последствиях.  Есть мнение, что совсем простое решение 
> > > этой проблемы - не делать так (c) анекдот.
> > 
> > Вся проблема в том что сами программисты Nginx в модуле FastCGI
> используют
> > переменную $http_host для HTTP_HOST, вместо нормализованной
> переменой $host,
> > администраторам на оборот приходится исправлять это своими руками и
> писать в
> > конфиге
> > fastcgi_param  HTTP_HOST  $host;
> > Если следовать вашей логике, надо изменить код модуля FastCGI, чтобы
> по
> > умолчанию Nginx был вполне себе безопасный.
> 
> По умолчанию в fastcgi http-заголовки передаются как есть, в виде 
> параметров HTTP_*.  Каноническое же имя сервера доступно в 
> параметре SERVER_NAME.  Что из этого и как использовать - это 
> вопрос к приложению, а не к nginx'у.

Я знаю, и уже выше объяснял почему бекенд-приложениям нужно использовать
HTTP_HOST вместо SERVER_NAME.
Значения SERVER_NAME не может использоваться, если в директиве server_name
используется маска или бекенд обрабатывает запросы для default_server.

Ещё раз приведу пример, в котором мы легко можем получить доступ, к закрытым
на уровне Nginx ресурсам.

server
{
  server_name *.example.com;
  ...
  fastcgi_pass php;
}

server
{
  server_name private.example.com;

  location / {
      allow 192.168.1.0/24;
      deny all;

      fastcgi_pass php;

      auth_request /auth;
    }
    ...
 }

Как видно два хоста используют один upstream, на котором бекенд приложения
даёт расширенные привилегии юзерам private.example.com, в расчете на то что
Nginx предварительно сделал проверку по IP и успешно провел аунтификацию,
всё вроде логично и удобно сделано, но такая схема легко ломается таким
запросом.

GET http://example.com/SecureData/ HTTP/1.1
Host: private.example.com

Бекенд получает HTTP_HOST=private.example.com, даёт юзеру привилегии, но
Nginx не проводил проверки по IP и не делал запрос аунтификацию, потому что
отработал хост конфигурации для example.com вместо private.example.com

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

Если мы оба понимаем, что ситуация когда authority component и значения Host
разные, это исключительная ситуация и её нужно обрабатывать как Exception, в
этом случаи есть три варианта поведения, выбросить Exception (отдать 400
статус), исправить ошибку (использовать переменую $host), и самый плохой
вариант (антишаблон) ничего не делать и не обрабатывать эту исключительную
ситуацию и оставить все как есть.

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


From gmm at csdoc.com  Mon Jun 16 20:20:57 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Mon, 16 Jun 2014 23:20:57 +0300
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <20140616120053.GS1849@mdounin.ru>
References: <52CEAABF.6030504@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop>
 <53982FB4.8090903@csdoc.com> <2674454.V4cZd09FeB@vbart-workstation>
 <53983CB2.9080808@csdoc.com> <20140611195331.GD1849@mdounin.ru>
 <53999FB5.2040108@csdoc.com> <20140614181433.GL1849@mdounin.ru>
 <539DFD1E.3010605@csdoc.com> <20140616120053.GS1849@mdounin.ru>
Message-ID: <539F51A9.5050302@csdoc.com>

On 16.06.2014 15:00, Maxim Dounin wrote:

>> озвученные в RFC 7230 требования к клиенту:
>>
>> http://tools.ietf.org/html/rfc7230#section-5.4
>>
>>     A client MUST send a Host header field in all HTTP/1.1 request
>>     messages.  If the target URI includes an authority component, then a
>>     client MUST send a field-value for Host that is identical to that
>>     authority component, excluding any userinfo subcomponent and its "@"
>>     delimiter (Section 2.7.1).
>>
>> - это ведь требования к синтаксису, которые обязательны для выполнения.
>
> Нет, это не требования к синтаксису, это требования к семантике.

Запись target URI в виде valid request message - это разве не syntax?

http://tools.ietf.org/html/rfc7231#section-2

    When a client constructs an HTTP/1.1 request message, it sends the
    target URI in one of various forms, as defined in (Section 5.3 of
    [RFC7230]).  When a request is received, the server reconstructs an
    effective request URI for the target resource (Section 5.5 of
    [RFC7230]).

    One design goal of HTTP is to separate resource identification from
    request semantics, which is made possible by vesting the request
    semantics in the request method (Section 4) and a few
    request-modifying header fields (Section 5).

"effective request URI" - это именно что resource identification.

Они ведь разнесли "syntax" и "semantics" по двум отдельным документам:

RFC 7230: Message Syntax and Routing
RFC 7231: Semantics and Content

>> http://tools.ietf.org/html/rfc7231#section-6.5.1
>>
>> 6.5.1. 400 Bad Request
>>
>>     The 400 (Bad Request) status code indicates that the server cannot or
>>     will not process the request due to something that is perceived to be
>>     a client error (e.g., malformed request syntax, invalid request
>>     message framing, or deceptive request routing).
>>
>> Следовательно, сервер имеет право вернуть 400 статус,
>> если получит запрос с разными authority component
>> в заголовке Host и в absolute Request URI ?
>
> Сервер имеет право вернуть 400 более или менее в любой момент.

Да, но здесь явно указывается, когда сервер возвращает 400:
в случае client error, например, "malformed request syntax"
или "deceptive request routing" - эти две причины подходят.

>> Кроме того, в разделе 5.5. Effective Request URI
>> http://tools.ietf.org/html/rfc7230#section-5.5
>>
>> даже прямо говорят, что запрос может быть misdirected,
>> deliberately or accidentally, и что origin server должен
>> сам решить, обрабатывать такой запрос или нет, потому что
>> "it might indicate an attempt to bypass security filters,
>> trick the server into delivering non-public content,
>> or poison a cache."
>>
>> именно это ведь и происходит в случае запроса
>>
>> GET http://apple.com/ HTTP/1.1
>> Host: samsung.com
>>
>> Разве ответить на такой запрос 400-м статусом не будет лучше?
>
> Это зависит от многих факторов.  Вот тут Валентин давеча
> напрограммировал возврат 400, если имя, указанное в SNI, не
> совпадало с именем, используемым в запросе, ибо RFC 6066 говорит:
>
>     ... If the server_name is
>     established in the TLS session handshake, the client SHOULD NOT
>     attempt to request a different server name at the application layer.
>
> Так пришлось распрограмировать обратно - потому что Chrome
> использует "a different server name at the application layer",
> когда считает нужным/возможным.

"SHOULD NOT" - это не запрет, а только лишь рекомендация:
http://tools.ietf.org/html/rfc2119#section-4
так что формально и фактически Chrome ничего не нарушает.

В обсуждаемой выше ситуации написано совсем иначе: "MUST".
http://tools.ietf.org/html/rfc2119#section-1
и если клиент этого не сделал - он сам прислал невалидный запрос,
так что ответить 400-м статусом на такой запрос - вполне разумно.

да и в RFC 7230 об этом тоже есть (про поведение хрома):

http://tools.ietf.org/html/rfc7230#section-2.3

    server MUST NOT assume that two requests on the same connection are
    from the same user agent unless the connection is secured and
    specific to that agent.  Some non-standard HTTP extensions (e.g.,
    [RFC4559]) have been known to violate this requirement, resulting in
    security and interoperability problems.

> То, как ведёт себя nginx по умолчанию - вполне себе безопасно,
> и проблемы нет.  Какая-либо проблема появляется тогда и только
> тогда, когда администратор начинает писать в конфиге $http_host,
> не думая о последствиях.  Есть мнение, что совсем простое решение
> этой проблемы - не делать так (c) анекдот.

Когда nginx выполняет роль origin server или HTTP reverse proxy
- тогда проблем действительно нет, но когда он выполняет роль
"gateway" и communicates с backend`ом по протоколу FastCGI -
тогда получаются очень неприятные проблемы.

Причина проблем: malformed request syntax,
который не получается корректным образом передать на backend.

Что мешает в этой ситуации вернуть 400 статус? Вместо того,
чтобы отсылать на backend невалидный запрос, интерпретируя
клиентский запрос не по спецификации HTTP/1.1 а по спецификации
CGI/1.1, которая не согласуется со спецификацией протокола HTTP/1.1.

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

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

-- 
Best regards,
  Gena


From mdounin at mdounin.ru  Tue Jun 17 06:30:46 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 17 Jun 2014 10:30:46 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <539F51A9.5050302@csdoc.com>
References: <2310697.ov1uODaMRR@vbart-laptop> <53982FB4.8090903@csdoc.com>
 <2674454.V4cZd09FeB@vbart-workstation> <53983CB2.9080808@csdoc.com>
 <20140611195331.GD1849@mdounin.ru> <53999FB5.2040108@csdoc.com>
 <20140614181433.GL1849@mdounin.ru> <539DFD1E.3010605@csdoc.com>
 <20140616120053.GS1849@mdounin.ru> <539F51A9.5050302@csdoc.com>
Message-ID: <20140617063046.GD1849@mdounin.ru>

Hello!

On Mon, Jun 16, 2014 at 11:20:57PM +0300, Gena Makhomed wrote:

> On 16.06.2014 15:00, Maxim Dounin wrote:
> 
> >>озвученные в RFC 7230 требования к клиенту:
> >>
> >>http://tools.ietf.org/html/rfc7230#section-5.4
> >>
> >>    A client MUST send a Host header field in all HTTP/1.1 request
> >>    messages.  If the target URI includes an authority component, then a
> >>    client MUST send a field-value for Host that is identical to that
> >>    authority component, excluding any userinfo subcomponent and its "@"
> >>    delimiter (Section 2.7.1).
> >>
> >>- это ведь требования к синтаксису, которые обязательны для выполнения.
> >
> >Нет, это не требования к синтаксису, это требования к семантике.
> 
> Запись target URI в виде valid request message - это разве не syntax?

Синтаксис - это то, что нарушает требования приведённых нормативных 
грамматик, см. http://tools.ietf.org/html/rfc7231#section-1.2 и 
далее.

[...]

> >>Разве ответить на такой запрос 400-м статусом не будет лучше?
> >
> >Это зависит от многих факторов.  Вот тут Валентин давеча
> >напрограммировал возврат 400, если имя, указанное в SNI, не
> >совпадало с именем, используемым в запросе, ибо RFC 6066 говорит:
> >
> >    ... If the server_name is
> >    established in the TLS session handshake, the client SHOULD NOT
> >    attempt to request a different server name at the application layer.
> >
> >Так пришлось распрограмировать обратно - потому что Chrome
> >использует "a different server name at the application layer",
> >когда считает нужным/возможным.
> 
> "SHOULD NOT" - это не запрет, а только лишь рекомендация:
> http://tools.ietf.org/html/rfc2119#section-4
> так что формально и фактически Chrome ничего не нарушает.

Фактически - упомянутый "SHOULD NOT" на тот момент безусловно 
отклонялся Apache'ом, а противоречащие друг другу Host + 
Request-Line - формально вообще ничего не нарушали до выхода 
HTTPbis.  И что на самом деле происходит в реальной жизни - это 
отдельный интересный вопрос.

Среди прочего, например, HTTPbis явно требует возвращать 400, если 
запрос содержит несколько заголовков Host.  В своё время, однако, 
nginx'у потребовалось от этой практики отказаться:

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

Если мне не изменяет память, причина была всё та же - реальная 
жизнь заставила.

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


From chipitsine at gmail.com  Tue Jun 17 06:40:04 2014
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 17 Jun 2014 12:40:04 +0600
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <53982FB4.8090903@csdoc.com>
References: <52CEAABF.6030504@csdoc.com> <52CFDD57.5040502@csdoc.com>
 <52CFE253.8020801@csdoc.com> <2310697.ov1uODaMRR@vbart-laptop>
 <53982FB4.8090903@csdoc.com>
Message-ID: <CAFHpkQEY_2LMQ08c9CehgVre-QUSWh7GJ9F=8Ahopdn5kHykow@mail.gmail.com>

а расскажите на примерах, как эту "уязвимость" можно эксплуатировать ?


бесконечный пинг-понг между Геннадием и Максимом утомляет ))

11 июня 2014 г., 16:30 пользователь Gena Makhomed <gmm at csdoc.com> написал:
> On 10.01.2014 15:07, Валентин Бартенев wrote:
>
>>>>>>> http://habrahabr.ru/post/166855/
>
>
>> Единственный правильный способ: пойти в IETF с предложением исправить
>> соответствующие RFC, которые в том числе оговаривают, что следует делать
>> при получении нескольких заголовков Host, ну а потом уже сюда.
>
>
> http://tools.ietf.org/html/rfc7230#section-5.4
>
>    When a proxy receives a request with an absolute-form of
>    request-target, the proxy MUST ignore the received Host header field
>    (if any) and instead replace it with the host information of the
>    request-target.  A proxy that forwards such a request MUST generate a
>    new Host field-value based on the received request-target rather than
>    forward the received Host field-value.
>
> Referer: http://www.opennet.ru/opennews/art.shtml?num=39956
>
> --
> Best regards,
>  Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From mdounin at mdounin.ru  Tue Jun 17 07:00:31 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 17 Jun 2014 11:00:31 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <a713ee6c7b7d5a8540b8df740f1a6f95.NginxMailingListRussian@forum.nginx.org>
References: <20140616153702.GA1849@mdounin.ru>
 <a713ee6c7b7d5a8540b8df740f1a6f95.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140617070031.GE1849@mdounin.ru>

Hello!

On Mon, Jun 16, 2014 at 03:36:38PM -0400, S.A.N wrote:

> > > Maxim Dounin Wrote:
> > > -------------------------------------------------------
> > > > Какая-либо проблема появляется тогда и только 
> > > > тогда, когда администратор начинает писать в конфиге $http_host, 
> > > > не думая о последствиях.  Есть мнение, что совсем простое решение 
> > > > этой проблемы - не делать так (c) анекдот.
> > > 
> > > Вся проблема в том что сами программисты Nginx в модуле FastCGI
> > используют
> > > переменную $http_host для HTTP_HOST, вместо нормализованной
> > переменой $host,
> > > администраторам на оборот приходится исправлять это своими руками и
> > писать в
> > > конфиге
> > > fastcgi_param  HTTP_HOST  $host;
> > > Если следовать вашей логике, надо изменить код модуля FastCGI, чтобы
> > по
> > > умолчанию Nginx был вполне себе безопасный.
> > 
> > По умолчанию в fastcgi http-заголовки передаются как есть, в виде 
> > параметров HTTP_*.  Каноническое же имя сервера доступно в 
> > параметре SERVER_NAME.  Что из этого и как использовать - это 
> > вопрос к приложению, а не к nginx'у.
> 
> Я знаю, и уже выше объяснял почему бекенд-приложениям нужно использовать
> HTTP_HOST вместо SERVER_NAME.
> Значения SERVER_NAME не может использоваться, если в директиве server_name
> используется маска или бекенд обрабатывает запросы для default_server.

Если SERVER_NAME нельзя использовать - значит, необходимо передать 
дополнительный параметр, который и использовать.

Использовать HTTP_* поля для чего-то, что позволяет "получить 
доступ" - это неправильно.

> Ещё раз приведу пример, в котором мы легко можем получить доступ, к закрытым
> на уровне Nginx ресурсам.
> 
> server
> {
>   server_name *.example.com;
>   ...
>   fastcgi_pass php;
> }
> 
> server
> {
>   server_name private.example.com;
> 
>   location / {
>       allow 192.168.1.0/24;
>       deny all;
> 
>       fastcgi_pass php;
> 
>       auth_request /auth;
>     }
>     ...
>  }
> 
> Как видно два хоста используют один upstream, на котором бекенд приложения
> даёт расширенные привилегии юзерам private.example.com, в расчете на то что
> Nginx предварительно сделал проверку по IP и успешно провел аунтификацию,
> всё вроде логично и удобно сделано, но такая схема легко ломается таким
> запросом.
> 
> GET http://example.com/SecureData/ HTTP/1.1
> Host: private.example.com
> 
> Бекенд получает HTTP_HOST=private.example.com, даёт юзеру привилегии, но
> Nginx не проводил проверки по IP и не делал запрос аунтификацию, потому что
> отработал хост конфигурации для example.com вместо private.example.com

Проблема в том, что приложение некорректно предполагает, что 
HTTP_HOST=private.example.com чем-то отличается от других.  Как 
показывает пример запроса выше - это не так.  И "не так" - не 
только в nginx'е, но и в других серверах.

Не надо себя обманывать и пытаться закрыть nginx'ом небезопасную 
логику приложения - это не работает и рано или поздно выстрелит.

Правильное решение - передавать информацию о произошедшей 
авторизации явно и отдельно (или пользоваться параметром 
SERVER_NAME, который уже передаётся и предназначен специально для 
идентификации сервера).

> В данном случаи можно было бы использовать переменную SERVER_NAME, но я выше
> писал почему это не всегда возможно.
> 
> Если мы оба понимаем, что ситуация когда authority component и значения Host
> разные, это исключительная ситуация и её нужно обрабатывать как Exception, в
> этом случаи есть три варианта поведения, выбросить Exception (отдать 400
> статус), исправить ошибку (использовать переменую $host), и самый плохой
> вариант (антишаблон) ничего не делать и не обрабатывать эту исключительную
> ситуацию и оставить все как есть.

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

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


From gmm at csdoc.com  Tue Jun 17 10:31:16 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Tue, 17 Jun 2014 13:31:16 +0300
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <20140617063046.GD1849@mdounin.ru>
References: <2310697.ov1uODaMRR@vbart-laptop> <53982FB4.8090903@csdoc.com>
 <2674454.V4cZd09FeB@vbart-workstation> <53983CB2.9080808@csdoc.com>
 <20140611195331.GD1849@mdounin.ru> <53999FB5.2040108@csdoc.com>
 <20140614181433.GL1849@mdounin.ru> <539DFD1E.3010605@csdoc.com>
 <20140616120053.GS1849@mdounin.ru> <539F51A9.5050302@csdoc.com>
 <20140617063046.GD1849@mdounin.ru>
Message-ID: <53A018F4.9030807@csdoc.com>

On 17.06.2014 9:30, Maxim Dounin wrote:

>>>> http://tools.ietf.org/html/rfc7230#section-5.4
>>>>
>>>>     A client MUST send a Host header field in all HTTP/1.1 request
>>>>     messages.  If the target URI includes an authority component, then a
>>>>     client MUST send a field-value for Host that is identical to that
>>>>     authority component, excluding any userinfo subcomponent and its "@"
>>>>     delimiter (Section 2.7.1).
>>>>
>>>> - это ведь требования к синтаксису, которые обязательны для выполнения.
>>>
>>> Нет, это не требования к синтаксису, это требования к семантике.
>>
>> Запись target URI в виде valid request message - это разве не syntax?
>
> Синтаксис - это то, что нарушает требования приведённых нормативных
> грамматик, см. http://tools.ietf.org/html/rfc7231#section-1.2 и
> далее.

Не все требования к синтаксису выражены в виде нормативных грамматик.
Например, требование отправлять первой строкой запроса request-line
- это тоже требование к синтаксису валидной HTTP request message.
Но это требование не выражено в виде Augmented Backus-Naur Form.

>> "SHOULD NOT" - это не запрет, а только лишь рекомендация:
>> http://tools.ietf.org/html/rfc2119#section-4
>> так что формально и фактически Chrome ничего не нарушает.
>
> Фактически - упомянутый "SHOULD NOT" на тот момент безусловно
> отклонялся Apache'ом,

И это безусловный BUG апача, копировать его в nginx - нет смысла.
Apache ведь не является reference implementation протокола HTTP/1.1

> а противоречащие друг другу Host +
> Request-Line - формально вообще ничего не нарушали

Вообще-то в RFC 2616 написано в точности то же самое что и в RFC 7230:

http://tools.ietf.org/html/rfc2616#section-14.23

    The Host request-header field specifies the Internet host and port
    number of the resource being requested, as obtained from the original
    URI given by the user or referring resource (generally an HTTP URL,
    as described in section 3.2.2). The Host field value MUST represent
    the naming authority of the origin server or gateway given by the
    original URL. This allows the origin server or gateway to
    differentiate between internally-ambiguous URLs, such as the root "/"
    URL of a server for multiple host names on a single IP address.

Здесь точно так же присутствует требование "MUST",
то есть клиент, который не выполнил это требование -
прислал на сервер невалидный запрос и сервер имеет
полное право ответить на такой запрос статусом 400.

> до выхода HTTPbis.

Выход HTTPbis так и не состоялся. Вместо этого - решили
уточнить спецификацию протокола HTTP/1.1 и сконцентировать
свои усилия в работе над протоколом HTTP/2.0 на базе SPDY,
насколько мне известно.

> И что на самом деле происходит в реальной жизни
> - это отдельный интересный вопрос.

В реальной жизни я не встречал софта, который бы создавал запросы

GET http://apple.com/ HTTP/1.1
Host: samsung.com

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

> Среди прочего, например, HTTPbis явно требует возвращать 400,
> если запрос содержит несколько заголовков Host.

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

Единственное что добавилось в RFC 7230 - это более явное требование,
чтобы такой заголовок был всего один. В RFC 2616 это было между строк.

> В своё время, однако, nginx'у потребовалось от этой практики отказаться:
>
> http://hg.nginx.org/nginx/rev/b9de93d804ea
>
> Если мне не изменяет память, причина была всё та же - реальная
> жизнь заставила.

Можно подробнее узнать про причину?

-- 
Best regards,
  Gena


From gmm at csdoc.com  Tue Jun 17 10:35:52 2014
From: gmm at csdoc.com (Gena Makhomed)
Date: Tue, 17 Jun 2014 13:35:52 +0300
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <20140617070031.GE1849@mdounin.ru>
References: <20140616153702.GA1849@mdounin.ru>
 <a713ee6c7b7d5a8540b8df740f1a6f95.NginxMailingListRussian@forum.nginx.org>
 <20140617070031.GE1849@mdounin.ru>
Message-ID: <53A01A08.5090907@csdoc.com>

On 17.06.2014 10:00, Maxim Dounin wrote:

 >> Значения SERVER_NAME не может использоваться,
 >> если в директиве server_name используется маска
 >> или бекенд обрабатывает запросы для default_server.

 > Если SERVER_NAME нельзя использовать - значит, необходимо
 > передать дополнительный параметр, который и использовать.

Именно для этого и существует HTTP_HOST - передать
значение заголовка Host из валидного клиентского запроса.

 > Использовать HTTP_* поля для чего-то, что позволяет
 > "получить доступ" - это неправильно.

Если nginx не будет отправлять на backend невалидные клиентские запросы
- проблем с заголовком HTTP_HOST не будет никаких, - он будет валидным.

 > Проблема в том, что приложение некорректно предполагает, что
 > HTTP_HOST=private.example.com чем-то отличается от других.  Как
 > показывает пример запроса выше - это не так.  И "не так" - не
 > только в nginx'е, но и в других серверах.

А мы никаких других веб-серверов кроме nginx и не используем.
В IIS например, багов еще больше, чем в Apache, и что с того?

 > Не надо себя обманывать и пытаться закрыть nginx'ом небезопасную
 > логику приложения - это не работает и рано или поздно выстрелит.

Приложение было написано в соответствии со стандартами HTTP/1.1
и ожидало, что nginx не пропустит на backend невалидный запрос.

 > Правильное решение - передавать информацию о произошедшей
 > авторизации явно и отдельно (или пользоваться параметром
 > SERVER_NAME, который уже передаётся и предназначен специально для
 > идентификации сервера).

server {
   server_name www.example.com example.com;
   // ...
}

на backend в переменной SERVER_NAME уйдет всегда www.example.com
вне зависимости от того, к какому именно вирт. хосту был запрос.

переменную HTTP_HOST использовать нельзя.
неужели надо всем делать workaround

fastcgi_param  X_REAL_HTTP_HOST  $host;

и потом использовать переменную X_REAL_HTTP_HOST вместо HTTP_HOST ?

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

Что мешает сделать это прямо сейчас?

 > Но это ни коим образом не избавляет
 > от необходимости исправить приложение.

Сейчас - приходится имена виртуальных хостов прописывать
в двух местах - в настройках nginx и в настройках самого
приложения. И дополнительно валидировать HTTP_HOST, проверяя
входит ли это имя в список имен, которые были указаны в директиве
server_name, и были повторно прописаны в настройках приложения.
И если нет - то явно возвращать клиенту статус 400 Bad Request.

Есть стойкое ощущение, что это может и даже должен делать nginx.
Тогда имена хостов надо будет настраивать всего в одном конфиге.

Добавить этот workaround во все backend`ы, которые есть в мире -
это нереально, гораздо проще добавить валидацию запроса в nginx.

-- 
Best regards,
  Gena


From mdounin at mdounin.ru  Tue Jun 17 11:03:18 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 17 Jun 2014 15:03:18 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <53A018F4.9030807@csdoc.com>
References: <2674454.V4cZd09FeB@vbart-workstation> <53983CB2.9080808@csdoc.com>
 <20140611195331.GD1849@mdounin.ru> <53999FB5.2040108@csdoc.com>
 <20140614181433.GL1849@mdounin.ru> <539DFD1E.3010605@csdoc.com>
 <20140616120053.GS1849@mdounin.ru> <539F51A9.5050302@csdoc.com>
 <20140617063046.GD1849@mdounin.ru> <53A018F4.9030807@csdoc.com>
Message-ID: <20140617110318.GH1849@mdounin.ru>

Hello!

On Tue, Jun 17, 2014 at 01:31:16PM +0300, Gena Makhomed wrote:

> On 17.06.2014 9:30, Maxim Dounin wrote:
> 
> >>>>http://tools.ietf.org/html/rfc7230#section-5.4
> >>>>
> >>>>    A client MUST send a Host header field in all HTTP/1.1 request
> >>>>    messages.  If the target URI includes an authority component, then a
> >>>>    client MUST send a field-value for Host that is identical to that
> >>>>    authority component, excluding any userinfo subcomponent and its "@"
> >>>>    delimiter (Section 2.7.1).
> >>>>
> >>>>- это ведь требования к синтаксису, которые обязательны для выполнения.
> >>>
> >>>Нет, это не требования к синтаксису, это требования к семантике.
> >>
> >>Запись target URI в виде valid request message - это разве не syntax?
> >
> >Синтаксис - это то, что нарушает требования приведённых нормативных
> >грамматик, см. http://tools.ietf.org/html/rfc7231#section-1.2 и
> >далее.
> 
> Не все требования к синтаксису выражены в виде нормативных грамматик.
> Например, требование отправлять первой строкой запроса request-line
> - это тоже требование к синтаксису валидной HTTP request message.
> Но это требование не выражено в виде Augmented Backus-Naur Form.

http://tools.ietf.org/html/rfc7230#appendix-B

HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
    ]
status-line = HTTP-version SP status-code SP reason-phrase CRLF

> >>"SHOULD NOT" - это не запрет, а только лишь рекомендация:
> >>http://tools.ietf.org/html/rfc2119#section-4
> >>так что формально и фактически Chrome ничего не нарушает.
> >
> >Фактически - упомянутый "SHOULD NOT" на тот момент безусловно
> >отклонялся Apache'ом,
> 
> И это безусловный BUG апача, копировать его в nginx - нет смысла.
> Apache ведь не является reference implementation протокола HTTP/1.1

Это не баг - как уже говорилось выше, вернуть 400 сервер может в 
любой момент.

Это ровно такое же решение авторов апача, как и предлагаемый 
возврат 400 в случае несовпадения Host и host'а из request line.

> >а противоречащие друг другу Host +
> >Request-Line - формально вообще ничего не нарушали
> 
> Вообще-то в RFC 2616 написано в точности то же самое что и в RFC 7230:
> 
> http://tools.ietf.org/html/rfc2616#section-14.23
> 
>    The Host request-header field specifies the Internet host and port
>    number of the resource being requested, as obtained from the original
>    URI given by the user or referring resource (generally an HTTP URL,
>    as described in section 3.2.2). The Host field value MUST represent
>    the naming authority of the origin server or gateway given by the
>    original URL. This allows the origin server or gateway to
>    differentiate between internally-ambiguous URLs, such as the root "/"
>    URL of a server for multiple host names on a single IP address.
> 
> Здесь точно так же присутствует требование "MUST",
> то есть клиент, который не выполнил это требование -
> прислал на сервер невалидный запрос и сервер имеет
> полное право ответить на такой запрос статусом 400.

Здесь нет каких-либо явных требований о совпадении Host и host'а 
из request-line.

Что касается "имеет полное право", то руководствующийся RFC 2616 
сервер не имеет права ответить на такой запрос 400, так как "MUST 
ignore".  Этот вопрос, мне помнится, Валентин уже прояснял.

> >до выхода HTTPbis.
> 
> Выход HTTPbis так и не состоялся. Вместо этого - решили
> уточнить спецификацию протокола HTTP/1.1 и сконцентировать
> свои усилия в работе над протоколом HTTP/2.0 на базе SPDY,
> насколько мне известно.

HTTPbis - рабочая группа, созданная для уточнения HTTP/1.1.  И 
именно набор RFC 7230 .. 7237 - основной результат её работы, aka 
HTTPbis.

http://trac.tools.ietf.org/wg/httpbis/trac/wiki

> >И что на самом деле происходит в реальной жизни
> >- это отдельный интересный вопрос.
> 
> В реальной жизни я не встречал софта, который бы создавал запросы
> 
> GET http://apple.com/ HTTP/1.1
> Host: samsung.com
> 
> и ожидал бы, что такой запрос будет нормально обработан сервером.

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

> >Среди прочего, например, HTTPbis явно требует возвращать 400,
> >если запрос содержит несколько заголовков Host.
> 
> Нет смысла отправлять несколько одинаковых заголовков
> с одинаковым значением. А разных значений там быть не должно.
> 
> Единственное что добавилось в RFC 7230 - это более явное требование,
> чтобы такой заголовок был всего один. В RFC 2616 это было между строк.

Угу, и именно так поступал nginx до упомянутого коммита.  Только 
не работает.

Из совсем свежих примеров - Opera при работе по SPDY присылает два 
заголовка Content-Length.  Ну и кто они после этого?

> >В своё время, однако, nginx'у потребовалось от этой практики отказаться:
> >
> >http://hg.nginx.org/nginx/rev/b9de93d804ea
> >
> >Если мне не изменяет память, причина была всё та же - реальная
> >жизнь заставила.
> 
> Можно подробнее узнать про причину?

Это вопрос к Игорю, может быть он помнит подробности.  

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


From vbart at nginx.com  Tue Jun 17 11:04:44 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Tue, 17 Jun 2014 15:04:44 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <53A018F4.9030807@csdoc.com>
References: <2310697.ov1uODaMRR@vbart-laptop>
 <20140617063046.GD1849@mdounin.ru> <53A018F4.9030807@csdoc.com>
Message-ID: <7545992.9nyARAd6kX@vbart-workstation>

On Tuesday 17 June 2014 13:31:16 Gena Makhomed wrote:
[..]
> >> "SHOULD NOT" - это не запрет, а только лишь рекомендация:
> >> http://tools.ietf.org/html/rfc2119#section-4
> >> так что формально и фактически Chrome ничего не нарушает.
> >
> > Фактически - упомянутый "SHOULD NOT" на тот момент безусловно
> > отклонялся Apache'ом,
> 
> И это безусловный BUG апача, копировать его в nginx - нет смысла.
> Apache ведь не является reference implementation протокола HTTP/1.1
> 
[..]

Там было и другое:

11.1.  Security Considerations for server_name

   If a single server hosts several domains, then clearly it is
   necessary for the owners of each domain to ensure that this satisfies
   their security needs.  Apart from this, server_name does not appear
   to introduce significant security issues.

   Since it is possible for a client to present a different server_name
   in the application protocol, application server implementations that
   rely upon these names being the same MUST check to make sure the
   client did not present a different name in the application protocol.

http://tools.ietf.org/html/rfc6066#section-11.1

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

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

From vbart at nginx.com  Tue Jun 17 11:14:24 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Tue, 17 Jun 2014 15:14:24 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <20140617110318.GH1849@mdounin.ru>
References: <2674454.V4cZd09FeB@vbart-workstation>
 <53A018F4.9030807@csdoc.com> <20140617110318.GH1849@mdounin.ru>
Message-ID: <2168094.Ec2rQn2W6y@vbart-workstation>

On Tuesday 17 June 2014 15:03:18 Maxim Dounin wrote:
[..]
> > >Среди прочего, например, HTTPbis явно требует возвращать 400,
> > >если запрос содержит несколько заголовков Host.
> > 
> > Нет смысла отправлять несколько одинаковых заголовков
> > с одинаковым значением. А разных значений там быть не должно.
> > 
> > Единственное что добавилось в RFC 7230 - это более явное требование,
> > чтобы такой заголовок был всего один. В RFC 2616 это было между строк.
> 
> Угу, и именно так поступал nginx до упомянутого коммита.  Только 
> не работает.
> 
> Из совсем свежих примеров - Opera при работе по SPDY присылает два 
> заголовка Content-Length.  Ну и кто они после этого?
[..]

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

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

From nginx-forum at nginx.us  Tue Jun 17 12:54:40 2014
From: nginx-forum at nginx.us (den68)
Date: Tue, 17 Jun 2014 08:54:40 -0400
Subject: =?UTF-8?Q?1=2E6_=D0=B8_nginx-push-stream-module?=
Message-ID: <1a385757f74fce5f3872cabc4ad2d5af.NginxMailingListRussian@forum.nginx.org>

При использовании nginx-push-stream-module (+ родной JS FM pushstream.js ) и
nginx 1.6 неожиданно появилась проблема:
крутится спин (загрузка) и 'ожидаю хост ...' и так до таймаута указанного в
параметре push_stream_longpolling_connection_ttl,
в этот промежуток оставшийся JS недогружается до окончания
таймаута...(document.ready).
Такое поведение при загрузке каждой страницы.
Используется схема лонг-пулл.

Логика хостов примерно следующая:
rpl.*.site.ru - push
*.site.ru - web

в JS более чем стандартно, приводить не имеет смысла, в конфиге nginx в
общем-то тоже.
проблема решается только усечением ttl до 1 секунды, но это как-то
неправильно, совсем...
трое суток экспериментов не принесли результата ...

может кто сталкивался?

http {

    push_stream_shared_memory_size                60m;
    push_stream_max_channel_id_length             150;
    push_stream_max_messages_stored_per_channel   100;
    push_stream_timeout_with_body                 off;
.....
    server {
        server_name
            rpl.site.ru;
        access_log off;
        sendfile   off;
        charset utf-8;

        include conf.d/header_set;

        location /pub {
            push_stream_publisher admin;
            push_stream_store_messages             on;
            push_stream_channel_info_on_publish    on;
            push_stream_channels_path              $arg_id;
            client_max_body_size                    256k;
            client_body_buffer_size                 256k;
            allow  127.0.0.1;
        }

        location ~ /sub/(.*) {
            push_stream_subscriber                  long-polling;
            push_stream_channels_path               $1;
            push_stream_last_received_message_tag   $arg_tag;
            push_stream_last_received_message_time  $arg_time;
            push_stream_longpolling_connection_ttl  1s;
            push_stream_message_template           
"{\"id\":~id~,\"channel\":\"~channel~\",\"text\":~text~,\"tag\":\"~tag~\"
итд..
            add_header 'Access-Control-Allow-Origin' $allow_origin;
            add_header 'Access-Control-Allow-Credentials' 'true';
            add_header 'Access-Control-Allow-Methods' 'GET, OPTIONS';
            add_header 'Access-Control-Allow-Headers' $acah;
            add_header 'Access-Control-Expose-Headers' 'ETag';
            add_header 'Last-Modified' '';
            if ($request_method = OPTIONS) { return 204; }
        }

....
}

в JS :

	var pushstream = new PushStream({
		host: rplhost,
		timeout: 20000,
		urlPrefixLongpolling: '/sub',
		modes: "longpolling"
	});
	pushstream.onmessage = rpl_messageReceived;
	pushstream.onstatuschange = rpl_messageStatus;
	pushstream.removeAllChannels();
	pushstream.addChannel('n_...');
	pushstream.addChannel('n_...');
.....
        pushstream.connect();


собственно все ... от чего такие тормоза? не может быть что у всех так
работает (не работает) ..

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


From mdounin at mdounin.ru  Tue Jun 17 13:35:41 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 17 Jun 2014 17:35:41 +0400
Subject: nginx-1.7.2
Message-ID: <20140617133540.GO1849@mdounin.ru>

Изменения в nginx 1.7.2                                           17.06.2014

    *) Добавление: директива hash в блоке upstream.

    *) Добавление: дефрагментация свободных блоков разделяемой памяти.
       Спасибо Wandenberg Peixoto и Yichun Zhang.

    *) Исправление: в рабочем процессе мог произойти segmentation fault,
       если использовалось значение access_log по умолчанию; ошибка
       появилась в 1.7.0.
       Спасибо Piotr Sikora.

    *) Исправление: завершающий слэш ошибочно удалялся из последнего
       параметра директивы try_files.

    *) Исправление: nginx мог не собираться на OS X.

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


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


From anatoly at sonru.com  Tue Jun 17 13:54:12 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Tue, 17 Jun 2014 14:54:12 +0100
Subject: =?UTF-8?B?UmU6IFNQRFkg0LLQvNC10YHRgtC1INGBINCy0LrQu9GO0YfQtdC90L3Ri9C8IHBy?=
 =?UTF-8?B?b3h5X2NhY2hlX2J5cGFzcyAoIzQyOCk=?=
In-Reply-To: <5DE2A9DB-6BA7-45E6-BB3A-C4316AE2DFEF@sonru.com>
References: <482D278A-1A4D-47A9-B936-1E1786D37CCC@sonru.com>
 <2702734.o9QWP8dTeh@vbart-workstation>
 <D5091AAB-380F-4EC9-A60D-AB2CAC0D7CD3@sonru.com>
 <1878949.JPPHYv9qVD@vbart-workstation>
 <B0D6D6AA-35E4-471D-935B-513E0641CDA2@sonru.com>
 <1B285EBC-A43C-4D8A-84A1-CCE7FB1F034F@sonru.com> <5391C1B5.7060403@nginx.com>
 <5DE2A9DB-6BA7-45E6-BB3A-C4316AE2DFEF@sonru.com>
Message-ID: <25619FF2-D441-4CF2-8290-88B68631C30E@sonru.com>


On 06 Jun 2014, at 16:13, Anatoly Mikhailov <anatoly at sonru.com> wrote:

> 
> On 06 Jun 2014, at 14:27, Maxim Konovalov <maxim at nginx.com> wrote:
> 
>> [...]
>>> начал ловить те же баги на не пропатченном Nginx на другом сервере 
>>> с меньшей нагрузкой, этот патч в опен-сорсе очень бы не помешал!
>>> 
>> Код в процессе внутреннего ревью.
> 
> Отличная новость в пятницу, спасибо!

Nginx 1.7.2 содержит именно этот багфикс?

> 
>> 
>> -- 
>> Maxim Konovalov
>> http://nginx.com
>> 
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From maxim at nginx.com  Tue Jun 17 13:57:18 2014
From: maxim at nginx.com (Maxim Konovalov)
Date: Tue, 17 Jun 2014 17:57:18 +0400
Subject: =?UTF-8?B?UmU6IFNQRFkg0LLQvNC10YHRgtC1INGBINCy0LrQu9GO0YfQtdC90L3Ri9C8IHBy?=
 =?UTF-8?B?b3h5X2NhY2hlX2J5cGFzcyAoIzQyOCk=?=
In-Reply-To: <25619FF2-D441-4CF2-8290-88B68631C30E@sonru.com>
References: <482D278A-1A4D-47A9-B936-1E1786D37CCC@sonru.com>
 <2702734.o9QWP8dTeh@vbart-workstation>
 <D5091AAB-380F-4EC9-A60D-AB2CAC0D7CD3@sonru.com>
 <1878949.JPPHYv9qVD@vbart-workstation>
 <B0D6D6AA-35E4-471D-935B-513E0641CDA2@sonru.com>
 <1B285EBC-A43C-4D8A-84A1-CCE7FB1F034F@sonru.com> <5391C1B5.7060403@nginx.com>
 <5DE2A9DB-6BA7-45E6-BB3A-C4316AE2DFEF@sonru.com>
 <25619FF2-D441-4CF2-8290-88B68631C30E@sonru.com>
Message-ID: <53A0493E.5040408@nginx.com>

On 6/17/14 5:54 PM, Anatoly Mikhailov wrote:
> 
> On 06 Jun 2014, at 16:13, Anatoly Mikhailov <anatoly at sonru.com> wrote:
> 
>>
>> On 06 Jun 2014, at 14:27, Maxim Konovalov <maxim at nginx.com> wrote:
>>
>>> [...]
>>>> начал ловить те же баги на не пропатченном Nginx на другом сервере 
>>>> с меньшей нагрузкой, этот патч в опен-сорсе очень бы не помешал!
>>>>
>>> Код в процессе внутреннего ревью.
>>
>> Отличная новость в пятницу, спасибо!
> 
> Nginx 1.7.2 содержит именно этот багфикс?
> 
Не содержит.

-- 
Maxim Konovalov
http://nginx.com


From nginx-forum at nginx.us  Tue Jun 17 14:46:01 2014
From: nginx-forum at nginx.us (S.A.N)
Date: Tue, 17 Jun 2014 10:46:01 -0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <CAFHpkQEY_2LMQ08c9CehgVre-QUSWh7GJ9F=8Ahopdn5kHykow@mail.gmail.com>
References: <CAFHpkQEY_2LMQ08c9CehgVre-QUSWh7GJ9F=8Ahopdn5kHykow@mail.gmail.com>
Message-ID: <dfd8e54a2ff46179ec6a749aa7284a52.NginxMailingListRussian@forum.nginx.org>

Илья Шипицин Wrote:
-------------------------------------------------------
> а расскажите на примерах, как эту "уязвимость" можно эксплуатировать?

Вариантов эксплойтов очень много:

1. SQL иньекции, когда содержимое HTTP_HOST без экранирования используется в
SQL запросах.
2. Хаки в include path, например в некоторых фрейворках имена конфиг файлов
строится из имени хоста и загружаются таким образом
include("configs/$_SERVER[HTTP_HOST].php")
3. Обход конфигураций веб сервера, Nginx будет выполнять директивы хоста
указанного в absolute uri, но на бекенд отправит HTTP_HOST указанный в
заголовке Host
4. И всевозможные обходы логики приложений которая строится на HTTP_HOST,
например система логирования, добавляет запись в таблицу поле host является
связующем для определения на каком сайте юзер выполнил определенное
действия, если вы будите высылать произвольный заголовок Host, нарушится
целостной данных и просмотреть ваши действия на реальном сайте будет не
возможно, потому что ваши действия логировались для сайта (host) которого не
существует или на оборот выполнять действия на одном сайте отправлять
заголовок Host другого сайта, тогда ваши действия будут логироватся для
другого сайта.

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

Пункты 1, 2, 4 полностью на совести разработчиков бекенд-приложений, это их
зона ответственности, но третий пункт (обход конфигураций веб сервера) на
мой взгляд остаётся на совести разработчиков веб-сервера.
Если закрыть эту уязвимость на уровне веб-сервера, сразу закроются все
варианты её эксплойта.

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


From chipitsine at gmail.com  Tue Jun 17 17:01:18 2014
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 17 Jun 2014 23:01:18 +0600
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <dfd8e54a2ff46179ec6a749aa7284a52.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQEY_2LMQ08c9CehgVre-QUSWh7GJ9F=8Ahopdn5kHykow@mail.gmail.com>
 <dfd8e54a2ff46179ec6a749aa7284a52.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQF=g8Hw6ZsaqGjaMo5d9y68ta+jP1mnmH7rP8bSJ0yBZw@mail.gmail.com>

а чем опасен пункт "3)" ?
мне почему-то кажется, что масштаб бедствия в районе нуля, шум из-за ничего.

ну ок, в nginx сработал конфиг для одного значения Host, на бекенд
улетело другое, что в этом случае может произойти страшного ?
в интернет-банке деньги спишутся со счета ?

или это какие-то абстрактные угрозы и именно так к ним и надо относиться ?


17 июня 2014 г., 20:46 пользователь S.A.N <nginx-forum at nginx.us> написал:
> Илья Шипицин Wrote:
> -------------------------------------------------------
>> а расскажите на примерах, как эту "уязвимость" можно эксплуатировать?
>
> Вариантов эксплойтов очень много:
>
> 1. SQL иньекции, когда содержимое HTTP_HOST без экранирования используется в
> SQL запросах.
> 2. Хаки в include path, например в некоторых фрейворках имена конфиг файлов
> строится из имени хоста и загружаются таким образом
> include("configs/$_SERVER[HTTP_HOST].php")
> 3. Обход конфигураций веб сервера, Nginx будет выполнять директивы хоста
> указанного в absolute uri, но на бекенд отправит HTTP_HOST указанный в
> заголовке Host
> 4. И всевозможные обходы логики приложений которая строится на HTTP_HOST,
> например система логирования, добавляет запись в таблицу поле host является
> связующем для определения на каком сайте юзер выполнил определенное
> действия, если вы будите высылать произвольный заголовок Host, нарушится
> целостной данных и просмотреть ваши действия на реальном сайте будет не
> возможно, потому что ваши действия логировались для сайта (host) которого не
> существует или на оборот выполнять действия на одном сайте отправлять
> заголовок Host другого сайта, тогда ваши действия будут логироватся для
> другого сайта.
>
> В реальности список уязвимости ещё больше, он ограничивается только
> фантазией взломщика и дырявостью бекенд-приложений.
>
> Пункты 1, 2, 4 полностью на совести разработчиков бекенд-приложений, это их
> зона ответственности, но третий пункт (обход конфигураций веб сервера) на
> мой взгляд остаётся на совести разработчиков веб-сервера.
> Если закрыть эту уязвимость на уровне веб-сервера, сразу закроются все
> варианты её эксплойта.
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246086,250942#msg-250942
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From vbart at nginx.com  Tue Jun 17 17:28:52 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Tue, 17 Jun 2014 21:28:52 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <dfd8e54a2ff46179ec6a749aa7284a52.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQEY_2LMQ08c9CehgVre-QUSWh7GJ9F=8Ahopdn5kHykow@mail.gmail.com>
 <dfd8e54a2ff46179ec6a749aa7284a52.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1683235.FpS3d37o99@vbart-workstation>

On Tuesday 17 June 2014 10:46:01 S.A.N wrote:
[..]
> 3. Обход конфигураций веб сервера, Nginx будет выполнять директивы хоста
> указанного в absolute uri, но на бекенд отправит HTTP_HOST указанный в
> заголовке Host
[..]

Как уже неоднократно в этой ветке говорилось, nginx в параметрах HTTP_* пишет
ровно то, что от него требуется: заголовки, пришедшие от клиента, в том виде,
в котором они получены.

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

Пытаться проводить тут какую-либо параллель - бессмысленно.  Нет никакого
"обхода" конфигурации.  То, что значение в HTTP_HOST должно каким-то образом
соответствовать выбранному блоку "server" - не более чем чья-то фантазия.

HTTP_* - данные пришедшие от клиента.  И если разработчик приложения не знает 
о том, что входные данные необходимо надлежавшим образом фильтровать, то тут
уже ничем не поможешь.


> 
> Пункты 1, 2, 4 полностью на совести разработчиков бекенд-приложений, это их
> зона ответственности, но третий пункт (обход конфигураций веб сервера) на
> мой взгляд остаётся на совести разработчиков веб-сервера.
> Если закрыть эту уязвимость на уровне веб-сервера, сразу закроются все
> варианты её эксплойта.
> 

Недавно на глаза попался замечательная цитата из интервью с Клинтом Иствудом:

I remember going to a huge waterfall on a glacier in Iceland. People were 
there on a rock-platform overlook to see it. They had their kids. There was a 
place that wasn't sealed off, but it had a cable that stopped anybody from 
going past a certain point. I said to myself, You know, in the States they'd 
have that hurricane-fenced off, because they're afraid somebody's gonna fall 
and some lawyer's going to appear. There, the mentality was like it was in 
America in the old days: If you fall, you're stupid.

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

From nginx-forum at nginx.us  Tue Jun 17 19:31:47 2014
From: nginx-forum at nginx.us (S.A.N)
Date: Tue, 17 Jun 2014 15:31:47 -0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <CAFHpkQF=g8Hw6ZsaqGjaMo5d9y68ta+jP1mnmH7rP8bSJ0yBZw@mail.gmail.com>
References: <CAFHpkQF=g8Hw6ZsaqGjaMo5d9y68ta+jP1mnmH7rP8bSJ0yBZw@mail.gmail.com>
Message-ID: <d76f5bef057b84aa5fde87fb8d68d280.NginxMailingListRussian@forum.nginx.org>

Илья Шипицин Wrote:
-------------------------------------------------------
> а чем опасен пункт "3)" ?
> мне почему-то кажется, что масштаб бедствия в районе нуля, шум из-за
> ничего.
> 
> ну ок, в nginx сработал конфиг для одного значения Host, на бекенд
> улетело другое, что в этом случае может произойти страшного ?
> в интернет-банке деньги спишутся со счета ?
> 
> или это какие-то абстрактные угрозы и именно так к ним и надо
> относиться ?

Угрозы от третьего пункта, зависят от отличий конфигурации хостов, который
исполняет Nginx и который уходит в значении HTTP_HOST на бекенд.
Отличий может быть масса, ограничения по IP, ограничения по кол-ву
одновременных запросов с IP, ограничения по размеру тела запросов и методов
запроса, наличия и отсутствия кеширования, не выполнения директив internal
для location потому что Nginx выполняет директивы другого хоста где нет
таких location и самое забавное это безусловное доверия бекенд-приложения
что юзер прошел аутентификация на уровне веб-сервера потому что эта
аутентификация прописана для хоста который пришел на бекенд в HTTP_HOST.

Но даже если у вас все хосты сконфигурированы одинаково и вы на сервере
используете SERVER_NAME вместо HTTP_HOST, у вас остается риск что где-то в
конфиге используется переменная $http_host вместо $host, расскажу ситуацию
которая возникла у моих знакомых.

Все хосты использовали единый fastcgi_cache_path, ключ для файл кеша
создавался как-то так: fastcgi_cache_key "$http_host$uri$args";
Теперь делаем запрос

GET http://apple.com/ HTTP/1.1
Host: samsung.com

Nginx обрабатывает директивы для хоста apple.com, бекенд правильно
генерирует страницу для apple.com, но в ключ кеша идет значения $http_host
т.е samsung.com и при следующем запросе http://samsung.com/ мы увидим
страницу для apple.com.
Это легко исправляется, в ключ кеша поставить $host вместо $http_host или
для каждого хоста использовать свой собственный fastcgi_cache_path.

Никогда нельзя доверять значению $http_host, но как показывает практика,
программисты бекенд-приложений доверяют HTTP_HOST, пологая что Nginx
безопасный и не пропустит инвалидный запросы. Но вот не задача разработчики
Nginx так же считают что бекенд разработчики умные и всегда пишут безопасный
код обрабатывая инвалидные заголовки Host.
К сожалению это не так.

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


From chipitsine at gmail.com  Tue Jun 17 20:11:07 2014
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 18 Jun 2014 02:11:07 +0600
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <d76f5bef057b84aa5fde87fb8d68d280.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQF=g8Hw6ZsaqGjaMo5d9y68ta+jP1mnmH7rP8bSJ0yBZw@mail.gmail.com>
 <d76f5bef057b84aa5fde87fb8d68d280.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQF58+720AhY8_9+hZ33X_AD3DwccALoO7e_DE76awAR6Q@mail.gmail.com>

пока что все озвученные сценарии для пользователя приведут к
400/404/200, ну то есть "назло маме отморожу уши".
ну ок, пользователь специально сконструировал такой запрос, чтобы он
попал в другой хост. ему там ответили 400 (в моих случаях обычно 404 в
силу особенностей майкрософтовского http.sys)

мне как администратору сервера это чем грозит ?
ну увеличится доля 404-х. посмотрю, удивлюсь, разведу руками. надоест,
отключу access_log.


18 июня 2014 г., 1:31 пользователь S.A.N <nginx-forum at nginx.us> написал:
> Илья Шипицин Wrote:
> -------------------------------------------------------
>> а чем опасен пункт "3)" ?
>> мне почему-то кажется, что масштаб бедствия в районе нуля, шум из-за
>> ничего.
>>
>> ну ок, в nginx сработал конфиг для одного значения Host, на бекенд
>> улетело другое, что в этом случае может произойти страшного ?
>> в интернет-банке деньги спишутся со счета ?
>>
>> или это какие-то абстрактные угрозы и именно так к ним и надо
>> относиться ?
>
> Угрозы от третьего пункта, зависят от отличий конфигурации хостов, который
> исполняет Nginx и который уходит в значении HTTP_HOST на бекенд.
> Отличий может быть масса, ограничения по IP, ограничения по кол-ву
> одновременных запросов с IP, ограничения по размеру тела запросов и методов
> запроса, наличия и отсутствия кеширования, не выполнения директив internal
> для location потому что Nginx выполняет директивы другого хоста где нет
> таких location и самое забавное это безусловное доверия бекенд-приложения
> что юзер прошел аутентификация на уровне веб-сервера потому что эта
> аутентификация прописана для хоста который пришел на бекенд в HTTP_HOST.
>
> Но даже если у вас все хосты сконфигурированы одинаково и вы на сервере
> используете SERVER_NAME вместо HTTP_HOST, у вас остается риск что где-то в
> конфиге используется переменная $http_host вместо $host, расскажу ситуацию
> которая возникла у моих знакомых.
>
> Все хосты использовали единый fastcgi_cache_path, ключ для файл кеша
> создавался как-то так: fastcgi_cache_key "$http_host$uri$args";
> Теперь делаем запрос
>
> GET http://apple.com/ HTTP/1.1
> Host: samsung.com
>
> Nginx обрабатывает директивы для хоста apple.com, бекенд правильно
> генерирует страницу для apple.com, но в ключ кеша идет значения $http_host
> т.е samsung.com и при следующем запросе http://samsung.com/ мы увидим
> страницу для apple.com.
> Это легко исправляется, в ключ кеша поставить $host вместо $http_host или
> для каждого хоста использовать свой собственный fastcgi_cache_path.
>
> Никогда нельзя доверять значению $http_host, но как показывает практика,
> программисты бекенд-приложений доверяют HTTP_HOST, пологая что Nginx
> безопасный и не пропустит инвалидный запросы. Но вот не задача разработчики
> Nginx так же считают что бекенд разработчики умные и всегда пишут безопасный
> код обрабатывая инвалидные заголовки Host.
> К сожалению это не так.
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246086,250956#msg-250956
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Tue Jun 17 20:11:37 2014
From: nginx-forum at nginx.us (S.A.N)
Date: Tue, 17 Jun 2014 16:11:37 -0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <20140617070031.GE1849@mdounin.ru>
References: <20140617070031.GE1849@mdounin.ru>
Message-ID: <594ea31495d3899361df5ae6c8eb44a0.NginxMailingListRussian@forum.nginx.org>

Maxim Dounin Wrote:
-------------------------------------------------------
> Возможно, когда-нибудь мы и придём к тому, что в таких ситуациях 
> будет возвращаться 400.  Но это ни коим образом не избавляет от 
> необходимости исправить приложение.

Приведенный мной пример немного утрирован, но взят из реальной жизни, это
внутренний портал довольно большой компании, на private.example.com работает
PHP сайт который ничего про аунтификацию юзеров не знает, этим занимается
локальный ASP сервер, на который отправляется подзапрос для аунтификации
локального юзера, создания общей сессии или токена который передается в
куках, для подтверждения что юзер прошел аутентификация сделано не было,
всем казалось что такая схема более чем надежна и главное что минимальные
трудозатраты.

Правильно что вы её критикуете, но вить поломалась эта схема благодаря тому
что Nginx не отдал 400 ошибку и выполнил этот заведомо инвалидный запрос.
Целью данного примера, было показать насколько важно для бекенд-приложения
исполнения всех директив Nginx конфига.

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


From chipitsine at gmail.com  Tue Jun 17 20:14:21 2014
From: chipitsine at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 18 Jun 2014 02:14:21 +0600
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <d76f5bef057b84aa5fde87fb8d68d280.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQF=g8Hw6ZsaqGjaMo5d9y68ta+jP1mnmH7rP8bSJ0yBZw@mail.gmail.com>
 <d76f5bef057b84aa5fde87fb8d68d280.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQHTo2x7q2VqfWCuUaKOQtOQuHm7XSJq6jcbdeH+SM1+DA@mail.gmail.com>

расскажу вам тоже одну байку.
читал как-то по Linux.

поставили линукс, настроили ssh, зашли удаленно.
один слушатель сильно занервничал.

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


18 июня 2014 г., 1:31 пользователь S.A.N <nginx-forum at nginx.us> написал:
> Илья Шипицин Wrote:
> -------------------------------------------------------
>> а чем опасен пункт "3)" ?
>> мне почему-то кажется, что масштаб бедствия в районе нуля, шум из-за
>> ничего.
>>
>> ну ок, в nginx сработал конфиг для одного значения Host, на бекенд
>> улетело другое, что в этом случае может произойти страшного ?
>> в интернет-банке деньги спишутся со счета ?
>>
>> или это какие-то абстрактные угрозы и именно так к ним и надо
>> относиться ?
>
> Угрозы от третьего пункта, зависят от отличий конфигурации хостов, который
> исполняет Nginx и который уходит в значении HTTP_HOST на бекенд.
> Отличий может быть масса, ограничения по IP, ограничения по кол-ву
> одновременных запросов с IP, ограничения по размеру тела запросов и методов
> запроса, наличия и отсутствия кеширования, не выполнения директив internal
> для location потому что Nginx выполняет директивы другого хоста где нет
> таких location и самое забавное это безусловное доверия бекенд-приложения
> что юзер прошел аутентификация на уровне веб-сервера потому что эта
> аутентификация прописана для хоста который пришел на бекенд в HTTP_HOST.
>
> Но даже если у вас все хосты сконфигурированы одинаково и вы на сервере
> используете SERVER_NAME вместо HTTP_HOST, у вас остается риск что где-то в
> конфиге используется переменная $http_host вместо $host, расскажу ситуацию
> которая возникла у моих знакомых.
>
> Все хосты использовали единый fastcgi_cache_path, ключ для файл кеша
> создавался как-то так: fastcgi_cache_key "$http_host$uri$args";
> Теперь делаем запрос
>
> GET http://apple.com/ HTTP/1.1
> Host: samsung.com
>
> Nginx обрабатывает директивы для хоста apple.com, бекенд правильно
> генерирует страницу для apple.com, но в ключ кеша идет значения $http_host
> т.е samsung.com и при следующем запросе http://samsung.com/ мы увидим
> страницу для apple.com.
> Это легко исправляется, в ключ кеша поставить $host вместо $http_host или
> для каждого хоста использовать свой собственный fastcgi_cache_path.
>
> Никогда нельзя доверять значению $http_host, но как показывает практика,
> программисты бекенд-приложений доверяют HTTP_HOST, пологая что Nginx
> безопасный и не пропустит инвалидный запросы. Но вот не задача разработчики
> Nginx так же считают что бекенд разработчики умные и всегда пишут безопасный
> код обрабатывая инвалидные заголовки Host.
> К сожалению это не так.
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246086,250956#msg-250956
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Tue Jun 17 20:50:23 2014
From: nginx-forum at nginx.us (S.A.N)
Date: Tue, 17 Jun 2014 16:50:23 -0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <CAFHpkQF58+720AhY8_9+hZ33X_AD3DwccALoO7e_DE76awAR6Q@mail.gmail.com>
References: <CAFHpkQF58+720AhY8_9+hZ33X_AD3DwccALoO7e_DE76awAR6Q@mail.gmail.com>
Message-ID: <b3f12507a096906d1a2422a0dec0f24b.NginxMailingListRussian@forum.nginx.org>

Илья Шипицин Wrote:
-------------------------------------------------------
> пока что все озвученные сценарии для пользователя приведут к
> 400/404/200, ну то есть "назло маме отморожу уши".
> ну ок, пользователь специально сконструировал такой запрос, чтобы он
> попал в другой хост. ему там ответили 400 (в моих случаях обычно 404
> в
> силу особенностей майкрософтовского http.sys)
> 
> мне как администратору сервера это чем грозит ?
> ну увеличится доля 404-х. посмотрю, удивлюсь, разведу руками.
> надоест,
> отключу access_log.
> 

Так это и есть наша цель, чтобы веб-сервер отдавал 400 ошибку на такие
запросы, вместо передачи их на бекенд.
Я так понимаю, что у вас происходит HTTP проксирования и бекендом выступает
другой веб сервер который и отдает 400 ошибку?
Мы здесь обсуждаем проблемы связанные с FastCGI где бекендом выступает
приложения которое в своей внутренней логике использует HTTP_HOST и
подразумевает что Nginx выполнил все директивы для этого хоста.

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


From nginx-forum at nginx.us  Tue Jun 17 22:05:15 2014
From: nginx-forum at nginx.us (S.A.N)
Date: Tue, 17 Jun 2014 18:05:15 -0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <1683235.FpS3d37o99@vbart-workstation>
References: <1683235.FpS3d37o99@vbart-workstation>
Message-ID: <cad485013b15b82d7552a532cd0fdfe0.NginxMailingListRussian@forum.nginx.org>

Валентин Бартенев Wrote:
-------------------------------------------------------
> Как уже неоднократно в этой ветке говорилось, nginx в параметрах
> HTTP_* пишет
> ровно то, что от него требуется: заголовки, пришедшие от клиента, в
> том виде,
> в котором они получены.

Nginx так и должен делать, если запрос валидный, а инвалидные запросы на
бекенд передавать не имеет никакого смысла, они не несут в себе полезной
нагрузки (payload) для бекенда.
По этому, мы разработчики бекенда хотели бы чтобы Nginx не передавал нам
инвалидные запросы, а отдавал 400 статус.

Немного позволю себе лирики, надеюсь никто не обидеться.
Слепое выполнения протокола CGI 1.1 для инвалидных запросов, напоминает
анегдот:
Когда маленькую девочку оставили одну дома и дали указания чужим людям двери
не открывать.
В квартире начался пожар, приехали пожарные стучат в двери, но девочка
утверждает, что двери чужим людям нельзя открывать, потому что были такие
указания )
Самое удивительное что переубедить девочку нельзя, она уверена в своей
правоте, вить указаний открывать двери пожарным не было, то что пожарным
тушить пожар из окна улицы сложней и накладней, по мнению девочки это
проблема пожарных, если они пожарные хреновые специалисты им уже не помочь.
Даже не знаю кто виноват, родители девочки что не дали указания что делать
при пожаре (нет указаний в CGI 1.1 при не соответствии host и absolute uri)
или пожарные не умеют быстро переубеждать.

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

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


From vbart at nginx.com  Wed Jun 18 07:54:59 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 18 Jun 2014 11:54:59 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <cad485013b15b82d7552a532cd0fdfe0.NginxMailingListRussian@forum.nginx.org>
References: <1683235.FpS3d37o99@vbart-workstation>
 <cad485013b15b82d7552a532cd0fdfe0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2596427.Juoj9iXyEH@vbart-workstation>

On Tuesday 17 June 2014 18:05:15 S.A.N wrote:
> Валентин Бартенев Wrote:
> -------------------------------------------------------
> > Как уже неоднократно в этой ветке говорилось, nginx в параметрах
> > HTTP_* пишет
> > ровно то, что от него требуется: заголовки, пришедшие от клиента, в
> > том виде,
> > в котором они получены.
> 
> Nginx так и должен делать, если запрос валидный, а инвалидные запросы на
> бекенд передавать не имеет никакого смысла, они не несут в себе полезной
> нагрузки (payload) для бекенда.
[..]

Вы подменяете понятия.  Пока ещё никто из дискутирующих не смог привести
аргументов за то, что такие запросы не являются валидными.

Попытки ссылаться на требования к клиенту и склонять спецификацию так,
как того хочется - результата точно не принесут.

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

Можете предложить исправить "баг" на ietf.org:

$ netcat ietf.org 80
HEAD http://www.ietf.org/ HTTP/1.1
Host: example.com
Host: example.org

HTTP/1.1 200 OK
Date: Wed, 18 Jun 2014 07:49:22 GMT
Server: Apache
Last-Modified: Thu, 05 Jun 2014 15:47:35 GMT
ETag: "884603a-49c4-4fb18a9ec37a4"
Accept-Ranges: bytes
Content-Length: 18884
Vary: Accept-Encoding
Content-Type: text/html


или на apache.org:

$ netcat apache.org 80
HEAD http://www.apache.org/ HTTP/1.1
Host: example.com
Host: example.org

HTTP/1.1 200 OK
Date: Wed, 18 Jun 2014 07:49:57 GMT
Server: Apache/2.4.9 (Unix) mod_wsgi/3.4 Python/2.7.5 OpenSSL/1.0.1h
Last-Modified: Sun, 15 Jun 2014 09:10:45 GMT
ETag: "a250-4fbdc492d0221"
Accept-Ranges: bytes
Content-Length: 41552
Vary: Accept-Encoding
Cache-Control: max-age=3600
Expires: Wed, 18 Jun 2014 08:49:57 GMT
Content-Type: text/html; charset=utf-8


или на google.com в конце-концов:

$ netcat google.com 80
HEAD http://google.com/ HTTP/1.1
Host: example.com
Host: example.org

HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: http://www.google.ru/?gfe_rd=cr&ei=wkShU4e1GM-A4AS4poHoDg
Content-Length: 258
Date: Wed, 18 Jun 2014 07:50:26 GMT
Server: GFE/2.0
Alternate-Protocol: 80:quic



> По этому, мы разработчики бекенда хотели бы чтобы Nginx не передавал нам
> инвалидные запросы, а отдавал 400 статус.
> 
[..]

Список "инвалидных запросов" в студию.  Завтра придут просить запретить
запрос к /private/, поскольку с точки зрения некоторого бэкенда он не
валиден. 


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

From vbart at nginx.com  Wed Jun 18 08:03:56 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 18 Jun 2014 12:03:56 +0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <cad485013b15b82d7552a532cd0fdfe0.NginxMailingListRussian@forum.nginx.org>
References: <1683235.FpS3d37o99@vbart-workstation>
 <cad485013b15b82d7552a532cd0fdfe0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <21588762.XgaMHY1CSK@vbart-workstation>

On Tuesday 17 June 2014 18:05:15 S.A.N wrote:
[..]
> Немного позволю себе лирики, надеюсь никто не обидеться.
> Слепое выполнения протокола CGI 1.1 для инвалидных запросов, напоминает
> анегдот:
> Когда маленькую девочку оставили одну дома и дали указания чужим людям двери
> не открывать.
> В квартире начался пожар, приехали пожарные стучат в двери, но девочка
> утверждает, что двери чужим людям нельзя открывать, потому что были такие
> указания )
> Самое удивительное что переубедить девочку нельзя, она уверена в своей
> правоте, вить указаний открывать двери пожарным не было, то что пожарным
> тушить пожар из окна улицы сложней и накладней, по мнению девочки это
> проблема пожарных, если они пожарные хреновые специалисты им уже не помочь.

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

Ok.

[..]
> 
> Мораль этой байки такова - при возникновении исключительной ситуации, когда
> нет указаний как поступать в этой ситуации, нужно руководствоватся общим
> правилом поведения в исключительных ситуациях, они гласят - нужно убегать,
> т.е выбрасывать эксепшин, в нашем случаи это выдать 400 статус и завершить
> запрос.
> 

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

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

From igor at sysoev.ru  Wed Jun 18 14:26:00 2014
From: igor at sysoev.ru (Igor Sysoev)
Date: Wed, 18 Jun 2014 23:26:00 +0900
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <20140617110318.GH1849@mdounin.ru>
References: <2674454.V4cZd09FeB@vbart-workstation>
 <53983CB2.9080808@csdoc.com> <20140611195331.GD1849@mdounin.ru>
 <53999FB5.2040108@csdoc.com> <20140614181433.GL1849@mdounin.ru>
 <539DFD1E.3010605@csdoc.com> <20140616120053.GS1849@mdounin.ru>
 <539F51A9.5050302@csdoc.com> <20140617063046.GD1849@mdounin.ru>
 <53A018F4.9030807@csdoc.com> <20140617110318.GH1849@mdounin.ru>
Message-ID: <1E364CF9-2627-47B3-A0DA-7D159F20F3F0@sysoev.ru>

On 17 Jun 2014, at 20:03, Maxim Dounin <mdounin at mdounin.ru> wrote:

>>> В своё время, однако, nginx'у потребовалось от этой практики отказаться:
>>> 
>>> http://hg.nginx.org/nginx/rev/b9de93d804ea
>>> 
>>> Если мне не изменяет память, причина была всё та же - реальная
>>> жизнь заставила.
>> 
>> Можно подробнее узнать про причину?
> 
> Это вопрос к Игорю, может быть он помнит подробности.  

В переписке следов не нашёл, но помню строки из error_log?а с десятками
строк ?Host? в одном запросе, по-моему от MSIE. Видел, скорее всего, в
рамблеровских логах.


--   
Igor Sysoev
http://nginx.com


From nginx-forum at nginx.us  Wed Jun 18 16:15:51 2014
From: nginx-forum at nginx.us (S.A.N)
Date: Wed, 18 Jun 2014 12:15:51 -0400
Subject: =?UTF-8?B?UmU6INCe0LEg0L7QtNC90L7QuSDQvNCw0LvQvtC40LfQstC10YHRgtC90L7QuSA=?=
 =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Lgg0LIg0LLQtdCxINGB0LDQudGC0LDRhQ==?=
In-Reply-To: <2596427.Juoj9iXyEH@vbart-workstation>
References: <2596427.Juoj9iXyEH@vbart-workstation>
Message-ID: <f442b00085010a4854eb119ea42a5d5e.NginxMailingListRussian@forum.nginx.org>

Валентин Бартенев Wrote:
-------------------------------------------------------
> Вы подменяете понятия.  Пока ещё никто из дискутирующих не смог
> привести
> аргументов за то, что такие запросы не являются валидными.

Я никогда не утверждал, что инвалидность этих запросов определяется
стандартом CGI, даже привел метафору про девочку которой не дали указания на
случай пожара.

Причины по которым такие запросы необходимо считать инвалидными очень
прозаичны, легальных HTTP клиентов которые создают такие запросы НЕТ,
сервера которые подвержены данному эксплойту ЕСТЬ, этих серверов не единицы,
обсуждать профессионализм администраторов и разработчиков этих бекендов
можно но это не меняет картину, это просто нужно признать как данность.

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

http://localhost/?var=<script>alert("XSS")</script>

<?php

echo $_GET['var'];

?>

По всем стандартам HTTP, данный запрос корректный (url encode я убрал для
читабельности).
JS код который находится в теле страницы тоже абсолютно корректный с точки
зрения JS, браузер обязан его выполнить, но браузер этот код не выполнит, по
соображениям безопасности и защиты от XSS атак.

К этому разработчики браузеров тоже пришли не сразу, много лет XSS атаки
было легко проводить на подверженных сайтах. 
Разработчики браузеров по праву считали что это проблема тех кто
разрабатывает сайт и это они должны на своей стороне закрыть XSS
уязвимости.
Но годы шли, а XSS уязвимостей находили все больше, они были даже в
инетбанкингах.
Тогда первым кто сделал мудрое решения был Chrome он реализовал защиты от
XSS атак и объявил себя самым безопасным браузером, потом так же сделал IE.

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


> Это с точки зрения вашего конкретного бэкенда запрос не валиден, nginx
> же вполне справляется с его обработкой, как в общем-то и многие другие
> сервера.

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

> Можете предложить исправить "баг" на ietf.org:
> 
> или на apache.org:
> 
> или на google.com в конце-концов:
> 

Chrome и IE тоже не сразу создали защиту от XSS, прошли годы, вопрос кто это
сделает первым Nginx или Apache.

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


From postmaster at softsearch.ru  Wed Jun 18 20:14:41 2014
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Thu, 19 Jun 2014 00:14:41 +0400
Subject: nginx-1.7.2
In-Reply-To: <20140617133540.GO1849@mdounin.ru>
References: <20140617133540.GO1849@mdounin.ru>
Message-ID: <1309504451.20140619001441@softsearch.ru>

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

>     *) Добавление: дефрагментация свободных блоков разделяемой памяти.
>        Спасибо Wandenberg Peixoto и Yichun Zhang.

И есть заметные ускорения от этого?

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


From vbart at nginx.com  Thu Jun 19 05:41:22 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 19 Jun 2014 09:41:22 +0400
Subject: nginx-1.7.2
In-Reply-To: <1309504451.20140619001441@softsearch.ru>
References: <20140617133540.GO1849@mdounin.ru>
 <1309504451.20140619001441@softsearch.ru>
Message-ID: <3114970.eLtipyeuoc@vbart-laptop>

On Thursday 19 June 2014 00:14:41 Михаил Монашёв wrote:
> Здравствуйте, Maxim.
> 
> >     *) Добавление: дефрагментация свободных блоков разделяемой памяти.
> >        Спасибо Wandenberg Peixoto и Yichun Zhang.
> 
> И есть заметные ускорения от этого?
> 

Эта функциональность нужна сторонним модулям.  У самого nginx проблем с 
фрагментацией и не было.

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

From nginx-forum at nginx.us  Sun Jun 22 17:38:39 2014
From: nginx-forum at nginx.us (pnp2000)
Date: Sun, 22 Jun 2014 13:38:39 -0400
Subject: Nginx fastcgi
Message-ID: <3c7976e4fd39f78450a917cab1046400.NginxMailingListRussian@forum.nginx.org>

Можно ли использовать связку Nginx + fastcgi без spawn'а ?

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


From mdounin at mdounin.ru  Sun Jun 22 18:02:17 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sun, 22 Jun 2014 22:02:17 +0400
Subject: Nginx fastcgi
In-Reply-To: <3c7976e4fd39f78450a917cab1046400.NginxMailingListRussian@forum.nginx.org>
References: <3c7976e4fd39f78450a917cab1046400.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140622180217.GT1849@mdounin.ru>

Hello!

On Sun, Jun 22, 2014 at 01:38:39PM -0400, pnp2000 wrote:

> Можно ли использовать связку Nginx + fastcgi без spawn'а ?

Можно - nginx'у всё равно, как именно вы запускаете 
fastcgi-бекенды.

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


From nginx-forum at nginx.us  Sun Jun 22 18:37:04 2014
From: nginx-forum at nginx.us (pnp2000)
Date: Sun, 22 Jun 2014 14:37:04 -0400
Subject: Nginx fastcgi
In-Reply-To: <20140622180217.GT1849@mdounin.ru>
References: <20140622180217.GT1849@mdounin.ru>
Message-ID: <753bc158e9b595c2ff56c21f7525a99c.NginxMailingListRussian@forum.nginx.org>

то есть можно напрямую запускать FCGI программы из под Nginx  миную
Spawn-fcgi ???

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


From mdounin at mdounin.ru  Sun Jun 22 20:20:07 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 23 Jun 2014 00:20:07 +0400
Subject: Nginx fastcgi
In-Reply-To: <753bc158e9b595c2ff56c21f7525a99c.NginxMailingListRussian@forum.nginx.org>
References: <20140622180217.GT1849@mdounin.ru>
 <753bc158e9b595c2ff56c21f7525a99c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140622202007.GU1849@mdounin.ru>

Hello!

On Sun, Jun 22, 2014 at 02:37:04PM -0400, pnp2000 wrote:

> то есть можно напрямую запускать FCGI программы из под Nginx  миную
> Spawn-fcgi ???

Нет.  Ничего "из-под nginx" нельзя - запуском fastcgi-приложений 
nginx не занимается.  Ваша задача - запустить приложение (aka 
fastcgi-бекенд) и сказать nginx'у, как с вашим приложением 
соединиться.

При этом, как уже было сказано в предыдущем ответе, nginx'у 
абсолютно всё равно, как именно вы будете запускать приложение - с 
помощью spawn-fcgi или чего либо ещё.  Заметная часть любителей 
php, например, просто запускают php-fpm или php-cgi в качестве 
отдельного демона.

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


From public-mail at alekciy.ru  Tue Jun 24 14:56:13 2014
From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=)
Date: Tue, 24 Jun 2014 18:56:13 +0400
Subject: nginx-1.7.2
In-Reply-To: <1309504451.20140619001441@softsearch.ru>
References: <20140617133540.GO1849@mdounin.ru>
 <1309504451.20140619001441@softsearch.ru>
Message-ID: <CAPP2NXoe_9d5r3BOGLPvAOJYpAiBkM8SMt1i-kKwshA3EOed6g@mail.gmail.com>

Что-то мне говорит, что это больше приводит к уменьшения расхода ОЗУ, а не
к ускорению. Интересно другое, лочится ли память в процессе дефрагментации.


19 июня 2014 г., 0:14 пользователь Михаил Монашёв <postmaster at softsearch.ru>
написал:

> Здравствуйте, Maxim.
>
> >     *) Добавление: дефрагментация свободных блоков разделяемой памяти.
> >        Спасибо Wandenberg Peixoto и Yichun Zhang.
>
> И есть заметные ускорения от этого?
>
> --
> С уважением,
>  Михаил                          mailto:postmaster at softsearch.ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140624/f9a78a5b/attachment.html>

From mdounin at mdounin.ru  Tue Jun 24 15:12:40 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 24 Jun 2014 19:12:40 +0400
Subject: nginx-1.7.2
In-Reply-To: <CAPP2NXoe_9d5r3BOGLPvAOJYpAiBkM8SMt1i-kKwshA3EOed6g@mail.gmail.com>
References: <20140617133540.GO1849@mdounin.ru>
 <1309504451.20140619001441@softsearch.ru>
 <CAPP2NXoe_9d5r3BOGLPvAOJYpAiBkM8SMt1i-kKwshA3EOed6g@mail.gmail.com>
Message-ID: <20140624151240.GM1849@mdounin.ru>

Hello!

On Tue, Jun 24, 2014 at 06:56:13PM +0400, Алексей Сундуков wrote:

> Что-то мне говорит, что это больше приводит к уменьшения расхода ОЗУ, а не
> к ускорению. Интересно другое, лочится ли память в процессе дефрагментации.

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

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

Самом nginx при использовании стандартных модулей - это 
изменение не затрагивает никак.

Подробнее можно посмотреть тут:

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

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


From m.nasedkin at gmail.com  Thu Jun 26 09:42:35 2014
From: m.nasedkin at gmail.com (Mihail Nasedkin)
Date: Thu, 26 Jun 2014 15:42:35 +0600
Subject: =?UTF-8?B?0L/RgNC+0YHRgtCw0Y8g0YHRgtCw0YLQuNC60LAg0Lgg0YDQtdCz0YPQu9GP0YA=?=
 =?UTF-8?B?0LrQuA==?=
Message-ID: <CALSKcLT0AzQiN91AYuRYwA1eGgMicq3DkebeM-Os-pMYZ=D8Aw@mail.gmail.com>

Доброго всем,

1. Странная регулярка для статики:

location ~ /^(images|css|js|files)/ {
        root /path/to/static; # A request for "/images/foo.ext" will
return the file /path/to/static/images/foo.ext
        access_log off;
        expires 30d;
}
Эта регулярка работает, в т.ч. для запросов типа /images/foo/bar.jpg
Вопрос: почему не работает "вроде более правильная" регулярка
location ~ ^/(images|css|js|files)/ { ... ? (символ начала строки
первый)

2. Далее пытаюсь для подкаталога /images/foo/ сделать отдельный локейшн:
location ~ ^/images/foo/ {
       root /path/to/static;
       access_log off;
       add_header Content-Type image/jpeg;
       expires max;
}
Получаю 403 ошибку, хотя, повторюсь, в первом локейшене все нормально
отдает, т.е. права на файлы точно открыты.

Подскажите, пожалуйста, в чем косяки?


-- 
---
С уважением,
Михаил

From mdounin at mdounin.ru  Thu Jun 26 11:47:55 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 26 Jun 2014 15:47:55 +0400
Subject: =?UTF-8?B?UmU6INC/0YDQvtGB0YLQsNGPINGB0YLQsNGC0LjQutCwINC4INGA0LXQs9GD0Ls=?=
 =?UTF-8?B?0Y/RgNC60Lg=?=
In-Reply-To: <CALSKcLT0AzQiN91AYuRYwA1eGgMicq3DkebeM-Os-pMYZ=D8Aw@mail.gmail.com>
References: <CALSKcLT0AzQiN91AYuRYwA1eGgMicq3DkebeM-Os-pMYZ=D8Aw@mail.gmail.com>
Message-ID: <20140626114755.GL1849@mdounin.ru>

Hello!

On Thu, Jun 26, 2014 at 03:42:35PM +0600, Mihail Nasedkin wrote:

> Доброго всем,
> 
> 1. Странная регулярка для статики:
> 
> location ~ /^(images|css|js|files)/ {
>         root /path/to/static; # A request for "/images/foo.ext" will
> return the file /path/to/static/images/foo.ext
>         access_log off;
>         expires 30d;
> }
> Эта регулярка работает, в т.ч. для запросов типа /images/foo/bar.jpg

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

> Вопрос: почему не работает "вроде более правильная" регулярка
> location ~ ^/(images|css|js|files)/ { ... ? (символ начала строки
> первый)

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

> 2. Далее пытаюсь для подкаталога /images/foo/ сделать отдельный локейшн:
> location ~ ^/images/foo/ {
>        root /path/to/static;
>        access_log off;
>        add_header Content-Type image/jpeg;
>        expires max;
> }
> Получаю 403 ошибку, хотя, повторюсь, в первом локейшене все нормально
> отдает, т.е. права на файлы точно открыты.

В error log'е должно быть написано, почему ошибка.  Подозреваю, 
что вы попытались запросить индекс, в то время как его нет, а 
autoindex - запрещён.

http://nginx.org/r/index
http://nginx.org/r/autoindex

> Подскажите, пожалуйста, в чем косяки?

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

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


From nginx-forum at nginx.us  Thu Jun 26 14:36:15 2014
From: nginx-forum at nginx.us (S.A.N)
Date: Thu, 26 Jun 2014 10:36:15 -0400
Subject: Cache revalidation using If-None-Match
Message-ID: <079e52f9f8fa022f68cbaaeab09fb56b.NginxMailingListRussian@forum.nginx.org>

Сегодня, Максим опубликовал патчи которые реализуют указанный функционал,
это очень хорошая новость.
http://forum.nginx.org/read.php?29,251168

Я так понимаю это финальный код, который войдет в версию Nginx 1.7.3?

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

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


From anatoly at sonru.com  Thu Jun 26 20:26:35 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Thu, 26 Jun 2014 21:26:35 +0100
Subject: Cache revalidation using If-None-Match
In-Reply-To: <079e52f9f8fa022f68cbaaeab09fb56b.NginxMailingListRussian@forum.nginx.org>
References: <079e52f9f8fa022f68cbaaeab09fb56b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CC48CE20-8626-4A6F-9C3B-5DAEB3125D2F@sonru.com>


On 26 Jun 2014, at 15:36, S.A.N <nginx-forum at nginx.us> wrote:

> Сегодня, Максим опубликовал патчи которые реализуют указанный функционал,
> это очень хорошая новость.
> http://forum.nginx.org/read.php?29,251168
> 
> Я так понимаю это финальный код, который войдет в версию Nginx 1.7.3?
> 
> Так же добавлена возможность использовать не строгие ETag, что тоже очень
> хорошо?

Об weak ETag ходили разговоры, мы давно ждали этот функционал!

> 
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,251189,251189#msg-251189
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From nginx-forum at nginx.us  Fri Jun 27 00:47:28 2014
From: nginx-forum at nginx.us (inliquid)
Date: Thu, 26 Jun 2014 20:47:28 -0400
Subject: =?UTF-8?B?0JrQvtC90YTQuNCz0YPRgNCw0YbQuNGPIE5naW54INCx0LXQtyByZXdyaXRl?=
Message-ID: <a245d0f659f2919cab428537e7cb99e3.NginxMailingListRussian@forum.nginx.org>

Добрый день,

пытаюсь переписать конфигурацию под форумный движок esoTalk на nginx, так
чтобы избежать использования rewrite, как рекомендует Игорь Сысоев... но не
получается...
Прошу уважаемое сообщество помочь...

Что имеем: 
1. сайт работает по ссылке example.com/forum, ЧПУ имеют вид
/forum/блабла/тынцтынц/.... иногда добавляются параметры ?token=....  и
т.д.
2. .htaccess из коробки для него имеет следующий вид:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php/$1 [QSA,L]
</IfModule>


3. Добился работающего аналога конфигурации nginx:

        location ~ \.(php) {
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME
$document_root/$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_script_name;
}

        location / {
                        try_files $uri @esotalk;
}

              location ~*
^/forum/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
                      root /var/www/example.com;
              }

        location @esotalk {
             rewrite ^/(.*)$ /forum/index.php/$1 last;
}



Пытаюсь настроить как рекомендовано, без rewrite:


        location / {
                        try_files $uri @esotalk;
}



        location @esotalk {
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME
$document_root/forum/index.php;
                fastcgi_param PATH_INFO /index.php$uri; # --->>>????
}


Вот содержимое fastcgi_params:

stcgi_param   QUERY_STRING            $query_string;
fastcgi_param   REQUEST_METHOD          $request_method;
fastcgi_param   CONTENT_TYPE            $content_type;
fastcgi_param   CONTENT_LENGTH          $content_length;

fastcgi_param   SCRIPT_FILENAME         $request_filename;
fastcgi_param   SCRIPT_NAME             $fastcgi_script_name;
fastcgi_param   REQUEST_URI             $request_uri;
fastcgi_param   DOCUMENT_URI            $document_uri;
fastcgi_param   DOCUMENT_ROOT           $document_root;
fastcgi_param   SERVER_PROTOCOL         $server_protocol;

fastcgi_param   GATEWAY_INTERFACE       CGI/1.1;
fastcgi_param   SERVER_SOFTWARE         nginx/$nginx_version;

fastcgi_param   REMOTE_ADDR             $remote_addr;
fastcgi_param   REMOTE_PORT             $remote_port;
fastcgi_param   SERVER_ADDR             $server_addr;
fastcgi_param   SERVER_PORT             $server_port;
fastcgi_param   SERVER_NAME             $server_name;

fastcgi_param   HTTPS                   $https if_not_empty;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param   REDIRECT_STATUS         200;


В итоге получаю что 

1. Адрес сайта меняется на http://example.com/forum// с '//' на конце
2. В исходном коде страниц появляются некорректные ссылки с этими '//'
3. При открытии страниц вручную по правильному url, например '/forum/admin'
выясняется, что ссылки на контент тоже генерятся не правильные но иного
плана, например '/forum/admin/uploads/avatars/1.jpg' вместо
'/forum/uploads/avatars/1.jpg'


При этом rewrite работает отлично. Помогите, пожалуйста, сделать нормальный
конфиг...

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


From m.nasedkin at gmail.com  Fri Jun 27 02:58:19 2014
From: m.nasedkin at gmail.com (Mihail Nasedkin)
Date: Fri, 27 Jun 2014 08:58:19 +0600
Subject: =?UTF-8?B?UmU6INC/0YDQvtGB0YLQsNGPINGB0YLQsNGC0LjQutCwINC4INGA0LXQs9GD0Ls=?=
 =?UTF-8?B?0Y/RgNC60Lg=?=
In-Reply-To: <20140626114755.GL1849@mdounin.ru>
References: <CALSKcLT0AzQiN91AYuRYwA1eGgMicq3DkebeM-Os-pMYZ=D8Aw@mail.gmail.com>
 <20140626114755.GL1849@mdounin.ru>
Message-ID: <CALSKcLQ76mnx1uxrp_FPF6P5bUts7ehO9u=NFMk_gGR-t+2ykQ@mail.gmail.com>

Спасибо, Максим.

26.06.14, Maxim Dounin<mdounin at mdounin.ru> написал(а):
> Hello!
>
> On Thu, Jun 26, 2014 at 03:42:35PM +0600, Mihail Nasedkin wrote:
>
>> Доброго всем,
>>
>> 1. Странная регулярка для статики:
>>
>> location ~ /^(images|css|js|files)/ {
>>         root /path/to/static; # A request for "/images/foo.ext" will
>> return the file /path/to/static/images/foo.ext
>>         access_log off;
>>         expires 30d;
>> }
>> Эта регулярка работает, в т.ч. для запросов типа /images/foo/bar.jpg
>
> Вам показалось, процитированное регулярное выражение - не
> работает.

Реально работает, я голову сломал.

>
>> Вопрос: почему не работает "вроде более правильная" регулярка
>> location ~ ^/(images|css|js|files)/ { ... ? (символ начала строки
>> первый)
>
> А эта - как раз должна работать.
> Видимо, результаты тестирования - обратны тому, что на самом деле.

Не работает, я голову сломал.

>
>> 2. Далее пытаюсь для подкаталога /images/foo/ сделать отдельный локейшн:
>> location ~ ^/images/foo/ {
>>        root /path/to/static;
>>        access_log off;
>>        add_header Content-Type image/jpeg;
>>        expires max;
>> }
>> Получаю 403 ошибку, хотя, повторюсь, в первом локейшене все нормально
>> отдает, т.е. права на файлы точно открыты.
>
> В error log'е должно быть написано, почему ошибка.  Подозреваю,
> что вы попытались запросить индекс, в то время как его нет, а
> autoindex - запрещён.
>
> http://nginx.org/r/index
> http://nginx.org/r/autoindex
>
>> Подскажите, пожалуйста, в чем косяки?
>
> Основная проблема в том, что вы используете регулярные выражения
> там, где без них можно прекрасно обойтись.  Используйте префиксные
> location'ы - и конфигурация станет куда проще и понятнее.

Хорошо, сделал как надо:

    location /static/ {
        root /path/to/static;
        access_log off;
        expires max;
    }

Но почему возникают проблемы с доступом к файлу open()
"/path/to/static/foo/bar.ext" failed (13: Permission denied)?
Ведь в локации с регулярным выражением этот файл отдает! Права доступа
проверил сотню раз. Я так понимаю, построение автоиндекса каталога не
задействовано, запрошен конкретный файл.

> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


-- 
---
С уважением,
Михаил Наседкин

From sytar.alex at gmail.com  Fri Jun 27 06:10:54 2014
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Fri, 27 Jun 2014 10:10:54 +0400
Subject: =?UTF-8?B?UmU6INC/0YDQvtGB0YLQsNGPINGB0YLQsNGC0LjQutCwINC4INGA0LXQs9GD0Ls=?=
 =?UTF-8?B?0Y/RgNC60Lg=?=
In-Reply-To: <CALSKcLQ76mnx1uxrp_FPF6P5bUts7ehO9u=NFMk_gGR-t+2ykQ@mail.gmail.com>
References: <CALSKcLT0AzQiN91AYuRYwA1eGgMicq3DkebeM-Os-pMYZ=D8Aw@mail.gmail.com>
 <20140626114755.GL1849@mdounin.ru>
 <CALSKcLQ76mnx1uxrp_FPF6P5bUts7ehO9u=NFMk_gGR-t+2ykQ@mail.gmail.com>
Message-ID: <CAKqRTSH+x6PAvm8o+Q6sfeva0jzGJ=v6RK4Ye9UH8pGkq3dWJw@mail.gmail.com>

27 июня 2014 г., 6:58 пользователь Mihail Nasedkin
<m.nasedkin at gmail.com> написал:

> Хорошо, сделал как надо:
>
>     location /static/ {
>         root /path/to/static;
>         access_log off;
>         expires max;
>     }
>
> Но почему возникают проблемы с доступом к файлу open()
> "/path/to/static/foo/bar.ext" failed (13: Permission denied)?
> Ведь в локации с регулярным выражением этот файл отдает! Права доступа
> проверил сотню раз. Я так понимаю, построение автоиндекса каталога не
> задействовано, запрошен конкретный файл.
>

Права на сам файл это уже хорошо, но до файла надо дойти. Вы уверены
что в пути все папки /path/to/static/foo доступны nginx для чтения?

From nginx-forum at nginx.us  Fri Jun 27 06:16:30 2014
From: nginx-forum at nginx.us (zzox4)
Date: Fri, 27 Jun 2014 02:16:30 -0400
Subject: =?UTF-8?B?bmdpbngg0LfQsNGB0YLRi9Cy0LDQtdGCINC+0YIgYWIg0YLQtdGB0YLQsCAobmdp?=
 =?UTF-8?B?bnggZnJlZXplcyB1bmRlciBhYiB0ZXN0KQ==?=
Message-ID: <e983a6ce7348161a894fd92bbc2f5985.NginxMailingListRussian@forum.nginx.org>

$ ab -n 10000 -c 100 http://example.com/test
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking example.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
apr_poll: The timeout specified has expired (70007)
Total of 5605 requests completed

При этом другие сайты на этом сервере перестают работать (after that other
sites don't work)
server {
    listen   80;
    server_name example.com;
    location ~ /test {
        echo "hello world";
    }
}

example.com - локальный хост
$ ping example.com
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.042 ms

iostat/top - показывает что нагрузки нет, сервер простаивает, это нода
digital ocean.

$ nginx -V
nginx version: nginx/1.6.0
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
--prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf
--http-log-path=/var/log/nginx/access.log
--error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock
--pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-proxy-temp-path=/var/lib/nginx/proxy
--http-scgi-temp-path=/var/lib/nginx/scgi
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit
--with-ipv6 --with-http_ssl_module --with-http_stub_status_module
--with-http_realip_module --with-http_auth_request_module
--with-http_addition_module --with-http_dav_module --with-http_geoip_module
--with-http_gzip_static_module --with-http_image_filter_module
--with-http_spdy_module --with-http_sub_module --with-http_xslt_module
--with-mail --with-mail_ssl_module
--add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-auth-pam
--add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-dav-ext-module
--add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-echo
--add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-upstream-fair
--add-module=/build/buildd/nginx-1.6.0/debian/modules/ngx_http_substitutions_filter_module


Это бага nginx или что?

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


From tetsio.nainn at gmail.com  Fri Jun 27 06:34:48 2014
From: tetsio.nainn at gmail.com (=?UTF-8?B?0Jwu0JAuINCc0L7RhdC90LDRh9C10LLRgdC60LjQuQ==?=)
Date: Fri, 27 Jun 2014 16:34:48 +1000
Subject: =?UTF-8?B?UmU6INC/0YDQvtGB0YLQsNGPINGB0YLQsNGC0LjQutCwINC4INGA0LXQs9GD0Ls=?=
 =?UTF-8?B?0Y/RgNC60Lg=?=
In-Reply-To: <CAKqRTSH+x6PAvm8o+Q6sfeva0jzGJ=v6RK4Ye9UH8pGkq3dWJw@mail.gmail.com>
References: <CALSKcLT0AzQiN91AYuRYwA1eGgMicq3DkebeM-Os-pMYZ=D8Aw@mail.gmail.com>
 <20140626114755.GL1849@mdounin.ru>
 <CALSKcLQ76mnx1uxrp_FPF6P5bUts7ehO9u=NFMk_gGR-t+2ykQ@mail.gmail.com>
 <CAKqRTSH+x6PAvm8o+Q6sfeva0jzGJ=v6RK4Ye9UH8pGkq3dWJw@mail.gmail.com>
Message-ID: <CALXqZiHEtfHyjQ6ofjGxcu+bxJL7iwzR3vjUamo7U1ke2yQ=bg@mail.gmail.com>

видимо, сейчас бэкенд отдает статику. а у ngnx нет прав?


27 июня 2014 г., 16:10 пользователь Aleksandr Sytar <sytar.alex at gmail.com>
написал:

> 27 июня 2014 г., 6:58 пользователь Mihail Nasedkin
> <m.nasedkin at gmail.com> написал:
>
> > Хорошо, сделал как надо:
> >
> >     location /static/ {
> >         root /path/to/static;
> >         access_log off;
> >         expires max;
> >     }
> >
> > Но почему возникают проблемы с доступом к файлу open()
> > "/path/to/static/foo/bar.ext" failed (13: Permission denied)?
> > Ведь в локации с регулярным выражением этот файл отдает! Права доступа
> > проверил сотню раз. Я так понимаю, построение автоиндекса каталога не
> > задействовано, запрошен конкретный файл.
> >
>
> Права на сам файл это уже хорошо, но до файла надо дойти. Вы уверены
> что в пути все папки /path/to/static/foo доступны nginx для чтения?
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



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

From m.nasedkin at gmail.com  Fri Jun 27 06:49:42 2014
From: m.nasedkin at gmail.com (Mihail Nasedkin)
Date: Fri, 27 Jun 2014 12:49:42 +0600
Subject: =?UTF-8?B?UmU6INC/0YDQvtGB0YLQsNGPINGB0YLQsNGC0LjQutCwINC4INGA0LXQs9GD0Ls=?=
 =?UTF-8?B?0Y/RgNC60Lg=?=
In-Reply-To: <CAKqRTSH+x6PAvm8o+Q6sfeva0jzGJ=v6RK4Ye9UH8pGkq3dWJw@mail.gmail.com>
References: <CALSKcLT0AzQiN91AYuRYwA1eGgMicq3DkebeM-Os-pMYZ=D8Aw@mail.gmail.com>
 <20140626114755.GL1849@mdounin.ru>
 <CALSKcLQ76mnx1uxrp_FPF6P5bUts7ehO9u=NFMk_gGR-t+2ykQ@mail.gmail.com>
 <CAKqRTSH+x6PAvm8o+Q6sfeva0jzGJ=v6RK4Ye9UH8pGkq3dWJw@mail.gmail.com>
Message-ID: <CALSKcLSgHmOAH58iXUfcQcU8LAss5gZN6_WF77=0oMDHm9weZg@mail.gmail.com>

27.06.14, Aleksandr Sytar<sytar.alex at gmail.com> написал(а):
> 27 июня 2014 г., 6:58 пользователь Mihail Nasedkin
> <m.nasedkin at gmail.com> написал:
>
>> Хорошо, сделал как надо:
>>
>>     location /static/ {
>>         root /path/to/static;
>>         access_log off;
>>         expires max;
>>     }
>>
>> Но почему возникают проблемы с доступом к файлу open()
>> "/path/to/static/foo/bar.ext" failed (13: Permission denied)?
>> Ведь в локации с регулярным выражением этот файл отдает! Права доступа
>> проверил сотню раз. Я так понимаю, построение автоиндекса каталога не
>> задействовано, запрошен конкретный файл.
>>
>
> Права на сам файл это уже хорошо, но до файла надо дойти. Вы уверены
> что в пути все папки /path/to/static/foo доступны nginx для чтения?

Абсолютно, 27 раз перепроверил. Смотрите, "кривая" регулярка (п.1 в
самом начале) точно выдает этот путь-запрос. "Правильная" регулярка
(п.2) так и не работает. Простой строковый локайшн тоже не рубит. Я
голову сломал на пустом месте, никогда вообще не было проблем с этим.

nginx version: nginx/1.4.1

> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


-- 
---
С уважением,
Михаил Наседкин

From vbart at nginx.com  Fri Jun 27 07:15:35 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 27 Jun 2014 11:15:35 +0400
Subject: =?UTF-8?B?UmU6IG5naW54INC30LDRgdGC0YvQstCw0LXRgiDQvtGCIGFiINGC0LXRgdGC0LAg?=
 =?UTF-8?B?KG5naW54IGZyZWV6ZXMgdW5kZXIgYWIgdGVzdCk=?=
In-Reply-To: <e983a6ce7348161a894fd92bbc2f5985.NginxMailingListRussian@forum.nginx.org>
References: <e983a6ce7348161a894fd92bbc2f5985.NginxMailingListRussian@forum.nginx.org>
Message-ID: <18475638.l2eUOTADxp@vbart-laptop>

On Friday 27 June 2014 02:16:30 zzox4 wrote:
> $ ab -n 10000 -c 100 http://example.com/test
[..]
> --add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-auth-pam
> --add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-dav-ext-module
> --add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-echo
> --add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-upstream-fair
> --add-module=/build/buildd/nginx-1.6.0/debian/modules/ngx_http_substitutions_filter_module
[..]

Выкинуть всё это и попробовать ещё раз.

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


From m.nasedkin at gmail.com  Fri Jun 27 07:21:24 2014
From: m.nasedkin at gmail.com (Mihail Nasedkin)
Date: Fri, 27 Jun 2014 13:21:24 +0600
Subject: =?UTF-8?B?UmU6INC/0YDQvtGB0YLQsNGPINGB0YLQsNGC0LjQutCwINC4INGA0LXQs9GD0Ls=?=
 =?UTF-8?B?0Y/RgNC60Lg=?=
In-Reply-To: <CALXqZiHEtfHyjQ6ofjGxcu+bxJL7iwzR3vjUamo7U1ke2yQ=bg@mail.gmail.com>
References: <CALSKcLT0AzQiN91AYuRYwA1eGgMicq3DkebeM-Os-pMYZ=D8Aw@mail.gmail.com>
 <20140626114755.GL1849@mdounin.ru>
 <CALSKcLQ76mnx1uxrp_FPF6P5bUts7ehO9u=NFMk_gGR-t+2ykQ@mail.gmail.com>
 <CAKqRTSH+x6PAvm8o+Q6sfeva0jzGJ=v6RK4Ye9UH8pGkq3dWJw@mail.gmail.com>
 <CALXqZiHEtfHyjQ6ofjGxcu+bxJL7iwzR3vjUamo7U1ke2yQ=bg@mail.gmail.com>
Message-ID: <CALSKcLShqP1SDDrmoQePVh8L9-BU6OTe6im08JO+B0+oBXUNgQ@mail.gmail.com>

27.06.14, М.А. Мохначевский<tetsio.nainn at gmail.com> написал(а):
> видимо, сейчас бэкенд отдает статику. а у ngnx нет прав?

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

>
>
> 27 июня 2014 г., 16:10 пользователь Aleksandr Sytar <sytar.alex at gmail.com>
> написал:
>
>> 27 июня 2014 г., 6:58 пользователь Mihail Nasedkin
>> <m.nasedkin at gmail.com> написал:
>>
>> > Хорошо, сделал как надо:
>> >
>> >     location /static/ {
>> >         root /path/to/static;
>> >         access_log off;
>> >         expires max;
>> >     }
>> >
>> > Но почему возникают проблемы с доступом к файлу open()
>> > "/path/to/static/foo/bar.ext" failed (13: Permission denied)?
>> > Ведь в локации с регулярным выражением этот файл отдает! Права доступа
>> > проверил сотню раз. Я так понимаю, построение автоиндекса каталога не
>> > задействовано, запрошен конкретный файл.
>> >
>>
>> Права на сам файл это уже хорошо, но до файла надо дойти. Вы уверены
>> что в пути все папки /path/to/static/foo доступны nginx для чтения?
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
>
> --
> С ув. М.А. Мохначевский
> Отдел системного администрирования
> ООО "Компания "СахаИнтернет НТ"
> к.т. (4112)219711 доб. 927
>


-- 
---
С уважением,
Михаил Наседкин

From m.nasedkin at gmail.com  Fri Jun 27 08:09:15 2014
From: m.nasedkin at gmail.com (Mihail Nasedkin)
Date: Fri, 27 Jun 2014 14:09:15 +0600
Subject: =?UTF-8?B?UmU6INC/0YDQvtGB0YLQsNGPINGB0YLQsNGC0LjQutCwINC4INGA0LXQs9GD0Ls=?=
 =?UTF-8?B?0Y/RgNC60Lg=?=
In-Reply-To: <CALSKcLShqP1SDDrmoQePVh8L9-BU6OTe6im08JO+B0+oBXUNgQ@mail.gmail.com>
References: <CALSKcLT0AzQiN91AYuRYwA1eGgMicq3DkebeM-Os-pMYZ=D8Aw@mail.gmail.com>
 <20140626114755.GL1849@mdounin.ru>
 <CALSKcLQ76mnx1uxrp_FPF6P5bUts7ehO9u=NFMk_gGR-t+2ykQ@mail.gmail.com>
 <CAKqRTSH+x6PAvm8o+Q6sfeva0jzGJ=v6RK4Ye9UH8pGkq3dWJw@mail.gmail.com>
 <CALXqZiHEtfHyjQ6ofjGxcu+bxJL7iwzR3vjUamo7U1ke2yQ=bg@mail.gmail.com>
 <CALSKcLShqP1SDDrmoQePVh8L9-BU6OTe6im08JO+B0+oBXUNgQ@mail.gmail.com>
Message-ID: <CALSKcLRf4CLknMoAeDTTuQjOUvbBe7ZhmOyGps6r4nkCQPOuuQ@mail.gmail.com>

Большие извинения, да, доступа нет в пути, не понятно, как выдавал бэк.
Всем спасибо.

27.06.14, Mihail Nasedkin<m.nasedkin at gmail.com> написал(а):
> 27.06.14, М.А. Мохначевский<tetsio.nainn at gmail.com> написал(а):
>> видимо, сейчас бэкенд отдает статику. а у ngnx нет прав?
>
> Статику отдает нгинкс по локу с кривой регуляркой, т.е. права есть,
> точно не бэкенд.
> Задумал прописать правильно и еще дописать локайшенов для статики, но
> все уперлось в невидимое, но останавливающее магнитное поле.
>
>>
>>
>> 27 июня 2014 г., 16:10 пользователь Aleksandr Sytar
>> <sytar.alex at gmail.com>
>> написал:
>>
>>> 27 июня 2014 г., 6:58 пользователь Mihail Nasedkin
>>> <m.nasedkin at gmail.com> написал:
>>>
>>> > Хорошо, сделал как надо:
>>> >
>>> >     location /static/ {
>>> >         root /path/to/static;
>>> >         access_log off;
>>> >         expires max;
>>> >     }
>>> >
>>> > Но почему возникают проблемы с доступом к файлу open()
>>> > "/path/to/static/foo/bar.ext" failed (13: Permission denied)?
>>> > Ведь в локации с регулярным выражением этот файл отдает! Права доступа
>>> > проверил сотню раз. Я так понимаю, построение автоиндекса каталога не
>>> > задействовано, запрошен конкретный файл.
>>> >
>>>
>>> Права на сам файл это уже хорошо, но до файла надо дойти. Вы уверены
>>> что в пути все папки /path/to/static/foo доступны nginx для чтения?
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>
>>
>>
>> --
>> С ув. М.А. Мохначевский
>> Отдел системного администрирования
>> ООО "Компания "СахаИнтернет НТ"
>> к.т. (4112)219711 доб. 927
>>
>
>
> --
> ---
> С уважением,
> Михаил Наседкин
>


-- 
---
С уважением,
Михаил Наседкин

From rogat1y at gmail.com  Fri Jun 27 10:52:09 2014
From: rogat1y at gmail.com (Maxim Kozlov)
Date: Fri, 27 Jun 2014 14:52:09 +0400
Subject: =?UTF-8?B?0JTQstCwIHN1Yl9maWx0ZXI=?=
Message-ID: <CAB-_x2OPWPOU=oxEwXoe6x6v1U1fcf4R1z-UYr_z1LuvsDn_Vg@mail.gmail.com>

Всем добра!

Возможно ли как-то применить два sub_filter для одного локейшена?
примерно так:
location ~(.*)/page.html {
        sub_filter .js '.js$is_args$args';
        sub_filter .css '.css$is_args$args';
        sub_filter_once off;
        sub_filter_types application/vnd.apple.mpegurl;
    }

Но на такой конфиг естественно получаю ошибку теста конфига:
"sub_filter" directive is duplicate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140627/19a84b86/attachment.html>

From nginx-forum at nginx.us  Fri Jun 27 11:56:17 2014
From: nginx-forum at nginx.us (EmpireX)
Date: Fri, 27 Jun 2014 07:56:17 -0400
Subject: =?UTF-8?B?0L3QtdC60L7RgNGA0LXQutGC0L3QvtC1INC+0YLQvtCx0YDQsNC20LXQvdC40LUg?=
 =?UTF-8?B?0YHQsNC50YLQsCDQv9GA0Lgg0L/QtdGA0LXQstC+0LTQtSDRgSBodHRwINC9?=
 =?UTF-8?B?0LAgaHR0cHM=?=
Message-ID: <d70c3e6cc96600d71fc001fda1ec289e.NginxMailingListRussian@forum.nginx.org>

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

некорректное отображение сайта при переводе с http на https

server {

                listen *:80;
                server_name wiki.off-it.ru;
                server_name_in_redirect off;
                proxy_set_header Host wiki.off-it.ru;
  location / {
    rewrite ^(.*)$ https://wiki.off-it.ru$1 permanent;

                 }
}


 server {

                listen *:443;
                server_name wiki.off-it.ru;
                ssl on;
                ssl_certificate  /etc/ssl/private/wiki.off-it.ru.pem;
                ssl_certificate_key /etc/ssl/private/wiki.off-it.ru.key;
                proxy_set_header Host wiki.off-it.ru;
                server_name_in_redirect off;
                access_log  /var/log/nginx/wiki1.access.log  main;
                location / {
                 proxy_pass         http://127.0.0.1:8080/;
                 proxy_redirect     off;
                 proxy_set_header   Host             $host;
                 proxy_set_header   X-Real-IP        $remote_addr;
                 proxy_set_header   X-Forwarded-For 
$proxy_add_x_forwarded_for;
                 client_max_body_size       10m;
                 client_body_buffer_size    128k;
                 proxy_connect_timeout      90;
                 proxy_send_timeout         90;
                 proxy_read_timeout         90;
                 proxy_buffer_size          4k;
                 proxy_buffers              4 32k;
                 proxy_busy_buffers_size    64k;
                 proxy_temp_file_write_size 10m;
                 }

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


From nginx-forum at nginx.us  Fri Jun 27 12:33:14 2014
From: nginx-forum at nginx.us (Dimka)
Date: Fri, 27 Jun 2014 08:33:14 -0400
Subject: =?UTF-8?B?bW9kcmV3cml0ZSDQuCDQt9Cw0LrQvtC00LjRgNC+0LLQsNC90L3Ri9C1INCx0YM=?=
 =?UTF-8?B?0LrQstGLIGVuY29kZVVSSUNvbXBvbmVudA==?=
Message-ID: <31c860d22ecc778991b770d29f5c8771.NginxMailingListRussian@forum.nginx.org>

Всем привет

Проблема похоже старая, но решения так и не нагуглил.

На сервере хранятся файлы пользователей.
Имена файлов могут быть на разных языках.

Для примера попытка скачать файл "fire fox" с пробелом приводит вот к какой
ошибке.

Лог с ошибкой

2014/06/27 16:27:07 [error] 13852#0: *339 open()
"/tmp/d3a6e42aeb1627b39a22cf7835a36dea/fire%20fox" failed (2: No such file
or directory), client: 80.75.131.7, server: u.com, request: "GET
/attachment/d3a6e42aeb1627b39a22cf7835a36dea/fire%20fox HTTP/1.1", host:
"u.com"

Конфигурация

       # URL - /attachment/d3a6e42aeb1627b39a22cf7835a36dea/fire fox
        location ~ /attachment/(................................)/(.+) {
            set $sub1 $1;
            set $sub2 $2;

            root                /tmp/$sub1;
            rewrite     ^       /$sub2 break;
        }

Как - то можно побороть?

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


From nginx-forum at nginx.us  Fri Jun 27 12:47:57 2014
From: nginx-forum at nginx.us (Dimka)
Date: Fri, 27 Jun 2014 08:47:57 -0400
Subject: =?UTF-8?B?UmU6IG1vZHJld3JpdGUg0Lgg0LfQsNC60L7QtNC40YDQvtCy0LDQvdC90YvQtSA=?=
 =?UTF-8?B?0LHRg9C60LLRiyBlbmNvZGVVUklDb21wb25lbnQ=?=
In-Reply-To: <31c860d22ecc778991b770d29f5c8771.NginxMailingListRussian@forum.nginx.org>
References: <31c860d22ecc778991b770d29f5c8771.NginxMailingListRussian@forum.nginx.org>
Message-ID: <a319bc9f10999fa5e8a928d5f9f818f8.NginxMailingListRussian@forum.nginx.org>

Всё, сорри за беспокойство - сам разабрался.

Избавился от реврайта :)

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


From anatoly at sonru.com  Fri Jun 27 12:48:31 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Fri, 27 Jun 2014 13:48:31 +0100
Subject: =?UTF-8?B?0LDRg9C00LjRgiDQtNC10LnRgdGC0LLQuNC5INC/0L7Qu9GM0LfQvtCy0LDRgtC1?=
 =?UTF-8?B?0LvRjw==?=
Message-ID: <D01EB58D-AE0A-47B7-B1E8-DDB7BBC9CF01@sonru.com>

Стоит следующая задача: есть несколько приложений, построенных не некотором количестве сервисов,
необходимо логировать каждое действие пользователя. В настоящее время все сделано на уровне
приложений, но есть идея использовать ngx_http_auth_request_module для этих целей, который будет 
отправлять JSON на новый отдельный внутренний сервис аудита и выполняться перед каждый запросом.
Цель - вынести все, что не связано с бизнес-логикой, из приложений насколько это возможно.

Такой use-case уже кем то используюется, что посоветуете?


Анатолий


From nginx-forum at nginx.us  Fri Jun 27 12:54:50 2014
From: nginx-forum at nginx.us (EmpireX)
Date: Fri, 27 Jun 2014 08:54:50 -0400
Subject: =?UTF-8?B?UmU6INC90LXQutC+0YDRgNC10LrRgtC90L7QtSDQvtGC0L7QsdGA0LDQttC10L0=?=
 =?UTF-8?B?0LjQtSDRgdCw0LnRgtCwINC/0YDQuCDQv9C10YDQtdCy0L7QtNC1INGBIGh0?=
 =?UTF-8?B?dHAg0L3QsCBodHRwcw==?=
In-Reply-To: <d70c3e6cc96600d71fc001fda1ec289e.NginxMailingListRussian@forum.nginx.org>
References: <d70c3e6cc96600d71fc001fda1ec289e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <ec99abcf99a173d4019f83352e1399d7.NginxMailingListRussian@forum.nginx.org>

решение найдено

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


From mdounin at mdounin.ru  Fri Jun 27 14:03:56 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 27 Jun 2014 18:03:56 +0400
Subject: =?UTF-8?B?UmU6INC/0YDQvtGB0YLQsNGPINGB0YLQsNGC0LjQutCwINC4INGA0LXQs9GD0Ls=?=
 =?UTF-8?B?0Y/RgNC60Lg=?=
In-Reply-To: <CALSKcLQ76mnx1uxrp_FPF6P5bUts7ehO9u=NFMk_gGR-t+2ykQ@mail.gmail.com>
References: <CALSKcLT0AzQiN91AYuRYwA1eGgMicq3DkebeM-Os-pMYZ=D8Aw@mail.gmail.com>
 <20140626114755.GL1849@mdounin.ru>
 <CALSKcLQ76mnx1uxrp_FPF6P5bUts7ehO9u=NFMk_gGR-t+2ykQ@mail.gmail.com>
Message-ID: <20140627140355.GS1849@mdounin.ru>

Hello!

On Fri, Jun 27, 2014 at 08:58:19AM +0600, Mihail Nasedkin wrote:

> Спасибо, Максим.
> 
> 26.06.14, Maxim Dounin<mdounin at mdounin.ru> написал(а):
> > Hello!
> >
> > On Thu, Jun 26, 2014 at 03:42:35PM +0600, Mihail Nasedkin wrote:
> >
> >> Доброго всем,
> >>
> >> 1. Странная регулярка для статики:
> >>
> >> location ~ /^(images|css|js|files)/ {
> >>         root /path/to/static; # A request for "/images/foo.ext" will
> >> return the file /path/to/static/images/foo.ext
> >>         access_log off;
> >>         expires 30d;
> >> }
> >> Эта регулярка работает, в т.ч. для запросов типа /images/foo/bar.jpg
> >
> > Вам показалось, процитированное регулярное выражение - не
> > работает.
> 
> Реально работает, я голову сломал.

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

Вынесите соответствующее регулярное выражение в отдельный блок 
server, в конфиг вида:

    server {
        server_name foo;

        location / {
            return 200 "this is location /\n";
        }

        location ~ /^(images|css|js|files)/ {
            return 200 "this is location /^(images|css|js|files)/\n";
        }
    }

И убедитесь, что оно не работает:

$ fetch -qo - http://localhost:8080/images/foo.jpg
this is location /

Что конкретно происходит в вашем конфиге, и почему вам кажется, 
что оно работает - "по хвосту" сказать нельзя.  Нужно смотреть на 
весь блок server{} как минимум.

[...]

> Хорошо, сделал как надо:
> 
>     location /static/ {
>         root /path/to/static;
>         access_log off;
>         expires max;
>     }
> 
> Но почему возникают проблемы с доступом к файлу open()
> "/path/to/static/foo/bar.ext" failed (13: Permission denied)?
> Ведь в локации с регулярным выражением этот файл отдает! Права доступа
> проверил сотню раз. Я так понимаю, построение автоиндекса каталога не
> задействовано, запрошен конкретный файл.

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

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


From mdounin at mdounin.ru  Fri Jun 27 14:24:26 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 27 Jun 2014 18:24:26 +0400
Subject: =?UTF-8?B?UmU6INCU0LLQsCBzdWJfZmlsdGVy?=
In-Reply-To: <CAB-_x2OPWPOU=oxEwXoe6x6v1U1fcf4R1z-UYr_z1LuvsDn_Vg@mail.gmail.com>
References: <CAB-_x2OPWPOU=oxEwXoe6x6v1U1fcf4R1z-UYr_z1LuvsDn_Vg@mail.gmail.com>
Message-ID: <20140627142426.GU1849@mdounin.ru>

Hello!

On Fri, Jun 27, 2014 at 02:52:09PM +0400, Maxim Kozlov wrote:

> Всем добра!
> 
> Возможно ли как-то применить два sub_filter для одного локейшена?
> примерно так:
> location ~(.*)/page.html {
>         sub_filter .js '.js$is_args$args';
>         sub_filter .css '.css$is_args$args';
>         sub_filter_once off;
>         sub_filter_types application/vnd.apple.mpegurl;
>     }
> 
> Но на такой конфиг естественно получаю ошибку теста конфига:
> "sub_filter" directive is duplicate

Сейчас sub_filter не умеет искать и заменять несколько строк 
одновременно.  Простой workaround - сделать дополнительное 
проксирование, и там заменять ещё раз.

Можно ещё попробовать поискать 3rd party модули (вроде бы subs 
умел), но там бывают сюрпризы с качеством модулей.  Так что этот 
вариант я не то, чтобы рекомендую.

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


From semenukha at gmail.com  Fri Jun 27 15:14:01 2014
From: semenukha at gmail.com (Styopa Semenukha)
Date: Fri, 27 Jun 2014 11:14:01 -0400
Subject: =?UTF-8?B?UmU6IFJlOiDQvdC10LrQvtGA0YDQtdC60YLQvdC+0LUg0L7RgtC+0LHRgNCw0LY=?=
 =?UTF-8?B?0LXQvdC40LUg0YHQsNC50YLQsCDQv9GA0Lgg0L/QtdGA0LXQstC+0LTQtSA=?=
 =?UTF-8?B?0YEgaHR0cCDQvdCwIGh0dHBz?=
In-Reply-To: <ec99abcf99a173d4019f83352e1399d7.NginxMailingListRussian@forum.nginx.org>
References: <d70c3e6cc96600d71fc001fda1ec289e.NginxMailingListRussian@forum.nginx.org>
 <ec99abcf99a173d4019f83352e1399d7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <15431620.FEsXkXuQKT@tornado>

?но никому не сказано.

On Friday, June 27, 2014 08:54:50 AM EmpireX wrote:
> решение найдено
> 
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,251222,251226#msg-251226
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-- 
Best regards,
Styopa Semenukha.

From tetsio.nainn at gmail.com  Fri Jun 27 18:17:06 2014
From: tetsio.nainn at gmail.com (=?UTF-8?B?0Jwu0JAuINCc0L7RhdC90LDRh9C10LLRgdC60LjQuQ==?=)
Date: Sat, 28 Jun 2014 04:17:06 +1000
Subject: =?UTF-8?B?UmU6INCw0YPQtNC40YIg0LTQtdC50YHRgtCy0LjQuSDQv9C+0LvRjNC30L7QstCw?=
 =?UTF-8?B?0YLQtdC70Y8=?=
In-Reply-To: <D01EB58D-AE0A-47B7-B1E8-DDB7BBC9CF01@sonru.com>
References: <D01EB58D-AE0A-47B7-B1E8-DDB7BBC9CF01@sonru.com>
Message-ID: <CALXqZiFM_-3pBUxM_NZNR3T4ZvHQT6mJWY_iN_ecxkA41xjFEw@mail.gmail.com>

А анализ логов не дает необходимых результатов?


27 июня 2014 г., 22:48 пользователь Anatoly Mikhailov <anatoly at sonru.com>
написал:

> Стоит следующая задача: есть несколько приложений, построенных не
> некотором количестве сервисов,
> необходимо логировать каждое действие пользователя. В настоящее время все
> сделано на уровне
> приложений, но есть идея использовать ngx_http_auth_request_module для
> этих целей, который будет
> отправлять JSON на новый отдельный внутренний сервис аудита и выполняться
> перед каждый запросом.
> Цель - вынести все, что не связано с бизнес-логикой, из приложений
> насколько это возможно.
>
> Такой use-case уже кем то используюется, что посоветуете?
>
>
> Анатолий
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




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

From tetsio.nainn at gmail.com  Fri Jun 27 18:18:15 2014
From: tetsio.nainn at gmail.com (=?UTF-8?B?0Jwu0JAuINCc0L7RhdC90LDRh9C10LLRgdC60LjQuQ==?=)
Date: Sat, 28 Jun 2014 04:18:15 +1000
Subject: =?UTF-8?B?UmU6INCw0YPQtNC40YIg0LTQtdC50YHRgtCy0LjQuSDQv9C+0LvRjNC30L7QstCw?=
 =?UTF-8?B?0YLQtdC70Y8=?=
In-Reply-To: <CALXqZiFM_-3pBUxM_NZNR3T4ZvHQT6mJWY_iN_ecxkA41xjFEw@mail.gmail.com>
References: <D01EB58D-AE0A-47B7-B1E8-DDB7BBC9CF01@sonru.com>
 <CALXqZiFM_-3pBUxM_NZNR3T4ZvHQT6mJWY_iN_ecxkA41xjFEw@mail.gmail.com>
Message-ID: <CALXqZiHhkye4-ZwTKZL7NY+q5sy8YFKTGw2ufk9-AAzuLMJqwg@mail.gmail.com>

имелось ввиду access_log с log_format


28 июня 2014 г., 4:17 пользователь М.А. Мохначевский <tetsio.nainn at gmail.com
> написал:

> А анализ логов не дает необходимых результатов?
>
>
> 27 июня 2014 г., 22:48 пользователь Anatoly Mikhailov <anatoly at sonru.com>
> написал:
>
> Стоит следующая задача: есть несколько приложений, построенных не
>> некотором количестве сервисов,
>> необходимо логировать каждое действие пользователя. В настоящее время все
>> сделано на уровне
>> приложений, но есть идея использовать ngx_http_auth_request_module для
>> этих целей, который будет
>> отправлять JSON на новый отдельный внутренний сервис аудита и выполняться
>> перед каждый запросом.
>> Цель - вынести все, что не связано с бизнес-логикой, из приложений
>> насколько это возможно.
>>
>> Такой use-case уже кем то используюется, что посоветуете?
>>
>>
>> Анатолий
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> --
> С ув. М.А. Мохначевский
> Отдел системного администрирования
> ООО "Компания "СахаИнтернет НТ"
> к.т. (4112)219711 доб. 927
>



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

From nginx-forum at nginx.us  Sat Jun 28 02:48:55 2014
From: nginx-forum at nginx.us (SkaN2412)
Date: Fri, 27 Jun 2014 22:48:55 -0400
Subject: =?UTF-8?B?bmdpbngg0LjQu9C4IHBocCDQvtCx0YDQtdC30LDQtdGCINGH0LDRgdGC0Ywg0L4=?=
 =?UTF-8?B?0YLQstC10YLQsCDQsiDQu9C+0LPQsNGFINC+0YjQuNCx0L7Qug==?=
Message-ID: <cfb0affb8b1b156ac56eb5cb3a36bd81.NginxMailingListRussian@forum.nginx.org>

Пытаюсь дебажить Wordpress, при котором ошибки PHP пишутся в лог nginx. Было
все хорошо, до какого-то момента (честно, я его даже не уловил), после
которого все ответы обрывались, как-то так:

PHP message: PHP Notice:  Undefined offset: 1 in
/home/andrey/Документы/Работа/Sources/1cloudroad/wp-content/plugins/feedwordpress/syndicatedlink.class.php
on line 568
PHP message: PHP Stack trace:
PHP message: PHP   1. {main}()
/home/andrey/Документы/Работа/Sources/1cloudroad/index.php:0
PHP message: PHP   2. require()
/home/andrey/Документы/Работа/Sources/1cloudroad/index.php:17
PHP message: PHP   3. require_once()
/home/andrey/Документы/Работа/Sources/1cloudroad/wp-blog-header.php:12
PHP message: PHP   4. require_once()
/home/andrey/Документы/Работа/Sources/1cloudroad/wp-load.php:29
PHP message: PHP   5. require_once()
/home/andrey/Документы/Работа/Sources/1cloudroad/wp-config.php:115
PHP message: PHP   6. shutdown_action_hook()
/home/andrey/Документы/Работа/Sources/1cloudroad/wp-includes/load.php:0
PHP message: PHP   7. do_action()
/home/andrey/Документы/Работа/Sources/1cloudroad/wp-includes/load.php:573
PHP message: PHP   8. call_user_func_array()
/home/andrey/Документы/Работа/Sources/1cloudroad/wp-includes/plugin.php:470
PHP message: PHP   9. FeedWordPress->auto_update()
/home/andrey/Документы/Работа/Sources/1cloudroad/wp-includes/plugin.php:470
PHP message: PHP  10. FeedWordPress->update()
/home/andrey/Документы/Работа/Sources/1cloudroad/wp-content/plugins/feedwordpress/feedwordpress.php:1584
PHP message: PHP  11

а бывает что и на полслове просто обрыв и все. До Fatal error, на которой
все останавливается, уже не доходит. Что такое может быть, кто-нибудь
сталкивался?

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


From mdounin at mdounin.ru  Sat Jun 28 03:08:56 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sat, 28 Jun 2014 07:08:56 +0400
Subject: =?UTF-8?B?UmU6IG5naW54INC40LvQuCBwaHAg0L7QsdGA0LXQt9Cw0LXRgiDRh9Cw0YHRgtGM?=
 =?UTF-8?B?INC+0YLQstC10YLQsCDQsiDQu9C+0LPQsNGFINC+0YjQuNCx0L7Qug==?=
In-Reply-To: <cfb0affb8b1b156ac56eb5cb3a36bd81.NginxMailingListRussian@forum.nginx.org>
References: <cfb0affb8b1b156ac56eb5cb3a36bd81.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140628030856.GE1849@mdounin.ru>

Hello!

On Fri, Jun 27, 2014 at 10:48:55PM -0400, SkaN2412 wrote:

> Пытаюсь дебажить Wordpress, при котором ошибки PHP пишутся в лог nginx. Было
> все хорошо, до какого-то момента (честно, я его даже не уловил), после
> которого все ответы обрывались, как-то так:
> 
> PHP message: PHP Notice:  Undefined offset: 1 in
> /home/andrey/Документы/Работа/Sources/1cloudroad/wp-content/plugins/feedwordpress/syndicatedlink.class.php
> on line 568
> PHP message: PHP Stack trace:
> PHP message: PHP   1. {main}()
> /home/andrey/Документы/Работа/Sources/1cloudroad/index.php:0
> PHP message: PHP   2. require()
> /home/andrey/Документы/Работа/Sources/1cloudroad/index.php:17
> PHP message: PHP   3. require_once()
> /home/andrey/Документы/Работа/Sources/1cloudroad/wp-blog-header.php:12
> PHP message: PHP   4. require_once()
> /home/andrey/Документы/Работа/Sources/1cloudroad/wp-load.php:29
> PHP message: PHP   5. require_once()
> /home/andrey/Документы/Работа/Sources/1cloudroad/wp-config.php:115
> PHP message: PHP   6. shutdown_action_hook()
> /home/andrey/Документы/Работа/Sources/1cloudroad/wp-includes/load.php:0
> PHP message: PHP   7. do_action()
> /home/andrey/Документы/Работа/Sources/1cloudroad/wp-includes/load.php:573
> PHP message: PHP   8. call_user_func_array()
> /home/andrey/Документы/Работа/Sources/1cloudroad/wp-includes/plugin.php:470
> PHP message: PHP   9. FeedWordPress->auto_update()
> /home/andrey/Документы/Работа/Sources/1cloudroad/wp-includes/plugin.php:470
> PHP message: PHP  10. FeedWordPress->update()
> /home/andrey/Документы/Работа/Sources/1cloudroad/wp-content/plugins/feedwordpress/feedwordpress.php:1584
> PHP message: PHP  11
> 
> а бывает что и на полслове просто обрыв и все. До Fatal error, на которой
> все останавливается, уже не доходит. Что такое может быть, кто-нибудь
> сталкивался?

Ограничение на размер сообщения в error log'е - 2 килобайта.  

У вас, судя по всему, включено расширение xdebug, которое 
добавляет к сообщениям полный stack trace, и в 2 килобайта 
сообщение не помещается.

Решение - сделать сообщения короче, чтобы помещались (например, 
укоротить путь, или вообще выключить stack trace, если он не 
нужен), либо пересобрать nginx, увеличив константу 
NGX_MAX_ERROR_STR.

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


From nginx-forum at nginx.us  Sat Jun 28 03:42:45 2014
From: nginx-forum at nginx.us (SkaN2412)
Date: Fri, 27 Jun 2014 23:42:45 -0400
Subject: =?UTF-8?B?UmU6IG5naW54INC40LvQuCBwaHAg0L7QsdGA0LXQt9Cw0LXRgiDRh9Cw0YHRgtGM?=
 =?UTF-8?B?INC+0YLQstC10YLQsCDQsiDQu9C+0LPQsNGFINC+0YjQuNCx0L7Qug==?=
In-Reply-To: <20140628030856.GE1849@mdounin.ru>
References: <20140628030856.GE1849@mdounin.ru>
Message-ID: <ee6022c937bfe4a199dfce3f811225c8.NginxMailingListRussian@forum.nginx.org>

Ну, stack trace нужен, потому что я отлаживаю то, что параллельно изучаю. А
вообще, все было хорошо, до определенного момента, как-то что-то случилось и
все стало плохо. А можно ли как-то изменить этот параметр без пересборки?
Потому что я установил nginx из репозитория и руками ничего не собирал.

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


From anatoly at sonru.com  Sat Jun 28 07:30:03 2014
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Sat, 28 Jun 2014 08:30:03 +0100
Subject: =?UTF-8?B?UmU6INCw0YPQtNC40YIg0LTQtdC50YHRgtCy0LjQuSDQv9C+0LvRjNC30L7QstCw?=
 =?UTF-8?B?0YLQtdC70Y8=?=
In-Reply-To: <CALXqZiHhkye4-ZwTKZL7NY+q5sy8YFKTGw2ufk9-AAzuLMJqwg@mail.gmail.com>
References: <D01EB58D-AE0A-47B7-B1E8-DDB7BBC9CF01@sonru.com>
 <CALXqZiFM_-3pBUxM_NZNR3T4ZvHQT6mJWY_iN_ecxkA41xjFEw@mail.gmail.com>
 <CALXqZiHhkye4-ZwTKZL7NY+q5sy8YFKTGw2ufk9-AAzuLMJqwg@mail.gmail.com>
Message-ID: <57069084-B388-4159-8D11-EC31655210EC@sonru.com>

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

On 27 Jun 2014, at 19:18, М.А. Мохначевский <tetsio.nainn at gmail.com> wrote:

> имелось ввиду access_log с log_format
> 
> 
> 28 июня 2014 г., 4:17 пользователь М.А. Мохначевский <tetsio.nainn at gmail.com> написал:
> А анализ логов не дает необходимых результатов?
> 
> 
> 27 июня 2014 г., 22:48 пользователь Anatoly Mikhailov <anatoly at sonru.com> написал:
> 
> Стоит следующая задача: есть несколько приложений, построенных не некотором количестве сервисов,
> необходимо логировать каждое действие пользователя. В настоящее время все сделано на уровне
> приложений, но есть идея использовать ngx_http_auth_request_module для этих целей, который будет
> отправлять JSON на новый отдельный внутренний сервис аудита и выполняться перед каждый запросом.
> Цель - вынести все, что не связано с бизнес-логикой, из приложений насколько это возможно.
> 
> Такой use-case уже кем то используюется, что посоветуете?
> 
> 
> Анатолий
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> 
> 
> -- 
> С ув. М.А. Мохначевский
> Отдел системного администрирования
> ООО "Компания "СахаИнтернет НТ"
> к.т. (4112)219711 доб. 927
> 
> 
> 
> -- 
> С ув. М.А. Мохначевский
> Отдел системного администрирования
> ООО "Компания "СахаИнтернет НТ"
> к.т. (4112)219711 доб. 927
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

From sytar.alex at gmail.com  Sat Jun 28 11:57:47 2014
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Sat, 28 Jun 2014 15:57:47 +0400
Subject: =?UTF-8?B?UmU6IG5naW54INC40LvQuCBwaHAg0L7QsdGA0LXQt9Cw0LXRgiDRh9Cw0YHRgtGM?=
 =?UTF-8?B?INC+0YLQstC10YLQsCDQsiDQu9C+0LPQsNGFINC+0YjQuNCx0L7Qug==?=
In-Reply-To: <ee6022c937bfe4a199dfce3f811225c8.NginxMailingListRussian@forum.nginx.org>
References: <20140628030856.GE1849@mdounin.ru>
 <ee6022c937bfe4a199dfce3f811225c8.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKqRTSHiU3XhiNXAhvzxGuYJ11AAG541JbfhmQ83pmxU_Nix-w@mail.gmail.com>

А что мешает в настройках php настоить error_log и не мучать nginx?
28 июня 2014 г. 7:42 пользователь "SkaN2412" <nginx-forum at nginx.us> написал:

> Ну, stack trace нужен, потому что я отлаживаю то, что параллельно изучаю. А
> вообще, все было хорошо, до определенного момента, как-то что-то случилось
> и
> все стало плохо. А можно ли как-то изменить этот параметр без пересборки?
> Потому что я установил nginx из репозитория и руками ничего не собирал.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,251272,251274#msg-251274
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140628/6a22f860/attachment.html>

From nginx-forum at nginx.us  Sat Jun 28 14:35:12 2014
From: nginx-forum at nginx.us (SkaN2412)
Date: Sat, 28 Jun 2014 10:35:12 -0400
Subject: =?UTF-8?B?UmU6IG5naW54INC40LvQuCBwaHAg0L7QsdGA0LXQt9Cw0LXRgiDRh9Cw0YHRgtGM?=
 =?UTF-8?B?INC+0YLQstC10YLQsCDQsiDQu9C+0LPQsNGFINC+0YjQuNCx0L7Qug==?=
In-Reply-To: <CAKqRTSHiU3XhiNXAhvzxGuYJ11AAG541JbfhmQ83pmxU_Nix-w@mail.gmail.com>
References: <CAKqRTSHiU3XhiNXAhvzxGuYJ11AAG541JbfhmQ83pmxU_Nix-w@mail.gmail.com>
Message-ID: <68b0d957c668c343788a0c9ece3241e8.NginxMailingListRussian@forum.nginx.org>

Дело в Wordpress, который все ошибки перенаправляет в лог, у меня-то
настроен вывод ошибок на экран, а в вордпрессе нет.

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


From stalker at altlinux.ru  Sat Jun 28 18:58:38 2014
From: stalker at altlinux.ru (Anton Gorlov)
Date: Sat, 28 Jun 2014 22:58:38 +0400
Subject: =?UTF-8?B?UmU6IG5naW54INC40LvQuCBwaHAg0L7QsdGA0LXQt9Cw0LXRgiDRh9Cw0YHRgtGM?=
 =?UTF-8?B?INC+0YLQstC10YLQsCDQsiDQu9C+0LPQsNGFINC+0YjQuNCx0L7Qug==?=
In-Reply-To: <68b0d957c668c343788a0c9ece3241e8.NginxMailingListRussian@forum.nginx.org>
References: <CAKqRTSHiU3XhiNXAhvzxGuYJ11AAG541JbfhmQ83pmxU_Nix-w@mail.gmail.com>
 <68b0d957c668c343788a0c9ece3241e8.NginxMailingListRussian@forum.nginx.org>
Message-ID: <53AF105E.1040901@altlinux.ru>

А он разве не использует то, что у php в error_log в php.ini?
А вообще
http://wordpress.org/support/topic/how-to-set-a-php-error-log-file-for-wp

// Enable Debug logging to the /wp-content/debug.log file
define('WP_DEBUG_LOG', true)

28.06.2014 18:35, SkaN2412 пишет:
> Дело в Wordpress, который все ошибки перенаправляет в лог, у меня-то
> настроен вывод ошибок на экран, а в вордпрессе нет.
>
>

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

From nginx-forum at nginx.us  Sat Jun 28 21:30:45 2014
From: nginx-forum at nginx.us (midobiho)
Date: Sat, 28 Jun 2014 17:30:45 -0400
Subject: net::ERR_INCOMPLETE_CHUNKED_ENCODING
Message-ID: <54f9a9aea1b4cfb36d137d1b0dafdbcc.NginxMailingListRussian@forum.nginx.org>

Всем привет, нужна помощь. Установлен nginx 1.6.0 + php5.4 fpm .Пытаюсь
поставить mediawiki 1.23.1 , после установки столкнулся с проблемой, что не
догружается стили (сам файл отдается урезанным), в связи с этим страница
отображается криво.

Проблема с файлом вида
load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=20140628T175745Z

в меню инструментов разработчиков chromium в столбце статус:

net::ERR_INCOMPLETE_CHUNKED_ENCODING

Конфиг 

server {
	server_name localhost;
	root /var/www/wiki;
	# Location for the wiki's root
	location / {
		index index.php;
		try_files $uri $uri/ @mediawiki;
		
		# Do this inside of a location so it can be negated
		location ~ \.php$ {
			try_files $uri $uri/ =404; # Don't let php execute non-existent php
files
			include /etc/nginx/fastcgi_params;
			fastcgi_pass unix:/var/run/php5-fpm-wiki.sock;
		}
	}
	
	location /images {
		# Separate location for images/ so .php execution won't apply
		
		location ~
^/images/thumb/(archive/)?[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$
{
			# Thumbnail handler for MediaWiki
			# This location only matches on a thumbnail's url
			# If the file does not exist we use @thumb to run the thumb.php script
			try_files $uri $uri/ @thumb;
		}
	}
	location /images/deleted {
		# Deny access to deleted images folder
		deny	all;
	}
	
	# Deny access to folders MediaWiki has a .htaccess deny in
	location /cache       { deny all; }
	location /languages   { deny all; }
	location /maintenance { deny all; }
	location /serialized  { deny all; }
	
	# Just in case, hide .svn and .git too
	location ~ /.(svn|git)(/|$) { deny all; }
	
	# Hide any .htaccess files
	location ~ /.ht { deny all; }
	
	# Uncomment the following code if you wish to hide the installer/updater
	## Deny access to the installer
	#location /mw-config { deny all; }
	
	# Handling for the article path
	location @mediawiki {
		include /etc/nginx/fastcgi_params;
		# article path should always be passed to index.php
		fastcgi_param SCRIPT_FILENAME	$document_root/index.php;
		fastcgi_pass  unix:/var/run/php5-fpm-wiki.sock;
	}
	
	# Thumbnail 404 handler, only called by try_files when a thumbnail does not
exist
	location @thumb {

		# Do a rewrite here so that thumb.php gets the correct arguments
		rewrite ^/images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$
/thumb.php?f=$1&width=$2;
		rewrite
^/images/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$
/thumb.php?f=$1&width=$2&archived=1;
		
		# Run the thumb.php script
		include /etc/nginx/fastcgi_params;
		fastcgi_param SCRIPT_FILENAME	$document_root/thumb.php;
		fastcgi_pass  unix:/var/run/php5-fpm-wiki.sock;
	}
	# не позволять nginx отдавать файлы, начинающиеся с точки (.htaccess, .svn,
.git и прочие)
    	location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
    }	
}

Кто сталкивался?

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


From nginx-forum at nginx.us  Sun Jun 29 02:22:26 2014
From: nginx-forum at nginx.us (SkaN2412)
Date: Sat, 28 Jun 2014 22:22:26 -0400
Subject: =?UTF-8?B?UmU6IG5naW54INC40LvQuCBwaHAg0L7QsdGA0LXQt9Cw0LXRgiDRh9Cw0YHRgtGM?=
 =?UTF-8?B?INC+0YLQstC10YLQsCDQsiDQu9C+0LPQsNGFINC+0YjQuNCx0L7Qug==?=
In-Reply-To: <53AF105E.1040901@altlinux.ru>
References: <53AF105E.1040901@altlinux.ru>
Message-ID: <e91fcc09db7c595a659edeb56b2d79a6.NginxMailingListRussian@forum.nginx.org>

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

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


From rogat1y at gmail.com  Sun Jun 29 17:07:55 2014
From: rogat1y at gmail.com (Maxim Kozlov)
Date: Sun, 29 Jun 2014 21:07:55 +0400
Subject: =?UTF-8?B?UmU6INCU0LLQsCBzdWJfZmlsdGVy?=
In-Reply-To: <20140627142426.GU1849@mdounin.ru>
References: <CAB-_x2OPWPOU=oxEwXoe6x6v1U1fcf4R1z-UYr_z1LuvsDn_Vg@mail.gmail.com>
 <20140627142426.GU1849@mdounin.ru>
Message-ID: <CAB-_x2OwJBv-FzvUPmOJJbw7z0ROWYa3qvMxDexCEuWshU5oag@mail.gmail.com>

Использовать сторонние модули желания нет.

>> Простой workaround - сделать дополнительное проксирование
Настраивать дополнительный виртуальный сервер? Как лучше тогда проксировать
-- на порт или unix сокет?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140629/dc7f76f1/attachment.html>

From andrey.ilyin at cpslabs.net  Mon Jun 30 09:27:39 2014
From: andrey.ilyin at cpslabs.net (Andrey Ilyin)
Date: Mon, 30 Jun 2014 13:27:39 +0400
Subject: =?UTF-8?B?Tmdpbngg0LLQvtC30LLRgNCw0YnQsNC10YIgNDk5INC/0YDQuCDQv9GA0L7QutGB?=
 =?UTF-8?B?0LjRgNC+0LLQsNC90LjQuCDQv9C+0YHQu9C1INC90LXRgdC60L7Qu9GM0Lo=?=
 =?UTF-8?B?0LjRhSDRh9Cw0YHQvtCyINGA0LDQsdC+0YLRiw==?=
Message-ID: <28531238.20140630132739@cpslabs.net>

Всем добрый день!

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

Через ~4-6 часов работы nginx перестает проксировать запросы на второй
сервер и возвращает статус 499.

При  этом  все  запросы,  которые  проксируются  на этом же сервере на
Apache отрабатывают нормально.

После reload или restart все возвращается в нормальное русло.

Проблема появилась после того как переехали на новый сервер и обновили
nginx с версии 1.4 до 1.7.1.

В debug log'e
http run request
http upstream check client, write event:0
epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while connecting to upstream


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


Сервер работает под ОС Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux
nginx version: nginx/1.7.1

Включенные модули nginx'a можно посмотреть тут
https://www.dropbox.com/s/uotxbtyks0xb15j/nginx-modules.txt

Дебаг логи
https://www.dropbox.com/s/avjetz8wcrx6fdy/filtered_bad_renamed.log


From sb at nginx.com  Mon Jun 30 11:49:52 2014
From: sb at nginx.com (Sergey Budnevitch)
Date: Mon, 30 Jun 2014 15:49:52 +0400
Subject: =?UTF-8?B?UmU6IE5naW54INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCIDQ5OSDQv9GA0Lgg0L/RgNC+?=
 =?UTF-8?B?0LrRgdC40YDQvtCy0LDQvdC40Lgg0L/QvtGB0LvQtSDQvdC10YHQutC+0Ls=?=
 =?UTF-8?B?0YzQutC40YUg0YfQsNGB0L7QsiDRgNCw0LHQvtGC0Ys=?=
In-Reply-To: <28531238.20140630132739@cpslabs.net>
References: <28531238.20140630132739@cpslabs.net>
Message-ID: <4C811491-8B7C-49A3-9F88-92B8894EBB39@nginx.com>


On 30 Jun 2014, at 13:27, Andrey Ilyin <andrey.ilyin at cpslabs.net> wrote:

> Всем добрый день!
> 
> Столкнулся с довольно странной проблемой на боевом сервере.
> 
> Через ~4-6 часов работы nginx перестает проксировать запросы на второй
> сервер и возвращает статус 499.
> 
> При  этом  все  запросы,  которые  проксируются  на этом же сервере на
> Apache отрабатывают нормально.
> 
> После reload или restart все возвращается в нормальное русло.
> 
> Проблема появилась после того как переехали на новый сервер и обновили
> nginx с версии 1.4 до 1.7.1.
> 
> В debug log'e
> http run request
> http upstream check client, write event:0
> epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while connecting to upstream
> 
> 
> Подскажите,  пожалуйста,  возможно  кто-то  уже  сталкивался  с данной
> проблемой, как можно это решить?

Посмотрите на ошибки на сетевой карте.

From nginx-forum at nginx.us  Mon Jun 30 12:44:53 2014
From: nginx-forum at nginx.us (=?UTF-8?Q? =D0=94=D0=B0=D0=B2=D0=B8=D0=B4=20=D0=9C=D0=B7=D0=B0=D1=80?=
 =?UTF-8?Q?=D0=B5=D1=83=D0=BB=D1=8F=D0=BD ?=)
Date: Mon, 30 Jun 2014 08:44:53 -0400
Subject: =?UTF-8?B?0J3QtdC/0L7QvdGP0YLQvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1INGA0LDQt9C8?=
 =?UTF-8?B?0LXRgNCwINC60Y3RiNCw?=
Message-ID: <5516cbf6bf6454ba80ef87f05e52f6e1.NginxMailingListRussian@forum.nginx.org>

Добрый день!

nginx/1.4.6 под ubuntu 14.04, определены две зоны кэша на 100-гигабайтном
диске:

proxy_cache_path        /mnt1/cache1 levels=2:2 keys_zone=previewCache1:512m
max_size=25g inactive=10y;
proxy_cache_path        /mnt1/cache2 levels=2:2 keys_zone=previewCache2:512m
max_size=70g inactive=10y;

Каталог первой зоны (/mnt1/cache1) сейчас имеет размер 26G, что нормально и
близко к заданному. А вот размер каталога второй зоны (/mnt1/cache2)
стабилизируется на 50-52G и дальше не растёт. Более того, если во втором
proxy_cache_path задать max_size=60g, то размер каталога уменьшается до
42G.

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

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


From nginx-forum at nginx.us  Mon Jun 30 13:14:18 2014
From: nginx-forum at nginx.us (Andruxa)
Date: Mon, 30 Jun 2014 09:14:18 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCIDQ5OSDQv9GA0Lgg0L/RgNC+?=
 =?UTF-8?B?0LrRgdC40YDQvtCy0LDQvdC40Lgg0L/QvtGB0LvQtSDQvdC10YHQutC+0Ls=?=
 =?UTF-8?B?0YzQutC40YUg0YfQsNGB0L7QsiDRgNCw0LHQvtGC0Ys=?=
In-Reply-To: <4C811491-8B7C-49A3-9F88-92B8894EBB39@nginx.com>
References: <4C811491-8B7C-49A3-9F88-92B8894EBB39@nginx.com>
Message-ID: <eae8329df36bda02ebff3334a738cb88.NginxMailingListRussian@forum.nginx.org>

На первом сервере (который проксирует):
RX packets:1968720 errors:0 dropped:1968574 overruns:0 frame:0
TX packets:61239 errors:0 dropped:0 overruns:0 carrier:0

На втором сервере (на который проксирует):
RX packets:1899886486 errors:0 dropped:0 overruns:447 frame:0
TX packets:2393436115 errors:0 dropped:0 overruns:0 carrier:0

Тут настораживает наличие ошибок overruns. Как считаете, это может быть
причиной ошибок?

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


From vitaliy.okulov at gmail.com  Mon Jun 30 15:05:28 2014
From: vitaliy.okulov at gmail.com (Vitaliy Okulov)
Date: Mon, 30 Jun 2014 19:05:28 +0400
Subject: =?UTF-8?B?UmU6IE5naW54INCy0L7Qt9Cy0YDQsNGJ0LDQtdGCIDQ5OSDQv9GA0Lgg0L/RgNC+?=
 =?UTF-8?B?0LrRgdC40YDQvtCy0LDQvdC40Lgg0L/QvtGB0LvQtSDQvdC10YHQutC+0Ls=?=
 =?UTF-8?B?0YzQutC40YUg0YfQsNGB0L7QsiDRgNCw0LHQvtGC0Ys=?=
In-Reply-To: <eae8329df36bda02ebff3334a738cb88.NginxMailingListRussian@forum.nginx.org>
References: <4C811491-8B7C-49A3-9F88-92B8894EBB39@nginx.com>
 <eae8329df36bda02ebff3334a738cb88.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CALiQiZ=Nv1kXk7W8cR+JyAy2oHxRLV5szykMyXzh--O-gZrXmw@mail.gmail.com>

Количество dropped не смущает?
30.06.2014 17:14 пользователь "Andruxa" <nginx-forum at nginx.us> написал:

> На первом сервере (который проксирует):
> RX packets:1968720 errors:0 dropped:1968574 overruns:0 frame:0
> TX packets:61239 errors:0 dropped:0 overruns:0 carrier:0
>
> На втором сервере (на который проксирует):
> RX packets:1899886486 errors:0 dropped:0 overruns:447 frame:0
> TX packets:2393436115 errors:0 dropped:0 overruns:0 carrier:0
>
> Тут настораживает наличие ошибок overruns. Как считаете, это может быть
> причиной ошибок?
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,251304,251309#msg-251309
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140630/931f8240/attachment.html>

From vbart at nginx.com  Mon Jun 30 17:32:39 2014
From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Mon, 30 Jun 2014 21:32:39 +0400
Subject: =?UTF-8?B?UmU6INCa0L7QvdGE0LjQs9GD0YDQsNGG0LjRjyBOZ2lueCDQsdC10LcgcmV3cml0?=
 =?UTF-8?B?ZQ==?=
In-Reply-To: <a245d0f659f2919cab428537e7cb99e3.NginxMailingListRussian@forum.nginx.org>
References: <a245d0f659f2919cab428537e7cb99e3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3216105.3NrTkZfCfY@vbart-workstation>

On Thursday 26 June 2014 20:47:28 inliquid wrote:
> Добрый день,
> 
> пытаюсь переписать конфигурацию под форумный движок esoTalk на nginx, так
> чтобы избежать использования rewrite, как рекомендует Игорь Сысоев... но не
> получается...
> Прошу уважаемое сообщество помочь...
> 
> Что имеем: 
> 1. сайт работает по ссылке example.com/forum, ЧПУ имеют вид
> /forum/блабла/тынцтынц/.... иногда добавляются параметры ?token=....  и
> т.д.
> 2. .htaccess из коробки для него имеет следующий вид:
> 
> <IfModule mod_rewrite.c>
> RewriteEngine On
> RewriteCond %{REQUEST_FILENAME} !-f
> RewriteRule ^(.*)$ index.php/$1 [QSA,L]
> </IfModule>
> 
> 
> 3. Добился работающего аналога конфигурации nginx:
> 
>         location ~ \.(php) {
>                 fastcgi_pass unix:/var/run/php5-fpm.sock;
>                 fastcgi_index index.php;
>                 include fastcgi_params;
>                 fastcgi_param SCRIPT_FILENAME
> $document_root/$fastcgi_script_name;
>                 fastcgi_param PATH_INFO $fastcgi_script_name;
> }
> 
>         location / {
>                         try_files $uri @esotalk;
> }
> 
>               location ~*
> ^/forum/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
>                       root /var/www/example.com;
>               }
> 
>         location @esotalk {
>              rewrite ^/(.*)$ /forum/index.php/$1 last;
> }
> 
> 
> 
> Пытаюсь настроить как рекомендовано, без rewrite:
> 
> 
>         location / {
>                         try_files $uri @esotalk;
> }
> 
> 
> 
>         location @esotalk {
>                 fastcgi_pass unix:/var/run/php5-fpm.sock;
>                 include fastcgi_params;
>                 fastcgi_param SCRIPT_FILENAME
> $document_root/forum/index.php;
>                 fastcgi_param PATH_INFO /index.php$uri; # --->>>????
> }

Уберите отсюда /index.php:

   fastcgi_param PATH_INFO $uri;

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

From mdounin at mdounin.ru  Mon Jun 30 18:54:30 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 30 Jun 2014 22:54:30 +0400
Subject: =?UTF-8?B?UmU6INCU0LLQsCBzdWJfZmlsdGVy?=
In-Reply-To: <CAB-_x2OwJBv-FzvUPmOJJbw7z0ROWYa3qvMxDexCEuWshU5oag@mail.gmail.com>
References: <CAB-_x2OPWPOU=oxEwXoe6x6v1U1fcf4R1z-UYr_z1LuvsDn_Vg@mail.gmail.com>
 <20140627142426.GU1849@mdounin.ru>
 <CAB-_x2OwJBv-FzvUPmOJJbw7z0ROWYa3qvMxDexCEuWshU5oag@mail.gmail.com>
Message-ID: <20140630185430.GG1849@mdounin.ru>

Hello!

On Sun, Jun 29, 2014 at 09:07:55PM +0400, Maxim Kozlov wrote:

> Использовать сторонние модули желания нет.
> 
> >> Простой workaround - сделать дополнительное проксирование
> Настраивать дополнительный виртуальный сервер? Как лучше тогда проксировать
> -- на порт или unix сокет?

Делайте так, как вам удобнее/понятнее.  С технической точки 
зрения - и отдельного location'а хватит:

    location / {
        sub_filter ...
        proxy_pass http://localhost/sub2/;
    }

    location /sub2/ {
        sub_filter ...
        ...
    }

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

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


From nginx-forum at nginx.us  Mon Jun 30 22:02:14 2014
From: nginx-forum at nginx.us (Klim81)
Date: Mon, 30 Jun 2014 18:02:14 -0400
Subject: rewrite xbt
Message-ID: <0df66cb59c6b55f79a5446a962f871f2.NginxMailingListRussian@forum.nginx.org>

proxy_pass отнимает у меня приблизительно 15-20% нагрузки, поэтому его не
предлагать...
http://tr.site.com/0218afaf304828a2a9492a7478ac668/announce оригинал.
rewrite ^/ http://ip/announce permanent; некорректно отрабатывался. 
rewrite ^ http://ip$request_uri permanent; приводил ошибку в клиенте об
многочисленных переходах. 
Пожалуйста, подскажите адекватный rewrite. 
Заранее спасибо.

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


From mdounin at mdounin.ru  Mon Jun 30 23:02:46 2014
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 1 Jul 2014 03:02:46 +0400
Subject: net::ERR_INCOMPLETE_CHUNKED_ENCODING
In-Reply-To: <54f9a9aea1b4cfb36d137d1b0dafdbcc.NginxMailingListRussian@forum.nginx.org>
References: <54f9a9aea1b4cfb36d137d1b0dafdbcc.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20140630230246.GL1849@mdounin.ru>

Hello!

On Sat, Jun 28, 2014 at 05:30:45PM -0400, midobiho wrote:

> Всем привет, нужна помощь. Установлен nginx 1.6.0 + php5.4 fpm .Пытаюсь
> поставить mediawiki 1.23.1 , после установки столкнулся с проблемой, что не
> догружается стили (сам файл отдается урезанным), в связи с этим страница
> отображается криво.
> 
> Проблема с файлом вида
> load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=20140628T175745Z
> 
> в меню инструментов разработчиков chromium в столбце статус:
> 
> net::ERR_INCOMPLETE_CHUNKED_ENCODING

Вероятно, бекенд упал и/или по каким-то ещё причинам разорвал 
соединение.  Имеет смысл заглянуть в error log (а равно в логи к 
бекенду), там, скорее всего, найдутся подробности.

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