Re: nginx-ru Digest, Vol 62, Issue 23

[Андрей Середенко]

ухх, ребят.. читать вас - одно сплошное удовольствие =)

17 декабря 2014 г., 21:46 пользователь  написал:
>
> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
> отправлять по адресу
> nginx-ru@nginx.org
>
> Для изменения параметров подписки вы можеже использовать веб-страницу
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> Для получения информации о том, как пользовать почтовым интерфейсом,
> отправьте письмо, в теле или теме которого будет слово 'help', по
> адресу:
> nginx-ru-requ...@nginx.org
>
> Адрес человека, ответственного за этот список рассылки:
> nginx-ru-ow...@nginx.org
>
> При ответе, пожалуйста, измение тему письма так, чтобы она была более
> содержательной чем "Re: Содержание дайджеста списка рассылки
> nginx-ru..."
>
> Today's Topics:
>
>1. Re: Всем: Платная опция и невозможность использования Nginx
>   под Windows (Dmitry)
>2. Re: Всем: Платная опция и невозможность использования Nginx
>   под Windows (Gena Makhomed)
>3. Re: Всем: Платная опция и невозможность использования Nginx
>   под Windows (sofiamay)
>4. Re: Всем: Платная опция и невозможность использования Nginx
>   под Windows (Vadim A. Misbakh-Soloviov)
>5. Re: Всем: Платная опция и невозможность использования Nginx
>   под Windows (Maxim Dounin)
>
>
> -- Пересылаемое сообщение --
> From: Dmitry 
> To: nginx-ru@nginx.org
> Cc:
> Date: Wed, 17 Dec 2014 21:39:39 +0400
> Subject: Re: Всем: Платная опция и невозможность использования Nginx под
> Windows
>
> Ну как бы так: если Майкрософт захочет профинансировать жнджинкс для
> своего пакета - ок, понятно. А так не ясно. Адекватный алмин на этой
> платформе - не очевидно.
> 17.12.2014 21:36 пользователь "Dmitry" 
> написал:
>
>> Все больше все больше и больше уходит с рынка серверных систем и остаётся
>> только в интранете офисного пакета. Платного. Довольно дорогого.
>> 17.12.2014 21:31 пользователь "sofiamay"  написал:
>>
>>> Nginx всё больше и больше используется в Windows. Многим нет смысла
>>> разбираться с Linux, если есть готовый Windows сервер и проекты у которых
>>> нет привязки к Linux или проекты которые требуют минимальной поддержки
>>> PHP.
>>> На Linux проблема работы с PHP совершенно не актуальна ввиду наличия
>>> PHP-FPM. Но что делать Windows пользователям? Почему такая дискриминация.
>>>
>>> Я просто не понимаю. Вон выше даже дали ссылку на
>>> http://nginx-win.ecsds.eu/
>>> отличную сборку, которая может держать десятки тысяч коннектов. Осталось
>>> решить вопрос с PHP, Максим, пожалуйста, прислушайтесь. Проблему нужно
>>> решить :(
>>>
>>> Вы отсылаете к least_conn, но отсылка к least_conn не имеет смысла, что
>>> толку от того, что запросы будут перенаправляться к наименее загруженному
>>> бэкенду, если они и так все заняты? Нужно сделать чтобы в Windows Nginx
>>> вообще не мог делать более 1 активного коннекта к бэкенду и ждал пока
>>> хоть
>>> один освободится. Это делает опция max_conns которую почему-то добавили в
>>> платную подписку, хотя оно и понятно почему - не подумали про Windows.
>>>
>>> Как уже писалось выше - есть прекрасная сборка от nginx-win.ecsds.eu, но
>>> чтобы её использовать с PHP осталось решить вопрос с ограничением
>>> коннекта к
>>> бэкенду. Уверен, что популярность Nginx под Windows выстрелит, как только
>>> его можно будет начать нормально использовать (первую проблему с 1024
>>> подключений за авторов Nginx решили в nginx-win.ecsds.eu, вторая с
>>> работой
>>> PHP пока не решена).
>>>
>>> Максим, знаю что вы разработчик, пожалуйста, пойдите навстречу Windows
>>> пользователям. Не нужно отмахиваться от всех Windows пользователей,
>>> говоря
>>> что сервер для тестирования и хватит вам 10-20 однокременных коннектов к
>>> PHP. Хотя я сам вас прекрасно понимаю и согласен что сервер на Windows
>>> это
>>> бред, но тем не менее я сам вижу что есть куча проектов которые прекрасно
>>> живут под Windows и их всё больше.
>>>
>>> Проблема есть, нужно решать, и всё дело лишь в одной опции, неужели
>>> хотение
>>> денег выше здравого смысла? Пожалуйста, помогите с решением вопроса.
>>>
>>> Posted at Nginx Forum:
>>> http://forum.nginx.org/read.php?21,255544,255584#msg-255584
>>>
>>> ___
>>> nginx-ru mailing list
>>> nginx-ru@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>>
>
> -- Пересылаемое сообщение --
> From: Gena Makhomed 
> To: nginx-ru@nginx.org
> Cc:
> Date: Wed, 17 Dec 2014 20:15:48 +0200
> Subject: Re: Всем: Платная опция и невозможность использования Nginx под
> Windows
> On 17.12.2014 19:31, sofiamay wrote:
>
>  Многим нет смысла разбираться с Linux,
>>
> > если есть готовый Windows сервер и проекты у которых
>
>> нет привязки к Linux или проекты которые требуют минимальной поддержки
>> PHP.
>>
>
> Вам нет смысла разбираться с nginx, когда есть готовый Windows сервер.
> Достаточно просто настроить его по инструкции и все будет работать.
>
> htt

О целесообразности размещения кеша Nginx в tmpfs (Linux)

[Андрей Середенко]

Привет сообществу!

Ребят, возник такой вопрос:


а есть ли профит от размещения кеша Nginx'а на tmpfs *в Linux *?


Дело в том, что когда-то, когда настраивал nginx с кешированием, натыкался
на старую рассылку, где ещё сам Игорь Сысоев рассказывал, что "*смысла в
этом нет, если только в кеш не производится много записи" **клац!
*
Но там речь шла о FreeBSD, а не про Linux. А в каком-то другом (
очередном?:) ) холливаре про "nginx + RAM cache" тоже речь шла изначально
про фряху, где потом кто-то сказал что "да ерунда это все! в линухах tmpfs
работает как пологается", на что Игорь остановил - мол, "давайте
определимся, о какой оси речь идет: линуксы или фрибсд?" Жаль, но пруф уже
не найду..

