Данные HTTP кусков по нескольким пакетам?

Question

Как правильно HTTP-серверу отправлять данные по нескольким пакетам?

Например, я хочу передать файл, первый отправленный мной пакет:

HTTP/1.1 200 OK
Content-type: application/force-download
Content-Type: application/download
Content-Type: application/octet-stream
Content-Description: File Transfer
Content-disposition: attachment; filename=test.dat
Content-Transfer-Encoding: chunked

400
<first 1024 bytes here>

400
<next 1024 bytes here>

400
<next 1024 bytes here>

Теперь мне нужно создать новый пакет, если я просто отправлю:

400
<next 1024 bytes here>

Все клиенты закрывают там соединения со мной, и файлы обрезаются.

Какие заголовки я помещаювторой пакет для продолжения потока данных?

Answer 1

Похоже, мой недостаток повторения не позволяет мне комментировать вопрос, просто отвечаю на него, поэтому я предполагаю, что что-то вроде «вы пытаетесь реализовать HTTP 1.1 на веб-сервере встроенного устройства, котороеимеет пакетно-ориентированный сетевой стек вместо потоково-ориентированного "- это правда, иначе вы бы не говорили о пакетах.(Если вы говорите о чанках, см. Другие ответы.)

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

Если вы не можете по какой-либо причине - вы, вероятно, выбрасываете размер первого пакета.Ваш MTU, вероятно, что-то вроде 1500 или 1492 (или меньше), и у вас есть + 5 + 1024 + 5 + 1024 + 5 + 1024 байта в списке «в вашем первом пакете».Ваш сетевой стек может быть достаточно отстойным, чтобы он не выдавал вам коды ошибок, или ваш код может не проверять их - или он может делать что-то другое, столь же бесполезное.

Answer 2

HTTP не имеет понятия о пакетах.Ваш HTTP-поток может быть даже разбит на 1-байтовые пакеты.

Для кодирования по частям вы должны указать необходимые заголовки для каждого блока (которые не имеют отношения к пакетам), как указано в RFC.

Answer 3

Обычно вы используете заголовки Accept-Ranges и Content-Range со стороны сервера, чтобы уведомить клиента о том, что сервер принимает резюме.Затем клиент отправил бы заголовок Range обратно, чтобы запросить частичную загрузку.

Поскольку заголовок Content-Range требует определения полной длины файла, и здесь это кажется неизвестным(иначе не было абсолютно никакой причины выбирать кодировку chunked), вы потерялись из-за стандартной спецификации HTTP.Вы либо выберете другой протокол, либо создадите собственную спецификацию, либо поищете альтернативные способы заранее определить длину содержимого.

---

Тем не менее, три заголовка Content-Type не имеют смысла.Выбери один.Также Content-Transfer-Encoding не так, это должно было быть Transfer-Encoding.

Answer 4

Во-первых, вы хотите заголовок

Transfer-Encoding: chunked

не Content-Transfer-Encoding.

Кроме того, почему вы отправляете три разных Content-Type заголовка?

Answer 5

Вы действительно должны обратиться к rfc: http://www.w3.org/Protocols/rfc2616/rfc2616.html

В частности: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1