Re: webdav в rest на nginx: upload, подзапрос, замена параметров запроса и ответа

[Maxim Dounin]

Hello!

On Mon, Oct 04, 2010 at 07:02:27PM +0400, Vasiliy Fedorov wrote:

> 2010/10/4 Maxim Dounin <mdounin at 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, то любые данные протаскиваются 
через $upstream_http_* - только надо не забыть запомнить их через 
set до того как следующее проксирование начнёт работу.

Если делать через auth request, то опять же любые данные 
протаскиваются через $upstream_http_*, в основном запросе доступны 
через auth_request_set.

> >> *: X-Accel-Redirect тут подходит плохо, хотя и используют для похожих
> >> вещей: http://kovyrin.net/2010/07/24/nginx-fu-x-accel-redirect-remote/
> >
> > X-Accel-Redirect подходит, но требует некоторой аккуратности в
> > написании конфигов.
> 
> То есть можно некоторыми ухищрениями добиться того чтоб контент не
> передавался для первого запроса, и передавался при редиректе?
> proxy_pass_request_body -- снова ключевое слово?

Да.

Только надо не забыть ещё и Content-Length в заголовках в 
соответствие привести, иначе протокол посыпется.

> > В большинстве случаев пропускать ещё не полученный запрос на
> > бекенд - излишняя трата ресурсов.  Кроме того, при таком подходе
> > пропадает возможность перепослать запрос на другой бекенд, если с
> > первым что-то случилось и он запрос недочитал.
> 
> Если проблема в этом, то можно запрос еще куда-нибудь копировать, но в
> общем-то можно сделать параметром конфигурации, наверно.
> 
> > Сделать подобный вариант обработки для больших постов безусловно
> > имеет смысл, но это 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 есть слова о ее появлении.

Всмысле "Beware! Ogres!".  При некорректном использовании может 
быть больно.

Maxim Dounin