Так вот. К чему это я всё: судя по всему, организация tmpfs во FreeBSD и
Linux'ах различается. И во фряхе размещать там кеш не всегда разумно. А как
с линуксами дело обстоит, может знает кто? Увы, у меня нет достаточных
знаний, чтобы философствовать на эту тему... но может у кого эмпирики
хватает.

purpose:

хочется отказаться от варниша в пользу nginx+cache. на данный момент
работает схема с варнишем спереди и nginx'ом в бэкенде.

Однако, при попытке убрать варниш, не было обнаружено какой-либо деградации
в синтетических тестбенчах (что весьма странно). То есть, выходило что
varnish не давал никакого профита (в синтетике) в сравнении с обычным
nginx'ом ? Поэтому встал вопрос "а можно ли вообще ускорить имеющийся
результат?" В ход пошли всякие коктейли из "pure nginx", "nginx+varnish",
"nginx+pagespeed", "nginx+cache" <ещё с пару десятков комбинаций> ...
И вот, собсно, дошли до "nginx + tmpfs-cache + ..." Но, тк особого доверия
своим тестам нет никогда , а теститься на
продакшенах бывает крайне дорого:) - хочется узнать мнения сообщества.

Спасибо!

P.s. Извините за графоманство - уж очень люблю это дело :D
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx-ru Digest, Vol 59, Issue 3

