Re: Re[2]: Несколько непонятностей по nginx

[proforg]

>>> Как я уже понял, блока if в другом блоке if быть не может, а можно в
>>> самом if проверять несколько условий (&& или ||)? Или может есть
>>> какие-нибудь другие пути проверки двух условий? Например для того,
>>> чтобы выдать клиенту 403, если у него неправильный реферер и адрес
>>> неподходящий...
>> Нет, нельзя.
>> Нужно сводить к последовательности if, используя например внутренние
>> переменные, если нужно логическое AND
>> http://sysoev.ru/nginx/docs/http/ngx_http_rewrite_module.html#set
>> или rewrite и разные локейшны
> Я, в принципе, подумал также и опробовал. Оно-то получилось, но, имхо,
> смотрится как-то, эээ, не то чтобы неправильно...,  непривычно...
> А, кстати, set-ом можно к существующей переменной добавлять значение,
> типа как если бы мы на перле написали $a .= ", welcome"; (другими
> словами, конкатенация переменной и текста)? Что-нибудь из этого:
> set $a $a.", bla-bla";
> set $a "$a, bla-bla";
> { set $a "User";
>   set $b ", bla-bla";
>   set $c $a$b;
> }
> ?
> Тогда можно будет соблюдение пары условий, объединенных AND,
> проверить посредством каких-нибудь меток в одной переменной,
> типа такого:
>
> if (<condition>){
>    set $a "COND1";
> }
>
> if (<condition>){
>    set $a "$aCOND2";
> }
>
> if ($a ~ COND1COND2){
>    return 500;
> }
>
> Или заместо последнего
> if ($a ~ (COND1|COND2)(COND1|COND2)){
>    return 500;
> }
> если порядок проверки if разный...
да, например так.
но такая конструкции работать не будет: set $a $a.", bla-bla";
остальные будут

>
>
>>> Есть какая-нибудь возможность в процессе проксировании запроса
>>> выполнять какой-либо скрипт, а по результату его выполнения, решать,
>>> отдавать запрос на обработку бэкенду или вернуть какой-нибудь  
>>> статус?
>>> Тут очень даже кстати был бы встроенный perl с возможностью
>>> назначения хэндлеров в location. Но поскольку модуль -
>>> экспериментальный, а в офф.доках не совсем понятно написано насчет
>>> пересборки самого перла (с последующей пересборкой бинарных  
>>> модулей),
>>> то на http_perl_module не особо надеюсь...
>> Если не хватает тривиальных проверок которые умеет if, то
>> видимо только на него и нужно надеяться :)
> Ну, в общем-то, не хватает (если не учитывать предыдущий подвопрос).
> Я правильно понял, что, чтобы сей модуль заработал, просто нужно nginx
> собрать с соответствующей --with? Без всяких пересборок самого
> интерпретатора с usethreads, usemultiplicity... ?
> Вот именно эта фраза из доков смущает: "Для того, чтобы во время
> переконфигурации perl перекомпилировал изменённые модули, его нужно
> собрать с параметрами -Dusemultiplicity=yes или -Dusethreads=yes".
> Перл какой? Который встроенный, или сам Интерпретатор на машине :)?
> О каких модулях идет речь и почему они измененные?
собирать с  --with-http_perl_module
в общем случае - без пересборок системного перла
но если он (системный перл) будет собран без usemultiplicity и  
usethreads
то, как написано, nginx  не будет перекомпилировать используемые  
перловые модули при
переконфигурации по -HUP. по русски - изменения внесённые в  
используемые им
перловые модули после запуска nginx не отразятся на текущщей его  
работе до перезапуска nginx.


>
>
>>> А проксировать сразу на два адреса можно? Напр., одновременно  
>>> апачу и
>>> какому-нибудь демону на 9999-м порту?
>> Нет, нельзя.
> Сорри за небольшой оффтоп, ради интереса спрашиваю. Процесс
> проксирования апачу (грубо): приходит запрос nginx-у, worker  
> форкается,
> открывает апачевый сокет, пишет туда запрос, потом читает оттуда ответ
> и отсылает его запрашиваемому (ч-з свой сокет)?
По сути да, за тем исключением что не форкается, используется  
асинхронный i/o.


>
>> Этот заголовок нужен устанавливать если бакенду необходимо получить
>> реальный IP клиента а не ip фронтенда.
>> Он добавляется первым в имеющийся список.
>> Назад (в случае apache) прозрачно получается модулем mod_rpaf /
>> mod_realip
>> Как вариант ещё можно использовать заголовок X-Real-IP который
>> понимает  mod_realip
> Ну, то бишь, как и во всех вышеназванных мною источниках конфигов
> используется
> proxy_set_header   X-Real-IP        $remote_addr;
>
> Но в варианте выше используется $proxy_add_x_forwarded_for, а не
> $remote_addr.!
> ЕМНИП, HTTP_X_FORWARDED_FOR устанавливают всякие офисные прокси,
> которые пускают работников из офиса в инет (ну и прочие сквиды, не
> обязательно установленные в офисе)...
> И вот приходит к нам такой человек, а nginx ему его же заголовок его
> же значением переустанавливает... Зачем? К тому же, в том заголовке
> прописан адрес, как правило, из intranet. Он апачу ни при чем.
> А устанавливать X-Real-IP из REQMOTE_ADDR - самое то, если нужно,
> чтобы апач знал адрес клиента. В статьях черным фонтом по белому
> бэкграунду и написано, что, чтобы апач знал адрес своего клиента (а не
> адрес фронтенда) - нужен ему в помощь mod_rpaf, который подсунет апачу
> адрес из X-Real-IP...
> Все равно не понятно пока про X-Forwarded-For...

Нет. директива
proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
не переустановит X-Forwarded-For, а добавит в список имеющихся там  
адресов адрес клиента.
mod_rpaf/mod_realip его прочитает, выставит connection->remote_ip  
апачу  и удалит его из списка.
то есть для бакенда всё будет "прозрачно"
X-Real-IP не подходит из за того что mod_rpaf например  "из коробки"  
его не понимает.

Алексей Бещёков
proforg at maloletka.ru
+7 495 7853149



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20070411/af0d5dfa/attachment.bin>