Hello! On Fri, Apr 12, 2013 at 12:20:05PM +0100, Anatoly Mikhailov wrote:
> > On Apr 12, 2013, at 10:29 AM, Maxim Dounin <mdou...@mdounin.ru> wrote: > > > Hello! > > > > On Thu, Apr 11, 2013 at 05:15:15PM +0100, Anatoly Mikhailov wrote: > > > >> > >> On Apr 10, 2013, at 12:43 AM, Maxim Dounin <mdou...@mdounin.ru> wrote: > >> > >>> Hello! > >>> > >>> On Tue, Apr 09, 2013 at 08:30:17PM +0100, Anatoly Mikhailov wrote: > >>> > >>> > >>> Так - должно работать, смотрите внимательно, что у вас в коде > >>> авторизатора на бекенде происходит. Видимо, он пытается лезть в > >>> тело, и вполне логично, что тела не находит - его ещё не читали. > >> > >> на бэкэнде у нас примитивный Rack, который к сожалению не пускает > >> запрос с пустым BODY, придется ограничиться Basic HTTP Auth для > >> запроса /upload... > > > > Как вам будет угодно. Но вообще - сделать body непустым, или > > убрать из запроса то, что ваш бекенд воспринимает в штыки - это ни > > разу не проблема: > > > > http://nginx.org/r/proxy_set_header > > http://nginx.org/r/proxy_set_body > > http://nginx.org/r/proxy_method > > > > Собственно, есть все механизмы для того, чтобы полностью > > сформировать запрос на бекенд. > > > > так (proxy_set_body off) заработало, спасибо > > location = /authentication/check { > proxy_set_header Content-Length ""; > proxy_pass_request_body off; > proxy_set_body off; > proxy_buffering off; > proxy_pass http://unicorn_api/authentication/check; > } Даже странно, честно говоря: - "proxy_set_body off" установит тело запроса в "off", что вероятно не совсем то, что вы хотели получить; - при этом "proxy_set_header Content-Length" таки уберёт из запроса Content-Length, и в результате передаваемые данные тела ("off") повиснут в воздухе; - "proxy_pass_request_body off" при использовании proxy_set_body смысла не имеет, исходное тело запроса в любом случае передано не будет. Скорее всего для удовлетворения поребностей вашего бекенда достаточно будет сделать так: location = /authentication/check { proxy_set_body "stub"; proxy_pass http://unicorn_api/authentication/check; } > В итоге "client_body_in_file_only on" и плагин "http_auth_request" в тандеме > превращаются > в отличное решение для аплоада больших файлов без необходимости пропускать их > файл через сокет (лишние операции копирования). Для того, чтобы данные лишний раз не пропускались через сокет - вполне достаточно одного client_body_in_file_only. Если мне не изменяет память, прозрачная поддержка этого со стороны php была одной из killer features php-fpm. Исходно документация была, судя по всему, тут: http://php-fpm.org/wiki/Features#Accelerated_upload_support К сожалению, сейчас по ссылке выше возвращается ошибка. > Плюс ко всему - предварительная > бэкэнд-аутентификация, которая не дает начать аплоад, если она не пройдена. > Насколько я понимаю, при обычном аплоаде бэкэнд-аутентификация запускается > только после того, как файл уже загружен и пропущен через сокет? Да. Но есть нюанс: если аутентификация таки не пройдёт, то, как и в случае ошибки 413, у браузера может не получиться нормально прочитать ответ. > Вопрос только один - почему эти просто замечательные вещи слабо > документированы? :) > Вы даже не представляете, насколько это востребованная типовая задача, > которую > почти всегда решают с помощью костылей, но nginx уже имеет все, что нужно. Да, недостаток HOWTO, не требующих думать, для типовых задач - это одна из основных проблем нашей текущей документации. С другой стороны, вот конкретно эта задача - она из области нетривиальных оптимизаций, и вряд ли стоит ожидать, что под неё в официальной документации найдётся HOWTO, из которого можно будет скопировать конфиг. -- Maxim Dounin http://nginx.org/en/donation.html _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru