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@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 - всё
сломается.

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

Проблемы HTTP pipelining'а - это то, что должен решать (и решает)
сам nginx в рамках функций чтения тела запроса. Фильтрам тела
запроса достаются уже прочитанные от клиента данные.

> >Из известных проблем - оно несовместимо со spdy, у которого, всилу
> >особенностей протокола, совсем своя логика чтения тела запроса.
>
> --
> Best regards,
> Valery Kholodkov
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

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