[Андрей Середенко]

Спасибо, попробуем!
Про внутреннее перенаправление я как-то вообще не задумывался.. сразу, как
try_files отвалился как вариант - так и перестал думать.)

Антиквариат, однако.
>
> Помните ту часть, что про " возможности повлиять на клиента нет" ?
Вот она и есть виновница этого антиквариата =)


3 сентября 2014 г., 15:00 пользователь  написал:

> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
> отправлять по адресу
> nginx-ru@nginx.org
>
> Для изменения параметров подписки вы можеже использовать веб-страницу
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> Для получения информации о том, как пользовать почтовым интерфейсом,
> отправьте письмо, в теле или теме которого будет слово 'help', по
> адресу:
> nginx-ru-requ...@nginx.org
>
> Адрес человека, ответственного за этот список рассылки:
> nginx-ru-ow...@nginx.org
>
> При ответе, пожалуйста, измение тему письма так, чтобы она была более
> содержательной чем "Re: Содержание дайджеста списка рассылки
> nginx-ru..."
>
> Today's Topics:
>
>1. Transparent file substitution (Андрей Середенко)
>2. Re: Transparent file substitution (Maxim Dounin)
>
>
> -- Пересылаемое сообщение --
> From: "Андрей Середенко" 
> To: nginx-ru@nginx.org
> Cc:
> Date: Tue, 2 Sep 2014 17:20:00 +0300
> Subject: Transparent file substitution
> Доброго дня всем!
>
> Ребят, подскажите - имеется такой вопрос..
>
> INTRO:
>
> Mono. Есть приложение, на которое nginx проксирует запросы. И есть один
> не-совсем-адекватный клиент, который у этого приложения запрашивает wsdl
> прежде, чем воспользоваться апишкой.. перед каждым запросом... и делает это
> с частотой ~200 запросов в минуту (на каждый полезный запрос - вот этот вот
> сорный запрос wsdl'ки, который впустую напрягает приложение)
>
> Возможности повлиять на клиента нет. Время подставлять костыли...
>
>
> WORKAROUND:
>
> Раз возможности повлиять на клиента нет, было принято решение обмануть его
> (нормальная практика, что =) ): вместо постоянной генерации wsdl'ки на
> стороне приложения - отдавать nginx'ом статический файл, содержащий её
> контент (если в параметрах запроса имеется ?wsdl, если его нет - то
> проксировать на приложение). Было сделано что-то вроде следующего:
>
> location = /some/app/url/messenger.asmx {
> if ( $args ~* wsdl ) {
> return 301 /some/app/url/static/messengerwsdl.xml;
> }
>
> proxy_passhttp://server1:8080;
>
> }
>
> где /some/app/url/static/ - смотрит на папку со статикой, обрабатываемую
> nginx'ом, а messengerwsdl.xml - тот самый файл с контентом wsdl'ки.
> работало всё просто замечательно, но..
>
> PROBLEMS:
>
> ..оказалось, что клиент, запрашивавший wsdl, не умеет работать с
> редиректом :(
>
> А т.к. повлиять на клиента возможности нет - пришлось чесать затылок.
>
>
> GOALS:
>
> Можно ли сделать нечто подобное *без перенаправлений* ?
> Что пробовалось: положить файл в папку статики по пути, аналогичным
> location и с тем же именем, и поменять $document_root в блоке if'a, но: из
> if'a тоже надо как-то выходить - break не годится (обработка пойдет дальше
> по локейшену и в результате - запрос будет проксирован), return не годится
> (клиент не понимает редиректов), rewrite... а смысл? все равно в итоге
> return new location.
>
> В этом смысле, наверное, неплохо вписался бы try_files в блоке if'a... но
> он внутри директивы if запрещён.
>
> Может, ещё какие-нибудь варианты? И могут ли они быть в принципе.
> Если что-то было не ясно в описании - могу на псевдопримерах пояснить. А
> пока - вот:
>
> #$ nginx -V
> nginx version: nginx/1.0.15
> built by gcc 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)
> TLS SNI support enabled
> configure arguments: --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
> --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi
> --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid
> --lock-path=/var/lock/subsys/nginx --user=nginx --group=nginx
> --with-file-aio --with-ipv6 --with-http_ssl_module
> --with-http_realip_module --with-http_addition_module
> --with-http_xslt_module --with-http_image_filter_module
> --with-http_geoip_module --with-http_sub_module --with-http_dav_module
> --with-http_flv_module --with-http_mp4_module
> --with-http_gzip_stat

