Re: [PATCH] Configure: added new option --with-pcre-conf-opt=OPTIONS.
As you already have libpcre installed, you don't need nginx to build it (and you don't need sources). If nginx isn't able to find the pcre itself, use something like this to tell where to look for headers and library: ./configure --with-cc-opt=-I/usr/local/include \ --with-ld-opt=-L/usr/local/lib64 That's easy enough, then. I've built pcre, separately, with pcre-jit support enabled. Is that sufficient for nginx to use pcre-jit? I suspect that it is, and that --with-pcrejit is also simply a build-pcre-in-nginx flag? Thanks ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH] Configure: added new option --with-pcre-conf-opt=OPTIONS.
./configure --with-cc-opt=-I/usr/local/include \ --with-ld-opt=-L/usr/local/lib64 works as promised, ... make ldd objs/nginx | egrep -i pcre libpcre.so.1 = /usr/local/lib64/libpcre.so.1 (0x7fc62c7e7000) Thanks. That is, it's only applies when nginx is going to build PCRE library itself. Clear. To actually activate JIT compilation, you'll also need to use pcre_jit directive, see nginx.org/r/pcre_jit. Note that use of PCRE JIT may actually result in lower performance (due to more memory used to compiled regular expressions, and less effective CPU cache as a result), enabling it unconditionally may not be a good idea. Noted. Thanks! ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH] Configure: added new option --with-pcre-conf-opt=OPTIONS.
oops. not quite ... on systems where ld.so.conf does NOT point to the pcre path -- i.e, on my production rather than dev boxes -- the RUNTIME link is incorrect, ldd objs/nginx | egrep -i pcre libpcre.so.1 = /usr/lib64/libpcre.so.1 (0x7fa719a0d000) This can be remedied by rpath'ing, --with-ld-opt=' ... -L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64 -lpcre' resulting correctly in ldd objs/nginx | egrep -i pcre libpcre.so.1 = /usr/local/lib64/libpcre.so.1 (0x7f961ada1000) *IN*sensitive to local/runtime env ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Проксирование http и https в одном конигурационном файле, на порты отличные от 80 и 443
Подскажите, как можно организовать прокисрование 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
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
PHP ошибки в nginx error log
Добрый день Имеется связка 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@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проксирование http и https в одном конигурационном файле, на порты отличные от 80 и 443
Тут наверное я еще не совсем правильно выразился, нужно описать конфигурацию
не то чтобы в одном когфиге, а в одном блоке 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@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проксирование http и https в одном конигурационном файле, на порты отличные от 80 и 443
Hello!
On Wed, Dec 11, 2013 at 10:23:50AM -0500, mnsold wrote:
Тут наверное я еще не совсем правильно выразился, нужно описать конфигурацию
не то чтобы в одном когфиге, а в одном блоке server {} и без повториний
location {} с разницей только http-https.
Повторюсь - вы, как мне кажется, не с той стороны подходите к
проблеме. Бояться надо не повторов с разницей только, а попыток
унификации ценой создания чудовищных монстров вместо
конфигурации.
Для того, чтобы избегать повторов - в nginx'е есть наследование
конфигурации, а равно директива include. Если этого нехватает -
обычно правильнее взять в руки любимый шаблонизатор, а не пытаться
то же самое сделать с помощью условных проверок в процессе
обработки запросов.
--
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: патч для отключения заголовков Connection: keep-alive (еще раз)
11 декабря 2013 г., 20:41 пользователь Maxim Dounin
mdou...@mdounin.ru написал:
Hello!
On Wed, Dec 11, 2013 at 01:39:21AM +0600, Илья Шипицин wrote:
11 декабря 2013 г., 0:43 пользователь Maxim Dounin mdou...@mdounin.ru
написал:
Hello!
On Tue, Dec 10, 2013 at 11:12:16PM +0600, Илья Шипицин wrote:
10 декабря 2013 г., 22:37 пользователь Maxim Dounin
mdou...@mdounin.ru написал:
Hello!
On Tue, Dec 10, 2013 at 09:22:02PM +0600, Илья Шипицин wrote:
10 декабря 2013 г., 19:37 пользователь Maxim Dounin
mdou...@mdounin.ru написал:
Hello!
On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote:
10 декабря 2013 г., 17:13 пользователь Maxim Dounin
mdou...@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
Странно видить попытки изобрести велосипед заново вместо того,
чтобы заняться тестированием и последующим убеждением, что это
надо закоммитить, тем более про тщательное тестирование было
явно написано. ;)
это именно та тема и есть, сейчас дошли руки тщательно
протестировать. я запустил в продакшн.
Меня в первую очередь удивило, что вместо патча, нарисованного ещё
полгода назад, к письму о потестировать прилагается совсем
другой патч, с чуть-чуть другими условиями и стилистическими
проблемами. Я бы всё-таки рекомендовал тестировать то, что потом
будем коммитить.
ждем пару месяцев (и, если проблем не всплывает, считаем, что все
ок) ?
Я, честно говоря, пребывал в надежде, что патч уже полгода
тестируется. ;)
Но если нет - то, видимо, так и делаем. Только просьба - взять
для тестирования патч в том виде, в каком его предполагается
коммитить, 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@nginx.org
Re: Проксирование http и https в одном конигурационном файле, на порты отличные от 80 и 443
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;
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: патч для отключения заголовков Connection: keep-alive (еще раз)
Hello!
On Wed, Dec 11, 2013 at 10:41:42PM +0600, Илья Шипицин wrote:
11 декабря 2013 г., 20:41 пользователь Maxim Dounin
mdou...@mdounin.ru написал:
Hello!
On Wed, Dec 11, 2013 at 01:39:21AM +0600, Илья Шипицин wrote:
11 декабря 2013 г., 0:43 пользователь Maxim Dounin mdou...@mdounin.ru
написал:
Hello!
On Tue, Dec 10, 2013 at 11:12:16PM +0600, Илья Шипицин wrote:
10 декабря 2013 г., 22:37 пользователь Maxim Dounin
mdou...@mdounin.ru написал:
Hello!
On Tue, Dec 10, 2013 at 09:22:02PM +0600, Илья Шипицин wrote:
10 декабря 2013 г., 19:37 пользователь Maxim Dounin
mdou...@mdounin.ru написал:
Hello!
On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote:
10 декабря 2013 г., 17:13 пользователь Maxim Dounin
mdou...@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
Странно видить попытки изобрести велосипед заново вместо того,
чтобы заняться тестированием и последующим убеждением, что это
надо закоммитить, тем более про тщательное тестирование было
явно написано. ;)
это именно та тема и есть, сейчас дошли руки тщательно
протестировать. я запустил в продакшн.
Меня в первую очередь удивило, что вместо патча, нарисованного ещё
полгода назад, к письму о потестировать прилагается совсем
другой патч, с чуть-чуть другими условиями и стилистическими
проблемами. Я бы всё-таки рекомендовал тестировать то, что потом
будем коммитить.
ждем пару месяцев (и, если проблем не всплывает, считаем, что все
ок) ?
Я, честно говоря, пребывал в надежде, что патч уже полгода
тестируется. ;)
Но если нет - то, видимо, так и делаем. Только просьба - взять
для тестирования патч в том виде, в каком его предполагается
коммитить, 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, нормально
скалирующиеся
Re: патч для отключения заголовков Connection: keep-alive (еще раз)
12 декабря 2013 г., 0:04 пользователь Maxim Dounin mdou...@mdounin.ru написал:
Hello!
On Wed, Dec 11, 2013 at 10:41:42PM +0600, Илья Шипицин wrote:
11 декабря 2013 г., 20:41 пользователь Maxim Dounin
mdou...@mdounin.ru написал:
Hello!
On Wed, Dec 11, 2013 at 01:39:21AM +0600, Илья Шипицин wrote:
11 декабря 2013 г., 0:43 пользователь Maxim Dounin mdou...@mdounin.ru
написал:
Hello!
On Tue, Dec 10, 2013 at 11:12:16PM +0600, Илья Шипицин wrote:
10 декабря 2013 г., 22:37 пользователь Maxim Dounin
mdou...@mdounin.ru написал:
Hello!
On Tue, Dec 10, 2013 at 09:22:02PM +0600, Илья Шипицин wrote:
10 декабря 2013 г., 19:37 пользователь Maxim Dounin
mdou...@mdounin.ru написал:
Hello!
On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote:
10 декабря 2013 г., 17:13 пользователь Maxim Dounin
mdou...@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
Странно видить попытки изобрести велосипед заново вместо того,
чтобы заняться тестированием и последующим убеждением, что это
надо закоммитить, тем более про тщательное тестирование было
явно написано. ;)
это именно та тема и есть, сейчас дошли руки тщательно
протестировать. я запустил в продакшн.
Меня в первую очередь удивило, что вместо патча, нарисованного ещё
полгода назад, к письму о потестировать прилагается совсем
другой патч, с чуть-чуть другими условиями и стилистическими
проблемами. Я бы всё-таки рекомендовал тестировать то, что потом
будем коммитить.
ждем пару месяцев (и, если проблем не всплывает, считаем, что
все ок) ?
Я, честно говоря, пребывал в надежде, что патч уже полгода
тестируется. ;)
Но если нет - то, видимо, так и делаем. Только просьба - взять
для тестирования патч в том виде, в каком его предполагается
коммитить, 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)
никогда не будет. Вопрос, повторяю, стилистический.
если вопрос стилистический, давайте остановимся на моей версии. она
мне больше нравится
Да сколько угодно, я ж разве возражаю? Только тогда патч не будет
закоммичен из-за стилистических проблем. ;)
без проблем. а чтобы всем было обидно, можете себе руку отрубить.
Речь о том, что когда что-то меняется, то важна именно версия, в
которой это что-то поменялось. Подход, предполагающий явное
перечисление - работает только в условиях малого количества
версий. С ростом количества версий он становится непригодным к
использованию.
это как раз случай
Re: Проксирование http и https в одном конигурационном файле, на порты отличные от 80 и 443
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/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проксирование http и https в одном конигурационном файле, на порты отличные от 80 и 443
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
#!/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
#!/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
ripehttp://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 = !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN
http://www.w3.org/TR/html4/strict.dtd;
htmlheadtitleredirect service/title
style type=text/css
a { text-decoration:none; display: block; }
a:link { color: black; }
a:visited { color: black; }
table { border: #00 1px solid; border-collapse: collapse; margin: 0 0 0 0;
padding 0 0 0 0; }
tr { margin: 0 0 0 0; padding 0 0 0 0; }
td { margin: 0 0 0 0; padding 0 0 0 0; }
table.left { margin-left: 64px; margin-right:auto; }
tr.ff { background-color: #ff; }
tr.ee { background-color: #ee; }
td.name { text-align: right; font-size: x-large; font-family: Courier New;
font-weight: bold; padding-left: 10px; padding-right: 10px; }
td.desc { text-align: left; font-size: large; font-family: Arial;
padding-right: 10px; }
div.footer { float: right; }
/style
/headbodytable class=left cellpadding=0
Re: Проксирование http и https в одном конигурационном файле, на порты отличные от 80 и 443
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
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Upstrea/ Keepalive strange behaviour
Hello Maxim, As per HTTP specification, persistent connection can be closed by the server at any time, and clients should handle this. That is, that's more or less normal, and nginx is expected to handle this fine by using another upstream server if this happens. Thanks for your reply. I suspected that this behavior was normal but it's good to have a confirmation from your side. -- David Donchez - Lead Engineer, Research Engineering SmartJog | T: +33 1 5868 6190 27 Blvd Hippolyte Marquès, 94200 Ivry-sur-Seine, France www.smartjog.com | a TDF Group company ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
$_SERVER['QUERY_STRING'] plus-signs and whitespace
Hello, I have the following Problem with Nginx 1.2.1-2.2 running on 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux A String like $_SERVER['QUERY_STRING'] = test=1+2 will get $_GET['test'] = 1 2 I have found the following: |$_GET||[||q||] = ||strtr||(||$_GET||[||q||], ||+||, || ||);| at http://www.dmuth.org/node/1268/how-get-rid-annoying-plus-signs-drupal-under-nginx Is there a way to do this, in nginx config? Regards, basti ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: $_SERVER['QUERY_STRING'] plus-signs and whitespace
'+' in url equla ' ' (base64). if value has '+', you must encode it. example: $a = 1+1; echo urlencode($a); the correct url is: http://x.com/?test=1%2B1; -- smallfish http://chenxiaoyu.org On Wed, Dec 11, 2013 at 6:19 PM, basti black.flederm...@arcor.de wrote: Hello, I have the following Problem with Nginx 1.2.1-2.2 running on 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux A String like $_SERVER['QUERY_STRING'] = test=1+2 will get $_GET['test'] = 1 2 I have found the following: $_GET[q] = strtr($_GET[q], +, ); at http://www.dmuth.org/node/1268/how-get-rid-annoying-plus-signs-drupal-under-nginx Is there a way to do this, in nginx config? Regards, basti ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Nginx Deployments in Practice
I build packages using omnibus - https://github.com/bakins/omnibus-nginx ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Subdomains no longer work
Thanks for the DNS hint, my provider must have done something wrong, now it is fixed, great! Posted at Nginx Forum: http://forum.nginx.org/read.php?2,244807,245415#msg-245415 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Nginx Deployments in Practice
2013/12/11 Brian Akins br...@akins.org: I build packages using omnibus - https://github.com/bakins/omnibus-nginx Thanks Brian. It appears omnibus-nginx does not contain the nginx sources. Is it safe to assume you provide them? What version of nginx do you currently use? Do you have any custom code that might create conflicts when stable changes from 1.4.4 to X (would X be 1.4.6 or 1.6)? Jeff ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: [Patch] possible mutex starvation issue affects all nginx Linux versions.
From the patch author:
Hi Maxim,
I apologize for my late reply: I just had now time to sort this out.
The short answer to your remarks is:
the first patch is partially correct, just incomplete, and could be easily
completed with the addition of a call to ngx_disable_accept_events(...)
addressing the issue of 2 workers accepting connections at the same time.
The second one is windows only and as correct and atomical as the unix only
ngx_unlock_mutexes(), addressing the very same issue that one is for (which
btw showed up during my tests) but being just one line long.
The long answer follows and, well, is quite long.
So before everything else, and for the sake of clarity:
accept mutex patching has been performed on codebase derived by nginx 1.5.6
after properly re-enabling it (the accept_mutex) removing the following
disable lines in ngx_event.c
#if (NGX_WIN32)
/*
* disable accept mutex on win32 as it may cause deadlock if
* grabbed by a process which can't accept connections
*/
ngx_use_accept_mutex = 0;
#endif
Thus submitted patch lines are not useless and are part of a larger patch
included in Catepillar 1.5.7.1.
The latter (Caterpillar) fully works distributing correctly the workload to
any number of configured process workers (not just one of the configured
number of them).
Now getting to specific proposed patches:
A) about the added line ngx_accept_mutex_held=0 in ngx_event.c
259 if (ngx_accept_mutex_held) {
--+ ngx_accept_mutex_held=0;
260 ngx_shmtx_unlock(ngx_accept_mutex);
261 }
that is not wrong, it's just incomplete.
In fact, first of all, it pairs with the similar one in
src/event/ngx_event_accept.c, line 402
which was patched in Caterpillar and that you too found later in your in
1.5.7.
The problem with this one (line 402) was that when ngx_accept_mutex_held's
process *local* variable and the accept_mutex *global* to all nginx
processes (being it allocated in shared memory) got out of synch.
This resulted (as it has been showed in tests) in more than a worker process
locally 'thinking' to have the ownership of the accept_mutex at the same
time.
The latter interfers in the call of their respective
ngx_disable_accept_events(...) in turn leading, because of nasty time
synching, to no worker being able to enabling them anymore and amounting to
all workers (so the whole server) unable to handle any further connection.
The line above, between 259 and 260, tried to fix this too, but, there, a
call to ngx_disable_accept_events(...) is missing.
In fact to be completely correct and not resulting in partially incorrect
behaviour as you correctly pointed out, such a call must be added too.
This can be done moving that 'if' completely patched code
if (ngx_accept_mutex_held) {
ngx_disable_accept_events(cycle);
ngx_accept_mutex_held=0;
ngx_shmtx_unlock(ngx_accept_mutex);
}
to ngx_event_accept.c (being ngx_disable_accept_events(...) internal
linkage) in a dedicated function, for example
void ngx_release_accept_mutex(ngx_cycle_t *cycle){ /* the if above */ }
which then gets called at 259 in ngx_event.c instead of the 'if' itself.
BTW to make the patch complete the 'if', in ngx_trylock_accept_mutex, where
ngx_disable_accept_events() is called should be removed since substituted by
that ngx_release_accept_mutex() call.
All of this is to avoid a partial incorrect behaviour that the 'if', as it
is now,
259 if (ngx_accept_mutex_held) {
260 ngx_shmtx_unlock(ngx_accept_mutex);
261 }
causes at the end of an iteration when the accept mutex was held:
the mutex is released in the 'if' above but the
ngx_disable_accept_events(...) won't be called until the next iteration with
ngx_trylock_accept_mutex(...).
Thus in the meanwhile another worker could succeed to acquire the accept
mutex, via ngx_trylock_accept_mutex(...), and start to accept connections as
well ( ngx_enable_accept_events() is called in ngx_trylock_accept_mutex when
mutex is acquired successfully).
This means that 2 workers at the same time can accept connections and this
goes against the reason of an accept mutex itself reasonably not being not
that the intended behaviour.
B) About the second proposed patch:
the 3 lines
if(*ngx_accept_mutex.lock==ngx_processes[n].pid) {
*ngx_accept_mutex.lock=0;
}
make a patch to prevent server's accept_mutex deadlock when its owning
worker process dies unexpectedly (program crash while processing a
request/answer or task manager's abrupt termination).
This is a scenario that occurred several times while testing and, when
showing up, lead to server's workers unable to accept any further
connection.
Given that, unlike in the unix version with its ngx_unlock_mutexes(), this
scenario is not addressed in the windows version and, as said, the above
lines are meant to fix it.
They are correct and thread-safe (the operation is atomic) *in the mentioned
specific scenario in which they are meant to be executed* because:
1) they are
Hg checkout missing config and friends
I performed a checkout to the latest stable: $ hg clone http://hg.nginx.org/nginx -u release-1.4.4 I tried to run config, and it appears to be missing: $ ./config -bash: ./config: No such file or directory $ nginx-release-1.4.4$ ls autoconfcontribdocsmiscsrc The file is present in the tarball on the website. How does one get all the files for release-1.4.4? (Forgive me if I only need to copy the one file. Its not readily apparent to me what I should do at this point). Thanks in advance. ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: OpenSSL Locks
On Wed, Dec 11, 2013 at 10:25 AM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Wed, Dec 11, 2013 at 05:55:16AM -0500, Jeffrey Walton wrote: I need to do some additional processing with OpenSSL in a custom module. I noticed ngingx does not set any locks in ngx_ssl_init (from ngx_event_openssl.c). A few questions: 1) Should lock installation be guarded on NGX_THREADS or something else? 2) Where is most appropirate to initialize the locks: ngx_init_threads or ngx_ssl_init (or somewhere else)? 3) Is the project interested in a patch? (Per http://nginx.org/en/docs/contributing_changes.html, thanks Maxim). There are basically no threads support in nginx (it was experimental and broken for a long time with the exception of some win32-related stuff), so it's not clear why you need locks at all. Thanks Maxim. The source code is full of: #if (NGX_THREADS) ... #endif I thought they were needed. My bad. Jeff ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Hg checkout missing config and friends
Hey, $ ./config -bash: ./config: No such file or directory ./auto/configure Best regards, Piotr Sikora ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: [Patch] possible mutex starvation issue affects all nginx Linux versions.
Hello! On Wed, Dec 11, 2013 at 07:57:32AM -0500, itpp2012 wrote: [...] A) about the added line ngx_accept_mutex_held=0 in ngx_event.c [...] The line above, between 259 and 260, tried to fix this too, but, there, a call to ngx_disable_accept_events(...) is missing. In fact to be completely correct and not resulting in partially incorrect behaviour as you correctly pointed out, such a call must be added too. This is wrong as well. There is no reason to disable accept events till we are sure that we wasn't able to re-aquire accept mutex before going into the kernel to wait for events. It's just waste of resources. You are misunderstanding the code, probably becase the ngx_accept_mutex_held variable has somewhat misleading name. It is not expected to mean we have the accept mutex locked, it means we had the accept mutex locked on previous iteration, we have to disable accept events if we won't be able to re-aquire it. There is no need to fix it, it's not broken. [...] B) About the second proposed patch: [...] Hopefully at this point it should be clear enough that releasing the accept_mutex directly with *ngx_accept_mutex.lock=0; is as much safe as calling ngx_shmtx_force_unlock(), the choice of which one I just deem cosmetic (they're functionally equivalent): my choice then went for the more performant, straight variable assignment. Even considering the code currently there for win32 version, there is no guarantee that reading *ngx_accept_mutex.lock is atomic. While usually it is, in theory it can be non-atomic, and the code will start doing wrong things due to the if() check unexpectedly succeeding. NOt wanting to make this post longer than it is I conclude just mentioning that, as of now, the accept mutex is the only mutex living in shared memory so unlocking other possibly shared mutexes is as well unrequired. That's not true. Something like $ grep -r shmtx_lock src/ will give you an idea where shared memory mutexes are used in nginx. While it's tricky to get all of this working on modern Windows versions with ASLR, the accept mutex is certainly not the only shared memory mutex used in nginx. As I already wrote, I don't object adding an unlock here, but I would like to see the code which is correct and in-line with the unix version of the code. -- Maxim Dounin http://nginx.org/ ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Imap proxy
Hello Maxim, Usually is normal setup of EOip tunnels though transport ipsec (transparent lan). And from security prospective the most bigger threat is coming from inside. Outside intrusion possible, but it match more complicated. I confirm that plain 143 proxy working good. I just wonder about this message. 2013/12/05 00:05:40 [error] 20003#0: *1 auth http server 127.0.0.1:80 did not send server or port while in http auth state, client: 10.12.130.102, server: 0.0.0.0:993, login: testuser1 Posted at Nginx Forum: http://forum.nginx.org/read.php?2,245255,245442#msg-245442 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: alias
On Tue, Dec 10, 2013 at 10:17:25PM +, Matthew Ngaha wrote:
The problem i've been having after looking in the error logs,is that
it's still trying to find /admin/ in the default html root.
That suggests that the configuration you are editing, and the
configuration that nginx is using, are not the same.
You can test by adding the following line:
location = /test/ {return 200 This is a test\n;}
just after the server_name line and reloading nginx.
If curl -i http://localhost/test/; does not show you This is a test,
then that's your problem.
I think that's the problem also. After doing that, curl returns 404
Not Found aswell. I then changed root from html to something else just
to test it was using a different configuration file. I changed it on
both:
/usr/local/nginx-1.4.3/conf/nginx.conf
/usr/local/nginx/conf-1.4.3/nginx.conf.default
but localhost still returns the main nginx welcome index page and not
the index.html in my test root dir that was in /var/www/testing
I ran the linux command locate and here's its output..
:~$ locate nginx.conf
/home/matthew/src/nginx-1.4.3/conf/nginx.conf
/usr/local/nginx-1.4.3/conf/.nginx.conf.swp
/usr/local/nginx-1.4.3/conf/nginx.conf
/usr/local/nginx-1.4.3/conf/nginx.conf.default
/usr/local/nginx-1.4.3/conf/nginx.conf~
I wasn't aware of the 1st result returned so i also edited this conf
file. But still no luck. I have no idea where to look for the file or
how to pick a default one for nginx to always use:(
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: alias
On Wed, Dec 11, 2013 at 08:20:51PM +, Matthew Ngaha wrote: On Tue, Dec 10, 2013 at 10:17:25PM +, Matthew Ngaha wrote: That suggests that the configuration you are editing, and the configuration that nginx is using, are not the same. /home/matthew/src/nginx-1.4.3/conf/nginx.conf /usr/local/nginx-1.4.3/conf/.nginx.conf.swp /usr/local/nginx-1.4.3/conf/nginx.conf /usr/local/nginx-1.4.3/conf/nginx.conf.default /usr/local/nginx-1.4.3/conf/nginx.conf~ I wasn't aware of the 1st result returned so i also edited this conf file. But still no luck. I have no idea where to look for the file or how to pick a default one for nginx to always use:( That's something you'll have to find. ps with arguments may let you see which nginx binary is running, and it might show you which config file it is reading (if it not the compiled-in default). Until you can reliably stop and start nginx, configuration changes are pointless. (Just changing the config file will do nothing, until you tell nginx to read the changed config file.) Good luck with it, f -- Francis Dalyfran...@daoine.org ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Nginx Deployments in Practice
Omnibus seems use AgentZh's ngx tar.gz. See https://github.com/bakins/omnibus-nginx/blob/master/config/software/nginx.rb 2013/12/11 Jeffrey Walton noloa...@gmail.com 2013/12/11 Brian Akins br...@akins.org: I build packages using omnibus - https://github.com/bakins/omnibus-nginx Thanks Brian. It appears omnibus-nginx does not contain the nginx sources. Is it safe to assume you provide them? What version of nginx do you currently use? Do you have any custom code that might create conflicts when stable changes from 1.4.4 to X (would X be 1.4.6 or 1.6)? Jeff ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx -- - http://www.54chen.com 坚持科学 分享技术 http://twitter.com/54chen ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Nginx Deployments in Practice
Hello! On Wed, Dec 11, 2013 at 5:55 PM, 54chen wrote: Omnibus seems use AgentZh's ngx tar.gz. Just a side note: please never never put capital letters into my nick because I hate that. If you really want to capitalize names, please use my first name, Yichun, instead. Thank you for the cooperation. Best regards, -agentzh ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
