Здравствуйте, proforg и все остальные.
Спасибо за ответ.
>> Как я уже понял, блока if в другом блоке if быть не может, а можно в
>> самом if проверять несколько условий (&& или ||)? Или может есть
>> какие-нибудь другие пути проверки двух условий? Например для того,
>> чтобы выдать клиенту 403, если у него неправильный реферер и адрес
>> неподходящий...
> Нет, нельзя.
> Нужно сводить к последовательности if, используя например внутренние
> переменные, если нужно логическое AND
>
> или 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 разный...
>> Есть какая-нибудь возможность в процессе проксировании запроса
>> выполнять какой-либо скрипт, а по результату его выполнения, решать,
>> отдавать запрос на обработку бэкенду или вернуть какой-нибудь статус?
>> Тут очень даже кстати был бы встроенный perl с возможностью
>> назначения хэндлеров в location. Но поскольку модуль -
>> экспериментальный, а в офф.доках не совсем понятно написано насчет
>> пересборки самого перла (с последующей пересборкой бинарных модулей),
>> то на http_perl_module не особо надеюсь...
> Если не хватает тривиальных проверок которые умеет if, то
> видимо только на него и нужно надеяться :)
Ну, в общем-то, не хватает (если не учитывать предыдущий подвопрос).
Я правильно понял, что, чтобы сей модуль заработал, просто нужно nginx
собрать с соответствующей --with? Без всяких пересборок самого
интерпретатора с usethreads, usemultiplicity... ?
Вот именно эта фраза из доков смущает: "Для того, чтобы во время
переконфигурации perl перекомпилировал изменённые модули, его нужно
собрать с параметрами -Dusemultiplicity=yes или -Dusethreads=yes".
Перл какой? Который встроенный, или сам Интерпретатор на машине :)?
О каких модулях идет речь и почему они измененные?
>> А проксировать сразу на два адреса можно? Напр., одновременно апачу и
>> какому-нибудь демону на 9999-м порту?
> Нет, нельзя.
Сорри за небольшой оффтоп, ради интереса спрашиваю. Процесс
проксирования апачу (грубо): приходит запрос nginx-у, worker форкается,
открывает апачевый сокет, пишет туда запрос, потом читает оттуда ответ
и отсылает его запрашиваемому (ч-з свой сокет)?
>>
>> В некоторых статьях (в частности, на blog.kovyrin.net) в примерах
>> конфига вижу строчку (настройка в кач-ве фронтенда)
>> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>> либо то же самое, но закомментаренное.
>>
>> А в чем сакральный смысл установки HTTP_X_FORWARDED_FOR?
>> nginx при обработке запроса сбрасывает существующий заголовок, если он
>> есть? Или это для каких-то других целей?
> Этот заголовок нужен устанавливать если бакенду необходимо получить
> реальный 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...
--
С уважением,
Max