Transparent file substitution

[Андрей Середенко]

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

Ребят, подскажите - имеется такой вопрос..

INTRO:

Mono. Есть приложение, на которое nginx проксирует запросы. И есть один
не-совсем-адекватный клиент, который у этого приложения запрашивает wsdl
прежде, чем воспользоваться апишкой.. перед каждым запросом... и делает это
с частотой ~200 запросов в минуту (на каждый полезный запрос - вот этот вот
сорный запрос wsdl'ки, который впустую напрягает приложение)

Возможности повлиять на клиента нет. Время подставлять костыли...


WORKAROUND:

Раз возможности повлиять на клиента нет, было принято решение обмануть его
(нормальная практика, что =) ): вместо постоянной генерации wsdl'ки на
стороне приложения - отдавать nginx'ом статический файл, содержащий её
контент (если в параметрах запроса имеется ?wsdl, если его нет - то
проксировать на приложение). Было сделано что-то вроде следующего:

location = /some/app/url/messenger.asmx {
if ( $args ~* wsdl ) {
return 301 /some/app/url/static/messengerwsdl.xml;
}

proxy_passhttp://server1:8080;

}

где /some/app/url/static/ - смотрит на папку со статикой, обрабатываемую
nginx'ом, а messengerwsdl.xml - тот самый файл с контентом wsdl'ки.
работало всё просто замечательно, но..

PROBLEMS:

..оказалось, что клиент, запрашивавший wsdl, не умеет работать с редиректом
:(

А т.к. повлиять на клиента возможности нет - пришлось чесать затылок.


GOALS:

Можно ли сделать нечто подобное *без перенаправлений* ?
Что пробовалось: положить файл в папку статики по пути, аналогичным
location и с тем же именем, и поменять $document_root в блоке if'a, но: из
if'a тоже надо как-то выходить - break не годится (обработка пойдет дальше
по локейшену и в результате - запрос будет проксирован), return не годится
(клиент не понимает редиректов), rewrite... а смысл? все равно в итоге
return new location.

В этом смысле, наверное, неплохо вписался бы try_files в блоке if'a... но
он внутри директивы if запрещён.

Может, ещё какие-нибудь варианты? И могут ли они быть в принципе.
Если что-то было не ясно в описании - могу на псевдопримерах пояснить. А
пока - вот:

#$ nginx -V
nginx version: nginx/1.0.15
built by gcc 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)
TLS SNI support enabled
configure arguments: --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
--http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi
--http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid
--lock-path=/var/lock/subsys/nginx --user=nginx --group=nginx
--with-file-aio --with-ipv6 --with-http_ssl_module
--with-http_realip_module --with-http_addition_module
--with-http_xslt_module --with-http_image_filter_module
--with-http_geoip_module --with-http_sub_module --with-http_dav_module
--with-http_flv_module --with-http_mp4_module
--with-http_gzip_static_module --with-http_random_index_module
--with-http_secure_link_module --with-http_degradation_module
--with-http_stub_status_module --with-http_perl_module --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-ld-opt=-Wl,-E

#$ lsb_release -a
LSB Version:
:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 6.2 (Final)
Release: 6.2
Codename: Final



