HTTP Chunked Encoding. Нужен пример «Трейлера», упомянутого в SPEC - PullRequest
24 голосов
/ 08 апреля 2011

Я пишу парсер HTTP для прозрачного прокси.Что меня озадачивает, так это Trailer:, упомянутый в спецификации для Transfer-Encoding: chunked.Как это выглядит?

Обычно, HTTP-чанк заканчивается следующим образом.

0\r\n
\r\n

Что меня смущает, так это как определить конец чанка, если есть какой-токонцевые заголовки ...

ОБНОВЛЕНИЕ: Я считаю, что простой \r\n\r\n, то есть пустой строки достаточно для обнаружения конца концевых заголовков ...это правильно?

Ответы [ 3 ]

16 голосов
/ 21 июля 2014

Ниже приведена копия примера трейлера, скопированного с Сайт руководства по TCP / IP . trailer sample

Как мы видим, если мы хотим использовать заголовок трейлера, нам нужно добавить поле заголовка «Trailer: header_name» с именем заголовка, а затем добавить сущность заголовка трейлера после области тела фрагмента.

Мы можем добавить 0 или более заголовков трейлера в теле HTTP для RFC. Раздел 4.1.2 из RFC7230 запрещает использование следующих заголовков в области заголовка трейлера:

Отправитель НЕ ДОЛЖЕН генерировать трейлер, содержащий необходимое поле для формирования сообщения (например, Transfer-Encoding и Content-Length), маршрутизация (например, хост), модификаторы запросов (например, элементы управления и условия в Разделе 5 RFC7231 ), аутентификация (например, см. RFC7235 и RFC6265 ), данные управления ответом (например, см. Раздел 7.1 RFC7231 ) или определение способа обработки полезной нагрузки (например, Content-Encoding, Content-Type, Content-Range и Trailer).

Это означает, что мы можем использовать другие стандартные и пользовательские заголовки в области заголовка трейлера.

15 голосов
/ 15 апреля 2011

0 \ r \ n
SomeAfterHeader: TheData \ r \ n
\ r \ n

ВДругими словами, достаточно искать \r\n\r\n в терминах непрофессионала: пустая строка .Чтобы определить конец фрагментированной передачи.Но очень важно, чтобы каждый кусок читался перед этим.Потому что сами фрагментированные данные могут содержать пустые строки, которые ошибочно будут определены как конец потока.

13 голосов
/ 03 июля 2012

Относительно прицепа:

Список концевых заголовков должен быть указан в заголовке Trailer, как вы заметили.

BNF в Раздел 14.40 RFC 2616 таков:

Trailer  = "Trailer" ":" 1#field-name

Гурли и Тотти приводят этот пример:

Trailer: Content-Length

(Странно, что они приводят этот пример, поскольку Content-Length явно запрещен в качестве конечного заголовка в 14.40.)

Шифлет приводит такой пример:

Trailer: Date

Относительно конца сообщения с конечными заголовками:

BNF в Разделе 3.6.1 RFC 2616 - это то, что вы ищете. Вот часть:

Chunked-Body = *chunk
               last-chunk
               trailer
               CRLF
last-chunk   = 1*("0") [ chunk-extension ] CRLF
trailer      = *(entity-header CRLF)

Таким образом, последний кусок и 2 конечных заголовка могут выглядеть следующим образом:

0<CRLF>
Date:Sun, 06 Nov 1994 08:49:37 GMT<CRLF>
Content-MD5:1B2M2Y8AsgTpgAmY7PhCfg==<CRLF>
<CRLF>
...