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: Наблюдаю интересную картину. При длинном $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: References: 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: Здравствуйте. Емнип, 400 ответ всегда логгируется в error log. Скорее всего ошибка попадает в лог того server, что является по-умолчанию для конкретной пары адрес:порт в listen. 1 сентября 2013 г., 14:31 пользователь locojohn написал: > Странно, но абсолютно ничего. Я бы написал если бы было чего. > > 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: 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: References: 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: <4456f58131d1f9d32f592c982af11e9b.NginxMailingListRussian@forum.nginx.org> Message-ID: Забыл сообщить, что использую 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: <4456f58131d1f9d32f592c982af11e9b.NginxMailingListRussian@forum.nginx.org> Message-ID: Это единственный сервер для listen 80? 2013/9/1 locojohn > /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: 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: References: Message-ID: > Это единственный сервер для 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: References: Message-ID: 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 > > Это единственный сервер для 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: 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: <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: >> >> >> 414 Request-URI Too Large >> >>

414 Request-URI Too Large

>>
nginx/1.2.9
>> >> > Это не "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: References: 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: 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: <4456f58131d1f9d32f592c982af11e9b.NginxMailingListRussian@forum.nginx.org> Message-ID: у вас ведь на php разработка? возможно, имеет смысл перенести логику управления сборками js и css на уровень php, например, вот при помощи такого https://github.com/kriswallsmith/assetic совешенно необязательно "вообще всё" делать на nginx-е. 2013/9/1 locojohn : > /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: Приветы всем! Тысячи раз уже слышал, что использовать 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: 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: <201309010057.12473.ne@vbart.ru> Message-ID: Амм... Спасибо за скорость и лаконичность. Судя по http://www.w3.org/Protocols/HTTP/HTRESP.html, в HTTP/0.9 тоже есть status codes, или я что то недопонимаю? Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK" 2013/8/31 Валентин Бартенев > On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote: > > Здравствуйте! > > > > Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414 > > status code, на запросы, размер которых, превышает large_client_header_ > > buffers? > > > > Постоянно получаю 200 http status code и нижеприведенное в body: > > > > > > 414 Request-URI Too Large > > > >

414 Request-URI Too Large

> >
nginx/1.2.9
> > > > > > Это не "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: 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: References: 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: References: Message-ID: > да и выяснить причину раз и навсегда куда полезнее, чем просто запомнить > постулат "скажем 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: References: <201309010057.12473.ne@vbart.ru> 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: <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: > >> > >> > >> 414 Request-URI Too Large > >> > >>

414 Request-URI Too Large

> >>
nginx/1.2.9
> >> > >> > > > > Это не "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: References: 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: <20130901234231.GI29448@mdounin.ru> Message-ID: <83031378083183@web24m.yandex.ru> Попытаюсь вклиниться в тему. Есть давно волнующий вопрос как раз на ряду с этими if-ами. Есть какой-то список директив, которые наследуются (или не наследуются) в location-ах из уровня выше и такой же для if-ов? Был бы крайне полезный материал, т.к. в голове всё удержать не выходит. 02.09.2013, 03:42, "Maxim Dounin" : > 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: <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: <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: > >> > >> > >> 414 Request-URI Too Large > >> > >>

414 Request-URI Too Large

> >>
nginx/1.2.9
> >> > >> > > > > Это не "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: 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: > Я даже и не знаю, что вам сказать русская халява - она такая 2013/9/2 Maxim Dounin : > 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: много всяких модных штук придумано, например, вот http://en.wikipedia.org/wiki/QUIC "двигатель" в данном вопросе всего один - клиентские каналы низкого качества (у tcp оверхед выше, на некачественных каналах это заметно), просто с ровного места никто не разбежится реализовывать новые протоколы, если всё вполне приемлимо работает на http/1.1 2 сентября 2013 г., 15:12 пользователь Vadim A. Misbakh-Soloviov написал: > Всем привет! :) > Я тут немного поковырялся в /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: References: Message-ID: В таком случае, если отрабатывает только последний из 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, необходимо > отправлять по адресу > 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 > 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 Валентин Бартенев > >> On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote: >> > Здравствуйте! >> > >> > Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414 >> > status code, на запросы, размер которых, превышает large_client_header_ >> > buffers? >> > >> > Постоянно получаю 200 http status code и нижеприведенное в body: >> > >> > >> > 414 Request-URI Too Large >> > >> >

414 Request-URI Too Large

>> >
nginx/1.2.9
>> > >> > >> >> Это не "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" > 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 > To: nginx-ru > 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: "Валентин Бартенев" > 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: "Валентин Бартенев" > 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: > > >> > > >> > > >> 414 Request-URI Too Large > > >> > > >>

414 Request-URI Too Large