Спасибо!
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx-ru Digest, Vol 51, Issue 18

[Андрей Середенко]

>
> Вся магия сводится к добавлению:
>
>   location = /webapp {
>   return 301 /webapp/;
>   }


Спасибо, Валентин! Чет как-то об этой "магии" я не подумал.) Обязательно
попробуем.

 мы вот так делаем

root /var/www/webapps/nginx-static;
>
> location /webapp/ {
> try_files $uri $uri/ @application-handle;
> }
>
> location @application-handle {
>include my-site/proxy_pass_params.conf;
>proxy_pass http://app_upstream;
> }
>
>
> 1) в try_files пишем $uri и $uri/
> 2) root-у нечего делать в location-е
> 3) include лучше делать в самую первую очередь, чтобы переопределенные
> параметры (если они будут) не перетерлись include-овыми


и Вам, Илья, Спасибо. Но - увы: если в try_files указать $uri и $uri/, то
на запрос /webapp/ будет прилетать 403. Пробовали..
По поводу root'a в location'е - тоже не тот случай: локейшн не один, равно
как и приложение не единственное, и прописывать рут на уровне server'a нет
возможности. А делать отдельную секцию server'a для каждого приложения.. ну
не знаю, не знаю - что-то меня тут коробит:)
Что же касается инклюдов - учту, спасибо. Хотя у меня есть некоторые
сомнения, что эти параметры унаследуются при проксировании, если определить
их до.. впрочем, это легко проверить.

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


9 января 2014 г., 21:35 пользователь  написал:

> Сообщения, предназначенные для списка рассылки nginx-ru, необходимо
> отправлять по адресу
> nginx-ru@nginx.org
>
> Для изменения параметров подписки вы можеже использовать веб-страницу
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> Для получения информации о том, как пользовать почтовым интерфейсом,
> отправьте письмо, в теле или теме которого будет слово 'help', по
> адресу:
> nginx-ru-requ...@nginx.org
>
> Адрес человека, ответственного за этот список рассылки:
> nginx-ru-ow...@nginx.org
>
> При ответе, пожалуйста, измение тему письма так, чтобы она была более
> содержательной чем "Re: Содержание дайджеста списка рассылки
> nginx-ru..."
>
> Today's Topics:
>
>1. Re: 301 redirect на URI без слэша на конце (Валентин Бартенев)
>2. Re: 301 redirect на URI без слэша на конце (Илья Шипицин)
>3. Re: Bug ? 304 status - Cache-Control (Ilya Pirogov)
>4. Slowloris attack (Михаил Монашёв)
>5. Re: Bug ? 304 status - Cache-Control (S.A.N)
>6. Re: Slowloris attack (Sergey Smitienko)
>
>
> -- Пересылаемое сообщение ------
> From: "Валентин Бартенев" 
> To: nginx-ru@nginx.org
> Cc:
> Date: Thu, 09 Jan 2014 19:09:55 +0400
> Subject: Re: 301 redirect на URI без слэша на конце
> On Thursday 09 January 2014 17:55:57 Андрей Середенко wrote:
> > Здравия, друзья! Всех с прошедшими праздниками!
> >
> > В процессе приведения конфигурации своих веб-серверов в более
> лицеприятный
> > столкнулся с таким моментом: автоматическое добавление слэша не
> происходит
> > после отрабатывания директивы try_files. Было неожиданно. Немного
> примеров,
> > чтобы стало понятнее, о чем речь (ниже 2 фрагмента конфигурации - "до" и
> > "после"):
> >
> > location /webapp/ {
> > proxy_pass http://app_upstream;
> >  include my-site/proxy_pass_params.conf;
> > }
> >
> > Подумалось, что правильнее отдавать статику силами nginx'а, а не
> напрягать
> > и без того кривое приложение:) В итоге, location принял следующий облик:
> >
> > location /webapp/ {
> > root /var/www/webapps/nginx-static;
> >  try_files $uri @application-handle;
> > }
> >
> > location @application-handle {
> > proxy_pass http://app_upstream;
> >  include my-site/proxy_pass_params.conf;
> > }
> >
> > В результате, в принципе, получил то, что хотел: запрашиваемые файлы
> > сначала ищутся в /var/www/webapps/nginx-static, и, если ничего не нашли,
> -
> > проксируем на приложение. Но - перестали обрабатываться запросы вида
> > http://my.site.com/webapp, хотя запросы http://my.site.com/webapp/ (со
> > слэшем на конце) обрабатываются корректно.
> > Оно то, в общем-то, и правильно: в документации сказано:
> >
> > Если location задан префиксной строкой со слэшом в конце и запросы
> >
> > > обрабатываются при помощи
> > > proxy_pass<
> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy
> > > _pass>
>  ,
> > > fastcgi_pass<
> http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#f
> > > astcgi_pass> ,
> > > scgi_pass<
> http://nginx.org/ru/docs/http/ngx_http_scgi_module.html#scgi_pa
> > > ss> ,
&

