Как я уже понял, блока 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 разный...
да, например так.
но такая конструкции работать не будет: 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@xxxxxxxxxxxx
+7 495 7853149