> > >>
nginx/1.2.9
> > >> > > >> > > > > > > Это не "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 > 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!\" Олег" > To: "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" : > > 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 > 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: 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: References: Message-ID: В данной конфигурации нужно выкинуть все if и сделать map + if. Либо использовать allow+deny, как это обычно делают. 2013/9/2 Андрей Середенко : > В таком случае, если отрабатывает только последний из 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, необходимо >> отправлять по адресу >> 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 >> 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 Валентин Бартенев >>> >>> On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote: >>> > Здравствуйте! >>> > >>> > Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, 414 >>> > status code, на запросы, размер которых, превышает large_client_header_ >>> > buffers? >>> > >>> > Постоянно получаю 200 http status code и нижеприведенное в body: >>> > >>> > >>> > 414 Request-URI Too Large >>> > >>> >

414 Request-URI Too Large

>>> >
nginx/1.2.9
>>> > >>> > >>> >>> Это не "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" >> 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 >> To: nginx-ru >> 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: "Валентин Бартенев" >> 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: "Валентин Бартенев" >> 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: >> > >> >> > >> >> > >> 414 Request-URI Too Large >> > >> >> > >>

414 Request-URI Too Large

>> > >>
nginx/1.2.9
>> > >> >> > >> >> > > >> > > Это не "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 >> 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!\" Олег" >> To: "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" : >> > 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 >> 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: References: 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: References: Message-ID: Изначально if'ы задействовались исключительно ради желания отдать красивую 500-ю страничку вместо "forbidden". Потом еще потребовалось фильтровать доступ, основываясь на информации в заголовках (к примеру, анализировать $http_x_forwarded_for вместо $remote_addr).... Поэтому простой allow/deny уже не прокатывал. А использование if внутри map что, не таит в себе никаких неожиданностей? 2 сентября 2013 г., 12:44 пользователь написал: > Сообщения, предназначенные для списка рассылки 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" > 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 > To: nginx-ru > 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 Андрей Середенко : > > В таком случае, если отрабатывает только последний из 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, необходимо > >> отправлять по адресу > >> 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 > >> 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 Валентин Бартенев > >>> > >>> On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote: > >>> > Здравствуйте! > >>> > > >>> > Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, > 414 > >>> > status code, на запросы, размер которых, превышает > large_client_header_ > >>> > buffers? > >>> > > >>> > Постоянно получаю 200 http status code и нижеприведенное в body: > >>> > > >>> > > >>> > 414 Request-URI Too Large > >>> > > >>> >

414 Request-URI Too Large

> >>> >
nginx/1.2.9
> >>> > > >>> > > >>> > >>> Это не "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" > >> 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 > >> To: nginx-ru > >> 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: "Валентин Бартенев" > >> 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: "Валентин Бартенев" > >> 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: > >> > >> > >> > >> > >> > >> 414 Request-URI Too Large > >> > >> > >> > >>

414 Request-URI Too Large

> >> > >>
nginx/1.2.9
> >> > >> > >> > >> > >> > > > >> > > Это не "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 > >> 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!\" Олег" > >> To: "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" : > >> > 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 > >> 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: 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: References: Message-ID: Ух ты, а geo{}, похоже, именно то, что мне надо, спасибо! но тема if-сек все равно как-то не раскрыта, придется на досуге курить исходники.. 2 сентября 2013 г., 13:42 пользователь написал: > Сообщения, предназначенные для списка рассылки 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 > 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: "Андрей Середенко" > 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, необходимо >> отправлять по адресу >> 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" >> 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 >> To: nginx-ru >> 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 Андрей Середенко : >> > В таком случае, если отрабатывает только последний из 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, необходимо >> >> отправлять по адресу >> >> 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 >> >> 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 Валентин Бартенев >> >>> >> >>> On Sunday 01 September 2013 00:32:16 Vladimir Getmanshchuk wrote: >> >>> > Здравствуйте! >> >>> > >> >>> > Подскажите пожалуйста, а как без "грязных хаков" получить от nginx, >> 414 >> >>> > status code, на запросы, размер которых, превышает >> large_client_header_ >> >>> > buffers? >> >>> > >> >>> > Постоянно получаю 200 http status code и нижеприведенное в body: >> >>> > >> >>> > >> >>> > 414 Request-URI Too Large >> >>> > >> >>> >

414 Request-URI Too Large

>> >>> >
nginx/1.2.9
>> >>> > >> >>> > >> >>> >> >>> Это не "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" >> >> 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 >> >> To: nginx-ru >> >> 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: "Валентин Бартенев" >> >> 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: "Валентин Бартенев" >> >> 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: >> >> > >> >> >> > >> >> >> > >> 414 Request-URI Too Large >> >> > >> >> >> > >>

414 Request-URI Too Large