301 redirect на URI без слэша на конце

[Андрей Середенко]

Здравия, друзья! Всех с прошедшими праздниками!

В процессе приведения конфигурации своих веб-серверов в более лицеприятный
столкнулся с таким моментом: автоматическое добавление слэша не происходит
после отрабатывания директивы try_files. Было неожиданно. Немного примеров,
чтобы стало понятнее, о чем речь (ниже 2 фрагмента конфигурации - "до" и
"после"):

location /webapp/ {
proxy_pass http://app_upstream;
 include my-site/proxy_pass_params.conf;
}

Подумалось, что правильнее отдавать статику силами nginx'а, а не напрягать
и без того кривое приложение:) В итоге, location принял следующий облик:

location /webapp/ {
root /var/www/webapps/nginx-static;
 try_files $uri @application-handle;
}

location @application-handle {
proxy_pass http://app_upstream;
 include my-site/proxy_pass_params.conf;
}

В результате, в принципе, получил то, что хотел: запрашиваемые файлы
сначала ищутся в /var/www/webapps/nginx-static, и, если ничего не нашли, -
проксируем на приложение. Но - перестали обрабатываться запросы вида
http://my.site.com/webapp, хотя запросы http://my.site.com/webapp/ (со
слэшем на конце) обрабатываются корректно.
Оно то, в общем-то, и правильно: в документации сказано:

Если location задан префиксной строкой со слэшом в конце и запросы
> обрабатываются при помощи 
> proxy_pass
> , 
> fastcgi_pass
> , scgi_pass
> , 
> uwsgi_pass
>  или 
> memcached_pass,
> а в ответ на запрос с URI равным этой строке, но без завершающего слэша,
> будет возвращено постоянное перенаправление с кодом 301 на URI с
> добавленным в конец слэшом. Если такое поведение нежелательно, можно задать
> точное совпадение URI и location, например:
>
> location /user/ {
> proxy_pass http://user.example.com;
> }
>
> location = /user {
> proxy_pass http://login.example.com;
> }
>
>
> Про try_files тут не сказано ни слова.) Но возник законный вопрос: а как
вернуть прежнее поведение? можно ли сделать это "красиво"? или придется
городить магию с реврайтами? а если писать реврайты - куда их пихать.. в
общем, как-то так. Как-то сходу не получилось самому ответить на эти
вопросы, решил поделиться с сообществом. Буду признателен за любые
предложения выхода из ситуации.

Немного информации, которая может быть полезной:

