From nginx-forum at nginx.us  Sun Sep  1 00:29:51 2013
From: nginx-forum at nginx.us (locojohn)
Date: Sat, 31 Aug 2013 20:29:51 -0400
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
Message-ID: <a24cbb2fcb955c789ae1c74e9c3ba9c2.NginxMailingListRussian@forum.nginx.org>

Наблюдаю интересную картину.  При длинном $uri (адресной строка = 750
символов) nginx 1.5.4 выдает 400 Bad Request, в то время как nginx 1.5.3 не
выдаёт ошибок и показывает страницу как полагается.

значение large_client_header_buffers в конфигурации в обоих случаях:

large_client_header_buffers 4 8k;

Баг?

Андрей

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


From vbart at nginx.com  Sun Sep  1 01:17:15 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Sun, 1 Sep 2013 05:17:15 +0400
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
In-Reply-To: <a24cbb2fcb955c789ae1c74e9c3ba9c2.NginxMailingListRussian@forum.nginx.org>
References: <a24cbb2fcb955c789ae1c74e9c3ba9c2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201309010517.15260.vbart@nginx.com>

On Sunday 01 September 2013 04:29:51 locojohn wrote:
> Наблюдаю интересную картину.  При длинном $uri (адресной строка = 750
> символов) nginx 1.5.4 выдает 400 Bad Request, в то время как nginx 1.5.3 не
> выдаёт ошибок и показывает страницу как полагается.
> 
> значение large_client_header_buffers в конфигурации в обоих случаях:
> 
> large_client_header_buffers 4 8k;
> 
> Баг?
> 

А в error_log что?  Должно быть безусловным рефлексом любого администратора при 
виде ошибки - проверить лог ошибок. 

--
Валентин Бартенев
http://nginx.org/en/donation.html

From nginx-forum at nginx.us  Sun Sep  1 10:31:54 2013
From: nginx-forum at nginx.us (locojohn)
Date: Sun, 01 Sep 2013 06:31:54 -0400
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
In-Reply-To: <201309010517.15260.vbart@nginx.com>
References: <201309010517.15260.vbart@nginx.com>
Message-ID: <88b389663292c5f2c0c80e76ee7306e3.NginxMailingListRussian@forum.nginx.org>

Странно, но абсолютно ничего.  Я бы написал если бы было чего.

error_log /var/log/nginx/cm.error_log info;

Андрей

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


From vadim.lazovskiy at gmail.com  Sun Sep  1 10:42:43 2013
From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy)
Date: Sun, 1 Sep 2013 14:42:43 +0400
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
In-Reply-To: <88b389663292c5f2c0c80e76ee7306e3.NginxMailingListRussian@forum.nginx.org>
References: <201309010517.15260.vbart@nginx.com>
 <88b389663292c5f2c0c80e76ee7306e3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAL-L5YBD6uSf=_9O+dso9pNLzNt6v+qBX-v==4z6=4d_qBtEgw@mail.gmail.com>

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

Емнип, 400 ответ всегда логгируется в error log.
Скорее всего ошибка попадает в лог того server, что является по-умолчанию
для конкретной пары адрес:порт в listen.


1 сентября 2013 г., 14:31 пользователь locojohn <nginx-forum at nginx.us>написал:

> Странно, но абсолютно ничего.  Я бы написал если бы было чего.
>
> error_log /var/log/nginx/cm.error_log info;
>
> Андрей
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,242399,242404#msg-242404
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



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

From nginx-forum at nginx.us  Sun Sep  1 10:59:05 2013
From: nginx-forum at nginx.us (locojohn)
Date: Sun, 01 Sep 2013 06:59:05 -0400
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
In-Reply-To: <CAL-L5YBD6uSf=_9O+dso9pNLzNt6v+qBX-v==4z6=4d_qBtEgw@mail.gmail.com>
References: <CAL-L5YBD6uSf=_9O+dso9pNLzNt6v+qBX-v==4z6=4d_qBtEgw@mail.gmail.com>
Message-ID: <4456f58131d1f9d32f592c982af11e9b.NginxMailingListRussian@forum.nginx.org>

/var/log/cm.access_log:

191.128.53.162 - - [01/Sep/2013:12:54:52 +0200] "GET
/??/_common/jquery/jquery-1.7.1.min.js,/_common/jquery/ui/jquery-ui-1.8.17.custom.min.js,/_common/jquery/jquery.cookie.min.js,/_common/jquery/jquery.json.min.js,/_common/jquery/json3.min.js,/_common/jquery/jquery.cookiejar.min.js,/_common/jquery/jquery.blockUI.min.js,/_common/jquery/jquery.spin.min.js,/_common/jquery/jquery.toggleElements.min.js,/_common/jquery/linkselect/lib/jquery.linkselect.min.js,/_common/jquery/jquery.tablesorter.min.js,/_common/jquery/jquery.asmselect.mod.js,/_common/jquery/brTip.src.js,/_common/jquery/validate/jquery.validate.min.js,/_common/jquery/jqGrid-4.5.2/js/i18n/grid.locale-en.js,/_common/jquery/jqGrid-4.5.2/js/jquery.jqGrid.min.js,/_common/jquery/jqGrid-4.5.2/plugins/grid.setcolumns.js,/js/ui.imageuploader.js
HTTP/1.1" 400 338

/var/log/cm.error_log:

2013/09/01 12:53:48 [info] 12848#0: *1 client 91.188.52.162 closed keepalive
connection
2013/09/01 12:54:00 [info] 12848#0: *5 client 91.188.52.162 closed keepalive
connection
2013/09/01 12:54:46 [info] 12848#0: *6 client 91.188.52.162 closed keepalive
connection
2013/09/01 12:54:49 [info] 12848#0: *8 client 91.188.52.162 closed keepalive
connection
2013/09/01 12:55:45 [info] 12848#0: *19 client 91.188.52.162 closed
keepalive connection
2013/09/01 12:55:45 [info] 12848#0: *16 client 91.188.52.162 closed
keepalive connection
2013/09/01 12:55:45 [info] 12848#0: *15 client 91.188.52.162 closed
keepalive connection
2013/09/01 12:55:45 [info] 12848#0: *17 client 91.188.52.162 closed
keepalive connection
2013/09/01 12:55:45 [info] 12848#0: *14 client 91.188.52.162 closed
keepalive connection

/var/log/error_log: (main)

2013/09/01 12:53:40 [notice] 12846#0: using the "epoll" event method
2013/09/01 12:53:40 [notice] 12846#0: nginx/1.5.4
2013/09/01 12:53:40 [notice] 12846#0: OS: Linux 3.9.11-gentoo-r1-mrbyte
2013/09/01 12:53:40 [notice] 12846#0: getrlimit(RLIMIT_NOFILE): 10000:30000
2013/09/01 12:53:40 [notice] 12847#0: start worker processes
2013/09/01 12:53:40 [notice] 12847#0: start worker process 12848
2013/09/01 12:53:40 [notice] 12847#0: start worker process 12849
2013/09/01 12:53:40 [notice] 12847#0: start worker process 12850
2013/09/01 12:53:40 [notice] 12847#0: start worker process 12852


nginx.conf:

        server {
                listen 80;
                server_name devel.coursemanagement.bimv.com;

                access_log /var/log/nginx/cm.access_log main;
                error_log /var/log/nginx/cm.error_log info;

                root /opt/www/cm;

                location / {
                  index index.php;
                }

                ..............

        }

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


From nginx-forum at nginx.us  Sun Sep  1 11:04:03 2013
From: nginx-forum at nginx.us (locojohn)
Date: Sun, 01 Sep 2013 07:04:03 -0400
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
In-Reply-To: <4456f58131d1f9d32f592c982af11e9b.NginxMailingListRussian@forum.nginx.org>
References: <CAL-L5YBD6uSf=_9O+dso9pNLzNt6v+qBX-v==4z6=4d_qBtEgw@mail.gmail.com>
 <4456f58131d1f9d32f592c982af11e9b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <cc3b433a116a2cb51639513c61f26112.NginxMailingListRussian@forum.nginx.org>

Забыл сообщить, что использую concat module
https://github.com/alibaba/nginx-http-concat для конкатенации Javascript/CSS
файлов в один запрос.

Андрей

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


From vadim.lazovskiy at gmail.com  Sun Sep  1 11:03:53 2013
From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy)
Date: Sun, 1 Sep 2013 15:03:53 +0400
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
In-Reply-To: <4456f58131d1f9d32f592c982af11e9b.NginxMailingListRussian@forum.nginx.org>
References: <CAL-L5YBD6uSf=_9O+dso9pNLzNt6v+qBX-v==4z6=4d_qBtEgw@mail.gmail.com>
 <4456f58131d1f9d32f592c982af11e9b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAL-L5YAUEPu_Lkg0oVzGCpMAGjoGM5nPu69sH_-L4jJvAR347Q@mail.gmail.com>

Это единственный сервер для listen 80?


2013/9/1 locojohn <nginx-forum at nginx.us>

> /var/log/cm.access_log:
>
> 191.128.53.162 - - [01/Sep/2013:12:54:52 +0200] "GET
>
> /??/_common/jquery/jquery-1.7.1.min.js,/_common/jquery/ui/jquery-ui-1.8.17.custom.min.js,/_common/jquery/jquery.cookie.min.js,/_common/jquery/jquery.json.min.js,/_common/jquery/json3.min.js,/_common/jquery/jquery.cookiejar.min.js,/_common/jquery/jquery.blockUI.min.js,/_common/jquery/jquery.spin.min.js,/_common/jquery/jquery.toggleElements.min.js,/_common/jquery/linkselect/lib/jquery.linkselect.min.js,/_common/jquery/jquery.tablesorter.min.js,/_common/jquery/jquery.asmselect.mod.js,/_common/jquery/brTip.src.js,/_common/jquery/validate/jquery.validate.min.js,/_common/jquery/jqGrid-4.5.2/js/i18n/grid.locale-en.js,/_common/jquery/jqGrid-4.5.2/js/jquery.jqGrid.min.js,/_common/jquery/jqGrid-4.5.2/plugins/grid.setcolumns.js,/js/ui.imageuploader.js
> HTTP/1.1" 400 338
>
> /var/log/cm.error_log:
>
> 2013/09/01 12:53:48 [info] 12848#0: *1 client 91.188.52.162 closed
> keepalive
> connection
> 2013/09/01 12:54:00 [info] 12848#0: *5 client 91.188.52.162 closed
> keepalive
> connection
> 2013/09/01 12:54:46 [info] 12848#0: *6 client 91.188.52.162 closed
> keepalive
> connection
> 2013/09/01 12:54:49 [info] 12848#0: *8 client 91.188.52.162 closed
> keepalive
> connection
> 2013/09/01 12:55:45 [info] 12848#0: *19 client 91.188.52.162 closed
> keepalive connection
> 2013/09/01 12:55:45 [info] 12848#0: *16 client 91.188.52.162 closed
> keepalive connection
> 2013/09/01 12:55:45 [info] 12848#0: *15 client 91.188.52.162 closed
> keepalive connection
> 2013/09/01 12:55:45 [info] 12848#0: *17 client 91.188.52.162 closed
> keepalive connection
> 2013/09/01 12:55:45 [info] 12848#0: *14 client 91.188.52.162 closed
> keepalive connection
>
> /var/log/error_log: (main)
>
> 2013/09/01 12:53:40 [notice] 12846#0: using the "epoll" event method
> 2013/09/01 12:53:40 [notice] 12846#0: nginx/1.5.4
> 2013/09/01 12:53:40 [notice] 12846#0: OS: Linux 3.9.11-gentoo-r1-mrbyte
> 2013/09/01 12:53:40 [notice] 12846#0: getrlimit(RLIMIT_NOFILE): 10000:30000
> 2013/09/01 12:53:40 [notice] 12847#0: start worker processes
> 2013/09/01 12:53:40 [notice] 12847#0: start worker process 12848
> 2013/09/01 12:53:40 [notice] 12847#0: start worker process 12849
> 2013/09/01 12:53:40 [notice] 12847#0: start worker process 12850
> 2013/09/01 12:53:40 [notice] 12847#0: start worker process 12852
>
>
> nginx.conf:
>
>         server {
>                 listen 80;
>                 server_name devel.coursemanagement.bimv.com;
>
>                 access_log /var/log/nginx/cm.access_log main;
>                 error_log /var/log/nginx/cm.error_log info;
>
>                 root /opt/www/cm;
>
>                 location / {
>                   index index.php;
>                 }
>
>                 ..............
>
>         }
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,242399,242406#msg-242406
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



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

From nginx-forum at nginx.us  Sun Sep  1 11:10:01 2013
From: nginx-forum at nginx.us (locojohn)
Date: Sun, 01 Sep 2013 07:10:01 -0400
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
In-Reply-To: <CAL-L5YAUEPu_Lkg0oVzGCpMAGjoGM5nPu69sH_-L4jJvAR347Q@mail.gmail.com>
References: <CAL-L5YAUEPu_Lkg0oVzGCpMAGjoGM5nPu69sH_-L4jJvAR347Q@mail.gmail.com>
Message-ID: <ecf5828dc3085535e230fea2ec38d499.NginxMailingListRussian@forum.nginx.org>

> Это единственный сервер для listen 80?

Нет.

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


From vadim.lazovskiy at gmail.com  Sun Sep  1 11:32:56 2013
From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy)
Date: Sun, 1 Sep 2013 15:32:56 +0400
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
In-Reply-To: <ecf5828dc3085535e230fea2ec38d499.NginxMailingListRussian@forum.nginx.org>
References: <CAL-L5YAUEPu_Lkg0oVzGCpMAGjoGM5nPu69sH_-L4jJvAR347Q@mail.gmail.com>
 <ecf5828dc3085535e230fea2ec38d499.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAL-L5YB7ONqNwpKy2_JsWr1tcifYBfHgJgUqg46VEebUstthcw@mail.gmail.com>

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

"Если у директивы есть параметр default_server, то сервер, в котором
описана эта директива, будет сервером по умолчанию для указанной пары *адрес
*:*порт*. Если же директив с параметром default_server нет, то сервером по
умолчанию будет первый сервер, в котором описана пара *адрес*:*порт*."

Возможно ваш server не первый для этой пары listen. Скорее всего ошибка
попадает в error_log другого сервера, поскольку на этапе разбора request
line еще не известен server который будет обслуживать этот запрос.

Попробуйте:

- listen 80;
+  listen 80 default_server;

если это не критично.



2013/9/1 locojohn <nginx-forum at nginx.us>

> > Это единственный сервер для listen 80?
>
> Нет.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,242399,242409#msg-242409
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



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

From gmm at csdoc.com  Sun Sep  1 13:15:55 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Sun, 01 Sep 2013 16:15:55 +0300
Subject: true 414 status code
In-Reply-To: <201309010057.12473.ne@vbart.ru>
References: <CAMxcU5KYfpL-HzY6nWooFjZx0sFLmKXQYsicqLoddAxVUfA0Ng@mail.gmail.com>
 <201309010057.12473.ne@vbart.ru>
Message-ID: <52233E0B.7020001@csdoc.com>

On 31.08.2013 23:57, Валентин Бартенев wrote:

>> Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414
>> status code, на запросы, размер которых, превышает large_client_header_
>> buffers?
>>
>> Постоянно получаю 200 http status code и нижеприведенное в body:
>>
>> <html>
>> <head><title>414 Request-URI Too Large</title></head>
>> <body bgcolor="white">
>> <center><h1>414 Request-URI Too Large</h1></center>
>> <hr><center>nginx/1.2.9</center>
>> </body>
>> </html>

> Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.

а есть ли смысл отвечать по протоколу версии HTTP/0.9 ?
тем более, что запрос в 99.9999999% был версии 1.0 или 1.1

даже если "Request-URI Too Large" - версию протокола
запроса можно узнать из строки запроса, при желании.

тем более, что протокол версии 0.9 не умеет прислать
клиенту ответ в котором будет указан status code 414

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

-- 
Best regards,
  Gena


From gmm at csdoc.com  Sun Sep  1 13:24:50 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Sun, 01 Sep 2013 16:24:50 +0300
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
In-Reply-To: <CAL-L5YB7ONqNwpKy2_JsWr1tcifYBfHgJgUqg46VEebUstthcw@mail.gmail.com>
References: <CAL-L5YAUEPu_Lkg0oVzGCpMAGjoGM5nPu69sH_-L4jJvAR347Q@mail.gmail.com>
 <ecf5828dc3085535e230fea2ec38d499.NginxMailingListRussian@forum.nginx.org>
 <CAL-L5YB7ONqNwpKy2_JsWr1tcifYBfHgJgUqg46VEebUstthcw@mail.gmail.com>
Message-ID: <52234022.1050909@csdoc.com>

On 01.09.2013 14:32, Vadim Lazovskiy wrote:

> Возможно ваш server не первый для этой пары listen. Скорее всего ошибка
> попадает в error_log другого сервера, поскольку на этапе разбора request
> line еще не известен server который будет обслуживать этот запрос.

кстати, запись в лог информации про ошибку разбора request line
можно отложить до тех пор, пока не станет известно имя хоста запроса
(из заголовка Host:, если он есть или дефолтовый сервер, если его нет)
- тогда запись информации про ошибку будет вестись в правильный лог-файл

-- 
Best regards,
  Gena


From nginx-forum at nginx.us  Sun Sep  1 14:02:58 2013
From: nginx-forum at nginx.us (locojohn)
Date: Sun, 01 Sep 2013 10:02:58 -0400
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
In-Reply-To: <52234022.1050909@csdoc.com>
References: <52234022.1050909@csdoc.com>
Message-ID: <494fbf6a03522927d56e4cf32d621524.NginxMailingListRussian@forum.nginx.org>

(Request-Line)	GET
/??/_common/jquery/jquery-1.7.1.min.js,/_common/jquery/ui/jquery-ui-1.8.17.custom.min.js,/_common/jquery/jquery.cookie.min.js,/_common/jquery/jquery.json.min.js,/_common/jquery/json3.min.js,/_common/jquery/jquery.cookiejar.min.js,/_common/jquery/jquery.blockUI.min.js,/_common/jquery/jquery.spin.min.js,/_common/jquery/jquery.toggleElements.min.js,/_common/jquery/linkselect/lib/jquery.linkselect.min.js,/_common/jquery/jquery.tablesorter.min.js,/_common/jquery/jquery.asmselect.mod.js,/_common/jquery/brTip.src.js,/_common/jquery/validate/jquery.validate.min.js,/_common/jquery/jqGrid-4.5.2/js/i18n/grid.locale-en.js,/_common/jquery/jqGrid-4.5.2/js/jquery.jqGrid.min.js,/_common/jquery/jqGrid-4.5.2/plugins/grid.setcolumns.js,/js/ui.imageuploader.js
HTTP/1.1
Host	: devel.coursemanagement.bimv.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0)
Gecko/20100101 Firefox/14.0.1
Accept:	text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language:	en-us,en;q=0.5
Accept-Encoding:	gzip, deflate
Connection:	keep-alive

(Status-Line)	HTTP/1.1 400 Bad Request
Server:	nginx/1.5.4
Date:	Sun, 01 Sep 2013 13:57:50 GMT
Content-Type:	text/html; charset=utf-8
Content-Length:	172
Connection:	close





# default fallback server
        server {
                listen 80 default_server;
                server_name  "_";
                error_log /var/log/nginx/error_log warn;
                return       444;
        }

/var/log/nginx/error_log: (default server error log)

2013/09/01 15:50:59 [notice] 22169#0: using the "epoll" event method
2013/09/01 15:50:59 [notice] 22169#0: nginx/1.5.4
2013/09/01 15:50:59 [notice] 22169#0: OS: Linux 3.9.11-gentoo-r1-mrbyte
2013/09/01 15:50:59 [notice] 22169#0: getrlimit(RLIMIT_NOFILE): 10000:30000
2013/09/01 15:50:59 [notice] 22170#0: start worker processes
2013/09/01 15:50:59 [notice] 22170#0: start worker process 22171
2013/09/01 15:50:59 [notice] 22170#0: start worker process 22172
2013/09/01 15:50:59 [notice] 22170#0: start worker process 22174
2013/09/01 15:50:59 [notice] 22170#0: start worker process 22175

devel.coursemanagement.bimv.com error log:

2013/09/01 15:47:10 [info] 21937#0: *1 client 91.188.52.162 closed keepalive
connection
2013/09/01 15:47:14 [info] 21937#0: *3 client 91.188.52.162 closed keepalive
connection
2013/09/01 15:48:31 [info] 22002#0: *4 client 91.188.52.162 closed keepalive
connection
2013/09/01 15:48:31 [info] 22002#0: *9 client 91.188.52.162 closed keepalive
connection
2013/09/01 15:48:31 [info] 22002#0: *3 client 91.188.52.162 closed keepalive
connection
2013/09/01 15:48:31 [info] 22002#0: *5 client 91.188.52.162 closed keepalive
connection
2013/09/01 15:56:52 [info] 22171#0: *5 client 91.188.52.162 closed keepalive
connection
2013/09/01 15:57:47 [info] 22171#0: *9 client 91.188.52.162 closed keepalive
connection

devel.coursemanagement.bimv.com access log:

91.188.52.162 - - [01/Sep/2013:15:57:50 +0200] "GET
/??/_common/jquery/jquery-1.7.1.min.js,/_common/jquery/ui/jquery-ui-1.8.17.custom.min.js,/_common/jquery/jquery.cookie.min.js,/_common/jquery/jquery.json.min.js,/_common/jquery/json3.min.js,/_common/jquery/jquery.cookiejar.min.js,/_common/jquery/jquery.blockUI.min.js,/_common/jquery/jquery.spin.min.js,/_common/jquery/jquery.toggleElements.min.js,/_common/jquery/linkselect/lib/jquery.linkselect.min.js,/_common/jquery/jquery.tablesorter.min.js,/_common/jquery/jquery.asmselect.mod.js,/_common/jquery/brTip.src.js,/_common/jquery/validate/jquery.validate.min.js,/_common/jquery/jqGrid-4.5.2/js/i18n/grid.locale-en.js,/_common/jquery/jqGrid-4.5.2/js/jquery.jqGrid.min.js,/_common/jquery/jqGrid-4.5.2/plugins/grid.setcolumns.js,/js/ui.imageuploader.js
HTTP/1.1" 400 338 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0)
Gecko/20100101 Firefox/14.0.1" "-" 0.050 1

Как видно из указанного выше, в access_log есть ответ со статусом 400.  В
*error_log ничего не наблюдаем.

Andrejs

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


From wangsamp at gmail.com  Sun Sep  1 14:31:37 2013
From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi)
Date: Sun, 1 Sep 2013 17:31:37 +0300 (EEST)
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
In-Reply-To: <494fbf6a03522927d56e4cf32d621524.NginxMailingListRussian@forum.nginx.org>
References: <52234022.1050909@csdoc.com>
 <494fbf6a03522927d56e4cf32d621524.NginxMailingListRussian@forum.nginx.org>
Message-ID: <alpine.BSF.2.00.1309011714180.37897@u.fchgavxzrqvn.arg>

Today Sep 1, 2013 at 10:02 locojohn wrote:

> (Status-Line)	HTTP/1.1 400 Bad Request
> Server:	nginx/1.5.4
> Date:	Sun, 01 Sep 2013 13:57:50 GMT
> Content-Type:	text/html; charset=utf-8
> Content-Length:	172
> Connection:	close

> devel.coursemanagement.bimv.com access log:
> 
> 91.188.52.162 - - [01/Sep/2013:15:57:50 +0200] "GET
> /??/_common/jquery/jquery-1.7.1.min.js,/_common/jquery/ui/jquery-ui-1.8.17.custom.min.js,/_common/jquery/jquery.cookie.min.js,/_common/jquery/jquery.json.min.js,/_common/jquery/json3.min.js,/_common/jquery/jquery.cookiejar.min.js,/_common/jquery/jquery.blockUI.min.js,/_common/jquery/jquery.spin.min.js,/_common/jquery/jquery.toggleElements.min.js,/_common/jquery/linkselect/lib/jquery.linkselect.min.js,/_common/jquery/jquery.tablesorter.min.js,/_common/jquery/jquery.asmselect.mod.js,/_common/jquery/brTip.src.js,/_common/jquery/validate/jquery.validate.min.js,/_common/jquery/jqGrid-4.5.2/js/i18n/grid.locale-en.js,/_common/jquery/jqGrid-4.5.2/js/jquery.jqGrid.min.js,/_common/jquery/jqGrid-4.5.2/plugins/grid.setcolumns.js,/js/ui.imageuploader.js
> HTTP/1.1" 400 338 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0)
> Gecko/20100101 Firefox/14.0.1" "-" 0.050 1
> 
> Как видно из указанного выше, в access_log есть ответ со статусом 400.  В
> *error_log ничего не наблюдаем.

  Как видно из кода стороннего модуля(а туда тоже следовало бы посмотреть), 
  там несколько return NGX_HTTP_BAD_REQUEST без записи чего-либо в лог ошибок.
  И они явно намекают на content type который теперь application/javascript.
  Добавление его в concat_types должно помочь.

-- 
WNGS-RIPE


From chipitsine at gmail.com  Sun Sep  1 18:08:15 2013
From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=)
Date: Mon, 2 Sep 2013 01:08:15 +0700
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
In-Reply-To: <4456f58131d1f9d32f592c982af11e9b.NginxMailingListRussian@forum.nginx.org>
References: <CAL-L5YBD6uSf=_9O+dso9pNLzNt6v+qBX-v==4z6=4d_qBtEgw@mail.gmail.com>
 <4456f58131d1f9d32f592c982af11e9b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQG7vGqje5dS6Qa1kZ8vyS34Vz+_h7wDNp4dViN=9H2=rQ@mail.gmail.com>

у вас ведь на php разработка?
возможно, имеет смысл перенести логику управления сборками js и css на
уровень php, например, вот при помощи такого

https://github.com/kriswallsmith/assetic

совешенно необязательно "вообще всё" делать на nginx-е.

2013/9/1 locojohn <nginx-forum at nginx.us>:
> /var/log/cm.access_log:
>
> 191.128.53.162 - - [01/Sep/2013:12:54:52 +0200] "GET
> /??/_common/jquery/jquery-1.7.1.min.js,/_common/jquery/ui/jquery-ui-1.8.17.custom.min.js,/_common/jquery/jquery.cookie.min.js,/_common/jquery/jquery.json.min.js,/_common/jquery/json3.min.js,/_common/jquery/jquery.cookiejar.min.js,/_common/jquery/jquery.blockUI.min.js,/_common/jquery/jquery.spin.min.js,/_common/jquery/jquery.toggleElements.min.js,/_common/jquery/linkselect/lib/jquery.linkselect.min.js,/_common/jquery/jquery.tablesorter.min.js,/_common/jquery/jquery.asmselect.mod.js,/_common/jquery/brTip.src.js,/_common/jquery/validate/jquery.validate.min.js,/_common/jquery/jqGrid-4.5.2/js/i18n/grid.locale-en.js,/_common/jquery/jqGrid-4.5.2/js/jquery.jqGrid.min.js,/_common/jquery/jqGrid-4.5.2/plugins/grid.setcolumns.js,/js/ui.imageuploader.js
> HTTP/1.1" 400 338
>
> /var/log/cm.error_log:
>
> 2013/09/01 12:53:48 [info] 12848#0: *1 client 91.188.52.162 closed keepalive
> connection
> 2013/09/01 12:54:00 [info] 12848#0: *5 client 91.188.52.162 closed keepalive
> connection
> 2013/09/01 12:54:46 [info] 12848#0: *6 client 91.188.52.162 closed keepalive
> connection
> 2013/09/01 12:54:49 [info] 12848#0: *8 client 91.188.52.162 closed keepalive
> connection
> 2013/09/01 12:55:45 [info] 12848#0: *19 client 91.188.52.162 closed
> keepalive connection
> 2013/09/01 12:55:45 [info] 12848#0: *16 client 91.188.52.162 closed
> keepalive connection
> 2013/09/01 12:55:45 [info] 12848#0: *15 client 91.188.52.162 closed
> keepalive connection
> 2013/09/01 12:55:45 [info] 12848#0: *17 client 91.188.52.162 closed
> keepalive connection
> 2013/09/01 12:55:45 [info] 12848#0: *14 client 91.188.52.162 closed
> keepalive connection
>
> /var/log/error_log: (main)
>
> 2013/09/01 12:53:40 [notice] 12846#0: using the "epoll" event method
> 2013/09/01 12:53:40 [notice] 12846#0: nginx/1.5.4
> 2013/09/01 12:53:40 [notice] 12846#0: OS: Linux 3.9.11-gentoo-r1-mrbyte
> 2013/09/01 12:53:40 [notice] 12846#0: getrlimit(RLIMIT_NOFILE): 10000:30000
> 2013/09/01 12:53:40 [notice] 12847#0: start worker processes
> 2013/09/01 12:53:40 [notice] 12847#0: start worker process 12848
> 2013/09/01 12:53:40 [notice] 12847#0: start worker process 12849
> 2013/09/01 12:53:40 [notice] 12847#0: start worker process 12850
> 2013/09/01 12:53:40 [notice] 12847#0: start worker process 12852
>
>
> nginx.conf:
>
>         server {
>                 listen 80;
>                 server_name devel.coursemanagement.bimv.com;
>
>                 access_log /var/log/nginx/cm.access_log main;
>                 error_log /var/log/nginx/cm.error_log info;
>
>                 root /opt/www/cm;
>
>                 location / {
>                   index index.php;
>                 }
>
>                 ..............
>
>         }
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242399,242406#msg-242406
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From andrei.seredenko at gmail.com  Sun Sep  1 18:31:35 2013
From: andrei.seredenko at gmail.com (=?KOI8-R?B?4c7E0sXKIPPF0sXExc7Lzw==?=)
Date: Sun, 1 Sep 2013 21:31:35 +0300
Subject: If is Evil
Message-ID: <CAK1EO=WJmRTg9-JzG9fLu=zyfX363yYBFtSQOruMQC-DDu-y8Q@mail.gmail.com>

Приветы всем!

Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не
рекомендуется, и что использовать его там можно только в купе с return или
rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и
почему.

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

    http://wiki.nginx.org/IfIsEvil
    http://habrahabr.ru/post/74135/
    http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html

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

Ребят, может кто может подробно и последовательно разжевать, КАК это
работает? А то пока получалось обходиться без if'ов, но кто его знает, что
будет завтра.. не хотелось бы оставить новый след от граблей, старый только
вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем просто
запомнить постулат "скажем if в location - НЕТ"

Буду признателен за любые ответы. Спасибо!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130901/be40f44f/attachment-0001.html>

From vladget at gmail.com  Sun Sep  1 20:33:57 2013
From: vladget at gmail.com (Vladimir Getmanshchuk)
Date: Sun, 1 Sep 2013 23:33:57 +0300
Subject: true 414 status code
In-Reply-To: <201309010057.12473.ne@vbart.ru>
References: <CAMxcU5KYfpL-HzY6nWooFjZx0sFLmKXQYsicqLoddAxVUfA0Ng@mail.gmail.com>
 <201309010057.12473.ne@vbart.ru>
Message-ID: <CAMxcU5JNDKYaV4ejDY+ojGwQqQL0YWqrwTVM+M9zR+ZaN6xzsw@mail.gmail.com>

Амм... Спасибо за скорость и лаконичность.

Судя по http://www.w3.org/Protocols/HTTP/HTRESP.html, в HTTP/0.9 тоже есть
status codes, или я что то недопонимаю?
Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"




2013/8/31 Валентин Бартенев <ne at vbart.ru>

> On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote:
> > Здравствуйте!
> >
> > Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414
> > status code, на запросы, размер которых, превышает large_client_header_
> > buffers?
> >
> > Постоянно получаю 200 http status code и нижеприведенное в body:
> >
> > <html>
> > <head><title>414 Request-URI Too Large</title></head>
> > <body bgcolor="white">
> > <center><h1>414 Request-URI Too Large</h1></center>
> > <hr><center>nginx/1.2.9</center>
> > </body>
> > </html>
>
> Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.
>
> --
> Валентин Бартенев
> http://nginx.org/en/donation.html
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Yours sincerely,
Vladimir Getmanshchuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130901/57a7b4d9/attachment.html>

From nginx-forum at nginx.us  Sun Sep  1 20:44:45 2013
From: nginx-forum at nginx.us (locojohn)
Date: Sun, 01 Sep 2013 16:44:45 -0400
Subject: 400 Bad Request 1.5.4 (1.5.3 = OK)
In-Reply-To: <alpine.BSF.2.00.1309011714180.37897@u.fchgavxzrqvn.arg>
References: <alpine.BSF.2.00.1309011714180.37897@u.fchgavxzrqvn.arg>
Message-ID: <04a45f072ccf80b2b8c85c098c74f73c.NginxMailingListRussian@forum.nginx.org>

Oleksandr V. Typlyns'kyi Wrote:

>   Как видно из кода стороннего модуля(а туда тоже следовало бы
> посмотреть), 
>   там несколько return NGX_HTTP_BAD_REQUEST без записи чего-либо в лог
> ошибок.
>   И они явно намекают на content type который теперь
> application/javascript.
>   Добавление его в concat_types должно помочь.

Спасибо за отличный хинт!  Добавление "application/javascript" в
concat_types не помогло, пришлось подпатчить исходный модуль concat:

--- ngx_http_concat_module.c
+++ ngx_http_concat_module.c
@@ -30,7 +30,7 @@


 static ngx_str_t  ngx_http_concat_default_types[] = {
-    ngx_string("application/x-javascript"),
+    ngx_string("application/javascript"),
     ngx_string("text/css"),
     ngx_null_string
 };

Ещё раз - спасибо!

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


From onokonem at gmail.com  Sun Sep  1 20:47:34 2013
From: onokonem at gmail.com (Daniel Podolsky)
Date: Mon, 2 Sep 2013 00:47:34 +0400
Subject: If is Evil
In-Reply-To: <CAK1EO=WJmRTg9-JzG9fLu=zyfX363yYBFtSQOruMQC-DDu-y8Q@mail.gmail.com>
References: <CAK1EO=WJmRTg9-JzG9fLu=zyfX363yYBFtSQOruMQC-DDu-y8Q@mail.gmail.com>
Message-ID: <CAKaHDOEit7ZusHh8s+tgSPosiyMFYqPCgkGeEvW6V1AoScv-Rw@mail.gmail.com>

> да и выяснить причину раз и навсегда куда полезнее, чем просто запомнить
> постулат "скажем if в location - НЕТ"
А мы им не скажем НЕТ. Мы просто помним, что для if создается скрытый
location, и что туда наследуется, а что нет, и какая там в результате
будет конфигурациия - ни за что не прописаешь, как говорили в школе.

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

Отдельно, конечно, смешно то, что это единственный разумный способ
пользоваться if, но директивы переадресации как не было, так и нет, и
приходится писать что-то вроде if (condition) { error_page 418 =
@location; return 418; }

From vbart at nginx.com  Sun Sep  1 23:02:45 2013
From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Mon, 2 Sep 2013 03:02:45 +0400
Subject: true 414 status code
In-Reply-To: <CAMxcU5JNDKYaV4ejDY+ojGwQqQL0YWqrwTVM+M9zR+ZaN6xzsw@mail.gmail.com>
References: <CAMxcU5KYfpL-HzY6nWooFjZx0sFLmKXQYsicqLoddAxVUfA0Ng@mail.gmail.com>
 <201309010057.12473.ne@vbart.ru>
 <CAMxcU5JNDKYaV4ejDY+ojGwQqQL0YWqrwTVM+M9zR+ZaN6xzsw@mail.gmail.com>
Message-ID: <201309020302.45995.vbart@nginx.com>

On Monday 02 September 2013 00:33:57 Vladimir Getmanshchuk wrote:
> Амм... Спасибо за скорость и лаконичность.
> 
> Судя по http://www.w3.org/Protocols/HTTP/HTRESP.html, в HTTP/0.9 тоже есть
> status codes, или я что то недопонимаю?

Вы ссылаетесь на спецификацию HTTP/1.0.  В HTTP/0.9 у ответа не было заголовка:
http://www.w3.org/Protocols/HTTP/AsImplemented.html
http://www.w3.org/DesignIssues/HTTP0.9Summary.html


> Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"

Сам дописывает видимо.  Смотрите более простыми средствами, типа netcat'а или 
telnet'а.

--
Валентин Бартенев
http://nginx.org/en/donation.html

From vbart at nginx.com  Sun Sep  1 23:08:04 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Mon, 2 Sep 2013 03:08:04 +0400
Subject: true 414 status code
In-Reply-To: <52233E0B.7020001@csdoc.com>
References: <CAMxcU5KYfpL-HzY6nWooFjZx0sFLmKXQYsicqLoddAxVUfA0Ng@mail.gmail.com>
 <201309010057.12473.ne@vbart.ru> <52233E0B.7020001@csdoc.com>
Message-ID: <201309020308.04729.vbart@nginx.com>

On Sunday 01 September 2013 17:15:55 Gena Makhomed wrote:
> On 31.08.2013 23:57, Валентин Бартенев wrote:
> >> Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414
> >> status code, на запросы, размер которых, превышает large_client_header_
> >> buffers?
> >> 
> >> Постоянно получаю 200 http status code и нижеприведенное в body:
> >> 
> >> <html>
> >> <head><title>414 Request-URI Too Large</title></head>
> >> <body bgcolor="white">
> >> <center><h1>414 Request-URI Too Large</h1></center>
> >> <hr><center>nginx/1.2.9</center>
> >> </body>
> >> </html>
> > 
> > Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.
> 
> а есть ли смысл отвечать по протоколу версии HTTP/0.9 ?
> тем более, что запрос в 99.9999999% был версии 1.0 или 1.1
> 
> даже если "Request-URI Too Large" - версию протокола
> запроса можно узнать из строки запроса, при желании.

Нельзя.  В наихудшим случае (а он обязательно наступит)
строка запроса будет бесконечна.

> 
> тем более, что протокол версии 0.9 не умеет прислать
> клиенту ответ в котором будет указан status code 414
> 
> а парсить тело ответа веб-сервера никто не будет,
> различных серверов много и формат ответов разный.

Я согласен, ИМХО имеет лучше откатываться до 1.0, и даже
прислал коллегам соответствующий патч на ревью.

--
Валентин Бартенев
http://nginx.org/en/donation.html

From mdounin at mdounin.ru  Sun Sep  1 23:42:31 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 2 Sep 2013 03:42:31 +0400
Subject: If is Evil
In-Reply-To: <CAK1EO=WJmRTg9-JzG9fLu=zyfX363yYBFtSQOruMQC-DDu-y8Q@mail.gmail.com>
References: <CAK1EO=WJmRTg9-JzG9fLu=zyfX363yYBFtSQOruMQC-DDu-y8Q@mail.gmail.com>
Message-ID: <20130901234231.GI29448@mdounin.ru>

Hello!

On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:

> Приветы всем!
> 
> Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не
> рекомендуется, и что использовать его там можно только в купе с return или
> rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и
> почему.
> 
> Пару рабочих дней было потрачено на то, чтобы разобраться, как оно
> работает. Но в итоге выяснилось, что сишку я уже неприлично подзабыл, а все
> гуглы мира ведут на 3 ссылки:
> 
>     http://wiki.nginx.org/IfIsEvil
>     http://habrahabr.ru/post/74135/
>     http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html
> 
> Но в первой кроме лирики толком ничего не сказано, вторая просто с первого
> же примера плавит мозг, а в последней уже куда по-лучше, примеров
> несколько.. но все одно - какой принцип отработки не ясно(
> 
> Ребят, может кто может подробно и последовательно разжевать, КАК это
> работает? А то пока получалось обходиться без if'ов, но кто его знает, что
> будет завтра.. не хотелось бы оставить новый след от граблей, старый только
> вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем просто
> запомнить постулат "скажем if в location - НЕТ"
> 
> Буду признателен за любые ответы. Спасибо!

В первую голову - надо уяснить для себя, что if создаёт вложенный 
location.  И именно в этом location'е в результате будет обработан 
запрос, если if выполнется.  Если таких if'ов много - то запрос 
будет обработан в последнем if'е, который выполнится.  Поэтому 
конфигурация вида

    location / {
        set $true 1;

        if ($true) {
            add_header X-Foo1 "bar";
        }

        if ($true) {
            add_header X-Foo2 "bar";
        }
    }

добавит только один заголовок, X-Foo2.  Эта особенность - что 
называется, не баг, а фича.

А дальше начинаются костыли, подпорки, и прочие нюансы, связанные, 
в первую очередь, с тем, что if'ы, в отличие от обычных вложенных 
location'ов, пытаются наследовать директивы, которые в норме не 
наследуются во вложенные location'ы (e.g., proxy_pass).  Иногда 
это получается, иногда - получается, но неправильно, иногда - не 
получается вовсе.  Конкретные известные случаи нехорошего 
поведения - коллекционируются на страничке IfIsEvil.

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


From zmey1992 at ya.ru  Mon Sep  2 00:53:03 2013
From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=)
Date: Mon, 02 Sep 2013 04:53:03 +0400
Subject: If is Evil
In-Reply-To: <20130901234231.GI29448@mdounin.ru>
References: <CAK1EO=WJmRTg9-JzG9fLu=zyfX363yYBFtSQOruMQC-DDu-y8Q@mail.gmail.com>
 <20130901234231.GI29448@mdounin.ru>
Message-ID: <83031378083183@web24m.yandex.ru>

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

02.09.2013, 03:42, "Maxim Dounin" <mdounin at mdounin.ru>:
> Hello!
>
> On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:
>
>>  Приветы всем!
>>
>>  Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не
>>  рекомендуется, и что использовать его там можно только в купе с return или
>>  rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и
>>  почему.
>>
>>  Пару рабочих дней было потрачено на то, чтобы разобраться, как оно
>>  работает. Но в итоге выяснилось, что сишку я уже неприлично подзабыл, а все
>>  гуглы мира ведут на 3 ссылки:
>>
>>      http://wiki.nginx.org/IfIsEvil
>>      http://habrahabr.ru/post/74135/
>>      http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html
>>
>>  Но в первой кроме лирики толком ничего не сказано, вторая просто с первого
>>  же примера плавит мозг, а в последней уже куда по-лучше, примеров
>>  несколько.. но все одно - какой принцип отработки не ясно(
>>
>>  Ребят, может кто может подробно и последовательно разжевать, КАК это
>>  работает? А то пока получалось обходиться без if'ов, но кто его знает, что
>>  будет завтра.. не хотелось бы оставить новый след от граблей, старый только
>>  вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем просто
>>  запомнить постулат "скажем if в location - НЕТ"
>>
>>  Буду признателен за любые ответы. Спасибо!
>
> В первую голову - надо уяснить для себя, что if создаёт вложенный
> location.  И именно в этом location'е в результате будет обработан
> запрос, если if выполнется.  Если таких if'ов много - то запрос
> будет обработан в последнем if'е, который выполнится.  Поэтому
> конфигурация вида
>
>     location / {
>         set $true 1;
>
>         if ($true) {
>             add_header X-Foo1 "bar";
>         }
>
>         if ($true) {
>             add_header X-Foo2 "bar";
>         }
>     }
>
> добавит только один заголовок, X-Foo2.  Эта особенность - что
> называется, не баг, а фича.
>
> А дальше начинаются костыли, подпорки, и прочие нюансы, связанные,
> в первую очередь, с тем, что if'ы, в отличие от обычных вложенных
> location'ов, пытаются наследовать директивы, которые в норме не
> наследуются во вложенные location'ы (e.g., proxy_pass).  Иногда
> это получается, иногда - получается, но неправильно, иногда - не
> получается вовсе.  Конкретные известные случаи нехорошего
> поведения - коллекционируются на страничке IfIsEvil.
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From mdounin at mdounin.ru  Mon Sep  2 01:16:01 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 2 Sep 2013 05:16:01 +0400
Subject: =?UTF-8?B?UmU6INCd0LXQv9GA0LDQstC40LvRjNC90YvQtSAo0L7Qs9GA0L7QvNC90YvQtSkg?=
 =?UTF-8?B?0LfQvdCw0YfQtdC90LjRjyAkcmVxdWVzdCB0aW1lINC00LvRjyBGYXN0Q0dJ?=
 =?UTF-8?B?LdC30LDQv9GA0L7RgdC+0LI=?=
In-Reply-To: <1d54207dc6d79255cd917f2d6c71a08e.NginxMailingListRussian@forum.nginx.org>
References: <5501669a502645a63199fab569d61e70.NginxMailingListRussian@forum.nginx.org>
 <1d54207dc6d79255cd917f2d6c71a08e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130902011601.GL29448@mdounin.ru>

Hello!

On Sat, Aug 31, 2013 at 04:50:28PM -0400, sofiamay wrote:

> А что, за год баг так и не исправили? Разрабы даже не удосужились здесь
> отписаться? Баг хотябы в багтрекере висит?
> Подтверждаю, у меня тоже $request_time выдаёт бред:
> 
> 240648971536.2381542
> 240648971536.2381542
> 240648971536.2381542
> 240648971536.2381542
> 240648971536.2381542
> 
> Одно и то же для многих запросов подряд, потом опять на другой бред меняет!
> Когда это исправят? Зачем в Nginx сделана переменная $request_time если она
> показывает всякий бред, мне думается её нужно убрать, а через несколько лет,
> когда разрабы соизволят исправить баг, вернуть. Пока же от неё больше вреда
> чем пользы. 
> 
> P.S. Использую Windows и PHP как FastCGI. 

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

Впрочем, патч:

diff -r 683283f8b5fd src/http/modules/ngx_http_log_module.c
--- a/src/http/modules/ngx_http_log_module.c	Thu Aug 29 20:39:13 2013 +0400
+++ b/src/http/modules/ngx_http_log_module.c	Mon Sep 02 04:38:34 2013 +0400
@@ -780,7 +780,7 @@ ngx_http_log_request_time(ngx_http_reque
              ((tp->sec - r->start_sec) * 1000 + (tp->msec - r->start_msec));
     ms = ngx_max(ms, 0);
 
-    return ngx_sprintf(buf, "%T.%03M", ms / 1000, ms % 1000);
+    return ngx_sprintf(buf, "%T.%03M", (time_t) ms / 1000, ms % 1000);
 }
 
 
diff -r 683283f8b5fd src/http/ngx_http_variables.c
--- a/src/http/ngx_http_variables.c	Thu Aug 29 20:39:13 2013 +0400
+++ b/src/http/ngx_http_variables.c	Mon Sep 02 04:38:34 2013 +0400
@@ -1992,7 +1992,7 @@ ngx_http_variable_request_time(ngx_http_
              ((tp->sec - r->start_sec) * 1000 + (tp->msec - r->start_msec));
     ms = ngx_max(ms, 0);
 
-    v->len = ngx_sprintf(p, "%T.%03M", ms / 1000, ms % 1000) - p;
+    v->len = ngx_sprintf(p, "%T.%03M", (time_t) ms / 1000, ms % 1000) - p;
     v->valid = 1;
     v->no_cacheable = 0;
     v->not_found = 0;

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


From mdounin at mdounin.ru  Mon Sep  2 01:40:01 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 2 Sep 2013 05:40:01 +0400
Subject: If is Evil
In-Reply-To: <83031378083183@web24m.yandex.ru>
References: <CAK1EO=WJmRTg9-JzG9fLu=zyfX363yYBFtSQOruMQC-DDu-y8Q@mail.gmail.com>
 <20130901234231.GI29448@mdounin.ru>
 <83031378083183@web24m.yandex.ru>
Message-ID: <20130902014001.GN29448@mdounin.ru>

Hello!

On Mon, Sep 02, 2013 at 04:53:03AM +0400, Васильев "Zmey!" Олег wrote:

> Попытаюсь вклиниться в тему. Есть давно волнующий вопрос как раз 
> на ряду с этими if-ами. Есть какой-то список директив, которые 
> наследуются (или не наследуются) в location-ах из уровня выше и 
> такой же для if-ов? Был бы крайне полезный материал, т.к. в 
> голове всё удержать не выходит.

Наследуется всё, кроме отдельных директив.  Не наследуются - 
инструкции модуля rewrite (if, set, break, return, rewrite), 
директивы, устанавливающие обработчики (proxy_pass и остальные 
*_pass, empty_gif, stub_status, perl, mp4, flv), и директива 
try_files.

Внуть if'ов, в теории, должно наследоваться всё.  По факту - см.  
http://wiki.nginx.org/IfIsEvil, как минимум с proxy_pass, 
try_files и alias - в некоторых случаях есть проблемы.

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


From vbart at nginx.com  Mon Sep  2 04:00:09 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Mon, 2 Sep 2013 08:00:09 +0400
Subject: true 414 status code
In-Reply-To: <52233E0B.7020001@csdoc.com>
References: <CAMxcU5KYfpL-HzY6nWooFjZx0sFLmKXQYsicqLoddAxVUfA0Ng@mail.gmail.com>
 <201309010057.12473.ne@vbart.ru> <52233E0B.7020001@csdoc.com>
Message-ID: <201309020800.09622.vbart@nginx.com>

On Sunday 01 September 2013 17:15:55 Gena Makhomed wrote:
> On 31.08.2013 23:57, Валентин Бартенев wrote:
> >> Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414
> >> status code, на запросы, размер которых, превышает large_client_header_
> >> buffers?
> >> 
> >> Постоянно получаю 200 http status code и нижеприведенное в body:
> >> 
> >> <html>
> >> <head><title>414 Request-URI Too Large</title></head>
> >> <body bgcolor="white">
> >> <center><h1>414 Request-URI Too Large</h1></center>
> >> <hr><center>nginx/1.2.9</center>
> >> </body>
> >> </html>
> > 
> > Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.
> 
> а есть ли смысл отвечать по протоколу версии HTTP/0.9 ?
> тем более, что запрос в 99.9999999% был версии 1.0 или 1.1
> 
> даже если "Request-URI Too Large" - версию протокола
> запроса можно узнать из строки запроса, при желании.
> 
> тем более, что протокол версии 0.9 не умеет прислать
> клиенту ответ в котором будет указан status code 414
> 
> а парсить тело ответа веб-сервера никто не будет,
> различных серверов много и формат ответов разный.

JFYI, http://hg.nginx.org/nginx/rev/62be77b0608f

--
Валентин Бартенев
http://nginx.org/en/donation.html

From mva at mva.name  Mon Sep  2 08:12:48 2013
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Mon, 02 Sep 2013 15:12:48 +0700
Subject: udp support
Message-ID: <52244880.4080500@mva.name>

Всем привет! :)
Я тут немного поковырялся в /etc/services и в
/usr/share/nmap/nmap-services и обнаружил, что есть такая штука, как

8008/tcp http-alt
8008/udp http-alt

В связи с этим стало интересно: в NgX нет (?) поддержки UDP по каким-то
причинам, или просто потому что не было нужды? :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130902/f5db32e3/attachment.bin>

From alex.hha at gmail.com  Mon Sep  2 08:21:15 2013
From: alex.hha at gmail.com (Alex Domoradov)
Date: Mon, 2 Sep 2013 11:21:15 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQv9GA0LDQstC40LvRjNC90YvQtSAo0L7Qs9GA0L7QvNC90YvQtSkg?=
 =?UTF-8?B?0LfQvdCw0YfQtdC90LjRjyAkcmVxdWVzdCB0aW1lINC00LvRjyBGYXN0Q0dJ?=
 =?UTF-8?B?LdC30LDQv9GA0L7RgdC+0LI=?=
In-Reply-To: <20130902011601.GL29448@mdounin.ru>
References: <5501669a502645a63199fab569d61e70.NginxMailingListRussian@forum.nginx.org>
 <1d54207dc6d79255cd917f2d6c71a08e.NginxMailingListRussian@forum.nginx.org>
 <20130902011601.GL29448@mdounin.ru>
Message-ID: <CAK90gp7vGKKVdwW8+KdykKZs6SO1AqmSRBtUTXx9Ug=7w4g47g@mail.gmail.com>

> Я даже и не знаю, что вам сказать
русская халява - она такая

2013/9/2 Maxim Dounin <mdounin at mdounin.ru>:
> Hello!
>
> On Sat, Aug 31, 2013 at 04:50:28PM -0400, sofiamay wrote:
>
>> А что, за год баг так и не исправили? Разрабы даже не удосужились здесь
>> отписаться? Баг хотябы в багтрекере висит?
>> Подтверждаю, у меня тоже $request_time выдаёт бред:
>>
>> 240648971536.2381542
>> 240648971536.2381542
>> 240648971536.2381542
>> 240648971536.2381542
>> 240648971536.2381542
>>
>> Одно и то же для многих запросов подряд, потом опять на другой бред меняет!
>> Когда это исправят? Зачем в Nginx сделана переменная $request_time если она
>> показывает всякий бред, мне думается её нужно убрать, а через несколько лет,
>> когда разрабы соизволят исправить баг, вернуть. Пока же от неё больше вреда
>> чем пользы.
>>
>> P.S. Использую Windows и PHP как FastCGI.
>
> Я даже и не знаю, что вам сказать.  Привыкайте - это open source.
> Тут вам никто ничего не должен, и править вылезающие у вас баги -
> вам.  Надеяться, что кто-то придёт, и за вас исправит, тем более
> на Windows - по меньшей мере наивно.
>
> Впрочем, патч:
>
> diff -r 683283f8b5fd src/http/modules/ngx_http_log_module.c
> --- a/src/http/modules/ngx_http_log_module.c    Thu Aug 29 20:39:13 2013 +0400
> +++ b/src/http/modules/ngx_http_log_module.c    Mon Sep 02 04:38:34 2013 +0400
> @@ -780,7 +780,7 @@ ngx_http_log_request_time(ngx_http_reque
>               ((tp->sec - r->start_sec) * 1000 + (tp->msec - r->start_msec));
>      ms = ngx_max(ms, 0);
>
> -    return ngx_sprintf(buf, "%T.%03M", ms / 1000, ms % 1000);
> +    return ngx_sprintf(buf, "%T.%03M", (time_t) ms / 1000, ms % 1000);
>  }
>
>
> diff -r 683283f8b5fd src/http/ngx_http_variables.c
> --- a/src/http/ngx_http_variables.c     Thu Aug 29 20:39:13 2013 +0400
> +++ b/src/http/ngx_http_variables.c     Mon Sep 02 04:38:34 2013 +0400
> @@ -1992,7 +1992,7 @@ ngx_http_variable_request_time(ngx_http_
>               ((tp->sec - r->start_sec) * 1000 + (tp->msec - r->start_msec));
>      ms = ngx_max(ms, 0);
>
> -    v->len = ngx_sprintf(p, "%T.%03M", ms / 1000, ms % 1000) - p;
> +    v->len = ngx_sprintf(p, "%T.%03M", (time_t) ms / 1000, ms % 1000) - p;
>      v->valid = 1;
>      v->no_cacheable = 0;
>      v->not_found = 0;
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From chipitsine at gmail.com  Mon Sep  2 08:27:13 2013
From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=)
Date: Mon, 2 Sep 2013 15:27:13 +0700
Subject: udp support
In-Reply-To: <52244880.4080500@mva.name>
References: <52244880.4080500@mva.name>
Message-ID: <CAFHpkQHF7kXt4xbhubk_b+rs9GViouxnLB2v7PSPBu4rSwp8_A@mail.gmail.com>

много всяких модных штук придумано, например, вот
http://en.wikipedia.org/wiki/QUIC

"двигатель" в данном вопросе всего один - клиентские каналы низкого
качества (у tcp оверхед выше, на некачественных каналах это заметно),
просто с ровного места никто не разбежится реализовывать новые
протоколы, если всё вполне приемлимо работает на http/1.1

2 сентября 2013 г., 15:12 пользователь Vadim A. Misbakh-Soloviov
<mva at mva.name> написал:
> Всем привет! :)
> Я тут немного поковырялся в /etc/services и в
> /usr/share/nmap/nmap-services и обнаружил, что есть такая штука, как
>
> 8008/tcp http-alt
> 8008/udp http-alt
>
> В связи с этим стало интересно: в NgX нет (?) поддержки UDP по каким-то
> причинам, или просто потому что не было нужды? :)
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From andrei.seredenko at gmail.com  Mon Sep  2 08:38:22 2013
From: andrei.seredenko at gmail.com (=?KOI8-R?B?4c7E0sXKIPPF0sXExc7Lzw==?=)
Date: Mon, 2 Sep 2013 11:38:22 +0300
Subject: nginx-ru Digest, Vol 47, Issue 4
In-Reply-To: <mailman.2359.1378084565.22071.nginx-ru@nginx.org>
References: <mailman.2359.1378084565.22071.nginx-ru@nginx.org>
Message-ID: <CAK1EO=UASpmRMd9U5Ze7M1uQPPN3MYi_C599c6i1bQ5XAPZZSw@mail.gmail.com>

В таком случае, если отрабатывает только последний из if'ов - то в данной
конфигурации:

 location ~* /test/url/Page.asmx {
            proxy_pass         http://test_upstream;
            proxy_redirect     off;
            proxy_set_header   Host             $host;
            proxy_set_header   Remote-Addr      $remote_addr;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
            proxy_set_header   X-Public-Url     http://$host$request_uri;
            ...
            some other proxy options
            ...
            #
            set $my_ipsrc 0;
            # allow 10.10.1.75/32;
            if ($remote_addr = 10.10.1.75) { set $my_ipsrc 1; }
            # allow 10.20.1.20/32;
            if ($remote_addr = 10.20.1.20) { set $my_ipsrc 1; }
            # allow 10.20.1.21/32;
            if ($remote_addr = 10.20.1.21) { set $my_ipsrc 1; }
            # allow 10.100.1.0/24;
            if ($remote_addr = 10.100.1.0/24) { set $my_ipsrc 1; }
            # allow 178.111.122.133/32;
            if ($remote_addr = 178.111.122.133) { set $my_ipsrc 1; }
            # deny all;
            if ($my_ipsrc = 0) { return 500; }
       }

всем, кроме последнего адреса, должно возвращаться "500" ?
или лыжи не едут? :)


2 сентября 2013 г., 4:16 пользователь <nginx-ru-request at nginx.org> написал:

> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
> отправлять по адресу
>         nginx-ru at nginx.org
>
> Для изменения параметров подписки вы можеже использовать веб-страницу
>         http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> Для получения информации о том, как пользовать почтовым интерфейсом,
> отправьте письмо, в теле или теме которого будет слово 'help', по
> адресу:
>         nginx-ru-request at nginx.org
>
> Адрес человека, ответственного за этот список рассылки:
>         nginx-ru-owner at nginx.org
>
> При ответе, пожалуйста, измение тему письма так, чтобы она была более
> содержательной чем "Re: Содержание дайджеста списка рассылки
> nginx-ru..."
>
> Today's Topics:
>
>    1. Re: true 414 status code (Vladimir Getmanshchuk)
>    2. Re: 400 Bad Request 1.5.4 (1.5.3 = OK) (locojohn)
>    3. Re: If is Evil (Daniel Podolsky)
>    4. Re: true 414 status code (Валентин Бартенев)
>    5. Re: true 414 status code (Валентин Бартенев)
>    6. Re: If is Evil (Maxim Dounin)
>    7. Re: If is Evil (Васильев Zmey! Олег)
>    8. Re: Неправильные (огромные) значения $request time для
>       FastCGI-запросов (Maxim Dounin)
>
>
> ---------- Пересылаемое сообщение ----------
> From: Vladimir Getmanshchuk <vladget at gmail.com>
> To: nginx-ru at nginx.org
> Cc:
> Date: Sun, 1 Sep 2013 23:33:57 +0300
> Subject: Re: true 414 status code
> Амм... Спасибо за скорость и лаконичность.
>
> Судя по http://www.w3.org/Protocols/HTTP/HTRESP.html, в HTTP/0.9 тоже
> есть status codes, или я что то недопонимаю?
> Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"
>
>
>
>
> 2013/8/31 Валентин Бартенев <ne at vbart.ru>
>
>> On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote:
>> > Здравствуйте!
>> >
>> > Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414
>> > status code, на запросы, размер которых, превышает large_client_header_
>> > buffers?
>> >
>> > Постоянно получаю 200 http status code и нижеприведенное в body:
>> >
>> > <html>
>> > <head><title>414 Request-URI Too Large</title></head>
>> > <body bgcolor="white">
>> > <center><h1>414 Request-URI Too Large</h1></center>
>> > <hr><center>nginx/1.2.9</center>
>> > </body>
>> > </html>
>>
>> Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.
>>
>> --
>> Валентин Бартенев
>> http://nginx.org/en/donation.html
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> --
> Yours sincerely,
> Vladimir Getmanshchuk
>
>
> ---------- Пересылаемое сообщение ----------
> From: "locojohn" <nginx-forum at nginx.us>
> To: nginx-ru at nginx.org
> Cc:
> Date: Sun, 01 Sep 2013 16:44:45 -0400
> Subject: Re: 400 Bad Request 1.5.4 (1.5.3 = OK)
> Oleksandr V. Typlyns'kyi Wrote:
>
> >   Как видно из кода стороннего модуля(а туда тоже следовало бы
> > посмотреть),
> >   там несколько return NGX_HTTP_BAD_REQUEST без записи чего-либо в лог
> > ошибок.
> >   И они явно намекают на content type который теперь
> > application/javascript.
> >   Добавление его в concat_types должно помочь.
>
> Спасибо за отличный хинт!  Добавление "application/javascript" в
> concat_types не помогло, пришлось подпатчить исходный модуль concat:
>
> --- ngx_http_concat_module.c
> +++ ngx_http_concat_module.c
> @@ -30,7 +30,7 @@
>
>
>  static ngx_str_t  ngx_http_concat_default_types[] = {
> -    ngx_string("application/x-javascript"),
> +    ngx_string("application/javascript"),
>      ngx_string("text/css"),
>      ngx_null_string
>  };
>
> Ещё раз - спасибо!
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,242399,242424#msg-242424
>
>
>
>
> ---------- Пересылаемое сообщение ----------
> From: Daniel Podolsky <onokonem at gmail.com>
> To: nginx-ru <nginx-ru at nginx.org>
> Cc:
> Date: Mon, 2 Sep 2013 00:47:34 +0400
> Subject: Re: If is Evil
> > да и выяснить причину раз и навсегда куда полезнее, чем просто запомнить
> > постулат "скажем if в location - НЕТ"
> А мы им не скажем НЕТ. Мы просто помним, что для if создается скрытый
> location, и что туда наследуется, а что нет, и какая там в результате
> будет конфигурациия - ни за что не прописаешь, как говорили в школе.
>
> Поэтому мы пользуемся if, но только одним образом - делаем на нем
> переадресацию в именованный локейшн.
>
> Отдельно, конечно, смешно то, что это единственный разумный способ
> пользоваться if, но директивы переадресации как не было, так и нет, и
> приходится писать что-то вроде if (condition) { error_page 418 =
> @location; return 418; }
>
>
> ---------- Пересылаемое сообщение ----------
> From: "Валентин Бартенев" <vbart at nginx.com>
> To: nginx-ru at nginx.org
> Cc:
> Date: Mon, 2 Sep 2013 03:02:45 +0400
> Subject: Re: true 414 status code
> On Monday 02 September 2013 00:33:57 Vladimir Getmanshchuk wrote:
> > Амм... Спасибо за скорость и лаконичность.
> >
> > Судя по http://www.w3.org/Protocols/HTTP/HTRESP.html, в HTTP/0.9 тоже
> есть
> > status codes, или я что то недопонимаю?
>
> Вы ссылаетесь на спецификацию HTTP/1.0.  В HTTP/0.9 у ответа не было
> заголовка:
> http://www.w3.org/Protocols/HTTP/AsImplemented.html
> http://www.w3.org/DesignIssues/HTTP0.9Summary.html
>
>
> > Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"
>
> Сам дописывает видимо.  Смотрите более простыми средствами, типа netcat'а
> или
> telnet'а.
>
> --
> Валентин Бартенев
> http://nginx.org/en/donation.html
>
>
> ---------- Пересылаемое сообщение ----------
> From: "Валентин Бартенев" <vbart at nginx.com>
> To: nginx-ru at nginx.org
> Cc:
> Date: Mon, 2 Sep 2013 03:08:04 +0400
> Subject: Re: true 414 status code
> On Sunday 01 September 2013 17:15:55 Gena Makhomed wrote:
> > On 31.08.2013 23:57, Валентин Бартенев wrote:
> > >> Подскажите пожалуйста, а как без "грязных хаков" получить от nginx,
> 414
> > >> status code, на запросы, размер которых, превышает
> large_client_header_
> > >> buffers?
> > >>
> > >> Постоянно получаю 200 http status code и нижеприведенное в body:
> > >>
> > >> <html>
> > >> <head><title>414 Request-URI Too Large</title></head>
> > >> <body bgcolor="white">
> > >> <center><h1>414 Request-URI Too Large</h1></center>
> > >> <hr><center>nginx/1.2.9</center>
> > >> </body>
> > >> </html>
> > >
> > > Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.
> >
> > а есть ли смысл отвечать по протоколу версии HTTP/0.9 ?
> > тем более, что запрос в 99.9999999% был версии 1.0 или 1.1
> >
> > даже если "Request-URI Too Large" - версию протокола
> > запроса можно узнать из строки запроса, при желании.
>
> Нельзя.  В наихудшим случае (а он обязательно наступит)
> строка запроса будет бесконечна.
>
> >
> > тем более, что протокол версии 0.9 не умеет прислать
> > клиенту ответ в котором будет указан status code 414
> >
> > а парсить тело ответа веб-сервера никто не будет,
> > различных серверов много и формат ответов разный.
>
> Я согласен, ИМХО имеет лучше откатываться до 1.0, и даже
> прислал коллегам соответствующий патч на ревью.
>
> --
> Валентин Бартенев
> http://nginx.org/en/donation.html
>
>
> ---------- Пересылаемое сообщение ----------
> From: Maxim Dounin <mdounin at mdounin.ru>
> To: nginx-ru at nginx.org
> Cc:
> Date: Mon, 2 Sep 2013 03:42:31 +0400
> Subject: Re: If is Evil
> Hello!
>
> On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:
>
> > Приветы всем!
> >
> > Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не
> > рекомендуется, и что использовать его там можно только в купе с return
> или
> > rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и
> > почему.
> >
> > Пару рабочих дней было потрачено на то, чтобы разобраться, как оно
> > работает. Но в итоге выяснилось, что сишку я уже неприлично подзабыл, а
> все
> > гуглы мира ведут на 3 ссылки:
> >
> >     http://wiki.nginx.org/IfIsEvil
> >     http://habrahabr.ru/post/74135/
> >     http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html
> >
> > Но в первой кроме лирики толком ничего не сказано, вторая просто с
> первого
> > же примера плавит мозг, а в последней уже куда по-лучше, примеров
> > несколько.. но все одно - какой принцип отработки не ясно(
> >
> > Ребят, может кто может подробно и последовательно разжевать, КАК это
> > работает? А то пока получалось обходиться без if'ов, но кто его знает,
> что
> > будет завтра.. не хотелось бы оставить новый след от граблей, старый
> только
> > вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем
> просто
> > запомнить постулат "скажем if в location - НЕТ"
> >
> > Буду признателен за любые ответы. Спасибо!
>
> В первую голову - надо уяснить для себя, что if создаёт вложенный
> location.  И именно в этом location'е в результате будет обработан
> запрос, если if выполнется.  Если таких if'ов много - то запрос
> будет обработан в последнем if'е, который выполнится.  Поэтому
> конфигурация вида
>
>     location / {
>         set $true 1;
>
>         if ($true) {
>             add_header X-Foo1 "bar";
>         }
>
>         if ($true) {
>             add_header X-Foo2 "bar";
>         }
>     }
>
> добавит только один заголовок, X-Foo2.  Эта особенность - что
> называется, не баг, а фича.
>
> А дальше начинаются костыли, подпорки, и прочие нюансы, связанные,
> в первую очередь, с тем, что if'ы, в отличие от обычных вложенных
> location'ов, пытаются наследовать директивы, которые в норме не
> наследуются во вложенные location'ы (e.g., proxy_pass).  Иногда
> это получается, иногда - получается, но неправильно, иногда - не
> получается вовсе.  Конкретные известные случаи нехорошего
> поведения - коллекционируются на страничке IfIsEvil.
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
>
>
>
> ---------- Пересылаемое сообщение ----------
> From: "Васильев \"Zmey!\" Олег" <zmey1992 at ya.ru>
> To: "nginx-ru at nginx.org" <nginx-ru at nginx.org>
> Cc:
> Date: Mon, 02 Sep 2013 04:53:03 +0400
> Subject: Re: If is Evil
> Попытаюсь вклиниться в тему. Есть давно волнующий вопрос как раз на ряду с
> этими if-ами. Есть какой-то список директив, которые наследуются (или не
> наследуются) в location-ах из уровня выше и такой же для if-ов? Был бы
> крайне полезный материал, т.к. в голове всё удержать не выходит.
>
> 02.09.2013, 03:42, "Maxim Dounin" <mdounin at mdounin.ru>:
> > Hello!
> >
> > On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:
> >
> >>  Приветы всем!
> >>
> >>  Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не
> >>  рекомендуется, и что использовать его там можно только в купе с return
> или
> >>  rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и
> >>  почему.
> >>
> >>  Пару рабочих дней было потрачено на то, чтобы разобраться, как оно
> >>  работает. Но в итоге выяснилось, что сишку я уже неприлично подзабыл,
> а все
> >>  гуглы мира ведут на 3 ссылки:
> >>
> >>      http://wiki.nginx.org/IfIsEvil
> >>      http://habrahabr.ru/post/74135/
> >>
> http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html
> >>
> >>  Но в первой кроме лирики толком ничего не сказано, вторая просто с
> первого
> >>  же примера плавит мозг, а в последней уже куда по-лучше, примеров
> >>  несколько.. но все одно - какой принцип отработки не ясно(
> >>
> >>  Ребят, может кто может подробно и последовательно разжевать, КАК это
> >>  работает? А то пока получалось обходиться без if'ов, но кто его знает,
> что
> >>  будет завтра.. не хотелось бы оставить новый след от граблей, старый
> только
> >>  вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем
> просто
> >>  запомнить постулат "скажем if в location - НЕТ"
> >>
> >>  Буду признателен за любые ответы. Спасибо!
> >
> > В первую голову - надо уяснить для себя, что if создаёт вложенный
> > location.  И именно в этом location'е в результате будет обработан
> > запрос, если if выполнется.  Если таких if'ов много - то запрос
> > будет обработан в последнем if'е, который выполнится.  Поэтому
> > конфигурация вида
> >
> >     location / {
> >         set $true 1;
> >
> >         if ($true) {
> >             add_header X-Foo1 "bar";
> >         }
> >
> >         if ($true) {
> >             add_header X-Foo2 "bar";
> >         }
> >     }
> >
> > добавит только один заголовок, X-Foo2.  Эта особенность - что
> > называется, не баг, а фича.
> >
> > А дальше начинаются костыли, подпорки, и прочие нюансы, связанные,
> > в первую очередь, с тем, что if'ы, в отличие от обычных вложенных
> > location'ов, пытаются наследовать директивы, которые в норме не
> > наследуются во вложенные location'ы (e.g., proxy_pass).  Иногда
> > это получается, иногда - получается, но неправильно, иногда - не
> > получается вовсе.  Конкретные известные случаи нехорошего
> > поведения - коллекционируются на страничке IfIsEvil.
> >
> > --
> > Maxim Dounin
> > http://nginx.org/en/donation.html
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> ---------- Пересылаемое сообщение ----------
> From: Maxim Dounin <mdounin at mdounin.ru>
> To: nginx-ru at nginx.org
> Cc:
> Date: Mon, 2 Sep 2013 05:16:01 +0400
> Subject: Re: Неправильные (огромные) значения $request time для
> FastCGI-запросов
> Hello!
>
> On Sat, Aug 31, 2013 at 04:50:28PM -0400, sofiamay wrote:
>
> > А что, за год баг так и не исправили? Разрабы даже не удосужились здесь
> > отписаться? Баг хотябы в багтрекере висит?
> > Подтверждаю, у меня тоже $request_time выдаёт бред:
> >
> > 240648971536.2381542
> > 240648971536.2381542
> > 240648971536.2381542
> > 240648971536.2381542
> > 240648971536.2381542
> >
> > Одно и то же для многих запросов подряд, потом опять на другой бред
> меняет!
> > Когда это исправят? Зачем в Nginx сделана переменная $request_time если
> она
> > показывает всякий бред, мне думается её нужно убрать, а через несколько
> лет,
> > когда разрабы соизволят исправить баг, вернуть. Пока же от неё больше
> вреда
> > чем пользы.
> >
> > P.S. Использую Windows и PHP как FastCGI.
>
> Я даже и не знаю, что вам сказать.  Привыкайте - это open source.
> Тут вам никто ничего не должен, и править вылезающие у вас баги -
> вам.  Надеяться, что кто-то придёт, и за вас исправит, тем более
> на Windows - по меньшей мере наивно.
>
> Впрочем, патч:
>
> diff -r 683283f8b5fd src/http/modules/ngx_http_log_module.c
> --- a/src/http/modules/ngx_http_log_module.c    Thu Aug 29 20:39:13 2013
> +0400
> +++ b/src/http/modules/ngx_http_log_module.c    Mon Sep 02 04:38:34 2013
> +0400
> @@ -780,7 +780,7 @@ ngx_http_log_request_time(ngx_http_reque
>               ((tp->sec - r->start_sec) * 1000 + (tp->msec -
> r->start_msec));
>      ms = ngx_max(ms, 0);
>
> -    return ngx_sprintf(buf, "%T.%03M", ms / 1000, ms % 1000);
> +    return ngx_sprintf(buf, "%T.%03M", (time_t) ms / 1000, ms % 1000);
>  }
>
>
> diff -r 683283f8b5fd src/http/ngx_http_variables.c
> --- a/src/http/ngx_http_variables.c     Thu Aug 29 20:39:13 2013 +0400
> +++ b/src/http/ngx_http_variables.c     Mon Sep 02 04:38:34 2013 +0400
> @@ -1992,7 +1992,7 @@ ngx_http_variable_request_time(ngx_http_
>               ((tp->sec - r->start_sec) * 1000 + (tp->msec -
> r->start_msec));
>      ms = ngx_max(ms, 0);
>
> -    v->len = ngx_sprintf(p, "%T.%03M", ms / 1000, ms % 1000) - p;
> +    v->len = ngx_sprintf(p, "%T.%03M", (time_t) ms / 1000, ms % 1000) - p;
>      v->valid = 1;
>      v->no_cacheable = 0;
>      v->not_found = 0;
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130902/bdeb0e0f/attachment-0001.html>

From nginx-forum at nginx.us  Mon Sep  2 09:33:19 2013
From: nginx-forum at nginx.us (DenisM)
Date: Mon, 02 Sep 2013 05:33:19 -0400
Subject: =?UTF-8?B?NTAyINGD0YHRgtGD0L/QuNC70Lgg0LzQtdGB0YLQviA1MDQ=?=
Message-ID: <9c47c4dfa6bab5da021609b44575dc11.NginxMailingListRussian@forum.nginx.org>

Привет.
После включения кеша fastcgi ошибки 502 сменились на 504. Это ожидаемое
поведение?

    fastcgi_cache_path /var/cache/nginx
        levels=2
        keys_zone=NAME:50m
        max_size=1024m
        inactive=5m;
    fastcgi_temp_path /var/cache/nginx/fastcgi_temp;
    fastcgi_cache_key
$cookie_uid|$scheme|$request_method|$host|$request_uri";
    fastcgi_cache_methods GET HEAD;
    map $request_uri $no_cache {
        default 1;
        ~/gsa/index 0;
        ~/product/ 0;
    }
    fastcgi_no_cache $no_cache;
    fastcgi_cache_bypass $no_cache;

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


From alexander.moskalenko at gmail.com  Mon Sep  2 09:44:08 2013
From: alexander.moskalenko at gmail.com (Alexander Moskalenko)
Date: Mon, 2 Sep 2013 12:44:08 +0300
Subject: nginx-ru Digest, Vol 47, Issue 4
In-Reply-To: <CAK1EO=UASpmRMd9U5Ze7M1uQPPN3MYi_C599c6i1bQ5XAPZZSw@mail.gmail.com>
References: <mailman.2359.1378084565.22071.nginx-ru@nginx.org>
 <CAK1EO=UASpmRMd9U5Ze7M1uQPPN3MYi_C599c6i1bQ5XAPZZSw@mail.gmail.com>
Message-ID: <CACVfVFu7EbTTr7kFZ4do90rJFgPuizso1K8B-TjiqsRrgcRVXQ@mail.gmail.com>

В данной конфигурации нужно выкинуть все if и сделать map + if.
Либо использовать allow+deny, как это обычно делают.

2013/9/2 Андрей Середенко <andrei.seredenko at gmail.com>:
> В таком случае, если отрабатывает только последний из if'ов - то в данной
> конфигурации:
>
>  location ~* /test/url/Page.asmx {
>             proxy_pass         http://test_upstream;
>             proxy_redirect     off;
>             proxy_set_header   Host             $host;
>             proxy_set_header   Remote-Addr      $remote_addr;
>             proxy_set_header   X-Real-IP        $remote_addr;
>             proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
>             proxy_set_header   X-Public-Url     http://$host$request_uri;
>             ...
>             some other proxy options
>             ...
>             #
>             set $my_ipsrc 0;
>             # allow 10.10.1.75/32;
>             if ($remote_addr = 10.10.1.75) { set $my_ipsrc 1; }
>             # allow 10.20.1.20/32;
>             if ($remote_addr = 10.20.1.20) { set $my_ipsrc 1; }
>             # allow 10.20.1.21/32;
>             if ($remote_addr = 10.20.1.21) { set $my_ipsrc 1; }
>             # allow 10.100.1.0/24;
>             if ($remote_addr = 10.100.1.0/24) { set $my_ipsrc 1; }
>             # allow 178.111.122.133/32;
>             if ($remote_addr = 178.111.122.133) { set $my_ipsrc 1; }
>             # deny all;
>             if ($my_ipsrc = 0) { return 500; }
>        }
>
> всем, кроме последнего адреса, должно возвращаться "500" ?
> или лыжи не едут? :)
>
>
> 2 сентября 2013 г., 4:16 пользователь <nginx-ru-request at nginx.org> написал:
>>
>> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
>> отправлять по адресу
>>         nginx-ru at nginx.org
>>
>> Для изменения параметров подписки вы можеже использовать веб-страницу
>>         http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>> Для получения информации о том, как пользовать почтовым интерфейсом,
>> отправьте письмо, в теле или теме которого будет слово 'help', по
>> адресу:
>>         nginx-ru-request at nginx.org
>>
>> Адрес человека, ответственного за этот список рассылки:
>>         nginx-ru-owner at nginx.org
>>
>> При ответе, пожалуйста, измение тему письма так, чтобы она была более
>> содержательной чем "Re: Содержание дайджеста списка рассылки
>> nginx-ru..."
>>
>> Today's Topics:
>>
>>    1. Re: true 414 status code (Vladimir Getmanshchuk)
>>    2. Re: 400 Bad Request 1.5.4 (1.5.3 = OK) (locojohn)
>>    3. Re: If is Evil (Daniel Podolsky)
>>    4. Re: true 414 status code (Валентин Бартенев)
>>    5. Re: true 414 status code (Валентин Бартенев)
>>    6. Re: If is Evil (Maxim Dounin)
>>    7. Re: If is Evil (Васильев Zmey! Олег)
>>    8. Re: Неправильные (огромные) значения $request time для
>>       FastCGI-запросов (Maxim Dounin)
>>
>>
>> ---------- Пересылаемое сообщение ----------
>> From: Vladimir Getmanshchuk <vladget at gmail.com>
>> To: nginx-ru at nginx.org
>> Cc:
>> Date: Sun, 1 Sep 2013 23:33:57 +0300
>> Subject: Re: true 414 status code
>> Амм... Спасибо за скорость и лаконичность.
>>
>> Судя по http://www.w3.org/Protocols/HTTP/HTRESP.html, в HTTP/0.9 тоже есть
>> status codes, или я что то недопонимаю?
>> Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"
>>
>>
>>
>>
>> 2013/8/31 Валентин Бартенев <ne at vbart.ru>
>>>
>>> On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote:
>>> > Здравствуйте!
>>> >
>>> > Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414
>>> > status code, на запросы, размер которых, превышает large_client_header_
>>> > buffers?
>>> >
>>> > Постоянно получаю 200 http status code и нижеприведенное в body:
>>> >
>>> > <html>
>>> > <head><title>414 Request-URI Too Large</title></head>
>>> > <body bgcolor="white">
>>> > <center><h1>414 Request-URI Too Large</h1></center>
>>> > <hr><center>nginx/1.2.9</center>
>>> > </body>
>>> > </html>
>>>
>>> Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.
>>>
>>> --
>>> Валентин Бартенев
>>> http://nginx.org/en/donation.html
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>>
>>
>>
>> --
>> Yours sincerely,
>> Vladimir Getmanshchuk
>>
>>
>> ---------- Пересылаемое сообщение ----------
>> From: "locojohn" <nginx-forum at nginx.us>
>> To: nginx-ru at nginx.org
>> Cc:
>> Date: Sun, 01 Sep 2013 16:44:45 -0400
>> Subject: Re: 400 Bad Request 1.5.4 (1.5.3 = OK)
>> Oleksandr V. Typlyns'kyi Wrote:
>>
>> >   Как видно из кода стороннего модуля(а туда тоже следовало бы
>> > посмотреть),
>> >   там несколько return NGX_HTTP_BAD_REQUEST без записи чего-либо в лог
>> > ошибок.
>> >   И они явно намекают на content type который теперь
>> > application/javascript.
>> >   Добавление его в concat_types должно помочь.
>>
>> Спасибо за отличный хинт!  Добавление "application/javascript" в
>> concat_types не помогло, пришлось подпатчить исходный модуль concat:
>>
>> --- ngx_http_concat_module.c
>> +++ ngx_http_concat_module.c
>> @@ -30,7 +30,7 @@
>>
>>
>>  static ngx_str_t  ngx_http_concat_default_types[] = {
>> -    ngx_string("application/x-javascript"),
>> +    ngx_string("application/javascript"),
>>      ngx_string("text/css"),
>>      ngx_null_string
>>  };
>>
>> Ещё раз - спасибо!
>>
>> Posted at Nginx Forum:
>> http://forum.nginx.org/read.php?21,242399,242424#msg-242424
>>
>>
>>
>>
>> ---------- Пересылаемое сообщение ----------
>> From: Daniel Podolsky <onokonem at gmail.com>
>> To: nginx-ru <nginx-ru at nginx.org>
>> Cc:
>> Date: Mon, 2 Sep 2013 00:47:34 +0400
>> Subject: Re: If is Evil
>> > да и выяснить причину раз и навсегда куда полезнее, чем просто запомнить
>> > постулат "скажем if в location - НЕТ"
>> А мы им не скажем НЕТ. Мы просто помним, что для if создается скрытый
>> location, и что туда наследуется, а что нет, и какая там в результате
>> будет конфигурациия - ни за что не прописаешь, как говорили в школе.
>>
>> Поэтому мы пользуемся if, но только одним образом - делаем на нем
>> переадресацию в именованный локейшн.
>>
>> Отдельно, конечно, смешно то, что это единственный разумный способ
>> пользоваться if, но директивы переадресации как не было, так и нет, и
>> приходится писать что-то вроде if (condition) { error_page 418 =
>> @location; return 418; }
>>
>>
>> ---------- Пересылаемое сообщение ----------
>> From: "Валентин Бартенев" <vbart at nginx.com>
>> To: nginx-ru at nginx.org
>> Cc:
>> Date: Mon, 2 Sep 2013 03:02:45 +0400
>> Subject: Re: true 414 status code
>> On Monday 02 September 2013 00:33:57 Vladimir Getmanshchuk wrote:
>> > Амм... Спасибо за скорость и лаконичность.
>> >
>> > Судя по http://www.w3.org/Protocols/HTTP/HTRESP.html, в HTTP/0.9 тоже
>> > есть
>> > status codes, или я что то недопонимаю?
>>
>> Вы ссылаетесь на спецификацию HTTP/1.0.  В HTTP/0.9 у ответа не было
>> заголовка:
>> http://www.w3.org/Protocols/HTTP/AsImplemented.html
>> http://www.w3.org/DesignIssues/HTTP0.9Summary.html
>>
>>
>> > Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"
>>
>> Сам дописывает видимо.  Смотрите более простыми средствами, типа netcat'а
>> или
>> telnet'а.
>>
>> --
>> Валентин Бартенев
>> http://nginx.org/en/donation.html
>>
>>
>> ---------- Пересылаемое сообщение ----------
>> From: "Валентин Бартенев" <vbart at nginx.com>
>> To: nginx-ru at nginx.org
>> Cc:
>> Date: Mon, 2 Sep 2013 03:08:04 +0400
>> Subject: Re: true 414 status code
>> On Sunday 01 September 2013 17:15:55 Gena Makhomed wrote:
>> > On 31.08.2013 23:57, Валентин Бартенев wrote:
>> > >> Подскажите пожалуйста, а как без "грязных хаков" получить от nginx,
>> > >> 414
>> > >> status code, на запросы, размер которых, превышает
>> > >> large_client_header_
>> > >> buffers?
>> > >>
>> > >> Постоянно получаю 200 http status code и нижеприведенное в body:
>> > >>
>> > >> <html>
>> > >> <head><title>414 Request-URI Too Large</title></head>
>> > >> <body bgcolor="white">
>> > >> <center><h1>414 Request-URI Too Large</h1></center>
>> > >> <hr><center>nginx/1.2.9</center>
>> > >> </body>
>> > >> </html>
>> > >
>> > > Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.
>> >
>> > а есть ли смысл отвечать по протоколу версии HTTP/0.9 ?
>> > тем более, что запрос в 99.9999999% был версии 1.0 или 1.1
>> >
>> > даже если "Request-URI Too Large" - версию протокола
>> > запроса можно узнать из строки запроса, при желании.
>>
>> Нельзя.  В наихудшим случае (а он обязательно наступит)
>> строка запроса будет бесконечна.
>>
>> >
>> > тем более, что протокол версии 0.9 не умеет прислать
>> > клиенту ответ в котором будет указан status code 414
>> >
>> > а парсить тело ответа веб-сервера никто не будет,
>> > различных серверов много и формат ответов разный.
>>
>> Я согласен, ИМХО имеет лучше откатываться до 1.0, и даже
>> прислал коллегам соответствующий патч на ревью.
>>
>> --
>> Валентин Бартенев
>> http://nginx.org/en/donation.html
>>
>>
>> ---------- Пересылаемое сообщение ----------
>> From: Maxim Dounin <mdounin at mdounin.ru>
>> To: nginx-ru at nginx.org
>> Cc:
>> Date: Mon, 2 Sep 2013 03:42:31 +0400
>> Subject: Re: If is Evil
>> Hello!
>>
>> On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:
>>
>> > Приветы всем!
>> >
>> > Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не
>> > рекомендуется, и что использовать его там можно только в купе с return
>> > или
>> > rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и
>> > почему.
>> >
>> > Пару рабочих дней было потрачено на то, чтобы разобраться, как оно
>> > работает. Но в итоге выяснилось, что сишку я уже неприлично подзабыл, а
>> > все
>> > гуглы мира ведут на 3 ссылки:
>> >
>> >     http://wiki.nginx.org/IfIsEvil
>> >     http://habrahabr.ru/post/74135/
>> >     http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html
>> >
>> > Но в первой кроме лирики толком ничего не сказано, вторая просто с
>> > первого
>> > же примера плавит мозг, а в последней уже куда по-лучше, примеров
>> > несколько.. но все одно - какой принцип отработки не ясно(
>> >
>> > Ребят, может кто может подробно и последовательно разжевать, КАК это
>> > работает? А то пока получалось обходиться без if'ов, но кто его знает,
>> > что
>> > будет завтра.. не хотелось бы оставить новый след от граблей, старый
>> > только
>> > вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем
>> > просто
>> > запомнить постулат "скажем if в location - НЕТ"
>> >
>> > Буду признателен за любые ответы. Спасибо!
>>
>> В первую голову - надо уяснить для себя, что if создаёт вложенный
>> location.  И именно в этом location'е в результате будет обработан
>> запрос, если if выполнется.  Если таких if'ов много - то запрос
>> будет обработан в последнем if'е, который выполнится.  Поэтому
>> конфигурация вида
>>
>>     location / {
>>         set $true 1;
>>
>>         if ($true) {
>>             add_header X-Foo1 "bar";
>>         }
>>
>>         if ($true) {
>>             add_header X-Foo2 "bar";
>>         }
>>     }
>>
>> добавит только один заголовок, X-Foo2.  Эта особенность - что
>> называется, не баг, а фича.
>>
>> А дальше начинаются костыли, подпорки, и прочие нюансы, связанные,
>> в первую очередь, с тем, что if'ы, в отличие от обычных вложенных
>> location'ов, пытаются наследовать директивы, которые в норме не
>> наследуются во вложенные location'ы (e.g., proxy_pass).  Иногда
>> это получается, иногда - получается, но неправильно, иногда - не
>> получается вовсе.  Конкретные известные случаи нехорошего
>> поведения - коллекционируются на страничке IfIsEvil.
>>
>> --
>> Maxim Dounin
>> http://nginx.org/en/donation.html
>>
>>
>>
>>
>> ---------- Пересылаемое сообщение ----------
>> From: "Васильев \"Zmey!\" Олег" <zmey1992 at ya.ru>
>> To: "nginx-ru at nginx.org" <nginx-ru at nginx.org>
>> Cc:
>> Date: Mon, 02 Sep 2013 04:53:03 +0400
>> Subject: Re: If is Evil
>> Попытаюсь вклиниться в тему. Есть давно волнующий вопрос как раз на ряду с
>> этими if-ами. Есть какой-то список директив, которые наследуются (или не
>> наследуются) в location-ах из уровня выше и такой же для if-ов? Был бы
>> крайне полезный материал, т.к. в голове всё удержать не выходит.
>>
>> 02.09.2013, 03:42, "Maxim Dounin" <mdounin at mdounin.ru>:
>> > Hello!
>> >
>> > On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:
>> >
>> >>  Приветы всем!
>> >>
>> >>  Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не
>> >>  рекомендуется, и что использовать его там можно только в купе с return
>> >> или
>> >>  rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и
>> >>  почему.
>> >>
>> >>  Пару рабочих дней было потрачено на то, чтобы разобраться, как оно
>> >>  работает. Но в итоге выяснилось, что сишку я уже неприлично подзабыл,
>> >> а все
>> >>  гуглы мира ведут на 3 ссылки:
>> >>
>> >>      http://wiki.nginx.org/IfIsEvil
>> >>      http://habrahabr.ru/post/74135/
>> >>
>> >> http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html
>> >>
>> >>  Но в первой кроме лирики толком ничего не сказано, вторая просто с
>> >> первого
>> >>  же примера плавит мозг, а в последней уже куда по-лучше, примеров
>> >>  несколько.. но все одно - какой принцип отработки не ясно(
>> >>
>> >>  Ребят, может кто может подробно и последовательно разжевать, КАК это
>> >>  работает? А то пока получалось обходиться без if'ов, но кто его знает,
>> >> что
>> >>  будет завтра.. не хотелось бы оставить новый след от граблей, старый
>> >> только
>> >>  вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем
>> >> просто
>> >>  запомнить постулат "скажем if в location - НЕТ"
>> >>
>> >>  Буду признателен за любые ответы. Спасибо!
>> >
>> > В первую голову - надо уяснить для себя, что if создаёт вложенный
>> > location.  И именно в этом location'е в результате будет обработан
>> > запрос, если if выполнется.  Если таких if'ов много - то запрос
>> > будет обработан в последнем if'е, который выполнится.  Поэтому
>> > конфигурация вида
>> >
>> >     location / {
>> >         set $true 1;
>> >
>> >         if ($true) {
>> >             add_header X-Foo1 "bar";
>> >         }
>> >
>> >         if ($true) {
>> >             add_header X-Foo2 "bar";
>> >         }
>> >     }
>> >
>> > добавит только один заголовок, X-Foo2.  Эта особенность - что
>> > называется, не баг, а фича.
>> >
>> > А дальше начинаются костыли, подпорки, и прочие нюансы, связанные,
>> > в первую очередь, с тем, что if'ы, в отличие от обычных вложенных
>> > location'ов, пытаются наследовать директивы, которые в норме не
>> > наследуются во вложенные location'ы (e.g., proxy_pass).  Иногда
>> > это получается, иногда - получается, но неправильно, иногда - не
>> > получается вовсе.  Конкретные известные случаи нехорошего
>> > поведения - коллекционируются на страничке IfIsEvil.
>> >
>> > --
>> > Maxim Dounin
>> > http://nginx.org/en/donation.html
>> >
>> > _______________________________________________
>> > nginx-ru mailing list
>> > nginx-ru at nginx.org
>> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>>
>>
>>
>> ---------- Пересылаемое сообщение ----------
>> From: Maxim Dounin <mdounin at mdounin.ru>
>> To: nginx-ru at nginx.org
>> Cc:
>> Date: Mon, 2 Sep 2013 05:16:01 +0400
>> Subject: Re: Неправильные (огромные) значения $request time для
>> FastCGI-запросов
>> Hello!
>>
>> On Sat, Aug 31, 2013 at 04:50:28PM -0400, sofiamay wrote:
>>
>> > А что, за год баг так и не исправили? Разрабы даже не удосужились здесь
>> > отписаться? Баг хотябы в багтрекере висит?
>> > Подтверждаю, у меня тоже $request_time выдаёт бред:
>> >
>> > 240648971536.2381542
>> > 240648971536.2381542
>> > 240648971536.2381542
>> > 240648971536.2381542
>> > 240648971536.2381542
>> >
>> > Одно и то же для многих запросов подряд, потом опять на другой бред
>> > меняет!
>> > Когда это исправят? Зачем в Nginx сделана переменная $request_time если
>> > она
>> > показывает всякий бред, мне думается её нужно убрать, а через несколько
>> > лет,
>> > когда разрабы соизволят исправить баг, вернуть. Пока же от неё больше
>> > вреда
>> > чем пользы.
>> >
>> > P.S. Использую Windows и PHP как FastCGI.
>>
>> Я даже и не знаю, что вам сказать.  Привыкайте - это open source.
>> Тут вам никто ничего не должен, и править вылезающие у вас баги -
>> вам.  Надеяться, что кто-то придёт, и за вас исправит, тем более
>> на Windows - по меньшей мере наивно.
>>
>> Впрочем, патч:
>>
>> diff -r 683283f8b5fd src/http/modules/ngx_http_log_module.c
>> --- a/src/http/modules/ngx_http_log_module.c    Thu Aug 29 20:39:13 2013
>> +0400
>> +++ b/src/http/modules/ngx_http_log_module.c    Mon Sep 02 04:38:34 2013
>> +0400
>> @@ -780,7 +780,7 @@ ngx_http_log_request_time(ngx_http_reque
>>               ((tp->sec - r->start_sec) * 1000 + (tp->msec -
>> r->start_msec));
>>      ms = ngx_max(ms, 0);
>>
>> -    return ngx_sprintf(buf, "%T.%03M", ms / 1000, ms % 1000);
>> +    return ngx_sprintf(buf, "%T.%03M", (time_t) ms / 1000, ms % 1000);
>>  }
>>
>>
>> diff -r 683283f8b5fd src/http/ngx_http_variables.c
>> --- a/src/http/ngx_http_variables.c     Thu Aug 29 20:39:13 2013 +0400
>> +++ b/src/http/ngx_http_variables.c     Mon Sep 02 04:38:34 2013 +0400
>> @@ -1992,7 +1992,7 @@ ngx_http_variable_request_time(ngx_http_
>>               ((tp->sec - r->start_sec) * 1000 + (tp->msec -
>> r->start_msec));
>>      ms = ngx_max(ms, 0);
>>
>> -    v->len = ngx_sprintf(p, "%T.%03M", ms / 1000, ms % 1000) - p;
>> +    v->len = ngx_sprintf(p, "%T.%03M", (time_t) ms / 1000, ms % 1000) -
>> p;
>>      v->valid = 1;
>>      v->no_cacheable = 0;
>>      v->not_found = 0;
>>
>> --
>> Maxim Dounin
>> http://nginx.org/en/donation.html
>>
>>
>>
>> _______________________________________________
>> 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 mdounin at mdounin.ru  Mon Sep  2 10:29:59 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 2 Sep 2013 14:29:59 +0400
Subject: nginx-ru Digest, Vol 47, Issue 4
In-Reply-To: <CAK1EO=UASpmRMd9U5Ze7M1uQPPN3MYi_C599c6i1bQ5XAPZZSw@mail.gmail.com>
References: <mailman.2359.1378084565.22071.nginx-ru@nginx.org>
 <CAK1EO=UASpmRMd9U5Ze7M1uQPPN3MYi_C599c6i1bQ5XAPZZSw@mail.gmail.com>
Message-ID: <20130902102959.GA65634@mdounin.ru>

Hello!

On Mon, Sep 02, 2013 at 11:38:22AM +0300, Андрей Середенко wrote:

> В таком случае, если отрабатывает только последний из if'ов - то в данной
> конфигурации:
> 
>  location ~* /test/url/Page.asmx {

[...]

>             set $my_ipsrc 0;
>             # allow 10.10.1.75/32;
>             if ($remote_addr = 10.10.1.75) { set $my_ipsrc 1; }
>             # allow 10.20.1.20/32;
>             if ($remote_addr = 10.20.1.20) { set $my_ipsrc 1; }
>             # allow 10.20.1.21/32;
>             if ($remote_addr = 10.20.1.21) { set $my_ipsrc 1; }
>             # allow 10.100.1.0/24;
>             if ($remote_addr = 10.100.1.0/24) { set $my_ipsrc 1; }

JFYI: эта проверка никогда не срабатывает, т.к. операция "=" - это 
сравнение со строкой, а адрес не может выглядеть как 
"10.100.1.0/24".

>             # allow 178.111.122.133/32;
>             if ($remote_addr = 178.111.122.133) { set $my_ipsrc 1; }
>             # deny all;
>             if ($my_ipsrc = 0) { return 500; }
>        }
> 
> всем, кроме последнего адреса, должно возвращаться "500" ?
> или лыжи не едут? :)

Вы неправильно прочитали то, что было написано.  Запрос будет 
обрабатываться в контексте неявного location'а, относящегося к 
последнему сработавшему if'у.  E.g., для ip 10.10.1.75 запрос 
будет обротан в контексте

    if ($remote_addr = 10.10.1.75) { set $my_ipsrc 1; }

со всеми вытекающими из этого последствиями вроде отсутствия 
try_files.

Но вообще конфигурация, скажем так, далека от разумного.  
Правильно - использовать allow/deny (+ error_page, если нужно 
вместо 403 выдать 500) или geo{}.

Ссылки по теме:

http://nginx.org/ru/docs/http/ngx_http_access_module.html
http://nginx.org/ru/docs/http/ngx_http_geo_module.html

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


From andrei.seredenko at gmail.com  Mon Sep  2 10:41:53 2013
From: andrei.seredenko at gmail.com (=?KOI8-R?B?4c7E0sXKIPPF0sXExc7Lzw==?=)
Date: Mon, 2 Sep 2013 13:41:53 +0300
Subject: nginx-ru Digest, Vol 47, Issue 6
In-Reply-To: <mailman.2373.1378115057.22071.nginx-ru@nginx.org>
References: <mailman.2373.1378115057.22071.nginx-ru@nginx.org>
Message-ID: <CAK1EO=XiieHDc1fmMabntjYRMUzmTF0cox8RCPz9V+tXqh1=Jg@mail.gmail.com>

Изначально if'ы задействовались исключительно ради желания отдать красивую
500-ю страничку вместо "forbidden". Потом еще потребовалось фильтровать
доступ, основываясь на информации в заголовках (к примеру, анализировать
$http_x_forwarded_for вместо $remote_addr)....  Поэтому простой allow/deny
уже не прокатывал.
А использование if внутри map что, не таит в себе никаких неожиданностей?


2 сентября 2013 г., 12:44 пользователь <nginx-ru-request at nginx.org> написал:

> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
> отправлять по адресу
>         nginx-ru at nginx.org
>
> Для изменения параметров подписки вы можеже использовать веб-страницу
>         http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> Для получения информации о том, как пользовать почтовым интерфейсом,
> отправьте письмо, в теле или теме которого будет слово 'help', по
> адресу:
>         nginx-ru-request at nginx.org
>
> Адрес человека, ответственного за этот список рассылки:
>         nginx-ru-owner at nginx.org
>
> При ответе, пожалуйста, измение тему письма так, чтобы она была более
> содержательной чем "Re: Содержание дайджеста списка рассылки
> nginx-ru..."
>
> Today's Topics:
>
>    1. 502 уступили место 504 (DenisM)
>    2. Re: nginx-ru Digest, Vol 47, Issue 4 (Alexander Moskalenko)
>
>
> ---------- Пересылаемое сообщение ----------
> From: "DenisM" <nginx-forum at nginx.us>
> To: nginx-ru at nginx.org
> Cc:
> Date: Mon, 02 Sep 2013 05:33:19 -0400
> Subject: 502 уступили место 504
> Привет.
> После включения кеша fastcgi ошибки 502 сменились на 504. Это ожидаемое
> поведение?
>
>     fastcgi_cache_path /var/cache/nginx
>         levels=2
>         keys_zone=NAME:50m
>         max_size=1024m
>         inactive=5m;
>     fastcgi_temp_path /var/cache/nginx/fastcgi_temp;
>     fastcgi_cache_key
> $cookie_uid|$scheme|$request_method|$host|$request_uri";
>     fastcgi_cache_methods GET HEAD;
>     map $request_uri $no_cache {
>         default 1;
>         ~/gsa/index 0;
>         ~/product/ 0;
>     }
>     fastcgi_no_cache $no_cache;
>     fastcgi_cache_bypass $no_cache;
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,242452,242452#msg-242452
>
>
>
>
> ---------- Пересылаемое сообщение ----------
> From: Alexander Moskalenko <alexander.moskalenko at gmail.com>
> To: nginx-ru <nginx-ru at nginx.org>
> Cc:
> Date: Mon, 2 Sep 2013 12:44:08 +0300
> Subject: Re: nginx-ru Digest, Vol 47, Issue 4
> В данной конфигурации нужно выкинуть все if и сделать map + if.
> Либо использовать allow+deny, как это обычно делают.
>
> 2013/9/2 Андрей Середенко <andrei.seredenko at gmail.com>:
> > В таком случае, если отрабатывает только последний из if'ов - то в данной
> > конфигурации:
> >
> >  location ~* /test/url/Page.asmx {
> >             proxy_pass         http://test_upstream;
> >             proxy_redirect     off;
> >             proxy_set_header   Host             $host;
> >             proxy_set_header   Remote-Addr      $remote_addr;
> >             proxy_set_header   X-Real-IP        $remote_addr;
> >             proxy_set_header   X-Forwarded-For
>  $proxy_add_x_forwarded_for;
> >             proxy_set_header   X-Public-Url     http://
> $host$request_uri;
> >             ...
> >             some other proxy options
> >             ...
> >             #
> >             set $my_ipsrc 0;
> >             # allow 10.10.1.75/32;
> >             if ($remote_addr = 10.10.1.75) { set $my_ipsrc 1; }
> >             # allow 10.20.1.20/32;
> >             if ($remote_addr = 10.20.1.20) { set $my_ipsrc 1; }
> >             # allow 10.20.1.21/32;
> >             if ($remote_addr = 10.20.1.21) { set $my_ipsrc 1; }
> >             # allow 10.100.1.0/24;
> >             if ($remote_addr = 10.100.1.0/24) { set $my_ipsrc 1; }
> >             # allow 178.111.122.133/32;
> >             if ($remote_addr = 178.111.122.133) { set $my_ipsrc 1; }
> >             # deny all;
> >             if ($my_ipsrc = 0) { return 500; }
> >        }
> >
> > всем, кроме последнего адреса, должно возвращаться "500" ?
> > или лыжи не едут? :)
> >
> >
> > 2 сентября 2013 г., 4:16 пользователь <nginx-ru-request at nginx.org>
> написал:
> >>
> >> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
> >> отправлять по адресу
> >>         nginx-ru at nginx.org
> >>
> >> Для изменения параметров подписки вы можеже использовать веб-страницу
> >>         http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >>
> >> Для получения информации о том, как пользовать почтовым интерфейсом,
> >> отправьте письмо, в теле или теме которого будет слово 'help', по
> >> адресу:
> >>         nginx-ru-request at nginx.org
> >>
> >> Адрес человека, ответственного за этот список рассылки:
> >>         nginx-ru-owner at nginx.org
> >>
> >> При ответе, пожалуйста, измение тему письма так, чтобы она была более
> >> содержательной чем "Re: Содержание дайджеста списка рассылки
> >> nginx-ru..."
> >>
> >> Today's Topics:
> >>
> >>    1. Re: true 414 status code (Vladimir Getmanshchuk)
> >>    2. Re: 400 Bad Request 1.5.4 (1.5.3 = OK) (locojohn)
> >>    3. Re: If is Evil (Daniel Podolsky)
> >>    4. Re: true 414 status code (Валентин Бартенев)
> >>    5. Re: true 414 status code (Валентин Бартенев)
> >>    6. Re: If is Evil (Maxim Dounin)
> >>    7. Re: If is Evil (Васильев Zmey! Олег)
> >>    8. Re: Неправильные (огромные) значения $request time для
> >>       FastCGI-запросов (Maxim Dounin)
> >>
> >>
> >> ---------- Пересылаемое сообщение ----------
> >> From: Vladimir Getmanshchuk <vladget at gmail.com>
> >> To: nginx-ru at nginx.org
> >> Cc:
> >> Date: Sun, 1 Sep 2013 23:33:57 +0300
> >> Subject: Re: true 414 status code
> >> Амм... Спасибо за скорость и лаконичность.
> >>
> >> Судя по http://www.w3.org/Protocols/HTTP/HTRESP.html, в HTTP/0.9 тоже
> есть
> >> status codes, или я что то недопонимаю?
> >> Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"
> >>
> >>
> >>
> >>
> >> 2013/8/31 Валентин Бартенев <ne at vbart.ru>
> >>>
> >>> On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote:
> >>> > Здравствуйте!
> >>> >
> >>> > Подскажите пожалуйста, а как без "грязных хаков" получить от nginx,
> 414
> >>> > status code, на запросы, размер которых, превышает
> large_client_header_
> >>> > buffers?
> >>> >
> >>> > Постоянно получаю 200 http status code и нижеприведенное в body:
> >>> >
> >>> > <html>
> >>> > <head><title>414 Request-URI Too Large</title></head>
> >>> > <body bgcolor="white">
> >>> > <center><h1>414 Request-URI Too Large</h1></center>
> >>> > <hr><center>nginx/1.2.9</center>
> >>> > </body>
> >>> > </html>
> >>>
> >>> Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.
> >>>
> >>> --
> >>> Валентин Бартенев
> >>> http://nginx.org/en/donation.html
> >>> _______________________________________________
> >>> nginx-ru mailing list
> >>> nginx-ru at nginx.org
> >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >>
> >>
> >>
> >>
> >> --
> >> Yours sincerely,
> >> Vladimir Getmanshchuk
> >>
> >>
> >> ---------- Пересылаемое сообщение ----------
> >> From: "locojohn" <nginx-forum at nginx.us>
> >> To: nginx-ru at nginx.org
> >> Cc:
> >> Date: Sun, 01 Sep 2013 16:44:45 -0400
> >> Subject: Re: 400 Bad Request 1.5.4 (1.5.3 = OK)
> >> Oleksandr V. Typlyns'kyi Wrote:
> >>
> >> >   Как видно из кода стороннего модуля(а туда тоже следовало бы
> >> > посмотреть),
> >> >   там несколько return NGX_HTTP_BAD_REQUEST без записи чего-либо в лог
> >> > ошибок.
> >> >   И они явно намекают на content type который теперь
> >> > application/javascript.
> >> >   Добавление его в concat_types должно помочь.
> >>
> >> Спасибо за отличный хинт!  Добавление "application/javascript" в
> >> concat_types не помогло, пришлось подпатчить исходный модуль concat:
> >>
> >> --- ngx_http_concat_module.c
> >> +++ ngx_http_concat_module.c
> >> @@ -30,7 +30,7 @@
> >>
> >>
> >>  static ngx_str_t  ngx_http_concat_default_types[] = {
> >> -    ngx_string("application/x-javascript"),
> >> +    ngx_string("application/javascript"),
> >>      ngx_string("text/css"),
> >>      ngx_null_string
> >>  };
> >>
> >> Ещё раз - спасибо!
> >>
> >> Posted at Nginx Forum:
> >> http://forum.nginx.org/read.php?21,242399,242424#msg-242424
> >>
> >>
> >>
> >>
> >> ---------- Пересылаемое сообщение ----------
> >> From: Daniel Podolsky <onokonem at gmail.com>
> >> To: nginx-ru <nginx-ru at nginx.org>
> >> Cc:
> >> Date: Mon, 2 Sep 2013 00:47:34 +0400
> >> Subject: Re: If is Evil
> >> > да и выяснить причину раз и навсегда куда полезнее, чем просто
> запомнить
> >> > постулат "скажем if в location - НЕТ"
> >> А мы им не скажем НЕТ. Мы просто помним, что для if создается скрытый
> >> location, и что туда наследуется, а что нет, и какая там в результате
> >> будет конфигурациия - ни за что не прописаешь, как говорили в школе.
> >>
> >> Поэтому мы пользуемся if, но только одним образом - делаем на нем
> >> переадресацию в именованный локейшн.
> >>
> >> Отдельно, конечно, смешно то, что это единственный разумный способ
> >> пользоваться if, но директивы переадресации как не было, так и нет, и
> >> приходится писать что-то вроде if (condition) { error_page 418 =
> >> @location; return 418; }
> >>
> >>
> >> ---------- Пересылаемое сообщение ----------
> >> From: "Валентин Бартенев" <vbart at nginx.com>
> >> To: nginx-ru at nginx.org
> >> Cc:
> >> Date: Mon, 2 Sep 2013 03:02:45 +0400
> >> Subject: Re: true 414 status code
> >> On Monday 02 September 2013 00:33:57 Vladimir Getmanshchuk wrote:
> >> > Амм... Спасибо за скорость и лаконичность.
> >> >
> >> > Судя по http://www.w3.org/Protocols/HTTP/HTRESP.html, в HTTP/0.9 тоже
> >> > есть
> >> > status codes, или я что то недопонимаю?
> >>
> >> Вы ссылаетесь на спецификацию HTTP/1.0.  В HTTP/0.9 у ответа не было
> >> заголовка:
> >> http://www.w3.org/Protocols/HTTP/AsImplemented.html
> >> http://www.w3.org/DesignIssues/HTTP0.9Summary.html
> >>
> >>
> >> > Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"
> >>
> >> Сам дописывает видимо.  Смотрите более простыми средствами, типа
> netcat'а
> >> или
> >> telnet'а.
> >>
> >> --
> >> Валентин Бартенев
> >> http://nginx.org/en/donation.html
> >>
> >>
> >> ---------- Пересылаемое сообщение ----------
> >> From: "Валентин Бартенев" <vbart at nginx.com>
> >> To: nginx-ru at nginx.org
> >> Cc:
> >> Date: Mon, 2 Sep 2013 03:08:04 +0400
> >> Subject: Re: true 414 status code
> >> On Sunday 01 September 2013 17:15:55 Gena Makhomed wrote:
> >> > On 31.08.2013 23:57, Валентин Бартенев wrote:
> >> > >> Подскажите пожалуйста, а как без "грязных хаков" получить от nginx,
> >> > >> 414
> >> > >> status code, на запросы, размер которых, превышает
> >> > >> large_client_header_
> >> > >> buffers?
> >> > >>
> >> > >> Постоянно получаю 200 http status code и нижеприведенное в body:
> >> > >>
> >> > >> <html>
> >> > >> <head><title>414 Request-URI Too Large</title></head>
> >> > >> <body bgcolor="white">
> >> > >> <center><h1>414 Request-URI Too Large</h1></center>
> >> > >> <hr><center>nginx/1.2.9</center>
> >> > >> </body>
> >> > >> </html>
> >> > >
> >> > > Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.
> >> >
> >> > а есть ли смысл отвечать по протоколу версии HTTP/0.9 ?
> >> > тем более, что запрос в 99.9999999% был версии 1.0 или 1.1
> >> >
> >> > даже если "Request-URI Too Large" - версию протокола
> >> > запроса можно узнать из строки запроса, при желании.
> >>
> >> Нельзя.  В наихудшим случае (а он обязательно наступит)
> >> строка запроса будет бесконечна.
> >>
> >> >
> >> > тем более, что протокол версии 0.9 не умеет прислать
> >> > клиенту ответ в котором будет указан status code 414
> >> >
> >> > а парсить тело ответа веб-сервера никто не будет,
> >> > различных серверов много и формат ответов разный.
> >>
> >> Я согласен, ИМХО имеет лучше откатываться до 1.0, и даже
> >> прислал коллегам соответствующий патч на ревью.
> >>
> >> --
> >> Валентин Бартенев
> >> http://nginx.org/en/donation.html
> >>
> >>
> >> ---------- Пересылаемое сообщение ----------
> >> From: Maxim Dounin <mdounin at mdounin.ru>
> >> To: nginx-ru at nginx.org
> >> Cc:
> >> Date: Mon, 2 Sep 2013 03:42:31 +0400
> >> Subject: Re: If is Evil
> >> Hello!
> >>
> >> On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:
> >>
> >> > Приветы всем!
> >> >
> >> > Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не
> >> > рекомендуется, и что использовать его там можно только в купе с return
> >> > или
> >> > rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и
> >> > почему.
> >> >
> >> > Пару рабочих дней было потрачено на то, чтобы разобраться, как оно
> >> > работает. Но в итоге выяснилось, что сишку я уже неприлично подзабыл,
> а
> >> > все
> >> > гуглы мира ведут на 3 ссылки:
> >> >
> >> >     http://wiki.nginx.org/IfIsEvil
> >> >     http://habrahabr.ru/post/74135/
> >> >
> http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html
> >> >
> >> > Но в первой кроме лирики толком ничего не сказано, вторая просто с
> >> > первого
> >> > же примера плавит мозг, а в последней уже куда по-лучше, примеров
> >> > несколько.. но все одно - какой принцип отработки не ясно(
> >> >
> >> > Ребят, может кто может подробно и последовательно разжевать, КАК это
> >> > работает? А то пока получалось обходиться без if'ов, но кто его знает,
> >> > что
> >> > будет завтра.. не хотелось бы оставить новый след от граблей, старый
> >> > только
> >> > вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем
> >> > просто
> >> > запомнить постулат "скажем if в location - НЕТ"
> >> >
> >> > Буду признателен за любые ответы. Спасибо!
> >>
> >> В первую голову - надо уяснить для себя, что if создаёт вложенный
> >> location.  И именно в этом location'е в результате будет обработан
> >> запрос, если if выполнется.  Если таких if'ов много - то запрос
> >> будет обработан в последнем if'е, который выполнится.  Поэтому
> >> конфигурация вида
> >>
> >>     location / {
> >>         set $true 1;
> >>
> >>         if ($true) {
> >>             add_header X-Foo1 "bar";
> >>         }
> >>
> >>         if ($true) {
> >>             add_header X-Foo2 "bar";
> >>         }
> >>     }
> >>
> >> добавит только один заголовок, X-Foo2.  Эта особенность - что
> >> называется, не баг, а фича.
> >>
> >> А дальше начинаются костыли, подпорки, и прочие нюансы, связанные,
> >> в первую очередь, с тем, что if'ы, в отличие от обычных вложенных
> >> location'ов, пытаются наследовать директивы, которые в норме не
> >> наследуются во вложенные location'ы (e.g., proxy_pass).  Иногда
> >> это получается, иногда - получается, но неправильно, иногда - не
> >> получается вовсе.  Конкретные известные случаи нехорошего
> >> поведения - коллекционируются на страничке IfIsEvil.
> >>
> >> --
> >> Maxim Dounin
> >> http://nginx.org/en/donation.html
> >>
> >>
> >>
> >>
> >> ---------- Пересылаемое сообщение ----------
> >> From: "Васильев \"Zmey!\" Олег" <zmey1992 at ya.ru>
> >> To: "nginx-ru at nginx.org" <nginx-ru at nginx.org>
> >> Cc:
> >> Date: Mon, 02 Sep 2013 04:53:03 +0400
> >> Subject: Re: If is Evil
> >> Попытаюсь вклиниться в тему. Есть давно волнующий вопрос как раз на
> ряду с
> >> этими if-ами. Есть какой-то список директив, которые наследуются (или не
> >> наследуются) в location-ах из уровня выше и такой же для if-ов? Был бы
> >> крайне полезный материал, т.к. в голове всё удержать не выходит.
> >>
> >> 02.09.2013, 03:42, "Maxim Dounin" <mdounin at mdounin.ru>:
> >> > Hello!
> >> >
> >> > On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:
> >> >
> >> >>  Приветы всем!
> >> >>
> >> >>  Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не
> >> >>  рекомендуется, и что использовать его там можно только в купе с
> return
> >> >> или
> >> >>  rewrite..last, но - все же хочется разобраться, КАК он отрабатывает
> и
> >> >>  почему.
> >> >>
> >> >>  Пару рабочих дней было потрачено на то, чтобы разобраться, как оно
> >> >>  работает. Но в итоге выяснилось, что сишку я уже неприлично
> подзабыл,
> >> >> а все
> >> >>  гуглы мира ведут на 3 ссылки:
> >> >>
> >> >>      http://wiki.nginx.org/IfIsEvil
> >> >>      http://habrahabr.ru/post/74135/
> >> >>
> >> >> http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html
> >> >>
> >> >>  Но в первой кроме лирики толком ничего не сказано, вторая просто с
> >> >> первого
> >> >>  же примера плавит мозг, а в последней уже куда по-лучше, примеров
> >> >>  несколько.. но все одно - какой принцип отработки не ясно(
> >> >>
> >> >>  Ребят, может кто может подробно и последовательно разжевать, КАК это
> >> >>  работает? А то пока получалось обходиться без if'ов, но кто его
> знает,
> >> >> что
> >> >>  будет завтра.. не хотелось бы оставить новый след от граблей, старый
> >> >> только
> >> >>  вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем
> >> >> просто
> >> >>  запомнить постулат "скажем if в location - НЕТ"
> >> >>
> >> >>  Буду признателен за любые ответы. Спасибо!
> >> >
> >> > В первую голову - надо уяснить для себя, что if создаёт вложенный
> >> > location.  И именно в этом location'е в результате будет обработан
> >> > запрос, если if выполнется.  Если таких if'ов много - то запрос
> >> > будет обработан в последнем if'е, который выполнится.  Поэтому
> >> > конфигурация вида
> >> >
> >> >     location / {
> >> >         set $true 1;
> >> >
> >> >         if ($true) {
> >> >             add_header X-Foo1 "bar";
> >> >         }
> >> >
> >> >         if ($true) {
> >> >             add_header X-Foo2 "bar";
> >> >         }
> >> >     }
> >> >
> >> > добавит только один заголовок, X-Foo2.  Эта особенность - что
> >> > называется, не баг, а фича.
> >> >
> >> > А дальше начинаются костыли, подпорки, и прочие нюансы, связанные,
> >> > в первую очередь, с тем, что if'ы, в отличие от обычных вложенных
> >> > location'ов, пытаются наследовать директивы, которые в норме не
> >> > наследуются во вложенные location'ы (e.g., proxy_pass).  Иногда
> >> > это получается, иногда - получается, но неправильно, иногда - не
> >> > получается вовсе.  Конкретные известные случаи нехорошего
> >> > поведения - коллекционируются на страничке IfIsEvil.
> >> >
> >> > --
> >> > Maxim Dounin
> >> > http://nginx.org/en/donation.html
> >> >
> >> > _______________________________________________
> >> > nginx-ru mailing list
> >> > nginx-ru at nginx.org
> >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >>
> >>
> >>
> >>
> >> ---------- Пересылаемое сообщение ----------
> >> From: Maxim Dounin <mdounin at mdounin.ru>
> >> To: nginx-ru at nginx.org
> >> Cc:
> >> Date: Mon, 2 Sep 2013 05:16:01 +0400
> >> Subject: Re: Неправильные (огромные) значения $request time для
> >> FastCGI-запросов
> >> Hello!
> >>
> >> On Sat, Aug 31, 2013 at 04:50:28PM -0400, sofiamay wrote:
> >>
> >> > А что, за год баг так и не исправили? Разрабы даже не удосужились
> здесь
> >> > отписаться? Баг хотябы в багтрекере висит?
> >> > Подтверждаю, у меня тоже $request_time выдаёт бред:
> >> >
> >> > 240648971536.2381542
> >> > 240648971536.2381542
> >> > 240648971536.2381542
> >> > 240648971536.2381542
> >> > 240648971536.2381542
> >> >
> >> > Одно и то же для многих запросов подряд, потом опять на другой бред
> >> > меняет!
> >> > Когда это исправят? Зачем в Nginx сделана переменная $request_time
> если
> >> > она
> >> > показывает всякий бред, мне думается её нужно убрать, а через
> несколько
> >> > лет,
> >> > когда разрабы соизволят исправить баг, вернуть. Пока же от неё больше
> >> > вреда
> >> > чем пользы.
> >> >
> >> > P.S. Использую Windows и PHP как FastCGI.
> >>
> >> Я даже и не знаю, что вам сказать.  Привыкайте - это open source.
> >> Тут вам никто ничего не должен, и править вылезающие у вас баги -
> >> вам.  Надеяться, что кто-то придёт, и за вас исправит, тем более
> >> на Windows - по меньшей мере наивно.
> >>
> >> Впрочем, патч:
> >>
> >> diff -r 683283f8b5fd src/http/modules/ngx_http_log_module.c
> >> --- a/src/http/modules/ngx_http_log_module.c    Thu Aug 29 20:39:13 2013
> >> +0400
> >> +++ b/src/http/modules/ngx_http_log_module.c    Mon Sep 02 04:38:34 2013
> >> +0400
> >> @@ -780,7 +780,7 @@ ngx_http_log_request_time(ngx_http_reque
> >>               ((tp->sec - r->start_sec) * 1000 + (tp->msec -
> >> r->start_msec));
> >>      ms = ngx_max(ms, 0);
> >>
> >> -    return ngx_sprintf(buf, "%T.%03M", ms / 1000, ms % 1000);
> >> +    return ngx_sprintf(buf, "%T.%03M", (time_t) ms / 1000, ms % 1000);
> >>  }
> >>
> >>
> >> diff -r 683283f8b5fd src/http/ngx_http_variables.c
> >> --- a/src/http/ngx_http_variables.c     Thu Aug 29 20:39:13 2013 +0400
> >> +++ b/src/http/ngx_http_variables.c     Mon Sep 02 04:38:34 2013 +0400
> >> @@ -1992,7 +1992,7 @@ ngx_http_variable_request_time(ngx_http_
> >>               ((tp->sec - r->start_sec) * 1000 + (tp->msec -
> >> r->start_msec));
> >>      ms = ngx_max(ms, 0);
> >>
> >> -    v->len = ngx_sprintf(p, "%T.%03M", ms / 1000, ms % 1000) - p;
> >> +    v->len = ngx_sprintf(p, "%T.%03M", (time_t) ms / 1000, ms % 1000) -
> >> p;
> >>      v->valid = 1;
> >>      v->no_cacheable = 0;
> >>      v->not_found = 0;
> >>
> >> --
> >> Maxim Dounin
> >> http://nginx.org/en/donation.html
> >>
> >>
> >>
> >> _______________________________________________
> >> nginx-ru mailing list
> >> nginx-ru at nginx.org
> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> >
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130902/18378b28/attachment-0001.html>

From andrei.seredenko at gmail.com  Mon Sep  2 11:22:29 2013
From: andrei.seredenko at gmail.com (=?KOI8-R?B?4c7E0sXKIPPF0sXExc7Lzw==?=)
Date: Mon, 2 Sep 2013 14:22:29 +0300
Subject: nginx-ru Digest, Vol 47, Issue 7
In-Reply-To: <mailman.2376.1378118521.22071.nginx-ru@nginx.org>
References: <mailman.2376.1378118521.22071.nginx-ru@nginx.org>
Message-ID: <CAK1EO=VA9gpb3-+zDyAGffv4RQ=R2dw48ELzU-EZDsYm6Yu0mA@mail.gmail.com>

Ух ты, а geo{}, похоже, именно то, что мне надо, спасибо!

но тема if-сек все равно как-то не раскрыта, придется на досуге курить
исходники..


2 сентября 2013 г., 13:42 пользователь <nginx-ru-request at nginx.org> написал:

> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
> отправлять по адресу
>         nginx-ru at nginx.org
>
> Для изменения параметров подписки вы можеже использовать веб-страницу
>         http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> Для получения информации о том, как пользовать почтовым интерфейсом,
> отправьте письмо, в теле или теме которого будет слово 'help', по
> адресу:
>         nginx-ru-request at nginx.org
>
> Адрес человека, ответственного за этот список рассылки:
>         nginx-ru-owner at nginx.org
>
> При ответе, пожалуйста, измение тему письма так, чтобы она была более
> содержательной чем "Re: Содержание дайджеста списка рассылки
> nginx-ru..."
>
> Today's Topics:
>
>    1. Re: nginx-ru Digest, Vol 47, Issue 4 (Maxim Dounin)
>    2. Re: nginx-ru Digest, Vol 47, Issue 6 (Андрей Середенко)
>
>
> ---------- Пересылаемое сообщение ----------
> From: Maxim Dounin <mdounin at mdounin.ru>
> To: nginx-ru at nginx.org
> Cc:
> Date: Mon, 2 Sep 2013 14:29:59 +0400
> Subject: Re: nginx-ru Digest, Vol 47, Issue 4
> Hello!
>
> On Mon, Sep 02, 2013 at 11:38:22AM +0300, Андрей Середенко wrote:
>
> > В таком случае, если отрабатывает только последний из if'ов - то в данной
> > конфигурации:
> >
> >  location ~* /test/url/Page.asmx {
>
> [...]
>
> >             set $my_ipsrc 0;
> >             # allow 10.10.1.75/32;
> >             if ($remote_addr = 10.10.1.75) { set $my_ipsrc 1; }
> >             # allow 10.20.1.20/32;
> >             if ($remote_addr = 10.20.1.20) { set $my_ipsrc 1; }
> >             # allow 10.20.1.21/32;
> >             if ($remote_addr = 10.20.1.21) { set $my_ipsrc 1; }
> >             # allow 10.100.1.0/24;
> >             if ($remote_addr = 10.100.1.0/24) { set $my_ipsrc 1; }
>
> JFYI: эта проверка никогда не срабатывает, т.к. операция "=" - это
> сравнение со строкой, а адрес не может выглядеть как
> "10.100.1.0/24".
>
> >             # allow 178.111.122.133/32;
> >             if ($remote_addr = 178.111.122.133) { set $my_ipsrc 1; }
> >             # deny all;
> >             if ($my_ipsrc = 0) { return 500; }
> >        }
> >
> > всем, кроме последнего адреса, должно возвращаться "500" ?
> > или лыжи не едут? :)
>
> Вы неправильно прочитали то, что было написано.  Запрос будет
> обрабатываться в контексте неявного location'а, относящегося к
> последнему сработавшему if'у.  E.g., для ip 10.10.1.75 запрос
> будет обротан в контексте
>
>     if ($remote_addr = 10.10.1.75) { set $my_ipsrc 1; }
>
> со всеми вытекающими из этого последствиями вроде отсутствия
> try_files.
>
> Но вообще конфигурация, скажем так, далека от разумного.
> Правильно - использовать allow/deny (+ error_page, если нужно
> вместо 403 выдать 500) или geo{}.
>
> Ссылки по теме:
>
> http://nginx.org/ru/docs/http/ngx_http_access_module.html
> http://nginx.org/ru/docs/http/ngx_http_geo_module.html
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
>
>
>
> ---------- Пересылаемое сообщение ----------
> From: "Андрей Середенко" <andrei.seredenko at gmail.com>
> To: nginx-ru at nginx.org
> Cc:
> Date: Mon, 2 Sep 2013 13:41:53 +0300
> Subject: Re: nginx-ru Digest, Vol 47, Issue 6
> Изначально if'ы задействовались исключительно ради желания отдать красивую
> 500-ю страничку вместо "forbidden". Потом еще потребовалось фильтровать
> доступ, основываясь на информации в заголовках (к примеру, анализировать
> $http_x_forwarded_for вместо $remote_addr)....  Поэтому простой allow/deny
> уже не прокатывал.
> А использование if внутри map что, не таит в себе никаких неожиданностей?
>
>
> 2 сентября 2013 г., 12:44 пользователь <nginx-ru-request at nginx.org>написал:
>
>> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
>> отправлять по адресу
>>         nginx-ru at nginx.org
>>
>> Для изменения параметров подписки вы можеже использовать веб-страницу
>>         http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>> Для получения информации о том, как пользовать почтовым интерфейсом,
>> отправьте письмо, в теле или теме которого будет слово 'help', по
>> адресу:
>>         nginx-ru-request at nginx.org
>>
>> Адрес человека, ответственного за этот список рассылки:
>>         nginx-ru-owner at nginx.org
>>
>> При ответе, пожалуйста, измение тему письма так, чтобы она была более
>> содержательной чем "Re: Содержание дайджеста списка рассылки
>> nginx-ru..."
>>
>> Today's Topics:
>>
>>    1. 502 уступили место 504 (DenisM)
>>    2. Re: nginx-ru Digest, Vol 47, Issue 4 (Alexander Moskalenko)
>>
>>
>> ---------- Пересылаемое сообщение ----------
>> From: "DenisM" <nginx-forum at nginx.us>
>> To: nginx-ru at nginx.org
>> Cc:
>> Date: Mon, 02 Sep 2013 05:33:19 -0400
>> Subject: 502 уступили место 504
>> Привет.
>> После включения кеша fastcgi ошибки 502 сменились на 504. Это ожидаемое
>> поведение?
>>
>>     fastcgi_cache_path /var/cache/nginx
>>         levels=2
>>         keys_zone=NAME:50m
>>         max_size=1024m
>>         inactive=5m;
>>     fastcgi_temp_path /var/cache/nginx/fastcgi_temp;
>>     fastcgi_cache_key
>> $cookie_uid|$scheme|$request_method|$host|$request_uri";
>>     fastcgi_cache_methods GET HEAD;
>>     map $request_uri $no_cache {
>>         default 1;
>>         ~/gsa/index 0;
>>         ~/product/ 0;
>>     }
>>     fastcgi_no_cache $no_cache;
>>     fastcgi_cache_bypass $no_cache;
>>
>> Posted at Nginx Forum:
>> http://forum.nginx.org/read.php?21,242452,242452#msg-242452
>>
>>
>>
>>
>> ---------- Пересылаемое сообщение ----------
>> From: Alexander Moskalenko <alexander.moskalenko at gmail.com>
>> To: nginx-ru <nginx-ru at nginx.org>
>> Cc:
>> Date: Mon, 2 Sep 2013 12:44:08 +0300
>> Subject: Re: nginx-ru Digest, Vol 47, Issue 4
>> В данной конфигурации нужно выкинуть все if и сделать map + if.
>> Либо использовать allow+deny, как это обычно делают.
>>
>> 2013/9/2 Андрей Середенко <andrei.seredenko at gmail.com>:
>> > В таком случае, если отрабатывает только последний из if'ов - то в
>> данной
>> > конфигурации:
>> >
>> >  location ~* /test/url/Page.asmx {
>> >             proxy_pass         http://test_upstream;
>> >             proxy_redirect     off;
>> >             proxy_set_header   Host             $host;
>> >             proxy_set_header   Remote-Addr      $remote_addr;
>> >             proxy_set_header   X-Real-IP        $remote_addr;
>> >             proxy_set_header   X-Forwarded-For
>>  $proxy_add_x_forwarded_for;
>> >             proxy_set_header   X-Public-Url     http://
>> $host$request_uri;
>> >             ...
>> >             some other proxy options
>> >             ...
>> >             #
>> >             set $my_ipsrc 0;
>> >             # allow 10.10.1.75/32;
>> >             if ($remote_addr = 10.10.1.75) { set $my_ipsrc 1; }
>> >             # allow 10.20.1.20/32;
>> >             if ($remote_addr = 10.20.1.20) { set $my_ipsrc 1; }
>> >             # allow 10.20.1.21/32;
>> >             if ($remote_addr = 10.20.1.21) { set $my_ipsrc 1; }
>> >             # allow 10.100.1.0/24;
>> >             if ($remote_addr = 10.100.1.0/24) { set $my_ipsrc 1; }
>> >             # allow 178.111.122.133/32;
>> >             if ($remote_addr = 178.111.122.133) { set $my_ipsrc 1; }
>> >             # deny all;
>> >             if ($my_ipsrc = 0) { return 500; }
>> >        }
>> >
>> > всем, кроме последнего адреса, должно возвращаться "500" ?
>> > или лыжи не едут? :)
>> >
>> >
>> > 2 сентября 2013 г., 4:16 пользователь <nginx-ru-request at nginx.org>
>> написал:
>> >>
>> >> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
>> >> отправлять по адресу
>> >>         nginx-ru at nginx.org
>> >>
>> >> Для изменения параметров подписки вы можеже использовать веб-страницу
>> >>         http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >>
>> >> Для получения информации о том, как пользовать почтовым интерфейсом,
>> >> отправьте письмо, в теле или теме которого будет слово 'help', по
>> >> адресу:
>> >>         nginx-ru-request at nginx.org
>> >>
>> >> Адрес человека, ответственного за этот список рассылки:
>> >>         nginx-ru-owner at nginx.org
>> >>
>> >> При ответе, пожалуйста, измение тему письма так, чтобы она была более
>> >> содержательной чем "Re: Содержание дайджеста списка рассылки
>> >> nginx-ru..."
>> >>
>> >> Today's Topics:
>> >>
>> >>    1. Re: true 414 status code (Vladimir Getmanshchuk)
>> >>    2. Re: 400 Bad Request 1.5.4 (1.5.3 = OK) (locojohn)
>> >>    3. Re: If is Evil (Daniel Podolsky)
>> >>    4. Re: true 414 status code (Валентин Бартенев)
>> >>    5. Re: true 414 status code (Валентин Бартенев)
>> >>    6. Re: If is Evil (Maxim Dounin)
>> >>    7. Re: If is Evil (Васильев Zmey! Олег)
>> >>    8. Re: Неправильные (огромные) значения $request time для
>> >>       FastCGI-запросов (Maxim Dounin)
>> >>
>> >>
>> >> ---------- Пересылаемое сообщение ----------
>> >> From: Vladimir Getmanshchuk <vladget at gmail.com>
>> >> To: nginx-ru at nginx.org
>> >> Cc:
>> >> Date: Sun, 1 Sep 2013 23:33:57 +0300
>> >> Subject: Re: true 414 status code
>> >> Амм... Спасибо за скорость и лаконичность.
>> >>
>> >> Судя по http://www.w3.org/Protocols/HTTP/HTRESP.html, в HTTP/0.9 тоже
>> есть
>> >> status codes, или я что то недопонимаю?
>> >> Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"
>> >>
>> >>
>> >>
>> >>
>> >> 2013/8/31 Валентин Бартенев <ne at vbart.ru>
>> >>>
>> >>> On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote:
>> >>> > Здравствуйте!
>> >>> >
>> >>> > Подскажите пожалуйста, а как без "грязных хаков" получить от nginx,
>> 414
>> >>> > status code, на запросы, размер которых, превышает
>> large_client_header_
>> >>> > buffers?
>> >>> >
>> >>> > Постоянно получаю 200 http status code и нижеприведенное в body:
>> >>> >
>> >>> > <html>
>> >>> > <head><title>414 Request-URI Too Large</title></head>
>> >>> > <body bgcolor="white">
>> >>> > <center><h1>414 Request-URI Too Large</h1></center>
>> >>> > <hr><center>nginx/1.2.9</center>
>> >>> > </body>
>> >>> > </html>
>> >>>
>> >>> Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.
>> >>>
>> >>> --
>> >>> Валентин Бартенев
>> >>> http://nginx.org/en/donation.html
>> >>> _______________________________________________
>> >>> nginx-ru mailing list
>> >>> nginx-ru at nginx.org
>> >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Yours sincerely,
>> >> Vladimir Getmanshchuk
>> >>
>> >>
>> >> ---------- Пересылаемое сообщение ----------
>> >> From: "locojohn" <nginx-forum at nginx.us>
>> >> To: nginx-ru at nginx.org
>> >> Cc:
>> >> Date: Sun, 01 Sep 2013 16:44:45 -0400
>> >> Subject: Re: 400 Bad Request 1.5.4 (1.5.3 = OK)
>> >> Oleksandr V. Typlyns'kyi Wrote:
>> >>
>> >> >   Как видно из кода стороннего модуля(а туда тоже следовало бы
>> >> > посмотреть),
>> >> >   там несколько return NGX_HTTP_BAD_REQUEST без записи чего-либо в
>> лог
>> >> > ошибок.
>> >> >   И они явно намекают на content type который теперь
>> >> > application/javascript.
>> >> >   Добавление его в concat_types должно помочь.
>> >>
>> >> Спасибо за отличный хинт!  Добавление "application/javascript" в
>> >> concat_types не помогло, пришлось подпатчить исходный модуль concat:
>> >>
>> >> --- ngx_http_concat_module.c
>> >> +++ ngx_http_concat_module.c
>> >> @@ -30,7 +30,7 @@
>> >>
>> >>
>> >>  static ngx_str_t  ngx_http_concat_default_types[] = {
>> >> -    ngx_string("application/x-javascript"),
>> >> +    ngx_string("application/javascript"),
>> >>      ngx_string("text/css"),
>> >>      ngx_null_string
>> >>  };
>> >>
>> >> Ещё раз - спасибо!
>> >>
>> >> Posted at Nginx Forum:
>> >> http://forum.nginx.org/read.php?21,242399,242424#msg-242424
>> >>
>> >>
>> >>
>> >>
>> >> ---------- Пересылаемое сообщение ----------
>> >> From: Daniel Podolsky <onokonem at gmail.com>
>> >> To: nginx-ru <nginx-ru at nginx.org>
>> >> Cc:
>> >> Date: Mon, 2 Sep 2013 00:47:34 +0400
>> >> Subject: Re: If is Evil
>> >> > да и выяснить причину раз и навсегда куда полезнее, чем просто
>> запомнить
>> >> > постулат "скажем if в location - НЕТ"
>> >> А мы им не скажем НЕТ. Мы просто помним, что для if создается скрытый
>> >> location, и что туда наследуется, а что нет, и какая там в результате
>> >> будет конфигурациия - ни за что не прописаешь, как говорили в школе.
>> >>
>> >> Поэтому мы пользуемся if, но только одним образом - делаем на нем
>> >> переадресацию в именованный локейшн.
>> >>
>> >> Отдельно, конечно, смешно то, что это единственный разумный способ
>> >> пользоваться if, но директивы переадресации как не было, так и нет, и
>> >> приходится писать что-то вроде if (condition) { error_page 418 =
>> >> @location; return 418; }
>> >>
>> >>
>> >> ---------- Пересылаемое сообщение ----------
>> >> From: "Валентин Бартенев" <vbart at nginx.com>
>> >> To: nginx-ru at nginx.org
>> >> Cc:
>> >> Date: Mon, 2 Sep 2013 03:02:45 +0400
>> >> Subject: Re: true 414 status code
>> >> On Monday 02 September 2013 00:33:57 Vladimir Getmanshchuk wrote:
>> >> > Амм... Спасибо за скорость и лаконичность.
>> >> >
>> >> > Судя по http://www.w3.org/Protocols/HTTP/HTRESP.html, в HTTP/0.9
>> тоже
>> >> > есть
>> >> > status codes, или я что то недопонимаю?
>> >>
>> >> Вы ссылаетесь на спецификацию HTTP/1.0.  В HTTP/0.9 у ответа не было
>> >> заголовка:
>> >> http://www.w3.org/Protocols/HTTP/AsImplemented.html
>> >> http://www.w3.org/DesignIssues/HTTP0.9Summary.html
>> >>
>> >>
>> >> > Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"
>> >>
>> >> Сам дописывает видимо.  Смотрите более простыми средствами, типа
>> netcat'а
>> >> или
>> >> telnet'а.
>> >>
>> >> --
>> >> Валентин Бартенев
>> >> http://nginx.org/en/donation.html
>> >>
>> >>
>> >> ---------- Пересылаемое сообщение ----------
>> >> From: "Валентин Бартенев" <vbart at nginx.com>
>> >> To: nginx-ru at nginx.org
>> >> Cc:
>> >> Date: Mon, 2 Sep 2013 03:08:04 +0400
>> >> Subject: Re: true 414 status code
>> >> On Sunday 01 September 2013 17:15:55 Gena Makhomed wrote:
>> >> > On 31.08.2013 23:57, Валентин Бартенев wrote:
>> >> > >> Подскажите пожалуйста, а как без "грязных хаков" получить от
>> nginx,
>> >> > >> 414
>> >> > >> status code, на запросы, размер которых, превышает
>> >> > >> large_client_header_
>> >> > >> buffers?
>> >> > >>
>> >> > >> Постоянно получаю 200 http status code и нижеприведенное в body:
>> >> > >>
>> >> > >> <html>
>> >> > >> <head><title>414 Request-URI Too Large</title></head>
>> >> > >> <body bgcolor="white">
>> >> > >> <center><h1>414 Request-URI Too Large</h1></center>
>> >> > >> <hr><center>nginx/1.2.9</center>
>> >> > >> </body>
>> >> > >> </html>
>> >> > >
>> >> > > Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.
>> >> >
>> >> > а есть ли смысл отвечать по протоколу версии HTTP/0.9 ?
>> >> > тем более, что запрос в 99.9999999% был версии 1.0 или 1.1
>> >> >
>> >> > даже если "Request-URI Too Large" - версию протокола
>> >> > запроса можно узнать из строки запроса, при желании.
>> >>
>> >> Нельзя.  В наихудшим случае (а он обязательно наступит)
>> >> строка запроса будет бесконечна.
>> >>
>> >> >
>> >> > тем более, что протокол версии 0.9 не умеет прислать
>> >> > клиенту ответ в котором будет указан status code 414
>> >> >
>> >> > а парсить тело ответа веб-сервера никто не будет,
>> >> > различных серверов много и формат ответов разный.
>> >>
>> >> Я согласен, ИМХО имеет лучше откатываться до 1.0, и даже
>> >> прислал коллегам соответствующий патч на ревью.
>> >>
>> >> --
>> >> Валентин Бартенев
>> >> http://nginx.org/en/donation.html
>> >>
>> >>
>> >> ---------- Пересылаемое сообщение ----------
>> >> From: Maxim Dounin <mdounin at mdounin.ru>
>> >> To: nginx-ru at nginx.org
>> >> Cc:
>> >> Date: Mon, 2 Sep 2013 03:42:31 +0400
>> >> Subject: Re: If is Evil
>> >> Hello!
>> >>
>> >> On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:
>> >>
>> >> > Приветы всем!
>> >> >
>> >> > Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не
>> >> > рекомендуется, и что использовать его там можно только в купе с
>> return
>> >> > или
>> >> > rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и
>> >> > почему.
>> >> >
>> >> > Пару рабочих дней было потрачено на то, чтобы разобраться, как оно
>> >> > работает. Но в итоге выяснилось, что сишку я уже неприлично
>> подзабыл, а
>> >> > все
>> >> > гуглы мира ведут на 3 ссылки:
>> >> >
>> >> >     http://wiki.nginx.org/IfIsEvil
>> >> >     http://habrahabr.ru/post/74135/
>> >> >
>> http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html
>> >> >
>> >> > Но в первой кроме лирики толком ничего не сказано, вторая просто с
>> >> > первого
>> >> > же примера плавит мозг, а в последней уже куда по-лучше, примеров
>> >> > несколько.. но все одно - какой принцип отработки не ясно(
>> >> >
>> >> > Ребят, может кто может подробно и последовательно разжевать, КАК это
>> >> > работает? А то пока получалось обходиться без if'ов, но кто его
>> знает,
>> >> > что
>> >> > будет завтра.. не хотелось бы оставить новый след от граблей, старый
>> >> > только
>> >> > вот зажил... да и выяснить причину раз и навсегда куда полезнее, чем
>> >> > просто
>> >> > запомнить постулат "скажем if в location - НЕТ"
>> >> >
>> >> > Буду признателен за любые ответы. Спасибо!
>> >>
>> >> В первую голову - надо уяснить для себя, что if создаёт вложенный
>> >> location.  И именно в этом location'е в результате будет обработан
>> >> запрос, если if выполнется.  Если таких if'ов много - то запрос
>> >> будет обработан в последнем if'е, который выполнится.  Поэтому
>> >> конфигурация вида
>> >>
>> >>     location / {
>> >>         set $true 1;
>> >>
>> >>         if ($true) {
>> >>             add_header X-Foo1 "bar";
>> >>         }
>> >>
>> >>         if ($true) {
>> >>             add_header X-Foo2 "bar";
>> >>         }
>> >>     }
>> >>
>> >> добавит только один заголовок, X-Foo2.  Эта особенность - что
>> >> называется, не баг, а фича.
>> >>
>> >> А дальше начинаются костыли, подпорки, и прочие нюансы, связанные,
>> >> в первую очередь, с тем, что if'ы, в отличие от обычных вложенных
>> >> location'ов, пытаются наследовать директивы, которые в норме не
>> >> наследуются во вложенные location'ы (e.g., proxy_pass).  Иногда
>> >> это получается, иногда - получается, но неправильно, иногда - не
>> >> получается вовсе.  Конкретные известные случаи нехорошего
>> >> поведения - коллекционируются на страничке IfIsEvil.
>> >>
>> >> --
>> >> Maxim Dounin
>> >> http://nginx.org/en/donation.html
>> >>
>> >>
>> >>
>> >>
>> >> ---------- Пересылаемое сообщение ----------
>> >> From: "Васильев \"Zmey!\" Олег" <zmey1992 at ya.ru>
>> >> To: "nginx-ru at nginx.org" <nginx-ru at nginx.org>
>> >> Cc:
>> >> Date: Mon, 02 Sep 2013 04:53:03 +0400
>> >> Subject: Re: If is Evil
>> >> Попытаюсь вклиниться в тему. Есть давно волнующий вопрос как раз на
>> ряду с
>> >> этими if-ами. Есть какой-то список директив, которые наследуются (или
>> не
>> >> наследуются) в location-ах из уровня выше и такой же для if-ов? Был бы
>> >> крайне полезный материал, т.к. в голове всё удержать не выходит.
>> >>
>> >> 02.09.2013, 03:42, "Maxim Dounin" <mdounin at mdounin.ru>:
>> >> > Hello!
>> >> >
>> >> > On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:
>> >> >
>> >> >>  Приветы всем!
>> >> >>
>> >> >>  Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не
>> >> >>  рекомендуется, и что использовать его там можно только в купе с
>> return
>> >> >> или
>> >> >>  rewrite..last, но - все же хочется разобраться, КАК он
>> отрабатывает и
>> >> >>  почему.
>> >> >>
>> >> >>  Пару рабочих дней было потрачено на то, чтобы разобраться, как оно
>> >> >>  работает. Но в итоге выяснилось, что сишку я уже неприлично
>> подзабыл,
>> >> >> а все
>> >> >>  гуглы мира ведут на 3 ссылки:
>> >> >>
>> >> >>      http://wiki.nginx.org/IfIsEvil
>> >> >>      http://habrahabr.ru/post/74135/
>> >> >>
>> >> >>
>> http://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html
>> >> >>
>> >> >>  Но в первой кроме лирики толком ничего не сказано, вторая просто с
>> >> >> первого
>> >> >>  же примера плавит мозг, а в последней уже куда по-лучше, примеров
>> >> >>  несколько.. но все одно - какой принцип отработки не ясно(
>> >> >>
>> >> >>  Ребят, может кто может подробно и последовательно разжевать, КАК
>> это
>> >> >>  работает? А то пока получалось обходиться без if'ов, но кто его
>> знает,
>> >> >> что
>> >> >>  будет завтра.. не хотелось бы оставить новый след от граблей,
>> старый
>> >> >> только
>> >> >>  вот зажил... да и выяснить причину раз и навсегда куда полезнее,
>> чем
>> >> >> просто
>> >> >>  запомнить постулат "скажем if в location - НЕТ"
>> >> >>
>> >> >>  Буду признателен за любые ответы. Спасибо!
>> >> >
>> >> > В первую голову - надо уяснить для себя, что if создаёт вложенный
>> >> > location.  И именно в этом location'е в результате будет обработан
>> >> > запрос, если if выполнется.  Если таких if'ов много - то запрос
>> >> > будет обработан в последнем if'е, который выполнится.  Поэтому
>> >> > конфигурация вида
>> >> >
>> >> >     location / {
>> >> >         set $true 1;
>> >> >
>> >> >         if ($true) {
>> >> >             add_header X-Foo1 "bar";
>> >> >         }
>> >> >
>> >> >         if ($true) {
>> >> >             add_header X-Foo2 "bar";
>> >> >         }
>> >> >     }
>> >> >
>> >> > добавит только один заголовок, X-Foo2.  Эта особенность - что
>> >> > называется, не баг, а фича.
>> >> >
>> >> > А дальше начинаются костыли, подпорки, и прочие нюансы, связанные,
>> >> > в первую очередь, с тем, что if'ы, в отличие от обычных вложенных
>> >> > location'ов, пытаются наследовать директивы, которые в норме не
>> >> > наследуются во вложенные location'ы (e.g., proxy_pass).  Иногда
>> >> > это получается, иногда - получается, но неправильно, иногда - не
>> >> > получается вовсе.  Конкретные известные случаи нехорошего
>> >> > поведения - коллекционируются на страничке IfIsEvil.
>> >> >
>> >> > --
>> >> > Maxim Dounin
>> >> > http://nginx.org/en/donation.html
>> >> >
>> >> > _______________________________________________
>> >> > nginx-ru mailing list
>> >> > nginx-ru at nginx.org
>> >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >>
>> >>
>> >>
>> >>
>> >> ---------- Пересылаемое сообщение ----------
>> >> From: Maxim Dounin <mdounin at mdounin.ru>
>> >> To: nginx-ru at nginx.org
>> >> Cc:
>> >> Date: Mon, 2 Sep 2013 05:16:01 +0400
>> >> Subject: Re: Неправильные (огромные) значения $request time для
>> >> FastCGI-запросов
>> >> Hello!
>> >>
>> >> On Sat, Aug 31, 2013 at 04:50:28PM -0400, sofiamay wrote:
>> >>
>> >> > А что, за год баг так и не исправили? Разрабы даже не удосужились
>> здесь
>> >> > отписаться? Баг хотябы в багтрекере висит?
>> >> > Подтверждаю, у меня тоже $request_time выдаёт бред:
>> >> >
>> >> > 240648971536.2381542
>> >> > 240648971536.2381542
>> >> > 240648971536.2381542
>> >> > 240648971536.2381542
>> >> > 240648971536.2381542
>> >> >
>> >> > Одно и то же для многих запросов подряд, потом опять на другой бред
>> >> > меняет!
>> >> > Когда это исправят? Зачем в Nginx сделана переменная $request_time
>> если
>> >> > она
>> >> > показывает всякий бред, мне думается её нужно убрать, а через
>> несколько
>> >> > лет,
>> >> > когда разрабы соизволят исправить баг, вернуть. Пока же от неё больше
>> >> > вреда
>> >> > чем пользы.
>> >> >
>> >> > P.S. Использую Windows и PHP как FastCGI.
>> >>
>> >> Я даже и не знаю, что вам сказать.  Привыкайте - это open source.
>> >> Тут вам никто ничего не должен, и править вылезающие у вас баги -
>> >> вам.  Надеяться, что кто-то придёт, и за вас исправит, тем более
>> >> на Windows - по меньшей мере наивно.
>> >>
>> >> Впрочем, патч:
>> >>
>> >> diff -r 683283f8b5fd src/http/modules/ngx_http_log_module.c
>> >> --- a/src/http/modules/ngx_http_log_module.c    Thu Aug 29 20:39:13
>> 2013
>> >> +0400
>> >> +++ b/src/http/modules/ngx_http_log_module.c    Mon Sep 02 04:38:34
>> 2013
>> >> +0400
>> >> @@ -780,7 +780,7 @@ ngx_http_log_request_time(ngx_http_reque
>> >>               ((tp->sec - r->start_sec) * 1000 + (tp->msec -
>> >> r->start_msec));
>> >>      ms = ngx_max(ms, 0);
>> >>
>> >> -    return ngx_sprintf(buf, "%T.%03M", ms / 1000, ms % 1000);
>> >> +    return ngx_sprintf(buf, "%T.%03M", (time_t) ms / 1000, ms % 1000);
>> >>  }
>> >>
>> >>
>> >> diff -r 683283f8b5fd src/http/ngx_http_variables.c
>> >> --- a/src/http/ngx_http_variables.c     Thu Aug 29 20:39:13 2013 +0400
>> >> +++ b/src/http/ngx_http_variables.c     Mon Sep 02 04:38:34 2013 +0400
>> >> @@ -1992,7 +1992,7 @@ ngx_http_variable_request_time(ngx_http_
>> >>               ((tp->sec - r->start_sec) * 1000 + (tp->msec -
>> >> r->start_msec));
>> >>      ms = ngx_max(ms, 0);
>> >>
>> >> -    v->len = ngx_sprintf(p, "%T.%03M", ms / 1000, ms % 1000) - p;
>> >> +    v->len = ngx_sprintf(p, "%T.%03M", (time_t) ms / 1000, ms % 1000)
>> -
>> >> p;
>> >>      v->valid = 1;
>> >>      v->no_cacheable = 0;
>> >>      v->not_found = 0;
>> >>
>> >> --
>> >> Maxim Dounin
>> >> http://nginx.org/en/donation.html
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> nginx-ru mailing list
>> >> nginx-ru at nginx.org
>> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >
>> >
>> >
>> > _______________________________________________
>> > nginx-ru mailing list
>> > nginx-ru at nginx.org
>> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130902/2f124b0e/attachment-0001.html>

From gmm at csdoc.com  Mon Sep  2 12:49:36 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Mon, 02 Sep 2013 15:49:36 +0300
Subject: true 414 status code
In-Reply-To: <201309020800.09622.vbart@nginx.com>
References: <CAMxcU5KYfpL-HzY6nWooFjZx0sFLmKXQYsicqLoddAxVUfA0Ng@mail.gmail.com>
 <201309010057.12473.ne@vbart.ru> <52233E0B.7020001@csdoc.com>
 <201309020800.09622.vbart@nginx.com>
Message-ID: <52248960.7030403@csdoc.com>

On 02.09.2013 7:00, Валентин Бартенев wrote:

 > JFYI, http://hg.nginx.org/nginx/rev/62be77b0608f

спасибо, теперь nginx стал еще лучше и удобнее.

-- 
Best regards,
  Gena


From vladget at gmail.com  Mon Sep  2 12:58:05 2013
From: vladget at gmail.com (Vladimir Getmanshchuk)
Date: Mon, 2 Sep 2013 15:58:05 +0300
Subject: true 414 status code
In-Reply-To: <52248960.7030403@csdoc.com>
References: <CAMxcU5KYfpL-HzY6nWooFjZx0sFLmKXQYsicqLoddAxVUfA0Ng@mail.gmail.com>
 <201309010057.12473.ne@vbart.ru> <52233E0B.7020001@csdoc.com>
 <201309020800.09622.vbart@nginx.com> <52248960.7030403@csdoc.com>
Message-ID: <CAMxcU5+eGLLoRB0GXa_b+FRx7goO1w_zeVKoqsanQukZOxs0cg@mail.gmail.com>

Здорово!

Но не повлияет ли это на производительность?

Спасибо!


2013/9/2 Gena Makhomed <gmm at csdoc.com>

> On 02.09.2013 7:00, Валентин Бартенев wrote:
>
> > JFYI, http://hg.nginx.org/nginx/rev/**62be77b0608f<http://hg.nginx.org/nginx/rev/62be77b0608f>
>
> спасибо, теперь nginx стал еще лучше и удобнее.
>
> --
> Best regards,
>  Gena
>
>
> ______________________________**_________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/**mailman/listinfo/nginx-ru<http://mailman.nginx.org/mailman/listinfo/nginx-ru>
>



-- 
Yours sincerely,
Vladimir Getmanshchuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130902/6b20f82c/attachment.html>

From vbart at nginx.com  Mon Sep  2 13:03:45 2013
From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Mon, 2 Sep 2013 17:03:45 +0400
Subject: true 414 status code
In-Reply-To: <CAMxcU5+eGLLoRB0GXa_b+FRx7goO1w_zeVKoqsanQukZOxs0cg@mail.gmail.com>
References: <CAMxcU5KYfpL-HzY6nWooFjZx0sFLmKXQYsicqLoddAxVUfA0Ng@mail.gmail.com>
 <52248960.7030403@csdoc.com>
 <CAMxcU5+eGLLoRB0GXa_b+FRx7goO1w_zeVKoqsanQukZOxs0cg@mail.gmail.com>
Message-ID: <201309021703.45220.vbart@nginx.com>

On Monday 02 September 2013 16:58:05 Vladimir Getmanshchuk wrote:
> Здорово!
> 
> Но не повлияет ли это на производительность?
> 
> Спасибо!
> 

Не повлияет.

--
Валентин Бартенев
http://nginx.org/en/donation.html

From nginx-forum at nginx.us  Mon Sep  2 21:05:40 2013
From: nginx-forum at nginx.us (GrooPER)
Date: Mon, 02 Sep 2013 17:05:40 -0400
Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDRgNCw0LfQvtCx0YDQsNGC0YzRgdGPINGBINC/0YA=?=
 =?UTF-8?B?0L7QstC10YDQutC+0Lkg0YDQtdGE0LXRgNCw?=
Message-ID: <3a4ebad111296b2828792b2457b1418d.NginxMailingListRussian@forum.nginx.org>

Не могу разобраться с проверкой реферера, что нужно: если реферер не с моего
сайта отдавать статику без jpg (он будет обрабатываться апачем бля наложения
ватермарка) если реферер с сайта то отдавать статику NGINXом включая и jpg 

мой код в конфиге:


		location * {
			valid_referers none blocked www.mysite.net www.mysite.net;
 
			if ($invalid_referer) {
				set $chek_referer
"jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf";
			}
			
			if (!-f $invalid_referer) {
				set $chek_referer
"jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf";
			}
		}
		
		location ~* ^.+\.($chek_referer)$ {
			root /var/www/user/data/www/img.mysite.net;
			access_log /var/www/httpd-logs/img.mysite.net.access.log ;
			access_log /var/www/nginx-logs/user isp;
		}

помогите разобраться

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


From admin at sysadmins.el.kg  Tue Sep  3 05:18:18 2013
From: admin at sysadmins.el.kg (admin at sysadmins.el.kg)
Date: Tue, 03 Sep 2013 11:18:18 +0600
Subject: =?UTF-8?B?0JDQtNCw0L/RgtCw0YbQuNGPINC/0YDQsNCy0LjQuyDRgNCw0LHQvtGC0LDRjtGJ?=
 =?UTF-8?B?0LjRhSDQsiBtb2RfcmV3cml0ZSDQtNC70Y8gbmdpbng=?=
In-Reply-To: <CAK1EO=VA9gpb3-+zDyAGffv4RQ=R2dw48ELzU-EZDsYm6Yu0mA@mail.gmail.com>
References: <mailman.2376.1378118521.22071.nginx-ru@nginx.org>
 <CAK1EO=VA9gpb3-+zDyAGffv4RQ=R2dw48ELzU-EZDsYm6Yu0mA@mail.gmail.com>
Message-ID: <5225711A.7090009@sysadmins.el.kg>

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

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

в httpd.conf:
RewriteMap  decode prg:/usr/local/etc/apache22/decode.pl

decode.pl - перловый скрипт, выправляющий закодированые части url, такие 
как слеши, пробелы и пр спецсимволы в читабельный и понимаемый mod_proxy 
вид:
#!/usr/bin/perl

use URI::Escape;

$| = 1;
while (<STDIN>) {

     print uri_unescape($_);
}

в .htaccess:
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} ^url=(.*)$ [NC]
RewriteRule .* ${decode:%1} [P,L,NE]

Можно-ли такую вот конструкцию реализовать в nginx и если да, то как?


From nginx-forum at nginx.us  Tue Sep  3 09:28:41 2013
From: nginx-forum at nginx.us (stitrace)
Date: Tue, 03 Sep 2013 05:28:41 -0400
Subject: =?UTF-8?B?0JrQsNC6INC+0YTQvtGA0LzQuNGC0Ywg0L/QvtC00L/QuNGB0LrRgyDQoNC+0YE=?=
 =?UTF-8?B?0YHQuNC50YHQutC+0LzRgyDRjtGALiDQu9C40YbRgz8=?=
Message-ID: <202346b7fb3b0dfcfd84f561a2452729.NginxMailingListRussian@forum.nginx.org>

Добрый день!

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

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


From maxim at nginx.com  Tue Sep  3 09:38:31 2013
From: maxim at nginx.com (Maxim Konovalov)
Date: Tue, 03 Sep 2013 13:38:31 +0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGE0L7RgNC80LjRgtGMINC/0L7QtNC/0LjRgdC60YMg0KA=?=
 =?UTF-8?B?0L7RgdGB0LjQudGB0LrQvtC80YMg0Y7RgC4g0LvQuNGG0YM/?=
In-Reply-To: <202346b7fb3b0dfcfd84f561a2452729.NginxMailingListRussian@forum.nginx.org>
References: <202346b7fb3b0dfcfd84f561a2452729.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5225AE17.2060807@nginx.com>

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

On 9/3/13 1:28 PM, stitrace wrote:
> Добрый день!
> 
> Расскажите пожалуйста, есть ли возможность оформить платную подписку
> российскому юр. лицу? То есть через договор, счета и прочее?
> 
На nginx.com есть форма для контакта с сейлзами, там вам ответят.

Если коротко, возможность есть, да.

-- 
Maxim Konovalov
http://nginx.com


From nginx-forum at nginx.us  Tue Sep  3 09:59:39 2013
From: nginx-forum at nginx.us (stitrace)
Date: Tue, 03 Sep 2013 05:59:39 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtGE0L7RgNC80LjRgtGMINC/0L7QtNC/0LjRgdC60YMg0KA=?=
 =?UTF-8?B?0L7RgdGB0LjQudGB0LrQvtC80YMg0Y7RgC4g0LvQuNGG0YM/?=
In-Reply-To: <5225AE17.2060807@nginx.com>
References: <5225AE17.2060807@nginx.com>
Message-ID: <be1297cbb5cd82a2cbdfa34eaf1d6535.NginxMailingListRussian@forum.nginx.org>

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

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


From nginx-forum at nginx.us  Tue Sep  3 14:26:47 2013
From: nginx-forum at nginx.us (ks2)
Date: Tue, 03 Sep 2013 10:26:47 -0400
Subject: =?UTF-8?B?0J3QtdGB0LrQvtC70YzQutC+INC30LDQv9C40YHQtdC5INC00LvRjyB1cHN0cmVh?=
 =?UTF-8?B?bSByZXNwb25zZSB0aW1lICg/KQ==?=
Message-ID: <175ff8b7388e873258eb3758c77dbbfc.NginxMailingListRussian@forum.nginx.org>

Добрый день,

Имею несколько серверов в апстриме, пишу аксесс лог
log_format foo '$time_local $status $connection $upstream_response_time
$request_time';

В логе вижу записи вида
03/Sep/2013:11:31:46 +0200 204 8889 0.065, 0.002 0.095
или
03/Sep/2013:11:31:46 +0200 204 6253 0.065, 0.065, 0.005 0.135

Почему тут записей больше, чем в спеке формата? nginx перебирает сервера в
апстриме?

Спасибо!

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


From vl at nginx.com  Tue Sep  3 14:38:24 2013
From: vl at nginx.com (Vladimir Homutov)
Date: Tue, 3 Sep 2013 18:38:24 +0400
Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDQt9Cw0L/QuNGB0LXQuSDQtNC70Y8gdXBz?=
 =?UTF-8?B?dHJlYW0gcmVzcG9uc2UgdGltZSAoPyk=?=
In-Reply-To: <175ff8b7388e873258eb3758c77dbbfc.NginxMailingListRussian@forum.nginx.org>
References: <175ff8b7388e873258eb3758c77dbbfc.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130903143823.GA1984@vlpc.i.nginx.com>

On Tue, Sep 03, 2013 at 10:26:47AM -0400, ks2 wrote:
> Добрый день,
>
> Имею несколько серверов в апстриме, пишу аксесс лог
> log_format foo '$time_local $status $connection $upstream_response_time
> $request_time';
>
> В логе вижу записи вида
> 03/Sep/2013:11:31:46 +0200 204 8889 0.065, 0.002 0.095
> или
> 03/Sep/2013:11:31:46 +0200 204 6253 0.065, 0.065, 0.005 0.135
>
> Почему тут записей больше, чем в спеке формата? nginx перебирает сервера в
> апстриме?
>
> Спасибо!

да, и записи разделены запятыми, см. описание $upstream_response_time
здесь:

http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#variables


From mdounin at mdounin.ru  Tue Sep  3 14:41:05 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 3 Sep 2013 18:41:05 +0400
Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDQt9Cw0L/QuNGB0LXQuSDQtNC70Y8gdXBz?=
 =?UTF-8?B?dHJlYW0gcmVzcG9uc2UgdGltZSAoPyk=?=
In-Reply-To: <175ff8b7388e873258eb3758c77dbbfc.NginxMailingListRussian@forum.nginx.org>
References: <175ff8b7388e873258eb3758c77dbbfc.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130903144105.GN65634@mdounin.ru>

Hello!

On Tue, Sep 03, 2013 at 10:26:47AM -0400, ks2 wrote:

> Добрый день,
> 
> Имею несколько серверов в апстриме, пишу аксесс лог
> log_format foo '$time_local $status $connection $upstream_response_time
> $request_time';
> 
> В логе вижу записи вида
> 03/Sep/2013:11:31:46 +0200 204 8889 0.065, 0.002 0.095
> или
> 03/Sep/2013:11:31:46 +0200 204 6253 0.065, 0.065, 0.005 0.135
> 
> Почему тут записей больше, чем в спеке формата? nginx перебирает сервера в
> апстриме?

Да, см. подробное описание тут:

http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#variables

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


From nginx-forum at nginx.us  Tue Sep  3 15:50:04 2013
From: nginx-forum at nginx.us (ks2)
Date: Tue, 03 Sep 2013 11:50:04 -0400
Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDQt9Cw0L/QuNGB0LXQuSDQtNC70Y8gdXBz?=
 =?UTF-8?B?dHJlYW0gcmVzcG9uc2UgdGltZSAoPyk=?=
In-Reply-To: <20130903144105.GN65634@mdounin.ru>
References: <20130903144105.GN65634@mdounin.ru>
Message-ID: <a97ca9ca9f9b3ce358dfaa95802f8022.NginxMailingListRussian@forum.nginx.org>

Всем спасибо, простите, что плохо умею читать.

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


From vladget at gmail.com  Tue Sep  3 18:28:38 2013
From: vladget at gmail.com (Vladimir Getmanshchuk)
Date: Tue, 3 Sep 2013 21:28:38 +0300
Subject: true 414 status code
In-Reply-To: <201309021703.45220.vbart@nginx.com>
References: <CAMxcU5KYfpL-HzY6nWooFjZx0sFLmKXQYsicqLoddAxVUfA0Ng@mail.gmail.com>
 <52248960.7030403@csdoc.com>
 <CAMxcU5+eGLLoRB0GXa_b+FRx7goO1w_zeVKoqsanQukZOxs0cg@mail.gmail.com>
 <201309021703.45220.vbart@nginx.com>
Message-ID: <CAMxcU5+1cdihgLXcyndyghuDFaJYHV04+84JNWK5dKPQjPEDpw@mail.gmail.com>

Все одно получаю 200й код.


2013/9/2 Валентин Бартенев <vbart at nginx.com>

> On Monday 02 September 2013 16:58:05 Vladimir Getmanshchuk wrote:
> > Здорово!
> >
> > Но не повлияет ли это на производительность?
> >
> > Спасибо!
> >
>
> Не повлияет.
>
> --
> Валентин Бартенев
> http://nginx.org/en/donation.html
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
Yours sincerely,
Vladimir Getmanshchuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130903/a4cd2e0a/attachment.html>

From nginx-forum at nginx.us  Tue Sep  3 23:25:33 2013
From: nginx-forum at nginx.us (npodesign)
Date: Tue, 03 Sep 2013 19:25:33 -0400
Subject: gzip_proxied
Message-ID: <5a80830a43b8b2ff35a0af00532debff.NginxMailingListRussian@forum.nginx.org>

Чем опасно ставить gzip_proxied в значение any?
Почему по умолчанию установлено значение off?
При значении any эффективность сжатия логично будет выше.

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


From sargaskn at gmail.com  Wed Sep  4 00:25:29 2013
From: sargaskn at gmail.com (Sargas)
Date: Wed, 4 Sep 2013 03:25:29 +0300
Subject: =?UTF-8?B?0JjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LUgdHJ5X2ZpbGVz?=
Message-ID: <CANA-tskXnMX4XQTGUs9SZJ9ZN_ytu4AEYb9Ukip6q6MpgjrKeA@mail.gmail.com>

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

Подскажите, пожалуйста как переписать апачевские реврайты

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)\.(php|html)$ /index.php?key=$1 [L,QSA]


на nginx/FastCGI с использованием try_files

В документации (http://sysoev.ru/nginx/docs/faq.html) есть пример с
именованным локейшеном

location / {
    try_files      $uri  $uri/  @drupal;
}

location @drupal {
    fastcgi_pass   ...;

    fastcgi_param  SCRIPT_FILENAME  /path/to/*index.php*;
    fastcgi_param  SCRIPT_NAME      /*index.php*;
    fastcgi_param  QUERY_STRING     *q=$uri&$args*;

    ... прочие fastcgi_param
}

Вопрос в том как в QUERY_STRING передать имя файла, но без его расширения
(php|html).

Чтобы работали подобные ссылки
http://www.example.com/channels.php  <=>
http://www.example.com/index.php?key=channels



И вопрос по директиве accept_mutex
http://nginx.org/ru/docs/ngx_core_module.html#accept_mutex
Судя по описанию выключать её не рекомендуется. А в какой ситуации может
понадобится её выключить? :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130904/e5e1e2c7/attachment.html>

From nginx-forum at nginx.us  Wed Sep  4 06:10:01 2013
From: nginx-forum at nginx.us (ks2)
Date: Wed, 04 Sep 2013 02:10:01 -0400
Subject: =?UTF-8?B?0KHQvtGB0YLQsNCy0L3QvtC5IHVwc3RyZWFtINCx0LXQtyDQv9C10YDQtdC90LA=?=
 =?UTF-8?B?0L/RgNCw0LLQu9C10L3QuNGPINC80LXQttC00YMg0YHQtdGA0LLQtdGA0LA=?=
 =?UTF-8?B?0LzQuA==?=
Message-ID: <8df72908ce7d236963043333273f5c6a.NginxMailingListRussian@forum.nginx.org>

Добрый день,

Имеем секцию апстрим из N серверов:
upstream foo {
  server a;
  server b;
  ...
}

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

location = /foo {
  fastcgi_pass  
  fastcgi_keep_conn on;
  include fastcgi-params.conf;

  fastcgi_read_timeout 75ms;
  fastcgi_intercept_errors on;
  error_page 500 501 502 503 504 = /foo_failover;
}

location = /foo_failover {
  root    /var/www;
}

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

Есть ли более элегантный способ сохранить балансировку нагрузки, но
запретить перенаправление, кроме как заводить N апстримов, каждый из одного
сервера, прописывать им отдельно fastcgi_read_timeout и error_page, а из
локейшена /foo, скажем, проксировать запрос на эти локейшены?

Спасибо!

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


From denis at webmaster.spb.ru  Wed Sep  4 09:39:12 2013
From: denis at webmaster.spb.ru (denis)
Date: Wed, 04 Sep 2013 13:39:12 +0400
Subject: =?UTF-8?B?UmU6INCR0LDQsyB0cnlfZmlsZXMgKyB2YWxpZF9yZWZlcmVycw==?=
In-Reply-To: <521F7F8A.7060409@kpi.ua>
References: <521F34B5.6000501@kpi.ua> <20130829120015.GF22852@mdounin.ru>
 <521F5317.2040203@kpi.ua> <20130829150724.GH22852@mdounin.ru>
 <521F7F8A.7060409@kpi.ua>
Message-ID: <5226FFC0.6050900@webmaster.spb.ru>

29.08.2013 21:06, Андрей Василишин пишет:
>         location @invalid {
>                 access_log  /var/log/nginx/site.com.invalid.log  main;
>                 root   /var/www/site.com;
>                 try_files $uri
>                 $uri/
>                 /index.php?q=$uri&$args;
>         }
насколько я помню, в конце лучше бы еще дописать =404;
и включить многократную обработку ошибок


From vladget at gmail.com  Wed Sep  4 09:54:18 2013
From: vladget at gmail.com (Vladimir Getmanshchuk)
Date: Wed, 4 Sep 2013 12:54:18 +0300
Subject: true 414 status code
In-Reply-To: <CAMxcU5+1cdihgLXcyndyghuDFaJYHV04+84JNWK5dKPQjPEDpw@mail.gmail.com>
References: <CAMxcU5KYfpL-HzY6nWooFjZx0sFLmKXQYsicqLoddAxVUfA0Ng@mail.gmail.com>
 <52248960.7030403@csdoc.com>
 <CAMxcU5+eGLLoRB0GXa_b+FRx7goO1w_zeVKoqsanQukZOxs0cg@mail.gmail.com>
 <201309021703.45220.vbart@nginx.com>
 <CAMxcU5+1cdihgLXcyndyghuDFaJYHV04+84JNWK5dKPQjPEDpw@mail.gmail.com>
Message-ID: <CAMxcU5JT-L2Pi9SD3uDq6380wSa2QS4tWYW-XGohWU4YmqYxCw@mail.gmail.com>

Даже идиотизм типа:

        error_page 414 =414 @414;

        location @414 {
          return 414;
        }
не дал результат - получаю 200

2013/09/04 09:40:10 [info] 5564#0: *45 client sent too long URI while
reading client request line, client: 123.123.123.123, server:
host.example.com, request: "GET
/file.php?qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwer
2013/09/04 09:40:10 [debug] 5564#0: *45 http finalize request: 414, "?"
a:1, c:1
2013/09/04 09:40:10 [debug] 5564#0: *45 event timer del: 15: 1378287669763
2013/09/04 09:40:10 [debug] 5564#0: *45 http special response: 414, "?"
2013/09/04 09:40:10 [debug] 5564#0: *45 test location: "@414"
2013/09/04 09:40:10 [debug] 5564#0: *45 using location: @414 "?"
2013/09/04 09:40:10 [debug] 5564#0: *45 rewrite phase: 3
2013/09/04 09:40:10 [debug] 5564#0: *45 http finalize request: 414, "?"
a:1, c:2
2013/09/04 09:40:10 [debug] 5564#0: *45 http special response: 414, "?"
2013/09/04 09:40:10 [debug] 5564#0: *45 http set discard body
2013/09/04 09:40:10 [debug] 5564#0: *45 xslt filter header
2013/09/04 09:40:10 [debug] 5564#0: *45 HTTP/1.1
Server: nginx/1.2.9
Date: Wed, 04 Sep 2013 09:40:10 GMT
Content-Type: text/html
Content-Length: 192
Connection: close



2013/9/3 Vladimir Getmanshchuk <vladget at gmail.com>

> Все одно получаю 200й код.
>
>
> 2013/9/2 Валентин Бартенев <vbart at nginx.com>
>
>> On Monday 02 September 2013 16:58:05 Vladimir Getmanshchuk wrote:
>> > Здорово!
>> >
>> > Но не повлияет ли это на производительность?
>> >
>> > Спасибо!
>> >
>>
>> Не повлияет.
>>
>> --
>> Валентин Бартенев
>> http://nginx.org/en/donation.html
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
>
> --
> Yours sincerely,
> Vladimir Getmanshchuk
>



-- 
Yours sincerely,
Vladimir Getmanshchuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130904/c534e739/attachment.html>

From mdounin at mdounin.ru  Wed Sep  4 10:28:11 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 4 Sep 2013 14:28:11 +0400
Subject: gzip_proxied
In-Reply-To: <5a80830a43b8b2ff35a0af00532debff.NginxMailingListRussian@forum.nginx.org>
References: <5a80830a43b8b2ff35a0af00532debff.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130904102810.GX65634@mdounin.ru>

Hello!

On Tue, Sep 03, 2013 at 07:25:33PM -0400, npodesign wrote:

> Чем опасно ставить gzip_proxied в значение any?
> Почему по умолчанию установлено значение off?
> При значении any эффективность сжатия логично будет выше.

Опасно тем, что прокси-сервер может не знать про то, что некоторые 
клиенты умеют gzip, а некоторые - не умеют.  Не говоря уже о том, 
что некоторые - говорят что умеют, а на самом деле - не умеют (см.  
директиву gzip_disabled).  В HTTP/1.1 проблема частично решается - 
с помощью заголовка Vary (см. gzip_vary).  Но это не решает 
проблемы у HTTP/1.0 клиентов/проксей, а таких до сих пор заметное 
количество.

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


From mdounin at mdounin.ru  Wed Sep  4 10:33:23 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 4 Sep 2013 14:33:23 +0400
Subject: =?UTF-8?B?UmU6INCh0L7RgdGC0LDQstC90L7QuSB1cHN0cmVhbSDQsdC10Lcg0L/QtdGA0LU=?=
 =?UTF-8?B?0L3QsNC/0YDQsNCy0LvQtdC90LjRjyDQvNC10LbQtNGDINGB0LXRgNCy0LU=?=
 =?UTF-8?B?0YDQsNC80Lg=?=
In-Reply-To: <8df72908ce7d236963043333273f5c6a.NginxMailingListRussian@forum.nginx.org>
References: <8df72908ce7d236963043333273f5c6a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130904103323.GY65634@mdounin.ru>

Hello!

On Wed, Sep 04, 2013 at 02:10:01AM -0400, ks2 wrote:

[...]

> Есть ли более элегантный способ сохранить балансировку нагрузки, но
> запретить перенаправление, кроме как заводить N апстримов, каждый из одного
> сервера, прописывать им отдельно fastcgi_read_timeout и error_page, а из
> локейшена /foo, скажем, проксировать запрос на эти локейшены?

http://nginx.org/r/fastcgi_next_upstream

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


From vbart at nginx.com  Wed Sep  4 10:51:01 2013
From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 4 Sep 2013 14:51:01 +0400
Subject: true 414 status code
In-Reply-To: <CAMxcU5JT-L2Pi9SD3uDq6380wSa2QS4tWYW-XGohWU4YmqYxCw@mail.gmail.com>
References: <CAMxcU5KYfpL-HzY6nWooFjZx0sFLmKXQYsicqLoddAxVUfA0Ng@mail.gmail.com>
 <CAMxcU5+1cdihgLXcyndyghuDFaJYHV04+84JNWK5dKPQjPEDpw@mail.gmail.com>
 <CAMxcU5JT-L2Pi9SD3uDq6380wSa2QS4tWYW-XGohWU4YmqYxCw@mail.gmail.com>
Message-ID: <201309041451.01947.vbart@nginx.com>

On Wednesday 04 September 2013 13:54:18 Vladimir Getmanshchuk wrote:
> Даже идиотизм типа:
> 
>         error_page 414 =414 @414;
> 
>         location @414 {
>           return 414;
>         }
> не дал результат - получаю 200
> 
> 2013/09/04 09:40:10 [info] 5564#0: *45 client sent too long URI while
> reading client request line, client: 123.123.123.123, server:
> host.example.com, request: "GET
> /file.php?qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasd
> fghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiop
> asdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyu
> iopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwer
> tyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmq
> wertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvb
> nmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzx
> cvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjk
> lzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfg
> hjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopas
> dfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuio
> pasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwerty
> uiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwe
> rtyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnm
> qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcv
> bnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklz
> xcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghj
> klzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdf
> ghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopa
> sdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyui
> opasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwert
> yuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqw
> ertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbn
> mqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxc
> vbnmqwertyuiopasdfghjklzxcvbnmqwer 2013/09/04 09:40:10 [debug] 5564#0: *45
> http finalize request: 414, "?" a:1, c:1
> 2013/09/04 09:40:10 [debug] 5564#0: *45 event timer del: 15: 1378287669763
> 2013/09/04 09:40:10 [debug] 5564#0: *45 http special response: 414, "?"
> 2013/09/04 09:40:10 [debug] 5564#0: *45 test location: "@414"
> 2013/09/04 09:40:10 [debug] 5564#0: *45 using location: @414 "?"
> 2013/09/04 09:40:10 [debug] 5564#0: *45 rewrite phase: 3
> 2013/09/04 09:40:10 [debug] 5564#0: *45 http finalize request: 414, "?"
> a:1, c:2
> 2013/09/04 09:40:10 [debug] 5564#0: *45 http special response: 414, "?"
> 2013/09/04 09:40:10 [debug] 5564#0: *45 http set discard body
> 2013/09/04 09:40:10 [debug] 5564#0: *45 xslt filter header
> 2013/09/04 09:40:10 [debug] 5564#0: *45 HTTP/1.1
> Server: nginx/1.2.9
> Date: Wed, 04 Sep 2013 09:40:10 GMT
> Content-Type: text/html
> Content-Length: 192
> Connection: close
> 
[..]

Это не 200, а просто невалидный ответ.  Патч, исправляющий проблему, уже лежит
на ревью: http://mailman.nginx.org/pipermail/nginx-devel/2013-April/003609.html

Плюс вдогонку ещё один:

# HG changeset patch
# User Valentin Bartenev <vbart at nginx.com>
# Date 1378228039 -14400
# Node ID 9f8ebfbe04f28544fd9cfc1473679aee13202506
# Parent  659464c695b7c70f64207462d0e1a4ee3d018583
Return reason phrase for 414.

After 62be77b0608f nginx can return this code.

diff -r 659464c695b7 -r 9f8ebfbe04f2 src/http/ngx_http_header_filter_module.c
--- a/src/http/ngx_http_header_filter_module.c  Mon Sep 02 20:06:03 2013 +0400
+++ b/src/http/ngx_http_header_filter_module.c  Tue Sep 03 21:07:19 2013 +0400
@@ -92,10 +92,7 @@ static ngx_str_t ngx_http_status_lines[]
     ngx_string("411 Length Required"),
     ngx_string("412 Precondition Failed"),
     ngx_string("413 Request Entity Too Large"),
-    ngx_null_string,  /* "414 Request-URI Too Large", but we never send it
-                       * because we treat such requests as the HTTP/0.9
-                       * requests and send only a body without a header
-                       */
+    ngx_string("414 Request-URI Too Large"),
     ngx_string("415 Unsupported Media Type"),
     ngx_string("416 Requested Range Not Satisfiable"),
 

--
Валентин


From vbart at nginx.com  Wed Sep  4 10:56:36 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Wed, 4 Sep 2013 14:56:36 +0400
Subject: =?UTF-8?B?UmU6INCR0LDQsyB0cnlfZmlsZXMgKyB2YWxpZF9yZWZlcmVycw==?=
In-Reply-To: <5226FFC0.6050900@webmaster.spb.ru>
References: <521F34B5.6000501@kpi.ua> <521F7F8A.7060409@kpi.ua>
 <5226FFC0.6050900@webmaster.spb.ru>
Message-ID: <201309041456.36464.vbart@nginx.com>

On Wednesday 04 September 2013 13:39:12 denis wrote:
> 29.08.2013 21:06, Андрей Василишин пишет:
> >         location @invalid {
> >                 access_log  /var/log/nginx/site.com.invalid.log  main;
> >                 root   /var/www/site.com;
> >                 try_files $uri
> >                 $uri/
> >                 /index.php?q=$uri&$args;
> >         }
> 
> насколько я помню, в конце лучше бы еще дописать =404;
> и включить многократную обработку ошибок
> 

Если дописать "=404" - то всё сломается, поскольку /index.php?q=$uri&$args 
перестанет быть перенаправлением.

Читаем внимательно: http://nginx.org/r/try_files/ru

--
Валентин Бартенев
http://nginx.org/en/donation.html

From nginx-forum at nginx.us  Wed Sep  4 13:34:02 2013
From: nginx-forum at nginx.us (ks2)
Date: Wed, 04 Sep 2013 09:34:02 -0400
Subject: =?UTF-8?B?UmU6INCh0L7RgdGC0LDQstC90L7QuSB1cHN0cmVhbSDQsdC10Lcg0L/QtdGA0LU=?=
 =?UTF-8?B?0L3QsNC/0YDQsNCy0LvQtdC90LjRjyDQvNC10LbQtNGDINGB0LXRgNCy0LU=?=
 =?UTF-8?B?0YDQsNC80Lg=?=
In-Reply-To: <20130904103323.GY65634@mdounin.ru>
References: <20130904103323.GY65634@mdounin.ru>
Message-ID: <cb2c8437bb4c6801468c6766d850846c.NginxMailingListRussian@forum.nginx.org>

Отлично, спасибо, Максим!

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


From nginx-forum at nginx.us  Wed Sep  4 13:47:18 2013
From: nginx-forum at nginx.us (ks2)
Date: Wed, 04 Sep 2013 09:47:18 -0400
Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDQt9Cw0L/QuNGB0LXQuSDQtNC70Y8gdXBz?=
 =?UTF-8?B?dHJlYW0gcmVzcG9uc2UgdGltZSAoPyk=?=
In-Reply-To: <a97ca9ca9f9b3ce358dfaa95802f8022.NginxMailingListRussian@forum.nginx.org>
References: <20130903144105.GN65634@mdounin.ru>
 <a97ca9ca9f9b3ce358dfaa95802f8022.NginxMailingListRussian@forum.nginx.org>
Message-ID: <f3582d285868da8ddbf0431c39d1a4e5.NginxMailingListRussian@forum.nginx.org>

Разрешите задать еще один вопрос:

В логе есть такие записи:
04/Sep/2013:15:12:00 +0200 499 725974 - 5.004

(Формат лога, напомню
log_format foo '$time_local $status $connection $upstream_response_time
$request_time';)

Для локейшена сейчас прописано:
fastcgi_read_timeout 75ms;
fastcgi_intercept_errors on;
fastcgi_next_upstream off;
error_page 500 501 502 503 504 = /failover; # возвращает 204

Значит ли такая запись (5.004), что клиент реально ждал 5 секунд и отвалился
по таймауту? Как же тогда настройка fastcgi_read_timeout 75ms? Не должна ли
она отдать клиенту статус 204 значительно раньше?

Спасибо!

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


From mdounin at mdounin.ru  Wed Sep  4 14:09:57 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 4 Sep 2013 18:09:57 +0400
Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDQt9Cw0L/QuNGB0LXQuSDQtNC70Y8gdXBz?=
 =?UTF-8?B?dHJlYW0gcmVzcG9uc2UgdGltZSAoPyk=?=
In-Reply-To: <f3582d285868da8ddbf0431c39d1a4e5.NginxMailingListRussian@forum.nginx.org>
References: <20130903144105.GN65634@mdounin.ru>
 <a97ca9ca9f9b3ce358dfaa95802f8022.NginxMailingListRussian@forum.nginx.org>
 <f3582d285868da8ddbf0431c39d1a4e5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130904140957.GC65634@mdounin.ru>

Hello!

On Wed, Sep 04, 2013 at 09:47:18AM -0400, ks2 wrote:

> Разрешите задать еще один вопрос:
> 
> В логе есть такие записи:
> 04/Sep/2013:15:12:00 +0200 499 725974 - 5.004
> 
> (Формат лога, напомню
> log_format foo '$time_local $status $connection $upstream_response_time
> $request_time';)
> 
> Для локейшена сейчас прописано:
> fastcgi_read_timeout 75ms;
> fastcgi_intercept_errors on;
> fastcgi_next_upstream off;
> error_page 500 501 502 503 504 = /failover; # возвращает 204
> 
> Значит ли такая запись (5.004), что клиент реально ждал 5 секунд и отвалился
> по таймауту? Как же тогда настройка fastcgi_read_timeout 75ms? Не должна ли
> она отдать клиенту статус 204 значительно раньше?

Судя по отсутствию $upstream_response_time - на бекенд вообще 
не ходили.  Исходя из кода 499 - вероятно какой-нибудь limit_req 
держал клиента, и он устал ждать.

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


From nginx-forum at nginx.us  Wed Sep  4 15:52:02 2013
From: nginx-forum at nginx.us (ks2)
Date: Wed, 04 Sep 2013 11:52:02 -0400
Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDQt9Cw0L/QuNGB0LXQuSDQtNC70Y8gdXBz?=
 =?UTF-8?B?dHJlYW0gcmVzcG9uc2UgdGltZSAoPyk=?=
In-Reply-To: <20130904140957.GC65634@mdounin.ru>
References: <20130904140957.GC65634@mdounin.ru>
Message-ID: <78fa6e0f85e661263d517e40168bfaa2.NginxMailingListRussian@forum.nginx.org>

Странно, я добавил в log_format переменную $upstream_addr и ровно во всех
строчках лога, содержащих код 499, вижу упоминание об адресе одного из
серверов, перечисленных в секции апстрима, из чего я делаю вывод, что на
сервер все же ходили.

Также странно, что нет ровно ни одного упоминания о переадресации на
локейшен /failover, о чем сказано в доке ("Если произошло внутреннее
перенаправление... с помощью ...error_page").

Директивы limit_req в наших конфигах нет.

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


From mdounin at mdounin.ru  Wed Sep  4 16:49:41 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 4 Sep 2013 20:49:41 +0400
Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDQt9Cw0L/QuNGB0LXQuSDQtNC70Y8gdXBz?=
 =?UTF-8?B?dHJlYW0gcmVzcG9uc2UgdGltZSAoPyk=?=
In-Reply-To: <78fa6e0f85e661263d517e40168bfaa2.NginxMailingListRussian@forum.nginx.org>
References: <20130904140957.GC65634@mdounin.ru>
 <78fa6e0f85e661263d517e40168bfaa2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130904164941.GG65634@mdounin.ru>

Hello!

On Wed, Sep 04, 2013 at 11:52:02AM -0400, ks2 wrote:

> Странно, я добавил в log_format переменную $upstream_addr и ровно во всех
> строчках лога, содержащих код 499, вижу упоминание об адресе одного из
> серверов, перечисленных в секции апстрима, из чего я делаю вывод, что на
> сервер все же ходили.

Значит, видимо, не дошли.  С учётом выставленного таймаута на 
чтение - такое может быть, если клиент устал ждать в процессе 
соединения с бекендом, тюнить fastcgi_connect_timeout.

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


From nginx-forum at nginx.us  Wed Sep  4 18:52:23 2013
From: nginx-forum at nginx.us (npodesign)
Date: Wed, 04 Sep 2013 14:52:23 -0400
Subject: gzip_proxied
In-Reply-To: <20130904102810.GX65634@mdounin.ru>
References: <20130904102810.GX65634@mdounin.ru>
Message-ID: <6afa4a83ec85480490cf643e7371646b.NginxMailingListRussian@forum.nginx.org>

Спасибо.

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


From nginx-forum at nginx.us  Thu Sep  5 13:24:41 2013
From: nginx-forum at nginx.us (Alexander Platonov)
Date: Thu, 05 Sep 2013 09:24:41 -0400
Subject: =?UTF-8?B?0L3QtSDQvtGC0LTQsNC10YLRgdGPIC5neiDRh9C10YDQtdC3INC/0YDQvtC60YE=?=
 =?UTF-8?B?0Lgg0L3QsCBuZ2lueA==?=
Message-ID: <e263a5a33b3ed3e2ae9539c54ccacc19.NginxMailingListRussian@forum.nginx.org>

Дорбрый день.

Помогите, пожалуйста, разобраться с отдачей .gz с помощью gzip_static on
Почему через прокси не работает?

Есть 2 сервера, uname -a:
FreeBSD front-end 9.1-RELEASE-p4
FreeBSD bsddb 9.1-RELEASE-p5

front-end имеет реальный ip адрес и проксирует на внутренний сервер bsddb
запросы, пробросил с старого сайта
страничку: http://lingvopro-dev.abbyy-ls.com/index.htm и рядом положил
предварительно сжатый index.htm.gz, изменил исходный index.htm, теперь если
прописываю в hosts адрес bsddb, то отдается сжатый файл, если адрес прокси,
то отдается index.htm

Если брать другой внутренний сервер, то поведение аналогично.

конфиг front-end:
http {
        include       mime.types;
        default_type  application/octet-stream;

        keepalive_timeout       20 15;
        send_timeout            5m;
        proxy_read_timeout      300;

        sendfile        on;
        aio             sendfile;
        server_tokens   off;

        client_body_buffer_size 10m;
        client_max_body_size    10m;

        proxy_buffers           512 32k;
        proxy_cache_path        /var/nginx-cache  levels=1     
keys_zone=nginx-cache:8m        inactive=2d;
        proxy_cache_key        
$scheme+$host+$request_uri+$http_accept_encoding;
        proxy_cache             off;
        gzip_proxied any;

        upstream backend-test {
                server 10.16.2.152      fail_timeout=5m;
        }
        ######### some other servers ##########
        server {
                server_name  lingvopro-dev.abbyy-ls.com;
                location        / {
                        proxy_pass      http://backend-test;
                        proxy_set_header Host $http_host;
                }
        }

конфиг bsddb:
worker_processes        auto;
timer_resolution        100ms;
worker_rlimit_nofile    8192;
worker_priority         -5;
pid                     /var/run/nginx.pid;
error_log               /var/log/nginx/error.log warn;
events {
  worker_connections  1024;
  use kqueue;
}

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

    client_body_buffer_size         16k;
    client_max_body_size            10m;
    proxy_read_timeout              60;
    proxy_send_timeout              60;
    proxy_buffers                   64 16k;
    send_timeout                    60;
    server_names_hash_bucket_size   512;
    keepalive_timeout               15 10;

    reset_timedout_connection  on;
    sendfile                on;
    aio            sendfile;
    tcp_nopush      on;
    tcp_nodelay on;
    directio 10m;

    gzip                    on;
    gzip_static             on;
    gzip_proxied            any;
    gzip_vary               on;
    gzip_http_version       1.1;
    gzip_min_length         1100;
    gzip_buffers            64 16k;
    gzip_comp_level         4;
    gzip_types text/plain text/css application/json \
        application/x-javascript text/xml application/xml
application/xml+rss text/javascript application/javascript text/x-js;
    expires  5m;
    ##
    # File Cache Settings
    ##
    open_file_cache          max=5000  inactive=20s;
    open_file_cache_valid    30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors   on;

    fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=microcache:10m
max_size=1000m inactive=60m;

   server {
        server_name  lingvopro-dev.abbyy-ls.com;
        root   /usr/local/www/abbyy-ls/cache/normal/abbyy-ls.com/;
        charset utf8;
        gzip_static on;
    }

Александр Платонов

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


From vbart at nginx.com  Thu Sep  5 14:09:49 2013
From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 5 Sep 2013 18:09:49 +0400
Subject: =?UTF-8?B?UmU6ICDQvdC1INC+0YLQtNCw0LXRgtGB0Y8gLmd6INGH0LXRgNC10Lcg0L/RgNC+?=
 =?UTF-8?B?0LrRgdC4INC90LAgbmdpbng=?=
In-Reply-To: <e263a5a33b3ed3e2ae9539c54ccacc19.NginxMailingListRussian@forum.nginx.org>
References: <e263a5a33b3ed3e2ae9539c54ccacc19.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201309051809.49053.vbart@nginx.com>

On Thursday 05 September 2013 17:24:41 Alexander Platonov wrote:
> Дорбрый день.
> 
> Помогите, пожалуйста, разобраться с отдачей .gz с помощью gzip_static on
> Почему через прокси не работает?
> 
[..]

Читаем: http://nginx.org/r/gzip_static/ru

 | Разрешает (?on?) или запрещает (?off?) проверку готового сжатого файла. При
 | использовании также учитываются директивы gzip_http_version, gzip_proxied,
 | gzip_disable и gzip_vary.

Далее: http://nginx.org/r/gzip_http_version/ru

 | Устанавливает минимальную HTTP-версию запроса, необходимую для сжатия ответа.

Какая версия HTTP при запросе front-end -> bsddb? Читаем: 
http://nginx.org/r/proxy_http_version/ru

 | Задаёт версию протокола HTTP для проксирования. По умолчанию используется
 | версия 1.0. 

--
Валентин Бартенев
http://nginx.org/en/donation.html

From sargaskn at gmail.com  Fri Sep  6 04:57:04 2013
From: sargaskn at gmail.com (Sargas)
Date: Fri, 6 Sep 2013 07:57:04 +0300
Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1IHRyeV9maWxlcw==?=
In-Reply-To: <CANA-tskXnMX4XQTGUs9SZJ9ZN_ytu4AEYb9Ukip6q6MpgjrKeA@mail.gmail.com>
References: <CANA-tskXnMX4XQTGUs9SZJ9ZN_ytu4AEYb9Ukip6q6MpgjrKeA@mail.gmail.com>
Message-ID: <CANA-tskQh6vH=uzbSYeBvf2heuksBnOHHbDU6Km4j2+GZNn52Q@mail.gmail.com>

Сейчас используется

if (!-e $request_filename) {
 rewrite ^/(.*)\.(php|html)$ /index.php?key=$1 break;
}

Хочется без if'а



4 сентября 2013 г., 3:25 пользователь Sargas <sargaskn at gmail.com> написал:

> Приветствую.
>
> Подскажите, пожалуйста как переписать апачевские реврайты
>
> RewriteCond %{REQUEST_FILENAME} !-d
> RewriteCond %{REQUEST_FILENAME} !-f
> RewriteRule ^(.*)\.(php|html)$ /index.php?key=$1 [L,QSA]
>
>
> на nginx/FastCGI с использованием try_files
>
> В документации (http://sysoev.ru/nginx/docs/faq.html) есть пример с
> именованным локейшеном
>
> location / {
>     try_files      $uri  $uri/  @drupal;
> }
>
> location @drupal {
>     fastcgi_pass   ...;
>
>     fastcgi_param  SCRIPT_FILENAME  /path/to/*index.php*;
>     fastcgi_param  SCRIPT_NAME      /*index.php*;
>     fastcgi_param  QUERY_STRING     *q=$uri&$args*;
>
>     ... прочие fastcgi_param
> }
>
> Вопрос в том как в QUERY_STRING передать имя файла, но без его расширения
> (php|html).
>
> Чтобы работали подобные ссылки
> http://www.example.com/channels.php  <=>
> http://www.example.com/index.php?key=channels
>
>
>
> И вопрос по директиве accept_mutex
> http://nginx.org/ru/docs/ngx_core_module.html#accept_mutex
> Судя по описанию выключать её не рекомендуется. А в какой ситуации может
> понадобится её выключить? :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130906/d195452f/attachment.html>

From nginx-forum at nginx.us  Fri Sep  6 05:48:02 2013
From: nginx-forum at nginx.us (Alexander Platonov)
Date: Fri, 06 Sep 2013 01:48:02 -0400
Subject: =?UTF-8?B?UmU6INC90LUg0L7RgtC00LDQtdGC0YHRjyAuZ3og0YfQtdGA0LXQtyDQv9GA0L4=?=
 =?UTF-8?B?0LrRgdC4INC90LAgbmdpbng=?=
In-Reply-To: <201309051809.49053.vbart@nginx.com>
References: <201309051809.49053.vbart@nginx.com>
Message-ID: <2360ea8fb59bf6b17d179e9b0abc3d7b.NginxMailingListRussian@forum.nginx.org>

Валентин, большое спасибо, все понятно.

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


From vladget at gmail.com  Fri Sep  6 07:49:13 2013
From: vladget at gmail.com (Vladimir Getmanshchuk)
Date: Fri, 6 Sep 2013 10:49:13 +0300
Subject: true 414 status code
In-Reply-To: <201309041451.01947.vbart@nginx.com>
References: <CAMxcU5KYfpL-HzY6nWooFjZx0sFLmKXQYsicqLoddAxVUfA0Ng@mail.gmail.com>
 <CAMxcU5+1cdihgLXcyndyghuDFaJYHV04+84JNWK5dKPQjPEDpw@mail.gmail.com>
 <CAMxcU5JT-L2Pi9SD3uDq6380wSa2QS4tWYW-XGohWU4YmqYxCw@mail.gmail.com>
 <201309041451.01947.vbart@nginx.com>
Message-ID: <CAMxcU5LtbUcKb75Y8dceG65xOr+zx-8xV+HJEkgtwhoK3RSF-A@mail.gmail.com>

Спасибо починилось.
Пусть тут полежит:

--- src/http/ngx_http_header_filter_module.c.orig 2013-05-13
10:43:28.000000000 +0000
+++ src/http/ngx_http_header_filter_module.c 2013-09-05 14:37:15.011369647
+0000
@@ -92,10 +92,7 @@
     ngx_string("411 Length Required"),
     ngx_string("412 Precondition Failed"),
     ngx_string("413 Request Entity Too Large"),
-    ngx_null_string,  /* "414 Request-URI Too Large", but we never send it
-                       * because we treat such requests as the HTTP/0.9
-                       * requests and send only a body without a header
-                       */
+    ngx_string("414 Request-URI Too Large"),
     ngx_string("415 Unsupported Media Type"),
     ngx_string("416 Requested Range Not Satisfiable"),

@@ -270,6 +267,12 @@
             len += NGX_INT_T_LEN;
             status_line = NULL;
         }
+
+        if (status_line && status_line->len == 0) {
+            status = r->headers_out.status;
+            len += NGX_INT_T_LEN;
+            status_line = NULL;
+        }
     }

     clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);


On Wed, Sep 4, 2013 at 1:51 PM, Валентин Бартенев <vbart at nginx.com> wrote:

> On Wednesday 04 September 2013 13:54:18 Vladimir Getmanshchuk wrote:
> > Даже идиотизм типа:
> >
> >         error_page 414 =414 @414;
> >
> >         location @414 {
> >           return 414;
> >         }
> > не дал результат - получаю 200
> >
> > 2013/09/04 09:40:10 [info] 5564#0: *45 client sent too long URI while
> > reading client request line, client: 123.123.123.123, server:
> > host.example.com, request: "GET
> >
> /file.php?qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasd
> >
> fghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiop
> >
> asdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyu
> >
> iopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwer
> >
> tyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmq
> >
> wertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvb
> >
> nmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzx
> >
> cvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjk
> >
> lzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfg
> >
> hjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopas
> >
> dfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuio
> >
> pasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwerty
> >
> uiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwe
> >
> rtyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnm
> >
> qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcv
> >
> bnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklz
> >
> xcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghj
> >
> klzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdf
> >
> ghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopa
> >
> sdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyui
> >
> opasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwert
> >
> yuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqw
> >
> ertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbn
> >
> mqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxc
> > vbnmqwertyuiopasdfghjklzxcvbnmqwer 2013/09/04 09:40:10 [debug] 5564#0:
> *45
> > http finalize request: 414, "?" a:1, c:1
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 event timer del: 15:
> 1378287669763
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 http special response: 414, "?"
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 test location: "@414"
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 using location: @414 "?"
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 rewrite phase: 3
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 http finalize request: 414, "?"
> > a:1, c:2
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 http special response: 414, "?"
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 http set discard body
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 xslt filter header
> > 2013/09/04 09:40:10 [debug] 5564#0: *45 HTTP/1.1
> > Server: nginx/1.2.9
> > Date: Wed, 04 Sep 2013 09:40:10 GMT
> > Content-Type: text/html
> > Content-Length: 192
> > Connection: close
> >
> [..]
>
> Это не 200, а просто невалидный ответ.  Патч, исправляющий проблему, уже
> лежит
> на ревью:
> http://mailman.nginx.org/pipermail/nginx-devel/2013-April/003609.html
>
> Плюс вдогонку ещё один:
>
> # HG changeset patch
> # User Valentin Bartenev <vbart at nginx.com>
> # Date 1378228039 -14400
> # Node ID 9f8ebfbe04f28544fd9cfc1473679aee13202506
> # Parent  659464c695b7c70f64207462d0e1a4ee3d018583
> Return reason phrase for 414.
>
> After 62be77b0608f nginx can return this code.
>
> diff -r 659464c695b7 -r 9f8ebfbe04f2
> src/http/ngx_http_header_filter_module.c
> --- a/src/http/ngx_http_header_filter_module.c  Mon Sep 02 20:06:03 2013
> +0400
> +++ b/src/http/ngx_http_header_filter_module.c  Tue Sep 03 21:07:19 2013
> +0400
> @@ -92,10 +92,7 @@ static ngx_str_t ngx_http_status_lines[]
>      ngx_string("411 Length Required"),
>      ngx_string("412 Precondition Failed"),
>      ngx_string("413 Request Entity Too Large"),
> -    ngx_null_string,  /* "414 Request-URI Too Large", but we never send it
> -                       * because we treat such requests as the HTTP/0.9
> -                       * requests and send only a body without a header
> -                       */
> +    ngx_string("414 Request-URI Too Large"),
>      ngx_string("415 Unsupported Media Type"),
>      ngx_string("416 Requested Range Not Satisfiable"),
>
>
> --
> Валентин
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
Yours sincerely,
Vladimir Getmanshchuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130906/5ae9fc93/attachment-0001.html>

From alexander.moskalenko at gmail.com  Fri Sep  6 07:55:10 2013
From: alexander.moskalenko at gmail.com (Alexander Moskalenko)
Date: Fri, 6 Sep 2013 10:55:10 +0300
Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1IHRyeV9maWxlcw==?=
In-Reply-To: <CANA-tskQh6vH=uzbSYeBvf2heuksBnOHHbDU6Km4j2+GZNn52Q@mail.gmail.com>
References: <CANA-tskXnMX4XQTGUs9SZJ9ZN_ytu4AEYb9Ukip6q6MpgjrKeA@mail.gmail.com>
 <CANA-tskQh6vH=uzbSYeBvf2heuksBnOHHbDU6Km4j2+GZNn52Q@mail.gmail.com>
Message-ID: <CACVfVFuATPtXEsWaD3G=Rj4dxMtZbLAk+oCM-BbQp_P5+bwm3Q@mail.gmail.com>

location "^/(?<filename>.*)\.(php|html)$" {

    fastcgi_pass   ...;

    fastcgi_param  SCRIPT_FILENAME  /path/to/index.php;
    fastcgi_param  SCRIPT_NAME      /index.php;
    fastcgi_param  QUERY_STRING     key=$filename;

}

2013/9/6 Sargas <sargaskn at gmail.com>:
> Сейчас используется
>
> if (!-e $request_filename) {
>  rewrite ^/(.*)\.(php|html)$ /index.php?key=$1 break;
> }
>
> Хочется без if'а
>
>
>
> 4 сентября 2013 г., 3:25 пользователь Sargas <sargaskn at gmail.com> написал:
>
>> Приветствую.
>>
>> Подскажите, пожалуйста как переписать апачевские реврайты
>>
>> RewriteCond %{REQUEST_FILENAME} !-d
>> RewriteCond %{REQUEST_FILENAME} !-f
>> RewriteRule ^(.*)\.(php|html)$ /index.php?key=$1 [L,QSA]
>>
>>
>> на nginx/FastCGI с использованием try_files
>>
>> В документации (http://sysoev.ru/nginx/docs/faq.html) есть пример с
>> именованным локейшеном
>>
>> location / {
>>     try_files      $uri  $uri/  @drupal;
>> }
>>
>> location @drupal {
>>     fastcgi_pass   ...;
>>
>>     fastcgi_param  SCRIPT_FILENAME  /path/to/index.php;
>>     fastcgi_param  SCRIPT_NAME      /index.php;
>>     fastcgi_param  QUERY_STRING     q=$uri&$args;
>>
>>     ... прочие fastcgi_param
>> }
>>
>> Вопрос в том как в QUERY_STRING передать имя файла, но без его расширения
>> (php|html).
>>
>> Чтобы работали подобные ссылки
>> http://www.example.com/channels.php  <=>
>> http://www.example.com/index.php?key=channels
>>
>>
>>
>> И вопрос по директиве accept_mutex
>> http://nginx.org/ru/docs/ngx_core_module.html#accept_mutex
>> Судя по описанию выключать её не рекомендуется. А в какой ситуации может
>> понадобится её выключить? :)
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Fri Sep  6 08:50:27 2013
From: nginx-forum at nginx.us (valch85)
Date: Fri, 06 Sep 2013 04:50:27 -0400
Subject: =?UTF-8?B?MjAwINC+0YLQstC10YIg0L/RgNC4INC+0YLRgdGD0YLRgdCy0LjQuCDRhNCw0Lk=?=
 =?UTF-8?B?0LvQsA==?=
Message-ID: <4dca8bd037b982aecaf2d8d054a1204e.NginxMailingListRussian@forum.nginx.org>

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

Пытаюсь настроить nginx для wordpress (использование в сабдиректории)

location /blog2 {
access_log /data0/logs/nginx/blog_log blog2;
error_log /var/log/nginx/test.log debug;
index index.php;
root /var/www/blog2.site.com;
try_files $uri $uri/ /blog2/index.php?$args;
location ~ \.php$ {

fastcgi_pass 127.0.0.1:9000;
fastcgi_split_path_info ^(/blog2)(/.*)$;
fastcgi_index index.php;
fastcgi_intercept_errors on;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires max;
log_not_found off;
}
}

при этом получаю 200 ответ на любой мой запрос
напримет http://www.site.com/blog2/luboizapros


2 проблема, которую видно из логов, это то что nginx пытается найти файлы в
/var/www/blog2.site.com/blog2

256.256.256.256 - - [05/Sep/2013:11:57:34 +0000] "GET /blog2/index.php
HTTP/1.1" 200 226 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.65 Safari/537.36"
"0.00"
256.256.256.256 - - [05/Sep/2013:11:57:40 +0000] "GET /blog2 HTTP/1.1" 200
226 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/29.0.1547.65 Safari/537.36" "0.00"


подскажите pls что это или куда стоит обратить внимание для решения проблемы
?

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


From onokonem at gmail.com  Fri Sep  6 08:59:52 2013
From: onokonem at gmail.com (Daniel Podolsky)
Date: Fri, 6 Sep 2013 12:59:52 +0400
Subject: =?UTF-8?B?UmU6IDIwMCDQvtGC0LLQtdGCINC/0YDQuCDQvtGC0YHRg9GC0YHQstC40Lgg0YQ=?=
 =?UTF-8?B?0LDQudC70LA=?=
In-Reply-To: <4dca8bd037b982aecaf2d8d054a1204e.NginxMailingListRussian@forum.nginx.org>
References: <4dca8bd037b982aecaf2d8d054a1204e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKaHDOEXb9v_Hkw8Wh=anRKOaw0aL_yuagZAzR05mLZ6-=xKeQ@mail.gmail.com>

> try_files $uri $uri/ /blog2/index.php?$args;
> при этом получаю 200 ответ на любой мой запрос
ну так тут и написано - если файла нет, то отдать /blog2/index.php

в чем проблема?

From sargaskn at gmail.com  Fri Sep  6 09:22:40 2013
From: sargaskn at gmail.com (Sargas)
Date: Fri, 6 Sep 2013 12:22:40 +0300
Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1IHRyeV9maWxlcw==?=
In-Reply-To: <CACVfVFuATPtXEsWaD3G=Rj4dxMtZbLAk+oCM-BbQp_P5+bwm3Q@mail.gmail.com>
References: <CANA-tskXnMX4XQTGUs9SZJ9ZN_ytu4AEYb9Ukip6q6MpgjrKeA@mail.gmail.com>
 <CANA-tskQh6vH=uzbSYeBvf2heuksBnOHHbDU6Km4j2+GZNn52Q@mail.gmail.com>
 <CACVfVFuATPtXEsWaD3G=Rj4dxMtZbLAk+oCM-BbQp_P5+bwm3Q@mail.gmail.com>
Message-ID: <CANA-ts=ahW=Xywh7oWoVS4AbEDJVQcpBVCvMtCt6pCXNSv=FAg@mail.gmail.com>

Спасибо, но не работает.

Performing sanity check on nginx configuration:
nginx: [emerg] unknown "filename" variable
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed

http://nginx.org/ru/docs/http/ngx_http_core_module.html#variables нет такой
встроенной переменной :(


6 сентября 2013 г., 10:55 пользователь Alexander Moskalenko <
alexander.moskalenko at gmail.com> написал:

> location "^/(?<filename>.*)\.(php|html)$" {
>
>     fastcgi_pass   ...;
>
>     fastcgi_param  SCRIPT_FILENAME  /path/to/index.php;
>     fastcgi_param  SCRIPT_NAME      /index.php;
>     fastcgi_param  QUERY_STRING     key=$filename;
>
> }
>
> 2013/9/6 Sargas <sargaskn at gmail.com>:
> > Сейчас используется
> >
> > if (!-e $request_filename) {
> >  rewrite ^/(.*)\.(php|html)$ /index.php?key=$1 break;
> > }
> >
> > Хочется без if'а
> >
> >
> >
> > 4 сентября 2013 г., 3:25 пользователь Sargas <sargaskn at gmail.com>
> написал:
> >
> >> Приветствую.
> >>
> >> Подскажите, пожалуйста как переписать апачевские реврайты
> >>
> >> RewriteCond %{REQUEST_FILENAME} !-d
> >> RewriteCond %{REQUEST_FILENAME} !-f
> >> RewriteRule ^(.*)\.(php|html)$ /index.php?key=$1 [L,QSA]
> >>
> >>
> >> на nginx/FastCGI с использованием try_files
> >>
> >> В документации (http://sysoev.ru/nginx/docs/faq.html) есть пример с
> >> именованным локейшеном
> >>
> >> location / {
> >>     try_files      $uri  $uri/  @drupal;
> >> }
> >>
> >> location @drupal {
> >>     fastcgi_pass   ...;
> >>
> >>     fastcgi_param  SCRIPT_FILENAME  /path/to/index.php;
> >>     fastcgi_param  SCRIPT_NAME      /index.php;
> >>     fastcgi_param  QUERY_STRING     q=$uri&$args;
> >>
> >>     ... прочие fastcgi_param
> >> }
> >>
> >> Вопрос в том как в QUERY_STRING передать имя файла, но без его
> расширения
> >> (php|html).
> >>
> >> Чтобы работали подобные ссылки
> >> http://www.example.com/channels.php  <=>
> >> http://www.example.com/index.php?key=channels
> >>
> >>
> >>
> >> И вопрос по директиве accept_mutex
> >> http://nginx.org/ru/docs/ngx_core_module.html#accept_mutex
> >> Судя по описанию выключать её не рекомендуется. А в какой ситуации может
> >> понадобится её выключить? :)
> >
> >
> >
> > _______________________________________________
> > 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/20130906/c20625b4/attachment.html>

From onokonem at gmail.com  Fri Sep  6 09:26:49 2013
From: onokonem at gmail.com (Daniel Podolsky)
Date: Fri, 6 Sep 2013 13:26:49 +0400
Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1IHRyeV9maWxlcw==?=
In-Reply-To: <CANA-ts=ahW=Xywh7oWoVS4AbEDJVQcpBVCvMtCt6pCXNSv=FAg@mail.gmail.com>
References: <CANA-tskXnMX4XQTGUs9SZJ9ZN_ytu4AEYb9Ukip6q6MpgjrKeA@mail.gmail.com>
 <CANA-tskQh6vH=uzbSYeBvf2heuksBnOHHbDU6Km4j2+GZNn52Q@mail.gmail.com>
 <CACVfVFuATPtXEsWaD3G=Rj4dxMtZbLAk+oCM-BbQp_P5+bwm3Q@mail.gmail.com>
 <CANA-ts=ahW=Xywh7oWoVS4AbEDJVQcpBVCvMtCt6pCXNSv=FAg@mail.gmail.com>
Message-ID: <CAKaHDOE2_ahZJiqcavzEcExNz8hvbumuLGWd_SwNaHiuCDA3LQ@mail.gmail.com>

> nginx: [emerg] unknown "filename" variable
Это вам прописано обновление nginx, до версии с поддержкой именованных
групп в регекспах.

From sargaskn at gmail.com  Fri Sep  6 09:29:18 2013
From: sargaskn at gmail.com (Sargas)
Date: Fri, 6 Sep 2013 12:29:18 +0300
Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1IHRyeV9maWxlcw==?=
In-Reply-To: <CAKaHDOE2_ahZJiqcavzEcExNz8hvbumuLGWd_SwNaHiuCDA3LQ@mail.gmail.com>
References: <CANA-tskXnMX4XQTGUs9SZJ9ZN_ytu4AEYb9Ukip6q6MpgjrKeA@mail.gmail.com>
 <CANA-tskQh6vH=uzbSYeBvf2heuksBnOHHbDU6Km4j2+GZNn52Q@mail.gmail.com>
 <CACVfVFuATPtXEsWaD3G=Rj4dxMtZbLAk+oCM-BbQp_P5+bwm3Q@mail.gmail.com>
 <CANA-ts=ahW=Xywh7oWoVS4AbEDJVQcpBVCvMtCt6pCXNSv=FAg@mail.gmail.com>
 <CAKaHDOE2_ahZJiqcavzEcExNz8hvbumuLGWd_SwNaHiuCDA3LQ@mail.gmail.com>
Message-ID: <CANA-tsmX=KNYTmvhFZbikSO7NSq1xknckFcOgtToy=pygTdpmQ@mail.gmail.com>

Используется последний stable без сторонних модулей.


# nginx -v
nginx version: nginx/1.4.2
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx-error.log --user=www --group=www
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx-access.log --without-http-cache
--with-http_geoip_module --with-http_realip_module
--with-http_stub_status_module --with-pcre


6 сентября 2013 г., 12:26 пользователь Daniel Podolsky
<onokonem at gmail.com>написал:

> > nginx: [emerg] unknown "filename" variable
> Это вам прописано обновление nginx, до версии с поддержкой именованных
> групп в регекспах.
> _______________________________________________
> 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/20130906/d8796551/attachment-0001.html>

From nginx-forum at nginx.us  Fri Sep  6 09:32:30 2013
From: nginx-forum at nginx.us (gatesat)
Date: Fri, 06 Sep 2013 05:32:30 -0400
Subject: =?UTF-8?B?0J7RiNC40LHQutC4IFNTTCDQv9GA0Lgg0L7RgtC00LDRh9C1INGE0LDQudC70L4=?=
 =?UTF-8?B?0LIu?=
Message-ID: <1c04e8325d5eba30e69ce9cfedc2e687.NginxMailingListRussian@forum.nginx.org>

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

Имеем nginx 1.4.2 под debian-ом.

При отдаче файлов без использования SSL все ОК, при отдаче файлов с
использованием SSL файлы отдаются, но в логах я вижу много записей
SSL_get_error: 3

2013/09/06 12:26:36 [debug] 2504#0: *4 SSL buf copy: 16048
2013/09/06 12:26:36 [debug] 2504#0: *4 SSL to write: 16384
2013/09/06 12:26:36 [debug] 2504#0: *4 SSL_write: 16384
2013/09/06 12:26:36 [debug] 2504#0: *4 SSL buf copy: 16384
2013/09/06 12:26:36 [debug] 2504#0: *4 SSL to write: 16384
2013/09/06 12:26:36 [debug] 2504#0: *4 SSL_write: 16384
2013/09/06 12:26:36 [debug] 2504#0: *4 SSL buf copy: 16384
2013/09/06 12:26:36 [debug] 2504#0: *4 SSL to write: 16384
2013/09/06 12:26:36 [debug] 2504#0: *4 SSL_write: 16384
2013/09/06 12:26:36 [debug] 2504#0: *4 SSL buf copy: 16384
2013/09/06 12:26:36 [debug] 2504#0: *4 SSL to write: 16384
2013/09/06 12:26:36 [debug] 2504#0: *4 SSL_write: -1
2013/09/06 12:26:36 [debug] 2504#0: *4 SSL_get_error: 3

И так много раз пока качается файл.
Приседания с sendfile on/off и размером разных буферов картину не меняют.
Гугл и поиск по форуму ответа не подсказали, поэтому прошу совета здесь, в
какую сторону смотреть ?

Заранее благодарен, Иван.

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


From onokonem at gmail.com  Fri Sep  6 09:50:31 2013
From: onokonem at gmail.com (Daniel Podolsky)
Date: Fri, 6 Sep 2013 13:50:31 +0400
Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1IHRyeV9maWxlcw==?=
In-Reply-To: <CANA-tsmX=KNYTmvhFZbikSO7NSq1xknckFcOgtToy=pygTdpmQ@mail.gmail.com>
References: <CANA-tskXnMX4XQTGUs9SZJ9ZN_ytu4AEYb9Ukip6q6MpgjrKeA@mail.gmail.com>
 <CANA-tskQh6vH=uzbSYeBvf2heuksBnOHHbDU6Km4j2+GZNn52Q@mail.gmail.com>
 <CACVfVFuATPtXEsWaD3G=Rj4dxMtZbLAk+oCM-BbQp_P5+bwm3Q@mail.gmail.com>
 <CANA-ts=ahW=Xywh7oWoVS4AbEDJVQcpBVCvMtCt6pCXNSv=FAg@mail.gmail.com>
 <CAKaHDOE2_ahZJiqcavzEcExNz8hvbumuLGWd_SwNaHiuCDA3LQ@mail.gmail.com>
 <CANA-tsmX=KNYTmvhFZbikSO7NSq1xknckFcOgtToy=pygTdpmQ@mail.gmail.com>
Message-ID: <CAKaHDOEPCicg=6xxf4PWzJz6bAVXb+k1cT+vvmQnEKzAQ2uQEw@mail.gmail.com>

> Используется последний stable без сторонних модулей.
Вариантов 2:
1) вы невнимательно читали, и не дописали именованное выделение в регексп
2) у вас опечатка в конфиге, используется неверное имя именованного выделения

From vbart at nginx.com  Fri Sep  6 09:51:28 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Fri, 6 Sep 2013 13:51:28 +0400
Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCBTU0wg0L/RgNC4INC+0YLQtNCw0YfQtSDRhNCw0Lk=?=
 =?UTF-8?B?0LvQvtCyLg==?=
In-Reply-To: <1c04e8325d5eba30e69ce9cfedc2e687.NginxMailingListRussian@forum.nginx.org>
References: <1c04e8325d5eba30e69ce9cfedc2e687.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201309061351.28430.vbart@nginx.com>

On Friday 06 September 2013 13:32:30 gatesat wrote:
> Приветствую !
> 
> Имеем nginx 1.4.2 под debian-ом.
> 
> При отдаче файлов без использования SSL все ОК, при отдаче файлов с
> использованием SSL файлы отдаются, но в логах я вижу много записей
> SSL_get_error: 3

Это нормально.  Это не ошибка, оно логгируется на уровне debug, а не
error/crit/alert, и является частью обычного функционирования OpenSSL.

> 
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL buf copy: 16048
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL to write: 16384
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL_write: 16384
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL buf copy: 16384
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL to write: 16384
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL_write: 16384
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL buf copy: 16384
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL to write: 16384
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL_write: 16384
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL buf copy: 16384
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL to write: 16384
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL_write: -1
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL_get_error: 3
> 
> И так много раз пока качается файл.
> Приседания с sendfile on/off и размером разных буферов картину не меняют.

sendfile при работе по SSL/TLS вообще не применим.

> Гугл и поиск по форуму ответа не подсказали, поэтому прошу совета здесь, в
> какую сторону смотреть ?
> 

В сторону выключения debug-лога.

--
Валентин Бартенев
http://nginx.org/en/donation.html

From citrin at citrin.ru  Fri Sep  6 09:52:38 2013
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Fri, 06 Sep 2013 13:52:38 +0400
Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQuCBTU0wg0L/RgNC4INC+0YLQtNCw0YfQtSDRhNCw0Lk=?=
 =?UTF-8?B?0LvQvtCyLg==?=
In-Reply-To: <1c04e8325d5eba30e69ce9cfedc2e687.NginxMailingListRussian@forum.nginx.org>
References: <1c04e8325d5eba30e69ce9cfedc2e687.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5229A5E6.2070104@citrin.ru>

On 09/06/13 13:32, gatesat wrote:
> При отдаче файлов без использования SSL все ОК, при отдаче файлов с
> использованием SSL файлы отдаются, но в логах я вижу много записей
> SSL_get_error: 3
...
> 2013/09/06 12:26:36 [debug] 2504#0: *4 SSL_get_error: 3

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


From nginx-forum at nginx.us  Fri Sep  6 10:16:53 2013
From: nginx-forum at nginx.us (romas1982)
Date: Fri, 06 Sep 2013 06:16:53 -0400
Subject: =?UTF-8?B?0J/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC1INC/0L7Qu9GM0LfQvtCy0LA=?=
 =?UTF-8?B?0YLQtdC70LXQuSDQsiDQt9Cw0LLQuNGB0LjQvNC+0YHRgtC4INC+0YIg0Lc=?=
 =?UTF-8?B?0LDQvdGP0YLQvtGB0YLQuCDQutCw0L3QsNC70LA=?=
Message-ID: <491219bdc52fcf43eaf6969e9a1538d8.NginxMailingListRussian@forum.nginx.org>

Добрый день, 

Есть канал в 500мб/c и задача раздавать видео через nginx. Но при условии,
что в случае, если из 500мб/c будет съедено 400 - всех приходящих новых
пользователей редиректить на внешний cdn. 

Подскажите пожалуйста, существует ли решение средствами nginx померять канал
так, чтобы можно было if'ом,например, отгонять пользователей на cdn? (может
модуль есть такой готовый).

Спасибо!

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


From nginx-ru at sadok.spb.ru  Fri Sep  6 10:25:20 2013
From: nginx-ru at sadok.spb.ru (Dmitry Ivanov)
Date: Fri, 6 Sep 2013 14:25:20 +0400
Subject: =?UTF-8?B?UmU6INCf0LXRgNC10L3QsNC/0YDQsNCy0LvQtdC90LjQtSDQv9C+0LvRjNC30L4=?=
 =?UTF-8?B?0LLQsNGC0LXQu9C10Lkg0LIg0LfQsNCy0LjRgdC40LzQvtGB0YLQuCDQvtGC?=
 =?UTF-8?B?INC30LDQvdGP0YLQvtGB0YLQuCDQutCw0L3QsNC70LA=?=
In-Reply-To: <491219bdc52fcf43eaf6969e9a1538d8.NginxMailingListRussian@forum.nginx.org>
References: <491219bdc52fcf43eaf6969e9a1538d8.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1565073364.20130906142520@sadok.spb.ru>

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

Вы писали 6 сентября 2013 г., 14:16:53:

> Добрый день, 

> Есть канал в 500мб/c и задача раздавать видео через nginx. Но при условии,
> что в случае, если из 500мб/c будет съедено 400 - всех приходящих новых
> пользователей редиректить на внешний cdn. 

> Подскажите пожалуйста, существует ли решение средствами nginx померять канал
> так, чтобы можно было if'ом,например, отгонять пользователей на cdn? (может
> модуль есть такой готовый).

Измерять чем-то внешним, вешать/убирать флаг, наличие флага проверять
nginx'ом.

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


From sargaskn at gmail.com  Fri Sep  6 10:26:37 2013
From: sargaskn at gmail.com (Sargas)
Date: Fri, 6 Sep 2013 13:26:37 +0300
Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1IHRyeV9maWxlcw==?=
In-Reply-To: <CAKaHDOEPCicg=6xxf4PWzJz6bAVXb+k1cT+vvmQnEKzAQ2uQEw@mail.gmail.com>
References: <CANA-tskXnMX4XQTGUs9SZJ9ZN_ytu4AEYb9Ukip6q6MpgjrKeA@mail.gmail.com>
 <CANA-tskQh6vH=uzbSYeBvf2heuksBnOHHbDU6Km4j2+GZNn52Q@mail.gmail.com>
 <CACVfVFuATPtXEsWaD3G=Rj4dxMtZbLAk+oCM-BbQp_P5+bwm3Q@mail.gmail.com>
 <CANA-ts=ahW=Xywh7oWoVS4AbEDJVQcpBVCvMtCt6pCXNSv=FAg@mail.gmail.com>
 <CAKaHDOE2_ahZJiqcavzEcExNz8hvbumuLGWd_SwNaHiuCDA3LQ@mail.gmail.com>
 <CANA-tsmX=KNYTmvhFZbikSO7NSq1xknckFcOgtToy=pygTdpmQ@mail.gmail.com>
 <CAKaHDOEPCicg=6xxf4PWzJz6bAVXb+k1cT+vvmQnEKzAQ2uQEw@mail.gmail.com>
Message-ID: <CANA-tsnT6rSW_WgNM4rNTV4p+KEX7syDVTmV53gCX6+8hwDbAg@mail.gmail.com>

Разобрался. Нужно было тильду добавить

location "~^/(?<filename>.*)\.(php|html)$"

Всем спасибо за помощь :)


6 сентября 2013 г., 12:50 пользователь Daniel Podolsky
<onokonem at gmail.com>написал:

> > Используется последний stable без сторонних модулей.
> Вариантов 2:
> 1) вы невнимательно читали, и не дописали именованное выделение в регексп
> 2) у вас опечатка в конфиге, используется неверное имя именованного
> выделения
> _______________________________________________
> 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/20130906/02d1d55e/attachment.html>

From a at gelun.ru  Fri Sep  6 10:34:02 2013
From: a at gelun.ru (Gelun, Artem)
Date: Fri, 6 Sep 2013 14:34:02 +0400
Subject: =?UTF-8?B?0JDQu9Cz0L7RgNC40YLQvCDRg9C00LDQu9C10L3QuNGPINC00LDQvdC90YvRhSA=?=
 =?UTF-8?B?0LjQtyDQutGN0YjQsA==?=
Message-ID: <CAA5W3D0WD-sbLQvgu96Yk0WwJtY-bxUs79_cqL08V893tsHD_Q@mail.gmail.com>

Простите, если где-то тема освещалась, но не могу найти ни в доках, ни в
рассылке, ни в гугле ...

Хотелось бы понимать алгоритм по которому cache-manager удаляет объекты из
кэша при недостаточности объёма самого кэша. Какие критерии учитываотся, в
каком порядке и т.п.? Может быть есть где-то детальное описание? или курить
исходники?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130906/e35fb027/attachment-0001.html>

From vbart at nginx.com  Fri Sep  6 11:42:22 2013
From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 6 Sep 2013 15:42:22 +0400
Subject: =?UTF-8?B?UmU6INCQ0LvQs9C+0YDQuNGC0Lwg0YPQtNCw0LvQtdC90LjRjyDQtNCw0L3QvdGL?=
 =?UTF-8?B?0YUg0LjQtyDQutGN0YjQsA==?=
In-Reply-To: <CAA5W3D0WD-sbLQvgu96Yk0WwJtY-bxUs79_cqL08V893tsHD_Q@mail.gmail.com>
References: <CAA5W3D0WD-sbLQvgu96Yk0WwJtY-bxUs79_cqL08V893tsHD_Q@mail.gmail.com>
Message-ID: <201309061542.22891.vbart@nginx.com>

On Friday 06 September 2013 14:34:02 Gelun, Artem wrote:
> Простите, если где-то тема освещалась, но не могу найти ни в доках, ни в
> рассылке, ни в гугле ...
> 
> Хотелось бы понимать алгоритм по которому cache-manager удаляет объекты из
> кэша при недостаточности объёма самого кэша. Какие критерии учитываотся, в
> каком порядке и т.п.? Может быть есть где-то детальное описание? или курить
> исходники?

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

 | The special ?cache manager? process monitors the maximum cache size set by
 | the max_size parameter. When this size is exceeded, it removes the least
 | recently used data.


http://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used

--
Валентин Бартенев
http://nginx.org/en/donation.html
 

From nginx-forum at nginx.us  Fri Sep  6 12:33:51 2013
From: nginx-forum at nginx.us (valch85)
Date: Fri, 06 Sep 2013 08:33:51 -0400
Subject: =?UTF-8?B?UmU6IDIwMCDQvtGC0LLQtdGCINC/0YDQuCDQvtGC0YHRg9GC0YHQstC40Lgg0YQ=?=
 =?UTF-8?B?0LDQudC70LA=?=
In-Reply-To: <CAKaHDOEXb9v_Hkw8Wh=anRKOaw0aL_yuagZAzR05mLZ6-=xKeQ@mail.gmail.com>
References: <CAKaHDOEXb9v_Hkw8Wh=anRKOaw0aL_yuagZAzR05mLZ6-=xKeQ@mail.gmail.com>
Message-ID: <40931396dcdb17fc218f3dbba0eef8f3.NginxMailingListRussian@forum.nginx.org>

проблема в том что он отдает при этом пустую страницу и код ответа 200 при
этом

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


From dmitriy at lyalyuev.info  Fri Sep  6 12:35:06 2013
From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev)
Date: Fri, 06 Sep 2013 15:35:06 +0300
Subject: =?UTF-8?B?UmU6IDIwMCDQvtGC0LLQtdGCINC/0YDQuCDQvtGC0YHRg9GC0YHQstC40Lgg0YQ=?=
 =?UTF-8?B?0LDQudC70LA=?=
In-Reply-To: <40931396dcdb17fc218f3dbba0eef8f3.NginxMailingListRussian@forum.nginx.org>
References: <CAKaHDOEXb9v_Hkw8Wh=anRKOaw0aL_yuagZAzR05mLZ6-=xKeQ@mail.gmail.com>
 <40931396dcdb17fc218f3dbba0eef8f3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5229CBFA.3060708@lyalyuev.info>

Это результат работы index.php
Смотрите в его сторону.

06.09.2013 15:33, valch85 пишет:
> проблема в том что он отдает при этом пустую страницу и код ответа 200 при
> этом
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242619,242637#msg-242637
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


-- 
Dmitriy Lyalyuev
http://lyalyuev.info


From a at gelun.ru  Fri Sep  6 13:25:42 2013
From: a at gelun.ru (Gelun, Artem)
Date: Fri, 6 Sep 2013 17:25:42 +0400
Subject: =?UTF-8?B?UmU6INCQ0LvQs9C+0YDQuNGC0Lwg0YPQtNCw0LvQtdC90LjRjyDQtNCw0L3QvdGL?=
 =?UTF-8?B?0YUg0LjQtyDQutGN0YjQsA==?=
In-Reply-To: <201309061542.22891.vbart@nginx.com>
References: <CAA5W3D0WD-sbLQvgu96Yk0WwJtY-bxUs79_cqL08V893tsHD_Q@mail.gmail.com>
 <201309061542.22891.vbart@nginx.com>
Message-ID: <CAA5W3D0GKjdD8Z-fHjMUaT5aPO4dUiuN7tBW5NBXEZ2ydT=o9g@mail.gmail.com>

Спасибо!

Я считал что в nginx первичной является документация на русском, но в ней
всё менее конкретно:

Специальный процесс "cache manager" следит за максимальным размером кэша,
> заданным параметром max_size, и при превышении его размеров *удаляет
> наименее востребованные данные*
>

"наименее востребованные" можно и понимать по разному (LRU и LFU на него,
как минимум, тянут), и на название алгоритма не похоже ))

Нет ли планов реализовать другие методы кэширования? ведь LRU далеко не для
всех нагрузок оптимальна.




6 сентября 2013 г., 15:42 пользователь Валентин Бартенев
<vbart at nginx.com>написал:

> On Friday 06 September 2013 14:34:02 Gelun, Artem wrote:
> > Простите, если где-то тема освещалась, но не могу найти ни в доках, ни в
> > рассылке, ни в гугле ...
> >
> > Хотелось бы понимать алгоритм по которому cache-manager удаляет объекты
> из
> > кэша при недостаточности объёма самого кэша. Какие критерии учитываотся,
> в
> > каком порядке и т.п.? Может быть есть где-то детальное описание? или
> курить
> > исходники?
>
> http://nginx.org/r/proxy_cache_path/ru
>
>  | The special "cache manager" process monitors the maximum cache size set
> by
>  | the max_size parameter. When this size is exceeded, it removes the least
>  | recently used data.
>
>
> http://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used
>
> --
> Валентин Бартенев
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130906/ab15650f/attachment.html>

From vbart at nginx.com  Fri Sep  6 13:34:01 2013
From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 6 Sep 2013 17:34:01 +0400
Subject: =?UTF-8?B?UmU6INCQ0LvQs9C+0YDQuNGC0Lwg0YPQtNCw0LvQtdC90LjRjyDQtNCw0L3QvdGL?=
 =?UTF-8?B?0YUg0LjQtyDQutGN0YjQsA==?=
In-Reply-To: <CAA5W3D0GKjdD8Z-fHjMUaT5aPO4dUiuN7tBW5NBXEZ2ydT=o9g@mail.gmail.com>
References: <CAA5W3D0WD-sbLQvgu96Yk0WwJtY-bxUs79_cqL08V893tsHD_Q@mail.gmail.com>
 <201309061542.22891.vbart@nginx.com>
 <CAA5W3D0GKjdD8Z-fHjMUaT5aPO4dUiuN7tBW5NBXEZ2ydT=o9g@mail.gmail.com>
Message-ID: <201309061734.01258.vbart@nginx.com>

On Friday 06 September 2013 17:25:42 Gelun, Artem wrote:
> Спасибо!
> 
> Я считал что в nginx первичной является документация на русском, но в ней
> всё менее конкретно:
> 
> Специальный процесс "cache manager" следит за максимальным размером кэша,
> 
> > заданным параметром max_size, и при превышении его размеров *удаляет
> > наименее востребованные данные*
> 
> "наименее востребованные" можно и понимать по разному (LRU и LFU на него,
> как минимум, тянут), и на название алгоритма не похоже ))
> 
> Нет ли планов реализовать другие методы кэширования? ведь LRU далеко не для
> всех нагрузок оптимальна.
> 

Какие интересуют?

--
Валентин Бартенев
http://nginx.org/en/donation.html

From a at gelun.ru  Fri Sep  6 21:10:46 2013
From: a at gelun.ru (Gelun, Artem)
Date: Sat, 7 Sep 2013 01:10:46 +0400
Subject: =?UTF-8?B?UmU6INCQ0LvQs9C+0YDQuNGC0Lwg0YPQtNCw0LvQtdC90LjRjyDQtNCw0L3QvdGL?=
 =?UTF-8?B?0YUg0LjQtyDQutGN0YjQsA==?=
In-Reply-To: <201309061734.01258.vbart@nginx.com>
References: <CAA5W3D0WD-sbLQvgu96Yk0WwJtY-bxUs79_cqL08V893tsHD_Q@mail.gmail.com>
 <201309061542.22891.vbart@nginx.com>
 <CAA5W3D0GKjdD8Z-fHjMUaT5aPO4dUiuN7tBW5NBXEZ2ydT=o9g@mail.gmail.com>
 <201309061734.01258.vbart@nginx.com>
Message-ID: <CAA5W3D0sVvz+pqZB8AmeRYBVT3MgYcdsmXxu-kCMz+ESL4iyAA@mail.gmail.com>

LFU, к примеру (сейчас у нас ситуация, когда из-за нехватки кэша (tmpfs)
много вытеснений низкочастотными запросами высокочастотных)

Вообще было бы здОрово добавить возможность написания кастомных модулей
управления кэшом, чтобы не приходилось переписывать весь proxy_module или
fastcgi_module если потребуется реализовать "своё" кэширование с каким-то
совсем нестандартным алгоритмом.

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



6 сентября 2013 г., 17:34 пользователь Валентин Бартенев
<vbart at nginx.com>написал:

> On Friday 06 September 2013 17:25:42 Gelun, Artem wrote:
> > Спасибо!
> >
> > Я считал что в nginx первичной является документация на русском, но в ней
> > всё менее конкретно:
> >
> > Специальный процесс "cache manager" следит за максимальным размером кэша,
> >
> > > заданным параметром max_size, и при превышении его размеров *удаляет
> > > наименее востребованные данные*
> >
> > "наименее востребованные" можно и понимать по разному (LRU и LFU на него,
> > как минимум, тянут), и на название алгоритма не похоже ))
> >
> > Нет ли планов реализовать другие методы кэширования? ведь LRU далеко не
> для
> > всех нагрузок оптимальна.
> >
>
> Какие интересуют?
>
> --
> Валентин Бартенев
> http://nginx.org/en/donation.html
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130907/09b53b23/attachment.html>

From voron at amhost.net  Sat Sep  7 11:05:30 2013
From: voron at amhost.net (Alex Vorona)
Date: Sat, 07 Sep 2013 14:05:30 +0300
Subject: =?UTF-8?B?UmU6INCQ0LvQs9C+0YDQuNGC0Lwg0YPQtNCw0LvQtdC90LjRjyDQtNCw0L3QvdGL?=
 =?UTF-8?B?0YUg0LjQtyDQutGN0YjQsA==?=
In-Reply-To: <CAA5W3D0sVvz+pqZB8AmeRYBVT3MgYcdsmXxu-kCMz+ESL4iyAA@mail.gmail.com>
References: <CAA5W3D0WD-sbLQvgu96Yk0WwJtY-bxUs79_cqL08V893tsHD_Q@mail.gmail.com>
 <201309061542.22891.vbart@nginx.com>
 <CAA5W3D0GKjdD8Z-fHjMUaT5aPO4dUiuN7tBW5NBXEZ2ydT=o9g@mail.gmail.com>
 <201309061734.01258.vbart@nginx.com>
 <CAA5W3D0sVvz+pqZB8AmeRYBVT3MgYcdsmXxu-kCMz+ESL4iyAA@mail.gmail.com>
Message-ID: <522B087A.3080908@amhost.net>

07.09.2013 00:10, Gelun, Artem wrote:
> Ещё одно - многоуровневые кэши (конечно, их можно реализовать
> проксированием запросов на другой server, но это как-то криво и гонять
> несколько гигабит через loopback нехорошо)
если TCP не нравится - гоняйте через unix-сокеты. Хотя и для TCP это не проблема по loopback.


From gmm at csdoc.com  Sat Sep  7 16:51:16 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Sat, 07 Sep 2013 19:51:16 +0300
Subject: =?UTF-8?B?UmU6IGx1YSDQvNC+0LTRg9C70Yw=?=
In-Reply-To: <51AE278D.9030505@citrin.ru>
References: <C4B86854-B3E5-40A0-AF5F-BAE6903260B7@gmail.com>
 <201306041849.22887.vbart@nginx.com>
 <358232E4-B2E2-4B6A-B905-CFC06C5BFF52@gmail.com>
 <201306041935.54096.vbart@nginx.com> <51AE125C.4050803@csdoc.com>
 <51AE278D.9030505@citrin.ru>
Message-ID: <522B5984.9030501@csdoc.com>

On 04.06.2013 20:44, Anton Yuzhaninov wrote:

>> есть какие-то вещи, которые нельзя сделать с помощью встроенного
>> perl-модуля, но можно сделать с помощью этого стороннего lua-модуля?
>
> Есть.
> Используя встроенный perl можно выполнять операции, которые не
> блокируются и имеет очень ограниченный доступ к функциям nginx (см.
> http://nginx.org/en/docs/http/ngx_http_perl_module.html#methods)
>
> LUA модуль позволяет делать многое из того, что можно сделать написав
> модуль к nginx на C. Например он позволяет делать подзапросы.
>
> Обратная сторона такой гибкости - сложность самого LUA-модуля и как
> следствие баги в нём.

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

http://blog.cloudflare.com/cloudflares-new-waf-compiling-to-lua
http://blog.cloudflare.com/pushing-nginx-to-its-limit-with-lua

>> учитывая, что у lua более простой синтаксис, чем у perl
>> может быть имеет смысл "из коробки" встроить lua в nginx?

если не сейчас, то может быть в версии nginx 2.0 ?
nginx+lua может быть достойной альтернативой node.js

>> (по крайней мере, в ядра netbsd и linux этот язык уже встроили -
>> про linux: http://www.opennet.ru/opennews/art.shtml?num=36991)

lua лучше чем javascript подходит для встраивания в nginx,
вот: http://www.inf.puc-rio.br/~roberto/talks/www2013.pdf

>> тогда уж точно можно будет программировать "на конфигах nginx".
>> и модуль rewrite тогда можно будет реализовать используя lua.

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

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

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

"One project that's now almost entirely written in Lua
is the new CloudFlare WAF" - хотя могли и на С написать.

-- 
Best regards,
  Gena


From nginx-forum at nginx.us  Sat Sep  7 18:51:55 2013
From: nginx-forum at nginx.us (burlaka)
Date: Sat, 07 Sep 2013 14:51:55 -0400
Subject: =?UTF-8?B?0LrQsNC6INGA0LDQsdC+0YLQsNC10YIgcHJveHkgcmVkaXJlY3Q=?=
Message-ID: <af8a811f970c18a63794598161b1058b.NginxMailingListRussian@forum.nginx.org>

Коллеги, помогите разобраться с работой дериктивы proxy_redirect.
Есть конфиг:
  location /bpm1/ {
    proxy_pass https://proto4.portal.local:9443/;
    proxy_redirect https://proto4.portal.local:9443/
http://wpsdm.portal.local;
  }

Т.е. надо все входящие запросы на /bpm1/ перебрасывать на
https://proto4.portal.local:9443/ и в ответе от этого сервера менять
заголовок Location на http://wpsdm.portal.local. Переброс работает, а
дериктива proxy_redirect - нет.
Что я не так делаю?

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


From vbart at nginx.com  Sat Sep  7 19:28:06 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Sat, 7 Sep 2013 23:28:06 +0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIHByb3h5IHJlZGlyZWN0?=
In-Reply-To: <af8a811f970c18a63794598161b1058b.NginxMailingListRussian@forum.nginx.org>
References: <af8a811f970c18a63794598161b1058b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201309072328.06721.vbart@nginx.com>

On Saturday 07 September 2013 22:51:55 burlaka wrote:
> Коллеги, помогите разобраться с работой дериктивы proxy_redirect.
> Есть конфиг:
>   location /bpm1/ {
>     proxy_pass https://proto4.portal.local:9443/;
>     proxy_redirect https://proto4.portal.local:9443/
> http://wpsdm.portal.local;
>   }
> 
> Т.е. надо все входящие запросы на /bpm1/ перебрасывать на
> https://proto4.portal.local:9443/ и в ответе от этого сервера менять
> заголовок Location на http://wpsdm.portal.local. Переброс работает, а
> дериктива proxy_redirect - нет.
> Что я не так делаю?
> 

Как вы определили, что директива не работает?

p.s. Если в Location:  https://proto4.portal.local:9443/some/path
заменить https://proto4.portal.local:9443/ на http://wpsdm.portal.local,
то получится http://wpsdm.portal.localsome/path

--
Валентин Бартенев
http://nginx.org/en/donation.html

From nginx-forum at nginx.us  Sun Sep  8 01:23:19 2013
From: nginx-forum at nginx.us (burlaka)
Date: Sat, 07 Sep 2013 21:23:19 -0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIHByb3h5IHJlZGlyZWN0?=
In-Reply-To: <201309072328.06721.vbart@nginx.com>
References: <201309072328.06721.vbart@nginx.com>
Message-ID: <3c52d766243d7cb7c5eb346b01f22a2c.NginxMailingListRussian@forum.nginx.org>

Потому что даже, если я в ней напишу:
  proxy_redirect https://proto4.portal.local:9443/ http://aaaa;

запрос всё равно пойдёт в корень локального сервера.

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


From vbart at nginx.com  Sun Sep  8 11:32:11 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Sun, 8 Sep 2013 15:32:11 +0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIHByb3h5IHJlZGlyZWN0?=
In-Reply-To: <3c52d766243d7cb7c5eb346b01f22a2c.NginxMailingListRussian@forum.nginx.org>
References: <201309072328.06721.vbart@nginx.com>
 <3c52d766243d7cb7c5eb346b01f22a2c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201309081532.11181.vbart@nginx.com>

On Sunday 08 September 2013 05:23:19 burlaka wrote:
> Потому что даже, если я в ней напишу:
>   proxy_redirect https://proto4.portal.local:9443/ http://aaaa;
> 
> запрос всё равно пойдёт в корень локального сервера.
> 

Какой запрос? Куда идет? Вы заголовки смотрели?  Задача директивы
изменять информацию в заголовках Location и Refresh.  Что в них?

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

--
Валентин Бартенев
http://nginx.org/en/donation.html

From nginx-forum at nginx.us  Sun Sep  8 12:39:01 2013
From: nginx-forum at nginx.us (burlaka)
Date: Sun, 08 Sep 2013 08:39:01 -0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIHByb3h5IHJlZGlyZWN0?=
In-Reply-To: <201309081532.11181.vbart@nginx.com>
References: <201309081532.11181.vbart@nginx.com>
Message-ID: <d519af5e3ac95770ce73bd24262b042c.NginxMailingListRussian@forum.nginx.org>

Есть 2 сервера: frontend - wpsdm.portal.local и backend -
proto4.portal.local. Надо реализовать, чтобы все запросы на 
https://wpsdm.portal.local/bpm1/ перенаправлялись на
https://proto4.portal.local/

Соответственно я пишу в конфиге:
        location /bpm1/ {
                proxy_pass https://proto4.portal.local:9443/;
                proxy_redirect https://proto4.portal.local:9443/
https://wpsdm.portal.local:9443/bpm1/;
        }

proxy_pass - чтобы отправить запрос куда мне надо
proxy_redirect - чтобы поправить заголовки Location и Refresh в ответе на
frontend сервер.

Как такое реализовать?

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


From vbart at nginx.com  Sun Sep  8 15:29:12 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Sun, 8 Sep 2013 19:29:12 +0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIHByb3h5IHJlZGlyZWN0?=
In-Reply-To: <d519af5e3ac95770ce73bd24262b042c.NginxMailingListRussian@forum.nginx.org>
References: <201309081532.11181.vbart@nginx.com>
 <d519af5e3ac95770ce73bd24262b042c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201309081929.12036.vbart@nginx.com>

On Sunday 08 September 2013 16:39:01 burlaka wrote:
> Есть 2 сервера: frontend - wpsdm.portal.local и backend -
> proto4.portal.local. Надо реализовать, чтобы все запросы на
> https://wpsdm.portal.local/bpm1/ перенаправлялись на
> https://proto4.portal.local/
> 
> Соответственно я пишу в конфиге:
>         location /bpm1/ {
>                 proxy_pass https://proto4.portal.local:9443/;
>                 proxy_redirect https://proto4.portal.local:9443/
> https://wpsdm.portal.local:9443/bpm1/;
>         }
> 
> proxy_pass - чтобы отправить запрос куда мне надо
> proxy_redirect - чтобы поправить заголовки Location и Refresh в ответе на
> frontend сервер.
> 
> Как такое реализовать?
> 

Именно так, как вы написали выше. Вопрос опять же, что не работает?
Какие заголовки возвращаются?

Если в ответ возвращаются заголовки Location/Refresh с содержимым,
отличным от того, что вы указали в proxy_redirect, то естественно
директива работать не будет.

Что именно возвращается в ответ, смотрели?

--
Валентин Бартенев
http://nginx.org/en/donation.html

From nginx-forum at nginx.us  Mon Sep  9 08:25:46 2013
From: nginx-forum at nginx.us (demo)
Date: Mon, 09 Sep 2013 04:25:46 -0400
Subject: Nginx + Websockets
Message-ID: <075afd26e4ce9d1a508f5e32dae7224d.NginxMailingListRussian@forum.nginx.org>

Здравствуйте!
Можно ли как-то организовать работу с вебсокетами на nginx без использования
NodeJS, Socket.IO и т.п.?
Если это возможно, поделитесь пожалуйста примерами.

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


From gmm at csdoc.com  Mon Sep  9 09:26:47 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Mon, 09 Sep 2013 12:26:47 +0300
Subject: ssl_prefer_server_ciphers
Message-ID: <522D9457.9080008@csdoc.com>

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

директива ssl_prefer_server_ciphers иимеет значение по-умолчанию off.
возможно имеет смысл изменить дефолтовое значение этой директивы в on?

потому что при ssl_prefer_server_ciphers off;
nginx подвержен влиянию BEAST-атаки CVE-2011-3389.

подробности: http://habrahabr.ru/post/173125/
https://www.ssllabs.com/ssltest/ и https://www.ssllabs.com/

при текущем значении по-умолчанию ssl_prefer_server_ciphers
- nginx даже не соответствует требованиям стандарта PCI DSS.

я понимаю, что nginx - это не совсем OpenBSD, но он часть OpenBSD,
и поэтому лучше подход http://www.openbsd.org/security.html#default

-- 
Best regards,
  Gena


From sytar.alex at gmail.com  Mon Sep  9 09:56:43 2013
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Mon, 9 Sep 2013 13:56:43 +0400
Subject: Nginx + Websockets
In-Reply-To: <075afd26e4ce9d1a508f5e32dae7224d.NginxMailingListRussian@forum.nginx.org>
References: <075afd26e4ce9d1a508f5e32dae7224d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKqRTSH-iCtE3mMvWfhh=ijdszzhr6vbDh3kNvwK72+VRmiZLQ@mail.gmail.com>

9 сентября 2013 г., 12:25 пользователь demo <nginx-forum at nginx.us> написал:

> Здравствуйте!
> Можно ли как-то организовать работу с вебсокетами на nginx без
> использования
> NodeJS, Socket.IO и т.п.?
> Если это возможно, поделитесь пожалуйста примерами.
>
>
Как вы собираетесь работать в вебсокетами без сервера? Nginx - это всего
лишь прокси
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130909/036ba51d/attachment.html>

From citrin at citrin.ru  Mon Sep  9 10:06:12 2013
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Mon, 09 Sep 2013 14:06:12 +0400
Subject: ssl_prefer_server_ciphers
In-Reply-To: <522D9457.9080008@csdoc.com>
References: <522D9457.9080008@csdoc.com>
Message-ID: <522D9D94.3020202@citrin.ru>

On 09/09/13 13:26, Gena Makhomed wrote:
>
> потому что при ssl_prefer_server_ciphers off;
> nginx подвержен влиянию BEAST-атаки CVE-2011-3389.

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

А что писать в ssl_ciphers вопрос не очень простой.

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

Из того, что поддерживается широко:

AES-CBC - подвержен BEAST
RC4 в теории тоже уязвим: http://www.isg.rhul.ac.uk/tls/ (хотя сильно опасаться 
этого пока не стоит).

И еще возможно бывают клиенты со старыми браузерами, которые не поддерживают ни 
AES и RC4 (таких наверно мало).


From gmm at csdoc.com  Mon Sep  9 11:31:11 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Mon, 09 Sep 2013 14:31:11 +0300
Subject: ssl_prefer_server_ciphers
In-Reply-To: <522D9D94.3020202@citrin.ru>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
Message-ID: <522DB17F.60507@csdoc.com>

On 09.09.2013 13:06, Anton Yuzhaninov wrote:

>> потому что при ssl_prefer_server_ciphers off;
>> nginx подвержен влиянию BEAST-атаки CVE-2011-3389.
>
> Без очень тщательного выбора того что и каком порядке указывать в
> ssl_ciphers это делать смысла мало.
>
> А что писать в ssl_ciphers вопрос не очень простой.
>
> На первом месте логично поставить AES-GCM, но он пока не поддерживается
> большинством браузеров. Да и на сервере для его нужен openssl 1.0.1 а во
> многих дистрибутивах используются более старые версии.

ясно. а нельзя сделать так, чтобы если openssl версии 1.0.1,
то по-умолчанию в ssl_ciphers на первом месте стоял AES-GCM,
а если openssl более ранней версии, тогда лучшее из возможного:

ssl_ciphers RC4:HIGH:!aNULL:!MD5:!kEDH;

а если директива ssl_ciphers будет игнорировать AES-GCM,
если он есть в строке, но openssl его не поддерживает -
то и вообще одной дефолтовой строкой тогда можно обойтись.

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

и тогда nginx будет "secure by default" настолько,
насколько это возможно и это будет гораздо лучше,
чем теперешний более уязвимый дефолт:

ssl_ciphers HIGH:!aNULL:!MD5;

> Из того, что поддерживается широко:
>
> AES-CBC - подвержен BEAST
> RC4 в теории тоже уязвим: http://www.isg.rhul.ac.uk/tls/ (хотя сильно
> опасаться этого пока не стоит).

в интернетах пишут про RC4, что "Пока что в реальных условиях атака 
трудно воспроизводима, но может проводиться крупными организациями"
так что на сегодня RC4 является более предпочтительным, чем AES-CBC

AES-CBC входит в группу HIGH, так что поменяв

ssl_ciphers HIGH:!aNULL:!MD5;

на

ssl_ciphers RC4:HIGH:!aNULL:!MD5:!kEDH;

мы просто скажем клиенту, что cipher RC4 является более предпочтительным
и если какой-то браузер умеет AES-CBC и не умеет RC4 - он будет работать

насколько я понимаю логику работы директивы ssl_prefer_server_ciphers
при ssl_prefer_server_ciphers on: будет выбран наилучший cipher из тех, 
что предпочитает сервер и поддерживает клиент. т.е. будет выбран:
(1)AES-GCM или (2)RC4 или любой другой из (3)HIGH (AES-CBC и т.п.)

> И еще возможно бывают клиенты со старыми браузерами, которые не
> поддерживают ни AES и RC4 (таких наверно мало).

может быть имеет смысл в документации к nginx написать рекомендацию,
чтобы пользователи после настройки ssl проверили свой сайт на предмет 
уязвимостей на сайте https://www.ssllabs.com/ssltest/ ?

и почитали SSL/TLS Deployment Best Practices https://www.ssllabs.com/

подозреваю, что многие пользователи считают, что nginx имеет дефолтовые
значения параметров такие, что он будет "secure by default" и они даже
не догадываются про все эти уязвимости и нюансы в настройке ssl в nginx.

-- 
Best regards,
  Gena


From mdounin at mdounin.ru  Mon Sep  9 12:35:23 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 9 Sep 2013 16:35:23 +0400
Subject: ssl_prefer_server_ciphers
In-Reply-To: <522DB17F.60507@csdoc.com>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com>
Message-ID: <20130909123523.GD20921@mdounin.ru>

Hello!

On Mon, Sep 09, 2013 at 02:31:11PM +0300, Gena Makhomed wrote:

> On 09.09.2013 13:06, Anton Yuzhaninov wrote:
> 
> >>потому что при ssl_prefer_server_ciphers off;
> >>nginx подвержен влиянию BEAST-атаки CVE-2011-3389.
> >
> >Без очень тщательного выбора того что и каком порядке указывать в
> >ssl_ciphers это делать смысла мало.
> >
> >А что писать в ssl_ciphers вопрос не очень простой.
> >
> >На первом месте логично поставить AES-GCM, но он пока не поддерживается
> >большинством браузеров. Да и на сервере для его нужен openssl 1.0.1 а во
> >многих дистрибутивах используются более старые версии.
> 
> ясно. а нельзя сделать так, чтобы если openssl версии 1.0.1,
> то по-умолчанию в ssl_ciphers на первом месте стоял AES-GCM,
> а если openssl более ранней версии, тогда лучшее из возможного:
> 
> ssl_ciphers RC4:HIGH:!aNULL:!MD5:!kEDH;

Если говорить о борьбе с BEAST'ом, то правильных решений два:

1) Решать проблему переходом на TLS 1.1+ (в том числе AES-CBC 
будет работать нормально).

2) Решать проблему на стороне клиента (собственно, все современные 
браузеры это делают).

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

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

Что до ssl_prefer_server_ciphers, то оно имеет смысл в случае 
использования конструкций вроде вышеописанного anti-BEAST решения.  
Включать же его при ssl_ciphers по умолчанию - особого смысла нет.

[...]

> может быть имеет смысл в документации к nginx написать рекомендацию,
> чтобы пользователи после настройки ssl проверили свой сайт на
> предмет уязвимостей на сайте https://www.ssllabs.com/ssltest/ ?
> 
> и почитали SSL/TLS Deployment Best Practices https://www.ssllabs.com/
> 
> подозреваю, что многие пользователи считают, что nginx имеет дефолтовые
> значения параметров такие, что он будет "secure by default" и они даже
> не догадываются про все эти уязвимости и нюансы в настройке ssl в nginx.

Почитать ssllabs.com - это завсегда полезно.  :)

В частности, сейчас там на голове висит ссылка на вот эту статью Ivan'а
Ristic'а:

RC4 in TLS is Broken: Now What?
https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what

А в тестах сейчас светится:

BEAST attack: No longer rated; considered sufficiently mitigated client-side

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


From anatoly at sonru.com  Tue Sep 10 09:18:50 2013
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Tue, 10 Sep 2013 10:18:50 +0100
Subject: ssl_prefer_server_ciphers
In-Reply-To: <20130909123523.GD20921@mdounin.ru>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
Message-ID: <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>


On Sep 9, 2013, at 1:35 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
> 
> On Mon, Sep 09, 2013 at 02:31:11PM +0300, Gena Makhomed wrote:
> 
>> On 09.09.2013 13:06, Anton Yuzhaninov wrote:
>> 
>>>> потому что при ssl_prefer_server_ciphers off;
>>>> nginx подвержен влиянию BEAST-атаки CVE-2011-3389.
>>> 
>>> Без очень тщательного выбора того что и каком порядке указывать в
>>> ssl_ciphers это делать смысла мало.
>>> 
>>> А что писать в ssl_ciphers вопрос не очень простой.
>>> 
>>> На первом месте логично поставить AES-GCM, но он пока не поддерживается
>>> большинством браузеров. Да и на сервере для его нужен openssl 1.0.1 а во
>>> многих дистрибутивах используются более старые версии.
>> 
>> ясно. а нельзя сделать так, чтобы если openssl версии 1.0.1,
>> то по-умолчанию в ssl_ciphers на первом месте стоял AES-GCM,
>> а если openssl более ранней версии, тогда лучшее из возможного:
>> 
>> ssl_ciphers RC4:HIGH:!aNULL:!MD5:!kEDH;
> 
> Если говорить о борьбе с BEAST'ом, то правильных решений два:
> 
> 1) Решать проблему переходом на TLS 1.1+ (в том числе AES-CBC 
> будет работать нормально).
> 
> 2) Решать проблему на стороне клиента (собственно, все современные 
> браузеры это делают).
> 
> Использование RC4 - это костыль, заметно ухудшающий безопасность с 
> остальных точек зрения.  Его имело смысл использовать в момент 
> появления BEAST-атаки, сейчас - скорее не имеет.
> 
> Что до значения по умолчанию директивы ssl_ciphers, то оно выбрано 
> так, чтобы обеспечить максимальную безопасность на длинном отрезке 
> времени и требовать минимума изменений.
> 
> Что до ssl_prefer_server_ciphers, то оно имеет смысл в случае 
> использования конструкций вроде вышеописанного anti-BEAST решения.  
> Включать же его при ssl_ciphers по умолчанию - особого смысла нет.
> 

Максим, насколько такая конфигурация сейчас актуальна и надежна?

    ssl_session_timeout       15m;
    ssl_protocols             SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers               RC4:HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    ssl_session_cache         shared:SSL:10m;

Данная конфигурация набирает 100/90/80/90 (Rating A) на Qualys SSL Labs.

И второй вопрос, в плане _безопасности_ стоит обновляться 
с Nginx 1.3.14 до последней стабильной версии?


Анатолий


> [...]
> 
>> может быть имеет смысл в документации к nginx написать рекомендацию,
>> чтобы пользователи после настройки ssl проверили свой сайт на
>> предмет уязвимостей на сайте https://www.ssllabs.com/ssltest/ ?
>> 
>> и почитали SSL/TLS Deployment Best Practices https://www.ssllabs.com/
>> 
>> подозреваю, что многие пользователи считают, что nginx имеет дефолтовые
>> значения параметров такие, что он будет "secure by default" и они даже
>> не догадываются про все эти уязвимости и нюансы в настройке ssl в nginx.
> 
> Почитать ssllabs.com - это завсегда полезно.  :)
> 
> В частности, сейчас там на голове висит ссылка на вот эту статью Ivan'а
> Ristic'а:
> 
> RC4 in TLS is Broken: Now What?
> https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
> 
> А в тестах сейчас светится:
> 
> BEAST attack: No longer rated; considered sufficiently mitigated client-side
> 
> -- 
> Maxim Dounin
> http://nginx.org/en/donation.html
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From nginx-forum at nginx.us  Tue Sep 10 11:02:33 2013
From: nginx-forum at nginx.us (valch85)
Date: Tue, 10 Sep 2013 07:02:33 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C+0LvRg9GH0LjRgtGMINC+0YIgUEhQLUZQTSDQutC+0LQg?=
 =?UTF-8?B?0L7RiNC40LHQutC4LCDQvtGC0LvQuNGH0L3Ri9C5INC+0YIgMjAwLCDQv9GA?=
 =?UTF-8?B?0LggUEhQIEZhdGFsIGVycm9yPw==?=
In-Reply-To: <CAOheUCpJjNmGsySqW8JXRZqA5GvacNkhbmWW8e7nCg8tGcU0LQ@mail.gmail.com>
References: <CAOheUCpJjNmGsySqW8JXRZqA5GvacNkhbmWW8e7nCg8tGcU0LQ@mail.gmail.com>
Message-ID: <b800277228542cfddcdbd5cf321dc5c3.NginxMailingListRussian@forum.nginx.org>

Попробуйте в /etc/php5/fpm/php-fpm.conf прописал 
php_admin_flag[display_errors] = on
у меня начало выводить ошибки в браузер

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


From nginx-forum at nginx.us  Tue Sep 10 11:06:30 2013
From: nginx-forum at nginx.us (valch85)
Date: Tue, 10 Sep 2013 07:06:30 -0400
Subject: =?UTF-8?B?UmU6IDIwMCDQvtGC0LLQtdGCINC/0YDQuCDQvtGC0YHRg9GC0YHQstC40Lgg0YQ=?=
 =?UTF-8?B?0LDQudC70LA=?=
In-Reply-To: <4dca8bd037b982aecaf2d8d054a1204e.NginxMailingListRussian@forum.nginx.org>
References: <4dca8bd037b982aecaf2d8d054a1204e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <39f5da5a05855ea82652741eaf945384.NginxMailingListRussian@forum.nginx.org>

Проблема решена. Всем спасибо
Такая конфигурация заработала нормально

location /blog {
access_log /data0/logs/nginx/blog_log blog2;
error_log /var/log/nginx/test.log debug;
root /var/www/blog2.site.com;
index index.php;
try_files $uri $uri/ /blog/index.php?$query_string;

        location ~ \.php$ {
                fastcgi_pass 127.0.0.1:9000;
                fastcgi_index index.php;
                fastcgi_intercept_errors on;
                fastcgi_param SCRIPT_FILENAME
/var/www/blog2.site.com$fastcgi_script_name;
                include fastcgi.conf;
        }

       location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
                expires max;
                log_not_found off;
        }
}

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


From maxout.mail at gmail.com  Tue Sep 10 11:29:27 2013
From: maxout.mail at gmail.com (Ktulhu Ftagn)
Date: Tue, 10 Sep 2013 18:29:27 +0700
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C+0LvRg9GH0LjRgtGMINC+0YIgUEhQLUZQTSDQutC+0LQg?=
 =?UTF-8?B?0L7RiNC40LHQutC4LCDQvtGC0LvQuNGH0L3Ri9C5INC+0YIgMjAwLCDQv9GA?=
 =?UTF-8?B?0LggUEhQIEZhdGFsIGVycm9yPw==?=
In-Reply-To: <b800277228542cfddcdbd5cf321dc5c3.NginxMailingListRussian@forum.nginx.org>
References: <CAOheUCpJjNmGsySqW8JXRZqA5GvacNkhbmWW8e7nCg8tGcU0LQ@mail.gmail.com>
 <b800277228542cfddcdbd5cf321dc5c3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAOheUCrF6Vir7v_duKazrDTd82PLBZgTE8EVN9gNDhcqK_LK1Q@mail.gmail.com>

Ошибки выводятся, только код ответа при этом 200
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130910/fb84982c/attachment.html>

From nginx-forum at nginx.us  Tue Sep 10 12:07:51 2013
From: nginx-forum at nginx.us (burlaka)
Date: Tue, 10 Sep 2013 08:07:51 -0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIHByb3h5IHJlZGlyZWN0?=
In-Reply-To: <201309081929.12036.vbart@nginx.com>
References: <201309081929.12036.vbart@nginx.com>
Message-ID: <ff547b37f92b739cb92e149716b963e7.NginxMailingListRussian@forum.nginx.org>

Конфиг ровно как я написал выше:
        location /bpm1/ {
                proxy_pass https://proto4.portal.local:9443/;
                proxy_redirect https://proto4.portal.local:9443/
https://wpsdm.portal.local:9443/bpm1/;
        }

Делаю запрос: curl -v -k
https://wpsdm.portal.local:9443/bpm1/ProcessPortal/
> GET /bpm1/ProcessPortal/ HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5
OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: wpsdm.portal.local:9443
> Accept: */*
>
< HTTP/1.1 302 Found
< Server: nginx/1.5.3
< Date: Tue, 10 Sep 2013 08:06:13 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 0
< Connection: keep-alive
< X-Powered-By: Servlet/3.0
< Location: https://wpsdm.portal.local:9443/ProcessPortal/jsp/index.jsp
< Content-Language: ru-RU
< Set-Cookie: JSESSIONID=0000XvN3inHgBBXhcSWW0NkVovd:17v6qmgqn; Path=/;
HttpOnly
< Expires: Thu, 01 Dec 1994 16:00:00 GMT
< Cache-Control: no-cache="set-cookie, set-cookie2"

Заголовок Location исправлен, но без учета /bpm1/ как указано в директиве.
В чем может быть ошибка?

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


From mdounin at mdounin.ru  Tue Sep 10 12:34:36 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 10 Sep 2013 16:34:36 +0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIHByb3h5IHJlZGlyZWN0?=
In-Reply-To: <ff547b37f92b739cb92e149716b963e7.NginxMailingListRussian@forum.nginx.org>
References: <201309081929.12036.vbart@nginx.com>
 <ff547b37f92b739cb92e149716b963e7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130910123436.GI20921@mdounin.ru>

Hello!

On Tue, Sep 10, 2013 at 08:07:51AM -0400, burlaka wrote:

> Конфиг ровно как я написал выше:
>         location /bpm1/ {
>                 proxy_pass https://proto4.portal.local:9443/;
>                 proxy_redirect https://proto4.portal.local:9443/
> https://wpsdm.portal.local:9443/bpm1/;
>         }
> 
> Делаю запрос: curl -v -k
> https://wpsdm.portal.local:9443/bpm1/ProcessPortal/
> > GET /bpm1/ProcessPortal/ HTTP/1.1
> > User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5
> OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> > Host: wpsdm.portal.local:9443
> > Accept: */*
> >
> < HTTP/1.1 302 Found
> < Server: nginx/1.5.3
> < Date: Tue, 10 Sep 2013 08:06:13 GMT
> < Content-Type: text/html; charset=UTF-8
> < Content-Length: 0
> < Connection: keep-alive
> < X-Powered-By: Servlet/3.0
> < Location: https://wpsdm.portal.local:9443/ProcessPortal/jsp/index.jsp
> < Content-Language: ru-RU
> < Set-Cookie: JSESSIONID=0000XvN3inHgBBXhcSWW0NkVovd:17v6qmgqn; Path=/;
> HttpOnly
> < Expires: Thu, 01 Dec 1994 16:00:00 GMT
> < Cache-Control: no-cache="set-cookie, set-cookie2"
> 
> Заголовок Location исправлен, но без учета /bpm1/ как указано в директиве.
> В чем может быть ошибка?

Скорее всего проблема в том, что заголовок Location не 
исправлен, а именно такой и пришёл с бекенда.

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


From nginx-forum at nginx.us  Tue Sep 10 15:45:50 2013
From: nginx-forum at nginx.us (burlaka)
Date: Tue, 10 Sep 2013 11:45:50 -0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIHByb3h5IHJlZGlyZWN0?=
In-Reply-To: <20130910123436.GI20921@mdounin.ru>
References: <20130910123436.GI20921@mdounin.ru>
Message-ID: <25701b2e5321c26f41a18fcf455b5de0.NginxMailingListRussian@forum.nginx.org>

Такой с бекэнда прийти не мог. Бекэнд ничего не знает про
wpsdm.portal.local.

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


From onokonem at gmail.com  Tue Sep 10 16:02:37 2013
From: onokonem at gmail.com (Daniel Podolsky)
Date: Tue, 10 Sep 2013 20:02:37 +0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIHByb3h5IHJlZGlyZWN0?=
In-Reply-To: <25701b2e5321c26f41a18fcf455b5de0.NginxMailingListRussian@forum.nginx.org>
References: <20130910123436.GI20921@mdounin.ru>
 <25701b2e5321c26f41a18fcf455b5de0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKaHDOFFh8j7Mz3oBQ1dKiR_PuHHZ2f_=UNKEQRuUHoo_yhQ7w@mail.gmail.com>

> Такой с бекэнда прийти не мог. Бекэнд ничего не знает про
> wpsdm.portal.local.
Ну кто же вам мешает взять в руки снифер, и поглядеть, чем там
обмениваются nginx и backend?

From mdounin at mdounin.ru  Wed Sep 11 10:27:23 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 11 Sep 2013 14:27:23 +0400
Subject: =?UTF-8?B?UmU6INC60LDQuiDRgNCw0LHQvtGC0LDQtdGCIHByb3h5IHJlZGlyZWN0?=
In-Reply-To: <25701b2e5321c26f41a18fcf455b5de0.NginxMailingListRussian@forum.nginx.org>
References: <20130910123436.GI20921@mdounin.ru>
 <25701b2e5321c26f41a18fcf455b5de0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130911102722.GJ20921@mdounin.ru>

Hello!

On Tue, Sep 10, 2013 at 11:45:50AM -0400, burlaka wrote:

> Такой с бекэнда прийти не мог. Бекэнд ничего не знает про
> wpsdm.portal.local.

Для того, чтобы бекенд узнал - достаточно, чтобы в конфиге было 
что-нибудь вроде "proxy_set_header Host $host".  Не надо гадать - 
проверьте, tcpdump и/или debug log в помощь.

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

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


From nginx-forum at nginx.us  Wed Sep 11 13:25:11 2013
From: nginx-forum at nginx.us (F1restorm)
Date: Wed, 11 Sep 2013 09:25:11 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0LrQsNGB0YLQvtC80L3Ri9C80Lggc2Vu?=
 =?UTF-8?B?dCBodHRwINC30LDQs9C+0LvQvtCy0LrQsNC80Lg=?=
In-Reply-To: <df4f1a0c9e7025c9e109ee481757046c.NginxMailingListRussian@forum.nginx.org>
References: <df4f1a0c9e7025c9e109ee481757046c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <24815cacd3b3bdedb3c5ebcb364cc9ea.NginxMailingListRussian@forum.nginx.org>

В дополнение к вышеописанной ситуации не работает конструкция вида:
error_page 400 http://site/page?server=$sent_http_server;

Всегда перенаправление выполняется на "http://site/page?server=", а не
"http://site/page?server=nginx".
Хотя в ответе есть заголовок "Server:nginx".

Как все же заставить nginx передавать заголовок в URL?

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


From mdounin at mdounin.ru  Wed Sep 11 13:37:54 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 11 Sep 2013 17:37:54 +0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0LrQsNGB0YLQvtC80L3Ri9C80Lggc2Vu?=
 =?UTF-8?B?dCBodHRwINC30LDQs9C+0LvQvtCy0LrQsNC80Lg=?=
In-Reply-To: <24815cacd3b3bdedb3c5ebcb364cc9ea.NginxMailingListRussian@forum.nginx.org>
References: <df4f1a0c9e7025c9e109ee481757046c.NginxMailingListRussian@forum.nginx.org>
 <24815cacd3b3bdedb3c5ebcb364cc9ea.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130911133754.GO20921@mdounin.ru>

Hello!

On Wed, Sep 11, 2013 at 09:25:11AM -0400, F1restorm wrote:

> В дополнение к вышеописанной ситуации не работает конструкция вида:
> error_page 400 http://site/page?server=$sent_http_server;
> 
> Всегда перенаправление выполняется на "http://site/page?server=", а не
> "http://site/page?server=nginx".
> Хотя в ответе есть заголовок "Server:nginx".
> 
> Как все же заставить nginx передавать заголовок в URL?

Заголовок Server появляется лишь в тот момент, когда формируются 
заголовки ответа.  В то же время, перенаправление с помощью 
директивы error_page происходит _до_ того, как сформирован ответ, 
в том числе - его заголовок, и соответственно использовать 
$sent_http_server при формировании ответа - бессмысленно.

Что можно использовать, это заголовки, полученные от бекенда - 
$upstream_http_..., подробнее тут:

http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#variables

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


From anatoly at sonru.com  Wed Sep 11 16:28:09 2013
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Wed, 11 Sep 2013 17:28:09 +0100
Subject: ssl_prefer_server_ciphers
In-Reply-To: <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
 <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
Message-ID: <CF48096A-F6EE-4FB7-9429-26B32D601EFD@sonru.com>


On Sep 10, 2013, at 10:18 AM, Anatoly Mikhailov <anatoly at sonru.com> wrote:

> 
> On Sep 9, 2013, at 1:35 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
>> Hello!
>> 
>> On Mon, Sep 09, 2013 at 02:31:11PM +0300, Gena Makhomed wrote:
>> 
>>> On 09.09.2013 13:06, Anton Yuzhaninov wrote:
>>> 
>>>>> потому что при ssl_prefer_server_ciphers off;
>>>>> nginx подвержен влиянию BEAST-атаки CVE-2011-3389.
>>>> 
>>>> Без очень тщательного выбора того что и каком порядке указывать в
>>>> ssl_ciphers это делать смысла мало.
>>>> 
>>>> А что писать в ssl_ciphers вопрос не очень простой.
>>>> 
>>>> На первом месте логично поставить AES-GCM, но он пока не поддерживается
>>>> большинством браузеров. Да и на сервере для его нужен openssl 1.0.1 а во
>>>> многих дистрибутивах используются более старые версии.
>>> 
>>> ясно. а нельзя сделать так, чтобы если openssl версии 1.0.1,
>>> то по-умолчанию в ssl_ciphers на первом месте стоял AES-GCM,
>>> а если openssl более ранней версии, тогда лучшее из возможного:
>>> 
>>> ssl_ciphers RC4:HIGH:!aNULL:!MD5:!kEDH;
>> 
>> Если говорить о борьбе с BEAST'ом, то правильных решений два:
>> 
>> 1) Решать проблему переходом на TLS 1.1+ (в том числе AES-CBC 
>> будет работать нормально).
>> 
>> 2) Решать проблему на стороне клиента (собственно, все современные 
>> браузеры это делают).
>> 
>> Использование RC4 - это костыль, заметно ухудшающий безопасность с 
>> остальных точек зрения.  Его имело смысл использовать в момент 
>> появления BEAST-атаки, сейчас - скорее не имеет.
>> 
>> Что до значения по умолчанию директивы ssl_ciphers, то оно выбрано 
>> так, чтобы обеспечить максимальную безопасность на длинном отрезке 
>> времени и требовать минимума изменений.
>> 
>> Что до ssl_prefer_server_ciphers, то оно имеет смысл в случае 
>> использования конструкций вроде вышеописанного anti-BEAST решения.  
>> Включать же его при ssl_ciphers по умолчанию - особого смысла нет.
>> 
> 
> Максим, насколько такая конфигурация сейчас актуальна и надежна?
> 
>    ssl_session_timeout       15m;
>    ssl_protocols             SSLv3 TLSv1 TLSv1.1 TLSv1.2;
>    ssl_ciphers               RC4:HIGH:!aNULL:!MD5;
>    ssl_prefer_server_ciphers on;
>    ssl_session_cache         shared:SSL:10m;
> 
> Данная конфигурация набирает 100/90/80/90 (Rating A) на Qualys SSL Labs.
> 
> И второй вопрос, в плане _безопасности_ стоит обновляться 
> с Nginx 1.3.14 до последней стабильной версии?

Обновление Nginx до последней стабильной версии в планах, но пока
очень интересно узнать, насколько это критично в плане безопасности.

> 
> 
> Анатолий
> 
> 
>> [...]
>> 
>>> может быть имеет смысл в документации к nginx написать рекомендацию,
>>> чтобы пользователи после настройки ssl проверили свой сайт на
>>> предмет уязвимостей на сайте https://www.ssllabs.com/ssltest/ ?
>>> 
>>> и почитали SSL/TLS Deployment Best Practices https://www.ssllabs.com/
>>> 
>>> подозреваю, что многие пользователи считают, что nginx имеет дефолтовые
>>> значения параметров такие, что он будет "secure by default" и они даже
>>> не догадываются про все эти уязвимости и нюансы в настройке ssl в nginx.
>> 
>> Почитать ssllabs.com - это завсегда полезно.  :)
>> 
>> В частности, сейчас там на голове висит ссылка на вот эту статью Ivan'а
>> Ristic'а:
>> 
>> RC4 in TLS is Broken: Now What?
>> https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
>> 
>> А в тестах сейчас светится:
>> 
>> BEAST attack: No longer rated; considered sufficiently mitigated client-side
>> 
>> -- 
>> Maxim Dounin
>> http://nginx.org/en/donation.html
>> 
>> _______________________________________________
>> 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 mdounin at mdounin.ru  Wed Sep 11 16:54:54 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 11 Sep 2013 20:54:54 +0400
Subject: ssl_prefer_server_ciphers
In-Reply-To: <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
 <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
Message-ID: <20130911165454.GQ20921@mdounin.ru>

Hello!

On Tue, Sep 10, 2013 at 10:18:50AM +0100, Anatoly Mikhailov wrote:

[...]

> Максим, насколько такая конфигурация сейчас актуальна и надежна?
> 
>     ssl_session_timeout       15m;
>     ssl_protocols             SSLv3 TLSv1 TLSv1.1 TLSv1.2;
>     ssl_ciphers               RC4:HIGH:!aNULL:!MD5;
>     ssl_prefer_server_ciphers on;
>     ssl_session_cache         shared:SSL:10m;
> 
> Данная конфигурация набирает 100/90/80/90 (Rating A) на Qualys SSL Labs.

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

> И второй вопрос, в плане _безопасности_ стоит обновляться 
> с Nginx 1.3.14 до последней стабильной версии?

Как минимум пропатчить - необходимо.  См. 
http://nginx.org/en/security_advisories.html.

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


From anatoly at sonru.com  Wed Sep 11 17:30:07 2013
From: anatoly at sonru.com (Anatoly Mikhailov)
Date: Wed, 11 Sep 2013 18:30:07 +0100
Subject: ssl_prefer_server_ciphers
In-Reply-To: <20130911165454.GQ20921@mdounin.ru>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
 <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
 <20130911165454.GQ20921@mdounin.ru>
Message-ID: <D3FD9BC0-48D7-462B-BD91-4D7372D8F6C8@sonru.com>


On Sep 11, 2013, at 5:54 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
> 
> On Tue, Sep 10, 2013 at 10:18:50AM +0100, Anatoly Mikhailov wrote:
> 
> [...]
> 
>> Максим, насколько такая конфигурация сейчас актуальна и надежна?
>> 
>>    ssl_session_timeout       15m;
>>    ssl_protocols             SSLv3 TLSv1 TLSv1.1 TLSv1.2;
>>    ssl_ciphers               RC4:HIGH:!aNULL:!MD5;
>>    ssl_prefer_server_ciphers on;
>>    ssl_session_cache         shared:SSL:10m;
>> 
>> Данная конфигурация набирает 100/90/80/90 (Rating A) на Qualys SSL Labs.
> 
> Насколько я понимаю, практических атак на RC4 пока нет, так что 
> это вполне нормальный конфиг.  В перспективе - из него, видимо, 
> следует убирать RC4.  (Отдельно отмечу, что вышеизложенное - про 
> безопасность.  Если параллельно думать ещё и про 
> производительность, то всё становится куда интереснее.)

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

> 
>> И второй вопрос, в плане _безопасности_ стоит обновляться 
>> с Nginx 1.3.14 до последней стабильной версии?
> 
> Как минимум пропатчить - необходимо.  См. 
> http://nginx.org/en/security_advisories.html.

спасибо огромное!

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


From mdounin at mdounin.ru  Wed Sep 11 17:59:33 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 11 Sep 2013 21:59:33 +0400
Subject: ssl_prefer_server_ciphers
In-Reply-To: <D3FD9BC0-48D7-462B-BD91-4D7372D8F6C8@sonru.com>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
 <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
 <20130911165454.GQ20921@mdounin.ru>
 <D3FD9BC0-48D7-462B-BD91-4D7372D8F6C8@sonru.com>
Message-ID: <20130911175933.GR20921@mdounin.ru>

Hello!

On Wed, Sep 11, 2013 at 06:30:07PM +0100, Anatoly Mikhailov wrote:

> 
> On Sep 11, 2013, at 5:54 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > Hello!
> > 
> > On Tue, Sep 10, 2013 at 10:18:50AM +0100, Anatoly Mikhailov wrote:
> > 
> > [...]
> > 
> >> Максим, насколько такая конфигурация сейчас актуальна и надежна?
> >> 
> >>    ssl_session_timeout       15m;
> >>    ssl_protocols             SSLv3 TLSv1 TLSv1.1 TLSv1.2;
> >>    ssl_ciphers               RC4:HIGH:!aNULL:!MD5;
> >>    ssl_prefer_server_ciphers on;
> >>    ssl_session_cache         shared:SSL:10m;
> >> 
> >> Данная конфигурация набирает 100/90/80/90 (Rating A) на Qualys SSL Labs.
> > 
> > Насколько я понимаю, практических атак на RC4 пока нет, так что 
> > это вполне нормальный конфиг.  В перспективе - из него, видимо, 
> > следует убирать RC4.  (Отдельно отмечу, что вышеизложенное - про 
> > безопасность.  Если параллельно думать ещё и про 
> > производительность, то всё становится куда интереснее.)
> 
> Есть ли разумный компромисс между достаточным уровнем безопасности и производительностью?

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

Если нет - то можно, например, пожертвовать forward secrecy в 
некоторых случаях, и оставить только ECDHE, запретив DHE.  Или 
вообще пожертвовать forward secrecy, предпочтя RC4-SHA.  Но я бы 
не рекомендовал трогать без необходимости и хорошего понимания 
последствий.

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


From gmm at csdoc.com  Wed Sep 11 18:08:11 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Wed, 11 Sep 2013 21:08:11 +0300
Subject: ssl_prefer_server_ciphers
In-Reply-To: <D3FD9BC0-48D7-462B-BD91-4D7372D8F6C8@sonru.com>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
 <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
 <20130911165454.GQ20921@mdounin.ru>
 <D3FD9BC0-48D7-462B-BD91-4D7372D8F6C8@sonru.com>
Message-ID: <5230B18B.3000106@csdoc.com>

On 11.09.2013 20:30, Anatoly Mikhailov wrote:

>>> насколько такая конфигурация сейчас актуальна и надежна?
>>>
>>>     ssl_session_timeout       15m;
>>>     ssl_protocols             SSLv3 TLSv1 TLSv1.1 TLSv1.2;
>>>     ssl_ciphers               RC4:HIGH:!aNULL:!MD5;
>>>     ssl_prefer_server_ciphers on;
>>>     ssl_session_cache         shared:SSL:10m;
>>>
>>> Данная конфигурация набирает 100/90/80/90 (Rating A) на Qualys SSL Labs.

1) легко можно поднять до 100/90/90/90, прописав в ssl_dhparam 2048 бит.

$ openssl dhparam -out dh2048.pem 2048

Read The Full Manual: 
http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html

2) добавить немного скорости работы с сайтом можно включив ssl_stapling.

3) желательно использовать latest stable версию OpenSSL, для TLS 1.1/1.2

-- 
Best regards,
  Gena


From nginx-ru at sadok.spb.ru  Wed Sep 11 18:18:35 2013
From: nginx-ru at sadok.spb.ru (Dmitry Ivanov)
Date: Wed, 11 Sep 2013 22:18:35 +0400
Subject: ssl_prefer_server_ciphers
In-Reply-To: <CF48096A-F6EE-4FB7-9429-26B32D601EFD@sonru.com>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
 <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
 <CF48096A-F6EE-4FB7-9429-26B32D601EFD@sonru.com>
Message-ID: <179979707.20130911221835@sadok.spb.ru>

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

Вы писали 11 сентября 2013 г., 20:28:09:

> Обновление Nginx до последней стабильной версии в планах, но пока
> очень интересно узнать, насколько это критично в плане безопасности.

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

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


From gmm at csdoc.com  Wed Sep 11 18:31:58 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Wed, 11 Sep 2013 21:31:58 +0300
Subject: ssl_prefer_server_ciphers
In-Reply-To: <20130911175933.GR20921@mdounin.ru>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
 <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
 <20130911165454.GQ20921@mdounin.ru>
 <D3FD9BC0-48D7-462B-BD91-4D7372D8F6C8@sonru.com>
 <20130911175933.GR20921@mdounin.ru>
Message-ID: <5230B71E.9@csdoc.com>

On 11.09.2013 20:59, Maxim Dounin wrote:

> Если нет - то можно, например, пожертвовать forward secrecy в
> некоторых случаях, и оставить только ECDHE, запретив DHE.  Или
> вообще пожертвовать forward secrecy, предпочтя RC4-SHA.  Но я бы
> не рекомендовал трогать без необходимости и хорошего понимания
> последствий.

кстати, http://www.opennet.ru/opennews/art.shtml?num=37846

Шнайер не рекомендует применять стандарты шифрования по эллиптическим 
кривым, так как АНБ активно участвовало в их разработке. Сразу 
вспоминается история с заявлениями о попытках внедрения бэкдора в 
IPSEC-стек OpenBSD.

и вот еще: http://habrahabr.ru/post/192722/

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

в связи с чем сразу вспоминается http://en.wikipedia.org/wiki/NSAKEY

и статья http://www.3dnews.ru/650677

-- 
Best regards,
  Gena


From nginx-forum at nginx.us  Wed Sep 11 19:59:39 2013
From: nginx-forum at nginx.us (SergeyFs)
Date: Wed, 11 Sep 2013 15:59:39 -0400
Subject: =?UTF-8?B?bGltaXQgcmVxIHpvbmUgIC0g0L3QtdC60L7RgNGA0LXQutGC0YvQuSDQv9C+0LQ=?=
 =?UTF-8?B?0YHRh9C10YIg0YfQuNGB0LvQsCDQt9Cw0L/RgNC+0YHRgtC+0LIgPw==?=
Message-ID: <c211cbcd80fbc215c65ce8a7f38d4523.NginxMailingListRussian@forum.nginx.org>

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

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

AWS, nginx стоит за лоад балансером. 

nginx.conf :

    set_real_ip_from 10.0.0.0/16;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    limit_req_zone  $binary_remote_addr zone=basic:16m rate=300r/s;

......
    location ~* \.(html)$ {
        limit_req   zone=basic  nodelay;
.....

Лимит специально сделан сильно выше, чем в принципе нужно (реквест рэйт
вообще не превышает 10r/s по данным амазона)  Но несмотря на это я в логах
вижу (поправил dns и ip):

2013/09/09 23:19:54 [error] 4818#0: *328855 limiting requests, excess: 0.700
by zone "basic", client: 6.1.2.194, server: dev.testserver.io, request: "GET
/scripts/ops/views/organizations/organizations.html HTTP/1.1", host:
"dev.testserver.io", referrer: "https://dev.testserver.io/ops.html"
2013/09/09 23:21:46 [error] 4818#0: *329120 limiting requests, excess: 1.000
by zone "basic", client: 6.1.2.194, server: dev.testserver.io, request: "GET
/scripts/ops/views/organizations/organizations.html HTTP/1.1", host:
"dev.tesserver.io", referrer: "https://dev.testserver.io/ops.html"
2013/09/09 23:21:46 [error] 4818#0: *329120 limiting requests, excess: 0.700
by zone "basic", client: 6.1.2.194, server: dev.testserver.io, request: "GET
/scripts/ops/views/organizations/organizations.list.html HTTP/1.1", host:
dev.testserver.io", referrer: "https://dev.testserver.io/ops.html"


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

Спасибо,
Сергей

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


From vbart at nginx.com  Wed Sep 11 20:07:52 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Thu, 12 Sep 2013 00:07:52 +0400
Subject: =?UTF-8?B?UmU6IGxpbWl0IHJlcSB6b25lICAtICDQvdC10LrQvtGA0YDQtdC60YLRi9C5INC/?=
 =?UTF-8?B?0L7QtNGB0YfQtdGCINGH0LjRgdC70LAg0LfQsNC/0YDQvtGB0YLQvtCyID8=?=
In-Reply-To: <c211cbcd80fbc215c65ce8a7f38d4523.NginxMailingListRussian@forum.nginx.org>
References: <c211cbcd80fbc215c65ce8a7f38d4523.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201309120007.52511.vbart@nginx.com>

On Wednesday 11 September 2013 23:59:39 SergeyFs wrote:
> Добрый день всем...
> 
> Пытался сделать ограничение кол-ва запросов для одного локейшена, и
> сталкнулся с непонятным для меня эффектом.
> 
> AWS, nginx стоит за лоад балансером.
> 
> nginx.conf :
> 
>     set_real_ip_from 10.0.0.0/16;
>     real_ip_header X-Forwarded-For;
>     real_ip_recursive on;
> 
>     limit_req_zone  $binary_remote_addr zone=basic:16m rate=300r/s;
> 
> ......
>     location ~* \.(html)$ {
>         limit_req   zone=basic  nodelay;
> .....
> 
> Лимит специально сделан сильно выше, чем в принципе нужно (реквест рэйт
> вообще не превышает 10r/s по данным амазона)  Но несмотря на это я в логах
> вижу (поправил dns и ip):
> 
> 2013/09/09 23:19:54 [error] 4818#0: *328855 limiting requests, excess:
> 0.700 by zone "basic", client: 6.1.2.194, server: dev.testserver.io,
> request: "GET /scripts/ops/views/organizations/organizations.html
> HTTP/1.1", host: "dev.testserver.io", referrer:
> "https://dev.testserver.io/ops.html" 2013/09/09 23:21:46 [error] 4818#0:
> *329120 limiting requests, excess: 1.000 by zone "basic", client:
> 6.1.2.194, server: dev.testserver.io, request: "GET
> /scripts/ops/views/organizations/organizations.html HTTP/1.1", host:
> "dev.tesserver.io", referrer: "https://dev.testserver.io/ops.html"
> 2013/09/09 23:21:46 [error] 4818#0: *329120 limiting requests, excess:
> 0.700 by zone "basic", client: 6.1.2.194, server: dev.testserver.io,
> request: "GET /scripts/ops/views/organizations/organizations.list.html
> HTTP/1.1", host: dev.testserver.io", referrer:
> "https://dev.testserver.io/ops.html"
> 
> 
> подскажите, пожалуйста, в чем может быть причина...

В том, что "реквест рэйт" все-таки превысил 300r/s.  Это не так сложно, как
может показаться.  Достаточно послать два запроса с интервалом менее 3-х 
миллисекунд.

--
Валентин Бартенев
http://nginx.org/en/donation.html

From nginx-forum at nginx.us  Wed Sep 11 21:39:19 2013
From: nginx-forum at nginx.us (SergeyFs)
Date: Wed, 11 Sep 2013 17:39:19 -0400
Subject: =?UTF-8?B?UmU6IGxpbWl0IHJlcSB6b25lIC0g0L3QtdC60L7RgNGA0LXQutGC0YvQuSDQv9C+?=
 =?UTF-8?B?0LTRgdGH0LXRgiDRh9C40YHQu9CwINC30LDQv9GA0L7RgdGC0L7QsiA/?=
In-Reply-To: <201309120007.52511.vbart@nginx.com>
References: <201309120007.52511.vbart@nginx.com>
Message-ID: <060769fbc376098bbb586942aa951c9a.NginxMailingListRussian@forum.nginx.org>

Валентин, спасибо!

я так понимаю что burst должен помочь в этой ситуации, правильно?

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


From vbart at nginx.com  Wed Sep 11 21:48:30 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Thu, 12 Sep 2013 01:48:30 +0400
Subject: =?UTF-8?B?UmU6IGxpbWl0IHJlcSB6b25lIC0gINC90LXQutC+0YDRgNC10LrRgtGL0Lkg0L8=?=
 =?UTF-8?B?0L7QtNGB0YfQtdGCINGH0LjRgdC70LAg0LfQsNC/0YDQvtGB0YLQvtCyID8=?=
In-Reply-To: <060769fbc376098bbb586942aa951c9a.NginxMailingListRussian@forum.nginx.org>
References: <201309120007.52511.vbart@nginx.com>
 <060769fbc376098bbb586942aa951c9a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201309120148.30706.vbart@nginx.com>

On Thursday 12 September 2013 01:39:19 SergeyFs wrote:
> Валентин, спасибо!
> 
> я так понимаю что burst должен помочь в этой ситуации, правильно?
> 

Правильно.

--
Валентин Бартенев
http://nginx.org/en/donation.html

From nginx-forum at nginx.us  Wed Sep 11 22:00:48 2013
From: nginx-forum at nginx.us (SergeyFs)
Date: Wed, 11 Sep 2013 18:00:48 -0400
Subject: =?UTF-8?B?UmU6IGxpbWl0IHJlcSB6b25lIC0g0L3QtdC60L7RgNGA0LXQutGC0YvQuSDQv9C+?=
 =?UTF-8?B?0LTRgdGH0LXRgiDRh9C40YHQu9CwINC30LDQv9GA0L7RgdGC0L7QsiA/?=
In-Reply-To: <201309120148.30706.vbart@nginx.com>
References: <201309120148.30706.vbart@nginx.com>
Message-ID: <0c13dd4c4f0dd0e6d54bc3baf655a378.NginxMailingListRussian@forum.nginx.org>

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

Сергей

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


From nginx-forum at nginx.us  Thu Sep 12 02:32:54 2013
From: nginx-forum at nginx.us (shtein)
Date: Wed, 11 Sep 2013 22:32:54 -0400
Subject: =?UTF-8?B?UmU6IE5naW54IDEuNC4yICsgTW9kIHNlY3VyaXR5IDIuNy41ICsgQXBhY2hlIDIu?=
 =?UTF-8?B?Mi4yMiAtINCf0YDQvtCx0LvQtdC80Ysg0YEg0LrQvtC00LjRgNC+0LLQutC+?=
 =?UTF-8?B?0Lku?=
In-Reply-To: <374480d5f7523e14a1804417e9c0786f.NginxMailingListRussian@forum.nginx.org>
References: <201308302005.41055.vbart@nginx.com>
 <374480d5f7523e14a1804417e9c0786f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <c1d0f4db7ecdbefe32901ce9746527d5.NginxMailingListRussian@forum.nginx.org>

Вобщем выяснил, что проблема с кодировкой появляется и для других страниц,
не только с Ajax. Просто на страницах с Ajax чаще. Так же, при помощи
Firebug выяснилось, что когда включаешь modsecurity в header добавляется
дополнительный charset=windows-1251. Причём после 1251 ставится рандомный
символ: 1251i, 1251s, 1251u, 1251{
Как я понимаю, корни проблемы лежат где-то там.

Самое смешное, что modsecurity для apache поставленный из пакета, не
добавляет никаких заголовков.

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


From nginx-forum at nginx.us  Thu Sep 12 02:40:33 2013
From: nginx-forum at nginx.us (shtein)
Date: Wed, 11 Sep 2013 22:40:33 -0400
Subject: =?UTF-8?B?UmU6IE5naW54IDEuNC4yICsgTW9kIHNlY3VyaXR5IDIuNy41ICsgQXBhY2hlIDIu?=
 =?UTF-8?B?Mi4yMiAtINCf0YDQvtCx0LvQtdC80Ysg0YEg0LrQvtC00LjRgNC+0LLQutC+?=
 =?UTF-8?B?0Lku?=
In-Reply-To: <1798251478.20130829081905@softsearch.ru>
References: <1798251478.20130829081905@softsearch.ru>
Message-ID: <7c29b150dc003dd9b92b6ceb9b0eae4a.NginxMailingListRussian@forum.nginx.org>

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

В дебаг  логах найти корни своей проблемы не могу. Как выясняется при
включенном modsecurity добавляется ещё одна директива charset в заголовок,
при чём она рандомно испорчена (то windows-1251i, то windows-1251s).

Я крайне слабо знаком с nginx, совсем не знаком с modsecurity, по-этому и
спрашиваю советов у более грамотных людей.

Спасибо за ответ.

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


From nginx-forum at nginx.us  Thu Sep 12 05:36:02 2013
From: nginx-forum at nginx.us (F1restorm)
Date: Thu, 12 Sep 2013 01:36:02 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0LrQsNGB0YLQvtC80L3Ri9C80Lggc2Vu?=
 =?UTF-8?B?dCBodHRwINC30LDQs9C+0LvQvtCy0LrQsNC80Lg=?=
In-Reply-To: <20130911133754.GO20921@mdounin.ru>
References: <20130911133754.GO20921@mdounin.ru>
Message-ID: <9688bff0956f8a935ff1bec10d34865f.NginxMailingListRussian@forum.nginx.org>

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

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


From citrin at citrin.ru  Thu Sep 12 09:10:54 2013
From: citrin at citrin.ru (Anton Yuzhaninov)
Date: Thu, 12 Sep 2013 13:10:54 +0400
Subject: ssl_prefer_server_ciphers
In-Reply-To: <D3FD9BC0-48D7-462B-BD91-4D7372D8F6C8@sonru.com>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
 <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
 <20130911165454.GQ20921@mdounin.ru>
 <D3FD9BC0-48D7-462B-BD91-4D7372D8F6C8@sonru.com>
Message-ID: <5231851E.6090102@citrin.ru>

On 09/11/13 21:30, Anatoly Mikhailov wrote:
> Есть ли разумный компромисс между достаточным уровнем безопасности и производительностью?
>

Если думать о производительности то прежде всего нужно запретить 3DES, 
безопасность от этого не сильно пострадает:

http://zombe.es/post/4078724716/openssl-cipher-selection


From gmm at csdoc.com  Thu Sep 12 10:38:28 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Thu, 12 Sep 2013 13:38:28 +0300
Subject: =?UTF-8?B?UmU6IE5naW54IDEuNC4yICsgTW9kIHNlY3VyaXR5IDIuNy41ICsgQXBhY2hlIDIu?=
 =?UTF-8?B?Mi4yMiAtINCf0YDQvtCx0LvQtdC80Ysg0YEg0LrQvtC00LjRgNC+0LLQutC+?=
 =?UTF-8?B?0Lku?=
In-Reply-To: <7c29b150dc003dd9b92b6ceb9b0eae4a.NginxMailingListRussian@forum.nginx.org>
References: <1798251478.20130829081905@softsearch.ru>
 <7c29b150dc003dd9b92b6ceb9b0eae4a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <523199A4.7060105@csdoc.com>

On 12.09.2013 5:40, shtein wrote:

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

у сервиса https://www.cloudflare.com/ есть бесплатный тарифный план
CloudFlare Free, куда входит "Reputation-based threat protection"
и "Comment spam protection". обнаруженным ботам показывает CAPTCHA.

в своей работе CloudFlare использует данные из Project Honey Pot.
кстати CloudFlare и Project Honey Pot создали одни и те же люди.
https://www.cloudflare.com/our-story и frontend у них на nginx.

P.S. не сочтите за рекламу, просто CloudFlare мне очень сильно помог,
защитив сайт от DDOS-атаки, когда датацентр просто выключал IP из-за
превышения Threshold Packets 500.000 packets/s для входящих пакетов.

-- 
Best regards,
  Gena


From gmm at csdoc.com  Thu Sep 12 16:37:23 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Thu, 12 Sep 2013 19:37:23 +0300
Subject: ssl_prefer_server_ciphers
In-Reply-To: <5231851E.6090102@citrin.ru>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
 <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
 <20130911165454.GQ20921@mdounin.ru>
 <D3FD9BC0-48D7-462B-BD91-4D7372D8F6C8@sonru.com> <5231851E.6090102@citrin.ru>
Message-ID: <5231EDC3.6010005@csdoc.com>

On 12.09.2013 12:10, Anton Yuzhaninov wrote:

> Если думать о производительности то прежде всего нужно запретить 3DES,
> безопасность от этого не сильно пострадает:
>
> http://zombe.es/post/4078724716/openssl-cipher-selection
>

а если думать о безопасности - тогда наверное имеет смысл включить
Forward Secrecy для всех браузеров и клиентов, которые это умеют:

https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

причем на выбор есть три варианта - "with RC4" для защиты от BEAST,
вообще "without RC4" и "RC4 enabled, but used only as a last resort".

судя по сайту http://www.ie6countdown.com/ - IE6 в России 1.7%,
но если надо чтобы и он работал - тогда придется включить SSLv3

да и по производительности AES ведь обгоняет RC4,
если процессор поддерживает набор команд AES-NI.

получается такой вариант:

если "BEAST attack considered sufficiently mitigated client-side"
и процессор поддерживает AES-NI и nginx скомпилирован с openssl 1.0.1+
и необходима поддержка IE6 под Windows XP, тогда оптимальный вариант:

     ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
     ssl_prefer_server_ciphers on;
     ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM 
EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 
EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA
  RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS +RC4 RC4";

     ssl_dhparam /etc/tls/dh2048/dh2048.pem;
     ssl_session_cache shared:SSL:4M;
     ssl_session_timeout 120m;

     ssl_stapling on;
     resolver 8.8.8.8 8.8.4.4;

тогда тест https://www.ssllabs.com/ssltest/ говорит:

"This server supports Forward Secrecy with modern browsers."

-- 
Best regards,
  Gena


From marck at rinet.ru  Thu Sep 12 20:01:19 2013
From: marck at rinet.ru (Dmitry Morozovsky)
Date: Fri, 13 Sep 2013 00:01:19 +0400 (MSK)
Subject: ssl_prefer_server_ciphers
In-Reply-To: <5231EDC3.6010005@csdoc.com>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
 <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
 <20130911165454.GQ20921@mdounin.ru>
 <D3FD9BC0-48D7-462B-BD91-4D7372D8F6C8@sonru.com>
 <5231851E.6090102@citrin.ru> <5231EDC3.6010005@csdoc.com>
Message-ID: <alpine.BSF.2.00.1309122359430.74501@woozle.rinet.ru>

On Thu, 12 Sep 2013, Gena Makhomed wrote:

[snip]

> да и по производительности AES ведь обгоняет RC4,
> если процессор поддерживает набор команд AES-NI.

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


-- 
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck at FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru ***
------------------------------------------------------------------------


From gmm at csdoc.com  Thu Sep 12 20:32:30 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Thu, 12 Sep 2013 23:32:30 +0300
Subject: ssl_prefer_server_ciphers
In-Reply-To: <alpine.BSF.2.00.1309122359430.74501@woozle.rinet.ru>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
 <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
 <20130911165454.GQ20921@mdounin.ru>
 <D3FD9BC0-48D7-462B-BD91-4D7372D8F6C8@sonru.com> <5231851E.6090102@citrin.ru>
 <5231EDC3.6010005@csdoc.com>
 <alpine.BSF.2.00.1309122359430.74501@woozle.rinet.ru>
Message-ID: <523224DE.1000105@csdoc.com>

On 12.09.2013 23:01, Dmitry Morozovsky wrote:

>> да и по производительности AES ведь обгоняет RC4,
>> если процессор поддерживает набор команд AES-NI.

> Вот это *если* -- ограничивает применимость очень изрядно.
> На мой взгляд, реально можно будет считать, что какой-нибудь ускоритель AES
> стоит на стороне клиента не раньше чем через года три...

а зачем на стороне клиента "какой-нибудь ускоритель AES" ?

при тех объемах HTTPS трафика, что шифрует/расшифровывает один
клиент - ему вполне достаточно будет и "софтверной" реализации.

-- 
Best regards,
  Gena


From marck at rinet.ru  Thu Sep 12 20:36:12 2013
From: marck at rinet.ru (Dmitry Morozovsky)
Date: Fri, 13 Sep 2013 00:36:12 +0400 (MSK)
Subject: ssl_prefer_server_ciphers
In-Reply-To: <523224DE.1000105@csdoc.com>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
 <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
 <20130911165454.GQ20921@mdounin.ru>
 <D3FD9BC0-48D7-462B-BD91-4D7372D8F6C8@sonru.com>
 <5231851E.6090102@citrin.ru> <5231EDC3.6010005@csdoc.com>
 <alpine.BSF.2.00.1309122359430.74501@woozle.rinet.ru>
 <523224DE.1000105@csdoc.com>
Message-ID: <alpine.BSF.2.00.1309130033540.74501@woozle.rinet.ru>

On Thu, 12 Sep 2013, Gena Makhomed wrote:

> > > да и по производительности AES ведь обгоняет RC4,
> > > если процессор поддерживает набор команд AES-NI.
> 
> > Вот это *если* -- ограничивает применимость очень изрядно.
> > На мой взгляд, реально можно будет считать, что какой-нибудь ускоритель AES
> > стоит на стороне клиента не раньше чем через года три...
> 
> а зачем на стороне клиента "какой-нибудь ускоритель AES" ?
> 
> при тех объемах HTTPS трафика, что шифрует/расшифровывает один
> клиент - ему вполне достаточно будет и "софтверной" реализации.

hm, тогда the whole original point is moot.

хотя, разве не AES'ом нынче в основном пользуются для криптования транспорта 
https/tls?

мы помним, что gmail/facebook уже переключили дефолты в https?

-- 
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck at FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru ***
------------------------------------------------------------------------


From gmm at csdoc.com  Thu Sep 12 21:43:23 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Fri, 13 Sep 2013 00:43:23 +0300
Subject: ssl_prefer_server_ciphers
In-Reply-To: <alpine.BSF.2.00.1309130033540.74501@woozle.rinet.ru>
References: <522D9457.9080008@csdoc.com> <522D9D94.3020202@citrin.ru>
 <522DB17F.60507@csdoc.com> <20130909123523.GD20921@mdounin.ru>
 <52A870C2-1C58-4D30-8F46-46092F1D920E@sonru.com>
 <20130911165454.GQ20921@mdounin.ru>
 <D3FD9BC0-48D7-462B-BD91-4D7372D8F6C8@sonru.com> <5231851E.6090102@citrin.ru>
 <5231EDC3.6010005@csdoc.com>
 <alpine.BSF.2.00.1309122359430.74501@woozle.rinet.ru>
 <523224DE.1000105@csdoc.com>
 <alpine.BSF.2.00.1309130033540.74501@woozle.rinet.ru>
Message-ID: <5232357B.1060805@csdoc.com>

On 12.09.2013 23:36, Dmitry Morozovsky wrote:

> разве не AES'ом нынче в основном пользуются
> для криптования транспорта https/tls?

~50%.

After the BEAST attack was disclosed in 2011, we?grudgingly?started 
using RC4 in order to avoid the vulnerable CBC suites in TLS 1.0 and 
earlier. This caused the usage of RC4 to increase, and some say that it 
now accounts for about 50% of all TLS traffic.

https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what

-- 
Best regards,
  Gena


From kak.serpom.po.yaitsam at gmail.com  Fri Sep 13 12:43:30 2013
From: kak.serpom.po.yaitsam at gmail.com (Vasily Zorin)
Date: Fri, 13 Sep 2013 16:43:30 +0400
Subject: =?UTF-8?B?0KLRgNC10LHRg9C10YLRgdGPINC90LDQv9C40YHQsNGC0Ywg0LzQvtC00YPQu9GM?=
 =?UTF-8?B?INC30LAg0L/Qu9Cw0YLRgy4=?=
Message-ID: <CAOqa_uOuEgVQWB=vxUtUmBsBtcTnoi9_M1ieWG5-gDyoPFemOA@mail.gmail.com>

Добрый день!

Мне требуется модуль к nginx, готов заплатить за написание. Суть его
работы: прочесть JSON-документ из fastcgi_pass/proxy_pass ответа,
описывающий мета-данные этого файла (размер, название, список
файлов-частей), и отправить HTTP-клиенту последовательно каждую часть,
учитывая Content-Range. По сути дела, нечто вроде X-Accel-Redirect-Multi.
Есть ТЗ, но всё можно обсудить и изменить работу backend'а, как будет
удобнее Вам.

Прошу писать на maintainer at daemon.io или в Skype: gf.at.hackweb. Ответы в
рассылке так же мониторю.
Очень надеюсь на отклик! Благодарю заранее.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130913/41793d3b/attachment.html>

From postmaster at softsearch.ru  Fri Sep 13 17:25:30 2013
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Fri, 13 Sep 2013 21:25:30 +0400
Subject: =?UTF-8?B?UmU6INCi0YDQtdCx0YPQtdGC0YHRjyDQvdCw0L/QuNGB0LDRgtGMINC80L7QtNGD?=
 =?UTF-8?B?0LvRjCDQt9CwINC/0LvQsNGC0YMu?=
In-Reply-To: <CAOqa_uOuEgVQWB=vxUtUmBsBtcTnoi9_M1ieWG5-gDyoPFemOA@mail.gmail.com>
References: <CAOqa_uOuEgVQWB=vxUtUmBsBtcTnoi9_M1ieWG5-gDyoPFemOA@mail.gmail.com>
Message-ID: <272137930.20130913212530@softsearch.ru>

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

> Мне требуется модуль к nginx, готов заплатить за написание. Суть
> его работы: прочесть JSON-документ из fastcgi_pass/proxy_pass
> ответа, описывающий мета-данные этого файла (размер, название,
> список файлов-частей), и отправить HTTP-клиенту последовательно
> каждую часть, учитывая Content-Range. По сути дела, нечто вроде
> X-Accel-Redirect-Multi.

Это нечто вроде SSI. Только вместо json-а список ssi-инклудов. Может
можно обойтись без модуля и попробовать ssi?

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


From postmaster at softsearch.ru  Fri Sep 13 17:34:44 2013
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Fri, 13 Sep 2013 21:34:44 +0400
Subject: =?UTF-8?B?UmU6INCi0YDQtdCx0YPQtdGC0YHRjyDQvdCw0L/QuNGB0LDRgtGMINC80L7QtNGD?=
 =?UTF-8?B?0LvRjCDQt9CwINC/0LvQsNGC0YMu?=
In-Reply-To: <CAOqa_uOuEgVQWB=vxUtUmBsBtcTnoi9_M1ieWG5-gDyoPFemOA@mail.gmail.com>
References: <CAOqa_uOuEgVQWB=vxUtUmBsBtcTnoi9_M1ieWG5-gDyoPFemOA@mail.gmail.com>
Message-ID: <60201479.20130913213444@softsearch.ru>

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

> Есть ТЗ, но всё можно обсудить и изменить работу backend'а, как будет удобнее Вам.


> Прошу писать на maintainer at daemon.io или в Skype: gf.at.hackweb.
> Ответы в рассылке так же мониторю.
> Очень надеюсь на отклик! Благодарю заранее. 


Вдогонку...
А Вы писали разработчика nginx-а? Они кроме всего прочего занимаются
бизнесом и за деньги наверняка напишут. Или скажут как решить Вашу
задачу иначе.

P.S.
Я  бы  стал  городить модуль лишь в самом крайнем случае. Ибо ему 100%
понадобится  поддержка,  за  которую  придётся  вечно платить. Оно Вам
надо?


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


From nginx-forum at nginx.us  Fri Sep 13 17:49:41 2013
From: nginx-forum at nginx.us (Yury Pavlovsky)
Date: Fri, 13 Sep 2013 13:49:41 -0400
Subject: =?UTF-8?B?0JrQsNC6INGA0LDQsdC+0YLQsNC10YIgLyDQutCw0Log0L7RgtC70Y7Rh9C40YI=?=
 =?UTF-8?B?0Ywg0LTQuNGA0LXQutGC0LjQstGDIGluZGV4?=
Message-ID: <014c7d2f907e540f788cd82a41355436.NginxMailingListRussian@forum.nginx.org>

Здравствуйте!
Вопросы по директиве index
1. Из документации совершенно не очевидно КОГДА фактически nginx проверяет
существование указанных индексных файлов до / после отработки location'ов?
2. Учитывая, что в современном вебе индексные файлы почти нигде не
используются: на языке "index.html" уже никто не пишет, а "index.php" - это
не индексный файл, а единая точка входа в приложение. С моей колокольни
кажется очень архаичным:
умолчание: index index.html;
И самое главное почему нет (или есть?) `index off`, чтобы совсем эту логику
отключить, так как не намерен никоим образом мучить этого мамонта?
Заранее спасибо.

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


From p934hw9gaog6y887z at mailforspam.com  Fri Sep 13 17:57:08 2013
From: p934hw9gaog6y887z at mailforspam.com (p934hw9gaog6y887z at mailforspam.com)
Date: Fri, 13 Sep 2013 17:57:08 GMT
Subject: яНГДЮМХЕ location, АНПЧЫЕЦНЯЪ ЯН ЯЙЮМХПНБЮМХЕЛ ЯЮИРЮ
Message-ID: <82728524l.4548755l1634048l1l@mailforspam.com>

гДПЮБЯРБСИРЕ! оНЛНЦХРЕ, ОНФЮКСИЯРЮ, Я ЙНППЕЙРМШЛ МЮОХЯЮМХЕЛ location. оНЯРНЪММН ЯЙЮМХПСЧР ЯЕПБЕП Б ОНХЯЙЮУ ЮДЛХМНЙ. с АНКЭЬХМЯРБЮ ГЮОПНЯНБ НДХМЮЙНБШИ ЬЮАКНМ ОНБЕДЕМХЪ √ ХЫСР КХАН ТЮИКШ, КХАН ТЮИКШ Б ОЮОЙЮУ Я ХЛЕМЮЛХ admin Х login. нРЯЧДЮ ЖЕКЭ: ЯНГДЮРЭ РСОХЙНБШИ location Б ОСРХ ЙНРНПНЦН, БМЕ ГЮБХЯХЛНЯРХ НР ПЕЦХЯРПЮ, БШЪБКЪКХЯЭ *admin* Х *login*. вРН-РН РХОЮ   location ~* *(admin|login)* { return 400; }


................
This email was sent using a trial version of SMTP Diagnostics.
For more information, visit http://www.smtpdiagnostics.com/.
Buy now to eliminate this message.


From mdounin at mdounin.ru  Sat Sep 14 13:22:13 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sat, 14 Sep 2013 17:22:13 +0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0LHQvtGC0LDQtdGCIC8g0LrQsNC6INC+0YLQu9GO0Yc=?=
 =?UTF-8?B?0LjRgtGMINC00LjRgNC10LrRgtC40LLRgyBpbmRleA==?=
In-Reply-To: <014c7d2f907e540f788cd82a41355436.NginxMailingListRussian@forum.nginx.org>
References: <014c7d2f907e540f788cd82a41355436.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130914132213.GB29076@mdounin.ru>

Hello!

On Fri, Sep 13, 2013 at 01:49:41PM -0400, Yury Pavlovsky wrote:

> 1. Из документации совершенно не очевидно КОГДА фактически nginx проверяет
> существование указанных индексных файлов до / после отработки location'ов?

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

И, подозреваю, остальные вопросы у вас после прочтения тоже 
отпадут.

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


From zmey1992 at ya.ru  Sat Sep 14 23:12:21 2013
From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=)
Date: Sun, 15 Sep 2013 03:12:21 +0400
Subject: http 500
Message-ID: <25501379200341@web20m.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130915/0e252aa8/attachment.html>

From alexey.bobok at gmail.com  Sun Sep 15 01:45:43 2013
From: alexey.bobok at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JHQvtCx0L7Qug==?=)
Date: Sun, 15 Sep 2013 04:45:43 +0300
Subject: http 500
In-Reply-To: <29544824.3097.1379200376688.JavaMail.mobile-sync@vcbbm4>
References: <29544824.3097.1379200376688.JavaMail.mobile-sync@vcbbm4>
Message-ID: <-8013978418144908836@unknownmsgid>

Вы действительно думаете, что без хотя бы символического предисловия
об архитектуре Вашего сервера, ПО, языка попиливания и прочих данных,
Вам помогут и напишут "ей, чувак, так тебе надо включить 3 опции и и
фиксануть пару функций"?
В лучшем случае в менее профессиональной рассылке Вам ответят "Пых
фуфло, Рельсы рулят!"

Конкретизируйте.

--
Best regards,
Alexey Bobok

15.09.2013, в 2:12, "Васильев \"Zmey!\" Олег" <zmey1992 at ya.ru> написал(а):

> Hello everybody!
> Попиливаю маленький статический сайтик. После сохранения файла первый его запрос возвращает HTTP 500. Второй возвращает обновлённую страницу. Почему так?
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From pavel2000 at ngs.ru  Sun Sep 15 03:52:27 2013
From: pavel2000 at ngs.ru (Pavel V.)
Date: Sun, 15 Sep 2013 10:52:27 +0700
Subject: http 500
In-Reply-To: <25501379200341@web20m.yandex.ru>
References: <25501379200341@web20m.yandex.ru>
Message-ID: <1759778781.20130915105227@ngs.ru>

Здравствуйте, Васильев.

Вы писали 15 сентября 2013 г., 6:12:21:

> Hello everybody!
> Попиливаю маленький статический сайтик. После сохранения файла первый его запрос возвращает HTTP
> 500. Второй возвращает обновлённую страницу.

>  Почему так?

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


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


From unlexx at gmail.com  Sun Sep 15 09:22:59 2013
From: unlexx at gmail.com (Un Lexx)
Date: Sun, 15 Sep 2013 15:22:59 +0600
Subject: =?UTF-8?B?0L7Rh9C10YDQtdC00Ywg0LogZnBtLXBocA==?=
Message-ID: <CAAnzuPPoHCq23nk1+XDAUGFJO04KjzfCyF5ENz1=KziCGVR_XQ@mail.gmail.com>

есть ли возможность заставить nginx пересылать запросы к fcg php бакенду
последовательно делая один запрос на одну куку

ну то есть запросы которые пришли с одной кукой должны пересылатся бакенду
по FIFO.

Да да понятно что следовало внутри php обеспечить решение slide эффектов но
на данный момент менять код на бакенде нет ресурсов.

Пока из быстрых решений сделать проксю в каком нибудь ерланге дабы запросы
вставали по очереди пересылались в fpmphp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130915/fffc7473/attachment.html>

From zmey1992 at ya.ru  Sun Sep 15 10:30:41 2013
From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=)
Date: Sun, 15 Sep 2013 14:30:41 +0400
Subject: =?UTF-8?B?UmU6INCh0L7Qt9C00LDQvdC40LUgbG9jYXRpb24sINCx0L7RgNGO0YnQtdCz0L4=?=
 =?UTF-8?B?0YHRjyDRgdC+INGB0LrQsNC90LjRgNC+0LLQsNC90LjQtdC8INGB0LDQudGC?=
 =?UTF-8?B?0LA=?=
In-Reply-To: <82728524l.4548755l1634048l1l@mailforspam.com>
References: <82728524l.4548755l1634048l1l@mailforspam.com>
Message-ID: <343131379241041@web3h.yandex.ru>

lcoation ~* ^/.*(admin|login).*$ { return 444; }
Локейшн по вашему шаблону. Будьте осторожны, не побаньте себе какие-нибудь ссылки. И правильно разместите локейшн в конфиге.


13.09.2013, 21:57, "p934hw9gaog6y887z at mailforspam.com" <p934hw9gaog6y887z at mailforspam.com>:

>  Здравствуйте! Помогите, пожалуйста, с корректным написанием location. Постоянно сканируют сервер в поисках админок. У большинства запросов одинаковый шаблон поведения ? ищут либо файлы, либо файлы в папках с именами admin и login. Отсюда цель: создать тупиковый location в пути которого, вне зависимости от регистра, выявлялись *admin* и *login*. Что-то типа   location ~* *(admin|login)* { return 400; }
>
>  ................
>  This email was sent using a trial version of SMTP Diagnostics.
>  For more information, visit http://www.smtpdiagnostics.com/.
>  Buy now to eliminate this message.
>
>  ,
>  _______________________________________________
>  nginx-ru mailing list
>  nginx-ru at nginx.org
>  http://mailman.nginx.org/mailman/listinfo/nginx-ru


From zmey1992 at ya.ru  Sun Sep 15 11:10:19 2013
From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=)
Date: Sun, 15 Sep 2013 15:10:19 +0400
Subject: http 500
In-Reply-To: <-8013978418144908836@unknownmsgid>
References: <29544824.3097.1379200376688.JavaMail.mobile-sync@vcbbm4>
 <-8013978418144908836@unknownmsgid>
Message-ID: <374011379243419@web3h.yandex.ru>

Ну сайт, как и сказал - статический. Голый HTML без всяких SSI и любой динамической генерации. Я бы упомнял, если бы было иначе.
В остальном я и вправду, пожалуй, неправ. Исправляюсь:
Ось Ubuntu 12.04
Linux pyxis-server 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux
nginx:
nginx version: nginx/1.4.2
built by clang 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)
TLS SNI support enabled
configure arguments: --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx.pid --lock-path=/var/lock/nginx.lock --http-log-path=/var/log/nginx/access.log --with-http_ssl_module --with-http_random_index_module --with-http_stub_status_module --with-cpu-opt=pentium4 --with-cc=/usr/bin/clang --with-cpp=/usr/bin/clang

В error логе:
2013/09/15 14:44:57 [crit] 22654#0: *103 open() "<путь стёрт>" failed (11: Resource temporarily unavailable)

Редактирование производится через Sublime Text 2 по сети через Samba-шару.
Как я и сказал, проблема воспроизводится после изменения и сохранения файла. Если вносить изменения через nano локально, то проблемы нет.

15.09.2013, 05:46, "Алексей Бобок" <alexey.bobok at gmail.com>:
> Вы действительно думаете, что без хотя бы символического предисловия
> об архитектуре Вашего сервера, ПО, языка попиливания и прочих данных,
> Вам помогут и напишут "ей, чувак, так тебе надо включить 3 опции и и
> фиксануть пару функций"?
> В лучшем случае в менее профессиональной рассылке Вам ответят "Пых
> фуфло, Рельсы рулят!"
>
> Конкретизируйте.
>
> --
> Best regards,
> Alexey Bobok
>
> 15.09.2013, в 2:12, "Васильев \"Zmey!\" Олег" <zmey1992 at ya.ru> написал(а):
>
>>  Hello everybody!
>>  Попиливаю маленький статический сайтик. После сохранения файла первый его запрос возвращает HTTP 500. Второй возвращает обновлённую страницу. Почему так?
>>  _______________________________________________
>>  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 alexey.bobok at gmail.com  Sun Sep 15 11:17:33 2013
From: alexey.bobok at gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JHQvtCx0L7Qug==?=)
Date: Sun, 15 Sep 2013 14:17:33 +0300
Subject: http 500
In-Reply-To: <374011379243419@web3h.yandex.ru>
References: <29544824.3097.1379200376688.JavaMail.mobile-sync@vcbbm4>
 <-8013978418144908836@unknownmsgid> <374011379243419@web3h.yandex.ru>
Message-ID: <8140312572644961827@unknownmsgid>

Возможно и не верное предположение, но похоже на какую-то блокировку
файла на чтение.

--
Best regards,
Alexey Bobok

15.09.2013, в 14:10, "Васильев \"Zmey!\" Олег" <zmey1992 at ya.ru> написал(а):

> Ну сайт, как и сказал - статический. Голый HTML без всяких SSI и любой динамической генерации. Я бы упомнял, если бы было иначе.
> В остальном я и вправду, пожалуй, неправ. Исправляюсь:
> Ось Ubuntu 12.04
> Linux pyxis-server 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux
> nginx:
> nginx version: nginx/1.4.2
> built by clang 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)
> TLS SNI support enabled
> configure arguments: --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx.pid --lock-path=/var/lock/nginx.lock --http-log-path=/var/log/nginx/access.log --with-http_ssl_module --with-http_random_index_module --with-http_stub_status_module --with-cpu-opt=pentium4 --with-cc=/usr/bin/clang --with-cpp=/usr/bin/clang
>
> В error логе:
> 2013/09/15 14:44:57 [crit] 22654#0: *103 open() "<путь стёрт>" failed (11: Resource temporarily unavailable)
>
> Редактирование производится через Sublime Text 2 по сети через Samba-шару.
> Как я и сказал, проблема воспроизводится после изменения и сохранения файла. Если вносить изменения через nano локально, то проблемы нет.
>
> 15.09.2013, 05:46, "Алексей Бобок" <alexey.bobok at gmail.com>:
>> Вы действительно думаете, что без хотя бы символического предисловия
>> об архитектуре Вашего сервера, ПО, языка попиливания и прочих данных,
>> Вам помогут и напишут "ей, чувак, так тебе надо включить 3 опции и и
>> фиксануть пару функций"?
>> В лучшем случае в менее профессиональной рассылке Вам ответят "Пых
>> фуфло, Рельсы рулят!"
>>
>> Конкретизируйте.
>>
>> --
>> Best regards,
>> Alexey Bobok
>>
>> 15.09.2013, в 2:12, "Васильев \"Zmey!\" Олег" <zmey1992 at ya.ru> написал(а):
>>
>>>  Hello everybody!
>>>  Попиливаю маленький статический сайтик. После сохранения файла первый его запрос возвращает HTTP 500. Второй возвращает обновлённую страницу. Почему так?
>>>  _______________________________________________
>>>  nginx-ru mailing list
>>>  nginx-ru at nginx.org
>>>  http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From mdounin at mdounin.ru  Sun Sep 15 11:32:49 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sun, 15 Sep 2013 15:32:49 +0400
Subject: http 500
In-Reply-To: <374011379243419@web3h.yandex.ru>
References: <29544824.3097.1379200376688.JavaMail.mobile-sync@vcbbm4>
 <-8013978418144908836@unknownmsgid>
 <374011379243419@web3h.yandex.ru>
Message-ID: <20130915113249.GG29076@mdounin.ru>

Hello!

On Sun, Sep 15, 2013 at 03:10:19PM +0400, Васильев "Zmey!" Олег wrote:

> Ну сайт, как и сказал - статический. Голый HTML без всяких SSI и любой динамической генерации. Я бы упомнял, если бы было иначе.
> В остальном я и вправду, пожалуй, неправ. Исправляюсь:
> Ось Ubuntu 12.04
> Linux pyxis-server 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux
> nginx:
> nginx version: nginx/1.4.2
> built by clang 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)
> TLS SNI support enabled
> configure arguments: --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx.pid --lock-path=/var/lock/nginx.lock --http-log-path=/var/log/nginx/access.log --with-http_ssl_module --with-http_random_index_module --with-http_stub_status_module --with-cpu-opt=pentium4 --with-cc=/usr/bin/clang --with-cpp=/usr/bin/clang
> 
> В error логе:
> 2013/09/15 14:44:57 [crit] 22654#0: *103 open() "<путь стёрт>" failed (11: Resource temporarily unavailable)
> 
> Редактирование производится через Sublime Text 2 по сети через Samba-шару.
> Как я и сказал, проблема воспроизводится после изменения и сохранения файла. Если вносить изменения через nano локально, то проблемы нет.

Самба на линуксе пытается использовать для блокировок 
fcntl(F_GETLEASE), если не ошибаюсь, что и заканчивается ошибками 
при попытке доступа к файлам, редактируемым через самбу.

Вообще не надо редактировать файлы по месту.  Надо создавать новую 
версию файла, после чего атомарно заменять с помощью rename()/mv.  
Если же редактировать по месту - имеет место race между отдачей 
клиенту заголовков ответа, в частности - Content-Length, и телом 
ответа.

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


From zmey1992 at ya.ru  Sun Sep 15 11:46:59 2013
From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=)
Date: Sun, 15 Sep 2013 15:46:59 +0400
Subject: http 500
In-Reply-To: <20130915113249.GG29076@mdounin.ru>
References: <29544824.3097.1379200376688.JavaMail.mobile-sync@vcbbm4>
 <-8013978418144908836@unknownmsgid>
 <374011379243419@web3h.yandex.ru> <20130915113249.GG29076@mdounin.ru>
Message-ID: <115731379245619@web27g.yandex.ru>

Спасибо за ответ.
Дело в том, что не важно сколько времени прошло после сохранения (можно успеть по диалапу файл залить и сохранить), первая попытка запросить файл после изменения отдаст 500. Может, nginx кеширует какие-то данные о файле между запросами?

15.09.2013, 15:32, "Maxim Dounin" <mdounin at mdounin.ru>:
> Hello!
>
> On Sun, Sep 15, 2013 at 03:10:19PM +0400, Васильев "Zmey!" Олег wrote:
>
>>  Ну сайт, как и сказал - статический. Голый HTML без всяких SSI и любой динамической генерации. Я бы упомнял, если бы было иначе.
>>  В остальном я и вправду, пожалуй, неправ. Исправляюсь:
>>  Ось Ubuntu 12.04
>>  Linux pyxis-server 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386 GNU/Linux
>>  nginx:
>>  nginx version: nginx/1.4.2
>>  built by clang 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)
>>  TLS SNI support enabled
>>  configure arguments: --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx.pid --lock-path=/var/lock/nginx.lock --http-log-path=/var/log/nginx/access.log --with-http_ssl_module --with-http_random_index_module --with-http_stub_status_module --with-cpu-opt=pentium4 --with-cc=/usr/bin/clang --with-cpp=/usr/bin/clang
>>
>>  В error логе:
>>  2013/09/15 14:44:57 [crit] 22654#0: *103 open() "<путь стёрт>" failed (11: Resource temporarily unavailable)
>>
>>  Редактирование производится через Sublime Text 2 по сети через Samba-шару.
>>  Как я и сказал, проблема воспроизводится после изменения и сохранения файла. Если вносить изменения через nano локально, то проблемы нет.
>
> Самба на линуксе пытается использовать для блокировок
> fcntl(F_GETLEASE), если не ошибаюсь, что и заканчивается ошибками
> при попытке доступа к файлам, редактируемым через самбу.
>
> Вообще не надо редактировать файлы по месту.  Надо создавать новую
> версию файла, после чего атомарно заменять с помощью rename()/mv.
> Если же редактировать по месту - имеет место race между отдачей
> клиенту заголовков ответа, в частности - Content-Length, и телом
> ответа.
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From onokonem at gmail.com  Sun Sep 15 12:03:13 2013
From: onokonem at gmail.com (Daniel Podolsky)
Date: Sun, 15 Sep 2013 16:03:13 +0400
Subject: http 500
In-Reply-To: <115731379245619@web27g.yandex.ru>
References: <29544824.3097.1379200376688.JavaMail.mobile-sync@vcbbm4>
 <-8013978418144908836@unknownmsgid>
 <374011379243419@web3h.yandex.ru>
 <20130915113249.GG29076@mdounin.ru>
 <115731379245619@web27g.yandex.ru>
Message-ID: <CAKaHDOHujsSBFEZ=-j5yFMhZL-s-VGW4D9FPevJQBfQMriJNVw@mail.gmail.com>

2013/9/15 Васильев "Zmey!" Олег <zmey1992 at ya.ru>:
> Может, nginx кеширует какие-то данные о файле между запросами?
Может, и кеширует. Мы же не видали вашего конфига.

From mdounin at mdounin.ru  Sun Sep 15 12:25:12 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sun, 15 Sep 2013 16:25:12 +0400
Subject: http 500
In-Reply-To: <115731379245619@web27g.yandex.ru>
References: <29544824.3097.1379200376688.JavaMail.mobile-sync@vcbbm4>
 <-8013978418144908836@unknownmsgid>
 <374011379243419@web3h.yandex.ru>
 <20130915113249.GG29076@mdounin.ru>
 <115731379245619@web27g.yandex.ru>
Message-ID: <20130915122512.GH29076@mdounin.ru>

Hello!

On Sun, Sep 15, 2013 at 03:46:59PM +0400, Васильев "Zmey!" Олег wrote:

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

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

> Может, nginx 
> кеширует какие-то данные о файле между запросами?

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

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

http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html#id2616903

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

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


From zmey1992 at ya.ru  Sun Sep 15 12:51:36 2013
From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=)
Date: Sun, 15 Sep 2013 16:51:36 +0400
Subject: http 500
In-Reply-To: <20130915122512.GH29076@mdounin.ru>
References: <29544824.3097.1379200376688.JavaMail.mobile-sync@vcbbm4>
 <-8013978418144908836@unknownmsgid>
 <374011379243419@web3h.yandex.ru>
 <20130915113249.GG29076@mdounin.ru>
 <115731379245619@web27g.yandex.ru> <20130915122512.GH29076@mdounin.ru>
Message-ID: <108171379249496@web25m.yandex.ru>

Ещё раз спасибо за крайне исчерпывающий ответ. Пойду почитаю.

15.09.2013, 16:25, "Maxim Dounin" <mdounin at mdounin.ru>:
> Hello!
>
> On Sun, Sep 15, 2013 at 03:46:59PM +0400, Васильев "Zmey!" Олег wrote:
>
>>  Спасибо за ответ.
>>  Дело в том, что не важно сколько времени прошло после сохранения
>>  (можно успеть по диалапу файл залить и сохранить), первая
>>  попытка запросить файл после изменения отдаст 500.
>
> Насколько я понимаю, так ведёт себя самба - блокировка файла
> отпускается только в тот момент, когда кто-нибудь ещё попытается
> его открыть.
>
>>  Может, nginx
>>  кеширует какие-то данные о файле между запросами?
>
> Со своей стороны nginx что-либо кеширует только в том случае, если
> его об этом явно попросили, настроив open_file_cache.  Но к
> обсуждаемой проблеме это имеет очень опосредованное отношение -
> при использовании open_file_cache гораздо проще наблюдать
> негативные последствия редактирования файлов по месту.
>
> Ошибки открытия файлов при редактировании файлов через самбу на
> линуксе - это отдельная проблема.  Если хочется понять, что там
> происходит, то стоит начать с чтения чего-нибудь вроде вот этого:
>
> http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html#id2616903
>
> Но, как я уже писал, пытаться редактировать файлы "по месту" - в
> любом случае неправильно.
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From nginx-forum at nginx.us  Mon Sep 16 08:00:47 2013
From: nginx-forum at nginx.us (Yury Pavlovsky)
Date: Mon, 16 Sep 2013 04:00:47 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0LHQvtGC0LDQtdGCIC8g0LrQsNC6INC+0YLQu9GO0Yc=?=
 =?UTF-8?B?0LjRgtGMINC00LjRgNC10LrRgtC40LLRgyBpbmRleA==?=
In-Reply-To: <20130914132213.GB29076@mdounin.ru>
References: <20130914132213.GB29076@mdounin.ru>
Message-ID: <60c6b71488f3e7feca9b02164e9af6ed.NginxMailingListRussian@forum.nginx.org>

Спасибо, документацию читал.
Повторюсь, исчерпывающего формального описания работы директивы там нет,
передан лишь её смысл. Видимо, раз в документации никто до этого не написал,
вряд ли мне стоит рассчитывать, что напишут тут, тем более что знают это
только разработчики...
Если есть способ отключить директиву "наверняка", напишите, пожалуйста.
Думал можно пересобрать nginx без модуля ngx_http_index_module, но мой
`nginx -V` (оф дебиан-репозитарий) не содержит ngx_http_index_module. Видимо
этот модуль вшили в ядро?

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


From zmey1992 at ya.ru  Mon Sep 16 11:39:38 2013
From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=)
Date: Mon, 16 Sep 2013 15:39:38 +0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0LHQvtGC0LDQtdGCIC8g0LrQsNC6INC+0YLQu9GO0Yc=?=
 =?UTF-8?B?0LjRgtGMINC00LjRgNC10LrRgtC40LLRgyBpbmRleA==?=
In-Reply-To: <60c6b71488f3e7feca9b02164e9af6ed.NginxMailingListRussian@forum.nginx.org>
References: <20130914132213.GB29076@mdounin.ru>
 <60c6b71488f3e7feca9b02164e9af6ed.NginxMailingListRussian@forum.nginx.org>
Message-ID: <596431379331578@web3h.yandex.ru>

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

16.09.2013, 12:01, "Yury Pavlovsky" <nginx-forum at nginx.us>:
> Спасибо, документацию читал.
> Повторюсь, исчерпывающего формального описания работы директивы там нет,
> передан лишь её смысл. Видимо, раз в документации никто до этого не написал,
> вряд ли мне стоит рассчитывать, что напишут тут, тем более что знают это
> только разработчики...
> Если есть способ отключить директиву "наверняка", напишите, пожалуйста.
> Думал можно пересобрать nginx без модуля ngx_http_index_module, но мой
> `nginx -V` (оф дебиан-репозитарий) не содержит ngx_http_index_module. Видимо
> этот модуль вшили в ядро?
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,242838,242866#msg-242866
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From mdounin at mdounin.ru  Mon Sep 16 12:43:39 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 16 Sep 2013 16:43:39 +0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0LHQvtGC0LDQtdGCIC8g0LrQsNC6INC+0YLQu9GO0Yc=?=
 =?UTF-8?B?0LjRgtGMINC00LjRgNC10LrRgtC40LLRgyBpbmRleA==?=
In-Reply-To: <60c6b71488f3e7feca9b02164e9af6ed.NginxMailingListRussian@forum.nginx.org>
References: <20130914132213.GB29076@mdounin.ru>
 <60c6b71488f3e7feca9b02164e9af6ed.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130916124339.GB57081@mdounin.ru>

Hello!

On Mon, Sep 16, 2013 at 04:00:47AM -0400, Yury Pavlovsky wrote:

> Спасибо, документацию читал.
> Повторюсь, исчерпывающего формального описания работы директивы там нет,
> передан лишь её смысл. Видимо, раз в документации никто до этого не написал,
> вряд ли мне стоит рассчитывать, что напишут тут, тем более что знают это
> только разработчики...

Повторюсь - прочитайте присланную ссылку ещё раз, внимательно.  В 
частности, со вот этот кусок:

: Обработка запроса ?/? более сложная. Ему соответствует только 
: префиксный location ?/?, поэтому запрос обрабатывается в нём. 
: Затем директива index проверяет существование индексных файлов 
: согласно своих параметров и директиве ?root /data/www?. Если файл 
: /data/www/index.html не существует, а файл /data/www/index.php 
: : существует, то директива делает внутреннее перенаправление на 
: ?/index.php? и nginx снова сопоставляет его с location?ами, как 
: если бы такой запрос был послан клиентом. Как мы видели ранее, 
: перенаправленный запрос будет в конечном итоге обработан сервером 
: FastCGI.

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

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

> Если есть способ отключить директиву "наверняка", напишите, пожалуйста.
> Думал можно пересобрать nginx без модуля ngx_http_index_module, но мой
> `nginx -V` (оф дебиан-репозитарий) не содержит ngx_http_index_module. Видимо
> этот модуль вшили в ядро?

Модуль index не отключается и всегда обрабатывает запросы, 
оканчивающиеся слэшом, если обработка не перехвачена каким-либо из 
безусловных обработчиков (proxy_pass, fastcgi_pass и т.п.) и/или 
не прервана в процессе обриботки.  Если очень хочется, чтобы index 
не работал никогда, можно сделать так:

    location ~ /$ { return 403; }

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

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


From nginx-forum at nginx.us  Tue Sep 17 07:01:25 2013
From: nginx-forum at nginx.us (Aleus Essentia)
Date: Tue, 17 Sep 2013 03:01:25 -0400
Subject: =?UTF-8?B?0JrQsNC6INC/0L7Qu9GD0YfQuNGC0YwgUE9TVC3Qt9Cw0L/RgNC+0YEg0LIg0YE=?=
 =?UTF-8?B?0L7QsdGB0YLQstC10L3QvdC+0Lwg0LzQvtC00YPQu9C1Pw==?=
Message-ID: <3266307d0617c4f00ed744d8a46c0098.NginxMailingListRussian@forum.nginx.org>

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

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


From vadim.lazovskiy at gmail.com  Tue Sep 17 07:18:26 2013
From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy)
Date: Tue, 17 Sep 2013 11:18:26 +0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C+0LvRg9GH0LjRgtGMIFBPU1Qt0LfQsNC/0YDQvtGBINCy?=
 =?UTF-8?B?INGB0L7QsdGB0YLQstC10L3QvdC+0Lwg0LzQvtC00YPQu9C1Pw==?=
In-Reply-To: <3266307d0617c4f00ed744d8a46c0098.NginxMailingListRussian@forum.nginx.org>
References: <3266307d0617c4f00ed744d8a46c0098.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAL-L5YBaihpmrXv=vwA3x7HR9y-u7o_URTbQqNJEpsPakSq9_Q@mail.gmail.com>

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

Для примера можно посмотреть как ngx_http_dav_handler обрабатывает
NGX_HTTP_PUT в src/http/modules/ngx_http_dav_module.c


17 сентября 2013 г., 11:01 пользователь Aleus Essentia <nginx-forum at nginx.us
> написал:

> День добрый!
> Пишу модуль для работы с одной программой. Get-запросы и http-заголовок
> легко получаю, а как получить аргументы POST-запрос от клиента ума не
> приложу....
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,242907,242907#msg-242907
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru




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

From nginx-forum at nginx.us  Tue Sep 17 07:37:08 2013
From: nginx-forum at nginx.us (Aleus Essentia)
Date: Tue, 17 Sep 2013 03:37:08 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C+0LvRg9GH0LjRgtGMIFBPU1Qt0LfQsNC/0YDQvtGBINCy?=
 =?UTF-8?B?INGB0L7QsdGB0YLQstC10L3QvdC+0Lwg0LzQvtC00YPQu9C1Pw==?=
In-Reply-To: <CAL-L5YBaihpmrXv=vwA3x7HR9y-u7o_URTbQqNJEpsPakSq9_Q@mail.gmail.com>
References: <CAL-L5YBaihpmrXv=vwA3x7HR9y-u7o_URTbQqNJEpsPakSq9_Q@mail.gmail.com>
Message-ID: <ef1038e32f158aadde963da41ec28b53.NginxMailingListRussian@forum.nginx.org>

Как понимаю, нужно посмотреть функцию gx_http_read_client_request_body?

В самом ngx_http_dav_module.c такой код:

      case NGX_HTTP_PUT:
  
          if (r->uri.data[r->uri.len - 1] == '/') {
              ngx_log_error(NGX_LOG_ERR, r->connection->log, 0,
                            "cannot PUT to a collection");
              return NGX_HTTP_CONFLICT;
          }
  
          r->request_body_in_file_only = 1;
          r->request_body_in_persistent_file = 1;
          r->request_body_in_clean_file = 1;
          r->request_body_file_group_access = 1;
          r->request_body_file_log_level = 0;
  
          rc = ngx_http_read_client_request_body(r, ngx_http_dav_put_han
  
          if (rc >= NGX_HTTP_SPECIAL_RESPONSE) {
              return rc;
          }
  
          return NGX_DONE;

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


From nginx-forum at nginx.us  Tue Sep 17 08:23:25 2013
From: nginx-forum at nginx.us (Aleus Essentia)
Date: Tue, 17 Sep 2013 04:23:25 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C+0LvRg9GH0LjRgtGMIFBPU1Qt0LfQsNC/0YDQvtGBINCy?=
 =?UTF-8?B?INGB0L7QsdGB0YLQstC10L3QvdC+0Lwg0LzQvtC00YPQu9C1Pw==?=
In-Reply-To: <3266307d0617c4f00ed744d8a46c0098.NginxMailingListRussian@forum.nginx.org>
References: <3266307d0617c4f00ed744d8a46c0098.NginxMailingListRussian@forum.nginx.org>
Message-ID: <05a7ebb84bcb9ce5641fa527909bfe59.NginxMailingListRussian@forum.nginx.org>

Спасибо за совет. Нашёл статью с подробный описанием процесса получения
POST-запроса: http://habrahabr.ru/post/76963.

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


From usows at pomorsu.ru  Tue Sep 17 13:15:29 2013
From: usows at pomorsu.ru (usows)
Date: Tue, 17 Sep 2013 17:15:29 +0400
Subject: =?UTF-8?Q?Nginx_reverse_proxy_=D0=B8_WebDav?=
Message-ID: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>

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

Столкнулся сейчас с проблемой. Есть некий сервер, к нему идет обращение 
через reverse-proxy. До недавнего времени работа шла через прокси на 
апаче, сейчас в качестве прокси используется nginx
Проблема в том, что после переезда перестал работать WebDav для 
клиентов на Windows

Конфиг апача:


<VirtualHost *:80>
   ServerName server.example.ru
    Redirect permanent /        https://server.example.ru/
    ErrorLog /var/log/apache2/server.example.ru/error.log
    CustomLog /var/log/apache2/server.example.ru/access.log combined
</VirtualHost>

<VirtualHost *:443>
   ServerName server.example.ru
   ProxyRequests off

   Alias /errors/ "/var/www/errors/"
   <Proxy *>
     Order deny,allow
     Allow from all
   </Proxy>

   ProxyPass / http://server.example.local:8080/
   ProxyPassReverse / http://server.example.local:8080/

   ErrorLog /var/log/apache2/server.example.ru/error.log
   CustomLog /var/log/apache2/server.example.ru/access.log combined

   SSLEngine on
   SSLOptions +StrictRequire
   SSLProtocol -all +TLSv1 +SSLv3
   SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM
   SSLCertificateFile /etc/ssl/server/ssl.crt
   SSLCertificateKeyFile /etc/ssl/server/ssl.key
   SSLCertificateChainFile /etc/ssl/server/sub.class1.server.ca.pem
   SSLCACertificateFile /etc/ssl/server/ca.pem
   SSLVerifyClient none
   SSLProxyEngine off
   SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown 
downgrade-1.0 force-response-1.0
</VirtualHost>

Конфиг nginx:

server {
         listen 80;
         server_name server.example.ru;

         rewrite     ^ https://server.example.ru$request_uri? permanent;
         access_log /var/log/nginx/server/access.log;
         error_log /var/log/nginx/server/error.log;
}

server {
         listen 443 ssl;
         server_name server.example.ru
         ssl                     on;

         ssl_certificate         /etc/nginx/ssl/server.crt;
         ssl_certificate_key     /etc/nginx/ssl/server.key;

         access_log /var/log/nginx/server/access.log;
         error_log /var/log/nginx/server/error.log;

         location / {
                 proxy_set_header Host $host;
                 proxy_set_header X-Real-IP $remote_addr;
                 proxy_set_header X-Forwarded-Proto https;
                 proxy_set_header X-Forward-For 
$proxy_add_x_forwarded_for;

                 chunked_transfer_encoding off;

                 proxy_redirect off;
                 proxy_pass http://server.example.local:8080/;
         }
}


Заранее спасибо за помощь

Сергей


From mdounin at mdounin.ru  Tue Sep 17 13:43:52 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 17 Sep 2013 17:43:52 +0400
Subject: nginx-1.5.5
Message-ID: <20130917134351.GW57081@mdounin.ru>

Изменения в nginx 1.5.5                                           17.09.2013

    *) Изменение: теперь nginx по умолчанию использует HTTP/1.0, если точно
       определить протокол не удалось.

    *) Добавление: директива disable_symlinks теперь использует O_PATH на
       Linux.

    *) Добавление: для определения того, что клиент закрыл соединение, при
       использовании метода epoll теперь используются события EPOLLRDHUP.

    *) Исправление: в директиве valid_referers при использовании параметра
       server_names.

    *) Исправление: переменная $request_time не работала в nginx/Windows.

    *) Исправление: в директиве image_filter.
       Спасибо Lanshun Zhou.

    *) Исправление: совместимость с OpenSSL 1.0.1f.
       Спасибо Piotr Sikora.


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


From andrey at kopeyko.ru  Tue Sep 17 15:48:26 2013
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Tue, 17 Sep 2013 19:48:26 +0400
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
Message-ID: <523879CA.8020604@kopeyko.ru>

17.09.2013 17:15, usows пишет:
> Доброго времени суток

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

> Столкнулся сейчас с проблемой. Есть некий сервер, к нему идет обращение
> через reverse-proxy. До недавнего времени работа шла через прокси на
> апаче, сейчас в качестве прокси используется nginx
> Проблема в том, что после переезда перестал работать WebDav для клиентов
> на Windows

Вы, по-видимому, перед переездом невнимательно прочитали документацию. 
На http://nginx.org/ru/docs/http/ngx_http_dav_module.html прямо написано:

   Модуль обрабатывает HTTP- и WebDAV-методы PUT, DELETE, MKCOL, COPY и 
MOVE.
   ...
   WebDAV-клиенты, которые требуют для работы дополнительных
   WebDAV-методов, не будут работать с этим модулем.


Так что проблемой nginx это считать нельзя; это фича.

По-видимому, вам придётся откатывать взад.


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


From gmm at csdoc.com  Tue Sep 17 16:03:41 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Tue, 17 Sep 2013 19:03:41 +0300
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <523879CA.8020604@kopeyko.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru>
Message-ID: <52387D5D.3090300@csdoc.com>

On 17.09.2013 18:48, Andrey Kopeyko wrote:

> Вы, по-видимому, перед переездом невнимательно прочитали документацию.
> На http://nginx.org/ru/docs/http/ngx_http_dav_module.html прямо написано:
>
>    Модуль обрабатывает HTTP- и WebDAV-методы PUT, DELETE, MKCOL, COPY и
> MOVE.
>    ...
>    WebDAV-клиенты, которые требуют для работы дополнительных
>    WebDAV-методов, не будут работать с этим модулем.
>
> Так что проблемой nginx это считать нельзя; это фича.
>
> По-видимому, вам придётся откатывать взад.

вообще-то есть модуль https://github.com/arut/nginx-dav-ext-module
который реализует все недостающие методы, если надо полноценный WebDAV

-- 
Best regards,
  Gena


From mdounin at mdounin.ru  Tue Sep 17 16:08:34 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 17 Sep 2013 20:08:34 +0400
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <523879CA.8020604@kopeyko.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru>
Message-ID: <20130917160834.GB57081@mdounin.ru>

Hello!

On Tue, Sep 17, 2013 at 07:48:26PM +0400, Andrey Kopeyko wrote:

> 17.09.2013 17:15, usows пишет:
> >Доброго времени суток
> 
> Добрый вечер!
> 
> >Столкнулся сейчас с проблемой. Есть некий сервер, к нему идет обращение
> >через reverse-proxy. До недавнего времени работа шла через прокси на
> >апаче, сейчас в качестве прокси используется nginx
> >Проблема в том, что после переезда перестал работать WebDav для клиентов
> >на Windows
> 
> Вы, по-видимому, перед переездом невнимательно прочитали
> документацию. На
> http://nginx.org/ru/docs/http/ngx_http_dav_module.html прямо
> написано:
> 
>   Модуль обрабатывает HTTP- и WebDAV-методы PUT, DELETE, MKCOL, COPY
> и MOVE.
>   ...
>   WebDAV-клиенты, которые требуют для работы дополнительных
>   WebDAV-методов, не будут работать с этим модулем.
> 
> 
> Так что проблемой nginx это считать нельзя; это фича.
> 
> По-видимому, вам придётся откатывать взад.

Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это 
совершенно отдельная тема.  Должно работать.  Основная проблема, 
которая там обычно возникает - это заголовок Destination при 
всяких копированиях/перемещениях, если таковые используются.  Но 
это уже детали.

Другой вопрос, что по "престал работать WebDav" многого не 
надиагностируешь, а единственный телепат в нашей компании как раз 
в отпуске.  ;)

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


From alex.hha at gmail.com  Tue Sep 17 16:28:14 2013
From: alex.hha at gmail.com (Alex Domoradov)
Date: Tue, 17 Sep 2013 19:28:14 +0300
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <20130917160834.GB57081@mdounin.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
Message-ID: <CAK90gp7zm+ZpkmF4z+ny+V0iajggaJhMNRTp9O4PuMMsxmnT9w@mail.gmail.com>

> вообще-то есть модуль https://github.com/arut/nginx-dav-ext-module
который реализует все недостающие методы, если надо полноценный WebDAV
насколько помню, когда тестировал его с subversion 1.6.x, то нормально
он не работал. Возможно, что то поменялось, но судя по гитхаб, уже год
никаких изменений не вносилось

2013/9/17 Maxim Dounin <mdounin at mdounin.ru>:
> Hello!
>
> On Tue, Sep 17, 2013 at 07:48:26PM +0400, Andrey Kopeyko wrote:
>
>> 17.09.2013 17:15, usows пишет:
>> >Доброго времени суток
>>
>> Добрый вечер!
>>
>> >Столкнулся сейчас с проблемой. Есть некий сервер, к нему идет обращение
>> >через reverse-proxy. До недавнего времени работа шла через прокси на
>> >апаче, сейчас в качестве прокси используется nginx
>> >Проблема в том, что после переезда перестал работать WebDav для клиентов
>> >на Windows
>>
>> Вы, по-видимому, перед переездом невнимательно прочитали
>> документацию. На
>> http://nginx.org/ru/docs/http/ngx_http_dav_module.html прямо
>> написано:
>>
>>   Модуль обрабатывает HTTP- и WebDAV-методы PUT, DELETE, MKCOL, COPY
>> и MOVE.
>>   ...
>>   WebDAV-клиенты, которые требуют для работы дополнительных
>>   WebDAV-методов, не будут работать с этим модулем.
>>
>>
>> Так что проблемой nginx это считать нельзя; это фича.
>>
>> По-видимому, вам придётся откатывать взад.
>
> Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это
> совершенно отдельная тема.  Должно работать.  Основная проблема,
> которая там обычно возникает - это заголовок Destination при
> всяких копированиях/перемещениях, если таковые используются.  Но
> это уже детали.
>
> Другой вопрос, что по "престал работать WebDav" многого не
> надиагностируешь, а единственный телепат в нашей компании как раз
> в отпуске.  ;)
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From andrey at kopeyko.ru  Tue Sep 17 16:38:02 2013
From: andrey at kopeyko.ru (Andrey Kopeyko)
Date: Tue, 17 Sep 2013 20:38:02 +0400
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <20130917160834.GB57081@mdounin.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
Message-ID: <5238856A.70907@kopeyko.ru>

17.09.2013 20:08, Maxim Dounin пишет:
> Hello!
>
> On Tue, Sep 17, 2013 at 07:48:26PM +0400, Andrey Kopeyko wrote:
>
>> 17.09.2013 17:15, usows пишет:
>>> Доброго времени суток
>>
>> Добрый вечер!
>>
>>> Столкнулся сейчас с проблемой. Есть некий сервер, к нему идет обращение
>>> через reverse-proxy. До недавнего времени работа шла через прокси на
>>> апаче, сейчас в качестве прокси используется nginx
>>> Проблема в том, что после переезда перестал работать WebDav для клиентов
>>> на Windows
>>
>> Вы, по-видимому, перед переездом невнимательно прочитали
>> документацию. На
>> http://nginx.org/ru/docs/http/ngx_http_dav_module.html прямо
>> написано:
>>
>>    Модуль обрабатывает HTTP- и WebDAV-методы PUT, DELETE, MKCOL, COPY
>> и MOVE.
>>    ...
>>    WebDAV-клиенты, которые требуют для работы дополнительных
>>    WebDAV-методов, не будут работать с этим модулем.
>>
>>
>> Так что проблемой nginx это считать нельзя; это фича.
>>
>> По-видимому, вам придётся откатывать взад.
>
> Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это
> совершенно отдельная тема.  Должно работать.

Хорошо коли так - мой личный опыт успешного проксирования webDAV 
ограничивается ровно "разрешёнными" методами GET\PUT\DELETE (других в 
моей задаче просто не требуется).


> Другой вопрос, что по "престал работать WebDav" многого не
> надиагностируешь, а единственный телепат в нашей компании как раз
> в отпуске.  ;)

Это да.

А не пора ли на сайте nginx.org вывесить "правила правильного задавания 
вопроса 'почему у меня не работает ХХХ?' в рассылку", с подробным примером?

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

>


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


From arut at qip.ru  Tue Sep 17 16:55:35 2013
From: arut at qip.ru (Roman Arutyunyan)
Date: Tue, 17 Sep 2013 20:55:35 +0400
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <CAK90gp7zm+ZpkmF4z+ny+V0iajggaJhMNRTp9O4PuMMsxmnT9w@mail.gmail.com>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
 <CAK90gp7zm+ZpkmF4z+ny+V0iajggaJhMNRTp9O4PuMMsxmnT9w@mail.gmail.com>
Message-ID: <20130917205535.369123b9@laptop>

On Tue, 17 Sep 2013 19:28:14 +0300
Alex Domoradov <alex.hha at gmail.com> wrote:

> > вообще-то есть модуль https://github.com/arut/nginx-dav-ext-module
> который реализует все недостающие методы, если надо полноценный WebDAV
> насколько помню, когда тестировал его с subversion 1.6.x, то нормально
> он не работал. Возможно, что то поменялось, но судя по гитхаб, уже год
> никаких изменений не вносилось

В subversion совершенно свой подход к WebDAV. Это не просто доступ к
файловой системе через вебдав, там свои объекты и куча специфики. Когда
реализую LOCK, будет работать git, а svn, боюсь, не будет никогда.


From mdounin at mdounin.ru  Tue Sep 17 17:26:41 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 17 Sep 2013 21:26:41 +0400
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <5238856A.70907@kopeyko.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
 <5238856A.70907@kopeyko.ru>
Message-ID: <20130917172641.GC57081@mdounin.ru>

Hello!

On Tue, Sep 17, 2013 at 08:38:02PM +0400, Andrey Kopeyko wrote:

> 17.09.2013 20:08, Maxim Dounin пишет:
> >Hello!
> >
> >On Tue, Sep 17, 2013 at 07:48:26PM +0400, Andrey Kopeyko wrote:
> >
> >>17.09.2013 17:15, usows пишет:
> >>>Доброго времени суток
> >>
> >>Добрый вечер!
> >>
> >>>Столкнулся сейчас с проблемой. Есть некий сервер, к нему идет обращение
> >>>через reverse-proxy. До недавнего времени работа шла через прокси на
> >>>апаче, сейчас в качестве прокси используется nginx
> >>>Проблема в том, что после переезда перестал работать WebDav для клиентов
> >>>на Windows
> >>
> >>Вы, по-видимому, перед переездом невнимательно прочитали
> >>документацию. На
> >>http://nginx.org/ru/docs/http/ngx_http_dav_module.html прямо
> >>написано:
> >>
> >>   Модуль обрабатывает HTTP- и WebDAV-методы PUT, DELETE, MKCOL, COPY
> >>и MOVE.
> >>   ...
> >>   WebDAV-клиенты, которые требуют для работы дополнительных
> >>   WebDAV-методов, не будут работать с этим модулем.
> >>
> >>
> >>Так что проблемой nginx это считать нельзя; это фича.
> >>
> >>По-видимому, вам придётся откатывать взад.
> >
> >Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это
> >совершенно отдельная тема.  Должно работать.
> 
> Хорошо коли так - мой личный опыт успешного проксирования webDAV
> ограничивается ровно "разрешёнными" методами GET\PUT\DELETE (других
> в моей задаче просто не требуется).

Ну так nginx'у по большому счёту всё равно, что проксировать - 
GET, PUT, или ещё что.

Из того, что вспоминается - могут быть проблемы с "OPTIONS *", 
если вдруг клиенты его пытаются использовать.

> >Другой вопрос, что по "престал работать WebDav" многого не
> >надиагностируешь, а единственный телепат в нашей компании как раз
> >в отпуске.  ;)
> 
> Это да.
> 
> А не пора ли на сайте nginx.org вывесить "правила правильного
> задавания вопроса 'почему у меня не работает ХХХ?' в рассылку", с
> подробным примером?
> 
> Было бы куда отправлять как взывающих к телепатам, так и по каплям
> выжимающих из себя информацию о своей системе. Там бы и расписали
> подробно "куда ваша информация может, а куда точно не может
> попасть", т.е. принятые внутренние стандарты обращения с данным
> пользователей\клиентов.

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

http://wiki.nginx.org/Debugging

Но оно больше расчитано на серьёзный анализ, а не проблемы класса 
"не работает".  Впрочем, как по мне, то пусть уж пишут в рассылку, 
лишь бы тикетов в trac'е не заводили.  ;)

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


From alex.hha at gmail.com  Tue Sep 17 19:41:45 2013
From: alex.hha at gmail.com (Alex Domoradov)
Date: Tue, 17 Sep 2013 22:41:45 +0300
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <20130917172641.GC57081@mdounin.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
 <5238856A.70907@kopeyko.ru> <20130917172641.GC57081@mdounin.ru>
Message-ID: <CAK90gp4sz8y__1upmsRc8BjAD780odO5EUAyTUyV3nPX+cB+nw@mail.gmail.com>

> Когда реализую LOCK, будет работать git, а svn, боюсь, не будет никогда.
жаль, очень не хватает, чтобы перейти на nginx.

2013/9/17 Maxim Dounin <mdounin at mdounin.ru>:
> Hello!
>
> On Tue, Sep 17, 2013 at 08:38:02PM +0400, Andrey Kopeyko wrote:
>
>> 17.09.2013 20:08, Maxim Dounin пишет:
>> >Hello!
>> >
>> >On Tue, Sep 17, 2013 at 07:48:26PM +0400, Andrey Kopeyko wrote:
>> >
>> >>17.09.2013 17:15, usows пишет:
>> >>>Доброго времени суток
>> >>
>> >>Добрый вечер!
>> >>
>> >>>Столкнулся сейчас с проблемой. Есть некий сервер, к нему идет обращение
>> >>>через reverse-proxy. До недавнего времени работа шла через прокси на
>> >>>апаче, сейчас в качестве прокси используется nginx
>> >>>Проблема в том, что после переезда перестал работать WebDav для клиентов
>> >>>на Windows
>> >>
>> >>Вы, по-видимому, перед переездом невнимательно прочитали
>> >>документацию. На
>> >>http://nginx.org/ru/docs/http/ngx_http_dav_module.html прямо
>> >>написано:
>> >>
>> >>   Модуль обрабатывает HTTP- и WebDAV-методы PUT, DELETE, MKCOL, COPY
>> >>и MOVE.
>> >>   ...
>> >>   WebDAV-клиенты, которые требуют для работы дополнительных
>> >>   WebDAV-методов, не будут работать с этим модулем.
>> >>
>> >>
>> >>Так что проблемой nginx это считать нельзя; это фича.
>> >>
>> >>По-видимому, вам придётся откатывать взад.
>> >
>> >Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это
>> >совершенно отдельная тема.  Должно работать.
>>
>> Хорошо коли так - мой личный опыт успешного проксирования webDAV
>> ограничивается ровно "разрешёнными" методами GET\PUT\DELETE (других
>> в моей задаче просто не требуется).
>
> Ну так nginx'у по большому счёту всё равно, что проксировать -
> GET, PUT, или ещё что.
>
> Из того, что вспоминается - могут быть проблемы с "OPTIONS *",
> если вдруг клиенты его пытаются использовать.
>
>> >Другой вопрос, что по "престал работать WebDav" многого не
>> >надиагностируешь, а единственный телепат в нашей компании как раз
>> >в отпуске.  ;)
>>
>> Это да.
>>
>> А не пора ли на сайте nginx.org вывесить "правила правильного
>> задавания вопроса 'почему у меня не работает ХХХ?' в рассылку", с
>> подробным примером?
>>
>> Было бы куда отправлять как взывающих к телепатам, так и по каплям
>> выжимающих из себя информацию о своей системе. Там бы и расписали
>> подробно "куда ваша информация может, а куда точно не может
>> попасть", т.е. принятые внутренние стандарты обращения с данным
>> пользователей\клиентов.
>
> Я в своё время попытался что-нибудь написать тут:
>
> http://wiki.nginx.org/Debugging
>
> Но оно больше расчитано на серьёзный анализ, а не проблемы класса
> "не работает".  Впрочем, как по мне, то пусть уж пишут в рассылку,
> лишь бы тикетов в trac'е не заводили.  ;)
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From usows at pomorsu.ru  Wed Sep 18 06:41:20 2013
From: usows at pomorsu.ru (usows)
Date: Wed, 18 Sep 2013 10:41:20 +0400
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <20130917160834.GB57081@mdounin.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
Message-ID: <ed8b916e06774d4ba2e844b07e78c84f@mail.pomorsu.ru>


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

Maxim Dounin писал 17.09.2013 20:08:
> Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это
> совершенно отдельная тема.  Должно работать.  Основная проблема,
> которая там обычно возникает - это заголовок Destination при
> всяких копированиях/перемещениях, если таковые используются.  Но
> это уже детали.
>
> Другой вопрос, что по "престал работать WebDav" многого не
> надиагностируешь, а единственный телепат в нашей компании как раз
> в отпуске.  ;)


Я очень извиняюсь за неполное описание проблемы

Подключение нормально работает в клиентах типа cadaver, список файлов 
нормально открывается в браузере (в т.ч. IE). Попытка подключить ресурс 
как сетевой диск (net use * https://server.example.ru/dav /USER:user 
password) выкидывает ошибку "Системная ошибка 1244. Запрошенная операция 
не была выполнена, так как пользователь не зарегистрирован."
Еще раз подчеркиваю, то же самое подключение на том же компьютере с той 
же учеткой в браузере открывается нормально

В логах nginx ничего нет. То есть, при попытке подключить сетевой диск 
в логах просто ничего не появляется

Мне кажется, проблема где-то в настройках SSL


From alex.hha at gmail.com  Wed Sep 18 06:53:16 2013
From: alex.hha at gmail.com (Alex Domoradov)
Date: Wed, 18 Sep 2013 09:53:16 +0300
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <ed8b916e06774d4ba2e844b07e78c84f@mail.pomorsu.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
 <ed8b916e06774d4ba2e844b07e78c84f@mail.pomorsu.ru>
Message-ID: <CAK90gp4cFntq_-ya7f82Ej7YVO-0=z6O393e5de6n7x4ySYQQA@mail.gmail.com>

Ну чтобы точно понять дело в SSL или где то еще, попробуй подключить
просто по http

2013/9/18 usows <usows at pomorsu.ru>:
>
> Здравствуйте
>
> Maxim Dounin писал 17.09.2013 20:08:
>
>> Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это
>> совершенно отдельная тема.  Должно работать.  Основная проблема,
>> которая там обычно возникает - это заголовок Destination при
>> всяких копированиях/перемещениях, если таковые используются.  Но
>> это уже детали.
>>
>> Другой вопрос, что по "престал работать WebDav" многого не
>> надиагностируешь, а единственный телепат в нашей компании как раз
>> в отпуске.  ;)
>
>
>
> Я очень извиняюсь за неполное описание проблемы
>
> Подключение нормально работает в клиентах типа cadaver, список файлов
> нормально открывается в браузере (в т.ч. IE). Попытка подключить ресурс как
> сетевой диск (net use * https://server.example.ru/dav /USER:user password)
> выкидывает ошибку "Системная ошибка 1244. Запрошенная операция не была
> выполнена, так как пользователь не зарегистрирован."
> Еще раз подчеркиваю, то же самое подключение на том же компьютере с той же
> учеткой в браузере открывается нормально
>
> В логах nginx ничего нет. То есть, при попытке подключить сетевой диск в
> логах просто ничего не появляется
>
> Мне кажется, проблема где-то в настройках SSL
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From usows at pomorsu.ru  Wed Sep 18 07:30:51 2013
From: usows at pomorsu.ru (usows)
Date: Wed, 18 Sep 2013 11:30:51 +0400
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <CAK90gp4cFntq_-ya7f82Ej7YVO-0=z6O393e5de6n7x4ySYQQA@mail.gmail.com>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
 <ed8b916e06774d4ba2e844b07e78c84f@mail.pomorsu.ru>
 <CAK90gp4cFntq_-ya7f82Ej7YVO-0=z6O393e5de6n7x4ySYQQA@mail.gmail.com>
Message-ID: <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru>

К сожалению, просто не получится. Бэкенд работает только по https

Alex Domoradov писал 18.09.2013 10:53:
> Ну чтобы точно понять дело в SSL или где то еще, попробуй подключить
> просто по http
>
> 2013/9/18 usows <usows at pomorsu.ru>:
>>
>> Здравствуйте
>>
>> Maxim Dounin писал 17.09.2013 20:08:
>>
>>> Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это
>>> совершенно отдельная тема.  Должно работать.  Основная проблема,
>>> которая там обычно возникает - это заголовок Destination при
>>> всяких копированиях/перемещениях, если таковые используются.  Но
>>> это уже детали.
>>>
>>> Другой вопрос, что по "престал работать WebDav" многого не
>>> надиагностируешь, а единственный телепат в нашей компании как раз
>>> в отпуске.  ;)
>>
>>
>>
>> Я очень извиняюсь за неполное описание проблемы
>>
>> Подключение нормально работает в клиентах типа cadaver, список 
>> файлов
>> нормально открывается в браузере (в т.ч. IE). Попытка подключить 
>> ресурс как
>> сетевой диск (net use * https://server.example.ru/dav /USER:user 
>> password)
>> выкидывает ошибку "Системная ошибка 1244. Запрошенная операция не 
>> была
>> выполнена, так как пользователь не зарегистрирован."
>> Еще раз подчеркиваю, то же самое подключение на том же компьютере с 
>> той же
>> учеткой в браузере открывается нормально
>>
>> В логах nginx ничего нет. То есть, при попытке подключить сетевой 
>> диск в
>> логах просто ничего не появляется
>>
>> Мне кажется, проблема где-то в настройках SSL
>>
>>
>> _______________________________________________
>> 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

-- 
Ведущий программист отдела СА УИТ САФУ
Усов С.А.

s.usov at agtu.ru

(8182)21-61-00p1797


From nginx-forum at nginx.us  Wed Sep 18 08:04:54 2013
From: nginx-forum at nginx.us (Aleus Essentia)
Date: Wed, 18 Sep 2013 04:04:54 -0400
Subject: =?UTF-8?B?bmd4IGh0dHAgZ2V0IG1vZHVsZSBsb2MgY29uZiDQstC+0LfQstGA0LDRidCw0LU=?=
 =?UTF-8?B?0YIgTlVMTA==?=
Message-ID: <771fdd1e6fc5079ea7e49b61d0f38d27.NginxMailingListRussian@forum.nginx.org>

Написал маленький модуль. Но почему-то не могу получить конфигурации локации
- возвращается NULL? Хендлер, в котором нужна конфа находится в фазе
NGX_HTTP_CONTENT_PHASE.
Вот код модуля:

typedef struct {
	ngx_str_t  path;
} ngx_http_ispmngr_loc_conf_t;

static ngx_command_t  ngx_http_mymodule_commands[] = {
    { ngx_string("mymodule"),
      NGX_HTTP_LOC_CONF|NGX_CONF_NOARGS,
      ngx_http_mymodule,
      NGX_HTTP_LOC_CONF_OFFSET,
      0,
      NULL },

    { ngx_string("path_in_mymodule"),
      NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1,
      ngx_conf_set_str_slot, 
      NGX_HTTP_LOC_CONF_OFFSET,
      offsetof(ngx_http_mymodule_loc_conf_t, path),
      NULL },

      ngx_null_command
};

static ngx_http_module_t  ngx_http_mymodule_module_ctx = {
    NULL,       
    NULL,       

    NULL,       
    NULL,       

    NULL,       
    NULL,       

    ngx_http_mymodule_create_loc_conf,
    ngx_http_mymodule_merge_loc_conf 
};

ngx_module_t  ngx_http_mymodule_module = {
    NGX_MODULE_V1,
    &ngx_http_mymodule_module_ctx, 
    ngx_http_mymodule_commands,   
    NGX_HTTP_MODULE,              
    NULL, 
    NULL, 
    NULL, 
    NULL, 
    NULL, 
    NULL, 
    NULL, 
    NGX_MODULE_V1_PADDING
};

static ngx_int_t
ngx_http_mymodule_handler (ngx_http_request_t *r)
{
    ngx_http_mymodule_loc_conf_t *clcf
    	= ngx_http_get_module_loc_conf( r, ngx_http_mymodule_module );

	if( clcf ){
		ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "couldn't retrieve
module configurationr.");
		return NGX_ERROR;
	}
   
   // .....
   // some code
   // ....


    return ngx_http_output_filter(r, &out);
}

static char *
ngx_http_mymodule(ngx_conf_t *cf, ngx_command_t *cmd, void *conf)
{
    ngx_http_core_loc_conf_t    *clcf;

    clcf          = ngx_http_conf_get_module_loc_conf(cf,
ngx_http_core_module);
    clcf->handler = ngx_http_mymodule_handler;

    return NGX_CONF_OK;
}

static void *
ngx_http_mymodule_create_loc_conf(ngx_conf_t *cf)
{
    ngx_http_mymodule_loc_conf_t  *conf;

    conf = ngx_pcalloc(cf->pool, sizeof(ngx_http_mymodule_loc_conf_t));
    if (conf == NULL) {
        return NGX_CONF_ERROR;
    }

    return conf;
}

static char *
ngx_http_mymodule_merge_loc_conf(ngx_conf_t *cf, void *parent, void *child)
{
    ngx_http_mymodule_loc_conf_t *prev = parent;
    ngx_http_mymodule_loc_conf_t *conf = child;
    ngx_conf_merge_str_value( conf->path, prev->path, "./" );
    return NGX_CONF_OK;
}

Конфигурация NGINX:
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  15;

    server {
        listen       80 default_server;
        listen       3000;
        server_name  localhost expt expt.ru;

        access_log /home/aleus/server/expt/logs.txt;
        error_log  /home/aleus/server/expt/error.txt debug_http;
        charset utf-8;

        location / {
            root  /home/usr/html;
	    path  /home/usr/path;
	    mymodule;
            index  index.html index.htm;
        }
    }
}

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


From kav at karagodov.name  Wed Sep 18 08:31:49 2013
From: kav at karagodov.name (Alexey V. Karagodov)
Date: Wed, 18 Sep 2013 12:31:49 +0400
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
 <ed8b916e06774d4ba2e844b07e78c84f@mail.pomorsu.ru>
 <CAK90gp4cFntq_-ya7f82Ej7YVO-0=z6O393e5de6n7x4ySYQQA@mail.gmail.com>
 <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru>
Message-ID: <054A0AA8-BD69-46DA-A26A-DC721987F378@karagodov.name>

кто то ж делал доп-модуль к штатному дав-у nginx-а 
загуглите, там были реализованы недостающие методы 
 ! НО ! 
как то было сыровато и с мак-ами не очень дружило 

On 18.09.2013, at 11:30, usows <usows at pomorsu.ru> wrote:

> К сожалению, просто не получится. Бэкенд работает только по https
> 
> Alex Domoradov писал 18.09.2013 10:53:
>> Ну чтобы точно понять дело в SSL или где то еще, попробуй подключить
>> просто по http
>> 
>> 2013/9/18 usows <usows at pomorsu.ru>:
>>> 
>>> Здравствуйте
>>> 
>>> Maxim Dounin писал 17.09.2013 20:08:
>>> 
>>>> Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это
>>>> совершенно отдельная тема.  Должно работать.  Основная проблема,
>>>> которая там обычно возникает - это заголовок Destination при
>>>> всяких копированиях/перемещениях, если таковые используются.  Но
>>>> это уже детали.
>>>> 
>>>> Другой вопрос, что по "престал работать WebDav" многого не
>>>> надиагностируешь, а единственный телепат в нашей компании как раз
>>>> в отпуске.  ;)
>>> 
>>> 
>>> 
>>> Я очень извиняюсь за неполное описание проблемы
>>> 
>>> Подключение нормально работает в клиентах типа cadaver, список файлов
>>> нормально открывается в браузере (в т.ч. IE). Попытка подключить ресурс как
>>> сетевой диск (net use * https://server.example.ru/dav /USER:user password)
>>> выкидывает ошибку "Системная ошибка 1244. Запрошенная операция не была
>>> выполнена, так как пользователь не зарегистрирован."
>>> Еще раз подчеркиваю, то же самое подключение на том же компьютере с той же
>>> учеткой в браузере открывается нормально
>>> 
>>> В логах nginx ничего нет. То есть, при попытке подключить сетевой диск в
>>> логах просто ничего не появляется
>>> 
>>> Мне кажется, проблема где-то в настройках SSL
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> -- 
> Ведущий программист отдела СА УИТ САФУ
> Усов С.А.
> 
> s.usov at agtu.ru
> 
> (8182)21-61-00p1797
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130918/8028a427/attachment-0001.bin>

From usows at pomorsu.ru  Wed Sep 18 08:41:49 2013
From: usows at pomorsu.ru (usows)
Date: Wed, 18 Sep 2013 12:41:49 +0400
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <054A0AA8-BD69-46DA-A26A-DC721987F378@karagodov.name>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
 <ed8b916e06774d4ba2e844b07e78c84f@mail.pomorsu.ru>
 <CAK90gp4cFntq_-ya7f82Ej7YVO-0=z6O393e5de6n7x4ySYQQA@mail.gmail.com>
 <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru>
 <054A0AA8-BD69-46DA-A26A-DC721987F378@karagodov.name>
Message-ID: <0e8c7e4f4f53ed5dbe8af552aa826bb6@mail.pomorsu.ru>

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

Alexey V. Karagodov писал 18.09.2013 12:31:
> кто то ж делал доп-модуль к штатному дав-у nginx-а
> загуглите, там были реализованы недостающие методы
>  ! НО !
> как то было сыровато и с мак-ами не очень дружило
>
> On 18.09.2013, at 11:30, usows <usows at pomorsu.ru> wrote:
>
>> К сожалению, просто не получится. Бэкенд работает только по https
>>
>> Alex Domoradov писал 18.09.2013 10:53:
>>> Ну чтобы точно понять дело в SSL или где то еще, попробуй 
>>> подключить
>>> просто по http
>>>
>>> 2013/9/18 usows <usows at pomorsu.ru>:
>>>>
>>>> Здравствуйте
>>>>
>>>> Maxim Dounin писал 17.09.2013 20:08:
>>>>
>>>>> Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это
>>>>> совершенно отдельная тема.  Должно работать.  Основная проблема,
>>>>> которая там обычно возникает - это заголовок Destination при
>>>>> всяких копированиях/перемещениях, если таковые используются.  Но
>>>>> это уже детали.
>>>>>
>>>>> Другой вопрос, что по "престал работать WebDav" многого не
>>>>> надиагностируешь, а единственный телепат в нашей компании как раз
>>>>> в отпуске.  ;)
>>>>
>>>>
>>>>
>>>> Я очень извиняюсь за неполное описание проблемы
>>>>
>>>> Подключение нормально работает в клиентах типа cadaver, список 
>>>> файлов
>>>> нормально открывается в браузере (в т.ч. IE). Попытка подключить 
>>>> ресурс как
>>>> сетевой диск (net use * https://server.example.ru/dav /USER:user 
>>>> password)
>>>> выкидывает ошибку "Системная ошибка 1244. Запрошенная операция не 
>>>> была
>>>> выполнена, так как пользователь не зарегистрирован."
>>>> Еще раз подчеркиваю, то же самое подключение на том же компьютере 
>>>> с той же
>>>> учеткой в браузере открывается нормально
>>>>
>>>> В логах nginx ничего нет. То есть, при попытке подключить сетевой 
>>>> диск в
>>>> логах просто ничего не появляется
>>>>
>>>> Мне кажется, проблема где-то в настройках SSL
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> --
>> Ведущий программист отдела СА УИТ САФУ
>> Усов С.А.
>>
>> s.usov at agtu.ru
>>
>> (8182)21-61-00p1797
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Ведущий программист отдела СА УИТ САФУ
Усов С.А.

s.usov at agtu.ru

(8182)21-61-00p1797


From mdounin at mdounin.ru  Wed Sep 18 12:05:55 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 18 Sep 2013 16:05:55 +0400
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
 <ed8b916e06774d4ba2e844b07e78c84f@mail.pomorsu.ru>
 <CAK90gp4cFntq_-ya7f82Ej7YVO-0=z6O393e5de6n7x4ySYQQA@mail.gmail.com>
 <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru>
Message-ID: <20130918120555.GE57081@mdounin.ru>

Hello!

On Wed, Sep 18, 2013 at 11:30:51AM +0400, usows wrote:

> К сожалению, просто не получится. Бэкенд работает только по https

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

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

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


From chipitsine at gmail.com  Wed Sep 18 12:04:22 2013
From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=)
Date: Wed, 18 Sep 2013 18:04:22 +0600
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <0e8c7e4f4f53ed5dbe8af552aa826bb6@mail.pomorsu.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
 <ed8b916e06774d4ba2e844b07e78c84f@mail.pomorsu.ru>
 <CAK90gp4cFntq_-ya7f82Ej7YVO-0=z6O393e5de6n7x4ySYQQA@mail.gmail.com>
 <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru>
 <054A0AA8-BD69-46DA-A26A-DC721987F378@karagodov.name>
 <0e8c7e4f4f53ed5dbe8af552aa826bb6@mail.pomorsu.ru>
Message-ID: <CAFHpkQHqGhSurR4Gpyc0=5MS+j0DupcyV9DRWz+hp5W5xrUkQA@mail.gmail.com>

а вы сравните в Fiddler-е запросы в случае, когда работает, и, когда
не работает.
ну или можно декодировать SSL при помощи Wireshark

я так понимаю, у вас ситуация "не работает, но логов нет" ? а снифер
вы не знаете как делать, потому что SSL ?

18 сентября 2013 г., 14:41 пользователь usows <usows at pomorsu.ru> написал:
> В моем случае WebDav реализует бэкенд, nginx только проксирует запросы. И
> работает все, за исключением подключения диска в виндах...
>
> Alexey V. Karagodov писал 18.09.2013 12:31:
>
>> кто то ж делал доп-модуль к штатному дав-у nginx-а
>> загуглите, там были реализованы недостающие методы
>>  ! НО !
>> как то было сыровато и с мак-ами не очень дружило
>>
>> On 18.09.2013, at 11:30, usows <usows at pomorsu.ru> wrote:
>>
>>> К сожалению, просто не получится. Бэкенд работает только по https
>>>
>>> Alex Domoradov писал 18.09.2013 10:53:
>>>>
>>>> Ну чтобы точно понять дело в SSL или где то еще, попробуй подключить
>>>> просто по http
>>>>
>>>> 2013/9/18 usows <usows at pomorsu.ru>:
>>>>>
>>>>>
>>>>> Здравствуйте
>>>>>
>>>>> Maxim Dounin писал 17.09.2013 20:08:
>>>>>
>>>>>> Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это
>>>>>> совершенно отдельная тема.  Должно работать.  Основная проблема,
>>>>>> которая там обычно возникает - это заголовок Destination при
>>>>>> всяких копированиях/перемещениях, если таковые используются.  Но
>>>>>> это уже детали.
>>>>>>
>>>>>> Другой вопрос, что по "престал работать WebDav" многого не
>>>>>> надиагностируешь, а единственный телепат в нашей компании как раз
>>>>>> в отпуске.  ;)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Я очень извиняюсь за неполное описание проблемы
>>>>>
>>>>> Подключение нормально работает в клиентах типа cadaver, список файлов
>>>>> нормально открывается в браузере (в т.ч. IE). Попытка подключить ресурс
>>>>> как
>>>>> сетевой диск (net use * https://server.example.ru/dav /USER:user
>>>>> password)
>>>>> выкидывает ошибку "Системная ошибка 1244. Запрошенная операция не была
>>>>> выполнена, так как пользователь не зарегистрирован."
>>>>> Еще раз подчеркиваю, то же самое подключение на том же компьютере с той
>>>>> же
>>>>> учеткой в браузере открывается нормально
>>>>>
>>>>> В логах nginx ничего нет. То есть, при попытке подключить сетевой диск
>>>>> в
>>>>> логах просто ничего не появляется
>>>>>
>>>>> Мне кажется, проблема где-то в настройках SSL
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>> --
>>> Ведущий программист отдела СА УИТ САФУ
>>> Усов С.А.
>>>
>>> s.usov at agtu.ru
>>>
>>> (8182)21-61-00p1797
>>>
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> --
> Ведущий программист отдела СА УИТ САФУ
> Усов С.А.
>
> s.usov at agtu.ru
>
> (8182)21-61-00p1797
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From onokonem at gmail.com  Wed Sep 18 12:18:51 2013
From: onokonem at gmail.com (Daniel Podolsky)
Date: Wed, 18 Sep 2013 16:18:51 +0400
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <CAFHpkQHqGhSurR4Gpyc0=5MS+j0DupcyV9DRWz+hp5W5xrUkQA@mail.gmail.com>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
 <ed8b916e06774d4ba2e844b07e78c84f@mail.pomorsu.ru>
 <CAK90gp4cFntq_-ya7f82Ej7YVO-0=z6O393e5de6n7x4ySYQQA@mail.gmail.com>
 <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru>
 <054A0AA8-BD69-46DA-A26A-DC721987F378@karagodov.name>
 <0e8c7e4f4f53ed5dbe8af552aa826bb6@mail.pomorsu.ru>
 <CAFHpkQHqGhSurR4Gpyc0=5MS+j0DupcyV9DRWz+hp5W5xrUkQA@mail.gmail.com>
Message-ID: <CAKaHDOG5R64ouceHZN7UTiS+V_4fDVttFRep1C6VZuZ2gnsqng@mail.gmail.com>

> ну или можно декодировать SSL при помощи Wireshark
В общем случае - нельзя. Даже зная ключ и сертификат. Такое нынче шифрование.

Надо еще правильных ciphers указать, которые могут быть дешифрации подвергнуты.

From vbart at nginx.com  Wed Sep 18 13:14:52 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Wed, 18 Sep 2013 17:14:52 +0400
Subject: =?UTF-8?B?UmU6IG5neCBodHRwIGdldCBtb2R1bGUgbG9jIGNvbmYg0LLQvtC30LLRgNCw0Yk=?=
 =?UTF-8?B?0LDQtdGCIE5VTEw=?=
In-Reply-To: <771fdd1e6fc5079ea7e49b61d0f38d27.NginxMailingListRussian@forum.nginx.org>
References: <771fdd1e6fc5079ea7e49b61d0f38d27.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201309181714.52512.vbart@nginx.com>

On Wednesday 18 September 2013 12:04:54 Aleus Essentia wrote:
> Написал маленький модуль. Но почему-то не могу получить конфигурации
> локации - возвращается NULL? Хендлер, в котором нужна конфа находится в
> фазе NGX_HTTP_CONTENT_PHASE.
> Вот код модуля:
[...]
> 	if( clcf ){
> 		ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "couldn't retrieve
> module configurationr.");
> 		return NGX_ERROR;
> 	}

Т.е. если clcf *не* 0, то печатаем ошибку и возвращаем NGX_ERROR.

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

From chipitsine at gmail.com  Wed Sep 18 13:20:15 2013
From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=)
Date: Wed, 18 Sep 2013 19:20:15 +0600
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <CAKaHDOG5R64ouceHZN7UTiS+V_4fDVttFRep1C6VZuZ2gnsqng@mail.gmail.com>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
 <ed8b916e06774d4ba2e844b07e78c84f@mail.pomorsu.ru>
 <CAK90gp4cFntq_-ya7f82Ej7YVO-0=z6O393e5de6n7x4ySYQQA@mail.gmail.com>
 <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru>
 <054A0AA8-BD69-46DA-A26A-DC721987F378@karagodov.name>
 <0e8c7e4f4f53ed5dbe8af552aa826bb6@mail.pomorsu.ru>
 <CAFHpkQHqGhSurR4Gpyc0=5MS+j0DupcyV9DRWz+hp5W5xrUkQA@mail.gmail.com>
 <CAKaHDOG5R64ouceHZN7UTiS+V_4fDVttFRep1C6VZuZ2gnsqng@mail.gmail.com>
Message-ID: <CAFHpkQGQAZ_xkQsTkvW42u-n=PrdQkedxutNUZ5_BiWQepGXhQ@mail.gmail.com>

ну это да, шифры надо указать. об этом вам Wireshark очень внятно
намекнет (в debug log), если не сможет декодировать.

18 сентября 2013 г., 18:18 пользователь Daniel Podolsky
<onokonem at gmail.com> написал:
>> ну или можно декодировать SSL при помощи Wireshark
> В общем случае - нельзя. Даже зная ключ и сертификат. Такое нынче шифрование.
>
> Надо еще правильных ciphers указать, которые могут быть дешифрации подвергнуты.
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From chmind at yandex.ru  Wed Sep 18 13:52:52 2013
From: chmind at yandex.ru (chmind at yandex.ru)
Date: Wed, 18 Sep 2013 17:52:52 +0400
Subject: =?UTF-8?B?Y3JvcCDQstC80LXRgdGC0LUg0YEgcmVzaXplINC40YHQv9C+0LvRjNC30YPRjyA=?=
 =?UTF-8?B?0LzQvtC00YPQu9GMIG5neF9odHRwX2ltYWdlX2ZpbHRlcl9tb2R1bGU=?=
Message-ID: <E2807AFC-822E-4164-98AD-D4D1C16EBEC2@yandex.ru>

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

Подскажите пожалуйста, возможно ли как-то сделать  crop вместе с resize используя модуль ngx_http_image_filter_module ? 
Спасибо. 

From mdounin at mdounin.ru  Wed Sep 18 14:10:48 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 18 Sep 2013 18:10:48 +0400
Subject: =?UTF-8?B?UmU6IGNyb3Ag0LLQvNC10YHRgtC1INGBIHJlc2l6ZSDQuNGB0L/QvtC70YzQt9GD?=
 =?UTF-8?B?0Y8g0LzQvtC00YPQu9GMIG5neF9odHRwX2ltYWdlX2ZpbHRlcl9tb2R1bGU=?=
In-Reply-To: <E2807AFC-822E-4164-98AD-D4D1C16EBEC2@yandex.ru>
References: <E2807AFC-822E-4164-98AD-D4D1C16EBEC2@yandex.ru>
Message-ID: <20130918141048.GJ57081@mdounin.ru>

Hello!

On Wed, Sep 18, 2013 at 05:52:52PM +0400, chmind at yandex.ru wrote:

> Подскажите пожалуйста, возможно ли как-то сделать  crop вместе с 
> resize используя модуль ngx_http_image_filter_module ?  Спасибо. 

Параметр crop - это такой специальный случай resize, который 
по одной стороне делает resize, а по другой - обрезает лишнее.  
Так что crop, в каком-то смысле, всегда делается вместе с resize.

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

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


From chmind at yandex.ru  Wed Sep 18 14:23:04 2013
From: chmind at yandex.ru (chmind at yandex.ru)
Date: Wed, 18 Sep 2013 18:23:04 +0400
Subject: =?UTF-8?B?UmU6IGNyb3Ag0LLQvNC10YHRgtC1INGBIHJlc2l6ZSDQuNGB0L/QvtC70YzQt9GD?=
 =?UTF-8?B?0Y8g0LzQvtC00YPQu9GMIG5neF9odHRwX2ltYWdlX2ZpbHRlcl9tb2R1bGU=?=
In-Reply-To: <20130918141048.GJ57081@mdounin.ru>
References: <E2807AFC-822E-4164-98AD-D4D1C16EBEC2@yandex.ru>
 <20130918141048.GJ57081@mdounin.ru>
Message-ID: <F25A0530-C295-49B6-8FE7-D7BDD0AA4B94@yandex.ru>

Спасибо. В моем случае crop'а будет достаточно. 

On Sep 18, 2013, at 6:10 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
> 
> On Wed, Sep 18, 2013 at 05:52:52PM +0400, chmind at yandex.ru wrote:
> 
>> Подскажите пожалуйста, возможно ли как-то сделать  crop вместе с 
>> resize используя модуль ngx_http_image_filter_module ?  Спасибо. 
> 
> Параметр crop - это такой специальный случай resize, который 
> по одной стороне делает resize, а по другой - обрезает лишнее.  
> Так что crop, в каком-то смысле, всегда делается вместе с resize.
> 
> Если же хочется именно сначала сделать одну операцию, а потом 
> другую - то только используя дополнительное проксирование.  Хотя я 
> затрудняюсь представить, зачем это может быть надо.
> 
> -- 
> Maxim Dounin
> http://nginx.org/en/donation.html
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From nginx-forum at nginx.us  Wed Sep 18 22:59:50 2013
From: nginx-forum at nginx.us (Aleus Essentia)
Date: Wed, 18 Sep 2013 18:59:50 -0400
Subject: =?UTF-8?B?UmU6IG5neCBodHRwIGdldCBtb2R1bGUgbG9jIGNvbmYg0LLQvtC30LLRgNCw0Yk=?=
 =?UTF-8?B?0LDQtdGCIE5VTEw=?=
In-Reply-To: <201309181714.52512.vbart@nginx.com>
References: <201309181714.52512.vbart@nginx.com>
Message-ID: <76d71030005d6b65dc800dbe2fafdbb8.NginxMailingListRussian@forum.nginx.org>

Да... Опять я забыл восклицательный знак...
Спасибо за указание ошибки.

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


From fry.kun at gmail.com  Wed Sep 18 23:10:04 2013
From: fry.kun at gmail.com (Konstantin Svist)
Date: Wed, 18 Sep 2013 16:10:04 -0700
Subject: =?UTF-8?B?RmVkb3JhIDE5INC90LUg0YLRj9C90LXRgg==?=
Message-ID: <523A32CC.8000008@gmail.com>

Пытаюсь перейти с Fedora 14 (2.6.35.14-97.fc14.x86_64) на Fedora 19
(3.10.11-200.fc19.x86_64)

worker_processes  40;
events {
    worker_connections  8000;
    use  epoll;
}
http {
    proxy_headers_hash_max_size     8096;   # default was: 512
    proxy_headers_hash_bucket_size  128;    # default was: 64
    variables_hash_max_size         1024;
    variables_hash_bucket_size      128;
    default_type        application/octet-stream;
    sendfile            on;
    keepalive_timeout   65;
    charset             utf-8;
    resolver            127.0.0.1;      # necessary for dynamic upstream resolution
    limit_req_log_level warn;
    proxy_intercept_errors      on;
    server  {
        listen  80;
        location  =  /service_check_nginx  {  echo "nginx";  }
    }
}


Симптомы:

* ab -n1000000 -c1000 'http://localhost/service_check_nginx' 
(параллельно 4 раза, т.е. 4000 одновременных соединений)
говорит что некоторые запросы занимают >3сек

* netstat -s:
...
1269313 times the listen queue of a socket overflowed
1282868 SYNs to LISTEN sockets dropped
...

Растёт со скоростью примерно 2000/сек, иногда больше


* CPU загрузка не одинакова по workers:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                            
27671 nobody    20   0  418.6m 149.2m   1.1m S  51.1  0.1   0:00.77 nginx: worker process                                                                                              
27685 nobody    20   0  418.6m 149.2m   1.1m S  39.7  0.1   0:01.76 nginx: worker process                                                                                              
27661 nobody    20   0  418.6m 149.2m   1.1m S  22.7  0.1   0:01.63 nginx: worker process                                                                                              
27688 nobody    20   0  418.6m 149.2m   1.2m S  22.7  0.1   0:01.90 nginx: worker process                                                                                              
27697 nobody    20   0  418.6m 149.2m   1.1m S  17.0  0.1   0:00.95 nginx: worker process                                                                                              
27666 nobody    20   0  422.0m 152.3m   1.1m R   7.6  0.1   0:01.50 nginx: worker process                                                                                              
27701 nobody    20   0  419.3m 149.7m   1.1m S   1.9  0.1   0:00.01 nginx: worker process                                                                                              
27650 nobody    20   0  418.6m 149.9m   1.8m S   0.0  0.1   0:03.52 nginx: worker process                                                                                              
27658 nobody    20   0  418.6m 149.2m   1.1m S   0.0  0.1   0:01.30 nginx: worker process                                                                                              
27664 nobody    20   0  419.0m 149.5m   1.1m S   0.0  0.1   0:01.86 nginx: worker process                                                                                              
27669 nobody    20   0  418.6m 149.2m   1.1m S   0.0  0.1   0:00.35 nginx: worker process                                                                                              
27672 nobody    20   0  418.6m 149.2m   1.1m S   0.0  0.1   0:00.23 nginx: worker process   
                                                                                           

а на F14:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                   
30042 nobody    20   0 1224m 955m  17m R 41.2  0.4 523:24.45 nginx: worker process
30038 nobody    20   0 1224m 955m  17m S 39.4  0.4 522:24.30 nginx: worker process                                                                                                      
30047 nobody    20   0 1224m 955m  17m R 39.4  0.4 520:35.36 nginx: worker process
30053 nobody    20   0 1224m 955m  17m R 39.4  0.4 520:42.77 nginx: worker process
30027 nobody    20   0 1224m 955m  17m S 37.6  0.4 520:55.20 nginx: worker process                                                                                                      
30036 nobody    20   0 1224m 955m  18m R 37.6  0.4 525:26.07 nginx: worker process
30037 nobody    20   0 1224m 955m  17m S 37.6  0.4 523:59.09 nginx: worker process                                                                                                      
30041 nobody    20   0 1224m 955m  17m R 37.6  0.4 529:31.88 nginx: worker process
30049 nobody    20   0 1224m 954m  17m R 37.6  0.4 519:58.73 nginx: worker process


Кстати, если ставлю worker_connections 800 (worker_processes 40) и запускаю "ab -c1000 ..." -- то ab отваливается с ошибкой (на F19).

Где же дальше копать?


From mva at mva.name  Thu Sep 19 05:53:54 2013
From: mva at mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 19 Sep 2013 12:53:54 +0700
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <CAK90gp4sz8y__1upmsRc8BjAD780odO5EUAyTUyV3nPX+cB+nw@mail.gmail.com>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
 <5238856A.70907@kopeyko.ru> <20130917172641.GC57081@mdounin.ru>
 <CAK90gp4sz8y__1upmsRc8BjAD780odO5EUAyTUyV3nPX+cB+nw@mail.gmail.com>
Message-ID: <523A9172.8090503@mva.name>

Ну так взяли бы и написали/спонсировали написание модуля http_nginx_svn ;)


18.09.2013 02:41, Alex Domoradov пишет:
>> Когда реализую LOCK, будет работать git, а svn, боюсь, не будет никогда.
> жаль, очень не хватает, чтобы перейти на nginx.
> 
> 2013/9/17 Maxim Dounin <mdounin at mdounin.ru>:
>> Hello!
>>
>> On Tue, Sep 17, 2013 at 08:38:02PM +0400, Andrey Kopeyko wrote:
>>
>>> 17.09.2013 20:08, Maxim Dounin пишет:
>>>> Hello!
>>>>
>>>> On Tue, Sep 17, 2013 at 07:48:26PM +0400, Andrey Kopeyko wrote:
>>>>
>>>>> 17.09.2013 17:15, usows пишет:
>>>>>> Доброго времени суток
>>>>>
>>>>> Добрый вечер!
>>>>>
>>>>>> Столкнулся сейчас с проблемой. Есть некий сервер, к нему идет обращение
>>>>>> через reverse-proxy. До недавнего времени работа шла через прокси на
>>>>>> апаче, сейчас в качестве прокси используется nginx
>>>>>> Проблема в том, что после переезда перестал работать WebDav для клиентов
>>>>>> на Windows
>>>>>
>>>>> Вы, по-видимому, перед переездом невнимательно прочитали
>>>>> документацию. На
>>>>> http://nginx.org/ru/docs/http/ngx_http_dav_module.html прямо
>>>>> написано:
>>>>>
>>>>>   Модуль обрабатывает HTTP- и WebDAV-методы PUT, DELETE, MKCOL, COPY
>>>>> и MOVE.
>>>>>   ...
>>>>>   WebDAV-клиенты, которые требуют для работы дополнительных
>>>>>   WebDAV-методов, не будут работать с этим модулем.
>>>>>
>>>>>
>>>>> Так что проблемой nginx это считать нельзя; это фича.
>>>>>
>>>>> По-видимому, вам придётся откатывать взад.
>>>>
>>>> Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это
>>>> совершенно отдельная тема.  Должно работать.
>>>
>>> Хорошо коли так - мой личный опыт успешного проксирования webDAV
>>> ограничивается ровно "разрешёнными" методами GET\PUT\DELETE (других
>>> в моей задаче просто не требуется).
>>
>> Ну так nginx'у по большому счёту всё равно, что проксировать -
>> GET, PUT, или ещё что.
>>
>> Из того, что вспоминается - могут быть проблемы с "OPTIONS *",
>> если вдруг клиенты его пытаются использовать.
>>
>>>> Другой вопрос, что по "престал работать WebDav" многого не
>>>> надиагностируешь, а единственный телепат в нашей компании как раз
>>>> в отпуске.  ;)
>>>
>>> Это да.
>>>
>>> А не пора ли на сайте nginx.org вывесить "правила правильного
>>> задавания вопроса 'почему у меня не работает ХХХ?' в рассылку", с
>>> подробным примером?
>>>
>>> Было бы куда отправлять как взывающих к телепатам, так и по каплям
>>> выжимающих из себя информацию о своей системе. Там бы и расписали
>>> подробно "куда ваша информация может, а куда точно не может
>>> попасть", т.е. принятые внутренние стандарты обращения с данным
>>> пользователей\клиентов.
>>
>> Я в своё время попытался что-нибудь написать тут:
>>
>> http://wiki.nginx.org/Debugging
>>
>> Но оно больше расчитано на серьёзный анализ, а не проблемы класса
>> "не работает".  Впрочем, как по мне, то пусть уж пишут в рассылку,
>> лишь бы тикетов в trac'е не заводили.  ;)
>>
>> --
>> Maxim Dounin
>> http://nginx.org/en/donation.html
>>
>> _______________________________________________
>> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130919/6acebf79/attachment.bin>

From maillist at itcall.ru  Thu Sep 19 06:20:26 2013
From: maillist at itcall.ru (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JHQtdGF0YLQtdGA0LXQsg==?=)
Date: Thu, 19 Sep 2013 10:20:26 +0400
Subject: =?UTF-8?B?0L7RiNC40LHQutCwIDQwMCByZXF1ZXN0IGhlYWRlciBvciBjb29raWUgdG9vIGxh?=
 =?UTF-8?B?cmdl?=
Message-ID: <523A97A4.2080803@itcall.ru>

Добрый день!
Ошибку 400 Bad request (request header or cookie too large) выдает
nginx, стоящий на фронт-енде (на бэк-енде апач). Ошибка плавающая, может быть при посещениях разных ссылок с разных браузеров.
Жалуются клиенты региональные. В Москве ни у кого, в т.ч. у себя отловить не смог.
  Подскажите, куда копать. Можно ли как-то включить лог таких ошибок.
Спасибо.


From alex.hha at gmail.com  Thu Sep 19 06:50:35 2013
From: alex.hha at gmail.com (Alex Domoradov)
Date: Thu, 19 Sep 2013 09:50:35 +0300
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <523A9172.8090503@mva.name>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru>
 <5238856A.70907@kopeyko.ru> <20130917172641.GC57081@mdounin.ru>
 <CAK90gp4sz8y__1upmsRc8BjAD780odO5EUAyTUyV3nPX+cB+nw@mail.gmail.com>
 <523A9172.8090503@mva.name>
Message-ID: <CAK90gp756b1YVMM8QFoL=6N99u+86iUBVHYCpVZK0wMStQSk1w@mail.gmail.com>

А какой хоть порядок стоимости написания такого модуля?

2013/9/19 Vadim A. Misbakh-Soloviov <mva at mva.name>:
> Ну так взяли бы и написали/спонсировали написание модуля http_nginx_svn ;)
>
>
> 18.09.2013 02:41, Alex Domoradov пишет:
>>> Когда реализую LOCK, будет работать git, а svn, боюсь, не будет никогда.
>> жаль, очень не хватает, чтобы перейти на nginx.
>>
>> 2013/9/17 Maxim Dounin <mdounin at mdounin.ru>:
>>> Hello!
>>>
>>> On Tue, Sep 17, 2013 at 08:38:02PM +0400, Andrey Kopeyko wrote:
>>>
>>>> 17.09.2013 20:08, Maxim Dounin пишет:
>>>>> Hello!
>>>>>
>>>>> On Tue, Sep 17, 2013 at 07:48:26PM +0400, Andrey Kopeyko wrote:
>>>>>
>>>>>> 17.09.2013 17:15, usows пишет:
>>>>>>> Доброго времени суток
>>>>>>
>>>>>> Добрый вечер!
>>>>>>
>>>>>>> Столкнулся сейчас с проблемой. Есть некий сервер, к нему идет обращение
>>>>>>> через reverse-proxy. До недавнего времени работа шла через прокси на
>>>>>>> апаче, сейчас в качестве прокси используется nginx
>>>>>>> Проблема в том, что после переезда перестал работать WebDav для клиентов
>>>>>>> на Windows
>>>>>>
>>>>>> Вы, по-видимому, перед переездом невнимательно прочитали
>>>>>> документацию. На
>>>>>> http://nginx.org/ru/docs/http/ngx_http_dav_module.html прямо
>>>>>> написано:
>>>>>>
>>>>>>   Модуль обрабатывает HTTP- и WebDAV-методы PUT, DELETE, MKCOL, COPY
>>>>>> и MOVE.
>>>>>>   ...
>>>>>>   WebDAV-клиенты, которые требуют для работы дополнительных
>>>>>>   WebDAV-методов, не будут работать с этим модулем.
>>>>>>
>>>>>>
>>>>>> Так что проблемой nginx это считать нельзя; это фича.
>>>>>>
>>>>>> По-видимому, вам придётся откатывать взад.
>>>>>
>>>>> Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это
>>>>> совершенно отдельная тема.  Должно работать.
>>>>
>>>> Хорошо коли так - мой личный опыт успешного проксирования webDAV
>>>> ограничивается ровно "разрешёнными" методами GET\PUT\DELETE (других
>>>> в моей задаче просто не требуется).
>>>
>>> Ну так nginx'у по большому счёту всё равно, что проксировать -
>>> GET, PUT, или ещё что.
>>>
>>> Из того, что вспоминается - могут быть проблемы с "OPTIONS *",
>>> если вдруг клиенты его пытаются использовать.
>>>
>>>>> Другой вопрос, что по "престал работать WebDav" многого не
>>>>> надиагностируешь, а единственный телепат в нашей компании как раз
>>>>> в отпуске.  ;)
>>>>
>>>> Это да.
>>>>
>>>> А не пора ли на сайте nginx.org вывесить "правила правильного
>>>> задавания вопроса 'почему у меня не работает ХХХ?' в рассылку", с
>>>> подробным примером?
>>>>
>>>> Было бы куда отправлять как взывающих к телепатам, так и по каплям
>>>> выжимающих из себя информацию о своей системе. Там бы и расписали
>>>> подробно "куда ваша информация может, а куда точно не может
>>>> попасть", т.е. принятые внутренние стандарты обращения с данным
>>>> пользователей\клиентов.
>>>
>>> Я в своё время попытался что-нибудь написать тут:
>>>
>>> http://wiki.nginx.org/Debugging
>>>
>>> Но оно больше расчитано на серьёзный анализ, а не проблемы класса
>>> "не работает".  Впрочем, как по мне, то пусть уж пишут в рассылку,
>>> лишь бы тикетов в trac'е не заводили.  ;)
>>>
>>> --
>>> Maxim Dounin
>>> http://nginx.org/en/donation.html
>>>
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru at nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From vladget at gmail.com  Thu Sep 19 09:10:23 2013
From: vladget at gmail.com (Vladimir Getmanshchuk)
Date: Thu, 19 Sep 2013 12:10:23 +0300
Subject: =?UTF-8?B?UmU6INC+0YjQuNCx0LrQsCA0MDAgcmVxdWVzdCBoZWFkZXIgb3IgY29va2llIHRv?=
 =?UTF-8?B?byBsYXJnZQ==?=
In-Reply-To: <523A97A4.2080803@itcall.ru>
References: <523A97A4.2080803@itcall.ru>
Message-ID: <CAMxcU5+9YwgbX+RRvD8jntPqxr3niC2=pvK13=E8Pjt7gavE+A@mail.gmail.com>

Добрый день!

Все просто: http://wiki.nginx.org/HttpCoreModule#large_client_header_buffers


2013/9/19 Дмитрий Бехтерев <maillist at itcall.ru>

> Добрый день!
> Ошибку 400 Bad request (request header or cookie too large) выдает
> nginx, стоящий на фронт-енде (на бэк-енде апач). Ошибка плавающая, может
> быть при посещениях разных ссылок с разных браузеров.
> Жалуются клиенты региональные. В Москве ни у кого, в т.ч. у себя отловить
> не смог.
>  Подскажите, куда копать. Можно ли как-то включить лог таких ошибок.
> Спасибо.
>
> ______________________________**_________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/**mailman/listinfo/nginx-ru<http://mailman.nginx.org/mailman/listinfo/nginx-ru>




-- 
Yours sincerely,
Vladimir Getmanshchuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130919/2f262bb9/attachment-0001.html>

From vbart at nginx.com  Thu Sep 19 09:51:27 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Thu, 19 Sep 2013 13:51:27 +0400
Subject: =?UTF-8?B?UmU6ICDQvtGI0LjQsdC60LAgNDAwIHJlcXVlc3QgaGVhZGVyIG9yIGNvb2tpZSB0?=
 =?UTF-8?B?b28gbGFyZ2U=?=
In-Reply-To: <523A97A4.2080803@itcall.ru>
References: <523A97A4.2080803@itcall.ru>
Message-ID: <201309191351.28063.vbart@nginx.com>

On Thursday 19 September 2013 10:20:26 Дмитрий Бехтерев wrote:
> Добрый день!
> Ошибку 400 Bad request (request header or cookie too large) выдает
> nginx, стоящий на фронт-енде (на бэк-енде апач). Ошибка плавающая, может
> быть при посещениях разных ссылок с разных браузеров. Жалуются клиенты
> региональные. В Москве ни у кого, в т.ч. у себя отловить не смог.
> Подскажите, куда копать. Можно ли как-то включить лог таких ошибок.
> Спасибо.
> 
[..]

Если ошибку в самом деле выдал nginx, а не кто-то другой, то в error_log
будет об этом запись на уровне info.

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

--
Валентин Бартенев
http://nginx.org/en/donation.html

From mdounin at mdounin.ru  Thu Sep 19 10:58:43 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 19 Sep 2013 14:58:43 +0400
Subject: =?UTF-8?B?UmU6IEZlZG9yYSAxOSDQvdC1INGC0Y/QvdC10YI=?=
In-Reply-To: <523A32CC.8000008@gmail.com>
References: <523A32CC.8000008@gmail.com>
Message-ID: <20130919105843.GQ57081@mdounin.ru>

Hello!

On Wed, Sep 18, 2013 at 04:10:04PM -0700, Konstantin Svist wrote:

> Пытаюсь перейти с Fedora 14 (2.6.35.14-97.fc14.x86_64) на Fedora 19
> (3.10.11-200.fc19.x86_64)
> 
> worker_processes  40;
> events {
>     worker_connections  8000;

[...]

> Симптомы:
> 
> * ab -n1000000 -c1000 'http://localhost/service_check_nginx' 
> (параллельно 4 раза, т.е. 4000 одновременных соединений)
> говорит что некоторые запросы занимают >3сек
> 
> * netstat -s:
> ...
> 1269313 times the listen queue of a socket overflowed
> 1282868 SYNs to LISTEN sockets dropped
> ...
> 
> Растёт со скоростью примерно 2000/сек, иногда больше

Listen queue при этом какого размера?

> * CPU загрузка не одинакова по workers:
> 
>   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
> 27671 nobody    20   0  418.6m 149.2m   1.1m S  51.1  0.1   0:00.77 nginx: worker process
> 27685 nobody    20   0  418.6m 149.2m   1.1m S  39.7  0.1   0:01.76 nginx: worker process
> 27661 nobody    20   0  418.6m 149.2m   1.1m S  22.7  0.1   0:01.63 nginx: worker process
> 27688 nobody    20   0  418.6m 149.2m   1.2m S  22.7  0.1   0:01.90 nginx: worker process
> 27697 nobody    20   0  418.6m 149.2m   1.1m S  17.0  0.1   0:00.95 nginx: worker process
> 27666 nobody    20   0  422.0m 152.3m   1.1m R   7.6  0.1   0:01.50 nginx: worker process
> 27701 nobody    20   0  419.3m 149.7m   1.1m S   1.9  0.1   0:00.01 nginx: worker process
> 27650 nobody    20   0  418.6m 149.9m   1.8m S   0.0  0.1   0:03.52 nginx: worker process
> 27658 nobody    20   0  418.6m 149.2m   1.1m S   0.0  0.1   0:01.30 nginx: worker process
> 27664 nobody    20   0  419.0m 149.5m   1.1m S   0.0  0.1   0:01.86 nginx: worker process
> 27669 nobody    20   0  418.6m 149.2m   1.1m S   0.0  0.1   0:00.35 nginx: worker process
> 27672 nobody    20   0  418.6m 149.2m   1.1m S   0.0  0.1   0:00.23 nginx: worker process
>
>
> а на F14:
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 30042 nobody    20   0 1224m 955m  17m R 41.2  0.4 523:24.45 nginx: worker process
> 30038 nobody    20   0 1224m 955m  17m S 39.4  0.4 522:24.30 nginx: worker process
> 30047 nobody    20   0 1224m 955m  17m R 39.4  0.4 520:35.36 nginx: worker process
> 30053 nobody    20   0 1224m 955m  17m R 39.4  0.4 520:42.77 nginx: worker process
> 30027 nobody    20   0 1224m 955m  17m S 37.6  0.4 520:55.20 nginx: worker process
> 30036 nobody    20   0 1224m 955m  18m R 37.6  0.4 525:26.07 nginx: worker process
> 30037 nobody    20   0 1224m 955m  17m S 37.6  0.4 523:59.09 nginx: worker process
> 30041 nobody    20   0 1224m 955m  17m R 37.6  0.4 529:31.88 nginx: worker process
> 30049 nobody    20   0 1224m 954m  17m R 37.6  0.4 519:58.73 nginx: worker process

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

При этом судя по цифрам F19, nginx - недогружен, так что listen 
queue overflows - возможно, являются просто следствие неверно 
выбранного для подобных тестов размера listen queue.  Могут, 
впрочем, быть и другие причины, но для начала имеет смысл 
исключить тривиальные.

> Кстати, если ставлю worker_connections 800 (worker_processes 40) 
> и запускаю "ab -c1000 ..." -- то ab отваливается с ошибкой (на 
> F19).
> 
> Где же дальше копать?

Копать в сторону лучшего понимания того, как используется accept() 
в nginx'е, что такое accept_mutex и зачем он нужен, а также всяких 
ручек про multi_accept и listen ... backlog=N в nginx'е и 
соответствующих ручек в ядре и утилит для их контроля 
(net.core.somaxconn и ss -nlt на линуксе).

Простейшая рекомендация для тестов с дешёвыми запросами - 
accept_mutex off, и поставить размер listen queue таким, чтобы 
туда помещалось столько запросов, сколько система должна 
обслуживать в секунду.  Но следует иметь ввиду, что это 
рекомендация именно для тестов, особенно в части accept_mutex off.

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


From usows at pomorsu.ru  Fri Sep 20 12:12:34 2013
From: usows at pomorsu.ru (usows)
Date: Fri, 20 Sep 2013 16:12:34 +0400
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
Message-ID: <6b674c7ad57ab48e61cde7d507f9d39e@mail.pomorsu.ru>

Проблему удалось локализовать. Имя ей - SNI. К сожалению, даже Win8 об 
этой тонкости ничего не знает

Всем спасибо за участие, извините за потраченное время

usows писал 17.09.2013 17:15:
> Доброго времени суток
>
> Столкнулся сейчас с проблемой. Есть некий сервер, к нему идет
> обращение через reverse-proxy. До недавнего времени работа шла через
> прокси на апаче, сейчас в качестве прокси используется nginx
> Проблема в том, что после переезда перестал работать WebDav для
> клиентов на Windows
>
> Конфиг апача:
>
>
> <VirtualHost *:80>
>   ServerName server.example.ru
>    Redirect permanent /        https://server.example.ru/
>    ErrorLog /var/log/apache2/server.example.ru/error.log
>    CustomLog /var/log/apache2/server.example.ru/access.log combined
> </VirtualHost>
>
> <VirtualHost *:443>
>   ServerName server.example.ru
>   ProxyRequests off
>
>   Alias /errors/ "/var/www/errors/"
>   <Proxy *>
>     Order deny,allow
>     Allow from all
>   </Proxy>
>
>   ProxyPass / http://server.example.local:8080/
>   ProxyPassReverse / http://server.example.local:8080/
>
>   ErrorLog /var/log/apache2/server.example.ru/error.log
>   CustomLog /var/log/apache2/server.example.ru/access.log combined
>
>   SSLEngine on
>   SSLOptions +StrictRequire
>   SSLProtocol -all +TLSv1 +SSLv3
>   SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM
>   SSLCertificateFile /etc/ssl/server/ssl.crt
>   SSLCertificateKeyFile /etc/ssl/server/ssl.key
>   SSLCertificateChainFile /etc/ssl/server/sub.class1.server.ca.pem
>   SSLCACertificateFile /etc/ssl/server/ca.pem
>   SSLVerifyClient none
>   SSLProxyEngine off
>   SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
> downgrade-1.0 force-response-1.0
> </VirtualHost>
>
> Конфиг nginx:
>
> server {
>         listen 80;
>         server_name server.example.ru;
>
>         rewrite     ^ https://server.example.ru$request_uri? 
> permanent;
>         access_log /var/log/nginx/server/access.log;
>         error_log /var/log/nginx/server/error.log;
> }
>
> server {
>         listen 443 ssl;
>         server_name server.example.ru
>         ssl                     on;
>
>         ssl_certificate         /etc/nginx/ssl/server.crt;
>         ssl_certificate_key     /etc/nginx/ssl/server.key;
>
>         access_log /var/log/nginx/server/access.log;
>         error_log /var/log/nginx/server/error.log;
>
>         location / {
>                 proxy_set_header Host $host;
>                 proxy_set_header X-Real-IP $remote_addr;
>                 proxy_set_header X-Forwarded-Proto https;
>                 proxy_set_header X-Forward-For 
> $proxy_add_x_forwarded_for;
>
>                 chunked_transfer_encoding off;
>
>                 proxy_redirect off;
>                 proxy_pass http://server.example.local:8080/;
>         }
> }
>
>
> Заранее спасибо за помощь
>
> Сергей
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Ведущий программист отдела СА УИТ САФУ
Усов С.А.

s.usov at agtu.ru

(8182)21-61-00p1797


From alex.hha at gmail.com  Fri Sep 20 12:17:04 2013
From: alex.hha at gmail.com (Alex Domoradov)
Date: Fri, 20 Sep 2013 15:17:04 +0300
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <6b674c7ad57ab48e61cde7d507f9d39e@mail.pomorsu.ru>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <6b674c7ad57ab48e61cde7d507f9d39e@mail.pomorsu.ru>
Message-ID: <CAK90gp5NCg8cuk0rRDvKX3spEQbFb+_y03=K43HnW6fDXn0EuQ@mail.gmail.com>

В каком смысле не знает? SNI начиная с Win7 без проблем работает

2013/9/20 usows <usows at pomorsu.ru>:
> Проблему удалось локализовать. Имя ей - SNI. К сожалению, даже Win8 об этой
> тонкости ничего не знает
>
> Всем спасибо за участие, извините за потраченное время
>
> usows писал 17.09.2013 17:15:
>
>> Доброго времени суток
>>
>> Столкнулся сейчас с проблемой. Есть некий сервер, к нему идет
>> обращение через reverse-proxy. До недавнего времени работа шла через
>> прокси на апаче, сейчас в качестве прокси используется nginx
>> Проблема в том, что после переезда перестал работать WebDav для
>> клиентов на Windows
>>
>> Конфиг апача:
>>
>>
>> <VirtualHost *:80>
>>   ServerName server.example.ru
>>    Redirect permanent /        https://server.example.ru/
>>    ErrorLog /var/log/apache2/server.example.ru/error.log
>>    CustomLog /var/log/apache2/server.example.ru/access.log combined
>> </VirtualHost>
>>
>> <VirtualHost *:443>
>>   ServerName server.example.ru
>>   ProxyRequests off
>>
>>   Alias /errors/ "/var/www/errors/"
>>   <Proxy *>
>>     Order deny,allow
>>     Allow from all
>>   </Proxy>
>>
>>   ProxyPass / http://server.example.local:8080/
>>   ProxyPassReverse / http://server.example.local:8080/
>>
>>   ErrorLog /var/log/apache2/server.example.ru/error.log
>>   CustomLog /var/log/apache2/server.example.ru/access.log combined
>>
>>   SSLEngine on
>>   SSLOptions +StrictRequire
>>   SSLProtocol -all +TLSv1 +SSLv3
>>   SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM
>>   SSLCertificateFile /etc/ssl/server/ssl.crt
>>   SSLCertificateKeyFile /etc/ssl/server/ssl.key
>>   SSLCertificateChainFile /etc/ssl/server/sub.class1.server.ca.pem
>>   SSLCACertificateFile /etc/ssl/server/ca.pem
>>   SSLVerifyClient none
>>   SSLProxyEngine off
>>   SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
>> downgrade-1.0 force-response-1.0
>> </VirtualHost>
>>
>> Конфиг nginx:
>>
>> server {
>>         listen 80;
>>         server_name server.example.ru;
>>
>>         rewrite     ^ https://server.example.ru$request_uri? permanent;
>>         access_log /var/log/nginx/server/access.log;
>>         error_log /var/log/nginx/server/error.log;
>> }
>>
>> server {
>>         listen 443 ssl;
>>         server_name server.example.ru
>>         ssl                     on;
>>
>>         ssl_certificate         /etc/nginx/ssl/server.crt;
>>         ssl_certificate_key     /etc/nginx/ssl/server.key;
>>
>>         access_log /var/log/nginx/server/access.log;
>>         error_log /var/log/nginx/server/error.log;
>>
>>         location / {
>>                 proxy_set_header Host $host;
>>                 proxy_set_header X-Real-IP $remote_addr;
>>                 proxy_set_header X-Forwarded-Proto https;
>>                 proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
>>
>>                 chunked_transfer_encoding off;
>>
>>                 proxy_redirect off;
>>                 proxy_pass http://server.example.local:8080/;
>>         }
>> }
>>
>>
>> Заранее спасибо за помощь
>>
>> Сергей
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> --
> Ведущий программист отдела СА УИТ САФУ
> Усов С.А.
>
> s.usov at agtu.ru
>
> (8182)21-61-00p1797
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From usows at pomorsu.ru  Fri Sep 20 12:21:53 2013
From: usows at pomorsu.ru (usows)
Date: Fri, 20 Sep 2013 16:21:53 +0400
Subject: =?UTF-8?Q?Re=3A_Nginx_reverse_proxy_=D0=B8_WebDav?=
In-Reply-To: <CAK90gp5NCg8cuk0rRDvKX3spEQbFb+_y03=K43HnW6fDXn0EuQ@mail.gmail.com>
References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru>
 <6b674c7ad57ab48e61cde7d507f9d39e@mail.pomorsu.ru>
 <CAK90gp5NCg8cuk0rRDvKX3spEQbFb+_y03=K43HnW6fDXn0EuQ@mail.gmail.com>
Message-ID: <e6f5f37d85374184fab9070c45b15397@mail.pomorsu.ru>

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

Alex Domoradov писал 20.09.2013 16:17:
> В каком смысле не знает? SNI начиная с Win7 без проблем работает
>
> 2013/9/20 usows <usows at pomorsu.ru>:
>> Проблему удалось локализовать. Имя ей - SNI. К сожалению, даже Win8 
>> об этой
>> тонкости ничего не знает
>>
>> Всем спасибо за участие, извините за потраченное время
>>


From vsjcfm at gmail.com  Fri Sep 20 14:27:41 2013
From: vsjcfm at gmail.com (Anton Sayetsky)
Date: Fri, 20 Sep 2013 17:27:41 +0300
Subject: directio_alignment
Message-ID: <CAFG2KCJPPiWdOB=HrL6w50QohPMWp_iMD8ny+SFXtDc3_NKXpA@mail.gmail.com>

Приветствую,
Имеет ли смысл данный параметр ставить в 4к при ФС с соответствующими
блоками на SSD?
Заранее благодарю.

From igor at sysoev.ru  Fri Sep 20 14:38:26 2013
From: igor at sysoev.ru (Igor Sysoev)
Date: Fri, 20 Sep 2013 18:38:26 +0400
Subject: directio_alignment
In-Reply-To: <CAFG2KCJPPiWdOB=HrL6w50QohPMWp_iMD8ny+SFXtDc3_NKXpA@mail.gmail.com>
References: <CAFG2KCJPPiWdOB=HrL6w50QohPMWp_iMD8ny+SFXtDc3_NKXpA@mail.gmail.com>
Message-ID: <22F89311-DAA8-475E-9A77-5887BFEA4DB1@sysoev.ru>

On Sep 20, 2013, at 18:27 , Anton Sayetsky wrote:

> Приветствую,
> Имеет ли смысл данный параметр ставить в 4к при ФС с соответствующими
> блоками на SSD?

Нет.


-- 
Igor Sysoev
http://nginx.com

From vsjcfm at gmail.com  Fri Sep 20 14:43:03 2013
From: vsjcfm at gmail.com (Anton Sayetsky)
Date: Fri, 20 Sep 2013 17:43:03 +0300
Subject: directio_alignment
In-Reply-To: <22F89311-DAA8-475E-9A77-5887BFEA4DB1@sysoev.ru>
References: <CAFG2KCJPPiWdOB=HrL6w50QohPMWp_iMD8ny+SFXtDc3_NKXpA@mail.gmail.com>
 <22F89311-DAA8-475E-9A77-5887BFEA4DB1@sysoev.ru>
Message-ID: <CAFG2KCKWFGHbxj7Mm=L_G37Zx7YukTf-9zLh2cKAk0PQ3EALbw@mail.gmail.com>

20 сентября 2013 г., 17:38 пользователь Igor Sysoev <igor at sysoev.ru> написал:
> Нет.
Тогда можно ли краткий экскурс на тему того, почему стоит это делать
только для XFS?

From igor at sysoev.ru  Fri Sep 20 15:05:26 2013
From: igor at sysoev.ru (Igor Sysoev)
Date: Fri, 20 Sep 2013 19:05:26 +0400
Subject: directio_alignment
In-Reply-To: <CAFG2KCKWFGHbxj7Mm=L_G37Zx7YukTf-9zLh2cKAk0PQ3EALbw@mail.gmail.com>
References: <CAFG2KCJPPiWdOB=HrL6w50QohPMWp_iMD8ny+SFXtDc3_NKXpA@mail.gmail.com>
 <22F89311-DAA8-475E-9A77-5887BFEA4DB1@sysoev.ru>
 <CAFG2KCKWFGHbxj7Mm=L_G37Zx7YukTf-9zLh2cKAk0PQ3EALbw@mail.gmail.com>
Message-ID: <E6E985D6-F3C6-465E-9B0A-FBBE9CB77A1B@sysoev.ru>

On Sep 20, 2013, at 18:43 , Anton Sayetsky wrote:

> 20 сентября 2013 г., 17:38 пользователь Igor Sysoev <igor at sysoev.ru> написал:
>> Нет.
> Тогда можно ли краткий экскурс на тему того, почему стоит это делать
> только для XFS?

На XFS это не оптимизация, а вынужденная мера.
Потому что на XFS размеры блоков не 512 байт, а 4096, и при выровненным на
512 чтении байт возвращается ошибка.


-- 
Igor Sysoev
http://nginx.com

From a.vasilishin at kpi.ua  Fri Sep 20 16:50:06 2013
From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=)
Date: Fri, 20 Sep 2013 19:50:06 +0300
Subject: directio_alignment
In-Reply-To: <E6E985D6-F3C6-465E-9B0A-FBBE9CB77A1B@sysoev.ru>
References: <CAFG2KCJPPiWdOB=HrL6w50QohPMWp_iMD8ny+SFXtDc3_NKXpA@mail.gmail.com>
 <22F89311-DAA8-475E-9A77-5887BFEA4DB1@sysoev.ru>
 <CAFG2KCKWFGHbxj7Mm=L_G37Zx7YukTf-9zLh2cKAk0PQ3EALbw@mail.gmail.com>
 <E6E985D6-F3C6-465E-9B0A-FBBE9CB77A1B@sysoev.ru>
Message-ID: <523C7CBE.7090104@kpi.ua>

20.09.2013 18:05, Igor Sysoev пишет:
> On Sep 20, 2013, at 18:43 , Anton Sayetsky wrote:
>
>> 20 сентября 2013 г., 17:38 пользователь Igor Sysoev <igor at sysoev.ru> написал:
>>> Нет.
>> Тогда можно ли краткий экскурс на тему того, почему стоит это делать
>> только для XFS?
>
> На XFS это не оптимизация, а вынужденная мера.
> Потому что на XFS размеры блоков не 512 байт, а 4096, и при выровненным на
> 512 чтении байт возвращается ошибка.
>
>

а про bigaaloc 1m в ext4 что скажете, имеет ли смысл делать выравнивание 
в 1м?


From vbart at nginx.com  Fri Sep 20 18:56:58 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Fri, 20 Sep 2013 22:56:58 +0400
Subject: directio_alignment
In-Reply-To: <523C7CBE.7090104@kpi.ua>
References: <CAFG2KCJPPiWdOB=HrL6w50QohPMWp_iMD8ny+SFXtDc3_NKXpA@mail.gmail.com>
 <E6E985D6-F3C6-465E-9B0A-FBBE9CB77A1B@sysoev.ru> <523C7CBE.7090104@kpi.ua>
Message-ID: <201309202256.58552.vbart@nginx.com>

On Friday 20 September 2013 20:50:06 Андрей Василишин wrote:
> 20.09.2013 18:05, Igor Sysoev пишет:
> > On Sep 20, 2013, at 18:43 , Anton Sayetsky wrote:
> >> 20 сентября 2013 г., 17:38 пользователь Igor Sysoev <igor at sysoev.ru> 
написал:
> >>> Нет.
> >> 
> >> Тогда можно ли краткий экскурс на тему того, почему стоит это делать
> >> только для XFS?
> > 
> > На XFS это не оптимизация, а вынужденная мера.
> > Потому что на XFS размеры блоков не 512 байт, а 4096, и при выровненным
> > на 512 чтении байт возвращается ошибка.
> 
> а про bigaaloc 1m в ext4 что скажете, имеет ли смысл делать выравнивание
> в 1м?
> 

Оно при этом ломается?  Ещё раз, это *не* оптимизация, а вынужденная мера,
чтобы nginx при включении directio мог отдавать файлы, а не сыпал 500-ые ошибки
с записью в лог:

  [crit] pread() failed (22: Invalid argument) while sending response to client

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

From a.vasilishin at kpi.ua  Fri Sep 20 19:03:59 2013
From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=)
Date: Fri, 20 Sep 2013 22:03:59 +0300
Subject: directio_alignment
In-Reply-To: <201309202256.58552.vbart@nginx.com>
References: <CAFG2KCJPPiWdOB=HrL6w50QohPMWp_iMD8ny+SFXtDc3_NKXpA@mail.gmail.com>
 <E6E985D6-F3C6-465E-9B0A-FBBE9CB77A1B@sysoev.ru> <523C7CBE.7090104@kpi.ua>
 <201309202256.58552.vbart@nginx.com>
Message-ID: <523C9C1F.6030404@kpi.ua>

20.09.2013 21:56, Валентин Бартенев пишет:

> Оно при этом ломается?  Ещё раз, это *не* оптимизация, а вынужденная мера,
> чтобы nginx при включении directio мог отдавать файлы, а не сыпал 500-ые ошибки
> с записью в лог:
>
>    [crit] pread() failed (22: Invalid argument) while sending response to client
>

нет не ломается, pread() ошибки нет при таком конфиге:

                 output_buffers  1 2m;
                 aio on;
                 directio  1m;
                 directio_alignment 1m;
                 limit_rate   80k;
                 limit_rate_after 10m;



From vbart at nginx.com  Fri Sep 20 19:15:14 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Fri, 20 Sep 2013 23:15:14 +0400
Subject: directio_alignment
In-Reply-To: <523C9C1F.6030404@kpi.ua>
References: <CAFG2KCJPPiWdOB=HrL6w50QohPMWp_iMD8ny+SFXtDc3_NKXpA@mail.gmail.com>
 <201309202256.58552.vbart@nginx.com> <523C9C1F.6030404@kpi.ua>
Message-ID: <201309202315.14638.vbart@nginx.com>

On Friday 20 September 2013 23:03:59 Андрей Василишин wrote:
> 20.09.2013 21:56, Валентин Бартенев пишет:
> > Оно при этом ломается?  Ещё раз, это *не* оптимизация, а вынужденная
> > мера, чтобы nginx при включении directio мог отдавать файлы, а не сыпал
> > 500-ые ошибки
> > 
> > с записью в лог:
> >    [crit] pread() failed (22: Invalid argument) while sending response to
> >    client
> 
> нет не ломается, pread() ошибки нет при таком конфиге:
> 
>                  output_buffers  1 2m;
>                  aio on;
>                  directio  1m;
>                  directio_alignment 1m;
>                  limit_rate   80k;
>                  limit_rate_after 10m;
> 

Вопрос был о том, ломается ли при стандартном directio_alignment 512?

Я поясню два момента:

 1. Невыровненный кусок всё равно будет прочитан.
 2. Это будет сделано отдельным системным вызовом без O_DIRECT.

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

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

From nginx-forum at nginx.us  Sat Sep 21 17:40:04 2013
From: nginx-forum at nginx.us (nickolay)
Date: Sat, 21 Sep 2013 13:40:04 -0400
Subject: =?UTF-8?B?0KLQtdC/0LXRgNGMINC90LXQu9GM0LfRjyDQstGL0YHRgtCw0LLQu9GP0YLRjCA=?=
 =?UTF-8?B?0YLQuNC/INC60L7QvdGC0LXQvdGC0LAh?=
Message-ID: <5147393756b56da7913ba3ac42e60669.NginxMailingListRussian@forum.nginx.org>

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

Обновили nginx до версии 1.5.5 и perl-скрипты перестали отдавать файлы, в
лог выпадает следующее:
"header already sent while reading response header from upstream"

Нашёл, что всему виной вот этот коммит:
http://hg.nginx.org/nginx/rev/03ff14058272
Он проверяет, если заголовок уже отправлялся, то это ошибка.

Но как быть? Нам перед тем как сделать внутренний редирект обязательно нужно
установить MIME-тип, так как редирект будет на файл без расширения, и если
не установить явно тип контента, то nginx сам установит
application/octet-stream.

Устанавливаем из скрипта тип контента таким образом:
$r->send_http_header("$mime")

Если убрать эту строку, то всё работает, но отдаётся с
application/octet-stream.

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


From mdounin at mdounin.ru  Sat Sep 21 23:12:33 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sun, 22 Sep 2013 03:12:33 +0400
Subject: =?UTF-8?B?UmU6INCi0LXQv9C10YDRjCDQvdC10LvRjNC30Y8g0LLRi9GB0YLQsNCy0LvRj9GC?=
 =?UTF-8?B?0Ywg0YLQuNC/INC60L7QvdGC0LXQvdGC0LAh?=
In-Reply-To: <5147393756b56da7913ba3ac42e60669.NginxMailingListRussian@forum.nginx.org>
References: <5147393756b56da7913ba3ac42e60669.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130921231233.GA2170@mdounin.ru>

Hello!

On Sat, Sep 21, 2013 at 01:40:04PM -0400, nickolay wrote:

> Здравствуйте,
> 
> Обновили nginx до версии 1.5.5 и perl-скрипты перестали отдавать файлы, в
> лог выпадает следующее:
> "header already sent while reading response header from upstream"
> 
> Нашёл, что всему виной вот этот коммит:
> http://hg.nginx.org/nginx/rev/03ff14058272
> Он проверяет, если заголовок уже отправлялся, то это ошибка.

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

> Но как быть? Нам перед тем как сделать внутренний редирект обязательно нужно
> установить MIME-тип, так как редирект будет на файл без расширения, и если
> не установить явно тип контента, то nginx сам установит
> application/octet-stream.
> 
> Устанавливаем из скрипта тип контента таким образом:
> $r->send_http_header("$mime")
> 
> Если убрать эту строку, то всё работает, но отдаётся с
> application/octet-stream.

Простейшее решение - отдавать файл perl'ом же, для этого есть 
специальный метод $r->sendfile().

http://nginx.org/ru/docs/http/ngx_http_perl_module.html#methods

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


From nginx-forum at nginx.us  Sat Sep 21 23:36:55 2013
From: nginx-forum at nginx.us (nickolay)
Date: Sat, 21 Sep 2013 19:36:55 -0400
Subject: =?UTF-8?B?UmU6INCi0LXQv9C10YDRjCDQvdC10LvRjNC30Y8g0LLRi9GB0YLQsNCy0LvRj9GC?=
 =?UTF-8?B?0Ywg0YLQuNC/INC60L7QvdGC0LXQvdGC0LAh?=
In-Reply-To: <20130921231233.GA2170@mdounin.ru>
References: <20130921231233.GA2170@mdounin.ru>
Message-ID: <3d411a22591997c56e0a30601961ed84.NginxMailingListRussian@forum.nginx.org>

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

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


From nginx-forum at nginx.us  Sun Sep 22 15:27:16 2013
From: nginx-forum at nginx.us (aaaa5)
Date: Sun, 22 Sep 2013 11:27:16 -0400
Subject: nginx proxy vs memcached data
Message-ID: <811ce9343e7d957db911c4289f808c20.NginxMailingListRussian@forum.nginx.org>

Подскажите пожалуйста, никак не могу сообразить, как сделать так, чтобы
данные возвращаемые memcached-сервером, использовать в качестве uri для
дальнейшего проксирования с помощью nginx? Можно ли их поместить в
какую-либо переменную, а потом сделать proxy_pass $var; ? Или как-то
иначе....

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


From mdounin at mdounin.ru  Sun Sep 22 18:20:53 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sun, 22 Sep 2013 22:20:53 +0400
Subject: =?UTF-8?B?UmU6INCi0LXQv9C10YDRjCDQvdC10LvRjNC30Y8g0LLRi9GB0YLQsNCy0LvRj9GC?=
 =?UTF-8?B?0Ywg0YLQuNC/INC60L7QvdGC0LXQvdGC0LAh?=
In-Reply-To: <3d411a22591997c56e0a30601961ed84.NginxMailingListRussian@forum.nginx.org>
References: <20130921231233.GA2170@mdounin.ru>
 <3d411a22591997c56e0a30601961ed84.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130922182053.GB2170@mdounin.ru>

Hello!

On Sat, Sep 21, 2013 at 07:36:55PM -0400, nickolay wrote:

> Дело в том, что мы делали внутренний редирект на специальный локейшен, в
> котором был прописал `post_action`, который отрабатывал после того, как файл
> был отдан пользователю. Не подскажите, чем его можно заменить?

Лучше всего - заменить post_action на постобработку логов.  Но 
если очень хочется таки post_action, то просто добавить его в тот 
location, где работает perl.

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


From admin at xaker1.ru  Sun Sep 22 18:47:26 2013
From: admin at xaker1.ru (=?KOI8-R?B?4c7E0sXKIPTJ3cXOy88=?=)
Date: Sun, 22 Sep 2013 18:47:26 +0000
Subject: =?UTF-8?B?RndkOiDQkNCy0YLQvtGA0LjQt9Cw0YbQuNGPINGBINC/0L7QvNC+0YnRjNGOIFNT?=
 =?UTF-8?B?TA==?=
In-Reply-To: <CAK6srhAyZsPWEy6=+QBW9PZAWo2DdgQez2+Td05D13OS_BvzBA@mail.gmail.com>
References: <CAK6srhAyZsPWEy6=+QBW9PZAWo2DdgQez2+Td05D13OS_BvzBA@mail.gmail.com>
Message-ID: <CAK6srhDt05uYg0PUw1rg0g_CbTDeubH4=wq4fXPtXSRT6i-8-Q@mail.gmail.com>

Здравствуйте.
Пытаюсь реализовать авторизацию с помощью SSL сертификатов, но получаю
ошибку:
400 Bad Request
The SSL certificate error

Схема подписи:
CA -> Промежуточный CA -> клиентский сертификат.
Насколько я понял, проблема именно в том, что клиентский сертификат
подписан промежуточным центром сертификации, а не корневым (при подписи
корневым все было нормальноe).

server {
  listen 456;
  ssl on;
  ssl_certificate /var/www/client/data/www/client.ru/ssl/ca.crt;
  ssl_certificate_key /var/www/client/data/www/client.ru/ssl/ca.key;
  ssl_client_certificate /var/www/client/data/www/client.ru/ssl/pca.crt;
  ssl_verify_client optional;

...
}
-- 
С уважением,
Тищенко Андрей.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130922/687d0046/attachment.html>

From alex.hha at gmail.com  Sun Sep 22 18:49:37 2013
From: alex.hha at gmail.com (Alex Domoradov)
Date: Sun, 22 Sep 2013 21:49:37 +0300
Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8g0YEg0L/QvtC80L7RidGM0Y4gU1NM?=
In-Reply-To: <CAK6srhDt05uYg0PUw1rg0g_CbTDeubH4=wq4fXPtXSRT6i-8-Q@mail.gmail.com>
References: <CAK6srhAyZsPWEy6=+QBW9PZAWo2DdgQez2+Td05D13OS_BvzBA@mail.gmail.com>
 <CAK6srhDt05uYg0PUw1rg0g_CbTDeubH4=wq4fXPtXSRT6i-8-Q@mail.gmail.com>
Message-ID: <CAK90gp5X=-5uoS13F=Uf0xhQPd4nUt3uen+M7atSLCu01sRb+A@mail.gmail.com>

Вроде можно поместить CA и Промежуточные CA в один файл и указать его
в ssl_certificate

2013/9/22 Андрей Тищенко <admin at xaker1.ru>:
> Здравствуйте.
> Пытаюсь реализовать авторизацию с помощью SSL сертификатов, но получаю
> ошибку:
> 400 Bad Request
> The SSL certificate error
>
> Схема подписи:
> CA -> Промежуточный CA -> клиентский сертификат.
> Насколько я понял, проблема именно в том, что клиентский сертификат подписан
> промежуточным центром сертификации, а не корневым (при подписи корневым все
> было нормальноe).
>
> server {
>   listen 456;
>   ssl on;
>   ssl_certificate /var/www/client/data/www/client.ru/ssl/ca.crt;
>   ssl_certificate_key /var/www/client/data/www/client.ru/ssl/ca.key;
>   ssl_client_certificate /var/www/client/data/www/client.ru/ssl/pca.crt;
>   ssl_verify_client optional;
>
> ...
> }
> --
> С уважением,
> Тищенко Андрей.
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Mon Sep 23 06:49:24 2013
From: nginx-forum at nginx.us (Aleus Essentia)
Date: Mon, 23 Sep 2013 02:49:24 -0400
Subject: =?UTF-8?B?0JPQtdC90LXRgNCw0YbQuNGPINC+0YLQstC10YLQsCDQtNC70Y8g0LrQu9C40LU=?=
 =?UTF-8?B?0L3RgtCwINC4INCw0YHQuNC90YXRgNC+0L3QvdGL0LUg0YHQvtC60LXRgtGL?=
Message-ID: <eb4c29ba9779515af3caf34ee14b82e3.NginxMailingListRussian@forum.nginx.org>

Добрый день!

Мой модуль работает по следующему алгоритму:
1) Получает заголовок от клиента;
2) Записывает по специальному формату заголовок в сокет другого сервера;
3) Закрывает на запись сокет;
4) Читает ответ: заголовок и html-страницу из этого же сокета;
5) Отдаёт полученный заголовок и html клиенту.

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

Прочитал про регистрацию событий в этой статье:
http://green-shaman.livejournal.com/32600.html. Но там не написано, где я
должен вызывать функцию регистрации событий и где могу разместить код,
отрабатывающий после прочтения всего ответа из сокета?

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


From voron at amhost.net  Mon Sep 23 09:03:28 2013
From: voron at amhost.net (Alex Vorona)
Date: Mon, 23 Sep 2013 12:03:28 +0300
Subject: nginx proxy vs memcached data
In-Reply-To: <811ce9343e7d957db911c4289f808c20.NginxMailingListRussian@forum.nginx.org>
References: <811ce9343e7d957db911c4289f808c20.NginxMailingListRussian@forum.nginx.org>
Message-ID: <524003E0.2040205@amhost.net>

22.09.2013 18:27, aaaa5 wrote:
> Подскажите пожалуйста, никак не могу сообразить, как сделать так, чтобы
> данные возвращаемые memcached-сервером, использовать в качестве uri для
> дальнейшего проксирования с помощью nginx? Можно ли их поместить в
> какую-либо переменную, а потом сделать proxy_pass $var; ? Или как-то
> иначе....
http://www.grid.net.ru/nginx/eval.ru.html
если модуль ещё жив, правда


From nefer05 at gmail.com  Mon Sep 23 09:28:39 2013
From: nefer05 at gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=)
Date: Mon, 23 Sep 2013 13:28:39 +0400
Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0YDQuNC30LDRhtC40Y8g0YEg0L/QvtC80L7RidGM0Y4gU1NM?=
In-Reply-To: <CAK90gp5X=-5uoS13F=Uf0xhQPd4nUt3uen+M7atSLCu01sRb+A@mail.gmail.com>
References: <CAK6srhAyZsPWEy6=+QBW9PZAWo2DdgQez2+Td05D13OS_BvzBA@mail.gmail.com>
 <CAK6srhDt05uYg0PUw1rg0g_CbTDeubH4=wq4fXPtXSRT6i-8-Q@mail.gmail.com>
 <CAK90gp5X=-5uoS13F=Uf0xhQPd4nUt3uen+M7atSLCu01sRb+A@mail.gmail.com>
Message-ID: <CAE-UrwjdDuPzcd+1mnp_H+vKLZh=4+EfEPu21HxX97DeM6LhHA@mail.gmail.com>

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


2013/9/22 Alex Domoradov <alex.hha at gmail.com>

> Вроде можно поместить CA и Промежуточные CA в один файл и указать его
> в ssl_certificate
>
> 2013/9/22 Андрей Тищенко <admin at xaker1.ru>:
> > Здравствуйте.
> > Пытаюсь реализовать авторизацию с помощью SSL сертификатов, но получаю
> > ошибку:
> > 400 Bad Request
> > The SSL certificate error
> >
> > Схема подписи:
> > CA -> Промежуточный CA -> клиентский сертификат.
> > Насколько я понял, проблема именно в том, что клиентский сертификат
> подписан
> > промежуточным центром сертификации, а не корневым (при подписи корневым
> все
> > было нормальноe).
> >
> > server {
> >   listen 456;
> >   ssl on;
> >   ssl_certificate /var/www/client/data/www/client.ru/ssl/ca.crt;
> >   ssl_certificate_key /var/www/client/data/www/client.ru/ssl/ca.key;
> >   ssl_client_certificate /var/www/client/data/www/client.ru/ssl/pca.crt;
> >   ssl_verify_client optional;
> >
> > ...
> > }
> > --
> > С уважением,
> > Тищенко Андрей.
> >
> > _______________________________________________
> > 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/20130923/2a1ebb5d/attachment.html>

From nginx-forum at nginx.us  Mon Sep 23 12:38:22 2013
From: nginx-forum at nginx.us (aaaa5)
Date: Mon, 23 Sep 2013 08:38:22 -0400
Subject: nginx proxy vs memcached data
In-Reply-To: <524003E0.2040205@amhost.net>
References: <524003E0.2040205@amhost.net>
Message-ID: <bdd0e5b124e5f47929d40b0eaeb187ec.NginxMailingListRussian@forum.nginx.org>

Спасибо. По задумке то что надо. Пробую на стабильной версии 1.4.2:

	location / {
		eval $var {
			set            $memcached_key "$request_uri";
			memcached_pass localhost:11211;
		}
		proxy_pass $var;
	}
	
Получаю в логах:

2013/09/23 16:24:49 [debug] 24218#0: *1 test location: "/"
2013/09/23 16:24:49 [debug] 24218#0: *1 test location: "eval_7274000"
2013/09/23 16:24:49 [debug] 24218#0: *1 using configuration "/"

Вторая строчка это subrequest для перехода по значению memcached, однако
дальше 

2013/09/23 16:31:08 [debug] 24622#0: *1 http cl:-1 max:1048576
2013/09/23 16:31:08 [debug] 24622#0: *1 rewrite phase: 3
2013/09/23 16:31:08 [debug] 24622#0: *1 http subrequest "/eval_7274000?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http finalize request: -2,
"/aaa.php?" a:0, c:2
2013/09/23 16:31:08 [debug] 24622#0: *1 event timer add: 20:
60000:1379939528820
2013/09/23 16:31:08 [debug] 24622#0: *1 http posted request:
"/eval_7274000?"
2013/09/23 16:31:08 [debug] 24622#0: *1 rewrite phase: 1
2013/09/23 16:31:08 [debug] 24622#0: *1 test location: "/"
2013/09/23 16:31:08 [debug] 24622#0: *1 test location: "eval_7274000"
2013/09/23 16:31:08 [debug] 24622#0: *1 using configuration
"=/eval_7274000"
2013/09/23 16:31:08 [debug] 24622#0: *1 http cl:-1 max:1048576
2013/09/23 16:31:08 [debug] 24622#0: *1 rewrite phase: 3
2013/09/23 16:31:08 [debug] 24622#0: *1 rewrite phase: 4
2013/09/23 16:31:08 [debug] 24622#0: *1 http script complex value
2013/09/23 16:31:08 [debug] 24622#0: *1 http script var: "/aaa.php"
2013/09/23 16:31:08 [debug] 24622#0: *1 http script set $memcached_key
2013/09/23 16:31:08 [debug] 24622#0: *1 post rewrite phase: 5
2013/09/23 16:31:08 [debug] 24622#0: *1 generic phase: 6
2013/09/23 16:31:08 [debug] 24622#0: *1 generic phase: 7
2013/09/23 16:31:08 [debug] 24622#0: *1 generic phase: 8
2013/09/23 16:31:08 [debug] 24622#0: *1 posix_memalign:
00000000006E11C0:4096 @16
2013/09/23 16:31:08 [debug] 24622#0: *1 http init upstream, client timer: 0
2013/09/23 16:31:08 [debug] 24622#0: *1 epoll add event: fd:20 op:3
ev:80000005
2013/09/23 16:31:08 [debug] 24622#0: *1 http memcached request: "/aaa.php"
2013/09/23 16:31:08 [debug] 24622#0: *1 http cleanup add: 0000000000720A30
2013/09/23 16:31:08 [debug] 24622#0: *1 get rr peer, try: 1
2013/09/23 16:31:08 [debug] 24622#0: *1 socket 21
2013/09/23 16:31:08 [debug] 24622#0: *1 epoll add connection: fd:21
ev:80000005
2013/09/23 16:31:08 [debug] 24622#0: *1 connect to 127.0.0.1:11211, fd:21
#2
2013/09/23 16:31:08 [debug] 24622#0: *1 http upstream connect: -2
2013/09/23 16:31:08 [debug] 24622#0: *1 posix_memalign: 000000000073EA50:128
@16
2013/09/23 16:31:08 [debug] 24622#0: *1 event timer add: 21:
60000:1379939528820
2013/09/23 16:31:08 [debug] 24622#0: *1 http finalize request: -4,
"/eval_7274000?" a:1, c:3
2013/09/23 16:31:08 [debug] 24622#0: *1 event timer add: 20:
5000:1379939473820
2013/09/23 16:31:08 [debug] 24622#0: *1 http request count:3 blk:0
2013/09/23 16:31:08 [debug] 24622#0: *1 post event 00000000007AB938
2013/09/23 16:31:08 [debug] 24622#0: *1 post event 00000000007AB9A0
2013/09/23 16:31:08 [debug] 24622#0: *1 delete posted event
00000000007AB9A0
2013/09/23 16:31:08 [debug] 24622#0: *1 http upstream request:
"/eval_7274000?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http upstream send request handler
2013/09/23 16:31:08 [debug] 24622#0: *1 http upstream send request
2013/09/23 16:31:08 [debug] 24622#0: *1 chain writer buf fl:0 s:14
2013/09/23 16:31:08 [debug] 24622#0: *1 chain writer in: 0000000000720A68
2013/09/23 16:31:08 [debug] 24622#0: *1 writev: 14
2013/09/23 16:31:08 [debug] 24622#0: *1 chain writer out: 0000000000000000
2013/09/23 16:31:08 [debug] 24622#0: *1 event timer del: 21: 1379939528820
2013/09/23 16:31:08 [debug] 24622#0: *1 event timer add: 21:
60000:1379939528821
2013/09/23 16:31:08 [debug] 24622#0: *1 delete posted event
00000000007AB938
2013/09/23 16:31:08 [debug] 24622#0: *1 http run request: "/eval_7274000?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http upstream check client, write
event:1, "/eval_7274000"
2013/09/23 16:31:08 [debug] 24622#0: *1 http upstream recv(): -1 (11:
Resource temporarily unavailable)
2013/09/23 16:31:08 [debug] 24622#0: *1 post event 0000000000791990
2013/09/23 16:31:08 [debug] 24622#0: *1 post event 00000000007AB9A0
2013/09/23 16:31:08 [debug] 24622#0: *1 delete posted event
00000000007AB9A0
2013/09/23 16:31:08 [debug] 24622#0: *1 http upstream request:
"/eval_7274000?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http upstream dummy handler
2013/09/23 16:31:08 [debug] 24622#0: *1 delete posted event
0000000000791990
2013/09/23 16:31:08 [debug] 24622#0: *1 http upstream request:
"/eval_7274000?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http upstream process header
2013/09/23 16:31:08 [debug] 24622#0: *1 malloc: 00000000006D9220:4096
2013/09/23 16:31:08 [debug] 24622#0: *1 recv: fd:21 52 of 4096
2013/09/23 16:31:08 [debug] 24622#0: *1 memcached: "VALUE /aaa.php 0 24"
2013/09/23 16:31:08 [debug] 24622#0: *1 memcached filter bytes:31 size:31
length:31 rest:7
2013/09/23 16:31:08 [debug] 24622#0: *1 finalize http upstream request: 0
2013/09/23 16:31:08 [debug] 24622#0: *1 finalize http memcached request
2013/09/23 16:31:08 [debug] 24622#0: *1 free rr peer 1 0
2013/09/23 16:31:08 [debug] 24622#0: *1 close http upstream connection: 21
2013/09/23 16:31:08 [debug] 24622#0: *1 free: 000000000073EA50, unused: 48
2013/09/23 16:31:08 [debug] 24622#0: *1 event timer del: 21: 1379939528821
2013/09/23 16:31:08 [debug] 24622#0: *1 reusable connection: 0
2013/09/23 16:31:08 [debug] 24622#0: *1 http output filter "/eval_7274000?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http copy filter: "/eval_7274000?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http postpone filter
"/eval_7274000?" 00007FFFC4CFE300
2013/09/23 16:31:08 [debug] 24622#0: *1 write new buf t:0 f:0
0000000000000000, pos 0000000000000000, size: 0 file: 0, size: 0
2013/09/23 16:31:08 [debug] 24622#0: *1 http write filter: l:0 f:0 s:0
2013/09/23 16:31:08 [debug] 24622#0: *1 http copy filter: 0
"/eval_7274000?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http finalize request: 0,
"/eval_7274000?" a:1, c:2
2013/09/23 16:31:08 [debug] 24622#0: *1 http wake parent request:
"/aaa.php?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http posted request: "/aaa.php?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http writer handler: "/aaa.php?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http output filter "/aaa.php?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http copy filter: "/aaa.php?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http postpone filter "/aaa.php?"
0000000000000000
2013/09/23 16:31:08 [debug] 24622#0: *1 http copy filter: 0 "/aaa.php?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http writer output filter: 0,
"/aaa.php?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http writer done: "/aaa.php?"
2013/09/23 16:31:08 [debug] 24622#0: *1 http finalize request: 0,
"/aaa.php?" a:1, c:1
2013/09/23 16:31:08 [debug] 24622#0: *1 event timer del: 20: 1379939473820
2013/09/23 16:31:08 [debug] 24622#0: *1 event timer del: 20: 1379939528820
2013/09/23 16:31:08 [debug] 24622#0: *1 set http keepalive handler
2013/09/23 16:31:08 [debug] 24622#0: *1 http close request
2013/09/23 16:31:08 [debug] 24622#0: *1 http log handler
2013/09/23 16:31:08 [debug] 24622#0: *1 free: 00000000006D9220
2013/09/23 16:31:08 [debug] 24622#0: *1 free: 0000000000785530, unused: 2
2013/09/23 16:31:08 [debug] 24622#0: *1 free: 000000000071FCF0, unused: 24
2013/09/23 16:31:08 [debug] 24622#0: *1 free: 00000000006E11C0, unused:
2700
2013/09/23 16:31:08 [debug] 24622#0: *1 free: 00000000006D4660
2013/09/23 16:31:08 [debug] 24622#0: *1 hc free: 0000000000000000 0
2013/09/23 16:31:08 [debug] 24622#0: *1 hc busy: 0000000000000000 0
2013/09/23 16:31:08 [debug] 24622#0: *1 tcp_nodelay
2013/09/23 16:31:08 [debug] 24622#0: *1 reusable connection: 1
2013/09/23 16:31:08 [debug] 24622#0: *1 event timer add: 20:
15000:1379939483821
2013/09/23 16:31:08 [debug] 24622#0: *1 post event 0000000000791928
2013/09/23 16:31:08 [debug] 24622#0: *1 delete posted event
0000000000791928
2013/09/23 16:31:08 [debug] 24622#0: *1 http keepalive handler
2013/09/23 16:31:08 [debug] 24622#0: *1 malloc: 00000000006D4660:1024
2013/09/23 16:31:08 [debug] 24622#0: *1 recv: fd:20 -1 of 1024
2013/09/23 16:31:08 [debug] 24622#0: *1 recv() not ready (11: Resource
temporarily unavailable)
2013/09/23 16:31:08 [debug] 24622#0: *1 free: 00000000006D4660
2013/09/23 16:31:23 [debug] 24622#0: *1 event timer del: 20: 1379939483821
2013/09/23 16:31:23 [debug] 24622#0: *1 http keepalive handler
2013/09/23 16:31:23 [debug] 24622#0: *1 close http connection: 20
2013/09/23 16:31:23 [debug] 24622#0: *1 reusable connection: 0
2013/09/23 16:31:23 [debug] 24622#0: *1 free: 0000000000000000
2013/09/23 16:31:23 [debug] 24622#0: *1 free: 00000000007047A0, unused: 8
2013/09/23 16:31:23 [debug] 24622#0: *1 free: 0000000000728D70, unused: 144

Resource temporarily unavailable

И всё

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


From nginx-forum at nginx.us  Mon Sep 23 13:10:20 2013
From: nginx-forum at nginx.us (aaaa5)
Date: Mon, 23 Sep 2013 09:10:20 -0400
Subject: nginx proxy vs memcached data
In-Reply-To: <524003E0.2040205@amhost.net>
References: <524003E0.2040205@amhost.net>
Message-ID: <090e01a9e75260d785ea3a7164856fb7.NginxMailingListRussian@forum.nginx.org>

Возможно проблема в настройках memcached-сервера, который возвращает 

memcached: "VALUE /aaa.php 0 24"

имя параметр и длину ключа

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


From mdounin at mdounin.ru  Mon Sep 23 13:13:46 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 23 Sep 2013 17:13:46 +0400
Subject: =?UTF-8?B?UmU6IEZ3ZDog0JDQstGC0L7RgNC40LfQsNGG0LjRjyDRgSDQv9C+0LzQvtGJ0Yw=?=
 =?UTF-8?B?0Y4gU1NM?=
In-Reply-To: <CAK6srhDt05uYg0PUw1rg0g_CbTDeubH4=wq4fXPtXSRT6i-8-Q@mail.gmail.com>
References: <CAK6srhAyZsPWEy6=+QBW9PZAWo2DdgQez2+Td05D13OS_BvzBA@mail.gmail.com>
 <CAK6srhDt05uYg0PUw1rg0g_CbTDeubH4=wq4fXPtXSRT6i-8-Q@mail.gmail.com>
Message-ID: <20130923131345.GE2170@mdounin.ru>

Hello!

On Sun, Sep 22, 2013 at 06:47:26PM +0000, Андрей Тищенко wrote:

> Здравствуйте.
> Пытаюсь реализовать авторизацию с помощью SSL сертификатов, но получаю
> ошибку:
> 400 Bad Request
> The SSL certificate error
> 
> Схема подписи:
> CA -> Промежуточный CA -> клиентский сертификат.
> Насколько я понял, проблема именно в том, что клиентский сертификат
> подписан промежуточным центром сертификации, а не корневым (при подписи
> корневым все было нормальноe).
> 
> server {
>   listen 456;
>   ssl on;
>   ssl_certificate /var/www/client/data/www/client.ru/ssl/ca.crt;
>   ssl_certificate_key /var/www/client/data/www/client.ru/ssl/ca.key;
>   ssl_client_certificate /var/www/client/data/www/client.ru/ssl/pca.crt;
>   ssl_verify_client optional;
> 
> ...
> }

Как минимум, в конфиге не видно директивы ssl_verify_depth, 
которая по умолчанию 1 - и цепочки сертификатов работать не будут.  
Подробнее - http://nginx.org/r/ssl_verify_depth.

Ну и как уже отметили, сертификат промежуточного CA следует 
положить в файл, на который указывает директива 
ssl_client_certificate (или ssl_trusted_certificate).  Т.к. 
клиентов, присылающих цепочку сертификатов, скорее всего не 
бывает.

А вообще - не забывайте заглядывать в error_log, там обычно есть 
подробности.

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


From mdounin at mdounin.ru  Mon Sep 23 15:22:28 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 23 Sep 2013 19:22:28 +0400
Subject: =?UTF-8?B?UmU6INCT0LXQvdC10YDQsNGG0LjRjyDQvtGC0LLQtdGC0LAg0LTQu9GPINC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQsCDQuCDQsNGB0LjQvdGF0YDQvtC90L3Ri9C1INGB0L7QutC1?=
 =?UTF-8?B?0YLRiw==?=
In-Reply-To: <eb4c29ba9779515af3caf34ee14b82e3.NginxMailingListRussian@forum.nginx.org>
References: <eb4c29ba9779515af3caf34ee14b82e3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130923152228.GG2170@mdounin.ru>

Hello!

On Mon, Sep 23, 2013 at 02:49:24AM -0400, Aleus Essentia wrote:

> Добрый день!
> 
> Мой модуль работает по следующему алгоритму:
> 1) Получает заголовок от клиента;
> 2) Записывает по специальному формату заголовок в сокет другого сервера;
> 3) Закрывает на запись сокет;
> 4) Читает ответ: заголовок и html-страницу из этого же сокета;
> 5) Отдаёт полученный заголовок и html клиенту.
> 
> Всё бы было хорошо, но работать с сокетами нужно асинхронно, а сейчас чтение
> и запись происходит блокирующим способом.
> Подскажите, следуя каким принципам, я должен составить код для асинхронного
> получения заголовка и html из сокета?
> 
> Прочитал про регистрацию событий в этой статье:
> http://green-shaman.livejournal.com/32600.html. Но там не написано, где я
> должен вызывать функцию регистрации событий и где могу разместить код,
> отрабатывающий после прочтения всего ответа из сокета?

Я бы рекомендовал для начала ознакомится с кодом самого nginx'а.  
В частности - с кодом модуля upstream использующих его модулей 
(memcached, proxy).

Ну и Evan'а Miller'а почитать, если ещё не (а судя по вопросам - 
таки не).  Ссылки есть тут:

http://nginx.org/en/links.html

Там не всё соответствует текущему положению вещей в плане деталей, 
местами API поменялось, но вы, по крайней мере, начнёте понимать, 
о чём идёт речь.

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


From alex.hha at gmail.com  Tue Sep 24 07:53:36 2013
From: alex.hha at gmail.com (Alex Domoradov)
Date: Tue, 24 Sep 2013 10:53:36 +0300
Subject: =?UTF-8?B?UmU6IEZ3ZDog0JDQstGC0L7RgNC40LfQsNGG0LjRjyDRgSDQv9C+0LzQvtGJ0Yw=?=
 =?UTF-8?B?0Y4gU1NM?=
In-Reply-To: <20130923131345.GE2170@mdounin.ru>
References: <CAK6srhAyZsPWEy6=+QBW9PZAWo2DdgQez2+Td05D13OS_BvzBA@mail.gmail.com>
 <CAK6srhDt05uYg0PUw1rg0g_CbTDeubH4=wq4fXPtXSRT6i-8-Q@mail.gmail.com>
 <20130923131345.GE2170@mdounin.ru>
Message-ID: <CAK90gp4nf+3ROsxZyWyiN1NSYJyiEJerZ5tPJiqR2HhAY5=qdw@mail.gmail.com>

> Как минимум, в конфиге не видно директивы ssl_verify_depth, которая по умолчанию 1 - и цепочки сертификатов работать не будут.
а как можно определить необходимую глубину проверки?

2013/9/23 Maxim Dounin <mdounin at mdounin.ru>:
> Hello!
>
> On Sun, Sep 22, 2013 at 06:47:26PM +0000, Андрей Тищенко wrote:
>
>> Здравствуйте.
>> Пытаюсь реализовать авторизацию с помощью SSL сертификатов, но получаю
>> ошибку:
>> 400 Bad Request
>> The SSL certificate error
>>
>> Схема подписи:
>> CA -> Промежуточный CA -> клиентский сертификат.
>> Насколько я понял, проблема именно в том, что клиентский сертификат
>> подписан промежуточным центром сертификации, а не корневым (при подписи
>> корневым все было нормальноe).
>>
>> server {
>>   listen 456;
>>   ssl on;
>>   ssl_certificate /var/www/client/data/www/client.ru/ssl/ca.crt;
>>   ssl_certificate_key /var/www/client/data/www/client.ru/ssl/ca.key;
>>   ssl_client_certificate /var/www/client/data/www/client.ru/ssl/pca.crt;
>>   ssl_verify_client optional;
>>
>> ...
>> }
>
> Как минимум, в конфиге не видно директивы ssl_verify_depth,
> которая по умолчанию 1 - и цепочки сертификатов работать не будут.
> Подробнее - http://nginx.org/r/ssl_verify_depth.
>
> Ну и как уже отметили, сертификат промежуточного CA следует
> положить в файл, на который указывает директива
> ssl_client_certificate (или ssl_trusted_certificate).  Т.к.
> клиентов, присылающих цепочку сертификатов, скорее всего не
> бывает.
>
> А вообще - не забывайте заглядывать в error_log, там обычно есть
> подробности.
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From mdounin at mdounin.ru  Tue Sep 24 11:22:55 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 24 Sep 2013 15:22:55 +0400
Subject: =?UTF-8?B?UmU6IEZ3ZDog0JDQstGC0L7RgNC40LfQsNGG0LjRjyDRgSDQv9C+0LzQvtGJ0Yw=?=
 =?UTF-8?B?0Y4gU1NM?=
In-Reply-To: <CAK90gp4nf+3ROsxZyWyiN1NSYJyiEJerZ5tPJiqR2HhAY5=qdw@mail.gmail.com>
References: <CAK6srhAyZsPWEy6=+QBW9PZAWo2DdgQez2+Td05D13OS_BvzBA@mail.gmail.com>
 <CAK6srhDt05uYg0PUw1rg0g_CbTDeubH4=wq4fXPtXSRT6i-8-Q@mail.gmail.com>
 <20130923131345.GE2170@mdounin.ru>
 <CAK90gp4nf+3ROsxZyWyiN1NSYJyiEJerZ5tPJiqR2HhAY5=qdw@mail.gmail.com>
Message-ID: <20130924112255.GM2170@mdounin.ru>

Hello!

On Tue, Sep 24, 2013 at 10:53:36AM +0300, Alex Domoradov wrote:

> > Как минимум, в конфиге не видно директивы ssl_verify_depth, 
> > которая по умолчанию 1 - и цепочки сертификатов работать не 
> > будут.
> а как можно определить необходимую глубину проверки?

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

Если клиентские сертификаты подписаны непосредственно корневым CA, 
то достаточно одной проверки - и соответственно значения 
ssl_verify_depth по умолчанию, 1.  Если используется один 
промежуточный CA-сертификат - то нужно две проверки подписи, и 
соответственно ssl_verify_depth минимум 2.

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


From alex.hha at gmail.com  Tue Sep 24 21:36:40 2013
From: alex.hha at gmail.com (Alex Domoradov)
Date: Wed, 25 Sep 2013 00:36:40 +0300
Subject: =?UTF-8?B?UmU6IEZ3ZDog0JDQstGC0L7RgNC40LfQsNGG0LjRjyDRgSDQv9C+0LzQvtGJ0Yw=?=
 =?UTF-8?B?0Y4gU1NM?=
In-Reply-To: <20130924112255.GM2170@mdounin.ru>
References: <CAK6srhAyZsPWEy6=+QBW9PZAWo2DdgQez2+Td05D13OS_BvzBA@mail.gmail.com>
 <CAK6srhDt05uYg0PUw1rg0g_CbTDeubH4=wq4fXPtXSRT6i-8-Q@mail.gmail.com>
 <20130923131345.GE2170@mdounin.ru>
 <CAK90gp4nf+3ROsxZyWyiN1NSYJyiEJerZ5tPJiqR2HhAY5=qdw@mail.gmail.com>
 <20130924112255.GM2170@mdounin.ru>
Message-ID: <CAK90gp5DjWav3HdsraZyrtaoGdJ-u-BQci0OAEsmz1+u9z0nMA@mail.gmail.com>

Понятно, а будут ли какие то негативные последствия, если я знаю, что
необхходимая глубина 1, но выставлю знаениче 2 или 3. Это создаст
лишнюю нагрузку или проверка в таком случае вообще не будет проходить?

2013/9/24 Maxim Dounin <mdounin at mdounin.ru>:
> Hello!
>
> On Tue, Sep 24, 2013 at 10:53:36AM +0300, Alex Domoradov wrote:
>
>> > Как минимум, в конфиге не видно директивы ssl_verify_depth,
>> > которая по умолчанию 1 - и цепочки сертификатов работать не
>> > будут.
>> а как можно определить необходимую глубину проверки?
>
> Посчитать количество проверок подписей, которые необходимо сделать
> от корневого сертификата до проверяемого клиентского сертификата.
>
> Если клиентские сертификаты подписаны непосредственно корневым CA,
> то достаточно одной проверки - и соответственно значения
> ssl_verify_depth по умолчанию, 1.  Если используется один
> промежуточный CA-сертификат - то нужно две проверки подписи, и
> соответственно ssl_verify_depth минимум 2.
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum at nginx.us  Wed Sep 25 08:58:31 2013
From: nginx-forum at nginx.us (Dymytry)
Date: Wed, 25 Sep 2013 04:58:31 -0400
Subject: =?UTF-8?B?0KPRh9C40YLRi9Cy0LDQtdGCINC70Lggbmdpbngt0L/RgNC+0LrRgdC4INC60Y0=?=
 =?UTF-8?B?0Ygt0LfQsNCz0L7Qu9C+0LLQutC4INGBINCx0Y3QutC10L3QtNCwPw==?=
Message-ID: <89b2f1613969f20c0a35b8d54110c6a5.NginxMailingListRussian@forum.nginx.org>

День добрый! 
Изучаю nginx, разбираюсь в кэшировании, имею browser + nginx reverse proxy +
nginx web-server.

Допустим клиент сделал запрос, прокси перевел его на бэкенд, тот ответил и
прокси отдал ответ клиенту. Допустим бэкенд проставил какие-то заголовки,
связанные с кэшем, например: 
Cache-Control: no-cache         (или)
Cache-Control: max-age=100000   (или)
Expires: 'Next Friday'

Вопрос 1: следующий запрос клиента к этому ресурсу будет обработан с учетом
этих заголовков?
Вопрос 2: как nginx-proxy понимает что ресурс stale и его не надо отдавать
клиенту, а надо спросить бэкенд? (кроме директивы proxy_cache_valid) Может
ли он понять это из заголовков ответа бэкенда?
Вопрос 3: может ли клиент заставить прокси закрузить свежую версию ресурса,
которая еще не истекла согласно proxy_cache_valid?

Я пробую играть с заголовками Cache-Control прокси и бэкенда, и насколько я
могу судить, если ресурс закэшировался в прокси ничто не поможет мне
получить его свежую версию кроме удаления кэша или истечения
proxy_cache_valid. То есть "модель" кэша nginx reverse proxy это просто
веб-сервер с контентом, равным тому, что удалось закэшировать, а что именно
кэшировать определяется тем, не ставит ли бэкенд Cache-Control: no-cache или
no-store; заголовки Expired, Cache-Control: max-age бэкенда не учитываются.

Я правильно понимаю, или нет?
Так работают все прокси, и squid, и разные публичные прокси в интернете?
Изменить ли что-то, если nginx-proxy соединяется с клиентом по SSL?

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


From ru at nginx.com  Wed Sep 25 09:22:18 2013
From: ru at nginx.com (Ruslan Ermilov)
Date: Wed, 25 Sep 2013 13:22:18 +0400
Subject: =?UTF-8?B?UmU6INCj0YfQuNGC0YvQstCw0LXRgiDQu9C4IG5naW54LdC/0YDQvtC60YHQuCA=?=
 =?UTF-8?B?0LrRjdGILdC30LDQs9C+0LvQvtCy0LrQuCDRgSDQsdGN0LrQtdC90LTQsD8=?=
In-Reply-To: <89b2f1613969f20c0a35b8d54110c6a5.NginxMailingListRussian@forum.nginx.org>
References: <89b2f1613969f20c0a35b8d54110c6a5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130925092218.GL1483@lo0.su>

On Wed, Sep 25, 2013 at 04:58:31AM -0400, Dymytry wrote:
> День добрый! 
> Изучаю nginx, разбираюсь в кэшировании, имею browser + nginx reverse proxy +
> nginx web-server.
> 
> Допустим клиент сделал запрос, прокси перевел его на бэкенд, тот ответил и
> прокси отдал ответ клиенту. Допустим бэкенд проставил какие-то заголовки,
> связанные с кэшем, например: 
> Cache-Control: no-cache         (или)
> Cache-Control: max-age=100000   (или)
> Expires: 'Next Friday'
> 
> Вопрос 1: следующий запрос клиента к этому ресурсу будет обработан с учетом
> этих заголовков?

Ответ на этот вопрос есть в документации:
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_ignore_headers

> Вопрос 2: как nginx-proxy понимает что ресурс stale и его не надо отдавать
> клиенту, а надо спросить бэкенд? (кроме директивы proxy_cache_valid) Может
> ли он понять это из заголовков ответа бэкенда?

Ответ на этот вопрос есть в документации:
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_use_stale

> Вопрос 3: может ли клиент заставить прокси закрузить свежую версию ресурса,
> которая еще не истекла согласно proxy_cache_valid?

Может, если администратор nginx сочтёт нужным:
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_bypass

> Я пробую играть с заголовками Cache-Control прокси и бэкенда, и насколько я
> могу судить, если ресурс закэшировался в прокси ничто не поможет мне
> получить его свежую версию кроме удаления кэша или истечения
> proxy_cache_valid. То есть "модель" кэша nginx reverse proxy это просто
> веб-сервер с контентом, равным тому, что удалось закэшировать, а что именно
> кэшировать определяется тем, не ставит ли бэкенд Cache-Control: no-cache или
> no-store; заголовки Expired, Cache-Control: max-age бэкенда не учитываются.
> 
> Я правильно понимаю, или нет?
> Так работают все прокси, и squid, и разные публичные прокси в интернете?
> Изменить ли что-то, если nginx-proxy соединяется с клиентом по SSL?


From nginx-forum at nginx.us  Wed Sep 25 10:12:34 2013
From: nginx-forum at nginx.us (Dymytry)
Date: Wed, 25 Sep 2013 06:12:34 -0400
Subject: =?UTF-8?B?UmU6INCj0YfQuNGC0YvQstCw0LXRgiDQu9C4IG5naW54LdC/0YDQvtC60YHQuCA=?=
 =?UTF-8?B?0LrRjdGILdC30LDQs9C+0LvQvtCy0LrQuCDRgSDQsdGN0LrQtdC90LTQsD8=?=
In-Reply-To: <20130925092218.GL1483@lo0.su>
References: <20130925092218.GL1483@lo0.su>
Message-ID: <1f0943864718acd9812533316b007f3c.NginxMailingListRussian@forum.nginx.org>

Спасибо, Руслан! С первыми двумя вопросами все-таки не совсем понятно.

Я хочу понять: сохраняет ли nginx proxy внутри себя кэш-заголовки ответа
бэкенда для последующего использования?
То есть, имеется ли внутри nginx proxy таблица вида...

----URL---------- Cache Header---------
/logo.png     expires 12-10-2013
/icom.png    expires 01-01-1970

... которая используется для того, чтобы получив запрос на /logo.png прокси
отдал кэш, а на /icon.png - полез бы в бэкенд, несмотря на то что кэш есть.

В описании директивы proxy_use_stale не указано, к сожалению, как именно
nginx proxy решает,  является ли данный ресурс stale. Это именно то, что я
хочу понять: он решает это на основании заголовков предыдущих ответов
бэкенда на данный запрос, или ТОЛЬКО на основании proxy_cache_valid?

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


From mdounin at mdounin.ru  Wed Sep 25 12:35:53 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Wed, 25 Sep 2013 16:35:53 +0400
Subject: =?UTF-8?B?UmU6IEZ3ZDog0JDQstGC0L7RgNC40LfQsNGG0LjRjyDRgSDQv9C+0LzQvtGJ0Yw=?=
 =?UTF-8?B?0Y4gU1NM?=
In-Reply-To: <CAK90gp5DjWav3HdsraZyrtaoGdJ-u-BQci0OAEsmz1+u9z0nMA@mail.gmail.com>
References: <CAK6srhAyZsPWEy6=+QBW9PZAWo2DdgQez2+Td05D13OS_BvzBA@mail.gmail.com>
 <CAK6srhDt05uYg0PUw1rg0g_CbTDeubH4=wq4fXPtXSRT6i-8-Q@mail.gmail.com>
 <20130923131345.GE2170@mdounin.ru>
 <CAK90gp4nf+3ROsxZyWyiN1NSYJyiEJerZ5tPJiqR2HhAY5=qdw@mail.gmail.com>
 <20130924112255.GM2170@mdounin.ru>
 <CAK90gp5DjWav3HdsraZyrtaoGdJ-u-BQci0OAEsmz1+u9z0nMA@mail.gmail.com>
Message-ID: <20130925123553.GV2170@mdounin.ru>

Hello!

On Wed, Sep 25, 2013 at 12:36:40AM +0300, Alex Domoradov wrote:

> Понятно, а будут ли какие то негативные последствия, если я знаю, что
> необхходимая глубина 1, но выставлю знаениче 2 или 3. Это создаст
> лишнюю нагрузку или проверка в таком случае вообще не будет проходить?

Директива ssl_verify_depth задаёт максимальную глубину, дальше 
которой проверка делаться не будет.  Так что в нормальном случае 
проверки валидного сертификата, проверка которого ранее проходила, - 
ничего не изменится.  Меняются только аспекты, относящиеся к 
более "глубоким" проверкам:

1. Промежуточные CA начинают работать.  И если вдруг есть 
выпущенные промежуточные CA - то надо понимать, что выпущенные ими 
клиентские сертификаты тоже начнут работать.  Даже если никаких 
промежуточных сертификатов в nginx не добавлено - ибо в рамках 
протокола у клиента имеется возможность самостоятельно прислать 
промежуточные CA.

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

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


From nginx-forum at nginx.us  Wed Sep 25 12:47:01 2013
From: nginx-forum at nginx.us (jurio)
Date: Wed, 25 Sep 2013 08:47:01 -0400
Subject: ssl_crl non-critical
Message-ID: <7a152a7fa3208451a89d5fb4758c533a.NginxMailingListRussian@forum.nginx.org>

Добрый день!

Подскажите, пожалуйста, по поводу указанной инструкции:
ошибка проверки клиентского сертификата (если SN есть в списке отзыва)
возникает только в случае, если CDP extention отмечен как critical?

Версия nginx 1.2.9.
ssl                  on;
ssl_protocols        SSLv3 TLSv1;
ssl_ciphers          AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;
ssl_certificate      server.crt;
ssl_certificate_key  server_private.key;
ssl_verify_client    on;
ssl_client_certificate root.crt;
ssl_crl revoked.crl;

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


From ru at nginx.com  Wed Sep 25 13:01:26 2013
From: ru at nginx.com (Ruslan Ermilov)
Date: Wed, 25 Sep 2013 17:01:26 +0400
Subject: =?UTF-8?B?UmU6INCj0YfQuNGC0YvQstCw0LXRgiDQu9C4IG5naW54LdC/0YDQvtC60YHQuCA=?=
 =?UTF-8?B?0LrRjdGILdC30LDQs9C+0LvQvtCy0LrQuCDRgSDQsdGN0LrQtdC90LTQsD8=?=
In-Reply-To: <1f0943864718acd9812533316b007f3c.NginxMailingListRussian@forum.nginx.org>
References: <20130925092218.GL1483@lo0.su>
 <1f0943864718acd9812533316b007f3c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130925130126.GR1483@lo0.su>

On Wed, Sep 25, 2013 at 06:12:34AM -0400, Dymytry wrote:
> Спасибо, Руслан! С первыми двумя вопросами все-таки не совсем понятно.
> 
> Я хочу понять: сохраняет ли nginx proxy внутри себя кэш-заголовки ответа
> бэкенда для последующего использования?
> То есть, имеется ли внутри nginx proxy таблица вида...
> 
> ----URL---------- Cache Header---------
> /logo.png     expires 12-10-2013
> /icom.png    expires 01-01-1970
> 
> ... которая используется для того, чтобы получив запрос на /logo.png прокси
> отдал кэш, а на /icon.png - полез бы в бэкенд, несмотря на то что кэш есть.
> 
> В описании директивы proxy_use_stale не указано, к сожалению, как именно
> nginx proxy решает,  является ли данный ресурс stale. Это именно то, что я
> хочу понять: он решает это на основании заголовков предыдущих ответов
> бэкенда на данный запрос, или ТОЛЬКО на основании proxy_cache_valid?

По тем ссылкам, что я дал, есть все ответы на все ваши вопросы.
Ниже соотв. цитаты.

http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_valid
[...]
Параметры кэширования могут также быть заданы непосредственно в
заголовке ответа. Такой способ приоритетнее, чем задание времени
кэширования с помощью директивы.


http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_ignore_headers                                                                
[...]
Если не запрещено, обработка этих полей заголовка заключается
в следующем:

- ?X-Accel-Expires?, ?Expires?, ?Cache-Control? и ?Set-Cookie? задают
  параметры кэширования ответа; 


From dsimonov at gmail.com  Wed Sep 25 16:07:51 2013
From: dsimonov at gmail.com (Dmitry Simonov)
Date: Wed, 25 Sep 2013 20:07:51 +0400
Subject: =?UTF-8?B?0JLQvtC/0YDQvtGBINC6INGB0YLQsNGA0YvQvCDQv9GA0L7Qs9GA0LDQvNC80Lg=?=
 =?UTF-8?B?0YHRgtCw0Lw6INCy0LjQt9GD0LDQu9GM0L3QvtC1INC/0YDQvtCz0YDQsNC8?=
 =?UTF-8?B?0LjRgNC+0LLQsNC90LjQtSA6KQ==?=
Message-ID: <CAL9wMxWct+ic2s2t9C76npWR1mEGB30wLE=v_uRvASoV0b9GdQ@mail.gmail.com>

Вопрос к зубрам!

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

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

Весь опыт попыток подхода к этому снаряду показывает то, что любая система
автоматизации подобного динамического переконфигурирования ОЧЕНЬ БЫСТРО
устаревает (так как вся система растёт и развивается,
меняются/добавляются/удаляются конфигурационные параметры) подобно тому,
как устраревает документация.

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

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

---
Dmitriy V. Simonov,
Perl & Python programmer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130925/ca5df6f0/attachment.html>

From postmaster at softsearch.ru  Wed Sep 25 17:10:58 2013
From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=)
Date: Wed, 25 Sep 2013 21:10:58 +0400
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQuiDRgdGC0LDRgNGL0Lwg0L/RgNC+0LPRgNCw0Lw=?=
 =?UTF-8?B?0LzQuNGB0YLQsNC8OiDQstC40LfRg9Cw0LvRjNC90L7QtSDQv9GA0L7Qs9GA?=
 =?UTF-8?B?0LDQvNC40YDQvtCy0LDQvdC40LUgOik=?=
In-Reply-To: <CAL9wMxWct+ic2s2t9C76npWR1mEGB30wLE=v_uRvASoV0b9GdQ@mail.gmail.com>
References: <CAL9wMxWct+ic2s2t9C76npWR1mEGB30wLE=v_uRvASoV0b9GdQ@mail.gmail.com>
Message-ID: <975506965.20130925211058@softsearch.ru>

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

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

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


From alex.hha at gmail.com  Wed Sep 25 19:41:11 2013
From: alex.hha at gmail.com (Alex Domoradov)
Date: Wed, 25 Sep 2013 22:41:11 +0300
Subject: =?UTF-8?B?0J/QtdGA0LXQt9Cw0L/QuNGB0YwgUmVmZXJlciDQv9C+INGD0YHQu9C+0LLQuNGO?=
Message-ID: <CAK90gp6geDL0Q4n2BPVzVgCgGMWJ-_WY-B+OJybukgYaYj+COQ@mail.gmail.com>

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

Суть сводится к подключению в html коде js скрипта

fonts.com
<script type="text/javascript"
src="http://fast.fonts.net/jsapi/8163d577-49e6-9656-88c9-d8609ff327a1.js"></script>

typekit.com
<script type="text/javascript" src="//use.typekit.net/0cd8xtd.js"></script>

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

И вот собственно возникла проблема, необходимости тестирования данных
сайтов из 3х разных мест, при этом в админке должен быть указан только
один реальный домен.

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

Хотелось бы избежать подобной ситуации, и в настройках сервисов
прописать только localhost. Для этого я завернул на шлюзе все
обращения к fast.fonts.net (93.184.220.188) и use.typekit.net
(93.184.220.20) на nignx.

# iptables -I PREROUTING -p tcp -s 192.168.0.0/16 -d 93.184.220.20
--dport 80 -j DNAT --to-destination 192.168.1.1:80

# iptables -I PREROUTING -p tcp -s 192.168.0.0/16 -d 93.184.220.188
--dport 80 -j DNAT --to-destination 192.168.1.1:80

Внутри локальной сети подняты два внутр домена, typekit.example.net и
fonts.example.net и соотв следующий конфиг nginx

server {
    listen       192.168.1.1:80;
    server_name  _;

    location / {

            if ($http_referer ~ '^http://typekit.example.net/') {
                set $referer http://localhost;
                proxy_pass http://93.184.220.20:80;
            }

            if ($http_referer ~ '^http://fonts.example.net/') {
                set  $referer http://localhost;
                proxy_pass http://93.184.220.188:80;
            }

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

И все бы классно, за исключением двух моментов:

1. Многие сайты используют эти сервисы для размещения css, например,
wordpress.org, fonts.com, typekit.com и т.д. Хотелось бы для всех
сайтов, кроме typekit.example.net и fonts.example.net пропускать
запросы без модификаций

2. Необходимо как то сделать исключения для наших внешних тестовых
серверов (с внешними доменными именами). Т.е. например, если
http_referer = project.domain.com, то мы ничего не делаем с запросом,
а просто перенаправляем на соотв сервер (typekit.com или fonts.com)

Читал, что http://wiki.nginx.org/IfIsEvil крайне не желательно
использовать if в Location, может есть более элегантный способ решить
данную задачу?

From nginx-forum at nginx.us  Thu Sep 26 03:36:44 2013
From: nginx-forum at nginx.us (Aleus Essentia)
Date: Wed, 25 Sep 2013 23:36:44 -0400
Subject: =?UTF-8?B?UmU6INCT0LXQvdC10YDQsNGG0LjRjyDQvtGC0LLQtdGC0LAg0LTQu9GPINC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQsCDQuCDQsNGB0LjQvdGF0YDQvtC90L3Ri9C1INGB0L7QutC1?=
 =?UTF-8?B?0YLRiw==?=
In-Reply-To: <20130923152228.GG2170@mdounin.ru>
References: <20130923152228.GG2170@mdounin.ru>
Message-ID: <f1d3d6c66f14b967da7e751a715041c1.NginxMailingListRussian@forum.nginx.org>

У Evan'а тоже не всё написано. Сейчас сделал отправку в сокет с
ипользованием uptream'ов, по аналогии с модулемя FastCGI. 
Но осталась одна проблема: после отправки в сокет upstream'а, в роли
которого выступает наш внутренний сервер, нужно прикрывать соединение на
запись с помощью shutdown( fd, 0 ). Подскажите куда мне его вставить?

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


From dsimonov at gmail.com  Thu Sep 26 05:11:50 2013
From: dsimonov at gmail.com (Dmitry Simonov)
Date: Thu, 26 Sep 2013 09:11:50 +0400
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQuiDRgdGC0LDRgNGL0Lwg0L/RgNC+0LPRgNCw0Lw=?=
 =?UTF-8?B?0LzQuNGB0YLQsNC8OiDQstC40LfRg9Cw0LvRjNC90L7QtSDQv9GA0L7Qs9GA?=
 =?UTF-8?B?0LDQvNC40YDQvtCy0LDQvdC40LUgOik=?=
In-Reply-To: <975506965.20130925211058@softsearch.ru>
References: <CAL9wMxWct+ic2s2t9C76npWR1mEGB30wLE=v_uRvASoV0b9GdQ@mail.gmail.com>
 <975506965.20130925211058@softsearch.ru>
Message-ID: <CAL9wMxXnTwafz3BvFpDDZBDf4w3XpOMsgP0UWMHL+KB0Qe_qKQ@mail.gmail.com>

Миша! Ты слишком много работал на убыточных сервисах. На прибыльных
развитие идёт постоянно.

---
Dmitriy V. Simonov,
Perl & Python programmer


2013/9/25 Михаил Монашёв <postmaster at softsearch.ru>

> Здравствуйте, Dmitry.
>
> Система будет пригодна к документированию и автоматизации тогда, когда
> перестанет  бурно  развиваться.  Поэтому  не  надо  ничего выдумывать,
> просто  найдите  голову,  которая  будет  держать в себе весь конфиг и
> пускайте  только  через  неё все изменения. Есть же перл-программисты,
> будет  nginx-конфигуратор.  Глядишь,  он  в  своей  голове  постепенно
> структуризирует конфиг и напишет генерилку его или его частей.
>
> --
> С уважением,
>  Михаил                          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/20130926/a31ce2a2/attachment.html>

From nginx-forum at nginx.us  Thu Sep 26 07:06:27 2013
From: nginx-forum at nginx.us (Aleus Essentia)
Date: Thu, 26 Sep 2013 03:06:27 -0400
Subject: =?UTF-8?B?UmU6INCT0LXQvdC10YDQsNGG0LjRjyDQvtGC0LLQtdGC0LAg0LTQu9GPINC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQsCDQuCDQsNGB0LjQvdGF0YDQvtC90L3Ri9C1INGB0L7QutC1?=
 =?UTF-8?B?0YLRiw==?=
In-Reply-To: <eb4c29ba9779515af3caf34ee14b82e3.NginxMailingListRussian@forum.nginx.org>
References: <eb4c29ba9779515af3caf34ee14b82e3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5396a3bd9d3ffdac305dfa46ad55d0b6.NginxMailingListRussian@forum.nginx.org>

И ещё вопрос: я ничего не упускаю при создании программы?
#include <ngx_config.h>
#include <ngx_core.h>
#include <ngx_http.h>
#include <ngx_hash.h>
#include <math.h>
#include <string.h>

static void* ngx_http_mymodule_create_loc_conf(ngx_conf_t *cf);
static char* ngx_http_mymodule_merge_loc_conf(ngx_conf_t *cf,
					     void *parent, void *child);

//	Upstream-version
static char* ngx_http_mymodule (ngx_conf_t *cf, ngx_command_t *cmd, void
*conf);
static ngx_int_t ngx_http_mymodule_upstream_handler (ngx_http_request_t
*r);

//--------------------------------------------------------------------------
static ngx_command_t  ngx_http_mymodule_commands[] = {
    { ngx_string("mymodule"),
      NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1,
      ngx_http_mymodule, 
      NGX_HTTP_LOC_CONF_OFFSET,
      0,
      NULL },

      ngx_null_command
};


//--------------------------------------------------------------------------
static ngx_http_module_t  ngx_http_mymodule_module_ctx = {
    NULL,                          /* preconfiguration */
    NULL,           /* postconfiguration */

    NULL,                          /* create main configuration */
    NULL,                          /* init main configuration */

    NULL,                          /* create server configuration */
    NULL,                          /* merge server configuration */

    ngx_http_mymodule_create_loc_conf,  /* create location configuration */
    ngx_http_mymodule_merge_loc_conf /* merge location configuration */
};

//--------------------------------------------------------------------------
// Описание модуля подсоединения к CoreManager
//----
ngx_module_t  ngx_http_mymodule_module = {
    NGX_MODULE_V1,
    &ngx_http_mymodule_module_ctx, /* module context */
    ngx_http_mymodule_commands,   /* module directives */
    NGX_HTTP_MODULE,               /* module type */
    NULL,                          /* init master */
    NULL,                          /* init module */
    NULL,                          /* init process */
    NULL,                          /* init thread */
    NULL,                          /* exit thread */
    NULL,                          /* exit process */
    NULL,                          /* exit master */
    NGX_MODULE_V1_PADDING
};

//--------------------------------------------------------------------------
//	Функция вызывается перед просмотром конфигурации и создаёт необходимые
//	структуры для хранения конфигурации.
//----
static void *
ngx_http_mymodule_create_loc_conf(ngx_conf_t *cf)
{
    ngx_http_mymodule_loc_conf_t  *conf;

    conf = ngx_pcalloc( cf->pool, sizeof(ngx_http_mymodule_loc_conf_t) );
    if( conf == NULL ) {
        return NGX_CONF_ERROR;
    }

	//	Конфигурация upstream'а
		conf->upstream.connect_timeout = NGX_CONF_UNSET_MSEC;
		conf->upstream.send_timeout = NGX_CONF_UNSET_MSEC;
		conf->upstream.read_timeout = NGX_CONF_UNSET_MSEC;

		conf->upstream.pass_request_headers = NGX_CONF_UNSET;
		conf->upstream.pass_request_body = NGX_CONF_UNSET;

    ngx_str_set(&conf->upstream.module, "mymodule");

    return conf;
}

//--------------------------------------------------------------------------

//	Функция вызывается при прочтении конфигурации, сливает параметры,
записанные
//	в конфигурации в нескольких местах, иначе выставляет параметрам значения
//	по умолчанию.
//--------------------------------------------------------------------------
static char *
ngx_http_mymodule_merge_loc_conf(ngx_conf_t *cf, void *parent, void *child)
{
    ngx_http_mymodule_loc_conf_t *prev = parent;
    ngx_http_mymodule_loc_conf_t *conf = child;

	//	Совмещение конфигурации upstream'а
		ngx_conf_merge_msec_value(conf->upstream.connect_timeout,
								  prev->upstream.connect_timeout, 60000);

		ngx_conf_merge_msec_value(conf->upstream.send_timeout,
								  prev->upstream.send_timeout, 60000);

		ngx_conf_merge_msec_value(conf->upstream.read_timeout,
								  prev->upstream.read_timeout, 60000);
		ngx_conf_merge_value(conf->upstream.pass_request_headers,
								  prev->upstream.pass_request_headers, 0);
		ngx_conf_merge_value(conf->upstream.pass_request_body,
								  prev->upstream.pass_request_body, 0);

    return NGX_CONF_OK;
}


//--------------------------------------------------------------------------
// Функция вызывается когда nginx "натыкается" на команду "mymodule" 
// при просмотре конфигурации в секции "location".
//----
static char* ngx_http_mymodule (ngx_conf_t *cf, ngx_command_t *cmd, void
*conf)
{
    ngx_http_mymodule_loc_conf_t *ispcf = conf;

    ngx_http_core_loc_conf_t   *clcf;

    clcf 		  = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module);
    clcf->handler = ngx_http_mymodule_upstream_handler;

    ngx_str_t  *value = cf->args->elts;

    ngx_url_t    u;
    ngx_memzero( &u, sizeof(ngx_url_t) );

    u.url 		 = value[1];
    u.no_resolve = 1;

    ispcf->upstream.upstream = ngx_http_upstream_add(cf, &u, 0);
    if( ispcf->upstream.upstream == NULL) {
        return NGX_CONF_ERROR;
    }

    return NGX_CONF_OK;
}

//--------------------------------------------------------------------------
//	Функция вызывается, сразу после обращения клиента к серверу
//----
static ngx_int_t ngx_http_mymodule_upstream_handler (ngx_http_request_t *r)
{
    if( ngx_http_upstream_create(r) != NGX_OK ) {
        return NGX_HTTP_INTERNAL_SERVER_ERROR;
    }

	ngx_http_mymodule_module_ctx_t * ctx 
		= ngx_pcalloc( r->pool, sizeof(ngx_http_mymodule_module_ctx_t ) );
    if( ctx == NULL ) {
        return NGX_ERROR;
    }
    ngx_http_set_ctx(r, ctx, ngx_http_mymodule_module);

	ngx_http_mymodule_loc_conf_t *plcf
		= ngx_http_get_module_loc_conf( r, ngx_http_mymodule_module );


    if (ngx_http_upstream_create(r) != NGX_OK) {
        return NGX_HTTP_INTERNAL_SERVER_ERROR;
    }

	ngx_http_upstream_t *u = r->upstream;
	
	u->peer.log			= r->connection->log;
	u->peer.log_error	= NGX_ERROR_ERR;
	u->output.tag 		= (ngx_buf_tag_t) &ngx_http_mymodule_module;
	u->conf 			= &plcf->upstream;

	u->create_request	= ngx_http_mymodule_proxy_create_request; 
	u->reinit_request	= ngx_http_mymodule_proxy_reinit_request; 
	u->process_header	= ngx_http_mymodule_proxy_process_header;
	u->abort_request	= ngx_http_mymodule_proxy_abort_request; 
	u->finalize_request	= ngx_http_mymodule_proxy_finalize_request;

	r->state = 0;
	r->upstream = u;
    u->buffering = 1;

	ngx_int_t rc = ngx_http_read_client_request_body( r, ngx_http_upstream_init
);

	if( rc >= NGX_HTTP_SPECIAL_RESPONSE ){
		return rc;
	}

	return NGX_DONE;
}

//--------------------------------------------------------------------------
//	Генерируем буферы для отправки в сокет
//---
ngx_int_t ngx_http_mymodule_proxy_create_request (ngx_http_request_t *r)
{
	ngx_http_upstream_t *up = r->upstream;

	//	Создаём цепочку буферов запроса
		if( up->request_bufs ){
			ngx_free_chain( r->pool, up->request_bufs );
		}
		up->request_bufs = ngx_alloc_chain_link( r->pool );
		up->request_bufs->buf = NULL;

	// Далее заполняем цепочку буферов //

	return NGX_OK;
}

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


From mdounin at mdounin.ru  Thu Sep 26 12:24:30 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 26 Sep 2013 16:24:30 +0400
Subject: =?UTF-8?B?UmU6INCT0LXQvdC10YDQsNGG0LjRjyDQvtGC0LLQtdGC0LAg0LTQu9GPINC60Ls=?=
 =?UTF-8?B?0LjQtdC90YLQsCDQuCDQsNGB0LjQvdGF0YDQvtC90L3Ri9C1INGB0L7QutC1?=
 =?UTF-8?B?0YLRiw==?=
In-Reply-To: <f1d3d6c66f14b967da7e751a715041c1.NginxMailingListRussian@forum.nginx.org>
References: <20130923152228.GG2170@mdounin.ru>
 <f1d3d6c66f14b967da7e751a715041c1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130926122430.GB2271@mdounin.ru>

Hello!

On Wed, Sep 25, 2013 at 11:36:44PM -0400, Aleus Essentia wrote:

> У Evan'а тоже не всё написано.

Никто не говорит, что там _всё_ описано.  Но если вы не знаете 
того, что там описано - это очевидный повод отложить попытки 
задавать вопросы до того момента, как вы это узнаете.

> Сейчас сделал отправку в сокет с
> ипользованием uptream'ов, по аналогии с модулемя FastCGI. 
> Но осталась одна проблема: после отправки в сокет upstream'а, в роли
> которого выступает наш внутренний сервер, нужно прикрывать соединение на
> запись с помощью shutdown( fd, 0 ). Подскажите куда мне его вставить?

В рамках реализации протокола для модуля upstream сделать это, 
насколько я понимаю, у вас не получится.  По крайней мере без 
изменений в ngx_http_upstream.c.  Именно поэтому я предлагал 
ознакомится с кодом, а не садиться писать реализацию протокола для 
upstream'а.

Если же делать аналог модуля upstream, то очевидное место - в 
ngx_http_upstream_send_request().

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


From michaelholzman at gmail.com  Thu Sep 26 19:02:12 2013
From: michaelholzman at gmail.com (Michael Holzman)
Date: Thu, 26 Sep 2013 21:02:12 +0200
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQuiDRgdGC0LDRgNGL0Lwg0L/RgNC+0LPRgNCw0Lw=?=
 =?UTF-8?B?0LzQuNGB0YLQsNC8OiDQstC40LfRg9Cw0LvRjNC90L7QtSDQv9GA0L7Qs9GA?=
 =?UTF-8?B?0LDQvNC40YDQvtCy0LDQvdC40LUgOik=?=
In-Reply-To: <CAL9wMxXnTwafz3BvFpDDZBDf4w3XpOMsgP0UWMHL+KB0Qe_qKQ@mail.gmail.com>
References: <CAL9wMxWct+ic2s2t9C76npWR1mEGB30wLE=v_uRvASoV0b9GdQ@mail.gmail.com>
 <975506965.20130925211058@softsearch.ru>
 <CAL9wMxXnTwafz3BvFpDDZBDf4w3XpOMsgP0UWMHL+KB0Qe_qKQ@mail.gmail.com>
Message-ID: <CAPNViJqg1iow6Jd6RJ+rFxBqFVwUxX-9nHbkE+PaDrjT1f6o9w@mail.gmail.com>

Извините, что вмешиваюсь, не будучи плотно знаком с nginx'ом.

Но, будучи старым программистом (примерно 30 лет в бизнесе) и работая
последние 8 лет с очень сложной системой, обладающей графическим
конфигуратором, могу только добавить свою подпись к сказанному
Михаилом.

Графический конфигуратор не делает систему проще. И не облегчает
работу с ней. Строго наоборот. Он добавляет сложности поскольку сам
должен быть весьма и весьма непрост. А его надо написать и
поддерживать. Плюс, в случае с nginx, это добавление в систему новых
зависимостей (GUI-то на чем-то писать надо!)

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

-- 
Regards,
    Michael Holzman

From chipitsine at gmail.com  Fri Sep 27 03:43:10 2013
From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=)
Date: Fri, 27 Sep 2013 09:43:10 +0600
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQuiDRgdGC0LDRgNGL0Lwg0L/RgNC+0LPRgNCw0Lw=?=
 =?UTF-8?B?0LzQuNGB0YLQsNC8OiDQstC40LfRg9Cw0LvRjNC90L7QtSDQv9GA0L7Qs9GA?=
 =?UTF-8?B?0LDQvNC40YDQvtCy0LDQvdC40LUgOik=?=
In-Reply-To: <CAL9wMxWct+ic2s2t9C76npWR1mEGB30wLE=v_uRvASoV0b9GdQ@mail.gmail.com>
References: <CAL9wMxWct+ic2s2t9C76npWR1mEGB30wLE=v_uRvASoV0b9GdQ@mail.gmail.com>
Message-ID: <CAFHpkQGaprUW9-t0RxFFUK+9yTf6qM3GJDBT-wWONdyG5ftUEA@mail.gmail.com>

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


например:   http://technet.microsoft.com/en-us/library/jj721573.aspx
или вот: "NGINX Plus supports on-the-fly reconfiguration through a simple HTTP-
based API. "

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

P.S. мопед не мой. мы пока только присматриваемся к технологии.

25 сентября 2013 г., 22:07 пользователь Dmitry Simonov
<dsimonov at gmail.com> написал:
> Вопрос к зубрам!
>
> Есть большая многокомпонентная система. Компоненты опираются друг на друга
> достаточно затейливыми конфигурированием, сам процесс которого нетривиален.
> То есть типичный выкат в бой с нуля ещё как-то реален, но быстрое
> динамическое переконфигурирование - задача не для слабонервных.
>
> Речь идёт не о типовых перестановках, которые конечно же можно
> запрограммировать. Например, есть несколько слегка отличающихся экземпляров
> одной и той же компоненты, которые последовательно подключаются одна за
> другой к общей системе и мы смотрим, как система взаимодействует с каждой из
> них.
>
> Весь опыт попыток подхода к этому снаряду показывает то, что любая система
> автоматизации подобного динамического переконфигурирования ОЧЕНЬ БЫСТРО
> устаревает (так как вся система растёт и развивается,
> меняются/добавляются/удаляются конфигурационные параметры) подобно тому, как
> устраревает документация.
>
> Тыщу лет назад мелькал кейс о том, как решать эту задачу. - путём обычного
> визуального конструктора похожего на лего или на пазл. С таким визуальным
> конструктором очень удобно быстро перекидывать связи между компонентами. И
> вроде бы кейс был достаточно удачен.
>
> Может ли кто-то что-то рассказать о своих подходах к этому "снаряду"?
> Пожалуйста, не рассказывайте мне о том, как это надо делать. Расскажите о
> том, как вы делали и на какие грабли наткнулись.
>
> ---
> Dmitriy V. Simonov,
> Perl & Python programmer
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From unlexx at gmail.com  Fri Sep 27 05:44:40 2013
From: unlexx at gmail.com (Un Lexx)
Date: Fri, 27 Sep 2013 11:44:40 +0600
Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQuiDRgdGC0LDRgNGL0Lwg0L/RgNC+0LPRgNCw0Lw=?=
 =?UTF-8?B?0LzQuNGB0YLQsNC8OiDQstC40LfRg9Cw0LvRjNC90L7QtSDQv9GA0L7Qs9GA?=
 =?UTF-8?B?0LDQvNC40YDQvtCy0LDQvdC40LUgOik=?=
In-Reply-To: <CAFHpkQGaprUW9-t0RxFFUK+9yTf6qM3GJDBT-wWONdyG5ftUEA@mail.gmail.com>
References: <CAL9wMxWct+ic2s2t9C76npWR1mEGB30wLE=v_uRvASoV0b9GdQ@mail.gmail.com>
 <CAFHpkQGaprUW9-t0RxFFUK+9yTf6qM3GJDBT-wWONdyG5ftUEA@mail.gmail.com>
Message-ID: <CAAnzuPObYUiQwYNfRYcH1u1wkm24iSGOA+ES=Ht7DNMwJ1ZN4g@mail.gmail.com>

я думаю что вместо того что бы сразу разрисовывать визуализацию следует
внедрить классификацию и категории
все равно без этого вам не добиться нормальной визуализации

а проверить успешность классификации компонентов можно например используя
систему дистрибуции linux будь то deb/rpm/etc
затем уже можно сделать форк от аптитуда и добавить графики.



27 сентября 2013 г., 9:43 пользователь Илья Шипицин
<chipitsine at gmail.com>написал:

> Есть модная тема - управление правилами публикации приложений из
> системы виртуализации
>
>
> например:   http://technet.microsoft.com/en-us/library/jj721573.aspx
> или вот: "NGINX Plus supports on-the-fly reconfiguration through a simple
> HTTP-
> based API. "
>
> ну то есть идея в том, что приложение само себе правила публикации
> настраивает.
>
> P.S. мопед не мой. мы пока только присматриваемся к технологии.
>
> 25 сентября 2013 г., 22:07 пользователь Dmitry Simonov
> <dsimonov at gmail.com> написал:
> > Вопрос к зубрам!
> >
> > Есть большая многокомпонентная система. Компоненты опираются друг на
> друга
> > достаточно затейливыми конфигурированием, сам процесс которого
> нетривиален.
> > То есть типичный выкат в бой с нуля ещё как-то реален, но быстрое
> > динамическое переконфигурирование - задача не для слабонервных.
> >
> > Речь идёт не о типовых перестановках, которые конечно же можно
> > запрограммировать. Например, есть несколько слегка отличающихся
> экземпляров
> > одной и той же компоненты, которые последовательно подключаются одна за
> > другой к общей системе и мы смотрим, как система взаимодействует с
> каждой из
> > них.
> >
> > Весь опыт попыток подхода к этому снаряду показывает то, что любая
> система
> > автоматизации подобного динамического переконфигурирования ОЧЕНЬ БЫСТРО
> > устаревает (так как вся система растёт и развивается,
> > меняются/добавляются/удаляются конфигурационные параметры) подобно тому,
> как
> > устраревает документация.
> >
> > Тыщу лет назад мелькал кейс о том, как решать эту задачу. - путём
> обычного
> > визуального конструктора похожего на лего или на пазл. С таким визуальным
> > конструктором очень удобно быстро перекидывать связи между компонентами.
> И
> > вроде бы кейс был достаточно удачен.
> >
> > Может ли кто-то что-то рассказать о своих подходах к этому "снаряду"?
> > Пожалуйста, не рассказывайте мне о том, как это надо делать. Расскажите о
> > том, как вы делали и на какие грабли наткнулись.
> >
> > ---
> > Dmitriy V. Simonov,
> > Perl & Python programmer
> >
> > _______________________________________________
> > 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/20130927/cd177e73/attachment.html>

From nginx-forum at nginx.us  Fri Sep 27 07:32:53 2013
From: nginx-forum at nginx.us (megalodon)
Date: Fri, 27 Sep 2013 03:32:53 -0400
Subject: =?UTF-8?B?0JrQvtCz0LTQsCDQvNC+0LbQtdGCINCy0L7Qt9C90LjQutC90YPRgtGMINGB0Lg=?=
 =?UTF-8?B?0YLRg9Cw0YbQuNGPLCDRh9GC0L4gcmV2LT5pbnN0YW5jZSAhPSBpbnN0YW5j?=
 =?UTF-8?B?ZT8=?=
Message-ID: <d431b5e954f9856b8825c5a964584c59.NginxMailingListRussian@forum.nginx.org>

Добрый день.

В функции ngx_epoll_process_events() есть такой участок кода:

for (i = 0; i < events; i++)  {
        c = event_list[i].data.ptr;

        instance = (uintptr_t) c & 1;
        c = (ngx_connection_t *) ((uintptr_t) c & (uintptr_t) ~1);

        rev = c->read;

        if (c->fd == -1 || rev->instance != instance)  { 
               ..... 
        }
        .....
}

Условие rev->instance != instance будет проверяться, если c->fd != -1, т.е.
в случае когда дескриптор не был закрыт. 
c->fd устанавливается в -1 в функциях: ngx_close_connection() и
ngx_close_accepted_connection(). 
Но rev->instance инвертируется в функции ngx_get_connection(), которая
вызывается в ngx_event_accept().

Получается, что несоответсвие instance возможно, когда мы не закрыли
соединение и при этом акцептировали новое и для него была выделена уже
существующая структура ngx_connection_t ??

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


From nginx-forum at nginx.us  Fri Sep 27 09:10:27 2013
From: nginx-forum at nginx.us (Vurtatoo)
Date: Fri, 27 Sep 2013 05:10:27 -0400
Subject: Nginx and Jboss AS
Message-ID: <b9470b0697e0ba7f8857b08e68284def.NginxMailingListRussian@forum.nginx.org>

Всем привет.
Как передать доменное имя джейбосу, и как его получить?
Сейчас сервер запущен как демон коммандой ./standalone.sh
 
Конфиг файл, вернее его часть
        location ~ /myapp/ {
                proxy_pass http://127.0.0.1:8080;
        }
пытался получить имя домена, по которому обращались , но получал 127.0.0.1
 
К приложению обращаются по разным урлам, от этоо зависит что показывать.
Например : http://nginx.org/myapp/ или http://dev.nginx.org/myapp/
 
 
На пхп всё работает и сервер передаёт.
там работает
fastcgi_param  SERVER_SOFTWARE

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


From nefer05 at gmail.com  Fri Sep 27 09:58:26 2013
From: nefer05 at gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=)
Date: Fri, 27 Sep 2013 13:58:26 +0400
Subject: Nginx and Jboss AS
In-Reply-To: <b9470b0697e0ba7f8857b08e68284def.NginxMailingListRussian@forum.nginx.org>
References: <b9470b0697e0ba7f8857b08e68284def.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAE-UrwjX1UCUG21viy27T94MOCANf6ogqcBhhDdON-yvVjieNQ@mail.gmail.com>

Дык установи заголовок Host в что тебе надо... :)


2013/9/27 Vurtatoo <nginx-forum at nginx.us>

> Всем привет.
> Как передать доменное имя джейбосу, и как его получить?
> Сейчас сервер запущен как демон коммандой ./standalone.sh
>
> Конфиг файл, вернее его часть
>         location ~ /myapp/ {
>                 proxy_pass http://127.0.0.1:8080;
>         }
> пытался получить имя домена, по которому обращались , но получал 127.0.0.1
>
> К приложению обращаются по разным урлам, от этоо зависит что показывать.
> Например : http://nginx.org/myapp/ или http://dev.nginx.org/myapp/
>
>
> На пхп всё работает и сервер передаёт.
> там работает
> fastcgi_param  SERVER_SOFTWARE
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,243184,243184#msg-243184
>
> _______________________________________________
> 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/20130927/dfaf3f87/attachment.html>

From vbart at nginx.com  Fri Sep 27 10:49:43 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Fri, 27 Sep 2013 14:49:43 +0400
Subject: =?UTF-8?B?UmU6INCa0L7Qs9C00LAg0LzQvtC20LXRgiDQstC+0LfQvdC40LrQvdGD0YLRjCA=?=
 =?UTF-8?B?0YHQuNGC0YPQsNGG0LjRjywg0YfRgtC+IHJldi0+aW5zdGFuY2UgIT0gaW5z?=
 =?UTF-8?B?dGFuY2U/?=
In-Reply-To: <d431b5e954f9856b8825c5a964584c59.NginxMailingListRussian@forum.nginx.org>
References: <d431b5e954f9856b8825c5a964584c59.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201309271449.44015.vbart@nginx.com>

On Friday 27 September 2013 11:32:53 megalodon wrote:
> Добрый день.
> 
> В функции ngx_epoll_process_events() есть такой участок кода:
> 
> for (i = 0; i < events; i++)  {
>         c = event_list[i].data.ptr;
> 
>         instance = (uintptr_t) c & 1;
>         c = (ngx_connection_t *) ((uintptr_t) c & (uintptr_t) ~1);
> 
>         rev = c->read;
> 
>         if (c->fd == -1 || rev->instance != instance)  {
>                .....
>         }
>         .....
> }
> 
> Условие rev->instance != instance будет проверяться, если c->fd != -1, т.е.
> в случае когда дескриптор не был закрыт.
> c->fd устанавливается в -1 в функциях: ngx_close_connection() и
> ngx_close_accepted_connection().
> Но rev->instance инвертируется в функции ngx_get_connection(), которая
> вызывается в ngx_event_accept().
> 
> Получается, что несоответсвие instance возможно, когда мы не закрыли
> соединение и при этом акцептировали новое и для него была выделена уже
> существующая структура ngx_connection_t ??
> 
[...]

Почему не закрыли?  Закрыли, отдали объект в пул свободных, а потом
он был использован для нового соединения (и соответсвенно fd не -1).

--
Валентин Бартенев
http://nginx.org/en/donation.html

From mdounin at mdounin.ru  Fri Sep 27 11:26:28 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 27 Sep 2013 15:26:28 +0400
Subject: =?UTF-8?B?UmU6INCa0L7Qs9C00LAg0LzQvtC20LXRgiDQstC+0LfQvdC40LrQvdGD0YLRjCA=?=
 =?UTF-8?B?0YHQuNGC0YPQsNGG0LjRjywg0YfRgtC+IHJldi0+aW5zdGFuY2UgIT0gaW5z?=
 =?UTF-8?B?dGFuY2U/?=
In-Reply-To: <d431b5e954f9856b8825c5a964584c59.NginxMailingListRussian@forum.nginx.org>
References: <d431b5e954f9856b8825c5a964584c59.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130927112628.GJ2271@mdounin.ru>

Hello!

On Fri, Sep 27, 2013 at 03:32:53AM -0400, megalodon wrote:

> Добрый день.
> 
> В функции ngx_epoll_process_events() есть такой участок кода:
> 
> for (i = 0; i < events; i++)  {
>         c = event_list[i].data.ptr;
> 
>         instance = (uintptr_t) c & 1;
>         c = (ngx_connection_t *) ((uintptr_t) c & (uintptr_t) ~1);
> 
>         rev = c->read;
> 
>         if (c->fd == -1 || rev->instance != instance)  { 
>                ..... 
>         }
>         .....
> }
> 
> Условие rev->instance != instance будет проверяться, если c->fd != -1, т.е.
> в случае когда дескриптор не был закрыт. 
> c->fd устанавливается в -1 в функциях: ngx_close_connection() и
> ngx_close_accepted_connection(). 
> Но rev->instance инвертируется в функции ngx_get_connection(), которая
> вызывается в ngx_event_accept().
> 
> Получается, что несоответсвие instance возможно, когда мы не закрыли
> соединение и при этом акцептировали новое и для него была выделена уже
> существующая структура ngx_connection_t ??

Несоответствие instance возможно, когда мы уже закрыли соединение, 
про которое нам сообщает ядро, и уже успели использовать структуру 
соединения заново для других целей.

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


From dmitry.shurupov at flant.ru  Fri Sep 27 12:29:50 2013
From: dmitry.shurupov at flant.ru (Dmitry Shurupov)
Date: Fri, 27 Sep 2013 16:29:50 +0400
Subject: =?UTF-8?B?W9CQ0L3QvtC90YFdINCc0L7QtNGD0LvRjCBuZ2lueC1odHRwLXJkbnM=?=
Message-ID: <52457A3E.20800@flant.ru>

Всем привет!


Представляю вниманию сообщества модуль nginx-http-rdns, реализующий 
простой механизм контроля доступа по доменному имени клиента (имя 
определяется по результатам выполнения обратного DNS-запроса).

Модуль nginx-http-rdns:
* выполняет преобразование IP-адреса клиента в доменное имя;
* позволяет создавать простые списки контроля доступа (разрешить / 
запретить) на основе полученного доменного имени;
* поддерживает модуль rewrite для динамического включения / выключения 
внутри директив if.

Используем в production уже продолжительное время ? помогает нам в 
борьбе с DDoS-атаками.

Документация на русском языке: http://flant.ru/projects/nginx-http-rdns
Документация на английском языке: http://wiki.nginx.org/HttpRdnsModule 
(она же есть в README на GitHub)

Проект на GitHub: https://github.com/flant/nginx-http-rdns
Будем рады патчам и сообщениям о багах.


-- 
Дмитрий Шурупов,
руководитель проектов ЗАО ?Флант?
http://flant.ru/
+7 (495) 721-10-27, доб. 442
+7 (926) 120-77-71


From ppb at valuehost.ru  Fri Sep 27 12:50:28 2013
From: ppb at valuehost.ru (Peter B. Pokryshev)
Date: Fri, 27 Sep 2013 16:50:28 +0400
Subject: =?UTF-8?B?UmU6IFvQkNC90L7QvdGBXSDQnNC+0LTRg9C70YwgbmdpbngtaHR0cC1yZG5z?=
In-Reply-To: <52457A3E.20800@flant.ru>
References: <52457A3E.20800@flant.ru>
Message-ID: <20130927165028.93d6cb7305a9871e33d2102c@valuehost.ru>

On Fri, 27 Sep 2013 16:29:50 +0400
Dmitry Shurupov <dmitry.shurupov at flant.ru> wrote:

> Всем привет!
> 
> 
> Представляю вниманию сообщества модуль nginx-http-rdns, реализующий 
> простой механизм контроля доступа по доменному имени клиента (имя 
> определяется по результатам выполнения обратного DNS-запроса).
> 
> Модуль nginx-http-rdns:
> * выполняет преобразование IP-адреса клиента в доменное имя;
> * позволяет создавать простые списки контроля доступа (разрешить / 
> запретить) на основе полученного доменного имени;
> * поддерживает модуль rewrite для динамического включения / выключения 
> внутри директив if.
> 
> Используем в production уже продолжительное время ? помогает нам в 
> борьбе с DDoS-атаками.
> 

Привет. Нет обратки - значит бот?

> Документация на русском языке: http://flant.ru/projects/nginx-http-rdns
> Документация на английском языке: http://wiki.nginx.org/HttpRdnsModule 
> (она же есть в README на GitHub)
> 
> Проект на GitHub: https://github.com/flant/nginx-http-rdns
> Будем рады патчам и сообщениям о багах.
> 
> 
> -- 
> Дмитрий Шурупов,
> руководитель проектов ЗАО ?Флант?
> http://flant.ru/
> +7 (495) 721-10-27, доб. 442
> +7 (926) 120-77-71
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From dmitry.shurupov at flant.ru  Fri Sep 27 12:52:40 2013
From: dmitry.shurupov at flant.ru (Dmitry Shurupov)
Date: Fri, 27 Sep 2013 16:52:40 +0400
Subject: =?UTF-8?B?UmU6IFvQkNC90L7QvdGBXSDQnNC+0LTRg9C70YwgbmdpbngtaHR0cC1yZG5z?=
In-Reply-To: <20130927165028.93d6cb7305a9871e33d2102c@valuehost.ru>
References: <52457A3E.20800@flant.ru>
 <20130927165028.93d6cb7305a9871e33d2102c@valuehost.ru>
Message-ID: <52457F98.2020000@flant.ru>

On 27.09.2013 16:50, Peter B. Pokryshev wrote:
> Привет. Нет обратки - значит бот?
Далеко не факт. Например, помогает (вместе с лимитами по количеству 
запросов) делать исключения для поисковых ботов и других известных служб.

-- 
Дмитрий Шурупов,
руководитель проектов ЗАО ?Флант?
http://flant.ru/
+7 (495) 721-10-27, доб. 442
+7 (926) 120-77-71


From ppb at valuehost.ru  Fri Sep 27 13:02:52 2013
From: ppb at valuehost.ru (Peter B. Pokryshev)
Date: Fri, 27 Sep 2013 17:02:52 +0400
Subject: =?UTF-8?B?UmU6IFvQkNC90L7QvdGBXSDQnNC+0LTRg9C70YwgbmdpbngtaHR0cC1yZG5z?=
In-Reply-To: <52457F98.2020000@flant.ru>
References: <52457A3E.20800@flant.ru>
 <20130927165028.93d6cb7305a9871e33d2102c@valuehost.ru>
 <52457F98.2020000@flant.ru>
Message-ID: <20130927170252.880269f7d68f3be48d105b44@valuehost.ru>

On Fri, 27 Sep 2013 16:52:40 +0400
Dmitry Shurupov <dmitry.shurupov at flant.ru> wrote:

> On 27.09.2013 16:50, Peter B. Pokryshev wrote:
> > Привет. Нет обратки - значит бот?
> Далеко не факт. 

Я про тоже, а в чем защита от ддоса?
Вот от ддоса:
https://github.com/kyprizel/testcookie-nginx-module

>Например, помогает (вместе с лимитами по количеству 
> запросов) делать исключения для поисковых ботов и других известных служб.
> 
> -- 
> Дмитрий Шурупов,
> руководитель проектов ЗАО ?Флант?
> http://flant.ru/
> +7 (495) 721-10-27, доб. 442
> +7 (926) 120-77-71
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

^^^^^^^^^^^^^^ 
С уважением,
Пётр Покрышев
ValueHost


From dmitry.shurupov at flant.ru  Fri Sep 27 13:07:36 2013
From: dmitry.shurupov at flant.ru (Dmitry Shurupov)
Date: Fri, 27 Sep 2013 17:07:36 +0400
Subject: =?UTF-8?B?UmU6IFvQkNC90L7QvdGBXSDQnNC+0LTRg9C70YwgbmdpbngtaHR0cC1yZG5z?=
In-Reply-To: <20130927170252.880269f7d68f3be48d105b44@valuehost.ru>
References: <52457A3E.20800@flant.ru>
 <20130927165028.93d6cb7305a9871e33d2102c@valuehost.ru>
 <52457F98.2020000@flant.ru>
 <20130927170252.880269f7d68f3be48d105b44@valuehost.ru>
Message-ID: <52458318.5020203@flant.ru>

On 27.09.2013 17:02, Peter B. Pokryshev wrote:
> Я про тоже, а в чем защита от ддоса?
> Вот от ддоса:
> https://github.com/kyprizel/testcookie-nginx-module
Да, этим мы тоже пользуемся :-)
Нет утверждений, что nginx-http-rdns ? самодостоточное решение защиты от 
DDoS'а. Может использоваться как одна из ?шестеренок? в комплексной 
системе защиты (в комбинации с различными средствами).

-- 
Дмитрий Шурупов,
руководитель проектов ЗАО ?Флант?
http://flant.ru/
+7 (495) 721-10-27, доб. 442
+7 (926) 120-77-71


From nginx-forum at nginx.us  Fri Sep 27 15:32:20 2013
From: nginx-forum at nginx.us (megalodon)
Date: Fri, 27 Sep 2013 11:32:20 -0400
Subject: =?UTF-8?B?UmU6INCa0L7Qs9C00LAg0LzQvtC20LXRgiDQstC+0LfQvdC40LrQvdGD0YLRjCA=?=
 =?UTF-8?B?0YHQuNGC0YPQsNGG0LjRjywg0YfRgtC+IHJldi0+aW5zdGFuY2UgIT0gaW5z?=
 =?UTF-8?B?dGFuY2U/?=
In-Reply-To: <20130927112628.GJ2271@mdounin.ru>
References: <20130927112628.GJ2271@mdounin.ru>
Message-ID: <d992b3ac91e1be19cb49532f661e41cb.NginxMailingListRussian@forum.nginx.org>

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

Ход событий в общем: воркер блокируется на epoll_wait(), по истечении
тайм-аута либо по получении nevent событий, воркер просыпается и в цикле
перебирает эти события. Допустим, встретилось событие на чтение и recv()
вернуло 0, мы закрываем соединение, при этом дескриптор удаляется из
структур подсистемы epoll, также в массив cycle->free_connections
возвращается структура ngx_connection_t. 

Я не понимаю такой момент: почему ядро потом может вернуть событие для уже
закрытого сокета?

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


From mdounin at mdounin.ru  Fri Sep 27 15:51:40 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 27 Sep 2013 19:51:40 +0400
Subject: =?UTF-8?B?UmU6INCa0L7Qs9C00LAg0LzQvtC20LXRgiDQstC+0LfQvdC40LrQvdGD0YLRjCA=?=
 =?UTF-8?B?0YHQuNGC0YPQsNGG0LjRjywg0YfRgtC+IHJldi0+aW5zdGFuY2UgIT0gaW5z?=
 =?UTF-8?B?dGFuY2U/?=
In-Reply-To: <d992b3ac91e1be19cb49532f661e41cb.NginxMailingListRussian@forum.nginx.org>
References: <20130927112628.GJ2271@mdounin.ru>
 <d992b3ac91e1be19cb49532f661e41cb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130927155140.GO2271@mdounin.ru>

Hello!

On Fri, Sep 27, 2013 at 11:32:20AM -0400, megalodon wrote:

> Но после закрытия дескриптора, ядро автоматически удалит этот дескриптор из
> своих структур и не будет по нему отслеживать события. 
> 
> Ход событий в общем: воркер блокируется на epoll_wait(), по истечении
> тайм-аута либо по получении nevent событий, воркер просыпается и в цикле
> перебирает эти события. Допустим, встретилось событие на чтение и recv()
> вернуло 0, мы закрываем соединение, при этом дескриптор удаляется из
> структур подсистемы epoll, также в массив cycle->free_connections
> возвращается структура ngx_connection_t. 
> 
> Я не понимаю такой момент: почему ядро потом может вернуть событие для уже
> закрытого сокета?

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

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

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


From vbart at nginx.com  Fri Sep 27 15:52:14 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Fri, 27 Sep 2013 19:52:14 +0400
Subject: =?UTF-8?B?UmU6INCa0L7Qs9C00LAg0LzQvtC20LXRgiDQstC+0LfQvdC40LrQvdGD0YLRjCA=?=
 =?UTF-8?B?0YHQuNGC0YPQsNGG0LjRjywg0YfRgtC+IHJldi0+aW5zdGFuY2UgIT0gaW5z?=
 =?UTF-8?B?dGFuY2U/?=
In-Reply-To: <d992b3ac91e1be19cb49532f661e41cb.NginxMailingListRussian@forum.nginx.org>
References: <20130927112628.GJ2271@mdounin.ru>
 <d992b3ac91e1be19cb49532f661e41cb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201309271952.14209.vbart@nginx.com>

On Friday 27 September 2013 19:32:20 megalodon wrote:
> Но после закрытия дескриптора, ядро автоматически удалит этот дескриптор из
> своих структур и не будет по нему отслеживать события.
> 
> Ход событий в общем: воркер блокируется на epoll_wait(), по истечении
> тайм-аута либо по получении nevent событий, воркер просыпается и в цикле
> перебирает эти события. Допустим, встретилось событие на чтение и recv()
> вернуло 0, мы закрываем соединение, при этом дескриптор удаляется из
> структур подсистемы epoll, также в массив cycle->free_connections
> возвращается структура ngx_connection_t.
> 
> Я не понимаю такой момент: почему ядро потом может вернуть событие для уже
> закрытого сокета?
> 

Оно его уже вернуло, ещё до закрытия.  Там есть комментарий:

 /*
  * the stale event from a file descriptor
  * that was just closed in this iteration
  */

Ключевой момент тут "this iteration", вся речь идет о текущей итерации обработки 
событий.

Мы могли закрыть соединение до того, как добрались до обработки событий,
с ним связанных (первая проверка).  Могли закрыть соединение на read-событии,
а следом у нас идет write (вторая проверка).

--
Валентин Бартенев
http://nginx.org/en/donation.html

From nginx-forum at nginx.us  Fri Sep 27 16:15:46 2013
From: nginx-forum at nginx.us (VBart)
Date: Fri, 27 Sep 2013 12:15:46 -0400
Subject: leaky bucket limit_req
In-Reply-To: <fa79e94b9c8980483f9e7285012d5524.NginxMailingListRussian@forum.nginx.org>
References: <20091001153140.GD53184@rambler-co.ru>
 <fa79e94b9c8980483f9e7285012d5524.NginxMailingListRussian@forum.nginx.org>
Message-ID: <a3b6af9364734d8f50795ed0996335c1.NginxMailingListRussian@forum.nginx.org>

> Получается, что если в течение 1мс пришли 2 запроса, то второй будет
дропнут,
> даже если в конфиге будет прописано 2000r/s?

Только при условии, что burst был исчерпан.

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


From nginx-forum at nginx.us  Fri Sep 27 16:45:27 2013
From: nginx-forum at nginx.us (megalodon)
Date: Fri, 27 Sep 2013 12:45:27 -0400
Subject: =?UTF-8?B?UmU6INCa0L7Qs9C00LAg0LzQvtC20LXRgiDQstC+0LfQvdC40LrQvdGD0YLRjCA=?=
 =?UTF-8?B?0YHQuNGC0YPQsNGG0LjRjywg0YfRgtC+IHJldi0+aW5zdGFuY2UgIT0gaW5z?=
 =?UTF-8?B?dGFuY2U/?=
In-Reply-To: <201309271952.14209.vbart@nginx.com>
References: <201309271952.14209.vbart@nginx.com>
Message-ID: <dfd7000d5e9851a11c1ebe69f493fca3.NginxMailingListRussian@forum.nginx.org>

Пытаюсь вникнуть в мысль: "Мы могли закрыть соединение до того, как
добрались до обработки событий". Но где в промежутке между epoll_wait() и
итерацией цикла, в которой мы обрабатываем событие то место, где мы можем
потенциально закрыть сокет?

    events = epoll_wait(ep, event_list, (int) nevents, timer);

    err = (events == -1) ? ngx_errno : 0;

    if (flags & NGX_UPDATE_TIME || ngx_event_timer_alarm) {
        ngx_time_update();
    }

    if (err) {
    .....
    }

    if (events == 0) {
       .....
    }

    ngx_mutex_lock(ngx_posted_events_mutex);

    for (i = 0; i < events; i++) {
        c = event_list[i].data.ptr;

        instance = (uintptr_t) c & 1;
        c = (ngx_connection_t *) ((uintptr_t) c & (uintptr_t) ~1);

        rev = c->read;

        if (c->fd == -1 || rev->instance != instance) {

Если c->fd не равно -1 и если  rev->instance не совпадает с instance, то
получается, что где-то между строками    
 events = epoll_wait(ep, event_list, (int) nevents, timer);   и   
   .....
 if (c->fd == -1 || rev->instance != instance) { 
произошло инвертирование этого поля?


"Несоответствие instance возможно, когда мы уже закрыли соединение, про
которое нам сообщает ядро." Получается, что пока процесс спал, будучи
заблокированным на шаге epoll_wait(), каким-то образом сокет закрылся и
структура ngx_connection_t была использована повторно, но как, ведь процесс
был заблокирован?

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


From vbart at nginx.com  Fri Sep 27 17:06:14 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Fri, 27 Sep 2013 21:06:14 +0400
Subject: =?UTF-8?B?UmU6INCa0L7Qs9C00LAg0LzQvtC20LXRgiDQstC+0LfQvdC40LrQvdGD0YLRjCA=?=
 =?UTF-8?B?0YHQuNGC0YPQsNGG0LjRjywg0YfRgtC+IHJldi0+aW5zdGFuY2UgIT0gaW5z?=
 =?UTF-8?B?dGFuY2U/?=
In-Reply-To: <dfd7000d5e9851a11c1ebe69f493fca3.NginxMailingListRussian@forum.nginx.org>
References: <201309271952.14209.vbart@nginx.com>
 <dfd7000d5e9851a11c1ebe69f493fca3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201309272106.14141.vbart@nginx.com>

On Friday 27 September 2013 20:45:27 megalodon wrote:
> Пытаюсь вникнуть в мысль: "Мы могли закрыть соединение до того, как
> добрались до обработки событий". Но где в промежутке между epoll_wait() и
> итерацией цикла, в которой мы обрабатываем событие то место, где мы можем
> потенциально закрыть сокет?

"событий, с ним связанных"

[...]
> 
>     for (i = 0; i < events; i++) {
>         c = event_list[i].data.ptr;
> 
>         instance = (uintptr_t) c & 1;
>         c = (ngx_connection_t *) ((uintptr_t) c & (uintptr_t) ~1);
> 
>         rev = c->read;
> 
>         if (c->fd == -1 || rev->instance != instance) {
> 
> Если c->fd не равно -1 и если  rev->instance не совпадает с instance, то
> получается, что где-то между строками
>  events = epoll_wait(ep, event_list, (int) nevents, timer);   и
>    .....
>  if (c->fd == -1 || rev->instance != instance) {
> произошло инвертирование этого поля?
> 

Между этими строками ещё происходят итерации цикла, которые итерирует
по другим событиям, возвращенным из epoll_wait().

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

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

> 
> "Несоответствие instance возможно, когда мы уже закрыли соединение, про
> которое нам сообщает ядро." Получается, что пока процесс спал, будучи
> заблокированным на шаге epoll_wait(), каким-то образом сокет закрылся и
> структура ngx_connection_t была использована повторно, но как, ведь процесс
> был заблокирован?
> 

Нет, не так.  Максим в своем ответе уже привел пример.  Смотрите и мой выше.  
Соединение могло быть закрыто, а равно как открыто другое соединение при 
обработки других событий в цикле.

--
Валентин Бартенев
http://nginx.org/en/donation.html

From nginx-forum at nginx.us  Fri Sep 27 17:26:13 2013
From: nginx-forum at nginx.us (megalodon)
Date: Fri, 27 Sep 2013 13:26:13 -0400
Subject: =?UTF-8?B?UmU6INCa0L7Qs9C00LAg0LzQvtC20LXRgiDQstC+0LfQvdC40LrQvdGD0YLRjCA=?=
 =?UTF-8?B?0YHQuNGC0YPQsNGG0LjRjywg0YfRgtC+IHJldi0+aW5zdGFuY2UgIT0gaW5z?=
 =?UTF-8?B?dGFuY2U/?=
In-Reply-To: <201309272106.14141.vbart@nginx.com>
References: <201309272106.14141.vbart@nginx.com>
Message-ID: <588b2cfefb0d4983491c7e6402e62cdf.NginxMailingListRussian@forum.nginx.org>

Все, осознал: воркер, получив очередной event_list[] и обрабатывая некоторое
событие может закрыть также и другой дескриптор, связанный с обрабатываемым,
причем событие с этого другого закрываемого дескриптора также могло попасть
в этот event_list[], и пока мы до него доберемся, структура, которая была
связана с ним может быть уже использована под новое соединение.

Спасибо всем!!!

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


From vbart at nginx.com  Fri Sep 27 17:28:46 2013
From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=)
Date: Fri, 27 Sep 2013 21:28:46 +0400
Subject: =?UTF-8?B?UmU6INCa0L7Qs9C00LAg0LzQvtC20LXRgiDQstC+0LfQvdC40LrQvdGD0YLRjCA=?=
 =?UTF-8?B?0YHQuNGC0YPQsNGG0LjRjywg0YfRgtC+IHJldi0+aW5zdGFuY2UgIT0gaW5z?=
 =?UTF-8?B?dGFuY2U/?=
In-Reply-To: <588b2cfefb0d4983491c7e6402e62cdf.NginxMailingListRussian@forum.nginx.org>
References: <201309272106.14141.vbart@nginx.com>
 <588b2cfefb0d4983491c7e6402e62cdf.NginxMailingListRussian@forum.nginx.org>
Message-ID: <201309272128.46520.vbart@nginx.com>

On Friday 27 September 2013 21:26:13 megalodon wrote:
> Все, осознал: воркер, получив очередной event_list[] и обрабатывая
> некоторое событие может закрыть также и другой дескриптор, связанный с
> обрабатываемым, причем событие с этого другого закрываемого дескриптора
> также могло попасть в этот event_list[], и пока мы до него доберемся,
> структура, которая была связана с ним может быть уже использована под
> новое соединение.

Именно так.

--
Валентин Бартенев
http://nginx.org/en/donation.html

From nginx-forum at nginx.us  Sat Sep 28 07:12:27 2013
From: nginx-forum at nginx.us (Vurtatoo)
Date: Sat, 28 Sep 2013 03:12:27 -0400
Subject: Nginx and Jboss AS
In-Reply-To: <CAE-UrwjX1UCUG21viy27T94MOCANf6ogqcBhhDdON-yvVjieNQ@mail.gmail.com>
References: <CAE-UrwjX1UCUG21viy27T94MOCANf6ogqcBhhDdON-yvVjieNQ@mail.gmail.com>
Message-ID: <b71effb699acb979aabc1e0040bc454c.NginxMailingListRussian@forum.nginx.org>

Было бы круто, если Вы покажете пример, буду рад.

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


From sargaskn at gmail.com  Sat Sep 28 07:35:10 2013
From: sargaskn at gmail.com (Sargas)
Date: Sat, 28 Sep 2013 10:35:10 +0300
Subject: Nginx and Jboss AS
In-Reply-To: <b71effb699acb979aabc1e0040bc454c.NginxMailingListRussian@forum.nginx.org>
References: <CAE-UrwjX1UCUG21viy27T94MOCANf6ogqcBhhDdON-yvVjieNQ@mail.gmail.com>
 <b71effb699acb979aabc1e0040bc454c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CANA-tsnbSgikueJbfmVfgEXNayH8J8StNRV16pAe=rTU39Vfbg@mail.gmail.com>

        location ~ /myapp/ {
                proxy_pass http://127.0.0.1:8080;
                proxy_set_header Host $host;
        }

еще можно добавить

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

чтобы на бекенде видеть реальный ip юзера


28 сентября 2013 г., 10:12 пользователь Vurtatoo <nginx-forum at nginx.us>написал:

> Было бы круто, если Вы покажете пример, буду рад.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,243184,243225#msg-243225
>
> _______________________________________________
> 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/20130928/95da5c04/attachment.html>

From nginx-forum at nginx.us  Sat Sep 28 07:36:19 2013
From: nginx-forum at nginx.us (Sargas)
Date: Sat, 28 Sep 2013 03:36:19 -0400
Subject: Nginx and Jboss AS
In-Reply-To: <b71effb699acb979aabc1e0040bc454c.NginxMailingListRussian@forum.nginx.org>
References: <CAE-UrwjX1UCUG21viy27T94MOCANf6ogqcBhhDdON-yvVjieNQ@mail.gmail.com>
 <b71effb699acb979aabc1e0040bc454c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <b7efa715f0034ee3651ad0dfb3d131f0.NginxMailingListRussian@forum.nginx.org>

location ~ /myapp/ {
                proxy_pass http://127.0.0.1:8080;
                proxy_set_header Host $host;
        }

еще можно добавить

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

чтобы на бекенде видеть реальный ip юзера

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


From nginx-forum at nginx.us  Sun Sep 29 08:08:15 2013
From: nginx-forum at nginx.us (MaxNikitin)
Date: Sun, 29 Sep 2013 04:08:15 -0400
Subject: =?UTF-8?B?0J7RiNC40LHQutCwINC/0YDQuCDQutC+0LzQv9C40LvRj9GG0LjQuCDRgSBpbWFn?=
 =?UTF-8?B?ZSBmaWx0ZXIgbW9kdWxlIChsaWJnZCDRgdGC0L7QuNGCISk=?=
Message-ID: <a17426d38dcd76efb15bebc27192ae5f.NginxMailingListRussian@forum.nginx.org>

Здравствуйте. Скачал последнюю версию libgd (2.1.0), скомпилировал
(настройки по умолчанию), запускаю ./configire
--with-http_image_filter_module (версия исходников nginx - 1.5.5) - ошибок
не выдает (checking for GD library ... found), однако, при запуске make
вылезает ошибка:
 objs/ngx_modules.o \
        -lpthread -lcrypt -lpcre -lssl -lcrypto -ldl -lz -lgd
objs/src/http/modules/ngx_http_image_filter_module.o: In function
`ngx_http_image_source':
/root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1030: undefined
reference to `gdImageCreateFromJpegPtr'
/root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1040: undefined
reference to `gdImageCreateFromPngPtr'
objs/src/http/modules/ngx_http_image_filter_module.o: In function
`ngx_http_image_out':
/root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1106: undefined
reference to `gdImageJpegPtr'
/root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1116: undefined
reference to `gdImagePngPtr'
collect2: ld returned 1 exit status

Что я не так делаю?

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


From alex.hha at gmail.com  Sun Sep 29 13:40:38 2013
From: alex.hha at gmail.com (Alex Domoradov)
Date: Sun, 29 Sep 2013 16:40:38 +0300
Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQv9GA0Lgg0LrQvtC80L/QuNC70Y/RhtC40Lgg0YEg?=
 =?UTF-8?B?aW1hZ2UgZmlsdGVyIG1vZHVsZSAobGliZ2Qg0YHRgtC+0LjRgiEp?=
In-Reply-To: <a17426d38dcd76efb15bebc27192ae5f.NginxMailingListRussian@forum.nginx.org>
References: <a17426d38dcd76efb15bebc27192ae5f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAK90gp4Ra9mB9cCcmo59tYWBj2RLA+nfecNbJUeO-Px--SCELw@mail.gmail.com>

Что за система?

2013/9/29 MaxNikitin <nginx-forum at nginx.us>:
> Здравствуйте. Скачал последнюю версию libgd (2.1.0), скомпилировал
> (настройки по умолчанию), запускаю ./configire
> --with-http_image_filter_module (версия исходников nginx - 1.5.5) - ошибок
> не выдает (checking for GD library ... found), однако, при запуске make
> вылезает ошибка:
>  objs/ngx_modules.o \
>         -lpthread -lcrypt -lpcre -lssl -lcrypto -ldl -lz -lgd
> objs/src/http/modules/ngx_http_image_filter_module.o: In function
> `ngx_http_image_source':
> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1030: undefined
> reference to `gdImageCreateFromJpegPtr'
> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1040: undefined
> reference to `gdImageCreateFromPngPtr'
> objs/src/http/modules/ngx_http_image_filter_module.o: In function
> `ngx_http_image_out':
> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1106: undefined
> reference to `gdImageJpegPtr'
> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1116: undefined
> reference to `gdImagePngPtr'
> collect2: ld returned 1 exit status
>
> Что я не так делаю?
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,243240,243240#msg-243240
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From sytar.alex at gmail.com  Mon Sep 30 07:29:29 2013
From: sytar.alex at gmail.com (Aleksandr Sytar)
Date: Mon, 30 Sep 2013 11:29:29 +0400
Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQv9GA0Lgg0LrQvtC80L/QuNC70Y/RhtC40Lgg0YEg?=
 =?UTF-8?B?aW1hZ2UgZmlsdGVyIG1vZHVsZSAobGliZ2Qg0YHRgtC+0LjRgiEp?=
In-Reply-To: <a17426d38dcd76efb15bebc27192ae5f.NginxMailingListRussian@forum.nginx.org>
References: <a17426d38dcd76efb15bebc27192ae5f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKqRTSHygk3EVE0Avthsk6Ksbf_V4MAUEh4oyj=NbiGPZcaw0g@mail.gmail.com>

29 сентября 2013 г., 12:08 пользователь MaxNikitin
<nginx-forum at nginx.us>написал:

> Здравствуйте. Скачал последнюю версию libgd (2.1.0), скомпилировал
> (настройки по умолчанию), запускаю ./configire
> --with-http_image_filter_module (версия исходников nginx - 1.5.5) - ошибок
> не выдает (checking for GD library ... found), однако, при запуске make
> вылезает ошибка:
>  objs/ngx_modules.o \
>         -lpthread -lcrypt -lpcre -lssl -lcrypto -ldl -lz -lgd
> objs/src/http/modules/ngx_http_image_filter_module.o: In function
> `ngx_http_image_source':
> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1030:
> undefined
> reference to `gdImageCreateFromJpegPtr'
> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1040:
> undefined
> reference to `gdImageCreateFromPngPtr'
> objs/src/http/modules/ngx_http_image_filter_module.o: In function
> `ngx_http_image_out':
> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1106:
> undefined
> reference to `gdImageJpegPtr'
> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1116:
> undefined
> reference to `gdImagePngPtr'
> collect2: ld returned 1 exit status
>
> Что я не так делаю?
>


У вас заголовочные файлы стоят -  libgd-dev?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130930/702f75d5/attachment.html>

From alex.hha at gmail.com  Mon Sep 30 07:52:53 2013
From: alex.hha at gmail.com (Alex Domoradov)
Date: Mon, 30 Sep 2013 10:52:53 +0300
Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQv9GA0Lgg0LrQvtC80L/QuNC70Y/RhtC40Lgg0YEg?=
 =?UTF-8?B?aW1hZ2UgZmlsdGVyIG1vZHVsZSAobGliZ2Qg0YHRgtC+0LjRgiEp?=
In-Reply-To: <CAKqRTSHygk3EVE0Avthsk6Ksbf_V4MAUEh4oyj=NbiGPZcaw0g@mail.gmail.com>
References: <a17426d38dcd76efb15bebc27192ae5f.NginxMailingListRussian@forum.nginx.org>
 <CAKqRTSHygk3EVE0Avthsk6Ksbf_V4MAUEh4oyj=NbiGPZcaw0g@mail.gmail.com>
Message-ID: <CAK90gp6Q1kzwo4f_M5ZqBhsNEJEbQEpw-sAAy7vQxUhUKTHQDA@mail.gmail.com>

> У вас заголовочные файлы стоят -  libgd-dev?
ТС из исходников ставил libgd.

2013/9/30 Aleksandr Sytar <sytar.alex at gmail.com>:
>
>
>
> 29 сентября 2013 г., 12:08 пользователь MaxNikitin <nginx-forum at nginx.us>
> написал:
>
>> Здравствуйте. Скачал последнюю версию libgd (2.1.0), скомпилировал
>> (настройки по умолчанию), запускаю ./configire
>> --with-http_image_filter_module (версия исходников nginx - 1.5.5) - ошибок
>> не выдает (checking for GD library ... found), однако, при запуске make
>> вылезает ошибка:
>>  objs/ngx_modules.o \
>>         -lpthread -lcrypt -lpcre -lssl -lcrypto -ldl -lz -lgd
>> objs/src/http/modules/ngx_http_image_filter_module.o: In function
>> `ngx_http_image_source':
>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1030:
>> undefined
>> reference to `gdImageCreateFromJpegPtr'
>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1040:
>> undefined
>> reference to `gdImageCreateFromPngPtr'
>> objs/src/http/modules/ngx_http_image_filter_module.o: In function
>> `ngx_http_image_out':
>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1106:
>> undefined
>> reference to `gdImageJpegPtr'
>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1116:
>> undefined
>> reference to `gdImagePngPtr'
>> collect2: ld returned 1 exit status
>>
>> Что я не так делаю?
>
>
>
> У вас заголовочные файлы стоят -  libgd-dev?
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From alex.hha at gmail.com  Mon Sep 30 08:05:18 2013
From: alex.hha at gmail.com (Alex Domoradov)
Date: Mon, 30 Sep 2013 11:05:18 +0300
Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQv9GA0Lgg0LrQvtC80L/QuNC70Y/RhtC40Lgg0YEg?=
 =?UTF-8?B?aW1hZ2UgZmlsdGVyIG1vZHVsZSAobGliZ2Qg0YHRgtC+0LjRgiEp?=
In-Reply-To: <CAK90gp6Q1kzwo4f_M5ZqBhsNEJEbQEpw-sAAy7vQxUhUKTHQDA@mail.gmail.com>
References: <a17426d38dcd76efb15bebc27192ae5f.NginxMailingListRussian@forum.nginx.org>
 <CAKqRTSHygk3EVE0Avthsk6Ksbf_V4MAUEh4oyj=NbiGPZcaw0g@mail.gmail.com>
 <CAK90gp6Q1kzwo4f_M5ZqBhsNEJEbQEpw-sAAy7vQxUhUKTHQDA@mail.gmail.com>
Message-ID: <CAK90gp5PoEyk-MuiFLN2a3Hxie3oQGhx=-=ran8WQzAB360iRg@mail.gmail.com>

Просто при сборке надо явно указывать путь

# ./configure --with-http_image_filter_module
--with-cc-opt=-I/opt/libgd-2.1.0/include
--with-ld-opt=-L/opt/libgd-2.1.0/lib/
# make

# ldd objs/nginx | grep libgd
        libgd.so.3 => /opt/libgd-2.1.0/lib/libgd.so.3 (0x00007ff43af12000)

2 Developers
А почему nginx игнорирует CFLAGS/LDFLAGS? Т.е. если я делаю

# export CFLAGS=-I/opt/libgd-2.1.0/include/
# export LDFLAGS=-L/opt/libgd-2.1.0/lib/

а потом пробую собрать, то получаю ошибку

# ./configure --with-http_image_filter_module
...
checking for GD library ... not found
checking for GD library in /usr/local/ ... not found
checking for GD library in /usr/pkg/ ... not found
checking for GD library in /opt/local/ ... not found

2013/9/30 Alex Domoradov <alex.hha at gmail.com>:
>> У вас заголовочные файлы стоят -  libgd-dev?
> ТС из исходников ставил libgd.
>
> 2013/9/30 Aleksandr Sytar <sytar.alex at gmail.com>:
>>
>>
>>
>> 29 сентября 2013 г., 12:08 пользователь MaxNikitin <nginx-forum at nginx.us>
>> написал:
>>
>>> Здравствуйте. Скачал последнюю версию libgd (2.1.0), скомпилировал
>>> (настройки по умолчанию), запускаю ./configire
>>> --with-http_image_filter_module (версия исходников nginx - 1.5.5) - ошибок
>>> не выдает (checking for GD library ... found), однако, при запуске make
>>> вылезает ошибка:
>>>  objs/ngx_modules.o \
>>>         -lpthread -lcrypt -lpcre -lssl -lcrypto -ldl -lz -lgd
>>> objs/src/http/modules/ngx_http_image_filter_module.o: In function
>>> `ngx_http_image_source':
>>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1030:
>>> undefined
>>> reference to `gdImageCreateFromJpegPtr'
>>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1040:
>>> undefined
>>> reference to `gdImageCreateFromPngPtr'
>>> objs/src/http/modules/ngx_http_image_filter_module.o: In function
>>> `ngx_http_image_out':
>>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1106:
>>> undefined
>>> reference to `gdImageJpegPtr'
>>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1116:
>>> undefined
>>> reference to `gdImagePngPtr'
>>> collect2: ld returned 1 exit status
>>>
>>> Что я не так делаю?
>>
>>
>>
>> У вас заголовочные файлы стоят -  libgd-dev?
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From gmm at csdoc.com  Mon Sep 30 09:15:38 2013
From: gmm at csdoc.com (Gena Makhomed)
Date: Mon, 30 Sep 2013 12:15:38 +0300
Subject: Nginx and Jboss AS
In-Reply-To: <b7efa715f0034ee3651ad0dfb3d131f0.NginxMailingListRussian@forum.nginx.org>
References: <CAE-UrwjX1UCUG21viy27T94MOCANf6ogqcBhhDdON-yvVjieNQ@mail.gmail.com>
 <b71effb699acb979aabc1e0040bc454c.NginxMailingListRussian@forum.nginx.org>
 <b7efa715f0034ee3651ad0dfb3d131f0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5249413A.5010001@csdoc.com>

On 28.09.2013 10:36, Sargas wrote:

> еще можно добавить
>
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>
> чтобы на бекенде видеть реальный ip юзера

достаточно только первой строчки с установкой X-Real-IP.

модификация X-Forwarded-For может быть нужна в очень редких случаях.

-- 
Best regards,
  Gena


From ru at nginx.com  Mon Sep 30 09:51:31 2013
From: ru at nginx.com (Ruslan Ermilov)
Date: Mon, 30 Sep 2013 13:51:31 +0400
Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQv9GA0Lgg0LrQvtC80L/QuNC70Y/RhtC40Lgg0YEg?=
 =?UTF-8?B?aW1hZ2UgZmlsdGVyIG1vZHVsZSAobGliZ2Qg0YHRgtC+0LjRgiEp?=
In-Reply-To: <CAK90gp5PoEyk-MuiFLN2a3Hxie3oQGhx=-=ran8WQzAB360iRg@mail.gmail.com>
References: <a17426d38dcd76efb15bebc27192ae5f.NginxMailingListRussian@forum.nginx.org>
 <CAKqRTSHygk3EVE0Avthsk6Ksbf_V4MAUEh4oyj=NbiGPZcaw0g@mail.gmail.com>
 <CAK90gp6Q1kzwo4f_M5ZqBhsNEJEbQEpw-sAAy7vQxUhUKTHQDA@mail.gmail.com>
 <CAK90gp5PoEyk-MuiFLN2a3Hxie3oQGhx=-=ran8WQzAB360iRg@mail.gmail.com>
Message-ID: <20130930095131.GF49854@lo0.su>

On Mon, Sep 30, 2013 at 11:05:18AM +0300, Alex Domoradov wrote:
> Просто при сборке надо явно указывать путь
> 
> # ./configure --with-http_image_filter_module
> --with-cc-opt=-I/opt/libgd-2.1.0/include
> --with-ld-opt=-L/opt/libgd-2.1.0/lib/
> # make
> 
> # ldd objs/nginx | grep libgd
>         libgd.so.3 => /opt/libgd-2.1.0/lib/libgd.so.3 (0x00007ff43af12000)
> 
> 2 Developers
> А почему nginx игнорирует CFLAGS/LDFLAGS? Т.е. если я делаю
> 
> # export CFLAGS=-I/opt/libgd-2.1.0/include/
> # export LDFLAGS=-L/opt/libgd-2.1.0/lib/
> 
> а потом пробую собрать, то получаю ошибку
> 
> # ./configure --with-http_image_filter_module
> ...
> checking for GD library ... not found
> checking for GD library in /usr/local/ ... not found
> checking for GD library in /usr/pkg/ ... not found
> checking for GD library in /opt/local/ ... not found

Потому что configure nginx'а не поддерживает LDFLAGS.

> 2013/9/30 Alex Domoradov <alex.hha at gmail.com>:
> >> У вас заголовочные файлы стоят -  libgd-dev?
> > ТС из исходников ставил libgd.
> >
> > 2013/9/30 Aleksandr Sytar <sytar.alex at gmail.com>:
> >>
> >>
> >>
> >> 29 сентября 2013 г., 12:08 пользователь MaxNikitin <nginx-forum at nginx.us>
> >> написал:
> >>
> >>> Здравствуйте. Скачал последнюю версию libgd (2.1.0), скомпилировал
> >>> (настройки по умолчанию), запускаю ./configire
> >>> --with-http_image_filter_module (версия исходников nginx - 1.5.5) - ошибок
> >>> не выдает (checking for GD library ... found), однако, при запуске make
> >>> вылезает ошибка:
> >>>  objs/ngx_modules.o \
> >>>         -lpthread -lcrypt -lpcre -lssl -lcrypto -ldl -lz -lgd
> >>> objs/src/http/modules/ngx_http_image_filter_module.o: In function
> >>> `ngx_http_image_source':
> >>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1030:
> >>> undefined
> >>> reference to `gdImageCreateFromJpegPtr'
> >>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1040:
> >>> undefined
> >>> reference to `gdImageCreateFromPngPtr'
> >>> objs/src/http/modules/ngx_http_image_filter_module.o: In function
> >>> `ngx_http_image_out':
> >>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1106:
> >>> undefined
> >>> reference to `gdImageJpegPtr'
> >>> /root/nginx2/src/http/modules/ngx_http_image_filter_module.c:1116:
> >>> undefined
> >>> reference to `gdImagePngPtr'
> >>> collect2: ld returned 1 exit status
> >>>
> >>> Что я не так делаю?
> >>
> >>
> >>
> >> У вас заголовочные файлы стоят -  libgd-dev?
> >>
> >> _______________________________________________
> >> 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
> 

-- 
Ruslan Ermilov


From v.v.biriukov at gmail.com  Mon Sep 30 16:04:12 2013
From: v.v.biriukov at gmail.com (Viacheslav Biriukov)
Date: Mon, 30 Sep 2013 20:04:12 +0400
Subject: =?UTF-8?B?c3BsaXRfY2xpZW50cyDQuCDQtNC+0LHQsNCy0LvQtdC90LjQtSBnZXQg0L/QsNGA?=
 =?UTF-8?B?0LDQvNC10YLRgNCw?=
Message-ID: <CAPKsgQzR8eLg+ODZZAQ76Wo5gaMcLT4kJGUV-Ro4WP2jPSdgFQ@mail.gmail.com>

Привет,

В вики (которая я знаю, что не явлется офф документацией) нашёл, что с
помощью split_clients и set можно добавлять get параметр какому-то %
клиентов .
Но у меня такая конструкция не работает: не изменяет $args вообще никак.

http <http://wiki.nginx.org/NginxHttpCoreModule#http> {
    split_clients "${remote_addr}" $additionalQsVariable {
	    51% "coolVariable=1";
	    49% "";
	}

    server <http://wiki.nginx.org/NginxHttpCoreModule#server> {
        location <http://wiki.nginx.org/NginxHttpCoreModule#location> ~ \.php$ {
            set <http://wiki.nginx.org/NginxHttpRewriteModule#set>
$args "${query_string}&${additionalQsVariable}";
            proxy_pass http://127.0.0.1:8080;
        }
    }

nginx version: nginx/1.1.19
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-log-path=/var/log/nginx/access.log
--http-proxy-temp-path=/var/lib/nginx/proxy
--http-scgi-temp-path=/var/lib/nginx/scgi
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi
--lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug
--with-http_addition_module --with-http_dav_module --with-http_geoip_module
--with-http_gzip_static_module --with-http_image_filter_module
--with-http_realip_module --with-http_stub_status_module
--with-http_ssl_module --with-http_sub_module --with-http_xslt_module
--with-ipv6 --with-sha1=/usr/include/openssl
--with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module
--add-module=/build/buildd/nginx-1.1.19/debian/modules/nginx-auth-pam
--add-module=/build/buildd/nginx-1.1.19/debian/modules/nginx-echo
--add-module=/build/buildd/nginx-1.1.19/debian/modules/nginx-upstream-fair
--add-module=/build/buildd/nginx-1.1.19/debian/modules/nginx-dav-ext-module

Что я делаю не так? И как нужно делать?

Спасибо.

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

From nginx-forum at nginx.us  Mon Sep 30 21:09:59 2013
From: nginx-forum at nginx.us (MaxNikitin)
Date: Mon, 30 Sep 2013 17:09:59 -0400
Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQv9GA0Lgg0LrQvtC80L/QuNC70Y/RhtC40Lgg0YEg?=
 =?UTF-8?B?aW1hZ2UgZmlsdGVyIG1vZHVsZSAobGliZ2Qg0YHRgtC+0LjRgiEp?=
In-Reply-To: <CAK90gp5PoEyk-MuiFLN2a3Hxie3oQGhx=-=ran8WQzAB360iRg@mail.gmail.com>
References: <CAK90gp5PoEyk-MuiFLN2a3Hxie3oQGhx=-=ran8WQzAB360iRg@mail.gmail.com>
Message-ID: <e8e40ffe63a4b10da729d1b6820d5850.NginxMailingListRussian@forum.nginx.org>

Здравствуйте. Пробовал добавлять пути к исходникам (/root/libgd-2.1.0/src и
/root/libgd-2.1.0/src/.libs), добавлять путь, куда по умолчанию ставится
libgd (/usr/local/include и /usr/local/lib) - не помогает. При компиляции то
же самое сообщение.

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


From mdounin at mdounin.ru  Mon Sep 30 22:49:32 2013
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 1 Oct 2013 02:49:32 +0400
Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQv9GA0Lgg0LrQvtC80L/QuNC70Y/RhtC40Lgg0YEg?=
 =?UTF-8?B?aW1hZ2UgZmlsdGVyIG1vZHVsZSAobGliZ2Qg0YHRgtC+0LjRgiEp?=
In-Reply-To: <e8e40ffe63a4b10da729d1b6820d5850.NginxMailingListRussian@forum.nginx.org>
References: <CAK90gp5PoEyk-MuiFLN2a3Hxie3oQGhx=-=ran8WQzAB360iRg@mail.gmail.com>
 <e8e40ffe63a4b10da729d1b6820d5850.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20130930224931.GA62063@mdounin.ru>

Hello!

On Mon, Sep 30, 2013 at 05:09:59PM -0400, MaxNikitin wrote:

> Здравствуйте. Пробовал добавлять пути к исходникам (/root/libgd-2.1.0/src и
> /root/libgd-2.1.0/src/.libs), добавлять путь, куда по умолчанию ставится
> libgd (/usr/local/include и /usr/local/lib) - не помогает. При компиляции то
> же самое сообщение.

У вас библиотека libgd собралась без libpng / libjpeg.  При сборке 
libgd смотреть на:

: ** Configuration summary for libgd 2.1.0:
: 
:    Support for Zlib:                 yes
:    Support for PNG library:          no
:    Support for JPEG library:         no

И сделать так, чтобы в строках про "PNG library" и "JPEG library" 
стало "yes".  Тогда и nginx соберётся.

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