>> >> > >>
nginx/1.2.9
>> >> > >> >> >> > >> >> >> > > >> >> > > Это не "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 >> >> 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!\" Олег" >> >> To: "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" : >> >> > 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 >> >> 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: 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: <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: <201309010057.12473.ne@vbart.ru> <52233E0B.7020001@csdoc.com> <201309020800.09622.vbart@nginx.com> <52248960.7030403@csdoc.com> Message-ID: Здорово! Но не повлияет ли это на производительность? Спасибо! 2013/9/2 Gena Makhomed > On 02.09.2013 7:00, Валентин Бартенев wrote: > > > JFYI, 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 > -- Yours sincerely, Vladimir Getmanshchuk -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <52248960.7030403@csdoc.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: References: 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 () { 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: Максим, спасибо. 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: Всем спасибо, простите, что плохо умею читать. 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: <52248960.7030403@csdoc.com> <201309021703.45220.vbart@nginx.com> Message-ID: Все одно получаю 200й код. 2013/9/2 Валентин Бартенев > 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: 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: Приветствую. Подскажите, пожалуйста как переписать апачевские реврайты 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: 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: References: <52248960.7030403@csdoc.com> <201309021703.45220.vbart@nginx.com> Message-ID: Даже идиотизм типа: 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 > Все одно получаю 200й код. > > > 2013/9/2 Валентин Бартенев > >> 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: 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: References: 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 # 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: Отлично, спасибо, Максим! 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: References: <20130903144105.GN65634@mdounin.ru> Message-ID: Разрешите задать еще один вопрос: В логе есть такие записи: 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: References: <20130903144105.GN65634@mdounin.ru> 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: Дорбрый день. Помогите, пожалуйста, разобраться с отдачей .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: References: 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: References: Message-ID: Сейчас используется if (!-e $request_filename) { rewrite ^/(.*)\.(php|html)$ /index.php?key=$1 break; } Хочется без if'а 4 сентября 2013 г., 3:25 пользователь Sargas написал: > Приветствую. > > Подскажите, пожалуйста как переписать апачевские реврайты > > 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: 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: <201309041451.01947.vbart@nginx.com> Message-ID: Спасибо починилось. Пусть тут полежит: --- 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, Валентин Бартенев 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 > # 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: 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: References: Message-ID: location "^/(?.*)\.(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 : > Сейчас используется > > if (!-e $request_filename) { > rewrite ^/(.*)\.(php|html)$ /index.php?key=$1 break; > } > > Хочется без if'а > > > > 4 сентября 2013 г., 3:25 пользователь Sargas написал: > >> Приветствую. >> >> Подскажите, пожалуйста как переписать апачевские реврайты >> >> 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: > 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: References: Message-ID: Спасибо, но не работает. 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 "^/(?.*)\.(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 : > > Сейчас используется > > > > if (!-e $request_filename) { > > rewrite ^/(.*)\.(php|html)$ /index.php?key=$1 break; > > } > > > > Хочется без if'а > > > > > > > > 4 сентября 2013 г., 3:25 пользователь Sargas > написал: > > > >> Приветствую. > >> > >> Подскажите, пожалуйста как переписать апачевские реврайты > >> > >> 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: 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: References: Message-ID: > 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: References: Message-ID: Используется последний 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 написал: > > 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: 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: References: Message-ID: > Используется последний 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: References: Message-ID: Разобрался. Нужно было тильду добавить location "~^/(?.*)\.(php|html)$" Всем спасибо за помощь :) 6 сентября 2013 г., 12:50 пользователь Daniel Podolsky написал: > > Используется последний 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: 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: Простите, если где-то тема освещалась, но не могу найти ни в доках, ни в рассылке, ни в гугле ... Хотелось бы понимать алгоритм по которому cache-manager удаляет объекты из кэша при недостаточности объёма самого кэша. Какие критерии учитываотся, в каком порядке и т.п.? Может быть есть где-то детальное описание? или курить исходники? -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: 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: References: 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: <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: <201309061542.22891.vbart@nginx.com> Message-ID: Спасибо! Я считал что в nginx первичной является документация на русском, но в ней всё менее конкретно: Специальный процесс "cache manager" следит за максимальным размером кэша, > заданным параметром max_size, и при превышении его размеров *удаляет > наименее востребованные данные* > "наименее востребованные" можно и понимать по разному (LRU и LFU на него, как минимум, тянут), и на название алгоритма не похоже )) Нет ли планов реализовать другие методы кэширования? ведь LRU далеко не для всех нагрузок оптимальна. 6 сентября 2013 г., 15:42 пользователь Валентин Бартенев написал: > 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: 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: References: <201309061542.22891.vbart@nginx.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: <201309061542.22891.vbart@nginx.com> <201309061734.01258.vbart@nginx.com> Message-ID: LFU, к примеру (сейчас у нас ситуация, когда из-за нехватки кэша (tmpfs) много вытеснений низкочастотными запросами высокочастотных) Вообще было бы здОрово добавить возможность написания кастомных модулей управления кэшом, чтобы не приходилось переписывать весь proxy_module или fastcgi_module если потребуется реализовать "своё" кэширование с каким-то совсем нестандартным алгоритмом. Ещё одно - многоуровневые кэши (конечно, их можно реализовать проксированием запросов на другой server, но это как-то криво и гонять несколько гигабит через loopback нехорошо) 6 сентября 2013 г., 17:34 пользователь Валентин Бартенев написал: > 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: 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: References: <201309061542.22891.vbart@nginx.com> <201309061734.01258.vbart@nginx.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: <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: Коллеги, помогите разобраться с работой дериктивы 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: References: 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: Есть 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: References: <201309081532.11181.vbart@nginx.com> 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: 9 сентября 2013 г., 12:25 пользователь demo написал: > Здравствуйте! > Можно ли как-то организовать работу с вебсокетами на nginx без > использования > NodeJS, Socket.IO и т.п.? > Если это возможно, поделитесь пожалуйста примерами. > > Как вы собираетесь работать в вебсокетами без сервера? Nginx - это всего лишь прокси -------------- next part -------------- An HTML attachment was scrubbed... URL: 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 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: References: Message-ID: Попробуйте в /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: References: Message-ID: Ошибки выводятся, только код ответа при этом 200 -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: Конфиг ровно как я написал выше: 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: References: <201309081929.12036.vbart@nginx.com> 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: > Такой с бекэнда прийти не мог. Бекэнд ничего не знает про > 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: References: 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: <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: On Sep 10, 2013, at 10:18 AM, Anatoly Mikhailov wrote: > > On Sep 9, 2013, at 1:35 PM, Maxim Dounin 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: On Sep 11, 2013, at 5:54 PM, Maxim Dounin 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: 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: <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 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: 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: <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: 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: <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> <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: Добрый день всем... Пытался сделать ограничение кол-ва запросов для одного локейшена, и сталкнулся с непонятным для меня эффектом. 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: References: 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: Вобщем выяснил, что проблема с кодировкой появляется и для других страниц, не только с 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: 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: <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> <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> <5231851E.6090102@citrin.ru> <5231EDC3.6010005@csdoc.com> Message-ID: 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: 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> <5231851E.6090102@citrin.ru> <5231EDC3.6010005@csdoc.com> 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> <5231851E.6090102@citrin.ru> <5231EDC3.6010005@csdoc.com> <523224DE.1000105@csdoc.com> Message-ID: 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: 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> <5231851E.6090102@citrin.ru> <5231EDC3.6010005@csdoc.com> <523224DE.1000105@csdoc.com> 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: Добрый день! Мне требуется модуль к 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: 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: References: 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: References: 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: 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!\" Олег" написал(а): > 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: есть ли возможность заставить nginx пересылать запросы к fcg php бакенду последовательно делая один запрос на одну куку ну то есть запросы которые пришли с одной кукой должны пересылатся бакенду по FIFO. Да да понятно что следовало внутри php обеспечить решение slide эффектов но на данный момент менять код на бакенде нет ресурсов. Пока из быстрых решений сделать проксю в каком нибудь ерланге дабы запросы вставали по очереди пересылались в fpmphp -------------- next part -------------- An HTML attachment was scrubbed... URL: 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" : >  Здравствуйте! Помогите, пожалуйста, с корректным написанием 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, "Алексей Бобок" : > Вы действительно думаете, что без хотя бы символического предисловия > об архитектуре Вашего сервера, ПО, языка попиливания и прочих данных, > Вам помогут и напишут "ей, чувак, так тебе надо включить 3 опции и и > фиксануть пару функций"? > В лучшем случае в менее профессиональной рассылке Вам ответят "Пых > фуфло, Рельсы рулят!" > > Конкретизируйте. > > -- > Best regards, > Alexey Bobok > > 15.09.2013, в 2:12, "Васильев \"Zmey!\" Олег" написал(а): > >>  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!\" Олег" написал(а): > Ну сайт, как и сказал - статический. Голый 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, "Алексей Бобок" : >> Вы действительно думаете, что без хотя бы символического предисловия >> об архитектуре Вашего сервера, ПО, языка попиливания и прочих данных, >> Вам помогут и напишут "ей, чувак, так тебе надо включить 3 опции и и >> фиксануть пару функций"? >> В лучшем случае в менее профессиональной рассылке Вам ответят "Пых >> фуфло, Рельсы рулят!" >> >> Конкретизируйте. >> >> -- >> Best regards, >> Alexey Bobok >> >> 15.09.2013, в 2:12, "Васильев \"Zmey!\" Олег" написал(а): >> >>> 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" : > 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: 2013/9/15 Васильев "Zmey!" Олег : > Может, 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" : > 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 без модуля 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: Здравствуйте. Для примера можно посмотреть как ngx_http_dav_handler обрабатывает NGX_HTTP_PUT в src/http/modules/ngx_http_dav_module.c 17 сентября 2013 г., 11:01 пользователь Aleus Essentia написал: > День добрый! > Пишу модуль для работы с одной программой. 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: 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: References: Message-ID: Как понимаю, нужно посмотреть функцию 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 Конфиг апача: 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 ServerName server.example.ru ProxyRequests off Alias /errors/ "/var/www/errors/" Order deny,allow Allow from all 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 Конфиг 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 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: > вообще-то есть модуль https://github.com/arut/nginx-dav-ext-module который реализует все недостающие методы, если надо полноценный WebDAV насколько помню, когда тестировал его с subversion 1.6.x, то нормально он не работал. Возможно, что то поменялось, но судя по гитхаб, уже год никаких изменений не вносилось 2013/9/17 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'а - это > совершенно отдельная тема. Должно работать. Основная проблема, > которая там обычно возникает - это заголовок 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 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: References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru> <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru> Message-ID: <20130917205535.369123b9@laptop> On Tue, 17 Sep 2013 19:28:14 +0300 Alex Domoradov 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: > Когда реализую LOCK, будет работать git, а svn, боюсь, не будет никогда. жаль, очень не хватает, чтобы перейти на nginx. 2013/9/17 Maxim Dounin : > 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: Здравствуйте 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: References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru> <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru> Message-ID: Ну чтобы точно понять дело в SSL или где то еще, попробуй подключить просто по http 2013/9/18 usows : > > Здравствуйте > > 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: References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru> <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru> Message-ID: <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru> К сожалению, просто не получится. Бэкенд работает только по https Alex Domoradov писал 18.09.2013 10:53: > Ну чтобы точно понять дело в SSL или где то еще, попробуй подключить > просто по http > > 2013/9/18 usows : >> >> Здравствуйте >> >> 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> <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru> Message-ID: <054A0AA8-BD69-46DA-A26A-DC721987F378@karagodov.name> кто то ж делал доп-модуль к штатному дав-у nginx-а загуглите, там были реализованы недостающие методы ! НО ! как то было сыровато и с мак-ами не очень дружило On 18.09.2013, at 11:30, usows wrote: > К сожалению, просто не получится. Бэкенд работает только по https > > Alex Domoradov писал 18.09.2013 10:53: >> Ну чтобы точно понять дело в SSL или где то еще, попробуй подключить >> просто по http >> >> 2013/9/18 usows : >>> >>> Здравствуйте >>> >>> 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: 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> <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 wrote: > >> К сожалению, просто не получится. Бэкенд работает только по https >> >> Alex Domoradov писал 18.09.2013 10:53: >>> Ну чтобы точно понять дело в SSL или где то еще, попробуй >>> подключить >>> просто по http >>> >>> 2013/9/18 usows : >>>> >>>> Здравствуйте >>>> >>>> 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> <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> <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru> <054A0AA8-BD69-46DA-A26A-DC721987F378@karagodov.name> <0e8c7e4f4f53ed5dbe8af552aa826bb6@mail.pomorsu.ru> Message-ID: а вы сравните в Fiddler-е запросы в случае, когда работает, и, когда не работает. ну или можно декодировать SSL при помощи Wireshark я так понимаю, у вас ситуация "не работает, но логов нет" ? а снифер вы не знаете как делать, потому что SSL ? 18 сентября 2013 г., 14:41 пользователь usows написал: > В моем случае WebDav реализует бэкенд, nginx только проксирует запросы. И > работает все, за исключением подключения диска в виндах... > > Alexey V. Karagodov писал 18.09.2013 12:31: > >> кто то ж делал доп-модуль к штатному дав-у nginx-а >> загуглите, там были реализованы недостающие методы >> ! НО ! >> как то было сыровато и с мак-ами не очень дружило >> >> On 18.09.2013, at 11:30, usows wrote: >> >>> К сожалению, просто не получится. Бэкенд работает только по https >>> >>> Alex Domoradov писал 18.09.2013 10:53: >>>> >>>> Ну чтобы точно понять дело в SSL или где то еще, попробуй подключить >>>> просто по http >>>> >>>> 2013/9/18 usows : >>>>> >>>>> >>>>> Здравствуйте >>>>> >>>>> 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: References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru> <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru> <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru> <054A0AA8-BD69-46DA-A26A-DC721987F378@karagodov.name> <0e8c7e4f4f53ed5dbe8af552aa826bb6@mail.pomorsu.ru> Message-ID: > ну или можно декодировать 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: References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru> <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru> <19bc10c4b6d1bf99ff8ff44d42e2a57e@mail.pomorsu.ru> <054A0AA8-BD69-46DA-A26A-DC721987F378@karagodov.name> <0e8c7e4f4f53ed5dbe8af552aa826bb6@mail.pomorsu.ru> Message-ID: ну это да, шифры надо указать. об этом вам Wireshark очень внятно намекнет (в debug log), если не сможет декодировать. 18 сентября 2013 г., 18:18 пользователь Daniel Podolsky написал: >> ну или можно декодировать 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: Добрый вечер. Подскажите пожалуйста, возможно ли как-то сделать 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: References: 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: <20130918141048.GJ57081@mdounin.ru> Message-ID: Спасибо. В моем случае crop'а будет достаточно. On Sep 18, 2013, at 6:10 PM, Maxim Dounin 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: References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru> <523879CA.8020604@kopeyko.ru> <20130917160834.GB57081@mdounin.ru> <5238856A.70907@kopeyko.ru> <20130917172641.GC57081@mdounin.ru> 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 : >> 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: 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> <523A9172.8090503@mva.name> Message-ID: А какой хоть порядок стоимости написания такого модуля? 2013/9/19 Vadim A. Misbakh-Soloviov : > Ну так взяли бы и написали/спонсировали написание модуля http_nginx_svn ;) > > > 18.09.2013 02:41, Alex Domoradov пишет: >>> Когда реализую LOCK, будет работать git, а svn, боюсь, не будет никогда. >> жаль, очень не хватает, чтобы перейти на nginx. >> >> 2013/9/17 Maxim Dounin : >>> 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: Добрый день! Все просто: http://wiki.nginx.org/HttpCoreModule#large_client_header_buffers 2013/9/19 Дмитрий Бехтерев > Добрый день! > Ошибку 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 -- Yours sincerely, Vladimir Getmanshchuk -------------- next part -------------- An HTML attachment was scrubbed... URL: 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 > > Конфиг апача: > > > > 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 > > > > ServerName server.example.ru > ProxyRequests off > > Alias /errors/ "/var/www/errors/" > > Order deny,allow > Allow from all > > > 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 > > > Конфиг 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: В каком смысле не знает? SNI начиная с Win7 без проблем работает 2013/9/20 usows : > Проблему удалось локализовать. Имя ей - SNI. К сожалению, даже Win8 об этой > тонкости ничего не знает > > Всем спасибо за участие, извините за потраченное время > > usows писал 17.09.2013 17:15: > >> Доброго времени суток >> >> Столкнулся сейчас с проблемой. Есть некий сервер, к нему идет >> обращение через reverse-proxy. До недавнего времени работа шла через >> прокси на апаче, сейчас в качестве прокси используется nginx >> Проблема в том, что после переезда перестал работать WebDav для >> клиентов на Windows >> >> Конфиг апача: >> >> >> >> 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 >> >> >> >> ServerName server.example.ru >> ProxyRequests off >> >> Alias /errors/ "/var/www/errors/" >> >> Order deny,allow >> Allow from all >> >> >> 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 >> >> >> Конфиг 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: References: <4ec640bc095ed18477cd11e587516788@mail.pomorsu.ru> <6b674c7ad57ab48e61cde7d507f9d39e@mail.pomorsu.ru> Message-ID: В браузере - да, кажется, с 6 осла. При попытке подключить ресурс как сетевой диск по WebDav - увы, причем ошибки совершенно неинформативны Alex Domoradov писал 20.09.2013 16:17: > В каком смысле не знает? SNI начиная с Win7 без проблем работает > > 2013/9/20 usows : >> Проблему удалось локализовать. Имя ей - 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: Приветствую, Имеет ли смысл данный параметр ставить в 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: References: 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: <22F89311-DAA8-475E-9A77-5887BFEA4DB1@sysoev.ru> Message-ID: 20 сентября 2013 г., 17:38 пользователь Igor Sysoev написал: > Нет. Тогда можно ли краткий экскурс на тему того, почему стоит это делать только для 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: References: <22F89311-DAA8-475E-9A77-5887BFEA4DB1@sysoev.ru> Message-ID: On Sep 20, 2013, at 18:43 , Anton Sayetsky wrote: > 20 сентября 2013 г., 17:38 пользователь Igor Sysoev написал: >> Нет. > Тогда можно ли краткий экскурс на тему того, почему стоит это делать > только для 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: References: <22F89311-DAA8-475E-9A77-5887BFEA4DB1@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 написал: >>> Нет. >> Тогда можно ли краткий экскурс на тему того, почему стоит это делать >> только для 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: <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 написал: > >>> Нет. > >> > >> Тогда можно ли краткий экскурс на тему того, почему стоит это делать > >> только для 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: <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: <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: References: Message-ID: Здравствуйте. Пытаюсь реализовать авторизацию с помощью 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: 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: References: Message-ID: Вроде можно поместить CA и Промежуточные CA в один файл и указать его в ssl_certificate 2013/9/22 Андрей Тищенко : > Здравствуйте. > Пытаюсь реализовать авторизацию с помощью 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: Добрый день! Мой модуль работает по следующему алгоритму: 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: References: Message-ID: Не можно, а нужно. У всех провайдеров ключей есть инструкции и необходимые данные. 2013/9/22 Alex Domoradov > Вроде можно поместить CA и Промежуточные CA в один файл и указать его > в ssl_certificate > > 2013/9/22 Андрей Тищенко : > > Здравствуйте. > > Пытаюсь реализовать авторизацию с помощью 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: 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: Спасибо. По задумке то что надо. Пробую на стабильной версии 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: References: 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: References: 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: <20130923131345.GE2170@mdounin.ru> Message-ID: > Как минимум, в конфиге не видно директивы ssl_verify_depth, которая по умолчанию 1 - и цепочки сертификатов работать не будут. а как можно определить необходимую глубину проверки? 2013/9/23 Maxim Dounin : > 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: References: <20130923131345.GE2170@mdounin.ru> 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: <20130923131345.GE2170@mdounin.ru> <20130924112255.GM2170@mdounin.ru> Message-ID: Понятно, а будут ли какие то негативные последствия, если я знаю, что необхходимая глубина 1, но выставлю знаениче 2 или 3. Это создаст лишнюю нагрузку или проверка в таком случае вообще не будет проходить? 2013/9/24 Maxim Dounin : > 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: References: <20130923131345.GE2170@mdounin.ru> <20130924112255.GM2170@mdounin.ru> 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: Вопрос к зубрам! Есть большая многокомпонентная система. Компоненты опираются друг на друга достаточно затейливыми конфигурированием, сам процесс которого нетривиален. То есть типичный выкат в бой с нуля ещё как-то реален, но быстрое динамическое переконфигурирование - задача не для слабонервных. Речь идёт не о типовых перестановках, которые конечно же можно запрограммировать. Например, есть несколько слегка отличающихся экземпляров одной и той же компоненты, которые последовательно подключаются одна за другой к общей системе и мы смотрим, как система взаимодействует с каждой из них. Весь опыт попыток подхода к этому снаряду показывает то, что любая система автоматизации подобного динамического переконфигурирования ОЧЕНЬ БЫСТРО устаревает (так как вся система растёт и развивается, меняются/добавляются/удаляются конфигурационные параметры) подобно тому, как устраревает документация. Тыщу лет назад мелькал кейс о том, как решать эту задачу. - путём обычного визуального конструктора похожего на лего или на пазл. С таким визуальным конструктором очень удобно быстро перекидывать связи между компонентами. И вроде бы кейс был достаточно удачен. Может ли кто-то что-то рассказать о своих подходах к этому "снаряду"? Пожалуйста, не рассказывайте мне о том, как это надо делать. Расскажите о том, как вы делали и на какие грабли наткнулись. --- Dmitriy V. Simonov, Perl & Python programmer -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: 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: Привет всем, столкнулся с необходиомстью тестирования подключаемых шрифтов на сайтах через сервисы typekit.com и fonts.com Суть сводится к подключению в html коде js скрипта fonts.com typekit.com В админке каждого из сервисов прописывается для каких доменов будет отдаваться данный шрифт, проверка производится по полю 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: У 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: <975506965.20130925211058@softsearch.ru> Message-ID: Миша! Ты слишком много работал на убыточных сервисах. На прибыльных развитие идёт постоянно. --- Dmitriy V. Simonov, Perl & Python programmer 2013/9/25 Михаил Монашёв > Здравствуйте, 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: 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: References: Message-ID: <5396a3bd9d3ffdac305dfa46ad55d0b6.NginxMailingListRussian@forum.nginx.org> И ещё вопрос: я ничего не упускаю при создании программы? #include #include #include #include #include #include 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: References: <20130923152228.GG2170@mdounin.ru> 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: References: <975506965.20130925211058@softsearch.ru> Message-ID: Извините, что вмешиваюсь, не будучи плотно знаком с 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: References: Message-ID: Есть модная тема - управление правилами публикации приложений из системы виртуализации например: 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 написал: > Вопрос к зубрам! > > Есть большая многокомпонентная система. Компоненты опираются друг на друга > достаточно затейливыми конфигурированием, сам процесс которого нетривиален. > То есть типичный выкат в бой с нуля ещё как-то реален, но быстрое > динамическое переконфигурирование - задача не для слабонервных. > > Речь идёт не о типовых перестановках, которые конечно же можно > запрограммировать. Например, есть несколько слегка отличающихся экземпляров > одной и той же компоненты, которые последовательно подключаются одна за > другой к общей системе и мы смотрим, как система взаимодействует с каждой из > них. > > Весь опыт попыток подхода к этому снаряду показывает то, что любая система > автоматизации подобного динамического переконфигурирования ОЧЕНЬ БЫСТРО > устаревает (так как вся система растёт и развивается, > меняются/добавляются/удаляются конфигурационные параметры) подобно тому, как > устраревает документация. > > Тыщу лет назад мелькал кейс о том, как решать эту задачу. - путём обычного > визуального конструктора похожего на лего или на пазл. С таким визуальным > конструктором очень удобно быстро перекидывать связи между компонентами. И > вроде бы кейс был достаточно удачен. > > Может ли кто-то что-то рассказать о своих подходах к этому "снаряду"? > Пожалуйста, не рассказывайте мне о том, как это надо делать. Расскажите о > том, как вы делали и на какие грабли наткнулись. > > --- > 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: References: Message-ID: я думаю что вместо того что бы сразу разрисовывать визуализацию следует внедрить классификацию и категории все равно без этого вам не добиться нормальной визуализации а проверить успешность классификации компонентов можно например используя систему дистрибуции linux будь то deb/rpm/etc затем уже можно сделать форк от аптитуда и добавить графики. 27 сентября 2013 г., 9:43 пользователь Илья Шипицин написал: > Есть модная тема - управление правилами публикации приложений из > системы виртуализации > > > например: 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 > написал: > > Вопрос к зубрам! > > > > Есть большая многокомпонентная система. Компоненты опираются друг на > друга > > достаточно затейливыми конфигурированием, сам процесс которого > нетривиален. > > То есть типичный выкат в бой с нуля ещё как-то реален, но быстрое > > динамическое переконфигурирование - задача не для слабонервных. > > > > Речь идёт не о типовых перестановках, которые конечно же можно > > запрограммировать. Например, есть несколько слегка отличающихся > экземпляров > > одной и той же компоненты, которые последовательно подключаются одна за > > другой к общей системе и мы смотрим, как система взаимодействует с > каждой из > > них. > > > > Весь опыт попыток подхода к этому снаряду показывает то, что любая > система > > автоматизации подобного динамического переконфигурирования ОЧЕНЬ БЫСТРО > > устаревает (так как вся система растёт и развивается, > > меняются/добавляются/удаляются конфигурационные параметры) подобно тому, > как > > устраревает документация. > > > > Тыщу лет назад мелькал кейс о том, как решать эту задачу. - путём > обычного > > визуального конструктора похожего на лего или на пазл. С таким визуальным > > конструктором очень удобно быстро перекидывать связи между компонентами. > И > > вроде бы кейс был достаточно удачен. > > > > Может ли кто-то что-то рассказать о своих подходах к этому "снаряду"? > > Пожалуйста, не рассказывайте мне о том, как это надо делать. Расскажите о > > том, как вы делали и на какие грабли наткнулись. > > > > --- > > 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: 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: Добрый день. В функции 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: Всем привет. Как передать доменное имя джейбосу, и как его получить? Сейчас сервер запущен как демон коммандой ./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: References: Message-ID: Дык установи заголовок Host в что тебе надо... :) 2013/9/27 Vurtatoo > Всем привет. > Как передать доменное имя джейбосу, и как его получить? > Сейчас сервер запущен как демон коммандой ./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: 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: References: 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: References: 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 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 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: Но после закрытия дескриптора, ядро автоматически удалит этот дескриптор из своих структур и не будет по нему отслеживать события. Ход событий в общем: воркер блокируется на 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: References: <20130927112628.GJ2271@mdounin.ru> 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: References: <20130927112628.GJ2271@mdounin.ru> 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: References: <20091001153140.GD53184@rambler-co.ru> Message-ID: > Получается, что если в течение 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: Пытаюсь вникнуть в мысль: "Мы могли закрыть соединение до того, как добрались до обработки событий". Но где в промежутке между 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: References: <201309271952.14209.vbart@nginx.com> 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: References: Message-ID: Было бы круто, если Вы покажете пример, буду рад. 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: References: Message-ID: 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 написал: > Было бы круто, если Вы покажете пример, буду рад. > > 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: 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: References: Message-ID: 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: Здравствуйте. Скачал последнюю версию 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: References: Message-ID: Что за система? 2013/9/29 MaxNikitin : > Здравствуйте. Скачал последнюю версию 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: References: Message-ID: 29 сентября 2013 г., 12:08 пользователь MaxNikitin написал: > Здравствуйте. Скачал последнюю версию 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: 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: References: Message-ID: > У вас заголовочные файлы стоят - libgd-dev? ТС из исходников ставил libgd. 2013/9/30 Aleksandr Sytar : > > > > 29 сентября 2013 г., 12:08 пользователь MaxNikitin > написал: > >> Здравствуйте. Скачал последнюю версию 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: References: Message-ID: Просто при сборке надо явно указывать путь # ./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 : >> У вас заголовочные файлы стоят - libgd-dev? > ТС из исходников ставил libgd. > > 2013/9/30 Aleksandr Sytar : >> >> >> >> 29 сентября 2013 г., 12:08 пользователь MaxNikitin >> написал: >> >>> Здравствуйте. Скачал последнюю версию 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: References: 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: References: 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 : > >> У вас заголовочные файлы стоят - libgd-dev? > > ТС из исходников ставил libgd. > > > > 2013/9/30 Aleksandr Sytar : > >> > >> > >> > >> 29 сентября 2013 г., 12:08 пользователь MaxNikitin > >> написал: > >> > >>> Здравствуйте. Скачал последнюю версию 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: Привет, В вики (которая я знаю, что не явлется офф документацией) нашёл, что с помощью split_clients и set можно добавлять get параметр какому-то % клиентов . Но у меня такая конструкция не работает: не изменяет $args вообще никак. http { split_clients "${remote_addr}" $additionalQsVariable { 51% "coolVariable=1"; 49% ""; } server { location ~ \.php$ { 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: 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: References: Message-ID: Здравствуйте. Пробовал добавлять пути к исходникам (/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: References: 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