[ root@app1 ~]# nginx -V
> nginx version: nginx/1.0.15
> built by gcc 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)
> TLS SNI support enabled
> configure arguments: --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
> --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi
> --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid
> --lock-path=/var/lock/subsys/nginx --user=nginx --group=nginx
> --with-file-aio --with-ipv6 --with-http_ssl_module
> --with-http_realip_module --with-http_addition_module
> --with-http_xslt_module --with-http_image_filter_module
> --with-http_geoip_module --with-http_sub_module --with-http_dav_module
> --with-http_flv_module --with-http_mp4_module
> --with-http_gzip_static_module --with-http_random_index_module
> --with-http_secure_link_module --with-http_degradation_module
> --with-http_stub_status_module --with-http_perl_module --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-ld-opt=-Wl,-E
>
> [ root@app1 ~]# lsb_release -a
> LSB Version:
> :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
> Distributor ID: CentOS
> Description: CentOS release 6.2 (Final)
> Release: 6.2
> Codename: Final
>
> [ root@app1 ~]# uname -a
> Linux app1 2.6.32-220.23.1.el6.x86_64 #1 SMP Mon Jun 18 18:58:52 BST 2012
> x86_64 x86_64 x86_64 GNU/Linux
>

Содержимое my-site/proxy_pass_params.conf (роли наверняка не играет, но для
полноты картины - надо):

proxy_redirect off;
>
> proxy_set_header   Host   $host;
> proxy_set_header   Remote-Addr   $remote_addr;
> proxy_set_header   X-Real-IP$remote_addr;
> proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
> proxy_set_header   X-Public-Url http://$host$request_uri;
>
> client_max_body_size  40m;
> client_body_buffer_size128k;
>
> proxy_connect_timeout90;
> proxy_send_timeout90

Re: nginx-ru Digest, Vol 47, Issue 4

[Андрей Середенко]

