Здравствуйте, netch80, Вы писали:

N>Нет, зависит от того, как работает генератор ответа.
N>В HTTP/1.1 и последующих есть chunked encoding, позволяющее отдавать ответ по частям — и клиент может его обрабатывать по частям по мере получения. Но можно и цельным телом. Это уже как серверу удобно. Оба варианта должны поддерживаться полноценными клиентами.
Даже без этого енкодинга ничто не мешает серверу сделать flush посреди потока с известной длиной.
И ничто не мешает клиенту начать обрабатывать получаемый ответ, не дожидаясь приезда всех данных по сети.

S>>2)Допустим имеется сервер, который получает огромный (8гб) файл от клиента. Вот у меня в api есть stream параметр (networkstream в случае дотнет). Верно, что в данном случае мой сервер получит http post, хотя его тело (т.е. 8гб), еще до конца не получено? Т.е. я получю один http post и начинаю читать содержимое, которое до конца-то может и не придти, т.е. получается что http post в данном случае может не знать свой размер.
N>Точно так же, можно chunked. Но тут уже вопрос дизайна повыше HTTP. Если отправляется 8GB, вероятность разрыва огромна — значит, у клиента должен быть какой-то аплоадер (скрипт в браузере или аналог), который вызывает команду отправки по частям, и закончив отправку — говорит "фиксируй и сохраняй на постоянное".
Тут есть нюанс — download по частям является частью протокола, а вот upload — нет. Поэтому придётся изобретать какие-то свои велосипеды для восстановления после сбоя.

Здравствуйте, Sinclair, Вы писали:

N>>Нет, зависит от того, как работает генератор ответа.
N>>В HTTP/1.1 и последующих есть chunked encoding, позволяющее отдавать ответ по частям — и клиент может его обрабатывать по частям по мере получения. Но можно и цельным телом. Это уже как серверу удобно. Оба варианта должны поддерживаться полноценными клиентами.
S>Даже без этого енкодинга ничто не мешает серверу сделать flush посреди потока с известной длиной.
S>И ничто не мешает клиенту начать обрабатывать получаемый ответ, не дожидаясь приезда всех данных по сети.

Без этого энкодинга сервер должен отдать Content-Length раньше начала передачи хоть одного байта, то есть знать уже длину ответа. Это не общий случай, хотя да, надо отметить это как очень важный частный случай (отдача статики). Но ТС формулировал вопрос в духе

>> когда клиент что-то заращивает у сервера http get(большой json объект с 10000 записей)

то есть динамическое формирование, и в этом случае такие послабления недопустимы.

Именно поэтому я не акцентировался на том, когда возможно знание длины до начала ответа.

S>И ничто не мешает клиенту начать обрабатывать получаемый ответ, не дожидаясь приезда всех данных по сети.

Кэп

N>>Точно так же, можно chunked. Но тут уже вопрос дизайна повыше HTTP. Если отправляется 8GB, вероятность разрыва огромна — значит, у клиента должен быть какой-то аплоадер (скрипт в браузере или аналог), который вызывает команду отправки по частям, и закончив отправку — говорит "фиксируй и сохраняй на постоянное".
S>Тут есть нюанс — download по частям является частью протокола, а вот upload — нет. Поэтому придётся изобретать какие-то свои велосипеды для восстановления после сбоя.

Ну ровно это я и написал. Что-то должно обеспечить 1) разрешение хранения временных неполных закачек, 2) идентификацию, 3) финализацию. И HTTP это не делает.

Здравствуйте, netch80, Вы писали:


N>Ну ровно это я и написал. Что-то должно обеспечить 1) разрешение хранения временных неполных закачек, 2) идентификацию, 3) финализацию. И HTTP это не делает.

А новые версии http это тоже, я так понимаю, не позволяют? А нет единого протокола поверх http все это иметь или каждый пишет свой костыль?

Здравствуйте, Sharov, Вы писали:

S>А новые версии http это тоже, я так понимаю, не позволяют? А нет единого протокола поверх http все это иметь или каждый пишет свой костыль?

Не костыль, а решение, адекватное задачи. Возможно у вас один блоб и вы его хочете порезать по 4мб и потом собрать его воедино (где собрать, в каком хранилище)? А возможно у вас 10000 объектов сериализованных раздельно в блоки разной длины, и вы их "собираете" напрямую в SQL каком нибудь. Много ли будет помощи от протокола в последнем случае?

Здравствуйте, Sharov, Вы писали:
N>>Ну ровно это я и написал. Что-то должно обеспечить 1) разрешение хранения временных неполных закачек, 2) идентификацию, 3) финализацию. И HTTP это не делает.

S>А новые версии http это тоже, я так понимаю, не позволяют? А нет единого протокола поверх http все это иметь или каждый пишет свой костыль?

Это вообще мало кто пишет кроме всяких гугл драйвов. На десяти мегабитах минутная закачка даёт 50+ мегабайтов чего большинству сервисов хватает с головой. Так что да, если тебе нужно закачивать гигабайты, придётся делать самому.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, netch80, Вы писали:


N>>Ну ровно это я и написал. Что-то должно обеспечить 1) разрешение хранения временных неполных закачек, 2) идентификацию, 3) финализацию. И HTTP это не делает.

S>А новые версии http это тоже, я так понимаю, не позволяют? А нет единого протокола поверх http все это иметь или каждый пишет свой костыль?

А зачем что-то общее и кто его может сделать?
Здесь 90% логической нагрузки приходится на
1) Блок, который режет на порции на клиентской стороне (что-то, скорее всего, яваскриптовое) — он будет очень сильно зависеть от фреймворка
2) Блок, который на сервере учитывает по конкретному пользователю, сколько он имеет права догружать (и что делать с промежуточными результатами)

Первое должно быть раздельным для всех ангуляров-вуев-что-там-сегодня-популярно, второй, соответственно, для серверных фреймворков. Вот там и спрашивай готовые решения.