Данные HTTP разделяют на блоки по нескольким пакетам?
Каков корректный путь к серверу 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>
Все клиенты закрывают там соединения на мне, и файлы сокращены.
Какие заголовки я вставляю второй пакет для продолжения с потоком данных?
5 ответов
Отсутствие репутации не позволяет Чтобы прокомментировать вопрос, просто ответьте на него, поэтому я предполагаю, что что-то вроде "вы пытаетесь реализовать HTTP 1.1 на веб-сервере встроенного устройства, которое имеет пакетно-ориентированный сетевой стек вместо потокового one "верно, иначе вы бы не говорили о пакетах. (Если вы говорите о чанках, см. Другие ответы.)
Учитывая это - используйте сокеты, если можете; вам не нужно думать пакетами. Вероятно, где-то есть оболочка для вашего сетевого стека. Если нет, напишите такой, который не сильно повлияет на вашу производительность.
Если вы не можете по какой-либо причине - вы, вероятно, исчерпываете размер первого пакета. Ваш MTU, вероятно, примерно равен 1500 или 1492 (или меньше), и у вас есть + 5 + 1024 + 5 + 1024 + 5 + 1024 байта, перечисленные «в вашем первом пакете». Ваш сетевой стек может быть достаточно отстойным, чтобы не выдавать вам коды ошибок, или ваш код может не проверять их - или он может делать что-то еще, столь же бесполезное.
HTTP не имеет понятия о пакетах. Ваш HTTP-поток может быть даже разбит на пакеты по 1 байту.
Для кодирования с разбивкой на куски вы должны указать необходимые заголовки для каждого куска (что не имеет отношения к пакетам), как указано в RFC.
Вам действительно стоит обратиться к RFC: http://www.w3.org/Protocols/rfc2616/rfc2616.html
В частности : http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1
Обычно вы используете заголовки Accept-Ranges и Content-Range со стороны сервера, чтобы уведомить клиента о том, что сервер принимает возобновления. Затем клиент отправит заголовок Range обратно, чтобы запросить частичную загрузку.
Поскольку заголовок Content-Range требует представления о полной длине файла, а это, похоже, здесь неизвестно (иначе не было бы причин выбирать chunked кодировку), вы потеряны в отношении стандартной спецификации HTTP. Вы либо выберете другой протокол, либо разработаете собственную спецификацию, либо будете искать альтернативные способы узнать длину содержимого заранее.
Тем не менее, три Content-Type заголовка не имеют смысла. Выберите один. Также Content-Transfer-Encoding неверно, должно быть Transfer-Encoding.
Во-первых, вам нужен заголовок
Transfer-Encoding: chunked
, а не Content-Transfer-Encoding .
Кроме того, почему вы отправляете три разных заголовка Content-Type ?