From nginx-forum at nginx.us Sun Dec 1 16:36:48 2013 From: nginx-forum at nginx.us (Tyrone) Date: Sun, 01 Dec 2013 11:36:48 -0500 Subject: =?UTF-8?B?0JrQsNC6INC40LfQsdCw0LLQuNGC0YzRgdGPINC+0YIgR0VULdC/0LDRgNCw0Lw=?= =?UTF-8?B?0LXRgtGA0L7QsiDQv9GA0Lgg0YDQtdC00LjRgNC10LrRgtC1Pw==?= Message-ID: Доброго времени суток! Перевел сайт на другой движок, теперь нужно проставить редиректы со страниц вида /index.php?category_id=102&Itemid=238 к страницам /catalog/izdelie_takoe_to/ При этом, данные по соответствию страниц есть. Нужно только жестко прописать сотню правил для редиректа... Сначала пришло в голову только прописать в .htaccess: RewriteCond %{QUERY_STRING} ^category_id=102&Itemid=238 RewriteRule ^index\.php\?$ /catalog/izdelie_takoe_to/ [R=301,L] Редирект работает, однако в строке запроса остается гет-запрос и происходит перенаправление на /catalog/izdelie_takoe_to/?category_id=102&Itemid=238 Что, на самом деле, не очень устраивает. Дальше начал копать в сторону аналогичных правил для nginx. Но с помощью rewrite смог добиться ровно тех же результатов. Редирект есть, но get-параметры при перенаправлении сохраняются. Подскажите, как можно, если можно, организовать 301й редирект с /index.php?category_id=102&Itemid=238 на /catalog/izdelie_takoe_to/, избавившись от get-параметров? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245108,245108#msg-245108 From dth.pto at gmail.com Sun Dec 1 18:12:24 2013 From: dth.pto at gmail.com (dth) Date: Mon, 2 Dec 2013 00:12:24 +0600 Subject: =?UTF-8?Q?Proxy_auth_=D0=B2_nginx?= Message-ID: Пытаюсь использовать nginx в качестве прямого прокси сервера. Все устраивает, все работает, но мне необходим прокси с авторизацией. Basic http авторизация не подходит, так как передаются другие заголовки, возвращаются другие коды ответа. Нет ли специального модуля для прокси авторизации? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangsamp at gmail.com Sun Dec 1 20:29:32 2013 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Sun, 1 Dec 2013 22:29:32 +0200 (EET) Subject: =?UTF-8?B?UmU6INCa0LDQuiDQuNC30LHQsNCy0LjRgtGM0YHRjyDQvtGCIEdFVC3Qv9Cw0YA=?= =?UTF-8?B?0LDQvNC10YLRgNC+0LIg0L/RgNC4INGA0LXQtNC40YDQtdC60YLQtT8=?= In-Reply-To: References: Message-ID: Today Dec 1, 2013 at 11:36 Tyrone wrote: > Дальше начал копать в сторону аналогичных правил для nginx. Но с помощью > rewrite смог добиться ровно тех же результатов. Редирект есть, но > get-параметры при перенаправлении сохраняются. Нужно всего-навсего прочесть документацию: http://nginx.org/r/rewrite/ru "Если такое поведение нежелательно, можно отказаться от этого добавления, указав в конце строки замены знак вопроса" -- WNGS-RIPE From nginx-forum at nginx.us Mon Dec 2 09:46:41 2013 From: nginx-forum at nginx.us (gadstwo@gmail.com) Date: Mon, 02 Dec 2013 04:46:41 -0500 Subject: =?UTF-8?B?0J/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgaHR0cHMt0YHQsNC50YLQsA==?= Message-ID: <5407f975ac45984032d9e694c8b24064.NginxMailingListRussian@forum.nginx.org> Есть сайт работающий на связке nginx+apache. Схема тривиальная, nginx стоит перед апачем, поднимает ssl, раздает статику, остальное проксирует на апач. На сайте есть личный кабинет работающий на субдомене на отдельном ip, с шифрованием, сертификат доверенный. Задача - сделать зеркало этого сайта. Единственный нормальный мануал найденный по этой теме - с хабра http://habrahabr.ru/post/158393/ Делал все согласно этой статье. В итоге все что работает на http - работает прекрасно. При уходе на https - ERR_SSL_PROTOCOL_ERROR. В статье про https почти ничего не сказано и даже 443 порт не прослушивается. Я дела 2 вариант, редирект трафика с 443 на 80 и отдельный виртуальный сервер с аналогичной конфигурацией который слушает 443 порт. Собственно, главный вопрос - как запроксить https? и можно ли это вообще сделать? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245115,245115#msg-245115 From mdounin at mdounin.ru Mon Dec 2 11:43:02 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 2 Dec 2013 15:43:02 +0400 Subject: =?UTF-8?Q?Re=3A_Proxy_auth_=D0=B2_nginx?= In-Reply-To: References: Message-ID: <20131202114302.GS93176@mdounin.ru> Hello! On Mon, Dec 02, 2013 at 12:12:24AM +0600, dth wrote: > Пытаюсь использовать nginx в качестве прямого прокси сервера. Все > устраивает, все работает, но мне необходим прокси с авторизацией. Basic > http авторизация не подходит, так как передаются другие заголовки, > возвращаются другие коды ответа. Нет ли специального модуля для прокси > авторизации? Традиционно отмечу, что nginx - не forward proxy, nginx - reverse proxy. Попытки использовать nginx в качестве forward proxy могут привести к любым результатам. -- Maxim Dounin http://nginx.org/en/donation.html From chipitsine at gmail.com Mon Dec 2 12:08:03 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 2 Dec 2013 18:08:03 +0600 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0LfQsNCz0YDRg9C30LrQvtC5INC40Lc=?= =?UTF-8?B?0L7QsdGA0LDQttC10L3QuNC5INC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LI=?= =?UTF-8?B?0LDQvdC40LggbGltaXQgcmVxLiDQmtCw0Log0L/QvtCx0L7RgNC+0YLRjD8=?= In-Reply-To: References: Message-ID: в ключ добавьте uri и, возможно, параметры 29 ноября 2013 г., 1:47 пользователь Sferg написал: > Здравствуйте, господа. Установлена связка nginx + php-fpm. Возникла проблема > с загрузкой изображений при использовании limit_req. > > В секции http прописал: > limit_req_zone $binary_remote_addr zone=reqPerSec1:1m rate=1r/s; > > Далее, определены следующие локэйшены: > > location / { > #try_files $uri $uri/ /index.php$uri$is_args$args; > limit_req zone=reqPerSec1 burst=5 nodelay; > } > > location ~ [4-5][0-9][0-9].html { > internal; > } > > location /favicon.ico { > access_log off; > log_not_found off; > expires 1y; > > #empty_gif; > return 204; > } > > location ~ ^.+\.php(?:/.*)?$ { > limit_req zone=reqPerSec1 burst=5 nodelay; > include conf.d/php.conf; > } > > location ~* ^.+\.(jpg|jpeg|gif|png|css|js|swf)$ { > access_log off; > log_not_found off; > expires 1y; > } > > location ~ (?:/\..*|~)$ { > access_log off; > log_not_found off; > deny all; > } > > В результате получается, что при загрузке html-странички, css и картинки > грузятся исправно, даже если часто понажимать F5, а вот при вызове phpinfo, > логотипы пропадают после первого же обновления странички. В чём может быть > проблема и каким образом её можно побороть? К обработке html-страничек > вопросов никаких, но хотелось бы, чтоб и с php limit_req функционировал > исправно. > > С уважением, Геннадий. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245058,245058#msg-245058 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From chipitsine at gmail.com Mon Dec 2 12:10:09 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 2 Dec 2013 18:10:09 +0600 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0LfQsNCz0YDRg9C30LrQvtC5INC40Lc=?= =?UTF-8?B?0L7QsdGA0LDQttC10L3QuNC5INC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LI=?= =?UTF-8?B?0LDQvdC40LggbGltaXQgcmVxLiDQmtCw0Log0L/QvtCx0L7RgNC+0YLRjD8=?= In-Reply-To: References: Message-ID: с картинками есть особенность, в MSIE6, если у вас, например, на странице несколько скрытых div-ов, в каждом из которых есть одна и та же картинка (например, фон), добавленный через javascript, то MSIE6 будет ее загружать столько раз, сколько она встречается. более современные MSIE - понимают, что картинка все таки одна (независимо от способа, которым она добавляется на страницу). с картинками и limit_req надо осторожно. 29 ноября 2013 г., 1:47 пользователь Sferg написал: > Здравствуйте, господа. Установлена связка nginx + php-fpm. Возникла проблема > с загрузкой изображений при использовании limit_req. > > В секции http прописал: > limit_req_zone $binary_remote_addr zone=reqPerSec1:1m rate=1r/s; > > Далее, определены следующие локэйшены: > > location / { > #try_files $uri $uri/ /index.php$uri$is_args$args; > limit_req zone=reqPerSec1 burst=5 nodelay; > } > > location ~ [4-5][0-9][0-9].html { > internal; > } > > location /favicon.ico { > access_log off; > log_not_found off; > expires 1y; > > #empty_gif; > return 204; > } > > location ~ ^.+\.php(?:/.*)?$ { > limit_req zone=reqPerSec1 burst=5 nodelay; > include conf.d/php.conf; > } > > location ~* ^.+\.(jpg|jpeg|gif|png|css|js|swf)$ { > access_log off; > log_not_found off; > expires 1y; > } > > location ~ (?:/\..*|~)$ { > access_log off; > log_not_found off; > deny all; > } > > В результате получается, что при загрузке html-странички, css и картинки > грузятся исправно, даже если часто понажимать F5, а вот при вызове phpinfo, > логотипы пропадают после первого же обновления странички. В чём может быть > проблема и каким образом её можно побороть? К обработке html-страничек > вопросов никаких, но хотелось бы, чтоб и с php limit_req функционировал > исправно. > > С уважением, Геннадий. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245058,245058#msg-245058 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Mon Dec 2 13:50:59 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 2 Dec 2013 17:50:59 +0400 Subject: =?UTF-8?B?UmU6IGRlYnVnIHBvaW50cyBhYm9ydCwg0YfRgtC+INC00LXQu9Cw0YLRjCDRgSA=?= =?UTF-8?B?0LrQvtGA0LrQsNC80Lg=?= In-Reply-To: References: <20131129222050.GR93176@mdounin.ru> Message-ID: <20131202135059.GW93176@mdounin.ru> Hello! On Sat, Nov 30, 2013 at 04:18:47PM -0500, proforg wrote: > Linux shc 3.6-trunk-amd64 #1 SMP Debian 3.6.8-1~experimental.1 x86_64 > GNU/Linux > > nginx version: nginx/1.5.7 > built by gcc 4.4.5 (Debian 4.4.5-8) > TLS SNI support enabled [...] > 2013/11/30 16:06:49 [debug] 17787#0: *4925169 access phase: 9 > 2013/11/30 16:06:49 [debug] 17787#0: *4925169 access phase: 10 > 2013/11/30 16:06:49 [debug] 17787#0: *4925169 post access phase: 11 > 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http client request body > preread 148 > 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http request body content > length filter > 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http body new buf t:1 f:0 > 0000000000AE16BC, pos 0000000000AE16BC, size: 0 file: 0, size: 0 Понятно, при использовании pipelining'а в тело попадает пустой буфер, хотя не должен бы. Плохого от этого быть не должно, но в целом ругань по делу. Патч какой-то такой: # User Maxim Dounin # Date 1385936263 -14400 # Mon Dec 02 02:17:43 2013 +0400 # Node ID 591423596597056f214677ed48a874ec02306fb0 # Parent eda7fcb44dcea02763a5ae2de771b51a1d3e428c Fixed "zero size buf in output" alerts. If request had an empty request body (with Content-Length: 0), and there were preread data available (e.g., due to a pipelined request in buffer), the "zero size buf in output" alert might be logged while proxying the request to an upstream. Similar alerts appeared with client_body_in_file_only if a request had an empty request body. diff --git a/src/http/ngx_http_request_body.c b/src/http/ngx_http_request_body.c --- a/src/http/ngx_http_request_body.c +++ b/src/http/ngx_http_request_body.c @@ -160,7 +160,7 @@ ngx_http_read_client_request_body(ngx_ht ngx_memzero(b, sizeof(ngx_buf_t)); - b->in_file = 1; + b->in_file = (rb->temp_file->file.offset != 0); b->file_last = rb->temp_file->file.offset; b->file = &rb->temp_file->file; @@ -384,7 +384,7 @@ ngx_http_do_read_client_request_body(ngx ngx_memzero(b, sizeof(ngx_buf_t)); - b->in_file = 1; + b->in_file = (rb->temp_file->file.offset != 0); b->file_last = rb->temp_file->file.offset; b->file = &rb->temp_file->file; @@ -843,6 +843,10 @@ ngx_http_request_body_length_filter(ngx_ for (cl = in; cl; cl = cl->next) { + if (rb->rest == 0) { + break; + } + tl = ngx_chain_get_free_buf(r->pool, &rb->free); if (tl == NULL) { return NGX_HTTP_INTERNAL_SERVER_ERROR; -- Maxim Dounin http://nginx.org/en/donation.html From dth.pto at gmail.com Tue Dec 3 07:07:59 2013 From: dth.pto at gmail.com (dth) Date: Tue, 3 Dec 2013 13:07:59 +0600 Subject: =?UTF-8?Q?Re=3A_Proxy_auth_=D0=B2_nginx?= In-Reply-To: <20131202114302.GS93176@mdounin.ru> References: <20131202114302.GS93176@mdounin.ru> Message-ID: Однако в роли forward он работает прекрасно, меня все устраивает, кроме отсутствия авторизации. Поэтому и спросил, может есть какой-нибудь модуль для proxy auth от других разработчиков. 2 декабря 2013 г., 17:43 пользователь Maxim Dounin написал: > Hello! > > On Mon, Dec 02, 2013 at 12:12:24AM +0600, dth wrote: > > > Пытаюсь использовать nginx в качестве прямого прокси сервера. Все > > устраивает, все работает, но мне необходим прокси с авторизацией. Basic > > http авторизация не подходит, так как передаются другие заголовки, > > возвращаются другие коды ответа. Нет ли специального модуля для прокси > > авторизации? > > Традиционно отмечу, что nginx - не forward proxy, nginx - reverse > proxy. Попытки использовать nginx в качестве forward proxy могут > привести к любым результатам. > > -- > 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 Tue Dec 3 12:09:40 2013 From: nginx-forum at nginx.us (Dmitriy_K) Date: Tue, 03 Dec 2013 07:09:40 -0500 Subject: =?UTF-8?B?0JrQsNC6INGD0LTQtdGA0LbQsNGC0Ywg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC4?= =?UTF-8?B?0LUg0LIg0L/RgNC10LTQtdC70LDRhSDQv9C+0LTQtNC40YDQtdC60YLQvtGA?= =?UTF-8?B?0LjQuCDRgdCw0LnRgtCwIChwcm94eSByZWRpcmVjdCDQvdC1INGB0YDQsNCx?= =?UTF-8?B?0LDRgtGL0LLQsNC10YIpID8=?= Message-ID: <036a003b656212348b050cb61baf8301.NginxMailingListRussian@forum.nginx.org> Здесь в конференции неоднократно поднималась проблема перескока проксирования за пределы location, в которой оно производится: http://forum.nginx.org/read.php?21,240642,240642#msg-240642 http://forum.nginx.org/read.php?11,239231,239231#msg-239231 http://forum.nginx.org/read.php?21,242647,242671#msg-242671 Просьба к светочам нашей жизни внести ясность по данному поводу. Возможно, можно что-то придумать с корректировкой заголовков (через subs_filter?) или с реврайтами. Пожалуйста, помогите разобраться! Предложение с перечислением поддиректорий - "location ~ ^(/supervision|/nagios)" - никак не выход для подобных ситуаций. Кроме того, это выдаёт ошибку: nginx: [emerg] "proxy_pass" cannot have URI part in location given by regular expression, or inside named location, or inside "if" statement, or inside "limit_except" block in /usr/local/etc/nginx/sites/test.conf:50 В моём случае используется nginx-1.4.1,1 Общие установки проксирования nginx (имеющие отношение к делу): proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; Конфигурация тестовой location: ------------------ 1-й вариант. ------------------ location /online { rewrite ^/online/?(.*)?$ /$1 break; rewrite_log on; proxy_pass https://10.22.33.44:83; proxy_redirect https://10.22.33.44:83 /online; } ------------------ 2-й вариант. (По одному необычному интернетовскому примеру.) ------------------ location /online { rewrite ^/online/?(.*)?$ /__online__/$1 last; rewrite_log on; } location /__online__ { internal; proxy_pass https://10.22.33.44:83; break; } ------------------ Оба варианта одинаковым образом не срабатывают. Очень странно, что proxy_redirect (в первом варианте) почему-то не отрабатывает. Это видно по логу: 10.xxx - - [03/Dec/2013:13:23:32 +0400] "GET /online HTTP/1.1" 302 137 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" Здесь прокси даёт редирект на свою локальную директорию: /logon Пользовательский браузер получает этот редирект именно как /logon, а не как /online/logon 10.xxx - - [03/Dec/2013:13:23:32 +0400] "GET /logon HTTP/1.1" 301 236 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" В результате происходит этот самый перескок за пределы проксируемой location. При этом "curl -v -k" выдаёт: > GET /online HTTP/1.1 > User-Agent: curl/7.31.0 > Host: 10.xxx > Accept: */* > < HTTP/1.1 302 Found < Server: nginx < Date: Tue, 03 Dec 2013 09:41:52 GMT < Content-Type: text/html; charset=utf-8 < Content-Length: 137 < Connection: keep-alive < Keep-Alive: timeout=10 < Cache-Control: private < Location: /logon < Object moved

Object moved to here.

Попутный вопрос. Я прописал реврайт, чтобы из location на проксируемый бакэнд уходили запросы не "GET /online", а "GET /". rewrite ^/online/(.*) /$1 break; Однако есть альтеренативный вариант реврайта: rewrite ^/online/?(.*)?$ /$1 break; По логам, они отрабатывают одинаково правильно: 2013/12/03 12:40:15 [notice] 71288#0: *12543662 "^/online/?(.*)?$" matches "/online", client: 10.xxx, server: testserver.ru, request: "GET /online HTTP/1.1", host: "testserver.ru" 2013/12/03 12:40:15 [notice] 71288#0: *12543662 rewritten data: "/", args: "", client: 10.xxx, server: testserver.ru, request: "GET /online HTTP/1.1", host: "testserver.ru" Но из-за перескока последующих запросов за пределы проксируемой location не видно правильно ли всё работает в конечном счёте. Какой вариант будет лучше? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245155,245155#msg-245155 From nginx-forum at nginx.us Tue Dec 3 12:15:52 2013 From: nginx-forum at nginx.us (Dmitriy_K) Date: Tue, 03 Dec 2013 07:15:52 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHBzLdGB0LDQudGC0LA=?= In-Reply-To: <5407f975ac45984032d9e694c8b24064.NginxMailingListRussian@forum.nginx.org> References: <5407f975ac45984032d9e694c8b24064.NginxMailingListRussian@forum.nginx.org> Message-ID: <755d4b4ea1f0ad0fb70fcbdfc8333e55.NginxMailingListRussian@forum.nginx.org> Не хватает подробностей, но на вскидку - может быть мелкая ошибка настроек SSL в конфигах фронтэнда или бакэнда. Надо проверить как везде прописан 443. Должно быть: server { listen 443 ssl; Есть устаревший вариант: listen 443; ssl on; И ещё должно быть: proxy_pass https:// - если бакэнд принимает соединение по SSL. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245115,245156#msg-245156 From mdounin at mdounin.ru Tue Dec 3 13:00:32 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 3 Dec 2013 17:00:32 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LXRgNC20LDRgtGMINC/0YDQvtC60YHQuNGA0L7QstCw?= =?UTF-8?B?0L3QuNC1INCyINC/0YDQtdC00LXQu9Cw0YUg0L/QvtC00LTQuNGA0LXQutGC?= =?UTF-8?B?0L7RgNC40Lgg0YHQsNC50YLQsCAocHJveHkgcmVkaXJlY3Qg0L3QtSDRgdGA?= =?UTF-8?B?0LDQsdCw0YLRi9Cy0LDQtdGCKSA/?= In-Reply-To: <036a003b656212348b050cb61baf8301.NginxMailingListRussian@forum.nginx.org> References: <036a003b656212348b050cb61baf8301.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131203130032.GF93176@mdounin.ru> Hello! On Tue, Dec 03, 2013 at 07:09:40AM -0500, Dmitriy_K wrote: > Здесь в конференции неоднократно поднималась проблема перескока > проксирования за пределы location, в которой оно производится: > http://forum.nginx.org/read.php?21,240642,240642#msg-240642 > http://forum.nginx.org/read.php?11,239231,239231#msg-239231 > http://forum.nginx.org/read.php?21,242647,242671#msg-242671 > > Просьба к светочам нашей жизни внести ясность по данному поводу. > Возможно, можно что-то придумать с корректировкой заголовков (через > subs_filter?) или с реврайтами. > Пожалуйста, помогите разобраться! В общем случае - если бекенд не знает, по какому адресу на себя ссылаться, и при этом ссылается - то проксирование невозможно. Пример: бекенд возвращает swf и/или любой другой бинарный файл неизвестной структуры, в котором зашит неправильный адрес. В более частных случаях - работают решения, предусматривающие минимальное вмешательство в ответы бекенда, такие как proxy_redirect (+ proxy_cookie_*). В этом случае ответ меняется на уровне заголовков. Если в вашем случае proxy_redirect не хватает, то можно пытаться ходить в сторону замены адресов в возвращаемом ответе (sub_filter и т.п.). Но единственное гарантированно работающее решение - пойти на бекенд и объяснить ему, как на себя следует ссылаться. Я лично крайне не рекомендую пытаться делать замены в ответах. Либо надо сводить задачу к решаемой с помощью замен в заголовках (обычно для этого бывает достаточно отказаться от изменения пути при проксировании - либо использовав отдельный домен, либо использовав нужный префикс на бекенде), либо объяснять бекенду, как правильно на себя ссылаться. [...] -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Tue Dec 3 14:56:20 2013 From: nginx-forum at nginx.us (wastemaster) Date: Tue, 03 Dec 2013 09:56:20 -0500 Subject: =?UTF-8?B?0JLQuNGA0YPRgSDQsiDQsdC40L3QsNGA0L3QuNC60LUgbmdpbng=?= Message-ID: os: Linux version 2.6.32-042stab021.1 (root at rh6-build-x64) (gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) ) #1 SMP Thu Jul 14 18:02:30 MSD 2011 nginx: 1.4.4-1~squeeze комплектность: root at server:/var/cache/apt/archives# nginx -V nginx version: nginx/1.4.4 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-mail --with-mail_ssl_module --with-file-aio --with-cc-opt='-g -O2 -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt=-Wl,--as-needed --with-ipv6 nginx генерит перенаправления выборочно некоторых посетителей. в логах эти редиректы не отражаются. в целом ситуация очень похожа на описанную товарищами из eset http://habrahabr.ru/company/eset/blog/179115/ конечно есть еще вариант, что дело в наших скриптах, но мы их все проверили а потом и вовсе исключили этот вариант, когда увидели редирект с урла со статикой - те вместо того, чтобы отдать статический контент - nginx генерит 302 редирект. с той разницей, что тулзами приведенными в той статье проблема не детектируется. все что смогли придумать - это снести всю операционнку. И вот пока ждем замену по хостингу хочется выяснить все-таки как это безобразие к нам проникло. Сейчас активность вируса можно только фильтруюя трафик на интерфейсе через tcpdump на предмет 302 редиректов. Фильтруем в реальном времени - как только видим редирект - останавливаем nginx и переустанавливаем - запускаем заного. После этого проблема с редиректом пропадает на несколько часов, потом опять появляются редиректы уже на другой домен. nginx ставим отсюда deb http://nginx.org/packages/debian/ squeeze nginx deb-src http://nginx.org/packages/debian/ squeeze nginx apt-get install --reinstall nginx Проверяли в /var/cache/apt/archives лежит оригинальный пакет nginx чексумма совпадает, чексумма по бинарнику на диске тоже совпадает с оригинальной. Те либо вражеская штука его перезапускает, либо видоизменяет прямо в памяти (если конечно такое возможно) наружу у нас торчит mysql, postgres, nginx и все( Вариант с подбором пароля - маловерятный - пароли серьезные, в логах посторонней активности не замечено. Буду рад любым советам - может кто сталкивался. Как можно отсечь этой штуке пути отступления? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245164,245164#msg-245164 From postmaster at softsearch.ru Tue Dec 3 15:58:27 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 3 Dec 2013 19:58:27 +0400 Subject: =?UTF-8?B?UmU6INCS0LjRgNGD0YEg0LIg0LHQuNC90LDRgNC90LjQutC1IG5naW54?= In-Reply-To: References: Message-ID: <17881855.20131203195827@softsearch.ru> Здравствуйте Включите дебаг-лог и найдите в нём хотя бы один такой редирект. Если будут вопросы, то скиньте кусок лога сюда. -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Tue Dec 3 16:00:53 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 3 Dec 2013 20:00:53 +0400 Subject: =?UTF-8?B?UmU6INCS0LjRgNGD0YEg0LIg0LHQuNC90LDRgNC90LjQutC1IG5naW54?= In-Reply-To: References: Message-ID: <20131203160053.GI93176@mdounin.ru> Hello! On Tue, Dec 03, 2013 at 09:56:20AM -0500, wastemaster wrote: [...] > nginx генерит перенаправления выборочно некоторых посетителей. > в логах эти редиректы не отражаются. > в целом ситуация очень похожа на описанную товарищами из eset > http://habrahabr.ru/company/eset/blog/179115/ [...] > все что смогли придумать - это снести всю операционнку Собственно, если имеет место быть root compromise - это единственно правильное действие. Ну то есть совсем сносить-то было не обязательно, правильным было бы отложить в сторонку, чтобы потом поизучать под микроскопом. Но для работы - надо устанавливать систему заново с чистого носителя. > И вот пока ждем замену по хостингу хочется выяснить все-таки как > это безобразие к нам проникло. Была давеча замечательная история с cPanel, о которой в статье по ссылке, кстати, упоминается. Но в общем случае способов куда как больше одного. [...] > Проверяли в /var/cache/apt/archives лежит оригинальный пакет nginx > чексумма совпадает, чексумма по бинарнику на диске тоже совпадает с > оригинальной. > > Те либо вражеская штука его перезапускает, либо видоизменяет прямо в памяти > (если конечно такое возможно) Возможно всё. Вот тут, например, есть модуль для ядра Linux'а, который делает приблизительно то же самое: http://seclists.org/fulldisclosure/2012/Nov/94 https://www.securelist.com/en/blog/208193935/New_64_bit_Linux_Rootkit_Doing_iFrame_Injections -- Maxim Dounin http://nginx.org/en/donation.html From mail at knutov.com Tue Dec 3 21:26:23 2013 From: mail at knutov.com (Nick Knutov) Date: Wed, 04 Dec 2013 03:26:23 +0600 Subject: =?UTF-8?B?bGlzdGVuINC90LAg0LLRgdC10YUg0LjQvyDQutGA0L7QvNC1IDEyNy84?= Message-ID: <529E4C7F.5070509@knutov.com> А нет ли способа сделать listen на всех ип (как *:80), кроме 127/8 (и, наверное, IPv6:::1) ? Контекст - на разных 127.0.0/24 висят разные бэкенды, и им надо висеть именно на 80ом порту, а внешний(ие) ип (на которые должен биндится нгинх) часто меняются (и их количество вообще может быть не известно, отвечать надо на всех). Хочется делать релоад нгинх без переписывания кучи конфигов (виртуалхостов - много, очень много). -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From marck at rinet.ru Tue Dec 3 21:44:37 2013 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed, 4 Dec 2013 01:44:37 +0400 (MSK) Subject: =?UTF-8?B?UmU6IGxpc3RlbiDQvdCwINCy0YHQtdGFINC40L8g0LrRgNC+0LzQtSAxMjcvOA==?= In-Reply-To: <529E4C7F.5070509@knutov.com> References: <529E4C7F.5070509@knutov.com> Message-ID: On Wed, 4 Dec 2013, Nick Knutov wrote: > А нет ли способа сделать listen на всех ип (как *:80), кроме 127/8 (и, > наверное, IPv6:::1) ? > > Контекст - на разных 127.0.0/24 висят разные бэкенды, и им надо висеть > именно на 80ом порту, а внешний(ие) ип (на которые должен биндится > нгинх) часто меняются (и их количество вообще может быть не известно, > отвечать надо на всех). Хочется делать релоад нгинх без переписывания > кучи конфигов (виртуалхостов - много, очень много). А что за система и ядро? Многие современные, IIUC, позволяют одному слушать на *:80 и остальным откусывать у него specific:80 -- 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 igor at sysoev.ru Wed Dec 4 05:06:56 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Wed, 4 Dec 2013 09:06:56 +0400 Subject: =?UTF-8?B?UmU6IGxpc3RlbiDQvdCwINCy0YHQtdGFINC40L8g0LrRgNC+0LzQtSAxMjcvOA==?= In-Reply-To: References: <529E4C7F.5070509@knutov.com> Message-ID: On Dec 4, 2013, at 1:44 , Dmitry Morozovsky wrote: > On Wed, 4 Dec 2013, Nick Knutov wrote: > >> А нет ли способа сделать listen на всех ип (как *:80), кроме 127/8 (и, >> наверное, IPv6:::1) ? >> >> Контекст - на разных 127.0.0/24 висят разные бэкенды, и им надо висеть >> именно на 80ом порту, а внешний(ие) ип (на которые должен биндится >> нгинх) часто меняются (и их количество вообще может быть не известно, >> отвечать надо на всех). Хочется делать релоад нгинх без переписывания >> кучи конфигов (виртуалхостов - много, очень много). > > А что за система и ядро? Многие современные, [ не Линуксы ] > IIUC, позволяют одному слушать на > *:80 и остальным откусывать у него specific:80 -- Igor Sysoev From zmey1992 at ya.ru Wed Dec 4 09:27:19 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Wed, 04 Dec 2013 13:27:19 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QtNC40YTQuNC60LDRhtC40Y8g0LrRjdGI0LjRgNC+0LLQsNC90L0=?= =?UTF-8?B?0L7QuSDRgdGC0YDQsNC90LjRhtGL?= In-Reply-To: <07c7f1bcf0f050b84a3827a23be0cab1.NginxMailingListRussian@forum.nginx.org> References: <07c7f1bcf0f050b84a3827a23be0cab1.NginxMailingListRussian@forum.nginx.org> Message-ID: <43691386149239@web6m.yandex.ru> SSI не подойдёт? 28.11.2013, 15:05, "Romano" : > Здравствуйте! Возможно ли добавить в кэшируемую страницу (в контент) > произвольный текст, например, ссылку на дополнительный файл стилей CSS в > секции
? > > Сайтов много, а один элементов дизайна общий для всех, но разный для каждого > браузера. Хотелось бы переложить задачу на Nginx, который бы определял тип > браузера и подключал тот или иной файл стилей. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245050,245050#msg-245050 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mail at knutov.com Wed Dec 4 09:49:57 2013 From: mail at knutov.com (Nick Knutov) Date: Wed, 04 Dec 2013 15:49:57 +0600 Subject: =?UTF-8?B?UmU6IGxpc3RlbiDQvdCwINCy0YHQtdGFINC40L8g0LrRgNC+0LzQtSAxMjcvOA==?= In-Reply-To: References: <529E4C7F.5070509@knutov.com> Message-ID: <529EFAC5.5010807@knutov.com> Linux, OpenVZ. 04.12.2013 3:44, Dmitry Morozovsky пишет: > On Wed, 4 Dec 2013, Nick Knutov wrote: > >> А нет ли способа сделать listen на всех ип (как *:80), кроме 127/8 (и, >> наверное, IPv6:::1) ? >> >> Контекст - на разных 127.0.0/24 висят разные бэкенды, и им надо висеть >> именно на 80ом порту, а внешний(ие) ип (на которые должен биндится >> нгинх) часто меняются (и их количество вообще может быть не известно, >> отвечать надо на всех). Хочется делать релоад нгинх без переписывания >> кучи конфигов (виртуалхостов - много, очень много). > > А что за система и ядро? Многие современные, IIUC, позволяют одному слушать на > *:80 и остальным откусывать у него specific:80 > -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From kalinin-mic at yandex.ru Wed Dec 4 09:58:41 2013 From: kalinin-mic at yandex.ru (Kalinin Mike) Date: Wed, 04 Dec 2013 13:58:41 +0400 Subject: =?UTF-8?B?bWFwIHJlZ2V4cCDQvdC10L/QvtC90Y/RgtC60Lg=?= Message-ID: <148591386151121@web9j.yandex.ru> An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Dec 4 12:34:15 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 4 Dec 2013 16:34:15 +0400 Subject: =?UTF-8?B?UmU6IG1hcCByZWdleHAg0L3QtdC/0L7QvdGP0YLQutC4?= In-Reply-To: <148591386151121@web9j.yandex.ru> References: <148591386151121@web9j.yandex.ru> Message-ID: <20131204123415.GP93176@mdounin.ru> Hello! On Wed, Dec 04, 2013 at 01:58:41PM +0400, Kalinin Mike wrote: > Здравствуйте. > > Не получается следующая штука > > map $connection $upstream_group_num { > default 0; > "?\d{1}&" $connection; > } > > т.е. я хочу взять последнюю цифру из встроенной переменной $connection > и на ее основе отправлять запрос на определенный апстрим бекендов. > > nginx данную регулярку принимает, но всегда выдает default. > > Я не врубаюсь как он их применяет. Как заставить nginx ее отрабатывать? Проблемы конфигурации, которую вы пытаетесь написать: 1. У вас map'е используется не регулярное выражение, а константная строка. Чтобы было регулярное выражение - перед ним должне быть указан символ "~", см. http://nginx.org/r/map/ru. 2. Даже если сделать регулярное выражение из того, что у вас написано - работать не будет, т.к. то, что у вас написано - невозможно скомпилировать: $ pcretest PCRE version 8.33 2013-05-28 re> /?\d{1}&/ Failed: nothing to repeat at offset 0 re> 3. Не надо пытаться менять значение переменной $connection. Толку не будет, а плохо - может. Правильно как-то так: map $connection $upstream_group { default 0; "~(?\d)$" $foo; } Впрочем, я бы рекомендовал посмотреть вместо этого в сторону split_clients, http://nginx.org/ru/docs/http/ngx_http_split_clients_module.html -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Dec 4 13:06:06 2013 From: nginx-forum at nginx.us (gadstwo@gmail.com) Date: Wed, 04 Dec 2013 08:06:06 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHBzLdGB0LDQudGC0LA=?= In-Reply-To: <755d4b4ea1f0ad0fb70fcbdfc8333e55.NginxMailingListRussian@forum.nginx.org> References: <5407f975ac45984032d9e694c8b24064.NginxMailingListRussian@forum.nginx.org> <755d4b4ea1f0ad0fb70fcbdfc8333e55.NginxMailingListRussian@forum.nginx.org> Message-ID: <469d865c71377c4ef7cf8174abfad768.NginxMailingListRussian@forum.nginx.org> Основной сайт: DNS: mysite.com xxx.xxx.xxx.56 my.mysite.com xxx.xxx.xxx.59 Apache: ServerName localhost Listen 127.0.0.1:8080 NameVirtualHost *:8080 ServerAdmin webmaster at mysite.com DocumentRoot /home/mysite/publics/public_front ServerName mysite.com ServerAlias www.mysite.com ErrorLog /var/log/httpd/mysite.com-error_log CustomLog /var/log/httpd/mysite.com-access_log common Options All -Indexes AllowOverride All Order allow,deny Allow From All #Личный кабинет ServerAdmin webmaster at mysite.com DocumentRoot /home/mysite/publics/public_my ServerName my.mysite.com ErrorLog /var/log/httpd/my.mysite.com-error_log CustomLog /var/log/httpd/my.mysite.com-access_log common Options All -Indexes AllowOverride All Order allow,deny Allow From All Nginx: server { listen xxx.xxx.xxx.56:80; server_name www.mysite.com mysite.com *.mysite.com; access_log /var/log/nginx/mysite.com.access.log main; include "conf.d/redirect.default"; location ~ /\.ht { deny all; } location ~ /\.svn { deny all; } location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|js|ico|gif|swf|flv|htm|htc|cur|pdf|ttf|woff|eot|swf)$ { expires max; root /home/mysite/publics/public_front; } location / { proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_pass http://127.0.0.1:8080; } } server { listen xxx.xxx.xxx.56:443; server_name www.mysite.com mysite.com id.mysite.com; ssl on; ssl_certificate /etc/ssl/mysitewld.crt; ssl_certificate_key /etc/ssl/mysite.key; ssl_session_cache shared:SSL:10m;ssl_session_timeout 10m; ssl_protocols SSLv3 TLSv1; ssl_ciphers AES128-SHA:RC4-SHA:AES256-SHA:DES-CBC3-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:!MD5:!ADH:!DH:!PSK:!SSLv2; ssl_prefer_server_ciphers on; access_log /var/log/nginx/ssl.mysite.com.access.log main; include "conf.d/redirect.ssl.default"; location ~ /\.ht { deny all; } location ~ /\.svn { deny all; } location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|js|ico|gif|swf|flv|htm|htc|cur|pdf|ttf|woff|eot|swf)$ { expires max; root /home/mysite/publics/public_front; } location / { proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_set_header HTTPS on; proxy_pass http://127.0.0.1:8080; } server { listen xxx.xxx.xxx.59:80; server_name my.mysite.com; access_log /var/log/nginx/my.mysite.com.access.log main; rewrite ^(.*)$ https://my.mysite.com$1; location ~ /\.ht { deny all; } location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|js|ico|gif|swf|flv|htm|htc|cur|pdf|ttf|woff|eot|swf)$ { expires max; root /home/mysite/publics/public_my; } location / { proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_pass http://127.0.0.1:8080; } } server { listen xxx.xxx.xxx.59:443; server_name my.mysite.com ; ssl on; ssl_certificate /etc/ssl/mysitewld.crt; ssl_certificate_key /etc/ssl/mysite.key; ssl_session_cache shared:SSL:10m;ssl_session_timeout 10m; ssl_protocols SSLv3 TLSv1; ssl_ciphers AES128-SHA:RC4-SHA:AES256-SHA:DES-CBC3-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:!MD5:!ADH:!DH:!PSK:!SSLv2; ssl_prefer_server_ciphers on; access_log /var/log/nginx/ssl.my.mysite.com.access.log main; location ~ /\.ht { deny all; } location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|js|ico|gif|swf|flv|htm|htc|cur|pdf|ttf|woff|eot)$ { expires max; root /home/mysite/publics/public_my; } location / { proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_set_header HTTPS on; proxy_pass http://127.0.0.1:8080; } } Зеркало: DNS: mymirror.com y.y.y.154 my.mymirror.com y.y.y.155 nginx: server { listen yyy.yyy.yyy.154:80 ; server_name .mymirror.com; access_log /var/log/nginx/mymirror.com.access.log; error_log /var/log/nginx/mymirror.com.error.log; location / { root /var/www/mymirror.com; try_files $uri @static; } location @static { include 'mymirror.com.conf'; proxy_cookie_domain mysite.com mymirror.com; proxy_set_header Accept-Encoding ""; proxy_set_header Host www.mysite.com; proxy_pass http://www.mysite.com; proxy_redirect http://www.mysite.com http://mymirror.com; proxy_redirect https://www.mysite.com https://mymirror.com; } } server { listen yyy.yyy.yyy.155:443 ssl; server_name my.mymirror.com www.my.mymirror.com; access_log /var/log/nginx/mymirror.com.access.log; error_log /var/log/nginx/mymirror.com.error.log; location / { root /var/www/my.mymirror.com; try_files $uri @static; } location @static { include 'my.mymirror.com.conf'; proxy_cookie_domain my.mysite.com my.mymirror.com; proxy_set_header Accept-Encoding ""; proxy_set_header Host my.mysite.com; proxy_pass https://my.mysite.com; proxy_redirect https://my.mysite.com https://my.mymirror.com; proxy_redirect http://www.mysite.com http://mymirror.com; proxy_redirect https://www.mysite.com https://mymirror.com; } } } mymirror.com проксится великолепно, при переходе на my.mymirror.com Ошибка подключения SSL Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245115,245200#msg-245200 From nginx-forum at nginx.us Wed Dec 4 13:31:19 2013 From: nginx-forum at nginx.us (Dmitriy_K) Date: Wed, 04 Dec 2013 08:31:19 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHBzLdGB0LDQudGC0LA=?= In-Reply-To: <469d865c71377c4ef7cf8174abfad768.NginxMailingListRussian@forum.nginx.org> References: <5407f975ac45984032d9e694c8b24064.NginxMailingListRussian@forum.nginx.org> <755d4b4ea1f0ad0fb70fcbdfc8333e55.NginxMailingListRussian@forum.nginx.org> <469d865c71377c4ef7cf8174abfad768.NginxMailingListRussian@forum.nginx.org> Message-ID: Первое, что бросается в глаза - отсутствие сертификата для my.mymirror.com -------------- server { listen yyy.yyy.yyy.155:443 ssl; server_name my.mymirror.com www.my.mymirror.com; access_log /var/log/nginx/mymirror.com.access.log; error_log /var/log/nginx/mymirror.com.error.log; location / { root /var/www/my.mymirror.com; try_files $uri @static; } ....... -------------- Если это реальный конфиг, то затык именно в этом. Для клиента сертификаты на бакэнде не существуют, для него есть только фронтэнд. А на этом фонтэнде нет сертификата. Он должен быть для обоих имён сервера: server_name my.mymirror.com www.my.mymirror.com Либо надо оставлять одно имя под сертификат. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245115,245203#msg-245203 From nginx-forum at nginx.us Wed Dec 4 16:42:21 2013 From: nginx-forum at nginx.us (hexiw) Date: Wed, 04 Dec 2013 11:42:21 -0500 Subject: =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LUgbmd4IGh0dHAgaGVhZGVycyBtb2R1?= =?UTF-8?B?bGU=?= Message-ID: Здравствуйте, уважаемые форумчане :) Недавно мне понадобилось добавить в заголовки ответа нестандартный заголовок, мне удалось нагуглить модуль ngx_http_headers_module и, судя по описанию, он меня целиком устраивает. Но я не могу понять как его использовать и куда писать, нужные мне, строки. Буду благодарен если кто подскажет как вообще работать с модулями nginx и конкретно с ngx_http_headers_module. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245206,245206#msg-245206 From nginx-forum at nginx.us Wed Dec 4 23:04:28 2013 From: nginx-forum at nginx.us (Dmitriy_K) Date: Wed, 04 Dec 2013 18:04:28 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LXRgNC20LDRgtGMINC/0YDQvtC60YHQuNGA0L7QstCw?= =?UTF-8?B?0L3QuNC1INCyINC/0YDQtdC00LXQu9Cw0YUg0L/QvtC00LTQuNGA0LXQutGC?= =?UTF-8?B?0L7RgNC40Lgg0YHQsNC50YLQsCAocHJveHkgcmVkaXJlY3Qg0L3QtSDRgdGA?= =?UTF-8?B?0LDQsdCw0YLRi9Cy0LDQtdGCKSA/?= In-Reply-To: <036a003b656212348b050cb61baf8301.NginxMailingListRussian@forum.nginx.org> References: <036a003b656212348b050cb61baf8301.NginxMailingListRussian@forum.nginx.org> Message-ID: Насколько понял, ситуация с перескоком из проксируемой директории в корневую неизбежна и не имеет решения в nginx или в ещё чём-нибудь, если только не фильтровать с заменой путей возвращаемый с прокси ответ. Можно ли это как-то сделать надёжно работающим образом или всё безнадёжно? Остаётся ещё вариант изменить пути на самом бакэнде, чтобы они начинались с имени поддиректории, для которой делается проксирование. Просьба подсказать как это лучше сделать в случае nginx. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245155,245222#msg-245222 From nginx-forum at nginx.us Wed Dec 4 23:04:54 2013 From: nginx-forum at nginx.us (Ncs) Date: Wed, 04 Dec 2013 18:04:54 -0500 Subject: =?UTF-8?Q?Re=3A_Proxy_auth_=D0=B2_nginx?= In-Reply-To: References: Message-ID: <1f0bb5e728a6adf936251e872d487aa0.NginxMailingListRussian@forum.nginx.org> поставьте 3proxy и не мучайтесь Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245109,245223#msg-245223 From nginx-forum at nginx.us Wed Dec 4 23:40:29 2013 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 04 Dec 2013 18:40:29 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LXRgNC20LDRgtGMINC/0YDQvtC60YHQuNGA0L7QstCw?= =?UTF-8?B?0L3QuNC1INCyINC/0YDQtdC00LXQu9Cw0YUg0L/QvtC00LTQuNGA0LXQutGC?= =?UTF-8?B?0L7RgNC40Lgg0YHQsNC50YLQsCAocHJveHkgcmVkaXJlY3Qg0L3QtSDRgdGA?= =?UTF-8?B?0LDQsdCw0YLRi9Cy0LDQtdGCKSA/?= In-Reply-To: References: <036a003b656212348b050cb61baf8301.NginxMailingListRussian@forum.nginx.org> Message-ID: <908eb5ee4c19a17340099a4157a70ecd.NginxMailingListRussian@forum.nginx.org> > Остаётся ещё вариант изменить пути на самом бакэнде, чтобы они > начинались с имени поддиректории, для которой делается проксирование. > Просьба подсказать как это лучше сделать в случае nginx. Лучше установить бекенд на отдельный подомен и все будет работать в рут директории. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245155,245224#msg-245224 From nginx-forum at nginx.us Thu Dec 5 05:12:43 2013 From: nginx-forum at nginx.us (Dmitriy_K) Date: Thu, 05 Dec 2013 00:12:43 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LXRgNC20LDRgtGMINC/0YDQvtC60YHQuNGA0L7QstCw?= =?UTF-8?B?0L3QuNC1INCyINC/0YDQtdC00LXQu9Cw0YUg0L/QvtC00LTQuNGA0LXQutGC?= =?UTF-8?B?0L7RgNC40Lgg0YHQsNC50YLQsCAocHJveHkgcmVkaXJlY3Qg0L3QtSDRgdGA?= =?UTF-8?B?0LDQsdCw0YLRi9Cy0LDQtdGCKSA/?= In-Reply-To: <908eb5ee4c19a17340099a4157a70ecd.NginxMailingListRussian@forum.nginx.org> References: <036a003b656212348b050cb61baf8301.NginxMailingListRussian@forum.nginx.org> <908eb5ee4c19a17340099a4157a70ecd.NginxMailingListRussian@forum.nginx.org> Message-ID: <18c41a3b1fed76af8f81c5783b1990d2.NginxMailingListRussian@forum.nginx.org> Да, это нормальный вариант обходного решения. Но, к сожалению, со мной не советуются в решениях, только выдают директивы на исполнение. Кроме того, там заложена специальная задумка SEO по общему использованию кукисов на двух разных бакэндах при общем главном домене. Мне бы хоть понять точно ситуацию с проксированием директории сайта. Имеется какое-нибудь нормально работающее решение (не обязательно nginx) (раеализуемое в пределах только фронтэнда) или нет. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245155,245231#msg-245231 From chipitsine at gmail.com Thu Dec 5 06:35:59 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Thu, 5 Dec 2013 12:35:59 +0600 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LXRgNC20LDRgtGMINC/0YDQvtC60YHQuNGA0L7QstCw?= =?UTF-8?B?0L3QuNC1INCyINC/0YDQtdC00LXQu9Cw0YUg0L/QvtC00LTQuNGA0LXQutGC?= =?UTF-8?B?0L7RgNC40Lgg0YHQsNC50YLQsCAocHJveHkgcmVkaXJlY3Qg0L3QtSDRgdGA?= =?UTF-8?B?0LDQsdCw0YLRi9Cy0LDQtdGCKSA/?= In-Reply-To: <18c41a3b1fed76af8f81c5783b1990d2.NginxMailingListRussian@forum.nginx.org> References: <036a003b656212348b050cb61baf8301.NginxMailingListRussian@forum.nginx.org> <908eb5ee4c19a17340099a4157a70ecd.NginxMailingListRussian@forum.nginx.org> <18c41a3b1fed76af8f81c5783b1990d2.NginxMailingListRussian@forum.nginx.org> Message-ID: Приведите пример, как у вас сейчас работает и как вам хотелось бы четверг, 5 декабря 2013 г. пользователь Dmitriy_K писал: > Да, это нормальный вариант обходного решения. > Но, к сожалению, со мной не советуются в решениях, только выдают директивы > на исполнение. Кроме того, там заложена специальная задумка SEO по общему > использованию кукисов на двух разных бакэндах при общем главном домене. > > Мне бы хоть понять точно ситуацию с проксированием директории сайта. > Имеется > какое-нибудь нормально работающее решение (не обязательно nginx) > (раеализуемое в пределах только фронтэнда) или нет. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,245155,245231#msg-245231 > > _______________________________________________ > 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 Dec 5 06:49:14 2013 From: nginx-forum at nginx.us (S.A.N) Date: Thu, 05 Dec 2013 01:49:14 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LXRgNC20LDRgtGMINC/0YDQvtC60YHQuNGA0L7QstCw?= =?UTF-8?B?0L3QuNC1INCyINC/0YDQtdC00LXQu9Cw0YUg0L/QvtC00LTQuNGA0LXQutGC?= =?UTF-8?B?0L7RgNC40Lgg0YHQsNC50YLQsCAocHJveHkgcmVkaXJlY3Qg0L3QtSDRgdGA?= =?UTF-8?B?0LDQsdCw0YLRi9Cy0LDQtdGCKSA/?= In-Reply-To: <18c41a3b1fed76af8f81c5783b1990d2.NginxMailingListRussian@forum.nginx.org> References: <036a003b656212348b050cb61baf8301.NginxMailingListRussian@forum.nginx.org> <908eb5ee4c19a17340099a4157a70ecd.NginxMailingListRussian@forum.nginx.org> <18c41a3b1fed76af8f81c5783b1990d2.NginxMailingListRussian@forum.nginx.org> Message-ID: > SEO по общему использованию кукисов на двух разных бакэндах при общем > главном домене. На главном домене, отдавайте куки с параметром domain .example.com Тогда куки будут видны всем подоменам *.example.com С аяксом тоже есть решения Просто на отдельном домене у вас будут полностью развязаны руки для конфига Nginx Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245155,245235#msg-245235 From nginx-forum at nginx.us Thu Dec 5 07:34:46 2013 From: nginx-forum at nginx.us (Dmitriy_K) Date: Thu, 05 Dec 2013 02:34:46 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LXRgNC20LDRgtGMINC/0YDQvtC60YHQuNGA0L7QstCw?= =?UTF-8?B?0L3QuNC1INCyINC/0YDQtdC00LXQu9Cw0YUg0L/QvtC00LTQuNGA0LXQutGC?= =?UTF-8?B?0L7RgNC40Lgg0YHQsNC50YLQsCAocHJveHkgcmVkaXJlY3Qg0L3QtSDRgdGA?= =?UTF-8?B?0LDQsdCw0YLRi9Cy0LDQtdGCKSA/?= In-Reply-To: References: <036a003b656212348b050cb61baf8301.NginxMailingListRussian@forum.nginx.org> <908eb5ee4c19a17340099a4157a70ecd.NginxMailingListRussian@forum.nginx.org> <18c41a3b1fed76af8f81c5783b1990d2.NginxMailingListRussian@forum.nginx.org> Message-ID: Спасибо за идею. Только не знаю примут ли её наверху. А можете ли подсказать насчёт этого? >Остаётся ещё вариант изменить пути на самом бакэнде, чтобы они начинались с имени поддиректории, для которой делается проксирование. >Просьба подсказать как это лучше сделать в случае nginx. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245155,245236#msg-245236 From nginx-forum at nginx.us Thu Dec 5 07:52:03 2013 From: nginx-forum at nginx.us (S.A.N) Date: Thu, 05 Dec 2013 02:52:03 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LXRgNC20LDRgtGMINC/0YDQvtC60YHQuNGA0L7QstCw?= =?UTF-8?B?0L3QuNC1INCyINC/0YDQtdC00LXQu9Cw0YUg0L/QvtC00LTQuNGA0LXQutGC?= =?UTF-8?B?0L7RgNC40Lgg0YHQsNC50YLQsCAocHJveHkgcmVkaXJlY3Qg0L3QtSDRgdGA?= =?UTF-8?B?0LDQsdCw0YLRi9Cy0LDQtdGCKSA/?= In-Reply-To: References: <036a003b656212348b050cb61baf8301.NginxMailingListRussian@forum.nginx.org> <908eb5ee4c19a17340099a4157a70ecd.NginxMailingListRussian@forum.nginx.org> <18c41a3b1fed76af8f81c5783b1990d2.NginxMailingListRussian@forum.nginx.org> Message-ID: <2752bcc176529917605bed62dd861fc0.NginxMailingListRussian@forum.nginx.org> > А можете ли подсказать насчёт этого? > >Остаётся ещё вариант изменить пути на самом бакэнде, чтобы они > начинались с имени поддиректории, для которой делается проксирование. > >Просьба подсказать как это лучше сделать в случае nginx. Это подразумевает изменения исходников скриптов на бекенде, я так понимаю если разработчики скриптов сделали адресацию от рута значит они рассчитывали работать в рут папке а не в подкаталоге, если решите править исходники, сделайте в них относительную адресацию (./), чтобы адресация была относительно текущей директории. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245155,245237#msg-245237 From kalinin-mic at yandex.ru Thu Dec 5 10:40:01 2013 From: kalinin-mic at yandex.ru (Kalinin Mike) Date: Thu, 05 Dec 2013 14:40:01 +0400 Subject: =?UTF-8?B?UmU6IFJlOiBtYXAgcmVnZXhwINC90LXQv9C+0L3Rj9GC0LrQuA==?= In-Reply-To: References: Message-ID: <55811386240001@web1j.yandex.ru> An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Dec 6 03:46:54 2013 From: nginx-forum at nginx.us (dwow) Date: Thu, 05 Dec 2013 22:46:54 -0500 Subject: unknown "query_string_original" variable Message-ID: <3da69780311470d5354ccd5a576ceab5.NginxMailingListRussian@forum.nginx.org> Добрый день, есть такой конфиг: set $fn "index.html"; if ($arg_s) { set $fn $arg_s; } При релоаде выдается вот такая ошибка nginx: [emerg] unknown "query_string_original" variable В чем проблема? Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245271,245271#msg-245271 From nginx-forum at nginx.us Fri Dec 6 06:56:13 2013 From: nginx-forum at nginx.us (grygory.mos) Date: Fri, 06 Dec 2013 01:56:13 -0500 Subject: Cache Revalidate In-Reply-To: <20131127184013.GR93176@mdounin.ru> References: <20131127184013.GR93176@mdounin.ru> Message-ID: <8def4627f4032feadf2d1d32592a9384.NginxMailingListRussian@forum.nginx.org> > Вот и я о том же - если страница генерится 0.8 секунд, то как > может быть недопустимым кешировать её на 1 секунду? Откуда > взялось требование о недопустимости? > В моем случаи такое требования появилось, когда нужно было проверять права доступа юзера на каждом запросе, но для этого нужны куки юзера, Nginx их не передаст при ревалидации кеша, так что мы тоже все это делаем только в кеше браузера. Но эти задачи можно было бы решать на кешировании реверс-прокси (Nginx) Вот как это делается на других прокси http://www.mnot.net/blog/2005/11/26/caching Так что я поддерживаю развития этой темы ) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245273#msg-245273 From nginx-forum at nginx.us Fri Dec 6 08:06:47 2013 From: nginx-forum at nginx.us (izlom) Date: Fri, 06 Dec 2013 03:06:47 -0500 Subject: HTTP/1.1 000 Message-ID: берем URL http://xxxxx/xxx/ и получаем ответ "HTTP/1.1 000" куда делся 200 код? Как это фиксится? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245274,245274#msg-245274 From zmey1992 at ya.ru Fri Dec 6 09:53:53 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Fri, 06 Dec 2013 13:53:53 +0400 Subject: HTTP/1.1 000 In-Reply-To: References: Message-ID: <59731386323633@web1g.yandex.ru> Опишите проблему подробнее. URL ведёт на ваш сервер? Занимается его обработкой nginx? Как определяли проблему? Она проявляется всегда? Как и когда ещё? Покажите конфиг и nginx -V 06.12.2013, 12:07, "izlom" : > берем URL http://xxxxx/xxx/ > и получаем ответ "HTTP/1.1 000" куда делся 200 код? Как это фиксится? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245274,245274#msg-245274 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From zmey1992 at ya.ru Fri Dec 6 10:02:10 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Fri, 06 Dec 2013 14:02:10 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHBzLdGB0LDQudGC0LA=?= In-Reply-To: <5407f975ac45984032d9e694c8b24064.NginxMailingListRussian@forum.nginx.org> References: <5407f975ac45984032d9e694c8b24064.NginxMailingListRussian@forum.nginx.org> Message-ID: <87981386324130@web1g.yandex.ru> Если я правильно понял вашу задачу, то: 1) Метода connect в nginx нет, а значит просто прозрачно проксировать трафик на https бэкэнд не выйдет. 2) Если пытаться прикинуться сайтом, на который вы проксируете, но под другим доменом - тоже ничего не выйдет. Необходимо ЛИБО иметь сертификат бэкэнда, чтобы терминировать https на nginx (что не подходит, если домен другой), ЛИБО до вас будет доступ по http и все жёстко прописанные пути и редиректы вам как-то надо будет переводить на http, ЛИБО делаете свой сертификат, но он будет недоверенным. 02.12.2013, 13:47, "gadstwo at gmail.com" : > Есть сайт работающий на связке nginx+apache. Схема тривиальная, nginx стоит > перед апачем, поднимает ssl, раздает статику,  остальное проксирует на апач. > На сайте есть личный кабинет работающий на субдомене на отдельном ip, с > шифрованием, сертификат доверенный. > Задача - сделать зеркало этого сайта. > Единственный нормальный мануал найденный по этой теме - с хабра > http://habrahabr.ru/post/158393/ > Делал все согласно этой статье. В итоге все что работает на http - работает > прекрасно. При уходе на https - ERR_SSL_PROTOCOL_ERROR. > В статье про https почти ничего не сказано и даже 443 порт не > прослушивается. Я дела 2 вариант, редирект трафика с 443 на 80 и отдельный > виртуальный сервер с аналогичной конфигурацией который слушает 443 порт. > Собственно, главный вопрос -  как запроксить https? и можно ли это вообще > сделать? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245115,245115#msg-245115 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Fri Dec 6 10:53:39 2013 From: nginx-forum at nginx.us (dwow) Date: Fri, 06 Dec 2013 05:53:39 -0500 Subject: unknown "query_string_original" variable In-Reply-To: <3da69780311470d5354ccd5a576ceab5.NginxMailingListRussian@forum.nginx.org> References: <3da69780311470d5354ccd5a576ceab5.NginxMailingListRussian@forum.nginx.org> Message-ID: <4bb6a71984cc58dd928c094f1e6c6212.NginxMailingListRussian@forum.nginx.org> Проблема решена, сам себе злобный Буратино( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245271,245280#msg-245280 From nginx-forum at nginx.us Fri Dec 6 11:44:52 2013 From: nginx-forum at nginx.us (tuwe) Date: Fri, 06 Dec 2013 06:44:52 -0500 Subject: =?UTF-8?B?0LrQsNC6INC00L7QsdCw0LLQuNGC0Ywg0LzQvtC00YPQu9GMINCyINGD0YHRgtCw?= =?UTF-8?B?0L3QvtCy0LvQtdC90L3Ri9C5IG5naW54?= Message-ID: Здравствуйте! Не установлен ngx_http_ssi_module модуль. Restarting nginx: nginx: [emerg] unknown directive "ssi" in /etc/nginx/sites-enabled/112 nginx: configuration file /etc/nginx/nginx.conf test failed как добавить модуль ngx_http_ssi_module в уже установленный nginx? Спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245286,245286#msg-245286 From onokonem at gmail.com Fri Dec 6 11:51:26 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Fri, 6 Dec 2013 15:51:26 +0400 Subject: =?UTF-8?B?UmU6INC60LDQuiDQtNC+0LHQsNCy0LjRgtGMINC80L7QtNGD0LvRjCDQsiDRg9GB?= =?UTF-8?B?0YLQsNC90L7QstC70LXQvdC90YvQuSBuZ2lueA==?= In-Reply-To: References: Message-ID: > как добавить модуль ngx_http_ssi_module в уже установленный nginx? Никак. Модули линкуются при сборке. From mdounin at mdounin.ru Fri Dec 6 12:08:01 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 6 Dec 2013 16:08:01 +0400 Subject: =?UTF-8?B?UmU6INC60LDQuiDQtNC+0LHQsNCy0LjRgtGMINC80L7QtNGD0LvRjCDQsiDRg9GB?= =?UTF-8?B?0YLQsNC90L7QstC70LXQvdC90YvQuSBuZ2lueA==?= In-Reply-To: References: Message-ID: <20131206120801.GJ95113@mdounin.ru> Hello! On Fri, Dec 06, 2013 at 06:44:52AM -0500, tuwe wrote: > Здравствуйте! > > Не установлен ngx_http_ssi_module модуль. > > Restarting nginx: nginx: [emerg] unknown directive "ssi" in > /etc/nginx/sites-enabled/112 > nginx: configuration file /etc/nginx/nginx.conf test failed > > как добавить модуль ngx_http_ssi_module в уже установленный nginx? Пересобрать nginx, запустив configure без ключа --without-http_ssi_module (модуль ssi собирается по умолчанию, если сборка не запрещена явно), после чего установить новый исполняемый файл и либо перезапустить nginx, либо выполнить процедуру обновления исполняемого файла на лету. http://nginx.org/ru/docs/configure.html http://nginx.org/ru/docs/control.html -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Dec 6 13:11:51 2013 From: nginx-forum at nginx.us (Digan) Date: Fri, 06 Dec 2013 08:11:51 -0500 Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCDQvtCx0YDQsNGJ0LXQvdC40Lkg?= =?UTF-8?B?0Log0YHQtdGA0LLQuNGB0LDQvA==?= In-Reply-To: References: Message-ID: <6d11dd292ea39a557e01c8d9da2d3429.NginxMailingListRussian@forum.nginx.org> Вопрос решился, когда прописали в web.config Но запросы к сервисам могут идти как от сервера, так и от клиента. При первом обращении к сервисам с клиентам просто валится ошибка. Какой модуль для балансировки посоветуете? Нашел еще ngx_http_upstream_hash_module. Он подойдет? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245084,245290#msg-245290 From mdounin at mdounin.ru Fri Dec 6 13:16:42 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 6 Dec 2013 17:16:42 +0400 Subject: Cache Revalidate In-Reply-To: <8def4627f4032feadf2d1d32592a9384.NginxMailingListRussian@forum.nginx.org> References: <20131127184013.GR93176@mdounin.ru> <8def4627f4032feadf2d1d32592a9384.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131206131642.GN95113@mdounin.ru> Hello! On Fri, Dec 06, 2013 at 01:56:13AM -0500, grygory.mos wrote: > > Вот и я о том же - если страница генерится 0.8 секунд, то как > > может быть недопустимым кешировать её на 1 секунду? Откуда > > взялось требование о недопустимости? > > > > В моем случаи такое требования появилось, когда нужно было проверять права > доступа юзера на каждом запросе, но для этого нужны куки юзера, Nginx их не > передаст при ревалидации кеша, так что мы тоже все это делаем только в кеше > браузера. Just a side note: при ревалидации передаются все заголовки запроса пользователя, в том числе куки. Вы куда-то не туда посмотрели. > Но эти задачи можно было бы решать на кешировании реверс-прокси (Nginx) > > Вот как это делается на других прокси > http://www.mnot.net/blog/2005/11/26/caching > > Так что я поддерживаю развития этой темы ) Всмысле - хочется по-abuse'ить ревалидацию для контроля доступа отдельных пользователей к элементам общего кеша, я правильно понял? Подход интересный, хотя и следует понимать, что он полагается на то, что, если ревалидация не проходит - элемент кеша не будет удалён/заменён, а будет продолжать использоваться для других пользователей. Вообще в nginx'е для подобных задач удалённого контроля доступа есть аж два механизма - X-Accel-Redirect и auth_request, гораздо более приспособленных именно для контроля доступа, и не завязанных на наюнсы поведения кеширования. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Dec 6 20:20:01 2013 From: nginx-forum at nginx.us (Dmitriy_K) Date: Fri, 06 Dec 2013 15:20:01 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHBzLdGB0LDQudGC0LA=?= In-Reply-To: <87981386324130@web1g.yandex.ru> References: <87981386324130@web1g.yandex.ru> Message-ID: На крайний случай, метод connect есть в апаче. Nginx ещё не успел обрасти некоторыми фичами проксирования апача. Особенно не хватает аналога mod_proxy_html, чтобы автоматом правились ссылки в страницах. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245115,245297#msg-245297 From nginx-forum at nginx.us Fri Dec 6 22:04:32 2013 From: nginx-forum at nginx.us (grygory.mos) Date: Fri, 06 Dec 2013 17:04:32 -0500 Subject: Cache Revalidate In-Reply-To: <20131206131642.GN95113@mdounin.ru> References: <20131206131642.GN95113@mdounin.ru> Message-ID: <7c9902cdd915ab77d781cb3c5c891d9a.NginxMailingListRussian@forum.nginx.org> > Just a side note: при ревалидации передаются все заголовки запроса > пользователя, в том числе куки. Вы куда-то не туда посмотрели. Да вы правы, куки передаются, это ЕТаг не передается, но в кеше Nginx он есть. ЕТаг нужен нам для быстрой проверки прав доступа и версии кеша. Без него на ранней стадии работы скрипта невозможно быстро проверить все права доступа и определить изменилась версия страницы или нет, чтобы отдать 304 если страница не изменилась. > Всмысле - хочется по-abuse'ить ревалидацию для контроля доступа > отдельных пользователей к элементам общего кеша, я правильно понял? > > Подход интересный, хотя и следует понимать, что он полагается на > то, что, если ревалидация не проходит - элемент кеша не будет > удалён/заменён, а будет продолжать использоваться для других > пользователей. > > Вообще в nginx'е для подобных задач удалённого контроля доступа > есть аж два механизма - X-Accel-Redirect и auth_request, гораздо > более приспособленных именно для контроля доступа, и не завязанных > на наюнсы поведения кеширования. Если у клиента нет прав доступа, он получает статус 403, если есть права получает ? 200 или 304. Если бекенд не отвечает, Nginx отдает 504, никаких cache_use_stale в этом случаи быть не должно. Варианты с X-Accel-Redirect и auth_request, работают на подзапросах и это частное решения под Nginx. В варианте с кешем никаких доп запросов нет и такая схема будет работать даже в кеше браузера. Зачем выдумывать велосипед, если эта схема работает в кеше браузера. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245296#msg-245296 From nginx-forum at nginx.us Fri Dec 6 22:52:29 2013 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 06 Dec 2013 17:52:29 -0500 Subject: Cache Revalidate In-Reply-To: <7c9902cdd915ab77d781cb3c5c891d9a.NginxMailingListRussian@forum.nginx.org> References: <20131206131642.GN95113@mdounin.ru> <7c9902cdd915ab77d781cb3c5c891d9a.NginxMailingListRussian@forum.nginx.org> Message-ID: <3c7c0ffffa65f6f84bddd48f66ee977a.NginxMailingListRussian@forum.nginx.org> > > если ревалидация не проходит - элемент кеша не будет > > удалён/заменён, а будет продолжать использоваться для других > > пользователей. > Если у клиента нет прав доступа, он получает статус 403, если есть > права получает ? 200 или 304. > Если бекенд не отвечает, Nginx отдает 504, никаких cache_use_stale в > этом случаи быть не должно. Я так понимаю, grygory планировал использовать в кешировании max-age=0 (X-Accel-Expires: @$time-1), тогда возможность использования кеша другими пользователями исключена, потому что каждый запрос будет проходить ревалидацию, в которой будет проверка прав доступа и актуальности кеша. Вообще если на сайте соотношения на чтения и запись 10/1, тогда выходит что на 11 запросов, 10 раз будет отдан статус 304, без генерации страницы потому что она есть в кеше Nginx и только 1 запрос будет со статусом 200 который обновит кеш Nginx. Выходит, смысл в этой схеме есть. > Да вы правы, куки передаются, это ЕТаг не передается, но в кеше Nginx > он есть. В будущем планируют это реализовать, так что все будет хорошо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245299#msg-245299 From chipitsine at gmail.com Sat Dec 7 10:06:08 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Sat, 7 Dec 2013 16:06:08 +0600 Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCDQvtCx0YDQsNGJ0LXQvdC40Lkg?= =?UTF-8?B?0Log0YHQtdGA0LLQuNGB0LDQvA==?= In-Reply-To: <6d11dd292ea39a557e01c8d9da2d3429.NginxMailingListRussian@forum.nginx.org> References: <6d11dd292ea39a557e01c8d9da2d3429.NginxMailingListRussian@forum.nginx.org> Message-ID: настройка серверной части WCF-сервиса не должна ни на что влиять. кука же ему предназначалась, а nginx-у. расскажите подробнее, как у вас всё устроено. 6 декабря 2013 г., 19:11 пользователь Digan написал: > Вопрос решился, когда прописали в web.config ... allowCookies="true"> > > Но запросы к сервисам могут идти как от сервера, так и от клиента. При > первом обращении к сервисам с клиентам просто валится ошибка. > > Какой модуль для балансировки посоветуете? > > Нашел еще ngx_http_upstream_hash_module. Он подойдет? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245084,245290#msg-245290 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Sun Dec 8 10:43:27 2013 From: nginx-forum at nginx.us (Tyrone) Date: Sun, 08 Dec 2013 05:43:27 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQuNC30LHQsNCy0LjRgtGM0YHRjyDQvtGCIEdFVC3Qv9Cw0YA=?= =?UTF-8?B?0LDQvNC10YLRgNC+0LIg0L/RgNC4INGA0LXQtNC40YDQtdC60YLQtT8=?= In-Reply-To: References: Message-ID: <2577a2ed4633b8c05afe2ccf195b2799.NginxMailingListRussian@forum.nginx.org> Спасибо! Всё ок. То же самое относится и к RewriteRule для apache! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245108,245327#msg-245327 From nginx-forum at nginx.us Sun Dec 8 12:09:58 2013 From: nginx-forum at nginx.us (Romano) Date: Sun, 08 Dec 2013 07:09:58 -0500 Subject: =?UTF-8?B?0JTQvtGB0YLRg9C/INC6INGE0LDQudC70L7QstC+0Lkg0YHQuNGB0YLQtdC80LU=?= Message-ID: <6126ae14f8fae25dfd0957094383413c.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Такая задача встала, необходимо во временной папке tmp переименовать файл, имя которого может быть извлечено из cookie. Разумеется, задачу хотелось бы переложить на прокси-сервер Nginx, суть которой в следующем: [code]location / { if (-f /tmp/$cookie_name) { rename /tmp/$cookie_name /tmp/$cookie_name.old; } ... }[/code] Подобная конструкция необходима для обратной связи с приложениями Apache, т.е. чтобы они понимали, что было выполнено обращение к прокси-серверу Nginx, который может также выдать страницу и из кэша (в этом случае Apache не узнает о фактическом обращении). Насколько знаю, файловые операции Nginx не поддерживает. Буду благодарен за любое другое предложение! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245330,245330#msg-245330 From andrey at kopeyko.ru Sun Dec 8 12:24:58 2013 From: andrey at kopeyko.ru (Andrey Kopeyko) Date: Sun, 08 Dec 2013 16:24:58 +0400 Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0YPQvyDQuiDRhNCw0LnQu9C+0LLQvtC5INGB0LjRgdGC0LU=?= =?UTF-8?B?0LzQtQ==?= In-Reply-To: <6126ae14f8fae25dfd0957094383413c.NginxMailingListRussian@forum.nginx.org> References: <6126ae14f8fae25dfd0957094383413c.NginxMailingListRussian@forum.nginx.org> Message-ID: <52A4651A.2020702@kopeyko.ru> 08.12.2013 16:09, Romano пишет: > Здравствуйте! Добрый день, Romano! > Такая задача встала, необходимо во временной папке tmp > переименовать файл, имя которого может быть извлечено из cookie. Разумеется, > задачу хотелось бы переложить на прокси-сервер Nginx, суть которой в > следующем: > [code]location / { > if (-f /tmp/$cookie_name) { > rename /tmp/$cookie_name /tmp/$cookie_name.old; > } > ... > }[/code] > > Подобная конструкция необходима для обратной связи с приложениями Apache, > т.е. чтобы они понимали, что было выполнено обращение к прокси-серверу > Nginx, который может также выдать страницу и из кэша (в этом случае Apache > не узнает о фактическом обращении). > > Насколько знаю, файловые операции Nginx не поддерживает. Буду благодарен за > любое другое предложение! Другое предложение - использовать nginx. Существует встроенный perl, при аккуратном обращении (в вашем случае - аккуратность как раз нужна) - весьма полезен. Читайте http://nginx.org/ru/docs/http/ngx_http_perl_module.html -- Best regards, Andrey Kopeyko From nginx-forum at nginx.us Mon Dec 9 09:24:24 2013 From: nginx-forum at nginx.us (mnsold) Date: Mon, 09 Dec 2013 04:24:24 -0500 Subject: =?UTF-8?B?0J3QsNGB0YLRgNC+0LjRgtGMIEhUVFAg0LggSFRUUFMg0L3QsCDQvtC00L3QvtC8?= =?UTF-8?B?INGB0LXRgNCy0LXRgNC1?= Message-ID: <790868614648d62028ae2166b03dc558.NginxMailingListRussian@forum.nginx.org> Основная проблема: по HTTPS перенаправляет на HTTP протокол, вместо HTTPS. По HTTP все отрабатывает нормально. Локальный сетевой трафик хочется по HTTP гонять (и проблемы видимо отсюда и растут), чтобы не нагружать сервер, да и весь локальный трафик между серверами считаю доверенным. В качестве бэкэнда стоит апач. Само перенаправление (без слэша в конце), как оно проиходит. Тут все нормально: http://myhost/context -> http://myhost/context/ А вот тут перенаправляет на HTTP, вместо HTTPS https://myhost/context -> http://myhost/context/ Подскажите, как нужно поправить конфиг, чтобы перенаправлял на HTTPS, при условии что хочется внутренний трафик гонять по HTTP? Конфиги: server { listen *:80; listen *:443 ssl; server_name myhost; ssl_certificate /.../server.crt; ssl_certificate_key /.../server.key; ssl_protocols SSLv2 SSLv3; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP; ssl_verify_client off; include conf.d/test-apache.cfg; error_log /var/log/nginx/error.log warn; access_log /var/log/nginx/access.log main; } Файл test-apache.cfg location ^~ / { proxy_pass http://localhost:80; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } Замечено, что если в proxy_pass отправлять по https то все работает нормально, например: в файле test-apache.cfg заменить proxy_pass http://localhost:80; на if ( $scheme = "http" ) { proxy_pass http://localhost:80; } if ( $scheme = "https" ) { proxy_pass https://localhost:443; } На стороне апача на данный момент все предельно просто Alias /context "/var/www/context" Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245346,245346#msg-245346 From dmitriy at lyalyuev.info Mon Dec 9 09:30:47 2013 From: dmitriy at lyalyuev.info (Dmitriy Lyalyuev) Date: Mon, 09 Dec 2013 11:30:47 +0200 Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC40YLRjCBIVFRQINC4IEhUVFBTINC90LAg0L7QtNC9?= =?UTF-8?B?0L7QvCDRgdC10YDQstC10YDQtQ==?= In-Reply-To: <790868614648d62028ae2166b03dc558.NginxMailingListRussian@forum.nginx.org> References: <790868614648d62028ae2166b03dc558.NginxMailingListRussian@forum.nginx.org> Message-ID: <52A58DC7.8060201@lyalyuev.info> Добрый день. proxy_set_header X-Forwarded-Proto $scheme; 09.12.2013 11:24, mnsold пишет: > Основная проблема: по HTTPS перенаправляет на HTTP протокол, вместо HTTPS. > По HTTP все отрабатывает нормально. > Локальный сетевой трафик хочется по HTTP гонять (и проблемы видимо отсюда и > растут), чтобы не нагружать сервер, да и весь локальный трафик между > серверами считаю доверенным. > В качестве бэкэнда стоит апач. > > Само перенаправление (без слэша в конце), как оно проиходит. > Тут все нормально: > http://myhost/context -> http://myhost/context/ > А вот тут перенаправляет на HTTP, вместо HTTPS > https://myhost/context -> http://myhost/context/ > Подскажите, как нужно поправить конфиг, чтобы перенаправлял на HTTPS, при > условии что хочется внутренний трафик гонять по HTTP? > > Конфиги: > server { > listen *:80; > listen *:443 ssl; > server_name myhost; > > ssl_certificate /.../server.crt; > ssl_certificate_key /.../server.key; > > ssl_protocols SSLv2 SSLv3; > ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP; > ssl_verify_client off; > > include conf.d/test-apache.cfg; > > error_log /var/log/nginx/error.log warn; > access_log /var/log/nginx/access.log main; > } > > Файл test-apache.cfg > location ^~ / { > proxy_pass http://localhost:80; > > proxy_set_header Host $http_host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > } > > Замечено, что если в proxy_pass отправлять по https то все работает > нормально, например: > в файле test-apache.cfg заменить > proxy_pass http://localhost:80; > на > if ( $scheme = "http" ) { > proxy_pass http://localhost:80; > } > if ( $scheme = "https" ) { > proxy_pass https://localhost:443; > } > > На стороне апача на данный момент все предельно просто > Alias /context "/var/www/context" > > Options Indexes MultiViews > AllowOverride None > Order allow,deny > Allow from all > > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245346,245346#msg-245346 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Dmitriy Lyalyuev http://lyalyuev.info From nginx-forum at nginx.us Mon Dec 9 09:39:13 2013 From: nginx-forum at nginx.us (mnsold) Date: Mon, 09 Dec 2013 04:39:13 -0500 Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC40YLRjCBIVFRQINC4IEhUVFBTINC90LAg0L7QtNC9?= =?UTF-8?B?0L7QvCDRgdC10YDQstC10YDQtQ==?= In-Reply-To: <52A58DC7.8060201@lyalyuev.info> References: <52A58DC7.8060201@lyalyuev.info> Message-ID: <09e5170ec89d3dd1757bb5da97ccc054.NginxMailingListRussian@forum.nginx.org> Dmitriy Lyalyuev Wrote: ------------------------------------------------------- > Добрый день. > > proxy_set_header X-Forwarded-Proto $scheme; Пробовал данную директиву и форсировал ее вместо "$scheme" явно прописывал "https", но не срабатывает. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245346,245348#msg-245348 From nginx-forum at nginx.us Mon Dec 9 09:47:29 2013 From: nginx-forum at nginx.us (mnsold) Date: Mon, 09 Dec 2013 04:47:29 -0500 Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC40YLRjCBIVFRQINC4IEhUVFBTINC90LAg0L7QtNC9?= =?UTF-8?B?0L7QvCDRgdC10YDQstC10YDQtQ==?= In-Reply-To: <09e5170ec89d3dd1757bb5da97ccc054.NginxMailingListRussian@forum.nginx.org> References: <52A58DC7.8060201@lyalyuev.info> <09e5170ec89d3dd1757bb5da97ccc054.NginxMailingListRussian@forum.nginx.org> Message-ID: Точно знаю, что поможет директива proxy_redirect http://$http_host https://$http_host; Но не знаю, как ее можно применить только если $scheme=https. В "if ( $scheme = "https" ) ... " не работает, т.к. nginx пишет "proxy_redirect" directive is not allowed here" Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245346,245349#msg-245349 From nginx-forum at nginx.us Mon Dec 9 09:53:48 2013 From: nginx-forum at nginx.us (mnsold) Date: Mon, 09 Dec 2013 04:53:48 -0500 Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC40YLRjCBIVFRQINC4IEhUVFBTINC90LAg0L7QtNC9?= =?UTF-8?B?0L7QvCDRgdC10YDQstC10YDQtQ==?= In-Reply-To: References: <52A58DC7.8060201@lyalyuev.info> <09e5170ec89d3dd1757bb5da97ccc054.NginxMailingListRussian@forum.nginx.org> Message-ID: Помогла директива proxy_redirect http://$http_host $scheme://$http_host; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245346,245351#msg-245351 From mail at knutov.com Mon Dec 9 11:31:55 2013 From: mail at knutov.com (Nick Knutov) Date: Mon, 09 Dec 2013 17:31:55 +0600 Subject: =?UTF-8?B?UmU6IGxpc3RlbiDQvdCwINCy0YHQtdGFINC40L8g0LrRgNC+0LzQtSAxMjcvOA==?= In-Reply-To: References: <529E4C7F.5070509@knutov.com> Message-ID: <52A5AA2B.1000209@knutov.com> А с linux/openvz совсем вариантов нет? И даже никакого workaround-да, чтобы попроще, чем переписывать все конфиги? 04.12.2013 11:06, Igor Sysoev пишет: [...] >>> А нет ли способа сделать listen на всех ип (как *:80), кроме 127/8 (и, >>> наверное, IPv6:::1) ? >>> >>> Контекст - на разных 127.0.0/24 висят разные бэкенды, и им надо висеть >>> именно на 80ом порту, а внешний(ие) ип (на которые должен биндится >>> нгинх) часто меняются (и их количество вообще может быть не известно, >>> отвечать надо на всех). Хочется делать релоад нгинх без переписывания >>> кучи конфигов (виртуалхостов - много, очень много). >> >> А что за система и ядро? Многие современные, > > [ не Линуксы ] > >> IIUC, позволяют одному слушать на >> *:80 и остальным откусывать у него specific:80 -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From onokonem at gmail.com Mon Dec 9 12:30:14 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Mon, 9 Dec 2013 16:30:14 +0400 Subject: write $request_body to the log Message-ID: Добрый день! В некотором локейшене хочу принять post и записать его в лог. Проксировать его мне никуда не надо, просто принять и записать. Данных там не много, должны влезать в память. Вроде бы, для этой цели должна подойти переменная $request_body. Но в документации написано: =================== $request_body: тело запроса Значение переменной появляется в location'ах, обрабатываемых директивами proxy_pass и fastcgi_pass. =================== По моим наблюдениям - и правда, для локейшенов без проксирования в переменной пусто. Я чего-то недопонял, или так оно и есть? Спасибо. С уважением, Даниил Подольский. From nginx-forum at nginx.us Mon Dec 9 12:55:28 2013 From: nginx-forum at nginx.us (mnsold) Date: Mon, 09 Dec 2013 07:55:28 -0500 Subject: =?UTF-8?B?0J/RgNC+0LrRgdC4IEhUVFBTINC90LAgIG5naW54LzEuNS40INGB0L7QsdGA0LA=?= =?UTF-8?B?0L3QvdGL0Lkg0LLRgNGD0YfQvdGD0Y4gdnMgbmdpbngvMS41Ljcg0LjQtyA=?= =?UTF-8?B?0YDQtdC/0L7Qt9C40YLQvtGA0LjRjw==?= Message-ID: <2b7cc7e4da11ae47b14d915f748ea364.NginxMailingListRussian@forum.nginx.org> Есть два сервера nginx к томуже с разными openssl 1. nginx и opensl собрана вручную (opensl нужна для поддержки ГОСТА), вот эти версии: nginx/1.5.4+OpenSSL 1.0.1e 11 Feb 2013 2. nginx и opensl установленаая из репозитория дебиана, вот эти версии: nginx/1.5.7+OpenSSL 0.9.8o 01 Jun 2010(пробовал так же OpenSSL 1.0.1e ) Оба сервера nginx с openssl установлены на одном хосте. В качестве бэкэнда стоит glassfish 3.1.1. При проксировании в связке конфигурации nginx и opensl (собранные вручную) все нормально проксируется. При проксировании в связке конфигурации nginx и opensl (установленные из репозитория) glassfish не проксируется, пишет "502 Bad Gateway". В логе видно: 2013/12/09 16:45:59 [info] 4630#0: *5 peer closed connection in SSL handshake while SSL handshaking to upstream, client: 192.168.44.151, server: localhost, request: "GET /ised HTTP/1.1", upstream: "https://127.0.0.1:8002/ised", host: "myhost.lan.iac.spb.ru:8183" Замечу, что связка в конфигурации nginx и opensl (установленные из репозитория) прекрасно проксирует https на apache. Подскажите, как локализовать причину. Спасибо! Конфиг понятное дело одинаковый, разниза только в портах на которых он доступен, сам конфиг: server { listen *:8183 ssl; server_name myhost; ssl_certificate /data/cert-ssl/server.crt; ssl_certificate_key /data/cert-ssl/server.key; location / { proxy_pass https://localhost:8002; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } error_log /var/log/nginx/error.log debug; access_log /var/log/nginx/access.log main; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245360,245360#msg-245360 From mdounin at mdounin.ru Mon Dec 9 13:26:34 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 9 Dec 2013 17:26:34 +0400 Subject: write $request_body to the log In-Reply-To: References: Message-ID: <20131209132634.GZ95113@mdounin.ru> Hello! On Mon, Dec 09, 2013 at 04:30:14PM +0400, Daniel Podolsky wrote: > Добрый день! > > В некотором локейшене хочу принять post и записать его в лог. > Проксировать его мне никуда не надо, просто принять и записать. > > Данных там не много, должны влезать в память. > > Вроде бы, для этой цели должна подойти переменная $request_body. > > Но в документации написано: > =================== > $request_body: тело запроса > Значение переменной появляется в location'ах, обрабатываемых > директивами proxy_pass и fastcgi_pass. > =================== > > По моим наблюдениям - и правда, для локейшенов без проксирования в > переменной пусто. > > Я чего-то недопонял, или так оно и есть? Тело запроса читается только в том случае, если оно нужно (e.g, мы собрались его передавать на бекенда). Если не нужно (e.g., при возврате статических файлов или ошибок) - оно просто отбрасывается, и в этом случае в переменной $request_body будет пусто. -- Maxim Dounin http://nginx.org/ From sb at nginx.com Mon Dec 9 13:45:52 2013 From: sb at nginx.com (Sergey Budnevitch) Date: Mon, 9 Dec 2013 17:45:52 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuCBIVFRQUyDQvdCwICBuZ2lueC8xLjUuNCDRgdC+0LE=?= =?UTF-8?B?0YDQsNC90L3Ri9C5INCy0YDRg9GH0L3Rg9GOIHZzIG5naW54LzEuNS43INC4?= =?UTF-8?B?0Lcg0YDQtdC/0L7Qt9C40YLQvtGA0LjRjw==?= In-Reply-To: <2b7cc7e4da11ae47b14d915f748ea364.NginxMailingListRussian@forum.nginx.org> References: <2b7cc7e4da11ae47b14d915f748ea364.NginxMailingListRussian@forum.nginx.org> Message-ID: On 09.12.2013, at 16:55, mnsold wrote: > Подскажите, как локализовать причину. Попробуйте подключиться _штатным_ ( из пакетов ) s_client'ом к glassfish'у: openssl s_client -debug -connect localhost:8002 Посмотрите пройдет ли ssl handshake и если не пройдет, то почему. Посмотрите на glassfish'евский server.log, добавьте, если из лога не будет понятна причина, -Djavax.net.debug=ssl в список параметров для джавы. From onokonem at gmail.com Mon Dec 9 14:04:17 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Mon, 9 Dec 2013 18:04:17 +0400 Subject: write $request_body to the log In-Reply-To: <20131209132634.GZ95113@mdounin.ru> References: <20131209132634.GZ95113@mdounin.ru> Message-ID: 2013/12/9 Maxim Dounin : > Тело запроса читается только в том случае, если оно нужно (e.g, мы > собрались его передавать на бекенда) Это терминологическая путаница. Мне это тело нужно, но передавать я его никуда не собираюсь. Нет ли какого полезного ключа "прочесть тело, даже если проксирование не прописано"? Если нет - нельзя ли его сделать? А то сейчас у меня три варианта, и все они плохие. From vbart at nginx.com Mon Dec 9 14:20:40 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 9 Dec 2013 18:20:40 +0400 Subject: =?UTF-8?B?UmU6INC40YHQv9C+0LvRjNC30L7QstCw0L3QuNC1IG5neCBodHRwIGhlYWRlcnMg?= =?UTF-8?B?bW9kdWxl?= In-Reply-To: References: Message-ID: <201312091820.41029.vbart@nginx.com> On Wednesday 04 December 2013 20:42:21 hexiw wrote: > Здравствуйте, уважаемые форумчане :) Недавно мне понадобилось добавить в > заголовки ответа нестандартный заголовок, мне удалось нагуглить модуль > ngx_http_headers_module и, судя по описанию, он меня целиком устраивает. Но > я не могу понять как его использовать и куда писать, нужные мне, строки. > Буду благодарен если кто подскажет как вообще работать с модулями nginx и > конкретно с ngx_http_headers_module. > И чем документация не устроила? http://nginx.org/ru/docs/http/ngx_http_headers_module.html -- Валентин Бартенев From nginx-forum at nginx.us Mon Dec 9 14:34:23 2013 From: nginx-forum at nginx.us (mnsold) Date: Mon, 09 Dec 2013 09:34:23 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuCBIVFRQUyDQvdCwIG5naW54LzEuNS40INGB0L7QsdGA?= =?UTF-8?B?0LDQvdC90YvQuSDQstGA0YPRh9C90YPRjiB2cyBuZ2lueC8xLjUuNyDQuNC3?= =?UTF-8?B?INGA0LXQv9C+0LfQuNGC0L7RgNC40Y8=?= In-Reply-To: References: Message-ID: > Попробуйте подключиться _штатным_ ( из пакетов ) s_client'ом к glassfish'у: > openssl s_client -debug -connect localhost:8002 Включил > -Djavax.net.debug=ssl На данный момент openssl # openssl version OpenSSL 1.0.1e 11 Feb 2013 # dpkg -l|grep openssl ii openssl 1.0.1e-2 но nginx 1.5.7 использует все равно 0.9.8: # ldd `which nginx` linux-vdso.so.1 => (0x00007fffae33d000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fdd24f6b000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007fdd24d34000) libpcre.so.3 => /lib/libpcre.so.3 (0x00007fdd24b03000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007fdd248ac000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00007fdd2450b000) libz.so.1 => /usr/lib/libz.so.1 (0x00007fdd242f3000) libc.so.6 => /lib/libc.so.6 (0x00007fdd23f91000) /lib64/ld-linux-x86-64.so.2 (0x00007fdd25195000) libdl.so.2 => /lib/libdl.so.2 (0x00007fdd23d8d000) nginx 1.5.4: # ldd `which /data/nginx-gost/sbin/nginx` linux-vdso.so.1 => (0x00007fff695ff000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007ff4330f4000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007ff432ebd000) libpcre.so.3 => /lib/libpcre.so.3 (0x00007ff432c8c000) libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007ff432a2d000) libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007ff432649000) libdl.so.2 => /lib/libdl.so.2 (0x00007ff432444000) libz.so.1 => /usr/lib/libz.so.1 (0x00007ff43222d000) libc.so.6 => /lib/libc.so.6 (0x00007ff431ecb000) /lib64/ld-linux-x86-64.so.2 (0x00007ff43331e000) # openssl s_client -connect localhost:8002 -tlsextdebug CONNECTED(00000003) depth=0 C = US, ST = California, L = Santa Clara, O = Oracle Corporation, OU = GlassFish, CN = myhost.domain.local verify error:num=18:self signed certificate verify return:1 depth=0 C = US, ST = California, L = Santa Clara, O = Oracle Corporation, OU = GlassFish, CN = myhost.domain.local verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Santa Clara/O=Oracle Corporation/OU=GlassFish/CN=myhost.domain.local i:/C=US/ST=California/L=Santa Clara/O=Oracle Corporation/OU=GlassFish/CN=myhost.domain.local --- Server certificate -----BEGIN CERTIFICATE----- MIICsDCCAhmgAwIBAgIEUTCRSzANBgkqhkiG9w0BAQUFADCBijELMAkGA1UEBhMC VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMRsw GQYDVQQKExJPcmFjbGUgQ29ycG9yYXRpb24xEjAQBgNVBAsTCUdsYXNzRmlzaDEf MB0GA1UEAxMWb2N0b3B1cy5sYW4uaWFjLnNwYi5ydTAeFw0xMzAzMDExMTMwMTla Fw0yMzAyMjcxMTMwMTlaMIGKMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExGzAZBgNVBAoTEk9yYWNsZSBDb3Jw b3JhdGlvbjESMBAGA1UECxMJR2xhc3NGaXNoMR8wHQYDVQQDExZvY3RvcHVzLmxh bi5pYWMuc3BiLnJ1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHZ0/bGIlY r12glRa0B8ykVXGuXtzbNr6cqOlQ5ELkyAlW1zwju/JSPxw00zy/elOep/VMFlAg K7Sp+xQYqueWgF6u+05K1FTZeQSsgVO3fSkwbBiX4ObUVawuZoTW0tUs8t1RLUm6 widfiIsFrEjrbMWJ5xqxMwBzMdQnyggN3wIDAQABoyEwHzAdBgNVHQ4EFgQUPsyT ixhlk4gfm5ripc8C1E+J8EwwDQYJKoZIhvcNAQEFBQADgYEAAuaaVnxJN4jsxqHT AAwNyJl0493xApcKnWCFjdugNbCMvv0ez2tYJ4xuQsG0G4rL/zPLATJvQbJM36TO JGXR4P3S/QIDFYDpy6cpCBqg/2P0c/vwh/mK5U10sWnrbfLUlh5sBCM1jza3/wtX /Vqm9py36r3NhaX7hF2KKLG1s7A= -----END CERTIFICATE----- subject=/C=US/ST=California/L=Santa Clara/O=Oracle Corporation/OU=GlassFish/CN=myhost.domain.local issuer=/C=US/ST=California/L=Santa Clara/O=Oracle Corporation/OU=GlassFish/CN=myhost.domain.local --- No client certificate CA names sent --- SSL handshake has read 1264 bytes and written 478 bytes --- New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA Server public key is 1024 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : EDH-RSA-DES-CBC3-SHA Session-ID: 52A5C7084B96822C644DA72CADECFADD2C8684AFE17E63158BD8EB90819682B1 Session-ID-ctx: Master-Key: ECB9F34696C2F27C330007773E9272D9FE539517AC74FD3E94F5CF105AA77BF2DFFEFEE93BE22066F68D42CB080F289F Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1386596104 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) --- Если дедлаю запрос с nginx 1.5.7 (из репозитория), в логах glassfish'а: [#|2013-12-09T18:27:35.338+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=36;_ThreadName=Thread-2;|Using SSLEngineImpl.|#] [#|2013-12-09T18:27:35.338+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=36;_ThreadName=Thread-2;|http-thread-pool-8002(5), READ: TLSv1 Handshake, length = 89|#] [#|2013-12-09T18:27:35.339+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=36;_ThreadName=Thread-2;|http-thread-pool-8002(5), fatal error: 80: problem unwrapping net record javax.net.ssl.SSLException: Unexpected end of handshake data|#] [#|2013-12-09T18:27:35.339+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=36;_ThreadName=Thread-2;|http-thread-pool-8002(5)|#] [#|2013-12-09T18:27:35.339+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=36;_ThreadName=Thread-2;|, SEND TLSv1 ALERT: |#] [#|2013-12-09T18:27:35.339+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=36;_ThreadName=Thread-2;|fatal, |#] [#|2013-12-09T18:27:35.340+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=36;_ThreadName=Thread-2;|description = internal_error|#] [#|2013-12-09T18:27:35.340+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=36;_ThreadName=Thread-2;|http-thread-pool-8002(5), WRITE: TLSv1 Alert, length = 2|#] Других записей нет в логе Если дедлаю запрос с nginx 1.5.7 (сборка в ручную), в логах glassfish'а: [#|2013-12-09T18:30:54.568+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|Using SSLEngineImpl.|#] [#|2013-12-09T18:30:54.568+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|http-thread-pool-8002(4), READ: TLSv1 Handshake, length = 258|#] [#|2013-12-09T18:30:54.569+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|*** ClientHello, TLSv1|#] [#|2013-12-09T18:30:54.569+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|RandomCookie: |#] ... [#|2013-12-09T18:30:54.580+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|Ciph er Suites: [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, Unknown 0xc0:0x22, Unknown 0xc0:0x21, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TL S_DHE_DSS_WITH_AES_256_CBC_SHA, Unknown 0x0:0x88, Unknown 0x0:0x87, Unknown 0x0:0x81, Unknown 0x0:0x80, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_A ES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, Unknown 0x0:0x84, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, Unknown 0xc0:0x1c, U nknown 0xc0:0x1b, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA , SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, Unknown 0xc0:0x1f, Unknown 0xc0:0x1e, TLS_DHE_RSA_WIT H_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, Unknown 0x0:0x9a, Unknown 0x0:0x99, Unknown 0x0:0x45, Unknown 0x0:0x44, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, Unknown 0x0:0x96, Unknown 0x0:0x41, SSL_RSA_WITH_IDEA_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA , TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_DHE_ RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_ RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5, SSL_RSA_EXPORT_WITH_RC4_40_MD5, Unknown 0x0:0xff]|#] [#|2013-12-09T18:30:54.580+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|Comp ression Methods: { |#] [#|2013-12-09T18:30:54.580+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|0|#] [#|2013-12-09T18:30:54.580+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;| }|# ] [#|2013-12-09T18:30:54.580+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|Exte nsion ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]|#] [#|2013-12-09T18:30:54.580+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|Exte nsion elliptic_curves, curve names: {sect571r1, sect571k1, secp521r1, sect409k1, sect409r1, secp384r1, sect283k1, sect283r1, secp256k1, secp256r1, sect239k1, se ct233k1, sect233r1, secp224k1, secp224r1, sect193r1, sect193r2, secp192k1, secp192r1, sect163k1, sect163r1, sect163r2, secp160k1, secp160r1, secp160r2}|#] [#|2013-12-09T18:30:54.581+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|Unsu pported extension type_35, data: |#] [#|2013-12-09T18:30:54.581+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|Unsu pported extension type_15, data: 01|#] [#|2013-12-09T18:30:54.581+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|***| #] [#|2013-12-09T18:30:54.582+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=35;_ThreadName=Thread-2;|%% R esuming [Session-16, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA]|#] ... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245360,245366#msg-245366 From mdounin at mdounin.ru Mon Dec 9 15:01:58 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 9 Dec 2013 19:01:58 +0400 Subject: write $request_body to the log In-Reply-To: References: <20131209132634.GZ95113@mdounin.ru> Message-ID: <20131209150158.GB95113@mdounin.ru> Hello! On Mon, Dec 09, 2013 at 06:04:17PM +0400, Daniel Podolsky wrote: > 2013/12/9 Maxim Dounin : > > Тело запроса читается только в том случае, если оно нужно (e.g, мы > > собрались его передавать на бекенда) > Это терминологическая путаница. Мне это тело нужно, но передавать я > его никуда не собираюсь. > > Нет ли какого полезного ключа "прочесть тело, даже если проксирование > не прописано"? Если нет - нельзя ли его сделать? > > А то сейчас у меня три варианта, и все они плохие. Сейчас - есть ручка во встроенном перле, $r->has_request_body(). http://nginx.org/ru/docs/http/ngx_http_perl_module.html#methods -- Maxim Dounin http://nginx.org/ From sb at nginx.com Mon Dec 9 15:21:07 2013 From: sb at nginx.com (Sergey Budnevitch) Date: Mon, 9 Dec 2013 19:21:07 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuCBIVFRQUyDQvdCwIG5naW54LzEuNS40INGB0L7QsdGA?= =?UTF-8?B?0LDQvdC90YvQuSDQstGA0YPRh9C90YPRjiB2cyBuZ2lueC8xLjUuNyDQuNC3?= =?UTF-8?B?INGA0LXQv9C+0LfQuNGC0L7RgNC40Y8=?= In-Reply-To: References: Message-ID: <23F9094C-FB22-4532-A4D7-4F81F2197BE2@nginx.com> On 09.12.2013, at 18:34, mnsold wrote: >> Попробуйте подключиться _штатным_ ( из пакетов ) s_client'ом к > glassfish'у: >> openssl s_client -debug -connect localhost:8002 > > Включил >> -Djavax.net.debug=ssl > > На данный момент openssl > # openssl version > OpenSSL 1.0.1e 11 Feb 2013 > # dpkg -l|grep openssl > ii openssl 1.0.1e-2 > > но nginx 1.5.7 использует все равно 0.9.8: Добавьте proxy_ssl_protocols SSLv3; Посмотрите, исчезнет ли проблема. Проблема, возможно, в том, что nginx с openssl 0.9.8 шлет session ticket, который вызывает ошибку в реализации SSL в java. Чтобы убедиться поставьте openssl из 0.9.8 и проверьте s_client c и без -no_ticket. openssl из 1.0.1e у вас тикет не шлет. From onokonem at gmail.com Mon Dec 9 15:21:43 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Mon, 9 Dec 2013 19:21:43 +0400 Subject: write $request_body to the log In-Reply-To: <20131209150158.GB95113@mdounin.ru> References: <20131209132634.GZ95113@mdounin.ru> <20131209150158.GB95113@mdounin.ru> Message-ID: 2013/12/9 Maxim Dounin : > Сейчас - есть ручка во встроенном перле, $r->has_request_body(). это один из тез трех вариантов, что мне не нравятся... From nginx-forum at nginx.us Tue Dec 10 01:45:15 2013 From: nginx-forum at nginx.us (ruv) Date: Mon, 09 Dec 2013 20:45:15 -0500 Subject: =?UTF-8?Q?http_browser_module_=E2=80=94_ancient_browser?= Message-ID: <31ab62c60b42b68532b84889173afacc.NginxMailingListRussian@forum.nginx.org> День добрый! Вопрос такой. Должны ли дериктивы модуля http_browser располагаться в том же блоке (http, server, location), что и проверка соответствующих переменных? В документации об этом ни слова. А то у меня что-то криво работал код if ($ancient_browser) { ... } внутри location ? получалось always true, когда директивы modern_browser и ancient_browser заданы на уровне server. -- Ruvim Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245376,245376#msg-245376 From chipitsine at gmail.com Tue Dec 10 03:13:16 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 10 Dec 2013 09:13:16 +0600 Subject: =?UTF-8?B?0L/QsNGC0Ycg0LTQu9GPINC+0YLQutC70Y7Rh9C10L3QuNGPINC30LDQs9C+0Ls=?= =?UTF-8?B?0L7QstC60L7QsiAiQ29ubmVjdGlvbjoga2VlcC1hbGl2ZSIgKNC10YnQtSA=?= =?UTF-8?B?0YDQsNC3KQ==?= Message-ID: Добрый день! как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен. идея в том, что отправка заголовка "Connection: keep-alive" в большинстве случаев не нужна. абонентская база - сотни тысяч пользователей, сотни миллионов запросов в месяц. думаю, спустя месяц-два можно будет считать, что все протестировано во всех возможных ситуациях. желающие - приглашаются к тестированию. данное поведение "подсмотрено" у IIS, который по любым метрикам занимает десятки процентов "рынка": http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html - поэтому есть уверенность, что все обойдется без побочных эффектов diff --git a/src/http/ngx_http_header_filter_module.c b/src/http/ngx_http_header_filter_module.c index 707a813..759186f 100644 --- a/src/http/ngx_http_header_filter_module.c +++ b/src/http/ngx_http_header_filter_module.c @@ -383,7 +383,10 @@ ngx_http_header_filter(ngx_http_request_t *r) len += sizeof("Connection: upgrade" CRLF) - 1; } else if (r->keepalive) { + + if ((r->http_version == NGX_HTTP_VERSION_10) || (clcf->keepalive_header)) { len += sizeof("Connection: keep-alive" CRLF) - 1; + } /* * MSIE and Opera ignore the "Keep-Alive: timeout=" header. @@ -556,8 +559,10 @@ ngx_http_header_filter(ngx_http_request_t *r) sizeof("Connection: upgrade" CRLF) - 1); } else if (r->keepalive) { - b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF, + if ((r->http_version == NGX_HTTP_VERSION_10) || (clcf->keepalive_header)) { + b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF, sizeof("Connection: keep-alive" CRLF) - 1); + } if (clcf->keepalive_header) { b->last = ngx_sprintf(b->last, "Keep-Alive: timeout=%T" CRLF, From mdounin at mdounin.ru Tue Dec 10 11:13:49 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 10 Dec 2013 15:13:49 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: References: Message-ID: <20131210111349.GE95113@mdounin.ru> Hello! On Tue, Dec 10, 2013 at 09:13:16AM +0600, Илья Шипицин wrote: > Добрый день! > > как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен. > идея в том, что отправка заголовка "Connection: keep-alive" в > большинстве случаев не нужна. > > абонентская база - сотни тысяч пользователей, сотни миллионов запросов > в месяц. думаю, спустя месяц-два можно будет считать, что все > протестировано во всех возможных ситуациях. > > > желающие - приглашаются к тестированию. > > данное поведение "подсмотрено" у IIS, который по любым метрикам > занимает десятки процентов "рынка": > http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html > - поэтому есть уверенность, что все обойдется без побочных эффектов Илья, я вроде как сделал патч с таким поведением ещё в процессе прошлого обсуждения: http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051059.html Странно видить попытки изобрести велосипед заново вместо того, чтобы заняться тестированием и последующим убеждением, что это надо закоммитить, тем более про "тщательное тестирование" было явно написано. ;) -- Maxim Dounin http://nginx.org/ From chipitsine at gmail.com Tue Dec 10 11:16:45 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 10 Dec 2013 17:16:45 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: <20131210111349.GE95113@mdounin.ru> References: <20131210111349.GE95113@mdounin.ru> Message-ID: 10 декабря 2013 г., 17:13 пользователь Maxim Dounin написал: > Hello! > > On Tue, Dec 10, 2013 at 09:13:16AM +0600, Илья Шипицин wrote: > >> Добрый день! >> >> как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен. >> идея в том, что отправка заголовка "Connection: keep-alive" в >> большинстве случаев не нужна. >> >> абонентская база - сотни тысяч пользователей, сотни миллионов запросов >> в месяц. думаю, спустя месяц-два можно будет считать, что все >> протестировано во всех возможных ситуациях. >> >> >> желающие - приглашаются к тестированию. >> >> данное поведение "подсмотрено" у IIS, который по любым метрикам >> занимает десятки процентов "рынка": >> http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html >> - поэтому есть уверенность, что все обойдется без побочных эффектов > > Илья, я вроде как сделал патч с таким поведением ещё в процессе > прошлого обсуждения: > > http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051059.html > > Странно видить попытки изобрести велосипед заново вместо того, > чтобы заняться тестированием и последующим убеждением, что это > надо закоммитить, тем более про "тщательное тестирование" было > явно написано. ;) это именно та тема и есть, сейчас дошли руки "тщательно протестировать". я запустил в продакшн. ждем пару месяцев (и, если проблем не всплывает, считаем, что все ок) ? > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Tue Dec 10 13:37:20 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 10 Dec 2013 17:37:20 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: References: <20131210111349.GE95113@mdounin.ru> Message-ID: <20131210133720.GF95113@mdounin.ru> Hello! On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote: > 10 декабря 2013 г., 17:13 пользователь Maxim Dounin > написал: > > Hello! > > > > On Tue, Dec 10, 2013 at 09:13:16AM +0600, Илья Шипицин wrote: > > > >> Добрый день! > >> > >> как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен. > >> идея в том, что отправка заголовка "Connection: keep-alive" в > >> большинстве случаев не нужна. > >> > >> абонентская база - сотни тысяч пользователей, сотни миллионов запросов > >> в месяц. думаю, спустя месяц-два можно будет считать, что все > >> протестировано во всех возможных ситуациях. > >> > >> > >> желающие - приглашаются к тестированию. > >> > >> данное поведение "подсмотрено" у IIS, который по любым метрикам > >> занимает десятки процентов "рынка": > >> http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html > >> - поэтому есть уверенность, что все обойдется без побочных эффектов > > > > Илья, я вроде как сделал патч с таким поведением ещё в процессе > > прошлого обсуждения: > > > > http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051059.html > > > > Странно видить попытки изобрести велосипед заново вместо того, > > чтобы заняться тестированием и последующим убеждением, что это > > надо закоммитить, тем более про "тщательное тестирование" было > > явно написано. ;) > > это именно та тема и есть, сейчас дошли руки "тщательно > протестировать". я запустил в продакшн. Меня в первую очередь удивило, что вместо патча, нарисованного ещё полгода назад, к письму о "потестировать" прилагается совсем другой патч, с чуть-чуть другими условиями и стилистическими проблемами. Я бы всё-таки рекомендовал тестировать то, что потом будем коммитить. > ждем пару месяцев (и, если проблем не всплывает, считаем, что все ок) ? Я, честно говоря, пребывал в надежде, что патч уже полгода тестируется. ;) Но если нет - то, видимо, так и делаем. Только просьба - взять для тестирования патч в том виде, в каком его предполагается коммитить, if any: # HG changeset patch # User Maxim Dounin # Date 1386675580 -14400 # Tue Dec 10 15:39:40 2013 +0400 # Node ID 178020375791a638c79cfe1330bddabbf830f0bf # Parent 58716fd3bd2d63c93b0c04fa121232b7126e724b Http: Connection header sending change. Now "Connection: keep-alive" isn't sent if persistent connections are used by default (in HTTP/1.1) and we don't add Keep-Alive header. This is an experimental patch, see here for discussion: http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051052.html diff --git a/src/http/ngx_http_header_filter_module.c b/src/http/ngx_http_header_filter_module.c --- a/src/http/ngx_http_header_filter_module.c +++ b/src/http/ngx_http_header_filter_module.c @@ -386,7 +386,10 @@ ngx_http_header_filter(ngx_http_request_ len += sizeof("Connection: upgrade" CRLF) - 1; } else if (r->keepalive) { - len += sizeof("Connection: keep-alive" CRLF) - 1; + + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) { + len += sizeof("Connection: keep-alive" CRLF) - 1; + } /* * MSIE and Opera ignore the "Keep-Alive: timeout=" header. @@ -559,8 +562,11 @@ ngx_http_header_filter(ngx_http_request_ sizeof("Connection: upgrade" CRLF) - 1); } else if (r->keepalive) { - b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF, - sizeof("Connection: keep-alive" CRLF) - 1); + + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) { + b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF, + sizeof("Connection: keep-alive" CRLF) - 1); + } if (clcf->keepalive_header) { b->last = ngx_sprintf(b->last, "Keep-Alive: timeout=%T" CRLF, -- Maxim Dounin http://nginx.org/ From chipitsine at gmail.com Tue Dec 10 15:22:02 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 10 Dec 2013 21:22:02 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: <20131210133720.GF95113@mdounin.ru> References: <20131210111349.GE95113@mdounin.ru> <20131210133720.GF95113@mdounin.ru> Message-ID: 10 декабря 2013 г., 19:37 пользователь Maxim Dounin написал: > Hello! > > On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote: > >> 10 декабря 2013 г., 17:13 пользователь Maxim Dounin >> написал: >> > Hello! >> > >> > On Tue, Dec 10, 2013 at 09:13:16AM +0600, Илья Шипицин wrote: >> > >> >> Добрый день! >> >> >> >> как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен. >> >> идея в том, что отправка заголовка "Connection: keep-alive" в >> >> большинстве случаев не нужна. >> >> >> >> абонентская база - сотни тысяч пользователей, сотни миллионов запросов >> >> в месяц. думаю, спустя месяц-два можно будет считать, что все >> >> протестировано во всех возможных ситуациях. >> >> >> >> >> >> желающие - приглашаются к тестированию. >> >> >> >> данное поведение "подсмотрено" у IIS, который по любым метрикам >> >> занимает десятки процентов "рынка": >> >> http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html >> >> - поэтому есть уверенность, что все обойдется без побочных эффектов >> > >> > Илья, я вроде как сделал патч с таким поведением ещё в процессе >> > прошлого обсуждения: >> > >> > http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051059.html >> > >> > Странно видить попытки изобрести велосипед заново вместо того, >> > чтобы заняться тестированием и последующим убеждением, что это >> > надо закоммитить, тем более про "тщательное тестирование" было >> > явно написано. ;) >> >> это именно та тема и есть, сейчас дошли руки "тщательно >> протестировать". я запустил в продакшн. > > Меня в первую очередь удивило, что вместо патча, нарисованного ещё > полгода назад, к письму о "потестировать" прилагается совсем > другой патч, с чуть-чуть другими условиями и стилистическими > проблемами. Я бы всё-таки рекомендовал тестировать то, что потом > будем коммитить. > >> ждем пару месяцев (и, если проблем не всплывает, считаем, что все ок) ? > > Я, честно говоря, пребывал в надежде, что патч уже полгода > тестируется. ;) > > Но если нет - то, видимо, так и делаем. Только просьба - взять > для тестирования патч в том виде, в каком его предполагается > коммитить, if any: без проблем. сегодня запущу в продакшн в таком виде не совсем понятно, зачем делать условие "r->http_version < NGX_HTTP_VERSION_11" для версии 0.9, насколько я понимаю, и в моем и в вашем случае будет фигня > > # HG changeset patch > # User Maxim Dounin > # Date 1386675580 -14400 > # Tue Dec 10 15:39:40 2013 +0400 > # Node ID 178020375791a638c79cfe1330bddabbf830f0bf > # Parent 58716fd3bd2d63c93b0c04fa121232b7126e724b > Http: Connection header sending change. > > Now "Connection: keep-alive" isn't sent if persistent connections are > used by default (in HTTP/1.1) and we don't add Keep-Alive header. > > This is an experimental patch, see here for discussion: > http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051052.html > > diff --git a/src/http/ngx_http_header_filter_module.c b/src/http/ngx_http_header_filter_module.c > --- a/src/http/ngx_http_header_filter_module.c > +++ b/src/http/ngx_http_header_filter_module.c > @@ -386,7 +386,10 @@ ngx_http_header_filter(ngx_http_request_ > len += sizeof("Connection: upgrade" CRLF) - 1; > > } else if (r->keepalive) { > - len += sizeof("Connection: keep-alive" CRLF) - 1; > + > + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) { > + len += sizeof("Connection: keep-alive" CRLF) - 1; > + } > > /* > * MSIE and Opera ignore the "Keep-Alive: timeout=" header. > @@ -559,8 +562,11 @@ ngx_http_header_filter(ngx_http_request_ > sizeof("Connection: upgrade" CRLF) - 1); > > } else if (r->keepalive) { > - b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF, > - sizeof("Connection: keep-alive" CRLF) - 1); > + > + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) { > + b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF, > + sizeof("Connection: keep-alive" CRLF) - 1); > + } > > if (clcf->keepalive_header) { > b->last = ngx_sprintf(b->last, "Keep-Alive: timeout=%T" CRLF, > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Tue Dec 10 16:05:15 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 10 Dec 2013 20:05:15 +0400 Subject: =?UTF-8?Q?Re=3A_http_browser_module_=E2=80=94_ancient_browser?= In-Reply-To: <31ab62c60b42b68532b84889173afacc.NginxMailingListRussian@forum.nginx.org> References: <31ab62c60b42b68532b84889173afacc.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131210160515.GK95113@mdounin.ru> Hello! On Mon, Dec 09, 2013 at 08:45:15PM -0500, ruv wrote: > День добрый! > > Вопрос такой. Должны ли дериктивы модуля http_browser располагаться в том же > блоке (http, server, location), что и проверка соответствующих переменных? В > документации об этом ни слова. Не должны. Применяются обычные правила наследования - если на текущем уровне не заданы свои директивы modern_browser, то используются директивы, заданные на предыдущем уровне. Аналогично для ancient_browser. > А то у меня что-то криво работал код if ($ancient_browser) { ... } внутри > location ? получалось always true, когда директивы modern_browser и > ancient_browser заданы на уровне server. См. выше, должно работать. Следует, однако, иметь ввиду, что if в location имеет свои неповторимые особенности, http://wiki.nginx.org/IfIsEvil. -- Maxim Dounin http://nginx.org/ From mdounin at mdounin.ru Tue Dec 10 16:37:49 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 10 Dec 2013 20:37:49 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: References: <20131210111349.GE95113@mdounin.ru> <20131210133720.GF95113@mdounin.ru> Message-ID: <20131210163749.GL95113@mdounin.ru> Hello! On Tue, Dec 10, 2013 at 09:22:02PM +0600, Илья Шипицин wrote: > 10 декабря 2013 г., 19:37 пользователь Maxim Dounin > написал: > > Hello! > > > > On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote: > > > >> 10 декабря 2013 г., 17:13 пользователь Maxim Dounin > >> написал: > >> > Hello! > >> > > >> > On Tue, Dec 10, 2013 at 09:13:16AM +0600, Илья Шипицин wrote: > >> > > >> >> Добрый день! > >> >> > >> >> как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен. > >> >> идея в том, что отправка заголовка "Connection: keep-alive" в > >> >> большинстве случаев не нужна. > >> >> > >> >> абонентская база - сотни тысяч пользователей, сотни миллионов запросов > >> >> в месяц. думаю, спустя месяц-два можно будет считать, что все > >> >> протестировано во всех возможных ситуациях. > >> >> > >> >> > >> >> желающие - приглашаются к тестированию. > >> >> > >> >> данное поведение "подсмотрено" у IIS, который по любым метрикам > >> >> занимает десятки процентов "рынка": > >> >> http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html > >> >> - поэтому есть уверенность, что все обойдется без побочных эффектов > >> > > >> > Илья, я вроде как сделал патч с таким поведением ещё в процессе > >> > прошлого обсуждения: > >> > > >> > http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051059.html > >> > > >> > Странно видить попытки изобрести велосипед заново вместо того, > >> > чтобы заняться тестированием и последующим убеждением, что это > >> > надо закоммитить, тем более про "тщательное тестирование" было > >> > явно написано. ;) > >> > >> это именно та тема и есть, сейчас дошли руки "тщательно > >> протестировать". я запустил в продакшн. > > > > Меня в первую очередь удивило, что вместо патча, нарисованного ещё > > полгода назад, к письму о "потестировать" прилагается совсем > > другой патч, с чуть-чуть другими условиями и стилистическими > > проблемами. Я бы всё-таки рекомендовал тестировать то, что потом > > будем коммитить. > > > >> ждем пару месяцев (и, если проблем не всплывает, считаем, что все ок) ? > > > > Я, честно говоря, пребывал в надежде, что патч уже полгода > > тестируется. ;) > > > > Но если нет - то, видимо, так и делаем. Только просьба - взять > > для тестирования патч в том виде, в каком его предполагается > > коммитить, if any: > > без проблем. сегодня запущу в продакшн в таком виде > > не совсем понятно, зачем делать условие "r->http_version < NGX_HTTP_VERSION_11" > для версии 0.9, насколько я понимаю, и в моем и в вашем случае будет фигня Для 0.9 всё это не будет выполняться, т.к. будет отсечено проверкой if (r->http_version < NGX_HTTP_VERSION_10) { return NGX_OK; } в начале функции. Принципиальной разницы между патчами нет, вопрос в основном стилистический (с учётом того, что между HTTP/1.0 и HTTP/1.1 других версий быть не может). -- Maxim Dounin http://nginx.org/ From chipitsine at gmail.com Tue Dec 10 17:12:16 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 10 Dec 2013 23:12:16 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: <20131210163749.GL95113@mdounin.ru> References: <20131210111349.GE95113@mdounin.ru> <20131210133720.GF95113@mdounin.ru> <20131210163749.GL95113@mdounin.ru> Message-ID: 10 декабря 2013 г., 22:37 пользователь Maxim Dounin написал: > Hello! > > On Tue, Dec 10, 2013 at 09:22:02PM +0600, Илья Шипицин wrote: > >> 10 декабря 2013 г., 19:37 пользователь Maxim Dounin >> написал: >> > Hello! >> > >> > On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote: >> > >> >> 10 декабря 2013 г., 17:13 пользователь Maxim Dounin >> >> написал: >> >> > Hello! >> >> > >> >> > On Tue, Dec 10, 2013 at 09:13:16AM +0600, Илья Шипицин wrote: >> >> > >> >> >> Добрый день! >> >> >> >> >> >> как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен. >> >> >> идея в том, что отправка заголовка "Connection: keep-alive" в >> >> >> большинстве случаев не нужна. >> >> >> >> >> >> абонентская база - сотни тысяч пользователей, сотни миллионов запросов >> >> >> в месяц. думаю, спустя месяц-два можно будет считать, что все >> >> >> протестировано во всех возможных ситуациях. >> >> >> >> >> >> >> >> >> желающие - приглашаются к тестированию. >> >> >> >> >> >> данное поведение "подсмотрено" у IIS, который по любым метрикам >> >> >> занимает десятки процентов "рынка": >> >> >> http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html >> >> >> - поэтому есть уверенность, что все обойдется без побочных эффектов >> >> > >> >> > Илья, я вроде как сделал патч с таким поведением ещё в процессе >> >> > прошлого обсуждения: >> >> > >> >> > http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051059.html >> >> > >> >> > Странно видить попытки изобрести велосипед заново вместо того, >> >> > чтобы заняться тестированием и последующим убеждением, что это >> >> > надо закоммитить, тем более про "тщательное тестирование" было >> >> > явно написано. ;) >> >> >> >> это именно та тема и есть, сейчас дошли руки "тщательно >> >> протестировать". я запустил в продакшн. >> > >> > Меня в первую очередь удивило, что вместо патча, нарисованного ещё >> > полгода назад, к письму о "потестировать" прилагается совсем >> > другой патч, с чуть-чуть другими условиями и стилистическими >> > проблемами. Я бы всё-таки рекомендовал тестировать то, что потом >> > будем коммитить. >> > >> >> ждем пару месяцев (и, если проблем не всплывает, считаем, что все ок) ? >> > >> > Я, честно говоря, пребывал в надежде, что патч уже полгода >> > тестируется. ;) >> > >> > Но если нет - то, видимо, так и делаем. Только просьба - взять >> > для тестирования патч в том виде, в каком его предполагается >> > коммитить, if any: >> >> без проблем. сегодня запущу в продакшн в таком виде >> >> не совсем понятно, зачем делать условие "r->http_version < NGX_HTTP_VERSION_11" >> для версии 0.9, насколько я понимаю, и в моем и в вашем случае будет фигня > > Для 0.9 всё это не будет выполняться, т.к. будет отсечено > проверкой > > if (r->http_version < NGX_HTTP_VERSION_10) { > return NGX_OK; > } > > в начале функции. Принципиальной разницы между патчами нет, > вопрос в основном стилистический (с учётом того, что между > HTTP/1.0 и HTTP/1.1 других версий быть не может). тогда получается, что мой вариант лучше. для 0.9 по RFC не бывает keep-alive для 1.0 у меня сравнение по равенству > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Tue Dec 10 18:43:03 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 10 Dec 2013 22:43:03 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: References: <20131210111349.GE95113@mdounin.ru> <20131210133720.GF95113@mdounin.ru> <20131210163749.GL95113@mdounin.ru> Message-ID: <20131210184303.GR95113@mdounin.ru> Hello! On Tue, Dec 10, 2013 at 11:12:16PM +0600, Илья Шипицин wrote: > 10 декабря 2013 г., 22:37 пользователь Maxim Dounin > написал: > > Hello! > > > > On Tue, Dec 10, 2013 at 09:22:02PM +0600, Илья Шипицин wrote: > > > >> 10 декабря 2013 г., 19:37 пользователь Maxim Dounin > >> написал: > >> > Hello! > >> > > >> > On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote: > >> > > >> >> 10 декабря 2013 г., 17:13 пользователь Maxim Dounin > >> >> написал: > >> >> > Hello! > >> >> > > >> >> > On Tue, Dec 10, 2013 at 09:13:16AM +0600, Илья Шипицин wrote: > >> >> > > >> >> >> Добрый день! > >> >> >> > >> >> >> как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен. > >> >> >> идея в том, что отправка заголовка "Connection: keep-alive" в > >> >> >> большинстве случаев не нужна. > >> >> >> > >> >> >> абонентская база - сотни тысяч пользователей, сотни миллионов запросов > >> >> >> в месяц. думаю, спустя месяц-два можно будет считать, что все > >> >> >> протестировано во всех возможных ситуациях. > >> >> >> > >> >> >> > >> >> >> желающие - приглашаются к тестированию. > >> >> >> > >> >> >> данное поведение "подсмотрено" у IIS, который по любым метрикам > >> >> >> занимает десятки процентов "рынка": > >> >> >> http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html > >> >> >> - поэтому есть уверенность, что все обойдется без побочных эффектов > >> >> > > >> >> > Илья, я вроде как сделал патч с таким поведением ещё в процессе > >> >> > прошлого обсуждения: > >> >> > > >> >> > http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051059.html > >> >> > > >> >> > Странно видить попытки изобрести велосипед заново вместо того, > >> >> > чтобы заняться тестированием и последующим убеждением, что это > >> >> > надо закоммитить, тем более про "тщательное тестирование" было > >> >> > явно написано. ;) > >> >> > >> >> это именно та тема и есть, сейчас дошли руки "тщательно > >> >> протестировать". я запустил в продакшн. > >> > > >> > Меня в первую очередь удивило, что вместо патча, нарисованного ещё > >> > полгода назад, к письму о "потестировать" прилагается совсем > >> > другой патч, с чуть-чуть другими условиями и стилистическими > >> > проблемами. Я бы всё-таки рекомендовал тестировать то, что потом > >> > будем коммитить. > >> > > >> >> ждем пару месяцев (и, если проблем не всплывает, считаем, что все ок) ? > >> > > >> > Я, честно говоря, пребывал в надежде, что патч уже полгода > >> > тестируется. ;) > >> > > >> > Но если нет - то, видимо, так и делаем. Только просьба - взять > >> > для тестирования патч в том виде, в каком его предполагается > >> > коммитить, if any: > >> > >> без проблем. сегодня запущу в продакшн в таком виде > >> > >> не совсем понятно, зачем делать условие "r->http_version < NGX_HTTP_VERSION_11" > >> для версии 0.9, насколько я понимаю, и в моем и в вашем случае будет фигня > > > > Для 0.9 всё это не будет выполняться, т.к. будет отсечено > > проверкой > > > > if (r->http_version < NGX_HTTP_VERSION_10) { > > return NGX_OK; > > } > > > > в начале функции. Принципиальной разницы между патчами нет, > > вопрос в основном стилистический (с учётом того, что между > > HTTP/1.0 и HTTP/1.1 других версий быть не может). > > тогда получается, что мой вариант лучше. > > для 0.9 по RFC не бывает keep-alive > для 1.0 у меня сравнение по равенству Не согласен, т.к. важно не то, что в HTTP/1.0 нет keepalive'а по умолчанию, а то, что keepalive по умолчанию есть в HTTP/1.1 и выше, а в версиях до HTTP/1.1 его нужно явно включать. В условиях, когда у нас есть только HTTP/1.0 и HTTP/1.1, и никаких промежуточных версий быть не может - патчи эквивалентны, и различие только стилистическое. Но если бы был ещё какой-нибудь HTTP/1.(1/2) - сравнение с HTTP/1.0 было бы неправильным. (И таки да, не бывает keepalive'а в HTTP/0.9 потому, что там нет заголовков. Если бы они были - никто не мешает и там быть keepalive'у - если о нём договорились, аналогично соответствующей процедуре в HTTP/1.0.) -- Maxim Dounin http://nginx.org/ From chipitsine at gmail.com Tue Dec 10 19:39:21 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 11 Dec 2013 01:39:21 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: <20131210184303.GR95113@mdounin.ru> References: <20131210111349.GE95113@mdounin.ru> <20131210133720.GF95113@mdounin.ru> <20131210163749.GL95113@mdounin.ru> <20131210184303.GR95113@mdounin.ru> Message-ID: 11 декабря 2013 г., 0:43 пользователь Maxim Dounin написал: > Hello! > > On Tue, Dec 10, 2013 at 11:12:16PM +0600, Илья Шипицин wrote: > >> 10 декабря 2013 г., 22:37 пользователь Maxim Dounin >> написал: >> > Hello! >> > >> > On Tue, Dec 10, 2013 at 09:22:02PM +0600, Илья Шипицин wrote: >> > >> >> 10 декабря 2013 г., 19:37 пользователь Maxim Dounin >> >> написал: >> >> > Hello! >> >> > >> >> > On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote: >> >> > >> >> >> 10 декабря 2013 г., 17:13 пользователь Maxim Dounin >> >> >> написал: >> >> >> > Hello! >> >> >> > >> >> >> > On Tue, Dec 10, 2013 at 09:13:16AM +0600, Илья Шипицин wrote: >> >> >> > >> >> >> >> Добрый день! >> >> >> >> >> >> >> >> как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен. >> >> >> >> идея в том, что отправка заголовка "Connection: keep-alive" в >> >> >> >> большинстве случаев не нужна. >> >> >> >> >> >> >> >> абонентская база - сотни тысяч пользователей, сотни миллионов запросов >> >> >> >> в месяц. думаю, спустя месяц-два можно будет считать, что все >> >> >> >> протестировано во всех возможных ситуациях. >> >> >> >> >> >> >> >> >> >> >> >> желающие - приглашаются к тестированию. >> >> >> >> >> >> >> >> данное поведение "подсмотрено" у IIS, который по любым метрикам >> >> >> >> занимает десятки процентов "рынка": >> >> >> >> http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html >> >> >> >> - поэтому есть уверенность, что все обойдется без побочных эффектов >> >> >> > >> >> >> > Илья, я вроде как сделал патч с таким поведением ещё в процессе >> >> >> > прошлого обсуждения: >> >> >> > >> >> >> > http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051059.html >> >> >> > >> >> >> > Странно видить попытки изобрести велосипед заново вместо того, >> >> >> > чтобы заняться тестированием и последующим убеждением, что это >> >> >> > надо закоммитить, тем более про "тщательное тестирование" было >> >> >> > явно написано. ;) >> >> >> >> >> >> это именно та тема и есть, сейчас дошли руки "тщательно >> >> >> протестировать". я запустил в продакшн. >> >> > >> >> > Меня в первую очередь удивило, что вместо патча, нарисованного ещё >> >> > полгода назад, к письму о "потестировать" прилагается совсем >> >> > другой патч, с чуть-чуть другими условиями и стилистическими >> >> > проблемами. Я бы всё-таки рекомендовал тестировать то, что потом >> >> > будем коммитить. >> >> > >> >> >> ждем пару месяцев (и, если проблем не всплывает, считаем, что все ок) ? >> >> > >> >> > Я, честно говоря, пребывал в надежде, что патч уже полгода >> >> > тестируется. ;) >> >> > >> >> > Но если нет - то, видимо, так и делаем. Только просьба - взять >> >> > для тестирования патч в том виде, в каком его предполагается >> >> > коммитить, if any: >> >> >> >> без проблем. сегодня запущу в продакшн в таком виде >> >> >> >> не совсем понятно, зачем делать условие "r->http_version < NGX_HTTP_VERSION_11" >> >> для версии 0.9, насколько я понимаю, и в моем и в вашем случае будет фигня >> > >> > Для 0.9 всё это не будет выполняться, т.к. будет отсечено >> > проверкой >> > >> > if (r->http_version < NGX_HTTP_VERSION_10) { >> > return NGX_OK; >> > } >> > >> > в начале функции. Принципиальной разницы между патчами нет, >> > вопрос в основном стилистический (с учётом того, что между >> > HTTP/1.0 и HTTP/1.1 других версий быть не может). >> >> тогда получается, что мой вариант лучше. >> >> для 0.9 по RFC не бывает keep-alive >> для 1.0 у меня сравнение по равенству > > Не согласен, т.к. важно не то, что в HTTP/1.0 нет keepalive'а по > умолчанию, а то, что keepalive по умолчанию есть в HTTP/1.1 и > выше, а в версиях до HTTP/1.1 его нужно явно включать. > > В условиях, когда у нас есть только HTTP/1.0 и HTTP/1.1, и никаких > промежуточных версий быть не может - патчи эквивалентны, и > различие только стилистическое. Но если бы был ещё какой-нибудь > HTTP/1.(1/2) - сравнение с HTTP/1.0 было бы неправильным. Максим, почему вы думаете, что разработчики RFC для HTTP/1.(1/2) заложат поведение, идентичное HTTP/1.0 ? ваш вариант это подразумевает. я не уверен, что будет именно так. я могу обосновать, что выпуск промежуточной версии между 1.0 и 1.1 означает, что разработчики RFC попрощались с здравым смыслом. и в этом случае делать предположения опасно. на данный момент определено поведение keep-alive для версий 0.9 (отсутствует как класс) 1.0 (необходим явный хедер Connection: keep-alive) 1.1 (в некоторых случаях хедер можно опустить) я предлагаю не вводить пользователь в заблуждение сравнение "<" с вытекающим возможным побочным эффектом, если вдруг промежуточная версия между 1.0 и 1.1 появится и будет себя особым образом вести > > (И таки да, не бывает keepalive'а в HTTP/0.9 потому, что там нет > заголовков. Если бы они были - никто не мешает и там быть > keepalive'у - если о нём договорились, аналогично соответствующей > процедуре в HTTP/1.0.) > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Wed Dec 11 06:58:14 2013 From: nginx-forum at nginx.us (mnsold) Date: Wed, 11 Dec 2013 01:58:14 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuCBIVFRQUyDQvdCwIG5naW54LzEuNS40INGB0L7QsdGA?= =?UTF-8?B?0LDQvdC90YvQuSDQstGA0YPRh9C90YPRjiB2cyBuZ2lueC8xLjUuNyDQuNC3?= =?UTF-8?B?INGA0LXQv9C+0LfQuNGC0L7RgNC40Y8=?= In-Reply-To: <23F9094C-FB22-4532-A4D7-4F81F2197BE2@nginx.com> References: <23F9094C-FB22-4532-A4D7-4F81F2197BE2@nginx.com> Message-ID: > Добавьте > proxy_ssl_protocols SSLv3; Спасибо, эта директива помогла. Ниже написал решение Ранее я писал что пробовал nginx 1.5.7 с 1.0.1e-2, это оказалось не так, он все равно подгружал библиоетки openssl версии 0.9.8: # ldd `which nginx` linux-vdso.so.1 => (0x00007fffae33d000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fdd24f6b000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007fdd24d34000) libpcre.so.3 => /lib/libpcre.so.3 (0x00007fdd24b03000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007fdd248ac000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00007fdd2450b000) libz.so.1 => /usr/lib/libz.so.1 (0x00007fdd242f3000) libc.so.6 => /lib/libc.so.6 (0x00007fdd23f91000) /lib64/ld-linux-x86-64.so.2 (0x00007fdd25195000) libdl.so.2 => /lib/libdl.so.2 (0x00007fdd23d8d000) Для работы с openssl 0.9.8 c glassfish (java) необходимо прописать директиву (доступна в nginx начиная с версии 1.5.6): proxy_ssl_protocols SSLv3; С данной дерективой https работает без проблем. Также проверена работа версии nginx 1.5.7 из другого репозитория которая скомпилирована с openssl 1.0 -> https работает без проблем c glassfish (java), директива "proxy_ssl_protocols SSLv3;" не нужна. # ldd `which nginx` linux-vdso.so.1 => (0x00007fff5fccc000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f0b1a48d000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f0b1a256000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f0b1a018000) libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f0b19db9000) libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f0b199d5000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f0b197bd000) libc.so.6 => /lib/libc.so.6 (0x00007f0b1945b000) /lib64/ld-linux-x86-64.so.2 (0x00007f0b1a6b8000) libdl.so.2 => /lib/libdl.so.2 (0x00007f0b19257000) Итого 2 решения проблемы: 1. в случае с openssl 0.9.8 используем параметр (доступна в nginx начиная с версии 1.5.6 proxy_ssl_protocols SSLv3; 2. ставим nginx который работает с openssl 1.0 Сергей, спасибо за помощь поисках решения проблемы. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245360,245408#msg-245408 From nginx-forum at nginx.us Wed Dec 11 11:04:55 2013 From: nginx-forum at nginx.us (mnsold) Date: Wed, 11 Dec 2013 06:04:55 -0500 Subject: =?UTF-8?B?0J/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUgaHR0cCDQuCBodHRwcyDQsiDQvtC0?= =?UTF-8?B?0L3QvtC8INC60L7QvdC40LPRg9GA0LDRhtC40L7QvdC90L7QvCDRhNCw0Lk=?= =?UTF-8?B?0LvQtSwg0L3QsCDQv9C+0YDRgtGLINC+0YLQu9C40YfQvdGL0LUg0L7RgiA4?= =?UTF-8?B?MCDQuCA0NDM=?= Message-ID: Подскажите, как можно организовать прокисрование http и https в одном конфигурационном файле, если есть несколько веб-серверов порты у которых отличаются от 80 и 443. Опишу общий вариант, чтобы было понятнее о чем речь, думаю в организациях, у которых множество сервисов, такое или очень похожее часто встречается. Для упрощения пусть будут несколько веб-серверов (apache,tomcat,glassfish,jbos ... и т.д.) на одном сервере (в жизни конечно не васе прям так, но доля правды есть, да и заменить один хост на хост в сети не так и сложно). Пусть будет сервер в лок сети с установленым на нем ПО: - nginx, порты http=80 https=443, он же проксирует все во нешний мир. - apache, порты http=8080 https=8083 - glassfish, порты http=8181 https=8183 1. Каким образом нужно написать конфиг для проксирования, чтобы http и https были в одном конфиге? 2. Каким образом нужно написать конфиг для проксирования, чтобы http и https были в одном конфиге, при условии, что приложения на apache/glassfish находятся не в корне веб сервера? 2й вариант наиболее интересен! Несколько примеров: --------------------------------------------- Если проксирование идет от корня (вопрос 1), и порты отличны от 80 и 443, есть способ и он работает, но я не уверен что это правильное решение, может нужно по другому прописывать?: в одном из location указать проксирование на apache if ( $scheme = "http" ) { proxy_pass http://localhost:8080; } if ( $scheme = "https" ) { proxy_pass https://localhost:8083; } в другом location указать проксирование на glassfish if ( $scheme = "http" ) { proxy_pass http://localhost:8181; } if ( $scheme = "https" ) { proxy_pass https://localhost:8183; } Но в этом варианте нельзя указать проксирование к контексту (вопрос 2), например http://localhost:8080/app ,т.к. nginx пишет ошибку nginx: [emerg] "proxy_pass" cannot have URI part in location given by regular expression, or inside named location, or inside "if" statement, or inside "limit_except" По большом счету нужно проксирование с похожими возможностями, но чтобы можно было проксировать не только от корня, а и какое-то отдельной приложение. --------------------------------------------- Понимаю, что если сделать например так: - apache повесить на сетевой интерфейс 127.0.1.1, порты http=80 https=443 - glassfish повесить на сетевой интерфейс 127.0.1.2, порты http=80 https=443 то в location можно проксирование прописать следующим образом без использования if proxy_pass $scheme://127.0.1.1; | proxy_pass $scheme://127.0.1.1/app; или proxy_pass $scheme://127.0.1.2; | proxy_pass $scheme://127.0.1.2/app; Но этот способ не очень применим, т.к. повлечет за собой очень много изменений в сети. --------------------------------------------- Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245412,245412#msg-245412 From greenh at gmail.com Wed Dec 11 13:37:23 2013 From: greenh at gmail.com (greenh) Date: Wed, 11 Dec 2013 15:37:23 +0200 Subject: =?UTF-8?B?UEhQINC+0YjQuNCx0LrQuCDQsiBuZ2lueCBlcnJvciBsb2c=?= Message-ID: Добрый день Имеется связка nginx/1.4.2+php5-fpm (PHP 5.3.27) Очень хочется при display_errors=off заставить php ошибки ложиться в nginx error.log. Единственный кривой способ, который я смог использовать - это через fastcgi_param указать error_log=nginx-error.log Но при этом я получаю два разных формата записи в лог, что оченьнеудобно для парсинга. И вообще как то криво Подскажите плз, как это можно седлать по человечьи? [global] pid = run/php-fpm.pid error_log = /var/log/php-fpm.log [project] security.limit_extensions = .php .html listen = /home/project/run/socket listen.backlog = -1 user = project group = project pm = dynamic pm.max_children = 10 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 10 catch_workers_output = yes [PHP] date.timezone = "Europe/Moscow" display_errors=Off magic_quotes_gpc=Off upload_max_filesize = 20M post_max_size = 10M error_log = /home/php_error.log log_errors = on fastcgi.logging = 1 max_execution_time = 600 max_input_time = 600 magic_quotes_gpc = Off memory_limit = 256M file_uploads = On post_max_size = 20M max_file_uploads = 20 extension=mcrypt.so extension=/usr/local/lib/php/20090626/mcrypt.so php_memory_limit = 200M -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Dec 11 14:14:04 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 11 Dec 2013 18:14:04 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHAg0LggaHR0cHMg0LIg?= =?UTF-8?B?0L7QtNC90L7QvCDQutC+0L3QuNCz0YPRgNCw0YbQuNC+0L3QvdC+0Lwg0YQ=?= =?UTF-8?B?0LDQudC70LUsINC90LAg0L/QvtGA0YLRiyDQvtGC0LvQuNGH0L3Ri9C1INC+?= =?UTF-8?B?0YIgODAg0LggNDQz?= In-Reply-To: References: Message-ID: <20131211141403.GV95113@mdounin.ru> Hello! On Wed, Dec 11, 2013 at 06:04:55AM -0500, mnsold wrote: > Подскажите, как можно организовать прокисрование http и https в одном > конфигурационном файле, если есть несколько веб-серверов порты у которых > отличаются от 80 и 443. > Опишу общий вариант, чтобы было понятнее о чем речь, думаю в организациях, у > которых множество сервисов, такое или очень похожее часто встречается. > > Для упрощения пусть будут несколько веб-серверов > (apache,tomcat,glassfish,jbos ... и т.д.) на одном сервере (в жизни конечно > не васе прям так, но доля правды есть, да и заменить один хост на хост в > сети не так и сложно). > > Пусть будет сервер в лок сети с установленым на нем ПО: > - nginx, порты http=80 https=443, он же проксирует все во нешний мир. > - apache, порты http=8080 https=8083 > - glassfish, порты http=8181 https=8183 > > 1. Каким образом нужно написать конфиг для проксирования, чтобы http и https > были в одном конфиге? > 2. Каким образом нужно написать конфиг для проксирования, чтобы http и https > были в одном конфиге, при условии, что приложения на apache/glassfish > находятся не в корне веб сервера? > 2й вариант наиболее интересен! Для начала имеет смысл понять две простые вещи: 1) Весь конфиг nginx'а может быть записан в одном файле, nginx.conf. Все попытки разделения на множество маленьких файликов по доменам - это лишь средство для упрощения автоматизации, обычно применяемое в линуксе. Если вам хочется записать всё в "одном конфиге" - просто напишите всё в nginx.conf, и с головой будет в порядке. 2) Несколько блоков server{} в рамках одного nginx.conf - это нормально, и это хороший, годный способ писать простую конфигурацию. Если у вас два разных виртуальных сервера, которые обрабатываются по разному - напишите для них разные блоки server{}, и с головой будет в порядке. [...] > в одном из location указать проксирование на apache > if ( $scheme = "http" ) { > proxy_pass http://localhost:8080; > } > if ( $scheme = "https" ) { > proxy_pass https://localhost:8083; > } [...] > то в location можно проксирование прописать следующим образом без > использования if > proxy_pass $scheme://127.0.1.1; | proxy_pass $scheme://127.0.1.1/app; > или > proxy_pass $scheme://127.0.1.2; | proxy_pass $scheme://127.0.1.2/app; Не надо делать ни так, ни так. Если хочется, чтобы запросы, пришедшие по https, проксировались с использованием https, а запросы, пришедшие по http, проксировались без него, то правильно делать так: server { listen 80; location / { proxy_pass http://upstream; } } server { listen 443 ssl; location / { proxy_pass https://upstream; } } Блоки server{} - это инструмент, специально предназначенный для того, чтобы задавать разную обработку для разных виртуальных серверов. Его и надо использовать для решения таких задач. Отдельный вопрос - для чего в рамках одного сервера гонять трафик по SSL, тратя ресурсы на шифрование, но это уже скорее из области философии. -- Maxim Dounin http://nginx.org/ From mdounin at mdounin.ru Wed Dec 11 14:41:55 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 11 Dec 2013 18:41:55 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: References: <20131210111349.GE95113@mdounin.ru> <20131210133720.GF95113@mdounin.ru> <20131210163749.GL95113@mdounin.ru> <20131210184303.GR95113@mdounin.ru> Message-ID: <20131211144155.GW95113@mdounin.ru> Hello! On Wed, Dec 11, 2013 at 01:39:21AM +0600, Илья Шипицин wrote: > 11 декабря 2013 г., 0:43 пользователь Maxim Dounin написал: > > Hello! > > > > On Tue, Dec 10, 2013 at 11:12:16PM +0600, Илья Шипицин wrote: > > > >> 10 декабря 2013 г., 22:37 пользователь Maxim Dounin > >> написал: > >> > Hello! > >> > > >> > On Tue, Dec 10, 2013 at 09:22:02PM +0600, Илья Шипицин wrote: > >> > > >> >> 10 декабря 2013 г., 19:37 пользователь Maxim Dounin > >> >> написал: > >> >> > Hello! > >> >> > > >> >> > On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote: > >> >> > > >> >> >> 10 декабря 2013 г., 17:13 пользователь Maxim Dounin > >> >> >> написал: > >> >> >> > Hello! > >> >> >> > > >> >> >> > On Tue, Dec 10, 2013 at 09:13:16AM +0600, Илья Шипицин wrote: > >> >> >> > > >> >> >> >> Добрый день! > >> >> >> >> > >> >> >> >> как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен. > >> >> >> >> идея в том, что отправка заголовка "Connection: keep-alive" в > >> >> >> >> большинстве случаев не нужна. > >> >> >> >> > >> >> >> >> абонентская база - сотни тысяч пользователей, сотни миллионов запросов > >> >> >> >> в месяц. думаю, спустя месяц-два можно будет считать, что все > >> >> >> >> протестировано во всех возможных ситуациях. > >> >> >> >> > >> >> >> >> > >> >> >> >> желающие - приглашаются к тестированию. > >> >> >> >> > >> >> >> >> данное поведение "подсмотрено" у IIS, который по любым метрикам > >> >> >> >> занимает десятки процентов "рынка": > >> >> >> >> http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html > >> >> >> >> - поэтому есть уверенность, что все обойдется без побочных эффектов > >> >> >> > > >> >> >> > Илья, я вроде как сделал патч с таким поведением ещё в процессе > >> >> >> > прошлого обсуждения: > >> >> >> > > >> >> >> > http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051059.html > >> >> >> > > >> >> >> > Странно видить попытки изобрести велосипед заново вместо того, > >> >> >> > чтобы заняться тестированием и последующим убеждением, что это > >> >> >> > надо закоммитить, тем более про "тщательное тестирование" было > >> >> >> > явно написано. ;) > >> >> >> > >> >> >> это именно та тема и есть, сейчас дошли руки "тщательно > >> >> >> протестировать". я запустил в продакшн. > >> >> > > >> >> > Меня в первую очередь удивило, что вместо патча, нарисованного ещё > >> >> > полгода назад, к письму о "потестировать" прилагается совсем > >> >> > другой патч, с чуть-чуть другими условиями и стилистическими > >> >> > проблемами. Я бы всё-таки рекомендовал тестировать то, что потом > >> >> > будем коммитить. > >> >> > > >> >> >> ждем пару месяцев (и, если проблем не всплывает, считаем, что все ок) ? > >> >> > > >> >> > Я, честно говоря, пребывал в надежде, что патч уже полгода > >> >> > тестируется. ;) > >> >> > > >> >> > Но если нет - то, видимо, так и делаем. Только просьба - взять > >> >> > для тестирования патч в том виде, в каком его предполагается > >> >> > коммитить, if any: > >> >> > >> >> без проблем. сегодня запущу в продакшн в таком виде > >> >> > >> >> не совсем понятно, зачем делать условие "r->http_version < NGX_HTTP_VERSION_11" > >> >> для версии 0.9, насколько я понимаю, и в моем и в вашем случае будет фигня > >> > > >> > Для 0.9 всё это не будет выполняться, т.к. будет отсечено > >> > проверкой > >> > > >> > if (r->http_version < NGX_HTTP_VERSION_10) { > >> > return NGX_OK; > >> > } > >> > > >> > в начале функции. Принципиальной разницы между патчами нет, > >> > вопрос в основном стилистический (с учётом того, что между > >> > HTTP/1.0 и HTTP/1.1 других версий быть не может). > >> > >> тогда получается, что мой вариант лучше. > >> > >> для 0.9 по RFC не бывает keep-alive > >> для 1.0 у меня сравнение по равенству > > > > Не согласен, т.к. важно не то, что в HTTP/1.0 нет keepalive'а по > > умолчанию, а то, что keepalive по умолчанию есть в HTTP/1.1 и > > выше, а в версиях до HTTP/1.1 его нужно явно включать. > > > > В условиях, когда у нас есть только HTTP/1.0 и HTTP/1.1, и никаких > > промежуточных версий быть не может - патчи эквивалентны, и > > различие только стилистическое. Но если бы был ещё какой-нибудь > > HTTP/1.(1/2) - сравнение с HTTP/1.0 было бы неправильным. > > Максим, почему вы думаете, что разработчики RFC для HTTP/1.(1/2) > заложат поведение, идентичное HTTP/1.0 ? > ваш вариант это подразумевает. я не уверен, что будет именно так. Я уверен, что уже не будет. Всмысле - никакой версии HTTP/1.(1/2) никогда не будет. Вопрос, повторяю, стилистический. Речь о том, что когда что-то меняется, то важна именно версия, в которой это что-то поменялось. Подход, предполагающий явное перечисление - работает только в условиях малого количества версий. С ростом количества версий он становится непригодным к использованию. Если есть сомнения в правильности вышеприведённого абзаца - то можно заглянуть в src/event/ngx_event_opennsl.c, и попробовать переписать условия на OPENSSL_VERSION_NUMBER с помощью явного перечисления. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Wed Dec 11 15:06:45 2013 From: nginx-forum at nginx.us (mnsold) Date: Wed, 11 Dec 2013 10:06:45 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHAg0LggaHR0cHMg0LIg?= =?UTF-8?B?0L7QtNC90L7QvCDQutC+0L3QuNCz0YPRgNCw0YbQuNC+0L3QvdC+0Lwg0YQ=?= =?UTF-8?B?0LDQudC70LUsINC90LAg0L/QvtGA0YLRiyDQvtGC0LvQuNGH0L3Ri9C1INC+?= =?UTF-8?B?0YIgODAg0LggNDQz?= In-Reply-To: <20131211141403.GV95113@mdounin.ru> References: <20131211141403.GV95113@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > Для начала имеет смысл понять две простые вещи: > 1) Весь конфиг nginx'а может быть записан в одном файле, > nginx.conf. Все попытки разделения на множество маленьких > файликов по доменам - это лишь средство для упрощения > автоматизации, обычно применяемое в линуксе. Если вам хочется > записать всё в "одном конфиге" - просто напишите всё в nginx.conf, > и с головой будет в порядке. Упрощение автоматизации в виде разделения на множество маленьких файликов очень удобно, это и использую, писать в кучу все в nginx.conf крайне не хочется, т.к. потом будет сложно разгребсти. > 2) Несколько блоков server{} в рамках одного nginx.conf - это > нормально, и это хороший, годный способ писать простую > конфигурацию. Если у вас два разных виртуальных сервера, которые > обрабатываются по разному - напишите для них разные блоки > server{}, и с головой будет в порядке. Разные блоки server{} не страшны, страшно от дублирования location {}, т.к. в nginx будет достаточно много приложений доступных на разных контекстных путях, сами приложения крутятся на рядом стоящих серверах, что-то еще крутится и на локальном сервере с nginx. Вот эта ситуация как раз и не нравится, т.к. location для http и https нужно прописывать несколько раз, а при условии, что писать придется много, дублирования одного и тогоже с заменой http на https уж очень не хочется : > server { > listen 80; > > location / { > proxy_pass http://upstream; > } > } > > server { > listen 443 ssl; > > location / { > proxy_pass https://upstream; > } > } > Отдельный вопрос - для чего в рамках одного сервера гонять трафик > по SSL, тратя ресурсы на шифрование, но это уже скорее из области > философии. Проксирование конечно не только в рамках одного сервера, как я написал выше. Конечно, весь локальный трафик можно считать доверенным, но не все получается проксировать по схеме: внешний доступ по https -> локальный трафик между серверами по http. Правда в отдельных случаях нужно и между серверами https гонять, такое уж требование и от него никуда не уйти, благо что таких сервисов не так много. По схеме https->http получилось проксировать апач, а вот glassfish не получилось проксировать, на стороне пользователя теряется часть внуренних объктов приложения и интерфейс работает не полностью, т.е. часть содержимого в интерфейсе просто не видно (ну и еще по мелочи), хотя точно знаю что оно есть, т.к. без прокси все работает как надо и работает если проксирование сделано по схеме https->https. Почему не работает https->http с glassfish'ем тоже в процессе понимания, но пока безрезультатно. Тут я с Вами солидарен - тратить ресурсы на шифрование без необходимости ни к чему. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245412,245425#msg-245425 From nginx-forum at nginx.us Wed Dec 11 15:23:50 2013 From: nginx-forum at nginx.us (mnsold) Date: Wed, 11 Dec 2013 10:23:50 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHAg0LggaHR0cHMg0LIg?= =?UTF-8?B?0L7QtNC90L7QvCDQutC+0L3QuNCz0YPRgNCw0YbQuNC+0L3QvdC+0Lwg0YQ=?= =?UTF-8?B?0LDQudC70LUsINC90LAg0L/QvtGA0YLRiyDQvtGC0LvQuNGH0L3Ri9C1INC+?= =?UTF-8?B?0YIgODAg0LggNDQz?= In-Reply-To: References: <20131211141403.GV95113@mdounin.ru> Message-ID: <873545765ed49643409d5f4e7c9a68f6.NginxMailingListRussian@forum.nginx.org> Тут наверное я еще не совсем правильно выразился, нужно описать конфигурацию не то чтобы в одном когфиге, а в одном блоке server {} и без повториний location {} с разницей только http<->https. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245412,245426#msg-245426 From swood at fotofor.biz Wed Dec 11 15:28:47 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Wed, 11 Dec 2013 19:28:47 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHAg0LggaHR0cHMg0LIg?= =?UTF-8?B?0L7QtNC90L7QvCDQutC+0L3QuNCz0YPRgNCw0YbQuNC+0L3QvdC+0Lwg0YQ=?= =?UTF-8?B?0LDQudC70LUsINC90LAg0L/QvtGA0YLRiyDQvtGC0LvQuNGH0L3Ri9C1INC+?= =?UTF-8?B?0YIgODAg0LggNDQz?= In-Reply-To: <873545765ed49643409d5f4e7c9a68f6.NginxMailingListRussian@forum.nginx.org> References: <20131211141403.GV95113@mdounin.ru> <873545765ed49643409d5f4e7c9a68f6.NginxMailingListRussian@forum.nginx.org> Message-ID: Вы имеете ввиду map ? 11 декабря 2013 г., 19:23 пользователь mnsold написал: > Тут наверное я еще не совсем правильно выразился, нужно описать > конфигурацию > не то чтобы в одном когфиге, а в одном блоке server {} и без повториний > location {} с разницей только http<->https. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,245412,245426#msg-245426 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Dec 11 15:35:35 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 11 Dec 2013 19:35:35 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHAg0LggaHR0cHMg0LIg?= =?UTF-8?B?0L7QtNC90L7QvCDQutC+0L3QuNCz0YPRgNCw0YbQuNC+0L3QvdC+0Lwg0YQ=?= =?UTF-8?B?0LDQudC70LUsINC90LAg0L/QvtGA0YLRiyDQvtGC0LvQuNGH0L3Ri9C1INC+?= =?UTF-8?B?0YIgODAg0LggNDQz?= In-Reply-To: <873545765ed49643409d5f4e7c9a68f6.NginxMailingListRussian@forum.nginx.org> References: <20131211141403.GV95113@mdounin.ru> <873545765ed49643409d5f4e7c9a68f6.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131211153535.GY95113@mdounin.ru> Hello! On Wed, Dec 11, 2013 at 10:23:50AM -0500, mnsold wrote: > Тут наверное я еще не совсем правильно выразился, нужно описать конфигурацию > не то чтобы в одном когфиге, а в одном блоке server {} и без повториний > location {} с разницей только http<->https. Повторюсь - вы, как мне кажется, не с той стороны подходите к проблеме. Бояться надо не повторов "с разницей только", а попыток "унификации" ценой создания чудовищных монстров вместо конфигурации. Для того, чтобы избегать повторов - в nginx'е есть наследование конфигурации, а равно директива include. Если этого нехватает - обычно правильнее взять в руки любимый шаблонизатор, а не пытаться то же самое сделать с помощью условных проверок в процессе обработки запросов. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Wed Dec 11 15:41:00 2013 From: nginx-forum at nginx.us (mnsold) Date: Wed, 11 Dec 2013 10:41:00 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHAg0LggaHR0cHMg0LIg?= =?UTF-8?B?0L7QtNC90L7QvCDQutC+0L3QuNCz0YPRgNCw0YbQuNC+0L3QvdC+0Lwg0YQ=?= =?UTF-8?B?0LDQudC70LUsINC90LAg0L/QvtGA0YLRiyDQvtGC0LvQuNGH0L3Ri9C1INC+?= =?UTF-8?B?0YIgODAg0LggNDQz?= In-Reply-To: References: Message-ID: <82ae2d325cd81e0c801c30a88e7284f9.NginxMailingListRussian@forum.nginx.org> Anton Kiryushkin Wrote: ------------------------------------------------------- > Вы имеете ввиду map ? Не совсем понимаю что это такое. Я имел ввиду, чтобы все можно было написать вот так конфиг домена: server { listen 80; listen 443 ssl; ... include app ... } файл app: location /app { если пользователь работает по http, то проксируем сюда proxy_pass http://upstream:1111/app; если пользователь работает по https, то проксируем сюда proxy_pass https://upstream:1112/app; } это образно, но в этом случае location /app будет описан в одном отдельном файле а не так server { listen 80; ... include app <- для http ... } server { listen 443 ssl; ... include apps <- для https ... } в этом случае, location /app нужно описывать в 2х файлах Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245412,245430#msg-245430 From chipitsine at gmail.com Wed Dec 11 16:41:42 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 11 Dec 2013 22:41:42 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: <20131211144155.GW95113@mdounin.ru> References: <20131210111349.GE95113@mdounin.ru> <20131210133720.GF95113@mdounin.ru> <20131210163749.GL95113@mdounin.ru> <20131210184303.GR95113@mdounin.ru> <20131211144155.GW95113@mdounin.ru> Message-ID: 11 декабря 2013 г., 20:41 пользователь Maxim Dounin написал: > Hello! > > On Wed, Dec 11, 2013 at 01:39:21AM +0600, Илья Шипицин wrote: > >> 11 декабря 2013 г., 0:43 пользователь Maxim Dounin написал: >> > Hello! >> > >> > On Tue, Dec 10, 2013 at 11:12:16PM +0600, Илья Шипицин wrote: >> > >> >> 10 декабря 2013 г., 22:37 пользователь Maxim Dounin >> >> написал: >> >> > Hello! >> >> > >> >> > On Tue, Dec 10, 2013 at 09:22:02PM +0600, Илья Шипицин wrote: >> >> > >> >> >> 10 декабря 2013 г., 19:37 пользователь Maxim Dounin >> >> >> написал: >> >> >> > Hello! >> >> >> > >> >> >> > On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote: >> >> >> > >> >> >> >> 10 декабря 2013 г., 17:13 пользователь Maxim Dounin >> >> >> >> написал: >> >> >> >> > Hello! >> >> >> >> > >> >> >> >> > On Tue, Dec 10, 2013 at 09:13:16AM +0600, Илья Шипицин wrote: >> >> >> >> > >> >> >> >> >> Добрый день! >> >> >> >> >> >> >> >> >> >> как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен. >> >> >> >> >> идея в том, что отправка заголовка "Connection: keep-alive" в >> >> >> >> >> большинстве случаев не нужна. >> >> >> >> >> >> >> >> >> >> абонентская база - сотни тысяч пользователей, сотни миллионов запросов >> >> >> >> >> в месяц. думаю, спустя месяц-два можно будет считать, что все >> >> >> >> >> протестировано во всех возможных ситуациях. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> желающие - приглашаются к тестированию. >> >> >> >> >> >> >> >> >> >> данное поведение "подсмотрено" у IIS, который по любым метрикам >> >> >> >> >> занимает десятки процентов "рынка": >> >> >> >> >> http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html >> >> >> >> >> - поэтому есть уверенность, что все обойдется без побочных эффектов >> >> >> >> > >> >> >> >> > Илья, я вроде как сделал патч с таким поведением ещё в процессе >> >> >> >> > прошлого обсуждения: >> >> >> >> > >> >> >> >> > http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051059.html >> >> >> >> > >> >> >> >> > Странно видить попытки изобрести велосипед заново вместо того, >> >> >> >> > чтобы заняться тестированием и последующим убеждением, что это >> >> >> >> > надо закоммитить, тем более про "тщательное тестирование" было >> >> >> >> > явно написано. ;) >> >> >> >> >> >> >> >> это именно та тема и есть, сейчас дошли руки "тщательно >> >> >> >> протестировать". я запустил в продакшн. >> >> >> > >> >> >> > Меня в первую очередь удивило, что вместо патча, нарисованного ещё >> >> >> > полгода назад, к письму о "потестировать" прилагается совсем >> >> >> > другой патч, с чуть-чуть другими условиями и стилистическими >> >> >> > проблемами. Я бы всё-таки рекомендовал тестировать то, что потом >> >> >> > будем коммитить. >> >> >> > >> >> >> >> ждем пару месяцев (и, если проблем не всплывает, считаем, что все ок) ? >> >> >> > >> >> >> > Я, честно говоря, пребывал в надежде, что патч уже полгода >> >> >> > тестируется. ;) >> >> >> > >> >> >> > Но если нет - то, видимо, так и делаем. Только просьба - взять >> >> >> > для тестирования патч в том виде, в каком его предполагается >> >> >> > коммитить, if any: >> >> >> >> >> >> без проблем. сегодня запущу в продакшн в таком виде >> >> >> >> >> >> не совсем понятно, зачем делать условие "r->http_version < NGX_HTTP_VERSION_11" >> >> >> для версии 0.9, насколько я понимаю, и в моем и в вашем случае будет фигня >> >> > >> >> > Для 0.9 всё это не будет выполняться, т.к. будет отсечено >> >> > проверкой >> >> > >> >> > if (r->http_version < NGX_HTTP_VERSION_10) { >> >> > return NGX_OK; >> >> > } >> >> > >> >> > в начале функции. Принципиальной разницы между патчами нет, >> >> > вопрос в основном стилистический (с учётом того, что между >> >> > HTTP/1.0 и HTTP/1.1 других версий быть не может). >> >> >> >> тогда получается, что мой вариант лучше. >> >> >> >> для 0.9 по RFC не бывает keep-alive >> >> для 1.0 у меня сравнение по равенству >> > >> > Не согласен, т.к. важно не то, что в HTTP/1.0 нет keepalive'а по >> > умолчанию, а то, что keepalive по умолчанию есть в HTTP/1.1 и >> > выше, а в версиях до HTTP/1.1 его нужно явно включать. >> > >> > В условиях, когда у нас есть только HTTP/1.0 и HTTP/1.1, и никаких >> > промежуточных версий быть не может - патчи эквивалентны, и >> > различие только стилистическое. Но если бы был ещё какой-нибудь >> > HTTP/1.(1/2) - сравнение с HTTP/1.0 было бы неправильным. >> >> Максим, почему вы думаете, что разработчики RFC для HTTP/1.(1/2) >> заложат поведение, идентичное HTTP/1.0 ? >> ваш вариант это подразумевает. я не уверен, что будет именно так. > > Я уверен, что уже не будет. Всмысле - никакой версии HTTP/1.(1/2) > никогда не будет. Вопрос, повторяю, стилистический. если вопрос стилистический, давайте остановимся на моей версии. она мне больше нравится > > Речь о том, что когда что-то меняется, то важна именно версия, в > которой это что-то поменялось. Подход, предполагающий явное > перечисление - работает только в условиях малого количества > версий. С ростом количества версий он становится непригодным к > использованию. это как раз случай версий HTTP, их мало > > Если есть сомнения в правильности вышеприведённого абзаца - то > можно заглянуть в src/event/ngx_event_opennsl.c, и попробовать > переписать условия на OPENSSL_VERSION_NUMBER с помощью явного > перечисления. хорошо, если я буду править что-то связанное с OPENSSL, обязательно буду иметь это в виду > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ano at bestmx.net Wed Dec 11 16:43:21 2013 From: ano at bestmx.net (Andrey Oktyabrskiy) Date: Wed, 11 Dec 2013 20:43:21 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHAg0LggaHR0cHMg0LIg?= =?UTF-8?B?0L7QtNC90L7QvCDQutC+0L3QuNCz0YPRgNCw0YbQuNC+0L3QvdC+0Lwg0YQ=?= =?UTF-8?B?0LDQudC70LUsINC90LAg0L/QvtGA0YLRiyDQvtGC0LvQuNGH0L3Ri9C1INC+?= =?UTF-8?B?0YIgODAg0LggNDQz?= In-Reply-To: <82ae2d325cd81e0c801c30a88e7284f9.NginxMailingListRussian@forum.nginx.org> References: <82ae2d325cd81e0c801c30a88e7284f9.NginxMailingListRussian@forum.nginx.org> Message-ID: <52A89629.4060207@bestmx.net> On 11.12.2013 19:41, mnsold wrote: > server { > listen 80; > ... > include app <- для http > ... > } > > server { > listen 443 ssl; > ... > include apps <- для https > ... > } > в этом случае, location /app нужно описывать в 2х файлах Так и держите location /app в файле location_app, в файлах app и apps пишите include location_app; From nginx-forum at nginx.us Wed Dec 11 16:58:34 2013 From: nginx-forum at nginx.us (mnsold) Date: Wed, 11 Dec 2013 11:58:34 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHAg0LggaHR0cHMg0LIg?= =?UTF-8?B?0L7QtNC90L7QvCDQutC+0L3QuNCz0YPRgNCw0YbQuNC+0L3QvdC+0Lwg0YQ=?= =?UTF-8?B?0LDQudC70LUsINC90LAg0L/QvtGA0YLRiyDQvtGC0LvQuNGH0L3Ri9C1INC+?= =?UTF-8?B?0YIgODAg0LggNDQz?= In-Reply-To: <20131211153535.GY95113@mdounin.ru> References: <20131211153535.GY95113@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > создания чудовищных монстров Так вы посмотрите http://forum.nginx.org/read.php?21,245412,245430#msg-245430 то что хочется сделать, как раз выглядит наиболее изящным решением, а в условиях часто меняющихся приложений и обеспечения доступа к ним позволит только сделать всю конфигурацию более легкой, прозрачной и позволит освободить некоторое количество времени для решения других задач > Для того, чтобы избегать повторов - в nginx'е есть наследование > конфигурации, а равно директива include. Если этого нехватает - > обычно правильнее взять в руки любимый шаблонизатор, а не пытаться > то же самое сделать с помощью условных проверок в процессе > обработки запросов. include во всю используется, про условные проверки я в первом посте написал "не уверен что это правильное решение" и "этом варианте нельзя указать проксирование к контексту ... nginx пишет ошибку" Очень хочется иметь аналогичные возможности как было показано в if с возможностью проксирования контеста, а не от корня. Про то, что вы мне говорите - сделать блок server {} с location {} для http - сделать блок server {} с location {} для https изначально было понятно, что так можно. Но вопрос в том, как проксировать одно приложение по http и https в одном блоке server {} и одном блоке location {} (без дублей), учитавая, что приложение на бэкэенде может быть доступно как в корне так и по контекстному пути, а порты отличаются от 80 и 443. Согласитесь, N количество блоков server {} и N количество блоков location {} проще изменить, меньше вероятности допустить ошибки и понимать легче, чем N*2 количество блоков server {} и N*2 количество блоков location {} сделанных отдельно для http и для https. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245412,245436#msg-245436 From nginx-forum at nginx.us Wed Dec 11 17:08:35 2013 From: nginx-forum at nginx.us (mnsold) Date: Wed, 11 Dec 2013 12:08:35 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHAg0LggaHR0cHMg0LIg?= =?UTF-8?B?0L7QtNC90L7QvCDQutC+0L3QuNCz0YPRgNCw0YbQuNC+0L3QvdC+0Lwg0YQ=?= =?UTF-8?B?0LDQudC70LUsINC90LAg0L/QvtGA0YLRiyDQvtGC0LvQuNGH0L3Ri9C1INC+?= =?UTF-8?B?0YIgODAg0LggNDQz?= In-Reply-To: <52A89629.4060207@bestmx.net> References: <52A89629.4060207@bestmx.net> Message-ID: <968ad035bf068987dc0a18a6ca80b228.NginxMailingListRussian@forum.nginx.org> > Так и держите location /app в файле location_app, в файлах app и apps > пишите include location_app; получается вместо одного файла, целых 3 причем файлы app и apps ссылаются на один файл location_app, значит в нем будет прописано либо proxy_pass http://localhost:8181; либо proxy_pass https://localhost:8183; получается сделать схему http->http + https->https не возможно только одну из следующих http->http | http->https | https->https | https->http либо я что-то не понял, что вы хотели этим сказать Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245412,245437#msg-245437 From mdounin at mdounin.ru Wed Dec 11 18:04:25 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 11 Dec 2013 22:04:25 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: References: <20131210111349.GE95113@mdounin.ru> <20131210133720.GF95113@mdounin.ru> <20131210163749.GL95113@mdounin.ru> <20131210184303.GR95113@mdounin.ru> <20131211144155.GW95113@mdounin.ru> Message-ID: <20131211180425.GC95113@mdounin.ru> Hello! On Wed, Dec 11, 2013 at 10:41:42PM +0600, Илья Шипицин wrote: > 11 декабря 2013 г., 20:41 пользователь Maxim Dounin > написал: > > Hello! > > > > On Wed, Dec 11, 2013 at 01:39:21AM +0600, Илья Шипицин wrote: > > > >> 11 декабря 2013 г., 0:43 пользователь Maxim Dounin написал: > >> > Hello! > >> > > >> > On Tue, Dec 10, 2013 at 11:12:16PM +0600, Илья Шипицин wrote: > >> > > >> >> 10 декабря 2013 г., 22:37 пользователь Maxim Dounin > >> >> написал: > >> >> > Hello! > >> >> > > >> >> > On Tue, Dec 10, 2013 at 09:22:02PM +0600, Илья Шипицин wrote: > >> >> > > >> >> >> 10 декабря 2013 г., 19:37 пользователь Maxim Dounin > >> >> >> написал: > >> >> >> > Hello! > >> >> >> > > >> >> >> > On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote: > >> >> >> > > >> >> >> >> 10 декабря 2013 г., 17:13 пользователь Maxim Dounin > >> >> >> >> написал: > >> >> >> >> > Hello! > >> >> >> >> > > >> >> >> >> > On Tue, Dec 10, 2013 at 09:13:16AM +0600, Илья Шипицин wrote: > >> >> >> >> > > >> >> >> >> >> Добрый день! > >> >> >> >> >> > >> >> >> >> >> как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен. > >> >> >> >> >> идея в том, что отправка заголовка "Connection: keep-alive" в > >> >> >> >> >> большинстве случаев не нужна. > >> >> >> >> >> > >> >> >> >> >> абонентская база - сотни тысяч пользователей, сотни миллионов запросов > >> >> >> >> >> в месяц. думаю, спустя месяц-два можно будет считать, что все > >> >> >> >> >> протестировано во всех возможных ситуациях. > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> желающие - приглашаются к тестированию. > >> >> >> >> >> > >> >> >> >> >> данное поведение "подсмотрено" у IIS, который по любым метрикам > >> >> >> >> >> занимает десятки процентов "рынка": > >> >> >> >> >> http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html > >> >> >> >> >> - поэтому есть уверенность, что все обойдется без побочных эффектов > >> >> >> >> > > >> >> >> >> > Илья, я вроде как сделал патч с таким поведением ещё в процессе > >> >> >> >> > прошлого обсуждения: > >> >> >> >> > > >> >> >> >> > http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051059.html > >> >> >> >> > > >> >> >> >> > Странно видить попытки изобрести велосипед заново вместо того, > >> >> >> >> > чтобы заняться тестированием и последующим убеждением, что это > >> >> >> >> > надо закоммитить, тем более про "тщательное тестирование" было > >> >> >> >> > явно написано. ;) > >> >> >> >> > >> >> >> >> это именно та тема и есть, сейчас дошли руки "тщательно > >> >> >> >> протестировать". я запустил в продакшн. > >> >> >> > > >> >> >> > Меня в первую очередь удивило, что вместо патча, нарисованного ещё > >> >> >> > полгода назад, к письму о "потестировать" прилагается совсем > >> >> >> > другой патч, с чуть-чуть другими условиями и стилистическими > >> >> >> > проблемами. Я бы всё-таки рекомендовал тестировать то, что потом > >> >> >> > будем коммитить. > >> >> >> > > >> >> >> >> ждем пару месяцев (и, если проблем не всплывает, считаем, что все ок) ? > >> >> >> > > >> >> >> > Я, честно говоря, пребывал в надежде, что патч уже полгода > >> >> >> > тестируется. ;) > >> >> >> > > >> >> >> > Но если нет - то, видимо, так и делаем. Только просьба - взять > >> >> >> > для тестирования патч в том виде, в каком его предполагается > >> >> >> > коммитить, if any: > >> >> >> > >> >> >> без проблем. сегодня запущу в продакшн в таком виде > >> >> >> > >> >> >> не совсем понятно, зачем делать условие "r->http_version < NGX_HTTP_VERSION_11" > >> >> >> для версии 0.9, насколько я понимаю, и в моем и в вашем случае будет фигня > >> >> > > >> >> > Для 0.9 всё это не будет выполняться, т.к. будет отсечено > >> >> > проверкой > >> >> > > >> >> > if (r->http_version < NGX_HTTP_VERSION_10) { > >> >> > return NGX_OK; > >> >> > } > >> >> > > >> >> > в начале функции. Принципиальной разницы между патчами нет, > >> >> > вопрос в основном стилистический (с учётом того, что между > >> >> > HTTP/1.0 и HTTP/1.1 других версий быть не может). > >> >> > >> >> тогда получается, что мой вариант лучше. > >> >> > >> >> для 0.9 по RFC не бывает keep-alive > >> >> для 1.0 у меня сравнение по равенству > >> > > >> > Не согласен, т.к. важно не то, что в HTTP/1.0 нет keepalive'а по > >> > умолчанию, а то, что keepalive по умолчанию есть в HTTP/1.1 и > >> > выше, а в версиях до HTTP/1.1 его нужно явно включать. > >> > > >> > В условиях, когда у нас есть только HTTP/1.0 и HTTP/1.1, и никаких > >> > промежуточных версий быть не может - патчи эквивалентны, и > >> > различие только стилистическое. Но если бы был ещё какой-нибудь > >> > HTTP/1.(1/2) - сравнение с HTTP/1.0 было бы неправильным. > >> > >> Максим, почему вы думаете, что разработчики RFC для HTTP/1.(1/2) > >> заложат поведение, идентичное HTTP/1.0 ? > >> ваш вариант это подразумевает. я не уверен, что будет именно так. > > > > Я уверен, что уже не будет. Всмысле - никакой версии HTTP/1.(1/2) > > никогда не будет. Вопрос, повторяю, стилистический. > > если вопрос стилистический, давайте остановимся на моей версии. она > мне больше нравится Да сколько угодно, я ж разве возражаю? Только тогда патч не будет закоммичен из-за стилистических проблем. ;) > > Речь о том, что когда что-то меняется, то важна именно версия, в > > которой это что-то поменялось. Подход, предполагающий явное > > перечисление - работает только в условиях малого количества > > версий. С ростом количества версий он становится непригодным к > > использованию. > > это как раз случай версий HTTP, их мало Версий HTTP - потенциально бесконечное количество. В nginx'е уже сейчас используются проверки r->http_version, нормально скалирующиеся при увеличении количества версий, проверяющие именно версии, в которых что-то изменилось. См. например процитированный код выше. Не надо это пытаться сломать. -- Maxim Dounin http://nginx.org/ From chipitsine at gmail.com Wed Dec 11 18:20:35 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Thu, 12 Dec 2013 00:20:35 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: <20131211180425.GC95113@mdounin.ru> References: <20131210111349.GE95113@mdounin.ru> <20131210133720.GF95113@mdounin.ru> <20131210163749.GL95113@mdounin.ru> <20131210184303.GR95113@mdounin.ru> <20131211144155.GW95113@mdounin.ru> <20131211180425.GC95113@mdounin.ru> Message-ID: 12 декабря 2013 г., 0:04 пользователь Maxim Dounin написал: > Hello! > > On Wed, Dec 11, 2013 at 10:41:42PM +0600, Илья Шипицин wrote: > >> 11 декабря 2013 г., 20:41 пользователь Maxim Dounin >> написал: >> > Hello! >> > >> > On Wed, Dec 11, 2013 at 01:39:21AM +0600, Илья Шипицин wrote: >> > >> >> 11 декабря 2013 г., 0:43 пользователь Maxim Dounin написал: >> >> > Hello! >> >> > >> >> > On Tue, Dec 10, 2013 at 11:12:16PM +0600, Илья Шипицин wrote: >> >> > >> >> >> 10 декабря 2013 г., 22:37 пользователь Maxim Dounin >> >> >> написал: >> >> >> > Hello! >> >> >> > >> >> >> > On Tue, Dec 10, 2013 at 09:22:02PM +0600, Илья Шипицин wrote: >> >> >> > >> >> >> >> 10 декабря 2013 г., 19:37 пользователь Maxim Dounin >> >> >> >> написал: >> >> >> >> > Hello! >> >> >> >> > >> >> >> >> > On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote: >> >> >> >> > >> >> >> >> >> 10 декабря 2013 г., 17:13 пользователь Maxim Dounin >> >> >> >> >> написал: >> >> >> >> >> > Hello! >> >> >> >> >> > >> >> >> >> >> > On Tue, Dec 10, 2013 at 09:13:16AM +0600, Илья Шипицин wrote: >> >> >> >> >> > >> >> >> >> >> >> Добрый день! >> >> >> >> >> >> >> >> >> >> >> >> как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен. >> >> >> >> >> >> идея в том, что отправка заголовка "Connection: keep-alive" в >> >> >> >> >> >> большинстве случаев не нужна. >> >> >> >> >> >> >> >> >> >> >> >> абонентская база - сотни тысяч пользователей, сотни миллионов запросов >> >> >> >> >> >> в месяц. думаю, спустя месяц-два можно будет считать, что все >> >> >> >> >> >> протестировано во всех возможных ситуациях. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> желающие - приглашаются к тестированию. >> >> >> >> >> >> >> >> >> >> >> >> данное поведение "подсмотрено" у IIS, который по любым метрикам >> >> >> >> >> >> занимает десятки процентов "рынка": >> >> >> >> >> >> http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html >> >> >> >> >> >> - поэтому есть уверенность, что все обойдется без побочных эффектов >> >> >> >> >> > >> >> >> >> >> > Илья, я вроде как сделал патч с таким поведением ещё в процессе >> >> >> >> >> > прошлого обсуждения: >> >> >> >> >> > >> >> >> >> >> > http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051059.html >> >> >> >> >> > >> >> >> >> >> > Странно видить попытки изобрести велосипед заново вместо того, >> >> >> >> >> > чтобы заняться тестированием и последующим убеждением, что это >> >> >> >> >> > надо закоммитить, тем более про "тщательное тестирование" было >> >> >> >> >> > явно написано. ;) >> >> >> >> >> >> >> >> >> >> это именно та тема и есть, сейчас дошли руки "тщательно >> >> >> >> >> протестировать". я запустил в продакшн. >> >> >> >> > >> >> >> >> > Меня в первую очередь удивило, что вместо патча, нарисованного ещё >> >> >> >> > полгода назад, к письму о "потестировать" прилагается совсем >> >> >> >> > другой патч, с чуть-чуть другими условиями и стилистическими >> >> >> >> > проблемами. Я бы всё-таки рекомендовал тестировать то, что потом >> >> >> >> > будем коммитить. >> >> >> >> > >> >> >> >> >> ждем пару месяцев (и, если проблем не всплывает, считаем, что все ок) ? >> >> >> >> > >> >> >> >> > Я, честно говоря, пребывал в надежде, что патч уже полгода >> >> >> >> > тестируется. ;) >> >> >> >> > >> >> >> >> > Но если нет - то, видимо, так и делаем. Только просьба - взять >> >> >> >> > для тестирования патч в том виде, в каком его предполагается >> >> >> >> > коммитить, if any: >> >> >> >> >> >> >> >> без проблем. сегодня запущу в продакшн в таком виде >> >> >> >> >> >> >> >> не совсем понятно, зачем делать условие "r->http_version < NGX_HTTP_VERSION_11" >> >> >> >> для версии 0.9, насколько я понимаю, и в моем и в вашем случае будет фигня >> >> >> > >> >> >> > Для 0.9 всё это не будет выполняться, т.к. будет отсечено >> >> >> > проверкой >> >> >> > >> >> >> > if (r->http_version < NGX_HTTP_VERSION_10) { >> >> >> > return NGX_OK; >> >> >> > } >> >> >> > >> >> >> > в начале функции. Принципиальной разницы между патчами нет, >> >> >> > вопрос в основном стилистический (с учётом того, что между >> >> >> > HTTP/1.0 и HTTP/1.1 других версий быть не может). >> >> >> >> >> >> тогда получается, что мой вариант лучше. >> >> >> >> >> >> для 0.9 по RFC не бывает keep-alive >> >> >> для 1.0 у меня сравнение по равенству >> >> > >> >> > Не согласен, т.к. важно не то, что в HTTP/1.0 нет keepalive'а по >> >> > умолчанию, а то, что keepalive по умолчанию есть в HTTP/1.1 и >> >> > выше, а в версиях до HTTP/1.1 его нужно явно включать. >> >> > >> >> > В условиях, когда у нас есть только HTTP/1.0 и HTTP/1.1, и никаких >> >> > промежуточных версий быть не может - патчи эквивалентны, и >> >> > различие только стилистическое. Но если бы был ещё какой-нибудь >> >> > HTTP/1.(1/2) - сравнение с HTTP/1.0 было бы неправильным. >> >> >> >> Максим, почему вы думаете, что разработчики RFC для HTTP/1.(1/2) >> >> заложат поведение, идентичное HTTP/1.0 ? >> >> ваш вариант это подразумевает. я не уверен, что будет именно так. >> > >> > Я уверен, что уже не будет. Всмысле - никакой версии HTTP/1.(1/2) >> > никогда не будет. Вопрос, повторяю, стилистический. >> >> если вопрос стилистический, давайте остановимся на моей версии. она >> мне больше нравится > > Да сколько угодно, я ж разве возражаю? Только тогда патч не будет > закоммичен из-за стилистических проблем. ;) без проблем. а чтобы всем было обидно, можете себе руку отрубить. > >> > Речь о том, что когда что-то меняется, то важна именно версия, в >> > которой это что-то поменялось. Подход, предполагающий явное >> > перечисление - работает только в условиях малого количества >> > версий. С ростом количества версий он становится непригодным к >> > использованию. >> >> это как раз случай версий HTTP, их мало > > Версий HTTP - потенциально бесконечное количество. В nginx'е уже > сейчас используются проверки r->http_version, нормально > скалирующиеся при увеличении количества версий, проверяющие именно > версии, в которых что-то изменилось. См. например процитированный > код выше. Не надо это пытаться сломать. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Wed Dec 11 18:22:04 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 11 Dec 2013 22:22:04 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHAg0LggaHR0cHMg0LIg?= =?UTF-8?B?0L7QtNC90L7QvCDQutC+0L3QuNCz0YPRgNCw0YbQuNC+0L3QvdC+0Lwg0YQ=?= =?UTF-8?B?0LDQudC70LUsINC90LAg0L/QvtGA0YLRiyDQvtGC0LvQuNGH0L3Ri9C1INC+?= =?UTF-8?B?0YIgODAg0LggNDQz?= In-Reply-To: References: <20131211153535.GY95113@mdounin.ru> Message-ID: <20131211182204.GD95113@mdounin.ru> Hello! On Wed, Dec 11, 2013 at 11:58:34AM -0500, mnsold wrote: [...] > Согласитесь, N количество блоков server {} и N количество блоков location > {} проще изменить, меньше вероятности допустить ошибки и понимать легче, чем > N*2 количество блоков server {} и N*2 количество блоков location {} > сделанных отдельно для http и для https. Не соглашусь. Проще менять то, что само по себе просто. А вероятность допустить ошибку - гораздо выше при редактировании сложного конфига. Количество - не так важно, и принципиального значения не имеет. Ну и не следует забывать, что все эти попытки "сокращения" конфигурации обычно выливаются в множество лишней работы при обработке запросов. На всякий случай я оставлю эту ссылку здесь: http://nginx.org/en/docs/faq/variables_in_config.html -- Maxim Dounin http://nginx.org/ From gmm at csdoc.com Wed Dec 11 19:42:30 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Wed, 11 Dec 2013 21:42:30 +0200 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHAg0LggaHR0cHMg0LIg?= =?UTF-8?B?0L7QtNC90L7QvCDQutC+0L3QuNCz0YPRgNCw0YbQuNC+0L3QvdC+0Lwg0YQ=?= =?UTF-8?B?0LDQudC70LUsINC90LAg0L/QvtGA0YLRiyDQvtGC0LvQuNGH0L3Ri9C1INC+?= =?UTF-8?B?0YIgODAg0LggNDQz?= In-Reply-To: References: <20131211153535.GY95113@mdounin.ru> Message-ID: <52A8C026.1040604@csdoc.com> On 11.12.2013 18:58, mnsold wrote: > Но вопрос в том, как проксировать одно приложение по http и https в одном > блоке server {} и одном блоке location {} (без дублей), учитавая, что > приложение на бэкэенде может быть доступно как в корне так и по контекстному > пути, а порты отличаются от 80 и 443. > > Согласитесь, N количество блоков server {} и N количество блоков location > {} проще изменить, меньше вероятности допустить ошибки и понимать легче, чем > N*2 количество блоков server {} и N*2 количество блоков location {} > сделанных отдельно для http и для https. конфиг nginx - это примерно то же самое, что и "ассемблер". здесь нет макросов, и если нужны макроподстановки, условная компиляция и другие возможности "макроассемблера", их надо будет реализовать самостоятельно с помощью m4, python, ruby, perl, awk, sed, и т.п. следующий уровень - написать свой собственный DSL, аналог "языка высокого уровня", который будет транслироваться в директивы "ассемблера", для их выполнения на nginx. ======================================================== например, я когда-то делал DSL, который на входе получает "конфиг на языке высокого уровня" с очевидным синтаксисом: h http://habrahabr.ru/ Хабрахабр gt http://translate.google.com.ua/ Google Translate yt http://youtube.com/ YouTube (всего - несколько десятков таких записей) а на выходе транслятора получается конфигурационный файл nginx, готовый для включения с помощью директивы include, такого вида: # # this is auto-generated file, do not edit manually # config source file: /etc/nginx/conf/redirect.conf # server { server_name h; server_name h.example.com; rewrite ^ http://habrahabr.ru/ redirect; } server { server_name gt; server_name gt.example.com; rewrite ^ http://translate.google.com.ua/ redirect; } server { server_name yt; server_name yt.example.com; rewrite ^ http://youtube.com/ redirect; } и страничка /etc/nginx/site/t/index.html где перечислены все видимые shortcut`ы. - это используется на сервере, куда указывает * запись в DNS для домена example.com, чтобы вручную не набирать полный адрес, а только shortcut`ы "h", "gt", "yt" и т.п. это быстро и удобно. поскольку меня об этом уже спрашивали в прошлый раз - в аттаче сам конфиг / генератор конфига redirect.conf и пример его использования в скрипте reload`а nginx. -- Best regards, Gena -------------- next part -------------- #!/bin/bash nginx -v /etc/nginx/conf/redirect.conf service nginx reload # for pid in $(pgrep nginx); do cat /proc/$pid/limits; done # for pid in $(pgrep nginx); do grep open /proc/$pid/limits ; done -------------- next part -------------- #!/usr/bin/python # encoding: utf-8 raw_config = """ yt http://youtube.com/ YouTube h http://habrahabr.ru Р?Р°Р?С?Р°С?Р°Р?С? dw http://www.freedrweb.com/ Р°Р?С?РёР?РёС?С?С? Dr.Web CureIt! t --- С?Р?РёС?Р?Р? Р?С?Р?С? С?Р?Р?С?Р°С?Р?Р?РёР? gt http://translate.google.com.ua/ Google Translate y http://www.ya.ru/ ya.ru yy http://www.yandex.ru/ yandex.ru gmail https://mail.google.com/ --- Gmail kp http://www.kp.ru/ --- kp.ru ripe http://www.ripe.net/ --- ripe vt http://www.virustotal.com/ru/ --- VirusTotal """ # ----------------------------------------------------------------------------------------------------------------------------------------------------------- conf_header = """ # # this is auto-generated file, do not edit manually # config source file: $config_filename # """ conf_record = """ server { server_name $name; server_name $name.example.com; rewrite ^ $url redirect; } """ conf_footer = """ """ # ----------------------------------------------------------------------------------------------------------------------------------------------------------- html_header = """ redirect service """ html_record = """ """ html_footer = """
$name $desc
""" # ----------------------------------------------------------------------------------------------------------------------------------------------------------- conf_filename = "/etc/nginx/conf/virtual/zzz-auto-generated-config" html_filename = "/etc/nginx/site/t/index.html" # ----------------------------------------------------------------------------------------------------------------------------------------------------------- import os import sys import string,re import itertools config = sorted( [ line.strip() for line in raw_config.splitlines() if line.strip() ] ) config_line = re.compile( r'^\s*(\S+)\s+(\S+)\s+(\S+.*?)\s*$' ) empty = re.compile( r'^---' ) def generate_config( generate_html, filename, header, record, footer ): generate_conf = not generate_html config_filename = os.path.abspath( sys.argv [ 0 ] ) toggle = itertools.cycle( [ 'ffffff', 'eeeeee' ] ) output = open( filename, 'w' ) output.write( string.Template( header ).substitute( config_filename=config_filename ) ) for line in config: if empty.match( line ): continue if line[0] == '#': continue match = config_line.match( line ) if not match : raise ValueError, "unexpected line in raw_config: " + line name = match.group( 1 ) url = match.group( 2 ) desc = match.group( 3 ) if ( ( generate_conf and not empty.match( url ) ) or ( generate_html and not empty.match( desc ) ) ) : output.write( string.Template( record ).substitute( name=name, url=url, desc=desc, toggle=toggle.next() ) ) output.write( string.Template( footer ).substitute() ) output.close() if __name__=="__main__": print "generating config...", generate_config( False, conf_filename, conf_header, conf_record, conf_footer ) generate_config( True, html_filename, html_header, html_record, html_footer ) print "[Ok]" # ----------------------------------------------------------------------------------------------------------------------------------------------------------- From nginx-forum at nginx.us Wed Dec 11 20:45:17 2013 From: nginx-forum at nginx.us (mnsold) Date: Wed, 11 Dec 2013 15:45:17 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHAg0LggaHR0cHMg0LIg?= =?UTF-8?B?0L7QtNC90L7QvCDQutC+0L3QuNCz0YPRgNCw0YbQuNC+0L3QvdC+0Lwg0YQ=?= =?UTF-8?B?0LDQudC70LUsINC90LAg0L/QvtGA0YLRiyDQvtGC0LvQuNGH0L3Ri9C1INC+?= =?UTF-8?B?0YIgODAg0LggNDQz?= In-Reply-To: <20131211182204.GD95113@mdounin.ru> References: <20131211182204.GD95113@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > > Согласитесь, N количество блоков server {} и N количество блоков > location > > {} проще изменить, меньше вероятности допустить ошибки и понимать > легче, чем > > N*2 количество блоков server {} и N*2 количество блоков location {} > > сделанных отдельно для http и для https. > > Не соглашусь. Проще менять то, что само по себе просто. А > вероятность допустить ошибку - гораздо выше при редактировании > сложного конфига. Количество - не так важно, и принципиального > значения не имеет. > > Ну и не следует забывать, что все эти попытки "сокращения" > конфигурации обычно выливаются в множество лишней работы при > обработке запросов. На всякий случай я оставлю эту ссылку здесь: > > http://nginx.org/en/docs/faq/variables_in_config.html Я с вами тоже тут не соглашусь, т.к. конфиг вида: server { listen 80; listen 443 ssl; ... include app; ... } файл app: location / { ... proxy_pass $schema://upstream:; ... } Очень простой и то, что вы написали "А вероятность допустить ошибку - гораздо выше при редактировании сложного конфига" тут несколько не уместно, т.к. вы правильно написали чуть выше "само по себе просто" и эти слова очень подходят для данной конфигурации. Не ясна тогда возможность указывать в директивы в одном блоке server {} server { listen 80; listen 443 ssl; С ваших слов получается - если удается заставить проксировать по схеме http->http + https->http то можно использовать такую конструкцию, в остальном - ее использовать не правильно, и нужно плодить блоки server{} и location{}. Я не утверждаю, что именно так вы сказали, это лишь вывод который сделал я на основе ваших наводок. И конфиг выше уж точно проще чем этот конфиг (как минимум с точки зрения внесения правок, минимизации ошибок, да и не только этого): server { listen 80; ... include app; ... } файл app: location / { ... proxy_pass http://upstream:; ... } server { listen 443 ssl; ... include apps; ... } файл apps: location / { ... proxy_pass https://upstream:; ... } Даже с точки зрения "множество лишней работы при обработке запросов" в данном случае: 1сервер+1локейшен(в одном файле)+одна доп. переменная $schema может быть проще в обработке чем 2сервера+2локейшена(в 2х файлах) и в место одной переменной статика в виде http и https. Это только мысли в слух, они ничем не подтверждены, таких тестов я пока не делал и в серьез их сейчас конечно воспринимать не нужно, но и отказываться от них еще рано. Максим, вы не подумайте что я вас не понимаю, прекрасно понимаю, но хотелось бы найти решение для вопроса который я озвучивал ранее и был бы признателен за помощь: как проксировать одно приложение по http и https в одном блоке server {} и одном блоке location {} (без дублей), учитавая, что приложение на бэкэенде может быть доступно как в корне так и по контекстному пути, а порты отличаются от 80 и 443. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245412,245448#msg-245448 From mdounin at mdounin.ru Thu Dec 12 00:35:05 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 12 Dec 2013 04:35:05 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1IGh0dHAg0LggaHR0cHMg0LIg?= =?UTF-8?B?0L7QtNC90L7QvCDQutC+0L3QuNCz0YPRgNCw0YbQuNC+0L3QvdC+0Lwg0YQ=?= =?UTF-8?B?0LDQudC70LUsINC90LAg0L/QvtGA0YLRiyDQvtGC0LvQuNGH0L3Ri9C1INC+?= =?UTF-8?B?0YIgODAg0LggNDQz?= In-Reply-To: References: <20131211182204.GD95113@mdounin.ru> Message-ID: <20131212003505.GF95113@mdounin.ru> Hello! On Wed, Dec 11, 2013 at 03:45:17PM -0500, mnsold wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > > Согласитесь, N количество блоков server {} и N количество блоков > > location > > > {} проще изменить, меньше вероятности допустить ошибки и понимать > > легче, чем > > > N*2 количество блоков server {} и N*2 количество блоков location {} > > > сделанных отдельно для http и для https. > > > > Не соглашусь. Проще менять то, что само по себе просто. А > > вероятность допустить ошибку - гораздо выше при редактировании > > сложного конфига. Количество - не так важно, и принципиального > > значения не имеет. > > > > Ну и не следует забывать, что все эти попытки "сокращения" > > конфигурации обычно выливаются в множество лишней работы при > > обработке запросов. На всякий случай я оставлю эту ссылку здесь: > > > > http://nginx.org/en/docs/faq/variables_in_config.html > > > Я с вами тоже тут не соглашусь, т.к. конфиг вида: > server { > listen 80; > listen 443 ssl; > ... > include app; > ... > } > > файл app: > location / { > ... > proxy_pass $schema://upstream:; > ... > } > Очень простой и то, что вы написали "А вероятность допустить ошибку - > гораздо выше при редактировании сложного конфига" тут несколько не уместно, > т.к. вы правильно написали чуть выше "само по себе просто" и эти слова очень > подходят для данной конфигурации. Использование proxy_pass с переменными - это совершенно отдельный режим работы proxy. Различие с обычным proxy_pass куда как большее, чем может показаться на первый взгляд. В частности, при задании URI запроса - его надо задавать, как справедливо написано в документации, полностью. И на администратора при этом ложится обязанность обеспечить корректность этого URI, в частности - экранирование специальных символов. На практике это означает, что, фактически, при использовании пременных URI должен передаваться "как есть". Поэтому я крайне не рекомендую использовать proxy_pass с переменными для того, чтобы сократить количество строк в конфиге. Написанное по ссылке выше про переменные в конфиге - относится к этому случаю в первую очередь. Ну и да, если мне не изменяет память, вы начали этот разговор с того, что так у вас - не работает. > Не ясна тогда возможность указывать в директивы в одном блоке server {} > server { > listen 80; > listen 443 ssl; > С ваших слов получается - если удается заставить проксировать по схеме > http->http + https->http то можно использовать такую конструкцию, в > остальном - ее использовать не правильно, и нужно плодить блоки server{} и > location{}. > Я не утверждаю, что именно так вы сказали, это лишь вывод который сделал я > на основе ваших наводок. Логика очень простая: если виртуальные сервера обрабатываются одинаково - используйте один блок server{}, если по разному - используйте разные блоки server{}. Блоки server{} существуют как раз для того, чтобы реализовывать разную обработку виртуальных серверов. [...] > Максим, вы не подумайте что я вас не понимаю, прекрасно понимаю, но хотелось > бы найти решение для вопроса который я озвучивал ранее и был бы признателен > за помощь: > как проксировать одно приложение по http и https в одном блоке server {} и > одном блоке location {} (без дублей), учитавая, что приложение на бэкэенде > может быть доступно как в корне так и по контекстному пути, а порты > отличаются от 80 и 443. Если хочется обязательно сделать это в конфигах nginx'а, то в общем и целом всё сводится к тому, что замену путей надо будет делать самостоятельно, e.g., с помощью rewrite. Как-то так должно сработать: location /foo/ { rewrite ^/foo/(.*) /bar/$1; if ($scheme = "https") { proxy_pass https://https-upstream; break; } proxy_pass http://plain-http-upstream; break; } Или так: map $scheme $backend { http http://plain-http-upstream; https https://https-upstream; } location /foo/ { rewrite ^/foo/(.*) /bar/$1 break; proxy_pass $backend; } Но, повторяю, это плохой путь. Результирующий конфиг получится сложный и малопригодный к использованию, и тем паче модификации. -- Maxim Dounin http://nginx.org/ From public-mail at alekciy.ru Thu Dec 12 08:12:34 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Thu, 12 Dec 2013 12:12:34 +0400 Subject: =?UTF-8?B?UmU6IFBIUCDQvtGI0LjQsdC60Lgg0LIgbmdpbnggZXJyb3IgbG9n?= In-Reply-To: References: Message-ID: Для display_errors можно указать stderr, тогда логировать можно на уровне nginx ( https://www.google.ru/search?ie=UTF-8&hl=ru&q=display_errors#hl=ru&newwindow=1&q=display_errors+stderr). Но единого формата лога при этом все равно не достичь. 11 декабря 2013 г., 17:37 пользователь greenh написал: > Добрый день > Имеется связка nginx/1.4.2+php5-fpm (PHP 5.3.27) > Очень хочется при display_errors=off заставить php ошибки ложиться в nginx > error.log. Единственный кривой способ, который я смог использовать - это > через fastcgi_param указать error_log=nginx-error.log > Но при этом я получаю два разных формата записи в лог, что оченьнеудобно > для парсинга. И вообще как то криво > Подскажите плз, как это можно седлать по человечьи? > > [global] > pid = run/php-fpm.pid > error_log = /var/log/php-fpm.log > > [project] > security.limit_extensions = .php .html > listen = /home/project/run/socket > listen.backlog = -1 > user = project > group = project > pm = dynamic > pm.max_children = 10 > pm.start_servers = 2 > pm.min_spare_servers = 1 > pm.max_spare_servers = 10 > catch_workers_output = yes > > > [PHP] > date.timezone = "Europe/Moscow" > display_errors=Off > magic_quotes_gpc=Off > upload_max_filesize = 20M > post_max_size = 10M > error_log = /home/php_error.log > log_errors = on > fastcgi.logging = 1 > max_execution_time = 600 > max_input_time = 600 > magic_quotes_gpc = Off > memory_limit = 256M > file_uploads = On > post_max_size = 20M > max_file_uploads = 20 > extension=mcrypt.so > extension=/usr/local/lib/php/20090626/mcrypt.so > php_memory_limit = 200M > > > _______________________________________________ > 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 xinu at list.ru Thu Dec 12 11:52:12 2013 From: xinu at list.ru (=?UTF-8?B?eGludQ==?=) Date: Thu, 12 Dec 2013 15:52:12 +0400 Subject: =?UTF-8?B?c2FuZHN0dXJtIC0g0LIg0YHRgNCw0LLQvdC10L3QuNC4INGBIG5pZ254IC0g0Lo=?= =?UTF-8?B?0YLQviDRgtC+INGBINGN0YLQuNC8INGD0LbQtSDRgNCw0LfQsdC40YDQsNC7?= =?UTF-8?B?0YHRjyA/?= Message-ID: <1386849132.812068132@f432.i.mail.ru> день добрый, сегодня встретил : http://conferences.sigcomm.org/hotnets/2013/papers/hotnets-final43.pdf по (их) тестам в разы быстрее nginx'а т.к. основан на алтернативной (новой) реализации tcpip stack'а - на сколько я понял, конечно (libtcpip / netmapio / libeth - см. pdf)  - есть ли алтернативные мнения  / сравнения (поиск по маилинглист - как то ничего не дал)?  - смотрел ли кто-то из ув. разработчиков ningx'а в сторону упомянутых библиотек (не тему возможности испол'зования их в ningx ) (библиотеки действител'но интересные - на странице netmapio - довольно не плохая презентация) ps: конечно тема немного в сторону от основной, но все же интересно... ps2: коды sandsturm - по слухам - выложат  где то через 2 месяца с ув. Сергей -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Dec 12 20:27:47 2013 From: nginx-forum at nginx.us (axaaxa) Date: Thu, 12 Dec 2013 15:27:47 -0500 Subject: =?UTF-8?B?0J3QtSDRgdGC0YDQuNC80LjRgtGB0Y8gKHNlZWspIC5tcDQ=?= Message-ID: Сабж: http://spectator.io.ua/video_view_2.php?idv=226702 При прокрутке начинает играть с начала. Файлы брались и закодированые в *nix через qt-faststart и в windows через datagoround.com/lab/ и с Youtube. Т.е. есть основания считать, что moov atom а правильном месте. nginx version: nginx/1.4.2 configure arguments: --with-cc-opt=-Os --prefix=/usr/local/nginx --without-http_ssi_module --without-http_userid_module --without-http_auth_basic_module --without-http_empty_gif_module --without-http_gzip_module --without-http_fastcgi_module --without-http_autoindex_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-http_stub_status_module --with-http_realip_module --with-http_flv_module --with-http_mp4_module --with-http_geoip_module --with-poll_module --with-file-aio --add-module=nginx_eval_module-1.0.3 --with-debug Подскажите пож добрые люди, куда копать? Благодарствую! С уважением, Андрей Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245481,245481#msg-245481 From ilya.strahov at gmail.com Fri Dec 13 06:12:54 2013 From: ilya.strahov at gmail.com (=?KOI8-R?B?6czY0SDz1NLByM/X?=) Date: Fri, 13 Dec 2013 10:12:54 +0400 Subject: REST response Message-ID: Здравствуйте. Подскажите пожалуйста, можно в лог nginx вывести REST response? {"response":{"status":200,"message":"OK","data":{"id":"70","name":".............. .............."}}} -------------- next part -------------- An HTML attachment was scrubbed... URL: From ru at nginx.com Fri Dec 13 09:00:51 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Fri, 13 Dec 2013 13:00:51 +0400 Subject: REST response In-Reply-To: References: Message-ID: <20131213090051.GC72202@lo0.su> On Fri, Dec 13, 2013 at 10:12:54AM +0400, Илья Страхов wrote: > Здравствуйте. > Подскажите пожалуйста, можно в лог nginx > вывести REST response? > > {"response":{"status":200,"message":"OK","data":{"id":"70","name":".............. > .............."}}} http://nginx.org/r/log_format/ru From mdounin at mdounin.ru Fri Dec 13 10:30:08 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 13 Dec 2013 14:30:08 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgtGA0LjQvNC40YLRgdGPIChzZWVrKSAubXA0?= In-Reply-To: References: Message-ID: <20131213103008.GO95113@mdounin.ru> Hello! On Thu, Dec 12, 2013 at 03:27:47PM -0500, axaaxa wrote: > Сабж: http://spectator.io.ua/video_view_2.php?idv=226702 > При прокрутке начинает играть с начала. > > Файлы брались и закодированые в *nix через qt-faststart и в windows через > datagoround.com/lab/ и с Youtube. > Т.е. есть основания считать, что moov atom а правильном месте. > > nginx version: nginx/1.4.2 > configure arguments: > --with-cc-opt=-Os --prefix=/usr/local/nginx --without-http_ssi_module > --without-http_userid_module --without-http_auth_basic_module > --without-http_empty_gif_module > --without-http_gzip_module --without-http_fastcgi_module > --without-http_autoindex_module > --without-mail_pop3_module --without-mail_imap_module > --without-mail_smtp_module > --with-http_stub_status_module --with-http_realip_module > --with-http_flv_module > --with-http_mp4_module --with-http_geoip_module --with-poll_module > --with-file-aio > --add-module=nginx_eval_module-1.0.3 --with-debug > > Подскажите пож добрые люди, куда копать? Для начала - смотреть в конфиг и логи. В частности, из access_log'а убедиться, что запрос от действительно доходит, и обрабатывается именно там, где вы ожидаете. А из error_log'а - что ошибок нет. Just in case, у меня по приведённой вами ссылке всё замечательно стримится - но при этом используется HTML5 video и range-запросы, никакого flash'а. -- Maxim Dounin http://nginx.org/ From vadim.lazovskiy at gmail.com Fri Dec 13 15:03:01 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Fri, 13 Dec 2013 19:03:01 +0400 Subject: Nginx online upgrade & systemd Message-ID: Здравствуйте. Пробовал ли кто обновлять nginx налету? После USR2 все запускается, после QUIT, старое начинает умирать. Ускорил TERM-ами, после убийства последнего старого воркера вышел и старый мастер-процесс и новые процессы. В логе: 2013-12-13T18:47:47.896165+04:00 srv03 systemd[1]: nginx.service: control process exited, code=exited status=1 2013-12-13T18:47:47.929207+04:00 srv03 systemd[1]: Unit nginx.service entered failed state. Подскажите, обновление без перерыва принципиально не возможно при использовании systemd или же есть какой-то способ? -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mva at mva.name Fri Dec 13 15:23:39 2013 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Fri, 13 Dec 2013 22:23:39 +0700 Subject: Nginx online upgrade & systemd In-Reply-To: References: Message-ID: <1946193.877eK1Cx2f@note> Так после USR2 Надо не QUIT а WINCH же слать, не? В письме от Пт, 13 декабря 2013 19:03:01 пользователь Vadim Lazovskiy написал: > Здравствуйте. > > Пробовал ли кто обновлять nginx налету? > > После USR2 все запускается, после QUIT, старое начинает умирать. > Ускорил TERM-ами, после убийства последнего старого воркера вышел и старый > мастер-процесс и новые процессы. > > В логе: > 2013-12-13T18:47:47.896165+04:00 srv03 systemd[1]: nginx.service: control > process exited, code=exited status=1 > 2013-12-13T18:47:47.929207+04:00 srv03 systemd[1]: Unit nginx.service > entered failed state. > > Подскажите, обновление без перерыва принципиально не возможно при > использовании systemd или же есть какой-то способ? > > -- > Best Regards, > Vadim Lazovskiy -- Best regsrds, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From vadim.lazovskiy at gmail.com Fri Dec 13 21:09:20 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Sat, 14 Dec 2013 01:09:20 +0400 Subject: Nginx online upgrade & systemd In-Reply-To: <1946193.877eK1Cx2f@note> References: <1946193.877eK1Cx2f@note> Message-ID: Здравствуйте. В таргете upgrade -QUIT. Это работает, воркеры начинают завершаться, вслед за ними старый мастер. После смерти мастера умирает все. Nginx запускается вот так: /usr/sbin/nginx -g daemon off; Видимо чтобы systemd мог следить за master-процессом. 13 декабря 2013 г., 19:23 пользователь Vadim A. Misbakh-Soloviov < mva at mva.name> написал: > Так после USR2 Надо не QUIT а WINCH же слать, не? > > > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin at symbi.org Fri Dec 13 21:21:28 2013 From: konstantin at symbi.org (Konstantin Baryshnikov) Date: Sat, 14 Dec 2013 01:21:28 +0400 Subject: Nginx online upgrade & systemd In-Reply-To: References: <1946193.877eK1Cx2f@note> Message-ID: <80BBD4F6-7A6C-4975-B1F1-A039B0F0C6E3@symbi.org> On Dec 14, 2013, at 1:09 AM, Vadim Lazovskiy wrote: > Nginx запускается вот так: > /usr/sbin/nginx -g daemon off; > > Видимо чтобы systemd мог следить за master-процессом. С daemon off апгрейд вряд ли будет правильно работать. Можно вместо этого написать в systemd nginx.service так: [Service] Type=forking PIDFile=/path/to/nginx.pid From nginx-ru at sadok.spb.ru Sat Dec 14 09:17:42 2013 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Sat, 14 Dec 2013 13:17:42 +0400 Subject: Nginx online upgrade & systemd In-Reply-To: References: Message-ID: <922539495.20131214131742@sadok.spb.ru> An HTML attachment was scrubbed... URL: From zmey1992 at ya.ru Sat Dec 14 11:12:18 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Sat, 14 Dec 2013 15:12:18 +0400 Subject: Nginx online upgrade & systemd In-Reply-To: <922539495.20131214131742@sadok.spb.ru> References: <922539495.20131214131742@sadok.spb.ru> Message-ID: <230771387019538@web19g.yandex.ru> Многим с этим "кактусом" придётся жить начиная с RHEL 7 14.12.2013, 13:18, "Dmitry Ivanov" : > Здравствуйте, Vadim. > > Вы писали 13 декабря 2013 г., 19:03:01: > > Вкусный кактус, да ) > > -- > > С уважением, > >  Dmitry                          mailto:nginx-ru at sadok.spb.ru > , > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ru at nginx.com Sat Dec 14 17:59:26 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Sat, 14 Dec 2013 21:59:26 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: <20131211180425.GC95113@mdounin.ru> References: <20131210133720.GF95113@mdounin.ru> <20131210163749.GL95113@mdounin.ru> <20131210184303.GR95113@mdounin.ru> <20131211144155.GW95113@mdounin.ru> <20131211180425.GC95113@mdounin.ru> Message-ID: <20131214175926.GK74021@lo0.su> On Wed, Dec 11, 2013 at 10:04:25PM +0400, Maxim Dounin wrote: > Да сколько угодно, я ж разве возражаю? Только тогда патч не будет > закоммичен из-за стилистических проблем. ;) Максим, закоммить пожалуйста свою версию патча и закроем вопрос. (Мне твой вариант патча нравится больше.) From nginx-ru at sadok.spb.ru Sun Dec 15 08:50:34 2013 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Sun, 15 Dec 2013 12:50:34 +0400 Subject: Nginx online upgrade & systemd In-Reply-To: <230771387019538@web19g.yandex.ru> References: <922539495.20131214131742@sadok.spb.ru> <230771387019538@web19g.yandex.ru> Message-ID: <64665827.20131215125034@sadok.spb.ru> Здравствуйте, Васильев. Вы писали 14 декабря 2013 г., 15:12:18: > Многим с этим "кактусом" придётся жить начиная с RHEL 7 >> Вкусный кактус, да ) Я вот до сих пор 4.х наблюдаю и даже пожелания ее установки. Оракл головного мозга ) Предлагаю остановить офф -- С уважением, Dmitry mailto:nginx-ru at sadok.spb.ru From public-mail at alekciy.ru Sun Dec 15 18:42:32 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Sun, 15 Dec 2013 22:42:32 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: References: Message-ID: >идея в том, что отправка заголовка "Connection: keep-alive" > в большинстве случаев не нужна. А можно для танкистов пояснить, почему? Потому что http1.1 и так скорее всего persistent? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Mon Dec 16 04:11:05 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 16 Dec 2013 10:11:05 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: References: Message-ID: 16 декабря 2013 г., 0:42 пользователь Алексей Сундуков написал: >>идея в том, что отправка заголовка "Connection: keep-alive" >> в большинстве случаев не нужна. > > А можно для танкистов пояснить, почему? Потому что http1.1 и так скорее > всего persistent? ответов в данном случае два: теоретически так делать можно, потому что это разрешено по RFC 2616 для HTTP/1.1 практически так делать можно, потому что ровно так делает IIS (по любым оценкам у него доля рынка - десятки процентов), и при этом ни у кого никаких проблем не возникает. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From public-mail at alekciy.ru Mon Dec 16 06:34:55 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Mon, 16 Dec 2013 10:34:55 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: References: Message-ID: А практический смысл? В голову приходит лишь мысль об экономии трафика, но -1 заголовок это же копейки. Просто хочется понять, почему из-за такой вроде бы мелочи разгорелся такой нешуточный диалог и тема вообще требует отдельного патча. 16 декабря 2013 г., 8:11 пользователь Илья Шипицин написал: > 16 декабря 2013 г., 0:42 пользователь Алексей Сундуков > написал: > >>идея в том, что отправка заголовка "Connection: keep-alive" > >> в большинстве случаев не нужна. > > > > А можно для танкистов пояснить, почему? Потому что http1.1 и так скорее > > всего persistent? > > ответов в данном случае два: > > теоретически так делать можно, потому что это разрешено по RFC 2616 для > HTTP/1.1 > > практически так делать можно, потому что ровно так делает IIS (по > любым оценкам у него доля рынка - десятки процентов), и при этом ни у > кого никаких проблем не возникает. > > > > > _______________________________________________ > > 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 Dec 16 08:28:54 2013 From: nginx-forum at nginx.us (Dmitriy_K) Date: Mon, 16 Dec 2013 03:28:54 -0500 Subject: =?UTF-8?B?0KHQuNGB0YLQtdC80L3Ri9C1INGB0LHQvtC4INCyINCy0LjRgNGC0YPQsNC70Lo=?= =?UTF-8?B?0LUgVk13YXJlIEZyZWVCU0QrTmdpbngrcHJveHkgY2FjaGUrdG1wZnM=?= Message-ID: <6e8c3c3a538e5434c81c0a9b8dd08307.NginxMailingListRussian@forum.nginx.org> Имеется виртуалка VMware vSphere, в которой работает реверс-прокси FreeBSD 9.2 +Nginx+proxy_cache+tmpfs Рабочая нагрузка системы сравнительно маленькая как по процессору, так и по кэшу (10-20% от 250Мб). Дисковый массив быстрый, оперативки и процессорной мощности с избытком. Настроен и прекрасно работает ntpd (stratum 1). Других рабочих функций кроме реверс-прокси система не выполняет. Проблема: С непредсказуемой периодичностью от недели до трёх месяцев происходит системный сбой, при котором в системе останавливается системный таймер (то, что обеспечивает выдачу времени программам и командам типа "date"). В результате, всё замирает на одной временной отметке. Некоторое время (до нескольких дней) всё может продолжаться без внешних признаков, только перестаёт приходить почта с ежедневными отчётами и переполняется кэш на tmpfs (переход с tmpfs на обычный дисковый кэш ничего не даёт). Существует полная копия данной виртуалки, в которой Nginx+tmpfs установлен, но не работает. В этой виртуалке никих сбоев не возникает. Вопрос: Можно ли что-то сделать, чтобы устранить проблему? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245550,245550#msg-245550 From postmaster at softsearch.ru Mon Dec 16 08:32:46 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 16 Dec 2013 12:32:46 +0400 Subject: =?UTF-8?B?UmU6INCh0LjRgdGC0LXQvNC90YvQtSDRgdCx0L7QuCDQsiDQstC40YDRgtGD0LA=?= =?UTF-8?B?0LvQutC1IFZNd2FyZSBGcmVlQlNEK05naW54K3Byb3h5IGNhY2hlK3RtcGZz?= In-Reply-To: <6e8c3c3a538e5434c81c0a9b8dd08307.NginxMailingListRussian@forum.nginx.org> References: <6e8c3c3a538e5434c81c0a9b8dd08307.NginxMailingListRussian@forum.nginx.org> Message-ID: <131223092.20131216123246@softsearch.ru> Здравствуйте, Dmitriy_K. У меня была подобная проблема после перехода на FreeBSD 9.2. Пришлось вернуться на 9.1. -- С уважением, Михаил mailto:postmaster at softsearch.ru From chipitsine at gmail.com Mon Dec 16 08:45:24 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 16 Dec 2013 14:45:24 +0600 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: References: Message-ID: практический смысл в экономии трафика. при наших нагрузках экономия достигает 1 гигабайт в месяц (и у нас еще не такой HighLoad, как у многих в этой рассылке). это не копейки. если вы мыслите про каналы в терминах " у меня канал 10 гигабит, мне без разницы", подумайте о пользователях, на 3G эти "копейки" очень существенны. нешуточный спор возник, как лучше проверять условие, либо " < HTTP11", либо " = HTTP10" принципиального спора "включать этот патч или не включать" нет. 16 декабря 2013 г., 12:34 пользователь Алексей Сундуков написал: > А практический смысл? В голову приходит лишь мысль об экономии трафика, но > -1 заголовок это же копейки. Просто хочется понять, почему из-за такой вроде > бы мелочи разгорелся такой нешуточный диалог и тема вообще требует > отдельного патча. > > > 16 декабря 2013 г., 8:11 пользователь Илья Шипицин > написал: > >> 16 декабря 2013 г., 0:42 пользователь Алексей Сундуков >> написал: >> >>идея в том, что отправка заголовка "Connection: keep-alive" >> >> в большинстве случаев не нужна. >> > >> > А можно для танкистов пояснить, почему? Потому что http1.1 и так скорее >> > всего persistent? >> >> ответов в данном случае два: >> >> теоретически так делать можно, потому что это разрешено по RFC 2616 для >> HTTP/1.1 >> >> практически так делать можно, потому что ровно так делает IIS (по >> любым оценкам у него доля рынка - десятки процентов), и при этом ни у >> кого никаких проблем не возникает. >> >> > >> > _______________________________________________ >> > 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 nginx-ru at sadok.spb.ru Mon Dec 16 08:57:48 2013 From: nginx-ru at sadok.spb.ru (Dmitry Ivanov) Date: Mon, 16 Dec 2013 12:57:48 +0400 Subject: =?UTF-8?B?UmU6INCh0LjRgdGC0LXQvNC90YvQtSDRgdCx0L7QuCDQsiDQstC40YDRgtGD0LA=?= =?UTF-8?B?0LvQutC1IFZNd2FyZSBGcmVlQlNEK05naW54K3Byb3h5IGNhY2hlK3RtcGZz?= In-Reply-To: <6e8c3c3a538e5434c81c0a9b8dd08307.NginxMailingListRussian@forum.nginx.org> References: <6e8c3c3a538e5434c81c0a9b8dd08307.NginxMailingListRussian@forum.nginx.org> Message-ID: <252280421.20131216125748@sadok.spb.ru> Здравствуйте, Dmitriy_K. Вы писали 16 декабря 2013 г., 12:28:54: > С непредсказуемой периодичностью от недели до трёх месяцев происходит > системный сбой, при котором в системе останавливается системный таймер (то, > что обеспечивает выдачу времени программам и командам типа "date"). В Вот тут долго рыли http://blog.lexa.ru/2013/05/25/podzemnyi_stuk_vozvrashchaetsya.html -- С уважением, Dmitry mailto:nginx-ru at sadok.spb.ru From nginx-forum at nginx.us Mon Dec 16 09:14:19 2013 From: nginx-forum at nginx.us (Dmitriy_K) Date: Mon, 16 Dec 2013 04:14:19 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9C00LXRgNC20LDRgtGMINC/0YDQvtC60YHQuNGA0L7QstCw?= =?UTF-8?B?0L3QuNC1INCyINC/0YDQtdC00LXQu9Cw0YUg0L/QvtC00LTQuNGA0LXQutGC?= =?UTF-8?B?0L7RgNC40Lgg0YHQsNC50YLQsCAocHJveHkgcmVkaXJlY3Qg0L3QtSDRgdGA?= =?UTF-8?B?0LDQsdCw0YLRi9Cy0LDQtdGCKSA/?= In-Reply-To: <20131203130032.GF93176@mdounin.ru> References: <20131203130032.GF93176@mdounin.ru> Message-ID: <9f322edbdf56677ca4059d60c3e617a5.NginxMailingListRussian@forum.nginx.org> Большое спасибо за разъяснения! Как более понятное резюме, лучшим вариантом проксирования отдельных директорий является адаптация бакэнда так, чтобы корень размещённого на нём сайта был размещён в директории с тем же именем, что и проксируемая. Можно также не делать проксирование поддиректории, а использовать переход на домен уровнем выше. В этом случае так же можно использовать общие кукисы для этих доменов для нужд SEO. Кстати, чисто формально, чтобы избежать упомянутого перескока в корень основного сайта, можно использовать такое: location /online { rewrite ^/online/(.*) /$1 break; proxy_pass https://10.22.33.44:88/; proxy_redirect / /online/; } Но это ничего не даёт по сути, поскольку при попытке использования для проксирования страницы с бакэнда все ссылки на включения в страницу будут запрашиваться от корня основного сайта и, соответственно, не работать. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245160,245551#msg-245551 From citrin at citrin.ru Mon Dec 16 11:01:33 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Mon, 16 Dec 2013 15:01:33 +0400 Subject: =?UTF-8?B?UmU6INCh0LjRgdGC0LXQvNC90YvQtSDRgdCx0L7QuCDQsiDQstC40YDRgtGD0LA=?= =?UTF-8?B?0LvQutC1IFZNd2FyZSBGcmVlQlNEK05naW54K3Byb3h5IGNhY2hlK3RtcGZz?= In-Reply-To: <6e8c3c3a538e5434c81c0a9b8dd08307.NginxMailingListRussian@forum.nginx.org> References: <6e8c3c3a538e5434c81c0a9b8dd08307.NginxMailingListRussian@forum.nginx.org> Message-ID: <52AEDD8D.5000908@citrin.ru> On 12/16/13 12:28, Dmitriy_K wrote: > Имеется виртуалка VMware vSphere, в которой работает реверс-прокси FreeBSD > 9.2 +Nginx+proxy_cache+tmpfs Вряд ли это связано с nginx или tmpfs. > Дисковый массив быстрый, оперативки и процессорной мощности с избытком. > Настроен и прекрасно работает ntpd (stratum 1). В случае VMware, ntpd лучше запускать только на голом железе, а в виртуалках его отключать и получать время через VMware Tools: https://support.ntp.org/bin/view/Support/VMWareNTP > С непредсказуемой периодичностью от недели до трёх месяцев происходит > системный сбой, при котором в системе останавливается системный таймер (то, > что обеспечивает выдачу времени программам и командам типа "date"). На этом же физическом сервере есть другие виртуалки? Если другие виртуалки есть и с ними не возникает, то можно предположить что проблема не из за железа, и копать нужно в сторону взаимодействия VMware и гостевой OS. From vadim.lazovskiy at gmail.com Mon Dec 16 11:21:29 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Mon, 16 Dec 2013 15:21:29 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: References: Message-ID: Здравствуйте. это 34 мегабайта в день? Похоже на экономию на спичках. При 100 000 r/s это 2 мегабайта в секунду. Не велика экономия. curl -s -D - https://vk.com -o /dev/null | wc -c 328 curl -s -D - https://vk.com -o /dev/null | sed '/Connection: keep-alive/d' | wc -c 304 Чуть меньше 8% на заголовках. Это при том, что, как правило, сама страница, скрипты, продолжают содержать отступы, \n, а местами и \r. 16 декабря 2013 г., 12:45 пользователь Илья Шипицин написал: > практический смысл в экономии трафика. при наших нагрузках экономия > достигает 1 гигабайт в месяц (и у нас еще не такой HighLoad, как у > многих в этой рассылке). это не копейки. > если вы мыслите про каналы в терминах " у меня канал 10 гигабит, мне > без разницы", подумайте о пользователях, на 3G эти "копейки" очень > существенны. > > нешуточный спор возник, как лучше проверять условие, либо " < HTTP11", > либо " = HTTP10" > принципиального спора "включать этот патч или не включать" нет. > > 16 декабря 2013 г., 12:34 пользователь Алексей Сундуков > написал: > > А практический смысл? В голову приходит лишь мысль об экономии трафика, > но > > -1 заголовок это же копейки. Просто хочется понять, почему из-за такой > вроде > > бы мелочи разгорелся такой нешуточный диалог и тема вообще требует > > отдельного патча. > > > > > > 16 декабря 2013 г., 8:11 пользователь Илья Шипицин > > > написал: > > > >> 16 декабря 2013 г., 0:42 пользователь Алексей Сундуков > >> написал: > >> >>идея в том, что отправка заголовка "Connection: keep-alive" > >> >> в большинстве случаев не нужна. > >> > > >> > А можно для танкистов пояснить, почему? Потому что http1.1 и так > скорее > >> > всего persistent? > >> > >> ответов в данном случае два: > >> > >> теоретически так делать можно, потому что это разрешено по RFC 2616 для > >> HTTP/1.1 > >> > >> практически так делать можно, потому что ровно так делает IIS (по > >> любым оценкам у него доля рынка - десятки процентов), и при этом ни у > >> кого никаких проблем не возникает. > >> > >> > > >> > _______________________________________________ > >> > 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 > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.lazovskiy at gmail.com Mon Dec 16 11:24:44 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Mon, 16 Dec 2013 15:24:44 +0400 Subject: Nginx online upgrade & systemd In-Reply-To: <80BBD4F6-7A6C-4975-B1F1-A039B0F0C6E3@symbi.org> References: <1946193.877eK1Cx2f@note> <80BBD4F6-7A6C-4975-B1F1-A039B0F0C6E3@symbi.org> Message-ID: Спасибо! 14 декабря 2013 г., 1:21 пользователь Konstantin Baryshnikov < konstantin at symbi.org> написал: > On Dec 14, 2013, at 1:09 AM, Vadim Lazovskiy > wrote: > > > Nginx запускается вот так: > > /usr/sbin/nginx -g daemon off; > > > > Видимо чтобы systemd мог следить за master-процессом. > > С daemon off апгрейд вряд ли будет правильно работать. > > Можно вместо этого написать в systemd nginx.service так: > > [Service] > Type=forking > PIDFile=/path/to/nginx.pid > _______________________________________________ > 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 mdounin at mdounin.ru Mon Dec 16 13:45:29 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 16 Dec 2013 17:45:29 +0400 Subject: =?UTF-8?B?UmU6INC/0LDRgtGHINC00LvRjyDQvtGC0LrQu9GO0YfQtdC90LjRjyDQt9Cw0LM=?= =?UTF-8?B?0L7Qu9C+0LLQutC+0LIgIkNvbm5lY3Rpb246IGtlZXAtYWxpdmUiICjQtdGJ?= =?UTF-8?B?0LUg0YDQsNC3KQ==?= In-Reply-To: <20131214175926.GK74021@lo0.su> References: <20131210133720.GF95113@mdounin.ru> <20131210163749.GL95113@mdounin.ru> <20131210184303.GR95113@mdounin.ru> <20131211144155.GW95113@mdounin.ru> <20131211180425.GC95113@mdounin.ru> <20131214175926.GK74021@lo0.su> Message-ID: <20131216134529.GF95113@mdounin.ru> Hello! On Sat, Dec 14, 2013 at 09:59:26PM +0400, Ruslan Ermilov wrote: > On Wed, Dec 11, 2013 at 10:04:25PM +0400, Maxim Dounin wrote: > > Да сколько угодно, я ж разве возражаю? Только тогда патч не будет > > закоммичен из-за стилистических проблем. ;) > > Максим, закоммить пожалуйста свою версию патча и закроем вопрос. > (Мне твой вариант патча нравится больше.) Я уже говорил в прошлый раз, и с тех пор ситуация не изменилась - без тщательного тестирования я не горю желанием это коммитить. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Mon Dec 16 18:48:58 2013 From: nginx-forum at nginx.us (Sferg) Date: Mon, 16 Dec 2013 13:48:58 -0500 Subject: =?UTF-8?B?0JrQsNC6INC+0LPRgNCw0L3QuNGH0LjRgtGMINC00L7RgdGC0YPQvyDQuiDQvtC/?= =?UTF-8?B?0YDQtdC00LXQu9GR0L3QvdGL0LwgcGhwLdGE0LDQudC70LDQvD8=?= Message-ID: <8d8c1dff6767e0c9b0bfd2fbacda4326.NginxMailingListRussian@forum.nginx.org> Здравствуйте, господа. Как в одном location можно прописать ограничение доступа к нескольким php-файлам? Не хочется для каждого файла городить свой location. Можно ли как-то реализовать список файлов, которые разделялись бы символом "|")? С уважением. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245597,245597#msg-245597 From zmey1992 at ya.ru Tue Dec 17 04:33:43 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Tue, 17 Dec 2013 08:33:43 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtCz0YDQsNC90LjRh9C40YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0L7Qv9GA0LXQtNC10LvRkdC90L3Ri9C8IHBocC3RhNCw0LnQu9Cw0Lw/?= In-Reply-To: <8d8c1dff6767e0c9b0bfd2fbacda4326.NginxMailingListRussian@forum.nginx.org> References: <8d8c1dff6767e0c9b0bfd2fbacda4326.NginxMailingListRussian@forum.nginx.org> Message-ID: <180021387254823@web7j.yandex.ru> http://nginx.org/en/docs/http/ngx_http_core_module.html#location location ~ (one|two|free)\.php$ { deny all; } 16.12.2013, 22:49, "Sferg" : > Здравствуйте, господа. Как в одном location можно прописать ограничение > доступа к нескольким php-файлам? Не хочется для каждого файла городить свой > location. Можно ли как-то реализовать список файлов, которые разделялись бы > символом "|")? > > С уважением. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245597,245597#msg-245597 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Tue Dec 17 06:22:14 2013 From: nginx-forum at nginx.us (Digan) Date: Tue, 17 Dec 2013 01:22:14 -0500 Subject: =?UTF-8?B?0KDQsNC30LHQuNCy0LrQsCDQu9C+0LPQsCDQvdCwINGH0LDRgdGC0Lg=?= Message-ID: Есть возможность разбить лог на части? Например при достижении какого-то размера файла, рядом бы создавался другой файл в который дальнейший лог писался. А то лог nginx_upstream_access просто нереально растет. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245601,245601#msg-245601 From artem.vasiliev at gmail.com Tue Dec 17 06:23:26 2013 From: artem.vasiliev at gmail.com (Artem Vasiliev) Date: Mon, 16 Dec 2013 22:23:26 -0800 (PST) Subject: =?UTF-8?B?UmU6INCg0LDQt9Cx0LjQstC60LAg0LvQvtCz0LAg0L3QsCDRh9Cw0YHRgtC4?= In-Reply-To: References: Message-ID: <1387261406110.a537974c@Nodemailer> Man logrotate для начала ? Sent from Mailbox for iPhone On Tue, Dec 17, 2013 at 10:22 AM, Digan wrote: > Есть возможность разбить лог на части? Например при достижении какого-то > размера файла, рядом бы создавался другой файл в который дальнейший лог > писался. А то лог nginx_upstream_access просто нереально растет. > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245601,245601#msg-245601 > _______________________________________________ > 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 Tue Dec 17 11:35:35 2013 From: nginx-forum at nginx.us (kozakd) Date: Tue, 17 Dec 2013 06:35:35 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgtGA0LjQvNC40YLRgdGPIChzZWVrKSAubXA0?= In-Reply-To: <20131213103008.GO95113@mdounin.ru> References: <20131213103008.GO95113@mdounin.ru> Message-ID: Добрый день, Максим. В логах всё красиво. :( Прошу поделиться файликом .mp4 с работающим стримом(скролом). Дмитрий. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245481,245602#msg-245602 From nginx-forum at nginx.us Tue Dec 17 11:43:59 2013 From: nginx-forum at nginx.us (kozakd) Date: Tue, 17 Dec 2013 06:43:59 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgtGA0LjQvNC40YLRgdGPIChzZWVrKSAubXA0?= In-Reply-To: <20131213103008.GO95113@mdounin.ru> References: <20131213103008.GO95113@mdounin.ru> Message-ID: Добавлю, фрагменты конфига nginx sendfile off; tcp_nopush on; tcp_nodelay on; aio on; directio 1m; directio_alignment 4k; output_buffers 1 2m; keepalive_timeout 0; client_header_timeout 20; client_body_timeout 20; send_timeout 20s; resolver_timeout 0; reset_timedout_connection on; proxy_buffering off; open_file_cache max=16000 inactive=20m; open_file_cache_valid 120m; open_file_cache_min_uses 2; open_file_cache_errors on; В самом хосте... location ~ \.mp4 { mp4; root /farm-video; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245481,245603#msg-245603 From mdounin at mdounin.ru Tue Dec 17 14:08:07 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 17 Dec 2013 18:08:07 +0400 Subject: nginx-1.5.8 Message-ID: <20131217140806.GS95113@mdounin.ru> Изменения в nginx 1.5.8 17.12.2013 *) Добавление: теперь resolver поддерживает IPv6. *) Добавление: директива listen поддерживает параметр fastopen. Спасибо Mathew Rodley. *) Добавление: поддержка SSL в модуле ngx_http_uwsgi_module. Спасибо Roberto De Ioris. *) Добавление: скрипты подсветки синтаксиса для vim добавлены в contrib. Спасибо Evan Miller. *) Исправление: при чтении тела запроса с использованием chunked transfer encoding по SSL-соединению мог произойти таймаут. *) Исправление: директива master_process работала неправильно в nginx/Windows. *) Исправление: параметр setfib директивы listen мог не работать. *) Исправление: в модуле ngx_http_spdy_module. -- Maxim Dounin http://nginx.org/en/donation.html From niakrisn at gmail.com Tue Dec 17 14:34:54 2013 From: niakrisn at gmail.com (=?UTF-8?B?0J3QuNC60LjRgtCwINCa0L7Qt9C70L7Qsg==?=) Date: Tue, 17 Dec 2013 18:34:54 +0400 Subject: nginx-1.5.8 In-Reply-To: <20131217140806.GS95113@mdounin.ru> References: <20131217140806.GS95113@mdounin.ru> Message-ID: 17 декабря 2013 г., 18:08 пользователь Maxim Dounin написал: > Изменения в nginx 1.5.8 17.12.2013 > *) Исправление: параметр setfib директивы listen мог не работать. А при каких условиях setfib мог не работать? From postmaster at softsearch.ru Tue Dec 17 14:40:10 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 17 Dec 2013 18:40:10 +0400 Subject: nginx-1.5.8 In-Reply-To: <20131217140806.GS95113@mdounin.ru> References: <20131217140806.GS95113@mdounin.ru> Message-ID: <1281642340.20131217184010@softsearch.ru> Здравствуйте, Maxim. > *) Добавление: директива listen поддерживает параметр fastopen. > Спасибо Mathew Rodley. Что делает этот параметр. В документации пока ничего про него нет. -- С уважением, Михаил mailto:postmaster at softsearch.ru From maxim at nginx.com Tue Dec 17 14:43:15 2013 From: maxim at nginx.com (Maxim Konovalov) Date: Tue, 17 Dec 2013 18:43:15 +0400 Subject: nginx-1.5.8 In-Reply-To: <1281642340.20131217184010@softsearch.ru> References: <20131217140806.GS95113@mdounin.ru> <1281642340.20131217184010@softsearch.ru> Message-ID: <52B06303.3010402@nginx.com> On 12/17/13 6:40 PM, Михаил Монашёв wrote: > Здравствуйте, Maxim. > >> *) Добавление: директива listen поддерживает параметр fastopen. >> Спасибо Mathew Rodley. > > Что делает этот параметр. В документации пока ничего про него нет. > > Включает поддержку tcp fastopen на системах, где эта фича есть. http://trac.nginx.org/nginx/changeset/692afcea9d0d05c10b1dd7f2bd095dd014665f4c/nginx http://en.wikipedia.org/wiki/TCP_Fast_Open -- Maxim Konovalov http://nginx.com From citrin at citrin.ru Tue Dec 17 14:47:33 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Tue, 17 Dec 2013 18:47:33 +0400 Subject: nginx-1.5.8 In-Reply-To: <1281642340.20131217184010@softsearch.ru> References: <20131217140806.GS95113@mdounin.ru> <1281642340.20131217184010@softsearch.ru> Message-ID: <52B06405.1040004@citrin.ru> On 12/17/13 18:40, Михаил Монашёв wrote: > Что делает этот параметр. В документации пока ничего про него нет. http://en.wikipedia.org/wiki/TCP_Fast_Open Позволяет сэкономить на повторной установке соединений. Имеет смысл в том случае, если на то чтобы держать keep alive ресурсов не хватает. Но поддержка клиентами пока не очень широкая, чтобы это имело заметный эффект. From ru at nginx.com Tue Dec 17 14:48:08 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Tue, 17 Dec 2013 18:48:08 +0400 Subject: nginx-1.5.8 In-Reply-To: References: <20131217140806.GS95113@mdounin.ru> Message-ID: <20131217144808.GJ63816@lo0.su> On Tue, Dec 17, 2013 at 06:34:54PM +0400, Никита Козлов wrote: > 17 декабря 2013 г., 18:08 пользователь Maxim Dounin > написал: > > Изменения в nginx 1.5.8 17.12.2013 > > *) Исправление: параметр setfib директивы listen мог не работать. > > А при каких условиях setfib мог не работать? nginx экономит на listen-сокетах, когда можнa (см. описание параметра bind тут: http://nginx.org/r/listen/ru) Наличие в директиве listen параметра setfib означает, что для этого нужно создать отдельный сокет. Если других причин создавать отдельный сокет код nginx не усматривал, этого не происходило, и соотв. параметр setfib фактически игнорировался. Для первой по порядку listen для данного IP-адреса:порта это работало, для не первой - могло не работать. From mdounin at mdounin.ru Tue Dec 17 14:52:09 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 17 Dec 2013 18:52:09 +0400 Subject: nginx-1.5.8 In-Reply-To: References: <20131217140806.GS95113@mdounin.ru> Message-ID: <20131217145209.GU95113@mdounin.ru> Hello! On Tue, Dec 17, 2013 at 06:34:54PM +0400, Никита Козлов wrote: > 17 декабря 2013 г., 18:08 пользователь Maxim Dounin > написал: > > Изменения в nginx 1.5.8 17.12.2013 > > *) Исправление: параметр setfib директивы listen мог не работать. > > А при каких условиях setfib мог не работать? Если listen-сокет использовался более чем в одном блоке server{}, параметр был задан не в первом блоке server{}, при этом не использовалось других параметров. Простейший workaround в старых версиях - добавить параметр bind явно. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Tue Dec 17 15:58:11 2013 From: nginx-forum at nginx.us (gigabyte) Date: Tue, 17 Dec 2013 10:58:11 -0500 Subject: =?UTF-8?B?ZmFzdGNnaSBjYWNoZSAtINC90LUg0LrQtdGI0LjRgNGD0LXRgg==?= Message-ID: <6dbb2e144fd3972dc71656744bea1961.NginxMailingListRussian@forum.nginx.org> Здравствуйте уважаемые знатоки. Помогите пожалуйста Проблема в следующем: Хочу закешировать ответ от php-fpm. И точно знаю что он работал но теперь непонятно почему - не хочет работать (файлы в /tmp/nginx - папка кеша) не создаются. Конфиг обработки php выглядит следующим образом: location ~ \.php$ { add_header "X-Debug-cachekey" $request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri|$cookie_key|$cookie_phpsessid; fastcgi_index index.php; fastcgi_pass 127.0.0.1:9000; fastcgi_cache_bypass $skip_cache; fastcgi_cache gk; fastcgi_cache_valid 200 301 302 304 10s; fastcgi_cache_min_uses 1; fastcgi_hide_header "Set-Cookie"; fastcgi_ignore_headers "Cache-Control" "Expires"; fastcgi_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri|$cookie_key|$cookie_phpsessid"; include fastcgi_params; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_intercept_errors on; fastcgi_ignore_client_abort off; fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245604,245604#msg-245604 From nginx-forum at nginx.us Tue Dec 17 15:59:26 2013 From: nginx-forum at nginx.us (gigabyte) Date: Tue, 17 Dec 2013 10:59:26 -0500 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgLSDQvdC1INC60LXRiNC40YDRg9C10YI=?= In-Reply-To: <6dbb2e144fd3972dc71656744bea1961.NginxMailingListRussian@forum.nginx.org> References: <6dbb2e144fd3972dc71656744bea1961.NginxMailingListRussian@forum.nginx.org> Message-ID: P.S. Строчку fastcgi_cache_bypass $skip_cache; - менял во все направления - не помогает Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245604,245605#msg-245605 From nginx-forum at nginx.us Tue Dec 17 19:42:32 2013 From: nginx-forum at nginx.us (Sargas) Date: Tue, 17 Dec 2013 14:42:32 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgtGA0LjQvNC40YLRgdGPIChzZWVrKSAubXA0?= In-Reply-To: References: <20131213103008.GO95113@mdounin.ru> Message-ID: <16a0416c1e01df1b79685148ca8a06ca.NginxMailingListRussian@forum.nginx.org> Можете скачать любой ролик с youtube с помощью http://ru.savefrom.net/ , в них точно перемотка работает :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245481,245607#msg-245607 From maxim at nginx.com Tue Dec 17 20:08:55 2013 From: maxim at nginx.com (Maxim Konovalov) Date: Wed, 18 Dec 2013 00:08:55 +0400 Subject: =?UTF-8?B?c2FuZHN0b3JtICh3YXMgUmU6IHNhbmRzdHVybSAtINCyINGB0YDQsNCy0L3QtdC9?= =?UTF-8?B?0LjQuCDRgSBuaWdueCAtINC60YLQviDRgtC+INGBINGN0YLQuNC8INGD0LY=?= =?UTF-8?B?0LUg0YDQsNC30LHQuNGA0LDQu9GB0Y8gPyk=?= In-Reply-To: <1386849132.812068132@f432.i.mail.ru> References: <1386849132.812068132@f432.i.mail.ru> Message-ID: <52B0AF57.5090901@nginx.com> On 12/12/13 3:52 PM, xinu wrote: > день добрый, > > сегодня встретил : > http://conferences.sigcomm.org/hotnets/2013/papers/hotnets-final43.pdf > по (их) тестам в разы быстрее nginx'а т.к. основан на алтернативной > (новой) реализации tcpip stack'а - на сколько я понял, конечно > (libtcpip / netmapio / libeth - см. pdf) > > - есть ли алтернативные мнения / сравнения (поиск по маилинглист - > как то ничего не дал)? > - смотрел ли кто-то из ув. разработчиков ningx'а в сторону > упомянутых библиотек (не тему возможности испол'зования их в ningx ) > (библиотеки действител'но интересные - на странице netmapio - > довольно не плохая презентация) > > ps: конечно тема немного в сторону от основной, но все же интересно... > ps2: коды sandsturm - по слухам - выложат где то через 2 месяца > Работа, безусловно, интересная. Мы это направление (nginx + userland tcp/ip) обсуждали как перспективную тему для внутреннего НИР. -- Maxim Konovalov http://nginx.com From nginx-forum at nginx.us Tue Dec 17 20:47:26 2013 From: nginx-forum at nginx.us (hemper) Date: Tue, 17 Dec 2013 15:47:26 -0500 Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDRgNCw0LfQvtCx0YDQsNGC0YzRgdGPINC60LDQuiA=?= =?UTF-8?B?0YDRg9GH0LrQsNC80Lgg0YHQvtC30LTQsNGC0Ywgbmdpbngg0LrQtdGIINGE?= =?UTF-8?B?0LDQudC7INC90LAgUEhQ?= Message-ID: <97dca23cda111a1ca283f5e8b73cf293.NginxMailingListRussian@forum.nginx.org> Формат кеш файла следующий: -- {bytecode} KEY: {cache_key} {bytecode}{http_headers} {body} -- Меня интересует какая си-шная структура сериализируетя и как в {bytecode} местах? Мой вопрос на stackoverflow: http://stackoverflow.com/questions/19531019/how-to-manually-generate-nginx-http-cache-file Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245608,245608#msg-245608 From nginx-forum at nginx.us Tue Dec 17 21:01:43 2013 From: nginx-forum at nginx.us (arty777) Date: Tue, 17 Dec 2013 16:01:43 -0500 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0L3QsNGH0LDQu9CwINCy0L7RgdC/0YDQvtC4?= =?UTF-8?B?0LfQstC10LTQtdC90LjRjyDQstC40LTQtdC+INCyINC80L7QtNGD0LvQtSBt?= =?UTF-8?B?cDQ=?= In-Reply-To: References: <87ef7119656003519cf4bc86a1242207.NginxMailingListRussian@forum.nginx.org> Message-ID: <45f45a2da8bd9c4d7947b7dc39450ba3.NginxMailingListRussian@forum.nginx.org> Удалось решить проблему с МНОГО СКАЧАТЬ (5-6 егабайт) что бы начать проигрывание? Суть вопроса , у меня мп4 файл , хочу что бы скачивалось 100 килобайт и начиналось воспроизаедение , а не 3-5 мегабайт !!! Есть идеи? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,237744,245609#msg-245609 From ru at nginx.com Wed Dec 18 08:54:47 2013 From: ru at nginx.com (Ruslan Ermilov) Date: Wed, 18 Dec 2013 12:54:47 +0400 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUgLSDQvdC1INC60LXRiNC40YDRg9C10YI=?= In-Reply-To: <6dbb2e144fd3972dc71656744bea1961.NginxMailingListRussian@forum.nginx.org> References: <6dbb2e144fd3972dc71656744bea1961.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131218085447.GX63816@lo0.su> On Tue, Dec 17, 2013 at 10:58:11AM -0500, gigabyte wrote: > Здравствуйте уважаемые знатоки. Помогите пожалуйста > Проблема в следующем: Хочу закешировать ответ от php-fpm. И точно знаю что > он работал но теперь непонятно почему - не хочет работать (файлы в > /tmp/nginx - папка кеша) не создаются. > Конфиг обработки php выглядит следующим образом: > location ~ \.php$ { > add_header "X-Debug-cachekey" > $request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri|$cookie_key|$cookie_phpsessid; > fastcgi_index index.php; > fastcgi_pass 127.0.0.1:9000; > fastcgi_cache_bypass $skip_cache; > fastcgi_cache gk; > fastcgi_cache_valid 200 301 302 304 10s; > fastcgi_cache_min_uses 1; > fastcgi_hide_header "Set-Cookie"; Может быть в ответе есть Set-Cookie? > fastcgi_ignore_headers "Cache-Control" "Expires"; http://nginx.org/r/fastcgi_cache_valid/ru : Ответ, в заголовке которого есть поле ?Set-Cookie?, не будет кэшироваться. : Обработка одного или более из этих полей заголовка может быть отключена : при помощи директивы fastcgi_ignore_headers. > fastcgi_cache_key > "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri|$cookie_key|$cookie_phpsessid"; > > include fastcgi_params; > > fastcgi_param DOCUMENT_ROOT $document_root; > fastcgi_param SCRIPT_FILENAME > $document_root$fastcgi_script_name; > fastcgi_param PATH_TRANSLATED > $document_root$fastcgi_script_name; > fastcgi_param PATH_INFO $fastcgi_path_info; > fastcgi_param QUERY_STRING $query_string; > fastcgi_param REQUEST_METHOD $request_method; > fastcgi_param CONTENT_TYPE $content_type; > fastcgi_param CONTENT_LENGTH $content_length; > fastcgi_intercept_errors on; > fastcgi_ignore_client_abort off; > fastcgi_connect_timeout 60; > fastcgi_send_timeout 180; > fastcgi_read_timeout 180; > fastcgi_buffer_size 128k; > fastcgi_buffers 4 256k; > fastcgi_busy_buffers_size 256k; > fastcgi_temp_file_write_size 256k; > } From mdounin at mdounin.ru Wed Dec 18 12:15:27 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 18 Dec 2013 16:15:27 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0YDQsNC30L7QsdGA0LDRgtGM0YHRjyDQutCw?= =?UTF-8?B?0Log0YDRg9GH0LrQsNC80Lgg0YHQvtC30LTQsNGC0Ywgbmdpbngg0LrQtdGI?= =?UTF-8?B?INGE0LDQudC7INC90LAgUEhQ?= In-Reply-To: <97dca23cda111a1ca283f5e8b73cf293.NginxMailingListRussian@forum.nginx.org> References: <97dca23cda111a1ca283f5e8b73cf293.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131218121527.GB95113@mdounin.ru> Hello! On Tue, Dec 17, 2013 at 03:47:26PM -0500, hemper wrote: > Формат кеш файла следующий: > > -- > {bytecode} > KEY: {cache_key} > {bytecode}{http_headers} > > {body} > -- > > Меня интересует какая си-шная структура сериализируетя и как в {bytecode} > местах? Не надо этого делать. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Wed Dec 18 14:11:40 2013 From: nginx-forum at nginx.us (tfox) Date: Wed, 18 Dec 2013 09:11:40 -0500 Subject: =?UTF-8?B?0KfRgtC+INC30L3QsNGH0LjRgiAibG9jYXRpb24gLyIgPw==?= Message-ID: <908ce1f88896c90fb4bd0aac690d0cf2.NginxMailingListRussian@forum.nginx.org> Вот такой блок кода написал администратор веб-приложений: location / { # взято отсюда: habrahabr.ru/post/124684 proxy_cache cache_site; proxy_cache_valid 200m; proxy_cache_valid 404 20m; # взято отсюда: wiki.enchtex.info/practice/nginx/cache # Ключ по которому сохраняются и берутся данные из кеша proxy_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; # Защита от раздачи одинаковой куки в кешированном ответе proxy_hide_header "Set-Cookie"; # Игнорировать параметры кеша заданные бекэндом proxy_ignore_headers "Cache-Control" "Expires"; # Указывает в каких случаях клиенту можно отдать несвежий ответ из кеша proxy_cache_use_stale error timeout invalid_header http_500 http_502 http_503 http_504; proxy_pass http://178.110.218.120:81; # закомментировал редирект потому, что # после переполнения кэша происходит # циклическая переадрисация и сайт недоступен некоторое время proxy_redirect http://178.110.218.120:81/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } Он ускоряет работу нашего сайта. Может кому пригодится. Как я интуитивно догадываюсь "location /" - означает выполнять команды для всего сайта. Но как мне сделать, чтобы Локэйшен приведенный выше, выполнялся только тогда, когда в урле нет слова "administrator"? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245672,245672#msg-245672 From mdounin at mdounin.ru Wed Dec 18 14:25:31 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 18 Dec 2013 18:25:31 +0400 Subject: =?UTF-8?B?UmU6INCn0YLQviDQt9C90LDRh9C40YIgImxvY2F0aW9uIC8iID8=?= In-Reply-To: <908ce1f88896c90fb4bd0aac690d0cf2.NginxMailingListRussian@forum.nginx.org> References: <908ce1f88896c90fb4bd0aac690d0cf2.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131218142531.GC95113@mdounin.ru> Hello! On Wed, Dec 18, 2013 at 09:11:40AM -0500, tfox wrote: > Вот такой блок кода написал администратор веб-приложений: > > location / { [...] > } > > Он ускоряет работу нашего сайта. Может кому пригодится. > > Как я интуитивно догадываюсь "location /" - означает выполнять команды для > всего сайта. > Но как мне сделать, чтобы Локэйшен приведенный выше, выполнялся только > тогда, когда в урле нет слова "administrator"? Для начала - прочитать это: http://nginx.org/ru/docs/http/request_processing.html Потом заглянуть в документацию сюда: http://nginx.org/ru/docs/http/ngx_http_core_module.html#location -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Wed Dec 18 16:52:38 2013 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 18 Dec 2013 11:52:38 -0500 Subject: =?UTF-8?B?UmU6INCn0YLQviDQt9C90LDRh9C40YIgImxvY2F0aW9uIC8iID8=?= In-Reply-To: <908ce1f88896c90fb4bd0aac690d0cf2.NginxMailingListRussian@forum.nginx.org> References: <908ce1f88896c90fb4bd0aac690d0cf2.NginxMailingListRussian@forum.nginx.org> Message-ID: <60f1c19d9f454c198b459f6b74babb9e.NginxMailingListRussian@forum.nginx.org> > # Ключ по которому сохраняются и берутся > данные из кеша > proxy_cache_key > "$request_method|$http_if_modified_since|$http_if_none_match|$host|$re > quest_uri"; Стоит подумать про оптимизацию proxy_cache_key, у вас в ключе есть лишние переменные - $http_if_modified_since|$http_if_none_match которые указывать не стоит, из-за них кол-во файлов кеша будет только больше, процент выдачи ответа из кеша только уменьшится. И вместо $request_uri лучше использовать переменую $uri, она нормализирована и меняется при внутренних редиректах. Самый оптимальный вариант ключа для кеша будет выглядит так proxy_cache_key "$host$uri$is_args$args"; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245672,245692#msg-245692 From nginx-forum at nginx.us Wed Dec 18 17:54:09 2013 From: nginx-forum at nginx.us (Sferg) Date: Wed, 18 Dec 2013 12:54:09 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtCz0YDQsNC90LjRh9C40YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0L7Qv9GA0LXQtNC10LvRkdC90L3Ri9C8IHBocC3RhNCw0LnQu9Cw0Lw/?= In-Reply-To: <180021387254823@web7j.yandex.ru> References: <180021387254823@web7j.yandex.ru> Message-ID: <7707a30df8263bfb82682bf1324356fb.NginxMailingListRussian@forum.nginx.org> > location ~ (one|two|free)\.php$ { deny all; } Да, я находил подобное решение, но оно, к сожалению, не работают. Доступ к .php-файлам как был, так и остался. А хотелось бы видеть 403 Forbidden при обращении к файлам из списка. C уважением. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245597,245694#msg-245694 From universite at ukr.net Wed Dec 18 18:05:27 2013 From: universite at ukr.net (Vladislav Prodan) Date: Wed, 18 Dec 2013 20:05:27 +0200 Subject: =?UTF-8?B?UmVbMl06INCa0LDQuiDQvtCz0YDQsNC90LjRh9C40YLRjCDQtNC+0YHRgtGD0L8g?= =?UTF-8?B?0Log0L7Qv9GA0LXQtNC10LvRkdC90L3Ri9C8IHBocC3RhNCw0LnQu9Cw0Lw/?= In-Reply-To: <7707a30df8263bfb82682bf1324356fb.NginxMailingListRussian@forum.nginx.org> References: <180021387254823@web7j.yandex.ru> <7707a30df8263bfb82682bf1324356fb.NginxMailingListRussian@forum.nginx.org> Message-ID: <1387389915.300292827.hxi874j4@frv35.ukr.net> --- Исходное сообщение --- От кого: "Sferg" Дата: 18 декабря 2013, 19:54:14 > > location ~ (one|two|free)\.php$ { deny all; } > > Да, я находил подобное решение, но оно, к сожалению, не работают. Доступ к > .php-файлам как был, так и остался. А хотелось бы видеть 403 Forbidden при > обращении к файлам из списка. > Выставьте это правило вперед, перед обработчиком .php файлов и обновите конфигурацию nginx. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From nginx-forum at nginx.us Wed Dec 18 19:11:16 2013 From: nginx-forum at nginx.us (hemper) Date: Wed, 18 Dec 2013 14:11:16 -0500 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0YDQsNC30L7QsdGA0LDRgtGM0YHRjyDQutCw?= =?UTF-8?B?0Log0YDRg9GH0LrQsNC80Lgg0YHQvtC30LTQsNGC0Ywgbmdpbngg0LrQtdGI?= =?UTF-8?B?INGE0LDQudC7INC90LAgUEhQ?= In-Reply-To: <20131218121527.GB95113@mdounin.ru> References: <20131218121527.GB95113@mdounin.ru> Message-ID: <62d0dc7e5478a12d95b959161f1ffc5b.NginxMailingListRussian@forum.nginx.org> Спасибо за совет, но вопрос был, как, а не, нужно или нет :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245608,245697#msg-245697 From zmey1992 at ya.ru Thu Dec 19 07:08:15 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Thu, 19 Dec 2013 11:08:15 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtCz0YDQsNC90LjRh9C40YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0L7Qv9GA0LXQtNC10LvRkdC90L3Ri9C8IHBocC3RhNCw0LnQu9Cw0Lw/?= In-Reply-To: <7707a30df8263bfb82682bf1324356fb.NginxMailingListRussian@forum.nginx.org> References: <180021387254823@web7j.yandex.ru> <7707a30df8263bfb82682bf1324356fb.NginxMailingListRussian@forum.nginx.org> Message-ID: <63891387436895@web28m.yandex.ru> http://nginx.org/ru/docs/http/request_processing.html P.S. s/free/three/g 18.12.2013, 21:54, "Sferg" : >>  location ~ (one|two|free)\.php$ { deny all; } > > Да, я находил подобное решение, но оно, к сожалению, не работают. Доступ к > .php-файлам как был, так и остался. А хотелось бы видеть 403 Forbidden при > обращении к файлам из списка. > > C уважением. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245597,245694#msg-245694 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From slava.kokorin at gmail.com Thu Dec 19 09:02:51 2013 From: slava.kokorin at gmail.com (Slava Kokorin) Date: Thu, 19 Dec 2013 13:02:51 +0400 Subject: =?UTF-8?B?0J3QsNGB0LvQtdC00L7QstCw0L3QuNC1INCy0L3Rg9GC0YDQuCDQstC70L7QttC1?= =?UTF-8?B?0L3QvdGL0YUgbG9jYXRpb24=?= Message-ID: Добрый день. Имеется следующая конфигурация: server { auth_basic "On"; auth_basic_user_file .htpasswd; location /geoserver { proxy_pass http://127.0.0.1:8080; proxy_set_header Authorization ""; proxy_set_header Host $host; location /geoserver/devcosmo { auth_basic off; ? ? ## Цель - отключить авторизацию этого URI ? ? } } } Ожидал, что proxy_* директивы для этого вложенного /geoserver/devcosmo будут наследоваться из вышестоящего location, однако получилось 404. Версия nginx/1.4.4 Подскажите, почему так происходит что не всё наследуется во вложенных location ? Можно ссылками на документацию... Спасибо. -- Regards, Slava -------------- next part -------------- An HTML attachment was scrubbed... URL: From chmind at yandex.ru Thu Dec 19 09:05:32 2013 From: chmind at yandex.ru (chmind at yandex.ru) Date: Thu, 19 Dec 2013 13:05:32 +0400 Subject: force gzip Accept-Encoding: gzip Message-ID: Добрый день. Подскажите пожалуйста, можно ли заставить nginx сжимать все ответы даже если в запросе небыло Accept-Encoding заголовка ? From zmey1992 at ya.ru Thu Dec 19 09:07:39 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Thu, 19 Dec 2013 13:07:39 +0400 Subject: =?UTF-8?B?UmU6INCd0LDRgdC70LXQtNC+0LLQsNC90LjQtSDQstC90YPRgtGA0Lgg0LLQu9C+?= =?UTF-8?B?0LbQtdC90L3Ri9GFIGxvY2F0aW9u?= In-Reply-To: References: Message-ID: <142871387444059@web26g.yandex.ru> 02.09.2013, 05:40, "Maxim Dounin" : >  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 > >  _______________________________________________ >  nginx-ru mailing list >  nginx-ru at nginx.org >  http://mailman.nginx.org/mailman/listinfo/nginx-ru 19.12.2013, 13:03, "Slava Kokorin" : >  Добрый день. > >  Имеется следующая конфигурация: > >  server { > >    auth_basic "On"; > >    auth_basic_user_file .htpasswd; > >    location /geoserver { > >       proxy_pass http://127.0.0.1:8080; >       proxy_set_header Authorization ""; >       proxy_set_header Host $host; > >       location /geoserver/devcosmo { >          auth_basic off;  ? > >     ?     ## Цель - отключить авторизацию этого URI > >       ?   ? >  } >    } >  } > >  Ожидал, что proxy_* директивы для этого вложенного /geoserver/devcosmo будут наследоваться из вышестоящего location, однако получилось 404. > >  Версия nginx/1.4.4 > >  Подскажите, почему так происходит что не всё наследуется во вложенных location ? Можно ссылками на документацию... > >  Спасибо. > >  -- >  Regards, >  Slava >  , >  _______________________________________________ >  nginx-ru mailing list >  nginx-ru at nginx.org >  http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Thu Dec 19 13:14:21 2013 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 19 Dec 2013 17:14:21 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvtCz0YDQsNC90LjRh9C40YLRjCDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0L7Qv9GA0LXQtNC10LvRkdC90L3Ri9C8IHBocC3RhNCw0LnQu9Cw0Lw/?= In-Reply-To: <8d8c1dff6767e0c9b0bfd2fbacda4326.NginxMailingListRussian@forum.nginx.org> References: <8d8c1dff6767e0c9b0bfd2fbacda4326.NginxMailingListRussian@forum.nginx.org> Message-ID: <2019973.z4ii38kDXx@vbart-laptop> On Monday 16 December 2013 13:48:58 Sferg wrote: > Здравствуйте, господа. Как в одном location можно прописать ограничение > доступа к нескольким php-файлам? Не хочется для каждого файла городить свой > location. Можно ли как-то реализовать список файлов, которые разделялись бы > символом "|")? > > С уважением. > Реализовать список файлов можно с помощью директории, а директорию вынести за область видимости веб-сервера. -- Валентин Бартенев From mdounin at mdounin.ru Thu Dec 19 15:27:06 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 19 Dec 2013 19:27:06 +0400 Subject: force gzip Accept-Encoding: gzip In-Reply-To: References: Message-ID: <20131219152706.GT95113@mdounin.ru> Hello! On Thu, Dec 19, 2013 at 01:05:32PM +0400, chmind at yandex.ru wrote: > Подскажите пожалуйста, можно ли заставить nginx сжимать все ответы даже если в запросе небыло > Accept-Encoding заголовка ? Нет. Но скорее всего ваша задача решается добавлением заголовка Accept-Encoding на фронтенде. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Thu Dec 19 17:25:23 2013 From: nginx-forum at nginx.us (Sferg) Date: Thu, 19 Dec 2013 12:25:23 -0500 Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQmtCw0Log0L7Qs9GA0LDQvdC40YfQuNGC0Ywg0LTQvtGB0YI=?= =?UTF-8?B?0YPQvyDQuiDQvtC/0YDQtdC00LXQu9GR0L3QvdGL0LwgcGhwLdGE0LDQudC7?= =?UTF-8?B?0LDQvD8=?= In-Reply-To: <1387389915.300292827.hxi874j4@frv35.ukr.net> References: <1387389915.300292827.hxi874j4@frv35.ukr.net> Message-ID: <2aa977519fc00217e99482a17965742c.NginxMailingListRussian@forum.nginx.org> Благодарствую. Всё получилось. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245597,245727#msg-245727 From nginx-forum at nginx.us Fri Dec 20 21:38:45 2013 From: nginx-forum at nginx.us (Sferg) Date: Fri, 20 Dec 2013 16:38:45 -0500 Subject: =?UTF-8?B?0KTQvtGA0LzQsNGCIGFjY2Vzcy5sb2cg0LIgbmdpbnguLi4=?= Message-ID: Здравствуйте, господа. Подскажите, пожалуйста, каким образом (и вообще, возможно ли это) сделать так, чтобы в access.log писалась полная строчка запроса? Сейчас переменная $request выводит: "GET /index.php HTTP/1.1" А хотелось бы, чтоб выводила нечто вроде этого: "GET http://example.com/index.php HTTP1.1" Для того, чтобы знать, куда именно ходит пользователь или бот, например, на http или на https и т.д. С уважением. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245743,245743#msg-245743 From vbart at nginx.com Fri Dec 20 22:53:16 2013 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 21 Dec 2013 02:53:16 +0400 Subject: =?UTF-8?B?UmU6INCk0L7RgNC80LDRgiBhY2Nlc3MubG9nINCyIG5naW54Li4u?= In-Reply-To: References: Message-ID: <106741306.DQQ3dQDXOQ@vbart-laptop> On Friday 20 December 2013 16:38:45 Sferg wrote: > Здравствуйте, господа. Подскажите, пожалуйста, каким образом (и вообще, > возможно ли это) сделать так, чтобы в access.log писалась полная строчка > запроса? Сейчас переменная $request выводит: > > "GET /index.php HTTP/1.1" Это и есть полная строка запроса. > > А хотелось бы, чтоб выводила нечто вроде этого: > > "GET http://example.com/index.php HTTP1.1" > > Для того, чтобы знать, куда именно ходит пользователь или бот, например, на > http или на https и т.д. В большинстве случаев эта информация в http запросе не передается. Но вы можете воспользоваться переменной $scheme. -- Валентин Бартенев From nginx-forum at nginx.us Sat Dec 21 20:59:45 2013 From: nginx-forum at nginx.us (Helg) Date: Sat, 21 Dec 2013 15:59:45 -0500 Subject: =?UTF-8?B?0J3QtSDRgNCw0LHQvtGC0LDQtdGCIHVwc3RyZWFtIGtlZXBhbGl2ZSDQsiDRgdCy?= =?UTF-8?B?0Y/Qt9C60LUg0YEgZmFzdGNnaS1jINCx0Y3QutGN0L3QtNC+0Lw=?= Message-ID: Здравствуйте. У меня не работает upstream keepalive в связке с fastcgi-c бэкэндом. libfcgi - 2.4 nginx - 1.4.1, 1.5.8 Ubuntu 13.10 x64 Конфиг ngnix`а сделан по документации: upstream test { server 127.0.0.1:12000; keepalive 32; } location / { access_log off; error_log /var/log/nginx/error.log; allow all; fastcgi_keep_conn on; fastcgi_pass test; include fastcgi_params; } Тестирую просто: ab -T application/octet-stream -k -n 10000 -c 1 "http://test.local/" Если закомментировать "keepalive 32" то все работает отлично. Но на каждый запрос создается новое соединение. Это отлично видно по netstat -an | grep 12000 Если же оставить так как выше, то через 5-10 тысяч запросов ab подвисает и отваливается по таймауту. И больше ни одного запроса к бэкэкнду не доходит, до рестарта бэкэнда или nginx. Бэкэнд прост как лапоть (написан с помощью libfcgi): #include "fcgi_stdio.h" #include int count; int main() { count=0; while (FCGI_Accept() >= 0) { printf("Content-type: application/octet-stream\nContent-length: %u\n\n", 0); } return 0; } Вроде тут виснуть нечему. Но виснет. Подскажите, может стакливались с таким? Как чинить. И как продиагностировать, в чем именно проблема? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245757,245757#msg-245757 From mdounin at mdounin.ru Sun Dec 22 10:19:29 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 22 Dec 2013 14:19:29 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiB1cHN0cmVhbSBrZWVwYWxpdmUg0LIg?= =?UTF-8?B?0YHQstGP0LfQutC1INGBIGZhc3RjZ2ktYyDQsdGN0LrRjdC90LTQvtC8?= In-Reply-To: References: Message-ID: <20131222101929.GS95113@mdounin.ru> Hello! On Sat, Dec 21, 2013 at 03:59:45PM -0500, Helg wrote: > У меня не работает upstream keepalive в связке с fastcgi-c бэкэндом. [...] > Вроде тут виснуть нечему. Но виснет. > Подскажите, может стакливались с таким? Как чинить. И как > продиагностировать, в чем именно проблема? У вас бекенд способен обрабатывать не более одного соединения. Если вдруг соединений пытается образоваться больше одного (e.g., запросы начинает обрабатывать другой рабочий процесс) - всё ломается. В документации, кстати, этот момент особо оговорен, http://nginx.org/r/keepalive/ru: : Параметр "соединения" следует устанавливать достаточно : консервативно, чтобы серверы группы по-прежнему могли обрабатывать : новые входящие соединения. Поскольку при наличии хотя бы одного открытого соединения ваш бекенд обрабатывать новые входящие соединения не способен - включать keepalive просто нельзя. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Sun Dec 22 18:24:03 2013 From: nginx-forum at nginx.us (Helg) Date: Sun, 22 Dec 2013 13:24:03 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiB1cHN0cmVhbSBrZWVwYWxpdmUg0LIg?= =?UTF-8?B?0YHQstGP0LfQutC1INGBIGZhc3RjZ2ktYyDQsdGN0LrRjdC90LTQvtC8?= In-Reply-To: <20131222101929.GS95113@mdounin.ru> References: <20131222101929.GS95113@mdounin.ru> Message-ID: <3b0e0735b122e6f44db58d971b47dd6b.NginxMailingListRussian@forum.nginx.org> Ок. Тогда прошу пояснить, как правильно все настроить. Дано: 1. Однопоточный быстрый бэкэнд, который можно запустить в любом количестве копий 2. Сервер с 12 ядрами (24 потока в режиме гиперттединга) 3. Клиент, присылающий запросы в 16 потоков То есть, нужно: - выбрать правильное число воркеров = W - запустить B копий бэкэнда - прописать K в keepalive Помогите пожалуйста. Опишите зависимость между этими числами и как подобрать оптимальный конфиг? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245757,245764#msg-245764 From vadim.lazovskiy at gmail.com Sun Dec 22 19:34:19 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Sun, 22 Dec 2013 23:34:19 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiB1cHN0cmVhbSBrZWVwYWxpdmUg0LIg?= =?UTF-8?B?0YHQstGP0LfQutC1INGBIGZhc3RjZ2ktYyDQsdGN0LrRjdC90LTQvtC8?= In-Reply-To: <3b0e0735b122e6f44db58d971b47dd6b.NginxMailingListRussian@forum.nginx.org> References: <20131222101929.GS95113@mdounin.ru> <3b0e0735b122e6f44db58d971b47dd6b.NginxMailingListRussian@forum.nginx.org> Message-ID: Здравствуйте. Запустите, например 24 инстанса вашего демона на разных портах. Всех их пропишите под один upstream. Метод балансировки least_conn, keepalive выключите. Тогда ваш сервис сможет обслуживать до 24 одновременных соединений, остальные будут ждать. А еще лучше запилить хоть какое-то мультиплексирование на вашем fastcgi-бакенде. 22 декабря 2013 г., 22:24 пользователь Helg написал: > Ок. > Тогда прошу пояснить, как правильно все настроить. > Дано: > 1. Однопоточный быстрый бэкэнд, который можно запустить в любом количестве > копий > 2. Сервер с 12 ядрами (24 потока в режиме гиперттединга) > 3. Клиент, присылающий запросы в 16 потоков > > То есть, нужно: > - выбрать правильное число воркеров = W > - запустить B копий бэкэнда > - прописать K в keepalive > > Помогите пожалуйста. Опишите зависимость между этими числами и как > подобрать > оптимальный конфиг? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,245757,245764#msg-245764 > > _______________________________________________ > 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 Dec 22 20:23:50 2013 From: nginx-forum at nginx.us (Helg) Date: Sun, 22 Dec 2013 15:23:50 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiB1cHN0cmVhbSBrZWVwYWxpdmUg0LIg?= =?UTF-8?B?0YHQstGP0LfQutC1INGBIGZhc3RjZ2ktYyDQsdGN0LrRjdC90LTQvtC8?= In-Reply-To: References: Message-ID: > Запустите, например 24 инстанса вашего демона на разных портах. > Всех их пропишите под один upstream. Метод балансировки least_conn, > keepalive выключите. Да. Но тогда на каждый запрос будет создаваться новое соединение. Этого и хочется избежать. > Тогда ваш сервис сможет обслуживать до 24 одновременных соединений, > остальные будут ждать. В моем тестовом примере клиент посылает запросы последовательно, в один поток. Так что воркер их также последовательно обрабатывает. > А еще лучше запилить хоть какое-то мультиплексирование на вашем > fastcgi-бакенде. Что вы имеете ввиду под мультиплексированием? Очередь и так строится самой библиотекой fastcgi. Каждый вызов FCGI_Accept() забирает из очереди следующий необработанный запрос. Если я хочу обрабатывать два запроса одновременно - я запущу два воркера. Все равно один воркер (без многопоточности) не может обработать более одного запроса одновременно. Так что же еще мультиплексировать? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245757,245768#msg-245768 From nginx-forum at nginx.us Sun Dec 22 20:34:22 2013 From: nginx-forum at nginx.us (Helg) Date: Sun, 22 Dec 2013 15:34:22 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiB1cHN0cmVhbSBrZWVwYWxpdmUg0LIg?= =?UTF-8?B?0YHQstGP0LfQutC1INGBIGZhc3RjZ2ktYyDQsdGN0LrRjdC90LTQvtC8?= In-Reply-To: <20131222101929.GS95113@mdounin.ru> References: <20131222101929.GS95113@mdounin.ru> Message-ID: <829878814217463e43bf569128c0a59d.NginxMailingListRussian@forum.nginx.org> > У вас бекенд способен обрабатывать не более одного соединения. > Если вдруг соединений пытается образоваться больше одного (e.g., > запросы > начинает обрабатывать другой рабочий процесс) - всё ломается. То есть если nginx решает задействовать два воркера и так совпадает, что они оба пытаются установить соединение с бэкэндом, то все виснет, потому что один из воркеров не может подключиться? > Поскольку при наличии хотя бы одного открытого соединения ваш > бекенд обрабатывать новые входящие соединения не способен - > включать keepalive просто нельзя. Под словом "соединение" вы имеете ввиду соединение между nginx и бэкэндом? Интересно, а как сделать бэкэнд, который может работать с включенным keepalive? Есть ли примеры на любом языке программирования? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245757,245769#msg-245769 From nginx-forum at nginx.us Sun Dec 22 20:49:58 2013 From: nginx-forum at nginx.us (Helg) Date: Sun, 22 Dec 2013 15:49:58 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiB1cHN0cmVhbSBrZWVwYWxpdmUg0LIg?= =?UTF-8?B?0YHQstGP0LfQutC1INGBIGZhc3RjZ2ktYyDQsdGN0LrRjdC90LTQvtC8?= In-Reply-To: <829878814217463e43bf569128c0a59d.NginxMailingListRussian@forum.nginx.org> References: <20131222101929.GS95113@mdounin.ru> <829878814217463e43bf569128c0a59d.NginxMailingListRussian@forum.nginx.org> Message-ID: <9c8819ab3b407a0885d783a946c23622.NginxMailingListRussian@forum.nginx.org> > То есть если nginx решает задействовать два воркера и так совпадает, > что они оба пытаются установить соединение с бэкэндом, то все виснет, > потому что один из воркеров не может подключиться? Проверил сейчас. - 1 воркер и 1 бэкэнд - все ок на любом количестве запросов. - 2 воркера и 1 бэкэнд - зависаем практически сразу. - 2 воркера и 2 бэкэнда - зависаем чуть позже. То есть, nginx считает, что бэкэнд должен уметь держаь несколько fastcgi коннектов с ним... Осталось теперь только понять, как объяснить это библиотеке Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245757,245770#msg-245770 From nginx-forum at nginx.us Sun Dec 22 21:24:57 2013 From: nginx-forum at nginx.us (Helg) Date: Sun, 22 Dec 2013 16:24:57 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiB1cHN0cmVhbSBrZWVwYWxpdmUg0LIg?= =?UTF-8?B?0YHQstGP0LfQutC1INGBIGZhc3RjZ2ktYyDQsdGN0LrRjdC90LTQvtC8?= In-Reply-To: <9c8819ab3b407a0885d783a946c23622.NginxMailingListRussian@forum.nginx.org> References: <20131222101929.GS95113@mdounin.ru> <829878814217463e43bf569128c0a59d.NginxMailingListRussian@forum.nginx.org> <9c8819ab3b407a0885d783a946c23622.NginxMailingListRussian@forum.nginx.org> Message-ID: Тихо сам с собой я веду беседу... Нашел решение проблемы. Не скажу, что оно мне нравится, но оно проблему решает. Правда, я думал, что nginx сам разбирается с соединениями до бэкэндов. Ну нет - значит нет. spawn-fcgi -p 12000 -n -- /usr/bin/multiwatch -f 1 ./fcgitest Применение multiwatch позволяет мультиплексировать соединения от nginx к бэкэндам. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245757,245771#msg-245771 From voron at amhost.net Sun Dec 22 21:59:48 2013 From: voron at amhost.net (Alex Vorona) Date: Sun, 22 Dec 2013 23:59:48 +0200 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiB1cHN0cmVhbSBrZWVwYWxpdmUg0LIg?= =?UTF-8?B?0YHQstGP0LfQutC1INGBIGZhc3RjZ2ktYyDQsdGN0LrRjdC90LTQvtC8?= In-Reply-To: References: Message-ID: <52B760D4.5060003@amhost.net> 22.12.2013 22:23, Helg wrote: >> Запустите, например 24 инстанса вашего демона на разных портах. >> Всех их пропишите под один upstream. Метод балансировки least_conn, >> keepalive выключите. > Да. Но тогда на каждый запрос будет создаваться новое соединение. Этого и > хочется избежать. А unix-сокеты уже пробовали использовать и всё равно настолько тяжело создавать соединения? From nginx-forum at nginx.us Sun Dec 22 22:25:59 2013 From: nginx-forum at nginx.us (Helg) Date: Sun, 22 Dec 2013 17:25:59 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiB1cHN0cmVhbSBrZWVwYWxpdmUg0LIg?= =?UTF-8?B?0YHQstGP0LfQutC1INGBIGZhc3RjZ2ktYyDQsdGN0LrRjdC90LTQvtC8?= In-Reply-To: <52B760D4.5060003@amhost.net> References: <52B760D4.5060003@amhost.net> Message-ID: <5901462bac35d1b40bf65466fa85d9f1.NginxMailingListRussian@forum.nginx.org> > А unix-сокеты уже пробовали использовать и всё равно настолько тяжело > создавать соединения? клиент создает минимум 9000 QPS. А может и больше. Бэкэнд вполне такое тянуть может, в него не упираемся. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245757,245773#msg-245773 From nginx-forum at nginx.us Sun Dec 22 23:06:01 2013 From: nginx-forum at nginx.us (Helg) Date: Sun, 22 Dec 2013 18:06:01 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiB1cHN0cmVhbSBrZWVwYWxpdmUg0LIg?= =?UTF-8?B?0YHQstGP0LfQutC1INGBIGZhc3RjZ2ktYyDQsdGN0LrRjdC90LTQvtC8?= In-Reply-To: References: <20131222101929.GS95113@mdounin.ru> <829878814217463e43bf569128c0a59d.NginxMailingListRussian@forum.nginx.org> <9c8819ab3b407a0885d783a946c23622.NginxMailingListRussian@forum.nginx.org> Message-ID: <190efe48bdc1f1b03e005f8e3c8aa3b6.NginxMailingListRussian@forum.nginx.org> > Применение multiwatch позволяет мультиплексировать соединения от nginx > к бэкэндам. Прошу прощения. Поторопился с выводами :( Как только nginx создает больше соединений, чем запущено бэкэндов - все опять виснет. Соединения остаются висеть: tcp 0 0 127.0.0.1:3191 127.0.0.1:12000 ESTABLISHED tcp 1096 0 127.0.0.1:12000 127.0.0.1:3197 ESTABLISHED tcp 1096 0 127.0.0.1:12000 127.0.0.1:3204 ESTABLISHED tcp 0 0 127.0.0.1:12000 127.0.0.1:3140 ESTABLISHED Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245757,245776#msg-245776 From nginx-forum at nginx.us Sun Dec 22 23:48:40 2013 From: nginx-forum at nginx.us (grygory.mos) Date: Sun, 22 Dec 2013 18:48:40 -0500 Subject: Cache Revalidate In-Reply-To: <20131206131642.GN95113@mdounin.ru> References: <20131206131642.GN95113@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- >если ревалидация не проходит - элемент кеша не будет > удалён/заменён, а будет продолжать использоваться для других > пользователей. Будет очень полезно, если бекенд сможет через HTTP хедеры управлять, настройкой cache_use_stale, можно сделать так же как в HTTP спецификации, хедер Cache-Control: must-revalidate, запрещает использовать устаревший ответ и отменяет директиву stale если она была. Это нужно для того чтобы можно было разделить правило use_stale для залогиненых и анонимных запросов, т.е для страниц которые мы генерируем для аноним юзеров будет применятся правило из конфига Nginx cache_use_stale error updating, а страницы которые генерятся только для залогиненых (у них отдельный юрл) юзеров будет отдаватся хедер Cache-Control: must-revalidate, который отменит дериктиву use_stale указанную в конфиге Nginx. Тогда будет возможность использовать use_stale там где можно и отменять там где нужно. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245779#msg-245779 From snar at snar.spb.ru Mon Dec 23 08:51:59 2013 From: snar at snar.spb.ru (Alexandre Snarskii) Date: Mon, 23 Dec 2013 12:51:59 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiB1cHN0cmVhbSBrZWVwYWxpdmUg0LIg?= =?UTF-8?B?0YHQstGP0LfQutC1INGBIGZhc3RjZ2ktYyDQsdGN0LrRjdC90LTQvtC8?= In-Reply-To: <5901462bac35d1b40bf65466fa85d9f1.NginxMailingListRussian@forum.nginx.org> References: <52B760D4.5060003@amhost.net> <5901462bac35d1b40bf65466fa85d9f1.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131223085159.GA57770@snar.spb.ru> On Sun, Dec 22, 2013 at 05:25:59PM -0500, Helg wrote: > > А unix-сокеты уже пробовали использовать и всё равно настолько тяжело > > создавать соединения? > > клиент создает минимум 9000 QPS. А может и больше. > Бэкэнд вполне такое тянуть может, в него не упираемся. Если у вас в качестве прокладки между nginx и fcgi используется Linux - вы вполне можете упираться в Linux. Я, по крайней мере, когда-то упирался: http://www.lexa.ru/nginx-ru/msg38305.html тогда всё решилось именно переходом на unix domain sockets (в которых на уровне библиотеки есть "авторазлипалка", READABLE_UNIX_FD_DROP_DEAD_TIMEVAL). -- In theory, there is no difference between theory and practice. But, in practice, there is. From nginx-forum at nginx.us Mon Dec 23 09:21:17 2013 From: nginx-forum at nginx.us (xiaojie) Date: Mon, 23 Dec 2013 04:21:17 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiB1cHN0cmVhbSBrZWVwYWxpdmUg0LIg?= =?UTF-8?B?0YHQstGP0LfQutC1INGBIGZhc3RjZ2ktYyDQsdGN0LrRjdC90LTQvtC8?= In-Reply-To: References: Message-ID: <665a2763a0c0e56ed0220331abcea6bc.NginxMailingListRussian@forum.nginx.org> Nike manufactured a big UK Cheap Nike Blazers Sale Online Wholesale Nike free run menBlazer Nike field shoes and boots turned out with 1985, along with the relax is usually heritage. Jordans on-court achievements in addition to astounding attractiveness journey judge served them build this Nike blazers model. After that Nike possesses produced 1 unique References: <50f2f422c6f661b7024daea4b4b6936f.NginxMailingListRussian@forum.nginx.org> Message-ID: <6011921.NMjWgYdWAm@vbart-laptop> On Tuesday 24 December 2013 10:56:01 bodomic wrote: > Всем привет, > > Nginx-1.2.9 и 1.4.4 не выставляет Last-Modified заголовок, причём только для > js-файлов. Из-за этого клиент всегда получает статус 200 и всегда качает > скрипты заново. > Стили и картинки, выданные из того же локейшна того же сервера, получают > заголовок Last-Modified согласно stat, ну и обрабатываются кешем как надо. > Более того, я прочитал про отдельный статус этого заголовка и попробовал его > задать через add_header. Он всё равно не появился. > > Конфиг (первый локейшн добавлен специально для экспериментов): > location /js/j.js { > root /opt/project/www/static; > add_header 'Last-Modified' $time_iso8601; > expires 15m; > } > > location / { > root /opt/project/www/static; > expires 15m; > } > > Выше в конфиге ничего не делается с заголовками или кешами, но скажите, что > показать, я покажу. > [..] Покажите конфиг для начала, и nginx -V на всякий случай. -- Валентин Бартенев http://nginx.com/ From nginx-forum at nginx.us Tue Dec 24 16:33:08 2013 From: nginx-forum at nginx.us (proforg) Date: Tue, 24 Dec 2013 11:33:08 -0500 Subject: =?UTF-8?B?UmU6IGRlYnVnIHBvaW50cyBhYm9ydCwg0YfRgtC+INC00LXQu9Cw0YLRjCDRgSA=?= =?UTF-8?B?0LrQvtGA0LrQsNC80Lg=?= In-Reply-To: <20131202135059.GW93176@mdounin.ru> References: <20131202135059.GW93176@mdounin.ru> Message-ID: Спасибо, патч помог! Не могли бы вы включить его в официальную версию? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245088,245809#msg-245809 From nginx-forum at nginx.us Tue Dec 24 17:27:16 2013 From: nginx-forum at nginx.us (bodomic) Date: Tue, 24 Dec 2013 12:27:16 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0LLRi9GB0YLQsNCy0LvRj9C10YLRgdGPIExhc3QtbW9kaWZpZWQg?= =?UTF-8?B?0LTQu9GPIGpzLdGE0LDQudC70L7Qsg==?= In-Reply-To: <6011921.NMjWgYdWAm@vbart-laptop> References: <6011921.NMjWgYdWAm@vbart-laptop> Message-ID: <456c0a1ca1f554d32bfff5f08c870c2a.NginxMailingListRussian@forum.nginx.org> Проглядел конфиг ещё раз, может быть, это всё из-за ssi? Впрочем, вот он. # nginx_new -V nginx version: nginx/1.2.9 built by gcc 4.4.5 (Debian 4.4.5-8) TLS SNI support enabled configure arguments: --prefix=/ --sbin-path=/usr/sbin/nginx_new --conf-path=/etc/nginx_new/nginx_new.conf --pid-path=/var/run/nginx_new.pid --lock-path=/var/lock/nginx_new.lock --error-log-path=/var/log/nginx_new/error.log --http-log-path=/var/log/nginx_new/access.log --user=www-data --group=www-data --with-http_ssl_module --with-http_realip_module --with-http_gzip_static_module --with-http_image_filter_module --with-pcre=../../libs/pcre-8.31 --with-pcre-jit --with-zlib=../../libs/zlib-1.2.7 --with-openssl=../../libs/openssl-1.0.1c --http-client-body-temp-path=/var/lib/nginx_new/body --http-proxy-temp-path=/var/lib/nginx_new/proxy --http-fastcgi-temp-path=/var/lib/nginx_new/fastcgi --http-uwsgi-temp-path=/var/lib/nginx_new/uwsgi-temp --http-scgi-temp-path=/var/lib/nginx_new/scgi-temp --with-http_dav_module --with-http_stub_status_module --with-http_geoip_module --with-http_flv_module --with-http_mp4_module --add-module=../../libs/nginx_mogilefs_module-1.0.4 --add-module=../../libs/ngx_devel_kit-0.2.18 --with-http_secure_link_module --add-module=../../libs/lua-nginx-module-0.8.0 --add-module=../../libs/redis2-nginx-module-0.10 --add-module=../../libs/echo-nginx-module-0.45 #nginx.conf user www-data; worker_processes 8; error_log /var/log/nginx_new/error.log; pid /var/run/nginx_new.pid; worker_priority -10; worker_rlimit_nofile 250000; worker_rlimit_sigpending 32768; events { worker_connections 10240; use epoll; } http { geoip_country /usr/share/GeoIP/GeoIP.dat; geoip_city /usr/share/GeoIP/GeoLiteCity.dat; include /etc/nginx_new/mime.types; default_type application/octet-stream; log_format main '$geoip_country_code $remote_addr - $remote_user [$time_local] ' '"$request" $request_time $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '"$http_cookie" $http_host'; access_log off; server_tokens off; client_max_body_size 20m; client_header_timeout 30s; client_body_timeout 30s; send_timeout 30; client_header_buffer_size 4k; large_client_header_buffers 8 8k; output_buffers 256 128k; postpone_output 1460; keepalive_timeout 10; sendfile on; tcp_nopush on; tcp_nodelay on; ssi on; ssi_types text/xml application/x-javascript; open_file_cache max=20000 inactive=80s; open_file_cache_valid 20s; open_file_cache_min_uses 8; open_file_cache_errors on; gzip on; gzip_comp_level 4; gzip_disable "MSIE [1-6]\."; gzip_buffers 32 8k; gzip_min_length 1024; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml application/xml+rss image/x-icon; reset_timedout_connection on; recursive_error_pages on; map $hostname $numfront { ~(?\d+$) $s; default 0; } add_header X-Frontend $numfront; proxy_read_timeout 60; proxy_send_timeout 60; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Frontend $hostname; proxy_temp_path /var/lib/nginx_new/proxy_temp 1 2; root /var/www/nginx-default/; include /etc/nginx_new/conf.d/*.conf; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245807,245810#msg-245810 From nginx-forum at nginx.us Tue Dec 24 17:30:32 2013 From: nginx-forum at nginx.us (bodomic) Date: Tue, 24 Dec 2013 12:30:32 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0LLRi9GB0YLQsNCy0LvRj9C10YLRgdGPIExhc3QtbW9kaWZpZWQg?= =?UTF-8?B?0LTQu9GPIGpzLdGE0LDQudC70L7Qsg==?= In-Reply-To: <456c0a1ca1f554d32bfff5f08c870c2a.NginxMailingListRussian@forum.nginx.org> References: <6011921.NMjWgYdWAm@vbart-laptop> <456c0a1ca1f554d32bfff5f08c870c2a.NginxMailingListRussian@forum.nginx.org> Message-ID: <7a1d12be2763870b6373f656dce9eb64.NginxMailingListRussian@forum.nginx.org> Точно!! Думаю, вопрос закрыт, а мне надо подумать о версиях 1.5.*, хотя рановато, конечно, для продакшна. :( syntax: ssi_last_modified on | off; default: ssi_last_modified off; context: http, server, location This directive appeared in version 1.5.1. Allows preserving the ?Last-Modified? header field from the original response during SSI processing to facilitate response caching. By default, the header field is removed as contents of the response are modified during processing and may contain dynamically generated elements or parts that are changed independently of the original response. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245807,245811#msg-245811 From vbart at nginx.com Tue Dec 24 18:05:43 2013 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 24 Dec 2013 22:05:43 +0400 Subject: =?UTF-8?B?UmU6INCd0LUg0LLRi9GB0YLQsNCy0LvRj9C10YLRgdGPIExhc3QtbW9kaWZpZWQg?= =?UTF-8?B?0LTQu9GPIGpzLdGE0LDQudC70L7Qsg==?= In-Reply-To: <7a1d12be2763870b6373f656dce9eb64.NginxMailingListRussian@forum.nginx.org> References: <6011921.NMjWgYdWAm@vbart-laptop> <456c0a1ca1f554d32bfff5f08c870c2a.NginxMailingListRussian@forum.nginx.org> <7a1d12be2763870b6373f656dce9eb64.NginxMailingListRussian@forum.nginx.org> Message-ID: <4946246.qGgAhGUpSx@vbart-laptop> On Tuesday 24 December 2013 12:30:32 bodomic wrote: > Точно!! > Думаю, вопрос закрыт, а мне надо подумать о версиях 1.5.*, хотя рановато, > конечно, для продакшна. :( [..] Основная ветка (1.5.x) предназначена для продакшена ни чуть не меньше. Вот устаревшую и уязвимую 1.2.9 давно необходимо обновить. http://nginx.org/en/security_advisories.html -- Валентин Бартенев http://nginx.com/ From nginx-forum at nginx.us Tue Dec 24 19:40:09 2013 From: nginx-forum at nginx.us (glagola) Date: Tue, 24 Dec 2013 14:40:09 -0500 Subject: =?UTF-8?B?0KHRgtGA0LDQvdC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUgbGltaXQgY29ubg==?= Message-ID: <8b8d60bc016500f42f06ebd825672bd3.NginxMailingListRussian@forum.nginx.org> Всем привет, я пытаюсь ограничить кол-во соединений с одного ip к одному location. Как гласит документация, это можно сделать с помощью limit_conn. Вот мой конфиг http { limit_conn_zone $binary_remote_addr zone=addr:10m; ... server { ... location ~* "^/d/" { limit_conn addr 1; limit_rate 128k; } ... } ... } Все бы хорошо, но если параллельно в браузере в двух вкладках обратиться к файлу из этого location'а, то по одному запросу начнется скачка, а другой будет ждать пока завершиться первый и как только он завершиться, файл начнет скачиваться по второму запросу. Это весьма странное поведение, т.к. в документации сказано, что второй запрос должен отвалиться с 503 ошибкой. Версия nginx 1.2.1. Что я делаю не так? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245814,245814#msg-245814 From vbart at nginx.com Tue Dec 24 19:52:03 2013 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 24 Dec 2013 23:52:03 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IGxpbWl0IGNv?= =?UTF-8?B?bm4=?= In-Reply-To: <8b8d60bc016500f42f06ebd825672bd3.NginxMailingListRussian@forum.nginx.org> References: <8b8d60bc016500f42f06ebd825672bd3.NginxMailingListRussian@forum.nginx.org> Message-ID: <2078585.zMUhnVQRN9@vbart-laptop> On Tuesday 24 December 2013 14:40:09 glagola wrote: > Всем привет, я пытаюсь ограничить кол-во соединений с одного ip к одному > location. Как гласит документация, это можно сделать с помощью limit_conn. > > Вот мой конфиг > http { > limit_conn_zone $binary_remote_addr zone=addr:10m; > ... > server { > ... > location ~* "^/d/" { > limit_conn addr 1; > limit_rate 128k; > } > ... > } > ... > } > > Все бы хорошо, но если параллельно в браузере в двух вкладках обратиться к > файлу из этого location'а, то по одному запросу начнется скачка, а другой > будет ждать пока завершиться первый и как только он завершиться, файл начнет > скачиваться по второму запросу. Это весьма странное поведение, т.к. в > документации сказано, что второй запрос должен отвалиться с 503 ошибкой. > > Версия nginx 1.2.1. Скорее всего nginx тут вообще не причем, ваш браузер, перед тем как послать отправить второй запрос, ожидает завершения первого. > Что я делаю не так? Используете для проверки конфигурации веб-сервера такой сложный инструмент со своей непрозрачной логикой, как браузер. -- Валентин Бартенев http://nginx.com/ From nginx-forum at nginx.us Tue Dec 24 19:59:35 2013 From: nginx-forum at nginx.us (glagola) Date: Tue, 24 Dec 2013 14:59:35 -0500 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IGxpbWl0IGNv?= =?UTF-8?B?bm4=?= In-Reply-To: <2078585.zMUhnVQRN9@vbart-laptop> References: <2078585.zMUhnVQRN9@vbart-laptop> Message-ID: <78eab047f1379985b5b33262e32eed23.NginxMailingListRussian@forum.nginx.org> Попробовал через curl - Вы абсолютно правы, все дело в браузере! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245814,245817#msg-245817 From info at monumente-funerare.md Wed Dec 25 09:31:53 2013 From: info at monumente-funerare.md (=?koi8-r?B?7cHL08nNIO/Tz9HO?=) Date: Wed, 25 Dec 2013 11:31:53 +0200 Subject: =?UTF-8?B?0JjRgdC60LvRjtGH0LXQvdC40Y8g0LjQtyDRgNC10LTQuNGA0LXQutGC0LAh?= Message-ID: С Рождеством, уважаемые! Возникла проблема. Установлен редирект с Http на Https. Требуется из этого редиректа исключить один файл - обращение к крону. Перелопатил многое, но похожих примеров не нашел. Собственно - редирект такой: if ( $scheme = "http" ) { rewrite ^/(.*)$ https://$host/$1 permanent; } Исключить из него нужно вот такой файлик - site.example.md/cron.php Подскажите пожалуйста как это правильно сделать?! From wangsamp at gmail.com Wed Dec 25 09:35:42 2013 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Wed, 25 Dec 2013 11:35:42 +0200 (EET) Subject: =?UTF-8?B?UmU6INCY0YHQutC70Y7Rh9C10L3QuNGPINC40Lcg0YDQtdC00LjRgNC10LrRgtCw?= =?UTF-8?B?IQ==?= In-Reply-To: References: Message-ID: Today Dec 25, 2013 at 11:31 Максим Осоян wrote: > if ( $scheme = "http" ) { > rewrite ^/(.*)$ https://$host/$1 permanent; > } > > Исключить из него нужно вот такой файлик - site.example.md/cron.php > > Подскажите пожалуйста как это правильно сделать?! Прописать location /cron.php без rewrite. -- WNGS-RIPE From shadow at ekb-lug.ru Wed Dec 25 09:48:20 2013 From: shadow at ekb-lug.ru (Shadow) Date: Wed, 25 Dec 2013 15:48:20 +0600 Subject: =?UTF-8?B?UmU6INCY0YHQutC70Y7Rh9C10L3QuNGPINC40Lcg0YDQtdC00LjRgNC10LrRgtCw?= =?UTF-8?B?IQ==?= In-Reply-To: References: Message-ID: Коли вы с какой-то целью пользуетесь if'ом, то можно в него же и добавить условие. 25 декабря 2013 г., 15:31 пользователь Максим Осоян написал: > С Рождеством, уважаемые! > > Возникла проблема. > Установлен редирект с Http на Https. Требуется из этого редиректа исключить один файл - обращение к крону. > Перелопатил многое, но похожих примеров не нашел. > Собственно - редирект такой: > > if ( $scheme = "http" ) { > rewrite ^/(.*)$ https://$host/$1 permanent; > } > > Исключить из него нужно вот такой файлик - site.example.md/cron.php > > Подскажите пожалуйста как это правильно сделать?! > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Доб From info at monumente-funerare.md Wed Dec 25 10:15:56 2013 From: info at monumente-funerare.md (=?koi8-r?B?7cHL08nNIO/Tz9HO?=) Date: Wed, 25 Dec 2013 12:15:56 +0200 Subject: =?UTF-8?B?UmU6INCY0YHQutC70Y7Rh9C10L3QuNGPINC40Lcg0YDQtdC00LjRgNC10LrRgtCw?= =?UTF-8?B?IQ==?= In-Reply-To: References: Message-ID: Я в этом не силен, простите. Была задача реализовать редирект на https, но в моем случае, этот редирект мешает выполнению задач из упомянутого файла. Если можно, конкретный пример. 25 дек. 2013 г., в 11:48, Shadow написал(а): > Коли вы с какой-то целью пользуетесь if'ом, то можно в него же и > добавить условие. > > 25 декабря 2013 г., 15:31 пользователь Максим Осоян > написал: >> С Рождеством, уважаемые! >> >> Возникла проблема. >> Установлен редирект с Http на Https. Требуется из этого редиректа исключить один файл - обращение к крону. >> Перелопатил многое, но похожих примеров не нашел. >> Собственно - редирект такой: >> >> if ( $scheme = "http" ) { >> rewrite ^/(.*)$ https://$host/$1 permanent; >> } >> >> Исключить из него нужно вот такой файлик - site.example.md/cron.php >> >> Подскажите пожалуйста как это правильно сделать?! >> _______________________________________________ >> 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 zmey1992 at ya.ru Wed Dec 25 10:30:53 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Wed, 25 Dec 2013 14:30:53 +0400 Subject: =?UTF-8?B?UmU6INCY0YHQutC70Y7Rh9C10L3QuNGPINC40Lcg0YDQtdC00LjRgNC10LrRgtCw?= =?UTF-8?B?IQ==?= In-Reply-To: References: Message-ID: <243181387967453@web9h.yandex.ru> Я бы сделал отдельный server для редиректа и в целом это выглядело бы вот так: server { listen 80; server_name example.com; return 301 https://example.com$request_uri; location = /cron.php { # ...something... } } 25.12.2013, 14:16, "Максим Осоян" : > Я в этом не силен, простите. > Была задача реализовать редирект на https, но в моем случае, этот редирект мешает выполнению задач из упомянутого файла. > Если можно, конкретный пример. > > 25 дек. 2013 г., в 11:48, Shadow написал(а): > >>  Коли вы с какой-то целью пользуетесь if'ом, то можно в него же и >>  добавить условие. >> >>  25 декабря 2013 г., 15:31 пользователь Максим Осоян >>   написал: >>>  С Рождеством, уважаемые! >>> >>>  Возникла проблема. >>>  Установлен редирект с Http на Https. Требуется из этого редиректа исключить один файл - обращение к крону. >>>  Перелопатил многое, но похожих примеров не нашел. >>>  Собственно - редирект такой: >>> >>>  if ( $scheme = "http" ) { >>>  rewrite ^/(.*)$ https://$host/$1 permanent; >>>  } >>> >>>  Исключить из него нужно вот такой файлик - site.example.md/cron.php >>> >>>  Подскажите пожалуйста как это правильно сделать?! >>>  _______________________________________________ >>>  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 nginx-forum at nginx.us Wed Dec 25 11:54:56 2013 From: nginx-forum at nginx.us (bodomic) Date: Wed, 25 Dec 2013 06:54:56 -0500 Subject: =?UTF-8?B?UmU6INCd0LUg0LLRi9GB0YLQsNCy0LvRj9C10YLRgdGPIExhc3QtbW9kaWZpZWQg?= =?UTF-8?B?0LTQu9GPIGpzLdGE0LDQudC70L7Qsg==?= In-Reply-To: <4946246.qGgAhGUpSx@vbart-laptop> References: <4946246.qGgAhGUpSx@vbart-laptop> Message-ID: Спасибо! Обновим. Я пока прописал ssi_types без javascript там, где нужно, так что получилось и на текущих версиях. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245807,245827#msg-245827 From mdounin at mdounin.ru Wed Dec 25 13:58:31 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 25 Dec 2013 17:58:31 +0400 Subject: =?UTF-8?B?UmU6IGRlYnVnIHBvaW50cyBhYm9ydCwg0YfRgtC+INC00LXQu9Cw0YLRjCDRgSA=?= =?UTF-8?B?0LrQvtGA0LrQsNC80Lg=?= In-Reply-To: References: <20131202135059.GW93176@mdounin.ru> Message-ID: <20131225135831.GT95113@mdounin.ru> Hello! On Tue, Dec 24, 2013 at 11:33:08AM -0500, proforg wrote: > Спасибо, патч помог! > Не могли бы вы включить его в официальную версию? Пожалуйста, спасибо за тестирование. У меня по этому патчу ещё есть пара вопросов про часть, относящуюся к client_body_in_file_only, как будет время - подрихтую и закоммичу. -- Maxim Dounin http://nginx.org/ From johnbat26 at gmail.com Thu Dec 26 07:28:56 2013 From: johnbat26 at gmail.com (=?utf-8?B?0JHQsNGC0L7Qs9C+0LIg0JXQstCz0LXQvdC40Lk=?=) Date: Thu, 26 Dec 2013 11:28:56 +0400 Subject: Nginx worker 100% CPU: SIGALRM/rt_sigreturn loop Message-ID: <6360054.JXpYC2ld6o@dragon> Привет всем. У нас подвисает nginx worker и потребляет 100% СPU. stace показывает следующее: ... rt_sigreturn(0xe) = 2 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 165986344 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 1510 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 108 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 5 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 3 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 856814698 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 6 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 4 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 11 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 15 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 7 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 13 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 12 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = 15 ... В чём может быть причина? From nginx-forum at nginx.us Thu Dec 26 07:45:55 2013 From: nginx-forum at nginx.us (wsl5shuai) Date: Thu, 26 Dec 2013 02:45:55 -0500 Subject: Burgess Message-ID: <61f92e0244da69bcbcf6f695c61d2950.NginxMailingListRussian@forum.nginx.org> fagsdagdfahfdafsafas Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245841,245841#msg-245841 From nginx-forum at nginx.us Thu Dec 26 07:52:32 2013 From: nginx-forum at nginx.us (thritcasketfcont1986) Date: Thu, 26 Dec 2013 02:52:32 -0500 Subject: countries the place stun guns will be restricted Message-ID: Find some good wholesale nhl jerseys it? Baseball shirt is definitely growing within popularity all over the world, because it is any bet with a soccer addresses. The world of soccer fanatics are likely to buy hockey shirts, they'll have to declare your specific international team or even football group, and put straight into practice sports shirt lovers, they really assume they may prefer holding the team maybe in some way perhaps many others. A lot of shirt is identically as qualified football players have on on the floor, so you'll find soccer shirts might cost you significantly effort, the corporation has been created, whilst a few include these nfl jerseys extra money. Following regular year or so , can't graphic Celtics will expend all their chance to earn the 1st title , of course , they have covered with insurance the playoff location . Depends on its veteran , some people were expecting their excellent playoff performance . Wholesale jerseys cina you will for instance .. General soccer jersey can certainly end up being your own greatest usage if you want to be able to depict your own personal nature for virtually any sport action. Start of online games or simply universe coffee mug is definitely an exceptionally fascinating immediate for any basketball buffs since they obtain a chance to obtain the china soccer hat. That outlets that are bound to relieve that buyers within receiving lowpriced soccer Cheap Little league Uniforms in an exceedingly effortless approach have finally turn out to be cyber valuable.. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245842,245842#msg-245842 From vovansystems at gmail.com Thu Dec 26 09:17:16 2013 From: vovansystems at gmail.com (VovansystemS) Date: Thu, 26 Dec 2013 12:17:16 +0300 Subject: =?UTF-8?B?0LrQsNC6INC70YPRh9GI0LUg0YPQv9GA0LDQstC70Y/RgtGMINC60LXRiNC40YA=?= =?UTF-8?B?0L7QstCw0L3QuNC10LwgZmFzdGNnaV9jYWNoZQ==?= Message-ID: Добрый день, скажите, пожалуйста, каким образом правильнее в nginx 1.5.x + php5-fpm (chroot): 1. выставлять разные параметры кеширования для различных локейшнов, при использовании CMS на основе kohana (всё реврайтится на index.php)? сейчас я делаю это через if и $request_uri. 2. Есть ли смысл в ключе кеширования указывать также "$http_if_modified_since|$http_if_none_match|"? Etag будет одинаковый для некоторого числа запросов, а вот $http_if_modified_since просто будет плодить элементы кэша, но работать они будут тогда, когда два таких запроса придут в одну и ту же секунду? Сейчас использую примерно вот такой конфиг - как лучше его переписать: fastcgi_cache_path /run/shm/MAIN levels=1:2 keys_zone=MAIN:64m max_size=100m inactive=240h; server { listen 80; server_name domain.com; charset utf-8; error_log /var/log/nginx/domain.error.log error; access_log /var/log/nginx/domain.access.log; root /home/user/domain.com/public_html/; set $no_cache 0; if ($request_method = POST) { set $no_cache 1; # не кешируем POST } if ($https = on) { set $no_cache 1; # не кешируем https } if ($query_string != "") { set $no_cache 0; # кешируем страницы с аргументами } if ($request_uri ~* "^/admin(/?.*)$") { set $no_cache 1; # не кешируем админку } if ($request_uri ~* "^/search/(.*)$") { set $no_cache 1; # не кешируем поиск } # не кешируем, если есть такие куки if ($http_cookie ~* "auth_user|login|comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") { set $no_cache 1; } location / { rewrite ^/(.*)/$ /$1 redirect; # все ури должны быть без слэша на конце try_files $uri /index.php$is_args$args; } location = /index.php { include fastcgi_params; fastcgi_pass 127.0.0.1:9001; fastcgi_intercept_errors on; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /public_html/index.php; fastcgi_param DOCUMENT_ROOT /public_html; fastcgi_param KOHANA_ENV production; # если $no_cache отличен от нуля, отдаём некешированную страницу fastcgi_cache_bypass $no_cache; fastcgi_no_cache $no_cache; # ревалидируем элемент кэша при помощи условных запросов с полем заголовка "If-Modified-Since" fastcgi_cache_revalidate on; fastcgi_temp_path /run/shm/fcgi 1 2; fastcgi_cache MAIN; fastcgi_cache_key "$scheme|$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; fastcgi_ignore_headers "Cache-Control" "Expires" "Set-Cookie"; fastcgi_cache_min_uses 1; fastcgi_cache_valid 1h; fastcgi_cache_valid any 10s; fastcgi_cache_use_stale updating error timeout invalid_header http_500; # отдаём устаревший закешированный ответ в этих случаях } # все остальные .php файлы location ~* \.php$ { return 403; } # статика location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|docx)$ { expires 60d; access_log off; } } From mdounin at mdounin.ru Thu Dec 26 12:29:09 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 26 Dec 2013 16:29:09 +0400 Subject: =?UTF-8?B?UmU6INC60LDQuiDQu9GD0YfRiNC1INGD0L/RgNCw0LLQu9GP0YLRjCDQutC10Yg=?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQtdC8IGZhc3RjZ2lfY2FjaGU=?= In-Reply-To: References: Message-ID: <20131226122902.GZ95113@mdounin.ru> Hello! On Thu, Dec 26, 2013 at 12:17:16PM +0300, VovansystemS wrote: > Добрый день, > > скажите, пожалуйста, каким образом правильнее в nginx 1.5.x + php5-fpm (chroot): > > 1. выставлять разные параметры кеширования для различных локейшнов, > при использовании CMS на основе kohana (всё реврайтится на index.php)? > сейчас я делаю это через if и $request_uri. Лучше - по возможности избегать использование if'ов и rewrite'ов. Если нужна обработка одним и тем же index.php, то в нужных location'ах явно указывать SCRIPT_FILENAME. > 2. Есть ли смысл в ключе кеширования указывать также > "$http_if_modified_since|$http_if_none_match|"? Etag будет одинаковый > для некоторого числа запросов, а вот $http_if_modified_since просто > будет плодить элементы кэша, но работать они будут тогда, когда два > таких запроса придут в одну и ту же секунду? Нет. При кешировании заголовки If-Modified-Since и If-None-Match на бекенд не передаются (за исключением ревалидации кеша самим nginx'ом), так что в ключе их указывать бессмысленно и может принести лишь проблемы. Ну и да, см. http://nginx.org/r/proxy_cache_revalidate/ru. [...] -- Maxim Dounin http://nginx.org/ From mdounin at mdounin.ru Thu Dec 26 12:39:45 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 26 Dec 2013 16:39:45 +0400 Subject: Nginx worker 100% CPU: SIGALRM/rt_sigreturn loop In-Reply-To: <6360054.JXpYC2ld6o@dragon> References: <6360054.JXpYC2ld6o@dragon> Message-ID: <20131226123945.GA95113@mdounin.ru> Hello! On Thu, Dec 26, 2013 at 11:28:56AM +0400, Батогов Евгений wrote: > Привет всем. > > У нас подвисает nginx worker и потребляет 100% СPU. > stace показывает следующее: > ... > rt_sigreturn(0xe) = 2 > --- SIGALRM (Alarm clock) @ 0 (0) --- > rt_sigreturn(0xe) = 165986344 > --- SIGALRM (Alarm clock) @ 0 (0) --- [...] > В чём может быть причина? Причина может быть чуть менее, чем в чём угодно. SIGALARM - скорее всего не имеет отношения к проблеме, он используется для обновления времени, если в конфиге используется директива timer_resolution. Что показывает nginx -V, что в конфиге, что в логах, где крутится код ("gdb /path/to/nginx " и далее походить)? Ну и на всякий случай я оставлю эту ссылку здесь: http://wiki.nginx.org/Debugging -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Thu Dec 26 12:44:52 2013 From: nginx-forum at nginx.us (sofiamay) Date: Thu, 26 Dec 2013 07:44:52 -0500 Subject: =?UTF-8?B?0J/RgNC10LTQu9C+0LbQtdC90LjQtTog0J7Qs9GA0LDQvdC40YfQtdC90LjQtSA=?= =?UTF-8?B?0YHQutC+0YDQvtGB0YLQuCDQtNC70Y8gSVAvSG9zdC9Mb2NhdGlvbg==?= Message-ID: <8cc20db733f183710925362425274995.NginxMailingListRussian@forum.nginx.org> Всем привет, Прошло столько лет, а воз и ныне там. Nginx до сих пор не умеет управлять скоростью отдачи ответа, кроме как limit_rate per connection, даже не per ip. Я предлагаю расширить управления скоростями. Это вопрос в частности к Максиму Дунину и всем кто имеет отношение к развитию Nginx. На данный момент Nginx в плане балансировки и ограничения скоростей по сути ничего предложить не может, почти. Всё что предлагается сейчас это limit_rate per connection (не для ip), т.е. ограничение отдачи ответа для каждого соединения, что по сути малополезно и используется в основном с limit_conn. Суть моего предложения Для начала хочу сказать что я понятия не имею как устроено всё внутри, но предполагаю что так - при установке соединения nginx проверяет установлен ли limit_rate для текущего location и если да то отправляет ответ порциями по "n" килобайт в секунду для текущего подключения. Так вот я предлагаю ввести такие понятия (по ограничению скорости) как: 1) Ограничение скорости отдачи на коннект (per Conn) - limit_rate уже есть, отлично; 2) Ограничение скорости отдачи на IP (per IP). Поясняю, даже если юзер создал 10 коннектов, то всё равно он получит заданную скорость. Как это реализовать? Пускай Nginx отдает килобайты не по формуле "n" килобайт в секунду, как в случае limit_rate, а пускай он отдаёт заветные килобайты по формуле ("n" килобайт / count (IP connections)) в секунду, т.е. пускай сервер математически делит лимит еще и на количество текущих коннектов с этого IP. Это же так просто реализовать - подсчёт текущих коннектов с одного ip (уже сделано в модуле limit_conn с его zone $binary_remote_addr). 3) Ограничение скорости отдачи на хост (per Host). Поясняю, даже если 10 юзеров одновременно качают файлы, то всё равно он получат заданную скорость делённую на них всех. Как это реализовать? Пускай Nginx отдает килобайты не по формуле "n" килобайт в секунду, как в случае limit_rate, а пускай он отдаёт заветные килобайты по формуле ("n" килобайт / count (connections per host)) в секунду, т.е. пускай сервер математически делит лимит еще и на количество текущих коннектов к хосту. Это же так просто реализовать - подсчёт текущих коннектов к хосту (например через zone $host). 4) Ограничение скорости отдачи на локейшен (per URL). Поясняю, даже если 10 юзеров одновременно качают файлы из папки /limit_download/, то всё равно он получат заданную скорость для это локейшена, делённую на них всех. Как это реализовать? Пускай Nginx отдает килобайты не по формуле "n" килобайт в секунду, как в случае limit_rate, а пускай он отдаёт заветные килобайты по формуле ("n" килобайт / count (connections per md5($request_uri))) в секунду, т.е. пускай сервер математически делит лимит еще и на количество текущих коннектов к локейшену. Это же так просто реализовать - подсчёт текущих коннектов к хосту (например через zone $request_uri). А чтобы зона не была в сотни мегабайт лучше хранить md5($request_uri)... и вообще когда наконец сделаете в конфиге Nginx поддержку md5, уже надоело юзать perl module для этих целей! На мой взгляд, дописать формулы расчета скорости в функции отправки ответа, да ввести парочку переменных в конфиг, а по сути сделать 3 маленьких модуля за много лет уже можно было а? Я жду этих скоростных лимитов в Nginx уже мноооого лет... Да и вообще как-то он слабо развивается, совсем не в ту сторону которая нужна большинству пользователей. На мой взгляд такие элементарные вещи нужно было реализовывать уже давно, а то сделали limit_conn, limit req и limit rate и на этом всё, типа можешь ограничивать скорости как душа пожелает. Душа как раз таки желает, только управления скоростью в Nginx по сути нет, ограничение на каждый коннект (а не на все коннекты ip адреса) - это для девочек в песочке поиграться. Или то, что я описал, это верх сложности!? Прямо как сделать поддержку UTF-8 в PHP (так и не сделали кстати). Не поверю, потому что сделать нужные счетчики не сложнее чем уже сделано в limit_conn и limit rate. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245848,245848#msg-245848 From e.batogov at cti.ru Thu Dec 26 12:50:13 2013 From: e.batogov at cti.ru (=?utf-8?B?0JHQsNGC0L7Qs9C+0LIg0JXQstCz0LXQvdC40Lk=?=) Date: Thu, 26 Dec 2013 16:50:13 +0400 Subject: Nginx worker 100% CPU: SIGALRM/rt_sigreturn loop In-Reply-To: <20131226123945.GA95113@mdounin.ru> References: <6360054.JXpYC2ld6o@dragon> <20131226123945.GA95113@mdounin.ru> Message-ID: <347037512.j5DDCzcUZq@dragon> ./nginx -V nginx version: nginx/1.4.2 built by gcc 4.1.2 20080704 (Red Hat 4.1.2-54) TLS SNI support disabled configure arguments: --user=nginx --group=nginx --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --with-http_secure_link_module --with-http_random_index_module --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_stub_status_module --with-http_perl_module --with-http_xslt_module --with-debug --with-mail --with-mail_ssl_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ipv6 --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-upstream-fair --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-upload-progress-module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/mod_zip --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx_mod_h264_streaming --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-push-stream-module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx_upstream_hash --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-memcached-hash-pass --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/echo-nginx-module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/ngx_http_gunzip_filter_module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/headers-more-nginx-module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-rewrite-request-body-module Воркер пришлось прибить к сожалению. В письме от 26 декабря 2013 16:39:45 пользователь Maxim Dounin написал: > Hello! > > On Thu, Dec 26, 2013 at 11:28:56AM +0400, Батогов Евгений wrote: > > > Привет всем. > > > > У нас подвисает nginx worker и потребляет 100% СPU. > > stace показывает следующее: > > ... > > rt_sigreturn(0xe) = 2 > > --- SIGALRM (Alarm clock) @ 0 (0) --- > > rt_sigreturn(0xe) = 165986344 > > --- SIGALRM (Alarm clock) @ 0 (0) --- > > [...] > > > В чём может быть причина? > > Причина может быть чуть менее, чем в чём угодно. SIGALARM - скорее > всего не имеет отношения к проблеме, он используется для > обновления времени, если в конфиге используется директива > timer_resolution. > > Что показывает nginx -V, что в конфиге, что в логах, где крутится > код ("gdb /path/to/nginx " и далее походить)? > > Ну и на всякий случай я оставлю эту ссылку здесь: > > http://wiki.nginx.org/Debugging > > -- Best Regards, Eugene Batogov _______________________________________ Software Architect СTI - Communications. Technology. Innovations. Tel: +7 (495) 784-73-13 * 2551 Fax: +7 (495) 784-73-14 e-mail: e.batogov at cti.ru From nginx-forum at nginx.us Thu Dec 26 12:57:58 2013 From: nginx-forum at nginx.us (sofiamay) Date: Thu, 26 Dec 2013 07:57:58 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQtdC00LvQvtC20LXQvdC40LU6INCe0LPRgNCw0L3QuNGH0LXQvdC4?= =?UTF-8?B?0LUg0YHQutC+0YDQvtGB0YLQuCDQtNC70Y8gSVAvSG9zdC9Mb2NhdGlvbg==?= In-Reply-To: <8cc20db733f183710925362425274995.NginxMailingListRussian@forum.nginx.org> References: <8cc20db733f183710925362425274995.NginxMailingListRussian@forum.nginx.org> Message-ID: <55de9a0271e9457bd301fff5a510aeb4.NginxMailingListRussian@forum.nginx.org> Если уж быть совсем точным, то модуль должен быть один, просто чтобы можно было зону строить как угодно. Ограничение скорости отдачи на IP (per IP): zone $binary_remote_addr zone=name limit=200kb/s формула скорости - ("n" килобайт / count (zone name)) Ограничение скорости отдачи на хост (per Host): zone $host zone=name limit=200kb/s формула скорости - ("n" килобайт / count (zone name)) Ограничение скорости отдачи на локейшен (per URL): zone $host$request_uri zone=name limit=200kb/s формула скорости - ("n" килобайт / count (zone name)) Описал своими словами как я это понимаю. Естественно как оно всё внутри устроено разработчикам виднее... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245848,245851#msg-245851 From mdounin at mdounin.ru Thu Dec 26 13:00:07 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 26 Dec 2013 17:00:07 +0400 Subject: Nginx worker 100% CPU: SIGALRM/rt_sigreturn loop In-Reply-To: <347037512.j5DDCzcUZq@dragon> References: <6360054.JXpYC2ld6o@dragon> <20131226123945.GA95113@mdounin.ru> <347037512.j5DDCzcUZq@dragon> Message-ID: <20131226130007.GC95113@mdounin.ru> Hello! On Thu, Dec 26, 2013 at 04:50:13PM +0400, Батогов Евгений wrote: > ./nginx -V > nginx version: nginx/1.4.2 > built by gcc 4.1.2 20080704 (Red Hat 4.1.2-54) > TLS SNI support disabled > configure arguments: --user=nginx --group=nginx --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --with-http_secure_link_module --with-http_random_index_module --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_stub_status_module --with-http_perl_module --with-http_xslt_module --with-debug --with-mail --with-mail_ssl_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ipv6 --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-upstream-fair --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-upload-progress-module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/mod_zip --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx_mod_h264_streaming --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-push-stream-module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx_upstream_hash --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-memcached-hash-pass --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/echo-nginx-module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/ngx_http_gunzip_filter_module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/headers-more-nginx-module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-rewrite-request-body-module > > Воркер пришлось прибить к сожалению. При таком количестве сторонних модулей - в любом случае первую очередь имеет смысл попробовать воспроизвести проблему без них. > > > В письме от 26 декабря 2013 16:39:45 пользователь Maxim Dounin написал: > > Hello! > > > > On Thu, Dec 26, 2013 at 11:28:56AM +0400, Батогов Евгений wrote: > > > > > Привет всем. > > > > > > У нас подвисает nginx worker и потребляет 100% СPU. > > > stace показывает следующее: > > > ... > > > rt_sigreturn(0xe) = 2 > > > --- SIGALRM (Alarm clock) @ 0 (0) --- > > > rt_sigreturn(0xe) = 165986344 > > > --- SIGALRM (Alarm clock) @ 0 (0) --- > > > > [...] > > > > > В чём может быть причина? > > > > Причина может быть чуть менее, чем в чём угодно. SIGALARM - скорее > > всего не имеет отношения к проблеме, он используется для > > обновления времени, если в конфиге используется директива > > timer_resolution. > > > > Что показывает nginx -V, что в конфиге, что в логах, где крутится > > код ("gdb /path/to/nginx " и далее походить)? > > > > Ну и на всякий случай я оставлю эту ссылку здесь: > > > > http://wiki.nginx.org/Debugging > > > > > > -- > Best Regards, Eugene Batogov > _______________________________________ > Software Architect > СTI - Communications. Technology. Innovations. > Tel: +7 (495) 784-73-13 * 2551 > Fax: +7 (495) 784-73-14 > e-mail: e.batogov at cti.ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://nginx.org/ From vovansystems at gmail.com Thu Dec 26 15:14:05 2013 From: vovansystems at gmail.com (VovansystemS) Date: Thu, 26 Dec 2013 18:14:05 +0300 Subject: =?UTF-8?B?UmU6INC60LDQuiDQu9GD0YfRiNC1INGD0L/RgNCw0LLQu9GP0YLRjCDQutC10Yg=?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQtdC8IGZhc3RjZ2lfY2FjaGU=?= In-Reply-To: <20131226122902.GZ95113@mdounin.ru> References: <20131226122902.GZ95113@mdounin.ru> Message-ID: > Нет. При кешировании заголовки If-Modified-Since и If-None-Match > на бекенд не передаются (за исключением ревалидации кеша самим > nginx'ом), так что в ключе их указывать бессмысленно и может > принести лишь проблемы. спасибо! > Если нужна обработка одним и тем же index.php, то в нужных > location'ах явно указывать SCRIPT_FILENAME. вынес в отдельные location'ы то, что требует особых параметров кеширования, а сами настройки кеширования теперь задаются на уровне server. > Лучше - по возможности избегать использование if'ов и rewrite'ов. А вот как убирать слэши в конце URI без rewrite я не смог придумать (так, чтобы было перенаправление на URI без слэша) - есть ли какое-то иное решение? Также не совсем понятно, как избавится от if, когда на то, нужно ли кешировать (отдавать закешированный) контент, влияет несколько факторов (есть ли определённая кука ИЛИ метод запроса post ИЛИ есть аргументы (например)). Возможно ли и стоит ли переписать это на map'ы и как это будет выглядеть? Как бы сделали Вы? fastcgi_cache_path /run/shm/MAIN levels=1:2 keys_zone=MAIN:64m max_size=100m inactive=240h; server { listen 80; server_name domain.com; error_log /var/log/nginx/domain.error.log error; access_log /var/log/nginx/domain.access.log; root /home/user/domain.com/public_html/; set $no_cache 0; if ($request_method = POST) { set $no_cache 1; # не кешируем POST } if ($https = on) { set $no_cache 1; # не кешируем https } if ($query_string != "") { set $no_cache 0; # кешируем страницы с аргументами } # не кешируем, если есть такие куки if ($http_cookie ~* "auth_user|login|comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") { set $no_cache 1; } include fastcgi_params; fastcgi_intercept_errors on; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /public_html/index.php; fastcgi_param DOCUMENT_ROOT /public_html; fastcgi_param KOHANA_ENV production; # если $no_cache отличен от нуля, отдаём некешированную страницу fastcgi_cache_bypass $no_cache; fastcgi_no_cache $no_cache; # ревалидируем элемент кэша при помощи условных запросов с полем заголовка "If-Modified-Since" fastcgi_cache_revalidate on; fastcgi_temp_path /run/shm/fcgi 1 2; fastcgi_cache MAIN; fastcgi_cache_key "$scheme|$request_method|$host|$request_uri"; fastcgi_ignore_headers "Cache-Control" "Expires" "Set-Cookie"; fastcgi_cache_valid 1h; fastcgi_cache_valid any 10s; fastcgi_cache_use_stale updating error timeout invalid_header http_500; # отдаём устаревший закешированный ответ в этих случаях rewrite ^/(.*)/$ /$1 redirect; # все ури должны быть без слэша на конце location / { try_files $uri /index.php$is_args$args; } location ~* "^/(admin|search)((/.*)$|/$)" { set $no_cache 1; fastcgi_pass 127.0.0.1:9001; } location ~* "^/(news|feed)((/.*)$|/$)" { fastcgi_cache_valid 10m; fastcgi_pass 127.0.0.1:9001; } location = /index.php { fastcgi_pass 127.0.0.1:9001; } # все остальные .php файлы location ~* \.php$ { return 403; } # статика location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|docx)$ { expires 60d; access_log off; } } From mdounin at mdounin.ru Thu Dec 26 15:43:14 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 26 Dec 2013 19:43:14 +0400 Subject: =?UTF-8?B?UmU6INC60LDQuiDQu9GD0YfRiNC1INGD0L/RgNCw0LLQu9GP0YLRjCDQutC10Yg=?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQtdC8IGZhc3RjZ2lfY2FjaGU=?= In-Reply-To: References: <20131226122902.GZ95113@mdounin.ru> Message-ID: <20131226154314.GF95113@mdounin.ru> Hello! On Thu, Dec 26, 2013 at 06:14:05PM +0300, VovansystemS wrote: [...] > > Если нужна обработка одним и тем же index.php, то в нужных > > location'ах явно указывать SCRIPT_FILENAME. > вынес в отдельные location'ы то, что требует особых параметров > кеширования, а сами настройки кеширования теперь задаются на уровне > server. Лучше ещё переделать конфиг так, чтобы fastcgi_cache был включён только там, где используется. Ибо если кеш выключен - это одно, а если он включён, но ему сказали bypass / no cache - это немного другое. В частности, при обработке HEAD-запросов, а равно условных запросов будут различия (при включённом кеше на бекенд вместо HEAD уйдёт GET, а If-* заголовки будут убраны). > > Лучше - по возможности избегать использование if'ов и rewrite'ов. > > А вот как убирать слэши в конце URI без rewrite я не смог придумать > (так, чтобы было перенаправление на URI без слэша) - есть ли какое-то > иное решение? Такие вещи лучше всего делать внутри приложения, а не на конфигах nginx'а. > Также не совсем понятно, как избавится от if, когда на то, нужно ли > кешировать (отдавать закешированный) контент, влияет несколько > факторов (есть ли определённая кука ИЛИ метод запроса post ИЛИ есть > аргументы (например)). Возможно ли и стоит ли переписать это на map'ы > и как это будет выглядеть? Как бы сделали Вы? И такие вещи лучше всего делать в рамках приложения, возвращая корректные значения Cache-Control. Впрочем, если речь идёт про fastcgi_no_cache / fastcgi_cache_bypass, то следует иметь ввиду, что эти директивы принимают несколько параметров. Подробнее тут: http://nginx.org/r/fastcgi_no_cache/ru http://nginx.org/r/fastcgi_cache_bypass/ru -- Maxim Dounin http://nginx.org/ From vbart at nginx.com Thu Dec 26 15:50:09 2013 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 26 Dec 2013 19:50:09 +0400 Subject: =?UTF-8?B?UmU6INC60LDQuiDQu9GD0YfRiNC1INGD0L/RgNCw0LLQu9GP0YLRjCDQutC10Yg=?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQtdC8IGZhc3RjZ2lfY2FjaGU=?= In-Reply-To: References: <20131226122902.GZ95113@mdounin.ru> Message-ID: <3245917.s6dA54nk1D@vbart-laptop> On Thursday 26 December 2013 18:14:05 VovansystemS wrote: [..] > Также не совсем понятно, как избавится от if, когда на то, нужно ли > кешировать (отдавать закешированный) контент, влияет несколько > факторов (есть ли определённая кука ИЛИ метод запроса post ИЛИ есть > аргументы (например)). Возможно ли и стоит ли переписать это на map'ы > и как это будет выглядеть? Как бы сделали Вы? > > > fastcgi_cache_path /run/shm/MAIN levels=1:2 keys_zone=MAIN:64m > max_size=100m inactive=240h; > > server { > listen 80; > server_name domain.com; > error_log /var/log/nginx/domain.error.log error; > access_log /var/log/nginx/domain.access.log; > > root /home/user/domain.com/public_html/; > > set $no_cache 0; > if ($request_method = POST) { > set $no_cache 1; # не кешируем POST http://nginx.org/r/fastcgi_cache_methods/ru > } > if ($https = on) { > set $no_cache 1; # не кешируем https > } > if ($query_string != "") { > set $no_cache 0; # кешируем страницы с аргументами > } Обращаю ваше внимание на то, что вы таким образом разрешаете кешировать POST запросы по https с аргументами. Сомневаюсь, что именно такая логика вам была нужна. > # не кешируем, если есть такие куки > if ($http_cookie ~* > "auth_user|login|comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no > _cache|wordpress_logged_in") { > set $no_cache 1; > } Скорее всего вы хотите: map $args $empty_args { default 0; "" 1 } fastcgi_no_cache $empty_args $https $cookie_auth_user $cookie_login .. ; -- Валентин Бартенев From vovansystems at gmail.com Thu Dec 26 18:19:13 2013 From: vovansystems at gmail.com (VovansystemS) Date: Thu, 26 Dec 2013 21:19:13 +0300 Subject: =?UTF-8?B?UmU6INC60LDQuiDQu9GD0YfRiNC1INGD0L/RgNCw0LLQu9GP0YLRjCDQutC10Yg=?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQtdC8IGZhc3RjZ2lfY2FjaGU=?= In-Reply-To: <20131226154314.GF95113@mdounin.ru> References: <20131226122902.GZ95113@mdounin.ru> <20131226154314.GF95113@mdounin.ru> Message-ID: > Лучше ещё переделать конфиг так, чтобы fastcgi_cache был включён > только там, где используется. > > Ибо если кеш выключен - это одно, а если он включён, но ему > сказали bypass / no cache - это немного другое. В частности, при > обработке HEAD-запросов, а равно условных запросов будут различия > (при включённом кеше на бекенд вместо HEAD уйдёт GET, а If-* > заголовки будут убраны). интересно, будем иметь в виду >> А вот как убирать слэши в конце URI без rewrite я не смог придумать [..] > Такие вещи лучше всего делать внутри приложения, а не на конфигах > nginx'а. хорошо, переделаем при возможности >> Также не совсем понятно, как избавится от if, когда на то, нужно ли >> кешировать (отдавать закешированный) контент, влияет несколько >> факторов (есть ли определённая кука ИЛИ метод запроса post ИЛИ есть >> аргументы (например)). Возможно ли и стоит ли переписать это на map'ы >> и как это будет выглядеть? Как бы сделали Вы? > > И такие вещи лучше всего делать в рамках приложения, возвращая > корректные значения Cache-Control. > > Впрочем, если речь идёт про fastcgi_no_cache / > fastcgi_cache_bypass, то следует иметь ввиду, что эти директивы > принимают несколько параметров. [..] о, действительно, надо ещё раз перечитать документацию по модулю, т.к. за последние годы появилось много очень удобных и полезных директив, а я по-инерции продолжаю использовать костыли и воркэраунды от ранних версий, да ещё и исправленые множество раз, которые содержат логические ошибки, как показал Валентин. >> не кешируем POST > http://nginx.org/r/fastcgi_cache_methods/ru спасибо! > Обращаю ваше внимание на то, что вы таким образом разрешаете > кешировать POST запросы по https с аргументами. Сомневаюсь, > что именно такая логика вам была нужна. действительно, а ведь в одной продакшн системе так и крутится - пойду исправлять - спасибо! > Скорее всего вы хотите: > map $args $empty_args { > default 0; > "" 1 > } > fastcgi_no_cache $empty_args $https $cookie_auth_user $cookie_login .. ; да, именно так и требовалось в данном же конкретном случае нужно кешировать ответы безотносительно того, имеет ли запрашиваемая страница аргументы или нет. поэтому конечный конфиг будет выглядеть как-то так (без map, а на других проектах оно будет использоваться), но мы будем учитывать те рекоммендации, которые дал Максим. Всем огромное спасибо, я многое сегодня понял. fastcgi_cache_path /run/shm/MAIN levels=1:2 keys_zone=MAIN:64m max_size=100m inactive=240h; server { listen 80; server_name domain.com; error_log /var/log/nginx/domain.error.log error; access_log /var/log/nginx/domain.access.log; root /home/user/domain.com/public_html/; include fastcgi_params; fastcgi_intercept_errors on; fastcgi_param SCRIPT_FILENAME /public_html/index.php; fastcgi_param DOCUMENT_ROOT /public_html; fastcgi_param KOHANA_ENV production; # отдаём некешированную страницу и не помещаем такую страницу в кеш, # если значение хотя бы одного из строковых параметров непустое и не равно "0" fastcgi_no_cache $https $cookie_login $cookie_auth_user; fastcgi_cache_bypass $https $cookie_login $cookie_auth_user; fastcgi_cache_revalidate on; fastcgi_temp_path /run/shm/fcgi 1 2; fastcgi_cache MAIN; fastcgi_cache_key "$scheme|$request_method|$host|$request_uri"; fastcgi_cache_methods GET HEAD; # Если метод запроса клиента указан в этой директиве, то ответ будет закэширован fastcgi_ignore_headers "Cache-Control" "Expires" "Set-Cookie"; fastcgi_cache_valid 20m; fastcgi_cache_valid any 10s; fastcgi_cache_use_stale updating error timeout invalid_header http_500; rewrite ^/(.*)/$ /$1 redirect; # все URI должны быть без слэша на конце location / { try_files $uri /index.php$is_args$args; } location ~* "^/(admin|search)(/.*$|/$)" { fastcgi_cache off; fastcgi_pass 127.0.0.1:9001; } location ~* "^/(news|feed)(.*$|/$)" { fastcgi_cache_valid 10m; fastcgi_pass 127.0.0.1:9001; } location = /index.php { fastcgi_pass 127.0.0.1:9001; } # все остальные .php файлы location ~* \.php$ { return 403; } # статика location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|docx)$ { expires 60d; access_log off; } } From nginx-forum at nginx.us Thu Dec 26 19:00:56 2013 From: nginx-forum at nginx.us (Sergey Korzhevsky) Date: Thu, 26 Dec 2013 14:00:56 -0500 Subject: image_filter+proxy_pass and 301 (moved permanently) on backend Message-ID: <90055df89e0abed5ea9adb0dfb0ed018.NginxMailingListRussian@forum.nginx.org> Столкнулся со следующей проблемой. Необходимо проксировать картинки и при этом их резать. Реализуется в таком ключе (www.site.com/photos/www.images1.com/image1.jpg): location ~* "^/photos/(.*)$" { image_filter resize 50 -; proxy_pass http://$1; proxy_redirect off; } Все работает хорошо если только бэкэнд не возвращает для картинки 301 Moved permanently. Я так понял, что в этом случае nginx сразу передает этот ответ в image_filter в результате чего возвращается ошибка 415 Unsupported Media Type. Подскажите, можно ли сделать так, что бы nginx сначало забирал картинку по новому урлу а уж потом пытался ее порезать? Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245867,245867#msg-245867 From nginx-forum at nginx.us Fri Dec 27 13:41:40 2013 From: nginx-forum at nginx.us (proforg) Date: Fri, 27 Dec 2013 08:41:40 -0500 Subject: =?UTF-8?B?0L/QsNC00LDRjtGCINCy0L7RgNC60LXRgNGL?= Message-ID: <059611c74c4f4a1b845e5189ee399303.NginxMailingListRussian@forum.nginx.org> Воркеры падают, и оставляют после себя вот такое странное в корках: (gdb) bt #0 0x00007fc7081f91b5 in ?? () #1 0x00007fc7081fbfc0 in ?? () #2 0x00000000026cc930 in ?? () #3 0x00007fc7046fba50 in ?? () #4 0x00007fc704400e48 in ?? () #5 0x00000000026cc930 in ?? () #6 0x00000000026cc930 in ?? () #7 0x0000000000458c30 in ngx_http_file_cache_update (r=0x7474, tf=0x7474) at src/http/ngx_http_file_cache.c:972 #8 0x000000000040ce9a in ngx_strlcasestrn (s1=0x0, last=0x5a
, s2=0x26cc930 "HTTP", n=4349861) at src/core/ngx_string.c:733 #9 0x0000000000000000 in ?? () nginx version: nginx/1.5.8 built by gcc 4.4.5 (Debian 4.4.5-8) TLS SNI support enabled configure arguments: --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 --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --http-scgi-temp-path=/var/lib/nginx/scgi --with-debug --with-file-aio --with-http_stub_status_module --with-http_addition_module --with-http_random_index_module --with-http_flv_module --with-http_ssl_module --with-http_dav_module --with-http_realip_module --with-http_secure_link_module --with-http_xslt_module --with-http_addition_module --with-http_image_filter_module --with-http_mp4_module --with-http_spdy_module --with-http_gunzip_module --add-module=mod_zip --add-module=nginx-upload-progress-module --with-http_geoip_module --with-http_sub_module --add-module=ngx_http_substitutions_filter_module Linux s1140.serverel.net 3.6-trunk-amd64 #1 SMP Debian 3.6.6-1~experimental.1 x86_64 GNU/Linux И я как-то не понимаю, что с этим делать и как получить нормальный backtrace. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245877,245877#msg-245877 From mdounin at mdounin.ru Fri Dec 27 14:40:32 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 27 Dec 2013 18:40:32 +0400 Subject: =?UTF-8?B?UmU6INC/0LDQtNCw0Y7RgiDQstC+0YDQutC10YDRiw==?= In-Reply-To: <059611c74c4f4a1b845e5189ee399303.NginxMailingListRussian@forum.nginx.org> References: <059611c74c4f4a1b845e5189ee399303.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131227144032.GN95113@mdounin.ru> Hello! On Fri, Dec 27, 2013 at 08:41:40AM -0500, proforg wrote: > Воркеры падают, и оставляют после себя вот такое странное в корках: > > > (gdb) bt > #0 0x00007fc7081f91b5 in ?? () > #1 0x00007fc7081fbfc0 in ?? () > #2 0x00000000026cc930 in ?? () > #3 0x00007fc7046fba50 in ?? () > #4 0x00007fc704400e48 in ?? () > #5 0x00000000026cc930 in ?? () > #6 0x00000000026cc930 in ?? () > #7 0x0000000000458c30 in ngx_http_file_cache_update (r=0x7474, tf=0x7474) > at src/http/ngx_http_file_cache.c:972 > #8 0x000000000040ce9a in ngx_strlcasestrn (s1=0x0, last=0x5a
out of bounds>, s2=0x26cc930 "HTTP", n=4349861) at > src/core/ngx_string.c:733 > #9 0x0000000000000000 in ?? () > > > nginx version: nginx/1.5.8 > built by gcc 4.4.5 (Debian 4.4.5-8) > TLS SNI support enabled > configure arguments: --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 > --http-client-body-temp-path=/var/lib/nginx/body > --http-proxy-temp-path=/var/lib/nginx/proxy > --http-fastcgi-temp-path=/var/lib/nginx/fastcgi > --http-uwsgi-temp-path=/var/lib/nginx/uwsgi > --http-scgi-temp-path=/var/lib/nginx/scgi --with-debug --with-file-aio > --with-http_stub_status_module --with-http_addition_module > --with-http_random_index_module --with-http_flv_module > --with-http_ssl_module --with-http_dav_module --with-http_realip_module > --with-http_secure_link_module --with-http_xslt_module > --with-http_addition_module --with-http_image_filter_module > --with-http_mp4_module --with-http_spdy_module --with-http_gunzip_module > --add-module=mod_zip --add-module=nginx-upload-progress-module > --with-http_geoip_module --with-http_sub_module > --add-module=ngx_http_substitutions_filter_module > > Linux s1140.serverel.net 3.6-trunk-amd64 #1 SMP Debian > 3.6.6-1~experimental.1 x86_64 GNU/Linux > > > И я как-то не понимаю, что с этим делать и как получить нормальный > backtrace. Для начала - убедиться, что запущенный бинарник и бинарник на диске - это одно и то же. Если не поможет - имеет смысл попробовать воспроизвести проблему без сторонних модулей. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Sat Dec 28 10:57:13 2013 From: nginx-forum at nginx.us (buddha) Date: Sat, 28 Dec 2013 05:57:13 -0500 Subject: Rewrite+resolver Message-ID: <022f307a7c7aac672d71704aad350c9f.NginxMailingListRussian@forum.nginx.org> привет всем. есть 2 вопроса: 1. Понадобилось сделать чпу. Были ссылки вида http://www.host.ru/news/view?id=12 надо было переделать в виде http://www.host.ru/category/name_12 Сделал это с помощью proxy_pass вот так: location ~ .+/.+_(\d+)$ { proxy_pass http://$server_name/news/view?id=$1 } но возникла проблема. для хоста www.host.ru это работает нормально, а для хоста help.host.ru пишет no resolver defined поправил это вот таким способом location ~ .+/.+_(\d+)$ { resolver 8.8.8.8; proxy_pass proxy_pass http://$server_name/news/view?id=$1 } конфиги для www.host.ru и help.host.ru - идентичные, отличаются только server_name и root_dir Вопрос: почему для первого хоста все работает и без resolver, а для второго прописывать обязательно? 2. Правильно ли таким образом делать чпу? с помощью rewrite не получилось. вот конфиг для www.host.ru. Хотелось бы услышать как улучшить этот конфиг, в чем ошибка, и как сделать чпу с помощью rewrite(возможно ли) ################################ server { listen 81; server_name www.host.ru; root /var/www/host.ru/www/; access_log /var/log/nginx/www.host.access.log; error_log /var/log/nginx/www.host.error.log; location ~ .+/.+_(\d+)$ { proxy_pass http://$server_name/news/view?id=$1&internal=1; } location / { try_files $uri /index.php$uri?$query_string; } location /index.php { internal; root /var/www/host.ru/www; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; fastcgi_ignore_client_abort off; fastcgi_buffers 256 16K; fastcgi_buffer_size 32k; fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param CITY $city; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; include fastcgi_params; } location ~* \.php$ { root /var/www/host.ru/www/; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; fastcgi_ignore_client_abort off; fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param CITY $city; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_buffers 256 16K; fastcgi_buffer_size 32k; include fastcgi_params; } } ################################ Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245884,245884#msg-245884 From postmaster at softsearch.ru Sat Dec 28 11:20:47 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 28 Dec 2013 15:20:47 +0400 Subject: =?UTF-8?B?Q09QWSDQuCDQvdC10YHRg9GJ0LXRgdGC0LLRg9GO0YnQsNGPINC00LjRgNC10Lo=?= =?UTF-8?B?0YLQvtGA0LjRjyA9IDUwMCBJbnRlcm5hbCBTZXJ2ZXIgRXJyb3I=?= Message-ID: <816828878.20131228152047@softsearch.ru> Здравствуйте. Бага или фича? Если через WebDAV копируется несуществующий файл в существующей директории, то выдаётся 404. Но если копируется файл из несуществующей директории в неё же, то выдаётся 500 - Internal Server Error. Это правильное поведение или должно 404 тоже выдаваться? Пример: копируем http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg в http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg.tmp и получаем: 500 Internal Server Error в error_log-е: 2013/12/28 11:54:28 [crit] 2845#0: *4749150 open() "/opt2/beon/i39/17/74/1467417/47/avatars/4.jpeg.tmp" failed (2: No such file or directory), client: 89.208.146.210, server: i39.beon.ru, request: "COPY http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg HTTP/1.1", host: "i39.beon.ru" в access.log-e: 28/Dec/2013:11:54:28 +0400 500 89.208.146.210 353 i39.beon.ru "COPY http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg HTTP/1.1" "-" "-" "-" "-" "-" "-" "close" на диске: ls -l /opt2/beon/i39/17/74/1467417/47/avatars/ ls: /opt2/beon/i39/17/74/1467417/47/avatars/: No such file or directory ls -l /opt2/beon/i39/17/74/1467417/47/ total 2 drwxr-xr-x 2 www www 512 Feb 19 2012 45342747 nginx -V nginx version: nginx/1.5.7 configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www --group=www --with-debug --with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx-access.log --with-http_dav_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-pcre -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Sat Dec 28 12:35:02 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 28 Dec 2013 16:35:02 +0400 Subject: Rewrite+resolver In-Reply-To: <022f307a7c7aac672d71704aad350c9f.NginxMailingListRussian@forum.nginx.org> References: <022f307a7c7aac672d71704aad350c9f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131228123502.GS95113@mdounin.ru> Hello! On Sat, Dec 28, 2013 at 05:57:13AM -0500, buddha wrote: > привет всем. > > есть 2 вопроса: > > 1. Понадобилось сделать чпу. Были ссылки вида > http://www.host.ru/news/view?id=12 надо было переделать в виде > http://www.host.ru/category/name_12 > > Сделал это с помощью proxy_pass вот так: > > location ~ .+/.+_(\d+)$ { > proxy_pass http://$server_name/news/view?id=$1 > } > > но возникла проблема. для хоста www.host.ru это работает нормально, а для > хоста help.host.ru пишет no resolver defined > > поправил это вот таким способом > > location ~ .+/.+_(\d+)$ { > resolver 8.8.8.8; > proxy_pass proxy_pass http://$server_name/news/view?id=$1 > } > > конфиги для www.host.ru и help.host.ru - идентичные, отличаются только > server_name и root_dir > > Вопрос: почему для первого хоста все работает и без resolver, а для второго > прописывать обязательно? Когда-то я думал, что rewrite'ы - это плохо. Теперь я понимаю, что rewrite'ы по сравнению с перменными в proxy_pass - это детский лепет. Что до вопроса, то ответ на него есть в документации тут: http://nginx.org/r/proxy_pass/ru Резолвер не нужен, если проксирование происходит на имя сервера, для которого описан upstream (возможно, неявно, через proxy_pass на это имя). > 2. Правильно ли таким образом делать чпу? с помощью rewrite не получилось. Нет. Самое правильно решение - делать всё это в приложении, на нормальном языке программирования. Но proxy_pass с переменными однозначно хуже, чем даже rewrite'ы. -- Maxim Dounin http://nginx.org/ From mdounin at mdounin.ru Sat Dec 28 13:00:43 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 28 Dec 2013 17:00:43 +0400 Subject: =?UTF-8?B?UmU6IENPUFkg0Lgg0L3QtdGB0YPRidC10YHRgtCy0YPRjtGJ0LDRjyDQtNC40YA=?= =?UTF-8?B?0LXQutGC0L7RgNC40Y8gPSA1MDAgSW50ZXJuYWwgU2VydmVyIEVycm9y?= In-Reply-To: <816828878.20131228152047@softsearch.ru> References: <816828878.20131228152047@softsearch.ru> Message-ID: <20131228130043.GT95113@mdounin.ru> Hello! On Sat, Dec 28, 2013 at 03:20:47PM +0400, Михаил Монашёв wrote: > Здравствуйте. > > Бага или фича? > > Если через WebDAV копируется несуществующий файл в существующей > директории, то выдаётся 404. Но если копируется файл из несуществующей > директории в неё же, то выдаётся 500 - Internal Server Error. Это > правильное поведение или должно 404 тоже выдаваться? Если исходный файл/каталог не сущетсвует, то в любом случае должно выдаваться 404. > Пример: > копируем http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg > в http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg.tmp > и получаем: 500 Internal Server Error > > в error_log-е: > 2013/12/28 11:54:28 [crit] 2845#0: *4749150 open() "/opt2/beon/i39/17/74/1467417/47/avatars/4.jpeg.tmp" failed (2: No such file or directory), client: 89.208.146.210, server: i39.beon.ru, request: "COPY http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg HTTP/1.1", host: "i39.beon.ru" > > в access.log-e: > 28/Dec/2013:11:54:28 +0400 500 89.208.146.210 353 i39.beon.ru "COPY http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg HTTP/1.1" "-" "-" "-" "-" "-" "-" "close" Должно быть так: 2013/12/28 16:51:35 [error] 33014#0: *1 lstat() "/path/to/foo/bar/bazz" failed (2: No such file or directory), client: 127.0.0.1, server: , request: "COPY /foo/bar/bazz HTTP/1.1", host: "localhost" 127.0.0.1 - - [28/Dec/2013:16:51:35 +0400] "COPY /foo/bar/bazz HTTP/1.1" 404 168 "-" "-" То, что у тебя сломался open(), намекает на то, что в процессе выполнения этого запроса кто-то удалил каталог. -- Maxim Dounin http://nginx.org/ From nginx-forum at nginx.us Sat Dec 28 13:26:17 2013 From: nginx-forum at nginx.us (buddha) Date: Sat, 28 Dec 2013 08:26:17 -0500 Subject: Rewrite+resolver In-Reply-To: <20131228123502.GS95113@mdounin.ru> References: <20131228123502.GS95113@mdounin.ru> Message-ID: 1. насчет resolver увидел. действительно, выше задается upstream. спасибо 2. хотел перенести это на роуты в приложении, но подумал что сервер будет быстрее обрабатывать и парсить uri чем приложение. почему proxy_pass с переменными плохо? медленнее? или тяжелее для сервера? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245884,245889#msg-245889 From onokonem at gmail.com Sat Dec 28 14:13:19 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Sat, 28 Dec 2013 18:13:19 +0400 Subject: Rewrite+resolver In-Reply-To: References: <20131228123502.GS95113@mdounin.ru> Message-ID: 2013/12/28 buddha : > почему proxy_pass с переменными плохо? медленнее? или тяжелее для сервера? И то, и другое. если переменных нет - разрешение имени происходит один раз, при старте. а если есть - на каждом запросе. From onokonem at gmail.com Sat Dec 28 14:14:57 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Sat, 28 Dec 2013 18:14:57 +0400 Subject: Rewrite+resolver In-Reply-To: <20131228123502.GS95113@mdounin.ru> References: <022f307a7c7aac672d71704aad350c9f.NginxMailingListRussian@forum.nginx.org> <20131228123502.GS95113@mdounin.ru> Message-ID: 2013/12/28 Maxim Dounin : > Когда-то я думал, что rewrite'ы - это плохо. а чем плохо - рерайты? задача возникает часто, работает оно хорошо, и, вроде, без подводных камней. From ne at vbart.ru Sat Dec 28 15:50:05 2013 From: ne at vbart.ru (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 28 Dec 2013 19:50:05 +0400 Subject: Rewrite+resolver In-Reply-To: References: <022f307a7c7aac672d71704aad350c9f.NginxMailingListRussian@forum.nginx.org> <20131228123502.GS95113@mdounin.ru> Message-ID: <2231636.zd6BvjxcJf@vbart-laptop> On Saturday 28 December 2013 18:14:57 Daniel Podolsky wrote: > 2013/12/28 Maxim Dounin : > > > Когда-то я думал, что rewrite'ы - это плохо. > > а чем плохо - рерайты? > > задача возникает часто, работает оно хорошо, и, вроде, без подводных > камней. Конфигурация веб-сервера - не язык программирования, она должна быть максимально простой и понятной. Существование императивных директив в декларативном конфиге nginx, скорее можно рассматривать как баг. Кроме того, вы таким образом создаете существенный layering violation: то, за что должно отвечать приложение (за URI, которые оно генерирует и обрабатывает), частично оказывается вынесено на веб-сервер и изменения в приложении начинают требовать правки конфигурации веб-сервера. Особенно это весело когда программист и админ - не одно лицо, обычно админы в таких случаях постоянно про себя матерят разработчиков, а те пинают "ленивых и криворуких" админов. Что касается производительности, то я не ручаюсь сказать, что будет быстрее, но уверен, что разница, если она и есть в какую-либо сторону, неизмеримо мала. -- Валентин Бартенев From kisulja2000 at mail.ru Sun Dec 29 04:58:25 2013 From: kisulja2000 at mail.ru (Serg) Date: Sun, 29 Dec 2013 08:58:25 +0400 Subject: =?UTF-8?B?0JzQvtC00YPQu9C4INC/0L4g0YPQvNC+0LvRh9Cw0L3QuNGO?= Message-ID: Здравствуйте, Всех с наступающими праздниками! Подскажите пожалуйста, например в поставке debian, с каким набором модулей компилируют nginx? С уваженим, Сергей Мелехов From nginx-forum at nginx.us Sun Dec 29 06:04:05 2013 From: nginx-forum at nginx.us (S.A.N) Date: Sun, 29 Dec 2013 01:04:05 -0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDQu9GD0YfRiNC1INGD0L/RgNCw0LLQu9GP0YLRjCDQutC10Yg=?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQtdC8IGZhc3RjZ2kgY2FjaGU=?= In-Reply-To: References: Message-ID: Вам правильно ответили, в первую очередь нужно читать документацию. Возможно вы удивитесь но ваш конфиг по кешированию может и должен выглядить намного короче, как-то так fastcgi_cache_lock on; fastcgi_cache_revalidate on; fastcgi_cache_methods GET HEAD; fastcgi_cache_valid 200 301 302 0s; fastcgi_cache_key "$host$uri$is_args$args"; fastcgi_cache_use_stale error updating http_503; Програмить что-то более в конфиге Nginx не нужно, управлять кэшированием нужно на стороне бекенда, это будет удобней и эффективней. Т.е скрипты по адресу /admin /search, должны отдавать HTTP хедер Cache-Control: no-store, это запретит кеширования на стороне Nginx и в браузере клиента. Скрипты по адресу /news /feed должны отдавать HTTP хедер Cache-Control: max-age=600, это разрешит кешировать страницу на 10 минут (600 секунд), таким образом кеш будет в браузере клиента и в Nginx, и браузер на протяжении 10 минут, вообще не будет делать повторных запросов по этому uri, а будет использовать свой локальный кеш, это намного быстрей чем гонять контент по сети. С куками тоже все просто, как правило проблема в том что в скриптах используется session_start() всегда и везде, но эта функция автоматом отправляет HTTP заголовки на запрет кеширования и куки с id сессии, функция все делает правильно, просто вызывать её нужно только в тех скриптах которые недолжны попадать в кеш, во всех остальных скриптах, функция session_start() вызыватся не должна. И советую не читать статьи, типа - Подводные камни при использовании кэширования в nginx http://habrahabr.ru/post/72539/ К сожалению, в статье больше глупостей чем разумных вещей, если будите читать документацию и пользоваться логикой, подводных камней в кэшировании не будет и конфиг станет короче и управляемость кешем станет прозрачной а главное само кэширования станет эффективней. Да, насчет отрезать слеш в конце uri, лучше это тоже делать на стороне бекенда, тогда редиректы которые сделал бекенд, соханятся в кеше Nginx и повторные запросы со слешем в конце уже не будут приходить на бекенд, Nginx сам ответит редиректом из своего кеша. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245843,245896#msg-245896 From public-mail at alekciy.ru Sun Dec 29 08:30:39 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Sun, 29 Dec 2013 12:30:39 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvQuCDQv9C+INGD0LzQvtC70YfQsNC90LjRjg==?= In-Reply-To: References: Message-ID: [~]# uname -a Linux ww-realty.ru 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux [~]# nginx -v nginx version: nginx/1.2.1 [~]# nginx -V nginx version: nginx/1.2.1 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-pcre-jit --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=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-auth-pam --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-echo --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-upstream-fair --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-dav-ext-module 29 декабря 2013 г., 8:58 пользователь Serg написал: > Здравствуйте, > > Всех с наступающими праздниками! > > Подскажите пожалуйста, например в поставке debian, с каким набором > модулей компилируют 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 kisulja2000 at mail.ru Sun Dec 29 08:49:01 2013 From: kisulja2000 at mail.ru (kisulja) Date: Sun, 29 Dec 2013 12:49:01 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvQuCDQv9C+INGD0LzQvtC70YfQsNC90LjRjg==?= In-Reply-To: References: Message-ID: <52BFE1FD.1050802@mail.ru> Спасибо ! 29.12.2013 12:30, Алексей Сундуков пишет: > [~]# uname -a > Linux ww-realty.ru 3.2.0-4-amd64 #1 SMP Debian > 3.2.46-1+deb7u1 x86_64 GNU/Linux > [~]# nginx -v > nginx version: nginx/1.2.1 > [~]# nginx -V > nginx version: nginx/1.2.1 > 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-pcre-jit --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=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-auth-pam > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-echo > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-upstream-fair --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-dav-ext-module > > > > 29 декабря 2013 г., 8:58 пользователь Serg > написал: > > Здравствуйте, > > Всех с наступающими праздниками! > > Подскажите пожалуйста, например в поставке debian, с каким > набором модулей компилируют nginx? > > С уваженим, > Сергей Мелехов > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at softsearch.ru Sun Dec 29 10:11:29 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 29 Dec 2013 14:11:29 +0400 Subject: =?UTF-8?B?UmVbMl06IENPUFkg0Lgg0L3QtdGB0YPRidC10YHRgtCy0YPRjtGJ0LDRjyDQtNC4?= =?UTF-8?B?0YDQtdC60YLQvtGA0LjRjyA9IDUwMCBJbnRlcm5hbCBTZXJ2ZXIgRXJyb3I=?= In-Reply-To: <20131228130043.GT95113@mdounin.ru> References: <816828878.20131228152047@softsearch.ru> <20131228130043.GT95113@mdounin.ru> Message-ID: <15510205824.20131229141129@softsearch.ru> Здравствуйте, Maxim. >> Бага или фича? >> >> Если через WebDAV копируется несуществующий файл в существующей >> директории, то выдаётся 404. Но если копируется файл из несуществующей >> директории в неё же, то выдаётся 500 - Internal Server Error. Это >> правильное поведение или должно 404 тоже выдаваться? > Если исходный файл/каталог не сущетсвует, то в любом случае должно > выдаваться 404. >> Пример: >> копируем http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg >> в http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg.tmp >> и получаем: 500 Internal Server Error >> >> в error_log-е: >> 2013/12/28 11:54:28 [crit] 2845#0: *4749150 open() >> "/opt2/beon/i39/17/74/1467417/47/avatars/4.jpeg.tmp" failed (2: No >> such file or directory), client: 89.208.146.210, server: >> i39.beon.ru, request: "COPY >> http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg HTTP/1.1", host: >> "i39.beon.ru" >> >> в access.log-e: >> 28/Dec/2013:11:54:28 +0400 500 89.208.146.210 353 i39.beon.ru >> "COPY http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg HTTP/1.1" >> "-" "-" "-" "-" "-" "-" "close" > Должно быть так: > 2013/12/28 16:51:35 [error] 33014#0: *1 lstat() > "/path/to/foo/bar/bazz" failed (2: No such file or directory), > client: 127.0.0.1, server: , request: "COPY /foo/bar/bazz HTTP/1.1", > host: "localhost" > 127.0.0.1 - - [28/Dec/2013:16:51:35 +0400] "COPY /foo/bar/bazz HTTP/1.1" 404 168 "-" "-" > То, что у тебя сломался open(), намекает на то, что в процессе > выполнения этого запроса кто-то удалил каталог. Каталоги там никто не удаляет точно. Вся работа идёт через nginx, а он удалять каталоги не умеет и на встроенном перле у меня ничего не написано. И ошибка эта воспроизводится не всегда. Ошибка: Couldn't copy http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif => http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif.tmp: 500 Internal Server Error Посмотрел debug-лог. Я там тоже накрутил с конфигом, но 500 всёравно быть не должно ИМХО: 2013/12/29 14:00:55 [debug] 78336#0: *10484311 accept: 89.208.146.210 fd:4 2013/12/29 14:00:55 [debug] 78336#0: *10484311 post event 00000008032442A0 2013/12/29 14:00:55 [debug] 78336#0: *10484311 delete posted event 00000008032442A0 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http wait request handler 2013/12/29 14:00:55 [debug] 78336#0: *10484311 posix_memalign: 000000080303E300:256 @16 2013/12/29 14:00:55 [debug] 78336#0: *10484311 malloc: 0000000803007800:1024 2013/12/29 14:00:55 [debug] 78336#0: *10484311 recv: eof:0, avail:1, err:0 2013/12/29 14:00:55 [debug] 78336#0: *10484311 recv: fd:4 188 of 1024 2013/12/29 14:00:55 [debug] 78336#0: *10484311 reusable connection: 0 2013/12/29 14:00:55 [debug] 78336#0: *10484311 posix_memalign: 000000080308F000:4096 @16 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http process request line 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http request line: "COPY http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif HTTP/1.1" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http uri: "/43/96/1009643/43/avatars/9.gif" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http args: "" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http exten: "gif" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http process request header line 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http header: "Connection: close" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http header: "Host: b.i41.beon.ru" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http header: "Command-ID: 1" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http header: "Destination: http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif.tmp" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http header done 2013/12/29 14:00:55 [debug] 78336#0: *10484311 generic phase: 0 2013/12/29 14:00:55 [debug] 78336#0: *10484311 rewrite phase: 1 2013/12/29 14:00:55 [debug] 78336#0: *10484311 posix_memalign: 0000000803091000:4096 @16 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http script regex: "^(/\d+/\d+/\d+/)\d+/(avatars/.+|design/.+|0\.(?:gif|jpeg|png|mp3))$" 2013/12/29 14:00:55 [notice] 78336#0: *10484311 "^(/\d+/\d+/\d+/)\d+/(avatars/.+|design/.+|0\.(?:gif|jpeg|png|mp3))$" matches "/43/96/1009643/43/avatars/9.gif", client: 89.208.146.210, server: i41.beon.ru, request: "COPY http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif HTTP/1.1", host: "b.i41.beon.ru" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http script copy: "/" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http script capture: "/43/96/1009643/" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http script capture: "avatars/9.gif" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http script regex end 2013/12/29 14:00:55 [notice] 78336#0: *10484311 rewritten data: "//43/96/1009643/avatars/9.gif", args: "", client: 89.208.146.210, server: i41.beon.ru, request: "COPY http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif HTTP/1.1", host: "b.i41.beon.ru" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 test location: "/" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 test location: "robots.txt" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 using configuration "/" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http cl:-1 max:20971520 2013/12/29 14:00:55 [debug] 78336#0: *10484311 rewrite phase: 3 2013/12/29 14:00:55 [debug] 78336#0: *10484311 post rewrite phase: 4 2013/12/29 14:00:55 [debug] 78336#0: *10484311 generic phase: 5 2013/12/29 14:00:55 [debug] 78336#0: *10484311 generic phase: 6 2013/12/29 14:00:55 [debug] 78336#0: *10484311 generic phase: 7 2013/12/29 14:00:55 [debug] 78336#0: *10484311 access phase: 8 2013/12/29 14:00:55 [debug] 78336#0: *10484311 access: D292D059 000000FF 0000007F 2013/12/29 14:00:55 [debug] 78336#0: *10484311 access: D292D059 000000FF 0000000A 2013/12/29 14:00:55 [debug] 78336#0: *10484311 access: D292D059 F8FFFFFF D892D059 2013/12/29 14:00:55 [debug] 78336#0: *10484311 access: D292D059 FFFFFFFF E092D059 2013/12/29 14:00:55 [debug] 78336#0: *10484311 access: D292D059 FCFFFFFF D492D059 2013/12/29 14:00:55 [debug] 78336#0: *10484311 access: D292D059 FEFFFFFF D292D059 2013/12/29 14:00:55 [debug] 78336#0: *10484311 access phase: 9 2013/12/29 14:00:55 [debug] 78336#0: *10484311 post access phase: 10 2013/12/29 14:00:55 [debug] 78336#0: *10484311 content phase: 11 2013/12/29 14:00:55 [debug] 78336#0: *10484311 content phase: 12 2013/12/29 14:00:55 [debug] 78336#0: *10484311 content phase: 13 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http copy from: "/opt2/beon/i41//43/96/1009643/avatars/9.gif" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http copy to: "/opt2/beon/i41/43/96/1009643/43/avatars/9.gif.tmp" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 malloc: 0000000806E68000:65536 2013/12/29 14:00:55 [crit] 78336#0: *10484311 open() "/opt2/beon/i41/43/96/1009643/43/avatars/9.gif.tmp" failed (2: No such file or directory), client: 89.208.146.210, server: i41.beon.ru, request: "COPY http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif HTTP/1.1", host: "b.i41.beon.ru" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http finalize request: 500, "//43/96/1009643/avatars/9.gif?" a:1, c:1 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http special response: 500, "//43/96/1009643/avatars/9.gif?" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http set discard body 2013/12/29 14:00:55 [debug] 78336#0: *10484311 HTTP/1.1 500 Internal Server Error 2013/12/29 14:00:55 [debug] 78336#0: *10484311 write new buf t:1 f:0 0000000803091170, pos 0000000803091170, size: 161 file: 0, size: 0 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http write filter: l:0 f:0 s:161 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http output filter "//43/96/1009643/avatars/9.gif?" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http copy filter: "//43/96/1009643/avatars/9.gif?" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 image filter 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http postpone filter "//43/96/1009643/avatars/9.gif?" 0000000803091348 2013/12/29 14:00:55 [debug] 78336#0: *10484311 write old buf t:1 f:0 0000000803091170, pos 0000000803091170, size: 161 file: 0, size: 0 2013/12/29 14:00:55 [debug] 78336#0: *10484311 write new buf t:0 f:0 0000000000000000, pos 00000000006DC720, size: 140 file: 0, size: 0 2013/12/29 14:00:55 [debug] 78336#0: *10484311 write new buf t:0 f:0 0000000000000000, pos 00000000006DB5C0, size: 52 file: 0, size: 0 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http write filter: l:1 f:0 s:353 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http write filter limit 131072 2013/12/29 14:00:55 [debug] 78336#0: *10484311 writev: 353 of 353 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http write filter 0000000000000000 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http copy filter: 0 "//43/96/1009643/avatars/9.gif?" 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http finalize request: 0, "//43/96/1009643/avatars/9.gif?" a:1, c:1 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http request count:1 blk:0 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http close request 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http log handler 2013/12/29 14:00:55 [debug] 78336#0: *10484311 free: 000000080308F000, unused: 7 2013/12/29 14:00:55 [debug] 78336#0: *10484311 free: 0000000803091000, unused: 3192 2013/12/29 14:00:55 [debug] 78336#0: *10484311 close http connection: 4 2013/12/29 14:00:55 [debug] 78336#0: *10484311 reusable connection: 0 2013/12/29 14:00:55 [debug] 78336#0: *10484311 free: 0000000803007800 2013/12/29 14:00:55 [debug] 78336#0: *10484311 free: 000000080303E200, unused: 0 2013/12/29 14:00:55 [debug] 78336#0: *10484311 free: 000000080303E300, unused: 144 -- С уважением, Михаил mailto:postmaster at softsearch.ru From onokonem at gmail.com Sun Dec 29 11:13:54 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Sun, 29 Dec 2013 15:13:54 +0400 Subject: Rewrite+resolver In-Reply-To: <2231636.zd6BvjxcJf@vbart-laptop> References: <022f307a7c7aac672d71704aad350c9f.NginxMailingListRussian@forum.nginx.org> <20131228123502.GS95113@mdounin.ru> <2231636.zd6BvjxcJf@vbart-laptop> Message-ID: > Конфигурация веб-сервера - не язык программирования, она должна быть > максимально простой и понятной. Существование императивных директив в > декларативном конфиге nginx, скорее можно рассматривать как баг. Это - философский вопрос. Боюсь, эти директивы появились не просто так, а потому, что без них совсем не получалось решать реальные задачи. > Кроме того, вы таким образом создаете существенный layering violation: > то, за что должно отвечать приложение (за URI, которые оно генерирует > и обрабатывает), частично оказывается вынесено на веб-сервер Справедливо. Но мне рерайт пригождается в первую очередь для исправления косяков приложения, которые другим способом исправлять слишком дорого. From nginx-forum at nginx.us Sun Dec 29 13:02:48 2013 From: nginx-forum at nginx.us (buddha) Date: Sun, 29 Dec 2013 08:02:48 -0500 Subject: Rewrite+resolver In-Reply-To: <2231636.zd6BvjxcJf@vbart-laptop> References: <2231636.zd6BvjxcJf@vbart-laptop> Message-ID: <39c78b8761bf748dfec4791f1f9f2742.NginxMailingListRussian@forum.nginx.org> VBart Wrote: > Конфигурация веб-сервера - не язык программирования, она должна быть > максимально простой и понятной. Существование императивных директив в > > декларативном конфиге nginx, скорее можно рассматривать как баг. > > Кроме того, вы таким образом создаете существенный layering violation: > то, за что должно отвечать приложение (за URI, которые оно генерирует > и обрабатывает), частично оказывается вынесено на веб-сервер и > изменения > в приложении начинают требовать правки конфигурации веб-сервера. > Особенно это весело когда программист и админ - не одно лицо, обычно > админы в таких случаях постоянно про себя матерят разработчиков, а те > пинают "ленивых и криворуких" админов. > > Что касается производительности, то я не ручаюсь сказать, что будет > быстрее, но уверен, что разница, если она и есть в какую-либо сторону, > > неизмеримо мала. Вот с этим как раз и соглашусь - правки в конфигурации веб-сервера надо внести и потом перезапустить сервер. А на продашене это ой как не хочется делать, даже если перезагрузка очень быстрая Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245884,245901#msg-245901 From me at kemko.ru Sun Dec 29 13:45:18 2013 From: me at kemko.ru (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JDQvdC00YDQtdC10LI=?=) Date: Sun, 29 Dec 2013 17:45:18 +0400 Subject: Rewrite+resolver In-Reply-To: <39c78b8761bf748dfec4791f1f9f2742.NginxMailingListRussian@forum.nginx.org> References: <2231636.zd6BvjxcJf@vbart-laptop> <39c78b8761bf748dfec4791f1f9f2742.NginxMailingListRussian@forum.nginx.org> Message-ID: 29 декабря 2013 г., 17:02 пользователь buddha написал: > Вот с этим как раз и соглашусь - правки в конфигурации веб-сервера надо > внести и потом перезапустить сервер. А на продашене это ой как не хочется > делать, даже если перезагрузка очень быстрая > Ну, перезагружать-то (в обычном понимании этого слова) никто не заставляет: http://nginx.org/ru/docs/control.html#reconfiguration -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Sun Dec 29 16:19:43 2013 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sun, 29 Dec 2013 20:19:43 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvQuCDQv9C+INGD0LzQvtC70YfQsNC90LjRjg==?= In-Reply-To: References: Message-ID: <13614202.GARY9gDUlL@vbart-laptop> On Sunday 29 December 2013 12:30:39 Алексей Сундуков wrote: > [~]# uname -a > Linux ww-realty.ru 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 > GNU/Linux > [~]# nginx -v > nginx version: nginx/1.2.1 > [~]# nginx -V > nginx version: nginx/1.2.1 > 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-pcre-jit --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=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-auth-pam > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-echo > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-upstream-fair > --add-module=/tmp/buildd/nginx-1.2.1/debian/modules/nginx-dav-ext-module > На всякий случай прокомментирую. Это пакет из неофициального репозитория и к тому же устаревшей версии. Правильно nginx ставить отсюда: http://nginx.org/ru/linux_packages.html -- Валентин Бартенев http://nginx.com/ From denis at webmaster.spb.ru Sun Dec 29 23:25:11 2013 From: denis at webmaster.spb.ru (denis) Date: Mon, 30 Dec 2013 03:25:11 +0400 Subject: =?UTF-8?B?bGltaXRfcmVxX3pvbmUg0L3QsCDQutC+0L3QutGA0LXRgtC90YvQuSB1cmw=?= Message-ID: <52C0AF57.9070001@webmaster.spb.ru> Приветствую. Есть необходимость ограничить обращения к конкретному урлу, причём не учитывая аргументов. То есть что-то вроде limit_req_zone $server_name$uri zone=one:10m 5r/m; location = /lalala { ... limit_req zone=one nodelay; } при этом все ссылки вида /lalala?aaa=bbb также должны обработаться. Корректна ли конструкция $server_name$uri ? И как описывать путь до "?" И попутно такой вопрос: точно ли r/m работает корректно? Есть подозрение, что оно работает неправильно... прописана зона с описанием limit_req_zone $server_name zone=one:10m 5r/m; location тот же. Должны первые 5 запросов пропустить, остальные в течении минуты - срезать. По факту - уже даже 2 может быть срезан, что нам вообще не подходит. При этом запрос через 10с - может быть успешным.. Тесты на выделенном сервере, с перезапущенным через stop+start сервисом, чтобы исключить кэши. nginx 1.4.4 From vbart at nginx.com Mon Dec 30 00:05:19 2013 From: vbart at nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 30 Dec 2013 04:05:19 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0X3JlcV96b25lINC90LAg0LrQvtC90LrRgNC10YLQvdGL0LkgdXJs?= In-Reply-To: <52C0AF57.9070001@webmaster.spb.ru> References: <52C0AF57.9070001@webmaster.spb.ru> Message-ID: <154265520.YPV5qHsR9X@vbart-laptop> On Monday 30 December 2013 03:25:11 denis wrote: > Приветствую. > > Есть необходимость ограничить обращения к конкретному урлу, причём не > учитывая аргументов. То есть что-то вроде > limit_req_zone $server_name$uri zone=one:10m 5r/m; > > location = /lalala { > ... > limit_req zone=one nodelay; > } > > при этом все ссылки вида /lalala?aaa=bbb также должны обработаться. > Корректна ли конструкция $server_name$uri ? И как описывать путь до "?" > Некорректна, поскольку директива limit_req_zone может принимать только одну переменную. Читайте документацию: http://nginx.org/r/limit_req_zone/ru Правильно будет разнести все хосты по отдельным блокам server и на каждый выделить свою зону с $uri. В крайнем случае можно воспользоваться директивой set: set $limit $server_name$uri; http://nginx.org/r/set/ru > И попутно такой вопрос: точно ли r/m работает корректно? Точно. > Есть подозрение, что оно работает неправильно... > прописана зона с описанием > limit_req_zone $server_name zone=one:10m 5r/m; > location тот же. Должны первые 5 запросов пропустить, остальные в > течении минуты - срезать. Не должны. Встречный вопрос: если в городе ограничение скорости 60 км/ч, то должны ли вы проехать минимум 60 километров прежде чем может быть зафиксировано превышение скорости? В вашей конфигурации, чтобы запрос был отклонен, достаточно послать его с интервалом менее 12 секунд от предыдущего успешного. -- Валентин Бартенев From zmey1992 at ya.ru Mon Dec 30 06:12:31 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Mon, 30 Dec 2013 10:12:31 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvQuCDQv9C+INGD0LzQvtC70YfQsNC90LjRjg==?= In-Reply-To: References: Message-ID: <112351388383951@web27m.yandex.ru> Я добавлю, что в любом случае параметры сборки nginx можно посмотреть запустив бинарник с параметром -V: ~$ nginx -V 29.12.2013, 08:58, "Serg" : > Здравствуйте, > >  Всех с наступающими праздниками! > >  Подскажите пожалуйста, например в поставке debian, с каким набором модулей компилируют nginx? > > С уваженим, >  Сергей Мелехов > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Mon Dec 30 19:22:01 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 30 Dec 2013 23:22:01 +0400 Subject: Rewrite+resolver In-Reply-To: References: <022f307a7c7aac672d71704aad350c9f.NginxMailingListRussian@forum.nginx.org> <20131228123502.GS95113@mdounin.ru> Message-ID: <20131230192201.GV95113@mdounin.ru> Hello! On Sat, Dec 28, 2013 at 06:14:57PM +0400, Daniel Podolsky wrote: > 2013/12/28 Maxim Dounin : > > Когда-то я думал, что rewrite'ы - это плохо. > а чем плохо - рерайты? > > задача возникает часто, работает оно хорошо, и, вроде, без подводных камней. У rewrite'ов есть более одной проблемы, но наиболее важная состоит в том, что конфиг, написанный на rewrite'ах, очень дорого подерживать. -- Maxim Dounin http://nginx.org/ From mdounin at mdounin.ru Mon Dec 30 19:41:06 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 30 Dec 2013 23:41:06 +0400 Subject: =?UTF-8?B?UmU6IENPUFkg0Lgg0L3QtdGB0YPRidC10YHRgtCy0YPRjtGJ0LDRjyDQtNC40YA=?= =?UTF-8?B?0LXQutGC0L7RgNC40Y8gPSA1MDAgSW50ZXJuYWwgU2VydmVyIEVycm9y?= In-Reply-To: <15510205824.20131229141129@softsearch.ru> References: <816828878.20131228152047@softsearch.ru> <20131228130043.GT95113@mdounin.ru> <15510205824.20131229141129@softsearch.ru> Message-ID: <20131230194106.GW95113@mdounin.ru> Hello! On Sun, Dec 29, 2013 at 02:11:29PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > >> Бага или фича? > >> > >> Если через WebDAV копируется несуществующий файл в существующей > >> директории, то выдаётся 404. Но если копируется файл из несуществующей > >> директории в неё же, то выдаётся 500 - Internal Server Error. Это > >> правильное поведение или должно 404 тоже выдаваться? > > > Если исходный файл/каталог не сущетсвует, то в любом случае должно > > выдаваться 404. > > >> Пример: > >> копируем http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg > >> в http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg.tmp > >> и получаем: 500 Internal Server Error > >> > >> в error_log-е: > >> 2013/12/28 11:54:28 [crit] 2845#0: *4749150 open() > >> "/opt2/beon/i39/17/74/1467417/47/avatars/4.jpeg.tmp" failed (2: No > >> such file or directory), client: 89.208.146.210, server: > >> i39.beon.ru, request: "COPY > >> http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg HTTP/1.1", host: > >> "i39.beon.ru" > >> > >> в access.log-e: > >> 28/Dec/2013:11:54:28 +0400 500 89.208.146.210 353 i39.beon.ru > >> "COPY http://i39.beon.ru/17/74/1467417/47/avatars/4.jpeg HTTP/1.1" > >> "-" "-" "-" "-" "-" "-" "close" > > > Должно быть так: > > > 2013/12/28 16:51:35 [error] 33014#0: *1 lstat() > > "/path/to/foo/bar/bazz" failed (2: No such file or directory), > > client: 127.0.0.1, server: , request: "COPY /foo/bar/bazz HTTP/1.1", > > host: "localhost" > > 127.0.0.1 - - [28/Dec/2013:16:51:35 +0400] "COPY /foo/bar/bazz HTTP/1.1" 404 168 "-" "-" > > > То, что у тебя сломался open(), намекает на то, что в процессе > > выполнения этого запроса кто-то удалил каталог. > > Каталоги там никто не удаляет точно. Вся работа идёт через nginx, а он > удалять каталоги не умеет и на встроенном перле у меня ничего не > написано. И ошибка эта воспроизводится не всегда. Вообще-то, nginx удалять каталоги умеет, нужно просто правильно попросить. Но это не твой случай, см. ниже. > Ошибка: Couldn't copy http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif => http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif.tmp: 500 Internal Server Error > > Посмотрел debug-лог. Я там тоже накрутил с конфигом, но 500 всёравно > быть не должно ИМХО: [...] > 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http request line: "COPY http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif HTTP/1.1" [...] > 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http header: "Destination: http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif.tmp" [...] > 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http script regex: "^(/\d+/\d+/\d+/)\d+/(avatars/.+|design/.+|0\.(?:gif|jpeg|png|mp3))$" > 2013/12/29 14:00:55 [notice] 78336#0: *10484311 "^(/\d+/\d+/\d+/)\d+/(avatars/.+|design/.+|0\.(?:gif|jpeg|png|mp3))$" matches "/43/96/1009643/43/avatars/9.gif", client: 89.208.146.210, server: i41.beon.ru, request: "COPY http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif HTTP/1.1", host: "b.i41.beon.ru" > 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http script copy: "/" > 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http script capture: "/43/96/1009643/" > 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http script capture: "avatars/9.gif" > 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http script regex end > 2013/12/29 14:00:55 [notice] 78336#0: *10484311 rewritten data: "//43/96/1009643/avatars/9.gif", args: "", client: 89.208.146.210, server: i41.beon.ru, request: "COPY http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif HTTP/1.1", host: "b.i41.beon.ru" [...] > 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http copy from: "/opt2/beon/i41//43/96/1009643/avatars/9.gif" > 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http copy to: "/opt2/beon/i41/43/96/1009643/43/avatars/9.gif.tmp" > 2013/12/29 14:00:55 [debug] 78336#0: *10484311 malloc: 0000000806E68000:65536 > 2013/12/29 14:00:55 [crit] 78336#0: *10484311 open() "/opt2/beon/i41/43/96/1009643/43/avatars/9.gif.tmp" failed (2: No such file or directory), client: 89.208.146.210, server: i41.beon.ru, request: "COPY http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif HTTP/1.1", host: "b.i41.beon.ru" Из вышепроцитированного более или менее очевидно, что копируют существующий файл, однако в несуществующий каталог. Возврат 500 в подобной ситуации - не то чтобы лучшее из возможного, но как минимум объясним. IMHO, это классическая иллюстрация к соседнему треду про rewrite'ы. :) -- Maxim Dounin http://nginx.org/ From postmaster at softsearch.ru Mon Dec 30 20:57:06 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 31 Dec 2013 00:57:06 +0400 Subject: =?UTF-8?B?UmVbMl06IENPUFkg0Lgg0L3QtdGB0YPRidC10YHRgtCy0YPRjtGJ0LDRjyDQtNC4?= =?UTF-8?B?0YDQtdC60YLQvtGA0LjRjyA9IDUwMCBJbnRlcm5hbCBTZXJ2ZXIgRXJyb3I=?= In-Reply-To: <20131230194106.GW95113@mdounin.ru> References: <816828878.20131228152047@softsearch.ru> <20131228130043.GT95113@mdounin.ru> <15510205824.20131229141129@softsearch.ru> <20131230194106.GW95113@mdounin.ru> Message-ID: <1521711885.20131231005706@softsearch.ru> Здравствуйте, Maxim. >> > То, что у тебя сломался open(), намекает на то, что в процессе >> > выполнения этого запроса кто-то удалил каталог. >> >> Каталоги там никто не удаляет точно. Вся работа идёт через nginx, а он >> удалять каталоги не умеет и на встроенном перле у меня ничего не >> написано. И ошибка эта воспроизводится не всегда. > Вообще-то, nginx удалять каталоги умеет, нужно просто правильно > попросить. Но это не твой случай, см. ниже. Даже не пустые? ;-) >> 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http copy from: >> "/opt2/beon/i41//43/96/1009643/avatars/9.gif" >> 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http copy to: >> "/opt2/beon/i41/43/96/1009643/43/avatars/9.gif.tmp" >> 2013/12/29 14:00:55 [debug] 78336#0: *10484311 malloc: 0000000806E68000:65536 >> 2013/12/29 14:00:55 [crit] 78336#0: *10484311 open() >> "/opt2/beon/i41/43/96/1009643/43/avatars/9.gif.tmp" failed (2: No >> such file or directory), client: 89.208.146.210, server: >> i41.beon.ru, request: "COPY >> http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif HTTP/1.1", >> host: "b.i41.beon.ru" > Из вышепроцитированного более или менее очевидно, что копируют > существующий файл, однако в несуществующий каталог. Таки разглядел этот несуществующий каталог. Спасибо. > Возврат 500 в подобной ситуации - не то чтобы лучшее из возможного, > но как минимум объясним. Ну раз ошибки нет и 500 - правильный ответ, то тему можно считать закрытой. > IMHO, это классическая иллюстрация к соседнему треду про > rewrite'ы. :) Эх, если б всё было просто... :-) Да, сложность конфигов со всеми этими заменами растёт экспоненциально и уже думаешь не как сделать, а как сделать, чтобы не вводить ещё один уровень сложности. -- С уважением, Михаил mailto:postmaster at softsearch.ru From mdounin at mdounin.ru Mon Dec 30 22:52:06 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 31 Dec 2013 02:52:06 +0400 Subject: =?UTF-8?B?UmU6IENPUFkg0Lgg0L3QtdGB0YPRidC10YHRgtCy0YPRjtGJ0LDRjyDQtNC40YA=?= =?UTF-8?B?0LXQutGC0L7RgNC40Y8gPSA1MDAgSW50ZXJuYWwgU2VydmVyIEVycm9y?= In-Reply-To: <1521711885.20131231005706@softsearch.ru> References: <816828878.20131228152047@softsearch.ru> <20131228130043.GT95113@mdounin.ru> <15510205824.20131229141129@softsearch.ru> <20131230194106.GW95113@mdounin.ru> <1521711885.20131231005706@softsearch.ru> Message-ID: <20131230225206.GY95113@mdounin.ru> Hello! On Tue, Dec 31, 2013 at 12:57:06AM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > >> > То, что у тебя сломался open(), намекает на то, что в процессе > >> > выполнения этого запроса кто-то удалил каталог. > >> > >> Каталоги там никто не удаляет точно. Вся работа идёт через nginx, а он > >> удалять каталоги не умеет и на встроенном перле у меня ничего не > >> написано. И ошибка эта воспроизводится не всегда. > > > Вообще-то, nginx удалять каталоги умеет, нужно просто правильно > > попросить. Но это не твой случай, см. ниже. > > Даже не пустые? ;-) Легко, если не запрещено, см. http://nginx.org/r/min_delete_depth. > >> 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http copy from: > >> "/opt2/beon/i41//43/96/1009643/avatars/9.gif" > >> 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http copy to: > >> "/opt2/beon/i41/43/96/1009643/43/avatars/9.gif.tmp" > >> 2013/12/29 14:00:55 [debug] 78336#0: *10484311 malloc: 0000000806E68000:65536 > >> 2013/12/29 14:00:55 [crit] 78336#0: *10484311 open() > >> "/opt2/beon/i41/43/96/1009643/43/avatars/9.gif.tmp" failed (2: No > >> such file or directory), client: 89.208.146.210, server: > >> i41.beon.ru, request: "COPY > >> http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif HTTP/1.1", > >> host: "b.i41.beon.ru" > > > Из вышепроцитированного более или менее очевидно, что копируют > > существующий файл, однако в несуществующий каталог. > > Таки разглядел этот несуществующий каталог. Спасибо. > > > Возврат 500 в подобной ситуации - не то чтобы лучшее из возможного, > > но как минимум объясним. > > Ну раз ошибки нет и 500 - правильный ответ, то тему можно считать > закрытой. Возможно, имеет смысл это место допилить, чтобы нужный каталог создавался. E.g., так сейчас делает MOVE, и PUT при create_full_put_path. Но в твоём случае это бы скорее усложнило поиск проблемы, чем наоборот. > > IMHO, это классическая иллюстрация к соседнему треду про > > rewrite'ы. :) > > Эх, если б всё было просто... :-) Да, сложность конфигов со всеми > этими заменами растёт экспоненциально и уже думаешь не как сделать, а > как сделать, чтобы не вводить ещё один уровень сложности. Ну ты, насколько я понимаю, извращаешься с целью не добавлять динамический бекенд. Но когда сразу за rewrite'ами - динамический бекенд, то смысла портить себе жизнь - ну совсем мало. -- Maxim Dounin http://nginx.org/ From postmaster at softsearch.ru Tue Dec 31 09:22:25 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 31 Dec 2013 13:22:25 +0400 Subject: =?UTF-8?B?UmVbMl06IENPUFkg0Lgg0L3QtdGB0YPRidC10YHRgtCy0YPRjtGJ0LDRjyDQtNC4?= =?UTF-8?B?0YDQtdC60YLQvtGA0LjRjyA9IDUwMCBJbnRlcm5hbCBTZXJ2ZXIgRXJyb3I=?= In-Reply-To: <20131230225206.GY95113@mdounin.ru> References: <816828878.20131228152047@softsearch.ru> <20131228130043.GT95113@mdounin.ru> <15510205824.20131229141129@softsearch.ru> <20131230194106.GW95113@mdounin.ru> <1521711885.20131231005706@softsearch.ru> <20131230225206.GY95113@mdounin.ru> Message-ID: <761975646.20131231132225@softsearch.ru> Здравствуйте, Maxim. >> >> 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http copy from: >> >> "/opt2/beon/i41//43/96/1009643/avatars/9.gif" >> >> 2013/12/29 14:00:55 [debug] 78336#0: *10484311 http copy to: >> >> "/opt2/beon/i41/43/96/1009643/43/avatars/9.gif.tmp" >> >> 2013/12/29 14:00:55 [debug] 78336#0: *10484311 malloc: 0000000806E68000:65536 >> >> 2013/12/29 14:00:55 [crit] 78336#0: *10484311 open() >> >> "/opt2/beon/i41/43/96/1009643/43/avatars/9.gif.tmp" failed (2: No >> >> such file or directory), client: 89.208.146.210, server: >> >> i41.beon.ru, request: "COPY >> >> http://b.i41.beon.ru/43/96/1009643/43/avatars/9.gif HTTP/1.1", >> >> host: "b.i41.beon.ru" >> >> > Из вышепроцитированного более или менее очевидно, что копируют >> > существующий файл, однако в несуществующий каталог. >> >> Таки разглядел этот несуществующий каталог. Спасибо. >> >> > Возврат 500 в подобной ситуации - не то чтобы лучшее из возможного, >> > но как минимум объясним. >> >> Ну раз ошибки нет и 500 - правильный ответ, то тему можно считать >> закрытой. > Возможно, имеет смысл это место допилить, чтобы нужный каталог > создавался. E.g., так сейчас делает MOVE, и PUT при > create_full_put_path. > Но в твоём случае это бы скорее усложнило поиск проблемы, чем > наоборот. Буду убирать эти запросы. Они неправильные. >> > IMHO, это классическая иллюстрация к соседнему треду про >> > rewrite'ы. :) >> >> Эх, если б всё было просто... :-) Да, сложность конфигов со всеми >> этими заменами растёт экспоненциально и уже думаешь не как сделать, а >> как сделать, чтобы не вводить ещё один уровень сложности. > Ну ты, насколько я понимаю, извращаешься с целью не добавлять > динамический бекенд. Но когда сразу за rewrite'ами - динамический > бекенд, то смысла портить себе жизнь - ну совсем мало. Просто у аватарки путь на диске всегда один, а юзеры их перезаливают. Вот и было добавлено поколение аватарки, которое вырезается регэкспом. Так файл всегда один хранится, а запросы идут к последней версии и кэшируется всё правильно. -- С уважением, Михаил mailto:postmaster at softsearch.ru