resumable upload

[Valery Kholodkov]

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 at 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 в рамках функций чтения тела запроса.  Фильтрам тела
> запроса достаются уже прочитанные от клиента данные.

Так где API для этого? Какие функции нужно крутить, куда вставлять свои 
хэндлеры?

>>> Из известных проблем - оно несовместимо со spdy, у которого, всилу
>>> особенностей протокола, совсем своя логика чтения тела запроса.



-- 
Best regards,
Valery Kholodkov