Re: webdav в rest на nginx: upload, подзапрос, замена параметров запроса и ответа
Vasiliy Fedorov
fyodorovvv на gmail.com
Пн Окт 4 19:02:27 MSD 2010
2010/10/4 Maxim Dounin <mdounin на mdounin.ru>:
>
> В зависимости от конкретной задачи - можно либо сделать через
> X-Accel-Redirect,
Для аплоадов это не подойдет, вроде.
> либо взять какой-нибудь из модулей:
> eval (http://grid.net.ru/nginx/eval.en.html), auth request
> (http://mdounin.ru/hg/ngx_http_auth_request_module/).
Спасибо, как раз на последний смотрел, про pass_request_body и
спрашивал ниже. Но нужно в зависимости от ответа менять заголовки и
урл.
>> 3. Если нельзя -- ругнуться пользователю, если можно -- поменять
>> request: method, uri, заголовки* -- и проксировать дальше.
>
> Менять методы и заголовки можно в коробке, про uri даже и не
> говорю.
Да, спасибо, документацию я читал, то есть наличие всяких разных
параметров мне известно. Сложности с их комбинациями :-)
Конкретно в этом моменте ситуация осложняется тем что заголовки надо
выставлять динамически, в зависимости от ответа на подзапрос,
"подписывать запрос к Amazon S3".
>> *: X-Accel-Redirect тут подходит плохо, хотя и используют для похожих
>> вещей: http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/
>
> X-Accel-Redirect подходит, но требует некоторой аккуратности в
> написании конфигов.
То есть можно некоторыми ухищрениями добиться того чтоб контент не
передавался для первого запроса, и передавался при редиректе?
proxy_pass_request_body -- снова ключевое слово?
> В большинстве случаев пропускать ещё не полученный запрос на
> бекенд - излишняя трата ресурсов. Кроме того, при таком подходе
> пропадает возможность перепослать запрос на другой бекенд, если с
> первым что-то случилось и он запрос недочитал.
Если проблема в этом, то можно запрос еще куда-нибудь копировать, но в
общем-то можно сделать параметром конфигурации, наверно.
> Сделать подобный вариант обработки для больших постов безусловно
> имеет смысл, но это a) требует времени и b) нужно далеко не всегда.
>
>> 2. Авторизация через другой сервер:
>> -- можно попробовать запрос направить на статический файлик с SSI
>> инструкциями, первой инструкцией сходить авторизоваться, в зависимости
>> от значения ответа вызывать разные SSI (не авторизован -- ошибка,
>> авторизован -- вызвать url)
>
> Нет, так работать не будет. Статический файл выкинет тело
> запроса.
Понятно, спасибо.
>> P.S.: Директива proxy_pass_request_body есть в документации на
>> английском (http://wiki.nginx.org/HttpProxyModule#proxy_pass_request_body),
>> нет в документации на русском
>> (http://sysoev.ru/nginx/docs/http/ngx_http_proxy_module.html) и нет
>> слов о ее отмене в changes (http://sysoev.ru/nginx/changes.html)
>
> Это недокументированная директива.
В смысле "забытая"? В changes есть слова о ее появлении.
Спасибо :)
Подробная информация о списке рассылки nginx-ru