Re: resumable upload

[Maxim Dounin <mdounin@xxxxxxxxxx>]

Hello!

On Fri, May 10, 2013 at 05:16:10PM +0200, Valery Kholodkov wrote:

> On 05/09/2013 01:54 PM, Maxim Dounin wrote:
> >Hello!
> >
> >On Wed, May 08, 2013 at 10:13:05PM +0200, Valery Kholodkov wrote:
> >
> >>On 05/08/2013 07:03 PM, Maxim Dounin wrote:
> >>>Hello!
> >>>
> >>>On Tue, May 07, 2013 at 09:37:38PM +0200, Valery Kholodkov wrote:
> >>>
> >>>>On 03/29/2013 11:46 PM, Anatoly Mikhailov wrote:
> >>>>>
> >>>>>On Mar 29, 2013, at 7:38 PM, Andrey N. Oktyabrski <ano@xxxxxxxxx> wrote:
> >>>>>
> >>>>>>On 29.03.2013 17:02, Валентин Бартенев wrote:
> >>>>>>>Просто когда дело заходит о том, что на грамотную реализацию и 
> >>>>>>>последующую
> >>>>>>>поддержку этого кода нужно потратить сколько-то человеко-часов, 
> >>>>>>>которые должен
> >>>>>>>кто-то оплатить, то часто выясняется, что большинству вопрошающих не 
> >>>>>>>очень то
> >>>>>>>оно и нужно было.
> >>>>>>Большинство вопрошающих вполне устраивал upload_module.
> >>>>>>
> >>>>>>P.S. Пожалуй, это тупиковая ветвь дискуссии.
> >>>>>
> >>>>>тупиковая, он поломался с nginx 1.3.9, а автор этого плагина забил на 
> >>>>>поддержку
> >>>>>уже как полгода.
> >>>>
> >>>>Пожалуй, это подходящий момент, чтобы прокоментировать ситуацию.
> >>>>
> >>>>Конечно, я мог бы ответить в стиле Валентина Бартенева -- "был бы
> >>>>спрос, мы бы всё сделали". Иными словами, "дайте денег -- всё
> >>>>будет".
> >>>>
> >>>>Однако, я считатю, что подобный ответ не соответствует моему уровню.
> >>>>Предлагаемая бизнес-модель не работает, я проверил это на
> >>>>собственном опыте. В то же время, поддерживать этот модуль на
> >>>>собсвтенном энтузиазме мне тоже не имеет смысла, так как я уже вырос
> >>>>из nginx (sic!).
> >>>>
> >>>>Nginx меня многому научил, и у меня появилось множество идей того,
> >>>>как всевозможные вещи реализовать на более высоком уровне, гибче и
> >>>>доступнее. Более того, часть из своих гипотез я уже успел проверить.
> >>>>Однако, я пока не уверен, что это выльется в конкретный проект.
> >>>>
> >>>>Поэтому, как видите, ситуация не может сдвинутся с мертвой точки,
> >>>>несмотря на то, что в nginx достаточно было бы поправить несколько
> >>>>строк.
> >>>
> >>>Валерий, если есть конкретные предложения, какие именно строки
> >>>поправить в самом nginx'е - пожалуйста, выскажи их.
> >>
> >>Чтобы работало достаточно вернуть переменную to_write в
> >>ngx_http_request_body_t.
> >
> >Если я правильно понимаю, это - не чтобы работало, а чтобы
> >собиралось.  В 1.3.9 появилась поддержка Transfer-Encoding
> >chunked, и если такой запрос попадёт в location с upload - всё
> >сломается.
> 
> Ты предлагал высказать мои предложения относительно того, что нужно
> исправить, -- я высказал. У меня нет ни времени ни желания
> отслеживать что и как вы там меняете и подстраиваться под эти
> изменения.

Fair enough.

> >>>Мне, к сожалению, не кажется, что дело ограничется парой строчек.
> >>>Чтобы нормально работать с телом запроса - нужен, в первую
> >>>очередь, механизм для этого, чтобы не приходилось, как это сейчас
> >>>сделано, переизобретать чтение тела запроса в каждом модуле,
> >>>которому что-то с телом надо сделать.
> >>
> >>>Я потратил некоторое время на создание такого механизма в рамках
> >>>работы над поддержкой chunked-запросов, но a) upload модуль
> >>>придётся заметно переписать, чтобы использовать этот механизм и
> >>>б) скорее всего нужно будет ещё что-то допиливать, чтобы с этим можно
> >>>было нормально работать из сторонних модулей.
> >>>
> >>>Если вдруг есть желание заняться/посмотреть - то патч можно взять
> >>>тут:
> >>>
> >>>http://mailman.nginx.org/pipermail/nginx-devel/2013-March/003492.html
> >>
> >>У меня самого где-то валяется подобный кусок кода. Проблема
> >>заключается в HTTP pipelining. Я уже два года назад просил механизм
> >>возвращения буферов в заголовок запроса. Без этого нельзя выйти из
> >>ситуации, когда за телом запроса незамедлительно следует часть
> >>заголовка следующего запроса.
> >
> >Проблемы HTTP pipelining'а - это то, что должен решать (и решает)
> >сам nginx в рамках функций чтения тела запроса.  Фильтрам тела
> >запроса достаются уже прочитанные от клиента данные.
> 
> Так где API для этого? Какие функции нужно крутить, куда вставлять
> свои хэндлеры?

Патч по ссылке выше как раз это API добавляет.  Интерфейс - 
подобен body-фильтрам ответа: добавляешь обработчик в цепочку 
фильтров (сохранив/поставив ngx_http_top_request_body_filter), 
по мере прихода данных от клиента - его вызовут с цепочкой 
прочитанных буферов.

-- 
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru