Патч для второй проблемы (на 0.8.21, должен сработать для большого числа версий) — dolgov.name/nginx/vars_names.patch
Сработало написание переменной как $arg_user%5fid.
Рекомендую после наложение проверить, не сломалось ли еще что-то.
Насколько я помню,
1) для работы переменной надо, чтобы все тело запроса не писалось во временный файл (то есть, размер тела был меньше, чем размер одного буфера), client_body_in_single_buffer должен быть on, в location, где хочется получить значение переменной, должна быть директива proxy_pass или fastcgi_pass. Хотя, матчить POST по регекспу — не очень хорошая затея, пожалейте процессор и память :) Заюзайте iptables и его модуль string.
2) Проблема в том, что % не считается членом именем переменной. Сейчас попробую сделать патч.
Вообще, для подобного есть встроенное кеширование nginx, которое работает для proxy_pass и fastcgi_pass, учитывает и отсутствие файла, и POST, и истечение. Есть замечательная статья по этому поводу: dklab.ru/chicken/nablas/56.html
На данный момент — никак, только дублированием location'a (прямо или через include).
Давно упоминалось несколько идей, как это можно сделать:
1) сделать хендлер redirect, который сможет перенаправлять обработку запроса в именованный location или по другому uri.
2) выносить конфигурацию в отдельные блоки, например
use php-conf
{
fastcgi_pass ...;
}
location ~ \.php$
{
use php-conf;
}
location @fallback
{
use php-conf;
}
Увы, это невозможно по некоторым идеалогическим и техническим причинам :-)
1. В nginx нет понятия, подобного апачевскому Directory, только Location, а содержимое .htaccess приписывается как раз в Directory. Это было сделано намеренно, чтобы убрать эту ужасную двойственность конфигурации, где на один запрос влияет куча мест в конфиге. Это уже делает очень затруднительным выбор пути для того, чтобы искать в нем .htaccess.
2. Поддержка динамической конфигурации потребует весьма ресурсоемких операций, которые неприменимы на высоких нагрузках.
Во-первых, надо сделать stat() для всех возможных .htaccess файлов.
Во-вторых, надо прочитать их содержимое.
В третьих, надо скомпилировать их с с'merge'ить с текущей конфигурацией.
3. Что пораждает следующую проблему — конфигурация конфигурируется при запуске и ее изменение на лету достаточно проблематично.
В принципе, согласен. Однако, отключение у apache .htaccess может его немного ускорить, а большинстве VDS как раз нужно иметь возможность выжимать максимум из имеющегося :-)
Честно говоря, не вижу смысла — ведь $request_filename зависит от $uri и root или alias, то есть его возможные значение при написании конфига можно предсказать и вынести в location.
Можете показать пример конфига, где приходится писать такое?
Надо смотреть, что происходит внутри. Сейчас уже не смогу, скорее всего — завтра днем.
Сработало написание переменной как $arg_user%5fid.
Рекомендую после наложение проверить, не сломалось ли еще что-то.
1) для работы переменной надо, чтобы все тело запроса не писалось во временный файл (то есть, размер тела был меньше, чем размер одного буфера), client_body_in_single_buffer должен быть on, в location, где хочется получить значение переменной, должна быть директива proxy_pass или fastcgi_pass. Хотя, матчить POST по регекспу — не очень хорошая затея, пожалейте процессор и память :) Заюзайте iptables и его модуль string.
2) Проблема в том, что % не считается членом именем переменной. Сейчас попробую сделать патч.
location ~ /admin(.*) { return 403; } location / { proxy_pass ...; }server { listen 80; server_name *.bla.ru ""; rewrite ^ httр://blabla.ru$request_uri? permanent; } server { listen 80; server_name bla.ru; ... обычный конфиг ... }location ~ \.html$ { root cache; error_page 406 =@indexphp; if ( $request_method = 'POST' ) { return 406; } try_fiiles $uri @indexphp; } location @indexphp { fastcgi_pass ...; fastcgi_param script_FILENAME $document_root/index.php; include fastcgi_params; }</code>Тут мы по error_page .. if .. return или try_files уходим в другой location, когда кеширование неприменимо.
Если бекенд - apache, то можно написать что-то такое:
location ~ \.html$ { root cache; error_page 406 =/index.php; if ( $request_method = 'POST' ) { return 406; } try_fiiles $uri /index.php; } location =/index.php { proxy_pass ...; }</code>Вообще, для подобного есть встроенное кеширование nginx, которое работает для proxy_pass и fastcgi_pass, учитывает и отсутствие файла, и POST, и истечение. Есть замечательная статья по этому поводу: dklab.ru/chicken/nablas/56.html
А вопросы — можно задавать в комментариях, все они будут отвечены :) По их материалам потом тоже можно будет сделать отдельный пост.
Давно упоминалось несколько идей, как это можно сделать:
1) сделать хендлер redirect, который сможет перенаправлять обработку запроса в именованный location или по другому uri.
2) выносить конфигурацию в отдельные блоки, например
use php-conf { fastcgi_pass ...; } location ~ \.php$ { use php-conf; } location @fallback { use php-conf; }Увы, сейчас ничего из этого не реализовано :-(
1. В nginx нет понятия, подобного апачевскому Directory, только Location, а содержимое .htaccess приписывается как раз в Directory. Это было сделано намеренно, чтобы убрать эту ужасную двойственность конфигурации, где на один запрос влияет куча мест в конфиге. Это уже делает очень затруднительным выбор пути для того, чтобы искать в нем .htaccess.
2. Поддержка динамической конфигурации потребует весьма ресурсоемких операций, которые неприменимы на высоких нагрузках.
Во-первых, надо сделать stat() для всех возможных .htaccess файлов.
Во-вторых, надо прочитать их содержимое.
В третьих, надо скомпилировать их с с'merge'ить с текущей конфигурацией.
3. Что пораждает следующую проблему — конфигурация конфигурируется при запуске и ее изменение на лету достаточно проблематично.
Можете показать пример конфига, где приходится писать такое?
Я умею читать, я понимаю, что такое «запрос по протоколу HTTP». А Вы, судя по всему, нет.