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 <a...@bestmx.ru> 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@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
