proxy vs content-range

[Bogun Dmitriy]

В Срд, 23/12/2009 в 05:22 +0300, Ihalainen Nickolay пишет:

> > Еще раз говорю, знай я что по конкретному location'у будут многогиговые
> > статические файлы, апач бы никогда не получил туда запрос.
> это можно легко узнать на backend, если размер отдаваемого файла
> больше чем ваш разумный предел,
> то вместо ответа этого файла стоит сделать X-Accel-Redirect
> то, что на backend находятся большие файлы - это ошибка архитектуры.
> 
> логика буферизовать/не буферизовать в зависимости от хидера
> content-range порочна.
> этот хидер используется для докачки. в nginx такой костыль никогда не
> добавят (хотя вы можете и пропатчить).

Я знаю для чего нужен заголовок content-range, но последнюю вашу фразу
понять не могу. nginx корректно обрабатывает content-range при прямой
отдаче статики.

> > А вот теперь по теме:
> > Я лишь хочу выяснить и понять логику работы nginx модуля proxy при
> > облуживании запроса, у которого присутствует заголовок content-range, чтобы
> > иметь возможность его правильно настроить. О чем я собственно и спросил в
> > первом сообщении.
> >
> >> Если бы у меня была возможность разделить зоны вхостов на статические и
> >> динамические я бы просто статику прописал в отдачу на прямую nginx'ом и
> >> эту
> >> тему не поднимал бы.
> >>
> >> Меня больше интересыет логика работы nginx'а при проксировании запроса с
> >> установленным content-range. Зная ее можно будет планировать обход
> >> подобных
> >> проблемных мест.
> content-range не влияет логику проксирования и не должен этого делать.
> proxy получает запрос->передаёт его на backend->получает от backend
> ответ, кладёт в буфер в памяти
> если размера буфера не хватает пишет ответ на диск.

Почему же?
Если мы на backend передадим исходный запрос, с выставленным
content-range - к нам скорее всего вернется запрошенная, через
content-range, часть ответа. Как результат все будет работать гладко и
не так уж заметно портить жизнь при больших файлах. 
Если же при проксировании мы "потеряем" заголовок content-range, примем
полностью ответ от backend'а и лишь потом из этого ответа будет
выковыривать нужный клиенту кусок... это создаст большую проблему при
многопоточном скачивании больших файлов из-за наличия n копий этого
самого файла в proxy_temp_path и из-за необходимости копировать довольно
большой объем данных при запросе лишь малой части из них.

Судя по тому что я видел у себя, nginx работает по второму сценарию, но
это на столько нелогично что я пытаюсь тут это уточнить. А мне почему-то
упорно советуют вместо этого выключить буферизацию при проксировании и
не вникать в детали.

ЗЫ 
# nginx -V
nginx version: nginx/0.7.62
configure arguments: --prefix=/usr --conf-path=/etc/nginx/nginx.conf
--http-log-path=/var/log/nginx/access_log
--error-log-path=/var/log/nginx/error_log --pid-path=/var/run/nginx.pid
--http-client-body-temp-path=/var/tmp/nginx/client
--http-proxy-temp-path=/var/tmp/nginx/proxy
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi --with-md5-asm
--with-md5=/usr/include --with-sha1-asm --with-sha1=/usr/include
--without-http_fastcgi_module --with-http_ssl_module
--with-http_stub_status_module
--add-module=/var/tmp/portage/www-servers/nginx-0.7.62/work/nginx_uploadprogress_module

OS gentoo linux-2.6.28-hardened-r7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20091223/7bed784d/attachment.html>