уль concat:
>
> --- ngx_http_concat_module.c
> +++ ngx_http_concat_module.c
> @@ -30,7 +30,7 @@
>
>
>  static ngx_str_t  ngx_http_concat_default_types[] = {
> -ngx_string("application/x-javascript"),
> +ngx_string("application/javascript"),
>  ngx_string("text/css"),
>  ngx_null_string
>  };
>
> Ещё раз - спасибо!
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,242399,242424#msg-242424
>
>
>
>
> -- Пересылаемое сообщение --
> From: Daniel Podolsky 
> To: nginx-ru 
> Cc:
> Date: Mon, 2 Sep 2013 00:47:34 +0400
> Subject: Re: If is Evil
> > да и выяснить причину раз и навсегда куда полезнее, чем просто запомнить
> > постулат "скажем if в location - НЕТ"
> А мы им не скажем НЕТ. Мы просто помним, что для if создается скрытый
> location, и что туда наследуется, а что нет, и какая там в результате
> будет конфигурациия - ни за что не прописаешь, как говорили в школе.
>
> Поэтому мы пользуемся if, но только одним образом - делаем на нем
> переадресацию в именованный локейшн.
>
> Отдельно, конечно, смешно то, что это единственный разумный способ
> пользоваться if, но директивы переадресации как не было, так и нет, и
> приходится писать что-то вроде if (condition) { error_page 418 =
> @location; return 418; }
>
>
> -- Пересылаемое сообщение --
> From: "Валентин Бартенев" 
> To: nginx-ru@nginx.org
> Cc:
> Date: Mon, 2 Sep 2013 03:02:45 +0400
> Subject: Re: true 414 status code
> On Monday 02 September 2013 00:33:57 Vladimir Getmanshchuk wrote:
> > Амм... Спасибо за скорость и лаконичность.
> >
> > Судя по http://www.w3.org/Protocols/HTTP/HTRESP.html, в HTTP/0.9 тоже
> есть
> > status codes, или я что то недопонимаю?
>
> Вы ссылаетесь на спецификацию HTTP/1.0.  В HTTP/0.9 у ответа не было
> заголовка:
> http://www.w3.org/Protocols/HTTP/AsImplemented.html
> http://www.w3.org/DesignIssues/HTTP0.9Summary.html
>
>
> > Да! И еще, в "аутпуте" curl, nginx отвечает "HTTP/1.1 200 OK"
>
> Сам дописывает видимо.  Смотрите более простыми средствами, типа netcat'а
> или
> telnet'а.
>
> --
> Валентин Бартенев
> http://nginx.org/en/donation.html
>
>
> -- Пересылаемое сообщение --
> From: "Валентин Бартенев" 
> To: nginx-ru@nginx.org
> Cc:
> Date: Mon, 2 Sep 2013 03:08:04 +0400
> Subject: Re: true 414 status code
> On Sunday 01 September 2013 17:15:55 Gena Makhomed wrote:
> > On 31.08.2013 23:57, Валентин Бартенев wrote:
> > >> Подскажите пожалуйста, а как без "грязных хаков" получить от nginx,
> 414
> > >> status code, на запросы, размер которых, превышает
> large_client_header_
> > >> buffers?
> > >>
> > >> Постоянно получаю 200 http status code и нижеприведенное в body:
> > >>
> > >> 
> > >> 414 Request-URI Too Large
> > >> 
> > >> 414 Request-URI Too Large
> > >> nginx/1.2.9
> > >> 
> > >> 
> > >
> > > Это не "200 http status code", а HTTP/0.9 ответ с ошибкой.
> >
> > а есть ли смысл отвечать по протоколу версии HTTP/0.9 ?
> > тем более, что запрос в 99.999% был версии 1.0 или 1.1
> >
> > даже если "Request-URI Too Large" - версию протокола
> > запроса можно узнать из строки запроса, при желании.
>
> Нельзя.  В наихудшим случае (а он обязательно наступит)
> строка запроса будет бесконечна.
>
> >
> > тем более, что протокол версии 0.9 не умеет прислать
> > клиенту ответ в котором будет указан status code 414
> >
> > а парсить тело ответа веб-сервера никто не будет,
> > различных серверов много и формат ответов разный.
>
> Я согласен, ИМХО имеет лучше откатываться до 1.0, и даже
> прислал коллегам соответствующий патч на ревью.
>
> --
> Валентин Бартенев
> http://nginx.org/en/donation.html
>
>
> -- Пересылаемое сообщение --
> From: Maxim Dounin 
> To: nginx-ru@nginx.org
> Cc:
> Date: Mon, 2 Sep 2013 03:42:31 +0400
> Subject: Re: If is Evil
> Hello!
>
> On Sun, Sep 01, 2013 at 09:31:35PM +0300, Андрей Середенко wrote:
>
> > Приветы всем!
> >
> > Тысячи раз уже слышал, что использовать if в location КРАЙНЕ не
> > рекомендуется, и что использовать его там можно только в купе с return
> или
> > rewrite..last, но - все же хочется разобраться, КАК он отрабатывает и
> > почему.
> >
> > Пару рабочих дней было потрачено на то, чтобы разобраться, как оно
> > работает. Но в итоге выяснило

If is Evil

[Андрей Середенко]

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

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

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

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

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

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

Буду признателен за любые ответы. Спасибо!
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

upstream && if

[Андрей Середенко]

Доброго времени суток всем подписчикам!

Подскажите, возможно ли нечто этакое:

Использую proxy_pass, для примера:

upstream some_proxy {
server SERV_NAME_1:8080;
server SERV_NAME_2:8080 backup;
}

в локейшене анализирую урел на предмет наличия определенного параметра:
  /some/url/.?param=SERV_NAME_x

Задача в том, чтобы отдавать запрашиваемый файлик (имя передается в том же
в урле) при встрече такого параметра с машины SERV_NAME_x, и не
проксировался на вторую машину. Хотел попробовать в upstream вписать if
проверки, а-ля:

if ($args ~* (.*) param=SERV_NAME_1 (.+)) {
* server SERV_NAME_1:8080;*
}
аналогично для serv_name_2. Но в upstream, насколько я понял, нельзя
использовать директиву if. Подскажите, есть ли какое-то более-менее
стандартное решение этого вопроса, или же надо искать в другой степи?

Спасибо.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru