Подтвердить что ты не робот

HTTP Chunked Encoding. Нужен пример "Трейлера", упомянутого в SPEC

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

Как правило, HTTP chunked заканчивается следующим образом.

0\r\n
\r\n

В чем я смущен, так это то, как обнаружить конец куска, если есть какие-то трейлинг-заголовки...

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

4b9b3361

Ответ 1

0\г\п
SomeAfterHeader: TheData \r\n
\г\п

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

Ответ 2

Что касается трейлера:

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

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

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

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

Trailer: Content-Length

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

Shiflett дает следующий пример:

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)

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

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

Ответ 3

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

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

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

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

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